IT 災備：系統管理員對抗自然災害

Steven-j-vaughan-nichols發表於2019-08-12

面對傾瀉的洪水或地震時業務需要繼續運轉。在颶風卡特里娜、桑迪和其他災難中倖存下來的系統管理員向在緊急狀況下負責 IT 的人們分享真實世界中的建議。

說到自然災害，2017 年可算是多災多難。（LCTT 譯註：本文發表於 2017 年）颶風哈維、厄瑪和瑪莉亞給休斯頓、波多黎各、弗羅裡達和加勒比造成了嚴重破壞。此外，西部的野火將多處住宅和商業建築付之一炬。

再來一篇關於有備無患的警示文章 —— 當然其中都是好的建議 —— 是很簡單的，但這無法幫助網路管理員應對溼漉漉的爛攤子。那些善意的建議中大多數都假定掌權的人樂於投入資金來實施這些建議。

我們對真實世界更感興趣。不如讓我們來充分利用這些壞訊息。

一個很好的例子：自然災害的一個後果是老闆可能突然願意給災備計劃投入預算。如同一個紐約地區的系統管理員所言，“我發現颶風桑迪的最大好處是我們的客戶對 IT 投資更有興趣了，但願你也能得到更多預算。”

不過別指望這種意願持續很久。任何想提議改進基礎設施的系統管理員最好趁熱打鐵。如同另一位颶風桑迪中倖存下來的 IT 專員懊悔地提及那樣，“對 IT 開支最初的興趣持續到當年為止。到了第二年，任何尚未開工的計劃都因為‘預算約束’被擱置了，大約 6 個月之後則完全被遺忘。”

在管理層忘記惡劣的自然災害也可能降臨到好公司頭上之前提醒他們這點會有所幫助。根據商業和家庭安全協會Institute for Business & Home Safety的說法，自然災害後歇業的公司中 25% 再也沒能重新開業。聯邦緊急事務管理署FEMA認為這過於樂觀。根據他們的統計，“災後 40% 的小公司再也沒能重新開門營業。”

如果你是個系統管理員，你能幫忙挽救你的公司。這裡有一些倖存者的最好的主意，這些主意是基於他們從過去幾次自然災害中得到的經驗。

制訂一個計劃

當燈光忽明忽暗，狂風象火車機車一樣怒號時，就該啟動你的業務持續計劃和災備計劃了。

有太多的系統管理員報告當暴風雨來臨時這兩個計劃中一個也沒有。這並不令人驚訝。2014 年災備預備狀態委員會Disaster Recovery Preparedness Council發現世界範圍內被調查的公司中有 73% 沒有足夠的災備計劃。

“足夠”是關鍵詞。正如一個系統管理員 2016 年在 Reddit 上寫的那樣，“我們的災備計劃就是一場災難。我們所有的資料都備份在離這裡大約 30 英里的一個儲存區域網路SAN。我們沒有將資料重新上線的硬體，甚至好幾天過去了都沒能讓核心伺服器啟動執行起來。我們是個年營收 40 億美元的公司，卻不願為適當的裝置投入幾十萬美元，或是在資料中心添置幾臺伺服器。當添置硬體的提案被提出的時候，我們的管理層說，‘嗐，碰到這種事情的機會能有多大呢’。”

同一個帖子中另一個人說得更簡潔：“眼下我的災備計劃只能在黑暗潮溼的角落裡哭泣，但願沒人在乎損失的任何東西。”

如果你在哭泣，但願你至少不是獨自流淚。任何災備計劃，即便是 IT 部門制訂的災備計劃，必須確定你能跟別人通訊，如同系統管理員 Jim Thompson 從卡特里娜颶風中得到的教訓：“確保你有一個與人們通訊的計劃。在一場嚴重的區域性災難期間，你將無法給身處災區的任何人打電話。”

有一個選擇可能會讓有技術頭腦的人感興趣：業餘電臺ham radio。它在波多黎各發揮了巨大作用。

列一個願望清單

第一步是承認問題。“許多公司實際上對災備計劃不感興趣，或是消極對待”，Micro Focus 的首席架構師 Joshua Focus 說。“將災備看作業務持續性的一個方面是種不同的視角。所有公司都要應對業務持續性，所以災備應被視為業務持續性的一部分。”

IT 部門需要將其需求書面化以確保適當的災備和業務持續性計劃。即使是你不知道如何著手，或尤其是這種時候，也是如此。正如一個系統管理員所言，“我喜歡有一個‘想法轉儲’，讓所有計劃、點子、改進措施毫無保留地提出來。（這）對一類情況尤其有幫助，即當你提議變更，並付諸實施，接著 6 個月之後你警告過的狀況就要來臨。”現在你做好了一切準備並且可以開始討論：“如同我們之前在 4 月討論過的那樣……”

