Как Apache Kafka использует страничный кэш операционной системы, какие конфигураций файловой системы надо настраивать для повышения пропускной способности и снижения задержки и каковы недостатки RAID-массивов для надежного хранения опубликованных сообщений.
Страничный кэш ОС и быстродействие Kafka
В отличие от RabbitMQ, Apache Kafka может обеспечить долговременное хранение сообщений, записывая их на диск и сохраняя до тех пор, пока не запустится политика очистки по достижению лимитов, установленных в конфигурации топика retention.time или retention.size. Подробно об этом мы писали здесь. Поэтому работа с диском и взаимодействие с файловой системой очень важны для Kafka.
Рекомендуется использовать несколько дисков, чтобы получить хорошую пропускную способность. При этом следует разделять диски: сообщения, публикуемые в Kafka, хранить на одних дисках, а логи системных событий и файловой системы – на других. Впрочем, можно объединить эти диски в RAID-массив в один том или отформатировать и смонтировать каждый диск как отдельный каталог. Поскольку Kafka реализует репликацию сообщений с брокера лидера раздела на подписчиков, избыточность RAID (Redundant Array of Independent Disks) также может обеспечиваться на уровне приложения. Однако, при этом надо учитывать следующие соображения:
- При настройке нескольких каталогов данных, разделы будут назначены им циклически. Каждый раздел будет полностью находиться в одном из каталогов данных. Если данные не сбалансированы между разделами, это может привести к дисбалансу нагрузки между дисками. RAID потенциально может лучше распределять нагрузку между дисками благодаря собственным низкоуровневым механизмам балансировки нагрузки.
- Главным недостатком RAID является снижение производительности записи и доступного дискового пространства, хотя эта технология виртуализации данных для объединения нескольких физических дисковых устройств в логический модуль способна выдерживать сбои дисков. Тем не менее, восстановление RAID-массива требует настолько интенсивного ввода-вывода, что фактически отключает сервер, поэтому существенного повышения доступности это не обеспечивает.
Линейное чтение и запись сообщений в Kafka обеспечивают предсказуемый шаблон использования и отлично оптимизируются операционными системами. Любая современная операционная система предоставляет методы упреждающего чтения и отложенной записи, которые предварительно выбирают данные в больших блоках и группируют меньшие логические записи в большие физические записи для этих линейных операций.
Из-за разницы в производительности между пропускной способностью и поиском на диске современные ОС более активно используют основную память для кэширования диска. Современная ОС перенаправит всю свободную память на кэширование диска с небольшим снижением производительности при освобождении памяти. Все операции чтения и записи на диск будут проходить через этот единый кэш. Эту функцию трудно отключить без использования прямого ввода-вывода, поэтому даже если процесс поддерживает внутрипроцессный кеш данных, эти данные будут дублироваться в страничном кэше ОС, эффективно сохраняя все дважды.
Использование файловой системы и страничного кэша ядра ОС предпочтительнее, чем кэш в памяти или другая структура. Страничный кэш обеспечивает как минимум удвоенный объем доступного кэша, обеспечивая автоматический доступ ко всей свободной памяти, и увеличивает его, сохраняя компактную байтовую структуру, а не объекты.
В Kafka все данные немедленно записываются в постоянный журнал файловой системы без сброса на диск, т.е. данные передаются в страничный кэш ядра. Вся логика поддержания согласованности между кэшем и файловой системой находится в операционной системе, которая делает это эффективно и правильно, благодаря своим внутренним механизмам. Данные принудительно выводятся из кэша ОС на диск с помощью политики очистки, которой можно управлять через конфигурации retention. При выводе данных из страничного кэша Kafka выполняет системных вызов fsync, который синхронизирует файл с хранилищем, копируя на диск все части файла, находящиеся в памяти. Этот системный вызов для POSIX-систем ожидает тклика устройства, что все эти части данных сохранены. При восстановлении после сбоя любого сегмента журнала, о котором не известно, что он был обработан fsync, Kafka проверит целостность каждого сообщения, проверив его контрольную сумму (CRC, Cyclic Redundancy Check), а также перестроит соответствующий файл индекса смещения как часть процесса восстановления, выполняемого при запуске. Примечательно, что надежность в Kafka не требует синхронизации данных с диском, поскольку вышедший из строя узел всегда восстанавливается из своих реплик.
Рекомендуется использовать настройки очистки по умолчанию, которые полностью отключают fsync приложения. Это означает, что необходимо полагаться на фоновую очистку, выполняемую ОС, и собственную фоновую очистку Kafka. Это обеспечивает отличную пропускную способность и низкую задержку, а также гарантии полного восстановления. Тем не менее, политики fsync на уровне приложения по-прежнему поддерживаются, хотя они менее эффективны. Ручное управление fsync дает ОС меньше возможностей для изменения порядка записи и может привести к задержке, поскольку в большинстве файловых систем Linux блокирует запись в файл, тогда как фоновая очистка обеспечивает гораздо более детальную блокировку на уровне страницы.
Влияние файловой системы на быстродействие брокера сообщений
Поскольку Kafka пишет данные в простые файлы на диске, она может использоваться практически с любой файловой системой. Однако, на практике чаще всего применяются EXT4 и XFS. Исторически EXT4 использовался чаще, но недавний бенчмаркинговый тест на кластере с высокой нагрузкой показал, что XFS работает намного быстрее и производительнее EXT4. Впрочем, для любой файловой системы, используемой для каталогов данных, в системах Linux во время монтирования рекомендуется использовать опцию noatime, которая отключает обновление атрибута atime (время последнего доступа) файла при чтении файла. Это может исключить значительное количество операций записи в файловую систему, особенно в случае начальной загрузки потребителей. Kafka вообще не полагается на атрибуты atime, поэтому его можно безопасно отключить.
По умолчанию файловая система XFS не требует каких-либо изменений настроек во время создания файловой системы и при монтировании. Можно попробовать настроить параметр bigio, который влияет на предпочтительный размер ввода-вывода, сообщаемый вызовом статистики. Это может увеличить производительность при записи на большие диски, но не всегда заметно на практике. Параметр nobarrier для базовых устройств с кэшем на батарейном питании может повысить производительность за счет отключения периодической очистки записи. Но если базовое устройство работает нормально, оно сообщит файловой системе об отсутствии необходимости в очистки, и этот параметр не окажет никакого эффекта.
Файловая система EXT4 требует гораздо больше настроек параметров монтирования. Эти настройки могут быть сложны и в случае сбоя приводят к потере и повреждению данных. Для одного брокера это не проблема, поскольку диск можно очистить, а реплики восстановить из кластера. В сценарии с множественными сбоями, например при отключении электроэнергии, это может означать повреждение базовой файловой системы и данных, что очень сложно восстановить. Поэтому в EXT4 рекомендуется настроить следующие параметры:
- data=writeback, что устанавливает обратный порядок записи. По умолчанию файловая система EXT4 имеет строгий порядок записи, заданный в значении data=ordered. Однако, для Kafka это не нужно, поскольку она сама восстанавливает данные во всех несброшенных журналах. А data=writeback устраняет ограничение порядка и значительно снижает задержку обработки данных.
- отключение логирования. Хотя ведение журнала ускоряет перезагрузку после сбоя сервера, оно вводит множество дополнительных блокировок, которые снижают производительность записи. Если время перезагрузки некритично и нужно выровнять задержку записи, можно полностью отключить логирование.
- commit=num_secs — частота, с которой файловая система EXT4 фиксирует данные в своем журнале метаданных. Низкое значение этого параметра снижает потерю несброшенных данных во время сбоя, а высокое повышает пропускную способность.
- nobh – параметр, который управляет дополнительными гарантиями порядка при использовании режима data=writeback. Для Kafka это безопасно благодаря независимости от порядка записи. Также nobh позволяет улучшить пропускную способность и снизить задержку.
- delalloc – отложенное выделение, когда файловая система избегает выделения каких-либо блоков до тех пор, пока не произойдет физическая запись. Это позволяет EXT4 выделять большие экстенты вместо меньших страниц, обеспечивая последовательную запись данных. Эта функция повышает пропускную способность, но также увеличивает задержку, связанную с некоторой блокировкой файловой системы.
Узнайте больше про администрирование Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
- Apache Kafka для инженеров данных
Источники
