blog

Mesos設計アーキテクチャの再概念化

Mesosには、Mesosマスター、Mesosスレーブ、Protocal Bufferメッセージの4つの主要なタイプのサービスがあり、Protocal Bufferメッセージを通じて相互に通信します。...

Sep 9, 2014 · 4 min. read
シェア

Mesos には主に、Mesos Master、Mesos Slave、SchedulerProcess、ExecutorProcess の 4 種類のサービスがあり、Protocal Buffer メッセージを通じて相互に通信します。各サービスは、その内部に複数のProtocal Bufferメッセージプロセッサを登録しており、メッセージを受信すると、対応するメッセージプロセッサが呼び出されます。上記の4つのサービスに加えて、Mesosはまた、3種類の外部プログラム可能なコンポーネントを提供し、それぞれ、アロクタ、フレームワークスケジューラとフレームワークエグゼキュータ、これらのコンポーネントは、いくつかのインターフェイスの実装の要件に従わなければならないと書くと、これらのインターフェイスは、次の図の隣接するサービスによって呼び出されます。

ほとんどの人は、上記のMesosアーキテクチャを見て、フレームワークはMapReduce、Storm、Sparkなどの共通フレームワークでなければならず、Mesosマスターはフレームワークへのリソース割り当てを担当し、各フレームワークのスケジューラはさらにその内部アプリケーションにリソースを割り当てると考えます。この考え方は間違っており、Mesosアーキテクチャの誤った解釈です。

つまり、Frameworkは必ずしも "Framework "である必要はなく、また長時間稼働するサービスである必要もなく、ライフサイクルの短いJobやApplicationであってもよいのです。言い換えれば、Frameworkは必ずしも "Framework "である必要はなく、また長時間稼働するサービスである必要もなく、短いライフサイクルのJobやApplicationであることもできます。FrameworkがHadoop Jobに対応する場合、Framework SchedulerとFramework Executorはこのように設計することができます:

フレームワーク・スケジューラの機能

フレームワーク・スケジューラは、ジョブを入力データ量に応じて複数のタスクに分割し、これらのタスクのリソースを要求し、これらのタスクの実行状況を監視し、タスクが失敗したことが判明した場合は、タスクのリソースを再要求する役割を果たします。

フレームワーク・エクゼキュータの機能

各種jarパッケージやバイナリファイルの準備、必要な環境変数の設定、必要なリソースの分離、Reduceタスクのリモートデータコピーサービスを提供するJetty Shuffleの起動など、MapタスクやReduceタスクの実行環境をノード上に準備し、Framework Schedulerからのコマンドを受信します。を実行します。

上記の紹介からわかるように、Framework Scheduler は Hadoop ジョブを実行することだけを担当します。 YARN に精通していれば、これがまさに YARN の MapReduce ApplicationMaster が行っていることだとわかるでしょう。 その通り、Mesos と YARN の設計アーキテクチャは非常に似ているので、YARN の ApplicationMaster のどれかを改造して Mesos の Framework Scheduler として実行するのは簡単です。そうです、Mesos は YARN と非常に似ているので、YARN の ApplicationMaster のどれかを Mesos の Framework Scheduler として実行するように変更するのは簡単です。

最近Mesosは、クライアントがフレームワークスケジューラを実行しすぎるのを防ぐために、ユーザのフレームワークスケジューラを任意のMesosスレーブ上で実行できるようにするmesos-submitツールを提供し、Mesosのアーキテクチャとワークフロー全体がYARNに匹敵するようになりました。このようにして、Mesosのアーキテクチャとワークフロー全体がYARNと同等になりました。

MesosとYARNのアーキテクチャ上の共通点を理解しやすくするために、MesosとYARNのコンポーネントの対応表を以下に示します:

Mesosコンポーネント YARNコンポーネント 機能
Mesos Master Resource Manager クラスタ全体のリソース管理とスケジューリング
Mesos Slave Node Manager 各ノードのリソース管理、タスクの開始など
Framework Executor

MesosとYARNは似ているので、どちらを使うべきでしょうか?あるいは、どちらのシステムがより有望なのでしょうか?

現在のところ、YARNは以下の点で明らかに優位性があると思われます。YARNはHadoop 1.0から発展し、Hadoopの可視性を継承しており、パッチを共有する企業や開発者が多数存在します。しかし、Mesos***の利点は、シンプルな設計、使いやすい、それはYARNのように、リソースの割り当てプロセスは、いくつかのステートマシンを含むものではなく、各状態機械は、十数種類の状態、および十数種類のイベントを含んでいます。と1つのステートマシンにつき十数個の状態と十数個のイベント。しかし、安定性という点では、どちらのシステムも研究開発とテストの段階にあり、安定して使用できるようになるまでにはまだ長い道のりがあります。

Read next

Linux Deepin 郭攀インタビュー:アイコンの物語

バージョン12.06以降、Linux Deepinは他のLinuxディストリビューションよりも魅力的であるために、独自のテーマを作成しています。Linux DeepinのテーマであるDeepinテーマも丸1年かけてリリースされました。今日は、Linux Deepinのデザインチームの主要メンバーであるGuo Panさんにインタビューし、Deepinテーマの開発ヒストリーを聞いてもらいましょう!

Sep 8, 2014 · 5 min read