Версия сайта для слабовидящих
Что такое graceful shutdown в Apache Kafka, когда используется такое плавное завершение работы, при чем здесь синхронизация реплик и как это влияет на плановые операции обслуживания кластера.
Как работает механизм Graceful shutdown в Apache Kafka
Благодаря множеству внутренних механизмов обеспечения отказоустойчивости, Apache Kafka имеет высокую надежность и позволяет строить нагруженные конвейеры потоковой обработки данных. Одним из таких механизмов является репликация, когда брокеры-подписчики копируют сообщения с брокера-лидера раздела топика, куда приложение-продюсер опубликовало данные. Надежность и согласованность данных обеспечивается за счет синхронизации реплик, автоматическим обнаружением сбоя брокера-лидера и перевыборами, о чем мы писали здесь.
Однако, брокер может стать недоступным не только в случае незапланированного сбоя, но и в рамках планового отключения, например, для выполнения каких-либо операций обслуживания. Для этого в Kafka есть механизм плавной остановки (Graceful shutdown) для отдельно взятого узла, который работает следующим образом:
- синхронизирует все свои логи с диском, чтобы избежать необходимости восстановления журналов, т. е. проверки контрольной суммы для всех сообщений в конце журнала, при перезапуске. Поскольку восстановление лога может занять много времени, этот шаг ускоряет перезапуск.
- перед отключением брокера переносит все разделы, для которых сервер является ведущим, в другие реплики. Это ускоряет передачу лидерства другим брокерам и сокращает период недоступности каждого раздела до нескольких миллисекунд.
Синхронизация журналов происходит автоматически каждый раз при остановке сервера, если параметр конфигурации controlled.shutdown.enable установлен в значение true. Разумеется, плавное завершение работы успешно только в том случае, если все разделы, размещенные на остановленном брокере, имеют реплики, т. е. коэффициент репликации больше 1, и хотя бы одна из этих реплик активна.
При развертывании Apache Kafka в виде контейнера в поде Kubernetes процесс-брокер Kafka получит сигнал SIGTERM, когда Kubernetes захочет завершить работу пода. Напомним, в Unix-совместимых системах сигнал SIGTERM используется для запроса завершения процесса. Он посылается процессу утилитой kill по умолчанию и, в отличие от сигнала SIGKILL, SIGTERM может быть обработан или проигнорирован приложением. Таким образом, для плавного завершения работы брокера Kafka, развернутой в контейнере, посылается сигнал SIGTERM, обработка которого предполагает ожидание некоторого заданного количества времени. После того, как время ожидания плавного завершения работы истечет, а процесс все еще не завершился, Kubernetes выдает сигнал SIGKILL. Это эквивалентно выполнению команды shell-оболочки bin/kafka-server-stop.sh, которая завершает процесс по его идентификатору:
kill <kafka-pid>
Пример того, как это используется в легковесных контейнерах на платформе Heroku, мы рассматривали здесь.
Перезапуск брокера и другие эксплуатационные операции
Поскольку плавное завершение работы обычно применяется для плановых операций обслуживания, оно часто требуется не для одного отдельного узла, а для всех брокеров в кластере Apache Kafka. Например, чтобы обновить программное обеспечение, обновить конфигурации или провести обслуживание кластера, потребуется перезапустить все брокеры. Для этого можно выполнить последовательный перезапуск, перезапуская по одному брокеру за раз, чтобы избежать простоев приложений-потребителей. Это работает из коробки для Kafka на платформе Confluent. В частности, Confluent Control Center позволяет отслеживать состояние брокера во время последовательного перезапуска.
Как уже было отмечено выше, механизм обеспечения высокой доступности Kafka основан на репликации и синхронизации реплик, поэтому даже при недоступности одной из реплик во время перезапуска брокера, у клиентов не будет простоев, если количество оставшихся синхронизированных реплик больше настроенного значения конфигурации min.insync.replicas. Для этого надо запустить брокеры с controlled.shutdown.enable=true, чтобы изменить лидера раздела топика до остановки брокера. Активный контроллер должен быть последним брокером, который перезапускается, чтобы не перемещать его при каждом перезапуске брокера, увеличивая время этой процедуры.
В заключение отметим, что пока, даже для Kafka Confluent, нет встроенной возможности автоматически генерировать план переназначения лидера для вывода брокеров из эксплуатации. Администратору кластера Kafka приходится составлять такой план переназначения самостоятельно, чтобы переместить реплику всех разделов, размещенных на выводимом из эксплуатации брокере, на остальные узлы. Это может занимать много времени, поскольку для обеспечения надежности, переназначение должно быть таким, чтобы реплики от выведенного из эксплуатации брокера распределялись на разные узлы. Возможно, такой инструмент появится в будущих релизах этой платформы потоковой передачи событий.
Освойте администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Администрирование кластера Kafka
- Apache Kafka для инженеров данных
- Администрирование Arenadata Streaming Kafka
Источники
