Apache NiFi no Azure

Esse exemplo de cenário mostra como executar o Apache NiFi no Azure. O NiFi fornece um sistema para processamento e distribuição de dados.

Apache®, Apache NiFi® e NiFi® são marcas registradas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou em outros países. O uso desta marca não implica aprovação por parte da Apache Software Foundation.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

• O aplicativo NiFi é executado em VMs em nós de cluster NiFi. As VMs estão em um conjunto de dimensionamento de máquinas virtuais que a configuração implanta em zonas de disponibilidade.

• O Apache ZooKeeper é executado em VMs em um cluster separado. O NiFi usa o cluster ZooKeeper para estas finalidades:

  • Escolher um nó de coordenador de cluster
  • Coordenar o fluxo de dados

• O Gateway de Aplicativo do Azure fornece balanceamento de carga de camada 7 para a interface do usuário executada nos nós NiFi.

• O Monitor e seu recurso Log Analytics coletam, analisam e atuam na telemetria do sistema NiFi. A telemetria inclui logs do sistema NiFi e métricas de integridade do sistema e de desempenho.

• O Azure Key Vault armazena certificados e chaves com segurança para o cluster NiFi.

• O Microsoft Entra ID fornece autenticação multifator e de login único.

Componentes

• O NiFi fornece um sistema para processamento e distribuição de dados.
• O ZooKeeper é um servidor de código aberto que gerencia sistemas distribuídos.
• As Máquinas Virtuais são uma oferta de IaaS (infraestrutura como serviço). Você pode usar as Máquinas Virtuais para implantar, sob demanda, recursos de computação escalonáveis. As Máquinas Virtuais oferecem flexibilidade de virtualização, mas eliminam as demandas de manutenção do hardware físico.
• Os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure permitem gerenciar um grupo de VMs com balanceamento de carga. O número de instâncias de VM em um conjunto pode aumentar ou diminuir automaticamente em resposta à demanda ou a um agendamento definido.
• As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Essas ofertas de alta disponibilidade protegem aplicativos e dados contra falhas do data center.
• O Gateway de Aplicativo é um balanceador de carga que gerencia o tráfego para aplicativos Web.
• O Monitor coleta e analisa dados em ambientes e recursos do Azure. Esses dados incluem telemetria de aplicativo, como métricas de desempenho e logs de atividade. Para obter mais informações, consulte Considerações sobre monitoramento, adiante neste artigo.
• O Log Analytics é uma ferramenta de portal do Azure que executa consultas no monitoramento de dados de log. O Log Analytics também oferece recursos para criação de gráficos e análise estatística dos resultados de consultas.
• O Azure DevOps Services fornece serviços, ferramentas e ambientes para o gerenciamento de projetos de codificação e implantações.
• O Key Vault armazena e controla com segurança o acesso a segredos do sistema como chaves de API, senhas, certificados e chaves de criptografia.
• O Microsoft Entra ID é um serviço de identidade baseado em nuvem que controla o acesso ao Azure e a outros aplicativos de nuvem.

Alternativas

• O Azure Data Factory fornece uma alternativa para essa solução.
• Em vez do Key Vault, você pode usar um serviço comparável para armazenar segredos do sistema.
• Airflow do Apache. Veja como o Airflow e o NiFi são diferentes.
• É possível usar uma alternativa ao NiFi corporativo com suporte, como o Apache NiFi do Cloudera. A oferta do Cloudera está disponível no Azure Marketplace.

Detalhes do cenário

Nesse cenário, o NiFi é executado em uma configuração clusterizada em Máquinas Virtuais do Azure, em um conjunto de dimensionamento. Mas a maioria das recomendações deste artigo também se aplica a cenários que executem o NiFi no modo de instância única, em uma única VM (máquina virtual). As práticas recomendadas neste artigo demonstram uma implantação escalonável, com alta disponibilidade e segura.

Possíveis casos de uso

O NiFi funciona bem para mover dados e gerenciar o fluxo de dados:

• Conectando sistemas separados na nuvem
• Inserindo e retirando dados do Armazenamento do Azure e de outros armazenamentos de dados
• Integrando aplicativos da borda para a nuvem e de nuvem híbrida com o Azure IoT, Azure Stack e o AKS (Serviço de Kubernetes do Azure)

Como resultado, essa solução se aplica a muitas áreas:

• Os MDWs (data warehouses modernos) reúnem dados estruturados e não estruturados em escala. Eles coletam e armazenam dados de vários coletores, formatos e fontes. O NiFi se destaca na ingestão de dados em MDWs baseados no Azure pelos seguintes motivos:

  • Mais de 200 processadores estão disponíveis para leitura, escrita e manipulação de dados.
  • O sistema oferece suporte a serviços de Armazenamento como Armazenamento de Blobs do Azure, Azure Data Lake Storage, Hubs de Eventos do Azure, Armazenamento de Filas do Azure, Azure Cosmos DB e Azure Synapse Analytics.
  • Recursos robustos de comprovação de dados possibilitam implementar soluções em conformidade. Para obter informações sobre como capturar a comprovação de dados no recurso Log Analytics do Azure Monitor, consulte Considerações sobre relatórios, adiante neste artigo.

• O NiFi pode ser executado de forma autônoma em dispositivos de pequeno porte. Nesses casos, o NiFi possibilita processar dados de borda e movê-los para instâncias ou clusters do NiFi maiores na nuvem. O NiFi ajuda a filtrar, transformar e priorizar dados de borda em movimento, garantindo fluxos de dados confiáveis e eficientes.

• As soluções de IIoT (IoT Industrial) gerenciam o fluxo de dados da borda para o data center. Esse fluxo começa com a aquisição de dados de equipamentos e sistemas de controle industriais. Em seguida, esses dados são encaminhados a soluções de gerenciamento de dados e MDWs. O NiFi oferece recursos que o tornam adequado à aquisição e movimentação de dados:

  • Funcionalidade de processamento de dados de borda
  • Suporte para protocolos usados por dispositivos e gateways de IoT
  • Integração com Hubs de Eventos e serviços de Armazenamento

  Aplicativos IoT nas áreas de manutenção preditiva e gerenciamento de cadeia de fornecimento podem usar essa funcionalidade.

Recomendações

Tenha em mente os pontos a seguir ao implementar essa solução:

Versões recomendadas do NiFi

Quando você executar essa solução no Azure, é recomendável usar a versão 1.13.2+ do NiFi. É possível executar outras versões, mas elas podem exigir configurações diferentes das fornecidas neste guia.

Para instalar o NiFi em VMs do Azure, é melhor baixar os binários de conveniência na página de downloads do NiFi. Você também pode criar os binários com base no código-fonte.

Versões recomendadas do ZooKeeper

Para este exemplo de carga de trabalho, é recomendável usar as versões 3.5.5 e posteriores, ou a versão 3.6.x do ZooKeeper.

