что такое lun в nas

LOGICAL UNIT NUMBER (LUN)

LUN – понятие, связанное с системами хранения данных (СХД) и с сетями хранения данных (SAN- Storage Area Network).

LUN – это уникальный идентификатор одного или нескольких физических или виртуальных устройств хранения данных, выполняющих команды ввода-вывода, поступающие с сервера. Это номер логической единицы системы хранения (употребляется также перевод «номер логического устройства»).

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

Логической единицей может быть часть диска хранения, весь диск или несколько дисков хранения, включая жесткие диски, твердотельные диски или ленточные накопители, в одной или нескольких системах хранения. LUN может ссылаться на весь набор RAID (Redundant Array of Independent Disks), один диск или раздел или несколько дисков или разделов хранения. Весь объём дисков можно нарезать на разные LUN и раздать разным серверам.

Примеры типов LUN:
· зеркальный LUN – отказоустойчивый LUN с идентичными копиями на двух физических дисках для обеспечения избыточности данных и реализации резервного копирования;
· объединенный LUN – несколько LUN, объединенных в одну логическую единицу или том;
· чередующийся LUN – LUN, обеспечивающий запись данных на несколько физических дисков, потенциально повышающий производительность за счёт того, что запросы ввода-вывода распределены по дискам;
· чередующийся LUN с контролем четности – отказоустойчивый LUN, распределяющий данные и сведения о четности поочерёдно по трем или более физическим дискам. В случае выхода из строя физического диска данные могут быть восстановлены на основе информации на оставшихся дисках. Расчет четности может повлиять на производительность записи.

LUN-ы можно создавать и управлять ими с помощью «Диспетчера хранилища для сетей SAN» в дисковых подсистемах хранения протоколов Fibre Channel и iSCSI, которые поддерживают виртуальную дисковую службу (VDS).

Источник

О сетях хранения данных

Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке 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 для серверов.

А дальше на системах хранения нарезаются ресурсы, они же диски (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). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.

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

Источник

Быстрая настройка СХД Аэродиск Engine

Мы продолжаем вас знакомить с российскими системами хранения данных AERODISK ENGINE N-серии. Предыдущая – вводная – статья находится здесь. Также у ребят появился свой YouTube канал с обучающими видео по настройке и работе с системой. А еще перед новым годом Аэродиск запустил промо-программу, в рамках которой можно купить СХД со скидкой до 60%! Предложение, на наш взгляд, отличное.

В этот раз Аэродиск нам предоставил систему хранения ENGINE N2 в All-flash конфигурации для самостоятельного изучения и настройки, и мы поделимся этим опытом.
В рамках знакомства с ENGINE мы сделаем цикл из 3-х статей:

Распаковка

В руках у нас оказалась вот эта коробка. Как говорит производитель, в ней 40 ТБ с производительностью 300 000 IOPS. Звучит интригующе, будем проверять.

Распаковываем и видим следующее:

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

Спереди видим слоты под 24 диска, сзади – модульные контроллеры и блоки питания. На контроллерах установлены FC-порты, Ethernet-порты (обычный RJ-45 и 10 гигабитный на оптике), а также SAS-порты для подключения дисковых полок. То, что все типы популярных портов ввода-вывода есть в одной коробке – несомненный плюс. Все задублировано, значит, может меняться на горячую, и поэтому с работой в режиме нон-стоп проблем, по идее, быть не должно. Но мы проверим.

Монтируем СХД в стойку, подключаем к серверу через коммутаторы (и FC, и Ethernet), включаем СХД и начинаем настройку. Подключение можем осуществить через командную строку по SSH или Web. С командной строкой будем разбираться позже, сразу идем в веб-интерфейс:

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

Настраиваем группы хранения

По документации ENGINE может отдаваться наружу по следующим протоколам:

Имеем два типа дисковых групп: RDG, который умеет отдавать блочку и файлы и DDP, который умеет отдавать только блочку (и специально заточен под неё). В прошлой нашей статье про Аэродиск было приведено подробное описание и сценарии применения RDG и DDP. Поскольку RDG больше нашпигован полезными функциями, будем настраивать его. К DDP мы вернемся в следующей статье, когда надо будет тестировать различные сценарии производительности.

