觀點

許你一個無痛遷徙

2009 / 06 / 25
Deni Connor 譯 夏客
許你一個無痛遷徙

把資料在儲存陣列,或儲存層設備間搬移的這個冗長無趣的過程,現在慢慢地朝向自動化邁進了。

  
由於資料儲存量以每年新增50%的速度不斷地往上攀升、儲存技術無止境地翻新更替、伺服器和儲存設備的強化,以及資料分類分級的關係,驅使資料從某個儲存層移往另個儲存層,或者從某個儲存陣列搬遷至他處。甚至,我們可以說資料遷徙已是儲存管理師的生活表徵亦不為過!

  遷徙的完美境界,指的是你會使用自動化工具進行資料搬遷。然而,在現實當中,資料的搬遷仍是得借助手動才能完成:管理師將系統離線,把資料備份到磁帶上,接著安裝新的儲存陣列,並且把資料倒到它該有的位置。複雜一點的資料遷徙可能需要執行至50個,甚至更多的步驟,而這些工作又往往會佔用到夜晚,或者是在週末來進行。倘若以企業營運一天24小時,每年365天計算,這樣讓系統停擺下來的時間,似乎又顯得太長了!
  
  「機器停擺著實勞民傷財,每小時約耗損3萬元。當然實際上不會大到這個數目字,只是,若能不使NetApp儲存設備停止服務,或計畫只停機數小時的時間,這些對公司都是有利的。」Oversee.net位於洛杉磯的分部Oversee Domain Services,其技術部門的副總Stephen R. O''Neill接著又說,「我手下的工程師毋需大半夜還要醒過來作業,為得只是減輕因系統維護所帶來的影響。」

  不過,你會認為像資料遷徙這種枯燥乏味的日常例行作業,應該很容易吧?事實上,根據紐約一家研究機構TheInfoPro的調查指出,資料遷徙所引發的問題,通常會是用戶等待服務過久,或者受到無預警的服務停擺,另外,有些則是技術相容性議題,資料損毀以及裝置效能不彰,甚至是出現資料遺失等情況。進行資料遷徙的主要因素通常不外乎儲存設備的租約到期,或者是更換新系統。而資料遷徙的後遺症愈形嚴重,乃是出自資料從儲存陣列搬移,或從檔案系統中遷出至另一個儲存裝置上,均屬異質性裝置,再者,缺乏有效率、具自動化軟體也是原因之一。

  考慮以下這個情境:Peter Fitch在明尼蘇達州的Bloomington市半導體公司Rudolph Technologies擔任資訊基礎架構經理。2年多前,他將公司的資料從Dell的PowerVault儲存陣列,轉移到Compellent Technologies的SAN儲存中心上。「回顧當時,過去採用的是老舊的磁帶備份方式。」他接著說,「我們必須作磁帶備份,並且在後續想用的儲存層上,先建好一個新的儲存空間,接著才將資料回存,及重建所有共用的部份。但是,時間因素會是個考量點,因為如果資料量大一點的話600GB,或者1TB,那麼我們就必須多花整個週末的時間進行資料遷徙,另外,除了只能利用下班時間外,並且還耽誤到IT同事的週末假期。」

  有了Compellent的Data Progression Module(DPM)系統後,Fitch的遷徙作業變得容易許多,只要依搬移政策進行資料遷徙即可。「我們就是讓它自己執行。」,他接著說,「公司裡甚至沒人知道資料正在搬移!」Fitch說,99.95%的資料會被DPM搬遷到第三儲存層,而第一儲存層則會保留下來,為重要裝置作更新重整之用,例如boot-from-SAN或者是線上資料庫。

  有了Compellent的Thin Import功能,Fitch就毋需撰寫程式,或藉助任何的備份軟硬體,來搬移資料。「你可以使用Robocopy程式擬好搬移步驟,或者安裝試用版的磁帶備份軟體。」他繼續說,「但我們只要把NetApp檔案儲存器插上連在Compellent SAN的光纖通道(Fibre Channel)上,畫面就會顯示找到外接的硬體裝置,接下來,就是搬移資料的工作而已了。」(Robocopy為Windows Server 2008的內建程式,是複製資料夾的命令列工具。)

