Как мне установить коэффициент репликации в Cassandra для учета сбоя узла?

Question

Допустим, у нас есть развертывание cassandra с коэффициентом репликации 2. Под этим я подразумеваю, что мы можем выдержать полную потерю одного узла постоянного хранилища без общей потери данных. Я понимаю, что это означает, что каждое из значений хранится как минимум на двух разных узлах в любой момент времени. Следовательно, общий объем требуемого хранилища равен, по крайней мере, общим данным значений x 2. Ie, если нам нужно хранить 100 ТБ в кластере, нам потребуется как минимум 200 ТБ постоянного хранилища на всех узлах.

Однако по мере увеличения числа узлов увеличивается вероятность отказа более чем 1 узла. Следовательно, нужно ли нам увеличивать коэффициент репликации по мере увеличения количества узлов?

Например:

Предположим, что все компоненты надежны на 100%, за исключением контроллеров локального хранилища моих узлов, что время от времени полностью повреждает все локальное хранилище без возможности восстановления (ie, потеря данных полная). Все стоечное оборудование, коммутаторы, питание, охлаждение и т. Д. c идеальны. Я знаю, что это нереально. c.

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

Допустим, у моих узлов есть хранилище по 1 ТБ каждый. Для значений 100 ТБ мне потребуется 200 машин для достижения коэффициента репликации 2 (ie, я могу потерять любой узел и все равно сохранить данные). Однако, если я считаю, что одновременный отказ 2 узлов в этом наборе из 200, вероятно, мне нужно будет поднять коэффициент репликации до 3. Поэтому теперь мне нужно три копии каждого значения (на трех разных узлах), а теперь мне нужно 300 узлы. Теперь я чувствую, что вероятна одновременная потеря 3 или более узлов, поэтому мне нужно снова добавить дополнительные узлы, et c ...

Конечно, это не так, как это масштабируется? Что не так с моим logi c?

Answer 1

Существует несколько типов сбоев, которые необходимо учитывать:

1. Отказ отдельного узла (оборудование / ОС / ...) - ваш узел отказал полностью (данные потеряны ) или частично (например, отказал адаптер питания)
2. Сбой стойки / центра обработки данных - когда узлы в указанной c части центра обработки данных или центра обработки данных полностью вышли из строя или недоступны по сети

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

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

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

Доступность также зависит от требований вашего бизнеса - в простейшем случае, если вы используете уровни согласованности ONE или LOCAL_ONE, ваши данные доступны, даже если доступна только одна реплика, но если ваш бизнес-логи c требует большей согласованности, вам нужно иметь больше доступных реплик. И фактор репликации также влияет на уровни согласованности - если вы используете RF = 2 и требуете CL = QUORUM, вы не можете допустить сбоя одного узла, в то время как можно достичь этого CL с RF = 3 и отказом одного узла.