Special
» 2015年01月06日 10時00分 UPDATE

@IT主催セミナー「なぜバックアップがうまくいかないのか」リポート:トップアーキテクトが語るバックアップ/リストア設計・運用のポイント

[PR/@IT]

 2014年11月26日、@IT主催セミナー「なぜバックアップがうまくいかないのか トップアーキテクトは知っている、バックアップ設計・運用の盲点」が開催された。インフラの仮想化やクラウド化が進む一方で、バックアップ/リストアは旧来のまま運用している企業は多い。その結果、管理の複雑化やフルバックアップの失敗など、さまざまな問題に直面している。バックアップ/リストアがうまくいかない理由は何か、その設計や運用のポイントをプロが解き明かす。

富士フイルム事例で見るバックアップ運用の勘所

 基調講演「富士フイルムグループが実践する確実な障害復旧に求められる真のバックアップ運用設計」には、富士フイルムコンピューターシステムの柴田英樹氏が登壇した。

backup2_1.jpg 富士フイルムコンピューターシステム システム事業部 ITインフラ部 部長 柴田英樹氏

 富士フイルムグループの情報戦略の策定・推進などを担う同社は、効率的な業務、迅速な組織再編のできるグローバルIT戦略推進の一環で、2008年にプライベート基盤の構築を開始した。それから2年かけて基幹業務システムのサーバー430台の仮想化やWindows 2000 Serverの移行などを進め、2011年にはBCP対策に合わせて、さらに270台のサーバー移行を実施。2011年後半からは標準化や共通化の徹底を進めて、2012〜2013年にはサーバー350台規模のプライベートクラウドで本格活用が始まった。

 「2014年に入ってからも月10台のペースで仮想化を進めており、現在は千台強が稼働している」(柴田氏)

 バックアップ環境を最初に構築するとき、同社はコモディティ製品を使ったシンプルな構成を目指した。そして運用開始から6年後、ハードウェアの更新タイミングを迎えたことをきっかけに、同社は現状の見直しを実施した。その結果、物理/仮想やアプリケーション/インフラといった依存関係が短時間で把握できず復旧に時間がかかる点、サーバー集約率が高まり日次バックアップの負荷が集中し過ぎている点など、さまざま課題が浮かび上がった。それぞれを丁寧に見直しながら、リソースの拡張、ハードウェアの更新、ディスクストレージの重複排除機能の有効活用、サービスレベルの妥当性チェックプロセスの強化など各種改善を行い、現在に至るという。

 「プライベートクラウド構築時に、最初に行うべきは標準化だった」と柴田氏は言う。まずは障害復旧要件、復旧の考え方を整理し、その上で構成要素の設計を考えたという。例えば、業務データ領域の復旧ポイントを障害発生直前時点とした場合、リストアは障害発生時点のバックアップデータを充てるなどだ。その後、障害種別(データセンターやSANストレージなど)、障害個所(ディスクストレージや仮想サーバーなど)、復旧方針(ハードウェア交換など)をリスト化。ここでようやく必要なツールが見えてくる。

 この他、業務システムの責任者であるオーナー部門を設定、サービスレベルのパターンを標準化してカタログ化した。サービスレベルは3段階に分けて、I/O性能要件、復旧許容時間、復旧レベルやバックアップ取得タイミングなどの項目を取り決めた。ユーザー部門はコストやサービスレベルの組み合わせを選んで利用申請し、必要なバックアップサービスを手に入れる。

 「ユーザー部門がIT部門に期待するのは、変化への柔軟で迅速な対応と利用・運用コストの継続的削減だ。そこで、カタログ化したメニューからユーザーが導入したいシステムに適したものを選択しやすいように、稼働中のシステムの例示や利用コストの見える化を行った。選ぶのに迷って時間をかけさせない工夫だ」(柴田氏)

 見直し時に課題で挙がったのは、障害時の迅速復旧だ。「初期導入後、ディスクストレージで大規模障害を経験した。ディスクストレージ自体はとても高機能だったが、構成要素が増え複雑化し、ファームウェアで高度な制御を行うようになった結果、二重化構成のうちの片系が中途半端にダウンしても、もう一方への切り替えや切り戻しが発生するなどして全体に影響が出た」。そこで、復旧プランの検討体制や判断プロセスを確立、システム構成情報を詳細化・一元化して影響範囲の確認方法を改善した。

 「たとえ小さな犠牲を伴っても復旧を優先するには迅速な意思決定が必要と実感し、判断プロセスを確立した。また、早期復旧が不可能な場合の代替措置として、データ形式の定義と提供方法も明確化した。例えば、物流や在庫情報などでは必要最低限の情報をExcelシートで確認できれば業務を継続できるので、そうした提供方法を用意するなどだ。

 見直しの結果、効率や俊敏性はさらに向上し、セルフサービス体制も実現した。現在は、プライベートとパブリッククラウド間の連携を進めている。プライベートクラウドとパブリッククラウドのメリットを適材適所で生かせるような、ハイブリットクラウドを目指している」(柴田氏)

