<4D F736F F F696E74202D2089BC917A8AC28BAB82C982A882AF82E9836F E C C835882CC8C7091B190AB82CC8A6D95DB5F F E542E D>

(1)

仮想環境におけるバックアップと

ビジネス継続性の確保

2010年8月3日

EMCジャパン株式会社

テクニカル・コンサルティング本部

プロダクト・ソリューションズ統括部

テクノロジー・コンサルタント

田中宏幸

アジェンダ

• ミッションクリティカルな仮想環境の登場

–

仮想化の現状と方向性

–

ビジネス継続性の確保の重要性

• VMware環境のバックアップ

–

バックアップ、困ってませんか？

• VMware 環境にまつわるバックアップの課題

–

EMCならではのバックアップ方式のご紹介

• サーバに負荷をかけない、ストレージベースのバックアップ

• サーバにもネットワークにもやさしい、重複除外技術

(2)

仮想化の導入パターン

Time

仮想化の進展

仮想マシンが標準に

y

仮想マシンの移動性

の向上

y

「まずは仮想」という

ポリシー

ヘビーユース

y

ミッション・クリティカル

y

災害対策

y

仮想環境のバックアップ

y

性能/QoS

y

仮想マシンの移動

y

仮想デスクトップ

ライトユース

y

ミッション・クリティカルでないサーバ

パイロット

y

PoC

y

テスト・開発

時間

仮想マシン数

仮想化環境のインフラストラクチャに

求められる要件

インフラストラクチャ要件

y

高可用性

y

レプリケーション（ローカル/リモート）

y

ストレージ・リソースの管理

インフラストラクチャ要件

y

非常に高い可用性

y

サービス・レベルの管理

y

サーバ/ストレージの管理

Tier1

ミッション・クリティカルな

アプリケーション

Tier2

ビジネス・クリティカルな

アプリケーション

インフラストラクチャ要件

y

基本的なストレージ接続

y

テープによるバックアップと

リカバリ

Tier3

ビジネスをサポートする

アプリケーション

「

お

試し

」

か

ら「

本番業務」

へ

(3)

VMware環境の

バックアップ

バックアップ処理時間の増加とリソース負荷

• 占有の

I/O経路

• 占有の

H/Wリソース

OS APP

LAN

SAN

Storage

Data

従来の方式では、物理サーバ配下のリソースは物理サーバが任意にコントロール出来た

バックアップ

システム

ESX

OS APP OS APP OS APP OS APP

Data

仮想化環境では、リソースが共有されており競合が発生する

y

共有の

I/O経路

y

共有の

H/Wリソース

Storage

バックアップ

(4)

仮想化のバックアップとリカバリに関する課題

仮想化は

_{ITの考え方を変えた…バックアップはより高度な統合と価値を}

提供するために発展する必要がある

仮想

サーバ

A

仮想

サーバ

B

仮想

サーバ

C

従来の考え方

物理環境：全般的にサーバ使用率が低く、

バックアップに大量の帯域幅が利用可能

新しい考え方

仮想環境：全般的にサーバ使用率が高く、

バックアップ用の帯域幅は少ない

リソースの

20%の使用率

リソースの

80%の使用率

100%

80%

40%

0%

60%

20%

CPU

使用率

100%

80%

40%

0%

60%

20%

CPU

使用率

サーバA

サーバB

サーバC

ESX Server

ハードウェア

共有物理リソース

バックアップの基本的な考え

• VMware 社の VCB や vStorage API for Data Protection も方向性は同じ

業務サーバや業務ネットワークのリソースを使わない、

もしくは最小化する

(5)

EMCの2大バックアップ手法

1. ストレージ機能を用いたバックアップ

y

バックアップに伴なう負荷を、ストレージにオフロードする

2. 重複除外技術を用いたバックアップ

y

サーバやネットワークにかかる負荷を最小化する

EMCの2大バックアップ手法

1. ストレージ機能を用いたバックアップ

y

バックアップに伴なう負荷を、ストレージにオフロードする

2. 重複除外技術を用いたバックアップ

