Защита вашего конвейера данных: избегайте сбоев Apache Kafka с помощью резервного копирования тем и конфигурации

Отказ Apache Kafka происходит, когда кластер Kafka или некоторые из его компонентов выходят из строя, что приводит к прерыванию или ухудшению качества обслуживания. Kafka разработан для обработки потоков данных и сообщений с высокой пропускной способностью и отказоустойчивостью, но он может выйти из строя по разным причинам, включая сбои инфраструктуры, неправильные конфигурации и операционные проблемы. Причины возникновения отказов Kafka

Почему возникает отказ Kafka

Сбой брокера

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

Проблемы с ZooKeeper

Kafka зависит от Apache ZooKeeper для управления метаданными кластера и выбора лидера. Сбои ZooKeeper (из-за сетевых разделений, неправильных конфигураций или истощения ресурсов) могут нарушить работу Kafka. Проблемы с ZooKeeper могут быть исключены, если кластер сконфигурирован в режиме KRaft с более поздней версией 3.5 Apache Kafka.

Неправильная конфигурация темы

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

Сетевые разделы

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

Неправильная конфигурация

Неправильная настройка кластера (политики хранения, распределение реплик и т. д.) может привести к неожиданному поведению и сбоям.

Перегрузка

Внезапное увеличение трафика от производителей или потребителей может перегрузить кластер.

Порча данных

Повреждение журналов Kafka (из-за проблем с диском или резкого завершения работы) может вызвать проблемы при запуске или извлечении данных.

Недостаточный мониторинг и оповещение

Если ранние сигналы тревоги (например, всплески использования диска или высокая задержка) не будут замечены и устранены, незначительные проблемы могут привести к полным сбоям.

Резервные копии тем и конфигураций Apache Kafka важны для восстановления после катастроф, так как они позволяют нам восстановить наши данные и настройки в случае сбоя оборудования, программных проблем или человеческой ошибки. Kafka не имеет встроенных инструментов для резервного копирования тем, но мы можем достичь этого с помощью нескольких методов.

Как создать резервную копию тем и конфигураций Kafka

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

Потребители Kafka

Мы можем использовать потребители Kafka для чтения сообщений из темы и сохранения их во внешнем хранилище, таком как HDFS, S3 или локальное хранилище. Используя надежные инструменты потребителя Kafka, такие как встроенный kafka-console-consumer.sh или пользовательские скрипты потребителя, все сообщения из темы могут быть потреблены с начального смещения. Эта процедура проста и настраиваема, но требует большого объема хранилища для тем с высокой пропускной способностью и может потерять метаданные, такие как метки времени или заголовки.

Подключение Kafka

Путем потоковой передачи сообщений из тем в Объектное хранилище с помощью инструментов, таких как Kafka Connect. Мы можем настроить Kafka Connect с помощью коннектора для приемника (например, коннектора для приема S3, коннектора для приема JDBC и т. д.), настроить коннектор для чтения из определенных тем и записи в резервное место назначения. Конечно, нам понадобится дополнительная настройка для Kafka Connect.

Репликация кластера

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

Копии на уровне файловой системы

Резервные копии на уровне файловой системы, такие как копирование каталогов журналов Kafka напрямую с брокеров Kafka, могут выполняться путем идентификации каталога журналов Kafka (log.dirs в server.properties). Этот метод позволяет сохранить смещения и данные разделов. Однако для обеспечения согласованности и предотвращения потенциальных проблем требуется тщательный процесс восстановления.

Конфигурации и метаданные Kafka

В терминах конфигурации Kafka мы можем указать метаданные о темах, контроле доступа (ACL), файле server.properties со всех брокеров и каталоге данных ZooKeeper (как определено параметром dataDir в конфигурации ZooKeeper). Затем сохраните вывод в файл для дальнейшего использования. Необходимо убедиться, что все пользовательские настройки (например, log.retention.ms, num.partitions) должны быть задокументированы. С помощью встроенного скрипта kafka-acls.sh все свойства acl могут быть собраны в плоский файл.

Вывод

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

Прочитав эту статью, я надеюсь, что вы получите практические и проверенные стратегии для решения проблем с недоступностью Apache Kafka в развертываниях на собственных серверах.