Компания Netwell ‐ российский дистрибьютор высокотехнологичного оборудования. Основные направления деятельности – сетевые технологии, системы хранения данных, сетевая и информационная безопасность. Netwell является официальным дистрибьютором компании NetApp.

NETAPP TECHNICAL REPORT

Наилучшие практики построения FC SAN

Mathew Devanny, Daniel Chan, Field Centers for Innovation, NetApp

March 2012 | TR-4017

КОРОТКО О ГЛАВНОМ:

Это руководство рассматривает наилучшие практики и рекомендации для построения сети FC SAN.

Руководство особо сосредотачивается на некоторых ключевых вопросах дизайна и работы SAN,

таких как избыточность, масштабируемость, конфигурирование фабрик, зонирование,

возможностях поддержки, мониторинг, конфигурация коммутаторов и безопасность.

2

Оглавление 1 Введение .................................................................................................................................................. 4

1.1 Система хранения: Требования по высокой доступности ............................................................ 4

2 Избыточность ........................................................................................................................................... 4

2.1 Топология Dual-Fabric ....................................................................................................................... 4

2.2 Подключение конечных устройств ................................................................................................. 5

2.3 Избыточность физических путей в датацентре .............................................................................. 6

2.4 Избыточность по питанию ............................................................................................................... 8

3 Масштабируемость ................................................................................................................................. 8

3.1 Виды сетевых топологий .................................................................................................................. 8

Топология Single-Switch....................................................................................................................... 9

Топология Core-Edge ......................................................................................................................... 10

Другие топологии .............................................................................................................................. 11

3.2 Устаревшие коммутаторы .............................................................................................................. 12

4 Конфигурация фабрики ......................................................................................................................... 12

4.1 Жестко заданные параметры фабрики ........................................................................................ 12

4.2 Остерегайтесь использовать «межсайтовые фабрики».............................................................. 13

4.3 Межкоммутаторные линки (Interswitch Links, ISL) ...................................................................... 14

4.4 Flow Control ..................................................................................................................................... 15

4.5 Длина очереди ввода-вывода (Queue Depth) .............................................................................. 15

4.6 Аппаратная архитектура коммутатора ......................................................................................... 15

4.7 Гетерогенные фабрики .................................................................................................................. 16

5 Зонирование .......................................................................................................................................... 16

5.1 Zonesets и Zone Configurations ....................................................................................................... 18

5.2 Изменения на обеих фабриках...................................................................................................... 18

6 Поддерживаемость (Supportability) ..................................................................................................... 19

7 Средства мониторинга .......................................................................................................................... 20

7.1 Мониторинг по SNMP ..................................................................................................................... 20

7.2 Syslog ................................................................................................................................................ 22

7.3 Аудит команд (CLI audit) и ролевая схема контроля доступа (RBAC) ......................................... 22

7.4 Мониторинг производительности ................................................................................................ 24

8 Конфигурирование коммутаторов ....................................................................................................... 24

8.1 Периодически создавайте резервные копии конфигураций ..................................................... 24

8.2 Стандартизируйте конфигурации.................................................................................................. 25

8.3 Создайте руководство по восстановлению «с нуля» .................................................................. 25

3

8.4 Проводите аудит конфигураций ................................................................................................... 26

8.5 Создайте диаграмму сети .............................................................................................................. 26

9 Безопасность .......................................................................................................................................... 27

10 Ссылки и справочные материалы ....................................................................................................... 28

4

1 Введение

1.1 Система хранения: Требования по высокой доступности Впервые сформулированный в 1988 году, и утвержденный в качестве стандарта в ANSI в 1994 году,

протокол Fibre Channel (FC) сегодня общепринятый способ соединения в сетях хранения данных

(storage area network – SAN). Сегодня FC SAN является широкораспространенным элементом в

большинстве сложных IT-сред. Необходимость поддержки разнообразных приложений

внутренней разработки, использующих различные инфраструктурные компоненты, становится все

более сложной, так как, обычно, все они работают с общими ресурсами, и ожидают

максимального уровня обслуживания, а также минимальной длительности простоев. По этой

причине, руководство наилучших практик по дизайну и реализации FC SAN будет крайне полезно

для многих администраторов и архитекторов IT.

Это руководство особо сосредотачивается на некоторых ключевых вопросах дизайна и работы

SAN, таких как избыточность, масштабируемость, конфигурирование фабрик*, зонирование,

возможностях поддержки, мониторинг, конфигурация коммутаторов и безопасность. Мы

полагаем, что читатель уже имеет базовое понимание принципов работы сети FC. Для

углубленного технического обсуждения принципов SAN, мы рекомендуем книги, приведенные в

справочном разделе, в конце этого документа.

2 Избыточность Один из наиболее очевидных методов обеспечения высокой доступности данных в SAN, это

способ обеспечить избыточность для всех критически важных компонентов системы.

2.1 Топология Dual-Fabric Бизнес требует высокой доступности хранилища данных, так как наиболее важные для его работы

приложения, как правило, не допускают его недоступности даже на короткое время. По этой

причине большинство (если не вообще все) вендоры систем хранения, рекомендуют для

подключения системы хранения в SAN топологию типа dual-fabric.

Топология dual-fabric работает как две раздельные и изолированные сети SAN, что означает, что

ни один отдельный выход из строя компонентов оборудования или ПО не сможет сделать

дисковое хранилище недоступным. Она также дает возможность выполнять обслуживание одной

из SAN fabric без воздействия на работу системы хранения. Рисунок 1 показывает пример полной

изоляции, обеспечиваемый топологией dual-fabric. Например, отказ коммутатора D не приведет к

отказу в доступе к системе хранения, так как путь к данным сохранится через SAN fabric A.

* Здесь и далее, в переводе для термина fabric (дословно – «ткань», «переплетение») будет использоваться

формально неправильное, но глубоко укоренившееся в практике русскоязычного IT слово «фабрика».

5

Рисунок 1) Полная изоляция путей в топологии dual-fabric.

Выделенные SAN, используемые для подключения систем резервного копирования на магнитной

ленте, обычно не используют топологию dual-fabric, так как приводы магнитных картриджей и

роботы-манипуляторы библиотек часто не поддерживают multipathing. Вместо этого обычно

используется топология single-fabric, хотя многие компании и предпочитают использовать для

таких задач те же коммутаторы FC, что обслуживают дисковые системы хранения.

С использованием топологии dual-fabric, каждая из пары фабрик должна быть включена и

сконфигурирована идентично между собой. Это определение включает в себя число и тип

использованных коммутаторов, параметры конфигурации фабрики, и то, каким образом

контроллеры системы хранения подключены в SAN. Согласованной конфигурацией в типовой

топологии проще управлять администратору SAN и обеспечивать уровень сервиса приложениям.

Топология dual-fabric требует двойного числа коммутаторов, по сравнению с топологией single-

fabric, и вам может быть соблазнительно выбрать топологию single-fabric из соображения

экономии бюджета. В этом случае, вы должны убедиться, что каждое устройство включено в эту

SAN множественными путями доступа, и что предприняты достаточные усилия для того, чтобы

минимизировать количество единых точек отказа. Дополнительно, важно, чтобы администраторы

SAN достигли взаимопонимания с администраторами приложений относительно необходимых

«окон обслуживания», до того, как SAN будет развернута. Если стоимость топологии dual-fabric

непозволительно высока для вас, вместо использования топологии single-fabric, рекомендуется

