ハイ アベイラビリティの仕組み
HA の導入には、2 台の Prime Infrastructure サーバ(プライマリとセカンダリ)が必要です。これらのサーバのそれぞれに、アクティブ データベースとアクティブ データベースのスタンバイ バックアップ コピーがあります。通常状態では、プライマリ サーバがアクティブです。つまり、プライマリ サーバが自身のアクティブ データベースに接続されており、ネットワークを管理します。セカンダリ サーバはパッシブ状態で、自身のスタンバイ データベースのみに接続されていますが、プライマリ サーバとは継続的な通信状態にあります。
両方のサーバで実行されているヘルス モニタ プロセスにより、お互いのサーバのステータスがモニタされています。両方のサーバ上で実行されている Oracle Recovery Manager(RMAN)は、アクティブ データベースおよびスタンバイ データベースを作成し、変更の発生時には、プライマリ サーバで実行される Oracle Data Guard Broker の効果によりデータベースを同期します。
プライマリ サーバに障害が発生すると、セカンダリが引き継ぎ、自身のアクティブ データベースに接続します。このデータベースは、アクティブ プライマリ データベースと同期されています。この切り替えは「フェールオーバー」と呼ばれ、手動(推奨)または自動でトリガーできます。その後は、プライマリ サーバへのアクセスの復元作業をしながら、セカンダリ サーバを使用してネットワークを管理します。プライマリ サーバが再度使用可能になると、プライマリ サーバに戻するための切り替え(「フェールバック」)を開始し、プライマリを使用してネットワーク管理を再開できます。
プライマリ サーバとセカンダリ サーバを同一 IP サブネットに導入する場合は、1 つの仮想 IP アドレスで Prime Infrastructure に通知を送信するようにデバイスを設定できます。ディザスタ リカバリの実施などの目的で、2 台のサーバを地理的に離れた位置に分散する場合は、両方のサーバに通知を送信するようにデバイスを設定する必要があります。
プライマリ サーバとセカンダリ サーバについて
すべての Prime Infrastructure HA 実装には、プライマリ サーバの特定のインスタンスに対して専用のセカンダリ サーバが 1 台のみ必要です。
通常、HA サーバごとに独自の IP アドレスまたはホスト名が設定されています。同一サブネット上に配置されているサーバは、仮想 IP を使用して同じ IP を共有できます。これにより、デバイスの設定が容易になります。
HA をセットアップした後は、HA サーバの IP アドレスやホスト名を変更しないください。変更すると、HA 設定が失われます(「関連項目」の「サーバの IP アドレスまたはホスト名のリセット」を参照)。
障害の原因
Prime Infrastructure サーバの障害は、以下の 1 つ以上の分野での問題が原因で発生する可能性があります。
- アプリケーション プロセス:NMS サーバ、MATLAB、TFTP、FTP を含め、1 つ以上の Prime Infrastructure サーバ プロセスが失敗した場合。各アプリケーション プロセスの動作ステータスを確認するには、管理コンソールから ncs status コマンドを実行します。
- データベース サーバ:1 つ以上のデータベース関連のプロセスがダウンした場合。データベース サーバは、Prime Infrastructure 内のサービスとして実行されます。
- ネットワーク:ネットワーク アクセスの問題や、到達可能性の問題が発生した場合。
- システム:サーバの物理ハードウェアまたはオペレーティング システムに関連する問題が発生した場合。
- 仮想マシン(VM):プライマリ サーバとセカンダリ サーバがインストールされている VM 環境に問題が発生した場合(HA が VM 環境で稼動している場合)。
詳細については、「ハイ アベイラビリティの仕組み」を参照してください。ハイ アベイラビリティの仕組み
ファイルおよびデータベースの同期
HA コンフィギュレーションが、プライマリ サーバでの変更を判別すると、常にその変更がセカンダリ サーバに同期されます。これらの変更には、次の 2 種類があります。
- データベース:コンフィギュレーション、パフォーマンス、およびモニタリング データに関連するデータベースの更新などです。
- ファイル:コンフィギュレーション ファイルに対する変更などです。
両方のサーバ上で実行されている Oracle Recovery Manager(RMAN)は、アクティブ データベースおよびスタンバイ データベースを作成し、変更の発生時には、プライマリ サーバで実行される Oracle Data Guard Broker の効果によりデータベースを同期します。
ファイルの変更内容は、HTTPS プロトコルを使用して同期されます。ファイルの同期は、以下のいずれかの方法で行われます。
- バッチ:このカテゴリには、頻繁に更新されないファイル(ライセンス ファイルなど)が含まれます。これらのファイルは、500 秒間隔で同期されます。
- ほぼリアルタイム:頻繁に更新されるファイルは、このカテゴリに分類されます。これらのファイルは、11 秒間隔で同期されます。
デフォルトでは、HA フレームワークは、必要なすべての構成データをコピーするように設定されます。これらの構成データには、以下が含まれます。
- レポート設定
- 設定テンプレート
- TFTP ルート
- 管理設定
- ライセンス ファイル
HA サーバ通信
プライマリおよびセカンダリ HA サーバは、HA システムのヘルスを維持するために、次のメッセージを交換します。
- データベース同期:プライマリ サーバとセカンダリ サーバ上のデータベースが稼働および同期するために必要なすべての情報が含まれます。
- ファイル同期:頻繁に更新されるコンフィギュレーション ファイルが含まれます。これらのファイルは 11 秒間隔で同期され、他の頻繁に更新されないコンフィギュレーション ファイルは 500 秒間隔で同期されます
- プロセス同期:アプリケーションおよびデータベースに関連するプロセスの実行が継続されるようにします。これらのメッセージは、ハートビート カテゴリに分類されます。
- Health Monitor 同期:これらのメッセージは、以下の障害状態の有無を確認します。
- ネットワーク障害
- システム障害(サーバ ハードウェアとオペレーティング システムでの障害)
- ヘルス モニタ障害
ヘルス モニタ プロセス
Health Monitor(HM)とは、HA 操作を管理する主要コンポーネントです。プライマリ サーバとセカンダリ サーバでは、それぞれ別個の HM インスタンスがアプリケーション プロセスとして実行されます。HM は、以下の役割を果たします。
- HA に関連するデータベースおよび構成データを同期します(Oracle Data Guard を使用して別途同期されるデータベースは除きます)。
- プライマリ サーバとセカンダリ サーバの間で 5 秒間隔でハートビート メッセージを交換し、サーバ間の通信が維持されていることを確認します。
- 両方のサーバ上で使用可能なディスク容量を定期的に確認し、ストレージ容量が不足している場合にはイベントを生成します。
- リンクされた HA サーバ全体のヘルスを管理、制御、モニタします。プライマリ サーバで障害が発生した場合にセカンダリ サーバをアクティブ化するのは、Health Monitor の役目です。
ヘルス モニタ Web ページ
Health Monitor Web ページを使用して HA の動作を制御します。プライマリ サーバまたはセカンダリ サーバで実行される Health Monitor インスタンスごとに、専用の Web ページがあります。次の図に、「プライマリ アクティブ」状態と「セカンダリ同期中」状態にあるセカンダリ サーバのヘルス モニタ Web ページの例を示します。
1 |
[設定(Settings)] 領域に、ヘルス モニタの状態と設定の詳細情報を示す 5 つのセクションが表示されています。 |
2 |
[ステータス(Status)] は、HA セットアップの現在の機能ステータスを示します(緑色のチェック マークは、HA がオンであり機能していることを示します)。 |
3 |
[フェールオーバーの準備状況の確認(Check Failover Readiness)] フィールドに、チェックリスト項目のシステム フェールバックの値とシステム フェールオーバーの詳細が表示されます。 詳細については、表の下の「フェールオーバーの準備状況の確認」を参照してください。 |
4 |
[プライマリ IP アドレス(Primary IP Address)] は、このセカンダリ サーバのピア サーバの IP を示します(プライマリ サーバの場合、このフィールドには [セカンダリ IP アドレス(Secondary IP Address)] というラベルが付いています)。 |
5 |
[イベント(Events)] 表には、現在のすべての HA 関連イベントが最新のイベントを先頭に時系列順に表示されます。 |
[6] |
[メッセージ レベル(Message Level)] フィールドでは、ログ レベル([エラー(Error)]、[情報(Informational)]、[トレース(Trace)])を変更できます。ログ レベルを変更するには、[保存(Save)] をクリックする必要があります。 |
7 |
[ロギング ダウンロード(Logging Download)] 領域では、ヘルス モニタ ログ ファイルをダウンロードできます。 |
8 |
[状態(State)] は、この Health Monitoring インスタンスが実行されているサーバの現在の HA の状態を示します。 |
9 |
[フェールオーバー タイプ(Failover Type)] は、設定されているフェールオーバー タイプ([手動(Manual)] または [自動(Automatic)])を示します。 |
10 |
表示している Health Monitor Web ページの対象 HA サーバを示します。 |
11 |
[アクション(Actions)] は、実行できるアクション(フェールオーバーまたはフェールバック)を示します。[アクション(Actions)] のボタンは、HA 状態の変更が必要なアクションが Health Monitor により検出された場合にだけ有効になります。 |
チェックリスト名 |
説明 |
---|---|
システム - ディスク IOPS の確認(SYSTEM - CHECK DISK IOPS) |
プライマリ サーバとセカンダリ サーバの両方でディスク IOPS を検証します。 必要な最小ディスク IOPS は 200 Mbps です。 |
ネットワーク - ネットワーク インターフェイスの帯域幅確認(NETWORK - CHECK NETWORK INTERFACE BANDWIDTH) |
プライマリ サーバとセカンダリ サーバの両方で eth0 インターフェイス速度が推奨速度の 100 Mbps と一致するかどうかを確認します。 このテストでは、プライマリ サーバとセカンダリ サーバ間でのデータ送信によるネットワーク帯域幅の測定は行いません。 |
データベース - 同期ステータス(DATABASE - SYNC STATUS) |
プライマリ データベースとセカンダリ データベースを同期する Oracle Data Guard Broker の設定を確認します。 |
HA での仮想 IP アドレッシングの使用
通常の状況下では、Prime Infrastructure を使用して、管理対象デバイスがその syslog、SNMP トラップ、およびその他の情報を Prime Infrastructure サーバの IP アドレスに送信するように設定します。HA を実装する場合、それぞれ異なる IP アドレスを持つ 2 台の Prime Infrastructure サーバが導入されます。プライマリ サーバと同様にセカンダリ サーバにも通知を送信するようにデバイスを再設定しないと、セカンダリ Prime Infrastructure サーバがアクティブ モードになったときに、セカンダリ サーバではすべての通信が受信されません。
管理対象デバイスすべてで 2 台の別個のサーバに通知を送信するよう設定する場合、追加のデバイス設定作業が必要です。この追加のオーバーヘッドを回避するため、HA では両方のサーバが管理アドレスとして共有できる仮想 IP アドレスの使用がサポートされています。フェールオーバー プロセスとフェールバック プロセスの実行中に、この 2 台のサーバは必要に応じて IP を切り替えます。仮想 IP アドレスは常に、正しい Prime Infrastructure サーバを指し示します。
両方の HA サーバのアドレスおよび仮想 IP がすべて同じサブネット上にない場合、仮想 IP アドレッシングを使用できないことに注意してください。これは、HA サーバ導入の選択方法に影響する可能性があります(「関連項目」の「HA の導入計画」および「ローカル モデルの使用」参照)。
また、仮想 IP アドレスを 2 つのサーバ IP アドレスの代わりとして使用することは一切意図されていないことに注意してください。仮想 IP は、syslog やトラップなど Prime Infrastructure サーバに送信されるデバイス管理メッセージの宛先として使用されます。デバイスのポーリングは、2 つの Prime Infrastructure サーバ IP アドレスのうちの 1 つから常に実施されます。このことを考慮すると、仮想 IP アドレッシングを使用している場合、3 つすべてのアドレス(仮想 IP アドレスおよび 2 つの実際のサーバ IP)における着信および発信 TCP/IP 通信に対してファイアウォールを開く必要があります。
オペレーション センターでの HA の使用を計画している場合、仮想 IP アドレッシングを使用することもできます。オペレーション センターが有効になっている Prime Infrastructure インスタンスに仮想 IP を SSO として割り当てることができます。オペレーション センターを使用して管理されているインスタンスには、仮想 IP は必要ありません(「オペレーション センター用の HA の有効化」を参照)。
プライマリ サーバでの HA の登録時に仮想 IP アドレッシングを有効にできます。そのためには、この機能を使用する旨を指定し、プライマリ サーバとセカンダリ サーバで共有する仮想 IPv4(必要な場合は IPv6)アドレスを入力します(「プライマリ サーバでの HA の登録方法」を参照)。
仮想 IP アドレッシングを有効化した後に仮想 IP アドレッシングを削除するには、HA を完全に削除する必要があります(「GUI での HA の削除」を参照)。
ホット スタンバイ動作
プライマリ サーバがアクティブ状態のとき、セカンダリ サーバは、プライマリ サーバと常時同期状態にあり、高速で切り替えができるように、すべての Prime Infrastructure プロセスを実行しています。プライマリ サーバに障害が発生すると、セカンダリ サーバがフェールオーバー後 2 ~ 3 分以内にアクティブなロールを素早く引き継ぎます。
プライマリ サーバでの問題が解消され、プライマリ サーバが実行状態に戻ると、プライマリ サーバがスタンバイ ロールになります。プライマリ サーバがスタンバイ ロールになると、ヘルス モニタの GUI には「プライマリ同期中(Primary Syncing)」状態が表示され、プライマリ サーバ上のデータベースおよびファイルとアクティブなセカンダリ サーバとの同期が開始されます。
プライマリ サーバが再度使用可能になり、フェールバックがトリガーされると、再度プライマリ サーバがアクティブ ロールを引き継ぎます。このようなプライマリ サーバとセカンダリ サーバ間でのロールの切り替えは、2 ~ 3 分以内に実行されます。