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

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

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

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

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

== Требования ==

* Лицензия Высокая Доступность. См. [[Расчет потребления мониторинга]]. 
* Версия кластера '''DC-1''' должна быть 1.222+. 
* В кластере '''DC-1''' необходимо отключить резервное копирование перед началом процедуры миграции. Мы рекомендуем создать новую резервную копию кластера и отключить резервную копию кластера незадолго до развертывания дополнительного центра обработки данных. 
* Миграция не должна занимать более четырех недель. Если ваша миграция продлится более четырех недель, свяжитесь с командой Ключ-Астром . 
* Перед началом процедуры миграции необходимо отключить автоматическое обновление кластера '''DC-1'''. Кластер нельзя обновлять во время миграции. См. [[Обновление Ключ-АСТРОМ Managed|Автоматическое обновление]]. Свяжитесь с командой Ключ-Астром, если опция автоматического обновления отключена. 
* Убедитесь, что машины подготовлены для кластера в '''DC-2'''. Поскольку '''DC-2''' будет реплицировать данные '''DC-1''', мы рекомендуем назначить такое же количество узлов с тем же оборудованием, включая дисковое хранилище. Все узлы в '''DC-1''' и '''DC-2''' должны быть синхронизированы по времени. Этого можно добиться, настроив сетевой протокол времени (NTP).

* Для развертывания ВысокойДоступности требуется как минимум три узла в '''DC-1''' и три соответствующих узла в '''DC-2'''. 
* Убедитесь, что все узлы в обоих центрах обработки данных могут взаимодействовать друг с другом. Чтобы проверить, доступен ли узел в '''DC-1''' с хоста в '''DC-2''', вы можете выполнить вызов REST для проверки работоспособности. Например, выполните следующую команду с хоста в '''DC-2''':

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

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

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

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

=== Получение название дата-центра ===
Чтобы получить имя контроллера домена, выполните эту команду '''на начальном узле''' перед началом миграции:
 <code>sudo <AstromKey-directory>/utils/cassandra-nodetool.sh status</code>
Вы получите ответ, содержащий имя '''DC-1'''. Пример для контроллера домена с названием <code>datacenter1</code>:
 <code>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</code>

=== Установка переменных ===
Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в '''DC-1''' и '''DC-2'''.
 <code>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></code>
Например,
 <code>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</code>

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

Чтобы проверить, применяются ли пользовательские настройки, выполните '''на начальном узле''':
 <code>ls $DT_DIR/installer/custom.settings</code>
Если файл <code>custom.settings</code> существует, вы используете пользовательские настройки.

== Установка ==

=== Обновление Elasticsearch ===
Обновите Elasticsearch до нужной версии. Последовательно выполните следующую команду на каждом существующем узле '''DC-1''':
 <code>sudo nohup $DT_DIR/installer/reconfigure.sh --only els --premium-ha on &</code>

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

# Войти в '''Консоль Менеджмента Кластера'''.
# В меню выберите '''Домашняя страница'''.
# Щелкните '''Добавить новый узел кластера'''.
# Скопируйте командную строку <code>wget</code> из текстового поля '''Выполнить эту команду на целевом хосте'''. ''Важно! Не запускайте скрипт установки''.
# Вставьте и выполните <code>wget</code> в окне терминала.

=== Подготовка данных кластера для репликации ===
Выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterReplicationPreparation?Api-Token=$API_TOKEN</nowiki></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с командой Ключ-Астром.

==== Проверка статуса подготовки кластера ====
Выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterReplicationPreparation?Api-Token=$API_TOKEN</nowiki> -H  "accept: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.

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

Выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST -d "{\"newDatacenterName\" : \"$DC2_NAME\", \"nodesIp\" :$NODES_IPS}" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/datacenterTopology?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не 200 и ответ не предлагает дальнейших действий, свяжитесь с командой Ключ-Астром.

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

==== Открытие портов ====
Чтобы открыть порты для трафика с новых узлов '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST -d "$NODES_IPS" <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния правил брандмауэра. 

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

==== Подтверждение правил брандмауэра ====
Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
 <code>REQ_ID=<topology-configuration-request-id></code>
Чтобы проверить состояние правил брандмауэра, выполните следующий вызов API кластера '''только на начальном узле:'''
 <code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/clusterNodes/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния этого звонка не равен <code>200</code>, повторите попытку через несколько минут.

