Архитектура кластера Кассандры?

Question

фона:

Мы создаем Cassandra кластер, который охватывает 3 географически разделенных Датацентры. Мы планируем иметь 2 узла Cassandra в каждом центре обработки данных (2 узла x 3 сайта = всего 6 узлов). Все 6 узлов будут частью одного и того же кластера.

Идея состоит в том, чтобы иметь возможность записывать данные на любой узел в кластере и читать их с любого другого узла. [Мы можем терпеть 1 секунду задержки обновлений].

Вопрос:

Как мы проектируем клиента, чтобы написать в «кластер». В Cassandra нет маршрутизатора или среднего слоя, такого как MongoDB. Мы проектируем так, чтобы мы писали любой узел в кольце? Если да, то какой этот узел опустился (т. Е. Нужно ли информировать нашего клиента обо всех IP-адресах узла в кластере?)

Спасибо.

Answer 1

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

Запись в любой центр обработки данных автоматически реплицируется во все другие датацентры, поэтому вы можете писать на любой узел и читать с любого узла. Как правило, вы хотите использовать уровень согласованности LOCAL_QUORUM для чтения и записи, что требует, чтобы кворум реплик в локальном центре обработки данных отвечал за то, что операция считается успешной. Вы также можете рассмотреть запись в EACH_QUORUM, которая ждет ответа от кворума реплик в каждом центре обработки данных. Очевидно, что в этом случае латентность будет намного выше, но вы можете добиться значительной согласованности во всех датацентрах.

Однако, только с двумя узлами в каждом центре обработки данных, кворум реплик эквивалентен всем репликам, поэтому, если какой-либо узел опускается, вы потеряете доступность для этой части данных. По этой причине, если вы хотите использовать уровни согласованности кворума, рекомендуется, чтобы коэффициент репликации составлял не менее 3 в каждом центре данных, позволяя потерять одну реплика при сохранении сильной (или локальной сильной) последовательности.

Answer 2

Большинство клиентов Cassandra попытаются подключиться к одному узлу, и если он не сработает, попробуйте следующий в списке. Некоторые даже свяжутся и выяснят компоновку кластера и подберут правильный узел для подключения. Клиенты, такие как Hector, будут поддерживать связь с конкретными узлами, если вам понадобится запрашивать дополнительную информацию, это позволит избежать дорогостоящей настройки.

Answer 3

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

В вашем случае вы можете рассмотреть коэффициент репликации 3, по одному на центр обработки данных, каждый узел разбивает половину данных и использует QUORUM для чтения и записи. Настройте стратегию размещения реплик, чтобы каждая запись обновляла один узел из каждого центра обработки данных (например, A1, A2, A3, B1, B2, B3).Таким образом, каждый центр обработки данных имеет все имеющиеся в его распоряжении данные, и запрос на чтение или запись будет возвращать управление, как только он получит ответ от первого отвечающего центра обработки данных в дополнение к своему собственному.

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