Первая же боевая задача — презентовать несколько LUN под кластер Oracle на Solaris — получила неожиданный бонус-челлендж: настроить Solaris. Вообще-то это должны были делать швейцарские коллеги, от меня требовалось только предоставить диски и обеспечить совместимость железа, но наши незнакомые друзья из Швейцарии оказались ещё более криворукими чем я, так что задача «обновить прошивки на серверах» плавно переросла в «установить Solaris, настроить сеть, скопировать дистрибутивы с Win-сервера, презентовать LUN, настроить их в ОС и создать точки монтирования». То есть провести все подготовительные работы. С учётом того, что с unix-системами я не работал, а Solaris видел впервые в жизни, было увлекательно.
Solaris показалась мне, мягко говоря, интуитивно непонятной и недружественной к здравомыслящему человеку, хотя убеждён, что изрядная часть недружелюбия вызвана моим незнакомством с архитектурой ОС. Хотя переименование сервера путём правки четырёх или пяти конфиг-файлов — это как-то слишком сурово.
Ладно, хватит полемики, ограничим описываемую задачу до двух этапов: презентация LUN на стороне VNX и настройка их на стороне ОС до возможности использования.
Участники процесса: EMC VNX 5300 и 2х Sun Solaris 11.1
Шаг 1 — Создание и презентация LUN на VNX5300
Заходим в EMC Unisphere:
- Host — Host List — добавляем новый хост (имя + IP).
- Host — Initiators — добавляем инициаторы (каждый порт HBA на каждый контроллер СХД, то есть 4 объекта получается. В настройках выбираем CLARiiON/VNX в качестве Initiator type и ALUA в качестве Failover Mode (Solaris поддерживает ALUA с версии 10). Регистрируем инициаторы, привязывая их к созданному на предыдущем этапе хосту.
- Storage — LUNs — создаём LUN’ы необходимого размера и прочей конфигурации.
- Host — Storage Groups — создаём Storage Group (скажем, SG_<имя сервера>, как мастер создаёт) и добавляем в неё LUN’ы (вкладка LUNs) и хост (вкладка Hosts).
Всё, презентование завершено. По крайней мере на стороне стораджа. Стоит иметь ввиду, что не стоит добавлять хост в сторадж группу до того, как к нему не прицеплены все инициаторы. Если регистрировать инициаторы на уже добавленный в группу хост, то они остаются неактивными и потребуются дополнительные действия по их активации.
Шаг 1.1 — Зонинг на FC-коммутаторах
Ну это если есть коммутаторы, а на них практикуется зонирование. В моём случае были. Два Brocade. И каждый — отдельная фабрика. Но тут всё просто.
Заходим через Web Tools на коммутатор, выбираем Zone admin. В появившемся интерфейсе последовательно идём по вкладкам:
- Alias — создаём удобочитаемый и понятный псевдоним для WWN каждого устройства (хост, порт А и порт B стораджа)
- Zone — создаём зону и добавляем в неё созданные на предыдущем этапе aliases.
- Zone Config — добавляем выбранную зону в текущую активную конфигурацию.
Повторяем на второй фабрике. Помним про правило «одна зона — один инициатор». То есть, в случае двух фабрик, на каждой фабрике создаётся по одной зоне для одного порта HBA каждого хоста (во второй фабрике — для второго).
Шаг 2 — Конфигурирование LUN в ОС Sun Solaris
Делал по гайду, но там много лишнего, привожу упрощённый.
Чтобы ОС увидела LUN’ы нужно либо перезагрузить сервер, либо выполнить команду
cfgadm -al
Увидим что-то типа такой строки (для каждого LUN):
c1::2200000c50401277 disk connected configured unknown
Если будет unconfigured, то предлагают воспользоваться командой cfgadm -c configure c1. Мне не потребовалось. Также при необходимости диски можно отформатировать (интерактивной утилитой format). У меня такой необходимости тоже не возникло.
Далее командой
luxadm probe
получаем список путей к LUN. Результатом выполнения команды станет примерно такое:
Found Fibre Channel device(s):
Node WWN:50060160bee0331d Device Type:Disk device
Logical Path:/dev/rdsk/c0t60060160518034000EE314354F7CE311d0s2
Node WWN:50060160bee0331d Device Type:Disk device
Logical Path:/dev/rdsk/c0t6006016051803400D853DB1F4F7CE311d0s2
Node WWN:50060160bee0331d Device Type:Disk device
Logical Path:/dev/rdsk/c0t60060160518034007A234E454F7CE311d0s2
Нам нужна часть, выделенная жирным. Первым делом, используя полученную информацию создаём файловую систему на новых дисках
newfs /dev/rdsk/c0t6006016051803400D853DB1F4F7CE311d0s2
После этого диски, в общем-то готовы к использованию. Можно их куда-нибудь примонтировать.
mkdir /lun
mount -F ufs /dev/dsk/c0t6006016051803400D853DB1F4F7CE311d0s2 /lun
Но чтобы не делать это каждый раз вручную, нужно добавить запись в файл /etc/vfstab
/dev/dsk/c0t6006016051803400D853DB1F4F7CE311d0s2 /dev/rdsk/c0t6006016051803400D853DB1F4F7CE311d0s2 /export/home ufs 1 yes logging
Тут меня ждал один нюанс — когда я внёс эту запись средствами mcedit, система после перезагрузки выдала сообщение, что она не смогла примонтировать /var и отказалась загружаться. Так что я впихнул нужные записи таким вот подсмотренным у кого-то извращённым способом:
echo -e «/dev/dsk/c0t6006016051803400D853DB1F4F7CE311d0s2\t/dev/rdsk/c0t6006016051803400D853DB1F4F7CE311d0s2\t/ora/archive\tufs\t1\tyes\tlogging» >> /etc/vfstab
После чего всё заработало. Хотя визуально я никаких отличий не заметил.
Второй особенностью конкретно моей задачи было то, что два LUN имели одинаковый размер, но разные настройки производительности (тип RAID, tiering), ибо под разные нужды и при монтировании надо было этот факт конкретизировать. Однако определить их отличие внутри ОС не было никакой возможности. Я просто удалил один из них из сторадж группы, запомнил набор симолов пути второго и потом вернул первый.
Self Engineering 