4、NiFi集群部署及验证、监控及节点管理

Apache NiFi系列文章

1、nifi-1.9.2介绍、单机部署及简单验证
2、NIFI应用示例-GetFile和PutFile应用
3、NIFI处理器介绍、FlowFlie常见属性、模板介绍和运行情况信息查看
4、集群部署及验证、监控及节点管理
5、NiFi FileFlow示例和NIFI模板示例
6、NIFI应用场景-离线同步Mysql数据到HDFS中
7、NIFI综合应用场景-将mysql查询出的json数据转换成txt后存储至HDFS中
8、NIFI综合应用场景-NiFi监控MySQL binlog进行实时同步到hive
9、NIFI综合应用场景-通过NIFI配置kafka的数据同步



本分主要介绍NIFI的两种集群部署方式以及节点的日常管理和简单介绍state管理。
本文前提依赖是zookeeper环境具备。
本分分为三个部分,即集群部署、节点管理和state管理。

一、NIFI集群部署

DFM(DataFlow Manager)可能会发现在单个服务器上使用一个NiFi实例不足以处理他们拥有的数据量。集群NiFi服务器,可以增加处理能力同时,支持单接口控制,通过该接口可以更改整个集群数据流并监控数据流。集群允许DFM只进行一次更改,然后将更改的内容复制到集群的所有节点。通过单一接口,DFM还可以监视所有节点的健康状况和状态。
在这里插入图片描述

1、零主集群

NiFi采用Zero-Master Clustering。集群中的每个节点都对数据执行相同的任务,但每个节点都在不同的数据集上运行。其中一个节点自动被选择(通过Apache ZooKeeper)作为集群协调器。然后,集群中的所有节点都会向此节点发送心跳/状态信息,并且此节点负责断开在一段时间内未报告任何心跳状态的节点。此外,当新节点选择加入集群时,新节点必须首先连接到当前选定的集群协调器,以获取最新的流。如果集群协调器确定允许该节点加入(基于其配置的防火墙文件),则将当前流提供给该节点,并且该节点能够加入集群,假设节点的流副本与集群协调器提供的副本匹配。如果节点的流配置版本与集群协调器的版本不同,则该节点将不会加入集群。

  • NiFi集群协调器(NiFi Cluster Coordinator):NiFi集群协调器是NiFi集群中的节点,负责管理集群中允许执行任务的节点,并为新加入的节点提供最新的数据流量。当DataFlow Manager管理集群中的数据流时,可以通过集群中任何节点的用户界面执行此操作。然后,所做的任何更改都将复制到集群中的所有节点。
  • 节点(Nodes):每个集群由一个或多个节点组成。节点执行实际的数据处理。
  • 主节点(Primary Node):每个集群都有一个主节点。在此节点上,可以运行"隔离处理器"。ZooKeeper用于自动选择主节点。如果该节点由于任何原因断开与集群的连接,将自动选择新的主节点。用户可以通过查看用户界面的"集群管理"页面来确定当前选择哪个节点作为主节点。
    在这里插入图片描述
  • 孤立的Processor:在NiFi集群中,相同的数据流会在所有节点上运行。但是,可能存在DFM不希望每个处理器在每个节点上运行的情况。最常见的情况是使用的处理器存在与外部服务进行通信得的情况。例如,GetSFTP处理器从远程目录中提取。如果GetSFTP处理器在集群中的每个节点上运行并同时尝试从同一个远程目录中提取,则可能存在重复读取。因此,DFM可以将主节点上的GetSFTP配置为独立运行,这意味着它仅在该节点上运行。通过适当的数据流配置,它可以提取数据并在集群中的其余节点之间对其进行负载平衡。注意,虽然存在此功能,但仅使用独立的NiFi实例来提取数据并将其输出内容分发给集群也很常见。它仅取决于可用资源以及管理员配置集群的方式。
  • 心跳:节点通过"心跳"将其健康状况和状态传达给当前选定的集群协调器,这使协调器知道它们仍然处于连接状态并正常工作。默认情况下,节点每5秒发出一次心跳,如果集群协调器在40秒内没有从节点收到心跳,则由于"缺乏心跳"而断开节点。5秒设置可在_nifi.properties_文件中配置。集群协调器断开节点的原因是协调器需要确保集群中的每个节点都处于同步状态,并且如果没有定期收听到节点,协调器无法确定它是否仍与其余节点同步。如果在40秒后节点发送新的心跳,协调器将自动把请求节点重新加入集群。一旦接收到心跳,由于心跳不足导致的断开连接和重新连接信息都会报告给用户界面中的DFM

