中規模基幹系システム

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

想定するシステム

「中規模基幹系システム」を想定したソリューション例について解説します。
「中規模基幹系システム」とは、主に企業内のユーザーが利用する「業務系、財務/会計系システム」のうち、以下のような特徴を持つシステムを対象としています。
  • 24時間365日稼働。切り替わり時の短時間サービス断は許容される。
  • SPOF（Single Point of Failure、単一障害ポイント）は存在させず、冗長構成において物理分離を実施する。
  • RPO（Recovery Point Objective、目標復旧時点）は、極力0に近付ける。（REDOログ領域の消失時などの特定障害時には数時間～1日単位のバックアップ時点まで戻る）
  • 重要システムであり、災害時にも別拠点の社員が利用できるようにDR（Disaster Recovery、災害復旧）対策が必要。

システム構成

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

注釈

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


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

メインサイトでは、平時に稼働する基幹系システムを収容しており、以下のような構成を想定しています。
  • Web-AP/DBサーバーを1VMに同居させたサーバーシステム構成
  • 本番/検証/開発環境の3面運用。必要に応じて検証構成を追加作成
  • 長期保存データ用のアーカイブストレージ
  • データベースは夜間バッチ時間を十分に取るために、ストレージ機能を使い数分間でバックアップ処理を完了

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

DBMS構成

DBサーバーは、Web-APサーバーと一体のサーバーインスタンスとして構築します。ベアメタルサーバーは、即時利用開始可能ですので、納期等を気にすることなく、構築開始が可能です。
以下の図は、ベアメタルサーバー上にvSphere環境を構成した場合の概要を示しています。ベアメタルサーバー上にESXiをインストールし、DataStore用に作成したブロックストレージをESXiからiSCSIでマウントすることで、VMwareのVM環境を構築することができます。また、これらのESXiホストをvCenter Serverから統合制御することで、お客さま独自のvSphere環境を構成することができます。これにより、従来はオンプレミスでサーバーやストレージ機器を調達・構築していたvSphere環境を、プライベートクラウド環境として迅速に導入することができます。
DBMS構成
Web-AP/DBサーバーは、仮想化基盤上のVMとして稼働し、Web-AP/DBサーバーのシステム領域やAPモジュールは、VMの内蔵ディスク（仮想ディスク）に保存されます。
Web-AP/DBサーバーのシステム領域やAPモジュールの保護を考えた場合、仮想化プラットフォームが提供するHA機能(vSphere HAなど)やLive Migration機能(vMotionなど)を活用することで、システムの可用性・信頼性の向上をはかります。システムの重要性に応じて、収容ホストの分離やホストの冗長度(N+1構成, N+2構成など)もお客さまにて調整することが可能です。ここでは、本番環境用環境と検証・開発用環境を異なるベアメタルサーバー上に物理分散し、さらにフェイルオーバーホストとして予備機のベアメタルサーバーを構成しています。
ストレージ面については、ベアメタルサーバーが複数の物理NICを持っているため、iSCSI Multipathを構成することで、パスの冗長性を確保することができます。また、仮想化プラットフォームが提供するSnapshot機能やテンプレート/クローン機能、VADP（VADP: vStorage APIs for Data Protectionなど）に対応したバックアップソリューションを用いることで、Web-AP/DBサーバーのシステム領域やAPモジュールのバックアップを取得することができます。
また、ロジカルネットワークを作成する際に、データプレーンとストレージプレーンから選択することができます。ストレージプレーンのロジカルネットワークは、データプレーンのロジカルネットワークと物理的に分離された構成で提供される、ベアメタルサーバー・ストレージ間通信専用のロジカルネットワークです。そのため、データプレーンのトラフィック状況に左右されない通信が可能です。ベアメタルサーバーとLUN（Logical Unit Number、サーバーから1台の物理ハードディスクとして認識される単位）との間の通信にストレージプレーンのロジカルネットワークを活用いただくことで、データ通信のトラフィック急増時などにも安定したストレージ利用が可能となります。
なお、Web-AP/DBサーバーのデータ領域は、データストア用とは異なるLUNに保存します。データ領域の保護については後述します。

