1. 事業継続管理：
事業継続のテーマは不慮の事故による業務停止の予防にあります。そして事業継続リスクの種類は次の４種類に分類されます。
1.1. 事業継続管理の取り組み方：
その不慮の事故に対応する事業継続管理は3つのステップで考えていきます。
（注）復旧対応=ディザスタリ・リカバリー（DR）
2. BCP策定: 対策費用と損失の関係
ここではIT分野に関する復旧対応（ディザスタリカバリ：DR）について考察していきます。
ITに依存が高ければ災害時での業務への影響が大きくなります。システムの完全二重化などに対策費用をかけることによりシステムの停止時間を短縮することができますが、多額の支出を必要とします。一方対策費を削減することは災害時での業務に大きな影響を与え、多大なビジネス欠損をもたらします。ITと経営戦略の観点からBCPの最適化を進めることが必要になります。
3. RPOとRTOについて
ディザスタリカバリについて考えるときにRPOとRTOを決定する必要があり、各企業がどの様なRPO、RTOを設定するかはDRプランを設定する際に非常に重要な要素になります。
RPOとRTOは次のように定義されます。
● RPO: Recovery Point Objective ・ 災害時にどの地点のデータまで復旧させるかの目標
● RTO: Recovery Time Objective ・ 災害時からいつまでに業務を復旧させるかの目標
4. 仮想化ディザスタリカバリ(DR)に対するアプローチ
ここからは仮想化環境でのディザスタリカバリについて考察していきます。仮想化環境ではどの様にDRに対応するかのプランが必要で、そのアプローチには次の4つのフェーズが考えられます。
ここではアセスメントとデザイン・フェーズについて考えていきます。
4.1. アセスメント・フェーズには次の項目が含まれます。
4.2. デザイン・フェーズには次の項目が含まれます。
次にアセスメントとデザイン・フェーズのそれぞれの項目を考査します。
5. ビジネス・インパクト分析（BIA)
5.1. BIAとは：
企業にとってデータとシステムがいかに重要で、それを守るためにBIA（ビジネス・インパクト分析）では次の設定を決定することにあります。
●ビジネスとITサービスに対するRPO, RTOの決定
● DRプランナ(計画策定者)と管理者に対する目標の設定
5.2. 主なBIA行動策定：
BIA行動策定には次の５項目があります。
1. 重要なビジネス・システムの特定
2. システム・リソースの依存性を特定
3. 重要なサポート個人またはチームを特定
4. 被害インパクトを想定
5. リソース（資産）・リカバリの優先度の決定
ユーザ・システムへのビジネス・インパクトの詳細な知識があれば災害計画に役立つだけでなく、災害の準備テストにも役立ちます。BIAは単なる技術的なシステム・インベントリではなく、主なビジネス・サービスとITサービスに対応するRPOとRTOの定義が必要になります。
5.3. BIAテンプレートの活用
BIAをゼロから作成することは大変なことです。その場合はIPA(独立行政法人 情報処理推進機構)などから提供されているテンプレートを活用することを推奨します。
6. RPOとRTOの決定
企業には多様な製品とサービスがるので、BIA策定時に企業はそれぞれに適応するRPO、RTOを決定する必要があります。ここでは3つの例を紹介します。
6.1. 教育機関：
通常教育機関は大きな予算をDRプランに回すことができません。就学時期でのRPO/RTOは次のようになります。
* RTO：2日から1週間
* RPO：24～48時間
6.2. 会計事務所：
通常時のRPO/RTOは24～48時間と考えられますが、納税時期などの非常に業務が立て込む時期ではRPO/RTOは1時間以下が要求されます。
6.3. 医療機関：
患者の医療に直結するシステムではゼロに近いRPO/RTOが要求されますが、それ以外の一般的な事務システムでのRPO/RTO は24～48時間と考えられます。
7. 予算管理
仮想化DRは通常の物理DRより、コスト的には低くおさせることが可能です。しかしそれぞれの企業には予算の限界があります。できるだけDRオプションを1製品に統合することが必要です。
7.1. 段階的な予算：
DR導入を段階的に行うことで予算を段階的に支出し、経営的なインパクトを抑えることが可能です。
7.2. 仮想化DRの長期的なビジョンを持つ：
レガシーな物理DRから仮想DRへの移行メリットを経営者に説明することは重要なことです。そしてその仮想DRプランがよければ3~5年で低TCOが可能になります。
7.3. 経営者との会話：
経営者には仮想化の話は難しいものです。CIOまたはそれに代わる人にその必要性を絶えず説明していくことも必要です。
8. アプリケーションの依存性の確認
アプリケーションの依存性の確認し、最初にクリティカルなアプリケーションを保護します。
DRを必要とするコアのインフラ・サービスを確認：
Active Directory, DNS, IPアドレス・アサインメント( DHCP,等）、ファイヤーウォールがDRを必要とするコアなインフラ・サービスとして考えられ、マイクロソフトの VSS（Volume Shadow Copy Service)対応のツールを採用することが重要となります。ここではミッション・クリティカルなアプリケーション、ステートレスなアプリケーション・サーバ、ディプロイメント・システムの保護の3つの分野に分けて説明します。
１．ミッション・クリティカルなアプリケーション：
●データベース等の重要なデータ
●SQL Server, AD はVSSを必ず使用
●VSSをサポートしないデータベースはDBAと事前に相談が必要
●スクリプトでの対応を検討
2. ステートレスなアプリケーション・サーバ：
● それほどミッションクリティカルでないアプリケーション・サーバ
● クリティカルな変更がある期間は重要
– 例：アプリケーションのアップグレード、大きなソフトウェア変更
● 初期バックアップ後は帯域幅、 I/Oに対応したフル/差分バックアップ
3. ディプロイメント・システムの保護
● 例：ターミナルサーバ・ベースのアプリケーション・サーバ、Javaアプリケーション、Webサーバ
● DRサイトで再ディプロイが必要なシステムの依存性と検証
● エンド・ツー・エンドのプロビジョニングが必要か？
– いくつのVMに共通なコンフィグレーションを？
– そのリストアをどの様に短期間で？
9. 仮想化環境データの自動収集
仮想マシン・インベントリーのデータの自動収集はDRプランのデザインの可視化：DRプランに重要で正確なプランとジャンプスタートが可能とします。
仮想マシンのモニター、レポート機能から構築された統合仮想化監視ソリューション：Veeam ONEは仮想マシンのデータ自動収集をサポートします。
10. 仮想化への乗り遅れ
仮想化DR の機能とコストパフォーマンスは物理サーバのDRソリューションより優れています。
仮想化DRには次のような利点があります。
・ スナップショット：クリティカル・パッチのテストとフェイル時にロールバックが可能
・ サーバ・イメージ全体（OS,アプリケーション、データ)をドライバの心配なく、どんなH/Wにリストア可能
・ ゼロ・ダウンタイムでH/Wの再起動
・ リストアの自動化と必要に応じたテスト
・ VMバックアップ・イメージからファイルとアプリケーション・アイテムのリストが可能
・ VSSによるアプリケーションの整合性
仮想化への移行を行うのであれば物理サーバを残さず、すべて仮想化へ移行すべきです。また社内で仮想化に関して色々な抵抗が予想されます。特に経営者にとって仮想化のメリットは分かり難いものです。それらに対して粘り強く説得することが必要です。
VMパフォーマンスに関するバリアーは無くなりましたが、仮想化に対する適切なキャパシティ・プランは必要です。
仮想化のワークロードとハードウェア・リソースの適切なバランスを保つことが重要になります。
11. リソース・リクアイアメントの分析
– ディザスタ・シナリオで、そのリクアイアメントに必要なリカバリ・サイトのサイズと予算のバランスを考慮します。
– アセスメントの仮想化環境データ収集をベースに分析を行います。
CPU とメモリ
● 本番環境でのワークロードの統計を分析
● クリティカルなワークロードの検証
ストレージ
● 必要な生のストレージ・スペースの確認
● DRサイトへリカバリするすべてのVMのGB
● プラス日々の差分バックアップ
● ストレージ・パフォーマンスの確認
– IOPS, ストレージ・バンド幅
– SSD,SAS,SATA
● 統計と予算の分析が必要
ネットワーク
● VPN, WAN回線のリース
● データ量/日、またはデータ量/レプリケーションの分析
12. リストアが容易なデザイン
リストアのプロセスには単純化が鍵になります。
VMの強力な機能
● カプセル化とH/Wからの独立
● レガシーなリカバリ手法 よりVM全体のリカバリの方が優れている
● ステップ数の削減 ⇒ リスクとコストの低減
レプリケーションからスタート
● VM全体のリカバリ： バックアップとレプリケーションの両方を活用する
13. インフラ・コンフィグレーションの決定
H/W, ソフト、オフサイト・データ転送方法、リカバリープランの決定
・ サーバ
BIAにガイドされる仮想化環境から最適な容量を割り出す。
・ ストレージ
DRサイトへのvMotion, HA :
NAS, iSCSI, FC
SMB, リモート・オフィス：
ローカル・ディスクを使用したDR
・ ネットワーク
予算が充分であれば： しっかりした帯域幅の準備
帯域幅が小さければ: RTOの変更
– サーバ・リソースのプロビジョニングが必要
・ クラウドDR
仮想化ホスト・プロバイダの活用
初期投資の低減
充分な事前計画が必要
クラウドに対応したSLA
クラウド・ベンダのサポート体制に対応する準備
14. 継続的な仮想化DRテストのプラン
最初のバックアップ前にリストア計画と検証
テストを意識したデザイン
・ VMのリストア・テストが可能なワークフローの準備
継続テスト（Test Drive）が可能なDRテスト：新規VM追加等に対応
・ 仮想化ではテストが継続できるDRプランが可能
・ DRプランを守る自動リカバリ検証環境の確立
Surebackによるリカバリ検証プラン
・ いつでも、すべてのVMをすべてのバックアップでテスト
・ バックアップに対して変更なく
・ 隔離されたテスト環境
・ すべてのOS,アプリケーションに対して
ご意見・ご質問がありましたら、コメントにご記入ください。
RSSフィードを取得する
