ВысокаяДоступность — восстановление дата-центра через резервную копию: различия между версиями

Материал из Документация Ключ-АСТРОМ
(Новая страница: «В данной восстановительной процедуре следующие термины обозначаются следующим образом...»)
 
 
(не показаны 2 промежуточные версии 1 участника)
Строка 1: Строка 1:
'''ВНИМАНИЕ, ИНФОРМАЦИЯ НА ДАННОЙ СТРАНИЦЕ УСТАРЕЛА'''
В данной восстановительной процедуре следующие термины обозначаются следующим образом:
В данной восстановительной процедуре следующие термины обозначаются следующим образом:


Строка 51: Строка 54:
==Установка==
==Установка==


=== Удаление Ключ-Астром Managed на всех работающих узлах. ===
Следуйте официальной процедуре удаления узла кластера с помощью командной строки или консоли управления кластером. См. [[Удаление ноды кластера]].
=== Восстановление ЦОД из резервной копии ===
Следуйте официальной процедуре восстановления центра обработки данных из резервной копии. См. [[Резервное копирование и восстановление кластера]].
=== Удаление потерянного дата-центра из конфигурации ===
=== Удаление потерянного дата-центра из конфигурации ===
Выполните следующий вызов API кластера '''только на начальном узле''':
Выполните следующий вызов API кластера '''только на начальном узле''':

Текущая версия на 18:41, 24 апреля 2024

ВНИМАНИЕ, ИНФОРМАЦИЯ НА ДАННОЙ СТРАНИЦЕ УСТАРЕЛА


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

  • DC-1 - Исходный (уцелевший) ЦОД, в котором расположен кластер.
  • DC-2 - Целевой (утерянный) центр обработки данных, предназначенный для восстановления.
  • Начальный узел - Любой узел в Исходном-DC , который будет использоваться для выполнения задач установки и распространения конфигурации.

Процедура включает миграцию и миграцию управляемых компонентов по отдельности, чтобы они были готовы к миграции данных между двумя центрами обработки данных. См. Компоненты Managed.

Подготовка

Убедитесь, что ваша система соответствует указанным требованиям к оборудованию и операционной системе.

Сбор информации

Команды будут использовать эти переменные при выполнении вызовов REST API. Для этого вам понадобится следующая информация:

  • <seed-node-ip> - IP-адрес начального узла от DC-1. Это может быть любой узел, работающий в существующем центре обработки данных, который будет использоваться для выполнения задач установки и распространения конфигурации.
  • <nodes-ips> - Список адресов IPV4 новых узлов в DC-2. Например, "176.16.0.5", "176.16.0.6", "176.16.0.7"
  • <api-token> - Действительный токен Cluster API (требуется область действия ServiceProviderAPI). Вы можете сгенерировать его в консоли управления управляемым кластером Ключ-Астром.
  • <AstromKey-directory> - Каталог, в котором установлен Ключ-Астром Managed на начальном узле. Каталог управляемой установки Ключ-Астром по умолчанию располагается в директории: /opt/AstromKey-managed
  • <datacenter-1> - Имя DC-1 должно совпадать с именем ЦОД Cassandra. Имя ЦОД Cassandra по умолчанию: datacenter1.
  • <datacenter-2> - Имя DC-2 может быть любой строкой, которая начинается и заканчивается буквенно-цифровым символом и не длиннее 80 символов. В имени разрешены символы подчеркивания и тире. Например, dc-us-east-2.

Получение название дата-центра

Чтобы получить имя контроллера домена, выполните эту команду на начальном узле перед началом миграции: 

sudo <AstromKey-directory>/utils/cassandra-nodetool.sh status

Вы получите ответ, содержащий имя DC-1. Пример для контроллера домена с названием datacenter1: 

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.176.42.20   65.54 GB   256          100.0%            f053dd8d-ecf3-7834-b099-68542439817b  rack1
UN  10.176.42.244  65.47 GB   256          100.0%            2aa7e790-a423-9273-88f9-45bcd158dd6e  rack1
UN  10.176.42.168  65.47 GB   256          100.0%            48543bca-41f5-26d3-b2fd-6cfdf5c0f3b2  rack1

Установка переменных

Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в DC-1 и DC-2. 

