1

Надежный кластер Kafkaбез потерь данных

Отдел архитектуры и перспективных разработок

Октябрь 2017 г.

2

Содержание

1. Предпосылки

2. Гарантии работоспособности кластера

3. Основные понятия

4. Рецепт надежного кластера

5. Полный выход из строя одного из центров обработки данных

6. Потеря двух центров обработки данных

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

8. Брокер контроллер

9. Mirror Maker

10. Выводы

11. Дополнительная информация

3

Предпосылки

Предпосылками для создания кластера является широкое использование Kafka в Банке в качестве основы интеграционных решений.

Основные прикладные решения ММТ, ППРБ.CEP, КСШ СМ.

Кластер Kafka должен отвечать следующим критериям:

Высокая производительностьВысокая надежностьКонсистентность данныхВысокая доступность

4

Гарантии работоспособности кластера

Надежный кластер должен гарантировать работоспособность при сбое узлов.

Под гарантиями работоспособности при сбоях и в штатном режиме понимается следующее:

Кластер позволяет осуществлять запись данных всем работающим продьюсерам

Кластер корректно сохраняет записываемые данные

Кластер позволяет читать данные всем работающим консьюмерам

Кластер минимизирует дупликацию вычитывания данных

Кластер сбалансирован. То есть распределение лидеров партиций топиков равномерно по узлам кластера

Кластер автоматически восстанавливает конфигурацию при восстановлении работоспособности сбойных узлов

Предлагаемое решение для построения кластера остается работоспособным при сбоях сети между любыми двумя узлами (датацентрами), замедлении работы и выходе из строя одного из узлов кластера (датацентра)

5

Основные понятия

Брокер – это узел Kafka, через который осуществляются запросы на чтение и запись

Брокер-Контроллер – брокер с доп. обязанностями, координирует состояния партиций на брокерах, реагирует на малейшие изменения конфигураций кластера Kafka

Продьюсеры (Producer) – это процессы или приложения, которые публикуют данные

Консьюмеры (Consumer) - это процессы или приложения, которые потребляют данные

Zookeeper служба координации кластера Kafka, хранит конфигурацию всего кластера

Zookeeper-лидер (leader) – главный узел Zookeeper, обрабатывающий все запросы на запись (в Zookeeper)

Zookeeper-фолловер (follower) – узлы, доступные только для чтения. Синхронизируются с лидером

Топик (topic) – очередь сообщений, используемая для организации потоков данных. Продьюсеры записывают сообщения в топики. Консьюмеры подписываются на интересующие их топики и вычитывают из них сообщения.

Партиция (partition) – часть топика, обеспечивающая параллельность записи и чтения из топика. Партиции-лидеры могут реплицироваться в партиции-фолловеры и обслуживаться различными брокерами для повышения надежности и отказоустойчивости.

Партиция-фолловер – реплика партиции лидера. Доступна только для чтения. Синхронизируется с партицией-лидером.

Партиция-лидер – доступна и для чтения, и для записи.

Лидер партиции – брокер, который является лидером некоторой партиции. Партиция-лидер доступна для записи, находящуюся на этом брокера и который отвечает за синхронизацию реплик.

6

Рецепт надежного кластера

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

Брокеры, принадлежащие к разным датацентрам, должны иметь различный rack-id. rack-id это идентификатор группы брокеров. Отсутствие rack-id может привести к к тому что данные будут реплицироваться внутри одного датацентра, а не равномерно по кластеру.

Для каждого топика необходимо установить replication factor = 3 (равным количеству центров обработки данных), чтобы в каждом из датацентров располагалась копия каждого топика.

Настройка механизма записи:

Для каждого топика минимальное число синхронных реплик min.insync.replicas = 2. Запись для продьюсера считается успешной, если два из трех узлов подтвердили запись данных. Тем самым гарантируется, что актуальность данных на топиках будет поддерживаться как минимум в двух датацентрах и выход из строя одного датацентра не приведет к потере данных

Для каждого продьюсера необходимо установить acks = all. All означает что продьюсер, прежде, чем начать запись, будет ждать от лидера партиции подтверждение о том что брокеры готовы к записи. Минимальное количество этих брокеров равно min.insync.replicas (т.е. в нашем случае 2). Тем самым гарантируется, что запись будет осуществляться как минимум в 2 брокера в разных датацентрах и в любой момент времени актуальные данные будут сразу в двух датацентрах. Потеря одного датацентра из трех не критична.

Для каждого продьюсера должны быть указаны координаты всех брокеров

7

Рецепт надежного кластера

Необходимо отключить алгоритм выбора "нечистого" лидера партиции (unclean-leader-election = false). Нечистый лидер партиции – брокер с неактуальными данными, выбранный лидером партиции. Выбор нечистого лидера партиций грозит потерей данных, поскольку фолловеры будут считать его партицию актуальной.

