Тенденции развития современных инфраструктурных решений. Системы хранения данных компании Intel

И прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.

Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.

Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB , в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).

Используя SAN, мы сочетаем преимущества DAS — скорость и простоту, и NAS — гибкость и управляемость. Плюс получаем возможность масштабирования систем хранения до тех пор, пока хватает денег, параллельно убивая одним выстрелом еще несколько зайцев, которых сразу не видно:

* снимаем ограничения на дальность подключения SCSI -устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, это нам дает следующих двух зайцев:
- на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
- можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.

Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:

* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования — благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию — когда нам нужно — всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации — естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare — полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.

Из чего это состоит?
Как я писал выше — СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:

Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 — по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, по 2 администратора. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре — «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции — иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.

Среда передачи данных .

Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей — одномодовые и многомодовые , одномодовые более дальнобойные.
Внутри используется FCP — Fibre Channel Protocol , транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI , но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.

Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант — точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а сферический конь в вакууме простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» — передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.

Ну и заключительный вариант — коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения — все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология , в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия — VLAN . Каждому устройству в сети присваивается аналог MAC -адреса в сети Ethernet, он называется WWN — World Wide Name . Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.

Сервера подключают к СХД через HBA - Host Bus Adapter -ы. По аналогии с сетевыми картами существуют одно-, двух-, четырехпортовые адаптеры. Лучшие "собаководы" рекомендуют ставить по 2 адаптера на сервер, это позволяет как осуществлять балансировку нагрузки, так и обеспечивает надежность.

А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо — тот и так знает или прочитает, кому не надо — только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.

Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта — дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную — файловые ресурсы и все остальное.

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

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

Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.

Поддержка обычно сводится к замене умерших дисков и контроллеров, ну и к добавлению в систему полок с дисками и новых серверов. Много хлопот бывает после внезапной профилактики системы силами местных специалистов, особенно после полного останова и разборки-сборки системы (и такое бывает).

Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.

Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) — требуют подключенного ко всем системам хранилища.

Пока писал статью — у меня спросили — в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.

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

SAN Коммутаторы (SAN switches)

SAN коммутаторы используются в качестве центрального коммутирующего устройства для узлов сети SAN. Вы вставляете один конец оптического кабеля в разъем на адаптере вашего сервера или контроллере дискового массива, а другой в порт на коммутаторе. Коммутатор можно сравнить с набором проводов, которые скроссированы таким образом, чтобы позволить каждому устройству сети «говорить» по одному проводу с любым другим устройством сети одновременно. Т.е, иными словами все абоненты могут разговаривать одновременно.
Один или несколько коммутаторов, соединенных между собой образуют фабрику. Одна фабрика может состоять из одного или нескольких коммутаторов (до 239 в настоящее время). Поэтому, фабрику можно определить как сеть, состоящую из соединенных между собой коммутаторов. SAN может состоять из нескольких фабрик. Большинство SAN состоит по крайне мере из двух фабрик, одна из которых является резервной.
Вы можете подключить серверы и хранилища к SAN используя один коммутатор, но правилом хорошего тона является использование двух коммутаторов, дабы избежать потерю данных и простои при выходе из строя одного из них. На рисунке 1 показана обычная фабрика, использующая два коммутатора для соединения серверов с дисковым массивом.

Рис 1. Простейшая фабрика с использованием 2-х коммутаторов.

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

Рис 2. Расширение SAN Fabric

Модульные или обычные коммутаторы (modular switches)

SAN коммутаторы бывают на любой вкус от 8 до сотен портов. Большинство модульных коммутаторов поставляется с 8 или 16 портами. Последним веянием является возможность наращивать количество портов на приобретенном коммутаторе с инкрементом 4. Типичным примером такого коммутатора может служить Qlogic SANbox 5200 (рис. 3). Этот продукт вы можете приобрести с 8-ю портами в базе, и наращивать затем до 16 в одном модуле и до 64 портов (!) в четырех модулях, соединяемых между собой 10 гигабитным FC.

Рис 3. Qlogic SANbox 5200 - четырехмодульный стек с 64 портами

Директоры или коммутаторы класса предприятия (director switches)

Директоры на много дороже модульных коммутаторов и обычно содержат сотни портов (рис. 4). Директоры можно увидеть в центре очень больших коммутированных фабрик в качестве ядра сети. Директоры обладают исключительной отказоустойчивостью и поддерживают работоспособность всей инфраструктуры 24 часа в сутки, 7 дней в неделю. Они позволяют осуществлять регламентные работы и замену модулей «на лету».

Рис. 4. SilkWorm 1200 128 port и McData InterPid 6140

Директор состоит из платформы, модулей портов горячей замены (обычно 12 или 16 портов) и процессорных модулей горячей замены (обычно двухпроцессорных). Директор можно приобрести с 32 портами и наращивать его до 128 – 140 портов.
В корпоративных сетях SAN обычно используют директоры в качестве ядра сети. К ним подключают модульные коммутаторы в качестве оконечных (граничных) коммутаторов. К тем, в свою очередь подключают серверы и хранилища. Такая топология называется ядро-граница (core-to-edge topology) и позволяет масштабировать сеть до тысяч портов (рис. 5).

