IPVマルチサイト(リージョン)アーキテクトガイド¶
IPVでは、複数のOrg(以降、サイトと表記)もしくはリージョンを用いたOvDC(以降、テナントと表記)連携を行うことが可能です。
マルチサイト環境では、サービスアプリケーションの検証/開発用途と本番用途でサイト連携して構築することが可能です。
これにより検証/開発内容の本番反映をマルチサイト構成環境内に閉じて行う事が可能となります。
マルチリージョン環境では、DB等のコア業務システムコンポーネントを双方に配備しておくことで障害時の信頼性影響を最小にすることが可能となります。
そのため、事業継続性やシステム信頼性が求められる場合にはマルチリージョン構成を採用することを推奨します。
この設計方針では以下のディザスター リカバリー(以降、DRと表記)アーキテクトモデルに対応することが可能です。
| DRアーキテクト | 概要/採用メリット |
|---|---|
| バックアップ/リストア | 定期的にシステムのバックアップ(レプリケーション)をサブサイトへ取得転送し、有事の際はそのバックアップから復旧する方式
・最小コストでの実現
■デメリット
・バックアップ取得後のデータ変更差分が発生
・業務システム復旧のために運用手順の確立、訓練が必要
|
| ウォームスタンバイ | 複数のサイト/テナント双方にコアとなる業務システム(DB等)を縮小構成を構築しデータ同期する方式
・コア業務システムに対して最も適切な性能とスループットを実現
■デメリット
・バックアップ/リストアと比較しコスト増
・コア業務システム以外の構築が必要となるためバックアップ/リストア等と組み合わせる必要がある
・業務システム復旧のために運用手順の確立、訓練が必要
|
| マルチサイト(アクティブ-アクティブ) | 複数のサイトを構築する方式
・構築システムに対して最も適切な性能とスループットを実現
・構築システムのデータ差分のみのため切り替え時はDNS変更等のみとなり復旧が容易
■デメリット
・コスト増
|
本ガイドではマルチサイト(リージョン)構成で各DRアーキテクトモデルを実現するための概要を記載致します。
本ガイドに記載するDRアーキテクトモデルを実現する上で次の考慮事項が存在します。
- マルチリージョン化を行うべきかどうか
各リージョンは異なるデータセンターで構成されており、地理的に離れた場所にあります。
これにより、停電、フラッディング、その他の局所的な混乱などの災害イベントに対して、別々の異なる場所にある複数のデータセンターを利用することによりビジネス保証が提供されます。
- プライマリおよびスタンバイ環境間でのデータおよびシステム構成を同期する方法
バックアップ戦略が重要となり、仮想マシンインスタンス(以降、VMと表記)レベルでの同期を採用するか、業務データに重きを置いた同期を採用するかにより選択肢が変わります。
IPVにて提供しているVMware Cloud Director Availability(以降、vCDAと表記)を使用しVMレベルでの同期を実現することが可能です。
ただし、vCDAはVMレベルの同期を提供する機能であるため、VM上の業務データの同期には不向きな点もあります。
例えばデータベースやメールサーバーなどのトランザクションアプリケーションが含まれている場合、アプリケーションを静止し、実行に適した状態にすることでアプリケーション整合性が担保されます。
これに対し、vCDAの処理方式は仮想マシンディスクフォーマット(VMDK)ファイルを同期する方式となりVM上の業務データに注力を置く場合には適していません。
VM上の業務データの同期を重要視する場合にはVM内にバックアップエージェントを導入する形式のバックアップ製品と組み合わせることが推奨となることがあります。
※ IPVが提供しているバックアップ機能であるCohesity Data Protectionではリージョン間へバックアップデータの同期を行う事ができません。
- ネットワークトラフィックまたはWeb等のサービストラフィックを迂回する方式
複数のサイト/テナント間にて各種ネットワークトラフィックをどの様に迂回するかが重要となります。
広域負荷分散(Global Server Load Balancing[以降、GSLBと表記])を活用しリージョン間を迂回する方法があります。
この場合、以下の経路について考える必要があります。
・ポリシーベースルーティング … サービストラフィックに重み付けを行い、設定したポリシーに従ってトラフィックを分散させることができます。
・優先順位によるルーティング … ルーティング経路に優先順位を付与しエンドポイントの正常性チェックに基づいてルーティングを行うことで分散します。
各トラフィックに応じてローカルDNSの配備、公開DNSサービスへの登録等を考慮する必要があります。
DNSの考慮事項は以下となります。
・DNS_Aレコード … Aレコードは、ドメインをIPアドレスに置き換えるレコードです。
・DNS_CNAME等 … 別のドメインのエイリアスを提供します。
また、マルチサイトでのOvDC内論理ネットワークを組む際にも適切に設計する必要があります。
サイト/テナント内論理ネットワークを構成する上での留意事項には以下があります。
DRアーキテクトモデル概要¶
バックアップ/リストア(サイトバックアップ)¶
IPVが提供しているマイグレーション機能「vCDA」により実現することが可能です。
VMレベルのサイト間バックアップには「vCDA」マイグレーション機能を使用し、DRサイト側一次領域にVMデータを保存しておきます。
本番環境の障害時にDRサイト側に保存されたVMデータをDRサイトにデプロイすることで業務サービス復旧が行えます。
本アーキテクトは障害発生から復旧に時間を要するため復旧効率は悪くなります。
そのため復旧時に更新差分の影響が少ないシステム、サービスアプリケーションにて採用することを推奨します。
各環境のバックアップ用途として本モデルが採用可能です。
ウォームスタンバイ¶
IPVが提供しているレプリケーション機能「vCDA」とSDPF クラウド/サーバー-ミドルウェア「Arcserve Unified Data Protection」を組み合わせることにより実現することが可能です。
本アーキテクトは本番環境のデータは最新を保っており、対向環境のデータはレプリケーションにより一定間隔で連携されます。
なお、VMレベルのデータ同期と合わせて業務データを「Arcserve Unified Data Protection」にて転送しておくことでより最新の状態を復元することが可能です。
この際、本番環境に配備されたサービスは稼働状態となりますが、対向環境のサービスはアイドル状態となります。
対向環境のコストを抑えるためには対向環境に配備するサービスをデプロイせずにvCDA内に保管しておくことを推奨します。
但し、最新の状態を維持する必要がある場合には本番環境の災害イベントによっては最新のデータ状態を取得できないことから他の仕組みと組み合わせる必要があります。
※ 災害イベント前の同期状態には戻すことが可能です。
検証/開発環境用途として本モデルが採用可能です。
マルチサイト(アクティブ-アクティブ)¶
マルチサイトアーキテクチャは、2つ以上のリージョンがアクティブにリクエストを受け付けます。
本アーキテクトはContents Delivery Network(CDN)やApplication Delivery Controller(ADC)を用いて各リージョン環境でデータを最新に保ちます。
これにより突発的な災害イベントにおいてもサービスの継続性が保証され、サービス中断等のイベント影響を最小限に抑えられます。
マルチサイトでは各リージョンの状態組み合わせにより組み合わせるべき機能が異なってきます。
アクティブ-アクティブでは同一環境の手配が必要となるため構築/維持管理コストも増大します。
これに際しアクティブ-スタンバイでは対向環境はコストを抑えるため一部コアサービスを除きライブ状態を維持せずにレプリケーションにすることでコストを抑えることが可能です。
上記と合わせ、GSLB等を用いてサービスリクエストに対応する必要があります。
DR用途として本モデルが推奨となりますが、上述のモデルを組み合わせてDR構成とすることも可能です。