|
NetApp資料保護及異地備援系統
台灣位處環太平洋地震帶上，地震發生頻繁；近年又有颱風及土石流肆虐，是天然災害頻仍的地區。然而，災難發生的地點並非人為所能控制，因此不管是企業、銀行、醫院或是政府機關的資料隨時隨地面臨威脅。因此，『資料保護』及『異地備援』等相關機制因應而生，以期當資料不幸被摧毀、服務停止或中斷時，能夠讓資料快速回復及服務快速啟動，進而讓損失達到最低。
何謂資料保護
『資料保護』最基本的用意，不外乎是保證資料的正確性及可用性，將其簡述如下：
- 正確性：資料遺失、應用程式發生錯誤造成資料毀損或是病毒感染等，都會造成資料內容錯誤，可以使用以往的備份資料來恢復；當然，備份方式包括了磁帶備份，或是熱門很久的快照技術。
- 可用性：當災難發生時，可利用資料備份將檔案恢復；或是將既往的資料進行備份，以符合資安法規。
然而，隨著時間不斷往前推移，新的資料不斷增加，舊的資料又須留存，資料量只會不斷成長，這意味著備份時間將會越來越長。本來資料庫備份可能只需數分鐘或是數十分鐘，但因日積月累的關係，資料庫可能會增加到需要三小時、四小時或是數天才能備份完成，此時，則須重新檢視傳統的備份技術是否能夠符合現今環境。
資料保護方式
由於資料是組織的重要命脈，因此NetApp提供下列資料保護功能，以避免因天然災害或是人為因素等原因，所造成的資料損失，並期能達到快速備份。
|
資料保護功能
|
敘述
|
|
Snapshot
|
無視空間容量大小，僅需數秒即可快速完成快照備份，並可利用手動或是排程的方式建立專屬的備份策略，亦可搭配撰寫Script的方式，驅動儲存設備自發性的建立Snapshot。
|
|
SnapRestore
|
當需要從回復大量資料時，可利用此SnapRestore的快速回復功能，不會因為容量或是資料量多寡，造成回復的時間冗長。
|
|
SnapMirror(異地備援使用)
|
利用同步或是排程的方式，將資料傳送至異地端的儲存設備，利用Snapshot的專利技術，僅傳輸資料有異動的部分，所以，SnapMirror所需的傳輸時間，遠較其他儲存設備來的短暫。
|
|
SnapVault(異地備份使用)
|
當Production NetApp Storage或是將OS上所需要的資料，”備份”到異地端的NetApp Storage。
|
|
SyncMirror
(active/active configuration required)
|
其實就是Raid_DP+1或是Raid_4+1；當資料寫進儲存設備時，此時儲存設備會同時寫兩份到兩邊的硬碟群組(Pool)。當其中一個Pool完全的損壞時，不會影響線上的資料或是服務；當損壞的Pool被修復時，儲存設備會自動的同步最新的資料，在同步的過程中，完全不會影響線上的資料或是服務。
|
|
MetroCluster
|
NetApp的備援方案，結合了儲存設備的高可用性(High Availability)及異地備援(Disaster Recovery)方案，當儲存設備無預警毀壞時，自動啟動備援機制，而不影響線上資料或是服務。
|
異地備援
資料保護對每個組織而言，是一項持續性的挑戰，更是現今各資訊中心所面臨的重要議題，因此NetApp針對異地備援提供了SnapMirror與MetroCluster兩種架構，避免資料毀損時所造成的損失，並能快速回復既有的服務與資料，以下說明這兩種架構的備援方式及應用。
SnapMirror
SnapMirror提供手動、時間排程與同步三種模式，供使用者依據不同的應用而自行設定。此模式是在正式使用環境(以下簡稱Production Site)與異地備援環境(以下簡稱DR Site)各自建立一套NetApp儲存設備。
一般的日常存取等運作都是由Production Site的儲存設備提供服務，當Production Site遭受災難進而導致線上服務停擺時，此時就由管理者手動將主控權切換至DR Site，讓DR Site的儲存設備接手繼續提供服務。當Production Site的環境及設備修復後，僅需先將DR Site災難發生後的異動資料同步回Production Site，再把服務切換到Production Site，即恢復至災難發生前的運作模式，在此過程中，所有的線上服務幾乎是不中斷的，可以說是沒有受到影響的。
MetroCluster：
MetroCluster可說是SnapMirror的進階版，上述當災難發生時，SnapMirror異地備援架構是透過手動的方式，將主控權切換到異地備援端的設備，但MetroCluster則是透過自動偵測的方式，由DR Site自動接手。
MetroCluster是由Cluster與Sync_Mirror所組成的，以下針對Cluster與Sync_Mirror詳細說明。
Cluster
NetApp採用的是雙主動式叢集故障自動接管方案（Active-Active Cluster Failover），平常是兩台各自獨立服務工作的主機，各有各的volume、IP位址，當其中有一台故障時，另一台主機會立刻接手那一台尚未完成的交易、volume和IP位址，使服務不會中斷，即為高可用性(High Availability)架構。
NetApp MetroCluster故障自動接管方案
上述的NetApp的Cluster高可用性(High Availability)架構，提供下列優點：
- 容錯性(Fault tolerance)：
當此架構中的某一儲存設備受損或毀壞時，其鄰近的設備會自動接管，原本的服務會由接管的設備接手，並持續提供服務。
- 升級不中斷：
當某一儲存設備要做升級時，會暫時先由另一儲存設備接管並持續為系統提供服務，待升級完成後，再將服務提供權回歸至原本的儲存設備。
- 維護不中斷：
當儲存設備發生實體機件故障時，可由另一儲存設備接管，待損壞的設備更換完成後，再將服務提供權移回原本的儲存設備。
Sync_Mirror
NetApp Sync_Mirror技術即是為防止多顆硬碟同時故障，所提出的Volume備援方案，通常用於保護極重要的資料的，因為Sync_Mirror是由儲存設備先做Raid4或是Raid_DP之後再做Raid1(Raid4+1或是Raid_DP+1)，應用這項技術可以避免掉DiskProblem，又因Sync_Mirror的其他機制，因此在Sync_Mirror架構下，可以同時避免掉Due Cable、HBA Failure等常見問題。Sync_Mirror工作示意圖如下：
MetroCluster是NetApp最完整的解決方案，透過此架構可防止任何單一設備故障而影響整個系統運作，所謂的單一設備故障，包括主機、網路（網路卡故障或是網路交換器故障）、volume，甚至機房整個毀壞，對於服務的提供，仍不會造成太大的影響。
異地備援即是MetroCluster解決方案的應用，透過Cluster加上Sync_Mirror架構，將儲存設備分別建置在兩個不同的機房，儲存設備會不斷的進行資料同步，因此當任一機房發生「完全性毀滅」時，仍可由另一機房繼續提供服務，因此有下列四個好處：
- 高可用性及區域保護
- 達到資料最低遺失的風險
- 當災難發生時，減少Service DownTime的時間
- 不妨礙使用者端應用程式的存取
雖然上述的MetroCluster架構，可以大大簡便「資料回復」的步驟以及縮短「服務中斷」的時間，但因為光纖種類的關係，又分為下列兩種模式（端視距離的長短）：
一、 Stretch MetroCluster (最長距離500M)，因距離限制的關係，此架構適用於近距離的不同校區或是園區內不同的廠房
二、 Fabric MetroCluster(最長距離100KM)，因距離可以較長，所以此架構適用距離較遠的兩地機房
(作者現任職於麟瑞科技)
|
