Apache NiFi no Azure

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

Apache®, Apache NiFi® e NiFi® são marcas registadas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou noutros países. Nenhum endosso da Apache Software Foundation está implícito no uso dessas marcas.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

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

• O Apache ZooKeeper é executado em VMs em um cluster separado. O NiFi usa o cluster do ZooKeeper para estes fins:

  • Para escolher um nó coordenador de cluster
  • Para coordenar o fluxo de dados

• O Gateway de Aplicativo do Azure fornece balanceamento de carga de camada 7 para a interface do usuário que é 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, métricas de integridade do sistema e métricas de desempenho.

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

• O Microsoft Entra ID fornece logon único (SSO) e autenticação multifator.

Componentes

• 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 infraestrutura como serviço (IaaS). Você pode usar máquinas virtuais para implantar recursos de computação escaláveis sob demanda. As máquinas virtuais oferecem a flexibilidade da virtualização, mas eliminam as demandas de manutenção do hardware físico.
• Os Conjuntos de Dimensionamento de Máquina Virtual do Azure fornecem uma maneira de 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 uma agenda definida.
• As zonas de disponibilidade são locais físicos exclusivos dentro de uma região do Azure. Essas ofertas de alta disponibilidade protegem aplicativos e dados contra falhas no datacenter.
• O Application Gateway é 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 aplicativos, como métricas de desempenho e registros de atividades. Para obter mais informações, consulte Considerações de monitoramento mais adiante neste artigo.
• O Log Analytics é uma ferramenta do portal do Azure que executa consultas nos dados de log do Monitor. O Log Analytics também fornece recursos para gráficos e análise estatística dos resultados da consulta.
• Os Serviços de DevOps do Azure fornecem serviços, ferramentas e ambientes para gerenciar projetos e implantações de codificação.
• O Cofre de Chaves armazena e controla com segurança o acesso aos segredos de um sistema, como chaves de API, senhas, certificados e chaves criptográficas.
• O Microsoft Entra ID é um serviço de identidade baseado na nuvem que controla o acesso ao Azure e a outras aplicações na nuvem.

Alternativas

• O Azure Data Factory fornece uma alternativa a esta solução.
• Em vez do Cofre da Chave, você pode usar um serviço comparável para armazenar segredos do sistema.
• Fluxo de ar Apache. Veja como o Airflow e o NiFi são diferentes.
• É possível usar uma alternativa NiFi empresarial suportada como Cloudera Apache NiFi. A oferta Cloudera está disponível através do Azure Marketplace.

Detalhes do cenário

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

Potenciais casos de utilização

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

• Conectando sistemas dissociados na nuvem
• Movendo dados para dentro e para fora do Armazenamento do Azure e outros armazenamentos de dados
• Integrando aplicativos de borda para nuvem e nuvem híbrida com o Azure IoT, Azure Stack e Azure Kubernetes Service (AKS)

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

• Os armazéns de dados modernos (MDWs) reúnem dados estruturados e não estruturados em escala. Eles coletam e armazenam dados de várias fontes, coletores e formatos. 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, gravação e manipulação de dados.
  • O sistema suporta serviços de Armazenamento, como Armazenamento de Blobs do Azure, Armazenamento de Data Lake do Azure, Hubs de Eventos do Azure, Armazenamento de Filas do Azure, Azure Cosmos DB e Azure Synapse Analytics.
  • Recursos robustos de procedência de dados possibilitam a implementação de soluções compatíveis. Para obter informações sobre como capturar a proveniência de dados no recurso Log Analytics do Azure Monitor, consulte Considerações sobre relatórios mais adiante neste artigo.

• O NiFi pode ser executado de forma independente em dispositivos de pequena dimensão. Nesses casos, o NiFi torna possível processar dados de borda e mover esses dados para instâncias NiFi maiores ou clusters 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 IoT industrial (IIoT) gerenciam o fluxo de dados da borda para o data center. Esse fluxo começa com a aquisição de dados de sistemas e equipamentos de controle industrial. Em seguida, os dados são movidos para soluções de gerenciamento de dados e MDWs. O NiFi oferece recursos que o tornam adequado para aquisição e movimentação de dados:

  • Funcionalidade de processamento de dados de borda
  • Suporte para protocolos que gateways e dispositivos IoT usam
  • Integração com Hubs de Eventos e serviços de armazenamento

  As aplicações de IoT nas áreas de manutenção preditiva e gestão da cadeia de abastecimento podem fazer uso desta funcionalidade.

