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つのノードは別々に書き込まれます1
、2
、3
#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を合理的かつ科学的に使用し、クラスターの正常性の監視で優れた仕事をし、彼のクラスターモードが一部の実稼働環境に適用されている限り、この程度のクラスターの高可用性はビジネスを完全にサポートできます。 (たとえば、比較的高いリアルタイムパフォーマンスでビジネスをサポートする一部の同期データステッププロセス)
公開なし
公式アカウントに従って、記事/ドキュメントの更新を直接プッシュしてください。