рассмотреть возможность использования iSCSI через IP-SAN, или оценить возможность

использования файловых протоколов, в качестве практичной альтернативы.

2.2 Подключение конечных устройств Руководство Fibre Channel and iSCSI Configuration Guide for the Data ONTAP 8.0 Release Family,

которое можно взять на сайте NetApp® Support (ранее NOW®), содержит детальное рассмотрение

поддерживаемых и рекомендованных методов подключения контроллеров систем хранения к FC

SAN. В этом документе можно найти подробное рассмотрение вопроса о предпочтительных

портах, использованных для достижения максимальной избыточности аппаратных ресурсов HBA

контроллера системы хранения. NetApp рекомендует для достижения максимального уровня

6

избыточности, при подключении серверов к контроллеру системы хранения, использовать порты

HBA в разных слотах PCI, или на разных шинах PCI, если это доступно.

В приведенном выше руководстве также рассматриваются различные максимумы конфигураций

для каждой из моделей контроллеров NetApp, включая максимальное число портов FC target на

контроллер системы хранения и максимальное соотношение fan-in ratio на target-порт. Это все

может также повлиять на ваши расчеты, лежащие в основе решения о выбираемой топологии

сети.

Правила, унаследованные от общего принципа данной сети SAN, должны быть идентичными на

всех фабриках SAN, таргет-порты должны быть разделены поровну между фабриками, если

реализуется dual-fabric SAN. Бизнес, со значительными объемами nonproduction-систем, должен

выделить специальные target-порты для их трафика. Это минимизирует эффект возможного

влияния трафика таких систем на более важный трафик production-систем. Кроме этого,

использование выделенных портов на контроллере системы хранения поможет принудительно

организовать разделение трафиков; такие группы портов (port sets) расширяют конфигурацию LUN

masking, закрепляя конфигурацию LUN masking за такой группой портов.

Бизнесы, которые имеют несколько различных серверных сред, с различными требованиями по

безопасности, должны использовать отдельные сети virtual SAN (vSAN) или virtual fabrics для

разделения их трафиков. Target-порты контроллеров системы хранения должны быть выделены и

закреплены в соответствии с необходимой классификацией.

Системы хранения на ленте и дисках могут использовать одни и те же коммутаторы SAN, но они

должны быть помещены в выделенные vSAN или virtual fabric. Устройства записи на ленту часто

работают с гораздо большим непрерывным потоком трафика чем дисковые устройства.

Отделение этого трафика в vSAN или virtual fabric предотвращает его влияние на работу дисковых

устройств.

Наконец, администраторы SAN должны рассмотреть возможность выделить в vSAN или virtual

fabric для подключения контроллеров систем хранения, используемых для виртуализации

хранилищ (это, например контроллеры NetApp V-Series) если соединение их с

виртуализируемыми системами делается через коммутаторы SAN. Каждая vSAN или virtual fabric

обслуживает свою собственную конфигурацию зонирования (zoning configuration) и сервисы

фабрики, усложняя для администраторов SAN возможность непреднамеренно изменить

настройки, влияющие на доступ контроллеров к back-end storage. Это неприменимо к ситуации,

когда контроллеры подключены непосредственно к back-end storage, минуя коммутаторы.

2.3 Избыточность физических путей в датацентре Если коммутирующее оборудование, принадлежащее двум разным SAN, размещено в общем или

смежных шкафах, следуйте перечисленным правилам, которые помогут снизить риски появления

«единой точки отказа».

Используйте различные многожильные кабели для передачи данных разных фабрик SAN.

Например, один 12-жильный оптоволоконный кабель, который передает данные обоих

фабрик SAN, будет являться «единой точкой отказа», так как его повреждение или разрыв

повлечет за собой повреждение обоих SAN-фабрик разом.

Выделите отдельную патч-панель для каждой отдельной фабрики SAN.

7

Ведите кабели и питание, относящиеся к разным фабрикам SAN, по разным сторонам

шкафа с оборудованием.

В некоторых больших промышленных SAN, core-коммутаторы SAN размещаются в

противоположных концах серверного помещения датацентра, используя полностью

раздельное подключение кабелями и кабельными каналами к шкафам, содержащим

edges-коммутаторы, инициаторы и таргеты.

Эти рекомендации могут выглядеть несколько экстремальными, поэтому, следует, в первую

очередь, руководствоваться принципами здравого смысла и осмысленности затрат; однако все

они потенциально сокращают время незапланированных простоев и повышают надежность

системы. Рис. 2 показывает пример обустройства избыточности физических путей в серверном

шкафу.

Рисунок 2) Избыточность физических путей в серверном шкафу.

Схема размещения оборудования в серверных шкафах должна быть хорошо продумана и

спланирована. Шкафы с сетевым оборудованием могут быть конечной точкой для сотен кабелей,

поэтому имеет смысл приобретать для них шкафы увеличенного размера (750mm) которые

разработаны для упрощения размещения большого количества кабелей.

Переполненные шкафы могут привести к повышению рисков при коммутационной работе. Это

увеличивает вероятность того, что кабели могут быть случайно повреждены или ошибочно

отключены при работе технического персонала в шкафу. В случае оптических кабелей проблемы

могут быть вызваны не только обрывом кабеля или отключением разъема; техперсонал при

работе может случайно негативно воздействовать на имеющиеся кабеля, например такой

параметр, как bit error rate (BER) может значительно увеличиться после простого сгибания кабеля.

8

Более просторные шкафы оборудования делают более простым следование рекомендациям и

наилучшим практикам в кабельной работе. Если техперсонал не зажат в тиски недостатка

времени и пространства, ему будет проще выполнять рекомендации и следовать правильным

методикам, соблюсти требования по радиусам изгибов, допустимым натяжениям и весу бухт

кабеля.

2.4 Избыточность по питанию Остерегайтесь возможного превышения потребления по питанию. Некоторые модульные

коммутаторы позволяют использовать такой oversubscription по электропитанию; это означает, что

при нормальной работе коммутатор может потреблять электричества больше, чем может ему

дать его источник питания, в случае отказа одного из входящих в него блоков питания. Это может

привести к тому, что коммутатор отключит некоторые свои порты, пока не будет восстановлен

достаточный уровень электропитания.

Большинство коммутаторов SAN имеют, как минимум, два блока питания, и они могут быть

включены в раздельно питаемые линии (PDU). Плохо спроектированная система электропитания

может привести к отключению коммутатора при обесточивании одного из PDU, и хотя топология

dual-fabric может помочь пережить такой сбой без потерь и недоступности данных, лучше

спроектировать электропитание таким образом, чтобы отказ одной из линий не влиял на питание

на второй.

3 Масштабируемость Масштабируемость есть важный параметр, позволяющий поддерживать хорошее состояние сети

и обеспечивать стабильный класс обслуживания для клиентов. Если расширение емкости SAN не

будет осуществляться просто, быстро и недорого, то администраторам SAN следует найти

альтернативную схему, ту, которая позволит немедленно удовлетворять требованиям

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

структуры.

Администраторы SAN должны хорошо понимать, каково максимальное число хостов,

контроллеров системы хранения и устройств на магнитной ленте может быть включено в SAN,

прежде чем принимается решение о вложениях в закупку коммутаторов и иного оборудования

SAN. Сеть SAN должна быть разработана и спланирована так, чтобы удовлетворять

определенному числу подключений в нее, и это число должно быть согласовано и

соответствовать планам стратегического развития IT-инфраструктуры данного бизнеса.

