Перенос кластера - История изменений

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

2025-01-07T08:06:13Z

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

	Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близость и объем трафика), допустимости простоев и политик данных. Мы рекомендуем выполнять миграцию управляемых кластеров АппОптима одним из двух способов:		Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близость и объем трафика), допустимости простоев и политик данных. Мы рекомендуем выполнять миграцию управляемых кластеров АппОптима одним из двух способов:

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

2024-12-25T20:47:46Z

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

	=== Перенести кластер с помощью репликации ===		=== Перенести кластер с помощью репликации ===
	Чтобы выполнить миграцию узлов АппОптима ~~Managed~~ с помощью метода репликации:		Чтобы выполнить миграцию узлов АппОптима с помощью метода репликации:

	1. Настройте целевые узлы и всю необходимую сеть.		1. Настройте целевые узлы и всю необходимую сеть.
Строка 67:		Строка 67:
	* См. Какие сетевые порты использует АппОптима Server?		* См. Какие сетевые порты использует АппОптима Server?

	2. Добавляйте новые узлы АппОптима ~~Managed~~ в целевой кластер по одному.		2. Добавляйте новые узлы АппОптима в целевой кластер по одному.

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

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

2024-11-08T13:50:45Z

← Предыдущая версия		Версия от 13:50, 8 ноября 2024
Строка 1:		Строка 1:
	Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близость и объем трафика), допустимости простоев и политик данных. Мы рекомендуем выполнять миграцию управляемых кластеров ~~Ключ-АСТРОМ~~ одним из двух способов:		Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близость и объем трафика), допустимости простоев и политик данных. Мы рекомендуем выполнять миграцию управляемых кластеров АппОптима одним из двух способов:

	Используйте процедуры резервного копирования и восстановления кластера		Используйте процедуры резервного копирования и восстановления кластера
Строка 23:		Строка 23:

	=== Перенести кластер с помощью резервного копирования и восстановления ===		=== Перенести кластер с помощью резервного копирования и восстановления ===
	Чтобы перенести управляемые узлы ~~Ключ-АСТРОМ~~ с помощью метода резервного копирования и восстановления:		Чтобы перенести управляемые узлы АппОптима с помощью метода резервного копирования и восстановления:

	1. Настройте целевые узлы и всю необходимую сеть в целевом развертывании.		1. Настройте целевые узлы и всю необходимую сеть в целевом развертывании.
Строка 30:		Строка 30:
	* Для типичного сценария предполагается, что количество целевых узлов равно или превышает количество исходных узлов.		* Для типичного сценария предполагается, что количество целевых узлов равно или превышает количество исходных узлов.

	2. Создайте резервную копию текущего управляемого кластера ~~Ключ-АСТРОМ~~.		2. Создайте резервную копию текущего управляемого кластера АппОптима.

	* См. раздел Резервное копирование кластера		* См. раздел Резервное копирование кластера

	3. Остановите текущий управляемый кластер ~~Ключ-АСТРОМ~~.		3. Остановите текущий управляемый кластер АппОптима.

	4. Выполните восстановление из резервной копии в целевой управляемый кластер ~~Ключ-АСТРОМ~~.		4. Выполните восстановление из резервной копии в целевой управляемый кластер АппОптима.

	* См. Восстановление кластера		* См. Восстановление кластера
Строка 59:		Строка 59:

	=== Перенести кластер с помощью репликации ===		=== Перенести кластер с помощью репликации ===
	Чтобы выполнить миграцию узлов ~~Ключ-АСТРОМ~~ Managed с помощью метода репликации:		Чтобы выполнить миграцию узлов АппОптима Managed с помощью метода репликации:

	1. Настройте целевые узлы и всю необходимую сеть.		1. Настройте целевые узлы и всю необходимую сеть.