注釈

ESXiなどのハイパーバイザやvCenterなどの管理用サーバーなどの仮想化基盤の設計・構築・運用はお客さま作業です。また、サーバーインスタンス上で稼働するゲストOS、ミドルウェア、アプリケーションなどのソフトウェアライセンスの調達・管理もお客さまにて実施いただく必要があります。


データベースストレージ構成

Web-AP/DBサーバーのデータ領域は、ブロックストレージが提供するLUNの上に保存します。このLUNは、VM上のゲストOS上で動作するiSCSIイニシエータを用いてマウントすることにより利用します。先述のDataStore用LUNをESXiホストからマウントする方式とは異なることに注意してください。
データベースを構成するファイルの用途ごとに異なるLUNを構成することができます。LUNを構成する際には、ブロックストレージのグループを活用します。グループはブロックストレージの筐体が収容される設備群を識別するための概念であり、異なるAGのSANストレージからそれぞれLUN を作成することで、2つのLUNが異なる物理機器（媒体・装置）上に構成されていることを担保することが出来ます。そこで、異なるグループ上にLUNを構成して、物理障害への対応を図ります。
データベースストレージ構成

データファイル
データファイルは、ランダムなスモールIOが発生するという特徴があり、大規模なDBになるほど大きなパフォーマンスが求められます。パフォーマンス管理の観点では、LUNは当初2IOPS/GBの性能となるため、Web-AP/DBサーバーの負荷に応じたIO性能を発揮することができます。
容量管理の面では、システムの成長に伴うデータの肥大化によってLUN容量が枯渇するというシナリオが考えられます。この場合には、より容量の大きな2つ目のLUNを追加・マウントしてから、DBMSでのデータファイル移動やOracle ASMのようなボリューム管理機能でのデータ移動を行うことで、容量枯渇に対応できます。
データファイルの移行

注釈

構成済みのLUNの容量拡張はできません。例えば、100GBで作成したLUNを、後から250GBに拡張することはできません。


トランザクションログファイル
データベースでは、障害に備えてトランザクションログのデータ配置も重要です。ここでは、OracleにおけるREDOログファイルの管理を想定したストレージ設計について説明しています。
オンラインREDOログファイルは、物理障害に対応するために、異なるディスク領域に対して多重化して保存する必要があります。そこで、異なるAG上で構成したLUNをまたいでREDOロググループを構成し、ストレージ筐体が異なるLUN上にオンラインREDOログファイルを分散して配置します。
トランザクションログの物理障害対応

注釈

REDOログファイルはストレージの性能が求められます。そのため、ログファイルサイズによる容量要件だけでなく、性能要件も考慮したLUNのサイジングが必要です。


制御ファイル
制御ファイルは、複数のディスクに分散した配置が必要となります。そこで、ブロックストレージ上やサーバーインスタンスにアタッチされたボリューム(内蔵ディスク)上に多重化して制御ファイルを保存することで、ストレージの物理障害を回避することができます。

バックアップファイル
RMAN等のツールを用いてデータベースのバックアップを行う場合、バックアップの出力先としてサーバーインスタンスにアタッチされたボリューム(内蔵ディスク)を指定することで、ブロックストレージと物理的に分散することができ、ストレージ障害発生時にバックアップファイルにアクセスできなくなる事態を回避できます。
データベースのバックアップ

検証環境の構築と本番データの再現