Рис. 5. Топология ядро-граница с использованием директоров.

SAN маршрутизаторы или мультипротокльные коммутаторы (multiprotocol switches)

SAN маршрутизаторы служат для соединения удаленных островков SAN в единую сеть для решения задач защиты от катастроф, консолидации ресурсов хранения, организации процедур back-up данных удаленных подразделений на ленточные и дисковые ресурсы головного центра данных и т.д (рис 6.). Объединение удаленных сетей SAN в единый ресурс это следующий шаг в эволюции сетей хранения данных после внедрения SAN в головной структуре и подразделениях предприятий (рис. 7).

Рис. 6: McDATA Eclipse 1620, 3300 и 4300

Рис. 7: Объединение удаленных сетей SAN в единый ресурс

Островки SAN можно соединить, используя протокол FC и обычные модульные коммутаторы или директоры, через одномодовый оптический кабель (single mode cable или dark fiber) или же используя оборудование мультиплексирования (DWDM). Однако такой метод не позволит вам выйти за рамки города (радиус 70 км.). Для большего удаления понадобится протокол Fiber Channel over IP (FCIP, http://www.iscsistorage.com/ipstorage.htm), реализованный в маршрутизаторах Eclipse компании McData (рис. 6). FCIP «заворачивает» каждый кадр FC в пакет IP для транспорта через сеть IP. Принимающая сторона распаковывает пакет IP и достает оттуда оригинальный кадр FC для дальнейшей передачи уже по локальной сети FC. Здесь расстояния не ограничены. Все дело лишь в скорости вашего канала IP.

Типы FC кабелей

В качестве физической среды передачи данных в сетях FC используют оптоволоконный или медный кабель. Медный кабель представляет собой витую пару в оболочке и использовался в основном для местных подключений в сетях FC 1Gbit/s. В современных сетях FC 2Gbit/s в основном используется оптоволоконный кабель.
Существует два вида оптоволоконного кабеля: одномодовый и многомодовый.

Одномодовый кабель (long wave)

В одномодовом кабеле (SM) существует единственный путь распространения световой волны. Размер сердцевины (core size) обычно составляет 8.3 мк. Одномодовые кабели используются в устройствах, в которых требуется низкий уровень исчезновения (потери) сигнала и высокая скорость передачи данных, например на больших интервалах между двумя системами или сетевыми устройствами. Например, между сервером и хранилищем, расстояние между которыми, несколько десятков километров.

Максимальное расстояние между двумя узлами сети FC 2Gbit, соединенных одномодовым кабелем 80км без повторителей.

Многомодовый кабель (short wave)

Многомодовый кабель (MM) способен передавать по одному волокну несколько световых волн, так как относительно большой размер сердцевины позволяет свету распространяться под различными углами (рефракция). Типичными размерами сердцевины для MM являются 50 мк и 62.5 мк. Многомодовые волоконные соединения лучше всего подходят для устройств, работающих на небольших расстояниях. Внутри офиса, здания.

Максимальное расстояние на которое многомодовый кабель поддерживает скорость 2 Gbit/s – 300 (50um) и 150м (62,5 um).

Типы разъемов FC кабелей (Cable connector types)

Разъемы FC кабелей бывают:

Типы трансиверов (GBIC types)

Устройства для преобразования света в электрический сигнал и наоборот, называют трансиверами. Их еще называют GBIC (Gigabit Interface Connectors). Трансивер находится на плате FC адаптера (FC HBA), обычно он впаян в нее, в свитче - в виде съемного модуля (см. рис.) и на устройстве хранения в том или ином виде.

Трансиверы бывают:

SFP-LC	HSSDC2

Cъемные модули трансиверов (SFP)

HSSDC2 : для 1/2Gbit FC для медного кабеля
SFP-LC : (Small Form Factor Pluggable LC) 1/2Gbit FC Short/Long wave для оптоволоконного кабеля с LC коннектором
SFP-SC : (Small Form Factor Pluggable SC) 1/2Gbit FC Short/Long wave для оптоволоконного кабеля с SC коннектором

В простейшем случае SAN состоит из СХД , коммутаторов и серверов, объединённых оптическими каналами связи. Помимо непосредственно дисковых СХД в SAN можно подключить дисковые библиотеки, ленточные библиотеки (стримеры), устройства для хранения данных на оптических дисках (CD/DVD и прочие) и др.

Пример высоконадёжной инфраструктуры, в которой серверы включены одновременно в локальную сеть (слева) и в сеть хранения данных (справа). Такая схема обеспечивает доступ к данным, находящимся на СХД, при выходе из строя любого процессорного модуля, коммутатора или пути доступа.

Использование SAN позволяет обеспечить:

• централизованное управление ресурсами серверов и систем хранения данных ;
• подключение новых дисковых массивов и серверов без остановки работы всей системы хранения;
• использование ранее приобретенного оборудования совместно с новыми устройствами хранения данных;
• оперативный и надежный доступ к накопителям данных, находящимся на большом расстоянии от серверов, *без значительных потерь производительности;
• ускорение процесса резервного копирования и восстановления данных - BURA .

История

Развитие сетевых технологий привело к появлению двух сетевых решений для СХД – сетей хранения Storage Area Network (SAN) для обмена данными на уровне блоков, поддерживаемых клиентскими файловыми системами, и серверов для хранения данных на файловом уровне Network Attached Storage (NAS). Чтобы отличать традиционные СХД от сетевых был предложен еще один ретроним – Direct Attached Storage (DAS).

Появлявшиеся на рынке последовательно DAS, SAN и NAS отражают эволюционирующие цепочки связей между приложениями, использующими данные, и байтами на носителе, содержащим эти данные. Когда-то сами программы-приложения читали и писали блоки, затем появились драйверы как часть операционной системы. В современных DAS, SAN и NAS цепочка состоит из трех звеньев: первое звено – создание RAID-массивов, второе – обработка метаданных, позволяющих интерпретировать двоичные данные в виде файлов и записей, и третье – сервисы по предоставлению данных приложению. Они различаются по тому, где и как реализованы эти звенья. В случае с DAS СХД является «голой», она только лишь предоставляет возможность хранения и доступа к данным, а все остальное делается на стороне сервера, начиная с интерфейсов и драйвера. С появлением SAN обеспечение RAID переносится на сторону СХД, все остальное остается так же, как в случае с DAS. А NAS отличается тем, что в СХД переносятся к тому же и метаданные для обеспечения файлового доступа, здесь клиенту остается только лишь поддерживать сервисы данных.

Появление SAN стало возможным после того, как в 1988 году был разработан протокол Fibre Channel (FC) и в 1994 утвержден ANSI как стандарт. Термин Storage Area Network датируется 1999 годом. Со временем FC уступил место Ethernet, и получили распространение сети IP-SAN с подключением по iSCSI.

Идея сетевого сервера хранения NAS принадлежит Брайану Рэнделлу из Университета Ньюкэстла и реализована в машинах на UNIX-сервере в 1983 году. Эта идея оказалась настолько удачной, что была подхвачена множеством компаний, в том числе Novell, IBM , и Sun, но в конечном итоге сменили лидеров NetApp и EMC.

В 1995 Гарт Гибсон развил принципы NAS и создал объектные СХД (Object Storage, OBS). Он начал с того, что разделил все дисковые операции на две группы, в одну вошли выполняемые более часто, такие как чтение и запись, в другую более редкие, такие как операции с именами. Затем он предложил в дополнение к блокам и файлам еще один контейнер, он назвал его объектом.

OBS отличается новым типом интерфейса, его называют объектным. Клиентские сервисы данных взаимодействуют с метаданными по объектному API (Object API). В OBS хранятся не только данные, но еще и поддерживается RAID, хранятся метаданные, относящиеся к объектам и поддерживается объектный интерфейс. DAS, и SAN, и NAS, и OBS сосуществуют во времени, но каждый из типов доступа в большей мере соответствует определенному типу данных и приложений.

Архитектура SAN

Топология сети

SAN является высокоскоростной сетью передачи данных, предназначенной для подключения серверов к устройствам хранения данных. Разнообразные топологии SAN (точка-точка, петля с арбитражной логикой (Arbitrated Loop) и коммутация) замещают традиционные шинные соединения «сервер - устройства хранения» и предоставляют по сравнению с ними большую гибкость, производительность и надежность. В основе концепции SAN лежит возможность соединения любого из серверов с любым устройством хранения данных, работающим по протоколу Fibre Channel . Принцип взаимодействия узлов в SAN c топологиями точка-точка или коммутацией показан на рисунках. В SAN с топологией Arbitrated Loop передача данных осуществляется последовательно от узла к узлу. Для того, чтобы начать передачу данных передающее устройство инициализирует арбитраж за право использования среды передачи данных (отсюда и название топологии – Arbitrated Loop).

Транспортную основу SAN составляет протокол Fibre Channel, использующий как медные, так и волоконно-оптические соединения устройств.

Компоненты SAN

Компоненты SAN подразделяются на следующие:

• Ресурсы хранения данных;
• Устройства, реализующие инфраструктуру SAN;

Host Bus Adaptors

Ресурсы хранения данных

К ресурсам хранения данных относятся дисковые массивы , ленточные накопители и библиотеки с интерфейсом Fibre Channel . Многие свои возможности ресурсы хранения реализуют только будучи включенными в SAN. Так дисковые массивы высшего класса могут осуществлять репликацию данных между масcивами по сетям Fibre Channel, а ленточные библиотеки могут реализовывать перенос данных на ленту прямо с дисковых массивов с интерфейсом Fibre Channel, минуя сеть и серверы (Serverless backup). Наибольшую популярность на рынке приобрели дисковые массивы компаний EMC , Hitachi , IBM , Compaq (семейство Storage Works , доставшееся Compaq от Digital), а из производителей ленточных библиотек следует упомянуть StorageTek , Quantum/ATL , IBM .

Устройства, реализующие инфраструктуру SAN

Устройствами, реализующими инфраструктуру SAN, являются коммутаторы Fibre Channel (Fibre Channel switches , FC switches),концентраторы (Fibre Channel Hub) и маршрутизаторы (Fibre Channel-SCSI routers).Концентраторы используются для объединения устройств, работающих в режиме Fibre Channel Arbitrated Loop (FC_AL). Применение концентраторов позволяет подключать и отключать устройства в петле без остановки системы, поскольку концентратор автоматически замыкает петлю в случае отключения устройства и автоматически размыкает петлю, если к нему было подключено новое устройство. Каждое изменение петли сопровождается сложным процессом её инициализации . Процесс инициализации многоступенчатый, и до его окончания обмен данными в петле невозможен.

Все современные SAN построены на коммутаторах, позволяющих реализовать полноценное сетевое соединение. Коммутаторы могут не только соединять устройства Fibre Channel , но и разграничивать доступ между устройствами, для чего на коммутаторах создаются так называемые зоны. Устройства, помещенные в разные зоны, не могут обмениваться информацией друг с другом. Количество портов в SAN можно увеличивать, соединяя коммутаторы друг с другом. Группа связанных коммутаторов носит название Fibre Channel Fabric или просто Fabric. Связи между коммутаторами называют Interswitch Links или сокращенно ISL.

Программное обеспечение

Программное обеспечение позволяет реализовать резервирование путей доступа серверов к дисковым массивам и динамическое распределение нагрузки между путями. Для большинства дисковых массивов существует простой способ определить, что порты, доступные через разные контроллеры , относятся к одному диску. Специализированное программное обеспечение поддерживает таблицу путей доступа к устройствам и обеспечивает отключение путей в случае аварии, динамическое подключение новых путей и распределение нагрузки между ними. Как правило, изготовители дисковых массивов предлагают специализированное программное обеспечение такого типа для своих массивов. Компания VERITAS Software производит программное обеспечение VERITAS Volume Manager , предназначенное для организации логических дисковых томов из физических дисков и обеспечивающее резервирование путей доступа к дискам, а также распределение нагрузки между ними для большинства известных дисковых массивов.

Используемые протоколы

В сетях хранения данных используются низкоуровневые протоколы:

• Fibre Channel Protocol (FCP), транспорт SCSI через Fibre Channel. Наиболее часто используемый на данный момент протокол . Существует в вариантах 1 Gbit/s, 2 Gbit/s, 4 Gbit/s, 8 Gbit/s и 10 Gbit/s.
• iSCSI , транспорт SCSI через TCP/IP .
• FCoE , транспортировка FCP/SCSI поверх "чистого" Ethernet.
• FCIP и iFCP , инкапсуляция и передача FCP/SCSI в пакетах IP.
• HyperSCSI , транспорт SCSI через Ethernet .
• FICON транспорт через Fibre Channel (используется только мейнфреймами).
• ATA over Ethernet , транспорт ATA через Ethernet.
• SCSI и/или TCP/IP транспорт через InfiniBand (IB).

Преимущества

• Высокая надёжность доступа к данным, находящимся на внешних системах хранения. Независимость топологии SAN от используемых СХД и серверов.
• Централизованное хранение данных (надёжность, безопасность).
• Удобное централизованное управление коммутацией и данными.
• Перенос интенсивного трафика ввода-вывода в отдельную сеть – разгрузка LAN.
• Высокое быстродействие и низкая латентность.
• Масштабируемость и гибкость логической структуры SAN
• Географические размеры SAN, в отличие от классических DAS, практически не ограничены.
• Возможность оперативно распределять ресурсы между серверами.
• Возможность строить отказоустойчивые кластерные решения без дополнительных затрат на базе имеющейся SAN.
• Простая схема резервного копирования – все данные находятся в одном месте.
• Наличие дополнительных возможностей и сервисов (снапшоты, удаленная репликация).
• Высокая степень безопасности SAN.

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

Другим приемуществом является возможность загружать сервера прямо из сети хранения. При такой конфигурации можно быстро и легко заменить сбойный

Что это?
Сеть хранения данных , или Storage Area Network - это система, состоящая из собственно устройств хранения данных - дисковых, или RAID - массивов, ленточных библиотек и прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД - это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.

Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой - DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера - и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива - достаточную надежность, хотя копья на тему надежности уже давно.
Однако такое использование дискового пространства не оптимально - на одном сервере место кончается, на другом его еще много. Решение этой проблемы - NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения - гибкости и централизованного управления - есть один существенный недостаток - скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.

Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) - это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB , в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).

