25

この質問を読んだ後、追加の質問をしたいと思います。

  1. Cluster Manager は長時間実行されるサービスですが、どのノードで実行されていますか?
  2. マスター ノードとドライバー ノードが同じマシンになる可能性はありますか? これらの 2 つのノードは異なるべきであるという規則がどこかにあるはずだと思いますか?
  3. ドライバー ノードに障害が発生した場合、アプリケーションの再起動は誰が担当しますか? そして、正確には何が起こるでしょうか?つまり、マスター ノード、クラスター マネージャー、およびワーカー ノードが関与する方法 (関与する場合) とその順序は?
  4. 前の質問と同様に、マスター ノードに障害が発生した場合、正確には何が起こり、誰が障害から回復する責任がありますか?
4

2 に答える 2

30

1. Cluster Manager は長時間実行されるサービスですが、どのノードで実行されていますか?

Cluster Manager は、Spark スタンドアロン モードのマスター プロセスです。実行することでどこでも開始できます./sbin/start-master.sh.YARNではResource Managerになります.

2. マスター ノードとドライバー ノードが同じマシンになる可能性はありますか? これらの 2 つのノードは異なるべきであるという規則がどこかにあるはずだと思いますか?

MasterクラスタDriverごと、アプリケーションごとです。スタンドアロン/yarn クラスターの場合、Spark は現在 2 つのデプロイ モードをサポートしています。

  1. クライアント モードでは、ドライバーはアプリケーションを送信するクライアントと同じプロセスで起動されます
  2. ただし、クラスターモードでは、スタンドアロンの場合、ドライバーはワーカーの1つから起動され、糸の場合、アプリケーションマスターノード内で起動され、クライアントプロセスはアプリを待たずにアプリケーションを送信するという責任を果たすとすぐに終了します終わる。

アプリケーションがマスター ノードで送信された場合、マスターとドライバー--deploy-mode clientの両方が同じノードになります。YARN を介した Spark アプリケーションのデプロイを確認する

3. ドライバー ノードに障害が発生した場合、アプリケーションの再起動は誰が担当しますか? そして、正確には何が起こりますか?つまり、マスター ノード、クラスター マネージャー、およびワーカー ノードが関与する方法 (関与する場合) とその順序は?

ドライバーが失敗した場合、サブミット/トリガーされた Spark アプリケーションのすべてのエグゼキューター タスクが強制終了されます。

4. マスター ノードに障害が発生した場合、正確には何が起こり、誰が障害から回復する責任がありますか?

マスター ノードの障害は、2 つの方法で処理されます。

  1. ZooKeeper を使用したスタンバイ マスター:

    ZooKeeper を利用してリーダーの選出といくつかの状態ストレージを提供することで、同じ ZooKeeper インスタンスに接続されたクラスターで複数のマスターを起動できます。1 人が「リーダー」に選ばれ、残りはスタンバイ モードのままになります。現在のリーダーが死亡した場合、別のマスターが選出され、古いマスターの状態を回復してからスケジューリングを再開します。復旧プロセス全体 (最初のリーダーがダウンした時点から) には 1 ~ 2 分かかります。この遅延は、新しいアプリケーションのスケジューリングにのみ影響することに注意してください。マスターのフェイルオーバー中にすでに実行されていたアプリケーションは影響を受けません。構成についてはこちらを確認してください

  2. ローカル ファイル システムを使用した単一ノードのリカバリ:

    ZooKeeper は本番レベルの高可用性を実現するための最良の方法ですが、マスターがダウンした場合にマスターを再起動できるようにしたい場合は、FILESYSTEM モードで対応できます。アプリケーションとワーカーが登録されると、指定されたディレクトリに十分な状態が書き込まれるため、マスター プロセスの再起動時に回復できます。conf と詳細については、こちらを確認してください

于 2016-11-12T06:06:46.147 に答える
6

Cluster Manager は長時間実行されるサービスですが、どのノードで実行されていますか?

クラスター マネージャーは、SchedulerBackends がタスクを起動するために使用するリソース (つまり、CPU と RAM) の単なるマネージャーです。クラスター マネージャーは Apache Spark に対して何もしませんが、リソースを提供し、Spark エグゼキューターが起動すると、ドライバーと直接通信してタスクを実行します。

次のコマンドを実行して、スタンドアロンのマスターサーバーを起動できます。

./sbin/start-master.sh

どこでも始められます。

Spark クラスターでアプリケーションを実行するには

./bin/spark-shell --master spark://IP:PORT

マスター ノードとドライバー ノードが同じマシンになる可能性はありますか? これらの 2 つのノードは異なるべきであるという規則がどこかにあるはずだと思いますか?

スタンドアロン モードでは、マシンを起動すると、特定の JVM が起動します。SparK マスターが起動し、各マシンでワーカー JVM が起動し、Spark マスターに登録されます。どちらもリソース マネージャーです。アプリケーションを起動するか、クラスター モードでアプリケーションを送信すると、そのアプリケーションを起動するために ssh を実行すると、ドライバーが起動します。ドライバー JVM は Executor (Ex) の SparK マスターに接続し、スタンドアロン モードでは Worker が Ex を開始します。したがって、Spark マスターはクラスター単位であり、ドライバー JVM はアプリケーション単位です。

ドライバー ノードに障害が発生した場合、アプリケーションの再起動は誰が担当しますか? そして、正確には何が起こるでしょうか?つまり、マスター ノード、クラスター マネージャー、およびワーカー ノードが関与する方法 (関与する場合) とその順序は?

Ex JVM がクラッシュすると、Worker JVM が Ex を開始し、Worker JVM がクラッシュすると Spark Master がそれらを開始します。また、クラスター デプロイ モードの Spark スタンドアロン クラスターでは、 --supervise を指定して、ゼロ以外の終了コードで失敗した場合にドライバーが自動的に再起動されるようにすることもできます。Spark マスターはドライバー JVM を開始します

前の質問と同様に、マスター ノードに障害が発生した場合、正確には何が起こり、誰が障害から回復する責任がありますか?

マスターで障害が発生すると、エグゼキュータはマスターと通信できなくなります。だから、彼らは仕事をやめます。マスターに障害が発生すると、ドライバーはジョブ ステータスについてマスターと通信できなくなります。したがって、アプリケーションは失敗します。マスターの損失は実行中のアプリケーションによって認識されますが、それ以外の場合は、2 つの重要な例外を除いて、何も起こらなかったように多かれ少なかれ機能し続けるはずです。

1.アプリケーションはエレガントな方法で終了できません。

2.Spark マスターがダウンしている場合、ワーカーはマスターに再登録しようとします。これが何度も失敗すると、ワーカーは単にあきらめます。

reregisterWithMaster() -- このワーカーが通信していたアクティブなマスターに再登録します。何もない場合は、このワーカーがまだブートストラップ中であり、マスターとの接続がまだ確立されていないことを意味します。この場合、すべてのマスターに再登録する必要があります。失敗時にアクティブなマスターのみに再登録することが重要です。worker は無条件にすべてのマスターに再登録しようとしますが、競合状態が発生する可能性があります。SPARK-4592 に詳述されているエラー:

現時点では、長時間実行されているアプリケーションは処理を続行できませんが、すぐに障害が発生することはありません。代わりに、アプリケーションはマスターがオンラインに戻るか (ファイル システムの回復)、新しいリーダーからの連絡 (Zookeeper モード) を待ち、それが発生した場合は処理を続行します。

于 2016-11-15T10:25:31.253 に答える