Однако часто бывает сложно определить, сколько серверов, систем хранения и устройств на

магнитной ленте может понадобиться бизнесу в будущем. Сделайте экспертную оценку; выберите

схему и дизайн, соответствующий текущим представлениям о будущем компании, и разработайте

план развития вашего дизайна сети на случай, если потребуется большее число подключений, чем

предполагается на сегодня, в случае развития бизнеса.

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

масштабируемости, это выбор топологии SAN; она влияет не только на общую емкость портов

SAN, но также на ряд других характеристик системы хранения. Чем больше слоев коммутации

содержит структура топологии, тем, обычно выше уровень масштабируемости, но также растут

9

показатели задержек (latency). Вне зависимости от того, какая топология выбрана, важно

реализовывать и использовать ее последовательно. Контроллеры системы хранения и серверы

должны включаться в заданные места сети с тем, чтобы два разных сервера не получали

различные показатели latency в SAN.

Топология Single-Switch

Вариант топологии с одним коммутатором на фабрику (single-switch) может использоваться в

случае, если известен «потолок» по «портовой» емкости сети, и эти требования можно

удовлетворить фиксированным числом портов. Компании малого и среднего размера часто

начинают с топологии single-switch, так как их датацентры, зачастую, сосредоточены в одном

помещении и число серверов статично.

Рисунок 3) Топология типа single-switch.

Компании малого и среднего бизнеса также часто просто арендуют место в чужом крупном

датацентре, поэтому иногда может сложиться такая ситуация, что если место в данной серверной

комнате исчерпано, то дополнительное пространство могут предоставить лишь в другой комнате,

на соседнем этаже. Соединение новых серверов, в дополнительном помещении, в коммутатор

SAN в старом помещении, может быть невозможным, даже если еще имеются свободные порты

на том коммутаторе. В этом случае, обычным решением является установка второго коммутатора

в фабрике во второй комнате.

Рисунок 4 показывает описанное развитие топологии single-switch.

Рисунок 4) Развитие топологии single-switch.

Эволюция системы, показанная на Рисунке 4, естественна, но имеет ряд недостатков:

10

Новая система хранения должна быть подключена к коммутаторам SAN в каждой из

серверных комнат датацентра, при этом используется вдвое больше портов на

коммутаторе и системе хранения.

Требуется зонирование на коммутаторах, чтобы выборочно соединять порты инициатора с

нужными таргетами, что обычно делается в «больших» SAN.

В фабрику включены два модульных коммутатора, каждый из которых имеет

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

В случае, когда серверы второй комнаты датацентра полностью заполнят порты

коммутатора, потребуется новый коммутатор в фабрике. Кроме этого, экспоненциально

растет количество кабелей для обеспечения интерконнекта с исходной инфраструктурой. В

результате мы получим топологию типа full-mesh.

Топология Core-Edge

Топология типа core-edge проще всего управляется (проще нее только single-switch) но имеет

возможности предсказуемо масштабироваться добавлением edge-коммутаторов. Единственный

core-коммутатор обеспечивает связь для всех таргет-портов фабрики, а другой уровень

коммутаторов, под названием edge-коммутаторы, обеспечивает соединения с серверами.

Наиболее важным является то, что такое структурное размещение серверов и систем хранения

обеспечивает стабильный и предсказуемый уровень сетевого сервиса, хотя задержки (latencies) в

ней и будут превышать таковые для топологии single-switch.

Edge-коммутаторы могут быть недорогими коммутаторами с фиксированной конфигурацией и,

располагаясь как конечный элемент коммутирующей структуры SAN, могут значительно снизить

стоимость и сложность кабельного подключения серверов. Коммутаторы FCoE предлагаются

сегодня производителями сетевого оборудования, и позволяют подключать сервера с помощью

медных кабелей TwinAx, что еще более снижает стоимость этого участка сети.

11

Рисунок 5) Топология core-edge.

Расширение топологии core-edge называется edge-core-edge. Несмотря на неплохую

масштабируемость, топология core-edge имеет конечную емкость портов и, в больших системах,

есть возможность того, что порты в core-коммутаторе могут быть исчерпаны. Топология edge-core-

edge позволяет дальнейшую масштабируемость решения, выводя соединения к системам

хранения на отдельные edge-коммутаторы, и делая все порты core-коммутатора портами ISL, для

подключения других edge-коммутаторов.

Другие топологии

Руководства по построению SAN часто рассматривают несколько других топологий SAN fabric,

таких, как топология ring, hub, и mesh.

Топология ring позволяет неограниченное расширение, и хотя типичная реализация имеет сильно

варьирующиеся основные характеристики, основная проблема в этой топологии – растущий с

увеличением размеров сети параметр latency в ней.

Топология hub-and-spoke, которая рассматривается во многих руководствах по дизайну сети, в

настоящее время вытеснена топологией core-edge и edge-core-edge, и является ее подмножеством

и частным случаем. В качестве недостатков руководства называют возможность выхода из строя

хаба, однако эта проблема решается использованием модели dual fabric.

Full mesh гарантирует расстояние single-hop к системе хранения для любого инициатора сети SAN,

однако требует большого числа интерконнектов к коммутаторам и контроллерам системы

хранения. Число интерконнектов увеличивается с добавлением каждого нового коммутатора (и

растет экспононенциально). Ранее рассмотренная в этом документе схема с двумя

12

коммутаторами, в разделе о топологии single-switch, по сути, является примером full mesh (хотя и

«вырожденной» его формой, из всего двух коммутаторов).

Топология partial mesh преодолевает эти ограничения, но демонстрирует степень сложности,

превосходящую рассмотренные топологии. Технически, любая нерегулярная топология может

рассматриваться как partial mesh, но администраторам SAN следует стремиться создавать такой

дизайн типа partial mesh, который обеспечивает сервис SAN независимо от места подключения

инициаторов и таргетов в сеть.

Список поддерживаемых топологий можно найти в документе Fibre Channel and iSCSI Configuration

Guide for the Data ONTAP 8.0 Release Family.

3.2 Устаревшие коммутаторы Обычно коммутаторы SAN более дорогостоящие, чем, например, коммутаторы Ethernet со

сходным количеством портов и аппаратной архитектурой. По этой экономической причине

администраторы SAN чаще вынуждены работать с устаревшим оборудованием, чем такое

происходит у администраторов сетей Ethernet, хотя, следует признать, обычно старые

коммутаторы SAN работают лучше и более функциональны, чем старые коммутаторы Ethernet.

Практичный (экономный) менеджер инфраструктуры руководствуется подходом «не сломалось –

не трогай» в отношении устаревших коммутаторов SAN.

Недостаток комбинации старых и новых коммутаторов SAN заключается в появлении двух

различных «уровней сервиса», в то время, как хороший администратор должен стремиться к

единому уровню сервиса в инфраструктуре.

В конечном счете, все упирается в затраты. Следует дать ответы на вопросы:

Сколько будет стоить замена всех старых 2Gbps SAN-коммутаторов?

Сколько будет стоить пересоединение всех хостов на новые коммутаторы 4Gbps/8Gbps?

Эти хосты также будут скоро списываться?

Могут ли эти хосты располагаться в шкафах ближе к новому оборудованию SAN?

Какие возможности отсутствуют на старых коммутаторах, например Secure Shell (SSH)?

Старые коммутаторы могут использовать ту же версию firmware, что и новые?

Если нет, то полностью ли совместимы старая и новая версии?

