幾年前，數(shù)據(jù)中心最常見的遷移類型可能是操作系統(tǒng)的升級，通常情況下，操作系統(tǒng)的升級是伴隨服務器硬件或應用程序升級同步發(fā)生的，在此期間，生產(chǎn)數(shù)據(jù)將不可避免要從一個地方轉移到另一個地方。
隨著數(shù)據(jù)爆炸式增長和服務器虛擬化技術的普及，今天我們看到的更多是存儲系統(tǒng)的升級，與操作系統(tǒng)是否升級無關，虛擬化物理服務器或提供更多存儲空間已成為當務之急。
有人說數(shù)據(jù)遷移不就是從A點轉移到B點嗎?應該很簡單，如果你有這種想法就錯了，在IT領域，真正的麻煩在于細節(jié)。數(shù)據(jù)遷移的成敗關鍵在于最終需要的停機時間，應盡最大努力確保停機時間最小化，并確保遷移期間不出現(xiàn)突發(fā)問題，下面我將介紹幾種最常見的數(shù)據(jù)遷移情景，以及存在的陷阱。
從一種存儲類型遷移到另一種存儲類型時，首先需要正確了解源和目標存儲，你對它們的了解程度可能會最終左右你使用的數(shù)據(jù)遷移策略，面臨的風險，以及所需的時間。
DAS到SAN遷移
最簡單，最常見的存儲遷移形式可能要數(shù)從物理服務器本地，直接附加存儲遷移到SAN存儲，假設你有一臺部門文件服務器，本地磁盤空間已經(jīng)快用光，為了滿足用戶的存儲需求，你購買了一個新的SAN存儲，于是想將用戶的數(shù)據(jù)轉移到它上面，但必須不惜一切代價，避免不必要的停機時間。
第一步是將物理服務器連接到SAN，不管你使用的是FC SAN還是iSCSI SAN，都需要給服務器添加SAN存儲連接設備，如果是FC SAN，就需要FC HBA(主機總線適配器)，如果是iSCSI SAN，用雙端口千兆以太網(wǎng)網(wǎng)卡就行了，完成HBA或網(wǎng)卡的安裝不應該超過1小時，同時，你最好在這個時間范圍內(nèi)將需要的軟件也一并安裝好，避免以后再停機或重啟服務器。
配置好SAN后，在你的服務器上裝載新的數(shù)據(jù)卷，并格式化，完成后，你的服務器上就擁有一個全新的空卷了，這時你可以預遷移數(shù)據(jù)副本，很多人在這一步會犯錯，總是試圖將所有數(shù)據(jù)全部移走，其實完全沒必要這樣做，不僅風險很大，數(shù)據(jù)遷移所需時間往往比你預計的要長得多，特別是遷移包含大量小文件的文件服務器，相反，你應該使用robocopy(Windows)或rsync(Linux，Windows)等數(shù)據(jù)卷鏡像工具。
如果配置得當，這些工具允許你將生產(chǎn)服務器上的數(shù)據(jù)同步到SAN，包括非常重要的安全描述符，因此不需要生產(chǎn)磁盤卷脫機，通過幾天的連續(xù)同步，非生產(chǎn)SAN存儲上的數(shù)據(jù)就和生產(chǎn)服務器上的文件完全同步了，這樣就不需要中斷生產(chǎn)系統(tǒng)，如果你要遷移的是數(shù)據(jù)庫服務器，雖然不可能執(zhí)行增量復制，但你可以通過復制測試確定遷移需要的時間，從而做好停機規(guī)劃。
為了減少遷移時間，需確保沒有用戶打開或鎖定共享服務器上的文件，如果是Windows Server操作系統(tǒng)，可以停止“Windows Netlogon”和“Server”服務，這樣用戶就無法訪問服務器上的共享文件了，微軟的Process Explorer或Linux下的lsof可以檢查是否有進程鎖定你需要復制的文件，在Windows服務器上，WMI服務通常是罪魁禍首。
當你確定源存儲卷上沒有文件被打開后，就可以開始做同步操作了，遇到復制失敗錯誤時，應仔細閱讀錯誤消息，因為某些系統(tǒng)文件是無法移動的，重點應放在用戶數(shù)據(jù)上。
數(shù)據(jù)完全鏡像后，最簡單的辦法就是交換盤符或掛載點，當然，你也可以修改共享設置和應用程序設置，如殺毒軟件的排除選項，指向新的驅動器，最省時的辦法還是交換掛載點，如果你的本地數(shù)據(jù)卷使用的是D:，先將本地卷的驅動器號移除，然后將其分配給SAN卷，完成后，重啟服務器，再啟動需要的服務，用戶就可以訪問和使用新的SAN卷了。
SAN到SAN遷移
從一個SAN向另一個SAN遷移大批量數(shù)據(jù)的方法很多，基本上和NAS到SAN的遷移方法一樣，但也存在一些差異，動手之前，有必要先了解一下。
在SAN到SAN的遷移中，我經(jīng)常遇到不同SAN廠商的多路徑模塊不兼容問題，例如，如果你在EMC Clariion和惠普EVA陣列之間遷移數(shù)據(jù)，EMC PowerPath DSM和EVA multipathing DSM是互不兼容的，我曾親歷過這種問題，當我同時安裝了這兩個DSM嘗試管理對方的存儲路徑后，服務器居然啟動不了。
為了避免這種問題，將新存儲連接到服務器時最好不要使用多路徑，如果源和目標SAN都是FC SAN，當你想執(zhí)行臨時數(shù)據(jù)同步時，present單一路徑到新SAN。當你將生產(chǎn)服務器停機，準備正式遷移時，最好卸載舊的SAN的多路徑DSM，并unpresent掉舊存儲。
重啟后，安裝新的DSM并present其余路徑到新存儲，這個過程會因重啟服務器使停機時間變長，因此在評估時應將其考慮進去。事實上，如果你已經(jīng)有在同步的數(shù)據(jù)，花在調整軟件上的時間也許比真正移動數(shù)據(jù)所需的時間還長。
從SAN到SAN遷移數(shù)據(jù)時需要考慮的另一個問題是，有些SAN和多協(xié)議SAN橋支持在存儲網(wǎng)絡內(nèi)直接執(zhí)行塊級數(shù)據(jù)遷移，這些功能往往需要購買昂貴的許可，因此，只有當你要移動海量數(shù)據(jù)時才有必要這么做，它的確能節(jié)省很多時間，但有一點我需要強調的是，不管廠商聲稱它有多穩(wěn)定，在遷移生產(chǎn)數(shù)據(jù)前，都應該反復測試。
服務器和存儲虛擬化
如果你已經(jīng)實現(xiàn)了服務器或存儲虛擬化，從一個設備遷移到另一個設備這種任務就很簡單了，例如，如果你運行著VMware的vSphere Enterprise或Enterprise Plus版，你可以使用Storage Vmotion移動整個虛擬機，并且無需關閉虛擬機，所有需求是虛擬主機可以同時看到和使用源和目標存儲介質，一般來說，這并不難做到。
如果你已經(jīng)擁有良好的存儲虛擬化架構，你應該知道可以將整個SAN卷從一個SAN轉移到另一個SAN，服務器是感覺不到這種變化的，實際上，許多大型企業(yè)早已提前實現(xiàn)了存儲虛擬化，在這種環(huán)境中，要執(zhí)行存儲遷移是再簡單不過的事情了。
總結
不管你要做什么類型的存儲遷移，最重要的事情是確保你始終有一個可輕松執(zhí)行的回退計劃，這個最好不要偷懶或存在僥幸心理，如果你對新存儲平臺做了全面測試，任何可能遇到的問題都應該心中有數(shù)，確保正式遷移時不會手足無措。
京公網(wǎng)安備 11010502049343號