因此，當你的管理層對業務持續性計劃迴應道“嗐，碰到這種事的機會能有多大呢？”的時候你能做些什麼呢？有個系統管理員稱這也完全是管理層的正常行為。在這種糟糕的處境下，老練的系統管理員建議用書面形式把這些事情記錄下來。記錄應清楚表明你告知管理層需要採取的措施，且他們拒絕採納建議。“總的來說就是有足夠的書面材料能讓他們搓成一根繩子上吊，”該系統管理員補充道。

如果那也不起作用，恢復一個被洪水淹沒的資料中心的相關經驗對你找個新工作是很有幫助的。

保護有形的基礎設施

“我們的辦公室是幢搖搖欲墜的建築，”颶風哈維重創休斯頓之後有個系統管理員提到。“我們盲目地進入那幢建築，現場的基礎設施糟透了。正是我們給那幢建築裡帶去了最不想要的一滴水，現在基礎設施整個都沉在水下了。”

儘管如此，如果你想讓資料中心繼續運轉——或在暴風雨過後恢復運轉 —— 你需要確保該場所不僅能經受住你所在地區那些意料中的災難，而且能經受住那些意料之外的災難。一箇舊金山的系統管理員知道為什麼重要的是確保公司的伺服器安置在可以承受里氏 7 級地震的建築內。一家聖路易斯的公司知道如何應對龍捲風。但你應當為所有可能發生的事情做好準備：加州的龍捲風、密蘇里州的地震，或殭屍末日（給你在 IT 預算裡增加一把鏈鋸提供了充分理由）。

在休斯頓的情況下，多數資料中心保持運轉，因為它們是按照抵禦暴風雨和洪水的標準建造的。Data Foundry 的技術長 Edward Henigin 說他們公司的資料中心之一，“專門建造的休斯頓 2 號的設計能抵禦 5 級颶風的風速。這個場所的公共供電沒有中斷，我們得以避免切換到後備發電機。”

那是好訊息。壞訊息是伴隨著超級颶風桑迪於 2012 年登場，如果你的資料中心沒準備好應對洪水，你會陷入一個麻煩不斷的世界。一個不能正常運轉的資料中心 Datagram 服務的客戶包括 Gawker、Gizmodo 和 Buzzfeed 等知名網站。

當然，有時候你什麼也做不了。正如某個波多黎各聖胡安的系統管理員在颶風厄瑪掃過後悲傷地寫到，“發電機沒油了。伺服器機房靠電池在運轉但是沒有（空調）。永別了，伺服器。”由於 MPLSMultiprotocol Lable Switching 線路亦中斷，該系統管理員沒法切換到災備措施：“多麼充實的一天。”

總而言之，IT 專業人士需要了解他們所處的地區，瞭解他們面臨的風險並將他們的伺服器安置在能抵禦當地自然災害的資料中心內。

關於雲的爭議

當暴風雨席捲一切時避免 IT 資料中心失效的最佳方法就是確保災備資料中心在其他地方。選擇地點時需要審慎的決策。你的災備資料中心不應在會被同一場自然災害影響到的地域region；你的資源應安置在多個可用區availability zone內。考慮一下主備資料中心位於一場地震中的同一條斷層帶上，或是主備資料中心易於受互通河道導致的洪災影響這類情況。

有些系統管理員利用雲作為冗餘設施。例如，總是用微軟 Azure 雲端儲存服務儲存副本以確保永續性和高可用性。根據你的選擇，Azure 複製功能將你的資料要麼拷貝到同一個資料中心要麼拷貝到另一個資料中心。多數公有云提供類似的自動備份服務以確保資料安全，不論你的資料中心發生什麼情況——除非你的雲服務供應商全部設施都在暴風雨的行進路徑上。

昂貴麼？是的。跟業務中斷 1、2 天一樣昂貴麼？並非如此。

信不過公有云？可以考慮 colocolocation 服務。有了 colo，你依舊擁有你的硬體，執行你自己的應用，但這些硬體可以遠離麻煩。例如颶風哈維期間，一家公司“虛擬地”將它的資源從休斯頓搬到了其位於德克薩斯奧斯汀的 colo。但是那些本地資料中心和 colo 場所需要準備好應對災難；這點是你選擇場所時要考慮的一個因素。舉個例子，一個尋找 colo 場所的西雅圖系統管理員考慮的“全都是抗震和旱災應對措施（加固的地基以及補給冷卻系統的運水卡車）。”

周圍一片黑暗時

正如 Forrester Research 的分析師 Rachel Dines 在一份為災備期刊所做的調查中報告的那樣，宣佈的災難中最普遍的原因就是斷電。儘管你能應對一般情況下的斷電，颶風、火災和洪水的考驗會超越裝置的極限。

某個系統管理員挖苦式的計劃是什麼呢？“趁 UPS 完蛋之前把你能關的機器關掉，不能關的就讓它崩潰咯。然後，喝個痛快直到供電恢復。”

