Добавление в кластер системы хранения NetApp FAS происходит очень просто:
Подключаются порты кластерного интерконнекта в свич и выполняется команда:
А как вывести ноду из кластера?
Вывести ноду из кластера может понадобится в самых разнообразных случаях. Иллюстрацией тому может быть, если у вас есть кластер состоящий к примеру из систем FAS8020 и FAS2240/255x и вы хотите конвертировать вторую в полку, чтобы подключить её к 8020.
Для этого необходимо:
После чего вы увидите следующее сообщение:
Замечания по ошибкам и предложения правок в тексте прошу направлять в ЛС.
Подключаются порты кластерного интерконнекта в свич и выполняется команда:
cluster setup
А как вывести ноду из кластера?
Вывод нод из кластера
Вывести ноду из кластера может понадобится в самых разнообразных случаях. Иллюстрацией тому может быть, если у вас есть кластер состоящий к примеру из систем FAS8020 и FAS2240/255x и вы хотите конвертировать вторую в полку, чтобы подключить её к 8020.
Для этого необходимо:
- Удалить или мигрировать вольюмы из агрегатов находящихся на отключаемых нодах, включая системные вольюмы MDV
- Удалите или мигрируйте LIF'ы с нод которые будут отключены. SAN LIF'ы можно не мигрировать (ведь у вас скорее всего настроен мультипасинг) или могут быть мигрированы в offline режиме
- Измените home порты на LIF'ах, если они указывают на порты отключаемой ноды
- Удалите порты отключаемых нод из вручную содзанных failover-groups
- Удалите порты отключаемых нод из вручную созданных broadcast-domain'ов
- Просто удалите порты отключаемых нод из portset'ов или создайте новые portset'ы, замените в igroup'ах старные на новые, после удалите старые
- Выключите High Availability для группы в которой находится отключаемая нода
- Если на агрегатах находящихся на отключаемых нодах расположены системные вольюмы для аудит логов, выключите CIFS аудит
- При необходимости, из advanced режима перместите epsilon на ноду которая не будет удаляться
cluster1::> vserver audit delete -vserver vsm01
cluster1::> storage failover modify -node clA-01 -enabled false
cluster1::> storage failover modify -node clA-02 -enabled false
cluster1::*> set -privilege advanced
cluster1::*> cluster show
cluster1::*> cluster modify -node clA-02 -epsilon false
cluster1::*> cluster modify -node clA-04 -epsilon true
cluster1::*> cluster unjoin -node clA-02
После чего вы увидите следующее сообщение:
cluster1::*> cluster unjoin -node clA-02
Warning: This command will unjoin node "clA-02" from the cluster. You
must unjoin the failover partner as well. After the node is
successfully unjoined, erase its configuration and initialize all
disks by using the "Clean configuration and initialize all disks (4)"
option from the boot menu.
Do you want to continue? {y|n}: y
[Job 32] Cleaning cluster database[Job 32] Job succeeded: Cluster unjoin succeeded
Замечания по ошибкам и предложения правок в тексте прошу направлять в ЛС.
Комментарии (4)
bbk
01.09.2015 13:02По поводу стандартной процедуры.
Команда unjoin сама по себе конечно же очень простая и KB есть.
Но на практике столкнулся, что KB ничего не говорит про:
Системные вольюмы
Про cifs аудит
Про фэйловер-группы
Пришлось тыкать самому. Мелочь, а может сэкономить 3 часа времени ;)Pinkkoff
01.09.2015 13:05+1Мелочь, а может сэкономить 3 часа времени ;)
Что же, вынужден согласиться=)
NetApp вообще отличается некоторой сложностью внутренней архитектуры, особенно кластер.
Pinkkoff
Данная процедура более чем стандартная, и описана в документации вендора (например, здесь)
SAN LIF'ы не надо мигрировать в принципе. SAN полностью управляется мультипасингом, необходимо его проверить на всех хостах, использующих данный массив в качестве блочного таргета.Вообще говоря, такие операции как вывод узла из кластера нужно делать только тогда, когда 100% уверен в своих знаниях по этому вопросу и использовать только официальную документацию. А не так — прочитал хабр и пошел удалять ноды.
bbk
По поводу SAN lif, да в основном их мигрировать не нужно. Но можно
И иногда в редких случаях в этом есть необходимости. Такие случаи действительно крайне редкие и скорее экзотика.