Используя SAN, мы сочетаем преимущества DAS - скорость и простоту, и NAS - гибкость и управляемость. Плюс получаем возможность масштабирования систем хранения до тех пор, пока хватает денег, параллельно убивая одним выстрелом еще несколько зайцев, которых сразу не видно:

* снимаем ограничения на дальность подключения SCSI -устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, то нам дает следующих двух зайцев:
o на полную используем возможности VMWare - например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
o можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.

Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:

* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев - можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования - благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию - когда нам нужно - всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации - естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare - полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.

Из чего это состоит?
Как я писал выше - СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:

Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 - по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, по 2 администратора. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре - «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции - иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.

Среда передачи данных . Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей - одномодовые и многомодовые , одномодовые более дальнобойные.
Внутри используется FCP - Fibre Channel Protocol , транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI , но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.

Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант - точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а сферический конь в вакууме простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» - передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.

Ну и заключительный вариант - коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения - все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология , в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия - VLAN . Каждому устройству в сети присваивается аналог MAC -адреса в сети Ethernet, он называется WWN - World Wide Name . Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.

Сервера подключают к СХД через HBA - Host Bus Adapter -ы. По аналогии с сетевыми картами существуют одно-, двух-, четырехпортовые адаптеры. Лучшие собаководы рекомендуют ставить по 2 адаптера на сервер, это позволяет как осуществлять балансировку нагрузки, так и обеспечивает надежность.

