И прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую 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 столкнулся с определённым препятствием - труднодоступностью базовой информации. В вопросе изучения прочих инфраструктурных продуктов, с которыми доводилось сталкиваться, проще - есть пробные версии ПО, возможность установить их на вирутальной машине, есть куча учебников, референс гайдов и блогов по теме. Cisco и Microsoft клепают очень качественные учебники, MS вдобавок худо-бедно причесал свою адскую чердачную кладовку под названием technet, даже по VMware есть книга, пусть и одна (и даже на русском языке!), причём с КПД около 100%. Уже и по самим устройствам хранения данных можно получить информацию с семинаров, маркетинговых мероприятий и документов, форумов. По сети же хранения - тишина и мёртвые с косами стоять. Я нашёл два учебника, но купить не решился. Это "Storage Area Networks For Dummies " (есть и такое, оказывается. Очень любознательные англоговорящие «чайники» в целевой аудитории, видимо) за полторы тысячи рублей и "Distributed Storage Networks: Architecture, Protocols and Management " - выглядит более надёжно, но 8200р при скидке 40%. Вместе с этой книгой Ozon рекомендует также книгу «Искусство кирпичной кладки».

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

Попробую восполнить пробел, которого не хватало мне - описать базу и описать просто. Рассматривать буду SAN на базе её классического протокола - Fibre Channel.

Итак, SAN - Storage Area Network - предназначена для консолидации дискового пространства серверов на специально выделенных дисковых хранилищах. Суть в том, что так дисковые ресурсы экономнее используются, легче управляются и имеют большую производительность. А в вопросах виртуализации и кластеризации, когда нескольким серверам нужен доступ к одному дисковому пространству, подобные системы хранения данных вообще незаменимая штука.

Кстати, в терминологиях SAN, благодаря переводу на русский, возникает некоторая путаница. SAN в переводе означает «сеть хранения данных» - СХД. Однако классически в России под СХД понимается термин «система хранения данных», то есть именно дисковый массив (Storage Array ), который в свою очередь состоит из Управляющего блока (Storage Processor, Storage Controller ) и дисковых полок (Disk Enclosure ). Однако, в оригинале Storage Array является лишь частью SAN, хотя порой и самой значимой. В России получаем, что СХД (система хранения данных) является частью СХД (сети хранения данных). Поэтому устройства хранения обычно называют СХД, а сеть хранения - SAN (и путают с «Sun», но это уже мелочи).

Компоненты и термины

Технологически SAN состоит из следующих компонентов:

1. Узлы, ноды (nodes)

• Дисковые массивы (системы хранения данных) - хранилища (таргеты )
• Серверы - потребители дисковых ресурсов (инициаторы ).

2. Сетевая инфраструктура

• Коммутаторы (и маршрутизаторы в сложных и распределённых системах)
• Кабели

Особенности

Если не вдаваться в детали, протокол FC похож на протокол Ethernet с WWN-адресами вместо MAC-адресов. Только, вместо двух уровней Ethernet имеет пять (из которых четвёртый пока не определён, а пятый - это маппинг между транспортом FC и высокоуровневыми протоколами, которые по этому FC передаются - SCSI-3, IP). Кроме того, в коммутаторах FC используются специализированные сервисы, аналоги которых для IP сетей обычно размещаются на серверах. Например: Domain Address Manager (отвечает за назначение Domain ID коммутаторам), Name Server (хранит информацию о подключенных устройствах, эдакий аналог WINS в пределах коммутатора) и т.д.

Для SAN ключевыми параметрами являются не только производительность, но и надёжность. Ведь если у сервера БД пропадёт сеть на пару секунд (или даже минут) - ну неприятно будет, но пережить можно. А если на это же время отвалится жёсткий диск с базой или с ОС, эффект будет куда более серьёзным. Поэтому все компоненты SAN обычно дублируются - порты в устройствах хранения и серверах, коммутаторы, линки между коммутаторами и, ключевая особенность SAN, по сравнению с LAN - дублирование на уровне всей инфраструктуры сетевых устройств - фабрики.

Фабрика (fabric - что вообще-то в переводе с английского ткань, т.к. термин символизирует переплетённую схему подключения сетевых и конечных устройств, но термин уже устоялся) - совокупность коммутаторов, соединённых между собой межкоммутаторными линками (ISL - InterSwitch Link ).

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

