Для корректного отображения этого элемента вам необходимо установить FlashPlayer и включить в браузере Java Script.
+7 (495) 775-33-76




Зонирование (zonning)

Зонирование (zoning) становится достаточно важным с того момента, как ваша сеть SAN начинает насчитывать более десятка устройств. Несколько странно, но в начале развития SAN шли дискуссии о том, достаточно ли сильна необходимость и важность зонирования для того, чтобы признать его стандартом Fibre Channel SAN. Даже в настоящее время зонирование является сравнительно новым явлением в области стандартов и реализации.

Что такое зонирование?


Основной задачей зонирования является разграничение потоков ввода/вывода в сетях хранения данных (SAN). Зонирование, может осуществляться адаптером сервера (HBA), контроллером RAID массива или непосредственно коммутатором (switch).

На любом сервере, даже NT, существуют различные механизмы для контроля того, какие устройства могут быть видимы для приложения, и может ли приложение осуществлять коммуникацию с другим устройством. На самом низком уровне программно-аппаратные средства адаптеров шины узла (HBA) и/или их драйверы имеют возможности маскирования для контроля за тем, может ли сервер видеть другие устройства сети. Кроме того, операционную систему можно сконфигурировать таким образом, чтобы контролировать какие устройства сервер пытается смонтировать в виде томов хранилищ. Наконец, многие используют программное обеспечение с множеством уровней для управления томами, кластеризацией и совместным использованием файловых систем, что также позволяет контролировать доступ приложений.

Для зонирования хранилищ, в большинстве дисковых массивов, существует форма выборочного представления (selective presentation). Массив сконфигурирован с учетом перечня серверов, которые имеют право на доступ к определенным LUN на определенных портах, и попросту игнорирует или отвергает запросы доступа с тех устройств, которые не включены в данный перечень.

Что касается зонирования коммутаторов, то большинство, если не все коммутаторы Fibre Channel поддерживают какой-либо тип зонирования для контроля за тем, какие устройства на каких портах могут осуществлять доступ к другим устройствам или портам.

Еще одной категорией контроля доступа является виртуализация, но в данной статье виртуализация не рассматривается.

Какой тип зонирования необходим?


Самым мудрым советом был бы следующий – использовать понемногу каждый из вышеперечисленных подходов. Контролируйте, какие устройства/LUNы устанавливаются на сервер, используя возможности операционной системы или программного обеспечения (например, не использовать подход ‘установить все’). Используйте выборочное представление в массивах хранения и зонирование в топологии fabric.
Зачем все это? Используя аналогию с компьютерной сетью, вы ведь не хотите, чтобы компьютер нелегально забрался в файлы вашей корпоративной системы. Для того чтобы предотвратить такую возможность, у вас есть списки контроля доступа (ACL) к файлам в файловых системах. Для контроля совместного использования у вас есть firewall, шлюзы безопасности, фильтрация пакетов и др. Каждый из этих элементов выполняет дополняющую и несколько отличную от других работу по защите ваших данных.

Как именно работает зонирование?


Ранее были рассмотрены общие принципы работы зонирования. Сейчас рассмотрим их более детально с технической точки зрения. Простыми словами, когда появляется новый хост и подключается к сети fabric, первая полезная вещь, которую он делает – это вход (logon) в fabric. Именно таким образом устройство получает свой 24-битный адрес, который будет использоваться для маршрутизации в fabric (SID или DID обычно относятся к исходному адресу или адресу назначения). Устройство уже имеет World Wide Name (идентификационное имя, присваиваемое производителем) или несколько имен, поскольку каждый порт узла или устройства будет иметь свое уникальное имя WWN порта, обычно запрограммированное в самом оборудовании. Существует также имя WWN хоста, которое определяет узел или устройство и должно проявляться одинаково для каждого порта.
Следующий шаг – подключение устройства к серверу доменных имен (name server) в сети SAN и его регистрация. SAN создает базу данных всех устройств в сети fabric, используя отображение (mapping) имен WWN узлов и портов на 24-битный адрес, а также характеристик каждого устройства. Это также включает в себя, определение того, является ли устройство FCP устройством, т.е. передающим SCSI команды через Fibre Channel.

