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 - 成本参数。这实际上是一个十六进制编码N，r，p使用偏移。这可以使用Scrypt#encodeParams()和形成/解析Scrypt#parseParameters()。

      • 一些外部库以形式编码N，r并p单独编码$400$1$1$。可以使用实用方法ScryptCipherProvider#translateSalt()将外部表单转换为内部表单。

    • ABCDEFGHIJKLMNOPQRSTUV - 12-44字符，Base64编码，未填充，原盐值。这解码为密钥派生中使用的8-32字节的盐。

• PBKDF2

  • 该KDF在v0.5.0中添加。

  • 基于密码的密钥推导功能2是一种自适应推导功能，它使用内部伪随机函数（PRF）并通过密码和盐（至少16字节）多次迭代。

  • PRF建议为HMAC/SHA-256或HMAC/SHA-512。HMAC加密散列函数的使用减轻了长度扩展攻击。

  • 建议的最小迭代次数为160,000（截至2016年2月1日的商品硬件）。这个数字应该每两年增加一倍（见下面的时间表或PBKDF2CipherProviderGroovyTest#testDefaultConstructorShouldProvideStrongIterationCount()用来计算安全最小值）。

  • 这个KDF不是内存很难（可以用商用硬件进行大规模并行化），但仍然建议NIST SP 800-132（PDF）和许多密码学家（当使用适当的迭代计数和HMAC加密散列函数时）。

• 没有

  • 该KDF在v0.5.0中添加。

  • 该KDF不对输入执行操作，并且是用于指示向密码提供原始密钥的标记。密钥必须以十六进制编码提供，并且对于关联的密码/算法具有有效长度。

其他资源

• 最佳scrypt成本参数和关系的解释

• NIST特刊800-132

• OWASP密码存储工作因子计算

• PBKDF2轮次计算

• Scrypt为KDF vs密码存储漏洞

• Scrypt vs. Bcrypt（截至2010年）

• Bcrypt vs PBKDF2

• 为Bcrypt选择工作因素

• Spring Security Bcrypt

• OpenSSL EVP BytesToKey PKCS＃1v1.5

• OpenSSL PBKDF2 KDF

• OpenSSL 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文件以缓解此问题。

• Java 8的JCE Unlimited Strength Jurisdiction策略文件

如果在无法安装无限强度策略的系统上，建议切换到支持更长密码的算法（参见上表）。

允许弱加密 如果它是不可能安装无限强度管辖的政策，该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文件并重新启动节点，因为知道节点的流将不会被投票为“正确”流，除非找不到其他流。