А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо - тот и так знает или прочитает, кому не надо - только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.

Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта - дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную - файловые ресурсы и все остальное.

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

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

Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.

Поддержка обычно сводится к замене умерших дисков и контроллеров, ну и к добавлению в систему полок с дисками и новых серверов. Много хлопот бывает после внезапной профилактики системы силами местных специалистов, особенно после полного останова и разборки-сборки системы (и такое бывает).

Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.

Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) - требуют подключенного ко всем системам хранилища.

Пока писал статью - у меня спросили - в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.

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

Прежде чем окунуться в технологии сетей хранения данных (SAN), стоит освежить свои знания, относящиеся к сетям передачи данных (СПД). SAN стали неким обособленным «ответвлением» от столбового пути развития сетевой индустрии. Однако, скажем, коммутаторы SAN играют в сетях хранения данных ту же роль, что и коммутаторы Ethernet или IP-маршрутизаторы в обычных СПД. Такие продукты выпускаются многочисленными, хотя по большей части не очень известными, производителями (табл. 1), и их функциональные возможности и технические характеристики сильно различаются. Как показали испытания, проведенные компанией Mier Communications, последние разработки четырех ведущих производителей коммутаторов SAN совершенно не похожи друг на друга.

«Голубую ленту» победителя мы присудили устройствам SilkWorm 2400 и 2800 фирмы Brocade Communications . Они полностью соответствуют технологии Plug-and-Play и обладают наивысшей производительностью среди протестированных моделей.

