仮想環境におけるバックアップとビジネス継続性の確保 EMC ジャパン株式会社テクニカル コンサルティング本部プロダクト ソリューションズ統括部テクノロジー コンサルタント田中宏幸 2010 年 8 月 3 日 1 アジェンダ ミッションクリティカルな仮想環境の登場 仮想化の現状と方向性 ビジネス継続性の確保の重要性 VMware 環境のバックアップ バックアップ 困ってませんか? VMware 環境にまつわるバックアップの課題 EMC ならではのバックアップ方式のご紹介 サーバに負荷をかけない ストレージベースのバックアップ サーバにもネットワークにもやさしい 重複除外技術 VMware 環境における災害対策 災害対策の考え方 EMC ストレージによる災害対策 SRM との連携 まとめ 2
アプリケーション お試し から 本番業務 へ仮想化の導入パターン 仮想化の進展 仮想マシンが標準に 仮想マシンの移動性の向上 まずは仮想 というポリシー 仮想マシン数 ヘビーユース ミッション クリティカル 災害対策 仮想環境のバックアップ 性能 /QoS 仮想マシンの移動 仮想デスクトップ パイロット PoC テスト 開発 Time ライトユース ミッション クリティカルでないサーバ 時間 3 仮想化環境のインフラストラクチャに求められる要件 Tier1 ミッション クリティカルなアプリケーション Tier2 ビジネス クリティカルなアプリケーション Tier3 ビジネスをサポートする インフラストラクチャ要件 非常に高い可用性 サービス レベルの管理 サーバ / ストレージの管理 インフラストラクチャ要件 高可用性 レプリケーション ( ローカル / リモート ) ストレージ リソースの管理 インフラストラクチャ要件 基本的なストレージ接続 テープによるバックアップとリカバリ 4
VMware 環境のバックアップ 5 バックアップ処理時間の増加とリソース負荷 従来の方式では 物理サーバ配下のリソースは物理サーバが任意にコントロール出来た Storage Data APP OS バックアップシステム 占有の I/O 経路 占有の H/W リソース LAN 仮想化環境では リソースが共有されており競合が発生する VMFS Storage Data Data APP OS APP OS ESX APP OS APP OS バックアップシステム 共有のI/O 経路 共有のH/Wリソース データ容量の増加 VMFS Data Data LAN 課題 従来の方法ではバックアップが難しい バックアップ時間の延長 リソース負荷の増加 6
仮想化のバックアップとリカバリに関する課題 仮想化は IT の考え方を変えた バックアップはより高度な統合と価値を提供するために発展する必要がある 従来の考え方 物理環境 : 全般的にサーバ使用率が低く バックアップに大量の帯域幅が利用可能 新しい考え方 仮想環境 : 全般的にサーバ使用率が高く バックアップ用の帯域幅は少ない 100% 100% CPU 使用率 80% 60% 40% 20% 0% サーバ A サーバ B サーバ C CPU 使用率 80% 60% 40% 20% 0% 仮想サーバ A ESX Server ハードウェア共有物理リソース 仮想サーバ B 仮想サーバ C リソースの 20% の使用率 リソースの 80% の使用率 7 バックアップの基本的な考え 業務サーバや業務ネットワークのリソースを使わない もしくは最小化する VMware 社の VCB や vstorage API for Data Protection も方向性は同じ 8
EMC の 2 大バックアップ手法 1. ストレージ機能を用いたバックアップ バックアップに伴なう負荷を ストレージにオフロードする 2. 重複除外技術を用いたバックアップ サーバやネットワークにかかる負荷を最小化する 9 EMC の 2 大バックアップ手法 1. ストレージ機能を用いたバックアップ バックアップに伴なう負荷を ストレージにオフロードする 2. 重複除外技術を用いたバックアップ サーバやネットワークにかかる負荷を最小化する 10
超高速なストレージのバックアップ リストア リカバリリソース クローン / BCV リストア時間 ( 弊社検証結果より想定 ) 数分 ディスク 数十分 ~ テープ 数時間 時間 100GB 程度のデータをリストアする時間 11 ストレージベースのバックアップ手順 DB ストレージ 1 DB 3 業務サーバ Read/ Write 本番 Clone バックアップサーバ 本番ボリュームと Clone ボリュームを同期させる 本番 Clone Clone ボリュームを本番ボリュームから切り離す 同期 2 切り離し 4 DB DB 静止点確保 本番 Clone アプリケーション側で静止点を確保する 本番 マウント バックアップサーバから Cloneボリュームをマウントする Clone Cloneボリュームのデータをバックアップする 課題 ストレージ レプリケーション機能とアプリケーションの制御を連動させたい 12
ストレージベースのバックアップ手順 ~ESX なら ~ 1 3 ストレージ 業務サーバ Read/ Write 本番 同期 Clone バックアップサーバ 本番ボリュームと Clone ボリュームを同期させる 2 本番 Clone 切り離し Clone ボリュームを本番ボリュームから切り離す 4 静止点確保 本番 Clone 同じファイルシステムを利用している仮想マシンすべてについて静止点を確保する 本番 マウント バックアップサーバから Cloneボリュームをマウントする Clone Cloneボリュームのデータをバックアップする 課題 ストレージ レプリケーション機能と VMware 側の制御を連動させたい 13 ストレージ機能を用いたバックアップ ストレージの超高速なレプリケーション機能と vsphere の機能を連携し 自動化します ストレージの複製機能 + 14
アプリケーションとバックアップ処理の連携 各々の仮想マシンの静止点を保証しながら バックアップ運用の一元管理と自 動化を実現する Replication Manager 仮想マシン Replication Manager Replication Manager ESX サーバ CLARiX Production Snap View SnapView アプリケーションとストレージを連携し バックアップ運用の負担を軽減 スクリプト作成は不要 ストレージレベルのバックアップ ( クローン ) は サーバに負荷を与えない レプリカは LUN 単位 リストアはLUNもしくは仮想ディスク単位 Replica 15 アプリケーションとバックアップ処理の連携 1 操作 管理 GUI Console RM Client RM Server RM Client 2 レプリカ指示 3 マウント指示 ( 業務サーバ ) ( マウントホスト ) Replica 1 STD Establish Fracture Replica 2 Replica 3 BCV Replica 4 16
VMware 環境向けの RM 利用例 制御 Windows 業務 ESX マウント ESX RM Server 10VMs / ESX RM Proxy vcenter 仮想ディスク チャレンジ 多数の仮想マシン /Windows ゲストの起動ボリュームの ストレージベースのレプリケーション実施 日々の処理の自動化 結果 RM ですべてのレプリカを一元管理 レプリケーションジョブの自動化 ESX の snapshot 機能と ストレージのスナップショット機能の自動連携 17 EMC の 2 大バックアップ手法 1. ストレージ機能を用いたバックアップ バックアップに伴なう負荷を ストレージにオフロードする 2. 重複除外技術を用いたバックアップ サーバやネットワークにかかる負荷を最小化する 18
重複除外技術を用いたバックアップ 重複除外技術により劇的にデータ量を削減します 19 重複除外技術を用いたバックアップ 重複除外技術により劇的にデータ量を削減する Avamar 日々のバックアップデータ量を最大 1/500 に縮小 日々のバックアップ所要時間を最大 1/10 に短縮 バックアップの保存容量を最大 1/50 に縮小 簡単に設定できるレプリケーション ライセンス 0 Avamar バックアップ元でデータを削減し バックアップ時間を短縮 クライアント ( バックアップ元 ) 同士のデータも削減し 更にバックアップ容量を縮小 クライアントのライセンスは不要 vstorage API 対応 バックアップ元で重複除外 重複除外バックアップシステム クライアント間のデータも重複除外 最大 1/500 に縮小 20
Avamar の重複除外が機能する仕組み 最初のインスタンス 重複するインスタンス 変更されたインスタンス 2009 年 3 月 2009 年 3 月 2009 年 4 月 A B A B E B C D C D C D 固有のデータ セグメントのみをバックアップ A B C D データはバックアップ済みであるため 固有の ID ポインタのみを保存 (20 バイト ) E 新規データ セグメントを識別してバックアップ A B C D E ディスク上に保存された固有のデータは 即時のリカバリが可能 21 従来のバックアップソフトとの違い 従来のバックアップソフト Avamar 凡例 フル 週末など : 定期フルバックアップ 平日 : ファイルレベルの差分バックアップ リストア : フルと差分のセットを組み合わせて復旧 ( 煩雑な作業 ) 初回 : フルバックアップを取得するが 圧縮と重複除外処理でデータ量を圧縮 2 回目以降 : 毎日合成的にフルバックアップを行うが 差分ブロックのみデータ保管 リストア :Avamar が必要なブロックを再結合して データを復元 ( ワンクリック リストア ) Day 1 Backup 99.x% のデータ削減 Avamar のバックアップイメージ 400GB( 全体 ) 10MB/sec で約 11 時間 Day 2 2GB 10MB/sec で約 3 分 Day 3 2GB 10MB/sec で約 3 分 Day 4 800MB 10MB/secで約 70 秒 Month 200MB 10MB/secで約 18 秒 22
従来のバックアップ vs Avamar 従来のバックアップ CPU Network Disk Traditional vs Avamar Avamar 従来型のバックアップでは Guest マシンのリソースを占有してしまいます 特にフルバックアップ実行の際は長時間のリソースの占有が発生します それに対して Avamar は短時間でバックアップジョブが完了するため大幅に消費されるリソースを削減することが可能です 100GBのGuestマシンが計 12 台動作するESXサーバに対して Avamarのバックアップ所要時間は3~12 分で完了 ( 弊社内検証環境での結果 ) 23 Avamar 重複除外の効果 データ タイプ プライマリ データの量 毎日送信されるデータの量 毎日の重複除外比率 Windows ファイル システム 3,573 GB 6.1 GB 99.8% Windows Linux UNIX の各ファイル システムが混在 5,097 GB 11.7 GB 99.7% NAS ファイラのエンジニアリング ファイル (NDMP バックアップ ) 3,265 GB 24.2 GB 99.3% 20% のデータベースと 80% のファイル システムが混在 (Windows および UNIX) 9,583 GB 80.0 GB 99.2% Linux のファイル システムとデータベースが混在 7,831 GB 104.2 GB 98.7% 出典 :EMC 24
Avamar が VMware 環境に適している理由 EMC の重複除外技術により かなりのデータ量の削減とリソースの節減が期待できます VMware ESXサーバストレージデータ ネットワーク負荷最小 ESX サーバの負荷減少 Avamar 重複除外 Avamar バックアップサーバ データ Avamar 重複除外 バックアップ データ Avamar 重複除外 バックアップストレージ節減 25 Avamar クライアント バックアップ ソリューション VMware ゲスト OS バックアップ データ保護のための vstorage API = Avamar ソフトウェア エージェント Avamar サーバ 仮想マシン リソースプール VMware 仮想化レイヤー 一元的な Data Mover Avamar エージェントのある vstorage API プロキシ サーバ x86 アーキテクチャ 物理サーバ = Avamar ソフトウェア エージェント Avamar クライアント ソフトウェアは各仮想マシンで直接実行 ストレージ Avamar クライアント ソフトウェアは VCB プロキシ サーバで実行される 26
ここまでのまとめ 1. ストレージ機能を用いたバックアップ 業務サーバ ネットワークに負荷をかけない 超高速かつ自動化されたバックアップ リストア LUN 単位のバックアップ LUN もしくは VM 単位のリストア 2. 重複除外技術を用いたバックアップ 業務サーバ ネットワークの負荷を最小化 超軽量バックアップ VM 単位 ファイル単位のバックアップ リストア vstorage API との互換性 27 VMware 環境の災害対策 28
災害対策を検討する要素 システムの災害対策を検討する為には 以下の要因のバランスを考えて災害対策範囲や手法を検討する必要があります サービスレベル RPO( データ損失の許容量 ) RTO( リカバリ時間の許容量 ) RGO( 距離 / 想定する災害レベル ) パフォーマンス要件 保護の対象 対象システムの範囲 優先度 総データ量 I/O プロファイル コスト イニシャルコスト (IT) ランニングコスト (IT) 文書化 教育 訓練コスト 29 想定する災害の規模に応じた設計 影響範囲 ( 距離 ) 自然災害 地震 台風 集中豪雨 人為災害 テロ 大規模停電 広域火災 ウィルス感染 長距離災害対策 ( 非同期型 ) 施設障害 ビル停電 空調障害 近距離災害対策 ( 同期型 ) 筐体障害 機器故障 Kernel Panic / Blue Screen 頻度 30
想定する災害の規模に応じた設計 影響範囲 ( 距離 ) 自然災害 地震 台風 集中豪雨 人為災害 テロ 大規模停電 広域火災 ウィルス感染 外部保管リモート レプリケーション 長距離災害対策 ( 非同期型 ) 施設障害 ビル停電 空調障害 筐体障害 機器故障 設備 装置の多重化 Kernel Panic / バックアップ Blue Screen 近距離災害対策ローカル レプリケーション ( 同期型 ) 頻度 31 リモートサイトの構成は? 本番システムと同一を用意して 常に同期できれば. LAN 課金システム会計システム 本番サイト 顧客管理システム 請求システム 商品管理システム Clients 在庫管理システムリモートサイトへの書込みによるパフォーマンス低下 システム追加の際に必ず倍に発生するシステム投資 WAN Gateway Primary Storage リモートサイト Remote Storage Gateway 請求システム 転送に伴う回線費用の圧迫ハードウェア制限により距離的制限 商品管理システム在庫管理システム 顧客管理システム 課金システム 会計システム Clients LAN 32
PtoV による災害対策コスト削減 大規模メールシステムの例 SMTP Gateway LAN Email Archive Server Exchange Back-End Server Clusters Exchange Clients Exchange Front-End Servers Exchange Public Folders リモートサイト Remote Storage Gateway WAN Gateway Primary Storage 本番サイト SMTP Gateway Exchange Front- End Servers Email Archive Server Exchange Back-End Server Clusters Exchange Public Folders VMWare LAN VMWare Exchange Clients 33 ストレージベースでの DR( 物理 vs 仮想 ) 物理環境 OS 領域を複製しない場合は 個別に OS を用意し パッチあて等のメンテも必要 OS OS OS 領域を複製するには Boot が大前提 DATA DATA 本番環境と同じ HW Source Site Target Site 仮想環境 ゲスト OS ゲスト OS DATA DATA ゲスト OS は 共有ストレージ上 本番と同じ HW である必要はない 34
EMC が提供するビジネス機能性のフレームワーク情報保護サービEMC のレプリケーション製品 SRDF ファミリー (Symmetrix) 究極の事業継続 災害対策ソリューションで 様々な用途に利用できます Celerra Replicator (NAS) LAN/WAN の利用帯域を最適化し QoS に対応した IP ベースのレプリケーション FS/LUN Snaps LAN FS/LUN Snaps MirrorView (CLARiX) 同期 非同期に対応した柔軟なレプリケーション ソリューション RecoverPoint ( 異機種混在 ) ネットワークベースの continuous data protection (CDP), continuous remote replication (CRR), concurrent local and remote (CLR) データプロテクション 1 4 2 3 HARDWARE SOFTWARE Virtualization layer Intel architecture Production ESX Servers Windows Replica of Windows Linux Replica of Linux HARDWARE SOFTWARE Virtualization layer Intel architecture Backup Server 35 層ス型ンレプリMirrorView/A 代替案 設計 テクノロジー階CLARiX MirrorView/S Copy ( 数十分 ~) プランニング サービス レベルとビジネス要件 許容可能なデータ消失 0 秒 数秒 ~ 数分 数時間 24 時間以上 アプリケーションの可用性 数分 数分 数時間 24 時間以上 業務の中断 非常に少ない 少ない 標準 多い RecoverPoint CRR (Continuous remote replication) Symmetrix SRDF/S SRDF/A SRDF/AR SRDF/DM ケーショの可用性Celerra (NAS) Celerra Replicator SRM との連携 Yes 36
VMware vcenter Site Recovery Manager との連携 Storage Symmetrix: SRDF CLARiX: MirrorView Celerra: Replicator VMware Site Recovery Manager と EMC レプリケーション技術の連携により 災害時のフェイルオーバ動作を自動化 RecoverPoint WAN Symmetrix: SRDF CLARiX: MirrorView Celerra: Replicator RecoverPoint Storage 37 VMware vcenter Site Recovery Manager との連携 手動での管理作業 VMware ESX ESX Server 11. ローカル VM を復旧 3. 仮想マシンを shutdown 4. 複製停止 ( キャプチャされたジャーナル ) 5. 最新の snapshot を選択 6. リモート側 ESX に 複製イメージへのアクセス許可 RecoverPoint WAN 7. 新しい Disk をスキャン 8. VM の登録 9. VM の電源 ON RecoverPoint VMware ESX ESX Server (disaster recovery) 10. フェイルバック 1. VM が利用している LUN と Consistency Group 2. レプリカ LUN 38
SRM がある場合の VM のフェイルオーバー VMware ESX 仮想マシン shutdown 複製停止 ( キャプチャされたジャーナル ) 最新の snapshot を選択 リモート側 ESX に 複製イメージへのアクセス許可 新しい Disk をスキャン VM の登録 VM の電源 ON * ユーザが failback を指示 データの複製の方向を逆転 同期 ローカル VM を復旧 VMware ESX ESX Server RecoverPoint WAN RecoverPoint ESX Server (disaster recovery) 1. VM が利用している LUN と Consistency Group 2. レプリカ LUN 39 まとめ ミッションクリティカルな仮想環境の登場 物理環境 仮想環境にかかわらず ミッションクリティカルな要件が発生する 相応のビジネス継続性が求められる VMwareのバックアップの考え方 業務サーバに負荷をかけない ストレージベースのバックアップ 業務サーバにもネットワークにもやさしい 重複除外技術 VMware 環境における災害対策 RPO/RTOの要件に合わせた 製品 技術の選定 SRM との組み合わせによる自動化 40