Ручное переключение ролей контроллеров

Общая информация

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

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

Определение готовности системы к переключению

После выполнения требований необходимо уточнить текущее состояние основного и резервного контроллеров. Для этого необходимо перейти в CLI основного контроллера и выполнить команду:

node nodes-cli "controller status"

В случае, если в системе какой-либо контроллер установлен в режиме Controller (только контроллер), для уточнения его текущего статуса необходимо выполнить на нем команду:

controller status

На момент переключения на основном контроллере должны быть установлены следующие статусы:

• Статус инициализации работы с резервным контроллером.

  Status: Initialized for remote controller: ${IP_slave}.

  где ${IP_slave} — IP-адрес резервного контроллера.

• Состояние.

  State: active.

• Текущий статус узла.

  Current node status: master.

• Текущее состояние репликации БД.

  Postgresql replication process: active.

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

Роль основного контроллера — master.
Роль резервного контроллер — slave.

Кроме этого, на резервном контроллере в информации о текущем состоянии должна присутствовать строка задержки синхронизации (Postgres lag) со значением 0.

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

• Роли БД (pg_role) должны совпадать с текущей ролью контроллера.

• Размер БД (Pg_database_size) на основном и резервном контроллерах должен быть одинаковым.

Информация о времени, прошедшем с последней транзакции в секундах (Pg_last_xact_replay) и временная метка последней транзакции в БД (Pg_last_xact_replay date) дают информацию об актуальности записей в БД на соответствующем контроллере. Чем ближе Pg_last_xact_replay к нулю, а Pg_last_xact_replay date — к текущему времени, тем более вероятно, что при переключении ролей контроллеров работа системы не будет нарушена.

Переключение ролей

Перевод контроллера в режим резервного выполняется с помощью команды CLI:

controller role slave

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

controller status

В поле Current node status должно быть значение slave.

Затем необходимо перейти в CLI второго контроллера и проверить его состояние на данный момент, выполнив команду:

controller status

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

Если же оба контроллера имеют роль slave, необходимо перевести второй контроллер в режим основного с помощью команды:

controller role master

В случае возникновения необходимости ручной установки роли второму контроллеру необходимо убедиться, что инициализация связанности обоих контроллеров проведена (Initialized for remote controller) и активна. При отсутствии связанности требуется выполнить инициализацию повторно согласно указаниям в разделе Инициализация связанности.

Восстановление исходного состояния системы из резервной копии

Восстановление БД

В случае, если после переключения ролей контроллеров возникли ошибки в работе системы SpaceVM, необходимо переключить роли контроллеров обратно и выполнить восстановление БД контроллера из CLI согласно инструкции, приведенной в разделе Резервное копирование БД контроллера.

Восстановление ВМ

Если после восстановления БД ВМ не запускается и в журнале задач обнаруживается ошибка, связанная с недоступностью диска на пуле данных, необходимо выполнить процедуру поиска диска (.qcow2) и метаданных (.meta) по UUID.

Скопировав UUID диска, необходимо перейти в shell имеющихся узлов и выполнить на них поиск файлов по маске UUID с помощью команды:

find /storages -iname "${uuid}*"

где ${uuid} — идентификатор диска, скопированный в окне подробной информации о диске.

Данную процедуру необходимо произвести на всех узлах, пока файл не будет найден. После обнаружения файла в системе необходимо сравнить путь до этих файлов и его расположение на узлах с указанным в подробной информации о диске. Если данные расходятся, необходимо привести их в соответствие с информацией, указанной в Web-интерфейсе. Данная процедура выполняется с помощью команд shell узла, где были обнаружены файлы .qcow2 и .meta.

mv /storages/local/default/${uuid}* /storages/common_pool/

scp /storages/local/default/${uuid}* root@${IP}:/storages/local/default/.TMP

ssh root@${IP} "cd /storages/local/default/ ; mv .TMP/${uuid}* ./"

Проведя вышеописанные операции с необходимыми дисками и восстановив таким образом состояние системы, можно продолжать работу.