自動化模式運用于數(shù)據(jù)中心可行嗎
發(fā)布時間:2014-04-01 新聞來源:中國自動化網(wǎng)
據(jù)自動化英才網(wǎng)了解在IT界,特別是在數(shù)據(jù)中心架構(gòu)、建設和維護工作中的工作人員都表示,能夠從構(gòu)建新事物以及看著它們成功運作中獲得滿足感。在數(shù)據(jù)中心的所有領域都是如此,從網(wǎng)絡到存儲,大家喜歡構(gòu)建事物。
事物構(gòu)建完成之后,我們會開始優(yōu)化它,并監(jiān)控一切以確保其正常運行。在大多數(shù)情況下,這最終會涉及到一定程度的自動化,而這正是工具箱腳本和開發(fā)發(fā)揮作用的地方。通過編寫一些代碼來取代手動任務,將其放入生產(chǎn)環(huán)節(jié),并移動到下一個目標。
理想情況下,工作人員應該盡可能多地對代碼進行錯誤檢查,但很多時候,開發(fā)人員并不會進行真正的錯誤檢查,這可能帶來巨大的災難。
假設已經(jīng)部署了程序來調(diào)整負載均衡器,以及添加新的web服務器,我們真正要關注的是確保這些服務器上的應用程序堆棧的穩(wěn)定性和正常運行。我們編寫了一些代碼,并將其放入到init腳本,讓每臺web服務器可以下載某些需要的變量因素,以便可以正常運行。這又是簡單的事情。我們可以自動化anrsync或者scp進程。我們可以非常快速方便地測試這個代碼。
但是,如果我們沒有對該代碼進行足夠的錯誤檢查,我們可能會發(fā)現(xiàn),在半年內(nèi),整個應用程序開始間歇性崩潰。也許文件名更改了,或者服務器被替換,或者某人更改了authorized_keys文件。這些都是看蘇無害的變化,當這些web服務器啟動時,它們將無法訪問它們需要的東西,從而無法正常運行。
在這種情況下應該會發(fā)生這樣的事情:服務器通過SNMP或者電子郵件顯示錯誤,并不會打開web服務。這個問題將會顯而易見,也許一些調(diào)試就可以解決。然而,如果服務器繼續(xù)打開所有服務,并加入到負載均衡組,它可能無法正常工作。
根據(jù)所遇到的實際問題,這可能意味著新服務器上的所有服務都崩潰了,可能讓服務、內(nèi)容和應用程序監(jiān)控框架無法檢測到攻擊。服務器可能看起來沒問題,但實際并不是這樣。
如果這種影響相對較小,可能更加令人不安,這意味著通過該模版生成的新服務器啟動時,又會出現(xiàn)錯誤報告,或者只會有小部分用戶受影響,因為已經(jīng)運行的服務器沒有相同的問題。這些問題很難發(fā)現(xiàn)。筆者更愿意看到這樣的情況:啟動十幾臺服務器、發(fā)現(xiàn)一個錯誤、發(fā)送警報,然后破壞應用程序。與損壞的可能破壞數(shù)據(jù)庫的快速應用程序相比,容量較低而減緩運行的應用程序更可接受。
這個問題的關鍵是,看似微小的自動化工作可能能夠完美地工作很長的時間,但最終還是會帶來破壞。自動駕駛儀是偉大的發(fā)明,但我們還是希望由人來駕駛汽車,以確保事情的正常運行。對于簡單的自動化任務,我們應該盡可能多地進行錯誤檢查,因為這和自動化本身一樣重要。
筆者的一些自動化腳本是25%的函數(shù)代碼,以及75%的錯誤檢查和故障處理。當自動化腳本出現(xiàn)問題時,我們應該將調(diào)試信息輸出到STDOUT。當與cronjobs或啟動腳本中的mail-E結(jié)合使用時,調(diào)試到STDOUT能夠帶來簡單的通知步驟。
自動化確實能夠帶來很大的滿足感。我們能夠構(gòu)建一個機智的框架來簡化一些工作,然后看著其運作。但就像樂高車一樣,如果我們不重視,它最終將會碰壁。最好一開始就做好規(guī)劃。
【打印】 【關閉】
分享到: | qq空間 | 新浪微博 | 人人網(wǎng) | 豆瓣網(wǎng) | MSN | 騰訊微博 |