Три узла Cassandra кластера, все узлы настроены на разные стойки в одном и том же DC

Question

Я новичок ie в Кассандре. В нашей производственной среде три узла Cassandra работают и обслуживают производственный трафик c, но у меня есть следующие сомнения: -

1) Все узлы настроены в разных стойках, т.е. стойка 1, стойка 2 и стойка 3 в тот же д c. Это нормально или у этой конфигурации есть недостатки?

2) Мы используем rf2 и сетевую топологию для всех пространств клавиш, кроме системных таблиц, и эти системные таблицы настроены с использованием rf2 и simplestrategy. Это нормально или это нужно изменить? мы должны увеличить коэффициент репликации system_auth? ..пожалуйста, дайте мне знать ..

3) Теперь я хочу добавить еще один узел в тот же d c, что будет лучшим способом сделать то же самое, не влияя на живой трафик c? Кассандра версия Apache Кассандра 3.11.

Заранее спасибо ..

Answer 1

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

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

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

Ответ 1) Для одного кластера D C Cassandra рекомендуется иметь 4 узла с RF3. Стойка 1 с 2 узлами и Стойка 2 с 2 узлами. Помните, что узлы в одной стойке имеют более быструю сеть, чем узлы в разных стойках. С двумя узлами в одной стойке запросы с LOCAL_QUORUM будут быстрее по сравнению с запросами в кластере со всеми узлами в разных стойках.

Если вас не интересует задержка запроса, все узлы в разных стойках (3 стойки) обеспечат лучшее аварийное восстановление по сравнению с двумя развертываниями RACK. При этом всегда рекомендуется использовать несколько развертываний D C для производственного кластера.

Ответ 2) Всегда рекомендуется увеличивать коэффициент репликации пространства ключей System_auth и изменять класс репликации. Сетевой ТопологииСтратегии. Пожалуйста, следуйте этой документации для получения более подробной информации https://docs.datastax.com/en/security/6.0/security/secSystemKeyspace.html

Ответ 3) Да, вы можете легко добавить новый узел в существующий кластер, не влияя на трафик c. Пожалуйста, следуйте этой документации для более подробной информации: https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/operations/opsAddNodeToCluster.html

Answer 2

Ответ 1) Кажется, хорошо иметь узлы Cassandra в разных стойках для обеспечения доступности и отказоустойчивости. Ответ 2) Вы должны увеличить RF для system_auth, чтобы избежать проблем с входом cql sh с других узлов. Ответ 3) Вы можете добавить новый узел, не затрагивая живой трафик c в существующем кластере. Пожалуйста, следуйте приведенной ниже процедуре. http://cassandra.apache.org/doc/latest/operating/topo_changes.html