導致數(shù)據(jù)中心斷網的誘因那五大事件

數(shù)據(jù)中心斷網事件的五大誘因盤點？數(shù)據(jù)中心會因那些因素導致斷網？數(shù)據(jù)中心斷網都會有那些因素？導致數(shù)據(jù)中心斷網的誘因都有那五大事件！今天這篇文章就來介紹一下導致數(shù)據(jù)中心斷網的誘因都有那五大事件的盤點。

云計算服務在這個時代被吹捧成為IT圣者，所有的服務都可以被“云”化。但是，當很多公司勇于第一個吃螃蟹之后，卻發(fā)現(xiàn)往往最容易受傷的也是他們。近幾年來，層出不窮的云服務斷網事件，讓業(yè)界聽得心驚膽寒。

騰佑科技小編今天在這里回顧一下近年來發(fā)生的一系列斷網事件背后的原因。從2009年-2012年之間。也許能讓你看到：即便是計算機出錯似乎在所難免，再保險的措施似乎也只能把安全事件控制在一個小概率范圍內。

斷網誘因一：系統(tǒng)故障

典型事件1：GoDaddy網站DNS服務器中斷

故障原因：系統(tǒng)內一系列路由器的數(shù)據(jù)表造成的網絡中斷

2012年9月10日GoDaddy網站DNS服務器中斷：域名巨頭GoDaddy是一家最重要的DNS服務器供應商，其擁有500萬個網站，管理超過5000萬的域名。這就是為什么九月10日中斷事故會是一個2012年最具破壞性的事件。

一些炒作甚至認為，此次長達6個小時的中斷事件是由于拒絕服務攻擊的結果，但GoDaddy后來表示，這是路由器表的損壞數(shù)據(jù)造成的。"服務中斷不是由外部影響造成的。"GoDaddy的臨時首席執(zhí)行官史葛瓦格納說。"這不是黑客攻擊也不是一個拒絕服務攻擊(DDoS)。我們已經確定了服務中斷是由于內部的一系列路由器的數(shù)據(jù)表造成的網絡事件損壞。"

典型事件2：盛大云存儲斷網

故障原因：數(shù)據(jù)中心一臺物理服務器磁盤損壞

2012年8月6日晚上8：10，盛大云在其官方微博上發(fā)布一則因云主機故障致用戶數(shù)據(jù)丟失事件的公開聲明。聲明說到：8月6日，盛大云在無錫的數(shù)據(jù)中心因為一臺物理服務器磁盤發(fā)生損壞，導致"個別用戶"數(shù)據(jù)的丟失。盛大云已經在盡全力協(xié)助用戶恢復數(shù)據(jù)。

對于因為一臺"物理服務器磁盤發(fā)生損壞"，導致"個別用戶"數(shù)據(jù)的丟失的情況，盛大云技術人員給出自己的解釋：虛擬機的磁盤有兩種生產方式，一種是直接使用宿主機的物理磁盤。這種情況下，如果宿主機的物理磁盤發(fā)生故障，云主機不可避免會造成數(shù)據(jù)丟失，這也是本次事件產生的原因;另外一種是使用遠程存儲，也就是盛大硬盤產品，這種方式實際上是把用戶的數(shù)據(jù)存到了遠程的一個集群里，并同時做了多份備份，即使宿主機出故障也不會影響到云主機的數(shù)據(jù)。因為物理機的損壞很難避免，為了避免您遇到意外損失，我們建議您在云主機之外，也做好數(shù)據(jù)備份。

典型事件3：Google App Engine中斷服務

故障原因：網絡延遲

Google App Engine：GAE是用于開發(fā)和托管WEB應用程序的平臺，數(shù)據(jù)中心由google管理，中斷時間是10月26日，持續(xù)4小時，因為突然變得反應緩慢，而且出錯。受此影響，50%的GAE請求均失敗。

谷歌表示沒有數(shù)據(jù)丟失，應用程序行為也有備份可以還原。為表歉意，google宣布11月份用戶可以google表示他們正在加強其網絡服務以應對網絡延遲問題，"我們已經增強了流量路由能力，并調整了配置，這些將會有效防止此類問題再次發(fā)生"。

斷網誘因二：自然災害

典型事件1：亞馬遜北愛爾蘭柏林數(shù)據(jù)中心宕機

故障原因：閃電擊中柏林數(shù)據(jù)中心的變壓器

2011年8月6日，在北愛爾蘭都柏林出現(xiàn)的閃電引起亞馬遜和微軟在歐洲的云計算網絡因為數(shù)據(jù)中心停電而出現(xiàn)大規(guī)模宕機。閃電擊中都柏林數(shù)據(jù)中心附近的變壓器，導致其爆炸。爆炸引發(fā)火災，使所有公用服務機構的工作暫時陷入中斷，導致整個數(shù)據(jù)中心出現(xiàn)宕機。

這個數(shù)據(jù)中心是亞馬遜在歐洲唯一的數(shù)據(jù)存儲地，也就是說，EC2云計算平臺客戶在事故期間沒有其他數(shù)據(jù)中心可供臨時使用。宕機事件使得采用亞馬遜EC2云服務平臺的多家網站長中斷達兩天時間之久。