2、环境基础

1、系统:CentOS 6.10
2、Java环境:JDK8

3、部署

NiFi的集群部署有两种方式,即使用其自带的zookeeper或使用独立的zookeeper。本次部署采用的是独立的zookeeper,也是实际生产中常见的部署方式;自带的zookeeper部署仅供参考,一般用于开发或测试环境。

1)、使用NiFi集成的zookeeper

​ NiFi依赖于ZooKeeper以实现集群配置。但是,在有些环境中,部署了NiFi,而没有维护现有的ZooKeeper集群。为了避免强迫管理员维护单独的ZooKeeper实例的负担,NiFi提供了嵌入式ZooKeeper服务器的选项。
在这里插入图片描述
通过设置 nifi.properties 中的nifi.state.management.embedded.zookeeper.start属性为true来运行嵌入式的ZooKeeper服务器。

通常建议在3或5个节点上运行ZooKeeper。关于zookeeper的作用或部署要求详见本人zookeeper专栏相关内容。

如果nifi.state.management.embedded.zookeeper.start属性设置为true,则 nifi.properties 中的nifi.state.management.embedded.zookeeper.properties属性也需要设置。它用来指定要使用的ZooKeeper属性文件。这个属性文件至少需要配置ZooKeeper的服务器列表。另注意,由于ZooKeeper将侦听这些端口,因此可能需要将防火墙配置为打开这些端口。默认值为2181,但可以通过_zookeeper.properties_文件中的_clientPort_属性进行配置。

使用嵌入式ZooKeeper时,/ _conf / zookeeper.properties_文件具有名为dataDir的属性。默认情况下,此值为./state/zookeeper。如果多个NiFi节点正在运行嵌入式ZooKeeper,则必须告知服务器它是哪一个。通过创建名为_myid_的文件 并将其放在ZooKeeper的数据目录中来实现。此文件的内容应该是不同服务器的唯一索引值。
对于某一个ZooKeeper服务器,进行如下操作

cd $NIFI_HOME
mkdir state
mkdir state/zookeeper
echo 1 > state/zookeeper/myid

对于将运行ZooKeeper的下一个NiFi节点,进行如下操作

cd $NIFI_HOME
mkdir state
mkdir state/zookeeper
echo 2 > state/zookeeper/myid

采用三个节点的集群,且在一台机器上搭建,不同节点的端口会不同;如果搭建在三台机器上,IP不同,那么端口可以相同。

1、上传并解压

上传nifi-1.9.2-bin.tar.gz文件到服务器的/usr/local/bigdata目录下,并进行解压:

tar -zxvf nifi-1.9.2-bin.tar.gz -C /usr/local/bigdata/nifi-1.9.2-18001

在同个目录下创建三个副本,即将上文中解压的文件复制三份。

cp -r nifi-1.9.2-18001/ nifi-1.9.2-18002
cp -r nifi-1.9.2-18001/ nifi-1.9.2-18003
2、修改zookeeper配置文件

编辑实例中,conf/zookeeper.properties文件,不同节点改成对应内容,内容如下:

# zk客户端连接接口:1节点12181,2节点12182,1节点12183
clientPort=12181
# 不同服务的IP和选举端口号
server.1=192.168.52.15:12888:13888
server.2=192.168.52.15:14888:15888
server.3=192.168.52.15:16888:17888
3、修改zookeeper的节点id

在单个实例中新建文件夹,${NIFI_HOME}/state/zookeeper,在此文件夹中新建文件myid,且输入内容如下,三个都需要修改,与zookeeper的配置内容相对应。

1
4、修改NiFi的配置文件

编辑节点conf/nifi.properties文件,修改内容如下:

####################
# State Management #
####################
nifi.state.management.configuration.file=./conf/state-management.xml
nifi.state.management.provider.local=local-provider
nifi.state.management.provider.cluster=zk-provider
#  指定此NiFi实例是否应运行嵌入式ZooKeeper服务器,默认是false
nifi.state.management.embedded.zookeeper.start=true

nifi.state.management.embedded.zookeeper.properties=./conf/zookeeper.properties 

# web properties #                                                 
nifi.web.war.directory=./lib
# HTTP主机。默认为空白
nifi.web.http.host=192.168.52.15
# HTTP端口。默认值为8080;修改为18001、18002、18003
nifi.web.http.port=18001

# cluster node properties (only configure for cluster nodes) #   
# 如果实例是群集中的节点,请将此设置为true。默认值为false
nifi.cluster.is.node=true 
# 节点的完全限定地址。默认为空白
nifi.cluster.node.address=192.168.52.15
# 节点的协议端口。默认为空白,修改为:28001、28002、28003
nifi.cluster.node.protocol.port=28001

# 指定在选择Flow作为“正确”流之前等待的时间量。如果已投票的节点数等于nifi.cluster.flow.election.max.candidates属性指定的数量,则群集将不会等待这么长时间。默认值为5 mins
nifi.cluster.flow.election.max.wait.time=1 mins 
# 指定群集中所需的节点数,以便提前选择流。这允许群集中的节点避免在开始处理之前等待很长时间,如果我们至少达到群集中的此数量的节点
nifi.cluster.flow.election.max.candidates=1

# cluster load balancing properties #  
nifi.cluster.load.balance.host=
# 修改为:16342、26342、36342
nifi.cluster.load.balance.port=16342

# zookeeper properties, used for cluster management # 
# 连接到Apache ZooKeeper所需的连接字符串。这是一个以逗号分隔的hostname:port对列表
nifi.zookeeper.connect.string=192.168.52.15:12181,192.168.52.15:12182,192.168.52.15:12183
nifi.zookeeper.connect.timeout=3 secs                                                      
nifi.zookeeper.session.timeout=3 secs                                                   
nifi.zookeeper.root.node=/nifi

# 节点2、节点3内容跟节点1相同,只是nifi.web.http.port、nifi.cluster.node.protocol.port、nifi.cluster.load.balance.port这三个端口区分开来,避免端口重复
5、修改state-management.xml

编辑实例conf/state-management.xml文件,内容如下:


<cluster-provider>
    <id>zk-provider</id>
    <class>
        org.apache.nifi.controller.state.providers.zookeeper.ZooKeeperStateProvider
    </class>
    <property name="Connect String">
        192.168.52.15:12181,192.168.52.15:12182,192.168.52.15:12183
    </property>
    <property name="Root Node">/nifi</property>
    <property name="Session Timeout">10 seconds</property>
    <property name="Access Control">Open</property>
</cluster-provider>
6、验证

启动三个实例,浏览器输入:192.168.52.15:18001,访问即可
在这里插入图片描述
在这里插入图片描述

2)、使用外部zookeeper

此处是本文部署的重点,也是实际生产中使用的典型模式。

1、安装启动集群Zookeeper

确保zookeeper集群正常启动,并可用。

2、修改zookeeper配置文件

该部署的2-5步骤是在server1上完成的,server1的ip:192.168.10.41

conf/zookeeper.properties文件

