Apache NiFi na platformie Azure

W tym przykładowym scenariuszu pokazano, jak uruchomić usługę Apache NiFi na platformie Azure. NiFi zapewnia system przetwarzania i dystrybucji danych.

Apache®, Apache NiFi i NiFi®® są zastrzeżonymi znakami towarowymi lub znakami towarowymi fundacji Apache Software Foundation w Stany Zjednoczone i/lub innych krajach. Użycie tych znaków nie jest dorozumiane przez fundację Apache Software Foundation.

Architektura

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

• Aplikacja NiFi działa na maszynach wirtualnych w węzłach klastra NiFi. Maszyny wirtualne znajdują się w zestawie skalowania maszyn wirtualnych, który jest wdrażany w różnych strefach dostępności.

• Usługa Apache ZooKeeper działa na maszynach wirtualnych w osobnym klastrze. Usługa NiFi używa klastra ZooKeeper do następujących celów:

  • Aby wybrać węzeł koordynatora klastra
  • Aby koordynować przepływ danych

• aplikacja systemu Azure Gateway zapewnia równoważenie obciążenia warstwy 7 dla interfejsu użytkownika działającego w węzłach NiFi.

• Monitoruj i udostępniają funkcje usługi Log Analytics, zbierają, analizują i działają na podstawie danych telemetrycznych z systemu NiFi. Dane telemetryczne obejmują dzienniki systemu NiFi, metryki kondycji systemu i metryki wydajności.

• Usługa Azure Key Vault bezpiecznie przechowuje certyfikaty i klucze dla klastra NiFi.

• Usługa Microsoft Entra ID zapewnia logowanie jednokrotne i uwierzytelnianie wieloskładnikowe.

Składniki

• NiFi zapewnia system przetwarzania i dystrybucji danych.
• ZooKeeper to serwer typu open source, który zarządza systemami rozproszonymi.
• Maszyny wirtualne to oferta typu infrastruktura jako usługa (IaaS). Za pomocą usługi Virtual Machines można wdrażać skalowalne zasoby obliczeniowe na żądanie. Maszyny wirtualne zapewniają elastyczność wirtualizacji, ale eliminuje wymagania konserwacyjne sprzętu fizycznego.
• Zestawy skalowania maszyn wirtualnych platformy Azure umożliwiają zarządzanie grupą maszyn wirtualnych o zrównoważonym obciążeniu. Liczba wystąpień maszyn wirtualnych w zestawie może automatycznie wzrosnąć lub zmniejszyć odpowiedź na zapotrzebowanie lub zdefiniowany harmonogram.
• Strefy dostępności to unikatowe lokalizacje fizyczne w regionie świadczenia usługi Azure. Te oferty wysokiej dostępności chronią aplikacje i dane przed awariami centrum danych.
• Application Gateway to moduł równoważenia obciążenia, który zarządza ruchem do aplikacji internetowych.
• Monitoruj zbieranie i analizowanie danych w środowiskach i zasobach platformy Azure. Te dane obejmują dane telemetryczne aplikacji, takie jak metryki wydajności i dzienniki aktywności. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące monitorowania w dalszej części tego artykułu.
• Log Analytics to narzędzie witryny Azure Portal, które uruchamia zapytania dotyczące danych dziennika monitora. Usługa Log Analytics udostępnia również funkcje do tworzenia wykresów i statystycznego analizowania wyników zapytań.
• Usługa Azure DevOps Services udostępnia usługi, narzędzia i środowiska do zarządzania projektami i wdrożeniami kodowania.
• Usługa Key Vault bezpiecznie przechowuje i kontroluje dostęp do wpisów tajnych systemu, takich jak klucze interfejsu API, hasła, certyfikaty i klucze kryptograficzne.
• Microsoft Entra ID to oparta na chmurze usługa tożsamości, która kontroluje dostęp do platformy Azure i innych aplikacji w chmurze.

Alternatywy

• Usługa Azure Data Factory stanowi alternatywę dla tego rozwiązania.
• Zamiast usługi Key Vault można użyć porównywalnej usługi do przechowywania wpisów tajnych systemu.
• Apache Airflow. Zobacz , jak są różne rozwiązania Airflow i NiFi.
• Można użyć obsługiwanej alternatywy niFi przedsiębiorstwa, takiej jak Cloudera Apache NiFi. Oferta Cloudera jest dostępna za pośrednictwem witryny Azure Marketplace.

Szczegóły scenariusza

W tym scenariuszu niFi działa w konfiguracji klastrowanej w usłudze Azure Virtual Machines w zestawie skalowania. Jednak większość zaleceń tego artykułu dotyczy również scenariuszy z systemem NiFi w trybie pojedynczego wystąpienia na jednej maszynie wirtualnej. Najlepsze rozwiązania przedstawione w tym artykule przedstawiają skalowalne, wysokiej dostępności i bezpieczne wdrożenie.

Potencjalne przypadki użycia

Funkcja NiFi dobrze sprawdza się w przypadku przenoszenia danych i zarządzania przepływem danych:

• Połączenie oddzielenie systemów w chmurze
• Przenoszenie danych do i z usługi Azure Storage i innych magazynów danych
• Integrowanie aplikacji typu edge-to-cloud i chmury hybrydowej z usługami Azure IoT, Azure Stack i Azure Kubernetes Service (AKS)

W związku z tym to rozwiązanie ma zastosowanie do wielu obszarów:

• Nowoczesne magazyny danych (MDW) łączą ze sobą ustrukturyzowane i nieustrukturyzowane dane na dużą skalę. Zbierają i przechowują dane z różnych źródeł, ujściów i formatów. NiFi wyróżnia pozyskiwanie danych do mdW opartych na platformie Azure z następujących powodów:

  • Ponad 200 procesorów jest dostępnych do odczytywania, zapisywania i manipulowania danymi.
  • System obsługuje usługi Storage, takie jak Azure Blob Storage, Azure Data Lake Storage, Azure Event Hubs, Azure Queue Storage, Azure Cosmos DB i Azure Synapse Analytics.
  • Niezawodne możliwości testowania danych umożliwiają implementowanie zgodnych rozwiązań. Aby uzyskać informacje na temat przechwytywania pochodzenia danych w funkcji log analytics usługi Azure Monitor, zobacz Zagadnienia dotyczące raportowania w dalszej części tego artykułu.

• Interfejs NiFi może działać na podstawie autonomicznych urządzeń z małymi rozmiarami. W takich przypadkach usługa NiFi umożliwia przetwarzanie danych brzegowych i przenoszenie tych danych do większych wystąpień lub klastrów NiFi w chmurze. Interfejs NiFi pomaga filtrować, przekształcać i ustalać priorytety danych brzegowych w ruchu, zapewniając niezawodne i wydajne przepływy danych.

• Przemysłowe rozwiązania IoT (IIoT) zarządzają przepływem danych z krawędzi do centrum danych. Ten przepływ zaczyna się od pozyskiwania danych z systemów i urządzeń przemysłowych. Następnie dane są następnie przenosine do rozwiązań do zarządzania danymi i mdW. Usługa NiFi oferuje możliwości, które doskonale nadają się do pozyskiwania i przenoszenia danych:

  • Funkcje przetwarzania danych brzegowych
  • Obsługa protokołów używanych przez bramy i urządzenia IoT
  • Integracja z usługami Event Hubs i Storage

  Aplikacje IoT w obszarach konserwacji predykcyjnej i zarządzania łańcuchem dostaw mogą korzystać z tej funkcji.

Zalecenia

Podczas korzystania z tego rozwiązania należy pamiętać o następujących kwestiach:

Zalecane wersje niFi

Po uruchomieniu tego rozwiązania na platformie Azure zalecamy używanie wersji 1.13.2 lub nowszej niż NiFi. Możesz uruchomić inne wersje, ale mogą wymagać różnych konfiguracji niż te w tym przewodniku.

Aby zainstalować kartę NiFi na maszynach wirtualnych platformy Azure, najlepiej pobrać wygodne pliki binarne ze strony pobierania NiFi. Pliki binarne można również skompilować na podstawie kodu źródłowego.

Zalecane wersje usługi ZooKeeper

W tym przykładowym obciążeniu zalecamy używanie wersji 3.5.5 lub nowszej lub 3.6.x usługi ZooKeeper.