典型事件2：卡爾加里數(shù)據(jù)中心火災事故

故障原因：數(shù)據(jù)中心發(fā)生火災

2012年7月11日卡爾加里數(shù)據(jù)中心火災事故：加拿大通信服務供應商ShawCommunicationsInc位于卡爾加里阿爾伯塔的數(shù)據(jù)中心發(fā)生了一場火災，造成當?shù)蒯t(yī)院的數(shù)百個手術延遲。由于該數(shù)據(jù)中心提供管理應急服務，此次火災事件影響了支持關鍵公共服務主要的備份系統(tǒng)。此次事件為一系列政府機構敲響了警鐘，必須確保及時的恢復和擁有故障轉移系統(tǒng)，同時結合出臺災害管理計劃。

典型事件3：超級颶風桑迪襲擊數(shù)據(jù)中心

故障原因：風暴和洪水導致數(shù)據(jù)中心停止運行

2012年10月29日，超級颶風桑迪：紐約和新澤西州的數(shù)據(jù)中心都受到了此次颶風的影響，所帶來的惡劣影響包括為曼哈頓下城地區(qū)的洪水和一些設施的停機，周圍地區(qū)數(shù)據(jù)中心發(fā)電機運行失常。颶風桑迪所帶來的影響超出了一般單一的中斷事故，為受災地區(qū)數(shù)據(jù)中心產業(yè)帶來了規(guī)模空前的災難。事實上，柴油已然成為了數(shù)據(jù)中心恢復工作的生命線，作為備用電源系統(tǒng)接管了整個地區(qū)的負荷，促使特別措施，保持發(fā)電機的燃料。隨著眼前的工作重點逐步轉移到災后重建，我們有必要長期就數(shù)據(jù)中心的選址、工程和災難恢復進行探討，這一話題可能將持續(xù)幾個月，甚至幾年。

斷網誘因三：人為因素

典型事件1：Hosting.com服務中斷事故

故障原因：服務供應商執(zhí)行斷路器操作順序不正確造成的UPS關閉

2012年7月28日Hosting.com停運事件：人為錯誤通常被認為是數(shù)據(jù)中心停機的主導因素之一。7月Hosting.com中斷事件造成 1100名客戶服務中斷就是一個例子。停機事故的發(fā)生是由于該公司位于特拉華州紐瓦克的數(shù)據(jù)中心正進行UPS系統(tǒng)預防性維護，"服務供應商執(zhí)行斷路器操作順序不正確造成的UPS關閉是造成數(shù)據(jù)中心套房內的設施損失的關鍵因素之一。"Hosting.com首席執(zhí)行官ArtZeile說。"沒有任何重要的電力系統(tǒng)或備用電源系統(tǒng)出現(xiàn)故障，完全是一種人為的錯誤造成的。"

典型事件2：微軟爆發(fā)BPOS服務中斷事件

故障原因：微軟在美國、歐洲和亞洲的數(shù)據(jù)中心的一個沒有確定的設置錯誤造成的

2010年9月，微軟在美國西部幾周時間內出現(xiàn)至少三次托管服務中斷事件向用戶致歉。這是微軟首次爆出重大的云計算事件。

事故當時，用戶訪問BPOS(Business Productivity Online Suite)服務的時候，如果使用微軟北美設施訪問服務的客戶可能遇到了問題，這個故障持續(xù)了兩個小時。雖然，后來微軟工程師聲稱解決了這一問題，但是沒有解決根本問題，因而又產生了9月3日和9月7日服務再次中斷。

微軟的Clint Patterson說，這次數(shù)據(jù)突破事件是由于微軟在美國、歐洲和亞洲的數(shù)據(jù)中心的一個沒有確定的設置錯誤造成的。BPOS軟件中的離線地址簿在"非常特別的情況下"提供給了非授權用戶。這個地址簿包含企業(yè)的聯(lián)絡人信息。

微軟稱，這個錯誤在發(fā)現(xiàn)之后兩個小時就修復了。微軟稱，它擁有跟蹤設施，使它能夠與那些錯誤地下載這些數(shù)據(jù)的人取得聯(lián)系以便清除這些數(shù)據(jù)。

斷網類型四：系統(tǒng)故障

典型事件1：亞馬遜AWS平安夜斷網

故障原因：彈性負載均衡服務故障

2012年12月24日，剛剛過去的圣誕節(jié)平安夜，亞馬遜并沒有讓他們的客戶過得太平安。亞馬遜AWS位于美國東部1區(qū)的數(shù)據(jù)中心發(fā)生故障，其彈性負載均衡服務(Elastic Load Balancing Service)中斷，導致Netflix和Heroku等網站受到影響。其中，Heroku在之前的AWS美國東部區(qū)域服務故障中也受到過影響。不過，有些巧合的事情是Netflix的競爭對手，亞馬遜自己的業(yè)務Amazon Prime Instant Video并未因為這個故障而受到影響。