На второе место вышли SANbox 8 и SANbox 16 HA компании QLogic . Попытки установить их и заставить работать хотя и увенчались успехом, но отняли у нас гораздо больше сил, чем аналогичные процедуры с коммутаторами SilkWorm, да и быстродействие этих моделей оказалось весьма посредственным. Тем не менее мы по достоинству оценили удобство администрирования, которое обеспечивает приложение SANsurfer - безусловно, лучшее в своем классе. (В нынешнем году QLogic приобрела фирму Ancor, создавшую данные устройства, и коммутаторы поступили к нам от последней еще до урегулирования всех формальностей сделки. Впрочем, представители компании-покупателя заверили нас, что ее клиентам будут предлагаться продукты, идентичные «изначальным».)

Третью строчку заняли модели 7100 и 7200 фирмы Vixel , обладающие удобными средствами регистрации событий, но продемонстрировавшие крайне низкую производительность. Наконец, замыкало список устройство Capellix 2000G производства Gadgoox , главным недостатком которого является неспособность функционировать в коммутируемой сети SAN.

Три участника тестирования - QLogic, Vixel и Brocade - предоставили в наше распоряжение по два коммутатора на 8 и два - на 16 портов. Быстродействие устройств одного поставщика было практически одинаковым, что дало нам возможность привести на диаграммах, характеризующих производительность, общие для каждой пары значения. Таким же подходом мы воспользовались при выставлении оценок по критериям «Простота инсталляции», «Администрирование» и «Функциональные возможности».

Шина или матрица

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

Фирма Gadzoox предоставила устройство Capellix 2000G, которое сам производитель позиционирует как коммутатор для сетей с разделяемым доступом. Это означает, что другие варианты подключения узлов к сети не поддерживаются. Сеть с общей шиной - так на профессиональном жаргоне называют технологию Fibre Channel с арбитражем (Fibre Channel Arbitrated Loop, FCAL) - является довольно старой разновидностью сетевой архитектуры Fibre Channel, в которой сетевые узлы совместно используют полосу пропускания разделяемой среды передачи.

Между тем для объединения нескольких коммутаторов в SAN каждый из них должен поддерживать коммутируемые (или, в терминологии SAN, матричные ) соединения, по крайней мере для части своих портов. Если прибегнуть к аналогии из сферы передачи данных, то различие между шинной (loop) и матричной (fabric) архитектурами можно уподобить различию между двумя сетями Ethernet, в одной из которых установлен концентратор, а в другой - коммутатор. Как известно, до активного проникновения технологий коммутации в локальные сети Ethernet в них использовался разделяемый доступ к среде передачи, физическим воплощением которой был коаксиальный кабель или концентратор.