制訂遷徙計畫

  不管何種資料遷徙,其目的皆為將資料從儲存媒體當中搬往另一個儲存設備,而遷徙計畫所要顧及到的,就是確保資料遷徙是成功的。這裡頭要考慮到的變因,包含了:資料遷徙要花多久的時間?請規範出服務暫停(如果有的話)的時間長短;從儲存技術的不相容性、資料庫停擺時間及遷徙後效能降低等層面,評估影響營運的風險。而一份完整的遷徙計畫,也必須訂出是那些資料要進行遷徙?它要遷往何處?和如何搬遷?

  Oversee Domain Services的O''Neill是利用F5 Networks的Acopia ARX Series交換器,完成了資料遷徙。「我是得力於Acopia ARX交換器的幫助,才完成了資料遷徙,以volume-to-volume或者是array-to-array的遷徙為代表。不過,通常我管理資料都是採用鏡像層次(volume level)。」O''Neill接著說,「舉例來說,如果我有4~5台的檔案儲存設備,而想要把存放在上面的眾多資訊移往其他不同的檔案裝置,或者當我進行系統維護時,要將資料從原有檔案儲存裝置中移出;此時,我便會將其他的檔案儲存裝置接上Acopia交換器,並且使用內建在FreedomFabric Network OS裡的政策引擎來挪動資料。」

依環境挑選工具

  資料移動方式涵蓋了3種廣義類別:主機型(host-based)軟體、陣列式(array-based)資料遷徙,以及網路型設備(network appliance)。

  主機型軟體是最常被用來搬移資料的方式。這是進行特定程式資料遷徙的最佳選擇,像是從Microsoft Exchange 2003升級到Microsoft Exchange 2007的作業平台,資料庫的複製與簡單的檔案拷貝。另外,主機型軟體,比方說Symantec的Veritas Volume Manager或者是Brocade Communications Systems的StorageX能允許自儲存陣列搬移,同時這樣也使得在異質儲存設備之間的資料遷徙更為容易;此外,相形之下,它較其他小範圍的遷徙工具顯得經濟得多。不過,當面臨到眾多系統要進行資料遷徙時,可能就會是件苦差事。其他主機型遷徙軟體的例子,尚有可在z/OS、UNIX、Linux和Windows環境當中執行的IBM-Softek Transparent Data Migration Facility及Quest Software-Windows版的StorageConsolidator,和Symantec-Veritas Volume Replicator。以上所有這些套件,都可以拿來進行鏡像和檔案複製,以及資料區塊的搬遷。

  陣列式資料遷徙軟體主要是用在同質性的儲存裝置上,並降低電腦主機營運上所遭受到的影響。通常,使用者極可能選用陣列式軟體,在廠商各代的產品之間進行資料遷徙。這類的產品,包含了像是EMC的Symmetrix Remote Data Facility,IBM的Peer-to-Peer Remote Copy和Compellent的Storage Center Thin Import capability。

  不過,陣列式軟體的範疇最近被打破了。Hitachi的Data System現在為其TagmaStore儲存陣列,提供了一種控制器虛擬化(controller-based virtualization)產品,支援在Hitachi和非Hitachi陣列之間進行資料遷徙;而EMC則為其自家產品Symmetrix,提供了Open Replicator。

  第3種型態的資料遷徙工具是網路型設備,像是F5 Networks的Acopia ARX Series交換器、Brocade的File Management Engine或者是Sanrad的V-Switch。這些設備可依其組態設定,進行鏡像、檔案及資料區塊的搬移。比方說,Acopia ARX Series交換器可以在NAS裝置和檔案伺服器之間,搬遷檔案類型(file-oriented)的資料,而Sanrad的V-Switch則是搬遷區塊(block-oriented)資料。

  有了網路型設備,藉由集中並平衡各檔案裝置間的資料遷移負載,搬移效能將會得到改善。Oversee Domain Service的O''Neill接著補充,「倘若因為韌體升級,而要將檔案儲存裝置退出運作,我能夠將資料從裡頭遷出,並將該裝置抽離Acopia主幹,接下來進行韌體升級,好了之後再將該裝置加回去,最後把資料搬入即可,所以完全不會有任何阻礙。」他說。

