はじめ
私たちは毎日のデータの何百万ものレコードを処理する多くのバッチジョブを実行すると私はそれぞれの周りに座って、毎日数時間何もしないですべてのマシンについて、最近考えてきた会社で働く。 我々はシステムの処理能力を強化するためにこれらのマシンを使用することができればそれが良いのではないでしょうか？ 記事のこのセットでは、私はオフィスの採用の潜在的な利点を見に行くよグリッド仮想化環境を使用する。
でパート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と`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倍の時間がかかります。 理想では、最初が欠落して行く必要がプロセスに2日かかるとすると、ジョブを介して、最悪ケースでの刻々と仕事を続けるそのように、 簡単にそれぞれの長いアイドル期間の終了によってクリア少なくとも一つの完全な仕事があるんだけど。
- ジョブの実行に1分かかる：これは労働者がそれぞれのジョブを実行するために約15分かかることを意味します。 これは最初に理想的に見えるかもしれないが、あなたが昼食時に追加の作業の処理を得るため、コーヒーブレイク、ミーティング、など、このシナリオでは、システムの他の部分に負担がかかり、独自の問題を紹介します。 例えば、まず、セットアップ/処理時間の比率は、したがって、システムの効率性を失って、右下に行くつもりさ。 お使いのネットワークには、常に一日の仕事に一日洞である様々な労働者の不満スタッフへの求人情報をストリーミングされる予定です。 また、それは多くのと定期的に仕事の小片をたくさん皿に持っているとして、あなたの仕事の処理サーバーでより多くの負担をかけるつもりだ。 あなたの仕事のサーバがダウンした場合最後に、このような状況であなたはより大きなジョブに対し、未完了の作業の膨大なバックログを作成するつもりです可能性の継続的な処理のジョブサーバーが問題が発生したことを穏やかに気づいていない。
現実には多くの使用可能なリソース、ジョブの種類、ジョブのターンアラウンドタイムの要件、ネットワーク機能などによって変化するため、グリッドの設定のための1つの理想的な設定は存在しません。 しかし、いくつかのガイドラインは次のようになります。
- サイズジョブので、各労働者が15時間の期間に少なくとも3-4ジョブ（最長可能性がアイドル時間の期間）を介して得ることができること
- そのセットアップの時間が処理時間（心に上記の点を有する）に比べてごくわずかになるように、ジョブのサイズで再生します。
- ジョブがあなたはそれが完了する予定時間の2倍（多分少ない）に完了しない場合、そのなくなってAWOLとは別の労働者とそれを処理を開始することを前提としています。 これは、（おそらく長く、後続のジョブが失敗した場合に）三回にそれが完了するまで、ジョブの正常な長さを待たなければならないかもしれないことを意味します。 この時間を短縮するが、あまりにも多く、定期的に処理タスクを複製し始める可能性があるので、それを削減しないように注意することができます。
- ジョブズCEOは、可能な限り外部の要件から独立している必要があります。 ジョブサーバーは、例えば、唯一のすべてのジョブの開始時と終了時に連絡する必要があります。
- あなたのネットワークを飽和させないでください、この二つ負の効果を持って、あなたの昼間のスタッフはイライラするネットワークを使用して、問題は、あなたのグリッドをスケールとしてだけ悪くなる問題がタイムアウトに接続で発生する可能性があるでしょう。
- 確実に仕事もあなたの作業者で実行することができます。 仕事があまりにもなっている場合、メモリを集中的またはディスクスペースを集中的ジョブが中止開始され、あなたが気づくだけではない本当の理由理由で処理されたジョブの数の減少です。
ジョブのサブミットの結果
ジョブの結果を提出するとき、それは現在の労働者がしばらくの間休止している場合は特に、結果は別の労働者が提出されていないことを確認することが重要です。
結果が送信されると、結果の数は、ジョブ内のレコード数と一致していることを確認してください。
先に述べたように、およびジョブの検索と結果の提出にフォールトトレランスを構築し、強調を超えることはできません。 労働者は（そしておそらく意志）回数の最も不便な時にサスペンドモードに入ることができますし、これがために仕出し料理する必要があります。 また、もう一度、結果の提出を抽象化することに対処する方がはるかに簡単にジョブ制御システムへの将来の変化に応えるのに役立ちます。
まとめ
このsectionÂでは、ジョブ制御サーバが実行するとセットアップは非常に基本的なシステムを取得する方法必要なものを見てきました。 我々は、制御システムからジョブを最適な方法をほとんどの私たちのオフィスのグリッドシステムのを得るためにジョブを設定するにはを取得する方法について説明しました。 終了するには、ジョブ制御の結果をサーバーに提出する上で段落または2つが発表された。
- ジョブ制御サーバは、すべての作業単位が完了したことを仕事と確実に管理
- 選択/結果を提出して仕事を抽象化することにより、我々は非常に問題がなく、制御サーバの技術を変更することができます。
- それらは、ネットワークインフラストラクチャに過剰な圧力をかけることなく迅速かつ効率的に実行されるようにジョブを設定し、定期的に処理タスクを複製することなく。
- あなたのルーチンにフォールトトレランスおよびエラーcheckingÂを構築することを確認してください、労働者が一時停止と再開と時間の最も不便なことができる。 結果は既に別の労働者が提出されているかどうかを確認することを忘れないでください。
次の時間
に第3部私たちは、仮想加工機を作成し、アイドルタイム労働者になるために私たちのWindowsマシンをセットアップします。
コメント（2） 
データソースへのジョブ制御サーバのアップデートをスレーブとして労働者のそれぞれを設定することによって、ネットワーク活動の大幅な増加（あなたが巨大なデータの更新を実行し、すべての労働者がでキックしない限り、つまりすることなく、労働者にきちんとトリクルダウンになります一度に）。 これはその内のrsyncの利点を持っていることは、各ジョブの前に長い休止を取得しませんが、データベースの更新として、 mysqlの処理を続行しながら、労働者のデーモンは、継続的にデータを更新します。 
記事 、 コンピューティング 、 グリッドコンピューティング 、 Linuxでは 、 PHP 、 Webプログラミング | 
の更新 