4つの失敗事例から学ぶ仮想環境バックアップ対策

 続くセッション1「課題・失敗から学ぶ、VMware環境のバックアップ設計ポイント」は、伊藤忠テクノソリューションズの木島亮氏が登壇した。木島氏は、案件対応で経験した4つの課題・失敗を挙げ、解決方法や製品選定のポイントを解説した。その4つの課題・失敗は「VADP(vStorage API for Data Protection)バックアップ製品はどれも同じという思い込み」「フルバックアップが想定時間で終わらない」「事業継続/災害対策のレプリケーション設計ミス」「不透明かつ手動設定変更の多い運用」である。

backup2_2.jpg 伊藤忠テクノソリューションズ 製品・保守事業推進本部 ITインフラ技術推進第1部 ストレージ技術推進課 木島亮氏

 一つ目は「どのバックアップ製品でもVADP機能は同じという思い込み」だ。VADP機能はさまざまなバックアップ製品に実装されており、どの製品でも機能面で違いはないと考えがちである。バックアップ製品によっては、バックアップ/リストアに長時間を要し、整合性を確保する仕組みが不十分なものもある。それらをVADPの仕様と捉え、諦めがちだ。しかし、これらは最適な製品を選択することで解決できると木島氏は言う。「例えば、VADPで取得したバックアップからアプリケーションデータをリストアできる製品であれば、ネットワーク経由のバックアップが不要になり、トータルのバックアップ時間を短縮できる」

 二つ目は「データ容量が増加し、フルバックアップが想定時間で終わらない」という課題である。週次のフルバックアップを月次に変更し、バックアップスケジュールを手動で調整してもデータ増加に対応しきれないケースがある。「そのような状況は、永久増分バックアップ機能を有する製品を選択することで解決する。永久増分バックアップとは増分バックアップを取得し、前日までのバックアップと高速に合成することでフルバックアップを作成する方法だ。増分バックアップの所要時間と取得容量で、毎日の高速なフルバックアップを実現する。さらに、バックアップ対象が追加されても手動でのスケジュール調整が不要であることに加え、バックアップサーバーの増設も計画しやすい」(木島氏)

 三つ目は「バックアップデータの遠隔地保管に従来のNAS/SANストレージのレプリケーション機能を使用したため膨大な時間を要してしまった」という失敗である。バックアップデータは常に新規データとしてストレージに書き込まれるため、NAS/SANストレージの機能では全データが変更されたと判断される。それにより全データがレプリケーションされてしまうからだ。ここで、重複排除機能を使用すれば、非常に小容量のレプリケーションで済むようになる。ただ、バックアップサーバーと重複排除ストレージの組み合わせでは、バックアップとレプリケーションが別管理になり運用は複雑になる。「1つの製品でバックアップとレプリケーションが可能な統合バックアップアプライアンスを推奨する。そうすることで、バックアップとレプリケーションの一元管理、レプリケーションデータの自動認識、シンプルなサイト間切り替えが可能になる」(木島氏)

 四つ目は「運用が見える化/自動化されていない」という課題だ。よくあるのが、監視は監視ソフトを用いたログ監視を行い、リポートはコマンド出力を元に手動で作成し、日々の環境変化に手動設定変更で対応するという方法。これでは工数が掛かる割には想定されている成果は期待できない。まずは、通知とリポート機能を有するバックアップ製品を選ぶと良い。多くのカスタマイズ可能なテンプレートが用意され、ジョブのステータスや容量不足の通知機能、重複排除率やバックアップ未実施クライアントの有無など、作り込み不要でバックアップ運用のかゆい所に手が届く。また、バックアップ製品の機能と提供ベンダーのノウハウに基づく設定で、環境変化に自動で柔軟に対応できれば、導入後の運用負荷が下がる。

 「弊社は、これまでに多様な事例を見てきた。私が関わった案件だけでも年間90件以上になる。提案できる製品も多数取りそろえ、製品の比較検証も可能だ。カタログや製品説明だけでは分からない製品ごとのパフォーマンス比較など、困ったことがあれば、ぜひ相談していただきたい」(木島氏)

迅速/確実/シンプルなデータ復旧運用を実現するヒント

 セッション2は、シマンテックの勝野雅巳氏が「大規模な物理&仮想環境の、迅速/確実/シンプルなデータ復旧運用を実現するには?」と題する講演を行った。