SEED_IP=<seed-ip>
DT_DIR=<AstromKey-directory>
NODES_IPS=$(echo '[<nodes-ips]')
API_TOKEN=<api-token>
SDC_NAME=<datacenter-1>
TDC_NAME=<datacenter-2>

Например, 

SEED_IP=10.176.37.201
DT_DIR=/opt/AstromKey-managed
NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')
API_TOKEN=R_SZOpV4RTOmjr9fFmK4x
SDC_NAME=datacenter1
TDC_NAME=dc-us-east-2

Проверка дополнительных настроек

Если ваш кластер Cassandra или Elasticsearch настроен с custom.settings которые включают поддержку стойки, свяжитесь с командой Ключ-Астром, чтобы применить эти пользовательские настройки, прежде чем продолжить установку DC-2.

Чтобы проверить, применяются ли пользовательские настройки, выполните на начальном узле: 

ls $DT_DIR/installer/custom.settings

Если файл custom.settings существует, вы используете пользовательские настройки.

Установка

Удаление Ключ-Астром Managed на всех работающих узлах.

Следуйте официальной процедуре удаления узла кластера с помощью командной строки или консоли управления кластером. См. Удаление ноды кластера.

Восстановление ЦОД из резервной копии

Следуйте официальной процедуре восстановления центра обработки данных из резервной копии. См. Резервное копирование и восстановление кластера.

Удаление потерянного дата-центра из конфигурации

Выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/lostDatacenterCleanUp?Api-Token=$API_TOKEN -H  "accept: application/json" -H  "Content-Type: application/json"

Если код состояния не равен 200 и в ответе не предлагаются следующие шаги, свяжитесь с командой Ключ-Астром.

Копирование установщика

На этом шаге вы скопируете установщик узла на каждый узел в DC-2.

  1. Войти в Консоль Менеджмента Кластера.
  2. В меню выберите Домашняя страница.
  3. Щелкните Добавить новый узел кластера.
  4. Скопируйте командную строку wget из текстового поля Выполнить эту команду на целевом хосте. Важно! Не запускайте скрипт установки.
  5. Вставьте и выполните wget в окне терминала.

Подготовка данных кластера для миграции

Выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clustermigratePreparation?Api-Token=$API_TOKEN

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Ключ-Астром.

Проверка статуса подготовки кластера

Выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clustermigratePreparation?Api-Token=$API_TOKEN -H  "accept: application/json"

Если код состояния этого звонка не равен 200, повторите попытку через несколько минут.

Создание топологии центра обработки данных

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

Выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST -d "{\"newDatacenterName\" : \"$DC2_NAME\", \"nodesIp\" :$NODES_IPS}" https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/datacenterTopology?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Ключ-Астром.

Открытие правил брандмауэра

Открытие портов

Чтобы открыть порты для трафика с новых узлов DC-2, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST -d "$NODES_IPS" https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

В случае успеха код состояния будет 200, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния правил брандмауэра.

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Ключ-Астром.

Подтверждение правил брандмауэра

Установите переменную среды идентификатора запроса только на начальном узле. Идентификатор запроса берется из ответа в предыдущем вызове API. 

REQ_ID=<topology-configuration-request-id>

Чтобы проверить состояние правил брандмауэра, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc/$REQ_ID?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния этого звонка не равен 200, повторите попытку через несколько минут.

Установка нод в Целевой-DC

Выполните следующую команду на каждом узле в DC-2. Следуйте инструкциям на экране, так как это будет обычная установка узла. 

sudo /bin/sh ./managed-installer.sh --install-new-dc --premium-ha on --datacenter $DC2_NAME --seed-auth $API_TOKEN

Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким: 

Installation in new data center completed successfully after 2 minutes 51 seconds.

Проверка Nodekeeper в DC-2

Выполните следующий вызов API кластера только на начальном узле, когда все узлы в DC-2 закончат установку: 

curl -ikS https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/nodekeeper/healthCheck?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку через несколько минут.

Миграция Cassandra

На этом шаге вы перенастроите Cassandra в DC-1 и DC-2 для миграции между центрами обработки данных, инициируете синхронизацию данных, перестроите данные Cassandra и проверите состояние Cassandra.

Это может занять от нескольких минут до нескольких часов, в зависимости от размера хранилища метрик.

Миграция Cassandra в DC-1

Чтобы запустить миграцию Cassandra в центре обработки данных DC-1, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