Для каждого консьюмера указываем все узлы кластера.

При чтении данных консьюмерами не используем аллокацию читателя на партицию топика.

DC2 DC3

DC1

ZKlead

kafka

kafka

kafka

ZK

followZK

follow

C

PC

P

PC

8

Полный выход из строя одного из центров обработки данных

По любым причинам центр обработки данных может полностью выйти из строя. Наиболее частыми причинами при этом являются:

сбой электропитания в датацентре и/или стойках серверов

ошибочные действия администраторов по штатному выключению серверов

аварийный выход из строя сразу всех серверов кластера

DC2 DC3

DC1

ZKlead

kafka

kafka

kafka

ZK

followZK

follow

C

PC

P

PC

В результате отказа одного из датацентров:

кворум Zookeeper продолжает работу в штатном режиме и доступен для чтения/записи.

- исключается изолированный узел Zookeeper

- кворум не нарушен (из 3-х узлов: 2 узла рабочих > 1 нерабочий)

- при необходимости, будет выбран новый лидер Zookeeper

9

Потеря двух датацентров

DC2 DC3

DC1

ZKlead

kafka

kafka

kafka

ZK

followZK

follow

C

PC

P

PC

При потере двух датацентров на оставшемся датацентре остается один Zookeeper. Кворум нарушен. В связи с этим обслуживание косюмеров и продюсеров останавливается.

Восстановление работы происходит после восстановления связи с потерянными датацентрами.

Таким образом мы жертвуем доступностью в пользу согласованности данных. Данные не потеряны.

10

Полный выход из строя одного из центров обработки данных

кластер Kafka из двух брокеров продолжает работать в штатном режиме.

- т.к. replication factor = 3, то при потере 1 брокера мы имеем 2 реплики (данные не придется реплицировать полностью, как это было бы в случае replication factor = 2 что могло бы повлечь за собой перегрузку сети), причем как минимум одна из них (min.insync.replicas = 2) является актуальной. Таким образом мы не теряем данные.

- брокеры получат оповещения об обновлениях zнод на Zookeeper, на которые они подписаны

- брокеры автоматически обновят метаданные о состоянии кластера через запросы к Zookeeper

- при необходимости, Zookeeper назначит контроллером один из доступных брокеров (если контроллер потерян).

- контроллер назначит новых лидеров партиций (если лидер потерян). Т.к. выбор грязного лидера запрещен (unclean-leader-election = false) то лидером будет выбран брокер с актуальной партицией. Т.е. данные не потеряны. Затем т.к min.insync.replicas = 2 обе оставшиеся партиции синхронизируются.

- продьюсеры продолжат запись в штатном режиме (т.к. доступно 2 фолловера)

- консьюмеры, после ребалансировки в связи с обновлением структуры топиков, продолжат чтение

Таким образом гарантии работоспособности выполняются.

11

Полный выход из строя одного из центров обработки данных

После восстановления работы потерянного датацентра:

узел Zookeeper возвращается в кворум (на выходе - кворум из 3-х узлов)

сообщение между узлами Zookeeper и брокерами восстанавливается

сообщение между брокерами восстанавливается

контроллер, при необходимости, выбирает новых лидеров партиций

на консьюмере происходит ребалансировка

Восстановление происходит в автоматическом режиме

12

Полный отказ сетевого канала между двумя центрами обработки данных

Причины:

повреждение / обрыв сетевого кабеля, отказы повторителей, концентраторов или портов, насыщение полосы пропускания

выход из строя сегмента сети

ошибочные действия администраторов (например, физическая блокировка портов)

Возможно два варианта развития событий.

Вариант 1: "Разрыв сообщения произошел между двумя узлами-фолловерами Zookeeper":

коммуникация каждого из ZK узлов-фолловеров с лидером не нарушена

кворум из трех узлов сохраняется

выбор лидера не требуется

коммуникация между брокерами и узлами Zookeeper не нарушена - у каждого из брокеров есть доступ к узлу ZK в локальном датацентре и к узлу ZK в соседнем датацентре, с которым соединение не нарушено

Вариант 2: Разрыв сообщения произошел между узлом-лидером и одним из узлов-фолловеров Zookeeper:

один из узлов-фолловеров теряет связь с узлом-лидером

кворум Zookeeper деградирует до двух узлов. Узел-фолловер, потерявший связь с узлом-лидером, работу не завершает, но и не обслуживает запросы, находясь в состоянии ожидания для восстановления соединения

выбор лидера не требуется