backup2_3.jpg シマンテック セールスエンジニアリング本部 IMソリューションSE部 シニアプリンシパルセールスエンジニア 勝野雅巳氏

 「データの急増や物理・仮想混在による環境の複雑化によって、迅速・確実・シンプルなバックアップ/リストアは、ますます難しくなった」。勝野氏はそう述べ、阻害要因として、スクリプト処理で手順が複雑化してミスが多発、ツール別の復旧手順で作業が煩雑化、増殖を続け数千に及ぶ仮想サーバー、フルバックアップ時間の長期化、部分的リストアができないなどを挙げた。

 こうした問題を解決するのが、シマンテックのバックアップソリューション「Symantec NetBackup」(以下、NetBackup)だ。同ソリューションは、ファイルサーバーやデータベース、VMware環境、NASのNDMPなどを、ディスクやテープ、クラウドへ単一オペレーションでバックアップできる。常時リストア可能な状態にあり、ブロック単位およびファイル単位のいずれでも即時リストアできる。

 増殖する仮想サーバーのバックアップ問題については、自動バックアップ機能「VM Intelligent Policy」で対応する。事前設定されたポリシーに従って自動バックアップするので、取り逃しが防げる。処理速度も、VMDKに依存せずに1000台の仮想サーバーを3時間以内にバックアップするなど高速で、ネットワークバックアップも変更ブロックのみ転送し、ネットワーク負荷も保存容量も低く抑えることが可能だ。

 リストアでは、「Instant Recovery for VMware」機能を使えばNetBackupから仮想マシンを直接起動でき、1TBのOffice Exchangeを92秒で立ち上げ完了するなど高速リストアが可能だ。

 以上の機能に対して網羅的にアプローチし、効率的な運用をかなえるのが、統合バックアップアプライアンス「Symantec NetBackup 5230」だ。同製品は、1台で仮想マシン最大4800台をバックアップ可能なスペックを備え、限られた帯域であっても効率的なフルバックアップで遠隔地拠点へのバックアップ環境も構築できる。

 「サーバー、OS、ストレージ、NetBackupの全機能がパッケージ化されているので、設計・導入・構築期間を短縮でき、保守も一元化されていることから迅速な障害復旧も実現する。しかも処理速度は、最適化仮想合成機能(Accelerator)使用時で毎時最大30TBを発揮し、不正侵入検知機能も実装している」(勝野氏)

 もっとも、こうしたアプライアンス製品はブラックボックス化されているため、きめ細かな状況確認ができない印象が強い。これについて勝野氏は、メンテナンスモードにすればベースのLinux OSにアクセスでき、詳細を確認できると述べる。

 米国でも数多くの実績があり、例えばヘルスケア企業のPerkin Elmer社では導入の結果、今後3年で40万ドル以上のコスト削減の見通しという。「同社は以前、複数のバックアップ製品をシステムごとにポイントソリューションで導入、管理していた。NetBackupアプライアンスで統合、集約したことで、単一コンソールでの統合管理、メンテナンスや障害対応の一元化、ヘテロ環境への対応などで、運用もコストも大きく軽減された」(勝野氏)

 Symantec NetBackupは組み込み型もあり、環境に合わせた導入が可能だ。「本製品は、IT管理者の要求を阻害しない、効率的なバックアップ/リストア環境を実現できる。製品選定の際に参考にしていただければ幸いだ」(勝野氏)

「誰がバックアップするデータを決定するのか」「メニュー化されたバックアップは適切なレベルなのか」

 最後に、@IT編集長の内野宏信をモデレーターに全講演者が事前に提出された参加者からの疑問・質問に回答するQ&Aセッションが行われた。

backup2_4.jpg Q&Aセッションの様子。左からモデレーターの@IT編集長 内野宏信、柴田氏、木島氏、勝野氏

 「そもそも誰がバックアップするデータを決定するのか」という質問には、柴田氏が回答。「システムごとに主管となるオーナー部門を定め、その部門が決定する。オーナー部門とIT部門で障害復旧要件に基づきバックアップデータを合意・決定する」。合意の形成については「IT部門が御用聞きになってしまうとユーザー部門から高いSLAを要求されてしまうので、技術的にどこまで可能か、実現のためのコストはどれくらいかをきちんと伝え、議論、納得できるようにするのが大切」と述べた。

 「クラウドサービス、データセンターでのバックアップはメニュー化されている例が多いが、メニュー化されたバックアップは適切なレベルなのか教えてほしい」という質問については、木島氏が「クラウドサービスは基本的にはシステムバックアップだと思う。どこまで整合性が取れていて、障害時にアプリケーションやファイル単位でリストア可能かは分からない。クラウドサービス上にバックアップサーバーを立てて、アプリは自分たちでバックアップ、仮想マシンのシステムバックアップはサービスに任せるなどを検討する必要があるかもしれない。その上で、SLAをどこまで担保するか考えたい」と回答した。

 また勝野氏は「ビジネスの継続性の部分は人間が行い、それ以外でシステムやツールが補完できるところは任せるといった柔軟性で、コストを抑えた効率的な運用を実現したい。その意味でも、クラウドとオンプレミスの良いとこ取りをしたハイブリッド環境が構築できればベストだ」と述べた。


 このように、バックアップのさまざまな問題を解決するには、ビジネス要件にひも付いた復旧要件・運用要件を策定し、それに適合する最適な方式を見極め、その方式を効果的に実現する最適な製品を選定することが必要だ。本稿であらためて興味を持った読者は、自社のバックアップ体制を今一度見直してみてはいかがだろうか。

Copyright© 2017 ITmedia, Inc. All Rights Reserved.


提供:株式会社シマンテック
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2015年2月5日

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。