Отсутствие поддержки коммутируемых соединений и топологий с несколькими коммутаторами не могло не сказаться на баллах, которые получило оборудование Gadzoox по критериям «Конфигурация» и «Функциональные возможности». Располагая только одним коммутатором, пользователи не смогут построить сеть, отличающуюся высокой надежностью и способностью маршрутизировать данные в обход отказавших узлов или соединений. Сеть хранения данных, в которой инсталлирован Capellix 2000G, будет насчитывать не более 11 коммутационных портов (в стандартной конфигурации это устройство имеет восемь портов и разъем расширения, допускающий установку трехпортового модуля). По сообщению представителей Gadzoox, в настоящее время фирма занимается разработкой модуля для коммутирующей матрицы, который будет устанавливаться в модульный коммутатор Capellix 3000.

Общие черты

Несмотря на многочисленные различия коммутаторы SAN имеют и много общего. В частности, во всех моделях присутствуют модули преобразователей гигабитных интерфейсов (Gigabit Interface Converter, GBIC) для каждого из портов. Это позволяет легко заменить физический коннектор на отдельном порте. Так, в процессе тестирования сетевых конфигураций на оптических и кабельных линиях нам частенько приходилось переключаться с кабельных портов, оснащенных разъемами DB-9, на оптические порты, работающие в коротковолновом диапазоне. Фирмы-производители предлагают для своих изделий коннекторы обоих типов, а также несколько других разновидностей модулей GBIC - например, предназначенные для работы на длинных волнах с одномодовым волокном. Мы попробовали переставить модули преобразователей с одной модели на устройства других фирм: никаких проблем ни с совместимостью, ни с производительностью при этом не возникло. Судя по всему, на уровне модулей GBIC и портов, на которых они используются, можно говорить о стопроцентном выполнении принципа Plug-and-Play.

Все коммутаторы поддерживают скорость передачи данных 1 Гбит/с на всех портах, хотя уже сегодня существуют спецификации, предусматривающие 2-Гбит/с скорость передачи по каналам Fibre Channel; по некоторым данным, ведутся работы над увеличением последнего значения еще вдвое.

Каждый коммутатор снабжен портом Ethernet, предназначенным для доступа к устройству с управляющей станции и способным автоматически определять используемую скорость передачи (10 или 100 Мбит/с). Изделия компаний Brocade, Vixel и Gadzoox располагают портом для подключения консоли; именно через него коммутатору сообщается IP-адрес, который впоследствии служит для управления. Что же касается продукта фирмы QLogic, его IP-адрес задается заранее (т.е. фиксирован), и это, на наш взгляд, может иметь негативные последствия. При подключении устройства к сети пользователь будет вынужден отслеживать предопределенный IP-адрес, а в дальнейшем его все равно придется заменить на значение, более подходящее для конкретной сети.

Все устройства в равной степени поддерживают зонирование сети хранения данных. «На языке» SAN этот термин соответствует организации виртуальных ЛС в СПД, т.е. обозначает логическое группирование отдельных портов и подключенных к коммутатору узлов с одновременным их отделением от других ресурсов. В сетях SAN зонирование используется преимущественно для контроля трафика.

Наконец, все модели поддерживают одни и те же классы сервиса Fibre Channel - второй и третий. Услуги третьего класса, которые соответствуют сервису без подтверждения приема и не ориентированы на установление соединений, сегодня обеспечивают транспортировку по сетям SAN практически всего объема трафика. Услуги второго класса отличаются от предыдущих наличием подтверждений; широкого распространения они пока не получили. Выявленные во время испытаний достоинства и недостатки коммутаторов SAN, которые мы рассмотрим ниже, отображены в табл. 2 .

Сравниваем конфигурации

Самый высокий балл по этому критерию получили устройства SilkWorm компании Brocade, поскольку они поддерживают все интересовавшие нас опции - возможности работы в разных сетевых топологиях, использования преобразователей GBIC, подключения консоли к специальному порту и доступа по каналу Ethernet с автоматическим выбором скорости передачи. Кроме того, только фирма Brocade поставляет свои коммутаторы (как 8-, так и 16-портовый) с резервными источниками питания. Корпорация QLogic устанавливает дополнительный источник питания только в 16-портовой модели SANbox 16 HA, а Gadzoox и Vixel вообще не предусмотрели такой возможности.

Буферизация кадров, которая обеспечивает временное сохранение данных перед их дальнейшей транспортировкой, также привлекла наше внимание. Она позволяет предотвратить потерю или отбрасывание пакетов при возникновении незапланированных событий или непредвиденном ухудшении условий передачи. Прежде всего нас интересовал объем буферного пространства на отдельных портах. Как оказалось, в коммутаторе производства Gadzoox буферизация кадров попросту невозможна. Устройства SANbox имеют по восемь буферов для каждого порта. В коммутаторах SilkWorm буферов уже по 16, а кроме того, существует общий динамический буфер, части которого выделяются отдельным портам по мере необходимости. Наконец, в устройствах 7200 корпорации Vixel каждый порт располагает 32 буферами.