Usługę ZooKeeper można zainstalować na maszynach wirtualnych platformy Azure przy użyciu oficjalnych plików binarnych wygody lub kodu źródłowego. Oba są dostępne na stronie wydania usługi Apache ZooKeeper.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Aby uzyskać informacje na temat konfigurowania interfejsu NiFi, zobacz Przewodnik Administracja istratora systemu Apache NiFi. Należy również pamiętać o tych zagadnieniach podczas implementowania tego rozwiązania.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

• Użyj kalkulatora cen platformy Azure, aby oszacować koszt zasobów w tej architekturze.
• Aby uzyskać oszacowanie obejmujące wszystkie usługi w tej architekturze z wyjątkiem niestandardowego rozwiązania do zgłaszania alertów, zobacz ten przykładowy profil kosztów.

Zagadnienia dotyczące maszyn wirtualnych

W poniższych sekcjach przedstawiono szczegółowy opis sposobu konfigurowania maszyn wirtualnych NiFi:

Rozmiar maszyny wirtualnej

W tej tabeli wymieniono zalecane rozmiary maszyn wirtualnych na początek. W przypadku większości przepływów danych ogólnego przeznaczenia najlepiej jest Standard_D16s_v3. Jednak każdy przepływ danych w usłudze NiFi ma inne wymagania. Przetestuj przepływ i zmień rozmiar zgodnie z potrzebami na podstawie rzeczywistych wymagań przepływu.

Rozważ włączenie przyspieszonej sieci na maszynach wirtualnych, aby zwiększyć wydajność sieci. Aby uzyskać więcej informacji, zobacz Obsługa sieci w kontekście zestawów skalowania maszyn wirtualnych platformy Azure.

Rozmiar maszyny wirtualnej	Procesor wirtualny	Pamięć w GB	Maksymalna przepływność dysku danych bez buforowania w operacjach we/wy na sekundę (IOPS) na MB/s*	Maksymalna liczba interfejsów sieciowych (NIC) / Oczekiwana przepustowość sieci (Mb/s)
Standardowa_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

* Wyłącz buforowanie zapisu dysku danych dla wszystkich dysków danych używanych w węzłach NiFi.

** Zalecamy tę jednostkę SKU dla większości przepływów danych ogólnego przeznaczenia. Jednostki SKU maszyn wirtualnych platformy Azure z podobnymi konfiguracjami procesorów wirtualnych i pamięci powinny być również odpowiednie.

System operacyjny maszyny wirtualnej

Zalecamy uruchomienie interfejsu NiFi na platformie Azure w jednym z następujących systemów operacyjnych gościa:

• Ubuntu 18.04 LTS lub nowszy
• CentOS 7.9

Aby spełnić określone wymagania przepływu danych, należy dostosować kilka ustawień na poziomie systemu operacyjnego, w tym:

• Maksymalna liczba procesów rozwidlonych.
• Maksymalna liczba dojść do plików.
• Czas dostępu, atime.

Po dostosowaniu systemu operacyjnego do oczekiwanego przypadku użycia użyj narzędzia Azure VM Image Builder, aby skodyfikować generowanie tych dostrajanych obrazów. Aby uzyskać wskazówki specyficzne dla interfejsu NiFi, zobacz Najlepsze rozwiązania dotyczące konfiguracji w przewodniku Administracja istratora systemu Apache NiFi.

Storage

Przechowuj różne repozytoria NiFi na dyskach danych, a nie na dysku systemu operacyjnego z trzech głównych powodów:

• Przepływy często mają wymagania dotyczące wysokiej przepływności dysku, których pojedynczy dysk nie może spełnić.
• Najlepiej oddzielić operacje dysku NiFi od operacji dysku systemu operacyjnego.
• Repozytoria nie powinny znajdować się w magazynie tymczasowym.

W poniższych sekcjach opisano wskazówki dotyczące konfigurowania dysków danych. Te wytyczne są specyficzne dla platformy Azure. Aby uzyskać więcej informacji na temat konfigurowania repozytoriów, zobacz Zarządzanie stanami w przewodniku Administracja istratora systemu Apache NiFi.

Typ i rozmiar dysku danych

Podczas konfigurowania dysków danych dla karty NiFi należy wziąć pod uwagę następujące czynniki:

• Typ dysku
• Rozmiar dysku
• Łączna liczba dysków

W poniższej tabeli przedstawiono typy dysków zarządzanych, które są obecnie dostępne na platformie Azure. Możesz użyć niFi z dowolnym z tych typów dysków. Jednak w przypadku przepływów danych o wysokiej przepływności zalecamy ssd w warstwie Premium.

	Ultra Disk (NVM Express (NVMe))	Dysk SSD w warstwie Premium	Dysk SSD w warstwie Standardowa	Dysk HDD w warstwie Standardowa
Typ dysku	SSD	SSD	SSD	HDD
Maksymalny rozmiar dysku	65 536 GB	32 767 GB	32 767 GB	32 767 GB
Maksymalna przepustowość	2000 MiB/s	900 MiB/s	750 MiB/s	500 MiB/s
Maks. liczba operacji we/wy na sekundę	160 000	20 000	6000	2000

Użyj co najmniej trzech dysków danych, aby zwiększyć przepływność przepływu danych. Aby uzyskać najlepsze rozwiązania dotyczące konfigurowania repozytoriów na dyskach, zobacz Konfiguracja repozytorium w dalszej części tego artykułu.

W poniższej tabeli wymieniono odpowiednie rozmiary i liczby przepływności dla każdego rozmiaru i typu dysku.

	Hdd W warstwie Standardowa S15	Hdd w warstwie Standardowa S20	Hdd w warstwie Standardowa S30	Ssd w warstwie Standardowa S15	Ssd w warstwie Standardowa S20	Ssd w warstwie Standardowa S30	Premium SSD P15	Premium SSD P20	Premium SSD P30
Rozmiar dysku w GB	256	512	1,024	256	512	1,024	256	512	1,024
Operacje we/wy na sekundę na dysk	Do 500	Do 500	Do 500	Do 500	Do 500	Do 500	1,100	2300	5,000
Przepływność na dysk	Do 60 MB/s	Do 60 MB/s	Do 60 MB/s	Do 60 MB/s	Do 60 MB/s	Do 60 MB/s	125 MB/s	150 MB/s	200 MB/s

Jeśli system osiągnie limity maszyn wirtualnych, dodanie większej liczby dysków może nie zwiększyć przepływności:

• Limity liczby operacji we/wy na sekundę i przepływności zależą od rozmiaru dysku.
• Rozmiar maszyny wirtualnej, który wybierasz, umieszcza limity liczby operacji we/wy na sekundę i przepływności maszyny wirtualnej na wszystkich dyskach danych.

Aby uzyskać informacje o limitach przepływności dysku na poziomie maszyny wirtualnej, zobacz Rozmiary maszyn wirtualnych z systemem Linux na platformie Azure.

Buforowanie dysku maszyny wirtualnej

Na maszynach wirtualnych platformy Azure funkcja host Buforowanie zarządza buforowaniem zapisu na dysku. Aby zwiększyć przepływność dysków danych używanych w repozytoriach, wyłącz buforowanie zapisu dysku, ustawiając wartość Host Buforowanie na None.

Konfiguracja repozytorium

Najlepszym rozwiązaniem dla sieci NiFi jest użycie oddzielnego dysku lub dysków dla każdego z tych repozytoriów:

• Zawartość
• Plik przepływu
• Pochodzenie

Takie podejście wymaga co najmniej trzech dysków.

NiFi obsługuje również rozkładanie na poziomie aplikacji. Ta funkcja zwiększa rozmiar lub wydajność repozytoriów danych.

Poniższy fragment pochodzi z nifi.properties pliku konfiguracji. Ta konfiguracja partycjonuje i usuwa repozytoria między dyskami zarządzanymi dołączonymi do maszyn wirtualnych:

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

Aby uzyskać więcej informacji na temat projektowania magazynu o wysokiej wydajności, zobacz Azure Premium Storage: projektowanie pod kątem wysokiej wydajności.

Raportowanie

Interfejs NiFi zawiera zadanie raportowania pochodzenia dla funkcji usługi Log Analytics .