遷徙政策細思量

  請針對資料遷徙這事考慮再三:遷徙是否在同質性陣列間進行呢?還是異質性陣列?或者是分屬在不同的儲存層之中?資料遷徙若是在單一儲存層之間,像是從主要光纖(FC)硬碟搬往另一顆,通常會發生在單一廠商使用同質性儲存媒體上,或者是多個不同廠商採行異質性儲存設備。

  Barry Thomas在肯塔基州Bowling Green市的Graves-Gilbert Clinic公司擔任網路管理師一職,而就在今年1月,該公司資料將遷徙到Compellent SAN儲存網路上。Thomas必須使用最複雜的方式,在不同的儲存裝置上進行資料搬遷。
 
  Thomas要從EMC儲存陣列、Nexsan Technologies儲存陣列,以及現行伺服器上,將資料遷到他之前所購買的Compellent SAN儲存網路中。「我們先前並沒有許多資料遷徙的經驗,只有過度耗用儲存設備來處理這件事,不過,代價太過昂貴了。我們的幾次經驗是,必須先將系統關閉,把資料從一個儲存方案轉移到另一個,接著再把系統啟用。

  Thomas說,目前Graves-Gilbert Clinic公司擁有3組EMC Clariion CX300儲存陣列,一台Nexsan SATAboy儲存設備,再加上內部現行的儲存伺服器。「我們擬定給予暫存伺服器原有的存放空間大小,同樣地也會新增一個新的Compellent空間,接下來,我們會利用Thin Import功能,將舊有空間裡的資料,拷貝至新建立的空間當中。若是我給予伺服器100Gig的空間,卻只用掉80Gig存放資料,那麼,在新的儲存陣列裡,我真正只會消耗掉80Gig的儲存容量。」他說。

  「有一次我們使用了script自動化這整件事;那一天裡,我為伺服器備好了新的儲存空間,並且執行了script來關閉所有服務,再把資料從中拷貝到其他空間;直至最後,script主動寄信通知我工作全部完成了。」Thomas接著說,「接下來,我加入更改了容量標籤(volume label),情況看來似乎還不賴。」

  緬因州Bangor市St. Joseph Healthcare醫院資訊技術處主管兼任CIO的Eric Nelson,他在異質裝置之間,使用了硬體裝置的系統完成資料遷徙。該院擁有140台伺服器,8台虛擬主機伺服器,以及94台虛擬主機;一台Sanrad V-Switch叢集掌管了14TB的資料,另外,有28TB的資料存放在一台HP的StorageWorks Enterprise Virtual Array(EVA)機器上,EMC Symmetix設備中則有15TB的資料。為免2個醫院網站都遇到"avoid vendor lock-in"(譯注*)情況,而成為SAN儲存設備的孤兒,Nelson使用了Sanrad V-Switch設備,將EMC儲存陣列中的資料遷徙到HP StorageWorks EVA設備上。

  「不過,由於它們是相異的SAN儲存網路,所以我無法在它們之間互相複製資料。」Nelson接著說,「廠商給我的唯一選擇,就是再購買一台同廠牌的SAN設備,然後他們會幫忙我設好複製的組態。不過,這實在是太花錢了!」

  依據Nelson的說法,「Sanrad能夠在不同的系統當中,作非同步的資料複製,我們從EMC Symmetrix當中,整整移了13TB的資料到HP EVA 8100裝置上。只不過,資料遷徙會因為所使用系統的不同,而有所差異,我們利用VMware工具來搬移虛擬機器;另外,我們對於內部的檔案伺服器也還尚有議題未解決,所以針對這些資料遷徙,我們使用了備份和還原的作業方式。同時之間,我們亦建立了4套不同的Microsoft叢集系統,我們將其離線停止服務,備份好資料後再將其還原到新的系統上。」

分層儲存下的遷徙

  分層儲存(tiered storage)是驅策資料遷徙的最大推手之一。此外,依據最近一份由Storage雜誌所作成的調查報告指出,受訪讀者對於分層儲存的資料遷徙策略,近一半受訪者表示有做分層儲存:其中有分類到4層,甚至是更多層以上的佔21%,再者,大約有46%分到了3層,33%分作2層。在所有調查裡面,34%的受訪者表示,31%~50%的資料是存放在第1層儲存層當中。不過,不令人意外地,有40%的人信賴以手動的方式在儲存層當中搬移資料,近20%的人會用自動化的方法進行,剩餘的受訪者則是兩者並用。
 
  Rudolph Technologies的Fitch則按步就班地,在多儲存層當中執行資料遷徙作業。(詳見「老舊資料非分層儲存的唯一考量點」) 「我們有2個不同的儲存層:Fibre Channel磁碟和Serial ATA磁碟。」Fitch接著說,「就是儲存中心的Compellent Data Progression Module,讓我們可以相當自動化地在第1儲存層和第3儲存層之間搬移資料,而不致造成任何資料缺損。」

  Fitch僅針對多少天之內未使用的資料,設定警示訊息。「不常使用之圖檔,會自動地被移往第3儲存層。只有經常被存取的檔案,會保留在最大、最昂貴的Fibre Channel磁碟裡面。」他說。

  資料遷徙是我們得面對的生活現實,而為這般無趣的過程進行自動化而言,這努力是值得的。使用者或許已經發現,主機型軟體作為特定程式的資料遷徙是一個最佳解,比方說像是資料庫的複製。它不再限制住儲存陣列的處理方式,而是可以更加容易地用於異質儲存設備之間的資料遷徙上。

  陣列型設備的資料遷徙,像是為Compellent Technologies用戶所採納的那種方式,也已經變得相當地受歡迎,另外,有多數的使用者則是使用EMC的symmetrix Remote Data Facility設備,在EMC儲存陣列間搬動資料。但是,不少使用者也仍舊信賴他們所選擇的資料搬移工具,可以將資料從這兒遷到那兒,或者可以在儲存層間搬移。在儲存陣列間作陣列型資料遷徙是一個受歡迎的選擇,這不只是求技術進步的緣故,同時它也是為了在異質設備間作資料遷徙而存在。而最末,我們知道網路型設備則是提供了額外的遷徙彈性,在異質裝置之間,容許進行鏡像和檔案複製,以及資料區塊的搬遷。