По функциональным возможностям продукты различались не столь явно. Существенным моментом оказалась, пожалуй, лишь способность коммутаторов к взаимодействию с изделиями других фирм. Перед началом тестирования мы попросили производителей предоставить нам любую документацию, обычно предлагаемую заказчику и отражающую возможность функционирования данного продукта в той сетевой среде, где имеются коммутаторы SAN, системы хранения данных и шинные адаптеры (Host Bus Adapter, HBA; в терминологии SAN так называют сетевые карты Fibre Channel, которые устанавливаются на подключаемые к сети серверы) разных поставщиков. К сожалению, ни один из производителей не смог похвастать совместимостью своих коммутаторов с продуктами других фирм. Представители Brocade прямо заявили, что фирма не гарантирует такого взаимодействия, но ведет работы по обеспечению совместимости SilkWorm с конкретными моделями накопительных систем и сетевых карт. QLogic, Vixel и Gadzoox заняли более амбициозную позицию.

Включил и... работай?

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

Для тестирования всех моделей использовались одни и те же платы HBA производства QLogic. Трудно сказать, в какой мере такой выбор повлиял на полученные нами значения производительности и на возможность взаимодействия испытывавшихся устройств. Можно лишь отметить: работы по обеспечению совместимости различного оборудования SAN еще далеки от завершения, поэтому не исключено, что при установке других адаптеров или дисковых систем JBOD будут зафиксированы иные результаты.

Коммутаторы SilkWorm 2400 и 2800 компании Brocade полностью соответствуют принципу Plug-and-Play и поэтому получили наивысшие оценки. Вслед за ними идет модель Capellix: хотя фирма Gadzoox одним махом избавила себя от проблем, связанных с поддержкой многокоммутаторных сетевых сред, одно устройство заработало, что называется, с полоборота.

Модели 7100 и 7200 фирмы Vixel и, в меньшей степени, SANbox от QLogic доставили немало хлопот уже на стадии инсталляции. Происхождение возникших затруднений так и осталось неясным, причем не только для нас, но и, кажется, для сотрудников служб технической поддержки упомянутых компаний. На наш взгляд, причина кроется в плохой совместимости коммутаторов SAN, адаптеров и систем хранения данных.

Управление

Наилучшее впечатление оставила продукция компании QLogic. Написанное на Java управляющее приложение SANsurfer имеет высокоинтуитивный Web-интерфейс и работает вполне стабильно. Автоматически генерируемая карта топологии показывает соединения между отдельными коммутаторами в сети с детализацией до уровня отдельного порта. Уровни интенсивности трафика выводятся на экран в режиме реального времени, а кроме того, программа обеспечивает регистрацию событий в удобном для чтения формате.

Управляющее ПО Web Tools компании Brocade, также основанное на языке Java, показалось нам достаточно надежным и эффективным, однако ему недостает информативности и некоторых функций, присущих продукту QLogic. Web Tools не строит схемы сетевой топологии, а управляющий интерфейс не позволяет быстро определять типы физических портов коммутаторов. Функция генерации отчетов о параметрах трафика не вызвала особых нареканий, однако отсутствует система экранной помощи, которая в отдельных случаях просто необходима.

Несомненное достоинство административного пакета SAN InSite 2000 фирмы Vixel, тоже написанного на Java, - хорошие средства регистрации событий. Однако указанное ПО состоит из нескольких клиентских и серверных модулей, что затрудняет его использование. Мы работали с одной из поздних бета-версий SAN InSite 2000 3.0 и обнаружили в ней больше ошибок, чем можно было ожидать. Так, один из портов постоянно распознавался как порт для кабельной линии с разъемом DB-9, в то время как он являлся оптическим. Один раз выдача отчетов о параметрах трафика в режиме реального времени попросту прекратилась, и, несмотря на все усилия, нам не удалось исправить ситуацию. Продукт имеет массу полезных функций и превосходную систему экранной помощи, но его функционирование сопровождалось постоянными ошибками.

Java-приложение Ventana SANtools производства Gadzoox явно проигрывало другим управляющим программам по части графики и функциональных возможностей. Например, в нем отсутствуют средства мониторинга параметров трафика в режиме реального времени. Мы отметили определенные недостатки в организации интерфейса и средствах навигации. Gadzoox снабдила свое приложение экранной справочной системой, но, кажется, забыла о средствах поиска.

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

Первый из тестов на производительность, в котором регистрировалась задержка передачи данных, прошел на удивление гладко. Какое бы устройство мы не испытывали, суммарная задержка при транспортировке трафика по матрице из нескольких коммутаторов оказывалась в диапазоне от 10 до 15 мс. Задержка, вносимая коммутатором Capellix 2000G, была еще меньше; правда, стоит учесть, что в этом случае трафик проходил только через одно устройство.

