這篇博文是Glass House Technologies公司副總裁Bill Peldzus先生就如何管理和規(guī)劃數(shù)據(jù)中心遷移所寫的系列博文的第二部分。上周，在第一部分中，他就數(shù)據(jù)中心的任何變化都需要進行提前規(guī)劃必要性（這些變化包括采用新的技術以及數(shù)據(jù)中心選址和基礎設備的遷移）進行了探討。

“所謂經(jīng)驗，不過是人們給自己人生錯誤蒙上的一層遮羞布而已。”奧斯卡•王爾德
　　
　　“只有一件事情比從經(jīng)驗中學習更痛苦，那就是不從經(jīng)驗中學習。”勞倫斯J•皮特
　　
　　上述這些名言常常被人們引用來教育那些忽略吸取寶貴的經(jīng)驗教訓，而片面強調“下一次的機會更好”的行為。當處理一個像數(shù)據(jù)中心遷移這樣的大項目時，無論其是屬于基礎設施鞏固、還是項目升級、或遷移到另一個數(shù)據(jù)中心，或是同一地點的設備移動。總之，細節(jié)決定成敗，因此為減少相關風險，適當?shù)囊?guī)劃是至關重要的。
　　
　　在過去的幾年的時間里，我一直在關注數(shù)據(jù)中心的遷移問題，而這些觀察也為我今天關于數(shù)據(jù)中心遷移問題所遇到的挑戰(zhàn)的思考奠定了一定的基礎。現(xiàn)在，我們有必要對未來的數(shù)據(jù)中心遷移進行詳細的規(guī)劃，而不是為了避免斷電就突擊性的在半夜進行遷移，或者更糟的是，在遷移的最后一刻才完全恢復。但如果進行了很好的規(guī)劃，不管你實際上是否是為了避免或解決此類問題，在執(zhí)行的時候，相關經(jīng)驗都會發(fā)揮積極主動的作用，而不需要反復調試、考慮。我的執(zhí)行和贊助團隊總是熱衷于強調“如果這種情況發(fā)生了，我們有相關的步驟，計劃采取適當?shù)氖侄危瑏斫鉀Q這個問題。”
　　
　　關于突發(fā)事件的應急預案、以及數(shù)據(jù)中心遷移的問題，如下是一些可以幫助您提前進行一些詳細規(guī)劃的建議：
　　
　　新技術的采用通常也就意味著其他方面的升級
　　
　　如果在遷移活動過程中涉及到要遷移到新的硬件，這通常是要更新到更好、更新的硬件設備（可能會帶來成本效益），無論是具體到服務器、存儲設備、或網(wǎng)絡設備。積極處理報廢設備和潛在的即將過時的設備，這都是一件好事。
　　
　　但與此同時，新的硬件必然需要配套進行一些其他方面的兼容性升級和支持。最明顯的便是體現(xiàn)在服務器的操作系統(tǒng)上，一般都需要打或大或小的補丁，或甚至固件升級。但是，其實這只是冰山一角。你還需要考察其對幾乎所有的應用程序棧可能帶來的影響。這些因素包括數(shù)據(jù)庫版本、中間件版本、以及應用程序本身。這些類型的升級可能會為您的應用程序管理團隊帶來很大的負擔，無論是從認證和測試方面，甚至將有可能對您時間和項目計劃都有重大影響。

再有就是，沒有人提前展望未來。我回想起曾經(jīng)的那些痛苦的遷移經(jīng)歷，在沒有充分進行壓力測試的情況下，我們發(fā)現(xiàn)，在遷移之后，對于一個特定的應用程序加硬件組合來說，新的多線程處理器芯片設置實際上大大減慢了單線程應用程序的性能。這很詭異。所以，我們現(xiàn)在要問，是否單線或多線程在規(guī)劃之前有必要進行適當?shù)暮驮敿毜男阅軠y試。
　　
　　是否將物理移動lift-and-shift作為遷移首選方法？
　　
　　我的許多客戶都傾向于將大規(guī)模的物理遷移作為首選的方法。當然，從邏輯上講，你不需要重新部署電纜、插頭、機架等等，但是，這樣真的可行嗎？嗯……恐怕不是。對于某些項目來說，其存在著一系列重大的風險你需要慎重考慮：
　　
　　供應商是否需要重新檢測設備，特別是對較大的設備，如磁帶庫或存儲陣列？
　　
　　這其中是否涉及到航運商的選擇？
　　
　　你打算如何處置相關數(shù)據(jù)，如果這些數(shù)據(jù)位于存儲區(qū)域網(wǎng)絡（SAN）？
　　
　　你是打算遷移整個存儲區(qū)域網(wǎng)絡（SAN）嗎？
　　
　　NAS連接狀況如何？
　　
　　何時進行物理運輸？
　　
　　是否針對內部特殊數(shù)據(jù)的安全問題配套服務器？
　　
　　如果服務器在遷移過程中丟失或延遲，是否有相關緊急預案？這一預案絕對不便宜……你需要為其進行保險。
　　
　　當設備重新安裝時，將發(fā)生哪些變化？包括服務器的名稱、IP地址、防火墻規(guī)則、備份的基礎設施、網(wǎng)絡路由、DNS、負載均衡等。
　　
　　因此，基于上述一系列的原因，lift-and-shift遷移方法通常是我最優(yōu)遷移選擇中最后選擇的方案。雖然其針對諸如單機非生產實驗室和測試設備等“特殊情況”可能非常有效，但我確實曾因這一方法經(jīng)歷過很多不好的經(jīng)驗。
　　
　　在這篇專欄的下半部分，我將討論v-2-v副本、“廣域網(wǎng)”和“局域網(wǎng)”之間的差異、以及應用程序和連接速度問題如何影響你數(shù)據(jù)中心遷移的進展問題。

