分散クラスター管理システムの原理について

この記事は個人のパブリックアカウントから作成されました：TechFlow、オリジナルは簡単ではありません、注意を求めてください

今日は、分散トピックの12番目の記事です。引き続き、クラスターリソース管理システムについて見ていきましょう。

前回の記事では、分散クラスターリソース管理とは何か、その誕生の背景とそれが解決する問題、およびその利点と欠点について簡単に説明しました。前の章の内容は、表面的なものであり、あまり詳細な原則はありませんが、この記事では、クラスター管理システムの主要な部分を見てみましょう。

記事を忘れた場合、または最新のフォロワーである場合は、下のポータルをクリックして前の記事を確認できます。

分散クラスター資源管理システムの原理について

ローカル優先順位

ビッグデータアプリケーションのコンテキストでは、基本的な設計原則があります。通常、ノードから必要なデータを取得して計算を実行するのではなく、計算を実行用のデータを格納するノードに割り当てます。この理由は、ノード間のネットワーク通信を最小限に抑え、データ転送を減らすことができるため、簡単に理解できます。ビッグデータシナリオのデータのスケールは、TB、PB、場合によっては数百から数十GBと非常に大きいことを理解することが重要です。ネットワーク伝送データが必要になると、オーバーヘッドは非常に大きくなります。

「ローカル優先度」の原則と呼ぶことができるこの原則を要約します。つまり、タスクを実行するノードがローカルであるほど、物理マシンで完全すぎると、すべてのデータ転送を回避できるため、より良いです。

この原則に従って、クラスタースケジューリングシステムの容量を簡単に測定できます。また、局所性に応じて3つのレベルを簡単にリストできます。1つはノードの局所性です。つまり、すべての計算が1つのノードで行われるため、すべてのデータ送信を回避できます。これも最良のケースです。2番目の違いはラックの局所性と呼ばれます。つまり、すべての計算を1つのノードで実行できるわけではありませんが、少なくとも、実行中のマシンが同じラックにあることが保証されます。ラック内のマシンは、外部ネットワークに頼ることなく内部でデータを転送でき、そのような転送ははるかに高速です。最悪のケースは、ノードが異なるラックに分散していて、加速を行う方法がないことです。これはグローバルローカリティと呼ばれ、多くのオーバーヘッドをもたらします。

優れたクラスタースケジューリングシステムは、クラスター内のすべてのマシンのパフォーマンスを極端に「絞る」必要があることは誰もが知っていますが、実際、固定コンピューティングによって消費されるコンピューティングリソースは基本的に安定しています。機械の稼働率に加えて、もう一つのポイントはこれです。また、ネットワークIOによって発生するオーバーヘッドは、マシンの使用率が低い場合よりもひどい場合があります。

リソース割り当ての詳細

リソースの割り当てについては、私たちの直感的な理解は非常に単純な場合があります。マシンがアイドル状態の場合、それをタスクに割り当ててから実行します。リソースを回復しますが、実際のアプリケーションには、注意深い設計と思考を必要とする多くの詳細があります。少しの失敗は深刻な結果を引き起こすかもしれません。

2つの質問を見てみましょう。最初の質問は、新しいタスクがあるときにどうすればよいかということですが、十分なリソースがありません。

最初の戦略は何もしないことで、2つの戦略を考えるのは簡単です、ようにと。一部のタスクが終了し、リソースが解放されたら、現在のタスクを実行します。しかし、私たちの現在の使命が非常に緊急なものである場合はどうでしょうか？実行中のタスクの優先度が高くない可能性がありますが、占有されているリソースが長いため、永遠に待たなければなりませんか？

だから私たちは強奪されている第二者戦略を考えるでしょう。現在のリソースの優先度は高いため、実行しているタスクの優先度は低くなっています。最初に優先度の低いタスクからいくつかのリソースを取得し、次に重要なタスクを実行できます。優先度の低いタスクを実行する前に、優先度の高いタスクが実行されるのを待ちます。残念ながら、これには問題があります。最初に技術的な問題について話さないで、後で話します。あなたはそれについて考えたことがありますか？タスクの優先度を下げることを誰が望んでいますか？全員のタスクが最優先であることを確認してください。後で、いわゆる優先順位設定がすべて表示に変更され、実行中の優先順位がすべて同じで、すべてが最高の優先順位であることがわかります。

上記の質問について、フォローアップがありますが、脇に置いて別の質問を見てみましょう。この質問は、上記の質問の派生物です。異なるタスクには異なるリソースが必要であり、異なるリソースが必要です。たとえば、sparkやMapReduceなど、一部のタスクリソースは可能な限り多く実行できます。より多くのリソースが使用され、より多くのマシンが使用され、使用されるリソースが少なくなりますが、実行できるリソースがいくつあっても、実行時間は異なります。ただし、一部のタスクはこれとは異なります。たとえば、機械学習のタスクは一度に多くのリソースを必要とする場合があり、非常に多くのリソースを必要とします。次に、新しいタスクがあるとき、現在のリソースが割り当てのニーズを満たすのに十分ではない場合、最初に割り当てられないままにしておき、リソースが一度に割り当てられるのを待つか、少しだけ割り当ててから、少しだけリソースを割り当て続けますか？