Фабрики могут иметь идентичную (зеркальную) топологию или различаться. Например одна фабрика может состоять из четырёх коммутаторов, а другая - из одного, и к ней могут быть подключены только высококритичные узлы.

Топология

Различают следующие виды топологий фабрики:

Каскад - коммутаторы соединяются последовательно. Если их больше двух, то ненадёжно и непроизводительно.

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

Сетка (mesh ). Бывает Full Mesh - когда каждый коммутатор соединяется с каждым. Характерно высокой надёжностью, производительностью и ценой. Количество портов, требуемое под межкоммутаторные связи, с добавлением каждого нового коммутатора в схему растёт экспоненциально. При определённой конфигурации просто не останется портов под узлы - все будут заняты под ISL. Partial Mesh - любое хаотическое объединение коммутаторов.

Центр/периферия (Core/Edge) - близкая к классической топологии LAN, но без уровня распределения. Нередко хранилища подключаются к Core-коммутаторам, а серверы - к Edge. Хотя для хранилищ может быть выделен дополнительный слой (tier) Edge-коммутаторов. Также и хранилища и серверы могут быть подключены в один коммутатор для повышения производительности и снижения времени отклика (это называется локализацией). Такая топология характеризуется хорошей масштабируемостью и управляемостью.

Зонинг (зонирование, zoning)

Ещё одна характерная для SAN технология. Это определение пар инициатор-таргет. То есть каким серверам к каким дисковым ресурсам можно иметь доступ, дабы не получилось, что все серверы видят все возможные диски. Достигается это следующим образом:

• выбранные пары добавляются в предварительно созданные на коммутаторе зоны (zones);
• зоны помещаются в наборы зон (zone set, zone config), созданные там же;
• наборы зон активируются в фабрике.

Для первоначального поста по теме SAN, думаю, достаточно. Прошу прощения за разномастные картинки - самому нарисовать на работе пока нет возможности, а дома некогда. Была мысль нарисовать на бумаге и сфотографировать, но решил, что лучше так.

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

• Проектировать структуру так, чтобы между двумя конечными устройствами было не более трёх коммутаторов.
• Желательно чтобы фабрика состояла не более чем из 31 коммутатора.
• Стоит задавать Domain ID вручную перед вводом нового коммутатора в фабрику - улучшает управляемость и помогает избежать проблем одинаковых Domain ID, в случаях, например, переподключения коммутатора из одной фабрики в другую.
• Иметь несколько равноценных маршрутов между каждым устройством хранения и инициатором.
• В случаях неопределённых требований к производительности исходить из соотношения количества Nx-портов (для конечных устройств) к количеству ISL-портов как 6:1 (рекомендация EMC) или 7:1 (рекомендация Brocade). Данное соотношение называется переподпиской (oversubscription).
• Рекомендации по зонингу:
  - использовать информативные имена зон и зон-сетов;
  - использовать WWPN-зонинг, а не Port-based (основанный на адресах устройств, а не физических портов конкретного коммутатора);
  - каждая зона - один инициатор;
  - чистить фабрику от «мёртвых» зон.
• Иметь резерв свободных портов и кабелей.
• Иметь резерв оборудования (коммутаторы). На уровне сайта - обязательно, возможно на уровне фабрики.

7 июля 2010 в 15:12

SN6000 – коммутатор для развития сети хранения

• Блог компании Hewlett Packard Enterprise

Сегодня мы расскажем вам о новом стекируемом коммутаторе StorageWorks SN6000 c 20 восьмигигабитными портами Fibre Channel. Такое устройство предназначено прежде всего для построения сети хранения SAN в небольшой компании, где у ИТ-специалиста обычно нет опыта настройки оборудования Fibre Channel.

HP StorageWorks SN6000 стандартно поставляется с утилитой Simple SAN Connection Manager (SSCM), которая с помощью графических визардов помогает даже новичку в технологиях SAN правильно определить конфигурацию устройств SAN, включая сам коммутатор, HBA-адаптеры серверов и дисковый массив HP StorageWorks MSA или EVA (разумеется, если таковой имеется у заказчика).

