Несбалансированный кластер Кассандры

Обновление - Краткая версия:
PropertyFileSnitch cassandra-topology.properties для первых 3 узлов (стойки 1-3) указывает, что только эти узлы находятся в DC1, а остальные - в DC2. указав значение по умолчанию default=DC2:r1. Когда кластер был увеличен путем добавления узлов 4 и 5, PropertyFileSnitch для этих узлов был настроен на добавление их в DC1, а также в стойки 4 и 5, но снитч из первых 3 узлов остался неизменным и как в результате кластер находится в этом несогласованном состоянии.

Мой вопрос в том, можно ли перебалансировать (исправить) этот кластер. Было бы достаточно, если бы я выполнил полный перезапуск кластера после исправления cassandra-topology.properties?
Пожалуйста, посоветуйте, как я могу безопасно перебалансировать кластер.

Более длинная версия:

Я новичок в Cassandra, и я начал работать над уже созданным кластером.
У меня есть 5 узлов в одном центре обработки данных на разных стойках под управлением Cassandra версии 3.0.5 с vnodes num_tokens: 256 и пространством ключей с replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3'} AND durable_writes = true.
Раньше было всего 3 узла, и кластер был увеличен за счет дополнительных 2 узлов. У меня есть сценарий автоматического восстановления, который запускает nodetool repair с параметрами parallelism: parallel, primary range: false, incremental: true, job threads: 1.

После того, как был вставлен большой объем данных, начали появляться проблемы. При запуске сценария восстановления на узле 4 или 5 узел 2 перегружается: использование ЦП остается на уровне 100%, очередь MutationStage растет, а паузы сборщика мусора занимают не менее 1 секунды, пока процесс Cassandra окончательно не завершится. Результат ремонта обычно failed with error Stream failed (progress: 0%).

При запуске команды nodetool status на узлах 1, 2 или 3 я получаю следующий результат:

Datacenter: DC2
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens  Owns (effective)  Host ID    Rack
UN  10.0.0.13    10.68 GB   256     0.0%              75e17b8a   r1
UN  10.0.0.14    9.43 GB    256     0.0%              21678ddb   r1
Datacenter: DC1
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens  Owns (effective)  Host ID    Rack
UN  10.0.0.10    16.14 GB   256     100.0%            cf9d327f   Rack1
UN  10.0.0.11    22.83 GB   256     100.0%            e725441e   Rack2
UN  10.0.0.12    19.66 GB   256     100.0%            95b5c8e3   Rack3

Но при запуске команды nodetool status на узлах 4 или 5 я получаю следующий результат:

Datacenter: DC1
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens  Owns (effective)  Host ID    Rack
UN  10.0.0.13   10.68 GB   256     58.9%             75e17b8a   Rack4
UN  10.0.0.14   9.43 GB    256     61.1%             21678ddb   Rack5
UN  10.0.0.10   16.14 GB   256     60.3%             cf9d327f   Rack1
UN  10.0.0.11   22.83 GB   256     61.4%             e725441e   Rack2
UN  10.0.0.12   19.66 GB   256     58.3%             95b5c8e3   Rack3

После дальнейшего исследования выяснилось, что PropertyFileSnitch cassandra-topology.properties не обновлялся на узлах 1, 2 и 3 (которые также являются начальными значениями для этого кластера) после масштабирования кластера.

Спасибо!


cassandra nodetool cassandra-cli
person alien5    schedule 20.03.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

После поиска в нескольких интернет-ресурсах я нашел несколько возможных решений. Я выложу их здесь, чтобы они были доступны всем.

Из статьи Практическая Кассандра: подход разработчика:

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

То же решение можно найти также в документации DataStax: Вид кольца различается для некоторых узлов

Я также нашел аналогичный вопрос в сообществе Apache Cassandra. Ответ в ветке сообщества пользователей:

Произошло то, что теперь у вас есть два центра обработки данных в вашем кластере. То, как они копируют информацию, будет зависеть от настроек вашего пространства ключей. Что касается вашего процесса, я не думаю, что это безопасно. Я бы начал с вывода из эксплуатации узлов 4 и 5, чтобы ваш кластер вернулся к 1 центру обработки данных с 3 узлами, а затем снова добавил их последовательно, убедившись, что конфигурация в Snitch правильная.

person alien5    schedule 27.03.2017

arrow_upward
0
arrow_downward

Я не могу сказать, достаточно ли того, что вы предложили, без доступа к системе, но у меня есть несколько замечаний. Право собственности должно быть распределено между всеми узлами кластера. Это означает, что сумма всех значений на вкладке «Владеет» для всех 5 узлов должна быть равна 100, если они образуют один кластер. Неправильно иметь несколько узлов, владеющих 100% кластера. Это указывает на то, что каждый узел работает в автономном режиме и не присоединен к кластеру.
Я вижу адрес 10.40.0.10 в первой распечатке, а на второй - 10.0.0.10. Похоже на неправильную конфигурацию. Кроме того, проверьте, может ли каждый узел достичь IP-адресов всех остальных узлов. Я вижу, что 10.0.0.13 принадлежит «r1» в первой распечатке, а она принадлежит «Rack4» во второй.
Для простоты настройки вы можете настроить один центр обработки данных (например, DC1) и одну стойку (например, Rack1) для всех 5 узлов независимо от их физического распределения.

person Community    schedule 21.03.2017
comment
Вы правы, это неправильная конфигурация. Элемент PropertyFileSnitch cassandra-topology.properties для первых 3 узлов (стойки 1-3) указывает, что только эти узлы находятся в DC1, а остальные - в DC2, указав значение по умолчанию default=DC2:r1. Когда кластер был увеличен путем добавления узлов 4 и 5, PropertyFileSnitch для этих узлов был настроен на добавление их в DC1, а также в стойки 4 и 5, но снитч от первых 3 узлов остался неизменным и как в результате кластер находится в этом несогласованном состоянии. Я пытаюсь выяснить, как можно безопасно перенастроить его. - person alien5; 21.03.2017
comment
Спасибо, что указали на ошибку IP, она проскальзывала при форматировании ширины поста. Узлы находятся в одном центре обработки данных и имеют доступ друг к другу. Они могут видеть нагрузку друг друга, но нагрузка распределяется неравномерно из-за неправильно настроенного снитча. - person alien5; 21.03.2017