В случае успеха код состояния будет 200, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса только на начальном узле. Идентификатор запроса берется из ответа в предыдущем вызове API. 

REQ_ID=<migration-old-datacenter-request-id>

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

Проверка статуса миграции

Чтобы проверить состояние миграции, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc/$REQ_ID?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку через несколько минут.

Миграция Cassandra в DC-2

Чтобы запустить миграцию Cassandra в центре обработки данных DC-2, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

В случае успеха код состояния будет 200, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса только на начальном узле. Идентификатор запроса берется из ответа в предыдущем вызове API. 

REQ_ID=<migration-new-datacenter-request-id>

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

Проверка статуса миграции

Чтобы проверить состояние миграции, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc/$REQ_ID?Api-Token=$API_TOKEN -H  "accept: application/json" -H  "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку через несколько минут.

Восстановление данных Cassandra

Чтобы перестроить Cassandra, последовательно выполните следующую команду на каждом новом узле DC-2. Используйте команду nohup, чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций. 

sudo nohup $DT_DIR/utils/cassandra-nodetool.sh rebuild -- $DC1_NAME &
Проверка прогресса и статуса

Чтобы проверить ход выполнения и статус, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/rebuildStatus?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку примерно через 15 минут. Помните, что процесс восстановления может занять много времени.

Проверка состояния Кассандры

Чтобы проверить состояние кластера Cassandra, выполните cassandra-nodetool.sh с параметром состояния только на начальном узле: 

sudo $DT_DIR/utils/cassandra-nodetool.sh status

Результат должен выглядеть примерно так: 

Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.176.41.167  18.82 GB   256          100.0%            3af25127-4f99-4f43-afc3-216d7a2c10f8  rack1
UN  10.176.41.154  19.44 GB   256          100.0%            5a618559-3a73-42ec-83f0-32d28e08beec  rack1
UN  10.176.41.43   19.58 GB   256          100.0%            191f3b30-949a-4cf2-b620-68a40eebf31e  rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.176.42.54   19.18 GB   256          100.0%            852ce236-a430-400a-92a6-daeed99acf68  rack1
UN  10.176.42.104  19.12 GB   256          100.0%            84479219-b64d-442c-a807-a832db9aae18  rack1
UN  10.176.42.234  19.4 GB    256          100.0%            507b377c-5bfc-4667-b251-a9b7c453ed22  rack1

Значение нагрузки не должно существенно различаться между узлами, а состояние должно быть UN на всех узлах.

Миграция Elasticsearch

Чтобы запустить миграцию Elasticsearch в центр обработки данных DC-2, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

В случае успеха код состояния будет 200, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния миграции. Установите переменную среды идентификатора запроса только на начальном узле. Идентификатор запроса берется из ответа в предыдущем вызове API. 

REQ_ID=<migration-elasticsearch-request-id>

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

Проверка прогресса и статуса

Чтобы проверить состояние миграции Elasticsearch, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/restore/elasticsearch/recover/$REQ_ID?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку через несколько минут.

Проверка миграции данных

Чтобы проверить миграцию миграции данных Elasticsearch, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/indexMigrationStatus?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку через несколько минут.

Перенос сервера

Запустите управляемый кластер Ключ-Астром в DC-2, выполнив следующий вызов API кластера только на начальном узле: 

curl -ikS -X POST https://$SEED_IP/api/v1.0/onpremise/multiDc/restore/server/recovery?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

В случае успеха код состояния будет 200, а тело ответа будет содержать идентификатор запроса, необходимый для проверки готовности кластера. Установите переменную среды идентификатора запроса только на начальном узле. Идентификатор запроса берется из ответа в предыдущем вызове API. 

REQ_ID=<migration-server-request-id>

Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

Проверить готовность кластера

Чтобы проверить, готов ли кластер, выполните следующий вызов API кластера только на начальном узле: 

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server/$REQ_ID?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

Если код состояния не равен 200, повторите попытку через несколько минут.

Включение нового дата-центра

  1. Включите трафик ЕдиногоАгента.
  2. Включите резервное копирование в центрах обработки данных. Ваша резервная копия отключена после переноса.
Источник — https://doc.ruscomtech.ru/index.php?title=ВысокаяДоступность_—_восстановление_дата-центра_через_резервную_копию&oldid=3448