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

IKuznetsov в 08:27, 7 января 2025

2025-01-07T08:27:12Z

← Предыдущая версия		Версия от 08:27, 7 января 2025
Строка 1:		Строка 1:
			'''''[[Установка и настройка]] / [[Установка и настройка\|Основные элементы АппОптима]] / [[АппОптима]] / [[АппОптима\|Эксплуатация]] / ВысокаяДоступность - репликация нод между дата-центрами'''''

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

IKuznetsov в 18:17, 2 января 2025

2025-01-02T18:17:09Z

← Предыдущая версия		Версия от 18:17, 2 января 2025
Строка 37:		Строка 37:
	* <code><nodes-ips></code> - Список адресов IPV4 новых узлов в '''DC-2'''. Например, <code>"176.16.0.5", "176.16.0.6", "176.16.0.7"</code>		* <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><api-token></code> - Действительный токен Cluster API (требуется область действия ServiceProviderAPI). Вы можете сгенерировать его в консоли управления управляемым кластером АппОптима.
	* <code><~~AstromKey~~-directory></code> - Каталог, в котором установлен АппОптима на начальном узле. Каталог управляемой установки АппОптима по умолчанию располагается в директории: <code>/opt/~~AstromKey~~-АппОптима</code>		* <code><AppOptima-directory></code> - Каталог, в котором установлен АппОптима на начальном узле. Каталог управляемой установки АппОптима по умолчанию располагается в директории: <code>/opt/AppOptima-АппОптима</code>
	* <code><datacenter-1></code> - Имя '''DC-1''' должно совпадать с именем ЦОД Cassandra. Имя ЦОД Cassandra по умолчанию: <code>datacenter1</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><datacenter-2></code> - Имя '''DC-2''' может быть любой строкой, которая начинается и заканчивается буквенно-цифровым символом и не длиннее 80 символов. В имени разрешены символы подчеркивания и тире. Например, <code>dc-us-east-2</code>.
Строка 43:		Строка 43:
	=== Получение название дата-центра ===		=== Получение название дата-центра ===
	Чтобы получить имя контроллера домена, выполните эту команду '''на начальном узле''' перед началом миграции:		Чтобы получить имя контроллера домена, выполните эту команду '''на начальном узле''' перед началом миграции:
	<code>sudo <~~AstromKey~~-directory>/utils/cassandra-nodetool.sh status</code>		<code>sudo <AppOptima-directory>/utils/cassandra-nodetool.sh status</code>
	Вы получите ответ, содержащий имя '''DC-1'''. Пример для контроллера домена с названием <code>datacenter1</code>:		Вы получите ответ, содержащий имя '''DC-1'''. Пример для контроллера домена с названием <code>datacenter1</code>:
	<Datacenter: datacenter1		<Datacenter: datacenter1
Строка 57:		Строка 57:
	Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в '''DC-1''' и '''DC-2'''.		Чтобы упростить многочисленные вызовы REST API во время развертывания, задайте переменные среды на каждом узле в '''DC-1''' и '''DC-2'''.
	<SEED_IP=<seed-ip>		<SEED_IP=<seed-ip>
	DT_DIR=<~~AstromKey~~-directory>		DT_DIR=<AppOptima-directory>
	NODES_IPS=$(echo '[<nodes-ips]')		NODES_IPS=$(echo '[<nodes-ips]')
	API_TOKEN=<api-token>		API_TOKEN=<api-token>
Строка 64:		Строка 64:
	Например,		Например,
	<SEED_IP=10.176.37.201		<SEED_IP=10.176.37.201
	DT_DIR=/opt/~~AstromKey~~-АппОптима		DT_DIR=/opt/AppOptima-АппОптима
	NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')		NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')
	API_TOKEN=R_SZOpV4RTOmjr9fFmK4x		API_TOKEN=R_SZOpV4RTOmjr9fFmK4x

IKuznetsov в 10:16, 26 декабря 2024

2024-12-26T10:16:40Z

