我們都知道這種情況：解決方案A托管在服務器1上，但是服務器1的可靠性出于某些原因可能存在一些問題。這樣服務器會遭遇故障，更新延遲或者需要虛擬化來保存資源--這只是遷移到服務器2的眾多合理原因中的幾種。用戶要面臨的挑戰是即要完成服務器遷移又不會損失解決方案A所需的功能和資源或者引發過多的宕機從而招致用戶對IT部門的投訴。

因此當你小心謹慎的實施遷移的過程又不愿遭受損失整個系統的風險，那么你該如何應對這種兩難的狀況呢？你又該如何滿足用戶對零宕機的苛刻要求呢？以下是幫助你規避這些風險的五個提示。

了解系統之間的從屬性

雖然IT員工可能不愿意承認這一點，但某些員工可能確實不完全了解一項解決方案在既定的遷移戰略中是如何工作的。以Exchange Server為例。更改為Exchange Server可以用幾種方式完成，從單個用戶遷移簡單的電子郵箱轉移的操作到從整個服務器轉移到新的域這種第三方解決方案（如果必要的話）都涵蓋在內。

面臨的挑戰是這種遷移會對諸如Good Technologies服務，黑莓企業級服務器，Lync和移動技術套裝向Exchange (Outlook Web Access/App, Outlook Anywhere和ActiveSync)本地遷移的系統產生影響。與在電子郵箱服務器遷移過程中將這些生態系統解決方案考慮在內的方法不同，你可以非常快速的導出所有的移動用戶。但是無法全面了解所有的外圍系統，而你的目標遷移系統可能會依賴這些外圍系統或者相互依賴，從而讓你陷入真實遷移的夢魘。

#p#

什么是必須要進行遷移的

一套解決方案是由涉及一個或者多個服務器或者硬件資源的一個或者多個組件所組成的。在遷移過程中正確的步驟能確保你首先了解解決方案的工作原理和遷移部分在開始實際遷移前會占到所遷移系統中的比例。傳真服務器就是這種解決方案類型的***示例，因為要保證操作正確許多企業都需要物理傳真卡。如果你沒有確保傳真卡與你試圖遷移的新硬件/虛擬化平臺相兼容的話，那么再好的遷移計劃也會大打折扣。

#p#

什么應該被遷移

一旦你計算出必須從目前平臺遷移出去的組件，你應該全面分析你可能需要遷移或者不需要遷移的組件。總會有一些系統組件是沒必要遷移到新平臺上，但是為了將宕機的可能性和復雜性降到***可能又有必要遷移過去。

舉例來說，Windows系統狀態信息可能需要適合的工具從一個硬件平臺遷移到另一個硬件平臺。如果這種信息可以被遷移過去，那么新服務器配置的復雜性就能被大大降低，至少從Windows系統和軟件的角度來說是這樣的。

#p#

設定期望值

用戶都希望實現無宕機的遷移。但是不幸的事實是這種零宕機的夢想在真實的遷移世界中通常是不可能的。即使在實施物理遷移時沒有出現可見的宕機（比如在Exchange或者Notes中遷移電子郵箱），你仍然需要給你的員工一些喘息的空間來應對意料之外的突發狀況。遷移系統狀態信息和二進位，認真規劃和在遷移之前提前做好每一件事情能讓宕機的可能性降到***。不過消除所有主要硬件遷移過程當中的宕機只是種期許，可能很難實現。

設定合理的宕機數量，確保從IT員工到用戶每一個人都知道什么時候可能發生宕機，宕機的時間會持續多久。如果這種宕機無法被用戶所接受，要解釋清楚為什么必須這么做的原因以及一意孤行給系統可能導致的災難性后果。

#p#

獲得你需要的工具

遷移經常會由于不了解細則導致意外的結果。一個例子：許多從本地物理機遷移到虛擬機的工具需要數據在遷移過程中保持靜止的狀態（僅供數據庫管理員處理使用）。對于SQL或者諸如此類的服務器，這就意味著數據庫在遷移過程中必須保證離線狀態，因為在此過程中會面臨數據丟失的主要風險。物理機向虛擬機遷移的工具還是一種從物理服務器到虛擬機的單向遷移。這是對操作的一種限制。如果你的遷移只是從物理機到虛擬機是可行的，如果你試圖向另一臺物理機遷移就是沒有幫助的。如果在遷移后才發現這個問題也是于事無補的，應用軟件在新的環境中就無法達到你預期的狀態。

按照你的需求選擇工具庫--典型的做法是本地工具和第三方工具相結合，這樣能確保你可以安全的執行遷移，按照計劃實施。將這五個提示結合使用，可以確保不會遺漏掉那一點，你可以在實施遷移時以最小限度的宕機遷移到新平臺上。

【編輯推薦】

1. 什么促使刀片服務器走向滅亡？
2. 《魔獸世界:大災變》服務器能否給點力啊？
3. 你了解機房該監控些什么嗎？