Recomendações

Tenha em mente os seguintes pontos ao usar esta solução:

Versões recomendadas do NiFi

Quando você executa essa solução no Azure, recomendamos usar a versão 1.13.2+ do NiFi. Você pode executar outras versões, mas elas podem exigir configurações diferentes das deste 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 a partir do código-fonte.

Versões recomendadas do ZooKeeper

Para este exemplo de carga de trabalho, recomendamos o uso das versões 3.5.5 e posteriores ou 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 lançamentos do Apache ZooKeeper.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Para obter informações sobre como configurar o NiFi, consulte o Apache NiFi System Administrator's Guide. Tenha também estas considerações em mente ao implementar esta solução.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

• 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 nessa arquitetura, exceto a solução de alerta personalizada, consulte este exemplo de perfil de custo.

Considerações sobre VMs

As seções a seguir fornecem um esboço detalhado 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, Standard_D16s_v3 é melhor. Mas cada fluxo de dados no NiFi tem requisitos diferentes. Teste seu fluxo e redimensione conforme necessário com base nos requisitos reais do fluxo.

Considere habilitar a rede acelerada nas VMs para aumentar o desempenho da rede. Para obter mais informações, consulte Rede para conjuntos de dimensionamento de máquina virtual do Azure.

Tamanho da VM	vCPU	Memória em GB	Taxa de transferência máxima de disco de dados não armazenado em cache em operações de E/S por segundo (IOPS) por MBps*	Max interfaces de rede (NICs) / 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

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

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

Sistema operacional (SO) VM

Recomendamos executar o NiFi no Azure em um dos seguintes sistemas operacionais convidados:

• Ubuntu 18.04 LTS ou posterior
• CentOS 7,9

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

• Máximo de processos bifurcados.
• Máximo de identificadores de arquivo.
• O tempo de acesso, atime.

Depois de ajustar o sistema operacional para se adequar ao seu caso de uso esperado, use o Construtor de Imagens de VM do Azure para codificar a geração dessas imagens ajustadas. Para obter orientações específicas sobre 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 razões principais:

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

As seções a seguir descrevem diretrizes para configurar os discos de dados. Estas 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.