資料遷徙查核清單

不少遷徙專案,都是因欠缺良好的規劃,而導致作業時間過長或造成無預警的服務停擺。所以,若事先就能釐清步驟,將有助於資料遷徙作業順利進行。

行前規劃

. 確認與遷徙作業相關的人員:請儲存管理師,資料庫管理師,軟體程式
 經理和資安官,針對資料遷徙一事,彙整其建議和目標。
. 確認會因遷徙作業而受影響的範圍,包含:應用程式、系統功能、伺服
 主機以及儲存設備。
.找出將進行遷徙的資料。
. 訂出明確時間,包含:遷徙作業何時進行?要花多長的時間?以及在必
 要情況之下,系統需要暫停服務多久?
.為遷徙作業裝置上頭的原始資料進行備份。
. 記錄包含在遷徙過程當中,有關來源端與目的端儲存陣列的組態設定
 檔。
. 使用script作資料遷徙前,再三檢視這些script程式的可靠性與精確度。
. 記錄作業系統上相關之權限,以及目錄結構和資料共享權限。
. 記錄來源端與目的端裝置的LUN號碼和空間容量。

實際操演


.執行資料遷徙演練。
.檢視系統組態設定檔上的所有改變。
. 檢視來源端與目的端裝置的LUN號碼和空間容量資訊。
.測試回復程序,或者是替代方案程序。

事後檢驗


. 確認遷徙後結果:檢查資料的完整性,以及是否發生資料毀損。
. 驗證遷徙後結果:測試網路存取作業是否正常?檔案權限是否正常?目
 錄結構和應用程式運作是否正常?
. 檢視遷徙專案進行中所發生之議題,於下回作業時可作為修正或改進之
 參考依據。

老舊資料非分層儲存的唯一考量點

  在各儲存層之間搬移資料,不是像看到的那麼簡單。不少使用者遷徙資料是基於資料老化,以及非使用狀態的時間長短。然而,以下還是有些其他方面的準則,是我們在進行遷徙之前所要考慮到的。
  醫療與病患的資訊:要搬移此種形態的資料,得視病患的年齡而定。倘若資料是關於幼兒的,那麼,該筆資料在長達21年內都應該可被存取得到;如果病患是成人,則資料就必須依各州不同的法令,因病患生命的長短而決定被存取的時間,部份州政府甚至要求,在成人病患死亡後,其醫療資料仍必須保留住一段時間。再者,維護這種形態的資訊,有時是為了因應重大醫療災害事件的需要,所以,第一儲存層最好是能存放當前及最近接受過治療的病患,而第二儲存層則存放不常看病之病患的資料。
  智慧財產權:這裡又再次提到了,這類資料不應以資料老化的程度來作為儲存點的選擇。許多的使用者都是在第一儲存層,存放貼近其企業核心的智慧財產權資料,為的就是能夠更快速取得的關係。
  其他電子化資訊:這類的資料,乃是由人事記錄或任何其他與公司相關聯的訴訟資訊所構成的,通常都會被存放在第一、第二或第三儲存層的設備當中。倘若資料與訴訟官司是相關聯的,則該筆資料就必須能快速地被存取和搜尋到,所以就需要以適當的方式分層儲放,以達到快速存取的目的。在某些情況底下,會要求某些存放在磁帶上的第三儲存層資料,要回存至第二或第一磁碟儲存層。而許多的電子郵件軟體,同樣也支援電子郵件的分層儲存和資料遷徙。


Deni Connor於德克薩斯州Austin市的IT研究公司Storage Strategies Now擔任主要分析師一職。

(譯注*) avoid vendor lock-in:就經濟學上而言,vendor lock-in,等同於proprietary lock-in,或customer lock-in之意。也就是客戶必須一直依賴某廠商的產品和服務,若不付出實質的轉換成本,就無法換用其他廠商的產品和服務。