← Предыдущая версия		Версия от 10:16, 26 декабря 2024
Строка 19:		Строка 19:
	* В кластере '''DC-1''' необходимо отключить резервное копирование перед началом процедуры миграции. Мы рекомендуем создать новую резервную копию кластера и отключить резервную копию кластера незадолго до развертывания дополнительного центра обработки данных.		* В кластере '''DC-1''' необходимо отключить резервное копирование перед началом процедуры миграции. Мы рекомендуем создать новую резервную копию кластера и отключить резервную копию кластера незадолго до развертывания дополнительного центра обработки данных.
	* Миграция не должна занимать более четырех недель. Если ваша миграция продлится более четырех недель, свяжитесь с командой АппОптима .		* Миграция не должна занимать более четырех недель. Если ваша миграция продлится более четырех недель, свяжитесь с командой АппОптима .
	* Перед началом процедуры миграции необходимо отключить автоматическое обновление кластера '''DC-1'''. Кластер нельзя обновлять во время миграции. См. [[Обновление АппОптима ~~Managed~~\|Автоматическое обновление]]. Свяжитесь с командой АппОптима, если опция автоматического обновления отключена.		* Перед началом процедуры миграции необходимо отключить автоматическое обновление кластера '''DC-1'''. Кластер нельзя обновлять во время миграции. См. [[Обновление АппОптима\|Автоматическое обновление]]. Свяжитесь с командой АппОптима, если опция автоматического обновления отключена.
	* Убедитесь, что машины подготовлены для кластера в '''DC-2'''. Поскольку '''DC-2''' будет реплицировать данные '''DC-1''', мы рекомендуем назначить такое же количество узлов с тем же оборудованием, включая дисковое хранилище. Все узлы в '''DC-1''' и '''DC-2''' должны быть синхронизированы по времени. Этого можно добиться, настроив сетевой протокол времени (NTP).		* Убедитесь, что машины подготовлены для кластера в '''DC-2'''. Поскольку '''DC-2''' будет реплицировать данные '''DC-1''', мы рекомендуем назначить такое же количество узлов с тем же оборудованием, включая дисковое хранилище. Все узлы в '''DC-1''' и '''DC-2''' должны быть синхронизированы по времени. Этого можно добиться, настроив сетевой протокол времени (NTP).

IKuznetsov в 20:56, 25 декабря 2024

2024-12-25T20:56:44Z

← Предыдущая версия		Версия от 20:56, 25 декабря 2024
Строка 3:		Строка 3:


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

	В этой статье применяются следующие термины:		В этой статье применяются следующие термины:
Строка 11:		Строка 11:
	* '''Начальный узел''' — любой узел в DC-1, который будет использоваться для выполнения задач установки и распространения конфигурации.		* '''Начальный узел''' — любой узел в DC-1, который будет использоваться для выполнения задач установки и распространения конфигурации.

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

	== Требования ==		== Требования ==
Строка 37:		Строка 37:
	* <code><nodes-ips></code> - Список адресов IPV4 новых узлов в '''DC-2'''. Например, <code>"176.16.0.5", "176.16.0.6", "176.16.0.7"</code>		* <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><api-token></code> - Действительный токен Cluster API (требуется область действия ServiceProviderAPI). Вы можете сгенерировать его в консоли управления управляемым кластером АппОптима.
	* <code><AstromKey-directory></code> - Каталог, в котором установлен АппОптима ~~Managed~~ на начальном узле. Каталог управляемой установки АппОптима по умолчанию располагается в директории: <code>/opt/AstromKey-~~managed~~</code>		* <code><AstromKey-directory></code> - Каталог, в котором установлен АппОптима на начальном узле. Каталог управляемой установки АппОптима по умолчанию располагается в директории: <code>/opt/AstromKey-АппОптима</code>
	* <code><datacenter-1></code> - Имя '''DC-1''' должно совпадать с именем ЦОД Cassandra. Имя ЦОД Cassandra по умолчанию: <code>datacenter1</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><datacenter-2></code> - Имя '''DC-2''' может быть любой строкой, которая начинается и заканчивается буквенно-цифровым символом и не длиннее 80 символов. В имени разрешены символы подчеркивания и тире. Например, <code>dc-us-east-2</code>.
