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