Строка 65:		Строка 65:
	Для типичного сценария предполагается, что количество целевых узлов по крайней мере равно количеству исходных узлов. Убедитесь, что целевые узлы соответствуют требованиям к оборудованию и что существует неограниченное соединение между вашим текущим кластером и целевым кластером. Все порты, открытые в текущем кластере, также должны быть открыты в целевом кластере.		Для типичного сценария предполагается, что количество целевых узлов по крайней мере равно количеству исходных узлов. Убедитесь, что целевые узлы соответствуют требованиям к оборудованию и что существует неограниченное соединение между вашим текущим кластером и целевым кластером. Все порты, открытые в текущем кластере, также должны быть открыты в целевом кластере.

	* См. Какие сетевые порты использует ~~Ключ-АСТРОМ~~ Server?		* См. Какие сетевые порты использует АппОптима Server?

	2. Добавляйте новые узлы ~~Ключ-АСТРОМ~~ Managed в целевой кластер по одному.		2. Добавляйте новые узлы АппОптима Managed в целевой кластер по одному.

	Перед добавлением еще одного узла убедитесь, что все существующие узлы кластера исправны и доступны. Если выполняется миграция нескольких узлов, убедитесь, что новый узел полностью запущен, прежде чем переходить к следующему.		Перед добавлением еще одного узла убедитесь, что все существующие узлы кластера исправны и доступны. Если выполняется миграция нескольких узлов, убедитесь, что новый узел полностью запущен, прежде чем переходить к следующему.
Строка 104:		Строка 104:

	Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.		Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.
	----<blockquote>~~Ключ-АСТРОМ~~ не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.</blockquote>		----<blockquote>АппОптима не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.</blockquote>

Lobanov: /* Перенести кластер с помощью резервного копирования и восстановления */

2022-03-15T17:31:46Z

Перенести кластер с помощью резервного копирования и восстановления

← Предыдущая версия		Версия от 17:31, 15 марта 2022
Строка 34:		Строка 34:
	* См. раздел Резервное копирование кластера		* См. раздел Резервное копирование кластера

	3. Остановите текущий управляемый кластер Ключ-АСТРОМ. Как пользователь root войдите в систему Linux, на которой установлены узлы Ключ-АСТРОМ Managed, и выполните команду <code>{main-script}.sh</code> с параметром <code>stop</code>. По умолчанию сценарий находится в <code>/opt/<managed-dir>/launcher</code>.		3. Остановите текущий управляемый кластер Ключ-АСТРОМ.

	~~<code>[root@localhost]# {main-script}.sh stop</code>~~

	4. Выполните восстановление из резервной копии в целевой управляемый кластер Ключ-АСТРОМ.		4. Выполните восстановление из резервной копии в целевой управляемый кластер Ключ-АСТРОМ.

Lobanov: /* Перенести кластер с помощью резервного копирования и восстановления */

2022-03-15T17:31:25Z

Перенести кластер с помощью резервного копирования и восстановления

← Предыдущая версия		Версия от 17:31, 15 марта 2022
Строка 34:		Строка 34:
	* См. раздел Резервное копирование кластера		* См. раздел Резервное копирование кластера

	3. Остановите текущий управляемый кластер Ключ-АСТРОМ. Как пользователь root войдите в систему Linux, на которой установлены узлы Ключ-АСТРОМ Managed, и выполните команду <code>~~dynatrace~~.sh</code> с параметром <code>stop</code>. По умолчанию сценарий находится в <code>/opt/~~dynatrace~~-~~managed~~/launcher</code>.		3. Остановите текущий управляемый кластер Ключ-АСТРОМ. Как пользователь root войдите в систему Linux, на которой установлены узлы Ключ-АСТРОМ Managed, и выполните команду <code>{main-script}.sh</code> с параметром <code>stop</code>. По умолчанию сценарий находится в <code>/opt/<managed-dir>/launcher</code>.

	<code>[root@localhost]# ~~dynatrace~~.sh stop</code>		<code>[root@localhost]# {main-script}.sh stop</code>

	4. Выполните восстановление из резервной копии в целевой управляемый кластер Ключ-АСТРОМ.		4. Выполните восстановление из резервной копии в целевой управляемый кластер Ключ-АСТРОМ.

YaPolkin в 02:23, 6 декабря 2021

2021-12-06T02:23:25Z

YaPolkin: Новая страница: «Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близ...»

2021-12-06T02:22:30Z

Новая страница: «Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близ...»

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

Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близость и объем трафика), допустимости простоев и политик данных. Мы рекомендуем выполнять миграцию управляемых кластеров Ключ-АСТРОМ одним из двух способов:

Используйте процедуры резервного копирования и восстановления кластера

Используйте встроенный механизм репликации узлов

У каждого метода есть преимущества и недостатки, описанные ниже.

== Метод резервного копирования ==
Этот вариант включает в себя резервное копирование исходного кластера, перенос данных резервного копирования и восстановление данных в целевой кластер.

Прежде чем выбрать этот вариант миграции, примите во внимание следующее:

'''Преимущества'''

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

'''Недостатки'''

