ApacheNIFIクラスターの高可用性を探る



Explore High Availability Apache Nifi Cluster



はじめに:この記事では、事故をシミュレートすることにより、ApacheNIFIクラスターの高可用性を調査することに焦点を当てています。このシナリオでは、3ノードのNIFIクラスターがあり、不明な理由でノードの1つがクラスターから切断されていることを前提としています。クラスター(接続されたノードの2つのクラスター)と、切断されたノードに何が起こるか、および各ノードのデータに何が起こるかを調べます。 (注:不明な理由でノードがクラスターから切断されているのは、システム管理者がノードを手動でアンインストールする場合とは異なります)。これとは別に、他は重要ではありません。

私は探索プロセスを詳細に説明しようとしています。読者はこの記事に従って、その場で検証することができます。



3ノードの疑似クラスターを構築する

このセクションでは、3ノードの疑似クラスター構成をローカルで構築する方法について簡単に説明します。

バージョンを除いて :Nifi-1.12.0-SNAPSHOT(はい、あなたはその権利を読んでいます、作者は時々Apacheにコードを提供する人でもあります)
ネイティブシステム : マックOS
動物園の飼育係 :NIFIビルトイン動物園飼育係



nifi.propertiesを変更します(変更が必要なものを選択しました)

# Specifies whether or not this instance of NiFi should run an embedded ZooKeeper server nifi.state.management.embedded.zookeeper.start=true # 3 nodes are 8081 8082 8083 nifi.web.http.port=8081 # cluster node properties (only configure for cluster nodes) # nifi.cluster.is.node=true # 3 nodes are 9081 9082 9083 nifi.cluster.node.protocol.port=9081 # 3 nodes are 6341 6342 6343 nifi.cluster.load.balance.port=6341 # zookeeper properties, used for cluster management # nifi.zookeeper.connect.string=localhost:2181,localhost:2182,localhost:2183

zookeeper.propertiesを変更します(3.5.5以降のサーバー文字列の後にクライアントポートを構成する必要があることに注意してください)

# 3 nodes are the same server.1=localhost:2111:31112181 server.2=localhost:2222:32222182 server.3=localhost:2333:33332183

state-management.xmlを変更します(3つのノードはすべて同じです)



<cluster-provider> <id>zk-providerid> <class>org.apache.nifi.controller.state.providers.zookeeper.ZooKeeperStateProviderclass> <property name='Connect String'>localhost:2181,localhost:2182,localhost:2183property> <property name='Root Node'>/nifiproperty> <property name='Session Timeout'>10 secondsproperty> <property name='Access Control'>Openproperty> cluster-provider>

3ノードのNIFIディレクトリ(binディレクトリは同じレベルにあります)で、新しいstate/zookeeperを作成し、zookeeperフォルダに新しいファイルを作成しますmyid、3つのノードは別々に書き込まれます123

#3 nodes write 1 2 3 separately echo 1 > myid

これまでのところ、組み込みのzookeeperを備えた単純なローカルで起動可能な3ノードの疑似クラスターが構成されています。 3つのNIFIノードを個別に開始します。

クラスターが正常に開始されました

シミュレーションプロセスの構築

