Slipstreamの高可用性(HA)

       アプリケーションまたはStreamJobで、アップストリームストリームに障害が発生し(予期しない終了など)、時間内に復元できない場合、システム全体が麻痺する可能性があります。したがって、ストリーム処理システムの高い可用性は特に重要です。


目次

1つ、サーバーHA

1.1サーバーHAの原理

1.2サーバーHA構成

1.3まとめ

2.Zookeeperモードでのストリーム処理は非常に利用可能です

2.1Zookeeperモードの構成

2.2注意が必要な事項

3、SlipstreamHAテスト


1つ、サーバーHA

       Slipstream InceptorServerの{autofailover}は、InceptorServerレベルでHA保証を提供します。これにより、1つのInceptorServerが予期せず終了した後、ストリームタスクが別のInceptorServerで自動的に再起動することが保証されます。Slipstream InceptorServerレベル{autofailover}は、少なくとも2つのSlipstream InceptorServerをデプロイする必要があります。そのうちの1つは{active}モードで動作し、ストリームタスクの受信と処理を担当します。残りのSlipstream InceptorServerは{standby}モードで動作し、ストリームタスクの受信と処理を担当しません。 。{active} Slipstream InceptorServerが予期せず終了すると、{standby} SlipstreamInceptorServerの1つが{active} Slipstream InceptorServerに切り替わり、ストリーミングタスクを再開し、新しいストリーミングタスクを受信して​​処理します。

1.1サーバーHAの原理

       Slipstream InceptorServerレベルの{autofailover}は、InceptorGatewayと連携して実装する必要があります。Inceptor Gatewayは、複数のSlipstreamInceptorServerとの接続を構成します。これらの構成済みSlipstreamInceptorServerは、Metastore、Zookeeper、およびHDFS(以下、共有メタデータと呼びます)と接続を共有します。InceptorGatewayと複数のSlipstreamInceptorServerおよびSlipstreamInceptorServerと共有メタデータ間の接続関係を次の図に示します。

       上記のSlipstreamInceptorServerは、{active} / {standby}モードで動作します。つまり、Inceptor Gatewayとの接続でのみ、上記のSlipstreamInceptorServerは{active} / {standby}モードの区別があり、{active} Slipstream InceptorServer Inceptor Gatewayによって送信されたストリームタスクの受信と処理を担当しますが、{standby} SlipstreamInceptorServerはInceptorGatewayによって送信されたストリームタスクを受信しません。{active} Slipstream InceptorServerが予期せず終了した後、Inceptor Gatewayは、{active} SlipstreamInceptorServerへの接続が中断されたことを検出します。InceptorGatewayが{active} Slipstream InceptorServerへの接続が中断されたことを検出すると、InceptorGatewayは{standby} SlipstreamInceptorServerを選択して新しい{active} Slipstream InceptorServerになり、このSlipstreamInceptorServerで元の{active}を復元しようとします。 } SlipstreamInceptorServerで実行されているストリームタスク。

1.2サーバーHA構成

       Slipstream InceptorServerレベルで{autofailover}を有効にする必要がある場合は、複数(少なくとも2つ)のSlipstream InceptorServerをデプロイする必要があります。これらのSlipstreamInceptorServerを構成して、Metastore、Zookeeper、およびHDFSを共有します。インストールおよび構成方法は次のとおりです。

       1. 8180監視インターフェイスで、[+サービス]を選択し、Slipstreamコンポーネントを選択して、[次へ]をクリックします。

       Slipstreamを高可用性に構成する場合は、MetaStoreを共有する必要があります。現時点では、SlipstreamのMetaStoreを選択する必要はありません。InceptorMetaStoreを共有することを選択できます。残りの構成は、デフォルトまたはカスタマイズできます。注:この時点でSlipstreamがクラスターにインストールされている場合、インストールされたSlipstreamもInceptor MetaStoreの共有を選択する必要があり、Slipstream MetaStoreを構成する必要はありません(InceptorMetaStoreが共有されているときにSlipstreamMetaStoreがオンになっている場合、コンポーネントは起動時に再起動します失敗)。

       インストールが成功するまで「次へ」をクリックします。

       2.複数のSlipstreamサーバーを正常にインストールした後、同じZookeeperクラスターを使用し、同じZookeeperディレクトリを構成するように複数のSlipstreamInceptorServerを構成する必要があります。関連する構成項目は次のとおりです。

       3.複数のSlipstreamInceptorServerは、同じHDFSクラスターを使用するように構成し、同じHDFSディレクトリを使用するように構成する必要があります。関連する構成項目は次のとおりです。

       4.複数のSlipstreamInceptorServerに接続するようにInceptorGatewayを構成する必要があります。InceptorGatewayコンポーネントがクラスターにインストールされている場合は、関連する構成ファイルを直接構成できます。InceptorGatewayコンポーネントがクラスターにインストールされていない場合は、最初に「アプリケーションマーケット」にアクセスする必要があります。にコンポーネントをインストールします。

       Inceptor Gatewayの高可用性構成には、ダウンタイム転送とオーバータイム転送が含まれます。ダウンタイム転送とは、優先サービスを提供するInceptorServerがダウンした場合(実行中に接続されていないか異常な場合)、InceptorGatewayが別のInceptorServerへの切り替えを要求することを意味します。タイムアウト転送とは、サービスを提供するInceptorServerが最初にタイムアウトを実行するときに、InceptorGatewayが別のInceptorServerへの切り替えを要求することを意味します。この関数には、servers.xml、route-rule.xml、route-cluster.xmlの3つの構成ファイルが含まれます。

       (1)servers.xmlファイル:Inceptor Gatewayは、servers.xmlファイルから利用可能なInceptorServer情報を取得する必要があります。

       (2)Route-rule.xmlファイル:すべての要求をクラスターTDH_testに送信します。

       (3)route-cluster.xmlファイル:nameはクラスター名、default-serversはservers.xmlファイルのserver-tag名であり、servers.xmlファイルの名前ではなく、使用可能なサービス名が構成されています。サービス名も次のようにする必要があります。これは、servers.xmlファイル内のサーバータグ名です。InceptorServerを「server-fail」および「timeout:1000」に切り替えるための戦略を設定します。「Server-fail」はダウンタイム転送を意味し、「timeout:1000」はタイムアウト転送を意味します。たとえば、クライアントが応答なしでマスター1サービスに1000ミリ秒間要求を送信すると、InceptorGatewayはそれをmaster2サービスに転送します。

       注: Kerberosが有効になっているInceptorServerクラスターの場合、InceptorGatewayを一時的に使用することはできません。