在 2016 年德爾塔和西南航空停電事故之後，IT 員工推動的一個更加嚴肅的計劃是由一個有管理的服務供應商為其客戶部署不間斷電源：“對於至關重要的部分，在供電中斷時我們結合使用簡單網路管理協議SNMP信令和 PowerChute 網路關機PowerChute Nrework Shutdown客戶端來關閉裝置。至於重新開機，那取決於客戶。有些是自動啟動，有些則需要人工干預。”

另一種做法是用來自兩個供電所的供電線路支援資料中心。例如，西雅圖威斯汀大廈資料中心有來自不同供電所的多路 13.4 千伏供電線路，以及多個 480 伏三相變電箱。

預防嚴重斷電的系統不是“通用的”裝置。系統管理員應當為資料中心請求一臺定製的柴油發電機。除了按你特定的需求調整，發電機必須能迅速跳至全速運轉並承載全部電力負荷而不致影響系統負載效能。”

這些發電機也必須加以保護。例如，將你的發電機安置在泛洪區的一樓就不是個聰明的主意。位於紐約百老街Broad street的資料中心在超級颶風桑迪期間就是類似情形，備用發電機的燃料油桶在地下室 —— 並且被水淹了。儘管一場“人力接龍”用容量 5 加侖的水桶將柴油輸送到 17 段樓梯之上的發電機使 Peer 1 Hosting 得以繼續運營，但這不是一個切實可行的業務持續計劃。

正如多數資料中心專家所知那樣，如果你有時間 —— 假設一個颶風離你有一天的距離 —— 確保你的發電機正常工作，加滿油，準備好當供電線路被刮斷時立即開啟，不管怎樣你之前應當每月測試你的發電機。你之前是那麼做的，是吧？是就好！

測試你對備份的信心

普通使用者幾乎從不備份，檢查備份是否實際完好的就更少了。系統管理員對此更加了解。

有些 IT 部門在尋求將他們的備份遷移到雲端。但有些系統管理員仍對此不買賬 —— 他們有很好的理由。最近有人報告，“在用了整整 5 天從亞馬遜 Glacier 恢復了（400 GB）資料之後，我欠了亞馬遜將近 200 美元的傳輸費，並且（我還是）處於未完全恢復狀態，還差大約 100 GB 檔案。”

結果是有些系統管理員依然喜歡磁帶備份。磁帶肯定不夠時髦，但正如作業系統專家 Andrew S. Tanenbaum 說的那樣，“永遠不要低估一輛裝滿磁帶在高速上飛馳的旅行車的頻寬。”

目前每盤磁帶可以儲存 10 TB 資料；有的進行中的實驗可在磁帶上儲存高達 200 TB 資料。諸如線性磁帶檔案系統Linear Tape File System之類的技術允許你象訪問網路硬碟一樣讀取磁帶資料。

然而對許多人而言，磁帶絕對是最後選擇的手段。沒關係，因為備份應該有大量的可選方案。在這種情況下，一個系統管理員說到，“故障時我們會用這些方法（恢復備份）：（Windows）伺服器層面的 VSS （Volume Shadow Storage）快照，儲存區域網路SAN層面的卷快照，以及儲存區域網路層面的異地歸檔快照。但是萬一有什麼事情發生並摧毀了我們的虛擬機器，儲存區域網路和備份儲存區域網路，我們還是可以取回磁帶並恢復資料。”

當麻煩即將到來時，可使用副本工具如 Veeam，它會為你的伺服器建立一個虛擬機器副本。若出現故障，副本會自動啟動。沒有麻煩，沒有手忙腳亂，正如某個系統管理員在這個流行的系統管理員帖子中所說，“我愛你 Veeam。”

網路？什麼網路？

當然，如果員工們無法觸及他們的服務，沒有任何雲、colo 和遠端資料中心能幫到你。你不需要一場自然災害來證明冗餘網際網路連線的正確性。只需要一臺挖斷線路的挖掘機或斷掉的光纜就能讓你在工作中渡過糟糕的一天。

“理想狀態下”，某個系統管理員明智地觀察到，“你應該有兩路網際網路接入線路連線到有獨立基礎設施的兩個 ISP。例如，你不希望兩個 ISP 都依賴於同一根光纜。你也不希望採用兩家本地 ISP，並發現他們的上行頻寬都依賴於同一家骨幹網運營商。”

聰明的系統管理員知道他們公司的網際網路接入線路必須是商業級別的，帶有服務等級協議service-level agreement(SLA)，其中包含“修復時間”條款。或者更好的是採用網際網路接入專線dedicated Internet access。技術上這與任何其他網際網路接入方式沒有區別。區別在於網際網路接入專線不是一種“盡力而為”的接入方式，而是你會得到明確規定的專供你使用的頻寬並附有服務等級協議。這種專線不便宜，但正如一句格言所說的那樣，“速度、可靠性、便宜，只能挑兩個。”當你的業務跑在這條線路上並且一場暴風雨即將來襲，“可靠性”必須是你挑的兩個之一。