To zadanie raportowania umożliwia odciążanie zdarzeń pochodzenia w celu ekonomicznego, trwałego długoterminowego przechowywania. Funkcja Log Analytics udostępnia interfejs zapytania do wyświetlania i tworzenia wykresów poszczególnych zdarzeń. Aby uzyskać więcej informacji na temat tych zapytań, zobacz Zapytania usługi Log Analytics w dalszej części tego artykułu.

Możesz również użyć tego zadania z magazynem pochodzenia nietrwałego w pamięci. W wielu scenariuszach można następnie zwiększyć przepływność. Jednak takie podejście jest ryzykowne, jeśli musisz zachować dane zdarzeń. Upewnij się, że magazyn niestabilny spełnia wymagania dotyczące trwałości dla zdarzeń pochodzenia. Aby uzyskać więcej informacji, zobacz Repozytorium pochodzenia w przewodniku Administracja istratora systemu Apache NiFi.

Przed rozpoczęciem korzystania z tego procesu utwórz obszar roboczy usługi Log Analytics w ramach subskrypcji platformy Azure. Najlepiej skonfigurować obszar roboczy w tym samym regionie co obciążenie.

Aby skonfigurować zadanie raportowania pochodzenia:

1. Otwórz ustawienia kontrolera w interfejsie NiFi.
2. Wybierz menu zadań raportowania.
3. Wybierz pozycję Utwórz nowe zadanie raportowania.
4. Wybierz pozycję Zadanie raportowania usługi Azure Log Analytics.

Poniższy zrzut ekranu przedstawia menu właściwości dla tego zadania raportowania:

Wymagane są dwie właściwości:

• Identyfikator obszaru roboczego usługi Log Analytics
• Klucz obszaru roboczego usługi Log Analytics

Te wartości można znaleźć w witrynie Azure Portal, przechodząc do obszaru roboczego usługi Log Analytics.

Dostępne są również inne opcje dostosowywania i filtrowania zdarzeń pochodzenia wysyłanych przez system.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Sieci NiFi można zabezpieczyć z punktu widzenia uwierzytelniania i autoryzacji . Możesz również zabezpieczyć sieć NiFi dla całej komunikacji sieciowej, w tym:

• W klastrze.
• Między klastrem a usługą ZooKeeper.

Aby uzyskać instrukcje dotyczące włączania następujących opcji, zobacz Przewodnik po Administracja istratorach platformy Apache NiFi:

• Kerberos
• Protokół LDAP (Lightweight Directory Access Protocol)
• Uwierzytelnianie i autoryzacja oparta na certyfikatach
• Dwukierunkowa warstwa Secure Sockets Layer (SSL) na potrzeby komunikacji klastra

Jeśli włączysz bezpieczny dostęp klienta do usługi ZooKeeper, skonfiguruj usługę NiFi, dodając powiązane właściwości do jego bootstrap.conf pliku konfiguracji. Następujące wpisy konfiguracji zawierają przykład:

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]

Aby uzyskać ogólne zalecenia, zobacz Punkt odniesienia zabezpieczeń systemu Linux.

Bezpieczeństwo sieci

Podczas implementowania tego rozwiązania należy pamiętać o następujących kwestiach dotyczących zabezpieczeń sieci:

Sieciowe grupy zabezpieczeń

Na platformie Azure można użyć sieciowych grup zabezpieczeń, aby ograniczyć ruch sieciowy.

Zalecamy serwer przesiadkowy do nawiązywania połączenia z klastrem NiFi na potrzeby zadań administracyjnych. Użyj tej maszyny wirtualnej ze wzmocnionymi zabezpieczeniami z dostępem just in time (JIT) lub usługą Azure Bastion. Skonfiguruj sieciowe grupy zabezpieczeń, aby kontrolować sposób udzielania dostępu do serwera przesiadkowego lub usługi Azure Bastion. Można osiągnąć izolację sieci i kontrolę przy użyciu sieciowych grup zabezpieczeń rozsądnie w różnych podsieciach architektury.

Poniższy zrzut ekranu przedstawia składniki w typowej sieci wirtualnej. Zawiera ona wspólną podsieć dla serwera przesiadkowego, zestawu skalowania maszyn wirtualnych i maszyn wirtualnych usługi ZooKeeper. Ten uproszczony topologia sieci grupuje składniki w jedną podsieć. Postępuj zgodnie z wytycznymi organizacji dotyczącymi rozdzielania obowiązków i projektowania sieci.

Zagadnienia dotyczące dostępu do Internetu dla ruchu wychodzącego

Do uruchomienia niFi na platformie Azure nie jest potrzebny dostęp do publicznego Internetu. Jeśli przepływ danych nie wymaga dostępu do Internetu w celu pobrania danych, zwiększ bezpieczeństwo klastra, wykonując następujące kroki, aby wyłączyć wychodzący dostęp do Internetu:

1. Utwórz dodatkową regułę sieciowej grupy zabezpieczeń w sieci wirtualnej.

2. Użyj następujących ustawień:

   • Źródło: Any
   • Docelowy: Internet
   • Działania: Deny

Dzięki tej regule nadal można uzyskać dostęp do niektórych usług platformy Azure z przepływu danych, jeśli skonfigurujesz prywatny punkt końcowy w sieci wirtualnej. W tym celu użyj usługi Azure Private Link . Ta usługa umożliwia ruch do podróży w sieci szkieletowej firmy Microsoft, nie wymagając żadnego innego dostępu do sieci zewnętrznej. Usługa NiFi obsługuje obecnie usługę Private Link dla procesorów usługi Blob Storage i Data Lake Storage. Jeśli serwer protokołu NTP (Network Time Protocol) nie jest dostępny w sieci prywatnej, zezwól na dostęp wychodzący do NTP. Aby uzyskać szczegółowe informacje, zobacz Synchronizacja czasu dla maszyn wirtualnych z systemem Linux na platformie Azure.

Ochrona danych

Istnieje możliwość obsługi niezabezpieczonej sieci NiFi bez szyfrowania przewodu, zarządzania tożsamościami i dostępem (IAM) lub szyfrowania danych. Najlepiej jednak zabezpieczyć wdrożenia produkcyjne i wdrożenia w chmurze publicznej na następujące sposoby:

• Szyfrowanie komunikacji z protokołem Transport Layer Security (TLS)
• Korzystanie z obsługiwanego mechanizmu uwierzytelniania i autoryzacji
• Szyfrowanie danych magazynowanych

Usługa Azure Storage zapewnia przezroczyste szyfrowanie danych po stronie serwera. Jednak począwszy od wersji 1.13.2, NiFi nie konfiguruje szyfrowania przewodowego ani IAM domyślnie. To zachowanie może ulec zmianie w przyszłych wersjach.

W poniższych sekcjach pokazano, jak zabezpieczyć wdrożenia w następujący sposób:

• Włączanie szyfrowania przewodowego przy użyciu protokołu TLS
• Konfigurowanie uwierzytelniania opartego na certyfikatach lub identyfikatorze Entra firmy Microsoft
• Zarządzanie zaszyfrowanym magazynem na platformie Azure

Szyfrowanie dysków

Aby zwiększyć bezpieczeństwo, użyj usługi Azure Disk Encryption. Aby uzyskać szczegółową procedurę, zobacz Szyfrowanie systemu operacyjnego i dołączonych dysków danych w zestawie skalowania maszyn wirtualnych za pomocą interfejsu wiersza polecenia platformy Azure. Ten dokument zawiera również instrukcje dotyczące udostępniania własnego klucza szyfrowania. W poniższych krokach przedstawiono podstawowy przykład interfejsu NiFi, który działa w przypadku większości wdrożeń:

1. Aby włączyć szyfrowanie dysków w istniejącym wystąpieniu usługi Key Vault, użyj następującego polecenia interfejsu wiersza polecenia platformy Azure:

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

2. Włącz szyfrowanie dysków danych zestawu skalowania maszyn wirtualnych za pomocą następującego polecenia:

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

3. Opcjonalnie można użyć klucza szyfrowania klucza (KEK). Użyj następującego polecenia interfejsu wiersza polecenia platformy Azure, aby zaszyfrować klucz 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
   
   

Szyfrowanie podczas transferu

Interfejs NiFi obsługuje protokół TLS 1.2 na potrzeby szyfrowania podczas przesyłania. Ten protokół zapewnia ochronę dostępu użytkownika do interfejsu użytkownika. Dzięki klastrom protokół chroni komunikację między węzłami NiFi. Może również chronić komunikację z usługą ZooKeeper. Po włączeniu protokołu TLS usługa NiFi używa wzajemnego protokołu TLS (mTLS) do wzajemnego uwierzytelniania dla:

• Uwierzytelnianie klienta oparte na certyfikatach, jeśli skonfigurowano ten typ uwierzytelniania.
• Cała komunikacja intracluster.

Aby włączyć protokół TLS, wykonaj następujące czynności:

1. Utwórz magazyn kluczy i magazyn zaufania na potrzeby komunikacji i uwierzytelniania klienta i intracluster.

2. Skonfiguruj .$NIFI_HOME/conf/nifi.properties Ustaw następujące wartości:

   • Nazwy hostów
   • Porty
   • Właściwości magazynu kluczy
   • Właściwości magazynu zaufania
   • Właściwości zabezpieczeń klastra i usługi ZooKeeper, jeśli ma to zastosowanie

3. Skonfiguruj uwierzytelnianie w programie $NIFI_HOME/conf/authorizers.xml, zazwyczaj przy użyciu początkowego użytkownika z uwierzytelnianiem opartym na certyfikatach lub inną opcją.

4. Opcjonalnie skonfiguruj mTLS i zasady odczytu serwera proxy między niFi i dowolnymi serwerami proxy, modułami równoważenia obciążenia lub zewnętrznymi punktami końcowymi.

Aby zapoznać się z kompletnym przewodnikiem, zobacz Zabezpieczanie interfejsu NiFi przy użyciu protokołu TLS w dokumentacji projektu Apache.

Certyfikaty, klucze i magazyny kluczy

Aby obsługiwać protokół TLS, generuj certyfikaty, przechowuj je w magazynie kluczy Java i magazynie zaufania oraz dystrybuuj je w klastrze NiFi. Istnieją dwie ogólne opcje dla certyfikatów:

• Certyfikaty z podpisem własnym
• Certyfikaty podpisujące urzędy certyfikacji

W przypadku certyfikatów podpisanych przez urząd certyfikacji najlepiej używać pośredniego urzędu certyfikacji do generowania certyfikatów dla węzłów w klastrze.

KeyStore i TrustStore to kontenery kluczy i certyfikatów na platformie Java. Magazyn kluczy przechowuje klucz prywatny i certyfikat węzła w klastrze. Magazyn zaufania przechowuje jeden z następujących typów certyfikatów:

• Wszystkie zaufane certyfikaty dla certyfikatów z podpisem własnym w magazynie kluczy
• Certyfikat z urzędu certyfikacji dla certyfikatów podpisanych przez urząd certyfikacji w magazynie kluczy

Podczas wybierania kontenera należy pamiętać o skalowalności klastra NiFi. Na przykład możesz zwiększyć lub zmniejszyć liczbę węzłów w klastrze w przyszłości. Wybierz certyfikaty podpisane przez urząd certyfikacji w magazynie kluczy i co najmniej jeden certyfikat z urzędu certyfikacji w magazynie zaufania w tym przypadku. W przypadku tej opcji nie ma potrzeby aktualizowania istniejącego magazynu zaufania w istniejących węzłach klastra. Istniejąca relacja zaufania magazynu zaufania i akceptuje certyfikaty z następujących typów węzłów:

• Węzły dodawane do klastra
• Węzły, które zastępują inne węzły w klastrze

Konfiguracja niFi

Aby włączyć protokół TLS dla karty NiFi, użyj polecenia $NIFI_HOME/conf/nifi.properties , aby skonfigurować właściwości w tej tabeli. Upewnij się, że następujące właściwości zawierają nazwę hosta używaną do uzyskiwania dostępu do sieci NiFi:

• nifi.web.https.host lub nifi.web.proxy.host
• Nazwa lub alternatywne nazwy podmiotu certyfikatu hosta

W przeciwnym razie niepowodzenie weryfikacji nazwy hosta lub niepowodzenie weryfikacji nagłówka HTTP HOSTA może spowodować odmowę dostępu.

Nazwa właściwości	Opis	Przykładowe wartości
nifi.web.https.host	Nazwa hosta lub adres IP do użycia dla interfejsu użytkownika i interfejsu API REST. Ta wartość powinna być wewnętrznie rozpoznawalna. Nie zalecamy używania publicznie dostępnej nazwy.	nifi.internal.cloudapp.net
nifi.web.https.port	Port HTTPS do użycia dla interfejsu użytkownika i interfejsu API REST.	9443 (domyślne)
nifi.web.proxy.host	Rozdzielona przecinkami lista alternatywnych nazw hostów używanych przez klientów do uzyskiwania dostępu do interfejsu użytkownika i interfejsu API REST. Ta lista zazwyczaj zawiera dowolną nazwę hosta określoną jako alternatywną nazwę podmiotu (SAN) w certyfikacie serwera. Lista może również zawierać dowolną nazwę hosta i port używany przez moduł równoważenia obciążenia, serwer proxy lub kontroler ruchu przychodzącego Kubernetes.	40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore	Ścieżka do magazynu kluczy JKS lub PKCS12 zawierającego klucz prywatny certyfikatu.	./conf/keystore.jks
nifi.security.keystoreType	Typ magazynu kluczy.	JKS lub PKCS12
nifi.security.keystorePasswd	Hasło magazynu kluczy.	O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd	(Opcjonalnie) Hasło klucza prywatnego.
nifi.security.truststore	Ścieżka do magazynu zaufania JKS lub PKCS12 zawierającego certyfikaty lub certyfikaty urzędu certyfikacji, które uwierzytelniają zaufanych użytkowników i węzły klastra.	./conf/truststore.jks
nifi.security.truststoreType	Typ magazynu zaufania.	JKS lub PKCS12
nifi.security.truststorePasswd	Hasło magazynu zaufania.	RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure	Stan protokołu TLS dla komunikacji intracluster. Jeśli nifi.cluster.is.node ma truewartość , ustaw tę wartość na wartość , aby true włączyć protokół TLS klastra.	true
nifi.remote.input.secure	Stan protokołu TLS dla komunikacji typu lokacja-lokacja.	true

W poniższym przykładzie pokazano, jak te właściwości są wyświetlane w pliku $NIFI_HOME/conf/nifi.properties. Pamiętaj, że nifi.web.http.host wartości i nifi.web.http.port są puste.

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

Konfiguracja usługi ZooKeeper

Aby uzyskać instrukcje dotyczące włączania protokołu TLS w usłudze Apache ZooKeeper na potrzeby komunikacji kworum i dostępu klienta, zobacz Podręcznik Administracja istratora usługi ZooKeeper. Ta funkcja obsługuje tylko wersje 3.5.5 lub nowsze.

Usługa NiFi używa usługi ZooKeeper na potrzeby klastrowania zero-leader i koordynacji klastra. Począwszy od wersji 1.13.0, niFi obsługuje bezpieczny dostęp klienta do wystąpień usługi ZooKeeper z obsługą protokołu TLS. Usługa ZooKeeper przechowuje członkostwo w klastrze i stan procesora o zakresie klastra w postaci zwykłego tekstu. Dlatego ważne jest używanie bezpiecznego dostępu klienta do usługi ZooKeeper w celu uwierzytelniania żądań klientów usługi ZooKeeper. Szyfruj również poufne wartości podczas przesyłania.

Aby włączyć protokół TLS dla dostępu klienta NiFi do usługi ZooKeeper, ustaw następujące właściwości w pliku $NIFI_HOME/conf/nifi.properties. W przypadku ustawienia nifi.zookeeper.client.securetrue bez konfigurowania nifi.zookeeper.security właściwości funkcja NiFi powraca do magazynu kluczy i magazynu zaufania określonego w pliku nifi.securityproperties.

