新方式はこれだ！バックアップ見直しの必要性
∼既存方式の問題と限界に挑む最新テクノロジー∼
EMCジャパン・丸紅情報システムズ 共催導入事例でわかる！バックアップ見直しセミナー
プラットフォーム＆ネットワーク事業本部 ストレージネットワーク部 上村 修一Agenda
• 既存バックアップ方式の問題点
• 解決すべき部分
• 重複除外（De-dupe）の有効性
• データ保護の今後
• 将来を見据えたデータ保護用ストレージ
• PCのデータ保護と仮想環境の問題
既存のバックアップ方式をSLAの観点からもう一度洗い直し、
データセンターにおける異機種環境の問題点やDRのコスト問題の解決、
将来の容量の急激な増加に耐えうるバックアップの手法と
必要なテクノロジーに関して解説します。
従来のリカバリとSLA
ドライブ アプリケーション 再起動 正常な 最新イメージ アプリケーション停止時間 リカバリポイント目標（RPO） リカバリタイム目標（RTO） 最新イメージ以降の変更分Restore*
*10TBのリストア ~= ディスクから4時間, テープだと12.5時間 Recover 分析RPO: いかに頻繁にバックアップを取るか
RTO:いかに短時間でリカバリを行いアプリケーションを起動するか（サービス開始）
RTO/RPO
• SLA：
– 高：データロスを最小限（ゼロ）にしたい
• CDP、アプリケーション側でのリプリケーション（DataGuard等） – ログデータをNetwork転送しDR側アプリケーションで吸収 – データ量が増大し回線コスト高→限られたアプリケーション– 中：データロスは最小限にしたいがコストが優先
• １次側でのリカバリを優先し、DRサイトでのリカバリを優先的に行う – 一次側はスナップショット（BCVやストレージでの複製を含む） – 一次側にスタンバイのアプリケーションサーバを持ち サーバの不具合に対処 – DRサイトへはNetwork経由でのバックアップデータ転送– 低：従来のバックアップ手法に基づきデータの保持を最優先とする
• コスト優先 – 週次のフルバックアップ、日次の差分（増分）バックアップ – DRサイトへはメディアを搬送C
O
S
T
S
L
A
RTO/RPO
• SLA： – 高：サービス停止を最小限（ゼロ）にしたい • CDP、アプリケーション側でのリプリケーション（DataGuard等） – ログデータ等のデータを完全に吸収させるには若干の停止を伴う – 中：リストアは最短時間で行いたい • リストアを常時行う（自動リストア）、アーカイブ形式ではなく実行可能な形式で複 製 – DR側はスナップショットのコピーを１次利用可能なストレージに保持 – アプリケーションサーバをDRサイトに保持 – 低：従来のバックアップ手法に基づきデータの保持を最優先とする • コスト優先 – DRサイトにはメディアのみ保持 – データリストア先の確保は未定（兼用または、障害発生後手当）SLAとコスト
【GAPはなぜ起こるのか？】
•
サイト間Networkコスト： 転送量の違い
– SLAの高いものは厳選されており、 ストレージ全体の容量としては少ない – SLAの低いものは容量も多く回線を 大量に消費する – 回線コストは帯域が広いほど割高•
リカバリ用途とデータ保持のみのコスト
– バックアップのみのコストで計算 – リカバリサイトは「倉庫」 – RTOが数時間以内 ＞＞一気に無限大へ解決すべき部分
解決すべき部分
必要とされる技術
解決される問題
導入効果
解決すべき部分
【一次側】
•
コスト
– 増え続けるデータ – 増え続けるアプリケーション – 煩雑な管理•
SLA
– バックアップWindowsの相対的減少 – 多様なRPO【二次側】
•
コスト
– 復旧用機材（サーバ、ストレージ） – サイトの管理費（利用料） – 回線コスト•
SLA
– 多様なRTO必要とされる技術
【そもそもデータの爆発的な増加を抑えられないか？】
•
ユーザから見える容量と実際のストレージに保持される容量は同じ？
– 違うファイルでも同じデータを持っていないか？ – バックアップはそもそも同じデータが多いのでは？ • 週次のフルバックアップは９０％同じでは？【重複除外（De-dupe）】
•
ファイルやストリームを適当な大きさに小分けし、
その単位で同じものがすでに書かれていれば、
データは書かずに復元するのに必要なメタ情報のみ保持する仕組み
•
これにより、平均で20倍以上の圧縮効果が得られる実装も存在する
解決される問題
【サイト間Network回線】
•
サイト間で100TBのフルバックアップの複製を４８時間で行う際に必要な回線
– De-dupe無し： • 100 x1024 x 1024 = 104857600[MB] を 48 x 3600 (sec)で行う = 606[MB/sec] = 4.848[Gbps] …. 約５Gbpsの回線 • De-dupeあり： （1/50へ圧縮すると） 606[MB/sec] /50 = 96.96[Mbps] ….100Mbpsの回線
【増え続けるデータ】
•
100TBのフルバックアップのデータを3世代、差分5%(月∼金) Diskに保持
– De-dupe無し： • 100TBx3 = 300TB 、(100TBx 0.05) x 10、 計350TB • （複製をDRサイトに持つと計700TB） – De-dupeあり： （平均1/20とすると） • 350TB / 20 = 17.5TB ＞＞５Uで実現可能
• サイト合計35TB ※１TBHDDで３５０TB⇒３Uシェルフ（14本）ｘ25段＝７５U＝ラック2本統合バックアップ
解決される問題① - 一次側
BackupSoftA Script:cp/tar/dump Linux Server Firm 多様なSLAの バックアップを統合 De-dupe storageTo DR
Site
SLA
高
Local Replication
CDP、アプリケーション側でのリプリケーション（DataGuard等）SLA
低
SLA
中
ReplicationLocal BackupSoftB BackupSoftD BackupSoftC Back up Set Back up Set Back up Set Back up Set Back up Set解決される問題② - DRサイト側
Du-dupe storage De-dupe Storage DR Site リプリケーション時の帯域削減 DRサイト側でのリストアの自動化 Back up Set Back up Set Back up Set Back up Set Back up SetWAN
Back up Set Back up Set Back up Set Back up Set Back up SetDe-dupeによる
帯域削減
Script:cp/tar/dump Backup softによるリストア Primary Site重複除外
（DE-DUPE）の有効性
重複除外のバリエーション
インライン処理の重要性
重複除外のバリエーション
【対象による違い】
•
ファイル単位
•
オブジェクト単位（ファイルより小さな単位）
– 固定長（4KB等）、可変長【処理手法による違い】
•
ポスト処理（バッチ処理等を含む）
– 重複除外されていないRawデータを一度ストレージに書き込み、 その後ストレージ内で別個に重複排除処理を行う•
インライン処理
– ストレージに転送されたデータをストレージ内のディスクに書き込む前に 重複除外処理を行う17
インライン処理の重要性
【ポスト処理】
一度ディスクに保存後、重複除外
ディスクに保存する前に重複除外
【インライン処理】
•１００TBを１／２０に重複除外できたとしても １０５TBの容量は必要 •Backupを行うときにはバックアップ分の ストレージエリアを確保する必要がある これでは、本末転倒 •SLAを満足するための高速化は、 I/O能力の向上も必要でコスト効果が薄れる •１００TBを１／２０に重複除外できるなら ５TBの容量で十分 •I/Oを必要最小限にできるのでコスト効果が 高い •SLAを満足するための高速化に高価なHDD を多用しなくて済む De-dupe Storage100TB
5TB
Replication I/O De-dupe Storage5TB
Replicationインライン処理の重要性
バックアップと同時 にレプリケーションDR-Ready
インライン処理
バッチ処理／
ポストプロセス型の
重複排除製品
従来型の VTL／
テープトラック搬送
VTLへバックアップDR-Ready
バックアップ ウィンドウ RPO の大幅な改善 D R R e a d y バックアップ テープへ複製 トラック搬送 非重複処理とレプリケーション DR サイトへのデータ複製完了までに ２倍から４倍の時間が必要インライン処理を実現するテクノロジー例
オブジェクトの格納時にはベクタービットが立てられる
格納前に該当の場所のビットを確認し、
ひとつでも０があれば今まで格納されたことが無いとして書き込みを行う
この手法で書き込む必要があるセグメントをメモリ上で判断できる
セグメントから生成されるFingerprintデータから、
さらにブルーム関数を用いて3種類のハッシュ値（ベクタービット）を作成
←サマリーベクタ （最初はすべて０） ←サマリーベクタインライン処理を実現するテクノロジー例
【サマリーベクターの特徴】
– サマリービットが何れかが０⇒１００％重複していない – サマリービットがすべて合致⇒１００％に近い確率で重複データを所持【重複の確認のため既存セグメントのFinger Print値を直接比較】
– 合致すると重複とみなす – まずメモリキャッシュ内のFinger Printをチェックしなければストレージ内のFPを参照【ストレージからのデータ・ロードを効率化】
– Finger Printを含むメタデータとセグメントデータはローカリティという ユニットに複数まとめて保持 – ストレージ上のFinger Printインデックスを参照し該当するローカリティ全体を読み込む – ローカリティ生成はストリーム順に行われるため、 たとえばフル・バックアップを繰り返すような場合特に先読み効果が高いデータ保護の今後
データ保護で重要視すべきこと
保護の本質
【データ保護＝複製？】
– 別なメディアに復元可能な形式で情報を維持すること
• 別なメディア＝別なストレージシステムのメディア（ ≠Tape only） • 可搬メディアの必要性 – 最もコストを低く抑える手法 ⇒リスクも増大 – 永続的な「復元」は可能か？ ⇒読み取りのためのH/Wの互換性問題 – 復元に必要な時間に満足できるか？ – ライブラリ等のメカを維持するには 大規模になるほどコストが増大 » スケールアウト型を求められない （スロットを増やすだけでは高速化しない） – セキュリティの問題を解決できるか？ » 搬送中の盗難– Network経由で如何にコストを抑えて
別なメディアに情報を維持できるかが重要
データ保護用ストレージの基本要件
【保持しているデータは安全なのか？】
– 書き込み時
• HDDは受け取ったデータを本当に 正しくメディアに書き込んでいるか？ • HDDはwriteコマンドでは、自動では 確認をしない（No read after write）– 保持中
• HDDに書かれたデータは永遠に正しく 保持されるか？ • 磁気メディアは劣化するものである– エラー時
• HDDに書かれたデータを読み込んだ時 エラーが発生したら？ – HDD内部の機能ではECC等の エラーコレクションは可能であるが コレクション不能なエラーが出た場合 どうするのか？データ保護用ストレージの基本要件
【ストレージシステム自体でより強固な仕組みを持つことが大原則】
– 単純なRAIDやJBOD等で一見コストを抑えたように見えるが
リスクは大幅に増大する
– 特にDu-dupeではそもそも同じデータを持たないので
同じものを複数セット持っても意味はない
• De-dupeではストレージ自体の保護機能が非常に重要アーカイブとバックアップ
【アーカイブ＝バックアップ？】
– もちろんNo
【アーカイブのバックアップは必要？】
– Yes
【アーカイブの本質】
– 利用頻度の低い情報をよりコストの低いストレージに維持すること
• 可搬メディアでは、昨今の検索要求にこたえられない • 一次ストレージとアーカイブではアーカイブの容量がより増大傾向が強い【アーカイブ用ストレージに必要な技術】
– データ量を少しでも減らす機能
– データ保護機能（複製、バックアップ）
【データ保護の中期トレンド】
アーカイブの維持とそのバックアップを効果的に行えるストレージ
将来を見据えた
将来を見据えたデータ保護用ストレージ
【要件】
– バックアップの統合を可能にする柔軟なインターフェース
– 増大するストレージ容量を削減する技術
– 回線コストを抑えながらリプリケーションを可能にする技術
– バックアップウインドウを維持できる高速な処理能力
– リカバリに際して確実に処理できる機能
– DR発生時にも耐えうるリカバリ処理能力
– 情報の維持を安全に行えるストレージ保護機能
– アーカイブ用途での利用も可能でバックアップを自動的に行えるストレージ
DataDomainとは
DataDomain ファイルシステム NFS CIFS VTL （Tape Emulation) GbE or 10GbE 4Gb FC インライン重複排除 ホストアーキテクチャに 依存しない接続 OS コマンド （tar/dump/cp等） 既存アプリケーションへの 柔軟な対応 EMC NetWorker End-to-end Verification
• RAIDのパリティ値、ファイルシステム・
メタデータ、ユーザデータに対する
チェックサム値を即時ベリファイ
• 読み出し時にもベリファイ動作
①チェックサム生成
②チェックサム及びデータを
確実にディスクへ書き込む
③ディスクからリードバック
④チェックサムを比較する
「データ保全」「一貫性保持」のための高度な機能（１）
Data
20バイト ＦＰ 4バイト チェックサムセグメント
データ
（平均８ＫＢ）
20バイト ＦＰ 4バイト チェックサムベリファイ
ベリファイ
「データ保全」「一貫性保持」のための高度な機能（２）
Fault avoidance and containment
【万が一の事態においてもデータ破損が発生せず、一貫性を維持】
既存のデータを上書きすることの無いログ構造化ファイルシステム
よりシンプルで堅牢なファイルシステム構造
RAID における部分書き込みは行わず、常にストライプ全体を更新
NVRAM を活用したリスタート時のデータ保持と一貫性確認
. . .
= 使用済セグメント
常に追記のみ
= 書き込みセグメント
常にストライプ全体を更新
Continuous fault detection and healing
• 万が一何らかの問題が検出された場合、以下の仕組みにより
データを修復
RAID6 によるデータ復旧
ディスクスクラブによる事前検出
File system recoverability
• DDFSのメタデータはスナップショットを保存
• メタデータの再生成も可能
業界で最も拡張性の高いインライン重複除外システム
DDX Arrayシリーズ ソフトウェア・オプション：
DD Boost、DD Virtual Tape Library、 DD Replicator、DD Retention Lock、 DD Encryption 最大16コントローラ DD140リモート・オフィ ス・ アプライアンス DD600アプライアンス・シリーズ DD880
Global Deduplication Array
DD140 DD610 DD630 DD670 DD880 Global Deduplication Array DDX Array 速度（DD Boost以外） 450 GB/時 675 GB/時 1.1 TB/時 3.6 TB/時 5.4 TB/時 86.4 TB/時 速度（DD Boost） 490 GB/時 1.3 TB/時 2.1 TB/時 5.4 TB/時 8.8 TB/時 12.8 TB/時 140.8 TB/時 論理容量 17∼43 TB 75∼195 TB 165∼420 TB 1.1∼2.7 PB 2.8∼7.1 PB 5.7∼14 .2 PB 45.6∼114PB 物理容量 1.5 TB 最大6 TB 最大12 TB 最大76 TB 最大192 TB 最大384 TB 最大3.07 PB 使用可能な容量 0.86 TB 最大3.98 TB 最大8.4 TB 最大55.9 TB 最大142.5 TB 最大285 TB 最大2.28 PB New
ユーザ事例
【導入効果】
Backup Windowの維持
コンプライアンス用途以外の
テープ排除
約10分の一へ容量を削減
リカバリ時間が
45分から5分へ
ユーザ事例
【導入効果】
DataDomain DataDomain Backup Set Backup Set非重複化・圧縮後のデータを転送
DDが自動的にコピーを作成
データの転送量が少ない
少ない回線帯域で転送可能（回線コストの大幅削減）
ユーザ事例
【導入効果】
•
バックアップ及びDRの過程を自動化
– 一か月あたり480時間または正社員3人分の管理コスト削減•
非常なコスト削減
– $450K以上の購入コストを削減 – 年間約$75Kのテープ購入コストを削減•
より高速なバックアップ及びリカバリを実現
– 設計したバックアップ・ウインドウに容易に合致 – SLAの向上•
管理の簡易化
– 従来のオフサイト保管→自動複製 – Networkerのインデックスを5分間隔で複製 – テープの破損（ソフト・ハード）→ゼロ•
データセンターの効率化
– テープライブラリの撤去PCのデータ保護と
PCのデータ保護と仮想環境の問題
【ファイルサーバの限界と個人データの保護】
•
ファイルサーバのGB単価と個人PCのHDDのGB単価に圧倒的なGAP
– 結果ファイルサーバの容量は制限され入りきらない情報は個人PCへ – 個人で可搬メディアにバックアップすることはセキュリティ上危険•
シンクライアントが解決するか？
– データセンター内のストレージにデータを保持することに変わりはない – シンクライアント化がコスト削減につながる？•
個人PCのデータを効果的に
バックアップする手法を求めるユーザが増加
– 要件 • 回線使用を最小限に • 保持用ストレージのコストを最小限にPCのデータ保護と仮想環境の問題
【仮想化サーバのバックアップ】
•
従来の手法ではバックアップ時にCPU負荷が増加し
バックアップウインドウを満たせない
•
ハイパーバイザの機能を利用したバックアップが一般的
– 仮想サーバの台数も増加傾向のためバックアップ先のストレージが圧迫PCのデータ保護と仮想環境の問題
【De-dupeが問題を解決】
– バックアップサーバとバックアップストレージ間の
ネットワーク帯域の制限
• DataCenter内の
バックアップとの違い
• 一次側でDe-dupeを
行う新たな手法により解決
PCのデータ保護と仮想環境の問題
【要件】
• 一次側でのDe-dupe
– 回線コストの削減
– CPU負荷を低減できる手法が有効
• 他のバックアップ対象の情報に対してもDe-dupeすることでより効果的
– Network帯域の削減をより効果的に行うことが可能
– 仮想環境ではサーバ内重複だけでなくサーバ間の重複データを除外するこ
とがより効果的
革新的なバックアップシステム Avamar
バックアップする前に重複除外
LAN
重複除外バックアップシステムAvamar
• バックアップサーバ、バックアップソフト、バックアップデバイス（RAID）
をパッケージ化したバックアップ用アプライアンス
• バックアップクライアント上で重複を除外
• １日のデータ転送量が通常のフルバックアップの1/500
Avamar Desktop/Laptop
【優れた機能をエンド・ユーザーにも提供】
– デスクトップ/ラップトップへのデータの リストアに際してヘルプ・デスクを介す必 要がない⇒管理コストの削減 – 自動管理によるリストア – ドキュメント・レベルの検索エンジン【Avamarによるバックアップのメリット】
– ソース側でデータの重複除外により ネットワーク負荷を削減 – フェーズ分けによる重複除外対象の 絞り込みによりPCリソースへの影響を 最小限に抑制 – 毎日のフル・バックアップに要する 時間を最大10分の1に短縮時間や場所を問わず、エンド・ユーザーが自分でデータをリストア
Avamar Desktop/Laptop
エンド・ユーザーが リストアを開始 WindowsまたはMac OS XAvamar 重複除外 Avamar 重複除外 Avamar 重複除外
バックアップ
VMware ESXサーバ バックアップ サーバEMCの重複除外技術により、かなりのデータ量の削減と
リソースの節減が期待できます。
データ
データ
データ
ストレージ
ネットワーク負荷最小 ESXサーバの 負荷減少 バックアップストレージ Avamar活用例１：VMware環境での超短時間バックアップ
バックアップサーバ ・バックアップ管理を統合 ・バックアップデータ量を削減 ・テープ輸送のリスクを排除 バックアップクライアント バックアップサーバ レプリケーション