#p#副標題#e#

“局域網(wǎng)”與“廣域網(wǎng)”有著顯著的不同——即使只是暫時的 服務器
　　
　　高速局域網(wǎng)連接與低速廣域網(wǎng)連接（都涉及到網(wǎng)絡延遲和帶寬問題）與應用程序以及用戶沒有很好的連接到這些應用程序之間是相互依存的關系。太多的本土應用程序始終被認為：1）在同一數(shù)據(jù)中心和2）最終用戶可能是在同一建筑物的不同的樓層。而這無疑就給數(shù)據(jù)中心遷移工程增加了許多額外的挑戰(zhàn)，使得工期延長至好幾個禮拜甚至幾個月。但是又有多少數(shù)據(jù)中心遷移工程能夠容忍如此長時間的性能損失呢？
　　
　　雖然現(xiàn)在開發(fā)出的新的、更靈活的應用程序似乎使得解決上述問題更容易：尤其在當今互聯(lián)網(wǎng)可以連接一切，以及各種“XXX即服務”模式的廣泛普及，使得數(shù)據(jù)中心那些極少數(shù)的應用程序的遷移已經(jīng)不再可能長時間影響企業(yè)的核心的業(yè)務了。您可以讓您的應用程序團隊及早并經(jīng)常性的參與遷移工程。以便為延遲做好準備。
　　
　　從虛擬端到虛擬端（V-2-V）模式蓬勃興起，但也要意識到其制約性
　　
　　如果你有許多應用程序采用了虛擬化基礎設施和手段，這意味著增加了您的遷移的選項組合。我是虛擬化技術的忠實粉絲，特別是當涉及到服務器虛擬化，作為從虛擬端到虛擬端工作的時候，這真的能為你和您的應用程序團隊減輕負擔——不用再重新加載操作系統(tǒng)、數(shù)據(jù)庫、中間件等。
　　
　　但與此同時，您也需要了解所有這些好處和相應的計劃的另一面。讓我們假設一個簡單的v-2-v復制/或者通過廣域網(wǎng)遷移到一個新的數(shù)據(jù)中心的時候。您需要考慮如下問題：
　　
　　• 在遷移之后需要立即進行測試和驗證，因為服務器在遷移之后的當前狀態(tài)通常是關閉的。理解這一程度需要花費應用和測試團隊一定的時間。
　　
　　• 還必須考慮廣域網(wǎng)的傳輸速度：特別是對于大型數(shù)據(jù)存儲來說。如果超過300GB，您可能需要全天候的v-2-v，而不是幾個小時。
　　
　　• 如果在遷移期間出現(xiàn)v-2-v中斷，您的應急預案是什么？這是繼續(xù)遷移/重新啟動或重新遷移？這兩種方案的結果是完全不同的。
　　
　　• 并行會帶來什么影響？對于僅僅是25或40臺V-2-V運行一個周末來說，該計劃可能還是可行的，畢竟每臺服務器只有100GB或更少的數(shù)據(jù)量。但如果要同時遷移所有這些數(shù)據(jù)呢，如此眾多的數(shù)據(jù)轉移將使你的廣域網(wǎng)癱瘓，并打亂你的時間安排。
　　
　　上述這些都是在遷移過程中，通過適當?shù)囊?guī)劃幫助您減輕風險，正確衡量，并最終幫助您的企業(yè)成功按計劃完成遷移的一些建議。最后，我想強調務必把更多的精力放到你的遷移計劃中，須知“今天的好計劃勝過明天的完美計劃。”

原文鏈接：http://www.jifang360.com/news/2011823/n521027519.html