存儲容災規(guī)劃及自動化實現(xiàn)

1、存儲容災系統(tǒng)規(guī)劃及自動化建設劉文0. 自我介紹 目前就職于一家銀行科技部門從事存儲和小機的管理工作。 曾經(jīng)在IBM工作三年，主要從事IBM 軟件服務，同時參與過幾個 個存儲災備建設的項目，在存儲管理方面有一些小小的經(jīng)驗希望能跟大家分享一下。 我今天的選題是存儲容災規(guī)劃及自動化實現(xiàn)，關于今天的選題，之前劉啟軍曾講過關于數(shù)據(jù)中心的建設，我今天主要分享一下存儲災備的技術規(guī)劃和實現(xiàn)。主要內(nèi)容 1. 主流中端存儲災備解決方案和技術解讀(兩大類) 2. 存儲災備選型、規(guī)劃考慮，以V7000容災規(guī)劃舉例 3. 存儲災備切換的自動化實現(xiàn)1.1 雙活技術今年的6月11號，AIX china有過一次大型的雙活技術

2、討論，對這一部分的討論非常精彩。雙活技術適用于對于業(yè)務連續(xù)性要求高，RTO時間低的業(yè)務，包括建立在GPFS基礎上數(shù)據(jù)庫層面的IBM GDPC實現(xiàn)方案，ORACLE golden gate，今天主要講存儲級別的容災。 IBM SVC（聯(lián)想有一套大的SVC架構(gòu)）, powerha+hyperswap(對存儲平臺、軟件版本要求較高，國內(nèi)有幾家中小銀行開始采用這種架構(gòu)). EMC vplex（我行正在vnx5500+vmware+vplex環(huán)境中測試，目前反響還不錯 ，但由于要保證存儲的性能，對vplex和鏈路租賃的投入會比較大，主要問題：1.第三站點的問題實現(xiàn)自動切換，否則需要vplex的單點不能解

3、決。2. 一致性組的規(guī)劃。） 華為vis Netapp metrocluster. 雙活技術對于交換機和鏈路質(zhì)量要求比較高雙活技術對于交換機和鏈路質(zhì)量要求比較高1.2 主流存儲級容災技術及比較高端存儲： IBM DS8000高端存儲系列 Metro mirror/global mirror EMC VmaxSRDF/STAR HDS True copy/Universal Replicator中端 EMC vnxMirror viewreplication manager IBM XIV V7000 Metro/global mirror面對種類繁多的存儲產(chǎn)品和容災技術，怎么去建設一個適合自己

4、的容災系統(tǒng)？這是我第二部分想要闡述的內(nèi)容。2.1 結(jié)合容災的存儲選型考慮 1)業(yè)務特點，選擇合適的容災技術并確定具體的實現(xiàn)策略，滿足業(yè)務恢復時相應的RTO、RPO指標(監(jiān)控部門，例如金融行業(yè)，這是硬性需求)。 2)業(yè)務關聯(lián)程度。業(yè)務關聯(lián)緊密，數(shù)據(jù)的藕合程度高，可能會造成所有關聯(lián)的業(yè)務都要采用同一種容災技術，反之，可能會針對不同的業(yè)務要求進行區(qū)分，分別用不同的容災技術。 3)系統(tǒng)現(xiàn)狀，核心業(yè)務系統(tǒng)容災技術必須充分考慮與現(xiàn)有系統(tǒng)的配合。現(xiàn)有核心業(yè)務系統(tǒng)的應用分布、應用的實現(xiàn)方式（對于F5和雙活技術的支持）、硬件設備平臺的種類、存儲數(shù)據(jù)量的大小、IO吞吐量的大小等，都會對容災技術的選擇產(chǎn)生影響 4)

5、技術成熟度，容災系統(tǒng)必須采用成熟可靠的技術，保證系統(tǒng)特續(xù)，穩(wěn)定的運行。該技術應具有類似于電信業(yè)務運營支撐系統(tǒng)容災建設的成功案例，不能由于技術手段的不成熟或不穩(wěn)定而增加核心業(yè)務系統(tǒng)新的風險。 5)容災系統(tǒng)環(huán)境，核心業(yè)務系統(tǒng)容災技術必須考慮生產(chǎn)中心與容災中心之間的距離，網(wǎng)絡環(huán)境等因素，不同的技術對距離，網(wǎng)絡帶寬的要求會有所不同。 6)成本分析，軟硬件投資，鏈路租賃，實施維護成本。2.2 V7000選型參考有點像在打廣告。有點像在打廣告。環(huán)境考慮：環(huán)境考慮： 考慮到服務器的兼容性，服務器操作系統(tǒng)版本5.3 數(shù)據(jù)的擴展，V7000過渡架構(gòu)，滿足以后橫向擴展的需要，可作為一個虛擬化存儲平臺/存儲資源池V

6、7000的特點，它是一款采眾家之長的存儲產(chǎn)品的特點，它是一款采眾家之長的存儲產(chǎn)品 源代碼部分大部分來自于Svc/XIV: 管理界面人性化設計 /DS8000：raid, 自動分層, easy tier GPFS最新成果，active cloud engine技術 文件系統(tǒng)存儲/SVC集群技術，橫向擴展 V7k免費為所有舊存儲增加了快照，精簡配置，透明數(shù)據(jù)遷移等功能容災特性容災特性 Licence 單獨收費 MM支持300KM同步 GM 80ms延遲 舊版4000KM，新版本突破限制 最大支持與三個v7000組成伙伴關系 支持集群內(nèi)-集群間metro-mirror關系 Metro-mirror支

