IT（Office）基盤系システム

図に使用される表記の凡例
図に使用される表記の凡例

想定するシステム

「IT(Office)基盤系システム」を想定したソリューション例について解説します。
「IT(Office)基盤系システム」とは、企業内ユーザーがITシステムを業務利用する上での認証やファイル共有などの共通的な基盤システムであり、以下のような特徴を持つシステムを対象としています。
  • オフィス環境で利用するサーバーをクラウドサービスへ集約します。具体的には、以下のようなサーバーを配置することを想定しています。
    • AD（Active Directory）サーバー：社内のユーザーやホストの権利と権限を集中管理
    • WSUS（Windows Server Update Services）サーバー：社内Windowsホストの更新を集中管理
    • ウイルス対策管理サーバー：社内ホストのウイルス対策ソフトウェアを集中管理
    • ファイルサーバー：ファイル共有サーバー

システム構成

本システムは、DR（Disaster Recovery、災害復旧）対策を想定して、地理的に離れたメインサイトとDRサイトの2拠点から構成されます。以下では、メインサイトのシステム構成とDRサイトのシステム構成について説明します。

注釈

DRサイトとして利用できるリージョンについては、各リージョンで提供しているサービス を参照してください。


メインサイトのシステム構成

メインサイトでは、平時に稼働するシステムを収容しており、以下のような構成を想定しています。
  • 冗長化されたIT基盤系サーバーの展開
  • 10TB程度のファイルサーバーを配置

システム構成図は以下の通りです。
メインサイトのシステム構成
続いて、構成上のポイントをご説明します。

サーバーの物理レベルでの冗長構成

現在、企業活動はITを抜きには考えられず、IT基盤を構成する各種サーバーは、高い信頼性が求められます。
一般に、クラウドサービスが提供するサーバーインスタンスは、収容される物理ホストを指定することができません。そのため、複数のサーバーインスタンスで冗長化していても、同一の物理ホストに収容される可能性があります。この時に物理ホストの障害が発生した場合、冗長化しているサーバーインスタンスが同時にダウンし、サービス停止が発生することとなります。サーバーインスタンスは、作成時に収容される物理ホストの設備群（グループ）を指定することができます。そのため、異なるグループ上にサーバーインスタンスを作成し、冗長構成をとることで、収容物理ホストの分散を担保した物理レベルの冗長化が図れます。
物理レベルでの冗長構成

ファイルサーバー

冗長化されたファイルサーバーは、ブロックストレージが提供するボリュームを共有ディスクとしてiSCSIマウントすることで冗長構成をとることができます。これにより、サーバーのメンテナンスの際にもサービスの停止時間を最小化することができます。パフォーマンスについては、2IOPS/GBまたは4IOPS/GBの性能で、ファイルサーバーを構成できます。容量についても、使用状況によりボリュームを追加することができます。必要な容量を必要なタイミングで利用することで、コストの最小化を図れます。
バックアップは、Windows ServerのVSS（ボリューム・シャドウ・コピー・サービス）などを利用して、ファイルシステムのスナップショットを取得することを検討してください。
VSSスナップショット

DRサイトのシステム構成

災害等により、メインサイトに収容されたIT基盤サーバー群がダウンした場合、ADサーバーやファイルサーバーを利用できなくなるなどの影響が生じ、業務が停止することとなります。そのため、災害対策としてDRサイトを構築し、迅速に業務を再開するシナリオを検討する必要があります。ここでは、低コストでDRを実現するために、以下のような特徴を持つシステム構成例をご紹介します。
  • ADサーバー、ファイルサーバーなどはDRサイトにも構築・起動しておき、クラウド/サーバー リージョン間接続を通じたレプリケーションを実施し、負荷分散を行うと同時に、最新バックアップとなるようにする。
  • その他のWSUSサーバー、ウイルス対策管理サーバー等は、負荷分散目的があればDRサイトに構築しアクティブ化しておき、負荷分散目的がなければ通常時はボリュームのみの保存とし、DRサイトのコスト低減を図る。

システム構成図は以下の通りです。
DRサイトのシステム構成
続いて、構成上のポイントをご説明します。

サイト間のレプリケーション

ADサーバーにてメインサイトとDRサイト間で常時レプリケーションを行うと、定常的にサイト間でトラフィックが生じることとなります。このレプリケーション用のトラフィックを処理するために、クラウド/サーバー リージョン間接続を利用します。また、メインサイトのファイルサーバーの物理障害などによるデータ損失を防ぐために、DRサイトのファイルサーバーに対して定期的にデータ同期を行うことで、バックアップ目的でDRサイトを活用することも可能です。これにより、安価にサイト間で負荷分散およびDRを実現することができます。
サイト間のレプリケーション

DRサイトでのコールドスタンバイ

企業内のクライアントPCに対して定義ファイルを配信するためのウイルス対策管理サーバーなどについては、サービスが停止しても即時に業務が停止しない用途のサーバーについては、RTO（Recovery Time Objective、目標復旧時間）に多少の余裕があることがあり、ホットスタンバイ構成は不要です。
DRサイトにコールドスタンバイを構成するため、事前にサーバーインスタンス（インスタンス+ボリューム）の作成・設定をした後に、インスタンスを停止状態としておくことでインスタンス課金を最小化することができます。DR発生時にはインスタンスを起動することで、サービスを再開します。
また、DRサイトで設定したサーバーインスタンスからインスタンスを削除し、ボリュームだけの状態とすることで、インスタンスに対する課金をゼロにすることができます。この状態の時には、ライセンスサービスに対する課金も発生しません。DR発生時には、ボリュームをもとにインスタンスを作成し・起動することでサービスを再開します。DR時にインスタンス作成の手間がかかりますが、待機系サーバーインスタンスに関するコストはボリュームに対する課金のみとなり、ランニングコストを低減できます。
さらに、ボリュームのイメージ化することにより、イメージ管理を利用することが可能です。これにより、さらにランニングコストを最小化することができますが、DR発生時にボリュームイメージからのリストア処理が必要となるため、RTOが大きくなります。
Cost&RTO