Nazwa właściwości	Opis	Przykładowe wartości
nifi.zookeeper.client.secure	Stan protokołu TLS klienta podczas nawiązywania połączenia z usługą ZooKeeper.	true
nifi.zookeeper.security.keystore	Ścieżka do magazynu kluczy JKS, PKCS12 lub PEM zawierającego klucz prywatny certyfikatu przedstawionego do usługi ZooKeeper na potrzeby uwierzytelniania.	./conf/zookeeper.keystore.jks
nifi.zookeeper.security.keystoreType	Typ magazynu kluczy.	JKS, , PKCS12PEMlub autowykrywanie według rozszerzenia
nifi.zookeeper.security.keystorePasswd	Hasło magazynu kluczy.	caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd	(Opcjonalnie) Hasło klucza prywatnego.
nifi.zookeeper.security.truststore	Ścieżka do magazynu zaufania JKS, PKCS12 lub PEM zawierającego certyfikaty lub certyfikaty urzędu certyfikacji używane do uwierzytelniania usługi ZooKeeper.	./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType	Typ magazynu zaufania.	JKS, , PKCS12PEMlub autowykrywanie według rozszerzenia
nifi.zookeeper.security.truststorePasswd	Hasło magazynu zaufania.	qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string	Parametry połączenia do hosta lub kworum zooKeeper. Ten ciąg jest rozdzielaną przecinkami listą host:port wartości. secureClientPort Zazwyczaj wartość nie jest taka sama jak clientPort wartość. Sprawdź konfigurację usługi ZooKeeper, aby uzyskać poprawną wartość.	zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281

W poniższym przykładzie pokazano, jak te właściwości są wyświetlane w pliku $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

Aby uzyskać więcej informacji na temat zabezpieczania usługi ZooKeeper przy użyciu protokołu TLS, zobacz Apache NiFi Administracja istration Guide (Przewodnik po Administracja istration apache NiFi).

Tożsamość i kontrola dostępu

W usłudze NiFi tożsamość i kontrola dostępu są osiągane za pośrednictwem uwierzytelniania i autoryzacji użytkownika. W przypadku uwierzytelniania użytkowników interfejs NiFi ma wiele opcji do wyboru: Pojedynczy użytkownik, LDAP, Kerberos, Security Assertion Markup Language (SAML) i OpenID Połączenie (OIDC). Jeśli nie skonfigurujesz opcji, usługa NiFi używa certyfikatów klienta do uwierzytelniania użytkowników za pośrednictwem protokołu HTTPS.

Jeśli rozważasz uwierzytelnianie wieloskładnikowe, zalecamy połączenie identyfikatora Entra firmy Microsoft i identyfikatora OIDC. Aplikacja Microsoft Entra ID obsługuje natywne dla chmury logowanie jednokrotne (SSO) z funkcją OIDC. Dzięki tej kombinacji użytkownicy mogą korzystać z wielu funkcji zabezpieczeń przedsiębiorstwa:

• Rejestrowanie i zgłaszanie alertów dotyczących podejrzanych działań z kont użytkowników
• Monitorowanie próbuje uzyskać dostęp do dezaktywowanych poświadczeń
• Alerty dotyczące nietypowego zachowania logowania do konta

W przypadku autoryzacji karta NiFi zapewnia wymuszanie oparte na zasadach użytkowników, grup i dostępu. Interfejs NiFi zapewnia to wymuszanie za pośrednictwem elementów UserGroupProviders i AccessPolicyProviders. Domyślnie dostawcy obejmują obiekty File, LDAP, Shell i Azure Graph UserGroupProviders. Za pomocą elementu AzureGraphUserGroupProvider możesz źródło grup użytkowników z poziomu identyfikatora Entra firmy Microsoft. Następnie można przypisać zasady do tych grup. Aby uzyskać instrukcje dotyczące konfiguracji, zobacz Przewodnik po Administracja istration platformy Apache NiFi.

AccessPolicyProviders, które są oparte na plikach i Apache Ranger są obecnie dostępne do zarządzania i przechowywania zasad użytkowników i grup. Aby uzyskać szczegółowe informacje, zobacz dokumentację usługi Apache NiFi i dokumentację platformy Apache Ranger.

Brama aplikacji

Brama aplikacji udostępnia zarządzany moduł równoważenia obciążenia warstwy 7 dla interfejsu NiFi. Skonfiguruj bramę aplikacji, aby używać zestawu skalowania maszyn wirtualnych węzłów NiFi jako puli zaplecza.

W przypadku większości instalacji niFi zalecamy następującą konfigurację usługi Application Gateway :

• Warstwa: Standardowa
• Rozmiar jednostki SKU: średni rozmiar
• Liczba wystąpień: co najmniej dwa

Użyj sondy kondycji, aby monitorować kondycję serwera internetowego w każdym węźle. Usuń węzły w złej kondycji z rotacji modułu równoważenia obciążenia. Takie podejście ułatwia wyświetlanie interfejsu użytkownika, gdy ogólny klaster jest w złej kondycji. Przeglądarka kieruje cię tylko do węzłów, które są obecnie w dobrej kondycji i odpowiadają na żądania.

Należy wziąć pod uwagę dwie kluczowe sondy kondycji. Razem zapewniają one regularne pulsy w ogólnej kondycji każdego węzła w klastrze. Skonfiguruj pierwszą sondę kondycji, aby wskazywała ścieżkę /NiFi. Ta sonda określa kondycję interfejsu użytkownika NiFi w każdym węźle. Skonfiguruj drugą sondę kondycji dla ścieżki /nifi-api/controller/cluster. Ta sonda wskazuje, czy każdy węzeł jest obecnie w dobrej kondycji i przyłączony do ogólnego klastra.

Dostępne są dwie opcje konfigurowania adresu IP frontonu bramy aplikacji:

• Przy użyciu publicznego adresu IP
• Przy użyciu adresu IP podsieci prywatnej

Dołącz publiczny adres IP tylko wtedy, gdy użytkownicy muszą uzyskać dostęp do interfejsu użytkownika za pośrednictwem publicznego Internetu. Jeśli publiczny dostęp do Internetu dla użytkowników nie jest wymagany, uzyskaj dostęp do frontonu modułu równoważenia obciążenia z serwera przesiadkowego w sieci wirtualnej lub za pośrednictwem komunikacji równorzędnej z siecią prywatną. Jeśli skonfigurujesz bramę aplikacji z publicznym adresem IP, zalecamy włączenie uwierzytelniania certyfikatu klienta dla sieci NiFi i włączenie protokołu TLS dla interfejsu użytkownika NiFi. Możesz również użyć sieciowej grupy zabezpieczeń w podsieci delegowanej bramy aplikacji, aby ograniczyć źródłowe adresy IP.

Diagnostyka i monitorowanie kondycji

W ustawieniach diagnostycznych usługi Application Gateway istnieje opcja konfiguracji wysyłania metryk i dzienników dostępu. Korzystając z tej opcji, możesz wysłać te informacje z modułu równoważenia obciążenia do różnych miejsc:

• Konto magazynu
• Event Hubs
• Obszar roboczy usługi Log Analytics

Włączenie tego ustawienia jest przydatne w przypadku debugowania problemów z równoważeniem obciążenia i uzyskiwania wglądu w kondycję węzłów klastra.

Poniższe zapytanie usługi Log Analytics pokazuje kondycję węzła klastra w czasie z perspektywy usługi Application Gateway. Podobne zapytanie umożliwia generowanie alertów lub automatycznych akcji naprawy dla węzłów w złej kondycji.

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

Poniższy wykres wyników zapytania przedstawia widok czasu kondycji klastra:

Dostępność

Podczas implementowania tego rozwiązania należy pamiętać o następujących kwestiach dotyczących dostępności:

Moduł równoważenia obciążenia

Użyj modułu równoważenia obciążenia dla interfejsu użytkownika, aby zwiększyć dostępność interfejsu użytkownika podczas przestoju węzła.

Oddzielne maszyny wirtualne

Aby zwiększyć dostępność, wdróż klaster ZooKeeper na oddzielnych maszynach wirtualnych z maszyn wirtualnych w klastrze NiFi. Aby uzyskać więcej informacji na temat konfigurowania usługi ZooKeeper, zobacz Zarządzanie stanem w przewodniku Administracja istratora systemu Apache NiFi.

Strefy dostępności

Wdróż zarówno zestaw skalowania maszyn wirtualnych NiFi, jak i klaster ZooKeeper w konfiguracji między strefami, aby zmaksymalizować dostępność. Podczas komunikacji między węzłami w klastrze przecina strefy dostępności, wprowadza niewielkie opóźnienie. Jednak to opóźnienie zwykle ma minimalny ogólny wpływ na przepływność klastra.

Zestawy skalowania maszyn wirtualnych