Строка 52:		Строка 52:
	UN 10.176.42.20 65.54 GB 256 100.0% f053dd8d-ecf3-7834-b099-68542439817b rack1		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.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>~~		UN 10.176.42.168 65.47 GB 256 100.0% 48543bca-41f5-26d3-b2fd-6cfdf5c0f3b2 rack1

	=== Установка переменных ===		=== Установка переменных ===
Строка 61:		Строка 61:
	API_TOKEN=<api-token>		API_TOKEN=<api-token>
	DC1_NAME=<datacenter-1>		DC1_NAME=<datacenter-1>
	DC2_NAME=<datacenter-2~~></code~~>		DC2_NAME=<datacenter-2>
	Например,		Например,
	<SEED_IP=10.176.37.201		<SEED_IP=10.176.37.201
	DT_DIR=/opt/AstromKey-~~managed~~		DT_DIR=/opt/AstromKey-АппОптима
	NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')		NODES_IPS=$(echo '["10.176.37.218", "10.176.37.227", "10.176.37.120"]')
	API_TOKEN=R_SZOpV4RTOmjr9fFmK4x		API_TOKEN=R_SZOpV4RTOmjr9fFmK4x
	DC1_NAME=datacenter1		DC1_NAME=datacenter1
	DC2_NAME=dc-us-east-2~~</code>~~		DC2_NAME=dc-us-east-2

	=== Проверка дополнительных настроек ===		=== Проверка дополнительных настроек ===
Строка 127:		Строка 127:
	=== Установка нод в DC-2 ===		=== Установка нод в DC-2 ===
	Выполните следующую команду на каждом узле в '''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>		<code>sudo /bin/sh ./АппОптима-installer.sh --install-new-dc --premium-ha on --datacenter $DC2_NAME --seed-auth $API_TOKEN</code>
	Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким:		Эта операция должна занять от 3 до 5 минут, а ожидаемый результат должен быть примерно таким:
	<code>Installation in new data center completed successfully after 2 minutes 51 seconds.</code>		<code>Installation in new data center completed successfully after 2 minutes 51 seconds.</code>
Строка 193:		Строка 193:
	UN 10.176.42.54 19.18 GB 256 100.0% 852ce236-a430-400a-92a6-daeed99acf68 rack1		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.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>~~		UN 10.176.42.234 19.4 GB 256 100.0% 507b377c-5bfc-4667-b251-a9b7c453ed22 rack1
	Значение '''нагрузки''' не должно существенно различаться между узлами, а '''состояние''' должно быть <code>UN</code> на всех узлах.		Значение '''нагрузки''' не должно существенно различаться между узлами, а '''состояние''' должно быть <code>UN</code> на всех узлах.

IKuznetsov в 13:55, 8 ноября 2024

2024-11-08T13:55:14Z

Внесённые изменения

ENetrebin в 18:40, 24 апреля 2024

2024-04-24T18:40:46Z

← Предыдущая версия		Версия от 18:40, 24 апреля 2024
Строка 1:		Строка 1:
			'''ВНИМАНИЕ, ИНФОРМАЦИЯ НА ДАННОЙ СТРАНИЦЕ УСТАРЕЛА'''


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

RGolovanov: /* Скопируйте установщик */

2022-09-16T14:32:16Z

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

← Предыдущая версия		Версия от 14:32, 16 сентября 2022
Строка 79:		Строка 79:
	<code>sudo nohup $DT_DIR/installer/reconfigure.sh --only els --premium-ha on &</code>		<code>sudo nohup $DT_DIR/installer/reconfigure.sh --only els --premium-ha on &</code>

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

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

	==== Проверка ~~статус~~ подготовки кластера ====		==== Проверка статуса подготовки кластера ====
	Выполните следующий вызов API кластера '''только на начальном узле''':		Выполните следующий вызов 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>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>

RGolovanov в 14:31, 16 сентября 2022

2022-09-16T14:31:47Z

Внесённые изменения

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

2022-09-16T14:28:39Z

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

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

Для развертывания ВысокойДоступности необходим избыточный набор узлов в исходном развертывании кластера. Такие развертывания ВысокойДоступности охватывают несколько центров обработки данных. Ключ-Астром 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>