Você pode instalar o ZooKeeper em VMs do Azure usando binários de conveniência oficiais ou código-fonte. Ambos estão disponíveis na página de versões do Apache ZooKeeper.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Para obter informações sobre como configurar o NiFi, consulte o Guia do Administrador do Sistema Apache NiFi. Lembre-se também dessas considerações ao implementar esta solução.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

• Use a Calculadora de Preços do Azure para estimar o custo dos recursos nessa arquitetura.
• Para obter uma estimativa que inclua todos os serviços oferecidos nessa arquitetura, exceto a solução de alerta personalizado, consulte este exemplo de perfil de custo.

Considerações de VM

As seções a seguir fornecem uma visão detalhada de como configurar as VMs NiFi:

Tamanho da VM

Esta tabela lista os tamanhos de VM recomendados para começar. Para a maioria dos fluxos de dados de uso geral, a melhor opção é Standard_D16s_v3. Porém, cada fluxo de dados em NiFi tem requisitos diferentes. Teste seu fluxo e redimensione conforme necessário, com base nos requisitos reais do fluxo.

Considere a habilitação de rede acelerada nas VMs para aumentar o desempenho da rede. Para saber mais, confira Rede para os conjuntos de dimensionamento de máquinas virtuais do Azure.

Tamanho da VM	vCPU	Memória em GB	Taxa de transferência máxima do disco de dados sem armazenamento em cache em operações de IOPS (E/S por segundo) por MBps*	NICs (interfaces de rede) máximas / Largura de banda de rede esperada (Mbps)
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

* Desabilite o cache de gravação de disco de dados para todos os discos de dados que você use em nós NiFi.

** Recomendamos essa SKU para a maioria dos fluxos de dados de uso geral. As SKUs de VM do Azure com vCPU e configurações de memória semelhantes também devem ser adequadas.

OS (sistema operacional) da VM

É recomendável executar o NiFi no Azure em um dos seguintes sistemas operacionais convidados:

• Ubuntu 18.04 LTS ou mais recente
• CentOS 7.9

Para cumprir os requisitos específicos do seu fluxo de dados, é importante ajustar várias configurações no nível do sistema operacional, inclusive:

• Máximo de processos bifurcados.
• Máximo de identificadores de arquivo.
• Hora do acesso, atime.

Após ajustar o sistema operacional ao caso de uso esperado, use Construtor de Imagens de VM do Azure para codificar a geração dessas imagens ajustadas. Para obter diretrizes específicas para o NiFi, consulte Práticas recomendadas de configuração no Guia do Administrador do Sistema Apache NiFi.

Armazenamento

Armazene os vários repositórios NiFi em discos de dados e não no disco do sistema operacional, por três motivos principais:

• Os fluxos geralmente têm requisitos de alta taxa de transferência de disco que um único disco não consegue atender.
• É melhor separar as operações de disco do NiFi e do sistema operacional.
• Os repositórios não devem estar em armazenamento temporário.

As seções a seguir descrevem as diretrizes para configurar os discos de dados. Essas diretrizes são específicas do Azure. Para obter mais informações sobre como configurar os repositórios, consulte Gerenciamento de Estado no Guia do Administrador do Sistema Apache NiFi.

Tamanho e tipo de disco de dados

Considere estes fatores ao configurar os discos de dados para o NiFi:

• Tipo de disco
• Tamanho do disco
• Número total de discos

A tabela a seguir mostra os tipos de discos gerenciados atualmente disponíveis no Azure. Você pode usar o NiFi com qualquer um desses tipos de disco. Mas, para fluxos de dados com alta taxa de transferência, recomendamos o SSD Premium.

	Disco Ultra (NVMe)	SSD Premium	SSD Standard	HDD Standard
Tipo de disco	SSD	SSD	SSD	HDD
Tamanho máximo do disco	65.536 GB	32.767 GB	32.767 GB	32.767 GB
Taxa de transferência máxima	2.000 MiB/s	900 MiB/s	750 MiB/s	500 MiB/s
IOPS Máxima	160.000	20.000	6.000	2.000

Use no mínimo três discos de dados, para aumentar a taxa de transferência do fluxo de dados. Para informar-se sobre práticas recomendadas de configuração dos repositórios nos discos, confira Configuração de repositórios, adiante neste artigo.

A tabela a seguir lista os números relevantes de tamanho e taxa de transferência para cada tipo e tamanho do disco.

	HDD Standard S15	HDD Standard S20	HDD Standard S30	SSD Standard S15	SSD Standard S20	SSD Standard S30	SSD Premium P15	SSD Premium P20	SSD Premium P30
Tamanho do disco em GB	256	512	1\.024	256	512	1\.024	256	512	1\.024
IOPS por disco	Até 500	Até 500	Até 500	Até 500	Até 500	Até 500	1\.100	2\.300	5\.000
Taxa de transferência por disco	Até 60 MBps	Até 60 MBps	Até 60 MBps	Até 60 MBps	Até 60 MBps	Até 60 MBps	Até 125 MBps	Até 150 MBps	200 MBps

Se o sistema atingir os limites de VM, talvez a adição de mais discos não aumente a taxa de transferência:

• Os limites de IOPS e de taxa de transferência dependem do tamanho do disco.
• O tamanho da VM escolhido estabelece limites de IOPS e taxa de transferência para a VM em todos os discos de dados.

Para informar-se sobre limites de taxa de transferência de disco em termos de VM, consulte Tamanhos para máquinas virtuais do Linux no Azure.

Cache de disco para VMs

Em VMs do Azure, o recurso Host Caching gerencia o cache de gravação em disco. Para aumentar a taxa de transferência em discos de dados usados para repositórios, desative o cache de gravação de disco definindo o Host Caching como None.

Configuração de repositório

As diretrizes de práticas recomendadas para o NiFi são usar discos separados para cada um destes repositórios:

• Conteúdo
• FlowFile
• Comprovação

Essa abordagem requer no mínimo três discos.

O NiFi também oferece suporte à distribuição em nível de aplicativo. Essa funcionalidade aumenta o tamanho ou o desempenho dos repositórios de dados.

O trecho a seguir é do arquivo de configuração nifi.properties. Essa configuração particiona e distribui os repositórios entre os discos gerenciados anexados às VMs:

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

Para obter mais informações sobre o design de armazenamento de alto desempenho, consulte Armazenamento premium do Azure: design para alto desempenho.

Reporting

O NiFi inclui uma tarefa de relatório de comprovação para o recurso Log Analytics.

Você pode usar essa tarefa de relatório para descarregar eventos comprovados em armazenamento de longo prazo durável e econômico. O recurso Log Analytics fornece uma interface de consulta para exibição e grafia dos eventos individuais. Para obter mais informações sobre essas consultas, leia Consultas do Log Analytics, adiante neste artigo.

