Варианты миграции кластера зависят от деталей вашей среды развертывания (задержка, близость и объем трафика), допустимости простоев и политик данных. Мы рекомендуем выполнять миграцию управляемых кластеров АппОптима одним из двух способов:
Используйте процедуры резервного копирования и восстановления кластера
Используйте встроенный механизм репликации узлов
У каждого метода есть преимущества и недостатки, описанные ниже.
Метод резервного копирования
Этот вариант включает в себя резервное копирование исходного кластера, перенос данных резервного копирования и восстановление данных в целевой кластер.
Прежде чем выбрать этот вариант миграции, примите во внимание следующее:
Преимущества
- Поскольку вы вручную переносите данные кластера в целевой кластер, задержка в вашем развертывании не влияет на этот процесс. Мы рекомендуем этот тип миграции для развертываний с большой задержкой.
Недостатки
- Мониторинг будет недоступен с момента начала резервного копирования кластера до завершения восстановления кластера на целевом кластере.
- По умолчанию резервное копирование Cassandra выполняется ежедневно, поэтому точка восстановления кластера будет последней выполненной резервной копией, что потенциально может привести к резервному копированию данных на срок до 24 часов. Вы можете запланировать миграцию ближе к времени резервного копирования, чтобы минимизировать потерю данных, однако, учитывая время, необходимое для переноса данных вручную и восстановления нового кластера, всегда будет некоторая потеря данных.
- Поскольку хранилище транзакций (данные PurePath со стандартным сроком хранения 10 дней) не включается в резервную копию, данные хранилища транзакций теряются при этом методе миграции.
Перенести кластер с помощью резервного копирования и восстановления
Чтобы перенести управляемые узлы АппОптима с помощью метода резервного копирования и восстановления:
1. Настройте целевые узлы и всю необходимую сеть в целевом развертывании.
- Убедитесь, что целевые узлы соответствуют требованиям к оборудованию.
- Для типичного сценария предполагается, что количество целевых узлов равно или превышает количество исходных узлов.
2. Создайте резервную копию текущего управляемого кластера АппОптима.
- См. раздел Резервное копирование кластера
3. Остановите текущий управляемый кластер АппОптима.
4. Выполните восстановление из резервной копии в целевой управляемый кластер АппОптима.
- См. Восстановление кластера
Метод репликации
Метод репликации гарантирует непрерывность мониторинга во время миграции. Вы временно расширяете кластер, добавляя новые узлы, ждете, пока данные автоматически реплицируются на новые узлы, и после завершения репликации удаляете старые узлы по одному.
Перенести в другой дата-центр
Репликационный метод миграции возможен, даже если целевые узлы находятся в другом центре обработки данных. Это может быть выполнено в центрах обработки данных в непосредственной близости с временем RTT между узлами не более 10 мс и достаточной пропускной способностью между центрами обработки данных.
В сценариях центров обработки данных, где нет прямой связи между центрами обработки данных, используйте VPN для связи между центрами обработки данных.
Поскольку кластеру требуется постоянное межузловое соединение, сетевая связь между центрами обработки данных должна быть стабильной и безопасной. Имейте в виду, что трафик внутри кластеров (т. Е. Между узлами) не зашифрован. В результате для трафика между центрами обработки данных требуется зашифрованное соединение, например, с использованием VPN.
Преимущества
- Без простоев и без потери данных.
Недостатки
- Метод репликации хорошо работает только для развертываний с низкой задержкой или низким трафиком.
- Приблизительное время репликации, включая перенаправление данных и ожидание истечения срока действия нереплицированных данных хранилища транзакций, обычно составляет 10 дней.
Перенести кластер с помощью репликации
Чтобы выполнить миграцию узлов АппОптима с помощью метода репликации:
1. Настройте целевые узлы и всю необходимую сеть.
Для типичного сценария предполагается, что количество целевых узлов по крайней мере равно количеству исходных узлов. Убедитесь, что целевые узлы соответствуют требованиям к оборудованию и что существует неограниченное соединение между вашим текущим кластером и целевым кластером. Все порты, открытые в текущем кластере, также должны быть открыты в целевом кластере.
- См. Какие сетевые порты использует АппОптима Server?
2. Добавляйте новые узлы АппОптима в целевой кластер по одному.
Перед добавлением еще одного узла убедитесь, что все существующие узлы кластера исправны и доступны. Если выполняется миграция нескольких узлов, убедитесь, что новый узел полностью запущен, прежде чем переходить к следующему.
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.
Хранение транзакций
Отключение узла фактически переводит хранилище транзакций в режим только для чтения, но узел по-прежнему может обрабатывать запросы.
4. Удаляйте исходные узлы по одному.
Рекомендуется отложить удаление исходного (старого) узла до тех пор, пока не истечет срок хранения нереплицированных данных хранилища транзакций. Хранение этих данных можно настроить, но обычно оно хранится в течение 10 дней.
АппОптима не позволит вам удалить несколько узлов одновременно, поэтому перед удалением каждого последующего узла убедитесь, что данные были повторно распределены. Перенаправление данных обычно занимает пару часов в зависимости от объема данных и пропускной способности между узлами. В крайнем случае это может занять пару дней.