1.3まとめ

       SlipstreamInceptorServerの{active} / {standby}モードは、真の{active} / {standby}モードではありません。{standby}モードのSlipstreamInceptorServerの場合でも、このSlipstream InceptorServerに直接接続して、ストリームタスクを送信および処理できます。ただし、そうすると、ストリームタスクが繰り返し送信され、データに一貫性がなくなるリスクがあります。

       {active} Slipstream InceptorServerが予期せず終了してオンラインに戻った後も、Inceptor Gatewayは、{active}モードに切り替えられたSlipstream InceptorServerに送信する代わりに、新しいストリームタスクをSlipstreamInceptorServerに送信します。

       Slipstream InceptorServerレベルの{autofailover}は、イベントドリブンモードのストリームタスクでのみ使用できます。マイクロバッチモードは、InceptorServerレベルの{autofailover}をサポートしていません。Slipstream InceptorServerレベルで{autofailover}を有効にするには、ストリームタスクレベルでHAを有効にする必要があります。

2.Zookeeperモードでのストリーム処理は非常に利用可能です

       Zookeeperモードのストリーミングタスクのメタ情報はZookeeperに保存されます。また、このモードでは、タスクがHDFSに保存されるたびに完了するチェックポイント情報が表示されます。これにより、異常終了後にSlipstreamクラスター全体が再起動された場合でも、ストリームタスクで計算結果の精度を確保できます。

2.1Zookeeperモードの構成

       Zookeeperモードでは、8180インターフェイスで次のパラメータを設定する必要があります。

       1.基本的なパラメータ

       2.Zookeeper関連の構成

       3.チェックポイント関連の構成

2.2注意が必要な事項

       ZookeeperとHDFSのディレクトリは、Slipstreamの起動時に生成されます。誤って削除すると、Checkpointを起動するストリームタスクが正常に起動しない場合があります。このとき、手動でディレクトリを作成し、対応する権限を割り当てる必要があります。

3、SlipstreamHAテスト

       Slipstream HAを構成した後、関連するテストのために、ストリームとテーブルの間でGlobalLookupJoinを使用します。

       まず、「ストリームとストリームのスリップストリーム、ストリームとテーブルの結合」の「ストリームとテーブル間のGlobalLookupJoin」メソッドを使用して、関連するストリームとテーブルを作成します。スリップストリームストリームタスクの高可用性は、イベント駆動モードでのみ発生することに注意してください。サポート中、つまり、「streamsql.use.eventmode」= "true"をストリームタスクで設定する必要があります。Slipstreamストリームタスクレベルの高可用性を使用するには、CREATE STREAMJOBを使用してストリームタスクを定義する必要があり、対応するタスクレベルのパラメータがJOBPROPERTIESで指定されます。したがって、ストリームがトリガーされるときは、次のようにCREATESTREAMJOBによってトリガーされる必要があります。

CREATE STREAMJOB one AS ("insert into tab select * from s1")
JOBPROPERTIES(
 "streamsql.use.eventmode"="true",
 "morphling.task.max.failures"="5",
 "morphling.job.enable.checkpoint"="true",
 "morphling.job.checkpoint.interval"="5000",
 "morphling.job.enable.auto.failover"="true"
);

CREATE STREAMJOB two AS ("insert into t1 select * from s3")
JOBPROPERTIES(
 "streamsql.use.eventmode"="true",
 "morphling.task.max.failures"="5",
 "morphling.job.enable.checkpoint"="true",
 "morphling.job.checkpoint.interval"="5000",
 "morphling.job.enable.auto.failover"="true"
);

       パラメータ定義:

       (1)streamsql.use.eventmode:ストリームタスクはイベント駆動モードを使用します。

       (2)morphling.task.max.failures:タスク失敗の最大再試行回数。

       (3)morphling.job.enable.checkpoint:ストリーミングタスクのチェックポイントをオンにします。

       (4)morphling.job.checkpoint.interval:ストリームタスクチェックポイントの時間間隔。

       (5)morphling.job.enable.auto.failover:ストリーミングタスクの自動フェイルオーバーをオンにします。

       StreamJobを作成した後、次のコマンドを使用して、作成されたStreamJobを表示できます。

show streamjobs;

       次のコマンドを使用してStreamJobを開始します。

START STREAMJOB one;

START STREAMJOB two;

       この時点で、上の図の「kill」をクリックして、以前に構成された高可用性をテストできます。StreamJobを強制終了した後、ページを更新すると、強制終了されたStreamJobが自動的に再起動します。

       テストのために、Kafkaで関連トピックの生産データを開きます。

       クエリ結果テーブルが利用可能です:

おすすめ

転載: blog.csdn.net/gdkyxy2013/article/details/109204045