Skip To Content

Дисковое хранилище Kafka

ArcGIS GeoEvent Server использует Apache Kafka для управления всем трафиком событий от входов до сервисов GeoEvent, а затем снова от сервисов GeoEvent до выходов. Kafka предоставляет набор отделов (очередей сообщений) для событий, которые будут опубликованы, и для потребителей, подписывающихся на эти сообщения о событиях. Очереди отделов Kafka управляются на диске для постоянного хранения и для восстановления очередей сообщений после падения системы.

Основы GeoEvent Server Kafka

У каждого входа и выхода GeoEvent Server есть отдел Kafka

У каждого входа и выхода есть отдел

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

Разделы отделов в отделе

Каждый раздел отделов Kafka реплицируется дважды для обеспечения отказоустойчивости и параллелизма. Реплики распределяются между тремя отдельными папками на диске.

Реплики разделов отдела в отделе

Обратите внимание, что Kafka создает и управляет большим набором разделов для потребительских посторонних отделов. Такое большое количество разделов – то, что обеспечивает системе хорошую производительность благодаря распараллеливанию.

Общие рекомендации по размеру диска

Для новой установки GeoEvent Server сервису ArcGIS GeoEvent Gateway требуется как минимум 1 ГБ дискового пространства. Каждый вход или выход, потребует минимум 720 МБ дополнительного дискового пространства перед обработкой каких-либо событий. Обратите внимание, что все размеры являются минимальными оценками и, вероятно, будут увеличиваться по мере увеличения количества элементов, которые вы настраиваете в GeoEvent Server.

Настройки GeoEvent Server Kafka

Вы можете изменить поведение экземпляра Kafka для GeoEvent Server, изменив файл свойств Kafka. Основная причина для изменения файла свойств заключается в изменении расположения файлов на диске. Тем не менее, существуют редкие случаи, когда другие свойства может потребоваться изменить.

Файл свойств Kafka

Файл свойств, содержащий настройки Kafka (kafka.properties) для GeoEvent Server можно найти в следующих местоположениях, в зависимости от вашей операционной системы.

  • Windows (по умолчанию) – C:\Program Files\ArcGIS\server\geoevent\gateway\etc\kafka.properties
  • Linux (по умолчанию) – /home/arcgis/server/GeoEvent/gateway/etc/kafka.properties

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

Хранилище отделов

Отделы Kafka в GeoEvent Server хранятся в одном из следующих местоположений, в зависимости от вашей операционной системы.

  • Windows (по умолчанию) – C:\ProgramData\ESRI\GeoEvent-Gateway\kafka\
  • Linux (по умолчанию) – /home/arcgis/.esri/GeoEvent-Gateway/config.[machine name]/kafka/ (напр. /home/arcgis/.esri/GeoEvent-Gateway/config.gesdev01/kafka/)

В папке kafka\ будут три папки с журналами, где хранятся реплики разделов: log\, log1\, log2\.

Для изменения местоположения отделов Kafka, измените следующие свойства, в зависимости от вашей операционной системы.

Параметры по умолчанию для Windows:

  • gateway.data.dir=C://ProgramData//Esri//GeoEvent-Gateway//
  • log.dirs=kafka/logs,kafka/logs1,kafka/logs2

Параметры по умолчанию для Linux:

  • gateway.data.dir=/home/arcgis/.esri/GeoEvent-Gateway/config.[machine name] (напр. /home/arcgis/.esri/GeoEvent-Gateway/config.gesdev01)
  • log.dirs=kafka/logs,kafka/logs1,kafka/logs2

Разделы отделов

В GeoEvent Server по умолчанию 3 раздела в отделе. Таким образом, если вы изучите папки журналов, в которых хранятся ваши отделы, вы найдете папки с одинаковыми именами и индексами в конце (-1, -2 и -3). Внутри каждой папки раздела, Kafka ведет журнал всех данных в разделе отдела на данный момент. Для изменения числа разделов в отделе измените следующее свойство.

  • num.partitions=3