ご存知のように、一見当たり障りのない配信戦略には、まだ多くのトリッキーな詳細があります。これは実際のケースであり、上記の問題に対する特に優れた解決策がないため、現在のクラスターリソース管理システムは成熟しておらず、まだ始まったばかりだと私が言ったのはこのためです。

飢餓とデッドロック

上記の2つの質問を忘れないでください。これらの2つの質問にうまく答えられない場合、飢餓とデッドロックが発生します。

スターベーションとは、たとえば、優先度セットが無理であるために、タスクを常にスケジュールすることができないことを意味します。正直な子供であるあなただけが、あなたがそれほど重要ではないと考えるタスクに通常の優先順位を設定しますが、他の古いドライバーはそのタスクに最高の優先順位を設定しています。優先度の高いタスクは常に送信されているため、タスクが遅延し、すぐに結果が得られると考えています。タスクは、仕事が終わるまで実行されない場合があります。この場合、合流してタスクを最高の優先順位に設定するか、永遠に待たなければならないか、十分な作業が行われていないためにパフォーマンスとボスからのプレッシャーに直面します。

そのため、これは単純なタスクスケジューリングの問題から内部価値のテストにまで至りました。これも、不良金が良品を追い出す典型的なプロセスです。少数の人々がルールを守っていないため、ルールを守った人は罰せられます男性と女性の本当の涙を想像してみてください[犬の頭]。

デッドロックの状況は比較的理解しやすく、オペレーティングシステムを習得した学生がそれに慣れていれば、原則は同じです。たとえば、現在2つのタスクABがある場合、両方のタスクを実行するにはクラスターリソースの2/3が必要です。これら2つのタスクはほぼ同時に送信されたため、システムは先着順の原則を採用し、1/2のリソースを両方のタスクに割り当てました。次に、これらの2つのタスクのどちらも実行できず、どちらのタスクもリソースを解放しないため、これによりデッドロックが発生します。したがって、1つが手動で強制終了されない限り、継続的に解放されます。

現在の状況から、これら2つの状況を完全に回避する完璧な方法はないようです。アーキテクトは、自分のクラスターコールの実際の状況に基づいてのみ決定を下すことができます。また、法律の3つの章に関するチームの仕様や規制を策定するなど、人間の介入要因を追加することもできます。つまり、これはシステムの問題だけではなく、システムとチーム間の調整に関する複雑な問題でもあります。

スケジューラー

一般的なスケジューラのアーキテクチャを見てみましょう。一般的なスケジューラは3つあります。1つは集中型スケジューラ、2つ目は2レベルのスケジューラ、最後は状態共有スケジューラです。

集中スケジューラ

最初に、最も直感的でシンプルな集中型スケジューラを見てみましょう。

その設計ロジックは一元化されており、システム全体でグローバルな中央ディスパッチャは1つしかありません。すべてのフレームワークまたはコンピューティングタスクは、中央のスケジューラによって実装されます。封建時代の氏族制度のようなもので、大家族全体の大小すべてを一人で管理しています。明らかに、これを行うことには多くの不利な点があります。前述の2つの問題は人間の介入を必要とし、それ以外の場合は解決が困難です。

その後、これに基づいて改善が行われ、中央のディスパッチャー全体にブランチロジックが追加されました。このスケジューラはマルチパススケジューラと呼ばれます。

全体として、変化はほとんどなく、条件付き判断がもう1つだけあります。つまり、タスクの種類ごとに異なるスケジューリングと割り当ての戦略が内部的に実装されています。たとえば、それが小さなデブリタスクである場合は、優先順位管理を実行し、先着順の戦略を実行します。大きな機械学習タスクの場合、デッドロックなどを防ぐために完全なリソースを取得した場合にのみ実行されます。

集中型のスケジューリングの観点から単一パスと比較すると、集中スケジューリングマルチパスは、ある程度の柔軟性が追加されますが、全体的な拡張性は十分ではありません、と同時容量が比較的貧弱で、リソースの使用率が大規模な場合には、十分に高いではない、とスケジューリングパフォーマンスは簡単にボトルネックになる可能性があります。ただし、構造はシンプルで、メンテナンスが簡単です。

2レベルのスケジューラ

集中型スケジューラには多くの問題があり、柔軟性に欠けるため、柔軟性を高めるために、これに基づいて構造の別の層を追加しました。