* Мониторинг будет недоступен с момента начала резервного копирования кластера до завершения восстановления кластера на целевом кластере.
* По умолчанию резервное копирование Cassandra выполняется ежедневно, поэтому точка восстановления кластера будет последней выполненной резервной копией, что потенциально может привести к резервному копированию данных на срок до 24 часов. Вы можете запланировать миграцию ближе к времени резервного копирования, чтобы минимизировать потерю данных, однако, учитывая время, необходимое для переноса данных вручную и восстановления нового кластера, всегда будет некоторая потеря данных.
* Поскольку хранилище транзакций (данные PurePath со стандартным сроком хранения 10 дней) не включается в резервную копию, данные хранилища транзакций теряются при этом методе миграции.

=== Перенести кластер с помощью резервного копирования и восстановления ===
Чтобы перенести управляемые узлы Ключ-АСТРОМ с помощью метода резервного копирования и восстановления:

1. Настройте целевые узлы и всю необходимую сеть в целевом развертывании.

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

2. Создайте резервную копию текущего управляемого кластера Dynatrace.

* См. раздел Резервное копирование кластера

3. Остановите текущий управляемый кластер Dynatrace. Как пользователь root войдите в систему Linux, на которой установлены узлы Dynatrace Managed, и выполните команду <code>dynatrace.sh</code> с параметром <code>stop</code>. По умолчанию сценарий находится в <code>/opt/dynatrace-managed/launcher</code>.

<code>[root@localhost]# dynatrace.sh stop</code>

4. Выполните восстановление из резервной копии в целевой управляемый кластер Dynatrace.

* См. Восстановление кластера

== Метод репликации ==
Метод репликации гарантирует непрерывность мониторинга во время миграции. Вы временно расширяете кластер, добавляя новые узлы, ждете, пока данные автоматически реплицируются на новые узлы, и после завершения репликации удаляете старые узлы по одному.
----<blockquote><big>''Перенести в другой дата-центр''</big>

Репликационный метод миграции возможен, даже если целевые узлы находятся в другом центре обработки данных. Это может быть выполнено в центрах обработки данных в непосредственной близости с временем RTT между узлами не более 10 мс и достаточной пропускной способностью между центрами обработки данных.

В сценариях центров обработки данных, где нет прямой связи между центрами обработки данных, используйте VPN для связи между центрами обработки данных.

Поскольку кластеру требуется постоянное межузловое соединение, сетевая связь между центрами обработки данных должна быть стабильной и безопасной. Имейте в виду, что трафик внутри кластеров (т. Е. Между узлами) не зашифрован. В результате для трафика между центрами обработки данных требуется зашифрованное соединение, например, с использованием VPN.</blockquote>
----'''Преимущества'''

* Без простоев и без потери данных.

'''Недостатки'''

* Метод репликации хорошо работает только для развертываний с низкой задержкой или низким трафиком.
* Приблизительное время репликации, включая перенаправление данных и ожидание истечения срока действия нереплицированных данных хранилища транзакций, обычно составляет 10 дней.

=== Перенести кластер с помощью репликации ===
Чтобы выполнить миграцию узлов Dynatrace Managed с помощью метода репликации:

1. Настройте целевые узлы и всю необходимую сеть.

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

* См. Какие сетевые порты использует Dynatrace Server?

2. Добавляйте новые узлы Dynatrace Managed в целевой кластер по одному.

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

3. Отключите трафик OneAgent на исходных узлах, но продолжайте их работу до завершения репликации данных и до истечения срока хранения нереплицированных данных в хранилище транзакций.

Чтобы проверить прогресс репликации данных только на новом узле, выполните <code>cassandra-nodetool.sh</code> с параметром <code>status</code>:

<big>'''[Скачать]'''</big> '''<big>[Скопировать в буфер обмена]</big>'''

<code>sudo $DT_DIR/utils/cassandra-nodetool.sh status</code>

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

<code>Datacenter: datacenter1</code>

<code>===============Status=Up/Down</code>

<code>/ State=Normal/Leaving/Joining/Moving</code>

<code>– Address Load Tokens Owns (effective) Host ID Rack</code>

<code>UN 10.176.41.167 18.82 GB 256 100.0% 3af25127-4f99-4f43-afc3-216d7a2c10f8 rack1</code>

<code>UN 10.176.41.154 19.44 GB 256 100.0% 5a618559-3a73-42ec-83f0-32d28e08beec rack1</code>

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