4 Конфигурация фабрики Хотя коммутаторы SAN будут нормально функционировать с настройками «из коробки», «по

умолчанию», без дополнительной настройки его параметров, однако такой подход не

рекомендуется.

4.1 Жестко заданные параметры фабрики Производители коммутаторов позволяют администраторам SAN конфигурировать различные

параметры фабрики, такие как значения тайминга и domain ID. Администраторы SAN должны

установить некоторые параметры, например domain ID, вручную и оставить автоматическое

конфигурирование других, таких, как, например, значения таймера. Эти параметры должны быть

согласованы между двумя фабриками.

13

Некоторые системы под управлением UNIX® используют Fibre Channel ID (FCID), назначенный им

фабрикой SAN, в качестве имени устройства UNIX, отображая различные пути к таргету. Если

коммутатор не использует постоянный domain ID (конфигурируется вручную), перезагрузка

коммутатора может привести к изменению domain ID в коммутаторе, изменению имени

устройства в UNIX, и, в результате, диск исчезнет для хоста UNIX.

Администраторы SAN должны контролировать выбор и назначение так называемого principal

switch фабрики вручную, используя приоритеты коммутаторов. Выберите мощный коммутатор в

логическом центре сети, например core-коммутатор, для назначения его как principal switch.

Такие параметры, как значения fabric timer, например, не следует изменять, пока вы не считаете

себя экспертом в SAN.

Значения таких параметров следует изменять только когда это действительно необходимо, и

хорошо продумав свои действия.

4.2 Остерегайтесь использовать «межсайтовые фабрики» Большие SAN должны остерегаться использовать фабрику, «растянутую» между датацентрами, так

как в фабрике может существовать конечное число domain ID. Рис. 6 и Рис. 7 показывают разницу

между маленькими и большими сайтами.

Рисунок 6) Дизайн межсайтовой фабрики (небольшие сайты).

14

Рисунок 7) Дизайн межсайтовой фабрики (большие сайты).

Отделение фабрик разных сайтов одной от другой, с использованием маршрутизации FC,

позволяет уменьшить вероятность проблем на одном сайте (или межсайтового линка), влияющих

на другой сайт. Это, однако, также увеличивает сложность SAN и может потребовать

дополнительных лицензий. В крупных SAN, однако, такие преимущества позволяют оправдать

рост сложности и стоимости.

Примечание: Для любой из рассмотренных схем следует помнить, что существует значение

максимального поддерживаемого числа хопов между инициатором и таргетом, зависящее от

производителя коммутатора. Для более подробного рассмотрения темы, смотрите руководство

Fibre Channel and iSCSI Configuration Guide for the Data ONTAP 8.0 Release Family.

4.3 Межкоммутаторные линки (Interswitch Links, ISL) Когда таргеты и их инициаторы оказываются в различных коммутаторах SAN, межкоммутаторные

линки (interswitch links, ISL) становятся обычным местом затора трафика сети; большое количество

инициаторов «борются за место» в канале ISL, это то, что принято называть «contention». Однако

contention в ISL не всегда обязательно ведет к проблеме. Администратор SAN должен наблюдать

за реальной загрузкой ISL и принимать меры по необходимости.

Если администратор SAN наблюдает постоянное заполнение линков ISL трафиком, следует

использовать одну из двух возможностей:

Настройте многопутевую (multipath) конфигурацию. Multipathing на инициаторах может

быть настроен таким образом, чтобы доступ к системе хранения использовал

альтернативный путь доступа. Это может облегчит нагрузку на ISL, заставив инициатор

использовать путь через другую фабрику.

Добавьте дополнительные физические линки в ISL. Коммутаторы могут объединять

несколько физических линков в один логический линк, например у Cisco® это называется

port channeling, а у Brocade - ISL trunking. Для объединения множественных линков обычно

достаточно совсем небольшого объема настроек, и NetApp рекомендует конфигурировать

коммутаторы на использование link aggregation даже если в логическом линке будет всего

15

один физический; такая настройка позволит позднее, при необходимости, на ходу

добавить в такой логический линк еще физических.

Следует остерегаться ситуации с «насыщением» ISL, и администраторы SAN должны упреждающе

наблюдать и анализировать производительность ISL в их SAN.

4.4 Flow Control FC SAN реализует flow control иным способом, чем это делается в Ethernet и сетях на базе IP.

Рискуя впасть в чрезмерное упрощение, это можно описать как светофор на въезде на хайвей;

передача трафика в линк не разрешается до тех пор, пока это не разрешит устройство на другом

конце. Порты SAN используют так называемые buffer credits, которые пополняются устройством с

другого конца линка, и каждый фрейм FC забирает из бюджета порта при передаче один buffer

credit.

Настройка flow control в SAN использует множество настраиваемых параметров, однако менять их

значения не стоит до тех пор, пока это не будет вам порекомендовано в руководстве от

производителя коммутатора; если они будут установлены неверно, это может создать проблемы

поддержки системы.

Часто производители коммутаторов FC рекомендуют конфигурировать межсайтовые линки (ISL) с

большим количеством buffer credits для увеличения пропускной способности линка. Однако,

современные OS коммутаторов SAN абстрагируются от чисел buffer credit и вместо этого

предлагают администратору при настройке ввести расстояние между датацентрами в километрах.

4.5 Длина очереди ввода-вывода (Queue Depth) Производители систем хранения делают специальные рекомендации, относительно настройки

величины длины очереди (queue depth) на хост-сервере. Важно следовать этим рекомендациям

для большинства устройств, подключенных в SAN- fabric. Исключения могут быть сделаны для

устройств с экстремально высокой нагрузкой по вводу-выводу, но все такие исключения должны

предварительно оцениваться и отслеживаться.

Продукт NetApp FC Host Utilities автоматически настраивает величину очереди на хосте в

соответствии с рекомендациями NetApp. Она может быть отдельно настроена в случае особых

случаев рабочей нагрузки или специальных требований системы. NetApp требует установки Host

Utilities для всех серверов, использующих FC и iSCSI.

4.6 Аппаратная архитектура коммутатора Различные модели коммутаторов используют различные аппаратные архитектуры. Обратите на

это особое внимание и постарайтесь понять на верхнем уровне особенности реализации, и

особенности максимальной пропускной способности на уровне индивидуальных портов и их

групп.

Не рассчитывайте, что каждый порт вашего коммутатора может работать на устойчиво высокой

скорости передачи данных. Выделите порты, которые обеспечивают максимальную пропускную

производительность, под задачи ISL и для подключения контроллеров системы хранения.

Примите во внимание то, что, в ряде случаев, вам придется оставить некоторые порты

неиспользуемыми, чтобы гарантировать пропускную способность других портов на высоком

уровне.

16

Проконсультируйтесь со справочной литературой вендора, выпустившего коммутатор, и, если

необходимо, найдите учебный курс по соответствующей модели.

4.7 Гетерогенные фабрики Как общее правило, NetApp не поддерживает гетерогенные фабрики SAN. «Гетерогенная

фабрика» определяется, как фабрика SAN, включающая в себя коммутаторы более чем одного

вендора.

Это правило имеет исключения в области встроенных коммутаторов blade-серверов. В этом случае

коммутаторам может потребоваться настройка на работу в режиме interoperability mode, при этом

следует проконсультироваться с документацией производителя коммутатора SAN. Для справки о

поддерживаемых комбинациях коммутаторов blade-серверов и обычных коммутаторов SAN,