clientPort=2118

server.1=server1:2888:3888
server.2=server2:2888:3888
server.3=server3:2888:3888
3、修改nifi.properties配置

编辑节点conf/nifi.properties文件

####################
# State Management #                                                                                                 
####################
nifi.state.management.configuration.file=./conf/state-management.xml                                             
nifi.state.management.provider.local=local-provider  
nifi.state.management.provider.cluster=zk-provider
#  指定此NiFi实例是否应运行嵌入式ZooKeeper服务器,默认是false  
# 连接外部的时候,设置为false
nifi.state.management.embedded.zookeeper.start=false                          
nifi.state.management.embedded.zookeeper.properties=./conf/zookeeper.properties 

# web properties #                                                 
nifi.web.war.directory=./lib    
# HTTP主机。默认为空白,即本机localhost。集群中需要填写各node的ip
nifi.web.http.host=192.168.10.41
# HTTP端口。默认值为8080
nifi.web.http.port=38080

# cluster node properties (only configure for cluster nodes) #   
# 如果实例是群集中的节点,请将此设置为true。默认值为false
nifi.cluster.is.node=true 
# 节点的完全限定地址。默认为空白,即本机localhost。集群中需要填写各node的ip
nifi.cluster.node.address=192.168.10.41
# 节点的协议端口。默认为空白
nifi.cluster.node.protocol.port=38001

# 指定在选择Flow作为“正确”流之前等待的时间量。如果已投票的节点数等于nifi.cluster.flow.election.max.candidates属性指定的数量,则群集将不会等待这么长时间。默认值为5 mins
nifi.cluster.flow.election.max.wait.time=1 mins 
# 指定群集中所需的节点数,以便提前选择流。这允许群集中的节点避免在开始处理之前等待很长时间,如果我们至少达到群集中的此数量的节点
nifi.cluster.flow.election.max.candidates=1

# cluster load balancing properties #  
nifi.cluster.load.balance.host=
nifi.cluster.load.balance.port=6342

# zookeeper properties, used for cluster management # 
# 连接到Apache ZooKeeper所需的连接字符串。这是一个以逗号分隔的hostname:port对列表
# 连接外部的时候使用外部ZooKeeper连接地址
nifi.zookeeper.connect.string=server1:2118,server2:2118,server3:2118
nifi.zookeeper.connect.timeout=3 secs                                                      
nifi.zookeeper.session.timeout=3 secs     
# zk上的注册的节点  同一个zk集群的同一个节点设定为同一个nifi集群
# 根节点和zk集群ip同state-management.xml文件中的一致                                              
nifi.zookeeper.root.node=/nifi 
4、修改state-management.xml配置

编辑实例conf/state-management.xml文件,内容如下:

<cluster-provider>                   
    <id>zk-provider</id>                        
    <class>
        org.apache.nifi.controller.state.providers.zookeeper.ZooKeeperStateProvider
    </class>
    <!-- 使用外部zookeeper连接地址 --> 
    <property name="Connect String">
        server1:2118,server2:2118,server3:2118
    </property>           
    <!-- 根节点和zk集群ip同nifi.properties文件中的一致 -->
    <property name="Root Node">/nifi</property>               
    <property name="Session Timeout">10 seconds</property>
    <property name="Access Control">Open</property>
</cluster-provider>
5、复制至其他服务器
scp -r nifi-1.9.2 server2:$PWD
scp -r nifi-1.9.2 server3:$PWD
6、修改集群其他机器上的配置

本集群是三台nifi的机器,故本步骤需要修改的是server2、server3的机器,其ip是192.168.10.42、192.168.10.43
/conf/nifi.properties

# 修改内容:
## 分别需要在两台机器上进行修改

# server2/3节点需要配置nifi.properties文件,修改对应的IP
...
nifi.web.http.host=192.168.10.42/43
...
nifi.cluster.node.address=192.168.10.42/43
...
7、启动三台服务