Você também pode usar essa tarefa com armazenamento de comprovação volátil na memória. Em muitos cenários, é possível aumentar a taxa de transferência. Porém, essa abordagem é arriscada se você precisar preservar dados do evento. Verifique se o armazenamento volátil cumpre os seus requisitos de durabilidade para eventos de comprovação. Para obter mais informações, consulte Repositório de Comprovação no Guia do Administrador do Sistema Apache NiFi.

Antes de usar esse processo, crie um espaço de trabalho do Log Analytics em sua assinatura do Azure. É melhor configurar esse espaço de trabalho na mesma região que sua carga de trabalho.

Para configurar a tarefa de relatório de comprovação:

1. Abra as configurações de controlador no NiFi.
2. Selecione o menu de tarefas de relatório.
3. Selecione Criar uma nova tarefa de relatório.
4. Selecione Tarefa de Relatório do Log Analytics do Azure.

A captura de tela a seguir mostra o menu de propriedades desta tarefa de relatório:

Duas propriedades são obrigatórias:

• ID do espaço de trabalho de análise de logs
• Chave do espaço de trabalho de análise de logs

Você pode encontrar esses valores no portal do Azure, acessando seu espaço de trabalho do Log Analytics.

Outras opções também estão disponíveis para personalizar e filtrar os eventos de comprovação que o sistema envia.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Você pode proteger o NiFi sob o ponto de vista de autenticação e de autorização. Pode também proteger o NiFi para toda a comunicação de rede, inclusive:

• Dentro do cluster.
• Entre o cluster e o ZooKeeper.

Consulte o Guia de Administradores do Apache NiFi para obter instruções sobre como ativar as seguintes opções:

• Kerberos
• Protocolo LDAP
• Autenticação e autorização baseadas em certificado
• SSL (Secure Sockets Layer) de duas vias para comunicações de cluster

Se você ativar o acesso de cliente protegido do ZooKeeper, configure o NiFi adicionando propriedades relacionadas ao seu bootstrap.conf arquivo de configuração. As seguintes entradas de configuração fornecem um exemplo:

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]

Para obter recomendações gerais, consulte a Linha de base de segurança do Linux.

Segurança de rede

Ao implementar essa solução, tenha em mente os seguintes pontos sobre a segurança de rede:

Grupos de segurança de rede

No Azure, você pode usar grupos de segurança de rede para restringir o tráfego de rede.

Recomendamos um jumpbox para a conexão com o cluster NiFi para tarefas administrativas. Use essa VM protegida por segurança com acesso JIT (just-in-time) ou com o Azure Bastion. Configure grupos de segurança de rede para controlar como você concede acesso ao Jumpbox ou ao Azure Bastion. Você pode obter isolamento e controle de rede usando grupos de segurança de rede criteriosamente nas várias sub-redes da arquitetura.

A captura de tela a seguir mostra os componentes de uma rede virtual típica. Ela contém uma sub-rede comum para o jumpbox, conjunto de dimensionamento de máquinas virtuais e VMs ZooKeeper. Essa topologia de rede simplificada agrupa componentes em uma sub-rede. Siga as diretrizes de separação de tarefas e design de rede da sua organização.

Consideração sobre acesso à Internet de saída

O NiFi no Azure não precisa de acesso à Internet pública para ser executado. Se o fluxo de dados não precisar de acesso à Internet para recuperar dados, melhore a segurança do cluster seguindo estas etapas para desabilitar o acesso à Internet de saída:

1. Crie uma regra adicional de grupo de segurança de rede na rede virtual.

2. Use estas configurações:

   • Fonte: Any
   • Destino: Internet
   • Ação: Deny

Com essa regra em vigor, você ainda pode acessar alguns serviços do Azure do fluxo de dados, se configurar um ponto de extremidade privado na rede virtual. Use o Link Privado do Azure com essa finalidade. Esse serviço fornece uma forma para que seu tráfego percorra a rede de backbone da Microsoft sem exigir outro acesso à rede externa. No momento, o NiFi oferece suporte ao Link Privado para os processadores de Armazenamento de Blobs e Data Lake Storage. Se um servidor NTP (network time protocol) não estiver disponível na sua rede privada, permita o acesso de saída ao NTP. Para obter informações detalhadas, consulte Sincronização de horário para VMs do Linux no Azure.

Proteção de dados

É possível operar o NiFi não protegido, sem criptografia de transmissão, IAM (gerenciamento de identidades e acesso) ou criptografia de dados. No entanto, é melhor proteger as implantações de produção e de nuvem pública das seguintes formas:

• Criptografando a comunicação com TLS (Segurança da Camada de Transporte)
• Usando um mecanismo de autenticação e autorização com suporte
• Criptografando dados em repouso

O Armazenamento do Azure fornece criptografia de dados transparente no lado do servidor. Mas, a partir da versão 1.13.2, o NiFi não configura a criptografia de transmissão ou o IAM por padrão. Esse comportamento poderá ser alterado em versões futuras.

As seções a seguir mostram como proteger implantações das seguintes formas:

• Habilitar a criptografia de transmissão com TLS
• Configurar a autenticação baseada em certificados ou no Microsoft Entra ID
• Gerenciar o armazenamento criptografado no Azure

Criptografia de disco

Para aprimorar a segurança, use a criptografia de disco do Azure. Para informar-se sobre um procedimento detalhado, consulte Criptografar discos de sistema operacional e de dados anexados em um conjunto de dimensionamento de máquinas virtuais com a CLI do Azure. Esse documento também contém instruções sobre como fornecer sua própria chave de criptografia. As etapas a seguir descrevem um exemplo básico de NiFi que funciona na maioria das implantações:

1. Para ativar a criptografia de disco em uma instância existente do Key Vault, use o seguinte comando da CLI do Azure:

   az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
   

2. Ative a criptografia dos discos de dados do conjunto de dimensionamento de máquinas virtuais com este comando:

   az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
   

3. Opcionalmente, use uma KEK (chave de criptografia de chave). Use o seguinte comando da CLI do Azure para criptografar com uma 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
   
   

Criptografia em trânsito

O NiFi oferece suporte ao TLS 1.2 para criptografia em trânsito. Esse protocolo oferece proteção para acesso à interface do usuário. Com clusters, o protocolo protege a comunicação entre nós NiFi. Ele também pode proteger a comunicação com o ZooKeeper. Quando você habilita o TLS, o NiFi usa TLS (mTLS) mútua visando à autenticação mútua para:

• Autenticação de cliente baseada em certificado, se você tiver configurado esse tipo de autenticação.
• Toda a comunicação intracluster.

Para habilitar o TLS, siga estas etapas:

1. Crie um repositório de chaves e um truststore para comunicação e autenticação cliente-servidor e intracluster.