12月24日，亞馬遜AWS中斷服務事件不是第一次，當然也絕非最后一次。

2012年10月22日，亞馬遜位于北維吉尼亞的網絡服務AWS也中斷過一次。其原因與上次相似。事故影響了包括Reddit、Pinterest等知名大網站。中斷影響了彈性魔豆服務，其后是彈性魔豆服務的控制臺，關系數(shù)據(jù)庫服務，彈性緩存，彈性計算云EC2，以及云搜索。這次事故讓很多人認為，亞馬遜是應該升級其北維尼吉亞數(shù)據(jù)中心的基礎設施了。

2011年4月22日，亞馬遜云數(shù)據(jù)中心服務器大面積宕機，這一事件被認為是亞馬遜史上最為嚴重的云計算安全事件。由于亞馬遜在北弗吉尼亞州的云計算中心宕機，包括回答服務Quora、新聞服務Reddit、Hootsuite和位置跟蹤服務FourSquare在內的一些網站受到了影響。亞馬遜官方報告中聲稱，此次事件是由于其EC2系統(tǒng)設計存在漏洞和設計缺陷，并且在不斷修復這些已知的漏洞和缺陷來提高EC2(亞馬遜ElasticComputeCloud服務)的競爭力。

2010年1月，幾乎6萬8千名的Salesforce.com用戶經歷了至少1個小時的宕機。Salesforce.com由于自身數(shù)據(jù)中心的"系統(tǒng)性錯誤"，包括備份在內的全部服務發(fā)生了短暫癱瘓的情況。這也露出了Salesforce.com不愿公開的鎖定策略：旗下的PaaS平臺、Force.com不能在Salesforce.com之外使用。所以一旦Salesforce.com出現(xiàn)問題，F(xiàn)orce.com同樣會出現(xiàn)問題。所以服務發(fā)生較長時間中斷，問題將變得很棘手。

斷網誘因五：系統(tǒng)Bug

典型事件1：Azure全球中斷服務

事故原因：軟件Bug導致閏年時間計算不正確

2012年2月28日，由于"閏年bug"導致微軟Azure在全球范圍內大面積服務中斷，中斷時間超過24小時。雖然微軟表示該軟件BUG是由于閏年時間計算不正確導致，但這一事件激起了許多用戶的強烈反應，許多人要求微軟為此做出更合理詳細的解釋。

典型事件2：Gmail電子郵箱爆發(fā)全球性故障

事故原因：數(shù)據(jù)中心例行性維護時，新程序代碼的副作用

2009年2月24日，谷歌的Gmail電子郵箱爆發(fā)全球性故障，服務中斷時間長達4小時。谷歌解釋事故的原因：在位于歐洲的數(shù)據(jù)中心例行性維護之時，有些新的程序代碼(會試圖把地理相近的數(shù)據(jù)集中于所有人身上)有些副作用，導致歐洲另一個資料中心過載，于是連鎖效應就擴及到其它數(shù)據(jù)中心接口，最終釀成全球性的斷線，導致其他數(shù)據(jù)中心也無法正常工作。

典型事件3：“5.19斷網事件”

事故原因：客戶端軟件Bug，上網終端頻繁發(fā)起域名解析請求，引發(fā)DNS擁塞

2009年5月19日的21：50，江蘇、安徽、廣西、海南、甘肅、浙江等六省用戶申告訪問網站速度變慢或無法訪問。經過工信部相關單位調查通報稱，此次全國六省網絡中斷事故，原因是國內某公司推出的客戶端軟件存在缺陷，在該公司域名授權服務器工作異常的情況下，導致安裝該軟件的上網終端頻繁發(fā)起域名解析請求，引發(fā)DNS擁塞，造成大量用戶訪問網站慢或網頁打不開。

其中，DN SPod是國內知名的域名解析服務商之一的N SPod公司，服務數(shù)家知名網站的域名解析服務。此次攻擊導致DN SPod公司所屬的6臺dns域名解析服務器癱瘓，直接造成包括暴風影音在內的多家網絡服務商的域名解析系統(tǒng)癱瘓，由此引發(fā)網絡擁塞，造成大量用戶不能正常上網。 工信部指出，此次事件暴露出域名解析服務成為目前網絡安全的薄弱環(huán)節(jié)，指示各單位要加強對域名解析服務的安全保護。

啟用云服務的公司，很大程度是考慮這種服務可以更加編輯，性價比高。但是，這樣的考慮如果是以降低安全性作為代價，估計很多公司老大不會同意。層出不窮的云服務斷網事件引起了云端安全性的擔憂。

文章最后總結：目前來看，解決的辦法可以從幾個角度出發(fā)，對于企業(yè)級客戶來說，務必在采用云服務的同時定期備份云端的數(shù)據(jù)，擁有第二套解決方案按，以備不時之需。而對于云服務提供商來說，既然各種斷網事件是在所難免的，那就必須思考一個對策，將自己用戶的損失降到最低，對斷網事件的響應效率要提高。