В заключение, хост просит сервер доменных имен переслать список новых устройств FCP, которые он может видеть в сети fabric. И именно здесь включается зонирование. Сервер доменных имен пересылает список только тех FCP устройств, которые находятся в той же зоне (или в общей зоне). Иными словами, сервер может видеть только те устройства, которые ему разрешено видеть.

Таким образом, сервер имеет список 24-битных адресов всех тех устройств, которые он имеет право видеть. Затем он подключается к каждому порту, чтобы определить вид FCP/SCSI устройства. Это сходно с обычной схемой SCSI, где SCSI контроллер/сервер производит сканирование шины и запрашивает о свойствах каждого устройства, которое он может видеть на шине.

Это, по сути своей, и есть зонирование.

Существует множество терминов для определения различных подходов к зонированию и демонстрации усовершенствованных функциональных возможностей. Необходимо отметить, что в данной статье термин жесткое зонирование (hard zoning) не означает то же, что и port zoning, а мягкое зонирование (soft zoning) не обозначает то же самое, что и WWN zoning.

При конфигурации зоны, многие сети хранения данных (SAN) позволяют вам внести в список все устройства зоны, используя port ID или 24-битный адрес. Чтобы быть точным, синтаксис обычно таков - x,y, где x - доменное ID коммутатора, а y - номер порта на коммутаторе. Этот метод хорош, удобен и прост для понимания, подобно тому, как наблюдать на схеме как кабель из сервера номер 1 подключается к порту номер 3 коммутатора номер 5. Конечно, если вы измените топологию SAN, и измените положение кабелей в части сети SAN, вам придется заново конфигурировать все ваши зоны.

Другой подход к конфигурации зон – это внести в список устройства, входящие в зону, с использованием их имен WWN (это могут быть имена WWN портов или имена WWN узла). Этот подход имеет свои преимущества. Если вы измените доменное имя (ID) коммутатора, топологию SAN или место подключения устройства, зона по-прежнему будет находится в рабочем состоянии. В случае, если вам понадобится заменить адаптер шины узла (HBA), вам придется изменить зоны, поскольку WWN, как правило, ‘встроено’ в HBA, но в любом случае, это достаточно простое изменение.

Что такое жесткое и мягкое зонирование?


По сути, мягкое зонирование (soft zoning) – это директория X. Никто не скажет мне вашего номера телефона, но если я догадался, или набрал номер неправильно, ваш телефон все равно зазвонит. Защита мягкого зонирования состоит в том, что вам попросту не говорят вещи, которые вам не нужно знать (хотя, фактически, при известном любопытстве, любое устройство может сделать запрос серверу доменных имен, не входящему в данную зону).
По аналогии, жесткое зонирование (hard zoning) – это полный запрет вызова, установленный на вашем телефоне, так что даже если я и правильно угадал ваш номер, ваш телефон все равно не зазвонит. Вместо того, чтобы полагаться на то, что все граждане будут добропорядочны, данный подход обеспечивает реальную, серьезную безопасность.

Так в чем же путаница? Некоторые коммутаторы совсем не могут осуществлять жесткое зонирование. Некоторые коммутаторы могут осуществлять жесткое зонирование, но в данном случае зонирование не может опуститься до уровня отдельных портов и работает с большим количеством ограничений. Другие коммутаторы могут осуществлять жесткое зонирование только в том случае, если все зоны используют port-ID синтакс, отсюда предположение, что port-ID zoning является тем же самым, что и жесткое зонирование. В то же время, сейчас некоторые коммутаторы могут осуществлять жесткое зонирование тех зон, которые используют либо port-ID, либо WWN синтаксис.

Каковы различия между зонами и виртуальными сетями SAN?