y

サーバやネットワークにかかる負荷を最小化する

(6)

超高速なストレージのバックアップ・リストア

クローン

/ BCV

ディスク

テープ

時間

数分

数時間

リストア時間（弊社検証結果より想定）

リカバリリソース

•100GB程度のデータをリストアする時間

数十分～

ストレージベースのバックアップ手順

Clone

本番

DB

マウント

• バックアップサーバから

Cloneボリュームをマウ

ントする

• Cloneボリュームのデー

タをバックアップする

④

Clone

本番

DB

切り離し

• Cloneボリュームを本番

ボリュームから切り離す

③

本番

Clone

DB

同期

業務サーバ

バックアップサーバ

ストレージ

• 本番ボリュームとClone

ボリュームを同期させる

①

Read/

Write

y ストレージ・レプリケーション機能とアプリケーションの制御を連動させたい

課題

Clone

本番

DB

静止点

確保

• アプリケーション側で静

止点を確保する

②

(7)

ストレージベースのバックアップ手順

～

_ESXなら～

y ストレージ・レプリケーション機能とVMware側の制御を連動させたい

課題

本番

切り離し

• Cloneボリュームを本番

ボリュームから切り離す

③

Clone

本番

同期

業務サーバ

ストレージ

• 本番ボリュームと

Clone

ボリュームを同期させる

Read/

Write

バックアップサーバ

Clone

①

静止点

確保

• 同じファイルシステムを

利用している

仮想マシン

すべて

について静止点

を確保する

②

本番

Clone

マウント

• バックアップサーバから

Cloneボリュームをマウ

ントする

• Cloneボリュームのデー

タをバックアップする

④

本番

Clone

ストレージ機能を用いたバックアップ

• ストレージの超高速なレプリケーション機能と、

vSphereの機能を連携し、自動化します

ストレージの複製機能

＋

(8)

アプリケーションとバックアップ処理の連携

各々の仮想マシンの静止点を保証しながら、バックアップ運用の一元管理と自

動化を実現する

「

Replication Manager」

SnapView

CLARiX

Replica Snap View Production

Replication

Manager

ESXサーバ

仮想マシン

y

アプリケーションとストレージを連携し、バックアップ

運用の負担を軽減

y

スクリプト作成は不要

y

ストレージレベルのバックアップ（クローン）は、

サーバに負荷を与えない

y

レプリカは

LUN 単位。リストアはLUNもしくは仮想

ディスク単位

Replication Manager

アプリケーションとバックアップ処理の連携

GUI Console

（マウントホスト）

BCV

③

マウント指示

②

レプリカ指示

（業務サーバ）

Replica 1

Replica 2

Replica 3

Replica 4

STD

RM Client

①操作・管理

RM Server

RM Client

Establish

Fracture

(9)

VMware環境向けのRM利用例

業務ESX

マウントESX

制御Windows

10VMs / ESX

RM Server

RM Proxy

_vCenter

●チャレンジ

多数の仮想マシン/Windowsゲスト

の起動ボリュームの、ストレージ

ベースのレプリケーション実施。

日々の処理の自動化

● 結果

RMですべてのレプリカを一元管理。

レプリケーションジョブの自動化。

ESXの snapshot 機能と、ストレー

ジのスナップショット機能の自動連

携

● チャレンジ

多数の仮想マシン/Windowsゲスト

の起動ボリュームの、ストレージ

ベースのレプリケーション実施。

日々の処理の自動化

● 結果

RMですべてのレプリカを一元管理。

レプリケーションジョブの自動化。

ESXの snapshot 機能と、ストレー

ジのスナップショット機能の自動連

携

仮想ディスク

EMCの2大バックアップ手法

1. ストレージ機能を用いたバックアップ

y

バックアップに伴なう負荷を、ストレージにオフロードする

2. 重複除外技術を用いたバックアップ

y

サーバやネットワークにかかる負荷を最小化する

(10)

重複除外技術を用いたバックアップ

• 重複除外技術により劇的にデータ量を削減します

重複除外技術を用いたバックアップ

