災害時や障害時にビジネスを止めない為に大事なポイントとはなにか。
米国SIOS TechnologyのDave Berminghamが、継続性の目標値や構成について解説します。
災害復旧とビジネス継続性
Windows 環境における重要な SQL Server デプロイメントの災害復旧構成を考えているITプロフェッショナルは、当然のことながらリモートサイトと復旧可能性という観点から構成を考える。災害時にプライマリーデータセンターがオフラインになった場合、システムは同じ災害の影響を受けない別のデータセンターにフェールオーバーできなければならない。
しかし、災害復旧とビジネス継続性（緊急事態の際に重要なビジネス機能を迅速に再開する能力）は同じではない。ビジネス継続性に向けた計画ははるかに包括的な取り組みであり、災害復旧はその計画の重要な一部分ではあるが、あくまでも一部である。効果的な災害復旧施策を立案する前に、ITインフラのどの要素が本当にミッションクリティカルであるかについて、組織の主な関係者の間で合意する必要がある。これは必ずしも簡単なことではないが、その点に関する合意が得られて初めて、組織のビジネス継続性目標を真に反映した災害復旧計画を実装できるようになるのだ。
継続性の期待値の設定
ビジネス継続性では、継続できるかということがすべてだ。ITの観点では、ミッションクリティカルなシステムへのアクセスを可能にするために、中断を最小限に抑えることに重点を置く。しかし、最も重要なシステムはどれなのか？そして、その判断は誰がするのか？そこで、ビジネスの観点から、何を優先すべきかを理解する必要がある。なぜなら、どのシステムをすぐにオンラインにする必要があり、どのシステムは待機させても問題がないかを知ることは、ビジネス継続性計画全体を成功させるためには不可欠だからだ。
ダウンタイムのコスト
この問題の１つの見方として、ダウンタイムのコストがある。複数のシステムがオフラインになった場合、金銭的、そしてブランドの信頼性の両方の観点から見て、ビジネスが支払うことになるコストはどの程度になるのか？ERPシステムのコンポーネントに関する回答と、DevOpsシステムまたはオフィスの生産性システムのコンポーネントに関する回答は異なる。後者は個人の生産性には重要かもしれないが、SAPシステムが1日オフラインになることは、DevOpsシステムが1日オフラインになるよりも、ビジネスにはるかに大きな混乱を招く可能性がある。ここがポイントだ。あらゆる組織は、自分たち独自の優先順位を決定し、ビジネス継続性計画の中でその優先順位を明確にする必要がある。
そして、さらに詳細を詰めていこう。これらの重要なシステムを5分、1時間、10時間もオフラインにした場合のコストはいくらになるか？失っても問題のないデータ量はどの程度か？このような洞察は、災害が発生した場合に必要な選択や、組織が期待できるアプリケーションの可用性について、経営幹部と有意義な議論をするのに役立つのである。これらの予測について経営幹部（つまり、財布のヒモを握っている人々）の承認が得られると、合意されたビジネス継続性目標を達成するための災害復旧ソリューションを構成する方法を決定するために必要な見通しも得られる。
継続性を実現するための構成
Azure、AWS、Googleなどのクラウドサービスプロバイダーは、99.99％の可用性を約束するサービスレベル契約（SLA）を備えたインフラオプションを提供している。Windows フェールオーバー クラスター インスタンス（FCI）は、災害により本番システムが実行されているデータセンターがダウンした場合に、リモートデータセンターのインフラが迅速に引き継ぐことができるように設計されている。ただし、これらのSLAは、提供されたインフラ上で実行されている仮想マシン（VM）にのみ適用され、これらのVM上で実行されているアプリケーションには適用されない。被災したデータセンターでミッションクリティカルなアプリケーションを実行しているVMが別のデータセンターのVMにフェールオーバーする場合、第2のデータセンターのVMは、元のデータセンターで使用していたすべてのデータを使用できることが保証されていなければ、期待していたビジネス継続性を提供できない。
オンプレミスで実行されているFCIのようには、共有ストレージエリアネットワーク（SAN）を使用してクラウドベースのFCIを構成することはできないことに注意する必要がある。クラウドベースのFCIの各ノードには、重要なアプリケーションで使用されるデータの独自のコピーが必要である。そのため、ビジネス継続性計画の一環として、プライマリーデータセンターのクラスターノードからセカンダリーデータセンターのスタンバイノードにローカルデータを複製するメカニズムを構成する必要がある。
ソリューションの選択肢
ミッションクリティカルなアプリケーションをできるだけ早く復旧させることを目的としたソリューションを設計する場合、いくつかの方法がある。一部のアプリケーションでは、クラスター内のノード間でデータを複製するための組み込みサービスを提供している。しかし、アプリケーション固有の同期メカニズムが、複製したいすべてのデータをサポートしているかどうかという点を考慮する必要がある。たとえば、SQL Server Enterprise EditionのAlways On可用性グループ（AG）機能が複製するのはユーザー定義のSQL Serverデータベースのみで、SQLエージェントのジョブ、ユーザー、パスワードなどを保持している他のシステムデータベースは、セカンダリークラスターノードに複製されない。さらにAGは、SQL Server以外のデータも複製しないが、このようなデータは可用性を確保したい他のミッションクリティカルなアプリケーションにとって重要な可能性があるのだ。
Microsoft SQL Serverを使用していない場合や、SQL ServerのStandard Editionを使用していてEnterprise Editionの費用を負担したくない場合は、SANLess Clusteringソリューションを使用してデータレプリケーションをオーケストレーションすることができる。このアプローチは、アプリケーションに依存しないブロックレベルのデータレプリケーションサービスを提供するため、SANLessクラスタリングを使用してDRソリューションを構成すると、保護しようとしているすべてのアプリケーション（2008以降のSQLサーバーのすべてのエディションを含む）に関連付けられたデータのレプリケーションが保証される。実際、Microsoft SQL Server Enterprise Editionを使用している場合でも、SANLess Clusterを使用することをお勧めする。なぜなら、このアプローチのアプリケーションに依存しないという特性により、SQL Server Enterprise Editionに組み込まれているメカニズムよりも包括的なデータレプリケーションのメカニズムを確実に利用できるからだ。
本当に重要なアプリケーションに対し、地理的に分散したDRサポートを提供するように構成されたクラウドベースのインフラと、それらのアプリケーションが必要なデータに瞬時にアクセスして稼働できるように設計されたデータレプリケーションソリューションがあれば、ビジネス継続性を念頭に置いて設計された災害復旧ソリューションを実装することができるのだ。
写真提供： Olivier Le Moal/Shutterstock
Dave BerminghamはSIOS Technologyのシニア・テクニカル・エバンジェリストで、テクノロジーコミュニティ内で高可用性の専門家として認められており、過去11年間、Microsoft MVP（クラスターMVPとして6年、クラウドおよびデータセンター管理MVPとして5年）に選出される栄誉に浴している。Dave は多数の技術認定を取得しており、金融、医療、教育などの分野で30年以上のIT経験を持つ。