Как известно многим, обычная рекомендация состоит в том, что всегда следует использовать две отдельных сети fabric, при этом каждое устройство должно быть подключено к обеим сетям. Для этого существует несколько причин, одна из которых состоит в том, что такие сервисы как сервер доменных имен работают как единый распределенный сервис внутри fabric. Поэтому, существует небольшая возможность (и она действительно небольшая), что неправильно работающее устройство может нарушить работу данного сервиса до такой степени, что пострадают и все остальные устройства в сети fabric, и не только находящиеся в той же зоне.
Идея виртуальной сети SAN (VSAN) – получить конструкцию более высокого уровня, с абсолютно отдельными базами данных серверов доменных имен, нежели одну общую для всех зон. Она даже может работать как полностью обособленная служба в коммутаторе, так что возможность взаимного негативного влияния работы устройств снижается, и проблемы проще локализовать.

Безусловно, все еще остаются другие проблемы, например, если устройство подключено к двум отдельным виртуальным сетям SAN и начинает плохо работать, в этом случае потенциально оно может привести к сбою в обеих виртуальных сетях SAN. Или стандартизированная система управления может использовать Fibre Channel запрос сервера доменных имен, не входящего в данную зону (unzoned name server query) с целью определить все устройства в сети fabric, но как эта команда отобразится (map) на виртуальных сетях SAN, которые на настоящий момент не являются стандартом Fibre Channel?

Итак, описав, что такое зонирование и как оно работает, (не позволяя серверам монтировать все LUN, которые он видит в fabric) перейдем к краткому описанию общих схем зонирования.

Общий хост (Common host)


Общий хост является самой распространенной схемой зонирования для малого и среднего бизнеса. Зоны устанавливаются по критерию общей операционной системы, производителя серверов или бренда адаптера шины узла (HBA), либо по иному подобному критерию. Это обеспечивает достаточно простой подход. В конце концов, NT серверы будут хорошо работать друг с другом, адаптеры Qlogic также будут прекрасно работать вместе. В результате вы получите зону, состоящую из общих серверов плюс устройства хранения данных, к которым им необходимо осуществлять доступ.

Одина цель, множество инициаторов (Single target multiple initiator)


Традиционно, многие подсистемы хранения работали согласно правилу, которое заключалось в том, что доступ к любому порту массива осуществляется множеством серверов, использующих одинаковую операционную систему. Те, кто начали работу с использования подхода ‘общий хост’ (common host), но затем пожелали увеличить степень детализации зонирования, увидели преимущества в том, чтобы каждая зона включала один порт массива хранения и все устройства, которые имеют право доступа к данному порту.

Один инициатор, множество целей (Single initiator multiple target)


Данный подход становится все более популярным в гетерогенных сетях SAN, он основывается на простой предпосылке -- SCSI инициаторам (серверы) нет необходимости обращаться к другим SCSI инициаторам. Поэтому производительный подход, позволяющий избежать любых потенциальных проблем, связанных с негативным влиянием серверов на работу друг друга, - иметь один сервер или один адаптер (HBA) в каждой зоне и затем помещать в данную зону все устройства хранения данных, к которым хост имеет право доступа.

Один инициатор, один исполнитель (Single initiator single target)


Это абсолютно безопасный подход, потому как он предполагает поддержание зон в пределах абсолютно возможного минимального размера, таким образом, обеспечивая максимальную безопасность зонирования. В нескольких случаях этот подход был весьма успешно реализован, но все же он не является очень распространенным. Без хорошего программного обеспечения, установить и управлять такими зонами очень трудно.

Заключение


Как и во многих иных областях, выбранный вами подход будет во многом зависеть от используемой технологии и принципов работы. Одно можно сказать с уверенностью – над зонированием необходимо задуматься, выбрать подход и использовать его полностью и с максимальной эффективностью.
Необходимо помнить, что зонирование не может стать ответом на все ваши проблемы. Но оно является очень важной составляющей организации хранения данных. Начните прямо сейчас, даже если вам кажется что это чересчур в небольшой сети SAN. Начав двигаться в правильном направлении, вам будет легче продолжать работать в будущем с надежным и производительным решением.


© Copyright "СТОРУС" 2003 - 2017