6 июн. 2011 г.

SAS коммутатор LSI 6160. Часть 2: подключение

SAS коммутатор LSI 6160. Часть 1: обзор и сценарии использования
В предыдущей части у нас был обзор архитектуры и сценариев использования SAS коммутатора LSI 6160. Перейдем к практике.

Что подключать?

В официальном списке совместимости (публикуется в release notes к прошивке) есть только устройства от самой LSI: SAS-2 HBA и RAID-контроллеры, JBOD'ы 620/630 и entry-level СХД CTS2600.
Дисковые СХД с SAS контроллерами
В связи с весенними событиями (продажа компании NetApp подразделения, занимавшегося выпуском внешних СХД) стоит поискать альтернативу LSI CTS2600: это может быть либо соответствующий продукт под брендом NetApp, либо IBM DS3500 (их выпуском как занимался LSI), либо практически любая SAS-2 СХД начального уровня: на практике проверены HP P2000 G3, Infortrend Eonstor DS и многие другие.
Для подключения лучше всего использовать 2-портовый SAS-2 HBA LSI 9200-8e, который используется в OEM виде большинством tier-1 вендоров, другие HBA LSI, например с большим числом портов или на более современных чипах, либо рекомендуемые вендорами HBA: например, для HP MSA P2000 это SC08e. Следует использовать именно SAS-2 HBA, при использовании SAS-1 топология с каскадированными коммутаторами работать не будет.
JBOD-системы
Как уже было сказано в предыдущей статье, SAS коммутатор LSI 6160 позволяет организовать бюджетную схему с консолидацией дисковой подсистемы, обеспечив зонирование отдельных дисков в JBOD-полке при условии поддержки зонирования T10 чипом экспандера, установленном в JBOD. Гарантированно работать будет связка из SAS-2 HBA или RAID контроллеров LSI и SAS-2 JBOD, например, от Supermicro с чипом LSI SAS2X36, в партномере должно быть E16 (обычный бэкплейн) или E26 (двухэкспандерный). Результат: каждый RAID-контроллер в топологии будет видеть свой набор дисков, что позволит решить проблему нехватки места под локальную дисковую подсистему в каждом сервере. Естественно, поскольку мы отдаем отдельные диски, а не LUN'ы, то никаких кластерных применений и расширенного функционала силами самой СХД (репликация, снапшоты, thin provision) у нас не будет, потому что, собственно, нет никакой СХД - это всего лишь поделенный на отдельные части JBOD.
Пара особенностей работы JBOD'ов при подключении через SAS коммутатор (более подробно они описаны в официальной документации:
  • Если в JBOD'е есть SATA диски, то кабель длиннее 10м работать не будет. Напомню, что два порта коммутатора поддерживают активные кабели SAS длиной 10 и 20м.
  • В интерфейсе утилиты SDM (SAS Domain Manager, обеспечивает управление коммутатором LSI 6160) при подключении JBOD'а в списке конечных устройств не отображается емкость SATA дисков. Причина в ограничениях протокола STP (SATA tunneling protocol, который обеспечивает туннелирование SATA через SAS). STP допускает наличие только одного инициатора для SATA устройства, который привязывается к нему, Т.к. инициатором является контроллер, то коммутатор уже не может опросить SATA устройство, оно отображается с неизвестной емкостью.
Впрочем, эти особенности несущественны, да и SAS nearline диски существуют не зря.
Ленточные приводы
Поддерживаются одиночные приводы в количестве 1шт на каждый коммутатор, из протестированных: Quantum L700 и HP StorageWorks Ultrium 920 SAS.

Тестовый стенд

  • СХД LSI CTS2600 с двумя контроллерами SAS+FC (два порта 6Гбит SAS и 4 порта 8Гбит FC на каждый контроллер)
  • Два сервера в "двойной" платформе Supermicro 1U Twin 1026TT-TF
  • (два 2-процессорных серверных модуля в общем 1U корпусе) с одним процессором Intel Xeon E5620, 6ГБ памяти и HBA LSI 9200-8e
  • SAS коммутатор LSI SAS6160