Tipo e tamanho do disco de dados

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

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

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

	Ultra disco (NVM Express (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
Débito máximo	2,000 MiB/s	900 MiB/s	750 MiB/s	500 MiB/s
IOPS Máximo	160 000	20 000	6000	2.000

Use pelo menos três discos de dados para aumentar a taxa de transferência do fluxo de dados. Para obter as práticas recomendadas para configurar os repositórios nos discos, consulte Configuração do repositório mais adiante neste artigo.

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

	HDD padrão S15	HDD padrão S20	HDD padrão S30	SSD padrão S15	SSD padrão S20	SSD padrão S30	Premium SSD P15	Premium SSD P20	Premium SSD 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	1100	2300	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	125 MBps	150 MBps	200 MBps

Se o sistema atingir os limites da VM, adicionar mais discos pode não aumentar a taxa de transferência:

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

Para limites de taxa de transferência de disco no nível de VM, consulte Tamanhos para máquinas virtuais Linux no Azure.

Cache de disco da VM

Nas 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 que você usa para repositórios, desative o cache de gravação em disco definindo Host Caching como None.

Configuração do repositório

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

• Conteúdo
• FlowFile
• Proveniência

Esta abordagem requer um mínimo de três discos.

O NiFi também suporta striping ao nível da aplicação. Essa funcionalidade aumenta o tamanho ou o desempenho dos repositórios de dados.

O trecho a seguir é do nifi.properties arquivo de configuração. Essa configuração particiona e distribui os repositórios em discos gerenciados que estão conectados à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 como projetar para armazenamento de alto desempenho, consulte Armazenamento premium do Azure: design para alto desempenho.

Relatórios

O NiFi inclui uma tarefa de relatório de proveniência para o recurso Log Analytics .

Você pode usar essa tarefa de relatório para descarregar eventos de proveniência para armazenamento de longo prazo econômico e durável. O recurso Log Analytics fornece uma interface de consulta para visualizar e representar graficamente os eventos individuais. Para obter mais informações sobre essas consultas, consulte Consultas do Log Analytics mais adiante neste artigo.

Você também pode usar essa tarefa com armazenamento de proveniência volátil na memória. Em muitos cenários, você pode obter um aumento de taxa de transferência. Mas essa abordagem é arriscada se você precisar preservar dados de eventos. Certifique-se de que o armazenamento volátil atenda aos seus requisitos de durabilidade para eventos de procedência. Para obter mais informações, consulte Provenance Repository no Apache NiFi System Administrator's Guide.

Antes de usar esse processo, crie um espaço de trabalho de análise de log em sua assinatura do Azure. É melhor configurar o espaço de trabalho na mesma região da sua carga de trabalho.

Para configurar a tarefa de relatório de proveniência:

1. Abra as configurações do 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 Azure Log Analytics.

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

Duas propriedades são necessárias:

• O ID do espaço de trabalho de análise de log
• A chave do espaço de trabalho de análise de log

Você pode encontrar esses valores no portal do Azure navegando até seu espaço de trabalho do Log Analytics.

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

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Você pode proteger o NiFi do ponto de vista de autenticação e autorização . Você também pode proteger o NiFi para todas as comunicações de rede, incluindo:

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

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

• Kerberos
• LDAP (Lightweight Directory Access Protocol)
• Autenticação e autorização baseadas em certificados
• SSL (Secure Sockets Layer) bidirecional para comunicações de cluster

Se você ativar o acesso seguro do cliente 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 da rede

Ao implementar essa solução, tenha em mente os seguintes pontos sobre 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 se conectar ao cluster NiFi para tarefas administrativas. Use essa VM protegida por segurança com acesso just-in-time (JIT) ou 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 componentes em uma rede virtual típica. Ele contém uma sub-rede comum para a jumpbox, conjunto de escala de máquina virtual e VMs do ZooKeeper. Essa topologia de rede simplificada agrupa componentes em uma sub-rede. Siga as diretrizes da sua organização para separação de tarefas e design de rede.

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

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 de saída à Internet:

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

2. Utilize estas definições:

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

Com essa regra em vigor, você ainda pode acessar alguns serviços do Azure a partir do fluxo de dados se configurar um ponto de extremidade privado na rede virtual. Use o Azure Private Link para essa finalidade. Este serviço fornece uma maneira para o seu tráfego viajar na rede de backbone da Microsoft, sem exigir qualquer outro acesso à rede externa. Atualmente, o NiFi suporta Private Link para os processadores de armazenamento de Blob e armazenamento Data Lake. 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 tempo para VMs Linux no Azure.

Proteção de dados

É possível operar NiFi sem segurança, sem criptografia de fio, gerenciamento de identidade e acesso (IAM) ou criptografia de dados. Mas é melhor proteger a produção e as implantações de nuvem pública das seguintes maneiras:

• Criptografando a comunicação com TLS (Transport Layer Security)
• Usando um mecanismo de autenticação e autorização suportado
• Encriptar dados inativos

O Armazenamento do Azure fornece criptografia de dados transparente do lado do servidor. Mas, a partir da versão 1.13.2, o NiFi não configura criptografia de fio ou IAM por padrão. Esse comportamento pode mudar em versões futuras.

As seções a seguir mostram como proteger implantações dessas maneiras:

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

Encriptação de disco

Para melhorar a segurança, use a criptografia de disco do Azure. Para obter um procedimento detalhado, consulte Criptografar SO e discos de dados anexados em um conjunto de dimensionamento de máquina virtual com a CLI do Azure. Esse documento também contém instruções sobre como fornecer a sua própria chave de encriptação. As etapas a seguir descrevem um exemplo básico de NiFi que funciona para a maioria das implantações:

1. Para ativar a criptografia de disco em uma instância existente do Cofre da Chave, 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 escala da máquina virtual com o seguinte comando:

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

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

Encriptação em trânsito

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

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

Para habilitar o TLS, execute as seguintes etapas:

1. Crie um keystore e um truststore para comunicação e autenticação cliente-servidor e intracluster.

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

   • Nomes de anfitrião
   • Portas
   • Propriedades do Keystore
   • Propriedades Truststore
   • Propriedades de segurança do Cluster e do ZooKeeper, se aplicável

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

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

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

Certificados, chaves e armazenamentos de chaves

Para suportar TLS, gere certificados, armazene-os em Java KeyStore e TrustStore e distribua-os em um cluster NiFi. Existem duas opções gerais para certificados:

• Certificados autoassinados
• Certificados assinados pelas autoridades certificadas (AC)

Com certificados assinados por CA, é melhor usar uma CA 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. KeyStore armazena a chave privada e o certificado de um nó no cluster. TrustStore armazena um dos seguintes tipos de certificados:

• Todos os certificados confiáveis, para certificados autoassinados no KeyStore
• Um certificado de uma CA, para certificados assinados por CA no KeyStore

Tenha em mente a escalabilidade do seu cluster NiFi ao escolher um contêiner. Por exemplo, você pode querer aumentar ou diminuir o número de nós em um cluster no futuro. Escolha certificados assinados por CA no KeyStore e um ou mais certificados de uma CA no TrustStore nesse caso. Com essa opção, não há necessidade de 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 nós no cluster

Configuração NiFi

Para habilitar o TLS para NiFi, use $NIFI_HOME/conf/nifi.properties para configurar as propriedades nesta tabela. Certifique-se de que as seguintes propriedades incluam o nome do host que você usa para acessar o NiFi:

• nifi.web.https.host ou nifi.web.proxy.host
• O nome designado do certificado de host ou nomes alternativos de assunto

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

Property name	Description	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. Este valor deve ser resolúvel internamente. Recomendamos não usar um nome acessível publicamente.	nifi.internal.cloudapp.net
nifi.web.https.port	Porta HTTPS a ser usada para a interface do usuário e 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. Essa lista geralmente inclui qualquer nome de host especificado como um nome alternativo de entidade (SAN) 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 ingresso do Kubernetes usa.	40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore	O caminho para um keystore JKS ou PKCS12 que contém a chave privada do certificado.	./conf/keystore.jks
nifi.security.keystoreType	O tipo de keystore.	JKS ou PKCS12
nifi.security.keystorePasswd	A senha do keystore.	O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd	(Opcional) A senha para a chave privada.
nifi.security.truststore	O caminho para um armazenamento confiável JKS ou PKCS12 que contém certificados ou certificados de CA que autenticam usuários confiáveis e nós de cluster.	./conf/truststore.jks
nifi.security.truststoreType	O tipo truststore.	JKS ou PKCS12
nifi.security.truststorePasswd	A senha do armazenamento confiável.	RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure	O 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	O status do TLS para comunicação site a site.	true

O exemplo a seguir mostra como essas propriedades aparecem no $NIFI_HOME/conf/nifi.properties. Observe que os nifi.web.http.host valores 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 quórum e acesso de cliente, consulte o Guia do administrador do ZooKeeper. Apenas as versões 3.5.5 ou posteriores suportam esta funcionalidade.

A NiFi usa o ZooKeeper para seu agrupamento de líder zero e coordenação de cluster. A partir da versão 1.13.0, o NiFi suporta acesso seguro de cliente a instâncias habilitadas para TLS do ZooKeeper. O ZooKeeper armazena a associação ao cluster e o estado do processador com escopo de cluster em texto sem formatação. Portanto, é importante usar o acesso seguro do cliente ao ZooKeeper para autenticar as solicitações do cliente do ZooKeeper. Também criptografe valores confidenciais em trânsito.

Para habilitar o TLS para acesso de cliente NiFi ao ZooKeeper, defina as seguintes propriedades em $NIFI_HOME/conf/nifi.properties. Se você definir nifi.zookeeper.client.secure true sem configurar nifi.zookeeper.security propriedades, o NiFi retornará ao keystore e truststore especificados em nifi.securityproperties.

Property name	Description	Valores de exemplo
nifi.zookeeper.client.secure	O status do cliente TLS ao se conectar ao ZooKeeper.	true
nifi.zookeeper.security.keystore	O caminho para um keystore 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	O tipo de keystore.	JKS, PKCS12, PEM, ou deteção automática por extensão
nifi.zookeeper.security.keystorePasswd	A senha do keystore.	caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd	(Opcional) A senha para a chave privada.
nifi.zookeeper.security.truststore	O caminho para um armazenamento confiável JKS, PKCS12 ou PEM que contém certificados ou certificados de CA usados para autenticar o ZooKeeper.	./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType	O tipo truststore.	JKS, PKCS12, PEM, ou deteção automática por extensão
nifi.zookeeper.security.truststorePasswd	A senha do armazenamento confiável.	qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string	A cadeia de conexão com o host ou quórum do ZooKeeper. Esta cadeia de caracteres é uma lista de valores separada por host:port vírgula. Normalmente, o secureClientPort valor não é o mesmo que o clientPort valor. 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 Apache NiFi Administration Guide.

Identidade e controlo de acesso

Na NiFi, o controle de identidade e acesso é alcançado através da autenticação e autorização do usuário. Para autenticação de usuário, o NiFi tem várias opções para escolher: Usuário Único, LDAP, Kerberos, SAML (Security Assertion Markup Language) e OpenID Connect (OIDC). 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 a combinação de Microsoft Entra ID e OIDC. O Microsoft Entra ID oferece suporte ao logon único (SSO) nativo da nuvem com OIDC. Com essa combinação, os usuários podem tirar proveito de muitos recursos de segurança corporativa:

• Registo e alerta de atividades suspeitas de contas de utilizador
• Monitoramento de tentativas de acesso a credenciais desativadas
• Alertando sobre um comportamento incomum de entrada na conta

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

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

Gateway de aplicação

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

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

• Nível: Standard
• Tamanho do SKU: médio
• Contagem de instâncias: duas ou mais

Use uma sonda de integridade para monitorar a integridade do servidor Web em cada nó. Remova 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 apenas direciona você para nós que estão atualmente íntegros e respondendo a solicitações.

Há duas sondas de saúde fundamentais a considerar. Juntos, eles fornecem um batimento cardíaco regular sobre a saúde geral de cada nó no cluster. Configure a primeira sonda de integridade para apontar para o caminho /NiFi. Esta sonda determina a integridade da interface do usuário NiFi em cada nó. Configure uma segunda sonda de integridade para o caminho /nifi-api/controller/cluster. Essa sonda indica se cada nó está atualmente íntegro e unido ao cluster geral.

Você tem duas opções para configurar o endereço IP front-end do gateway de aplicativo:

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

Inclua apenas um endereço IP público se os usuários precisarem acessar a interface do usuário pela Internet pública. Se o acesso público à Internet para os utilizadores não for necessário, aceda ao front-end do balanceador de carga a partir de uma jumpbox na rede virtual ou através do emparelhamento para a sua rede privada. Se você configurar o gateway de aplicativo com um endereço IP público, recomendamos habilitar a autenticação de certificado de cliente para NiFi e habilitar o TLS para a interface do usuário 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 monitorização do estado de funcionamento

Dentro das configurações de diagnóstico do Application Gateway, há uma opção de configuração para enviar 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 espaço de trabalho do Log Analytics

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

A consulta do Log Analytics a seguir mostra a integridade do nó do cluster ao longo do tempo de uma perspetiva do Application Gateway. 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 a seguir dos resultados da consulta mostra uma exibição de tempo 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 a disponibilidade da interface do usuário durante o tempo de inatividade do nó.

VMs separadas

Para aumentar a disponibilidade, implante o cluster do ZooKeeper em VMs separadas das VMs 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áquina virtual NiFi e o cluster do ZooKeeper em uma configuração entre zonas para maximizar a disponibilidade. Quando a comunicação entre os nós no cluster atravessa zonas de disponibilidade, ela introduz uma pequena quantidade de latência. Mas essa latência normalmente tem um efeito geral mínimo na taxa de transferência do cluster.

Conjuntos de dimensionamento de máquinas virtuais

Recomendamos implantar os nós NiFi em um único conjunto de escala de máquina virtual que abranja zonas de disponibilidade, quando disponível. Para obter informações detalhadas sobre como usar conjuntos de escala dessa maneira, consulte Criar um conjunto de dimensionamento de máquina virtual que usa zonas de disponibilidade.

Monitorização

Para monitorar a integridade e o desempenho de um cluster NiFi, use tarefas de relatório.

Monitoramento baseado em tarefas de relatórios

Para monitoramento, você pode usar uma tarefa de relatório que você configura e executa em NiFi. À medida que o Diagnóstico e o monitoramento de integridade discutem, o Log Analytics fornece uma tarefa de relatório no pacote NiFi Azure. Você pode usar essa tarefa de relatório para integrar o monitoramento com o Log Analytics e os sistemas de monitoramento ou registro existentes.

Consultas do Log Analytics

Exemplos de consultas 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 do Kusto Query Language. Mas existem diferenças entre consultas de log e consultas Kusto. Para obter mais informações, consulte Visão geral da consulta Kusto.

Para uma aprendizagem mais estruturada, consulte estes tutoriais:

• Introdução às consultas de registos 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 nifimetrics tabela. Mas você pode configurar um destino diferente nas propriedades da tarefa de relatório. A tarefa de relatório captura as seguintes métricas NiFi:

Tipo de métrica	Nome da métrica
Métricas NiFi	FlowFilesReceived
Métricas NiFi	FlowFilesSent
Métricas NiFi	FlowFilesQueued
Métricas NiFi	BytesReceived
Métricas NiFi	BytesWritten
Métricas NiFi	BytesRead
Métricas NiFi	BytesSent
Métricas 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 de máquina virtual Java (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

Aqui está uma consulta de exemplo para a BytesQueued métrica 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 desta captura de tela:

Monitorização de infraestruturas 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 no nível da VM e métricas do ZooKeeper.

Logs personalizados para o aplicativo NiFi, usuário, bootstrap e ZooKeeper

Para capturar mais logs, siga estas etapas:

1. No portal do Azure, selecione Espaços de trabalho do Log Analytics e, em seguida, selecione 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
   • Nome do primeiro caminho: /opt/nifi/logs/nifi-user.log
   • Segundo tipo de caminho: Linux
   • Nome do segundo 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

   

Aqui está uma consulta de exemplo da NiFiAppLogs tabela personalizada que o primeiro exemplo criou:

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

Essa consulta produz resultados semelhantes aos seguintes resultados:

Configuração do log de infraestrutura

Você pode usar o Monitor para monitorar e gerenciar VMs ou computadores físicos. Esses recursos podem estar em seu datacenter 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 obter mais informações, consulte Visão geral do agente do Log Analytics.

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

Aqui está uma consulta de exemplo para os logs do aplicativo 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

Essa consulta produz um relatório como o desta captura de tela:

Alertas

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

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

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

Parâmetros de configuração

As seções a seguir discutem configurações recomendadas e não padrão para NiFi e suas dependências, incluindo ZooKeeper e Java. Essas configurações são adequadas para tamanhos de cluster que são 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 as propriedades e arquivos de configuração disponíveis, consulte o Apache NiFi System Administrator's Guide e o ZooKeeper Administrator's Guide.

NiFi

Para uma implantação do Azure, considere ajustar as propriedades no $NIFI_HOME/conf/nifi.properties. A tabela a seguir lista as propriedades mais importantes. Para obter mais recomendações e informações, consulte as listas de discussão do Apache NiFi.

Parâmetro	Description	Predefinido	Recomendação
nifi.cluster.node.connection.timeout	Quanto tempo esperar ao abrir uma conexão com outros nós de cluster.	5 segundos	60 segundos
nifi.cluster.node.read.timeout	Quanto tempo esperar por uma resposta ao fazer uma solicitação para outros nós de cluster.	5 segundos	60 segundos
nifi.cluster.protocol.heartbeat.interval	Com que frequência enviar pulsações de volta para o coordenador do cluster.	5 segundos	60 segundos
nifi.cluster.node.max.concurrent.requests	Que nível de paralelismo usar ao replicar chamadas HTTP, como chamadas de 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/replicadas.	10	50
nifi.cluster.node.protocol.max.threads	Número máximo de threads a serem usados para comunicações entre clusters/replicadas.	50	75
nifi.cluster.flow.election.max.candidates	Número de nós a serem usados ao decidir qual é o fluxo atual. Este valor curto-circuita a votação no número especificado.	empty	75
nifi.cluster.flow.election.max.wait.time	Quanto tempo esperar nos nós antes de decidir qual é o fluxo atual.	5 minutos	5 minutos

Comportamento do cluster

Ao configurar clusters, lembre-se dos seguintes pontos.

Limite de tempo excedido

Para garantir a integridade geral de um cluster e seus nós, pode ser benéfico aumentar os tempos limites. Essa prática ajuda a garantir que as falhas não resultem de problemas transitórios de rede ou cargas elevadas.

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

Use as propriedades nas seções a seguir para configurar tempos limite para atender às necessidades do seu sistema:

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

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

• Ser desconectado pelo coordenador do cluster devido a interrupções nos batimentos cardíacos
• Falha ao obter o fluxo do coordenador ao ingressar no cluster
• Estabelecimento de comunicações site a site (S2S) e balanceamento de carga

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

nifi.cluster.protocol.heartbeat.interval

Como parte da estratégia de agrupamento NiFi, cada nó emite um batimento cardíaco para comunicar seu estado saudável. Por padrão, os nós enviam pulsações a cada cinco segundos. Se o coordenador de cluster detetar que oito pulsações seguidas de um nó falharam, ele desconecta o nó. Aumente o nifi.cluster.protocol.heartbeat.interval intervalo definido na propriedade para ajudar a acomodar pulsações lentas e impedir que o cluster desconecte nós desnecessariamente.

Simultaneidade

Use as propriedades 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 nifi.cluster.node.protocol.max.threads propriedade especifica o número máximo de threads a serem usados para comunicações com todos os clusters, como balanceamento de carga S2S e agregação de interface do usuário. O padrão para essa propriedade é 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 nifi.cluster.node.protocol.threads propriedade determina o tamanho inicial do pool de threads. O valor padrão é 10 threads. Este valor é um mínimo. Ele cresce conforme necessário até o máximo definido em nifi.cluster.node.protocol.max.threads. Aumente o nifi.cluster.node.protocol.threads valor para clusters que usam um conjunto de grande escala na inicialização.

nifi.cluster.node.max.concurrent.requests

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

Eleição de fluxo

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

nifi.cluster.flow.election.max.Candidatos

O NiFi usa clustering 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 conta como a correta. Eles também votam para decidir quais nós se juntam ao cluster.

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

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

Em um ambiente de nuvem elástica, o tempo para provisionar hosts afeta o tempo de inicialização do aplicativo. A nifi.cluster.flow.election.max.wait.time propriedade determina quanto tempo NiFi espera antes de decidir sobre um fluxo. Torne esse valor proporcional ao tempo geral de inicialização do cluster em seu tamanho inicial. No teste inicial, cinco minutos são mais do que adequados 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

Recomendamos o uso de uma versão LTS do Java. Dessas versões, o Java 11 é ligeiramente preferível ao Java 8 porque o Java 11 suporta uma implementação de coleta de lixo mais rápida. No entanto, é possível ter uma implantação NiFi de alto desempenho usando qualquer uma das versões.

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

Coletor de lixo

Se você estiver executando o Java 11, recomendamos usar o coletor de lixo G1 (G1GC) na maioria das situações. O G1GC melhorou o desempenho em relação ao ParallelGC porque o G1GC reduz o comprimento das pausas do GC. 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 o G1GC. Em vez disso, use o ParallelGC. Há deficiências na implementação Java 8 do G1GC que impedem que você o use com as implementações de repositório recomendadas. O ParallelGC é mais lento que o G1GC. Mas com o ParallelGC, você ainda pode ter uma implementação NiFi de alto desempenho com Java 8.

Área dinâmica para dados

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

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

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

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

Para obter documentação detalhada, consulte Apache NiFi in Depth.

Faça a pilha apenas do tamanho necessário para atender aos requisitos de processamento. Essa abordagem minimiza o comprimento das pausas de GC. Para obter considerações gerais sobre a coleta de lixo Java, consulte o guia de ajuste da coleta de lixo para sua versão do Java.

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

• O número de FlowFiles, ou registros de dados NiFi, que estão ativos em um determinado período. Esse número inclui FlowFiles com pressão negativa ou enfileirada.

• O número de atributos definidos em FlowFiles.

• A quantidade de memória que um processador requer para processar um determinado conteúdo.

• A forma como um processador processa dados:

  • Transmissão em fluxo de dados
  • Usando processadores orientados a registros
  • Manter todos os dados na memória de uma só vez

Estes detalhes são importantes. Durante o processamento, o NiFi mantém referências e atributos para cada FlowFile na memória. No desempenho máximo, a quantidade de memória que o sistema usa é proporcional ao número de FlowFiles ao vivo e todos os atributos que eles contêm. Esse número inclui FlowFiles enfileirados. NiFi pode trocar para disco. Mas evite essa opção porque prejudica o desempenho.

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

• Execute seu fluxo com dados representativos e pressão traseira mínima, começando com a configuração -Xmx4G e, em seguida, aumentando a memória de forma conservadora, conforme necessário.
• Execute seu fluxo com dados representativos e pressão de retorno de pico começando com a configuração -Xmx4G e, em seguida, aumentando o tamanho do cluster de forma conservadora, conforme necessário.
• Crie o perfil do aplicativo enquanto o fluxo está sendo executado usando ferramentas como VisualVM e YourKit.
• Se aumentos conservadores no heap não melhorarem significativamente o desempenho, considere redesenhar fluxos, processadores e outros aspetos do seu sistema.

Parâmetros adicionais da JVM

A tabela a seguir lista opções adicionais da JVM. Ele também fornece os valores que funcionaram melhor nos testes iniciais. Os testes observaram a atividade do GC e o uso de memória e usaram um perfil cuidadoso.

Parâmetro	Description	Padrão da JVM	Recomendação
InitiatingHeapOccupancyPercent	A quantidade de pilha que está em uso antes de um ciclo de marcação ser acionado.	45	35
ParallelGCThreads	O número de threads que o GC usa. Este valor é limitado para limitar o efeito global no sistema.	5/8 do número de vCPUs	8
ConcGCThreads	O número de threads GC a serem executados em paralelo. Esse valor é aumentado para levar em conta ParallelGCThreads limitados.	1/4 do ParallelGCThreads valor	4
G1ReservePercent	A percentagem de memória de reserva para manter livre. Este valor é aumentado para evitar a exaustão do espaço, o que ajuda a evitar o GC completo.	10	20
UseStringDeduplication	Se deve tentar identificar e eliminar a duplicação de referências a cadeias de caracteres idênticas. Ativar esse recurso pode resultar em economia de memória.	-	Atualidade

Configure 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 um cluster. Adote essa abordagem, embora a maioria das implantações de NiFi coloque uma carga relativamente modesta no ZooKeeper. Ative o clustering para o ZooKeeper explicitamente. Por padrão, o ZooKeeper é executado no modo de servidor único. Para obter informações detalhadas, consulte Configuração em cluster (multisservidor) no Guia do administrador do ZooKeeper.

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

Se você tiver um cluster NiFi grande, talvez seja necessário usar um número maior de servidores do ZooKeeper. Para tamanhos de cluster menores, tamanhos menores de VM e discos gerenciados SSD padrão são suficientes.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Muazma Zahid - Brasil | Gestor Principal PM

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

Próximos passos

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

• Experimentação
• Práticas recomendadas do Azure
• Conhecimento, melhores práticas e documentação da comunidade NiFi

Para obter mais informações, consulte os seguintes recursos:

• Guia do Administrador do Sistema Apache NiFi
• Listas de discussão Apache NiFi
• Melhores práticas do Cloudera para configurar uma instalação NiFi de alto desempenho
• Armazenamento Premium do Azure: Conceção para elevado desempenho
• Solucionar problemas de desempenho da máquina virtual do Azure no Linux ou no Windows

Recursos relacionados

• Implantações baseadas em leme para Apache NiFi
• Monitoramento do Azure Data Explorer
• [Extrair, transformar, carregar (ETL) híbrido com o Azure Data Factory] [ETL híbrido com o Azure Data Factory]
• [DataOps para o armazém de dados moderno] [DataOps para o armazém de dados moderno]
• Armazenamento e análise de dados