Несколько вопросов про кластеризацию NetWare

[Константин Ошмян]

Доброго времени суток, коллеги!

В преддверии внедрения кластера возникло несколько вопросов, оставшихся неясными даже после чтения документации. Надеюсь, что кто-нибудь из использующих эту технологию сможет прояснить ситуацию.

Итак, дано:
- старый сервер NetWare 5.1sp8 с рабочим томом VOL1: (TFS) на внешнем дисковом массиве;
- новый сервер, куда уже установлена операционка NetWare 6.5sp7;
- внешний дисковый массив, доступный физически обоим серверам (на нём сейчас живёт том VOL1, а кроме того - есть место для того, чтобы сделать "правильный" NSS-ный кластерный том объёмом больше нынешнего VOL1).

Надо: оба этих сервера сделать узлами кластера, том VOL1 смигрировать так, чтобы он стал кластерным ресурсом.

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

Вопросы, собственно, такие:

1. Инсталятор кластерного софта категорически отказывается устанавливать что-либо, пока не увидит минимум два готовых для установки сервера. Т.е. поднять в качестве промежуточного шага "хромой" кластер на одной ноде не получается просто потому, что не удаётся такой кластер создать. Можно ли как-то обмануть инсталятор?
2. При установке кластера предлагается создать специальный служебный раздел (partition) на внешнем массиве, доступном всем нодам. Но есть возможность и отказаться. А как его тогда создать потом? Или перенести в другое место (на другое устройство), если вдруг понадобится?
3. Можно ли создать сейчас на внешнем массиве обычный том NSS, а впоследствии преобразовать его в кластерный ресурс? (В документации описывается только один вариант: том сразу создаётся как кластерный, т.е. то, что он - кластерный, нужно указать сразу при создании тома. Для этого, естественно, нужно, чтобы кластерный софт был уже установлен. Но установить его пока не удаётся - см.п.1.)
4. Как лучше перенести информацию с прежнего традиционного тома на новый кластерный (NSS)? Например, есть штатная утилита VCU для миграции томов TFS->NSS, но она ничего "не знает" про кластер. В частности, ей нужно в качестве destination указывать имя пула, где она сама создаст том NSS. Как ей "объяснять", что меня интересует именно кластерный том? (Впрочем, если есть ответ на предыдущий вопрос, то это становится неактуальным)

Заранее спасибо за ваши ответы и комментарии. Как обычно - благодарность моя не будет иметь границ в пределах разумного!

[Иван Левшин aka Ivan L.]

1. Shareable for clustering устанавливается на уровне либо Pool, либо Partition - если там нет галочки, сделать Shareable for clustering том потом не получится.
2. Установка SBD - SBD INSTALL с консоли.
3. Миграция - SCMT.

На самом деле изначальный вариант выглядит наиболее безопасно.

[Константин Ошмян]

Иван, большое спасибо за отзывы!

По первому пункту: я создавал на внешней тумбе Partition с пометкой "Shareable for clustering". Это, однако, не помогло проинсталировать кластерный софт. Инсталятор запускается с рабочей станции, и пока ему не укажешь минимум два сервера, которые будут в создаваемом кластере, дальше не едет (если я правильно помню, то там просто кнопка "Next >" недоступна).

По второму-третьему: спасибо за подсказку про SBD INSTALL. Нашёл TID 10098813 (Replacing SAN Hardware in a NetWare Cluster); похоже, что можно сделать и одно, и другое (это радует).

По четвёртому: правильно ли я понимаю, что SCMT позволяет смигрировать обычный традиционный том на кластерный NSS-ный? Он разве не только для копирования между различными серверами? (ушёл читать про SCMT)

[Иван Левшин aka Ivan L.]

1. Насколько я понимаю логику работы кластера - пометочка Shareable надобна только для того, чтобы кластерная служба могла работать с томом. Насколько я помню - до запуска NCS смонтировать такой том не получится в принципе. Что вполне логично - одна из основных функций NCS заключается в слежении за томами с целью предотвращения порчи данных.
2. SCMT работает с любыми томами, которые в принципе можно смонтировать - как ты наверняка помнишь, работает оно с рабочей станции, а ей совершенно наплевать на то, какой там том подключен. Я лично переносил с помощью SCMT данные из одной кластерной системы в другую. Не думаю, что задача переноса с обычного тома на кластерный ресурс будет для SCMT проблемой. Единственное "но" проистекает из самой логики работы SCMT - т.к. работает с клиентской машины, скорость так себе, да и сеть просаживается.
3. Про инсталлятор наверняка не скажу - насколько я помню, визард действительно не активирует кнопочку "Далее" до тех пор, пока не будут добавлены хотя бы две ноды. Что, согласись, вполне логично

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

[Aleksandr I]

На Вашем месте я бы сначала сделал миграцию старого сервера (в том числе и тома) на новое железо с помощью SCMT. Тогда у вас будет новый сервер(NetWare 6.5sp7) и том (NSS) с именами старых. Плюс ничего не надо менять в настройках пользователей и небольшой даун-тайм. Затем можно спокойно заняться старым сервером. Поставить на него NW6.5, ввести в дерево. Проверить, видит ли он общий раздел и после этого можно ставить кластерное ПО.

[Константин Ошмян]

Поднимаю старую тему, поскольку возник ещё один вопрос.

Вопрос теоретический: В какой момент кластерный софт проверяет лицензии?
Вопрос практический: При необходимости заменить сервер, являющийся нодой кластера, какова будет правильная последовательность действий?