プルGenerateFlow(ストリームファイルの生成に使用)およびLogAttribute(ログの印刷、ストリームファイル属性の出力)2つのコンポーネント。GenerateFlowマスターノードでのみ実行するように設定(クラスターモードでは、プロセスの最初のノードは通常、マスターノードとして実行するように設定する必要があります。これにより、重複データの処理を回避できます。これは、NIFIデータストリームを設計する際の常識です。もちろん、コンポーネントを除いて、ConsumeKafkaなどです。LogAttributeデフォルトでは、すべてのノードを実行できます。

構成connection負荷分散(各ノードにデータを分散します。そうでない場合、すべてのデータは実際にメインノードで処理されます)

クラスタノードが接続を失った後のストリーミングファイルの配布の調査

上記のプロセスのスクリーンショットの状態から、現在のプロセスのクラスターには3つのノードがあり、合計111のフローファイルがあることがわかります。ここで、NIFIノードを手動で停止して、不明な理由によるノードの損失をシミュレートします。

次に、クラスターが再度投票するのを待ちます。選出が完了したら、NIFIクラスターインターフェイスを開きます。

現時点では、NIFIクラスターに残っているストリームファイルは74個だけであり、欠落している37個のストリームファイルはまだ欠落しているノードにあります。同時に、失われたノードがクラスターに再接続されるか、システム管理者が失われたノードをアンインストールするまで、クラスターでプロセスの構成を変更できないこともわかります。

これはApacheNIFIの設計です。 NIFIはクラスターデータベース(GPなど)ではありません。これは単なるデータストリーム処理ツールです。各ノードまたは複数のノードでストリームファイルをバックアップする必要はありません。これにより、不要なIOが追加されます。また、ディスクストレージはNIFIのパフォーマンスに影響を与えます。

(欠落しているノードに37個のフローファイルがあるかどうかの確認の説明はここでは省略します。検証を確認する場合は、最初にクラスター内のすべてのノードを停止してから、欠落している接続をシミュレートしたノードを起動します。正常に起動したら、これは、何らかの理由でクラスターとの接続が失われたが、まだ実行中のノードです)

結論としてノードの1つに障害が発生した場合、クラスター内の他のノードは失われたノードの負荷を自動的に負担しません。欠落しているNIFIノードにデータがまだ存在します。

クラスターノードに障害が発生した後のストリームファイルの処理を調べる

欠落しているノードを再起動して、3ノードの疑似クラスターを復元します。connectionすでに111個のストリームファイルがあります(上記の調査から、これらの111個のストリームファイルは3ノードに分散されています)。この時点で開始しますLogAttributeクラスター内のデータを処理するアクションをシミュレートするコンポーネント。

起動後、障害をシミュレートするためにノードの1つをすぐに停止しました(ここではノードを直接強制終了しました)

クラスターが再選出されるまで待ち、クラスターインターフェースを開いて、ノードが失われた後のクラスターを監視します。



上記の3つの写真から、次のことがわかりました。 失われたノードの後のクラスターはまだデータを処理しています

それで、失われたノードがまだ実行されている(殺されていない、停止されていない)場合、何が起こりますか?

ノードがクラスターから切断されているが、不明な理由で実行されていることをシミュレートします(NIFIクラスターを停止し、失われたNIFIノードを再起動します)

次の図に示すように、これはクラスターから切断されたノードであり、そのユーザーインターフェイスにもアクセスできます。

スクリーンショットから、失われた接続ノードがまだデータを処理していることがわかります。時間を比較すると、接続が失われた後もNIFIノードがデータを処理していることがはっきりとわかります。最後のものLogAttribute印刷されたログは23:43:13、下の写真は私がNIFIクラスターを閉じたとき23:40:--、そして私はNIFIクラスターを停止した後に行方不明のノードを開始しました。

(さらに、上記の接続が失われたノードは変更できます。この設計は問題ありませんが、このノードをクラスターにスムーズに再接続したい場合は、この接続の切断を回避する必要があります(ノード変更プロセスの現象が発生します)

結論として :クラスター内のノードに障害が発生した場合でも、クラスターは引き続きデータを処理します。失われたノードも実行されている場合、失われたノードもデータの処理を続行します。

クラスターノードに障害が発生した後、マスターノードとして実行するように設定されたコンポーネントのステータスを調べます

クラスターを復元するためにノードに再接続した後、停止LogAttribute、起動GenerateFlow

上記のシミュレーションノードの損失を繰り返し、クラスターを表示しますGenerateFlowステータス


ご覧のとおり、マスターノードとして実行するように設定してくださいGenerateFlowビルドストリームファイルはまだ実行中です。

そして、欠落しているノードを数分間観察した後、GenerateFlowストリームファイルは生成されません。

結論として :クラスター内のノードに障害が発生した場合、マスターノードで実行するように設定されたクラスター内のコンポーネントは引き続き実行され、データを処理します。欠落しているノードも実行されている場合、マスターノードで実行するように設定されたコンポーネントは実行を継続せず、データを処理しません。

引き続き確認できます

引き続き詳細な検証と変更を行うことができますGenerateFlowすべてのノードで実行するように設定しますLogAttributeマスターノードでのみ実行するように設定し、上記の「ルーチン」に従ってさらに進んでくださいクラスター内のノードに障害が発生した場合に、クラスターと接続されていないノードのパフォーマンスを確認します。

総括する

まず、プロセス設計が科学的かつ合理的であるという前提の下で、クラスターノードに障害が発生した場合、Apache NIFIクラスターは、タスクの整合性、正確性、および継続的な実行を保証するという点で、ある程度の高可用性を備えています。失われたノードがまだ実行されている場合、データは完全で正確です。失われたノードがダウンしても、このノードに未処理のストリームファイルが残っている場合、データのこの部分は、手動で介入する前に実際に一時的に失われます。もちろん、クラスターがまだそこにある限り、タスクは常にオンになっています。進行中。 Apache NIFIを合理的かつ科学的に使用し、クラスターの正常性の監視で優れた仕事をし、彼のクラスターモードが一部の実稼働環境に適用されている限り、この程度のクラスターの高可用性はビジネスを完全にサポートできます。 (たとえば、比較的高いリアルタイムパフォーマンスでビジネスをサポートする一部の同期データステッププロセス)

公開なし

公式アカウントに従って、記事/ドキュメントの更新を直接プッシュしてください。