несмотря на недоступность Zookeeper в одном из датацентров, брокер этого датацентра не теряет связи с Zookeeper, находящемся на соседнем датацентре. Таким образом все брокеры работают в штатном режиме

13

Полный отказ сетевого канала между двумя центрами обработки данных – Вариант 1

Рассмотрим Вариант 1 более подробно.

Доступность Zookeeper делает возможным обновление метаданных на брокерах (информацию о конфигурации кластера, в т.ч. о соседних брокерах и топиках).

Консистентность данных на брокерах сохраняется.

Если перекрыто сообщение между партицией-лидером и партицией-фолловером , то:

партиция-фолловер покидает ISR (insync.replicas), т.е. становится несинхронной. Однако т.к min.insync.replicas=2, то мы имеем на момент потери связи как минимум одну актуальную партицию. Данные не потеряны. Далее партиции синхронизируются insync.replicas=2

т.к. min.insync.replicas=2 для каждого топика, а текущее insync.replicas=2, то запись продьюсером (с acks=all) в партицию остается возможной для всех брокеров, кроме того, который не имеет доступа к лидерской партиции

чтение из партиции возможно всеми консьюмерами по доступным каналам

Гарантии работоспособности выполняются (за исключением того что запись продьюсерами не имеющими доступ к лидеру партиции невозможна)

14

Полный отказ сетевого канала между двумя центрами обработки данных – Вариант 1

Если перекрыто сообщение между партициями фолловерами, то:

обе партиции фолловера остаются в ISR (insync.replicas), т.е. в режиме синхронизации с лидером

количество insync.replicas остается неизменным, т.к. связь с партицией-лидером не нарушена

т.к. min.insync.replicas=2 для каждого топика, а текущее синхронных партиций как минимум 2, то запись продьюсером (с acks=all) в партицию остается возможной

запись возможна из любого датацентра, поскольку партиция-лидер общедоступна для всех

чтение из партиции возможно по доступным каналам

топик остается доступным как для чтения, так и для записи

гарантии работоспособности выполняются

15

Полный отказ сетевого канала между двумя центрами обработки данных – Вариант 2

Вариант 2: Разрыв сообщения произошел между узлом-лидером и одним из узлов-фолловеров Zookeeper:

один из узлов-фолловеров теряет связь с узлом-лидером

Кворум Zookeeper деградирует до двух узлов. Узел-фолловер, потерявший связь с узлом-лидером, работу не завершает, но и не обслуживает запросы, находясь в состоянии ожидания для восстановления соединения

выбор лидера не требуется

несмотря на недоступность Zookeeper в одном из датацентров, брокер этого датацентра не теряет связи с Zookeeper, находящемся на соседнем датацентре. Таким образом все брокеры работают в штатном режиме

Ситуация с лидерами партиций аналогична ситуациям в варианте 1

Гарантии работоспособности выполняются (за исключением того что запись продьюсерами не имеющими доступ к лидеру партиции невозможна)

DC2 DC3

DC1

ZKlead

kafka

kafka

kafka

ZK

followZK

follow

C

PC

P

PC

DC2

16

Брокер контроллер

Рассмотрим разные варианты расположения брокера контроллера на момент развала кластера

1) Контроллер остался в кластере

Выбор нового контроллера не требуется

Имеем как минимум одну актуальную партицию (на контроллере). Данные не потеряны

2) Контроллер потерян

Происходит выбор нового контроллера

Т.к. unclean-leader-election = false то новый контроллер назначит лидером брокер с актуальной партицией. Данные не потеряны

17

Mirror maker

Mirror maker не используется потому что:

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

•Т.к. данные на зеркальный кластер копируются с запозданием, зеркальный кластер не учавствует в записи\чтении данных продюсерами\консюмерами до момента падения основного кластера. Таким образом имеем низкую утилизацию ресурсов

18

Выводы

Конфигурации кластера описанного в данной презентации обеспечивает защиту от потери данных за счет того что:

в любой момент времени имеем как минимум две синхронные реплики (min.insync.replicas = 2). Потеря одного кластера не страшна.

реплицируются только актуальные данные (unclean-leader-election = false). Так что потеря лидера партиции не критична

Минимальное количество датацентров для отказоустойчивого решения без потерь данных= 3. (В конфигурации их двух датацентров либо неизбежна потеря части данных при падении одного из датацентров либо невозможно достижение кворума ZK)

В случае падения двух датацентров обслуживание продюсеров и консюмеров прекращается до восстановления кластера.

19

Дополнительная информация

Более подробная информация и все сценарии отказов приведены тут (http://confluence.ca.sbrf.ru/pages/viewpage.action?pageId=132588207)

Авторы:

Голованов Михаил Евгеньевич

Хасанов Тимур Анварович

Дунаевский Александр Александрович