Apache NiFi в Azure

Шлюз приложений Azure

Azure Log Analytics

Виртуальные машины Azure

Виртуальная сеть Azure

Масштабируемые наборы виртуальных машин Azure

Внимание

В этой статье содержатся ссылки на CentOS, дистрибутив Linux, который является концом жизни (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

В этом примере сценария описывается, как запустить Apache NiFi в Azure. NiFi предоставляет систему для обработки и распространения данных.

Apache®, Apache NiFi®, и NiFi® являются зарегистрированными товарными знаками или товарными знаками Apache Software Foundation в США и/или других странах. Использование этих меток не подразумевает подтверждения от Apache Software Foundation.

Архитектура

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

Приложение NiFi выполняется на виртуальных машинах в узлах кластера NiFi. Виртуальные машины находятся в масштабируемом наборе виртуальных машин, который конфигурация развертывает по зонам доступности.
Apache ZooKeeper выполняется на виртуальных машинах в отдельном кластере. NiFi использует кластер ZooKeeper для следующих целей:
- Выбор узла-координатора кластера
- Координирование потока данных
Шлюз приложений Azure обеспечивает балансировку нагрузки уровня 7 для пользовательского интерфейса, который выполняется на узлах NiFi.
Azure Monitor и его функция Log Analytics собирают, анализируют и действуют на основе данных телеметрии от системы NiFi. Данные телеметрии включают в себя системные журналы NiFi, метрики работоспособности системы и метрики производительности.
Azure Key Vault безопасно хранит сертификаты и ключи для кластера NiFi.
Идентификатор Microsoft Entra предоставляет единый вход (SSO) и многофакторную проверку подлинности.

Компоненты

NiFi предоставляет систему для обработки и распространения данных.
ZooKeeper — это сервер с открытым исходным кодом, который управляет распределенными системами.
Виртуальные машины представляют собой предложение "инфраструктура как услуга" (IaaS). Виртуальные машины можно использовать для развертывания масштабируемых вычислительных ресурсов, предоставляемых по запросу. Виртуальные машины обеспечивают гибкость виртуализации, а также исключают необходимость обслуживать физическое оборудование.
Масштабируемые наборы виртуальных машин Azure предоставляют способ управления группой виртуальных машин с балансировкой нагрузки. Количество экземпляров виртуальных машин в наборе может автоматически увеличиваться или уменьшаться в зависимости от спроса или по определенному расписанию.
Зоны доступности — уникальные физические расположения в пределах одного региона Azure. Эти предложения по обеспечению высокого уровня доступности защищают приложения и данные от сбоев центров обработки данных.
Шлюз приложений — это подсистема балансировки нагрузки, которая управляет трафиком к веб-приложениям.
Azure Monitor собирает и анализирует данные о средах и ресурсах Azure. Сюда входят данные телеметрии приложений, такие как метрики производительности и журналы действий. Дополнительные сведения см. в разделе Вопросы мониторинга далее в этой статье.
Log Analytics — это средство портала Azure, выполняющее запросы к данным журнала Monitor. Log Analytics также предоставляет функции для построения диаграмм и статистического анализа результатов запросов.
Azure DevOps Services предоставляет службы, средства и окружения для управления проектами программирования и развертываниями.
Key Vault безопасно хранит и контролирует доступ к секретам системы, таким как ключи API, пароли, сертификаты и криптографические ключи.
Идентификатор Microsoft Entra — это облачная служба удостоверений, которая управляет доступом к Azure и другим облачным приложениям.

Альтернативные варианты

Фабрика данных Azure предоставляет альтернативу этому решению.
Вместо Key Vault можно использовать сравнимую службу для хранения секретов системы.
Apache Airflow. Дополнительные сведения см. в статье о том, как airflow и NiFi отличаются.
Можно использовать поддерживаемую корпоративную альтернативу NiFi, например Cloudera Apache NiFi. Предложение Cloudera доступно через Azure Marketplace.

Подробности сценария

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

Потенциальные варианты использования

NiFi рекомендуется для перемещения данных и управления потоком данных:

Подключение несвязанных систем в облаке
Перемещение данных в службу хранилища Azure и другие хранилища данных и из них
Интеграция пограничных облачных и гибридных облачных приложений с Azure IoT, Azure Stack и службой Azure Kubernetes (AKS)

Таким образом, это решение можно применять в разных областях:

Современные хранилища данных (MDW) объединяют структурированные и неструктурированные данные в масштабе. Они собирают и хранят данные разных форматов из различных источников и приемников. NiFi лучше всего справляется с приемом данных в MDW на базе Azure по следующим причинам:
- Более 200 процессоров доступны для чтения, записи и манипулирования данными.
- Система поддерживает такие службы хранения, как Хранилище BLOB-объектов Azure, Azure Data Lake Storage, Центры событий Azure, Хранилище очередей Azure, Azure Cosmos DB и Azure Synapse Analytics.
- Надежные возможности проверки происхождения данных позволяют реализовать решения, соответствующие требованиям. Сведения о сборе информации о происхождении данных в функции Log Analytics в Azure Monitor, см. в разделе Вопросы отчетности далее в этой статье.
NiFi может выполняться автономно на устройствах с небольшим объемом памяти. В таких случаях NiFi позволяет обрабатывать пограничные данные и перемещать их в более крупные экземпляры NiFi или кластеры в облаке. NiFi помогает фильтровать, преобразовывать пограничные данные и назначать им приоритеты при передаче, обеспечивая надежные и эффективные потоки данных.
Промышленные решения Интернета вещей (IIoT) управляют потоком данных из края в центр обработки данных. Этот поток начинается с получения данных об оборудовании и из систем энергоснабжения предприятия. Затем данные перемещаются в решения по управлению данными и в хранилища MDW. NiFi предлагает возможности, которые делают его оптимальным для получения и перемещения данных:
- Функциональность обработки пограничных данных
- Поддержка протоколов, используемых шлюзами Интернета вещей и устройствами
- Интеграция с Центрами событий Azure и службами хранилища Azure
Приложения Интернета вещей в областях прогнозируемого обслуживания и управления логистическими цепочками могут использовать эту функциональность.

Размер виртуальной машины	Виртуальные ЦП	Память в ГБ	Максимальная пропускная способность диска с некэшированными данными в операциях ввода-вывода в секунду (IOPS) на МБ/с*	Максимальное количество сетевых интерфейсов (NIC) / Ожидаемая пропускная способность сети (Мбит/с)
Standard_D8s_v3	8	32	12 800/192	4/4,000
Standard_D16s_v3**	16	64	25,600/384	8/8,000
Standard_D32s_v3	32	128	51,200/768	8/16,000
Standard_M16m	16	437,5	10,000/250	8/4,000

Хранилище

Различные репозитории NiFi следует хранить на дисках данных, а не на диске ОС по трем основным причинам:

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

В следующих разделах описаны рекомендации по настройке дисков данных. Эти рекомендации относятся только к Azure. Дополнительные сведения о настройке репозиториев см. в разделе Управление состоянием в руководстве системного администратора Apache NiFi.

Тип и размер диска данных

При настройке дисков данных для NiFi учитывайте указанные ниже факторы.

Тип диска
Размер диска
Общее количество дисков

Примечание.

Актуальную информацию о типах дисков, размерах и ценах см. в разделе Введение в управляемые диски Azure.

В следующей таблице приведены типы управляемых дисков, которые в настоящее время доступны в Azure. Вы можете использовать NiFi с любым из этих типов дисков. Но для потоков данных с высокой пропускной способностью рекомендуется использовать SSD (цен. категория "Премиум").

	Хранилище дисков категории "Ультра" (NVM Express (NVMe))	Диск SSD (цен. категория "Премиум")	SSD ценовой категории «Стандартный»	HDD ценовой категории «Стандартный»
Тип диска	SSD	SSD	SSD	HDD
Максимальный размер диска	65,536 ГБ	32,767 ГБ	32,767 ГБ	32,767 ГБ
Максимальная пропускная способность	2000 МиБ/с	900 МиБ/с	750 МиБ/с	500 МиБ/с
Maкс. количество операций ввода-вывода в секунду	160 000	20 000	6000	2 000

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

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

	HDD (цен. категория "Стандартный") для S15	HDD (цен. категория "Стандартный") для S20	HDD (цен. категория "Стандартный") для S30	SSD (цен. категория "Стандартный") для S15	SSD (цен. категория "Стандартный") для S20	SSD (цен. категория "Стандартный") для S30	SSD (цен. категория "Премиум") для P15	SSD (цен. категория "Премиум") для P20	SSD (цен. категория "Премиум") для P30
Размер диска в ГБ	256	512	1024	256	512	1024	256	512	1024
Операции ввода-вывода в секунду на диск	500	500	500	500	500	500	1100	2300	5,000
Пропускная способность на диск	До 60 Мбит/с	До 60 Мбит/с	До 60 Мбит/с	До 60 Мбит/с	До 60 Мбит/с	До 60 Мбит/с	125 Мбит/с	150 Мбит/с	200 Мбит/с

Если система достигает ограничений виртуальной машины, добавление дополнительных дисков может не увеличить пропускную способность:

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

Сведения об ограничениях пропускной способности дисков на уровне виртуальной машины см. в статье Размеры виртуальных машин Linux в Azure.

Кэширование диска виртуальной машины

На виртуальных машинах Azure функция кеширования узла управляет кэшированием записи на диск. Чтобы увеличить пропускную способность дисков данных, используемых для репозиториев, отключите кэширование записи на диск, установив для функции кэширования узла значение None.

Конфигурация репозитория

Рекомендации для NiFi: используйте отдельный диск или диски для каждого из этих репозиториев.

Содержимое
FlowFile
Происхождение

Этот подход требует не менее трех дисков.

NiFi также поддерживает чередование на уровне приложений. Эта функциональность увеличивает размер или производительность репозиториев данных.

Следующий фрагмент взят из файла конфигурации nifi.properties. Эта конфигурация разделяет репозитории и чередует их по управляемым дискам, подключенных к виртуальным машинам.

nifi.provenance.repository.directory.stripe1=/mnt/disk1/ provenance_repository
nifi.provenance.repository.directory.stripe2=/mnt/disk2/ provenance_repository
nifi.provenance.repository.directory.stripe3=/mnt/disk3/ provenance_repository
nifi.content.repository.directory.stripe1=/mnt/disk4/ content_repository
nifi.content.repository.directory.stripe2=/mnt/disk5/ content_repository
nifi.content.repository.directory.stripe3=/mnt/disk6/ content_repository
nifi.flowfile.repository.directory=/mnt/disk7/ flowfile_repository

Дополнительные сведения о разработке высокопроизводительного хранилища см. в статье Хранилище Azure класса "Премиум": разработка, обеспечивающая повышенную производительность

Отчетность

NiFi включает в себя задачу составления отчета о происхождении для функции Log Analytics.

Эту задачу создания отчетов можно использовать для разгрузки событий данных о происхождении в экономически эффективное и долговременное хранилище. Функция Log Analytics предоставляет интерфейс запросов для просмотра и построения графиков отдельных событий. Дополнительные сведения об этих запросах см. в разделе Запросы Log Analytics далее в этой статье.

Эту задачу также можно использовать с энергозависимым хранилищем данных о происхождении в памяти. Во многих сценариях можно добиться увеличения пропускной способности. Но этот подход рискован, если вам нужно сохранить данные о событиях. Убедитесь, что энергозависимое хранилище соответствует требованиям к устойчивости для событий данных о происхождении. Дополнительные сведения см. в разделе Репозиторий данных о происхождении в руководстве системного администратора Apache NiFi.

Перед использованием этого процесса создайте рабочую область Log Analytics в подписке Azure. Лучше настроить рабочую область в том же регионе, что и ваша рабочая нагрузка.

Чтобы настроить задачу составления отчета о происхождении, выполните следующие действия:

Откройте параметры контроллера в NiFi.
Выберите меню "Задачи создания отчета".
Выберите Создать задачу создания отчетов.
Выберите Задача создания отчетов Azure Log Analytics.

На следующем снимке экрана показано меню свойств для этой задачи создания отчетов:

Снимок экрана: окно задачи

Два свойства являются обязательными:

Идентификатор рабочей области Log Analytics
Ключ рабочей области Log Analytics

Вы можете найти эти значения на портале Azure, перейдя в рабочую область Log Analytics.

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

NiFi можно защитить с точки зрения проверки подлинности и авторизации. Вы также можете защитить NiFi для всех сетевых взаимодействий, включая:

Внутри кластера.
Между кластером и ZooKeeper.

Инструкции по включению указанных далее параметров см. в разделе Руководство администратора Apache NiFi.

Kerberos
Протокол LDAP
Проверка подлинности и авторизация на основе сертификатов
Двустороннее SSL для обмена данными между кластерами

Если вы включили безопасный клиентский доступ ZooKeeper, настройте NiFi, добавив соответствующие свойства в его файл конфигурации bootstrap.conf. Пример см. в следующих записях конфигурации:

java.arg.18=-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
java.arg.19=-Dzookeeper.client.secure=true
java.arg.20=-Dzookeeper.ssl.keyStore.location=/path/to/keystore.jks
java.arg.21=-Dzookeeper.ssl.keyStore.password=[KEYSTORE PASSWORD]
java.arg.22=-Dzookeeper.ssl.trustStore.location=/path/to/truststore.jks
java.arg.23=-Dzookeeper.ssl.trustStore.password=[TRUSTSTORE PASSWORD]

Общие рекомендации см. в статье Базовая конфигурация безопасности Linux.

Безопасность сети

При реализации этого решения учитывайте следующие моменты, касающиеся безопасности сети:

Группы безопасности сети

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

Мы рекомендуем Jumpbox для подключения к кластеру NiFi для задач администрирования Используйте эту виртуальную машину с усиленной защитой с доступом JIT или службой Бастион Azure. Настройте группы безопасности сети, чтобы контролировать предоставление доступа к Jumpbox или Бастион Azure. Вы можете добиться изоляции и контроля сети, разумно используя группы безопасности сети в различных подсетях архитектуры.

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

Снимок экрана: таблица, в которой перечислены устройства, типы и подсети компонентов виртуальной сети.

Вопросы исходящего доступа к Интернету

Для работы NiFi в Azure не требуется доступ к общедоступному интернету. Если потоку данных не требуется доступ к Интернету для извлечения данных, улучшите безопасность кластера, выполнив следующие действия, чтобы отключить исходящий доступ к Интернету:

Создайте дополнительное правило группы безопасности сети в виртуальной сети.
Используйте следующие параметры.
- Источник: Any
- Назначение: Internet
- Действие: Deny

Используя это правило, вы по-прежнему можете получить доступ к некоторым службам Azure из потока данных, если вы настроили частную конечную точку в виртуальной сети. Используйте для этой цели частную ссылку Azure. Эта служба позволяет вашему трафику проходить через магистральную сеть Майкрософт, не обращаясь к другим внешним сетевым ресурсам. NiFi в настоящее время поддерживает службу Приватный канал Azure для процессоров Хранилища BLOB-объектов и Azure Data Lake Storage. Если сервер NTP недоступен в частной сети, разрешите исходящий доступ к NTP. Подробные сведения см. в разделе Синхронизация времени для виртуальных машин Linux в Azure.

Защита данных

Можно использовать NiFi без защиты, без шифрования сети, управления удостоверениями и доступом (IAM) или шифрования данных. Но лучше всего обеспечить безопасность производственных и общедоступных облачных развертываний такими способами:

Шифрование подключения с помощью протокола TLS
Использование поддерживаемого механизма проверки подлинности и авторизации
Шифрование неактивных данных

Служба хранилища Azure обеспечивает прозрачное шифрование данных на стороне сервера. Но начиная с версии 1.13.2, NiFi по умолчанию не настраивает шифрование подключения по сети или IAM. Это поведение может измениться в будущих выпусках.

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

Включение шифрования подключения по сети с помощью TLS
Настройка проверки подлинности на основе сертификатов или идентификатора Microsoft Entra
Управление зашифрованным хранилищем в Azure

Шифрование дисков

Для повышения безопасности используйте шифрование дисков Azure. Подробное описание процедур см. в статье Шифрование диска ОС и подключенных дисков данных в масштабируемом наборе виртуальных машин с помощью Azure CLI Этот документ также содержит инструкции по предоставлению собственного ключа шифрования. Ниже приведен пример базового примера для NiFi, который подходит для большинства развертываний.

Чтобы включить шифрование дисков в существующем экземпляре Key Vault, используйте следующую команду Azure CLI:
```
az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
```
Включите шифрование дисков данных масштабируемого набора виртуальных машин с помощью следующей команды:
```
az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
```

При необходимости можно использовать ключ шифрования ключа (KEK). Используйте следующую команду Azure CLI для шифрования с помощью KEK:

az vmss encryption enable --resource-group myResourceGroup --name  myScaleSet  \
--disk-encryption-keyvault myKeyVaultID \
--key-encryption-keyvault myKeyVaultID \
--key-encryption-key https://<mykeyvaultname>.vault.azure.net/keys/myKey/<version> \
--volume-type DATA

Примечание.

Если вы настроили масштабируемый набор виртуальных машин на режим ручного обновления, выполните команду update-instances. Включите версию ключа шифрования, сохраненную в Key Vault.

Шифрование при передаче

NiFi поддерживает TLS версии 1.2 для шифрования при передаче. Этот протокол обеспечивает защиту доступа пользователей к пользовательскому интерфейсу. При использовании кластеров протокол обеспечивает защиту обмена данными между узлами NiFi. Он также может защищать связь с ZooKeeper. При включении TLS NiFi использует взаимную проверку подлинности TLS для взаимной проверки подлинности:

клиента на основе сертификата, если вы настроили этот тип проверки подлинности.
Все связи внутри кластера.

Чтобы включить TLS, выполните указанные ниже действия:

Создайте хранилище ключей и хранилище доверия для связи и проверки подлинности клиент-сервер и внутрикластерной.
Настройка $NIFI_HOME/conf/nifi.properties. Задайте следующие значения:
- Имена узлов
- Порты
- Свойства хранилища ключей
- Свойства хранилища доверия
- Свойства безопасности кластера и ZooKeeper, если применимо
Настройте проверку подлинности в $NIFI_HOME/conf/authorizers.xml, обычно начальный пользователь, который имеет проверку подлинности на основе сертификата или другой вариант.
При необходимости настройте взаимную проверку подлинности TLS и политику чтения прокси-сервера между NiFi и любыми прокси-сервером, подсистемами балансировки нагрузки или внешними конечными точками.

Полное пошаговое руководство см. в разделе Защита NiFi с помощью TLS в документации по проекту Apache.

Примечание.

Начиная с версии 1.13.2:

По умолчанию NiFi не включает TLS.
Для экземпляров NiFi с поддержкой TLS не предусмотрена встроенная поддержка анонимного и однопользовательского доступа.

Чтобы включить TLS для шифрования при передаче, настройте группу пользователей и поставщика политики для проверки подлинности и авторизации в $NIFI_HOME/conf/authorizers.xml. Дополнительные сведения см. в разделе Идентификаторы и управление доступом далее в этой статье.

Сертификаты, ключи и хранилища ключей

Для поддержки протокола TLS создайте сертификаты, храните их в KeyStore Java и в TrustStore а затем распределите их между кластерами NiFi. Существует два общих параметра сертификатов.

Самозаверяющие сертификаты
Сертификаты, подписанные центрами сертификации (ЦС)

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

KeyStore и TrustStore — это контейнеры ключей и сертификатов на платформе Java. Хранилище ключей хранит закрытый ключ и сертификат узла в кластере. TrustStore хранит один из следующих типов сертификатов:

Все доверенные сертификаты для самозаверяющих сертификатов в KeyStore
Сертификат из ЦС, для сертификатов, подписанных ЦС, в KeyStore

При выборе контейнера учитывайте масштабируемость кластера NiFi. Например, может потребоваться увеличить или уменьшить количество узлов в кластере в будущем. В этом случае выберите сертификаты, подписанные ЦС, в KeyStore и один или несколько сертификатов из центра сертификации в TrustStore. В этом случае нет необходимости обновлять существующие TrustStore в существующих узлах кластера. Существующий TrustStore доверяет сертификатам от указанных далее типов узлов и принимает их.

Узлы, добавляемые в кластер
Узлы, которые заменяют другие узлы в кластере

Конфигурация NiFi

Чтобы включить TLS для NiFi, используйте $NIFI_HOME/conf/nifi.properties для настройки свойств в этой таблице. Убедитесь, что следующие свойства включают имя узла, которое используется для доступа к NiFi:

nifi.web.https.host или nifi.web.proxy.host
Назначенное имя сертификата узла или альтернативные имена субъектов

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

Имя свойства	Description	Пример значений
`nifi.web.https.host`	Имя узла или IP-адрес, используемые для пользовательского интерфейса и REST API. Это значение должно быть разрешаемым изнутри. Мы не рекомендуем использовать общедоступное имя.	`nifi.internal.cloudapp.net`
`nifi.web.https.port`	Порт HTTPS, используемый для пользовательского интерфейса и REST API.	`9443` (по умолчанию)
`nifi.web.proxy.host`	Список альтернативных имен узлов, которые клиенты используют для доступа к пользовательскому интерфейсу и REST API, разделенный запятыми. В этот список обычно входит любое имя узла, указанное в качестве альтернативного имени субъекта (SAN) в сертификате сервера. Этот список может также включать любое имя узла и порт, используемые подсистемой балансировки нагрузки, прокси-сервером или контроллером объекта ingress Kubernetes.	`40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443`
`nifi.security.keystore`	Путь к хранилищу ключей JKS или PKCS12, содержащему закрытый ключ сертификата.	`./conf/keystore.jks`
`nifi.security.keystoreType`	Тип хранилища ключей.	`JKS` или `PKCS12`
`nifi.security.keystorePasswd`	Пароль хранилища ключей.	`O8SitLBYpCz7g/RpsqH+zM`
`nifi.security.keyPasswd`	(Необязательно) Пароль для закрытого ключа.
`nifi.security.truststore`	Путь к хранилищу доверия JKS или PKCS12, который содержит сертификаты или сертификаты ЦС, удостоверяющие подлинность доверенных пользователей и узлов кластера.	`./conf/truststore.jks`
`nifi.security.truststoreType`	Тип хранилища доверия.	`JKS` или `PKCS12`
`nifi.security.truststorePasswd`	Пароль хранилища доверия.	`RJlpGe6/TuN5fG+VnaEPi8`
`nifi.cluster.protocol.is.secure`	Состояние TLS для связи внутри кластера. Если `nifi.cluster.is.node` имеет значение `true`, установите это значение на `true`, чтобы включить TLS кластера.	`true`
`nifi.remote.input.secure`	Состояние TLS для связи типа "сеть — сеть".	`true`

В следующем примере показано, как эти свойства отображаются в $NIFI_HOME/conf/nifi.properties. Обратите внимание, что значения nifi.web.http.host и nifi.web.http.port пустые.

nifi.remote.input.secure=true
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=nifi.internal.cloudapp.net
nifi.web.https.port=9443
nifi.web.proxy.host=40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore=./conf/keystore.jks 
nifi.security.keystoreType=JKS          
nifi.security.keystorePasswd=O8SitLBYpCz7g/RpsqH+zM                  
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks                                   
nifi.security.truststoreType=JKS
nifi.security.truststorePasswd=RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure=true

Конфигурация ZooKeeper

Инструкции по включению протокола TLS в Apache ZooKeeper для связи с кворумом и доступа клиентов см. в Руководстве администратора ZooKeeper. Эта функция поддерживается в версии 3.5.5 и более поздних версий.

NiFi использует ZooKeeper для кластеризации без основных кластеров и для координации кластеров. Начиная с версии 1.13.0, NiFi поддерживает безопасный клиентский доступ к экземплярам ZooKeeper с поддержкой TLS. ZooKeeper хранит данные о принадлежности к кластеру и состоянии процессора для области кластера только в текстовом формате. Поэтому важно использовать безопасный клиентский доступ к ZooKeeper для проверки подлинности запросов клиентов ZooKeeper. Также следует шифровать конфиденциальные значения при передаче.

Чтобы включить TLS для доступа клиентов NiFi к ZooKeeper, настройте следующие свойства в $NIFI_HOME/conf/nifi.properties. Если вы не настраиваете nifi.zookeeper.client.secure true свойства, NiFi возвращается в хранилище ключей и хранилище доверия nifi.zookeeper.security , указанное в nifi.securityproperties.

Имя свойства	Description	Пример значений
`nifi.zookeeper.client.secure`	Состояние клиента TLS при подключении к ZooKeeper.	`true`
`nifi.zookeeper.security.keystore`	Путь к хранилищу ключей JKS, PKCS12 или PEM, содержащему закрытый ключ сертификата, который представлен ZooKeeper для проверки подлинности.	`./conf/zookeeper.keystore.jks`
`nifi.zookeeper.security.keystoreType`	Тип хранилища ключей.	`JKS`, `PKCS12`, `PEM`, или автоматическое определение по расширению
`nifi.zookeeper.security.keystorePasswd`	Пароль хранилища ключей.	`caB6ECKi03R/co+N+64lrz`
`nifi.zookeeper.security.keyPasswd`	(Необязательно) Пароль для закрытого ключа.
`nifi.zookeeper.security.truststore`	Путь к хранилищу доверия JKS, PKCS12 или PEM, который содержит сертификаты или сертификаты ЦС, используемые для проверки подлинности ZooKeeper.	`./conf/zookeeper.truststore.jks`
`nifi.zookeeper.security.truststoreType`	Тип хранилища доверия.	`JKS`, `PKCS12`, `PEM`, или автоматическое определение по расширению
`nifi.zookeeper.security.truststorePasswd`	Пароль хранилища доверия.	`qBdnLhsp+mKvV7wab/L4sv`
`nifi.zookeeper.connect.string`	Строка подключения к узлу ZooKeeper или кворуму. Эта строка представляет собой список значений `host:port`, разделенных запятыми. Обычно значение `secureClientPort` не совпадает со значением `clientPort`. Правильное значение см. в конфигурации ZooKeeper.	`zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281`

В следующем примере показано, как эти свойства отображаются в $NIFI_HOME/conf/nifi.properties.

nifi.zookeeper.client.secure=true
nifi.zookeeper.security.keystore=./conf/keystore.jks
nifi.zookeeper.security.keystoreType=JKS
nifi.zookeeper.security.keystorePasswd=caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd=
nifi.zookeeper.security.truststore=./conf/truststore.jks
nifi.zookeeper.security.truststoreType=JKS
nifi.zookeeper.security.truststorePasswd=qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string=zookeeper1.internal.cloudapp.net:2281,zookeeper2.internal.cloudapp.net:2281,zookeeper3.internal.cloudapp.net:2281

Дополнительные сведения о защите ZooKeeper с помощью TLS см. в Руководстве по администрированию Apache NiFi.

Управление доступом и удостоверениями

В NiFi идентификация и управление доступом осуществляются с помощью проверки подлинности и авторизации пользователя. Для проверки подлинности пользователей NiFi предлагает несколько вариантов на выбор: один пользователь, протокол LDAP, Kerberos, язык разметки зявлений системы безопасности (SAML) и OpenID Connect (OIDC). Если вы не настроите параметр, NiFi использует сертификаты клиента для проверки подлинности пользователей по протоколу HTTPS.

Если вы рассматриваете многофакторную проверку подлинности, рекомендуется использовать сочетание идентификатора Microsoft Entra и OIDC. Идентификатор Microsoft Entra поддерживает единый вход в облако (SSO) с помощью OIDC. Благодаря этому сочетанию пользователи могут воспользоваться преимуществами многих функций обеспечения корпоративной безопасности:

Ведение журнала и оповещение о подозрительных действиях с учетных записей пользователей
Отслеживание попыток доступа к отключенным учетным записям
Оповещение о необычном поведении при входе в учетную запись

Для авторизации NiFi обеспечивает принудительное применение защиты на основе политик пользователя, группы и доступа. NiFi обеспечивает это принудительное применение защиты с помощью UserGroupProviders и AccessPolicyProviders. Стандартными поставщиками являются файл, LDAP, Shell и UserGroupProviders на основе Azure Graph. С помощью AzureGraphUserGroupProvider можно использовать исходные группы пользователей из идентификатора Microsoft Entra. Затем можно назначить политики для этих групп. Инструкции по настройке см. в Руководстве по администрированию Apache NiFi.

AccessPolicyProviders, основанные на файлах и Apache Ranger, в настоящее время доступны для хранения пользовательских и групповых политик и управления ими. Подробные сведения см. в документации по Apache NiFi и документации по Apache Ranger.

Шлюз приложений

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

Для большинства установок NiFi рекомендуется использовать следующую конфигурацию Шлюза приложений:

Уровень: стандартный
Размер SKU: средний
Число экземпляров: два или более

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

Есть две основные пробы работоспособности, которые следует учитывать. Вместе они обеспечивают регулярный пакет пульса для общей работоспособности каждого узла в кластере. Настройте первую пробу работоспособности, чтобы она указывала на путь /NiFi. Эта проверка определяет работоспособность пользовательского интерфейса NiFi на каждом узле. Настройте вторую пробу работоспособности для пути /nifi-api/controller/cluster. Эта проба показывает, является ли каждый узел работоспособным и присоединен ли он к общему кластеру.

У вас есть два варианта настройки внешнего IP-адреса шлюза приложений:

С общедоступным IP-адресом
С IP-адресом частной подсети

Включайте общедоступный IP-адрес только в том случае, если пользователям необходим доступ к пользовательскому интерфейсу через общедоступный Интернет. Если доступ к общедоступному Интернету пользователям не требуется, откройте доступ к интерфейсу подсистемы балансировки нагрузки из Jumpbox в виртуальной сети или через пиринг с частной сетью. При настройке шлюза приложений с общедоступным IP-адресом рекомендуется включить проверку подлинности сертификата клиента для NiFi и включить TLS для пользовательского интерфейса NiFi. Вы также можете использовать группу безопасности сети в подсети шлюза делегированных приложений, чтобы ограничить IP-адреса источника.

Диагностика и отслеживание работоспособности

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

Учетная запись хранения
Event Hubs
Рабочая область Log Analytics

Включение этого параметра полезно для отладки проблем с балансировкой нагрузки и получения сведений о работоспособности узлов кластера.

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

AzureDiagnostics
| summarize UnHealthyNodes = max(unHealthyHostCount_d), HealthyNodes = max(healthyHostCount_d) by bin(TimeGenerated, 5m)
| render timechart

На следующей диаграмме результатов запроса показано временную информацию о работоспособности кластера.

Availability

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

Подсистема балансировки нагрузки

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

Отдельные виртуальные машины

Чтобы повысить доступность, разверните кластер ZooKeeper на отдельных виртуальных машинах из виртуальных машин в кластере NiFi. Дополнительные сведения о настройке ZooKeeper см. в разделе Управление состоянием в руководстве системного администратора Apache NiFi.

Зоны доступности

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

Масштабируемые наборы виртуальных машин

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

Наблюдение

Чтобы отслеживать работоспособность и производительность кластера NiFi, используйте задачи создания отчетов.

Мониторинг на основе задач создания отчетов

Для мониторинга можно использовать задачу создания отчетов, настроенную и выполняемую в NiFi. Как говорится в статье Наблюдение за работоспособностью системы и диагностика, Log Analytics обеспечивает задачу создания отчетов в пакете NiFi Azure. Эту задачу создания отчетов можно использовать для интеграции мониторинга с Log Analytics и существующими системами мониторинга или ведения журналов.

Запросы Log Analytics

Примеры запросов, приведенные в следующих разделах, помогут вам приступить к работе. Общие сведения о запросах данных Log Analytics см. в разделе Запросы журнала Azure Monitor.

Запросы журналов в Monitor и Log Analytics используют версию язык запросов Kusto. Однако существуют различия между запросами журнала и запросами Kusto. Дополнительные сведения см. в разделе Общие сведения о запросах Kusto.

Для более структурированного обучения см. учебники:

Задача создания отчетов Log Analytics

По умолчанию NiFi отправляет данные метрик в таблицу nifimetrics. Однако можно настроить другое назначение в свойствах задачи создания отчетов. Задача создания отчетов записывает следующие метрики NiFi:

Тип метрики	Имя метрики
Метрики NiFi	`FlowFilesReceived`
Метрики NiFi	`FlowFilesSent`
Метрики NiFi	`FlowFilesQueued`
Метрики NiFi	`BytesReceived`
Метрики NiFi	`BytesWritten`
Метрики NiFi	`BytesRead`
Метрики NiFi	`BytesSent`
Метрики NiFi	`BytesQueued`
Метрики состояния порта	`InputCount`
Метрики состояния порта	`InputBytes`
Метрики состояния подключения	`QueuedCount`
Метрики состояния подключения	`QueuedBytes`
Метрики состояния порта	`OutputCount`
Метрики состояния порта	`OutputBytes`
Метрики виртуальных машин Java (JVM)	`jvm.uptime`
Метрики виртуальной машины Java	`jvm.heap_used`
Метрики виртуальной машины Java	`jvm.heap_usage`
Метрики виртуальной машины Java	`jvm.non_heap_usage`
Метрики виртуальной машины Java	`jvm.thread_states.runnable`
Метрики виртуальной машины Java	`jvm.thread_states.blocked`
Метрики виртуальной машины Java	`jvm.thread_states.timed_waiting`
Метрики виртуальной машины Java	`jvm.thread_states.terminated`
Метрики виртуальной машины Java	`jvm.thread_count`
Метрики виртуальной машины Java	`jvm.daemon_thread_count`
Метрики виртуальной машины Java	`jvm.file_descriptor_usage`
Метрики виртуальной машины Java	`jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation`
Метрики виртуальной машины Java	`jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation`
Метрики виртуальной машины Java	`jvm.buff_pool_direct_capacity`
Метрики виртуальной машины Java	`jvm.buff_pool_direct_count`
Метрики виртуальной машины Java	`jvm.buff_pool_direct_mem_used`
Метрики виртуальной машины Java	`jvm.buff_pool_mapped_capacity`
Метрики виртуальной машины Java	`jvm.buff_pool_mapped_count`
Метрики виртуальной машины Java	`jvm.buff_pool_mapped_mem_used`
Метрики виртуальной машины Java	`jvm.mem_pool_code_cache`
Метрики виртуальной машины Java	`jvm.mem_pool_compressed_class_space`
Метрики виртуальной машины Java	`jvm.mem_pool_g1_eden_space`
Метрики виртуальной машины Java	`jvm.mem_pool_g1_old_gen`
Метрики виртуальной машины Java	`jvm.mem_pool_g1_survivor_space`
Метрики виртуальной машины Java	`jvm.mem_pool_metaspace`
Метрики виртуальной машины Java	`jvm.thread_states.new`
Метрики виртуальной машины Java	`jvm.thread_states.waiting`
Метрики уровня процессора	`BytesRead`
Метрики уровня процессора	`BytesWritten`
Метрики уровня процессора	`FlowFilesReceived`
Метрики уровня процессора	`FlowFilesSent`

Ниже приведен пример запроса для метрики BytesQueued кластера.

let table_name = nifimetrics_CL;
let metric = "BytesQueued";
table_name
| where Name_s == metric
| where Computer contains {ComputerName}
| project TimeGenerated, Computer, ProcessGroupName_s,  Count_d, Name_s
| summarize sum(Count_d) by bin(TimeGenerated, 1m),  Computer, Name_s
| render timechart

Этот запрос создает диаграмму, подобную представленной на снимке экрана:

Примечание.

При выполнении NiFi в Azure, вы не ограничены задачей создания отчетов Log Analytics. NiFi поддерживает задачи создания отчетов для многих сторонних технологий мониторинга. Список поддерживаемых задач составления отчетов см. в разделе Задачи создания отчетов в Документации по Apache NiFi (индекс).

Инфраструктура мониторинга NiFi

Помимо задачи создания отчета установите Расширение виртуальной машины Log Analytics на узлах NiFi и ZooKeeper. Это расширение собирает журналы, дополнительные метрики уровня виртуальной машины и метрики из ZooKeeper.

Пользовательские журналы для приложения NiFi, пользователя, начальной загрузки и ZooKeeper

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

На портале Azure выберите Рабочие области Log Analytics, а затем выберите рабочую область.
В разделе Параметры выберите Пользовательские журналы.
Выберите Добавить пользовательский журнал.
Настройте пользовательский журнал со следующими значениями:
- Имя: NiFiAppLogs
- Тип пути: Linux
- Имя пути: /opt/nifi/logs/nifi-app.log
Настройте пользовательский журнал со следующими значениями:
- Имя: NiFiBootstrapAndUser
- Тип первого пути: Linux
- Имя первого пути: /opt/nifi/logs/nifi-user.log
- Тип второго пути: Linux
- Имя второго пути: /opt/nifi/logs/nifi-bootstrap.log
Настройте пользовательский журнал со следующими значениями:
- Имя: NiFiZK
- Тип пути: Linux
- Имя пути: /opt/zookeeper/logs/*.out

Ниже приведен пример запроса NiFiAppLogs к пользовательской таблице, созданной в первом примере.

NiFiAppLogs_CL
| where TimeGenerated > ago(24h)
| where Computer contains {ComputerName} and RawData contains "error"
| limit 10

Этот запрос возвращает результаты, аналогичные приведенным ниже.

Конфигурация инфраструктуры журналов

Monitor можно использовать для отслеживания виртуальных машин или физических компьютеров, а также для управления ими. Эти ресурсы могут находиться в вашем локальном центре обработки данных или в другой облачной среде. Чтобы настроить это отслеживание, разверните агент Log Analytics. Настройте агент для создания и передачи отчетов в рабочую область Log Analytics. Дополнительные сведения см. в обзоре агентов Log Analytics.

На следующем снимке экрана показан пример конфигурации агента для виртуальных машин NiFi. Собранные данные хранятся в таблице Perf.

Ниже приведен пример запроса для журналов приложений Perf NiFi.

let cluster_name = {ComputerName};
// The hourly average of CPU usage across all computers.
Perf
| where Computer contains {ComputerName}
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| where ObjectName == "Processor"
| summarize CPU_Time_Avg = avg(CounterValue) by bin(TimeGenerated, 30m), Computer

Этот запрос создает отчет, подобный представленному на снимке экрана:

видны узлы

Используйте Monitor для создания оповещений о работоспособности и производительности кластера NiFi. Примеры оповещений:

Общее количество очередей превысило пороговое значение.
Значение BytesWritten ниже ожидаемого порогового значения.
Значение FlowFilesReceived ниже порогового значения.
Кластер в неработоспособном состоянии.

Дополнительные сведения о настройке оповещений в Monitor см. в разделе Обзор оповещений в Microsoft Azure.

Параметры конфигурации

В следующих разделах рассматриваются рекомендуемые, и не используемые по умолчанию конфигурации NiFi и зависимости службы, включая ZooKeeper и Java. Эти параметры подходят для размеров кластера, которые можно использовать в облаке. Задайте свойства в следующих файлах конфигурации:

$NIFI_HOME/conf/nifi.properties
$NIFI_HOME/conf/bootstrap.conf
$ZOOKEEPER_HOME/conf/zoo.cfg
$ZOOKEEPER_HOME/bin/zkEnv.sh

Подробные сведения о доступных свойствах и файлах конфигурации см. в Руководстве системного администратора Apache NiFi и Руководстве администратора ZooKeeper.

NiFi

Для развертывания Azure рассмотрите возможность настройки свойств в $NIFI_HOME/conf/nifi.properties. В следующей таблице перечислены наиболее важные свойства. Дополнительные рекомендации и подробные сведения см. в списках рассылки Apache NiFi.

Параметр	Описание	По умолч.	Рекомендация
`nifi.cluster.node.connection.timeout`	Время ожидания при открытии подключения к другим узлам кластера.	5 секунд	60 секунд
`nifi.cluster.node.read.timeout`	Время ожидания ответа при выполнении запроса к другим узлам кластера.	5 секунд	60 секунд
`nifi.cluster.protocol.heartbeat.interval`	Частота отправки пакетов пульса обратно в координатор кластера.	5 секунд	60 секунд
`nifi.cluster.node.max.concurrent.requests`	Уровень параллелизма, используемый при репликации вызовов HTTP, например вызовы REST API к другим узлам кластера.	100	500
`nifi.cluster.node.protocol.threads`	Начальный размер пула потоков для межкластерных и реплицированных связей.	10	50
`nifi.cluster.node.protocol.max.threads`	Максимальное количество потоков для межкластерных и реплицированных соединений.	50	75
`nifi.cluster.flow.election.max.candidates`	Количество узлов, используемых при принятии решения о текущем потоке. Это значение кратко передает голосование по указанному номеру.	empty	75
`nifi.cluster.flow.election.max.wait.time`	Время ожидания узлов перед принятием решения о текущем потоке.	5 мин	5 мин

Поведение кластера

При настройке кластеров учитывайте некоторые моменты.

Время ожидания

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

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

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

nifi.cluster.node.connection.timeout и nifi.cluster.node.read.timeout

Свойство nifi.cluster.node.connection.timeout определяет время ожидания при открытии подключения. Свойство nifi.cluster.node.read.timeout определяет время ожидания при получении данных между запросами. Значение по умолчанию для каждого свойства составляет 5 секунд. Эти свойства применяются к запросам между узлами. Увеличение этих значений помогает устранить несколько связанных с этим проблем:

Отключение координатором кластера из-за прерывания пульса
Не удалось получить поток от координатора при присоединении к кластеру
Установка связи "сеть — сеть" и балансировки нагрузки

Если только ваш кластер не имеет очень маленький масштабируемый набор, например, три узла или меньше, используйте значения, превышающие значения по умолчанию.

nifi.cluster.protocol.heartbeat.interval

В рамках стратегии кластеризации NiFi каждый узел создает пакет пульса, чтобы сообщить о своем работоспособном состоянии. По умолчанию узлы отправляют пакеты пульса каждые пять секунд. Если координатор кластера обнаружит, что восемь пакетов пульса в строке с узла не сработали, он отключает узел. Увеличьте интервал, заданный в свойстве nifi.cluster.protocol.heartbeat.interval, чтобы справиться с медленными сигналами пакетов пульса и предотвратить ненужное отключение узлов в кластере.

Параллелизм

Используйте свойства в следующих разделах для настройки параметров параллелизма:

nifi.cluster.node.protocol.threads и nifi.cluster.node.protocol.max.threads

Свойство nifi.cluster.node.protocol.max.threads определяет максимальное количество потоков, используемых для связи между всеми кластерами, например, балансировка нагрузки подключения типа "сеть-сеть" и агрегирование пользовательского интерфейса. Значение по умолчанию для этого свойства — 50 потоков. Для больших кластеров увеличьте это значение, чтобы учесть большее количество запросов, которые требуют эти операции.

Свойство nifi.cluster.node.protocol.threads определяет начальный размер пула потоков. Значение по умолчанию — 10 потоков. Это значение является минимальным. Оно растет по мере необходимости до максимального, заданного в nifi.cluster.node.protocol.max.threads. Увеличьте значение nifi.cluster.node.protocol.threads для кластеров, использующих большой масштабируемый набор при запуске.

nifi.cluster.node.max.concurrent.requests

Многие HTTP-запросы, такие как вызовы REST API и вызовы пользовательского интерфейса, необходимо реплицировать на другие узлы в кластере. По мере роста размера кластера увеличивается количество запросов, которые реплицируются. Свойство nifi.cluster.node.max.concurrent.requests ограничивает количество невыполненных запросов. Его значение должно превышать ожидаемый размер кластера. Значение по умолчанию — 100 параллельных запросов. Если вы не используете небольшой кластер, состоящий из трех или менее узлов, предотвращайте неудачные запросы, увеличивая это значение.

Выбор потока

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

nifi.cluster.flow.election.max.candidates

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

По умолчанию свойство nifi.cluster.flow.election.max.candidates является максимальным временем ожидания, которое задается свойством nifi.cluster.flow.election.max.wait.time. Если это значение слишком велико, запуск может выполняться медленно. Значение по умолчанию для nifi.cluster.flow.election.max.wait.time — пять минут. Задайте для максимального количества кандидатов непустое значение, например 1 или больше, чтобы время ожидания не превышало необходимое. Если вы устанавливаете это свойство, присвойте ему значение, соответствующее размеру кластера или какой-либо мажоритарной части ожидаемого размера кластера. Для небольших статических кластеров из 10 или менее узлов установите это значение равным количеству узлов в кластере.

nifi.cluster.flow.election.max.wait.time

В эластичной облачной среде время подготовки узлов влияет на время запуска приложения. Свойство nifi.cluster.flow.election.max.wait.time определяет, как долго NiFi ожидает, прежде чем принять решение о потоке. Сделайте это значение сравнимым с общим временем запуска кластера при его начальном размере. При первоначальном тестировании пяти минут оказалось более чем достаточно во всех регионах Azure с рекомендуемыми типами экземпляров. Но вы можете увеличить это значение, если время подготовки к работе регулярно превышает значение по умолчанию.

Java

Мы рекомендуем использовать Выпуск LTS Java. Из этих выпусков Java 11 немного предпочтительнее Java 8, поскольку Java 11 поддерживает более быструю реализацию сборки мусора. Тем не менее, вполне возможно обеспечить высокопроизводительное развертывание NiFi, используя любой из выпусков.

В следующих разделах рассматриваются распространенные конфигурации виртуальной машины Java, которые следует использовать при выполнении NiFi. Укажите параметры виртуальной машины Java в файле конфигурации начальной загрузки по адресу $NIFI_HOME/conf/bootstrap.conf.

Мусорщик

Если вы используете Java 11, мы рекомендуем использовать сборщик мусора G1 (G1GC) в большинстве ситуаций. Производительность G1GC выше, чем у ParallelGC, поскольку G1GC сокращает длительность приостановок процесса сборки мусора. G1GC используется по умолчанию в Java 11, но его можно явно настроить, установив следующее значение в bootstrap.conf:

java.arg.13=-XX:+UseG1GC

Если вы используете Java 8, не используйте G1GC. Вместо этого используйте ParallelGC. В реализации G1GC в Java 8 есть недостатки, которые не позволяют использовать его с рекомендованными реализациями репозитория. ParallelGC работает медленнее, чем G1GC. Но с ParallelGC все еще можно обеспечить высокопроизводительное развертывание NiFi с помощью Java 8.

Куча

Набор свойств в файле bootstrap.conf определяет конфигурацию кучи виртуальной машины Java NiFi. Для стандартного потока настройте кучу размером 32 ГБ, используя эти параметры:

java.arg.3=-Xmx32g
java.arg.2=-Xms32g

Чтобы выбрать оптимальный размер кучи для применения к процессу виртуальной машины Java, учитывайте два фактора:

Характеристики потока данных
То, как NiFi использует память при обработке данных

Подробную документацию см. в статье Глубокое изучение Apache NiFi.

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

При настройке параметров памяти виртуальной машины Java учитывайте эти важные факторы:

Количество FlowFiles, или записей данных NiFi, которые активны в заданный период времени. Это число включает в себя файлы FlowFiles с обратной реакцией или очередью.
Количество атрибутов, определенных в FlowFiles.
Объем памяти, который требуется процессору для обработки определенного фрагмента содержимого.
Способ обработки данных процессором:
- Потоковая передача данных
- Использование процессоров, ориентированных на запись
- Одновременное удержание всех данных в памяти

Эти детали очень важны. Во время обработки NiFi хранит в памяти ссылки и атрибуты для каждого FlowFile. При пиковой производительности объем памяти, используемой системой, пропорционален количеству активных файлов FlowFiles и всех содержащихся в них атрибутов. В это число входят файлы FlowFiles, поставленные в очередь. NiFi может переключиться на диск. Но не используйте этот параметр, поскольку он снижает уровень производительности.

Также не забывайте о базовом использовании памяти для объектов. В частности сделайте вашу кучу достаточно большой, чтобы удерживать объекты в памяти. Рассмотрите эти советы по настройке параметров памяти:

Запустите свой поток с репрезентативными данными и минимальной обратной реакцией, начав с параметра -Xmx4G и затем осмотрительно увеличивая память по мере необходимости.
Запустите свой поток с репрезентативными данными и максимальной обратной реакцией, начав с параметра -Xmx4G и затем осмотрительно увеличивая размер кластера пом мере необходимости.
Профилируйте приложение во время выполнения последовательности с помощью таких инструментов, как VisualVM и YourKit.
Если осмотрительное увеличение объема кучи не приводит к значительному повышению производительности, подумайте о перепроектировании потоков, процессоров и других аспектов вашей системы.

Дополнительные параметры виртуальной машины Java

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

Параметр	Описание	Виртуальная машина Java по умолчанию	Рекомендация
`InitiatingHeapOccupancyPercent`	Объем кучи, используемый до срабатывания цикла маркировки.	45	35
`ParallelGCThreads`	Количество потоков, используемых процессом сборки мусора. Это значение ограничено, чтобы ограничить общее влияние на систему.	5/8 от количества виртуальных ЦП	8
`ConcGCThreads`	Количество потоков сборки мусора, которые должны выполняться параллельно. Это значение увеличивается для учета ограниченных ParallelGCThreads.	1/4 от значения `ParallelGCThreads`	4
`G1ReservePercent`	Процент резервной памяти, которая должна оставаться свободной. Это значение увеличивается, чтобы избежать исчерпания свободного пространства, что помогает избежать полной сборки мусора.	10	20
`UseStringDeduplication`	Указывает, следует ли пытаться определить и отменить дублирование ссылок в идентичные строки. Включение этой функции может обеспечить экономию памяти.	-	Подарок

Настройте эти параметры, добавив следующие записи в NiFi bootstrap.conf:

java.arg.17=-XX:+UseStringDeduplication
java.arg.18=-XX:G1ReservePercent=20
java.arg.19=-XX:ParallelGCThreads=8
java.arg.20=-XX:ConcGCThreads=4
java.arg.21=-XX:InitiatingHeapOccupancyPercent=35

ZooKeeper

Для повышения уровня отказоустойчивости запускайте ZooKeeper как кластер. Используйте этот подход, даже если большинство развертываний NiFi создают относительно небольшую нагрузку на ZooKeeper. Включите кластеризацию для ZooKeeper явным образом. По умолчанию ZooKeeper работает в режиме отдельного сервера. Подробную информацию см. в разделе Кластерная (многосерверная) настройка в Руководстве администратора ZooKeeper.

За исключением параметров кластеризации, используйте значения по умолчанию для конфигурации ZooKeeper.

Если у вас большой кластер NiFi, может потребоваться использовать большее количество серверов ZooKeeper. Для меньших размеров кластера достаточно небольших размеров виртуальных машин и управляемых дисков SSD (цен. категория "Стандартный").

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

Муазма Захид | Главный диспетчер PM

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Материалы и рекомендации, приведенные в этом документе, взяты из нескольких источников:

Экспериментирование
Рекомендации для Azure
Знания сообщества NiFi, рекомендации и документация

Дополнительные сведения см. на следующих ресурсах:

Поделиться через

Apache NiFi в Azure

Архитектура

Рабочий процесс

Компоненты

Альтернативные варианты

Подробности сценария

Потенциальные варианты использования

Рекомендации

Рекомендуемые версии NiFi

Рекомендуемые версии ZooKeeper

Рекомендации

Оптимизация затрат

Рекомендации по работе с виртуальными машинами

Размер виртуальной машины

Операционная система (ОС) виртуальной машины:

Хранилище

Тип и размер диска данных

Кэширование диска виртуальной машины

Конфигурация репозитория

Отчетность

Безопасность

Безопасность сети

Группы безопасности сети

Вопросы исходящего доступа к Интернету

Защита данных

Шифрование дисков

Шифрование при передаче

Сертификаты, ключи и хранилища ключей

Конфигурация NiFi

Конфигурация ZooKeeper

Управление доступом и удостоверениями

Шлюз приложений

Диагностика и отслеживание работоспособности

Availability

Подсистема балансировки нагрузки

Отдельные виртуальные машины

Зоны доступности

Масштабируемые наборы виртуальных машин

Наблюдение

Мониторинг на основе задач создания отчетов

Запросы Log Analytics

Задача создания отчетов Log Analytics

Инфраструктура мониторинга NiFi

Пользовательские журналы для приложения NiFi, пользователя, начальной загрузки и ZooKeeper

Конфигурация инфраструктуры журналов

видны узлы

Параметры конфигурации

NiFi

Поведение кластера

Время ожидания

nifi.cluster.node.connection.timeout и nifi.cluster.node.read.timeout

nifi.cluster.protocol.heartbeat.interval

Параллелизм

nifi.cluster.node.protocol.threads и nifi.cluster.node.protocol.max.threads

nifi.cluster.node.max.concurrent.requests

Выбор потока

nifi.cluster.flow.election.max.candidates

nifi.cluster.flow.election.max.wait.time

Java

Мусорщик

Куча

Дополнительные параметры виртуальной машины Java

ZooKeeper

Соавторы

Следующие шаги

Связанные ресурсы

Обратная связь

Дополнительные ресурсы