Cassandra улучшает время отказоустойчивости

Question

Мы используем кластер cassandra с тремя узлами (каждый узел на другом vm) и в настоящее время исследуем времена отказа при выполнении операций записи и чтения в случае, если один из узлов умирает. Времена отказоустойчивости очень хороши при изящном закрытии одного узла, однако при убийстве узла (путем отключения виртуальной машины) латентность во время тестов составляет около 12 секунд. Думаю, это связано с тайм-аутом tcp?

Есть ли способ настроить это?

Редактировать: В данный момент мы используем версию Cassandra 2.0.10. Мы используем драйвер java-клиента, версия 2.1.9.

Чтобы описать ситуацию более подробно: записи/считывания операции выполняются с использованием QUROUM Консистенция Уровень с коэффициентом репликации 3. Кластер состоит из 3 узлов (c1,c2,c3), каждый из которых на другом хосте (VM). Драйвер клиента подключен к c1. Во время тестов я выключил хост для c2. С этого момента мы наблюдаем, что клиент блокирует> 12 секунд, пока другие узлы не поймут, что c2 ушел. Поэтому я думаю, что это не проблема клиента, так как клиент подключен к узлу c1, который по-прежнему работает в этом сценарии.

Редактировать: Я не верю, что факт, что работа cassandra внутри виртуальной машины влияет на сетевой стек. Фактически, убийство виртуальной машины приводит к тому, что TCP-соединения не прекращаются. В этом случае удаленный хост может заметить это только через некоторый механизм тайм-аута (либо тайм-аут в протоколе уровня приложения, либо таймаут TCP). Если процесс был убит на уровне ОС, стек TCP операционной системы позаботится о завершении TCP-соединения (IMHO с сбросом TCP), позволяя удаленному хосту немедленно получать уведомление об ошибке. Однако может оказаться важным, что даже в ситуациях, когда хост выходит из строя из-за сбоя оборудования или когда хост отключается из-за отсоединенного сетевого кабеля (в обоих случаях соединение TCP не будет немедленно прекращено) время переключения является низким. Я пробовал sigkill процесс cassandra внутри виртуальной машины. В этом случае время переключения составляет около 600 мс, что отлично.

вид касается

Answer 1

раз отказоустойчивых довольно хорошо, когда выключая один узел изящно, однако, при убийстве узла (путем выключения ВМ) задержку во время испытаний около 12 секунд

12 secs - довольно большое значение. Некоторые вопросы перед исследованием далее

• Какова ваша версия Cassandra? Начиная с версии 2.0.2 есть спекулятивный механизм повторных попыток, что позволит значительно уменьшить задержку для такого сценария отказоустойчивого: http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2

• что драйвер клиента вы используете (Java C# версии??). Обычно с правильно настроенной политикой балансировки нагрузки, когда узел не работает, клиент будет автоматически повторять запрос путем перенаправления на другую реплику.Существует также спекулятивная повторная попытка реализовать на стороне водителя: http://datastax.github.io/java-driver/manual/speculative_execution/

Edit: для узла, чтобы быть маркированы вниз, протокол сплетня с помощью детектора фи начислений. Вместо того, чтобы иметь двоичное состояние (UP/DOWN), алгоритм корректирует уровень подозрительности, и если значение превышает пороговое значение, узел считается down

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

Посмотрите в cassandra.yaml файл для этой конфигурации:

# phi value that must be reached for a host to be marked down. 
# most users should never need to adjust this. 
# phi_convict_threshold: 8 

Другой вопрос: , что балансировка нагрузки стратегии вы используете из драйвера? И вы использовали спекулятивную политику повтора?