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 モード) を待ち、それが発生した場合は処理を続行します。