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

Материал из Документация Ключ-АСТРОМ

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

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

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

Подготовка

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

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

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

Где <managed-installation-dir> - это каталог управляемых двоичных файлов Ключ-АСТРОМ, а <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 на отдельном томе, чтобы избежать проблем с дисковым пространством, связанных с различными типами данных.

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

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

Во время первоначального развертывания Ключ-АСТРОМ 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 может занять несколько дней.

Подсказка

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

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

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

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

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

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

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

Источник — https://doc.ruscomtech.ru/index.php?title=Преобразование_с_использованием_репликации_с_учетом_стойки&oldid=911