2. Configurar $NIFI_HOME/conf/nifi.properties. Defina os seguintes valores:

   • Nomes do host
   • Portas
   • Propriedades do repositório de chaves
   • Propriedades do truststore
   • Propriedades de segurança do cluster e do ZooKeeper, se for o caso

3. Configure a autenticação em $NIFI_HOME/conf/authorizers.xml, normalmente com um usuário inicial que tenha autenticação baseada em certificado ou outra opção.

4. Opcionalmente, configure o mTLS e uma política de leitura de proxy entre o NiFi e quaisquer proxies, balanceadores de carga ou pontos de extremidade externos.

Para obter um passo a passo completo, consulte Proteger o NiFi com TLS na documentação do projeto do Apache.

Certificados, chaves e repositórios de chaves

Para oferecer suporte ao TLS, gere certificados, armazene-os no Java KeyStore e no TrustStore e distribua-os em um cluster NiFi. Há duas opções gerais para certificados:

• Certificados autoassinados
• Certificados que as ACs (autoridades certificadas) assinam

Com certificados assinados por uma AC, é melhor usar uma AC intermediária para gerar certificados para nós no cluster.

KeyStore e TrustStore são os contêineres de chave e certificado na plataforma Java. O KeyStore armazena a chave privada e o certificado de um nó no cluster. O TrustStore armazena um dos seguintes tipos de certificados:

• Todos os certificados confiáveis para certificados autoassinados no KeyStore
• Um certificado de uma AC para certificados assinados pela AC no KeyStore

Ao escolher um contêiner, tenha em mente a escalabilidade do cluster NiFi. Por exemplo, talvez você queira aumentar ou diminuir o número de nós em um cluster no futuro. Escolha certificados assinados pela AC no KeyStore e um ou mais certificados de uma AC no TrustStore nesse caso. Com essa opção, não é preciso atualizar o TrustStore existente nos nós existentes do cluster. Um TrustStore existente confia e aceita certificados destes tipos de nós:

• Nós que você adiciona ao cluster
• Nós que substituem outros no cluster

Configuração do NiFi

Para habilitar o TLS para o NiFi, use $NIFI_HOME/conf/nifi.properties para configurar as propriedades nesta tabela. Verifique se as propriedades a seguir incluem o nome do host que você usa para acessar o NiFi:

• nifi.web.https.host ou nifi.web.proxy.host
• Nome designado do certificado do host ou nomes alternativos da entidade

Caso contrário, poderá resultar uma falha de verificação de nome de host ou de cabeçalho de HOST HTTP, negando o acesso.

Nome da propriedade	Descrição	Valores de exemplo
nifi.web.https.host	Nome do host ou endereço IP a ser usado para a interface do usuário e a API REST. Esse valor deve poder ser resolvido internamente. É recomendável não usar um nome publicamente acessível.	nifi.internal.cloudapp.net
nifi.web.https.port	Porta HTTPS a ser usada para a interface do usuário e a API REST.	9443 (padrão)
nifi.web.proxy.host	Lista separada por vírgulas de nomes de host alternativos que os clientes usam para acessar a interface do usuário e a API REST. Normalmente, essa lista inclui qualquer nome de host especificado como SAN (nome alternativo da entidade) no certificado do servidor. A lista também pode incluir qualquer nome de host e porta que um balanceador de carga, proxy ou controlador de entrada do Kubernetes use.	40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore	Caminho para um repositório de chaves JKS ou PKCS12 que contém a chave privada do certificado.	./conf/keystore.jks
nifi.security.keystoreType	Tipo de repositório de chaves.	JKS ou PKCS12
nifi.security.keystorePasswd	Senha do repositório de chaves.	O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd	(Opcional) Senha da chave privada.
nifi.security.truststore	O caminho para um repositório de confiança JKS ou PKCS12 que contém certificados ou certificados de AC que autenticam usuários e nós de cluster confiáveis.	./conf/truststore.jks
nifi.security.truststoreType	Tipo de truststore.	JKS ou PKCS12
nifi.security.truststorePasswd	Senha do truststore.	RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure	Status do TLS para comunicação intracluster. Se nifi.cluster.is.node for true, defina esse valor como true para habilitar o TLS do cluster.	true
nifi.remote.input.secure	Status do TLS para comunicação site a site.	true

O exemplo a seguir mostra como essas propriedades aparecem em $NIFI_HOME/conf/nifi.properties. Observe que os valores nifi.web.http.host e nifi.web.http.port estão em branco.

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

Configuração do ZooKeeper

Para obter instruções sobre como habilitar o TLS no Apache ZooKeeper para comunicações de quorum e acesso ao cliente, consulte o Guia do Administrador do ZooKeeper. Somente as versões 3.5.5 ou posteriores oferecem suporte a essa funcionalidade.

O NiFi usa o ZooKeeper para sua coordenação de clustering e cluster em modo zero líder. A partir da versão 1.13.0, o NiFi oferece suporte ao acesso seguro do cliente a instâncias habilitadas para TLS do ZooKeeper. O ZooKeeper armazena a associação de cluster e o estado do processador no escopo do cluster em texto sem formatação. Portanto, é importante usar o acesso de cliente protegido ao ZooKeeper para autenticar solicitações de cliente do ZooKeeper. Criptografe também valores confidenciais em trânsito.

Para habilitar o TLS para acesso do cliente do NiFi ao ZooKeeper, defina as propriedades a seguir em $NIFI_HOME/conf/nifi.properties. Se você definir nifi.zookeeper.client.securetrue sem configurar propriedades nifi.zookeeper.security, o NiFi voltará ao repositório de chaves e ao truststore que você especificar em nifi.securityproperties.

Nome da propriedade	Descrição	Valores de exemplo
nifi.zookeeper.client.secure	Status do TLS do cliente ao se conectar ao ZooKeeper.	true
nifi.zookeeper.security.keystore	O caminho para um repositório de chaves JKS, PKCS12 ou PEM que contém a chave privada do certificado apresentado ao ZooKeeper para autenticação.	./conf/zookeeper.keystore.jks
nifi.zookeeper.security.keystoreType	Tipo de repositório de chaves.	JKS, PKCS12, PEM ou detecção automática por extensão
nifi.zookeeper.security.keystorePasswd	Senha do repositório de chaves.	caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd	(Opcional) Senha da chave privada.
nifi.zookeeper.security.truststore	Caminho para um trustStore JKS, PKCS12 ou PEM que contém certificados ou certificados de AC usados para autenticar o ZooKeeper.	./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType	Tipo de truststore.	JKS, PKCS12, PEM ou detecção automática por extensão
nifi.zookeeper.security.truststorePasswd	Senha do truststore.	qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string	Cadeia de conexão para o host ou quorum do ZooKeeper. Trata-se de uma lista de valores separados por vírgulas host:port. Normalmente, o valor secureClientPort não é o mesmo que o valor clientPort. Consulte a configuração do ZooKeeper para obter o valor correto.	zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281

