Перенос кластера: различия между версиями

Материал из Dynatrace
(Новая страница: «Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близ...»)
 
Строка 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>

Версия 02:23, 6 декабря 2021

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

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

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

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

Метод резервного копирования

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

[root@localhost]# dynatrace.sh stop

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

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

Метод репликации

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


Перенести в другой дата-центр

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

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

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


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

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

Недостатки

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

Перенести кластер с помощью репликации

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

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

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

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

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

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

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

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

[Скачать] [Скопировать в буфер обмена]

sudo $DT_DIR/utils/cassandra-nodetool.sh status

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

Datacenter: datacenter1

===============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.

Соединение нод Managed


Хранение транзакций

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


4. Удаляйте исходные узлы по одному.

Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.


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