トラブル解析の際には、常設の検証環境だけでなく、追加で検証環境を手配したい場合があります。このようなシナリオにおいても、迅速に環境を構築することができます。
検証用のWeb-AP/DBサーバーといったベアメタルサーバー上で稼働するVMについては、仮想化プラットフォームのテンプレート/クローン機能を用いることによって、常設検証環境から臨時検証環境へのVMの複製が可能です。同様に、サーバーインスタンスで稼働するジョブ管理用などのVMについては、サーバーインスタンスが提供するVMのイメージ化機能を使い、常設検証環境から臨時検証環境へのVMの複製が可能です。
また、本番環境でのトラブル解析のために、本番データをそのまま用いた検証環境を構築したいことがあります。システム領域やAPモジュールについては、本番環境のベアメタルサーバーのクローン機能やサーバーインスタンスのデータ保存用内蔵ディスクをイメージ化機能を活用することで、検証環境上に複製することができます。
一方、DBのデータ領域については、DBのデータファイルを格納するSANストレージのLUNを直接的にイメージ化することができません。この場合は、ロジカルネットワークを本番環境から検証環境に延伸することで対応します。この機能を利用して、一時的に延伸したロジカルネットワークを経由してファイルサーバー等にDBのデータをエクスポートします。次に複製したAP/DBサーバーからDBのデータをインポートすることで、商用データのサルベージを行うことができます。これにより、短時間で検証環境に同じDB内容を再現することが可能となります。
検証環境の構築と本番データの再現

アーカイブデータ保存

基幹系等の社内の重要システムではアーカイブデータの長期保存が必要となります。アーカイブデータは、日々蓄積されるため、スループットやIOPSではなく、大容量を低価格に保存することが求められます。PB（ペタバイト）級の大容量データの保存には、Cloudn Object Storageの利用が適しています。
Cloudn Object Storageは、インターネット上ではありますが、Bizシンプルディスクよりも低コストで保存することができます。また、Cloudn Object StorageはAmazon S3互換のREST APIを提供しています。そのため、s3fsなどのツールを用いることでファイルシステムとしてマウントすることができ、アーカイブサーバーから見た場合、Cloudn Object Storageをあたかも1つのファイルシステムとして見せることができます。これにより、使い勝手を損なうことなくCloudn Object Storage上にデータを保存することができます。
なお、インターネット接続は、1テナント上に複数契約することができます。サービス用のインターネット接続と、Cloudn Object Storage用のインターネット接続を別に契約することにより、大容量データ保存用の通信がサービス用通信に影響を与える事態、ないしその逆の事態を防ぐことができます。

注釈

Cloudn Object Storageは、日本国内のみの提供です。


DRサイトのシステム構成

メインサイトでの災害発生時には、メインサイトからDRサイトにシステムを切り替えが必要です。
DR構成を組むにあたって、平時おいてはメインサイトで生成される本番データを適宜DRサイトに転送しておき、災害発生時にはDRサイトで転送済みのデータをリストアすることで、サイトを切り替えます。これにより、災害発生時においても迅速に業務を復旧・継続させることができます。

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

サーバーインスタンスを用いて構成しているアーカイブサーバーやバッチ処理サーバーは、イメージ化機能を用いることにより、サーバーインスタンスのボリューム（システムディスクおよびデータディスク）をイメージ保存領域に保存することができます。作成したボリュームイメージはAPI/GUIを用いてインポート/エクスポートすることができます。なお、この作業はインターネットを経由して行う必要があります。
上記の機能を利用して、定期的にメインサイトでボリュームイメージの作成を行い、エクスポートした後に改めてDRサイトにインポートしておきます。一連の作業間隔を短くすることで、RPOの短縮化を図ることができます。
災害発生時には、インポート済みのボリュームイメージを用いることで、迅速にDRサイトでサーバーインスタンスの作成を図り、RTOの短縮を図ります。

注釈

ボリュームイメージにソフトウェアライセンスサービスが紐づいている場合、当該ボリュームイメージはエクスポートができません。

ボリュームのイメージコピー

