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