O exemplo a seguir mostra como essas propriedades aparecem em $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

Para obter mais informações sobre como proteger o ZooKeeper com TLS, consulte o Guia de Administração do Apache NiFi.

Identidade e controle de acesso

No NiFi, a identidade e o controle de acesso são obtidos por meio de autenticação e autorização do usuário. Para a autenticação de usuário, o NiFi tem várias opções: Usuário Único, LDAP, Kerberos, SAML (Security Assertion Markup Language) e OIDC (OpenID Connect). Se você não configurar uma opção, o NiFi usará certificados de cliente para autenticar usuários por HTTPS.

Se você estiver considerando a autenticação multifator, recomendamos combinar o Microsoft Entra ID e o OIDC. O Microsoft Entra ID oferece suporte ao SSO (logon único) nativo da nuvem com OIDC. Com essa combinação, os usuários podem aproveitar muitos recursos de segurança corporativa:

• Registro em log e alertas sobre atividades suspeitas de contas de usuário
• Monitoramento de tentativas de acesso a credenciais desativadas
• Alertas sobre comportamento incomum de entrada em contas

Para autorização, o NiFi fornece a imposição baseada em políticas de usuário, grupo e acesso. O NiFi fornece essa imposição por meio de UserGroupProviders e AccessPolicyProviders. Por padrão, os provedores incluem Arquivo, LDAP, Shell e UserGroupProviders com base no Azure Graph. Com o AzureGraphUserGroupProvider, você pode originar grupos de usuários do Microsoft Entra ID. Em seguida, pode atribuir políticas a esses grupos. Para obter instruções de configuração, consulte o Guia de Administração do Apache NiFi.

No momento, AccessPolicyProviders com base em arquivos e no Apache Ranger estão disponíveis para gerenciar e armazenar políticas de usuário e de grupo. Para obter informações detalhadas, consulte a documentação do Apache NiFi e a documentação do Apache Ranger.

Gateway de Aplicativo

Um gateway de aplicativo fornece um balanceador de carga de camada 7 gerenciado para a interface do NiFi. Configure o gateway de aplicativo para usar o conjunto de dimensionamento de máquinas virtuais dos nós NiFi como seu pool de back-end.

Para a maioria das instalações do NiFi, recomendamos a seguinte configuração do Gateway de Aplicativo:

• Camada: Standard
• Tamanho da SKU: médio
• Contagem de instâncias: duas ou mais

Use uma investigação de integridade para monitorar a integridade do servidor Web em cada nó. Remova os nós não íntegros da rotação do balanceador de carga. Essa abordagem facilita a exibição da interface do usuário quando o cluster geral não está íntegro. O navegador direciona apenas para nós que, no momento, estão íntegros e respondendo a solicitações.

Há duas investigações de integridade principais a considerar. Juntas, elas fornecem uma pulsação regular para a integridade geral de cada nó no cluster. Configure a primeira investigação de integridade para apontar para o caminho /NiFi. Essa investigação determina a integridade da interface do usuário do NiFi em cada nó. Configure uma segunda investigação de integridade para o caminho /nifi-api/controller/cluster. Essa investigação indica se, no momento, cada nó está íntegro e adicionado no cluster geral.

Há duas opções para configurar o endereço IP de front-end do gateway de aplicativo:

• Com um endereço IP público
• Com um endereço IP de sub-rede privada

Inclua um endereço IP público apenas se os usuários precisarem acessar a interface do usuário pela Internet pública. Se o acesso público à Internet para os usuários for desnecessário, acesse o front-end do balanceador de carga usando um jumpbox na rede virtual ou por meio de emparelhamento na sua rede privada. Se você configurar o gateway de aplicativo com um endereço IP público, é recomendável habilitar a autenticação de certificado de cliente para o NiFi e habilitar o TLS para a interface do usuário do NiFi. Você também pode usar um grupo de segurança de rede na sub-rede do gateway de aplicativo delegado para limitar os endereços IP de origem.

Diagnóstico e monitoramento de integridade

Nas configurações de diagnóstico do Gateway de Aplicativo, há uma opção de configuração para envio de métricas e logs de acesso. Usando essa opção, você pode enviar essas informações do balanceador de carga para vários locais:

• Uma conta de armazenamento
• Hubs de Eventos
• Um workspace do Log Analytics

Ativar essa configuração é útil para depurar problemas de balanceamento de carga e obter informações sobre a integridade de nós de cluster.

A consulta do Log Analytics a seguir mostra a integridade do nó de cluster ao longo do tempo sob a perspectiva do Gateway de Aplicativo. Você pode usar uma consulta semelhante para gerar alertas ou ações de reparo automatizadas para nós não íntegros.

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

O gráfico dos resultados de consulta a seguir mostra uma exibição temporal da integridade do cluster:

Disponibilidade

Ao implementar essa solução, tenha em mente os seguintes pontos sobre disponibilidade:

Balanceador de carga

Use um balanceador de carga para a interface do usuário, para aumentar sua disponibilidade durante a inatividade do nó.

VMs separadas

Para aumentar a disponibilidade, implante o cluster ZooKeeper em VMs separadas daquelas existentes no cluster NiFi. Para obter mais informações sobre como configurar o ZooKeeper, consulte Gerenciamento de Estado no Guia do Administrador do Sistema Apache NiFi.

Zonas de disponibilidade

Implante o conjunto de dimensionamento de máquinas virtuais do NiFi e o cluster ZooKeeper em uma configuração de zona cruzada para maximizar a disponibilidade. Quando a comunicação entre os nós no cluster cruza as zonas de disponibilidade, introduz uma pequena latência. No entanto, o efeito geral dessa latência sobre a taxa de transferência do cluster normalmente é mínimo.

conjuntos de escala de máquina virtual

É recomendável implantar os nós NiFi em um único conjunto de dimensionamento de máquinas virtuais que abranja zonas de disponibilidade, quando disponíveis. Para obter informações detalhadas sobre o uso de conjuntos de dimensionamento dessa forma, consulte Criar um conjunto de dimensionamento de máquinas virtuais que use Zonas de Disponibilidade.

Monitoramento

Há várias opções disponíveis para monitorar a integridade e o desempenho de um cluster NiFi:

• Tarefas de relatório.
• MonitoFi, um aplicativo separado desenvolvido pela Microsoft. O MonitoFi é executado externamente e monitora o cluster usando a API do NiFi.

Monitoramento de relatório baseado em tarefa

Para o monitoramento, você pode usar uma tarefa de relatório configurada e executada no NiFi. À medida que o Diagnóstico e o monitoramento de integridade se comunicam, o Log Analytics fornece uma tarefa de relatório no pacote do Azure para o NiFi. Você pode usar essa tarefa de relatório para integrar o monitoramento com o Log Analytics e sistemas de monitoramento ou de registro existentes.

