話說..去年一整年(2014)都在乾坤大挪移..
Data 在不同的storage之間搬來搬去.
要如何減少service downtime. 一直是能不能得到service owner 允許搬家的關鍵
不同的系統有不同的data量..如果是TB等級的data要從某個storage搬到另一台storage.
這時候還傻傻的用OS level copy, 八成需要半天以上的downtime.
更不用說可以得到user的停機許可
所以一些中高階($_$)storage功能就派的上用場拉
以NetApp來說..全系列都有支援Snapmirror..當然要有license ($_$)
原本Snapmirror是被NetApp定義用來作DR..可以在遠端保留一份一樣的資料
最短的RPO可以到5 mins.
不過在我的經驗中..則是完全被利用來data大搬家.
說穿了 snapmirror 不過就是snapshot copy
都是先在原來volume作snapshot
然後再把這時間點的snapshot copy到另一部NetApp.
snapshot copy期間, 原本的volume不受影響可以繼續讀寫..寫入就直接寫到新的空間
直到snapshot copy完成..新寫入的data合併snapshot
如果data大搬家就是 snapmirror每隔5分鐘做一次snapshot, copy 到新地方
等到最後一刻..server關機..同步最後一份snapshot..切換到新的NetApp..server開機
動作快的話15mins搞定..就算10TB data 系統只要停機15mins即可完成搬家
當然這之前有許多準備動作要做..也有許多需要注意的技巧..
沒注意到 有可能就是DR目的還沒達到..反而變成另一個incident..
1.保留足夠空間.
記得在原來的aggrgate多保留一倍空間給volume.
因為volume的snapmirror有可能會斷..斷掉的話, snapshot 會持續重傳..
如果這時候持續有新data寫入..就會佔用volume之外aggregate的空間
如果aggregate滿了..或是volume可使用disk size上限到了..這時snapshot還是傳不完
這時候netapp就會把volume offline保護...incident就來拉
又不然某次user把某個volume當backup pool.
跑backup的時候寫入就多..snapshot長的就很快..就爆了
所以記得多保留一點空間給snapshot volume
2.多一點頻寬
snapshot copy需要不少頻寬..尤其是第一次full volume copy.
如果頻寬太少.可能第一次full volume copy就要花上幾天.
這時候也只能多用一點aggregate空間先撐住 snapshot吧
當然如果data 一直持續寫入..寫入量比mirror 頻寬高..
那還是乖乖加頻寬吧
3.早一點開始
如果snapshot是要用來作netapp之間的data搬家.
資料量越大.最好是越早開始做snapmirror
讓netapp至少先花一個禮拜同步data.
不然最後要切換的時間到了 data還沒同步完就糗了
4.精神好的時候再動手設定
data很重要, 所以會動用到snapmirror 貴森森的功能.
設定說複雜 不算複雜..不過如果眼花. source 跟 destination看錯..
或是蓋到不該蓋的volume..
這可不是網路斷線.修好就行..
5.多個volumes不要同時initial snapmirror
initial snapmirror就是啟動第一次full volume snapshot copy.
這時候時間花最長.之後第二次.第三次.才會慢慢加快.直到跟上data變動量
如果這次同時N個volumes啟動initial snapmirror.
多個volume大家搶頻寬.同時作full volume snapshot copy.
就得確保你的aggregate有足夠空間讓所有volumes 新資料寫入才行
說了那麼多..重點就是小心.小心.再小心.
storage, database管理與一般network device管理最大不同
network 斷線, 連的回來就好,
database 不小心砍到data, 說不定還有機會從log救回來
storage 蓋到不該蓋的data... 只能從backup回來
而且很不幸的 data backup在怎麼做都有一定的RPO..
怎麼救都會有一定時間的data lost.
就算丟了一分鐘的finance data 大家也都會捲鋪蓋
所以拉...轉network好像比較好玩哩..:P
No comments:
Post a Comment