重複除外技術により劇的にデータ量を削減する

「

Avamar」

日々のバックアップ

データ量を最大

1/500

に縮小

日々のバックアップ

所要時間を最大

1/10

に短縮

バックアップの

保存容量を最大

1/50

に縮小

y

バックアップ元でデータを削減し、バックアップ時間を短縮

y

クライアント（バックアップ元）同士のデータも削減し、更にバックアップ容量を縮小

y

クライアントのライセンスは不要

y

vStorage API 対応

簡単に設定できる

レプリケーション

ライセンス ¥0

重複除外バックアップシステム

バックアップ元で重複除外

クライアント間のデータも重複除外

最大

1/500に縮小

Avamar

(11)

Avamarの重複除外が機能する仕組み

固有のデータ・セ

グメントのみを

バックアップ

データはバックアップ済みで

あるため、固有の

IDポインタ

のみを保存（

20バイト）

n

最初のインスタンス

o

重複するインスタンス

p

変更されたインスタンス

2009年3月

2009年4月

ディスク上に保存された固有のデータは、即時のリカバリが可能

A

B

C

D

A

B

C

D

A

B

C

D

E

A

B

C

D

E

B

C

D

E

新規データ・セ

グメントを識別

してバックアップ

従来のバックアップソフトとの違い

フル

Avamar

従来のバックアップソフト

y

週末など：定期フルバックアップ

y

平日：ファイルレベルの差分バックアップ

y

リストア：フルと差分のセットを組み合わせて復旧

（煩雑な作業）

y

初回：フルバックアップを取得するが、圧縮と

重複除外処理でデータ量を圧縮

y

2回目以降：毎日合成的にフルバックアップを

行うが、差分ブロックのみデータ保管

y

リストア：Avamarが必要なブロックを再結合して、

データを復元（ワンクリック・リストア）

凡例

(12)

従来のバックアップ

vs Avamar

• 従来型のバックアップでは

Guestマシン

のリソースを占有してしまいます。特に

フルバックアップ実行の際は長時間のリ

ソースの占有が発生します。

• それに対して、Avamarは短時間でバッ

クアップジョブが完了するため大幅に消

費されるリソースを削減することが可能

です。

• 100GBのGuestマシンが計12台動作す

る

ESXサーバに対して、Avamarのバック

アップ所要時間は

３～１２分

で完了

–

（弊社内検証環境での結果）

CPU

Network

Disk

Traditional – vs – Avamar

従来のバックアップ

Avamar

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

(13)

AvamarがVMware環境に適している理由

Avamar

重複除外

Avamar

重複除外

Avamar

重複除外

バックアップ

VMware

ESXサーバ

バックアップ

サーバ

EMCの重複除外技術により、かなりのデータ量の削減と

リソースの節減が期待できます。

データ

ストレージ

ネットワーク負荷最小

ESXサーバの

負荷減少

バックアップストレージ

節減

Avamar

Avamarクライアント・バックアップ・ソリューション

VMwareゲストOSバックアップ

データ保護のためのvStorage API

仮想マシン

Avamarエー

ジェントのある

vStorage API

プロキシ・サー

バ

Avamar

サーバ

一元的な

Data Mover

= Avamarソフトウェア・エージェント

リソース

プール

VMware仮想化レイヤー

(14)

ここまでのまとめ

1. ストレージ機能を用いたバックアップ

y

業務サーバ・ネットワークに負荷をかけない

y

超高速かつ自動化されたバックアップ・リストア

y

LUN単位のバックアップ、LUNもしくはVM単位のリストア

2. 重複除外技術を用いたバックアップ

y

業務サーバ・ネットワークの負荷を最小化。超軽量バックアップ

y

VM単位、ファイル単位のバックアップ・リストア

y

vStorage API との互換性

VMware環境の

災害対策

(15)

災害対策を検討する要素

サービスレベル

•RPO

（データ損失の許容量）

•RTO

（リカバリ時間の許容量）

•RGO

（距離／想定する災害レベル）

•パフォーマンス要件

