簡介
本人在一家公司工作，我們批作業處理運行多個記錄的數據以百萬計的每一天，我最近一直在思考的所有的機器圍坐的每一天什麼都不做了幾個小時。 那豈不是好，如果我們可以利用這些機器的處理能力來支持我們的系統？ 在這組文章中，我要去看看的潛在好處僱用辦公室電網使用虛擬化環境。
在第一部分我給了系統的概述和技術我會用，以及討論了一些潛在的原因，你想創建一個Office網格。
作業控制
如果你要運行的工作，然後你會需要一些方法來管理它們。 你的任務控制系統（在你的作業服務器）需要，真正做到深思熟慮之前，甚至試圖運行一個辦公室的網格。 所以，首先，什麼是任務控制系統的工作：
- 伸手從工人的工作提出要求
- 告訴工人什麼類型的工作運行
- 跟踪工作
- 確保作業只運行一次
- 為工人提供就業數據，或者至少告訴他們在哪裡得到它
該系統還需要具有可擴展性，一個解決方案，工程正處在一個單一的情況下可以延長至運行多種類型的就業機會的企業認為值得在網格的解決方案。 例如，可能會獲得優先就業，多個工種可能存在（即幾個代碼基地），最終你甚至可能會出現幾個不同的工作機器，優化了每個類型的工作（雖然從沒有搬走的共通工人'的想法）。 總是試圖在思考未來發展的系統中，短期目標會導致長期的沮喪和更多的發展時間。
作業服務器
我們將需要一個地方來控制我們的工作從，這應該是唯一的系統在你的網格，它有一個固定資源定位器，是一個 IP地址，主機名稱，URL（使用內部 DNS）等，這是因為工人需要知道在哪裡找工作，工人們需要找到作業控制系統（未找到工作的工人控制系統）。
作業服務器本身並沒有真正有一個複雜的任務（在基本制度無論如何），它需要存儲一個列表的工作，手出的工作，接收結果，隨後它們存儲供日後檢索。 如何將這些部件（如'失控喬布斯）的定義可以是很基本的。 後來我們可以擴展系統，包括一個管理界面來添加，編輯，刪除，暫停工作，但是這已經超出這個練習。
沒有任何理由，然後，你的工作服務器不能是一個虛擬機運行在主服務器進行處理提供它不會消耗太多的資源了。 但是這項工作確實需要服務器的高可用性，如果它出現故障的星期五晚上你將失去整個週末的處理，你可能花費幾個星期的處理時間價值（相比，您的主服務器進行處理單） 。 您可能要考慮將你的工作服務器負載平衡環境中的高可用性。
基本設置
基本設置服務器為我們的工作將包括一個什麼我打電話，我癱軟服務器 （即李馬錢， 米ySql，磷馬力）。 該代碼將運行在西婭工人實際工作了什麼工作，它可以運行與工作的互動與控制系統數據庫。 後來，我們可以創建一個Web服務和工作實際不可收拾，而不是讓工人自己做艱苦的工作，但現在我們將繼續使用KISS原則 （保持簡單，愚蠢！）。
因此，讓我們創建三個mySQL的表來處理工作。 這些工作將是``，`jobRecords`，`和`jobResults。
在這裡，我使用的SQL巴迪一個偉大的小的替代phpMyAdmin的只是因為它更容易安裝在CentOS（對於別人看： 10大phpMyAdmin的替代品 ）
此表由5個簡單的領域，
- 編號：唯一標識工作
- 名稱：也許是客戶參考，或任意數量的其他標識
- 狀態：你要知道在那裡的工作是，如
- started_by：誰開始做這項工作嗎？ 這是必須的，但不完全是一個不錯的。 我建議由工人跟踪他們的IP地址在網絡上
- started_at：什麼時候工人開始上班？ 通過跟踪未完成的作業量在X的時候，我們知道我們需要拿起工作，並開始再次加工的另一名工人。 工人可以停止處理 /離線的任意數量的原因，停電，死機，網絡損失等
這是很容易如何表可以延長一些額外的字段，以便統計跟踪，完成時間列，了解工作多久了，計數器，看看有多少工人拿起工作（顯然，這往往需要1），作業的優先級，名單可以繼續下去。 在更複雜的工作方案將有可能指定多少內存工人將需要訪問（因此只使用合適的工人），甚至是什麼類型的工人將是必需的。
讓我們添加一些示例工作：
下表又是很容易理解，這些都是我們的工作記錄。 它們鏈接到的主要工作表中的列`jobs_id`。 美容，本表在很大程度上取決於你需要的數據提供給你的員工，讓做一個很簡單的例子，我們有四個列：
- 身份證：身份證的記錄
- 名稱：人的姓名
- 地址：人的地址
- jobs_id：工作記錄的ID，這是與
第三個也是最後一個結果表包括表，它有許多相同品牌，作為我們的記錄表，並與另外一些列可以是兼職的記錄表：
- job_record_id：鏈接的結果對工作表
- 結果：結果數據
...這就是你需要的作業控制！ （雖然在一個非常基本的水平）在我的情況下，我指著我的另一個表中的數據處理的位置，但是這也很容易被一個文件，參數運行模擬程序，你的名字。
選擇工作
如前所述，工人將盡我們的工作為我們現在的管理，所以我們真的需要做的是找到一份工作，需要處理和獲取信息。 我們怎麼做呢？ 挑好了我們的工作的選擇標準和尋找工作，在SQL我做了以下幾點：
- 採取任何作業未標記為完成，但我們的工人和重置它們（替代__ME__同一個標識符，最簡單的將是IP地址）：
更新`工作`設置`地位`= 0，其中`地位`和`started_by = 1`= __ME__;
- 用我們的工作選擇標準，選擇工作，告訴控制系統，這個工人是處理它：
更新`工作`設置`地位`= 1，`started_by`= __ME__，`started_at`=現在（）凡`地位`= 0或
（`地位`和`started_at = 1`> DATE_SUB（現在的（），間隔 x小時））的量級的`id`升序;
通過抓工作還沒有返回的結果在X的時間量，我們確保所有的工作都是運行在崩潰的事件或去工人擅離職守。
- 下一步的工作細節抓起其次是記錄自己：
選擇 *從`工作`其中`started_by`= __ME__極限 1;
選擇 *從`job_records`其中``= __JOBID__身份證;
這項工作完成後，我們插入我們的結果記錄和標記為已完成的工作。 記得作業可以暫停 /恢復在任何時候允許一些穩健性的腳本。 這可能是該任務中途中止更新作業控制系統，使檢查的記錄數在一份工作，結果數保存到作業控制系統將是一個明智之舉。
此外，雖然這項工作可以演示了如何選擇和管理，從一個SQL的查詢框，你真正應該抽象你的工作控制，因此，如果你決定轉而使用一個Web服務，基於文件系統， XML的 ，或任何其他數的系統也不會影響它上面的代碼。
作業配置
下一個方面要考慮的是作業的大小和配置。 透過扮演與工作配置，我們能夠取得良好平衡的速度，進程複製和可靠性。 以一對夫婦 ofÂ情況：
- 喬布斯以1天每次運行：這意味著你的員工需要15天時間來處理每一個工作（記得10％的功率2/3rds的時間）。 這顯然不是一個明智的配置，你的工作的大小是太大了！ 這將需要至少增加一倍的時間去處理工作應走的初始工人擅離職守（時間拿起它並沒有回加後處理結果的時間）。 在一個理想的你至少有一個完整的工作easily清除最後的每個長的空閒時間，這樣你的工作保持持續運轉，在最壞情況下工作需要兩天的過程中應首先失踪。
- 喬布斯需要1分鐘，運行：這意味著你的員工大約需要15分鐘才能運行每個作業。 雖然這最初可能似乎理想，你獲得額外的處理在工作午餐時間，茶點，會議等等這種情況下把其他領域的應變系統，介紹了其自身的問題。 例如，首先您的設置 /處理時間比還將會持續下去的權力下放，因此失去了系統效率。 您的網絡將是不斷流工作信息工作人員的各種令人沮喪的工人誰是毛澤東的日常工作。 你也將會把更多的應變處理服務器上的工作，因為它炮製出很多，很多小件作品定期。 最後，在這種情況下如果你的工作服務器停機你將創建一個巨大的回未完成的工作日誌，而更大的就業機會，可以繼續處理工作開心的不知道該服務器遇到的困難。
在現實中不會有一個理想的配置為您的網格設置，在很大程度上取決於可用的資源，類型的作業，作業周轉時間的要求，網絡功能等。 然而，有些準則是：
- 大小工作，這樣每個工人可以通過至少3-4在一段時間內的工作15個小時（最長可能空閒時間）
- 玩作業大小，使安裝時間變得相當微不足道相比，處理時間（銘記上述點）。
- 如果工作沒有完成的時間量的兩倍（也許更少），你期望它來完成它認為它不再擅離職守，並開始處理它與另一名工人。 這意味著你可能要等上三倍的正常長度為它的工作完成（可能更長如果後續工作失敗）。 您可能要減少這種時間，但要小心不要減少太多，你可以開始複製的處理任務定期。
- 喬布斯應該是獨立的外部要求盡可能。 作業服務器，例如，只應接觸的開始和結束每一項工作。
- 不飽和您的網絡，這將有兩方面的負面影響，你白天的工作人員將使用網絡找到令人沮喪和問題可能會遇到與連接超時的問題只會變得更糟，你縮放網格。
- 確保作業可以運行在自己的工人。 如果工作過於密集的內存或磁盤空間密集的工作將開始中止，唯一你會發現在數量上是一個下拉處理的工作，沒有真正原因。
提交結果求職
當提交一份工作的結果是很重要的檢查結果沒有被提交的其他工人，特別是如果目前的工作已經休眠一段時間。
當結果提交確保結果的數量相匹配的記錄數內的工作。
如前所述，而不能過分強調，建立容錯檢索到的工作和成果提交。 工人可以（而且很可能會）進入掛起模式在最不方便的時間，這需要被照顧。 還再次提取了你的結果提交將有助於應付未來的變化對你的工作更容易控制系統來處理。
綜述
在這 sectionÂ我們看到什麼工作需要做的控制服務器，以及如何得到一個非常基本的系統設置。 我們討論了如何檢索工作從控制系統以及如何最好地配置工作，以獲得最大的我們對您的辦公網系統。 要完成，一個段落或兩個提交結果返回到工作，提出了控制服務器。
- 一個作業控制服務器管理工作，確保完成各項工作單位
- 通過抽象你的工作選擇 /結果提交的技術，我們可以改變的控制服務器，沒有什麼問題
- 配置您的工作，以確保它們運行快速，高效地沒有把太多的壓力，您的網絡基礎設施，但不重複處理任務定期。
- 確定你建立容錯和錯誤 checkingÂ到您的程序，工人可以暫停，恢復和最不方便的時候。 記住要檢查的結果已經提交了另一名工人。
下次
在第三部分我們將創建我們的虛擬加工機，並成立了我們的窗戶機器成為空閒時間的工人。
評論（2） 
通過設置您的每個工人，作為一個奴隸的作業控制服務器更新您的數據源就會從天上掉下來的工人沒有很好的巨額增長，在網絡活動（即，除非你執行一個龐大的數據更新和所有的工人踢在一次）。 這已經超過rsync的優勢在，你不會得到一個長時間的停頓在每次工作;作為數據庫更新時， MySQL的守護進程在你的工人會不斷更新它的數據，而繼續處理。 