[[Файл:Managednodejoining.webp|альт=Соединение нод Managed]]
----<blockquote>''<big>Хранение транзакций</big>''

*

Отключение узла фактически переводит хранилище транзакций в режим только для чтения, но узел по-прежнему может обрабатывать запросы.</blockquote>
----4. Удаляйте исходные узлы по одному.

Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.
----<blockquote>Dynatrace не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.</blockquote>

← Предыдущая версия		Версия от 02:23, 6 декабря 2021
Строка 30:		Строка 30:
	* Для типичного сценария предполагается, что количество целевых узлов равно или превышает количество исходных узлов.		* Для типичного сценария предполагается, что количество целевых узлов равно или превышает количество исходных узлов.

	2. Создайте резервную копию текущего управляемого кластера ~~Dynatrace~~.		2. Создайте резервную копию текущего управляемого кластера Ключ-АСТРОМ.

	* См. раздел Резервное копирование кластера		* См. раздел Резервное копирование кластера

	3. Остановите текущий управляемый кластер ~~Dynatrace~~. Как пользователь root войдите в систему Linux, на которой установлены узлы ~~Dynatrace~~ Managed, и выполните команду <code>dynatrace.sh</code> с параметром <code>stop</code>. По умолчанию сценарий находится в <code>/opt/dynatrace-managed/launcher</code>.		3. Остановите текущий управляемый кластер Ключ-АСТРОМ. Как пользователь root войдите в систему Linux, на которой установлены узлы Ключ-АСТРОМ Managed, и выполните команду <code>dynatrace.sh</code> с параметром <code>stop</code>. По умолчанию сценарий находится в <code>/opt/dynatrace-managed/launcher</code>.

	<code>[root@localhost]# dynatrace.sh stop</code>		<code>[root@localhost]# dynatrace.sh stop</code>

	4. Выполните восстановление из резервной копии в целевой управляемый кластер ~~Dynatrace~~.		4. Выполните восстановление из резервной копии в целевой управляемый кластер Ключ-АСТРОМ.

	* См. Восстановление кластера		* См. Восстановление кластера
Строка 61:		Строка 61:

	=== Перенести кластер с помощью репликации ===		=== Перенести кластер с помощью репликации ===
	Чтобы выполнить миграцию узлов ~~Dynatrace~~ Managed с помощью метода репликации:		Чтобы выполнить миграцию узлов Ключ-АСТРОМ Managed с помощью метода репликации:

	1. Настройте целевые узлы и всю необходимую сеть.		1. Настройте целевые узлы и всю необходимую сеть.
Строка 67:		Строка 67:
	Для типичного сценария предполагается, что количество целевых узлов по крайней мере равно количеству исходных узлов. Убедитесь, что целевые узлы соответствуют требованиям к оборудованию и что существует неограниченное соединение между вашим текущим кластером и целевым кластером. Все порты, открытые в текущем кластере, также должны быть открыты в целевом кластере.		Для типичного сценария предполагается, что количество целевых узлов по крайней мере равно количеству исходных узлов. Убедитесь, что целевые узлы соответствуют требованиям к оборудованию и что существует неограниченное соединение между вашим текущим кластером и целевым кластером. Все порты, открытые в текущем кластере, также должны быть открыты в целевом кластере.

	* См. Какие сетевые порты использует ~~Dynatrace~~ Server?		* См. Какие сетевые порты использует Ключ-АСТРОМ Server?

	2. Добавляйте новые узлы ~~Dynatrace~~ Managed в целевой кластер по одному.		2. Добавляйте новые узлы Ключ-АСТРОМ Managed в целевой кластер по одному.

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

	3. Отключите трафик ~~OneAgent~~ на исходных узлах, но продолжайте их работу до завершения репликации данных и до истечения срока хранения нереплицированных данных в хранилище транзакций.		3. Отключите трафик ЕдиногоАгента на исходных узлах, но продолжайте их работу до завершения репликации данных и до истечения срока хранения нереплицированных данных в хранилище транзакций.

	Чтобы проверить прогресс репликации данных только на новом узле, выполните <code>cassandra-nodetool.sh</code> с параметром <code>status</code>:		Чтобы проверить прогресс репликации данных только на новом узле, выполните <code>cassandra-nodetool.sh</code> с параметром <code>status</code>:
Строка 106:		Строка 106:

	Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.		Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.
	----<blockquote>~~Dynatrace~~ не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.</blockquote>		----<blockquote>Ключ-АСТРОМ не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.</blockquote>