保護の対象

•対象システムの範囲・優先度

•総データ量

•I/Oプロファイル

コスト

•イニシャルコスト(IT)

•ランニングコスト(IT)

•文書化、教育、訓練コスト

• システムの

災害対策を検討する為には、以下の要因のバランスを考えて災害対策

範囲や手法を検討する必要があります。

想定する災害の規模に応じた設計

長距離災害対策

（非同期型）

影響範囲

（距離）

自然災害

•地震

•台風

•集中豪雨

人為災害

•テロ

•大規模停電

•広域火災

•ウィルス感染

施設障害

•ビル停電

筐体障害

(16)

想定する災害の規模に応じた設計

長距離災害対策

（非同期型）

近距離災害対策

（同期型）

頻度

影響範囲

（距離）

自然災害

•地震

•台風

•集中豪雨

人為災害

•テロ

•大規模停電

•広域火災

•ウィルス感

染

施設障害

•ビル停電

•空調障害

筐体障害

•機器故障

•Kernel Panic /

Blue Screen

設備・装置の多重化

バックアップ

ローカル・レプリケーション

外部保管

リモート・レプリケーション

リモートサイトの構成は？

Clients

顧客管理システム

商品管理システム

在庫管理システム

会計システム

請求システム

課金システム

Gateway

SAN

LAN

本番システムと同一を用意して、常に同期できれば

….

Primary

SAN Storage

Remote

SAN Storage

リモートサイト

本番サイト

WAN

Clients

顧客管理システム

課金システム

会計システム

商品管理システム

在庫管理システム

LAN

請求システム

転送に伴う回線費用の圧迫

ハードウェア制限により距離的制限

リモートサイトへの書込みによるパフォーマンス低下

システム追加の際に必ず倍に発生するシステム投資

SAN

(17)

PtoVによる災害対策コスト削減

Exchange

Clients

Exchange Back-End

Server Clusters

Exchange Front-End

Servers

SMTP

Gateway

Exchange Public

Folders

Email Archive

Server

Gateway

SAN

LAN

大規模メールシステムの例

Primary

SAN Storage

Remote

SAN Storage

リモートサイト

本番サイト

WAN

SMTP

Gateway

Exchange

Front-End Servers

Exchange Back-End

Server Clusters

Exchange

Clients

SAN

Email Archive

Server

Exchange Public

Folders

LAN

VMWare

ストレージベースでの

_{DR（物理vs仮想）}

Source Site

Target Site

OS

OS領域を複製しない場合は、

個別に

OSを用意し、パッチあて等のメンテも必要

物理環境

本番環境と同じ

HW

OS領域を複製するには、

SAN Bootが大前提

OS

DATA

仮想環境

(18)

EMCのレプリケーション製品

SRDF ファミリー (Symmetrix)

究極の事業継続・災害対策ソリューションで、様々な用途に利用

できます

MirrorView (CLARiX)

同期・非同期に対応した柔軟なレプリケーション・ソリューション

4 3 2 1

Celerra Replicator (NAS)

LAN/WANの利用帯域を最適化し、QoSに対応した IPベースのレプ

リケーション

LAN FS/LUN Snaps FS/LUN Snaps