7、持數(shù)據(jù)的增量復制（關系斷開后重新建立不需要重新初始化）限制：限制：兩地三中心/性能限制，列舉DPFv7000性能2.3 某行V7000規(guī)劃設計架構(gòu)1 架構(gòu)：架構(gòu)： MM + flashcopy方式方式 災備驗證方式：災備驗證方式： A. 災備區(qū)驗證（模擬環(huán)境） 生產(chǎn)系統(tǒng)正常運行情況下，暫停MetroMirror存儲復制，使MetroMirror目標卷變?yōu)榭勺x寫，在災備區(qū)服務器上啟動數(shù)據(jù)庫和應用，進行業(yè)務驗證。驗證通過之后，在災備區(qū)停止應用和數(shù)據(jù)庫，釋放存儲，恢復MetroMirror存儲復制。 此種場景下不影響生產(chǎn)系統(tǒng)運行 B. 測試區(qū)驗證（模擬環(huán)境） 生產(chǎn)系統(tǒng)和存儲復制正常運行情況下，重新生

8、成一份新的flashcopy，在測試區(qū)服務器上啟動數(shù)據(jù)庫和應用，進行業(yè)務驗證。 此種場景下不影響生產(chǎn)系統(tǒng)運行，不需中斷存儲復制。 C. 災備切換和回切（真實環(huán)境）2.4 某行V7000規(guī)劃設計架構(gòu)2 A. 我行V7000的應用現(xiàn)狀 兩套V7000, 一套集群，另一套MM架構(gòu) V7000 + SVC組合應用 業(yè)務分層 通過SVC減輕存儲IO壓力，同時管理其它存儲 B. 災備驗證方式 SVC enable disable端口 MM自動化切換2.5 可能遇到的問題 性能問題 容量規(guī)劃考慮，如果采用Global mirror方式，根據(jù)異步原理，如果架構(gòu)GPFS環(huán)境中，避免做restripe等動作，即發(fā)

9、生存儲數(shù)據(jù)的瞬間大副變動，不僅占用大帶寬，同時在由于超過RTOsnapshot空間用滿后，可能導致復制中斷 流程問題，比如災備端卷組可以激活，文件系統(tǒng)無法掛載。由此，我們會想到如果這些操作能夠自動化實現(xiàn)就好了，下面一部分我想闡述存儲災備的自動化建設。3.1 災備切換自動化的必要性根據(jù)剛才的描述，在我們設計了一套復雜的災備環(huán)境之后，怎么發(fā)揮它的價值，更好的使用它。根據(jù)監(jiān)管部門的要求，需要定期對災備系統(tǒng)進行驗證，每個企業(yè)都有自己的災備演練方案，涉及到繁冗復雜的操作。 1. 很多企業(yè)的災備演練方案，都是一大堆的重復工作，演練一般又安排在晚上，運維人員很勞累，面對很多的重復工作很容易出問題。 2. 我

10、們發(fā)現(xiàn)，實際災備演練過程中，很多的錯誤都是人工疏忽造成的 3. 除了雙活，存儲卷復制級別的容災一個很重要的問題就是RTO時間過長，自動化的應急機制可以有效規(guī)避該問題。3.2 自動化工具應用現(xiàn)狀 目前多為自主開發(fā)，IBM(tsa), HP(oo平臺), 某些自動化軟件例如Autoswitch 半自動化工具，例如華為replication director, 通過agent插件來實現(xiàn)主機上操作的自動化 銀行，多為自主開發(fā)，實現(xiàn)級別： 存儲切換自動化（關于存儲這一塊涉及到shell腳本和python的操作和標準化輸出） 服務器卷組/雙機操作的自動化 應用起停自動化3.3 自動化的規(guī)劃設計實現(xiàn)SAN環(huán)

11、境很復雜，不同的存儲容災管理平臺用到的軟件不一樣，比如DS8000 容災管理的tpc-R安裝在windows機器上，Solution enabler可能安裝在一臺AIX主機上。自動化規(guī)劃是一個龐大而復雜的工程。 存儲的集中管理，存儲控制機操作終端的選定（不同的存儲所采用的切換實現(xiàn)方式不同） 流程和場景制定（桌面演練/計劃內(nèi)/計劃外） 原子步驟設定 核心部分：腳本3.4 行內(nèi)災備自動化現(xiàn)狀 四個基本組件：災備指揮平臺、自動化引擎組件OO、服務器自動化組件SA、網(wǎng)絡自動化組件NA 災備指揮平臺界面，后臺通過HP OO流調(diào)度實現(xiàn)。 切換的流程和邏輯在OO平臺定義 SA/NA主機 Python中間件，

12、將命令發(fā)給存儲控制器， 返回日志,判斷日志結(jié)果，是否需要進行一下步操作。3.5 容易出問題的環(huán)節(jié) 流程設計 數(shù)據(jù)的同步方向 重試機制/狀態(tài)異常的處理機制3.6 V7000的自動化切換實現(xiàn) Ssh互信 停應用 切換前檢查 Failover 狀態(tài)判定 Failback 狀態(tài)判定3.7 netapp切換自動化步驟 Quiece/break changeconf resync break changeconf resync release snapdelete3.4 容災切換腳本心得 安全性，腳本風險大，不管是操作系統(tǒng)，還是應用的啟停，很多時候只是啟停失敗。存儲的每一步操作，都可能，比如在更新數(shù)據(jù)時，一旦方向弄反了。像netapp snapmirror, 把源和目標寫反了，都會釀成很嚴重的后果。 智能化，做好每一步狀態(tài)檢查的判斷工作，能自動化處理的則自動化處理，不能自動化處理的則需要人工介入，例如對異常狀態(tài)的