1. Обзор
В этом руководстве мы узнаем о работе снитча и о том, как Cassandra использует ее для эффективной маршрутизации запросов. Мы также рассмотрим различные типы снитчей, доступных в Cassandra.
2. Что такое снитч?
Снитч просто сообщает о стойке и дата-центре , к которому принадлежит каждый узел — по сути, он определяет и сообщает Cassandra о сетевой топологии кластера.
Зная топологию кластера, включая относительную близость между узлами, Cassandra может эффективно направлять запросы на соответствующие узлы в кластере.
2.1. Снитч при операции записи
Cassandra использует информацию от снитча для группировки узлов в стойки и центры обработки данных. Так что, чтобы избежать коррелированных сбоев во время операции записи, Cassandra делает все возможное, чтобы реплики не хранились в одной стойке.
2.2. Snitch on Read Operation
Мы знаем, что во время операции чтения Cassandra должна связаться с рядом узлов и реплик в зависимости от их уровней согласованности . Чтобы сделать операцию чтения эффективной, Cassandra использует информацию от снитча, чтобы определить узел, который быстрее всего вернет реплику.
Затем этот узел запрашивается для получения полной информации о строке. Затем Cassandra запрашивает хэш-значения других узлов реплики, чтобы убедиться, что возвращаются самые последние данные.
3. Типы снитчей
Снитч по умолчанию, SimpleSnitch , не поддерживает топологию. То есть он не знает стойки и датацентры для кластера. Поэтому он не подходит для развертывания в нескольких центрах обработки данных.
По этой причине Кассандра придумала различные типы снитчей, отвечающие нашим требованиям. Обычно мы можем настроить тип снитча в файле конфигурации cassandra.yml через имя свойства endpoint_snitch .
Давайте рассмотрим несколько типов снитчей и то, как они работают.
3.1. PropertyFileSnitch
PropertyFileSnitch — это снитч с поддержкой стоек . Мы можем предоставить информацию о топологии кластера в виде свойств ключ-значение в файле с именем cassandra-topology.properties . В этом файле свойств мы указываем имена стоек и центров обработки данных, к которым принадлежит каждый узел.
Более того, мы можем использовать любое имя для стойки и дата-центра. Но нам нужно убедиться, что имена центров обработки данных соответствуют именам, определенным как NetworkTopologyStrategy в определении пространства ключей .
Вот пример содержимого cassandra-topology.properties :
# Cassandra Node IP=Data Center:Rack
172.86.22.125=DC1:RAC1
172.80.23.120=DC1:RAC1
172.84.25.127=DC1:RAC1
192.53.34.122=DC1:RAC2
192.55.36.134=DC1:RAC2
192.57.302.112=DC1:RAC2
# default for unknown nodes
default=DC1:RAC1
В приведенном выше примере есть две стойки (RAC1, RAC2) и один центр обработки данных (DC1). Любой непокрытый IP-адрес узла попадет в центр обработки данных по умолчанию (DC1) и стойку (RAC1).
Один недостаток этого снитча заключается в том, что нам нужно убедиться, что файл cassandra-topology.properties синхронизирован со всеми узлами в кластере.
3.2. GossipingPropertyFileSnitch
GossipingPropertyFileSnitch также является стукачом для стойки. Чтобы избежать ручной синхронизации стоек и центров обработки данных, как это требуется в PropertyFileSnitch , в этом снитче мы просто определяем имя стойки и центра обработки данных индивидуально для каждого узла в файле cassandra-rackdc.properties .
И информация об этих стойках и дата-центрах обменивается со всеми узлами по протоколу gossip.
Вот пример содержимого файла cassandra-rackdc.properties :
dc=DC1
rack=RAC1
3.3. Ec2Snitch
Как следует из названия, Ec2Snitch связан с развертыванием кластера в Amazon Web Service (AWS) EC2 . В одном развертывании региона AWS имя региона рассматривается как центр обработки данных, а имя зоны доступности — как стойка.
Если нам нужно только развертывание с одним центром обработки данных, настройка свойств не требуется. Принимая во внимание, что в случае развертывания с несколькими центрами обработки данных мы можем указать dc_suffix в файле cassandra-rackdc.properties .
Например, в регионе us-east , если нам нужна пара центров обработки данных, мы можем предоставить конфигурацию dc_suffix как:
dc_suffix=_1_DC1
dc_suffix=_1_DC2
Каждая приведенная выше конфигурация входит в два разных узла. Следовательно, это приводит к us_east_1_DC1 и us_east_1_DC2 в качестве имен центров обработки данных.
3.4. Ec2MultiRegionSnitch
В случае развертывания мультирегионального кластера в AWS мы должны использовать Ec2MultiRegionSnitch . Более того, нам нужно настроить и cassandra.yaml , и cassandra-rackdc.properties.
Мы должны настроить общедоступный IP-адрес как широковещательный_адрес , а также, при необходимости, использовать его в качестве начального узла в cassandra.yaml . Кроме того, мы должны настроить частный IP-адрес как listen_address. Наконец, мы должны открыть session_port или ssl_session_port на общедоступном IP-брандмауэре.
Эти конфигурации позволяют узлам обмениваться данными между регионами AWS, что позволяет развертывать несколько центров обработки данных в разных регионах. В случае одного региона узлы Cassandra переключаются на частный IP-адрес для связи после установления соединения.
Конфигурация центра обработки данных dc_suffix в cassandra_rackdc.properties для каждого узла в регионе аналогична Ec2Snitch .
3.5. GoogleCloudSnitch
Как следует из названия, GoogleCloudSnitch предназначен для развертывания кластера в Google Cloud Platform в одном или нескольких регионах. Как и в AWS, имя региона считается центром обработки данных, а зона доступности — стойкой.
Нам не нужна никакая конфигурация в случае развертывания с одним центром обработки данных. И наоборот, в случае развертывания с несколькими центрами обработки данных, аналогичного Ec2Snitch , мы можем установить dc_suffix в файле cassandra-rackdc.properties .
3.6. СтойкаВыводСнитч
RackInferringSnitch определяет близость узлов к стойкам и центрам обработки данных по третьему и второму октетам IP-адресов узлов.
4. Динамический донос
По умолчанию Cassandra оборачивает любой тип снитча, который мы настраиваем в файле cassandra.yml , другим типом снитча, который называется DynamicEndpointSnitch. Этот динамический снитч получает основную информацию о топологии кластера от базового снитча, который уже настроен. Затем он отслеживает задержку чтения узлов, даже отслеживая операции уплотнения в любых узлах.
Затем эти данные о производительности используются динамическим снитчем для выбора наилучшего узла-реплики для любого запроса на чтение. Таким образом, Cassandra избегает перенаправления запросов на чтение на плохие или занятые (медленно работающие) узлы-реплики.
Динамический снитч использует модифицированную версию механизма обнаружения сбоев начисления Phi , используемого сплетнями для определения лучшего узла-реплики в запросе на чтение. Порог плохого состояния — это настраиваемый параметр, который определяет, насколько плохо должен работать предпочтительный узел по сравнению с самым эффективным узлом, чтобы потерять свой предпочтительный статус.
Cassandra периодически сбрасывает показатели производительности каждого узла, чтобы позволить плохо работающему узлу восстановиться и работать лучше, чтобы восстановить свой предпочтительный статус.
5. Вывод
В этом руководстве мы узнали, что такое Snitch, а также рассмотрели некоторые типы Snitch, доступные для настройки в развертывании кластера Cassandra.