Создаем группу хранения RDG

Делаем гибридную группу из 4-х SSD дисков (2 под кэш, 2 под тиринг с уровнем RAID-10 и 7 HDD дисков уровнем RAID-6P (тройная четность). В итоге получаем быстрый «верхний» уровень на SSD и медленный, но очень надежный «нижний» уровень из HDD.

Процесс создания группы вопросов у нас не вызвал, состоит из двух этапов, в начале создается основной «нижний», а потом на него накидываются «верхние» уровни. По ходу создания можно включить дедупликацию и компрессию (включаем). Также нас сразу предупреждают о том, сколько дисков автозамены у нас останется для нештатных ситуаций. Один диск оставляем для автозамены, чтобы протестировать этот механизм.

После создания видим «скелет» нашей рэйд-группы. Выглядит наглядно и удобно:

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

Группа создана. В свойствах самой группы есть вкладки с LUN-ами и шарами:

Оттуда же пошли создавать LUN. В процессе создания LUN-а нам предлагают различные опции. Из явно полезных отметим возможность создания «тонкого» LUN-а, свой размер блока на конкретный LUN (очень полезно для различных типов нагрузки) и возможность отдельно на каждый LUN включить или выключить дедупликацию и компрессию. Делаем «тонкий» LUN с дедупом и компрессией. LUN создан:

С созданным LUN-ом можно делать много разных операций. После того, как LUN отдадим серверу, мы их проверим.

Теперь создаем файловые ресурсы. Процесс создания NFS и SMB мало чем отличается от создания LUN-а, также можно выбрать индивидуальный блок, «тонкость» или «толстость», но есть и отличие. Задать индивидуальное включение дедупликации и компрессии на файловый ресурс нельзя, то есть настройка будет браться с родительского объекта. Таким образом если хотим, чтобы на файловые шары работала дедупликация и компрессия это нужно включать на уровне RDG. В принципе это ОК, но менее гибко, чем с LUN-ами.

Также отдельная тема — это настройка доступа к файловым ресурсам. Для NFS предусмотрено разграничение доступа (на чтение и/или запись) по IP-адресам и/или пользователям.

Для SMB предусмотрено создание локальных пользователей и интеграция с Active Directory. Для использования AD, при создании файлового ресурса можно разрешить авторизацию из AD и включить шару в домен. В этом случае права на файловый ресурс будут управляться через Active Directory.

Итак, создали два файловых ресурса: NFS и SMB.

После создания смотрим, какие операции мы можем выполнить. В принципе, все то же самое, что и с LUN-ами: изменение размеров, снэпшоты, тип доступа и т.д. Теперь задача отдать эти созданные ресурсы хосту.

Начнем с LUN-а

LUN мы можем отдать по iSCSI и/или FC. Это не опечатка, судя по документации Аэродиска, действительно, есть возможность отдать один LUN одновременно и по FC, и iSCSI. Зачем это нужно не очень понятно, но вендор говорит, что эта функция может пригодиться для диагностики. Ну, допустим, так. В любом случае мы будем делать «по-старинке» и один LUN отдадим по FC, а другой по iSCSI. Чтобы заново ничего не создавать, сделаем клон существующего LUNа.
Описывать процесс настройки SAN-коммутаторов мы не будем, он не отличается от настройки для других СХД. Отметим, что на портале поддержки Аэродиска в базе знаний есть примеры настройки различных вариантов SAN-коммутаторов, что, безусловно, плюс в карму вендора.

Делаем маппинг LUN-а по FC

Идем в инициаторы, видим, что с хоста прилетели WWN-ы инициаторов. Создаем таргет на СХД, связываем таргеты и инициаторы в группу устройств.

Выбираем нужный LUN и делаем маппинг через созданную группу устройств.

В приложении руководства администратора есть отдельный гайд, как правильно презентовать ресурсы СХД по каждому из протоколов с настройками для популярных ОС. Презентация LUN-а по FC особых вопросов не вызвала. В ОС CentOS предварительно должен быть установлен пакет device-mapper-multipath. Хост-сервер в итоге увидел блочное устройство, понял, что это AERODISK.

Кстати, в процессе маппинга обнаружили полезную вещь. Можно задать руками LUN ID. По умолчанию этот ID присваивается по порядку автоматически, но иногда возникают ситуации, когда его надо указывать руками. Например, для SAN boot (загрузка ОС с LUN-а СХД), а также в больших ЦОД-ах, где много разных СХД, а ещё больше LUN-ов с них. Там LUN ID служит для корректного учета и быстрого поиска. На наш взгляд функция – мастхэв и мастюз.

Теперь проверяем – видим, что LUN доступен с двух активных контроллеров (второй как неоптимальный путь – классическая ALUA).

Форматируем LUN в NTFS получаем диск «D».

Переходим к iSCSI

Создаем еще один LUN на той же дисковой группе. С презентацией по iSCSI пришлось потрудиться. Дело в том, что для iSCSI, кроме таргета, инициатора и их связи есть ещё одна дополнительная сущность — HA-ресурс. HA-ресурс — это виртуальный интерфейс, на который вешается виртуальный IP (VIP), который смотрит одновременно на два (или более) физических Ethernet-интерфейса на двух разных контроллерах и служит для отказоустойчивости. Схематично это выглядит так:

HA-ресурс привязывается к конкретной RDG. На туже группу можно привязать еще один HA-ресурс и отдать с него VIP в другую подсеть (может в жизни пригодиться).

В итоге разобрались. Создали HA-ресурс, поставили iSCSI-инициатор в винду, скопировали имя инициатора (IQN) винды. Далее создали iSCSI-таргет на СХД и связали таргет с инициатором.

Подключили LUN в винду. Отформатировали, создали диск D.

Подключаем файловые ресурсы

Этот процесс максимально простой, что с SMB, что с NFS. Единственный момент, на Windows нужно поставить штатный NFS-клиент. Все эти нюансы описаны в документации. Файловый доступ также требует HA-ресурс. Мы его создали на предыдущем шаге, поэтому будем использовать тот же.
Обе наши файловые шары подключаем с в Windows с помощью сетевого диска, соответственно, G и E.

Источник

Современные системы хранения данных. Часть 2

В первой части статьи, посвящённой системам хранения данных (СХД), мы познакомились с базовой аппаратной составляющей систем хранения и сферой применения такого оборудования. Ведь для возникновения целого направления в современной IT-индустрии был нужен мощный толчок. Можно с уверенностью сказать, что таких подвижек не было уже давно, повсеместно применялась стандартная схема – сервер с дисками внутри, на которых хранятся основные данные; локальная сеть и компьютеры-клиенты. И вот наконец-то свершилось – системы хранения данных выделяются в отдельный «пласт». Теперь данные хранятся на специализированном оборудовании, обеспечивающем высочайшую надёжность хранения и уровень сервиса, который сложно получить на стандартных схемах информационной инфраструктуры предприятия. Собственно, ради этих составляющих – надёжности хранения и сервиса, которые предоставляет хранилище для управления информацией – в основном и строятся сети хранения данных (Storage Area Network, SAN).

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

Итак – сети хранения и системы хранения данных. Если «зачем» пояснялось в первой части статьи, то во второй мы попытаемся ответить на вопрос «как». Как мы помним, системы хранения данных, или, на профессиональном жаргоне, дисковые стойки, в первую очередь легко различать по внешним интерфейсам, которые и обеспечивают подключения серверов (хостов), и по типу используемых внутри накопителей. Кое-какие из интерфейсов и типов накопителей мы уже упоминали, теперь же коснёмся самых современных. Наряду с терминами СХД (система хранения данных) будем также упоминать синонимы – к примеру, «дисковая стойка».

Внешние интерфейсы подключения – это, как мы помним, в основном SCSI или FibreChannel, а также довольно молодой стандарт iSCSI. Также не стоит сбрасывать со счетов небольшие интеллектуальные хранилища, которые могут подключаться даже по USB или FireWire. Мы не станем рассматривать более редкие (порой просто неудачные в том или ином плане) интерфейсы, как SSA от IBM или интерфейсы, разработанные для мейнфреймов – к примеру, FICON/ESCON. Особняком стоят хранилища NAS, подключаемые в сеть Ethernet. Под словом «интерфейс» в основном понимается внешний разъём, но не стоит забывать, что разъём не определяет протокол связи двух устройств. На этих особенностях мы остановимся чуть ниже.

Интерфейс SCSI

Расшифровывается как Small Computer System Interface (читается «скази») – полудуплексный параллельный интерфейс. В современных системах хранения данных чаще всего представлен разъёмом SCSI:

…и группой протоколов SCSI, а конкретнее – SCSI-3 Parallel Interface. Отличие SCSI от знакомого нам IDE – бОльшее число устройств на канал, бОльшая длина кабеля, бОльшая скорость передачи данных, а также «эксклюзивные» особенности типа high voltage differential signaling, command quequing и некоторые другие – углубляться в этот вопрос мы не станем.
Если говорить об основных производителях компонент SCSI, например SCSI-адаптеров, RAID-контроллеров с интерфейсом SCSI, то любой специалист сразу вспомнит два названия – Adaptec и LSI Logic. Думаю, этого достаточно, революций на этом рынке не было уже давно и, вероятно, не предвидится.

Интерфейс FibreChannel

Полнодуплексный последовательный интерфейс. Частично рассмотрен нами ранее, чаще всего в современном оборудовании представлен внешними оптическими разъёмами типа LC или SC (LC – меньше по размерам):

…и протоколами FibreChannel Protocols (FCP). Существует несколько схем коммутации устройств FibreChannel:

Подключение по схеме FibreChannel Switched является самой распространённой схемой, в терминах FibreChannel такое подключение называется Fabric – в русском языке существует калька с него – «фабрика». Следует учесть, что коммутаторы FibreChannel – это довольно продвинутые устройства, по сложности наполнения близкие к IP-коммутаторам уровня 3 (маршрутизаторам). Если коммутаторы соединены между собой, то они функционируют в единой фабрике, имея пул настроек, действующих для всей фабрики сразу. Изменение каких-то опций на одном из коммутаторов может приводить к перекоммутации всей фабрики, не говоря уже о настройках авторизации доступа, к примеру. С другой стороны, существуют схемы SAN, которые подразумевают несколько фабрик внутри единой сети SAN. Таким образом, фабрикой можно называть только группу объединённых между собой коммутаторов – два или более не объединённых между собой устройства, введённые в SAN для повышения отказоустойчивости, образуют две или более различные фабрики.

Адресация устройств FibreChannel осуществляется по 64-битовому адресу WorldWideName (WWN), простой пример записи WWN-адреса – 90:06:F1:60:00:60:03:b4. Применимо к портам FibreChannel можно сказать, что WWN этих портов – аналог MAC-адреса в LAN.

Компоненты, позволяющие объединять хосты и системы хранения данных в единую сеть, принято обозначать термином «connectivity». Connectivity – это, конечно же, дуплексные соединительные кабели (обычно с интерфейсом LC), коммутаторы (switches) и адаптеры FibreChannel (HBA, Host Base Adapters) – то есть те платы расширения, которые, будучи установленными в хосты, позволяют подключить хост в сеть SAN. HBA обычно реализованы в виде плат стандарта PCI-X или PCI-Express. На фотографии – PCI-X адаптер FibreChannel от компании QLogic с двумя внешними портами FC 2Gb и дуплексным интерфейсом подключения LC:

Часто возникают вопросы – как же FibreChannel может работать по «меди»? Как уже упоминалось, не стоит путать fibre и fiber – среда распространения сигнала может быть различной. Например, все жёсткие диски FibreChannel имеют металлические контакты, да и обычная коммутация устройств по «меди» – не редкость, просто постепенно все переходят на оптические каналы как наиболее перспективную технологию и функциональную замену «меди». В некотором современном оборудовании с внешними оптическими интерфейсами полки расширения (то есть «коробки» для дополнительных жёстких дисков) подключаются к основному устройству с внешними портами по схеме FC-AL (!) медными кабелями (!), что может вас удивить, однако медное подключение более надёжно в механическом плане и менее требовательно в плане своего обслуживания. Но имеются и минусы – например, ограничение на длину (не более 25 метров) и низкую помехозащищённость, что на скоростях в 2 Гбайт может быть проблемой.

Интерфейс iSCSI

Обычно представлен внешним разъёмом RJ-45 для подключения в сеть Ethernet – всем нам известный разъём:

…и собственно самим протоколом iSCSI (Internet Small Computer System Interface). По определению SNIA: «iSCSI — это протокол, который базируется на TCP/IP и разработан для установления взаимодействия и управления системами хранения данных, серверами и клиентами». На этом интерфейсе остановимся немножко подробней, хотя бы в силу того, что каждый пользователь способен использовать iSCSI даже в обычной «домашней» сети.

Необходимо знать, что протокол iSCSI определяет, как минимум, транспортный протокол для SCSI, который работает поверх TCP, и технологию инкапсуляции SCSI-команд в сеть на базе IP. Проще говоря, iSCSI – это протокол, позволяющий получить блочный доступ к данным с помощью команд SCSI, пересылаемых через сеть со стеком TCP/IP. iSCSI появился как замена FibreChannel и в современных СХД имеет перед ним несколько преимуществ – способность объединять устройства на огромных расстояниях (используя существующие сети IP), возможность обеспечивать заданный уровень QoS (Quality of Service, качество обслуживания), более низкую стоимость connectivity. Однако основная проблема использования iSCSI как замены FibreChannel – большое время задержек, возникающих в сети из-за особенностей реализации стека TCP/IP – это время может приближаться к 80 микросекундам, что сводит на нет одно из важных преимуществ использования СХД – скорость доступа к информации и низкую латентность. Это серьёзный минус.

Маленькое замечание по поводу хостов – они могут использовать как обычные сетевые карты (тогда обработка стека iSCSI и инкапсуляция команд будет осуществляться программными средствами), так и специализированные карты с поддержкой технологий аналогичных TOE (TCP/IP Offload Engines). Такая технология обеспечивает аппаратную обработку соответствующей части стека протокола iSCSI. Программный метод дешевле, однако больше загружает центральный процессор сервера и в теории может приводить к бОльшим задержкам, чем аппаратный обработчик. При современной скорости сетей Ethernet в 1 Гбит/с можно предположить, что iSCSI будет работать ровно в два раза медленнее FibreChannel со скоростью 2 Гбит, однако в реальном применении разница будет ещё заметнее.

Адресация iSCSI-устройств многим покажется слишком сложной, но это итог формирования стандартов эпохи расцвета IT. Существуют два типа адресации – EUI-based и IQN, просто приведу примеры записи адресов двумя различными методами адресации (они не эквивалентны друг другу – это лишь пример):

Желающие могут ознакомиться с RFC 3720 и 3721 для более полной информации, а также найти более свежие документы, определяющие структуру iSCSI в целом.

Однако возможность организовать SAN на базе iSCSI проще, чем вам кажется. Что необходимо для сети данных? Устройства хранения, компоненты коммутации (connectivity) и хосты. Хостами могут быть обычные компьютеры, компоненты коммутации – это ваша локальная IP-сеть, сложнее с системой хранения, но и это решаемо. В терминологии iSCSI принято различать два типа устройств – Initiator и Target. Как вы уже догадались: Initiator – это хост, а Target – это система хранения данных. Для того чтобы ваш хост с операционной системой Windows смог подключиться к хранилищу с интерфейсом iSCSI, достаточно лишь иметь установленный на машине Software Initiator, на данный момент актуальная версия – «Microsoft iSCSI Software Initiator Version 2.01 (build 1748)». По этой ссылке можно ознакомиться с продуктом и при желании скачать (его использование абсолютно бесплатно). Что интересно, в новой версии ОС от Microsoft, Windows Vista, Microsoft iSCSI Software Initiator встроен по умолчанию даже в «домашнюю» версию операционной системы:

Мы видим стандартные пункты панели управления и настройку iSCSI для этой машины. Выделен адрес этого хоста как iSCSI-инициатора, используется уже знакомая нам адресация IQN. После того, как мы имеем iSCSI-инициатор, компоненты коммутации, нам необходима iSCSI-target, то есть наша СХД. Естественно, первый и самый простой вариант – аппаратное устройство, система хранения данных с интерфейсом iSCSI. Второй вариант – опять же программно реализованный iSCSI-target. На базе всеми любимой операционной системы Windows его можно получить, используя стороннее ПО компании «String Bean Software», к примеру. Такое ПО называется «WinTarget» и может быть опробовано в виде бесплатной 14-дневной испытательной версии, хотя сам продукт платный. С помощью Wintarget вы можете создать на целевом хосте (компьютере, выступающем в роли iSCSI-target) виртуальные логические тома (LUN, хотя правильнее их всё же называть LU – logical unit), которые и будут доступны хостам-инициаторам, хотя на целевой машине эти логические тома будут представлен в виде обычных файлов соответствующей длины. В отличие от обычного файлового доступа к компьютеру по сети, при использовании iSCSI мы получаем блочный доступ. Наш LUN, физически размещённый на инициаторе (который, в свою очередь, может находиться за тысячи километров – подключение через Интернет), видится нашей машиной как обычный «логический диск» (в терминологии Windows). Мы можем присвоить ему «букву диска», отформатировать и использовать в нашей системе так же, как разделы локального жёсткого диска. Ведь забавно выглядит работа с домашнего компьютера с подключённым к нему десятком LUN’ов, которые физически разнесены по всему земному шару – когда загружаетесь вы, к примеру, с СD, а жёсткого диска в вашей системе и вовсе нет! Пока проблема только в «ширине каналов».

При желании каждый может найти дополнительную информацию по iSCSI и поставить собственные эксперименты, однако упомяну ещё одну функциональность, которая становится доступна домашним пользователям – это построение кластеров на базе стандартного аппаратного обеспечения. Необходимы лишь кластерная ОС да грамотно настроенный iSCSI-target, тогда необходимое число LUN видно сразу всем узлам кластера. Скажу более – кластер вида active-active был мной построен и опробован на базе обычной домашней машины (XP Professional), которая выступала в роли iSCSI-target. Хосты (iSCSI-initiator’ы) были установлены в виртуальной машине VMware Workstation на базе Windows 2003 Server с установленным поверх «Microsoft iSCSI Software Initiator». Все желающие могут повторить эти эксперименты.

И кратко упомянем ещё пару протоколов, которые встречаются более редко и предназначены для предоставления дополнительных сервисов уже существующим сетям хранения данных (SAN):

Мы кратко рассмотрели физические интерфейсы, протоколы, типы коммутации и адресацию для систем хранения данных, не останавливаясь на перечислении всех возможных вариантов. Теперь попытаемся представить эти технологии в реальных системах, поставляемых на наш рынок различными производителям. Сначала, просто для примера, приведу имеющийся у меня итоговый отчёт одной из ведущих аналитических компании мира – IDC. В таблице видны финансовые результаты 2 квартала 2005 года на мировом рынке внешних (именно они нас интересуют) дисковых систем хранения:

Думаю, кое-кому может быть не известно о лидере – EMC Corporation. Всё дело в том, что EMC специализируется именно на оборудовании для хранения данных, программных продуктах для обеспечения управления информацией и сервисе, предоставляемом клиентам, использующим это оборудование и ПО. Как мы понимаем, такие продукты – это сфера высоких технологий, а вот HP, IBM, Dell и Hitachi производят также широкий спектр другой продукции (часто даже не компьютерной), посему эти названия, как мне кажется, ни у кого не вызовут вопросов. Что интересно, ПО, поставляемое EMC, настолько актуально, что это позволило компании занять 7 место в мировом рейтинге «софтовых компаний» по объёмам поставок. Между прочим, известная всем специалистам компания VMWare также принадлежит корпорации EMC.

В приведенном списке есть две компании, которые сами производят весь спектр поставляемых ими дисковых систем хранения – это EMC Corp. и Hitachi (HDS, Hitachi Data Systems), также оборудование этих компаний поставляют другие производители под своей собственной маркой. Компания HP использует системы хранения от Hitachi как свои старшие модели (HP XP), а компания Dell – системы хранения от EMC (DELL|EMC). IBM же использует в качестве OEM-производителей для своих младших моделей СХД продукты от Adaptec и Engenio (подразделение LSI Logic, занимающееся направлением компонент систем хранения данных). Конечно, в лидеры не попали множество более мелких компаний, производящих свои собственные системы хранения, а их немало, и о них мы поговорим.

Если перечислить основных значимых производителей рынка внешних систем хранения данных, то список будет примерно таков: EMC, HP, IBM, Dell, Hitachi, NetApps, Dothill, Engenio, Adaptec, Raidtec и другие. Конечно, ещё есть имена, которые на слуху, но отношение к системам хранения данных имеют второстепенное, хотя их и выпускают – например, D-Link.

Какие же параметры характеризуют системы хранения данных? Некоторые из них были перечислены в прошлой статье – это тип внешних интерфейсов подключения и типы внутренних накопителей (жёстких дисков). Следующий параметр, который есть смысл рассматривать после двух вышеперечисленных при выборе дисковой системы хранения, – её надёжность. Надёжность можно оценить не по банальному времени наработки на отказ каких-то отдельных компонент (факт, что это время примерно равно у всех производителей), а по внутренней архитектуре. «Обычная» система хранения часто «внешне» представляет собой дисковую полку (для монтажа в 19-дюймовый шкаф) с жёсткими дисками, внешними интерфейсами для подключения хостов, несколькими блоками питания. Внутри обычно установлено всё то, что обеспечивает работу системы хранения – процессорные блоки, контроллеры дисков, портов ввода-вывода, кэш-память и так далее. Обычно управление стойкой осуществляется из командной строки или по web-интерфейсу через любой браузер, начальная конфигурация часто требует подключения по последовательному интерфейсу. Пользователь может «разбить» имеющиеся в системе диски на группы и объединить их в RAID (различных уровней), получившееся дисковое пространство разделяется на один или несколько логических блоков (LUN), к которым и имеют доступ хосты (серверы) и «видят» их как локальные жёсткие диски. Количество RAID-групп, LUN-ов, логика работы кэша, доступность LUN-ов конкретным серверам и всё остальное настраивается администратором системы. Обычно СХД предназначены для подключения к ним не одного, а нескольких (вплоть до сотен, в теории) серверов – посему такая система должна обладать высокой производительностью, гибкой системой управления и мониторинга, продуманными средствами защиты данных. Защита данных обеспечивается многими способами, самый простой из которых вы уже знаете – объединение дисков в RAID. Однако данные должны быть ещё и постоянно доступны – ведь остановка одной системы хранения данных, центральной на предприятии, способна нанести ощутимые убытки. Чем больше систем хранит данные на СХД, тем более надёжный доступ к системе должен быть обеспечен – потому что при аварии СХД останавливается работа сразу всех серверов, хранящих там данные. Высокая доступность стойки обеспечивается полным внутренним дублированием всех компонент системы – путей доступа к стойке (портов FibreChannel), процессорных модулей, кэш-памяти, блоков питания и т.д. Попытаемся принцип 100%-го резервирования (дублирования) объяснить следующим рисунком:

Источник