RecoverPoint (異機種混在）

ネットワークベースの、continuous data protection (CDP),

continuous remote replication (CRR), concurrent local and remote

(CLR) データプロテクション

Intel architectureSOF Virtualization layer

TWARE HARDWAR E Windows Replica of Windows Linux Replica of Linux Backup Server Intel architecture Virtualization layer SOF TWARE HARDWAR E

Production ESX Servers

EMCが提供するビジネス機能性のフレームワーク

情報保

護

サ

ー

ビ

ス

プランニング

サービス・レベルとビジネス要件

許容可能なデータ消失

0秒

数秒～数分

数時間

24時間以上

アプリケーションの可用性

数分

数時間

24時間以上

業務の中断

非常に少ない

少ない

標準

多い

代替案、設計、テクノロジー

階層

型

の

可用

性

レ

プ

リ

ケ

ー

シ

ョ

ン

Symmetrix

SRDF/S

SRDF/A

SRDF/AR

SRDF/DM

CLARiX

MirrorView/S

MirrorView/A

(数十分～）

SAN Copy

RecoverPoint

CRR （Continuous remote replication)

Celerra （NAS）

Celerra Replicator

(19)

VMware vCenter Site Recovery Managerとの連携

WAN

Symmetrix:

SRDF

CLARiX:

MirrorView

RecoverPoint

Symmetrix:

SRDF

RecoverPoint

VMware Site Recovery ManagerとEMCレプリ

ケーション技術の連携により、災害時のフェ

イルオーバ動作を自動化

Storage

Celerra:

Replicator

CLARiX:

MirrorView

Celerra:

Replicator

VMware vCenter Site Recovery Managerとの連携

VMware ESX

WAN

SAN

ESX Server

SAN

3. 仮想マシンを

shutdown

4. 複製停止 (キャプチャされたジャーナル)

5. 6. リモート側ESXに、複製イメージへのアクセス許可

7. 新しいDiskをスキャン

8. VM

の登録

9. VMの電源ON

11. ローカルVMを復旧

RecoverPoint

ESX Server

(disaster recovery)

手動での管理作業

VMware ESX

(20)

SRMがある場合のVMのフェイルオーバー

• 仮想マシンshutdown

• 複製停止 (キャプチャされたジャーナル)

•

• リモート側ESXに、複製イメージへのアクセス許可

• 新しいDiskをスキャン

• VMの登録

• VMの電源ON

*

ユーザがfailbackを指示

• データの複製の方向を逆転、同期

• ローカルVMを復旧

WAN

SAN

ESX Server

SAN

RecoverPoint

2. レプリカ

LUN

1. VMが利用しているLUNと、

Consistency Group

ESX Server

(disaster recovery)

VMware ESX

まとめ

• ミッションクリティカルな仮想環境の登場

–

物理環境・仮想環境にかかわらず、ミッションクリティカルな要件が発生

する

–

相応のビジネス継続性が求められる

• VMwareのバックアップの考え方

–

業務サーバに負荷をかけない、ストレージベースのバックアップ

<4D F736F F F696E74202D2089BC917A8AC28BAB82C982A882AF82E9836F E C C835882CC8C7091B190AB82CC8A6D95DB5F F E542E D>

仮想環境におけるバックアップと

ビジネス継続性の確保

2010年8月3日

EMCジャパン株式会社

テクニカル・コンサルティング本部

プロダクト・ソリューションズ統括部

テクノロジー・コンサルタント

田中 宏幸

アジェンダ

•

ミッションクリティカルな仮想環境の登場

–

仮想化の現状と方向性

–

ビジネス継続性の確保の重要性

•

VMware環境のバックアップ

–

バックアップ、困ってませんか？

•

VMware 環境にまつわるバックアップの課題

–

EMCならではのバックアップ方式のご紹介

•

サーバに負荷をかけない、ストレージベースのバックアップ

•

サーバにもネットワークにもやさしい、重複除外技術

仮想化の導入パターン

Time

仮想化の進展

仮想マシンが標準に

y

仮想マシンの移動性

の向上

y

「まずは仮想」という

ポリシー

ヘビーユース

y

ミッション・クリティカル

y

災害対策

y

仮想環境のバックアップ

y

性能/QoS

y

仮想マシンの移動

y

仮想デスクトップ

ライトユース

y

ミッション・クリティカルでないサーバ

パイロット

y

PoC

y

テスト・開発

時間

仮想マシン数

仮想化環境のインフラストラクチャに

求められる要件

インフラストラクチャ要件

y

高可用性

y

レプリケーション（ローカル/リモート）

y

ストレージ・リソースの管理

インフラストラクチャ要件

y

非常に高い可用性

y

サービス・レベルの管理

y

サーバ/ストレージの管理

Tier1

ミッション・クリティカルな

アプリケーション

田中宏幸

_{ITの考え方を変えた…バックアップはより高度な統合と価値を}