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

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

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

[[Файл:Man-conversion-ra.webp|альт=Процесс преобразования Managed кластера в кластер с учетом стойки.]]

== Подготовка ==

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

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

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

Где <code><managed-installation-dir></code> - это каталог управляемых двоичных файлов Ключ-АСТРОМ, а <code><node-IP></code> - это IP-адрес текущего узла (узел, который вы используете в данный момент).

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

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

<code>[cqlsh 5.0.1 | Cassandra 3.0.23 | CQL spec 3.4.0 | Native protocol v4]</code>

<code>Use HELP for help.                                                 </code> 

<code>cqlsh></code>

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

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

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

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

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

<code>CASSANDRA_NODE_RACK = rack1</code>

<code>CASSANDRA_NODE_RACK_DC = datacenter1  </code>

<code>ELASTICSEARCH_NODE_RACK = rack1</code>

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

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

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

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

== Расширение кластера на новые стойки ==
Во время первоначального развертывания Ключ-АСТРОМ Managed все узлы кластера по умолчанию сгруппированы в единую стойку по умолчанию, размещенную в центре обработки данных по умолчанию. Даже если ваше развертывание не поддерживает стойки, все узлы уже находятся в  <code>datacenter1</code> <code>rack1</code>. Чтобы избежать добавления нового узла в стойку по умолчанию, не используйте <code>rack1</code> в качестве значения параметра <code>--rack-name</code> для новой стойки.

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

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

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

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

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

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

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

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

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

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

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

[[Файл:Cmcstatus.webp|альт=Страница состояния развертывания CMC кластера с учетом стойки]]