В документации сказано, что кластер из двух узлов лицензий не требует (проверено: действительно, запускается и работает безо всяких лицензий). Нужно физически заменить один из двух серверов на третий. Для этого надо:
0) подготовить оборудование - подключить новый сервер, обеспечив необходимые коммуникации (в том числе видимость кластерного диска), установить на него операционку. Будем считать, что это уже сделано;
1) установить на новый сервер кластерный софт;
2) добавить новый сервер в существующий кластер;
3) запустить кластерный софт на новом сервере;
4) загасить кластерный софт на старом сервере;
5) убрать из кластера старый сервер.

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

[solomin]

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

P.S. Кстати, на сколько помню, в SLES версии кластер замечательно ставиться на 1 ноду и потом можно добавить вторую.

[Константин Ошмян]

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

Спасибо, я, собственно, так и предполагал. Вопрос только - что подразумевается под "убить"? Загасить на нём кластерный софт (ULDNCS.NCF) - достаточно? Или же надо полностью вычищать сервер из конфигурации кластера? Сам по себе сервер убивать не надо, он мне нужен (в дальнейшем пойдёт в состав другого кластера).

[Ковалев Артем]

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

Спасибо, я, собственно, так и предполагал. Вопрос только - что подразумевается под "убить"? Загасить на нём кластерный софт (ULDNCS.NCF) - достаточно? Или же надо полностью вычищать сервер из конфигурации кластера? Сам по себе сервер убивать не надо, он мне нужен (в дальнейшем пойдёт в состав другого кластера).

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

[Константин Ошмян]

Ну вот, переставил-таки недавно сервер в кластере. Делал так:
1) Перевёл все кластерные ресурсы на ту ноду, которая остаётся в кластере.
2) Загасил ту ноду, которая выводится из кластера (CLUSTER LEAVE, ULDNCS, выгрузка драйверов, через которые доступ к общему дисковому массиву). С этого момента данный сервер свободен (если надо - можно его и выключить).
3) Очистил конфигурацию кластера, удалив из контейнера "кластер" соответствующуюю ноду.
4) Запустил с рабочей станции (через менеджер развёртывания) установку кластера. Выбрал вариант "добавление сервера в существующий кластер", добавил нужный сервер.
NB В инсталяторе есть глюк: даже при выбранной опции "не копировать файлы" (а она по умолчанию выбрана) всё равно с инсталяционного диска без спросу заново копируется на все ноды кластера файл SBDLIB.NLM. Если у Вас уже был установлен патч sp8sbdup, то получается расхождение в версиях файлов SBD.NLM и SBDLIB.NLM, что приводит к ошибкам. Поэтому в конце инсталяции убираем опцию "запустить кластерное ПО автоматически" и сразу же после этого копируем вручную этот файл из патча заново. Причём не только на свежедобавленную ноду, но и на прежнюю тоже.
5) В конфигурации кластерных ресурсов добавил новый сервер в список assigned nodes. Это можно сделать через iManager, Remote Manager (на новом сервере); я это делал с помощью ConsoleOne.
NB Новый сервер добавляется в конфигурацию кластера, но не добавляется автоматически в в свойства кластерных ресурсов как assigned, это надо сделать руками!
6) Запустил на новом сервере кластерный софт: LDNCS. Убедился, что он подключился к кластеру (CLUSTER RESOURCES, CLUSTER VIEW, соотв. пункты в Remote Manager). "Старая" нода по-прежнему конфигурацию кластера отображает не совсем корректно (что не мешает ей работать), через Remote Manager либо CLUSTER VIEW отображает прежнюю конфигурацию. Согласно документации - надо перегрузить кластерное ПО на ней.
7) Переводим кластерные ресурсы на новую ноду (я это делал командами CLUSTER MIGRATE с консоли "нового" сервера). Перегружаем кластерное ПО на "старом" сервере - CLUSTER LEAVE, ULDNCS, LDNCS. Хотя я, по-моему, после CLUSTER LEAVE просто перезагрузил машину.

Всё! Поздравим себя - кластер работает в новой конфигурации. Даун-тайма практически нет (только на переезд ресурсов на другую ноду), клиенты продолжают работать, единственное "но" - некоторый промежуток времени, в течение которого кластер "летит на одном крыле" (но этот промежуток достаточно короткий).

[Дмитрий Иванов]

Доброго времени суток! Приподниму тему, требуются советы:
Задача у нас та-же, только по причине рухнувшего сервера, являвшегося узлом двух-нодового кластера на NW6.5SP8. Все ресурсы успешно прижились на оставшейся ноде. Кластер переведен в Maintenance mode, рухнувший сервер отключен от SAN. Главная реплика осталась на живом сервере.
Предполагаемые действия: Удалить узел из кластера, затем удалить RW-реплику рухнувшего сервера... или наоборот? Я так полагаю, что если удалю сначала узел из кластера, eDir захочет провести синхронизацию, что невозможно по причине, отсутствия сервера, несущего RW-реплику.
Получается вначале надо удалить через dsrepair -a реплику отсутствующего сервера, затем узел из кластера, а затем через C1 прибить объекты оставшиеся от сервера. Я прав?
Спасибо.

[Константин Ошмян]

Предполагаемые действия: [...]
Получается вначале надо удалить через dsrepair -a реплику отсутствующего сервера, затем узел из кластера, а затем через C1 прибить объекты оставшиеся от сервера.

Я бы делал именно так. Т.е. сначала - забота о eDirectory, потом - всё остальное.

[Дмитрий Иванов]

Спасибо! Так все и сделал. Пока все хорошо - ошибок в eDir нет. Следующим шагом будет инсталляция нового сервера и внедрение его в кластер.

[Константин Ошмян]

Успехов!

Добавление сервера в существующий кластер проходит достаточно спокойно (см. выше мои замечания). Только надо обратить внимание на NB! - можно по неосторожности на это наступить.