также полезно проконсультироваться в NetApp Interoperability Matrix Tool.

5 Зонирование Зонирование, применяемое в сети FC SAN, это форма контроля и разграничения доступа к

сервисам хранения. Оно управляет тем, какие инициаторы какие таргеты «видят» в сети.

Наиболее общая рекомендация по конфигурации зонирования, это использовать общие, единые

для всей SAN методы и параметры. В повседневной работе SAN, конфигурация зонирования это

то, что меняется чаще, чем любая другая часть конфигурации. Сложность администрирования

значительно уменьшается (в особенности, если группа администраторов состоит из нескольких

человек), если конфигурация зонирования четко определена.

Рассмотрим следующие рекомендации и практики:

Зонирование с одним инициатором на зону (sngle-initiator zoning) это наиболее

популярный метод зонирования, он рекомендуется NetApp и многими другими

производителями оборудования для SAN. Такая схема означает, что одна зона содержит

один инициатор и один или несколько таргетов. Зоны должны быть сконфигурированы

таким образом, чтобы минимизировать количество таргет-портов, видимых инициатором.

Чем больше лишних таргет-портов видит порт-инициатор, тем дольше будет происходить

опрос таргетов инициатором в поисках его LUN. Это может увеличить время файловера и

перезагрузки сервера.

Основные производители оборудования SAN рекомендуют использовать для зонирования

worldwide port names (WWPN), чтобы идентифицировать инициаторы и таргеты, в

особенности для новых моделей коммутаторов SAN.

Это не значит, что метод с использованием domain ID/port ID для идентификации не имеет

своих достоинств. Однако производители оборудования SAN сочли, что на сегодня метод

идентификации с использованием WWPN работает лучше. Многие SAN по-прежнему

используют метод domain ID/port ID для идентификации инициаторов и таргетов, поэтому

администраторам SAN следует рассмотреть возможность обновить свои процессы и

процедуры, с тем, чтобы перейти на идентификацию и конфигурацию зонирования по

WWPN.

Следует использовать алиасы для идентификации WWPN, это позволяет администратору

SAN ввести WWPN только раз, что уменьшает вероятность ошибки.

17

Производители коммутаторов рекомендуют не смешивать в пределах одной зоны WWPN

и domain ID/port ID.

Большинство производителей оборудования SAN предлагают два метода изменений в

конфигурации зонирования, использование специального GUI (вход в графический веб-интерфейс

по HTTP или с помощью специального приложения управления SAN, например Cisco Fabric

Manager, недавно ставшего Cisco Data Center Network Manager) или через CLI на коммутаторах.

Многие администраторы SAN используют только GUI, не рассматривая преимущества, имеющиеся

у CLI.

Вариант 1: Вариант 2: Вариант 3: Небольшая команда Разделение задач Разделение задач использующая GUI с использованием CLI с использованием приложения управления

Рисунок 8) Изменения в конфигурации зонирования: GUI или CLI?

Для небольших организаций, где изменения в планах и реализации выполняются, обычно, одной

и той же группой администраторов, или одним человеком, использование GUI упрощает работу.

Изменения в настройках зонирования с помощью визуальных средств в GUI проще для многих

администраторов SAN.

В больших организациях, где изменения в планах и их реализацию осуществляют различные

группы административного персонала, когда практические операции на технике, зачастую,

переданы на аутсорс сторонней компании, следует серьезно обдумать возможность

использования метода CLI.

Изменения с использованием CLI могут быть спланированы заранее, до фактического применения

их на технике, проанализированы, и, наконец, выполнены оператором, просто копирующим

необходимые команды из подробной инструкции в окно терминала. В таком варианте, работа

оператора становится гораздо более простой. Некоторые приложения управления SAN позволяют

передавать команды CLI через GUI приложения управления. Это позволяет «проксировать» доступ

к консоли управления коммутатора SAN, и это более безопасный вариант, использующий

преимущества CLI, и который часто подходит в ситуации с аутсорсингом работ сторонней

организации.

18

5.1 Zonesets и Zone Configurations Использование zonesets (Cisco) или zone configurations (Brocade) это быстрый путь «откатить»

изменения в настройках зон.

Сложные изменения на больших конфигурациях зон могут быть «откачены» в исходное состояния

с помощью небольшого числа команд, без необходимости манипулировать отдельными зонами.

NetApp рекомендует этот механизм, даже для опытных операторов. Рис. 9 показывает процесс

создания сложных изменений в зонах с использованием минимального количества команд.

Рисунок 9) Изменения в конфигурациях зон с использованием клонированных конфигураций.

5.2 Изменения на обеих фабриках Даже в случае использования конфигурации dual-fabric SAN, бизнес по-прежнему может

пострадать от незапланированного отказа в результате операторской ошибки. Хорошо

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

выполнялись на разных фабриках в разное время.

После того, как оператор SAN внесет изменения в одну фабрику, наступает время провести

некоторое количество тестирований, чтобы убедиться, что изменения привели к желаемому

результату, и нет никаких нежелательных эффектов. Тестирование на нежелательные эффекты

может быть довольно непростым. На любых SAN, кроме самых маленьких, войти на каждый хост и

проверить, что все диски остались подключенными, часто не представляется возможным.

Выдержать паузу, прежде чем менять что-то на второй фабрике – полезный способ дать

возможность проявится и вылезти на свет всем возможным проблемам. Если нежелательные

эффекты изменений обнаружены, то изменения второй фабрики SAN следует отложить. Рис. 10

показывает шаги изменений на обеих фабриках SAN.

19

Рисунок 10) Проведение изменений на обеих фабриках.

Для того, чтобы определить как долго стоит выжидать, прежде чем применять изменения на

обеих фабриках SAN, администратору SAN следует задать себе следующие вопросы:

Мы выполняем такие изменения нечасто?

Вызывали ли такие изменения неожиданные проблемы ранее?

Невозможно сделать статистическую выборку, чтобы убедиться, что все работает?

Чем больше ответов «да» или «не знаю» дано на эти вопросы, тем дольше администратор SAN

должен выждать, прежде чем применять изменения на второй фабрике SAN.

6 Поддерживаемость (Supportability) Вопрос «поддерживаемости» (supportability) в FC SAN – это крайне важный аспект ее

существования. SAN значительно отличается от сетей Ethernet и IP, где используется «неявное»,

«подразумеваемое» понятие поддержки для конфигурации, и именно такая «неявная

поддерживаемость» несет частичную ответственность за большую популярность сетей Ethernet и

IP над FC.

«Поддерживаемая конфигурация» это такая конфигурация, в которой любой из участвующих в

конфигурации производителей компонентов вашей SAN, будь то коммутаторы, HBA, или

контроллеры системы хранения, поможет вам, если вы с ним свяжетесь. Производители

коммутаторов FC, производители систем хранения, производители HBA, операционных систем и

приложений, все они поддерживают как «гарантировано работоспособные» только конечные

наборы конфигураций участвующих в SAN компонентов, и на администратора SAN возлагается

бремя удостовериться, что то, что было развернуто в SAN, упоминается в каждой из матриц

совместимости, всех участвующих производителей. Если это не так, то сервисная служба

соответствующего производителя, конечно, постарается помочь, когда вы откроете кейс в его

поддержке, но первый его совет наверняка будет изменить конфигурацию на проверенно

поддерживаемую.

Перед тем, как разрабатывать дизайн, следует свериться с матрицами поддержки каждого из

