Преобразование с использованием репликации с учетом стойки

Материал из Dynatrace

Этот метод полезен для небольших управляемых кластеров Dynatrace, где один узел может содержать полную реплику. Если ваше текущее хранилище метрик (база данных Cassandra) на узел превышает 1 ТБ, используйте метод восстановления кластера. Вы можете использовать существующие узлы для постепенной (один за другим) их переустановки с параметром «поддержка стойки». При желании вы можете использовать дополнительное оборудование в качестве новых узлов и удалить один узел при установке нового узла с параметром «поддержка стойки».

Преимущество этого подхода заключается в том, что он не влияет на доступность кластера, однако для поддержания доступности кластера необходимо разрешить управляемому кластеру использовать собственные методы репликации для обеспечения сохранения данных. Следует учитывать, что удаление и добавление узла в кластер требует времени. Это время зависит от размера вашего метрического хранилища и скорости вашего диска или сети. Некоторые операции с кластером могут занять даже один-два дня. Управляемый кластер предотвратит все другие операции кластера в течение этого времени (добавление и удаление узлов, обновление и резервное копирование). Если вы решили выполнить переустановку на существующем хосте, подождите 72 часа, прежде чем повторно подключать этот хост к кластеру.

Процесс преобразования Managed кластера в кластер с учетом стойки.

Подготовка

  • Подготовьте базу данных Cassandra для распространения реплик по кластеру (требуется Python 2.7).

На одном из существующих узлов измените пространство клавиш, чтобы изменить настройки снитча, используя Cassandra CQL:

sudo <managed-installation-dir>/cassandra/bin/cqlsh <node_IP>

Где <managed-installation-dir> - это каталог управляемых двоичных файлов Dynatrace, а <node-IP> - это IP-адрес текущего узла (узел, который вы используете в данный момент).

В результате вы попадете в оболочку CQL:

Connected to 00aa0a0a-1ab1-11a1-aaa1-0a0a0aa1a1aa at xx.xxx.xx.xxx:9042.

[cqlsh 5.0.1 | Cassandra 3.0.23 | CQL spec 3.4.0 | Native protocol v4]

Use HELP for help.                                                 

cqlsh>

Затем выполните:

ALTER KEYSPACE ruxitdb WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'datacenter1':3};

Когда закончите, введите: exit

  • Подготовьте кластер для добавления узлов в разные стойки.

На каждом из существующих узлов отредактируйте /etc/<conf-name>.conf и настройте следующие параметры:

CASSANDRA_NODE_RACK = rack1

CASSANDRA_NODE_RACK_DC = datacenter1  

ELASTICSEARCH_NODE_RACK = rack1

Выполните sudo reconfigure.sh , чтобы применить изменения конфигурации для узла кластера.

  • Подготовьте новую(ые) ноду(ы).

Убедитесь, что раздел диска, выделенный для хранилища Cassandra на новом узле, достаточен для размещения всей базы данных Cassandra (с запасом для сжатия и новых данных). Размер диска должен быть как минимум вдвое больше объединенных хранилищ Cassandra всех существующих узлов кластера. Рекомендуется размещать данные Cassandra на отдельном томе, чтобы избежать проблем с дисковым пространством, связанных с различными типами данных.

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

Расширение кластера на новые стойки

Во время первоначального развертывания Dynatrace Managed все узлы кластера по умолчанию сгруппированы в единую стойку по умолчанию, размещенную в центре обработки данных по умолчанию. Даже если ваше развертывание не поддерживает стойки, все узлы уже находятся в datacenter1 rack1. Чтобы избежать добавления нового узла в стойку по умолчанию, не используйте rack1 в качестве значения параметра --rack-name для новой стойки.

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

Расширить кластер на новые стойки

1. Добавьте в кластер новый узел с параметрами стойки.

Используйте процедуру Добавить новый узел кластера и добавьте параметры --rack-name и --rack-dc к команде установки. Например:

/bin/sh <managed-installer-name>.sh --seed-auth abcdefjhij1234567890 --rack-name rack2 --rack-dc datacenter1

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


Подсказка

Если узел испытывает трудности с поддержанием загрузки данных, вы можете временно остановить процесс сервера Dynatrace на этом узле и освободить больше циклов ЦП для Cassandra.


2. Добавьте еще один узел в ту же стойку с такими же параметрами стойки.

На этот раз ожидается, что загрузка Cassandra будет быстрее.

3. Продолжайте добавлять новые узлы в rack2. Как только у вас будет достаточное количество узлов в rack2 (1/3 размера целевого кластера), начните добавлять новые узлы с параметрами стойки в rack3 , учитывая требования к дисковому пространству.

4. Как только у вас будет достаточное количество узлов в стойке rack3 , начните удаление исходных узлов, которые были настроены без поддержки стойки (расположены в стойке по умолчанию rack1).

Когда преобразование будет завершено, вы увидите стойки на странице состояния развертывания в консоли управления кластером:

Страница состояния развертывания CMC кластера с учетом стойки