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

Материал из Документация Ключ-АСТРОМ
Версия от 14:28, 16 сентября 2022; RGolovanov (обсуждение | вклад) (Новая страница: «Для развертывания ВысокойДоступности необходим избыточный набор узлов в исходном разв...»)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

Для развертывания ВысокойДоступности необходим избыточный набор узлов в исходном развертывании кластера. Такие развертывания ВысокойДоступности охватывают несколько центров обработки данных. Ключ-Астром Managed позволяет добавлять зеркальные узлы, расположенные в другом центре обработки данных.

В этой статье применяются следующие термины:

  • DC-1 — центр обработки данных, в котором расположен исходный управляемый кластер.
  • DC-2 — дополнительный центр обработки данных, предназначенный для развертывания Ключ-Астром ВысокаяДоступность.
  • Начальный узел — любой узел в DC-1, который будет использоваться для выполнения задач установки и распространения конфигурации.

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

Требования

  • Лицензия Высокая Доступность. См. Расчет потребления мониторинга.
  • Версия кластера DC-1 должна быть 1.222+.
  • В кластере DC-1 необходимо отключить резервное копирование перед началом процедуры миграции. Мы рекомендуем создать новую резервную копию кластера и отключить резервную копию кластера незадолго до развертывания дополнительного центра обработки данных.
  • Миграция не должна занимать более четырех недель. Если ваша миграция продлится более четырех недель, свяжитесь с командой Ключ-Астром .
  • Перед началом процедуры миграции необходимо отключить автоматическое обновление кластера DC-1. Кластер нельзя обновлять во время миграции. См. Автоматическое обновление. Свяжитесь с командой Ключ-Астром, если опция автоматического обновления отключена.
  • Убедитесь, что машины подготовлены для кластера в DC-2. Поскольку DC-2 будет реплицировать данные DC-1, мы рекомендуем назначить такое же количество узлов с тем же оборудованием, включая дисковое хранилище. Все узлы в DC-1 и DC-2 должны быть синхронизированы по времени. Этого можно добиться, настроив сетевой протокол времени (NTP).
  • Для развертывания ВысокойДоступности требуется как минимум три узла в DC-1 и три соответствующих узла в DC-2.
  • Убедитесь, что все узлы в обоих центрах обработки данных могут взаимодействовать друг с другом. Чтобы проверить, доступен ли узел в DC-1 с хоста в DC-2, вы можете выполнить вызов REST для проверки работоспособности. Например, выполните следующую команду с хоста в DC-2:
curl -k https://<DC-1-node-IP>/rest/health

где <DC-1-node-IP> — IP-адрес любого узла в DC-1. Вы должны получить «RUNNING» в ответ, если соединение может быть установлено успешно.

Подготовка

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

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

Команды будут использовать эти переменные при выполнении вызовов 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>
DC1_NAME=<datacenter-1>
DC2_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
DC1_NAME=datacenter1
DC2_NAME=dc-us-east-2

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

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

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

ls $DT_DIR/installer/custom.settings

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

Установка

Обновление Elasticsearch

Обновите Elasticsearch до нужной версии. Последовательно выполните следующую команду на каждом существующем узле DC-1: 

sudo nohup $DT_DIR/installer/reconfigure.sh --only els --premium-ha on &

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

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

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

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

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

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

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

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

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

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterReplicationPreparation?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-2

Выполните следующую команду на каждом узле в 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=<replication-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=<replication-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=<replication-elasticsearch-request-id>

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

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

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

curl -ikS -X GET https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/$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/migration/server?Api-Token=$API_TOKEN -H "accept: application/json" -H "Content-Type: application/json"

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

REQ_ID=<replication-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. Включите резервное копирование в центрах обработки данных. Ваша резервная копия отключена после переноса.

Реконфигурация DC-1

Выполните следующую команду последовательно на каждом узле только в DC-1. 

sudo nohup $DT_DIR/installer/reconfigure.sh &
Источник — https://doc.ruscomtech.ru/index.php?title=ВысокаяДоступность_—_репликация_нод_между_дата-центрами&oldid=1245