Apache NiFi系統管理員指南 [ 二 ]

 

配置用戶和訪問策略

加密配置

關鍵衍生函數

鹽和IV編碼

Java密碼術擴展(JCE)有限強度管轄政策

允許不安全的加密模式

配置文件中的加密密碼

NiFi工具包管理工具

羣集配置

零主集羣

爲什麼集羣?

術語

集羣內的通信

管理節點

流動選舉


 

配置用戶和訪問策略

根據配置的UserGroupProvider和AccessPolicyProvider的功能,可以在UI中配置用戶,組和策略。如果擴展名不可配置,則用戶,組和策略在UI中將是隻讀的。如果配置的授權程序不使用UserGroupProvider和AccessPolicyProvider,則基於底層實現,用戶和策略可能在UI中可見或可配置。

本節假定用戶,組和策略可在UI中配置,並描述:

  • 如何創建用戶和組

  • 訪問策略如何用於定義授權

  • 如何查看在用戶上設置的策略

  • 如何通過遍歷特定示例來配置訪問策略

  需要與UI交互的說明假定User1(具有管理員權限的用戶)訪問應用程序,例如“初始管理員身份”用戶或轉換後的舊管理員用戶(請參閱Authorizers.xml設置)。

創建用戶和組

在UI中,從全局菜單中選擇“用戶”。這將打開一個用於創建和管理用戶和組的對話框。

單擊“添加”圖標(添加用戶圖標)。要創建用戶,請輸入與爲保護您的NiFi實例而選擇的身份驗證方法相關的“身份”信息。單擊確定。

要創建組,請選擇“組”單選按鈕,輸入組的名稱,然後選擇要包括在組中的用戶。單擊確定。

訪問政策

您可以使用“訪問策略”管理用戶和組查看或修改NiFi資源的能力。可以將兩種類型的訪問策略應用於資源:

  • View - 如果爲資源創建了視圖策略,則只有添加到該策略的用戶或組才能看到該資源的詳細信息。

  • Modify - 如果資源具有修改策略,則只有添加到該策略的用戶或組才能更改該資源的配置。

您可以在全局和組件級別創建和應用訪問策略。

全球訪問政策

全局訪問策略管理以下系統級授權:

政策特權全局菜單選擇資源描述符

查看用戶界面

允許用戶查看UI

N / A

/flow

訪問控制器

允許用戶查看/修改控制器,包括羣集中的報告任務,控制器服務和節點

控制器設置

/controller

查詢出處

允許用戶提交原型搜索並請求事件沿襲

數據來源

/provenance

訪問受限組件

假設其他權限足夠,允許用戶創建/修改受限制的組件。受限組件可以指示需要哪些特定權限。可以爲特定限制授予權限,也可以在不受限制的情況下授予權限。如果授予權限而不受限制,則用戶可以創建/修改所有受限制的組件。

N / A

/restricted-components

訪問所有政策

允許用戶查看/修改所有組件的策略

政策

/policies

訪問用戶/用戶組

允許用戶查看/修改用戶和用戶組

用戶

/tenants

檢索站點到站點的詳細信息

允許其他NiFi實例檢索站點到站點的詳細信息

N / A

/site-to-site

查看系統診斷

允許用戶查看系統診斷

摘要

/system

代理用戶請求

允許代理計算機代表其他人發送請求

N / A

/proxy

訪問計數器

允許用戶查看/修改計數器

計數器

/counters

組件級訪問策略

組件級訪問策略管理以下組件級別授權:

政策特權資源描述符和動作

查看組件

允許用戶查看組件配置詳細信息

resource="/<component-type>/<component-UUID>" action="R"

修改組件

允許用戶修改組件配置詳細信息

resource="/<component-type>/<component-UUID>" action="W"

操作組件

允許用戶通過更改組件運行狀態(啓動/停止/啓用/禁用),遠程端口傳輸狀態或終止處理器線程來操作組件

resource="/operation/<component-type>/<component-UUID>" action="W"

查看出處

允許用戶查看此組件生成的起源事件

resource="/provenance-data/<component-type>/<component-UUID>" action="R"

查看數據

允許用戶在出站連接中的流文件隊列中以及通過出處事件查看此組件的元數據和內容

resource="/data/<component-type>/<component-UUID>" action="R"