Zalecamy wdrożenie węzłów NiFi w jednym zestawie skalowania maszyn wirtualnych obejmującym strefy dostępności tam, gdzie są dostępne. Aby uzyskać szczegółowe informacje na temat korzystania z zestawów skalowania w ten sposób, zobacz Tworzenie zestawu skalowania maszyn wirtualnych, który używa Strefy dostępności.

Monitorowanie

Dostępnych jest wiele opcji monitorowania kondycji i wydajności klastra NiFi:

• Zadania raportowania.
• MonitoFi, oddzielna aplikacja opracowana przez firmę Microsoft. MonitoFi uruchamia zewnętrznie i monitoruje klaster przy użyciu interfejsu API NiFi.

Raportowanie monitorowania opartego na zadaniach

Do monitorowania można użyć zadania raportowania, które konfigurujesz i uruchamiasz w niFi. W miarę omawiania monitorowania diagnostyki i kondycji usługa Log Analytics udostępnia zadanie raportowania w pakiecie platformy Azure NiFi. Za pomocą tego zadania raportowania można zintegrować monitorowanie z usługą Log Analytics i istniejącymi systemami monitorowania lub rejestrowania.

Zapytania usługi Log Analytics

Przykładowe zapytania w poniższych sekcjach mogą pomóc w rozpoczęciu pracy. Aby zapoznać się z omówieniem sposobu wykonywania zapytań dotyczących danych usługi Log Analytics, zobacz Zapytania dzienników usługi Azure Monitor.

Zapytania dzienników w monitorze i usłudze Log Analytics używają wersji język zapytań Kusto. Istnieją jednak różnice między zapytaniami dzienników a zapytaniami Kusto. Aby uzyskać więcej informacji, zobacz Omówienie zapytania Kusto.

Aby uzyskać bardziej ustrukturyzowaną wiedzę, zobacz następujące samouczki:

• Wprowadzenie do zapytań dotyczących dzienników w usłudze Azure Monitor
• Wprowadzenie do usługi Log Analytics w usłudze Azure Monitor

Zadanie raportowania usługi Log Analytics

Domyślnie niFi wysyła dane metryk do nifimetrics tabeli. Można jednak skonfigurować inne miejsce docelowe we właściwościach zadania raportowania. Zadanie raportowania przechwytuje następujące metryki NiFi:

Typ metryki	Nazwa metryki
Metryki niFi	FlowFilesReceived
Metryki niFi	FlowFilesSent
Metryki niFi	FlowFilesQueued
Metryki niFi	BytesReceived
Metryki niFi	BytesWritten
Metryki niFi	BytesRead
Metryki niFi	BytesSent
Metryki niFi	BytesQueued
Metryki stanu portu	InputCount
Metryki stanu portu	InputBytes
Metryki stanu Połączenie ion	QueuedCount
Metryki stanu Połączenie ion	QueuedBytes
Metryki stanu portu	OutputCount
Metryki stanu portu	OutputBytes
Metryki maszyny wirtualnej Java (JVM)	jvm.uptime
Metryki JVM	jvm.heap_used
Metryki JVM	jvm.heap_usage
Metryki JVM	jvm.non_heap_usage
Metryki JVM	jvm.thread_states.runnable
Metryki JVM	jvm.thread_states.blocked
Metryki JVM	jvm.thread_states.timed_waiting
Metryki JVM	jvm.thread_states.terminated
Metryki JVM	jvm.thread_count
Metryki JVM	jvm.daemon_thread_count
Metryki JVM	jvm.file_descriptor_usage
Metryki JVM	jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation
Metryki JVM	jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation
Metryki JVM	jvm.buff_pool_direct_capacity
Metryki JVM	jvm.buff_pool_direct_count
Metryki JVM	jvm.buff_pool_direct_mem_used
Metryki JVM	jvm.buff_pool_mapped_capacity
Metryki JVM	jvm.buff_pool_mapped_count
Metryki JVM	jvm.buff_pool_mapped_mem_used
Metryki JVM	jvm.mem_pool_code_cache
Metryki JVM	jvm.mem_pool_compressed_class_space
Metryki JVM	jvm.mem_pool_g1_eden_space
Metryki JVM	jvm.mem_pool_g1_old_gen
Metryki JVM	jvm.mem_pool_g1_survivor_space
Metryki JVM	jvm.mem_pool_metaspace
Metryki JVM	jvm.thread_states.new
Metryki JVM	jvm.thread_states.waiting
Metryki na poziomie procesora	BytesRead
Metryki na poziomie procesora	BytesWritten
Metryki na poziomie procesora	FlowFilesReceived
Metryki na poziomie procesora	FlowFilesSent

Oto przykładowe zapytanie dotyczące BytesQueued metryki klastra:

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 

To zapytanie tworzy wykres podobny do tego na tym zrzucie ekranu:

Monitorowanie infrastruktury NiFi

Oprócz zadania raportowania zainstaluj rozszerzenie maszyny wirtualnej usługi Log Analytics w węzłach NiFi i ZooKeeper. To rozszerzenie zbiera dzienniki, dodatkowe metryki na poziomie maszyny wirtualnej i metryki z usługi ZooKeeper.

Dzienniki niestandardowe aplikacji NiFi, użytkownika, bootstrap i zooKeeper

Aby przechwycić więcej dzienników, wykonaj następujące kroki:

1. W witrynie Azure Portal wybierz pozycję Obszary robocze usługi Log Analytics, a następnie wybierz swój obszar roboczy.

2. W obszarze Ustawienia wybierz pozycję Dzienniki niestandardowe.

   

3. Wybierz pozycję Dodaj dziennik niestandardowy.

   

4. Skonfiguruj dziennik niestandardowy przy użyciu następujących wartości:

   • Nazwa: NiFiAppLogs
   • Typ ścieżki: Linux
   • Nazwa ścieżki: /opt/nifi/logs/nifi-app.log

   

5. Skonfiguruj dziennik niestandardowy przy użyciu następujących wartości:

   • Nazwa: NiFiBootstrapAndUser
   • Pierwszy typ ścieżki: Linux
   • Nazwa pierwszej ścieżki: /opt/nifi/logs/nifi-user.log
   • Drugi typ ścieżki: Linux
   • Nazwa drugiej ścieżki: /opt/nifi/logs/nifi-bootstrap.log

   