участвующих в проекте вендоров оборудования. Матрица поддержки самого NetApp называется

Interoperability Matrix Tool.

Поддерживаемость создаваемой конфигурации в SAN необходимо оценить и обеспечить до того,

как SAN будет развернута, так как добиваться поддерживаемости конфигурации на уже созданной

20

сети может оказаться чрезвычайно затратно. Если вы по долгу службы получаете под свое

командование уже построенную и развернутую SAN, NetApp настоятельно рекомендует

озаботиться вопросами поддерживаемости на уровне участвующих в построении SAN вендоров

так скоро, и с таким высоким приоритетом, как это возможно.

Рисунок 11) Оценка поддерживаемости решения.

На рисунке 11, у администратора SAN есть фабрика SAN, работающая на коммутаторах Brocade

48000 и Brocade 5300, на которых используется Brocade Fabric Operating System (FOS) version

6.3.2b2. Администратор системы хранения хочет знать, поддерживается ли в такой конфигурации

новый контроллер, работающий под управлением NetApp Data ONTAP® 7.3.5. Воспользовавшись

NetApp Interoperability Matrix, мы можем убедиться, что такая конфигурация поддерживается

NetApp (номер конфигурации 20110304-094931971, статус: Supported).

Далее серверный администратор предлагает подключить новый сервер платформы 64-bit Intel® к

SAN, с использованием HBA Emulex LP11000 и Microsoft® Windows Server® 2008 R2 Enterprise

Edition. NetApp Interoperability Matrix подтверждает 21 конфигурацию, поддерживаемую NetApp,

содержащую перечисленные параметры выборки. Администратор сервера может использовать

одну из этих поддерживаемых конфигураций, чтобы определить какую версию HBA firmware,

драйвера, Host Utilities Kit, и так далее, следует ему установить на сервер.

Чтобы убедиться, что другие производители участвующего оборудования (производитель

сервера, Microsoft, и Emulex в данном примере) поддерживают получившуюся конфигурацию,

администраторы сервера и системы хранения должны свериться с матрицами поддержки

вендоров используемого оборудования.

7 Средства мониторинга Для мониторинга фабрики SAN существует множество инструментов. Эта глава рассматривает

функциональность, которая требуется для работы высокодоступной SAN.

7.1 Мониторинг по SNMP Все современные коммутаторы SAN имеют в своем составе демон протокола Simple Network

Management Protocol (SNMP), посылающий трапы и отвечающий на запросы, а также

обеспечивающие передачу сообщений системы в формате syslog на удаленный сервер. Эти

возможности могут быть использованы для обеспечения высокодоступного сервиса; более того,

без использования таких средств мониторинга сервис высокой доступности и невозможно

21

создать. Может быть, администратор SAN и может вручную управлять и визуально наблюдать

каждый коммутатор сети SAN с понедельника по пятницу, но что делать с выходными днями, или

временем отпуска?

Рисунок 12) Прямой мониторинг коммутатора SAN.

Приложения управления, выпускаемые производителями оборудования SAN, например Cisco

Fabric Manager (недавно преобразованный в Cisco Data Center Network Manager) или Brocade Data

Centre Fabric Manager (ныне Brocade Network Advisor), могут помочь мониторить коммутаторы SAN

и автоматически отправлять уведомления администраторам по e-mail или с помощью пейджеров.

Приложения от производителей коммутаторов SAN могут помочь со своевременным

уведомление о событиях, связанных с коммутаторами SAN, но они, как правило, не могут помочь

со слежением за другими типами оборудования инфраструктуры.

Рисунок 13) Мониторинг коммутатора SAN с использованием централизованной системы

мониторинга.

Большие или работающие с mission-critical системами SAN могут потребовать интеграции в

специализированную систему мониторинга, такую как HP OpenView или IBM Tivoli suite.

Преимущество таких больших систем мониторинга в том, что они позволяют наблюдать из одного

приложения за всеми компонентами инфраструктуры разом.

22

В приложении, которое консолидирует разнородные события, появляется возможность

анализировать корреляцию таких событий между собой. Отказ кондиционера в датацентре проще

диагностировать при наличии консолидирующего события приложения; если почти любой

элемент инфраструктуры умеет посылать SNMP trap, сообщая, например, о повышении

температуры, операторы могут оценить обстановку и принять решение о вызове техника по

кондиционерам, вместо того, чтобы посылать все тревожные сообщения на пейджер дежурному

администратору инфраструктуры.

Важно включить и использовать опрос коммутаторов с использованием Internet Control Message

Protocol (ICMP). В случае внезапных проблем, у коммутатора может не оказаться достаточно

времени, чтобы сформировать и послать SNMP trap перед уходом в оффлайн.

7.2 Syslog Syslog можно использовать для мониторинга, однако это также важный инструмент диагностики.

Анализ сообщений syslog это важный аспект обнаружения ошибок и проблем в фабрике SAN до

того, как они вызовут проблемы, этот анализ также помогает найти причину и источник, когда эти

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

можно было использовать для диагностики; некоторые производители оборудования SAN в своих

приложениях управления не позволяют администраторам видеть всю информацию в «сыром»

виде, и предоставляют ее только в виде сообщений об ошибках.

Если вы столкнулись с проблемами в сети, вы сможете воспользоваться записанными

сообщениями. Администраторы должны периодически просматривать и очищать хранилище

syslog, и оценивать то, что происходит в SAN. Каждое сообщение в логах имеет тот или иной

смысл и значение; разобраться в том, важное сообщение поступило в логи или нет – прямая

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

поддержки производителя оборудования для того, чтобы понять, о чем идет речь. Выполните

поиск в Google или откройте кейс в поддержке, если это необходимо.

Запишите сообщение и разберитесь, требует ли оно вмешательства человека. Поделитесь этой

информацией с вашими коллегами по группе администрирования.

7.3 Аудит команд (CLI audit) и ролевая схема контроля доступа (RBAC) В SAN, которой управляет большой административный персонал, или которая отдана на

аутсорсное администрирование, следует предусмотреть возможности аудита команд (CLI audit

log), которые будут записываться и пересылаться в центральное хранилище. В SAN следует также

реализовать ролевую схему контроля доступа (Role-based access control, RBAC), только

минимально необходимое число персонала должно иметь возможность работать с правами root.

В дополнение к этому, доступ к центральному хранилищу логов должен быть ограничен и

контролироваться с тем, чтобы гарантировать, что записи в нем не были изменены или

уничтожены.

Это может показаться несколько экстремальной мерой для многих систем, если этого не требуют

некоторые специальные правовые нормы государства. Однако представьте, что любой сотрудник

административной команды, числом более трех человек и более, может правдоподобно отрицать

свои действия и свое участие в возможном инциденте. Эффективный анализ первопричин

необходим для любой попытки улучшений и, пока действия неквалифицированных операторов не

23

будут идентифицированы, анализ этих причин становится предельно трудным в случае, если

подозревается ошибка оператора.

Вот пример того, как введение RBAC и CLI auditing улучшает поведение операторов. Группа IT-

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

проблемы. Администраторы вынуждены работать над исправлением ситуации по ночам, так как

днем система загружена работой и не дает возможности заниматься ремонтом. Менеджер

проектов находится под сильным давлением, а административная команда вымотана, что ведет к

еще более значительным проблемам с системой.

Чтобы справиться с ситуацией, руководитель административной группы принимает решение

внедрить RBAC и сконфигурировать CLI audit logs для отсылки их в центральное хранилище. На

