はじめ
私たちは毎日のデータの何百万ものレコードを処理する多くのバッチジョブを実行すると私はそれぞれの周りに座っていると、毎日数時間何もしないですべてのマシンについて、最近考えてきた会社で働く。 我々はシステムの処理能力を強化するためにこれらのマシンを使用することができればそれが良いのではないでしょうか？ 記事のこのセットでは、私はオフィスの採用の潜在的な利点を見に行くよグリッド仮想化環境を使用する。
に第1部私は同様に、オフィスのグリッドを作成する理由の潜在的な理由のいくつかを説明したように私が使用するシステムの概要と技術を与えた。
ジョブコントロール
あなたがジョブを実行するつもりなら、あなたはそれらを管理するための何らかの方法が必要になるだろう。 あなたの仕事の制御システムは、（仕事上のサーバ上で）本当によくても事務所のグリッドを実行する前に考える必要があります。 そう、まず、ジョブ制御システム用のタスクは何か：
- 労働者からの要求に応じてジョブを配る
- ジョブの種類が実行する作業者に指示
- ジョブの追跡
- ジョブは一度だけ実行されていることを確認
- 労働者に仕事のデータを提供する、またはそれを取得する場所を、少なくともそれらを伝える
システムはまた、拡張可能な、企業がグリッドソリューションの価値を見つけるとジョブのいくつかのタイプを実行するために拡張できる単一の場合には今のところ有効な解決である必要があります。 たとえば、ジョブが優先順位を得ることが、複数のジョブタイプは最終的にあなたも、それが離れて"一般的な労働者から移動しませんが、ジョブの種類ごとに（用に最適化されているいくつかの異なるワーカーマシンを実行すること、（すなわちいくつかのコードベース）存在する場合があります"アイデア）。 常にシステムを開発する際に将来について考えてみて、短期的なビジョンは、長期的なフラストレーションと増加、開発期間につながることができます。
ジョブサーバ
我々から私達のジョブを制御するためにどこかに必要になるだろう、これは固定リソースロケータを持ってグリッド内の唯一のシステムでなければ、この原因はIPアドレス、ホスト名、URL（内部DNSを使用して）、等のことである労働者が仕事を検索する場所を知る必要がある、労働者は（ないジョブ制御システムは、労働者を見つける）ジョブ制御のシステムを見つける必要があります。
ジョブサーバー自体は本当に複雑なタスクを（基本的なシステムでとにかく）を持っていない、それはジョブアウト、ジョブのリストを格納するための手が必要、結果を受信し、その後、後で取得できるように保管しておきます。 どのようにこれらの部品（のような"手の仕事のうち"）が定義されていることは非常に基本的なことができます。 その後我々は、管理インターフェイスを含むようにシステムを拡張することができます、追加、編集、削除するには、ジョブを一時停止するが、これはこの練習を超えています。
全くしてから、ジョブサーバーは、メイン処理のサーバ内で実行中の仮想マシンであることができなかったということは、提供それからあまりにも多くのリソースを排出しない理由はありません。 それはあなたが処理の全体の週末を失うとしている金曜日の夜にダウンした場合、ジョブサーバーは、しかし、潜在的にあなたの処理時間、一週間のカップルを（単独であなたのメイン処理のサーバと比較した場合）、原価計算、高可用性を必要としている。 あなたは、高可用性を実現するために負荷分散環境でジョブサーバを置くことを検討する必要があります。
基本的なセットアップ
私たちの仕事のサーバの基本的なセットアップは私が私のLIMPサーバーのいずれかを（つまりは Li木の実、M ySql、P HPです）呼び出しているもので構成されます。 テアの労働者で実行されているコードは、実際にジョブ制御のシステムのデータベースと相互作用することにより、実行できるかジョブは正常に動作します。 後に我々は、むしろ労働者が大変な作業そのものを行うことよりも、ジョブからのWebサービスと実際に手を作成することもできますが、ここでは使い続けるだろうKISSの原則を （愚かな、それをシンプルに！）。
そう、三作成することができますmySQLのジョブに対応するテーブルを。 これらは、`ジョブ`、`jobRecords`、と`jobResults`になります。
ここに私が使用しているSQLバディのに偉大な小さな代替phpMyAdminを （他人のために参照してください：その簡単にCentOS上でインストールするという理由だけでphpMyAdminに10大の選択肢を ）
この表は、5つの簡単なフィールドで構成されています
- ID：ジョブを一意に識別
- 名前は：クライアントの参照、または他の識別子の任意の数の可能性がある
- ステータス：ジョブは、例えば、でどこにあるのかを知る必要がある
- started_by：誰が仕事を始めたのか？ この処理は、すべて必須ですが、あると便利ですされていません。 私は、ネットワーク上のIPアドレスで追跡労働者をお勧めしたい
- started_at：労働者がジョブを開始するのですか？ 我々は再び仕事をピックアップし、別の労働者によって処理を開始する必要がある知っている時のXの時間内に完了していないジョブを追跡することによって。 労働者は処理を停止/任意の数の理由により、電源障害、クラッシュ、ネットワークの損失、等のためにオフラインで行くことができる
それは、このテーブルを統計のトラッキング、仕事にかかった時間を確認するために終了時刻の列に、労働者が仕事を（明らかにこのニーズをする傾向にピックアップの数を確認するためにカウンタを可能にするためにいくつかの追加フィールドを拡張できる方法は簡単です1）、ジョブの優先順位は、リストが上に行くことができる。 より複雑なジョブのシナリオでは、労働者が（そのためだけに適して労働者を使用する）、あるいはどのような種類の労働者のことが必要とされるへのアクセスを必要とどれだけのメモリを指定することが可能になります。
いくつかのサンプルジョブを追加することができます。
次の表は、再びこれらが私たちの仕事のレコードである、理解することは非常に簡単です。 彼らは列`jobs_id`でメインジョブのテーブルにリンクされています。 非常にこのテーブルを構成することは、あなたの労働者に供給するために必要なデータに依存し、我々は4つの列を持っている非常に単純な例を行うことができます。
- ID：レコードのID
- 名前：人の名前
- 住所：人のアドレス
- jobs_id：このレコードがリンクされているジョブID
番目で最後のテーブルは、結果のテーブルで構成され、それは同じでは当社の記録表として構成する多く持っており、一部の列を追加することで、レコードのテーブルの一部である可能性があります：
- job_record_id：ジョブテーブルに結果をリンク
- 結果：結果データ
...そしてそれは、ジョブ制御のために必要なすべてです！ （非常に基本的なレベルではあるが）私の場合は、プロセスへの私のデータが置かれていた別のテーブルに指摘したんだけど、これは同じように簡単にファイルをされことが、シミュレーションコードを実行するためのパラメータは、あなたはそれに名前を付けます。
仕事の選択
前述したように、労働者が今の私たちのために我々の仕事の管理を行うので、我々が本当に必要なのは、処理を必要とする仕事を見つけると情報を得ることです。 どのようにこのようなことをするのでしょうか？ よく私たちの仕事の選択基準を選択し、SQLで私は次のことをやった、ジョブを探します。
- 完全としてではなく、私たちの労働者からマークし（識別子と__ME__を置き換える、最も簡単にはIPアドレスになる）にリセットされていないすべてのジョブを実行してください。
UPDATE`ジョブが`、SETは`status`= 0 WHERE`ステータス`= 1と`started_by`= __ME__;
- 私たちの仕事の選択基準を使用して、ジョブを選択し、この労働者はそれを扱っていることを制御システムに指示します。
UPDATE`ジョブが`は`status`= 1、`started_by`= __ME__、`started_at`= NOW（）WHERE`ステータス`= 0 ORをセット
（`ステータス`= 1 AND`started_at`> DATE_SUB（NOW（）、INTERVAL X HOUR））の`id`ASC ORDER BYを。
我々はすべてのジョブがAWOLをクラッシュさせたり、行く労働者のイベントで実行されるように時間のXの量で結果が返されていないジョブをつかんで。
- 次のレコード自体が続くジョブの詳細を取得できます。
`仕事`WHERE`started_by`= __ME__ LIMIT 1 * FROMを選択します。
;`job_records`の`id`= __JOBID__します。SELECT * FROM
ジョブの完了時に我々の結果レコードを挿入し、完全なようにジョブをマークします。 ジョブは、スクリプト内の一部の堅牢性を可能にする任意の時点で一時停止/再開ができるように覚えている。 それは、タスクがそのジョブ内のレコード数をチェックし、ジョブ制御のシステムを更新途中で中断し、ジョブ制御システムに戻って保存された結果の数は賢明な動きになることかもしれない。
さらに、これはジョブがあなたが本当にすべきSQL問合せのフレームから選択して管理できる方法を示すwhilst 抽象化は、Webサービスを使用するように切 り替えることにした場合ように、ジョブ制御を、ファイルベースのシステム、 XML 、またはその他のシステムの数は、それは上記のコードには影響しません。
ジョブの構成
次に考慮すべき側面は、ジョブのサイズと構成です。 ジョブの設定で再生することにより、我々はスピード、プロセスの複製、および信頼性の間で優れたバランスをとることができる。 カップルのOFAのシナリオを取る。
- ジョブを実行するには、それぞれ1日かかる：これは労働者が（時間の3分の2の電力の10％を覚えている）各ジョブを処理するために15日間必要があることを意味します。 これは明らかに賢明な設定ではない、あなたの仕事のサイズがあまりにも大きいです！ 初期の労働者がAWOLを（それが結果に加え、再処理の時間を返していないことをピックアップする時間）に行くはずそれが処理された仕事を得るために少なくとも2倍の時間がかかります。 理想的には、最初が欠けて行くべきプロセスに二日かかるとすると、ジョブを介して、最悪の場合で刻々と仕事を続けるそのように、 簡単にそれぞれの長いアイドル期間の終了でクリアされる少なくとも一つの完全な仕事があるんだけど。
- ジョブの実行に1分かかる：これは労働者がそれぞれのジョブを実行するために約15分かかることを意味します。 これは最初に理想的に見えるかもしれないが、あなたが昼食時に追加の作業の処理を得るため、コーヒーブレイク、ミーティング、など、このシナリオでは、システムの他の部分に負担がかかり、独自の問題を紹介します。 例えば、まず、セットアップ/処理時間の比率は、したがって、システムの効率性を失って、右下に行くつもりさ。 お使いのネットワークには、常に一日の仕事にその日のドンである様々な労働者イライラするスタッフへの求人情報をストリーミングされる予定です。 また、それは多くのと定期的に作業の小さな断片をたくさん皿に持っているとして、ジョブの処理サーバーでより多くの負担をかけるつもりだ。 あなたの仕事のサーバがダウンした場合最後に、このような状況では大きなジョブに対し、未完了の作業の膨大なバックログを作成するつもりです可能性の継続的な処理のジョブサーバーは、問題が発生したことを穏やかに気づいていない。
現実には多くの使用可能なリソース、ジョブの種類、ジョブのターンアラウンド時間の要件、ネットワーク機能などによって変化するため、グリッドの設定のための1つの理想的な設定は存在しません。 しかし、いくつかのガイドラインは次のようになります。
- サイズのジョブので、各労働者が15時間の期間に少なくとも3-4ジョブ（最長おそらくアイドル時間）を介して得ることができること
- そのセットアップの時間が処理時間（心に上記の点を有する）に比べてごくわずかになるように、ジョブのサイズで再生します。
- 仕事はあなたはそれが完了するまで期待時間の二重量（多分小さい）に完了しない場合、そのなくなっAWOLとは別の労働者とそれを処理を開始することを前提としています。 これは、（後続のジョブが失敗した場合おそらく長い）を完成させるためにそれのための仕事の三回、通常の長さに達するまで待つ必要がある場合がありますことを意味します。 この時間を短縮するが、あまりにも多く、定期的に処理タスクを複製し始める可能性があるので、それを削減しないように注意することができます。
- ジョブズCEOは、可能な限り外部の要件から独立している必要があります。 ジョブサーバーは、例えば、唯一のすべてのジョブの開始時と終了時に連絡する必要があります。
- あなたのネットワークを飽和させないでください、この二つ負の効果を持って、あなたの昼間のスタッフがイライラするネットワークを使用して、問題は、あなたのグリッドをスケールとしてだけ悪くなる問題をタイムアウトに接続で発生する可能性があるでしょう。
- 仕事があなたの労働者で実行できることを確認してください。 仕事があまりにもメモリになれば集中的にまたはディスクスペースを集中的ジョブが中止開始され、あなたが気づくだけではない本当の理由理由で処理されたジョブの数の減少です。
ジョブのサブミットの結果
ジョブの結果を提出するとき、それは現在の労働者がしばらくの間休止している場合は特に、結果は別の労働者が提出されていないことを確認することが重要です。
結果が送信されると、結果の数は、ジョブ内のレコード数と一致していることを確認してください。
先に述べたように、およびジョブの検索と結果の提出にフォールトトレランスを構築する、強調を超えることはできません。 労働者は（そしておそらく意志）回数の最も不便な時にサスペンドモードに入ることができますし、これがために仕出し料理する必要があります。 また、もう一度、結果の提出を抽象化することに対処する方がはるかに簡単にジョブの制御システムへの将来の変更の要求を満たすのに役立ちます。
まとめ
このsectionÂでは、ジョブ制御サーバが実行するとセットアップは非常に基本的なシステムを取得する方法必要なものを見てきました。 我々は、制御システムからのジョブとどのように最高の、最も私たちのオフィスのグリッドシステムのを得るためにジョブを設定するにはを取得する方法について説明しました。 終了するには、ジョブ制御の結果をサーバーに提出に関してはパラグラフまたは2つが発表された。
- ジョブ制御サーバは、すべての作業単位が完了したことをジョブと確実に管理
- 選択/結果を提出して仕事を抽象化することにより、我々は非常に問題がなく、制御サーバの技術を変更することができます。
- それらはあなたのネットワークインフラストラクチャに過剰な圧力をかけることなく迅速かつ効率的に実行されるようにジョブを設定し、定期的に処理タスクを複製することなく。
- あなたのルーチンにフォールトトレランスおよびエラーcheckingÂを構築することを保証する、労働者が一時停止と再開し、時代の最も不便なことができる。 結果は既に別の労働者が提出されているかどうかを確認することを忘れないでください。
次の時間
に第3部私たちは、仮想加工機を作成し、アイドルタイムの労働者になるために私たちのWindowsマシンをセットアップします。
コメント（4） 
記事 、 PHP 、 ウェブプログラミング 、 Zend Frameworkの | 
フレームワーク 、 iniファイル 、 PHP 、 ルータ 、 ルート 、 Zendの 、 Zend Frameworkは 、 Zend_Navigation 、 Zend_Router 