Один из портов каждого HBA серверов и каждого контроллера в СХД соединены через SAS коммутатор. Задача: отдать LUN'ы с СХД обоим серверам, на которых установлен ESXi 4.1 u1.
Естественно, подобная схема вовсе не требует использования коммутатора (но стенд у нас тестовый и двух серверов вполне достаточно), более того, в данном случае снижается отказоустойчивость: у каждого HBA есть два пути до СХД (контроллер 1 и контроллер 2), но только один путь к коммутатору, который становится единой точкой отказа. Дублированное подключение инициатора к коммутатору работать не будет: коммутатор сформирует один линк x8 - таковы особенности SAS топологии, хотите dual path от инициаторов до коммутатора - используйте два свитча. Впрочем, дублирование коммутаторов даже в небольших SAN - вещь крайне желательная. В предыдущей статье упоминается опция для монтажа в стойку двух LSI 6160.
Итак, начнем с обновления прошивок. Коммутатор прошивается через SDM: заходим браузером на ip по умолчанию -  192.168.1.100, с устройства скачивается и запускается java-приложение, логин/пароль - admin/admin, заходим на вкладку Devices, находим наш коммутатор в списке устройств.
Для начала нужны будут пункты Configure IP и непосредственно Update firmware. На сайте LSI можно получить последний firmware вместе с release notes, который крайне желательно прочитать: например для прошивки 200.09.04.00 нужно сначала обновиться до 200.05.03.00, подробности - в одном из предыдущих постов.
Прошивка HBA от LSI - тоже несложное дело. Обновить нужно как firmware, так и bios, как обычно, через чистый DOS (ключи -f и -b соотвественно).
Следующий шаг - настройка алиасов для подключенных устройств. На вкладке Devices можно увидеть список устройств, подключенных к коммутатору в виде SAS адресов и соответствующих типу устройства обозначений: инициаторы обозначены значком в виде прицела, таргеты - значком мишени, экспандеры - в виде черного прямоугольника с проводами. Ориентироваться по списку SAS адресов не удобно - нужно дать каждому устройству какое-либо осмысленное имя (диски в JBOD'е можно и та оставить). Идем на вкладку Domain и выбираем Alias management. Теперь список устройств выглядит так:
hba1_port1 и hba2_port1 - это SAS HBA, установленные в серверах, cts2600_1 и cts2600_2 - контроллеры в CTS2600.

Зонирование

Самое интересное - настройка зонирования. Технические подробности о зонировании T10 в SAS можно узнать либо в инструкции к LSI 6160, либо в первоисточнике. Причины необходимости в зонировании очевидны:
  • Безопасность: мы можем ограничить доступ к некоторым таргетам во избежание разных неприятных последствий
  • Скорость инициализации: в большой SAS топологии (сотни SAS адресов) у SAS HBA может уйти достаточно продолжительное время на сканирование всех доступных устройств при загрузке.
  • Подключение JBOD к нескольким RAID-контроллерам. Такой сценарий описывался в предыдущей статье, без зонирования он, естественно, не возможен: встреча двух RAID контроллеров на одной SAS топологии приводит к тому, что контроллеры элементарно не могут "договориться" об управлении дисками, что приводит к зависанию коммутатора и/или контроллеров.
Механизм настройки зонирования в коммутаторе LSI 6160 достаточно прост: устройства размещаются в группе зон (Zone Group), из нескольких групп зон и таблицы подключений формируется набор зон (Zone Set). Можно создать несколько наборов зон и активировать их по необходимости. Всего может быть создано максимум 192 группы и 16 наборов.
В средних и больших топологиях ручное создание конфигурации зонирования может показаться сложным. Для упрощения процесса есть три визарда, самым подходящим для нашего тестового сценария является Initiator Isolation Wizard. Как следует из названия данный визард формирует конфигурацию, в которой возможно только взаимодействие таргетов и инициаторов, сами инициаторы при этом изолированы друг от друга. Формируются две зон-группы: одна для инициаторов, другая для таргетов, создается зон-сет, который разрешает взаимодействие групп между собой.
 Два других визарда, Connector Wizard и End Device Wizard помогают в настройке зон-групп на уровне phy и на уровне устройств соответственно. Отображаются только устройства, относящиеся к ZPDS (Zoned Portion of a Service Delivery System), так как экспандеры без непосредственно подключенных к ним таргетов или инициаторов просто транслируют конфигурацию зонирования в домене.
После создания зон-сета его нужно активировать (Activate/Deactivate Zone Set), для обеспечения дополнительной безопасности при управлении зонированием используется пароль. Пароль по умолчанию для зон-сетов в LSI 6160: lynx.
Далее - все как обычно: создаем на СХД LUN'ы и презентуем LUN'ы хостам. Наличие в топологии SAS коммутатора можно заметить наличию его SAS адреса в утилите управления СХД, в хостовой ОС коммутатор будет виден в качестве SAS экспандера (каковым, по сути, он и является):
Два пути к каждому LUN'у в ESXi у нас есть, значит зонирование настроено правильно:
В SDM есть еще много полезного, например настройка SNMP и мониторинг статистики (производительность и ошибки) на портах. Управлять коммутатором необязательно через java GUI, существует и консольный SDM-CLI, в котором можно заскриптовать нужные задачи.

Заключение

Итого: SAS коммутатор LSI 6160 позволяет построить небольшую быструю сеть хранения данных по цене существенно ниже, чем FC и 10Гбит iSCSI: стоимость порта сравнима с гигабитным iSCSI при существенно более высокой (24Гбит/с на каждый 4x wide порт) полосе пропускания и наличии возможности организовать схему с распределением JBOD-полки между несколькими серверами. Конечно, из-за ограничений текущей версии протокола SAS он не коей мере не является "убийцей FC", но если вам не нужна репликация на стороне СХД и достаточно небольшой дистанции подключения, то коммутируемый SAS будет оптимальным решением.
Стоит добавить, что при выборе правильной СХД вам вовсе необязательно отказываться от FC и/или iSCSI в пользу SAS: IBM DS3500 есть в вариантах с контроллерами SAS+FC и SAS+iSCSI, Infortrend EonStor DS - с контроллерами SAS+iSCSI.
Продукт у LSI получился качественным и удобным в настройке, а приобрести его можно тут.

1 комментарий:

  1. > В связи с весенними событиями (продажа компании NetApp подразделения, занимавшегося выпуском внешних СХД) стоит поискать альтернативу LSI CTS2600: это может быть либо соответствующий продукт под брендом NetApp

    Возможно вам и вашим читателям будет полезно посмотреть на составленный мной FAQ по ситуации с бывшими LSI/Engenio.
    http://blog.aboutnetapp.ru/archives/945

    К сожалению, вокруг этой темы очень много ошибочных представлений и непонимания, в частности вот у вас: NetApp не будет продавать бывшие стораджи Engenio конечным покупателям, по крайней мере как отдельные продукты. Только в прежний OEM-канал (то есть все тем же IBM, Oracle, etc.) и через несколько партнеров на рынке США в составе специального решения.

    ОтветитьУдалить