=== Установка нод в DC-2 ===
Выполните следующую команду на каждом узле в '''DC-2'''. Следуйте инструкциям на экране, так как это будет обычная установка узла.
 <code>sudo /bin/sh ./managed-installer.sh --install-new-dc --premium-ha on --datacenter $DC2_NAME --seed-auth $API_TOKEN</code>
Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким:
 <code>Installation in new data center completed successfully after 2 minutes 51 seconds.</code>

==== Проверка Nodekeeper в DC-2 ====
Выполните следующий вызов API кластера '''только на начальном узле''', когда все узлы в '''DC-2''' закончат установку:
 <code>curl -ikS <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/nodekeeper/healthCheck?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

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

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

==== Репликация Cassandra в DC-1 ====
Чтобы запустить репликацию Cassandra в центре обработки данных '''DC-1''', выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния репликации. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
 <code>REQ_ID=<replication-old-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

==== Проверка статуса репликации ====
Чтобы проверить состояние репликации, выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/currentDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

==== Репликация Cassandra в DC-2 ====
Чтобы запустить репликацию Cassandra в центре обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния репликации. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
 <code>REQ_ID=<replication-new-datacenter-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

==== Проверка статуса репликации ====
Чтобы проверить состояние репликации, выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/newDc/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H  "accept: application/json" -H  "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

==== Восстановление данных Cassandra ====
Чтобы перестроить Cassandra, последовательно выполните следующую команду на каждом новом узле '''DC-2'''. Используйте команду nohup, чтобы предотвратить прерывание выполнения сценария (например, отключение сеанса) во время важных операций.
 <code>sudo nohup $DT_DIR/utils/cassandra-nodetool.sh rebuild -- $DC1_NAME &</code>

===== Проверка прогресса и статуса =====
Чтобы проверить ход выполнения и статус, выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/cassandra/rebuildStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку примерно через 15 минут. Помните, что процесс восстановления может занять много времени.

==== Проверка состояния Кассандры ====
Чтобы проверить состояние кластера Cassandra, выполните <code>cassandra-nodetool.sh</code> с параметром состояния '''только на начальном узле''':
 <code>sudo $DT_DIR/utils/cassandra-nodetool.sh status</code>
Результат должен выглядеть примерно так:
 <code>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</code>
Значение '''нагрузки''' не должно существенно различаться между узлами, а '''состояние''' должно быть <code>UN</code> на всех узлах.

=== Репликация Elasticsearch ===
Чтобы запустить репликацию Elasticsearch в центр обработки данных '''DC-2''', выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки состояния репликации. Установите переменную среды идентификатора запроса '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
 <code>REQ_ID=<replication-elasticsearch-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

==== Проверка прогресса и статуса ====
Чтобы проверить состояние репликации Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

==== Проверка репликации данных ====
Чтобы проверить репликацию репликации данных Elasticsearch, выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/elasticsearch/indexMigrationStatus?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

=== Перенос сервера ===
Запустите управляемый кластер Ключ-Астром в '''DC-2''', выполнив следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X POST <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
В случае успеха код состояния будет <code>200</code>, а тело ответа будет содержать идентификатор запроса, необходимый для проверки готовности кластера. Установите '''переменную среды идентификатора запроса''' '''только на начальном узле'''. Идентификатор запроса берется из ответа в предыдущем вызове API.
 <code>REQ_ID=<replication-server-request-id></code>
Если код состояния не <code>200</code> и ответ не предлагает дальнейших действий, свяжитесь с Ключ-Астром.

==== Проверить готовность кластера ====
Чтобы проверить, готов ли кластер, выполните следующий вызов API кластера '''только на начальном узле''':
 <code>curl -ikS -X GET <nowiki>https://$SEED_IP/api/v1.0/onpremise/multiDc/migration/server/$REQ_ID?Api-Token=$API_TOKEN</nowiki> -H "accept: application/json" -H "Content-Type: application/json"</code>
Если код состояния не равен <code>200</code>, повторите попытку через несколько минут.

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

# Включите трафик ЕдиногоАгента.
# Включите резервное копирование в центрах обработки данных. Ваша резервная копия отключена после переноса.

=== Реконфигурация DC-1 ===
Выполните следующую команду последовательно на каждом узле только в '''DC-1'''.
 <code>sudo nohup $DT_DIR/installer/reconfigure.sh &</code>