需要集群中的每台机器都需要启动

#在server1、server2、server3节点分别注册nifi服务
cd /usr/local/bigdata/nifi-1.9.2/bin
./nifi.sh install
Service nifi installed

#在server1、server2、server3节点分别启动集群
service nifi start

如果没有安装服务,则可以直接运行 nifi.sh start即可

8、验证

在浏览器中输入nifi.web.http.host 属性配置的地址即可,即本集群中三台机器的任意一台机器的ip均可。

在这里插入图片描述
在这里插入图片描述
以上,完成了NIFI的集群部署与验证。

二、节点管理

1、断开节点

DFM可以手动断开节点与集群的连接。节点也可能由于其他原因而断开连接,例如由于缺乏心跳。当节点断开连接时,集群协调器将在用户界面上显示公告。在解决断开连接节点的问题之前,DFM将无法对数据流进行任何更改。DFM或管理员需要对节点的问题进行故障排除,并在对数据流进行任何新的更改之前解决该问题。但是,仅仅因为节点断开连接并不意味着它不起作用。这可能由于某些原因而发生,例如,当节点由于网络问题而无法与集群协调器通信时。

要手动断开节点,请从节点的行中选择"断开连接"图标。断开连接的节点可以连接,卸载或删除。
在这里插入图片描述
并非所有处于"已断开连接"状态的节点都可以卸载。如果节点断开连接且无法访问,则节点无法接收卸载请求以启动卸载。此外,由于防火墙规则,可能会中断或阻止卸载。

2、卸载节点

保留在断开连接的节点上的流文件可以通过卸载重新平衡到集群中的其他活动节点。在Cluster Management对话框中,为Disconnected节点选择"Offload"图标。这将停止所有处理器,终止所有处理器,停止在所有远程进程组上传输,并将流文件重新平衡到集群中的其他连接节点。

由于遇到错误(内存不足,没有网络连接等)而保持"卸载"状态的节点可以通过重新启动节点上的NiFi重新连接到集群。卸载的节点可以重新连接到集群(通过选择连接或重新启动节点上的NiFi)或从集群中删除。
在这里插入图片描述

3、删除节点

在某些情况下,DFM可能希望继续对流进行更改,即使节点未连接到集群也是如此。在这种情况下,DFM可以选择完全从集群中删除节点。在Cluster Management对话框中,为Disconnected或Offloaded节点选择"Delete"图标。删除后,在重新启动节点之前,节点无法重新加入集群。

4、退役节点

停用节点并将其从集群中删除的步骤如下:

  • 断开节点
  • 断开连接完成后,卸载节点
  • 卸载完成后,删除该节点
  • 删除请求完成后,停止/删除主机上的NiFi服务

5、NiFi CLI节点命令

以下NiFi CLI命令可用于检索单个节点,检索节点列表以及连接/断开/卸载/删除(connecting/disconnecting/offloading/deleting ) 节点

nifi get-node
nifi get-nodes
nifi connect-node
nifi disconnect-node
nifi offload-node
nifi delete-node

6、流动选举

cluster启动的时候,NiFi必须确定哪个节点具有流的"正确"版本信息。这是通过对每个节点具有的流进行投票来完成的。当节点尝试连接到集群时,它会将其本地流的副本flow.xml.gz提供给集群协调器。如果尚未选择流"正确"流,则将节点的流与每个其他节点的流进行比较。然后每台对和自己一样的flow进行投票。如果还没有其他节点报告相同的流,则此流将以一票投票的方式添加到可能选择的流池中。如果投票时间(nifi.cluster.flow.election.max.wait.time)到了或者某一个flow.xml.gz已经达到票数(nifi.cluster.flow.election.max.candidates),则选出一个正确的flow.xml.gz。然后,不一致的node自动挂掉,除非它自己没有flow.xml.gz;而具有兼容流的节点将继承集群的流。选举是根据"民众投票"进行的,但除非所有流量都是空的,否则获胜者永远不会是"空流"。
对于加入集群失败的节点,可以通过删除flow.xml.gz文件来加入集群。