ベアメタルサーバー上で稼働するVMは、仮想化プラットフォームが提供するDRソリューションを活用することができます。これにより、ベアメタルサーバー上で稼働するVMの保護を実現します。例えば、vSphere環境においては、vSphere Replicationを用いて、ハイパーバイザレベルでの拠点間レプリケーションを実現できます。

注釈

DataStore用のSANストレージには、LUN Snapshotの転送機能がありません。そのため、VMware vCenter SRM(Site Recovery Manager)のアレイベースのレプリケーションに対応していません。


拠点間のレプリケーション用のトラフィックは、Arcstar Universal Oneやインターネットを利用することもできますが、業務用のVPNやインターネットのトラフィックとの共用を避けるため、クラウド/サーバー リージョン間接続の利用を推奨します。クラウド/サーバー リージョン間接続はベストエフォートではありますが、無償で利用することができます。

注釈

ベアメタルサーバー上に構築した仮想環境によるサイトリカバリー構成の設計・構築・運用は、お客さまにて実施いただく必要があります。

拠点間のリカバリー構成
ただし、サーバーインスタンスのサイトリカバリー構成においては、Web-AP/DBサーバーのようにブロックストレージ上のLUNをマウントしている場合は、LUN上のデータは保護対象になりません。そのため、このような場合にはDRサイトでもサーバーインスタンスを常時稼働しておき、LUN上のデータは後述の通り、別の方法で同期をとります。

Web-AP/DBサーバーのデータ領域は、SANストレージのLUN上に保存されています。このDBのデータ領域は、（Oracle Data Guardなどを用いて）メインサイトとDRサイトのWeb-AP/DBサーバー間で常に同期をとることでDRを実現します。同期用トラフィックの転送には、クラウド/サーバー リージョン間接続を無償で利用できます。
DBミラーリング/レプリケーション

Cloudn Object Storageは、複数データセンタにまたがった3分散のデータ保管による冗長化を図っています。これにより、Cloudn Object Storageは99.999999999％（eleven nine）の信頼性を達成しています。アーカイブデータの保存にこれらの外部サービスを利用することでメインサイトにサイト障害が発生したとしても、アーカイブデータの損失を防ぐことができます。
なお、アーカイブデータの保存は、Cloudn Object Storageはインターネット経由で行います。

注釈

Cloudn Object Storageは、日本国内のみの提供です。


DRサイトへのデータ移行とリストア処理が完了したら、ユーザーからのアクセス経路を切り替える必要があります。特に、基幹系システムにおいてはVPNを経由したアクセスが想定されるため、VPNのアクセス経路を円滑に変更することが必要となります。この切り替えには、以下の2つのパターンを用いることができます。
  • 平時からDRサイトの各ノードには新たなプライベートIPアドレスを割り振っておき、予めVPNを接続しておきます。DR発動時には、社内で利用されている内部用のDNSレコードを変更し、ユーザーからの接続先をメインサイトからリカバリサイトへの切り替えます。切り替え先のプライベートIPアドレスが確定しているので、ゾーンファイルや変更スクリプトを平時から予め準備しておくことで、切り替え作業をスムーズに実施することができます。
  • 事前に、DRサイトで、サービス面にメインサイトと同じプライベートIPアドレスを割り振った、レプリカ構成を構築しておきます。この時、DRサイトでは経路広告をしていないため、メインサイト/DRサイトそれぞれで同一アドレスが割り振られていても、通信に異常をきたすことはありません。メインサイトの異常時には、予め用意しておいたAPIを用いて、DRサイトから経路を広告することにより、通信をDRサイトへ誘導することができます。
また、インターネット接続も、10Mbpsベストエフォートメニューであれば無料または安価に利用することができるため、事前にインターネット接続を行っておきます。あわせて、必要な数のグローバルIPアドレス（有料）を確保しておくことで、グローバルIPアドレスを含めたパラメータを確定することができます。これにより、DR発動の際の切替手順を事前に作成することが容易になります。