コマンドを受け取る中央スケジューラーもありますが、中央スケジューラーはタスクを直接スケジュールするのではなく、クラスター内のリソースを比較的粗い戦略でフレームワークスケジューラーに割り当てます。タスクのスケジューリングと実行のロジックは、フレームワークスケジューラにあります。中央スケジューラーと比較して、フレームワークスケジューラーによって実装された戦略はよりきめ細かくなります。

さらに、中央のスケジューラーだけがクラスター全体のすべてのリソースの状況を見ることができ、フレームワークのスケジューラーは、割り当てられているリソースの部分だけを見ることができます。YARNとMesosはこのアーキテクチャに精通しています。

フレームワークスケジューラを使用すると、さまざまなフレームワークスケジューラでさまざまな戦略を実行できます。クラスター全体の並行性機能とリソース使用率の向上に役立ちます。したがって、全体として、2ステージスケジューラのパフォーマンスは、集中型スケジューラよりもはるかに優れています。

しかし、これでも完璧ではありません。中央のスケジューラは、スケジューリング時に悲観的な同時方式を実行するためです。簡単な説明は、割り当てを実行するプロセスでは、中央スケジューラーは事前に確立された順序に厳密に従い、リソースをロックして、異なるフレームワークがリソースを適用することによって引き起こされる競合を防止します。悲観的ロックが使用されるため、明らかに全体的なパフォーマンスに影響します。

状態共有スケジューラ

状態共有スケジューラのアーキテクチャは2レベルのスケジューラに非常に近く、中央スケジューラを削除した結果として簡単に理解できます。

このアーキテクチャは、GoogleのOmegaスケジューリングシステムに最初に登場しました。これは現在、人気のあるKubernetesの前身です。それと2レベルのスケジューラの最大の違いは、中央にスケジューラがないため、すべてのフレームスケジューラがクラスタ全体のすべてのリソースを直接確認できることです。リソースが必要な場合、フレームワークスケジューラは互いに競合してリソースを取得します。

中央のスケジューラとは異なり、楽観的ロックは状態共有戦略で使用されます。楽観的ロックと悲観的ロックの違いを簡単に説明します。悲観的ロックは多くの場合最悪のケースを想定しています。たとえば、現時点でリソースを取得した後、使用が終了する前に他のスレッドがアクセスまたは変更する可能性があるため、このような状況を回避するためにロックを追加する必要があります。

オプティミスティックロックは、オプティミスティックな前提に基づいてその逆です。つまり、システムは、リソースのプリエンプションなしでスムーズに実行できるという前提に基づいています。つまり、最初に実行します。実行後にプリエンプションまたはその他の問題が発生した場合は、他のメカニズムを使用して再度解決してください。

同時実行性の高いシナリオでも、リソースの競合は比較的小さな確率の時間です。悲観的ロックを使用すると、明らかに多くのロックオーバーヘッドが発生するため、楽観的ロックに基づく設計は、システムの同時パフォーマンスをより強力にします。しかし、これには代償が伴い、楽観的ロックは完全ではありません。多数の競争の競合が実際に発生した場合、競争に失敗した当事者は、多くの場合、タスクを再試行する必要があります。これにより、多くの不要なオーバーヘッドが発生し、リソースも発生します。廃棄物。

さらに、すべてのフレームワーク間のプリエンプションは無料であるため、つまり、優先度の高いフレームワークがリソースを先取りし、優先度の低いタスクが枯渇してしまう可能性があります。このメカニズムでは、タスク間の公平性を確保する方法はありません。これは、中央のディスパッチャーを弱体化させることの避けられない結果でもあります。

まとめ

上記の3つの戦略を確認すると、これら3つの戦略の進化の順序は、実際には中央ディスパッチャーが弱められる順序であることがわかります。強力な中央スケジューラーがクラスター全体の公平性を維持できることは実際に理解するのは簡単ですが、その効率が低いため、クラスター全体のボトルネックになる可能性があります。中央スケジューラーが弱いほど、フレームスケジューラーの自由度が高くなり、システムスケジューリング全体の柔軟性が高くなります。つまり、システムのパフォーマンスが向上することがよくあります。

中央集権化されたスケジューラーは、計画された経済のようなものです。国家がすべて計画しており、公平性は確保できるが、自由度や自由度が低く、国全体の運営・開発が効率的でないというメリットがあります。2レベルのディスパッチャーは、大規模な政府と小規模な市場の混合モデルのようなもので、政府の介入は依然として非常に強力ですが、少し自由度があります。国家共有装置は、小さな政府と大きな市場の自由競争経済モデルであり、政府の介入はほとんどなくなり、目に見えない手になり、柔軟性と国の運用効率をさらに向上させることができます。しかし、州の介入は少なく、リスクが発生すると、大きな問題を引き起こす可能性もあります。