三、State管理

NiFi为处理器报告任务,控制器服务和框架本身提供了一种机制来保持状态。例如,允许处理器在重新启动NiFi后从其停止的位置恢复。处理器可以从集群中的所有不同节点访问它的状态信息。

1、配置状态提供程序

当组件决定存储或检索状态时,有两种实现:节点本地或集群范围。在 nifi.properties 文件包含有关配置项。
在这里插入图片描述
此XML文件由顶级state-management元素组成,该元素具有local-provider和cluster-provider 元素。这些元素中的每一个都包含一个id元素,用于指定可在 nifi.properties 文件中引用的标识符, 以及一个class元素,该元素指定要用于实例化State Provider的完全限定类名。这些元素中的每一个可以具有零个或多个property元素。每个property元素都有一个属性,name即propertyState Provider支持的名称。property元素的文本内容是属性的值。

<local-provider>
    <id>local-provider</id>
    <class>org.apache.nifi.controller.state.providers.local.WriteAheadLocalStateProvider</class>
    <property name="Directory">./state/local</property>
    <property name="Always Sync">false</property>
    <property name="Partitions">16</property>
    <property name="Checkpoint Interval">2 mins</property>
</local-provider>

在_state-management.xml_文件(或配置的任何文件)中配置了这些状态提供程序后,这些提供程序可通过标识符被引用。

默认情况下,本地状态提供程序配置为将WriteAheadLocalStateProvider数据持久保存到 $NIFI_HOME/state/local目录。默认的集群状态提供程序配置为 ZooKeeperStateProvider。
默认的基于ZooKeeper的提供程序必须先Connect String填充其属性,然后才能使用它。
Connect String采用逗号分隔,IP和端口号使用:分割,例如 my-zk-server1:2181,my-zk-server2:2181,my-zk-server3:2181。如果没有为任何主机指定端口,2181则假定为ZooKeeper默认值 。

<cluster-provider>
    <id>zk-provider</id>
    <class>org.apache.nifi.controller.state.providers.zookeeper.ZooKeeperStateProvider</class>
    <property name="Connect String">server1:2118,server2:2118,server3:2118</property>
    <property name="Root Node">/nifi</property>
    <property name="Session Timeout">10 seconds</property>
    <property name="Access Control">Open</property>
</cluster-provider>

向ZooKeeper添加数据时,Access Control有两个选项:Open和CreatorOnly。如果该Access Control属性设置为Open,则允许任何人登录ZooKeeper并拥有查看,更改,删除或管理数据的完全权限。如果指定CreatorOnly,则仅允许创建数据的用户读取,更改,删除或管理数据。为了使用该CreatorOnly选项,NiFi必须提供某种形式的身份验证。建议使用Open。

如果NiFi配置为在独立模式下运行,则cluster-provider无需在_state-management.xml_ 文件中填充该元素,如果填充它们,实际上将忽略该元素。但是,local-provider元素必须始终存在并填充。

此外,如果NiFi在集群中运行,则每个节点还必须配置引用nifi.state.management.provider.cluster元素。否则,NiFi将无法启动。

这些都是通过外部的 state-management.xml 文件,而不是通过 nifi.properties 文件进行配置。

应注意,如果处理器和其他组件使用集群作用域保存状态,则如果实例是独立实例(不在集群中)或与集群断开连接,则将使用本地状态提供程序。这也意味着如果将独立实例迁移到集群中,则本地的状态将不再可用,因为该组件将开始使用集群状态提供程序而不是本地状态提供程序。

以上,完成了NIFI的集群部署验证、节点管理和state的内容。更多信息关注NIFI的其他内容。

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一瓢一瓢的饮 alanchanchn

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值