следующую же ночь частота возникновения одного из инцидентов упала до нуля, когда члены

административной команды узнали, что все их действия будут видны их коллегам.

Конечно, важно подчеркнуть администраторам, что осуществление этих мер не есть попытка

обвинить кого-то конкретно, в случае, когда дела идут плохо; скорее это делается для того, чтобы

команда сотрудников могла эффективнее выполнить анализ причин, породивших проблему, и

сделать так, чтобы проблема более не повторялась.

Когда данное решение внедрено, важно регулярно проверять логи CLI audit, в особенности, если

задачи администрирования отданы на аутсорс сторонней компании. CLI audit logs обычно

используется одним из двух способов. Либо они не трогаются до возникновения проблем, после

чего делается ретроспективный анализ, или они проверяются регулярно и периодически, второе

чаще используется для компаний, находящихся под определенными законодательными

требованиями.

Рисунок 14) Схема аудита логов CLI.

Каждая компания должна иметь политику того как и когда следует проводить изменения в

конфигурации ее инфраструктуры. Например, компания может иметь политику, определяющую,

что все конфигурационные изменения в SAN должны сопровождаться записями в системе

контроля изменений.

24

Внутренний аудитор должен периодически просматривать логи аудита команд (CLI audit logs) и

проверять, что каждой строке команды там соответствует запись в системе контроля изменений.

Эти записи могут не быть исчерпывающими, вполне достаточно краткого объяснения того,

соблюдаются или нет политики изменений конфигурации в организации.

7.4 Мониторинг производительности Сбор данных о производительности с коммутаторов SAN – это насущная необходимость при

эксплуатации и настройке оптимальной работы фабрики SAN. Администраторам SAN требуется

видеть величины использования сетевой пропускной емкости в различных критичных точках сети,

чтобы своевременно устранять любые возможные заторы и «узкие места».

Детальные данные о производительности также важны для ответов на вопросы от других

администраторов. Проблемы производительности часто «скатываются» по цепочке в самый низ,

и, зачастую, решаются сетевыми администраторами и администраторами приложений на их

уровне. Администраторы SAN часто вынуждены отвечать на вопросы о производительности перед

администраторами других уровней системы и наличие таких данных о производительности

снимает бремя доказывания того, что проблема находится именно на стороне SAN.

Используя NetApp OnCommand™ Insight suite, с лицензией performance, вы можете собрать

подробную информацию о производительности для портов коммутатора. Он также поможет

собрать детальную информацию о производительности с виртуальных машин и систем хранения,

вплоть до уровня томов и LUN-ов. Он автоматически свяжет имена хостов с данными

производительности томов и LUN-ов, обеспечивая точный и полный обзор состояния

производительности сервисов хранения. Важно также и то, что это продукт не требует установки

агентов (agentless), так что вы можете быстро и просто развернуть его на уже существующей

системе.

8 Конфигурирование коммутаторов

8.1 Периодически создавайте резервные копии конфигураций Конфигурация коммутатора должна сохраняться в резервную копию регулярно, а также перед

любыми изменениями в ней. Создание резервной копии на регулярной, периодической основе

позволит восстановить коммутатор в случае внезапного аппаратного сбоя.

Создание резервной копии непосредственно перед изменениями гарантирует возможность

быстрого отката изменений и возврата к предшествующему состоянию, если понадобится срочно

отказаться от этих изменений. Администраторы SAN обычно используют две процедуры «отката»

изменений: «мягкий откат», при котором откатываются только сделанные изменения в

конфигурации, и «жесткий откат», когда на коммутатор применяется ранее сохраненная

конфигурация, и делается полный его перезапуск.

«Конфигурация» означает не только «программная конфигурация». Это также относится к

кабельным соединениям и их документированию, а также к версиям программных компонентов,

работающих на коммутаторе. Это также требует создания резервной копии; убедитесь, что все

нужные бинарные файлы ПО включены в резервную копию. Например, коммутаторы Cisco MDS

требуют как файл kickstart, так и файл основного образа ПО (main software image file).

25

8.2 Стандартизируйте конфигурации Во многих SAN некоторые коммутаторы иногда слегка отличаются по настройке между собой,

потому стоит задаться следующими вопросами:

Почему конфигурация на core-коммутаторе фабрики A отличается от конфигурации core-

коммутатора фабрики B?

Почему конфигурации двух edge-коммутаторов данной фабрики совершенно разные?

Должен ли на самом деле один edge-коммутатор использовать SNMP-агент версии 2c, а

другой – версии 3?

Должен ли аплинк одного edge-коммутатора быть включен в порт 1, а аплинк на другом –

в порт 24?

Примите за общее правило, что конфигурации должны быть максимально идентичны для

коммутаторов, выполняющих одинаковые функции в SAN, за исключением полей комментариев,

описаний, или параметров фабрики, таких как domain ID.

Например, у вас должны быть две базовые конфигурации для SAN топологии core-edge: одна для

core-коммутатора, и одна для edge-коммутатора. Конфигурации на каждом из свитчей

соответствующего уровня в SAN должны быть идентичны и соответствовать одной из базовых

конфигураций (за исключением имени коммутатора, описания интерфейсов и значения domain

ID).

Стандартизация ваших конфигураций позволит вам сэкономить время, и сфокусироваться на

более важных, стратегических задачах. Потратив больше время на вопросы стратегического плана,

вы сэкономите деньги и время на обслуживание вашей SAN.

NetApp рекомендует вам делать конфигурацию ваших коммутаторов SAN похожей на

конфигурации ваших коммутаторов Ethernet. Разумеется, Ethernet и FC это два различных

протокола, но на фундаментальном уровне они весьма близки; они оба коммутируют пакеты

между портами, используя определенную логику. Правила именования и другие

нефункциональные особенности конфигураций, такие, как версии агентов SNMP, конфигурации

syslog, а также конфигурация AAA - Authentication, Authorization, and Accounting, может быть

весьма сходной. Чем ближе будут эти конфигурации, тем проще будет сетевым администраторам

и администраторам SAN работать совместно.

8.3 Создайте руководство по восстановлению «с нуля» NetApp настоятельно рекомендует вам создать операционные процедуры для формализации

работ, позволяющих восстановить или создать заново конфигурацию коммутаторов.

Это снижает затраты времени на то, чтобы восстановить работу коммутатора в случае аппаратного

сбоя. Хотя отказ в одном из коммутаторов в топологии dual-fabric не влияет на доступность

сервисов хранения, пока отказавший коммутатор не восстановит работоспособность, ваша

система находится в состоянии повышенного риска, так как становится чувствительна в любому

другому сбою в SAN.

Если вы задокументируете процедуры восстановления коммутатора, их сможет выполнить любой

член IT-команды администраторов. Это приведет к сокращению времени, когда работе SAN может

угрожать риск другой ошибки.

26

В том случае, если вы не храните коммутатор «горячей» или «холодной» замены непосредственно

на территории датацентра, эта процедура должна включать в себя описания и инструкции по

процессу return merchandise authorization (RMA), то есть возврата отказавшего коммутатора

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

пользователе (адреса доставки, контактные телефоны и e-mail) поддерживается в записях

сервисных служб вендора в актуальном состоянии, и что вся необходимая для проведения RMA

информация доступна. Когда вы будете писать эти процедуры, заранее свяжитесь с сервисной

службой вендора и убедитесь, что вся эта информация имеется у него в наличии.