Consultas do Log Analytics

Os exemplos de consultas mostrados nas seções a seguir podem ajudá-lo a começar. Para obter uma visão geral de como consultar dados do Log Analytics, consulte Consultas de log do Azure Monitor.

As consultas de log no Monitor e no Log Analytics usam uma versão da linguagem de consulta Kusto. Mas há diferenças entre consultas de log e do Kusto. Para obter mais informações, consulte Visão geral de consultas do Kusto.

Para uma aprendizagem mais estruturada, consulte estes tutoriais:

• Introdução às consultas de log no Azure Monitor
• Introdução ao Log Analytics no Azure Monitor

Tarefa de relatório do Log Analytics

Por padrão, o NiFi envia dados de métricas para a tabela nifimetrics. Mas você pode configurar outro destino nas propriedades da tarefa de relatório. A tarefa de relatório captura as seguintes métricas do NiFi:

Tipo de métrica	Nome da métrica
Métricas do NiFi	FlowFilesReceived
Métricas do NiFi	FlowFilesSent
Métricas do NiFi	FlowFilesQueued
Métricas do NiFi	BytesReceived
Métricas do NiFi	BytesWritten
Métricas do NiFi	BytesRead
Métricas do NiFi	BytesSent
Métricas do NiFi	BytesQueued
Métricas de status da porta	InputCount
Métricas de status da porta	InputBytes
Métricas de status da conexão	QueuedCount
Métricas de status da conexão	QueuedBytes
Métricas de status da porta	OutputCount
Métricas de status da porta	OutputBytes
Métricas da JVM	jvm.uptime
Métricas da JVM	jvm.heap_used
Métricas da JVM	jvm.heap_usage
Métricas da JVM	jvm.non_heap_usage
Métricas da JVM	jvm.thread_states.runnable
Métricas da JVM	jvm.thread_states.blocked
Métricas da JVM	jvm.thread_states.timed_waiting
Métricas da JVM	jvm.thread_states.terminated
Métricas da JVM	jvm.thread_count
Métricas da JVM	jvm.daemon_thread_count
Métricas da JVM	jvm.file_descriptor_usage
Métricas da JVM	jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation
Métricas da JVM	jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation
Métricas da JVM	jvm.buff_pool_direct_capacity
Métricas da JVM	jvm.buff_pool_direct_count
Métricas da JVM	jvm.buff_pool_direct_mem_used
Métricas da JVM	jvm.buff_pool_mapped_capacity
Métricas da JVM	jvm.buff_pool_mapped_count
Métricas da JVM	jvm.buff_pool_mapped_mem_used
Métricas da JVM	jvm.mem_pool_code_cache
Métricas da JVM	jvm.mem_pool_compressed_class_space
Métricas da JVM	jvm.mem_pool_g1_eden_space
Métricas da JVM	jvm.mem_pool_g1_old_gen
Métricas da JVM	jvm.mem_pool_g1_survivor_space
Métricas da JVM	jvm.mem_pool_metaspace
Métricas da JVM	jvm.thread_states.new
Métricas da JVM	jvm.thread_states.waiting
Métricas de nível de processador	BytesRead
Métricas de nível de processador	BytesWritten
Métricas de nível de processador	FlowFilesReceived
Métricas de nível de processador	FlowFilesSent

Este é um exemplo de consulta para a métrica BytesQueued de um cluster:

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 

Essa consulta produz um gráfico como o que vemos nesta captura de tela:

Monitoramento de infraestrutura do NiFi

Além da tarefa de relatório, instale a Extensão de VM do Log Analytics nos nós NiFi e ZooKeeper. Essa extensão reúne logs, métricas adicionais em nível de VM e métricas do ZooKeeper.

Logs personalizados para o aplicativo NiFi, usuário, inicialização e para o ZooKeeper

Para capturar mais logs, siga estas etapas:

1. No portal do Azure, selecione Espaços de trabalho do Log Analytics e o seu espaço de trabalho.

2. Em Configurações, selecione Logs personalizados.

   

3. Selecione Adicionar log personalizado.

   

4. Configure um log personalizado com estes valores:

   • Nome: NiFiAppLogs
   • Tipo de caminho: Linux
   • Nome do caminho: /opt/nifi/logs/nifi-app.log

   

5. Configure um log personalizado com estes valores:

   • Nome: NiFiBootstrapAndUser
   • Primeiro tipo de caminho: Linux
   • Primeiro nome de caminho: /opt/nifi/logs/nifi-user.log
   • Segundo tipo de caminho: Linux
   • Segundo nome de caminho: /opt/nifi/logs/nifi-bootstrap.log

   