А что происходит, когда коммутатор буквально бомбардируется потоками данных? Мы измеряли среднее время, которое необходимо семи серверам под Windows NT для выполнения случайных операций чтения/записи массивов данных объемом 10 Мбайт, причем обмен производился с одной и той же дисковой системой, подключенной через сеть коммутаторов SAN (см. ).

Среднее время одной операции ввода/вывода относится к ключевым показателям производительности, поскольку оно отражает реальное быстродействие сети SAN при передаче потоков большой интенсивности. Для SilkWorm, Capellix 2000G и 7100/7200 это время оказалось практически одинаковым (1,515, 1,512 и 1,536 мс соответственно). Коммутатору SANbox для транспортировки такого же объема данных потребовалось несколько больше - 2,177 мс.

Обратившись к пропускной способности, мы измерили ее максимальное значение для соединения Fibre Channel, по которому накопители были подключены к сети хранения данных. Мы вводили «в игру» от одного до семи серверов под Windows NT, заставляя их выполнять операции сначала чтения, затем записи, а потом смесь этих процедур и опять же общаясь с системой хранения данных через коммутационную матрицу SAN (при тестировании устройства Capellix 2000G фирмы Gadzoox сервер и дисковые накопители были подключены к одному и тому же коммутатору).

Пока операции записи выполнял один сервер, пропускная способность оставалась практически одной и той же для всех коммутаторов: они успевали обработать от 77,8 до 79,6 Мбайт/с. Очевидно, столь малым разбросом можно попросту пренебречь. Тот же результат наблюдался и для операций чтения: средняя пропускная способность составляла 81,6-85,1 Мбайт/с. Однако как только операции чтения начинали выполнять одновременно семь серверов, различия сразу же проявлялись. Коммутаторы Capellix 2000G и Vixel 7100 и 7200 работали со скоростями 95,3 и 94,3 Мбайт/с соответственно, что очень близко к максимальной пропускной способности линии Fibre Channel (100 Мбайт/с). Средняя производительность двух других устройств оказалась заметно ниже: у моделей SANbox она составила 88,9 Мбайт/с, а у SilkWorm - 73,9 Мбайт/с.

При выполнении серверами операций записи на диск, а также случайной последовательности операций чтения/записи наилучшие усредненные результаты показали коммутаторы SilkWorm. Второе место заняла модель Capellix 2000G, третье - устройства 7200 и 7100 от Vixel, а на последнем оказались коммутаторы SANbox. Надо отметить, что на практике пользователи постоянно сталкиваются с ситуацией одновременного выполнения множества операций чтения/записи.

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

Отключение и последующее подсоединение накопителей никак не повлияло на работу SilkWorm и Capellix 2000G, зато продукты Vixel не смогли адекватно отреагировать на изменения в сетевой топологии. Что же касается SANbox фирмы QLogic, иногда коммутирующая матрица корректно отрабатывала разрыв соединений, запускала процедуру повторной инициализации и налаживала новые маршруты, а иногда выдавала ошибки. Подчеркнем, что во время первого теста трафик в сети хранения данных отсутствовал.

Тест на обход отказавшего соединения при большой нагрузке c коммутатором Capellix 2000G провести не удалось, поскольку, как уже говорилось, этот продукт не способен работать в коммутируемой среде, состоящей из нескольких устройств. При обмене трафиком максимальной интенсивности между семью серверами под Windows NT и дисковой системой коммутатор SilkWorm каждый раз автоматически возобновлял передачу; период восстановления занимал от 8 до 12 с.

Устройства SANbox также продемонстрировали высокую надежность при обработке сбоев в условиях передачи больших объемов трафика. Более того, их архитектура позволяла автоматически перераспределять нагрузку между доступными маршрутами транспортировки по коммутирующей матрице, так что перерывы в передаче данных были практически незаметны.

Коммутаторы 7100 и 7200 фирмы Vixel уверенно возобновляли передачу лишь при небольших объемах трафика и участии в обмене только одного сервера. Как только мы раскручивали тест на полную катушку (подключая к сети все семь серверов), транспортировка данных прекращалась и уже не восстанавливалась.

Учитывая результаты всех тестов на производительность, победителем в данной категории следует признать коммутаторы SilkWorm 2400 и 2800 компании Brocade Communications. На втором месте оказалась модель Capellix 2000G.

Устройства от Brocade стали лидерами и всего комплекса испытаний продуктов данной категории, набрав 8,4 балла (табл. 3). Как показывает опыт компании Mier Communications, если итоговая оценка при использовании 10-балльной системы превышает 8, продукт можно смело рекомендовать потребителям. Коммутаторы SilkWorm - тот самый случай.

Эдвин Майер (Edwin Mier) - основатель и президент, а Кеннет Перси (Kennet Percy) - специалист по тестированию компании Mier Communications, специализирующейся на консалтинге и испытаниях сетевых продуктов. С ними можно связаться по адресам [email protected] и [email protected] .

Процедура тестирования

Базовые критерии

Максимальная пропускная способность