8.4 Проводите аудит конфигураций Без возможности получить доступ к каждому серверу, администратор SAN обычно предполагает,

что конфигурация, в особенности настройка зонирования, настроена правильно, пока не будет

продемонстрировано обратное. Поэтому они учатся дважды и трижды проверять эти

конфигурации перед тем, как они будут применены на сеть. Тем не менее, во многих случаях,

проблемы с конфигурацией SAN часто обнаруживаются уже только в случае сбоя.

Компании небольшого размера обычно не сталкиваются с этой проблемой. Если общее число

хостов в датацентре невелико, администратор SAN, который часто одновременно и серверный

администратор, может проверить каждый хост после любых изменений в настройках

зонирования. Однако это практически невозможно в случае большой компании.

Программный продукт NetApp OnCommand Insight с лицензией Assure анализирует конфигурации

зонирования, собираемые из коммутаторов SAN и настройки LUN masking контроллеров

хранения, и идентифицирует потенциальные проблемы настроек. Он может применять

определенные пользователем политики к конфигурации SAN, проверять, например, что не

участвующие в продакшне сервера видят минимум два, а продакшн-сервера – четыре пути к

контроллерам системы хранения, а также упреждающе сигнализировать администратору, когда

эти политики нарушаются.

8.5 Создайте диаграмму сети Администраторы SAN должны продумать возможность составить и поддерживать актуальность

диаграммы сети. Как уже говорилось ранее, всегда предпочтительнее использовать простую

топологию, и если следовать такому правилу, то вполне возможно, что администратору SAN и не

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

наличие диаграммы сети будет особенно полезным:

В больших сетевых топологиях, особенно топологиях типа partial mesh, которые трудно

концептуализировать, так как не все ISL имеют идентичные характеристики. Большое

число коммутаторов в обширных, многодоменных сетях может также создавать проблемы

идентификации и поиска нужных устройств.

В организациях, где операционный персонал многочисленен. Это может быть также

случай, когда администрирование SAN отдано на аутсорс сторонней компании. Диаграмма

сети (даже простая схема топологии) часто поможет вновь подключающимся сотрудникам

таких служб быстро войти в курс дела и целиком увидеть сетевую конфигурацию.

27

9 Безопасность Вопрос безопасности это то, что заставляет спорить многих администраторов SAN, и смущает

прочих. Большие затраты времени и денег на реализацию механизмов безопасности часто не

дают никакого видимого результата и преимуществ.

Этот раздел описывает некоторые общие наилучшие практики, которые могут быть применены к

почти любой системе. Некоторым системам, однако, могут потребоваться дополнительные меры

по обеспечению безопасности. Занимайтесь этими мерами, однако, только при наличии

конкретных причин, иначе вы рискуете получить затраты, превышающие полученную ценность

результата.

Вам следует принимать меры по обеспечению безопасности в вашей SAN, нацеленные на

выполнение конкретных требований безопасности. Требования, в свою очередь, нацелены на

решение проблем, связанных с определенными рисками. Проработайте самостоятельно, внутри

компании, или с привлечением внешних консультантов то, какие риски безопасности имеются для

вашей компании, и какие меры следует предпринять для устранения этих рисков. Вы можете

также проанализировать риски, проведя семинар с участием IT-администраторов компании.

Важно представить неприукрашенные результаты такого семинара на рассмотрение руководства.

Даже если ваши менеджеры не являются технически подготовленными, они те, кто отвечает за

риски и затраты. Руководство должно принять решение, какие риски следует признать

приемлемыми, а какие нет, и требуют устранения.

Требования к безопасности приложения, размещающегося на вашей инфраструктуре, могут

диктовать вам требования к безопасности и для самой инфраструктуры. В этом случае от вас

может потребоваться разработать и развернуть вашу SAN в соответствии с известными

промышленными стандартами безопасности.

Трафик FC иногда проходит по IP-сетям, в этом случае применяется протокол Fibre Channel Internet

Protocol (FCIP), обычно используемый для обеспечения межсайтных соединений. Если IP сети

включают в себя сегменты, которые не находятся под полным административным контролем

вашей организации, коммутаторы FC, находящиеся по обе стороны туннеля FCIP, должны, по

крайней мере, аутентифицировать друг друга.

Если это позволяют имеющиеся лицензии, используйте выделенные таблицы роутинга (dedicated

routing table instance) и тегированные virtual LAN (VLAN) для трафика FCIP по сети IP. Это позволит

сохранить конфигурацию предельно простой и обеспечит отсутствие утечки трафика за пределы

заданной сети.

Как и для всего дизайна FC, минимизация задержек (latency) является наиболее важным

аспектом. Используйте минимально возможное число коммутаторов IP между вашими SAN, и

убедитесь в том, что все эти коммутаторы достаточно высокого класса и имеют достаточную

производительность.

Контролируйте доступ к консольному порту ваших коммутаторов SAN. Убедитесь, что доступ к

консольному порту аутентифицируется и, если часть оборудования находится на удаленном

датацентре, убедитесь, что шкафы с оборудованием надежно запираются.

Как уже писалось ранее, в системе следует использовать ролевое управление доступом (RBAC) и

аудит команд (CLI auditing), но также следует рассмотреть возможность использовать

28

конфигурацию с сервером AAA. Использование централизованной базы пользователей для их

аутентификации позволит отказаться от необходимости вести локальные административные

аккаунты на оборудовании. Администрирование пользовательских аккаунтов тратит ценное

время, которое следует с большей пользой потратить на задачи администрирования

инфраструктуры, а не на изменения учетных записей. Централизация пользовательской

аутентификации с использованием, например, службы Active Directory®, означает, что управление

пользовательскими аккаунтами становится областью ответственности команды HR, а не

операторов SAN.

Большинство компаний конфигурируют две базовые роли на коммутаторах SAN: роль с правами

read-write для полных административных привилегий, и роль read-only для прочих нужд.

Дополнительные роли обычно могут потребоваться только для больших SAN. В этом случае ясно

определите цели и задачи каждой такой группы пользователей и убедитесь, что ролевая

конфигурация SAN соответствует этим задачам. Чрезмерно рьяная конфигурация авторизации

затруднит работу ваших администраторов SAN; например, может так получиться, что одна

команда данному пользователю может быть позволена, а другая, в то же время – нет.

Администраторы инфраструктуры в вашей организации либо входят в «доверенный круг», либо

нет. Если вы доверили им административные привилегии, и они ими злоупотребляют, аудит

команд (CLI auditing) позволит вам «держать их в узде».

Рассмотрите возможность централизованной авторизации на выделенном сервере AAA. Это

упростит конфигурирование коммутаторов.

Как и в случае традиционных сетей и устройств, все ненужные сервисы и процессы в SAN OS

коммутаторов должны быть остановлены и запрещены. Следует запретить Telnet и использовать

вместо него SSH. Использование протокола HTTP на коммутаторах следует запретить, и

использовать вместо него HTTPS.

10 Ссылки и справочные материалы Fibre Channel and iSCSI Configuration Guide for the Data ONTAP 8.0 Release Family

http://netappsky.com/wp-content/uploads/2010/12/fc_iscsi_config_guide_80.pdf

Interoperability Matrix Tool

http://now.netapp.com/matrix/mtx/login.do

Principles of SAN Design, Second Edition; Judd, Josh; 2007; Infinity Publishing

Storage Area Network Fundamentals; Gupta, Meeta; 2002; Cisco Press