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

2022-09-16T15:00:28Z

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

Новая страница

В данной восстановительной процедуре следующие термины обозначаются следующим образом:
*'''DC-1''' - Исходный (уцелевший) ЦОД, в котором расположен кластер.
*'''DC-2''' - Целевой (утерянный) центр обработки данных, предназначенный для восстановления.
*'''Начальный узел''' - Любой узел в '''Исходном-DC''' , который будет использоваться для выполнения задач установки и распространения конфигурации.
Процедура включает миграцию и миграцию управляемых компонентов по отдельности, чтобы они были готовы к миграции данных между двумя центрами обработки данных. См. [https://doc.ruscomtech.ru/index.php/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D1%8B_Managed Компоненты Managed].
==Подготовка==
Убедитесь, что ваша система соответствует указанным требованиям к оборудованию и операционной системе.
===Сбор информации===
Команды будут использовать эти переменные при выполнении вызовов 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>
SDC_NAME=<datacenter-1>
TDC_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
SDC_NAME=datacenter1
TDC_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> существует, вы используете пользовательские настройки.
==Установка==

=== Коды ответов API ===
Каждый из вызовов REST API будет возвращать код HTTP. Переходите к следующему шагу, только если возвращаемый код равен <code>200</code>. Все коды возврата:

<code>200</code> - переходите к следующему шагу, текущий шаг выполнен успешно.

<code>207</code> - Запрос обрабатывается, повторите шаг через несколько минут.

<code>40x</code> - Измените путь и аргументы запроса и повторите запрос..

<code>5xx</code> - Свяжитесь с поддержкой.

=== Остановка работы недоступного дата-центра ===
Остановите все необходимые службы Ключ-Астром Managed в рекомендованном порядке. См. раздел [[Запуск/остановка/перезапуск кластера]].

=== Удаление узлов ===

# Перейдите в Консоль Менеджмента Кластера.
# Для каждого узла в недоступном центре обработки данных перейдите на страницу сведений об узле и удалите узел..

Дополнительные сведения о других способах удаления узла см. в разделе [[Удаление ноды кластера]].

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

ВысокаяДоступность — переустановка дата-центра - История изменений

YaPolkin в 20:52, 26 января 2023

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