Перейти к содержанию

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

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

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

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

Внимание

Настоятельно рекомендуется на время переключения ролей контроллеров приостановить выполнение задач по расписанию, отключить функционал DRS, HA, а также отключить репликацию для ВМ. В случае, если в системе имеются дополнительные механизмы или внешние системы, способные приводить к изменениям в БД контроллера, необходимо приостановить или отключить их на время переключения ролей.


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

После выполнения требований необходимо уточнить текущее состояние основного и резервного контроллеров. Для этого необходимо перейти в 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 согласно инструкции, приведенной в разделе Резервное копирование БД контроллера.


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

Примечание

Приведенные ниже рекомендации применимы для ВМ и шаблонов ВМ.

Уникальный идентификатор (UUID) диска можно узнать, перейдя во вкладку Хранилища - Диски - <Диск>. UUID приведен в верхнем левом углу окна подробной информации о диске.

В этом же окне указано известное системе и требуемое для корректной работы ВМ расположение диска, формируемое из двух полей: Пул данных и Расположение.

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

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

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

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

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

Пример 1
Диск и метаданные, по данным Web-интерфейса, расположены на общем пуле данных (NFS, CIFS, GFS2), а в реальности располагаются на базовом локальном пуле данных. В таком случае на узле, где были обнаружены файлы, через shell необходимо переместить их на общий пул данных с помощью команды:
mv /storages/local/default/${uuid}* /storages/common_pool/
где ${uuid} — уникальный идентификатор,
а common_pool — путь до общего пула данных, куда необходимо переместить файлы.
Пример 2
Диск и метаданные, по данным Web-интерфейса, расположены на базовом пуле данных узла №1, а в реальности располагаются на базовом локальном пуле данных узла №2. В таком случае необходимо переместить данные с одного узла на другой. Для этого необходимо в shell узла №1 ввести следующие команды:
scp /storages/local/default/${uuid}* root@${IP}:/storages/local/default/.TMP
ssh root@${IP} "cd /storages/local/default/ ; mv .TMP/${uuid}* ./"
где ${uuid} — уникальный идентификатор,
а ${IP} — IP-адрес целевого узла.

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