Репликация отдела

В GeoEvent Server, числов реплик разделов отделов по умолчанию - 2. Таким образом, если вы изучите каждую папку журналов, в которых хранятся ваши отделы, вы всегда найдете две папки с одинаковыми именами и индексами в конце (-1, -2 или -3). Каждая из папок log\, log1\, log2\ отвечает за хранение одной реплики из двух папок разделов (какие два раздела получит папка выбирается случайным образом). Для изменения числа реплик разделов в отделе измените следующее свойство.

  • replication-factor=2

Размеры файлов раздела в отделе

По умолчанию каждый файл журнала раздела в отделе Kafka начинается с минимума в 20 МБ и растет до максимума в 100 МБ, прежде чем создается новый файл журнала. Можно иметь несколько файлов журнала в реплике раздела одновременно. Планируйте как минимум 720 МБ [(100 МБ + 20 МБ) x 3 раздела x 2 реплики = 720 МБ] на ввод/вывод. В крайних случаях высокоскоростных потоков событий каждая папка реплики раздела в отделе может увеличиваться в 3–4 раза по сравнению с максимальным размером файла журнала (до 300–400 МБ на реплику раздела). Для одного отдела с тремя разделами общее дисковое пространство может вырасти до 1800 – 2400 МБ в любой момент. Умножив этот максимальный размер на число входов и выходов вы получите необходимый размер диска, нужный для Kafka в GeoEvent Server. Свойство ниже контролирует максимальный размер файла журнала перед переходом на новый файл (по умолчанию 100 МБ).

  • log.segment.bytes=104857600

Если вы работаете с высокоскоростными данными, можете получить несколько файлов журнала по 100 МБ, в противном случае у вас может быть только один. Для данных с меньшей скоростью вы можете уменьшить размер, изменив это свойство. Для данных с большей скоростью вы можете увеличить размер, изменив это свойство. Если вы установите слишком малый размер, то в Kafka постоянно будет происходить переход на новые файлы. Если вы установите слишком большой размер, то Kafka будет редко переходить на новые файлы журнала и старые события будут храниться в очереди дольше, чем необходимо.

Другая настройка, влияющая на количество потребляемого дискового пространства разделами отделов Kafka – байты хранения. Это свойство дает указание Kafka всегда хранить минимальный объем данных. Значение этого свойства по умолчанию составляет 100 МБ. Поэтому даже если Kafka решает, что может и должен удалить старые данные, то размер оставшихся данных никогда не будет ниже 120 МБ (100 МБ для старых файлов журнала и 20 МБ для нового файла журнала). Как и в случае со свойством байтов сегмента, описанным выше, если вы работаете с более низкими скоростями данных, вы можете уменьшить значение этого свойства. Когда работаете с высокоскоростными данными используйте 100 МБ по умолчанию.

  • log.retention.bytes=104857600

Управление разделами отделов

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

  • log.retention.hours=1
  • log.retention.check.interval.ms=30000

По умолчанию срок хранения – 1 час. Любые файлы данных старше 1 часа и не хранящие в настоящий момент активные данные будут удалены. Если файл все еще активно используется для хранения данных (как это может быть в случае данных с низким объемом / скоростью), он не будет удален. По умолчанию Kafka проверяет удаление старых файлов данных каждые 30 секунд.

Свойства управления файлами разделов

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

  • log.roll.ms=1800000
  • log.roll.jitter.ms=180000

Первое свойство указывает Kafka переходить к новому файлу, по сути, заменяя его новым каждые 30 минут. Kafka создаст новый файл данных будет создаваться каждые 30 минут, независимо от размеров старого файла данных. Для потоков данных с низкой скоростью это может устранить необходимость поддерживать старые данные, если файл данных заполняется не очень часто. Второе свойство определяет насколько постоянно Kafka будет выполнять переход к новому файлу данных. Рекомендованное значение – 3 минуты, означающее что раз в 3 минуты Kafka будет проверять необходимость перехода к новому файлу данных.