修改數據

允許用戶在出站連接中清空流文件隊列,並通過出處事件提交重播

resource="/data/<component-type>/<component-UUID>" action="W"

查看政策

允許用戶查看可以查看/修改組件的用戶列表

resource="/policies/<component-type>/<component-UUID>" action="R"

修改政策

允許用戶修改可以查看/修改組件的用戶列表

resource="/policies/<component-type>/<component-UUID>" action="W"

通過站點到站點接收數據

允許端口從NiFi實例接收數據

resource="/data-transfer/input-ports/<port-UUID>" action="W"

通過站點到站點發送數據

允許端口從NiFi實例發送數據

resource="/data-transfer/output-ports/<port-UUID>" action="W"

  您可以將訪問策略應用於除連接之外的所有組件類型。連接授權由連接的源和目標組件上的各個訪問策略以及包含組件的進程組的訪問策略推斷。在下面的創建連接編輯連接示例中將對此進行更詳細的討論。
  爲了訪問連接的列表隊列或刪除隊列,用戶需要在組件上“查看數據”和“修改數據”策略的權限。在羣集環境中,所有節點也必須添加到這些策略中,因爲可以通過羣集中的任何節點複製用戶請求。

訪問策略繼承

管理員無需爲數據流中的每個組件手動創建策略。爲了減少管理員在授權管理上花費的時間,策略將從父資源繼承到子資源。例如,如果授予用戶查看和修改進程組的權限,則該用戶還可以查看和修改進程組中的組件。策略繼承使管理員可以一次分配策略,並在整個數據流中應用策略。

您可以覆蓋繼承的策略(如下面的移動處理器示例中所述)。覆蓋策略會刪除繼承的策略,從父項到子項斷開繼承鏈,並創建替換策略以根據需要添加用戶。可以通過刪除替換策略來恢復繼承的策略及其用戶。

  “查看策略”和“修改策略”組件級訪問策略是此繼承行爲的一個例外。將用戶添加到任一策略後,它們將添加到當前管理員列表中。他們不會覆蓋更高級別的管理員。因此,僅顯示特定於組件的管理員以查看“查看策略”和“修改策略”訪問策略。
  您無法修改繼承策略上的用戶/組。只能在父策略或覆蓋策略中添加或刪除用戶和組。

查看用戶策略

在UI中,從全局菜單中選擇“用戶”。這將打開“NiFi用戶”對話框。

選擇“查看用戶策略”圖標(用戶政策圖標)。

“用戶策略”窗口顯示已爲所選用戶設置的全局和組件級策略。選擇“轉到”圖標(轉到圖標)以導航到畫布中的該組件。

訪問策略配置示例

瞭解如何創建和應用訪問策略的最有效方法是介紹一些常見示例。以下方案假定User1是管理員,而User2是新添加的用戶,僅具有對UI的訪問權限。

讓我們從畫布上的兩個處理器開始作爲我們的起點:GenerateFlowFile和LogAttribute。

User1可以向數據流添加組件,並能夠移動,編輯和連接所有處理器。User1可以看到根進程組和處理器的詳細信息和屬性。

User1希望保持其對數據流及其組件的當前權限。

User2無法將組件添加到數據流或移動,編輯或連接組件。User2將隱藏根進程組和處理器的詳細信息和屬性。

移動處理器

爲了允許User2在數據流中移動GenerateFlowFile處理器而僅移動該處理器,User1執行以下步驟:

  1. 選擇GenerateFlowFile處理器以使其突出顯示。

  2. 訪問政策圖標從“操作”選項板中選擇“訪問策略”圖標(),然後打開“訪問策略”對話框。

  3. 從策略下拉列表中選擇“修改組件”。處理器(子)上當前存在的“修改組件”策略是從User1具有權限的根進程組(父)繼承的“修改組件”策略。

  4. 在策略繼承消息中選擇“覆蓋”鏈接。創建替換策略時,您可以選擇使用繼承策略的副本或空策略覆蓋。選擇“覆蓋”按鈕以創建副本。

  5. 在創建的替換策略上,選擇“添加用戶”圖標(添加用戶圖標)。在“用戶標識”字段中查找或輸入User2,然後選擇“確定”。通過這些更改,User1可以在畫布上移動兩個處理器。User2現在可以移動GenerateFlowFile處理器,但無法移動LogAttribute處理器。

