編集者のメモ
Mesosと糸は、多くの人々と2つのシナリオ間の差の分析の使用があり、非常に良好なリソーススケジューリングフレームワーク、コミュニティーです。InfoQの前にも、の二つの質問に話を聞いた関係。業界は、より多くのMesosを使用している、この記事では、著者が糸の代わりにMesosを使用することを選択した理由を説明するためのものであり、糸に基づく分散アプリケーションを開発する方法について説明します。この記事では、最初に見えたウィリアムさんのブログたい InfoQではにより公表され、承認さ復刻。
序文
実際にはMesosは、私は非常に精通していないですので、一部のコンテンツは、個人的な好みで、バイアスされてもよいです。我々はまだ特定する能力を持っている必要があります。
糸Mesosと素晴らしいですが、プログラム可能なフレームです。ハードウェアではなく、プログラミングは、死んでいる、かつて住んでプログラムすることができ、あなたは、限りプログラム可能な、基本的な意志が生きるためのように、すべての種類、奇抜の様々な同じことを達成することができます簡単にソフトウェアを投げることができます生態の形成。
糸VS Mesos
私は第一の容器スケジューリングエンジンを行うことについて語るとき、なぜ代わりにMesosの糸を選択してください。
展開性
ここ探求まずノートでは、アプリケーションを含まない糸またはMesosクラスターの展開、です。JDK糸依存性、我慢し、実質的に実行することができ、オペレーティングシステムに依存することなく、に加えて。Mesosは、C / C ++開発するので、インストールの配備は、ライブラリの依存関係を有することができます。私たちは体重を見ているかどうかわかりませんこれは、とにかく、私は非常に重いご覧ください。ソフトウェアは、ファイル名を指定して実行を下に低くすべきです。私自身は、ライン上の主な方法の開発が完了した後に実行するJavaサービスフレームワークを開発しましたので、12年。アプリケーションは、コンテナを含めるのではなく、あまりにも複雑で、直感的ではないこれらのコンテナの中に投げTomcatアプリケーションを作ってみましょう。
二次開発
Java / Scalaのエンジニア、ちょうどジャーパッケージ、同様の指標開発パッケージのLucene用の糸、あなたが望む任意のパッケージを行い、プロジェクトを紹介するためにそれを置くことができます。これは、1つです。
第二に、糸は、拡張インタフェースの多くを提供し、多くの実装がプラグイン可能です。また、XML構成で、それは簡単に、元の実装を離れてあなたの実装にあまり侵襲的ではない、それを置き換えることができ、そうであっても、将来の糸のアップグレードがあれば、大きな問題はなくなります。
比較して、より多くの既製品のようなMesosは、直接配備することができますが、二次開発のための友好的ではありません。
生態の利点
糸のHadoopは、「イニシエータ」ビッグデータプロジェクトで生まれた、それはビッグデータの分野における固有の利点を持っています。
分散ストレージシステムは、安定的かつ効率的な基盤となる自然HDFS、です。
大きなデータフィールドスパークを運ぶ支持シートの上に、MRらは、試して試験しました。
強力なコミュニティは、最近リリースされたバージョンが長いタスクをサポートするために、大幅に高速化もあることは、ますます優れたとなっています。
ロングミッションのサポート
長いタスク（実行時間の長いサービス）をサポートするために目を向けると、それは以前にオフライン糸の短いタスクをサポートするために考えられていた、それは長い任務を限定的にサポートを有することができます。実際には、例えば、今ストリーミングは、実行中のアップ実行中の24時間365日時間であり、また、問題を欠いスパークに基づいており、心配する必要はありません。一般的には、長いタスクをサポートするために、以下のいくつかの点を考慮してください。
寛容、主にAMのフォールトトレランスフォールト。
糸のセキュリティは、セキュリティメカニズムをオンにした場合など、トークンの有効期限は、注意を必要とされています。
クラスタにコレクションを記録します。
リソースの分離と優先順位があります。行うには、リソースの隔離があまりにも悪い場合は、タスクがインパクト長い時間を持つことになります。
我々はを参照することができます興味を持っているのJira。私はこのJiraの13年は、この問題は長い再び真剣に受け止めていることを示す、始まったと思います。ここでは、次の説明を行うために、私たちのチームで述べたいくつかのポイントがあります。
フォールトトレランス
彼らの可用性を糸。現在、マスターの糸は、HAを実現しています。
AMのフォールトトレランス、私はサポートされています（ソースコードを参照してください、またはそれ以前のバージョンでサポートされている場合があります）2.4バージョンからの試行オプション渡ってコンテナを保持します。それは何を意味するのでしょうか？AMは糸AMを再起動プロセス中にハングアップされている場合は、すべてのコンテナが殺されることなく、AMの管理によって維持されます。毛糸ない限り、いくつかの試みが（2回デフォルト）、それを再起動する方法をAMません。これは、ビューのスケジューリングポイントの底から、非常によくやっていることを示しています。
クラスタにコレクションをログ
バージョン2.6でのログ収集はすでに収集側縁を実行しています。
リソースの分離
リソースの分離は、その後、糸は、現在、力のメモリではありません、他の態様は、常にサポートしたいと思っているが、限定されていました。また、多くの人々がMesos最後の理由を選択していると推定されます。リソースの分離にドッカーコンテナは十分に行っているので、しかし、今、この利点Mesosはすでに、なくなっています。糸とドッカー統合、補完。
概要
Mesosと糸は、それぞれが長所と短所があり、柔軟なスケジューリング非常に良いスケジューリングフレームワークです、統一されたリソース管理プラットフォームは、このリソーススケジューリングフレームワークの管理に似て、将来の傾向は、確かに人気が出るだろうです。
いくつかの一般的な誤解
Hadoopの外に生まれ、彼のオーラとエコロジーを継承し、それはまた、Hadoopのオーラにある最初はカバーされていたいくつかの混乱をもたらすでしょう、と当たり前のための固有の慣性のため、我々はかかりますHadoopの中だけで糸います糸の構成要素は、誰かが一人でそれを考え出すだろうと思いましたか？
私はカリキュラムの前に持っているようしかし、彼が繰り返し強調してきた、Hadoopが分散ストレージ、リソース管理、スケジューリング、フレームの三つの部分の計算が含まれているソフトウェアのコレクションです。それらの間に必要な関係はありませんが、独立したに開いています。糸は、リソース管理とスケジューリングエンジンで、1つの設計目標は、単にMRを実行していない、一般的な始めることです。今ベースのサービスは、スパークの典型的な、糸の上に非常に多くなっています。
別の誤解があり、MRは現在オフラインバッチは基本的に間違って糸がオフラインバッチスケジューリングタスクのためにのみ適しているこの時間と同義です。実際には、私は上記の分析に与えている、糸は、信頼性の高い動作の安定した長いタスクを確実にするために完全に可能です。
糸に基づいた分散アプリケーションを開発する方法
この記事では、どのようにAPIの具体的な糸を使用する方法を教えていますが、あなたはAPIの糸を知っているだけでなく、公式文書があまりにも簡単であることを感じるようにしたい場合は、ここで私は2つの提案を与えられるだろう。
例としては、コードの使用中に見出すことができる糸関連するコードをスパーク。上でカウントアダプタの非常に合理化された糸です。
糸関連の本を購入、そのアーキテクチャを理解するためにも、あなたがそのAPIを理解するのに役立つように設計されています。
以下の内容は、次の2つのトピックを検討します。
分散アプリケーションの糸ベースの開発は、いくつかの準備作業を行う必要があります
コンテナのディスパッチシステムを開発するためのいくつかの基本的な考え方に基づいて糸
分散アプリケーションの糸ベースの開発は、いくつかの準備作業を行う必要があります
確かにその袖をロールアップし、乾燥し始めたことができません。手を開始する前に、私たちはどのような事を知っておく必要がありますか？
あまりにも複雑すぎる基盤となるAPIの糸ネイティブ、
あなたは糸アプリケーションの開発に滞在したい場合は、糸は一度APIパッケージが必要です。糸は柔軟性のために、またはほとんどの開発者のニーズを満たすことができるように、APIの基本的な相互作用は、よりオリジナルになります。当然のことながら大きな開発努力を引き起こしました。これは、私が思う人、今はApacheツイルないが、彼らはその層Huluのアダプタを開発するとき、彼らはこの問題を解決するために実際にあります。私はそれを使用しなかった理由ツイル、最初の文書が少なすぎであり、第二は、もう少し複雑ですが、私はこのような複雑なことをする必要はありません。私はとても万能その開発ツイル、本当に良いだけでなく、ドキュメントについて書く、と思います。
最高のは問題Frameworkのクラスにソリューションを開発することです
糸はただ低レベルのリソース管理およびスケジューリングエンジンです。あなたは、一般的に特定の問題を解決するためのフレームワークの開発に基づいてする必要があります。例をスパークするために、彼は、分散コンピューティングに関連したいくつかの問題を解決することです。私が開発したスケジューラと、コンテナは、実際には、動的なWebアプリケーションの展開を対処することです。その上、それはあなたのアプリケーションです。たとえば、あなたは限り、あなたはスパークのアプリケーションを開発するとして、統計情報を記録する必要があります。たとえば、あなたが下部容器包装容器が展開スケジューラをスケジュールすることができます使用している限り、推薦システムを提供したいです。
だから、一般的な、糸に基づく分散アプリケーションは、このようなレベルと一致している必要があります。
糸 - >アダプタ - >フレームワーク - >アプリケーション
アダプターは、私が最初にAPIの糸のあなた自身のパッケージ、それを言ったことです。フレームワークのプログラミングフレームワークは、問題のクラスを解決することで、アプリケーションは、あなたが本当にシステム事業を解決したいものです。このデカップリングを介して、すべてのレベルで、その中核機能の点に焦点をすることができる限り。
あなたの上部のフレームワーク/アプリケーションを転送することができることを確認します
スパークは典型的である、彼はMesos上で実行することができます、また糸上で実行することができ、また、糸に浸かり、リアルタイム、（スタンドアロン）自体上で実行、およびスタンドアロンモードを実行し、の多くを持つことができます。おかげでスパーク自体が根本的な資源管理スケジューリングエンジンに依存しません。
実は、これはアダプタは、上側のフレームワークは、リソーススケジューリングエンジンにタイアップすることはできませんので、私は、2つの利点の上に述べたものです。フレームワークは、限り、あなたはビジネスに集中できるよう、基本的なスケジューリング問題に注意を払うことなくApplicaitonを作ることができます。
また、あなたの痛みの開発フレームワークは、あなたが自然にそれがより多くのプラットフォーム上で実行されることを願って、右、より多くの人々のニーズを満たしています。
コンテナのディスパッチシステムを開発するためのいくつかの基本的な考え方に基づいて糸
まず、我々は二つの概念を理解する必要があります。
ダムアプリケーション。いわゆるダムアプリケーションが直接対話することができず、分散システムは、分散システムは、閉じた又は開いているアプリケーションとして、唯一の容器のライフサイクルを制御することができる指します。典型的な例MySQLの、Nginxはので、これらのアプリケーションに基づいて。彼らは一般的に、このようなコマンドラインまたはソケットプロトコル、またはHTTPプロトコルとして、対話する独自の方法を持っています。
関連するコンポーネント。ダムのアプリケーション、分散システム、およびこれらのアプリケーションとやり取りできるようにするがあったので、あなたは薬を持っている必要があります。そして、このエージェントとエージェントのダムアプリケーションは、同じライフサイクルを持っています。サービスは、分散システムは、関連nginxのアセンブリにイベントを送り、イベントが分散システムの通知される、シャットダウンされた後の典型的な例は、nginxの命令に関連する構成要素は、サービスが停止され、認識することができますnginxののProxyBackendリストは除外します。
コンテナのディスパッチシステムでは、ノードマネージャの糸が直接管理する場合ドッカー糸自体をサポートするために実行する必要があります、私は、これは間違っていると思います。糸の義務は、リソース管理は、割り当て、スケジューリングが可能行うことで、全ての糸がユニバーサルリソーススケジューリングの管理フレームワークである後に、特定のカップリング技術を必要としません。
それは上記の理論に基づいて、我々は、（糸の決定である）典型的なマスタースレーブ構造になるフレームワークを開発し、糸をベース。このフレームワークの奴隷は、実際にドッカーのコンパニオンオブジェクトです。マスターは、これらの容器スレーブの投与によって間接的に達成することができます。
私たちは簡単に下にそのプロセスを説明します。
ユーザーは、アプリケーション、アプリケーションのリソースを提出します。
糸は、マスターフレームワークを開始します。
スレーブフレームワークの糸開始。
マスター・スレーブ接続、およびスレーブマスタがスレーブサーバを知っているように、ハートビートを送信するには、ドッカー条件、有効ワンドッキングウィンドウコンテナとスレーブを開始します。
コンテナスレーブ定期的なモニタリング。
スレーブは糸がリソースを回復通知し、スレーブ自動的に終了し、コンテナのクラッシュを発見しました。
見つかったマスターノードは、ステップ2が最初から繰り返され、ノードが別のサーバー上のスレーブを再起動するための新しい要求を発行し、失敗しました。
スレーブは通常ちなみに、殺すの場合も、コンテナJVM ShudownHookでオフにすることができるという問題もあります。スレーブが異常なクラッシュであるか、殺す-9失われた場合でも、それはリソースリークにつながる可能性があります。この情報は現在、定期的に清掃され、クラスタ管理プラットフォームにマスターによって報告されました。また、MySQLのような、この情報を保存するかのRedisを入れ、その後、タスクが可能バックグラウンドでのクリーンアップを開始することができます。
この考え方を知ることは、特定の実装が簡素化され、糸をベースとし、対応するスレーブが新しい命令の受け入れなど、ドッカーコンテナを、管理することができ、マスタ・スレーブプログラムを開発することです。マスター・コンテナは、管理インターフェイス表示情報を提供し、動作状態とすることができます。
もちろん、あなたは上記のシステムは、このようなノードの変更を行うなど、専門的かつnginxの相互作用をフレームワークBを開発することができ、バックエンドを有効にする、更新を完了しnginxのをその関連コンポーネントのスレーブを介してマスタB、およびマスタBに通知自動変更通知サービス。
現在では、これは完璧な考え方は、それのアプリケーション間の相互作用をカバーしていないように見えますか？