Обычно для каждого из этих компонентов SAN используется отдельная утилиты настройки параметров Fibre Channel, а SSCM заменяет их одним универсальным инструментом. В результате существенно упрощается развертывание SAN и уменьшается риск ошибок конфигурации. SSCM автоматически распознает подключенные к сети хранения коммутаторы Fibre Channel, серверы и дисковые массивы HP StorageWorks. Также с помощью удобного графического интерфейса утилиты можно разбить сеть хранения на зоны и распределить между ними дисковые ресурсы.

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

Для снижения стоимости коммутатор SN6000 можно приобрести в начальной восьмипортовой конфигурации. HP также предлагает компаниям, которые хотят перейти к использованию внешнего дискового массива и построить свою первую SAN, готовый набор SAN Starter Kit. Набор состоит из нового массива HP StorageWorks P2000 G3 FC MSA () с двумя RAID-контроллерами, двух коммутаторов SN6000, четырех серверных HBA-адаптеров HP 81Q Single-Port PCI-e FC, 12 модулей HP 8Gb Short Wave FC SFP+ и 8 пятиметровых кабелей Fibre Channel. С помощью этого набора даже новичок в технологиях Fibre Channel сможет без проблем развернуть небольшую сеть хранения с четырьмя хостами.

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

Если же все 20 портов SN6000 будут задействованы, то для дальнейшего расширения сети SAN используется стекирование коммутаторов. SN6000 отличается от других коммутаторов Fibre Channel начального уровня наличием четырех выделенных десятигигабитных портов Fibre Channel для стекирования (Inter-Switch Link, ISL) поэтому при объединении коммутаторов в стек не потребуется освобождать часть портов, к которым подсоединены серверы и системы хранения SAN.

Благодаря этому стекирование производится в горячем режиме (без нарушения нормальной работы SAN) и меньше риск неправильного соединения кабелей между коммутаторами. Отметим, что порты для стекирования давно стали стандартными для модульных коммутаторов Ethernet, но в оборудовании для сетей Fibre Channel они стали использоваться только в последнее время. Порты стекирования SN6000 используют 10-гигабитный Fibre Channel с опцией перехода на 20-гигабитный интерфейс, причем после перехода на более быстрый интерфейс не нужно заменять кабели, соединяющие порты ISL.

В стек можно объединить до шести коммутаторов со 120 портами, и SSCM управляет всем стеком как одним устройством. Кроме того, можно соединить между собой до пяти стеков коммутаторов SN6000.

По сравнению с объединением нестекируемых коммутаторов Fibre Channel с помощью топологии mesh стек SN6000 уменьшает количество портов и кабелей, задействованных для соединения отдельных коммутаторов – например, для построения 80-портовой конфигурации требуется четыре SN6000 с 6 кабелями против пяти нестекируемых 24-портовых коммутаторов с 20 кабелями. Кроме того, для соединения портов нестекируемых коммутаторов потребуется еще приобрести модули SFP для портов, выполняющих функции ISL, а стекируемые порты SN6000 обеспечивают более высокую пропускную способность, чем основные восьмигигабитные порты коммутатора.

Для оптимизации работы портов стекирования SN6000 применяется функция Adaptive Trunking, которая автоматически перераспределяет трафик между несколькими путями ISL стека. Другая функция I/O StreamGuard гарантирует непрерывную передачу потоков данных через сеть хранения для критически-важных приложений (например, резервного копирования на ленту) при перезагрузке одного из серверов, подключенных к SAN,

SN6000 также подойдет и для расширения существующей большой сети SAN крупного предприятия. Из-за проблем совместимости коммутаторов Fibre Channel при построении и расширения SAN заказчики как правило стараются использовать в сети хранения оборудование одного производителя. SN6000 позволяет построить гетерогенную сеть благодаря реализованной в этом коммутаторе функции Transparent Routing, которая прозрачно соединяет его к большим коммутаторам Fibre Channel (так называемым директором, например, HP StorageWorks B-Series и C-Series) и в результате в фабрику существующей SAN добавляются подключенные к SN6000 системы хранения и серверы, но сам стекируемый коммутатор будет невидим для старой SAN.

Такой сценарий развертывания SN6000 для расширения существующей SAN можно применять при построении с помощью этих коммутаторов дополнительной SAN для резервного копирования, в которой установлены ленточные библиотеки, либо отдельной SAN департамента, соединенной с основной сетью хранения предприятия, а также для постепенного перевода SAN с технологий 2 или 4 Гбит/сек на восьмигигабитную версию Fibre Channel.

В простейшем случае 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.

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

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