編輯處理器

在上面的“移動處理器”示例中,User2被添加到GenerateFlowFile的“修改組件”策略中。如果無法查看處理器屬性,User2將無法修改處理器的配置。爲了編輯組件,用戶必須同時處於“查看組件”和“修改組件”策略。爲實現此目的,User1執行以下步驟:

  1. 選擇GenerateFlowFile處理器。

  2. 訪問政策圖標從“操作”選項板中選擇“訪問策略”圖標(),然後打開“訪問策略”對話框。

  3. 從策略下拉列表中選擇“查看組件”。組件“當前存在於處理器(子)上的策略”視圖是“查看組件”策略繼承自User1具有權限的根進程組(父組件) 。

  4. 在策略繼承消息中選擇“覆蓋”鏈接,保留“複製策略”的默認值並選擇“覆蓋”按鈕。

  5. 在創建的覆蓋策略上,選擇“添加用戶”圖標(添加用戶圖標)。在“用戶標識”字段中查找或輸入User2,然後選擇“確定”。通過這些更改,User1可以在畫布上查看和編輯處理器。User2現在可以查看和編輯GenerateFlowFile處理器。

創建連接

通過前面兩個示例中討論的配置訪問策略,User1能夠將GenerateFlowFile連接到LogAttribute:

User2無法建立連接:

這是因爲:

  • User2對進程組沒有修改權限。

  • 即使User2具有查看和修改對源組件(GenerateFlowFile)的訪問權限,User2也沒有對目標組件(LogAttribute)的訪問策略。

允許User2將GenerateFlowFile連接到LogAttribute,如User1:

  1. 選擇根進程組。操作選項板將更新根進程組的詳細信息。

  2. 訪問政策圖標從“操作”選項板中選擇“訪問策略”圖標(),然後打開“訪問策略”對話框。

  3. 從策略下拉列表中選擇“修改組件”。 

  4. 選擇“添加用戶”圖標(添加用戶圖標)。找到或輸入User2並選擇確定。

通過將User2添加到進程組上的“修改組件”策略,User2將通過策略繼承添加到LogAttribute處理器上的“修改組件”策略。要確認這一點,請突出顯示LogAttribute處理器,然後訪問政策圖標從Operate面板中選擇Access Policies圖標():

通過這些更改,User2現在可以將GenerateFlowFile處理器連接到LogAttribute處理器。

編輯連接

假設User1或User2將ReplaceText處理器添加到根進程組:

User1可以選擇並更改現有連接(在GenerateFlowFile和LogAttribute之間),現在將GenerateFlowFile連接到ReplaceText:

用戶2無法執行此操作。

允許User2將GenerateFlowFile連接到ReplaceText,如User1:

  1. 選擇根進程組。操作選項板將更新根進程組的詳細信息。

  2. 選擇“訪問策略”圖標(訪問政策圖標)。

  3. 從策略下拉列表中選擇“查看組件”。 

  4. 選擇“添加用戶”圖標(添加用戶圖標)。找到或輸入User2並選擇確定。

要添加到進程組的視圖和修改策略,User2現在可以將GenerateFlowFile處理器連接到ReplaceText處理器。

加密配置

本節概述了NiFi加密和解密數據的功能。

EncryptContent處理器允許加密和解密數據,這些數據既包含在NiFi內部,也包含在外部系統(如openssl其他數據源和消費者)中。

關鍵衍生函數