6. Configure um log personalizado com estes valores:

   • Nome: NiFiZK
   • Tipo de caminho: Linux
   • Nome do caminho: /opt/zookeeper/logs/*.out

   

Este é um exemplo de consulta da tabela personalizada NiFiAppLogs criada pelo primeiro exemplo:

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

Essa consulta produz resultados semelhantes a estes:

Configuração de log de infraestrutura

Você pode usar o Monitor para monitorar e gerenciar VMs ou computadores físicos. Esses recursos podem estar no seu data center local ou em outro ambiente de nuvem. Para configurar esse monitoramento, implante o agente do Log Analytics. Configure o agente para relatar a um espaço de trabalho do Log Analytics. Para saber mais, confira Visão geral do agente do Log Analytics.

A captura de tela a seguir mostra um exemplo de configuração de agente para VMs NiFi. A tabela Perf armazena os dados coletados.

Este é um exemplo de consulta para os logs de Perf do aplicativo 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

Essa consulta produz um relatório como o que vemos nesta captura de tela:

Alertas

Use o Monitor para criar alertas sobre a integridade e o desempenho do cluster NiFi. Os alertas de exemplo incluem:

• A contagem total de filas excedeu um limite.
• O valor BytesWritten está abaixo de um limite esperado.
• O valor FlowFilesReceived está abaixo de um limite.
• O cluster não está íntegro.

Para obter mais informações sobre alertas no Monitor, confira Visão geral de alertas no Microsoft Azure.

Parâmetros de configuração

As seções a seguir discutem as configurações recomendadas e não padrão para o NiFi e suas dependências, inclusive ZooKeeper e Java. Essas configurações são adequadas a tamanhos de cluster possíveis na nuvem. Defina as propriedades nos seguintes arquivos de configuração:

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

Para obter informações detalhadas sobre arquivos e propriedades de configuração disponíveis, consulte o Guia do Administrador do Sistema Apache NiFi e o Guia do Administrador do ZooKeeper.

NiFi

Para uma implantação do Azure, considere a execução do ajuste de propriedades em $NIFI_HOME/conf/nifi.properties. A tabela a seguir lista as propriedades mais importantes. Para obter mais recomendações e insights, confira as listas de endereçamento do Apache NiFi.

Parâmetro	Descrição	Padrão	Recomendação
nifi.cluster.node.connection.timeout	Tempo de espera ao abrir uma conexão com outros nós de cluster.	5 segundos	60 segundos
nifi.cluster.node.read.timeout	Tempo de espera por uma resposta ao fazer uma solicitação para outros nós de cluster.	5 segundos	60 segundos
nifi.cluster.protocol.heartbeat.interval	Frequência de envio de pulsações de volta ao coordenador do cluster.	5 segundos	60 segundos
nifi.cluster.node.max.concurrent.requests	Qual nível de paralelismo deve ser usado ao replicar chamadas HTTP, como chamadas à API REST para outros nós de cluster.	100	500
nifi.cluster.node.protocol.threads	Tamanho inicial do pool de threads para comunicações entre clusters/replicados.	10	50
nifi.cluster.node.protocol.max.threads	Número máximo de threads a ser usado para comunicações entre clusters/replicados.	50	75
nifi.cluster.flow.election.max.candidates	Número de nós a ser usado ao decidir qual é o fluxo atual. Esse valor encurta o circuito do voto no número especificado.	empty	75
nifi.cluster.flow.election.max.wait.time	Tempo de espera em nós antes de decidir qual é o fluxo atual.	5 minutos	5 minutos

Comportamento do cluster

Ao configurar clusters, tenha em mente os pontos a seguir.

Tempo limite

Para garantir a saúde geral de um cluster e de seus nós, pode ser útil aumentar os tempos limite. Essa prática ajuda a garantir que falhas não resultem de problemas transitórios de rede ou cargas altas.

Em um sistema distribuído, o desempenho de sistemas individuais varia. Essa variação inclui comunicações de rede e latência, o que geralmente afeta a comunicação entre nós e entre clusters. A infraestrutura de rede ou o próprio sistema pode causar essa variação. Como resultado, a probabilidade de variação é muito alta em grandes clusters de sistemas. Em aplicativos Java sob carga, pausas em GC (coleta de lixo) na JVM (máquina virtual Java) também podem afetar os tempos de resposta da solicitação.

Use as propriedades mostradas nas próximas seções para configurar tempos limite para suprir as necessidades do seu sistema:

nifi.cluster.node.connection.timeout e nifi.cluster.node.read.timeout

A propriedade nifi.cluster.node.connection.timeout especifica o tempo de espera ao abrir uma conexão. A propriedade nifi.cluster.node.read.timeout especifica o tempo de espera ao receber dados entre solicitações. O valor padrão para cada propriedade é de cinco segundos. Essas propriedades se aplicam a solicitações de nó para nó. Aumentar esses valores ajuda a atenuar vários problemas relacionados:

• Desconexão pelo coordenador de cluster devido a interrupções de pulsação
• Falha ao obter o fluxo do coordenador ao ingressar no cluster
• Estabelecimento de comunicações de S2S (site a site) e balanceamento de carga

A menos que o cluster tenha um conjunto de dimensionamento muito pequeno, como três nós ou menos, use valores maiores que os padrões.

nifi.cluster.protocol.heartbeat.interval

Como parte da estratégia de clustering NiFi, cada nó emite uma pulsação para comunicar seu status de integridade. Por padrão, os nós enviam pulsações a cada cinco segundos. Se o coordenador de cluster detectar falha de oito pulsações em uma linha de um nó, desconectará o nó. Aumente o intervalo definido na propriedade nifi.cluster.protocol.heartbeat.interval para ajudar a acomodar pulsações lentas e impedir que o cluster desconecte nós desnecessariamente.

Simultaneidade

Use as propriedades descritas nas seções a seguir para definir as configurações de simultaneidade:

nifi.cluster.node.protocol.threads e nifi.cluster.node.protocol.max.threads

A propriedade nifi.cluster.node.protocol.max.threads especifica o número máximo de threads a ser usado para comunicações de todos os clusters, como balanceamento de carga S2S e agregação de interface do usuário. O padrão para esta propriedade são 50 threads. Para clusters grandes, aumente esse valor para levar em conta o maior número de solicitações que essas operações exigem.

A propriedade nifi.cluster.node.protocol.threads determina o tamanho inicial do pool de threads. O valor padrão são 10 threads. Esse é um valor mínimo. Ele aumenta conforme necessário até o máximo definido em nifi.cluster.node.protocol.max.threads. Aumente o valor nifi.cluster.node.protocol.threads para clusters que usam um conjunto de grande escala na inicialização.

nifi.cluster.node.max.concurrent.requests

Muitas solicitações HTTP, como chamadas à API REST e de interface do usuário, precisam ser replicadas para outros nós no cluster. À medida que o tamanho do cluster aumenta, um número cada vez maior de solicitações é replicado. A propriedade nifi.cluster.node.max.concurrent.requests limita o número de solicitações pendentes. Seu valor deve exceder o tamanho esperado do cluster. O valor padrão é de 100 solicitações simultâneas. A menos que você esteja executando um cluster pequeno, de três nós ou menos, evite solicitações com falha aumentando esse valor.

Eleição de fluxo

Use as propriedades descritas nas seções a seguir para definir as configurações de eleição de fluxo:

nifi.cluster.flow.election.max.candidates

O NiFi usa clustering em modo de líder zero, o que significa que não há um nó autoritativo específico. Como resultado, os nós votam em qual definição de fluxo é considerada correta. Votam também para decidir quais nós ingressarão no cluster.

Por padrão, a propriedade nifi.cluster.flow.election.max.candidates é o tempo de espera máximo nifi.cluster.flow.election.max.wait.time especificado pela propriedade. Quando esse valor é muito alto, a inicialização pode ser lenta. O valor padrão para nifi.cluster.flow.election.max.wait.time é de cinco minutos. Defina o número máximo de candidatos para um valor não vazio como 1 ou mais, para garantir que a espera não seja superior ao necessário. Se você definir essa propriedade, atribua a ela um valor correspondente ao tamanho do cluster ou a alguma fração majoritária do tamanho esperado do cluster. Para clusters pequenos e estáticos de 10 nós ou menos, defina esse valor como o número de nós no cluster.

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

Em ambientes de nuvem elásticos, o tempo para provisionar hosts afeta o tempo de inicialização do aplicativo. A propriedade nifi.cluster.flow.election.max.wait.time determina o tempo de espera do NiFi antes de escolher um fluxo. Torne esse valor compatível com o tempo de inicialização geral do cluster em seu tamanho inicial. No teste inicial, cinco minutos são um tempo totalmente adequado em todas as regiões do Azure com os tipos de instância recomendados. Mas você pode aumentar esse valor, se o tempo para provisionar regularmente exceder o padrão.

Java

É recomendável usar uma versão LTS do Java. Dessas versões, a Java 11 é ligeiramente preferível à Java 8, pois oferece suporte a uma implementação de coleta de lixo mais rápida. No entanto, é possível ter uma implantação do NiFi de alto desempenho usando qualquer versão.

As seções a seguir discutem as configurações de JVM comuns a serem usadas na execução do NiFi. Defina os parâmetros de JVM no arquivo de configuração de inicialização em $NIFI_HOME/conf/bootstrap.conf.

Coletor de lixo

Se você estiver executando o Java 11, é recomendável usar o coletor de lixo G1 (G1GC) na maioria das situações. O G1GC aprimorou o desempenho em relação ao ParallelGC, pois o G1GC reduz o tamanho das pausas do GC. O G1GC é o padrão no Java 11, mas você pode configurá-lo explicitamente definindo o seguinte valor em bootstrap.conf:

java.arg.13=-XX:+UseG1GC

Se você estiver executando o Java 8, não use G1GC. Use o ParallelGC. Há deficiências na implementação do G1GC no Java 8 que impedem seu uso com as implementações de repositório recomendadas. O ParallelGC é mais lento que o G1GC. Porém, com o ParallelGC, é possível ter uma implantação do NiFi de alto desempenho com o Java 8.

Heap

Um conjunto de propriedades no arquivo bootstrap.conf determina a configuração do heap de JVM do NiFi. Para um fluxo padrão, configure um heap de 32 GB usando estas configurações:

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

Para escolher o tamanho de heap ideal a ser aplicado ao processo da JVM, considere dois fatores:

• As características do fluxo de dados
• A forma como o NiFi usa a memória em seu processamento

Para ver a documentação detalhada, confira Apache NiFi em detalhes.

Defina o heap com o tamanho estritamente necessário para cumprir os requisitos de processamento. Essa abordagem minimiza a extensão das pausas no GC. Para obter considerações gerais sobre a coleta de lixo do Java, consulte o guia de ajuste da coleta de lixo da sua versão do Java.

Ao ajustar as configurações de memória da JVM, considere estes importantes fatores:

• O número de FlowFiles, ou registros de dados do NiFi, ativos em determinado período. Esse número inclui FlowFiles sob pressão de atraso ou em fila.

• Número de atributos definidos em FlowFiles.

• Quantidade de memória que um processador exige para processar um conteúdo específico.

• Forma como um processador processa os dados:

  • Dados de streaming
  • Usando processadores orientados a registros
  • Mantendo todos os dados na memória de uma só vez

Esses detalhes são importantes. Durante o processamento, o NiFi mantém referências e atributos para cada FlowFile na memória. Em um desempenho de pico, a quantidade de memória usada pelo sistema é proporcional ao número de FlowFiles ativos e a todos os atributos que eles contêm. Esse número inclui FlowFiles em fila. O NiFi pode alternar para o disco. No entanto, evite essa opção, pois ela afeta o desempenho.

Tenha em mente também o uso básico de memória do objeto. Especificamente, torne o heap grande o suficiente para conter objetos na memória. Considere estas dicas para definir as configurações de memória:

• Execute seu fluxo com os dados representativos e pressão de retorno mínima, iniciando com a configuração -Xmx4G e aumentando a memória de forma conservadora, conforme necessário.
• Execute seu fluxo com dados representativos e pressão de retorno de pico, iniciando com a configuração -Xmx4G e aumentando a memória de forma conservadora, conforme necessário.
• Crie o perfil do aplicativo enquanto o fluxo estiver em execução, usando ferramentas como VisualVM e YourKit.
• Se um aumento conservador no heap não melhorar significativamente o desempenho, considere a possibilidade de reprojetar fluxos, processadores e outros aspectos do seu sistema.

Parâmetros adicionais da JVM

A tabela a seguir lista opções de JVM adicionais. Ela também fornece os valores que funcionaram melhor em testes iniciais. Os testes observaram a atividade de GC e o uso de memória, e usaram uma criação de perfil cuidadosa.

Parâmetro	Descrição	Padrão de JVM	Recomendação
InitiatingHeapOccupancyPercent	Quantidade de heap em uso antes de um ciclo de marcação ser disparado.	45	35
ParallelGCThreads	Número de threads usados pelo GC. Esse valor é limitado para conter o efeito geral no sistema.	5/8 do número de vCPUs	8
ConcGCThreads	Número de threads de GC a serem executados em paralelo. Esse valor é aumentado para fazer face ao ParallelGCThreads limitado.	1/4 do valor de ParallelGCThreads	4
G1ReservePercent	O percentual de reserva de memória a ser mantido livre. Esse valor é aumentado para evitar o esgotamento de espaço, o que ajuda a evitar o GC completo.	10	20
UseStringDeduplication	Se o usuário deseja tentar identificar e eliminar a duplicação de referências a cadeias de caracteres idênticas. A ativação desse recurso pode gerar economia de memória.	-	presente

Defina essas configurações adicionando as seguintes entradas ao 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

Para melhorar a tolerância a falhas, execute o ZooKeeper como cluster. Use essa abordagem mesmo que a maioria das implantações do NiFi represente uma carga relativamente modesta no ZooKeeper. Ative o clustering explicitamente para o ZooKeeper. Por padrão, o ZooKeeper é executado em modo de servidor único. Para obter informações detalhadas, consulte Instalação em cluster (Multisservidor) no Guia do Administrador do ZooKeeper.

Exceto para as configurações de clustering, use valores padrão para a configuração do ZooKeeper.

Se você tiver um cluster NiFi grande, talvez precise usar mais servidores ZooKeeper. Para tamanhos menores de cluster, são suficientes tamanhos menores de VM e discos gerenciados SSD Standard.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Muazma Zahid | Gerente Principal de PM

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

O material e as recomendações deste documento vieram de várias fontes:

• Experimentação
• Melhores práticas do Azure
• Conhecimentos da comunidade NiFi, práticas recomendadas e documentação

Para saber mais, consulte os recursos a seguir:

• Guia do Administrador do Sistema Apache NiFi
• Listas de endereçamento do Apache NiFi
• Práticas recomendadas do Cloudera para configurar uma instalação do NiFi de alto desempenho
• Armazenamento premium do Azure: design para alto desempenho
• Solução de problemas de desempenho da máquina virtual do Azure no Linux ou no Windows

Recursos relacionados

• Monitoramento do Apache NiFi com MonitoFi
• Implantações baseadas no Helm para Apache NiFi
• Monitoramento do Azure Data Explorer
• [ETL híbrido com o Azure Data Factory] [ETL híbrido com o Azure Data Factory]
• [DataOps para o data warehouse moderno] [DataOps para o data warehouse moderno]
• Data warehouse e análise