6. Skonfiguruj dziennik niestandardowy przy użyciu następujących wartości:

   • Nazwa: NiFiZK
   • Typ ścieżki: Linux
   • Nazwa ścieżki: /opt/zookeeper/logs/*.out

   

Oto przykładowe zapytanie tabeli niestandardowej NiFiAppLogs utworzonej w pierwszym przykładzie:

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

To zapytanie generuje wyniki podobne do następujących wyników:

Konfiguracja dziennika infrastruktury

Monitor umożliwia monitorowanie maszyn wirtualnych lub komputerów fizycznych oraz zarządzanie nimi. Te zasoby mogą znajdować się w lokalnym centrum danych lub w innym środowisku chmury. Aby skonfigurować to monitorowanie, wdróż agenta usługi Log Analytics. Skonfiguruj agenta do raportowania do obszaru roboczego usługi Log Analytics. Aby uzyskać więcej informacji, zobacz Omówienie agenta usługi Log Analytics.

Poniższy zrzut ekranu przedstawia przykładową konfigurację agenta dla maszyn wirtualnych NiFi. Tabela Perf przechowuje zebrane dane.

Oto przykładowe zapytanie dotyczące dzienników aplikacji 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

To zapytanie tworzy raport podobny do tego na tym zrzucie ekranu:

Alerty

Użyj monitora, aby utworzyć alerty dotyczące kondycji i wydajności klastra NiFi. Przykładowe alerty obejmują:

• Łączna liczba kolejek przekroczyła próg.
• Wartość BytesWritten jest poniżej oczekiwanego progu.
• Wartość FlowFilesReceived jest poniżej progu.
• Klaster jest w złej kondycji.

Aby uzyskać więcej informacji na temat konfigurowania alertów w monitorze, zobacz Omówienie alertów na platformie Microsoft Azure.

Parametry konfiguracji

W poniższych sekcjach omówiono zalecane, inne niż domyślne konfiguracje dla interfejsu NiFi i jego zależności, w tym ZooKeeper i Java. Te ustawienia są odpowiednie dla rozmiarów klastrów, które są możliwe w chmurze. Ustaw właściwości w następujących plikach konfiguracji:

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

Aby uzyskać szczegółowe informacje o dostępnych właściwościach konfiguracji i plikach, zobacz Przewodnik Administracja istratora systemu Apache NiFi i Przewodnik Administracja istratora usługi ZooKeeper.

NiFi

W przypadku wdrożenia platformy Azure rozważ dostosowanie właściwości w programie $NIFI_HOME/conf/nifi.properties. W poniższej tabeli wymieniono najważniejsze właściwości. Aby uzyskać więcej zaleceń i szczegółowych informacji, zobacz listy adresowe apache NiFi.

Parametr	Opis	Wartość domyślna	Zalecenie
nifi.cluster.node.connection.timeout	Czas oczekiwania podczas otwierania połączenia z innymi węzłami klastra.	5 s	60 s
nifi.cluster.node.read.timeout	Jak długo czekać na odpowiedź podczas tworzenia żądania do innych węzłów klastra.	5 s	60 s
nifi.cluster.protocol.heartbeat.interval	Jak często wysyłać pulsy z powrotem do koordynatora klastra.	5 s	60 s
nifi.cluster.node.max.concurrent.requests	Jakiego poziomu równoległości używać podczas replikowania wywołań HTTP, takich jak wywołania interfejsu API REST do innych węzłów klastra.	100	500
nifi.cluster.node.protocol.threads	Początkowy rozmiar puli wątków dla komunikacji między klastrami/replikowanymi.	10	50
nifi.cluster.node.protocol.max.threads	Maksymalna liczba wątków używanych do komunikacji między klastrami/replikowanymi.	50	75
nifi.cluster.flow.election.max.candidates	Liczba węzłów do użycia podczas podejmowania decyzji o bieżącym przepływie. Ta wartość zwarci głosuje pod określoną liczbą.	empty	75
nifi.cluster.flow.election.max.wait.time	Jak długo czekać na węzłach przed podjęciem decyzji o bieżącym przepływie.	5 min	5 min

Zachowanie klastra

Podczas konfigurowania klastrów należy pamiętać o następujących kwestiach.

Timeout

Aby zapewnić ogólną kondycję klastra i jego węzłów, może być korzystne zwiększenie limitu czasu. Ta praktyka pomaga zagwarantować, że błędy nie wynikają z przejściowych problemów z siecią ani dużych obciążeń.

W systemie rozproszonym wydajność poszczególnych systemów różni się. Ta odmiana obejmuje komunikację sieciową i opóźnienie, które zwykle wpływa na komunikację między węzłami i między klastrami. Infrastruktura sieciowa lub sam system może spowodować tę zmianę. W związku z tym prawdopodobieństwo odchylenia jest bardzo prawdopodobne w dużych klastrach systemów. W przypadku aplikacji Java pod obciążeniem wstrzymanie odzyskiwania pamięci (GC) na maszynie wirtualnej Java (JVM) może również wpływać na czasy odpowiedzi na żądania.

Użyj właściwości w poniższych sekcjach, aby skonfigurować limity czasu zgodnie z potrzebami systemu:

nifi.cluster.node.connection.timeout i nifi.cluster.node.read.timeout

Właściwość nifi.cluster.node.connection.timeout określa czas oczekiwania podczas otwierania połączenia. Właściwość nifi.cluster.node.read.timeout określa czas oczekiwania podczas odbierania danych między żądaniami. Wartość domyślna każdej właściwości to pięć sekund. Te właściwości dotyczą żądań węzła-węzła. Zwiększenie tych wartości pomaga złagodzić kilka powiązanych problemów:

• Odłączanie przez koordynatora klastra z powodu przerw w pulsie
• Nie można pobrać przepływu z koordynatora podczas dołączania do klastra
• Ustanawianie komunikacji typu lokacja-lokacja (S2S) i równoważenia obciążenia

Jeśli klaster nie ma bardzo małego zestawu skalowania, takiego jak trzy węzły lub mniej, użyj wartości, które są większe niż wartości domyślne.

nifi.cluster.protocol.heartbeat.interval

W ramach strategii klastrowania NiFi każdy węzeł emituje puls w celu przekazania stanu dobrej kondycji. Domyślnie węzły wysyłają pulsy co pięć sekund. Jeśli koordynator klastra wykryje, że osiem pulsów z rzędu z węzła nie powiodło się, rozłączy węzeł. Zwiększ interwał ustawiony we nifi.cluster.protocol.heartbeat.interval właściwości, aby pomóc w obsyłaniu wolnych pulsów i zapobiec niepotrzebnemu odłączaniu węzłów przez klaster.

Współbieżność

Użyj właściwości w poniższych sekcjach, aby skonfigurować ustawienia współbieżności:

nifi.cluster.node.protocol.threads i nifi.cluster.node.protocol.max.threads

Właściwość nifi.cluster.node.protocol.max.threads określa maksymalną liczbę wątków do użycia dla komunikacji wszystkich klastrów, takich jak równoważenie obciążenia S2S i agregacja interfejsu użytkownika. Wartość domyślna dla tej właściwości to 50 wątków. W przypadku dużych klastrów zwiększ tę wartość, aby uwzględnić większą liczbę żądań, których wymagają te operacje.

Właściwość nifi.cluster.node.protocol.threads określa rozmiar początkowej puli wątków. Wartość domyślna to 10 wątków. Ta wartość jest minimalna. Zwiększa się w miarę potrzeb do maksymalnego zestawu w elem nifi.cluster.node.protocol.max.threads. nifi.cluster.node.protocol.threads Zwiększ wartość klastrów używających dużego zestawu skalowania podczas uruchamiania.

nifi.cluster.node.max.concurrent.requests

Wiele żądań HTTP, takich jak wywołania interfejsu API REST i wywołania interfejsu użytkownika, musi być replikowanych do innych węzłów w klastrze. Wraz ze wzrostem rozmiaru klastra coraz większa liczba żądań jest replikowana. Właściwość nifi.cluster.node.max.concurrent.requests ogranicza liczbę zaległych żądań. Jego wartość powinna przekraczać oczekiwany rozmiar klastra. Wartość domyślna to 100 współbieżnych żądań. Jeśli nie korzystasz z małego klastra z co najmniej trzema węzłami, zapobiec żądaniom, które zakończyły się niepowodzeniem, zwiększając tę wartość.

Wybory w usłudze Flow

Użyj właściwości w poniższych sekcjach, aby skonfigurować ustawienia wyboru przepływu:

nifi.cluster.flow.election.max.kandydaci

Usługa NiFi używa klastrowania zero-leader, co oznacza, że nie ma jednego konkretnego węzła autorytatywnego. W związku z tym węzły głosują, które definicje przepływu są liczone jako poprawne. Głosują również, aby zdecydować, które węzły dołączają do klastra.

Domyślnie nifi.cluster.flow.election.max.candidates właściwość to maksymalny czas oczekiwania określony przez nifi.cluster.flow.election.max.wait.time właściwość. Jeśli ta wartość jest zbyt wysoka, uruchamianie może być powolne. Wartość domyślna to nifi.cluster.flow.election.max.wait.time pięć minut. Ustaw maksymalną liczbę kandydatów na wartość niepustą, na przykład 1 lub większą, aby upewnić się, że oczekiwanie nie jest już potrzebne. Jeśli ustawisz tę właściwość, przypisz jej wartość odpowiadającą rozmiarowi klastra lub części większości oczekiwanego rozmiaru klastra. W przypadku małych, statycznych klastrów z co najmniej 10 węzłami ustaw tę wartość na liczbę węzłów w klastrze.

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

W elastycznym środowisku chmury czas aprowizacji hostów wpływa na czas uruchamiania aplikacji. Właściwość nifi.cluster.flow.election.max.wait.time określa, jak długo niFi czeka przed podjęciem decyzji o przepływie. Ustaw tę wartość proporcjonalnie do ogólnego czasu uruchamiania klastra w rozmiarze początkowym. Podczas testowania początkowego pięć minut jest więcej niż odpowiednie we wszystkich regionach świadczenia usługi Azure z zalecanymi typami wystąpień. Można jednak zwiększyć tę wartość, jeśli czas aprowizacji regularnie przekracza wartość domyślną.

Java

Zalecamy używanie wersji LTS języka Java. W tych wersjach środowisko Java 11 jest nieco preferowane dla środowiska Java 8, ponieważ środowisko Java 11 obsługuje szybszą implementację odzyskiwania pamięci. Istnieje jednak możliwość wdrożenia karty NiFi o wysokiej wydajności przy użyciu jednej z tych wersji.

W poniższych sekcjach omówiono typowe konfiguracje maszyn wirtualnych JVM do użycia podczas uruchamiania interfejsu NiFi. Ustaw parametry JVM w pliku konfiguracji bootstrap pod adresem $NIFI_HOME/conf/bootstrap.conf.

Moduł odśmiecający elementy bezużyteczne

Jeśli używasz środowiska Java 11, w większości sytuacji zalecamy użycie modułu odśmiecania pamięci G1 (G1GC). G1GC ma lepszą wydajność w usłudze ParallelGC, ponieważ G1GC zmniejsza długość pauzy GC. G1GC jest wartością domyślną w środowisku Java 11, ale można ją jawnie skonfigurować, ustawiając następującą wartość w bootstrap.confpliku :

java.arg.13=-XX:+UseG1GC

Jeśli używasz środowiska Java 8, nie używaj G1GC. Zamiast tego użyj klasy ParallelGC. W implementacji G1GC języka Java 8 występują braki, które uniemożliwiają korzystanie z niego z zalecanymi implementacjami repozytorium. ParallelGC jest wolniejsza niż G1GC. Jednak w przypadku usługi ParallelGC nadal można mieć wdrożenie karty NiFi o wysokiej wydajności za pomocą języka Java 8.

Sterta

Zestaw właściwości w bootstrap.conf pliku określa konfigurację stert niFi JVM. W przypadku standardowego przepływu skonfiguruj stertę 32 GB przy użyciu następujących ustawień:

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

Aby wybrać optymalny rozmiar sterty do zastosowania do procesu JVM, należy wziąć pod uwagę dwa czynniki:

• Cechy przepływu danych
• Sposób, w jaki niFi używa pamięci w przetwarzaniu

Aby uzyskać szczegółową dokumentację, zobacz Apache NiFi in Depth (Szczegółowe informacje na temat interfejsu Apache NiFi).

Ustaw stertę tylko tak dużą, jak to konieczne, aby spełnić wymagania dotyczące przetwarzania. Takie podejście minimalizuje długość pauzy GC. Aby zapoznać się z ogólnymi zagadnieniami dotyczącymi odzyskiwania pamięci w języku Java, zobacz przewodnik po dostrajaniu odzyskiwania pamięci dla używanej wersji języka Java.

Podczas dostosowywania ustawień pamięci JVM należy wziąć pod uwagę następujące ważne czynniki:

• Liczba rekordów danych FlowFiles lub NiFi, które są aktywne w danym okresie. Ta liczba obejmuje pliki FlowFiles z obciążeniem wstecznym lub w kolejce.

• Liczba atrybutów zdefiniowanych w pliku FlowFiles.

• Ilość pamięci wymaganej przez procesor do przetworzenia określonego elementu zawartości.

• Sposób przetwarzania danych przez procesor:

  • Dane przesyłane strumieniowo
  • Korzystanie z procesorów zorientowanych na rekordy
  • Przechowywanie wszystkich danych w pamięci jednocześnie

Te szczegóły są ważne. Podczas przetwarzania niFi przechowuje odwołania i atrybuty dla każdego pliku FlowFile w pamięci. W szczytowej wydajności ilość pamięci używanej przez system jest proporcjonalna do liczby dynamicznych plików FlowFiles i wszystkich atrybutów, które zawierają. Ta liczba obejmuje kolejkowane pliki FlowFiles. NiFi może zamienić się na dysk. Należy jednak unikać tej opcji, ponieważ boli wydajność.

Należy również pamiętać o podstawowym użyciu pamięci obiektu. W szczególności utwórz stertę wystarczająco dużą, aby przechowywać obiekty w pamięci. Zapoznaj się z poniższymi wskazówkami dotyczącymi konfigurowania ustawień pamięci:

• Uruchom przepływ z reprezentatywnymi danymi i minimalnym ciśnieniem wstecznym, zaczynając od ustawienia -Xmx4G , a następnie zwiększając ilość pamięci w razie potrzeby.
• Uruchom przepływ z reprezentatywnymi danymi i szczytowym ciśnieniem wstecznym, zaczynając od ustawienia -Xmx4G , a następnie zwiększając rozmiar klastra w sposób konserwatywny zgodnie z potrzebami.
• Profilowanie aplikacji, gdy przepływ jest uruchomiony przy użyciu narzędzi, takich jak VisualVM i YourKit.
• Jeśli konserwatywny wzrost stert nie poprawi wydajności znacząco, rozważ przeprojektowanie przepływów, procesorów i innych aspektów systemu.

Dodatkowe parametry JVM

W poniższej tabeli wymieniono dodatkowe opcje JVM. Zawiera również wartości, które działały najlepiej podczas testowania początkowego. Testy zaobserwowały użycie pamięci i aktywności GC oraz użyli starannego profilowania.

Parametr	Opis	Domyślna funkcja JVM	Zalecenie
InitiatingHeapOccupancyPercent	Ilość sterta, która jest używana przed wyzwoleniem cyklu oznaczania.	45	35
ParallelGCThreads	Liczba wątków używanych przez GC. Ta wartość jest ograniczona do ograniczenia ogólnego wpływu na system.	5/8 liczby procesorów wirtualnych	8
ConcGCThreads	Liczba wątków GC do równoległego uruchamiania. Ta wartość jest zwiększana w celu uwzględnienia ograniczonych wartości ParallelGCThreads.	1/4 ParallelGCThreads wartości	100
G1ReservePercent	Procent pamięci rezerwowej do utrzymania wolnego. Ta wartość jest zwiększana, aby uniknąć wyczerpania przestrzeni, co pomaga uniknąć pełnego GC.	10	20
UseStringDeduplication	Czy należy spróbować zidentyfikować i usunąć zduplikowane odwołania do identycznych ciągów. Włączenie tej funkcji może spowodować oszczędności pamięci.	-	Obecny

Skonfiguruj te ustawienia, dodając następujące wpisy do interfejsu 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

Aby zwiększyć odporność na uszkodzenia, uruchom usługę ZooKeeper jako klaster. Weź to podejście, mimo że większość wdrożeń NiFi stosunkowo skromne obciążenie usługi ZooKeeper. Włącz klastrowanie dla usługi ZooKeeper jawnie. Domyślnie usługa ZooKeeper działa w trybie pojedynczego serwera. Aby uzyskać szczegółowe informacje, zobacz Konfiguracja klastra (wiele serwerów) w przewodniku Administracja istratora usługi ZooKeeper.

Z wyjątkiem ustawień klastrowania użyj wartości domyślnych dla konfiguracji usługi ZooKeeper.

Jeśli masz duży klaster NiFi, może być konieczne użycie większej liczby serwerów ZooKeeper. W przypadku mniejszych rozmiarów klastrów wystarczające są mniejsze rozmiary maszyn wirtualnych i dyski zarządzane SSD w warstwie Standardowa.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Muazma Zahid | Główny menedżer pm

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Materiały i zalecenia w tym dokumencie pochodzą z kilku źródeł:

• Eksperymenty
• Najlepsze rozwiązania dotyczące platformy Azure
• Wiedza społeczności niFi, najlepsze rozwiązania i dokumentacja

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Przewodnik Administracja istratora systemu Apache NiFi
• Listy poczty e-mail usługi Apache NiFi
• Najlepsze rozwiązania dotyczące konfigurowania instalacji niFi o wysokiej wydajności
• Azure Premium Storage: projektowanie pod kątem wysokiej wydajności
• Rozwiązywanie problemów z wydajnością maszyny wirtualnej platformy Azure w systemie Linux lub Windows

Powiązane zasoby

• Monitorowanie usługi Apache NiFi za pomocą narzędzia MonitoFi
• Wdrożenia oparte na narzędziach Helm dla usługi Apache NiFi
• Monitorowanie usługi Azure Data Explorer
• [Wyodrębnianie hybrydowe, przekształcanie, ładowanie (ETL) za pomocą usługi Azure Data Factory] [Hybrydowe etL z usługą Azure Data Factory]
• [DataOps dla nowoczesnego magazynu danych] [DataOps dla nowoczesnego magazynu danych]
• Magazynowanie i analiza danych