密鑰導出函數(KDF)是將人類可讀信息(通常是密碼或其他祕密信息)轉換爲適合於數據保護的加密密鑰的機制。有關詳細信息,請閱讀關鍵導出函數Wikipedia條目。目前,KDF由CipherProvider實現提取並返回Cipher用於加密或解密的完全初始化的對象。由於使用了a CipherProviderFactory,KDF目前無法自定義。未來的增強功能包括在初始化時向KDF提供自定義成本參數的能力。作爲解決方法,CipherProvider可以在構造函數中使用自定義成本參數初始化實例,但目前不支持CipherProviderFactory。以下是NiFi目前支持的KDF(主要EncryptContent用於基於密碼的加密處理器(PBE))和相關說明:

  • NiFi Legacy KDF

    • NiFi用於PBE的內部密鑰推導的原始KDF,這是在密碼和8或16字節隨機鹽的串聯上的MD5摘要的1000次迭代(鹽長度取決於所選擇的密碼塊大小)。

    • 從NiFi 0.5.0開始,該KDF已棄用,並且僅應用於向後兼容以解密先前由傳統版本的NiFi加密的數據。

  • OpenSSL PKCS#5 v1.5 EVP_BytesToKey

    • 該KDF在v0.4.0中添加。

    • 此KDF用於與使用OpenSSL的默認PBE加密的數據兼容,稱爲EVP_BytesToKey。這是MD5在密碼和8字節隨機ASCII鹽的串聯上的單次迭代。OpenSSL建議使用PBKDF2密鑰派生,但不公開命令行工具所需的庫方法,因此該KDF仍然是命令行加密的事實上的默認值。

  • Bcrypt

    • 該KDF在v0.5.0中添加。

    • Bcrypt是一種基於Blowfish密碼的自適應函數。強烈建議使用此KDF,因爲它會自動合併一個隨機的16字節鹽,可配置的成本參數(或“工作因素”),並且可以通過要求訪問“大”來使用GPGPU(在內核之間共享內存)來抵禦暴力攻擊。密鑰推導期間的內存塊。它對FPGA暴力攻擊的抵抗力較弱,門陣列可以訪問各個嵌入式RAM塊。

    • 由於Bcrypt派生密鑰的長度始終爲184位,因此將完整輸出提供給SHA-512摘要並截斷爲所需的密鑰長度。這爲格式化輸入提供了雪崩效應的好處。

    • 建議的最小工作因數是12(2 12個密鑰派生輪次)(截至2016年2 月 1 日的商品硬件),應增加到合法系統遇到有害延遲的閾值(參見下面的時間表或用於BcryptCipherProviderGroovyTest#testDefaultConstructorShouldProvideStrongWorkFactor()計算安全性)最小值)。

    • 鹽格式是$2a$10$ABCDEFGHIJKLMNOPQRSTUV。鹽被劃分,$三個部分如下:

      • 2a - 格式的版本。這裏可以找到廣泛的解釋。NiFi目前2a用於內部產生的所有鹽。

      • 10 - 工作因素。這實際上是log 2值,因此在這種情況下總迭代次數將是2 10。

      • ABCDEFGHIJKLMNOPQRSTUV - 22個字符,Base64編碼,未填充,原鹽值。這解碼爲密鑰派生中使用的16字節鹽。

  • Scrypt

    • 該KDF在v0.5.0中添加。

    • Scrypt是爲響應而設計的自適應功能bcrypt。建議使用此KDF,因爲它需要相對大量的內存用於每個派生,從而抵抗硬件暴力攻擊。

    • 建議的最低成本是N= 2 14,r= 8,p= 1(截至2016年2 月 1日的商品硬件),應增加到合法系統遇到有害延遲的閾值(參見下面的時間表或用於ScryptCipherProviderGroovyTest#testDefaultConstructorShouldProvideStrongParameters()計算安全性)最小值)。

    • 鹽格式是$s0$e0101$ABCDEFGHIJKLMNOPQRSTUV。鹽被劃分,$三個部分如下:

      • s0 - 格式的版本。NiFi目前s0用於內部產生的所有鹽。

      • e0101 - 成本參數。這實際上是一個十六進制編碼Nrp使用偏移。這可以使用Scrypt#encodeParams()和形成/解析Scrypt#parseParameters()

        • 一些外部庫以形式編碼Nrp單獨編碼$400$1$1$。可以使用實用方法ScryptCipherProvider#translateSalt()將外部表單轉換爲內部表單。

      • ABCDEFGHIJKLMNOPQRSTUV - 12-44字符,Base64編碼,未填充,原鹽值。這解碼爲密鑰派生中使用的8-32字節的鹽。

  • PBKDF2

    • 該KDF在v0.5.0中添加。

    • 基於密碼的密鑰推導功能2是一種自適應推導功能,它使用內部僞隨機函數(PRF)並通過密碼和鹽(至少16字節)多次迭代。

    • PRF建議爲HMAC/SHA-256HMAC/SHA-512。HMAC加密散列函數的使用減輕了長度擴展攻擊。

    • 建議的最小迭代次數爲160,000(截至2016年2月1日的商品硬件)。這個數字應該每兩年增加一倍(見下面的時間表或PBKDF2CipherProviderGroovyTest#testDefaultConstructorShouldProvideStrongIterationCount()用來計算安全最小值)。

    • 這個KDF不是內存很難(可以用商用硬件進行大規模並行化),但仍然建議NIST SP 800-132(PDF)和許多密碼學家(當使用適當的迭代計數和HMAC加密散列函數時)。

  • 沒有

    • 該KDF在v0.5.0中添加。

    • 該KDF不對輸入執行操作,並且是用於指示向密碼提供原始密鑰的標記。密鑰必須以十六進制編碼提供,並且對於關聯的密碼/算法具有有效長度。

其他資源

鹽和IV編碼

最初,EncryptContent處理器有一種從用戶提供的密碼導出加密密鑰的方法。現在NiFiLegacy有效地將其稱爲模式MD5 digest, 1000 iterations。在v0.4.0中,添加了另一種導出密鑰的方法,OpenSSL PKCS#5 v1.5 EVP_BytesToKey以便與使用openssl命令行工具在NiFi外部加密的內容兼容。這兩個密鑰派生函數(KDF)都具有硬編碼的摘要函數和迭代計數,並且salt格式也是硬編碼的。使用v0.5.0,引入了具有可變迭代計數,工作因子和鹽格式的附加KDF。另外,原始密鑰加密還介紹了。這需要將任意鹽和初始化矢量(IV)編碼到密碼流中的能力,以便由NiFi或後續系統恢復以解密這些消息。

對於現有的KDF,salt格式沒有改變。

NiFi Legacy

輸入的前8或16個字節是salt。鹽長度基於所選算法的密碼塊長度確定。如果無法確定密碼塊大小(例如使用流密碼RC4),則使用默認值8字節。在解密時,鹽被讀入並與密碼組合以導出加密密鑰和IV。

OpenSSL PKCS#5 v1.5 EVP_BytesToKey

OpenSSL允許使用salted或unsalted密鑰派生。*無保留密鑰派生是一種安全風險,不建議使用。*如果存在salt,則輸入的前8個字節爲ASCII字符串“Salted __”(0x53 61 6C 74 65 64 5F 5F),接下來的8個字節爲ASCII編碼的salt。在解密時,鹽被讀入並與密碼組合以導出加密密鑰和IV。如果沒有salt標頭,則整個輸入被認爲是密文。

對於新的KDF,每個都允許非確定性IV,IV必須與密文一起存儲。這不是一個漏洞,因爲IV不需要保密,而只是對於使用相同密鑰加密的消息是唯一的,以減少加密攻擊的成功。對於這些KDF,輸出包括鹽,然後是鹽分隔符,UTF-8字符串“NiFiSALT”(0x4E 69 46 69 53 41 4C 54)然後是IV,接着是IV分隔符,UTF-8字符串“NiFiIV”(0x4E 69 46 69 49 56),然後是密文。

Bcrypt,Scrypt,PBKDF2

 

 

 

 

 

 

Java密碼術擴展(JCE)有限強度管轄政策

由於美國的出口法規,默認JVM 對其可用的加密操作的強度施加了限制。例如,AES操作128 bit keys默認限制爲。雖然AES-128在加密方面是安全的,但這可能會產生意想不到的後果,特別是在基於密碼的加密(PBE)上。

PBE是從用戶提供的祕密材料(通常是密碼)導出用於加密或解密的加密密鑰的過程。不是人類記住(隨機出現的)32或64個字符的十六進制字符串,而是使用密碼或密碼。

由於基礎密鑰長度檢查,NiFi提供的許多PBE算法對密碼長度施加了嚴格的限制。下表列出了具有有限加密強度的JVM上的最大密碼長度。

表1.有限加密強度JVM上的最大密碼長度
算法最大密碼長度

PBEWITHMD5AND128BITAES-CBC-OPENSSL

16

PBEWITHMD5AND192BITAES-CBC-OPENSSL

16

PBEWITHMD5AND256BITAES-CBC-OPENSSL

16

PBEWITHMD5ANDDES

16

PBEWITHMD5ANDRC2

16

PBEWITHSHA1ANDRC2

16

PBEWITHSHA1ANDDES

16

PBEWITHSHAAND128BITAES-CBC-BC

7

PBEWITHSHAAND192BITAES-CBC-BC

7

PBEWITHSHAAND256BITAES-CBC-BC

7

PBEWITHSHAAND40BITRC2-CBC

7

PBEWITHSHAAND128BITRC2-CBC

7

PBEWITHSHAAND40BITRC4

7

PBEWITHSHAAND128BITRC4

7

PBEWITHSHA256AND128BITAES-CBC-BC

7

PBEWITHSHA256AND192BITAES-CBC-BC

7

PBEWITHSHA256AND256BITAES-CBC-BC

7

PBEWITHSHAAND2-KEYTRIPLEDES-CBC

7

PBEWITHSHAAND3-KEYTRIPLEDES-CBC

7

PBEWITHSHAANDTWOFISH-CBC

7

允許不安全的加密模式

默認情況下,處理器設置中的Allow Insecure Cryptographic Modes屬性EncryptContent設置爲not-allowed。這意味着如果提供的密碼少於10字符,則會發生驗證錯誤。10個字符是保守估計,不考慮完整熵計算,模式等。

在具有有限強度加密的JVM上,一些PBE算法將最大密碼長度限制爲7,在這種情況下,將無法提供“安全”密碼。建議爲JVM安裝JCE Unlimited Strength Jurisdiction Policy文件以緩解此問題。

如果在無法安裝無限強度策略的系統上,建議切換到支持更長密碼的算法(參見上表)。

 

允許弱加密

如果它是不可能安裝無限強度管轄的政策,該Allow Weak Crypto設置可以改變allowed,但是這是推薦的。更改此設置明確承認使用弱加密配置的固有風險。

最好是請求上游/下游系統切換到密鑰加密或使用NiFi支持的“強” 密鑰導出功能(KDF)

配置文件中的加密密碼

爲了便於安全設置NiFi,您可以使用encrypt-config命令行實用程序加密NiFi在啓動時在內存中解密的原始配置值。這種可擴展的保護方案透明地允許NiFi在操作中使用原始值,同時保護它們靜止。將來,將集成硬件安全模塊(HSM)和外部安全存儲機制,但目前,AES加密提供程序是默認實現。

這是行爲的改變; 在1.0之前,所有配置值都以明文形式存儲在文件系統上。建議使用POSIX文件權限來限制對這些文件的未授權訪問。

如果未執行管理員操作,則配置值保持未加密狀態。

有關更多信息,請參閱“ NiFi工具包指南”中的“ 加密配置工具”部分。

NiFi工具包管理工具

除了tls-toolkit和之外encrypt-config,NiFi Toolkit還包含命令行實用程序,供管理員在獨立和集羣環境中支持NiFi維護。這些工具包括:

  • CLI - 該cli工具使管理員能夠與NiFi和NiFi Registry實例進行交互,以自動執行諸如部署版本化流程以及管理流程組和羣集節點等任務。

  • 文件管理器(File Manager) - 該file-manager工具使管理員能夠從備份中備份,安裝或恢復NiFi安裝。

  • 流量分析器(Flow Analyzer) - 該flow-analyzer工具生成一個報告,幫助管理員瞭解可以存儲在給定流量的背壓中的最大數據量。

  • 節點管理器(Node Manager ) - 該node-manager工具使管理員能夠對節點執行狀態檢查,以及從羣集連接,斷開連接或刪除節點的功能。

  • 通知(Notify) - 該notify工具使管理員能夠將公告發送到NiFi UI。

  • S2S - 該s2s工具使管理員能夠通過站點到站點將數據發送到NiFi流中或從中發送出來。

有關每個實用程序的詳細信息,請參閱“ NiFi工具包指南”

羣集配置

本節簡要概述了NiFi羣集以及如何設置基本羣集的說明。在未來,我們希望提供涵蓋NiFi集羣架構的補充文檔。

零主集羣

NiFi採用Zero-Master Clustering範例。集羣中的每個節點都對數據執行相同的任務,但每個節點都在不同的數據集上運行。其中一個節點自動選擇(通過Apache ZooKeeper)作爲集羣協調器。然後,羣集中的所有節點都會向此節點發送心跳/狀態信息,並且此節點負責斷開在一段時間內未報告任何心跳狀態的節點。此外,當新節點選擇加入羣集時,新節點必須首先連接到當前選定的羣集協調器,以獲取最新的流。如果羣集協調器確定允許該節點加入(基於其配置的防火牆文件),則將當前流提供給該節點,並且該節點能夠加入羣集,假設節點的流副本與羣集協調器提供的副本匹配。如果節點的流配置版本與羣集協調器的版本不同,則該節點將不會加入羣集。

爲什麼集羣?

NiFi管理員或DataFlow管理器(DFM)可能會發現在單個服務器上使用一個NiFi實例不足以處理他們擁有的數據量。因此,一種解決方案是在多個NiFi服務器上運行相同的數據流。但是,這會產生管理問題,因爲每次DFM想要更改或更新數據流時,他們必須在每個服務器上進行這些更改,然後單獨監視每個服務器。通過集羣NiFi服務器,可以增加處理能力以及單個接口,通過該接口可以更改數據流並監控數據流。羣集允許DFM僅進行一次更改,然後將更改複製到羣集的所有節點。通過單一接口,DFM還可以監視所有節點的健康狀況和狀態。

術語

NiFi Clustering是獨一無二的,有自己的術語。在設置羣集之前瞭解以下術語非常重要:

NiFi羣集協調器(NiFi Cluster Coordinator):NiFi羣集協調器是NiFi羣集中的節點,負責執行任務以管理羣集中允許的節點,併爲新加入的節點提供最新的流量。當DataFlow Manager管理羣集中的數據流時,他們可以通過羣集中任何節點的用戶界面執行此操作。然後,所做的任何更改都將複製到羣集中的所有節點。

節點(Nodes):每個羣集由一個或多個節點組成。節點執行實際的數據處理。

主節點(Primary Node):每個羣集都有一個主節點。在此節點上,可以運行“隔離處理器”(見下文)。ZooKeeper用於自動選擇主節點。如果該節點由於任何原因斷開與羣集的連接,將自動選擇新的主節點。用戶可以通過查看用戶界面的“羣集管理”頁面來確定當前選擇哪個節點作爲主節點。

孤立的處理器:在NiFi羣集中,相同的數據流在所有節點上運行。因此,流中的每個組件都在每個節點上運行。但是,可能存在DFM不希望每個處理器在每個節點上運行的情況。最常見的情況是使用的處理器使用不能很好擴展的協議與外部服務進行通信。例如,GetSFTP處理器從遠程目錄中提取。如果GetSFTP處理器在羣集中的每個節點上運行並同時嘗試從同一個遠程目錄中提取,則可能存在競爭條件。因此,DFM可以將主節點上的GetSFTP配置爲獨立運行,這意味着它僅在該節點上運行。通過適當的數據流配置,它可以提取數據並在羣集中的其餘節點之間對其進行負載平衡。請注意,雖然存在此功能,但僅使用獨立的NiFi實例來提取數據並將其提供給羣集也很常見。它僅取決於可用資源以及管理員決定配置羣集的方式。

心跳:節點通過“心跳”將其健康狀況和狀態傳達給當前選定的羣集協調器,這使協調器知道它們仍然連接到羣集並正常工作。默認情況下,節點每5秒發出一次心跳,如果羣集協調器在40秒內沒有從節點收到心跳,則由於“缺乏心跳”而斷開節點。5秒設置可在nifi.properties文件中配置(請參閱羣集公共屬性部分了解更多信息)。羣集協調器斷開節點的原因是協調器需要確保羣集中的每個節點都處於同步狀態,並且如果沒有定期聽到節點,協調器無法確定它是否仍與其餘節點同步集羣。如果在40秒後節點發送新的心跳,協調器將自動請求節點重新加入羣集,以包括重新驗證節點的流。一旦接收到心跳,由於心跳不足導致的斷開連接和重新連接都會報告給用戶界面中的DFM。

集羣內的通信

如上所述,節點通過心跳與羣集協調器通信。當選擇羣集協調器時,它會使用其連接信息更新Apache ZooKeeper中衆所周知的ZNode,以便節點了解發送心跳的位置。如果其中一個節點發生故障,則羣集中的其他節點將不會自動獲取丟失節點的負載。DFM可以配置故障轉移意外事件的數據流; 但是,這取決於數據流設計,並不會自動發生。

當DFM對數據流進行更改時,接收更改流的請求的節點會將這些更改傳遞給所有節點,並等待每個節點響應,表明它已對其本地流進行了更改。

管理節點

斷開節點

DFM可以手動斷開節點與羣集的連接。節點也可能由於其他原因而斷開連接,例如由於缺乏心跳。當節點斷開連接時,羣集協調器將在用戶界面上顯示公告。在解決斷開連接節點的問題之前,DFM將無法對數據流進行任何更改。DFM或管理員需要對節點的問題進行故障排除,並在對數據流進行任何新的更改之前解決該問題。但是,值得注意的是,僅僅因爲節點斷開連接並不意味着它不起作用。這可能由於某些原因而發生,例如,當節點由於網絡問題而無法與集羣協調器通信時。

要手動斷開節點,請斷開圖標從節點的行中選擇“斷開連接”圖標()。

斷開連接的節點可以連接(連接圖標),卸載(卸載圖標)或刪除(刪除圖標)。

  並非所有處於“已斷開連接”狀態的節點都可以卸載。如果節點斷開連接且無法訪問,則節點無法接收卸載請求以啓動卸載。此外,由於防火牆規則,可能會中斷或阻止卸載。

卸載節點

保留在斷開連接的節點上的流文件可以通過卸載重新平衡到羣集中的其他活動節點。在Cluster Management對話框中,卸載圖標爲Disconnected節點選擇“Offload”圖標()。這將停止所有處理器,終止所有處理器,停止在所有遠程進程組上傳輸,並將流文件重新平衡到羣集中的其他連接節點。

由於遇到錯誤(內存不足,沒有網絡連接等)而保持“卸載”狀態的節點可以通過重新啓動節點上的NiFi重新連接到羣集。卸載的節點可以重新連接到羣集(通過選擇連接或重新啓動節點上的NiFi)或從羣集中刪除。

刪除節點(Delete Nodes)

在某些情況下,DFM可能希望繼續對流進行更改,即使節點未連接到羣集也是如此。在這種情況下,DFM可以選擇完全從集羣中刪除節點。在Cluster Management對話框中,刪除圖標爲Disconnected或Offloaded節點選擇“Delete”圖標()。刪除後,在重新啓動節點之前,節點無法重新加入羣集。

退役節點 (Decommission Nodes)

停用節點並將其從羣集中刪除的步驟如下:

  1. 斷開節點。

  2. 斷開連接完成後,卸載節點。

  3. 卸載完成後,刪除該節點。

  4. 刪除請求完成後,停止/刪除主機上的NiFi服務。

NiFi CLI節點命令

作爲UI的替代方案,以下NiFi CLI命令可用於檢索單個節點,檢索節點列表以及連接/斷開/卸載/刪除(connecting/disconnecting/offloading/deleting )  節點:

  • nifi get-node

  • nifi get-nodes

  • nifi connect-node

  • nifi disconnect-node

  • nifi offload-node

  • nifi delete-node

有關更多信息,請參閱NiFi工具包指南中NiFi CLI部分。

流動選舉

當羣集首次啓動時,NiFi必須確定哪個節點具有流的“正確”版本。這是通過對每個節點具有的流進行投票來完成的。當節點嘗試連接到羣集時,它會將其本地流的副本提供給羣集協調器。如果尚未選擇流“正確”流,則將節點的流與每個其他節點的流進行比較。如果另一個Node的流與此流匹配,則爲此流投票。如果還沒有其他節點報告相同的流,則此流將以一票投票的方式添加到可能選擇的流池中。經過一段時間後(通過設置nifi.cluster.flow.election.max.wait.time屬性配置)或一些節點有投票(通過設置nifi.cluster.flow.election.max.candidates屬性),流被選爲流的“正確”副本。然後,具有不兼容流的所有節點將與羣集斷開連接,而具有兼容流的節點將繼承羣集的流。選舉是根據“民衆投票”進行的,但需要注意的是,除非所有流量都是空的,否則獲勝者永遠不會是“空流”。這允許管理員刪除節點的flow.xml.gz文件並重新啓動節點,因爲知道節點的流將不會被投票爲“正確”流,除非找不到其他流。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章