|
|
サーバ インスタンスの障害は、さまざまな出来事によって引き起こされます。1 つの障害が別の障害のきっかけになることも少なくありません。停電、ハードウェアの故障、オペレーティング システムのクラッシュ、ネットワーク パーティション、アプリケーションの予期しない動作は、いずれもサーバ インスタンスの障害の一因になり得ます。
Oracle Communications Converged Application Server では、障害発生時の影響を最小限に抑えるための基盤として、高度にクラスタ化されたアーキテクチャを使用しています。ただし、個々のサーバまたはサーバマシンに障害が発生した場合にそなえて、クラスタ環境でも適切な回復プロセスを用意しておく必要があります。
以下の節では、Oracle Communications Converged Application Server の障害回避機能と回復機能をまとめたものであり、Oracle Communications Converged Application Server ドメインのさまざまな部分を復元するため必要なコンフィグレーション アーティファクトを説明します。
Oracle Communications Converged Application Server およびその基盤である WebLogic Server プラットフォームでは、サーバを障害から保護する多くの機能を提供します。プロダクション システムでは、継続的なサービスを保証するためにすべての利用可能な機能を使用する必要があります。
Oracle Communications Converged Application Server は、デプロイ済みの SIP サーブレットのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出し、あらかじめ定義された負荷のしきい値に達するとメッセージの処理を自動的に規制します。
過負荷保護を使用すると、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する障害を回避することができます。
Oracle Communications Converged Application Server は、以下のような特定の状況が発生したときに障害の回避を試みます。
詳細については、『コンフィグレーション リファレンス マニュアル』の「overload」を参照してください。
基盤となる WebLogic SIP Server プラットフォームは、デプロイ済みアプリケーションのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出します。WebLogic Server ではあらかじめ定義されたロードのしきい値で自動的に発生する障害回避アクションのコンフィグレーションを管理者に許可します。自動過負荷保護を使用すると、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する以下のような障害を回避することができます。
詳細については、Oracle WebLogic Server 10g Release 3 ドキュメントの「過負荷の回避と管理」を参照してください。
専用のクラスタで複数のエンジン層サーバを使用すると共に、専用の SIP データ層クラスタで複数の SIP データ層サーバ (レプリカ) を使用することにより、アプリケーションの信頼性と可用性を向上させることができます。エンジン層クラスタはアプリケーションに関するステートフルな情報を保持しないので、エンジン層サーバで障害が起きてもデータが失われたり呼が切断されたりすることはありません。SIP データ層パーティションの複数のレプリカには呼状態情報の冗長コピーが保存され、1 つのレプリカで障害が起きると相互に自動的にフェイルオーバされます。
詳細については、『コンフィグレーション ガイド』の「Oracle Communications Converged Application Server アーキテクチャの概要」を参照してください。
WebLogic Server の自己管理モニタ機能はドメイン内のサーバ インスタンスの信頼性と可用性を向上させます。各サーバ インスタンス内の選択されたサブシステムは、そのサブシステムに特定の条件に基づいて状態をモニタします。(たとえば、JMS サブシステムは JMS スレッド プールの状態をモニタし、コア サーバ サブシステムはデフォルトおよびユーザ定義実行キューの統計をモニタします。)あるサブシステムが一貫した信頼のおける方法で動作しないと判断された場合、その状態がホスト サーバに「failed」として登録されます。
次に各 WebLogic Server インスタンスは、全体的に稼動が可能であるか判断するために、登録されたサブシステムの状態をチェックします。1 つまたは複数の必須のサブシステムが FAILED 状態に達した場合、サーバ インスタンスはアプリケーションを確実にホストできないことを示すためにそれ自体の状態を FAILED にマークします。
ノード マネージャと組み合わせて使用すると、サーバの自動状態モニタ機能で、障害が発生したサーバを自動的に再起動することができます。これにより、ドメインの全体的な信頼性が向上し、管理者による直接の操作が不要になります。詳細については、Oracle WebLogic Server 10g Release 3 ドキュメントの「管理対象サーバを起動するため、ドメインまたはクラスタでノード マネージャの使用」を参照してください。
管理対象サーバは、ドメイン コンフィグレーションのローカル コピーを保持しています。起動時に、管理対象サーバは管理サーバに接続し、自身が最後に停止してからドメイン コンフィグレーションに加えられた変更を取得します。起動時に管理サーバに接続できない場合は、ローカルにキャッシュされたコンフィグレーション情報を使用します。この情報は、管理対象サーバが最後に停止した時点で最新だったコンフィグレーションです。管理サーバに接続してコンフィグレーションの更新情報をチェックせずに起動した管理対象サーバは、「管理対象サーバ独立 (MSI)」モードで実行されます。デフォルトでは、MSI モードは有効になっています。Oracle WebLogic Server 10g Release 3 ドキュメントの「管理対象サーバ独立用のドメイン コンフィグレーション ファイルの置き換え」を参照してください。
Linux または UNIX オペレーティング システムを使用している場合、ネットワーク層サーバのマシンに障害が発生した場合やネットワークからパーティションされた場合に自動的に候補 (バックアップ) サーバを起動するため、WebLogic Server のサーバ移行機能を使用することができます。サーバ移行機能はノード マネージャを wlsifconfig.sh スクリプトと組み合わせて使い、浮動 IP アドレスを使用して自動的に候補サーバを起動します。ネットワーク層インスタンスをホストするプライマリ サーバにアクセスができなくなった場合のみ、候補サーバが起動されます。サーバ移行機能の使用方法の詳細については、Oracle WebLogic Server 10g Release 3 ドキュメントの「サーバ移行」を参照してください。
サーバ レベルの冗長性およびフェイルオーバの機能に加え、Oracle Communications Converged Application Server では、ドメイン全体に影響を及ぼす停電などの破滅的な障害を防ぐためにピア サイトもコンフィグレーションできます。これにより、サービスが完全に停止されることなく、地理的なサイト間でフェイルオーバすることができます。詳細については、『コンフィグレーション ガイド』の「地理的に冗長なインストールのコンフィグレーション」を参照してください。
サーバ インスタンスの障害から回復するには、ドメインのコンフィグレーション データにアクセスする必要があります。デフォルトでは、管理サーバはドメインのプライマリ コンフィグレーション データを domain_name/config/config.xml というファイルに保存します。ここで、domain_name はドメインのルート ディレクトリです。一次コンフィグレーション ファイルは、JDBC や JMS など特定の Oracle Communications Converged Application Server サービス、および SIP コンテナ プロパティや SIP データ層コンフィグレーションなどの WebLogic SIP Server サービスに対して、追加コンフィグレーション ファイルを参照する可能性があります。特定のサービス用コンフィグレーションは、domain_name/config ディレクトリのサブディレクトリ内の追加 XML ファイルに保存されます。たとえば、Oracle Communications Converged Application Server コンフィグレーション ファイルの domain_name/config/jms、domain_name/config/jdbc、domain_name/config/custom などです。
管理サーバはドメイン コンフィグレーションの複数のバージョンを自動的にアーカイブすることができます (domain-name/config ディレクトリ全体)。偶発的に変更されたコンフィグレーションを元に戻す必要がある場合、システムを復旧するためにコンフィグレーション アーカイブを使用することができます。たとえば、管理者がコンフィグレーションされたリソースを誤って削除した場合、最後に行なわれた自動バックアップを使用して以前のコンフィグレーションを復元することができます。
管理サーバは domain_name/config でローカル的に有限数の自動化されたバックアップだけを保存します。このため、ハードディスクに障害が発生した場合などのデータ破損に対処できる自動ドメイン バックアップの機能は限られています。自動バックアップでも、LDAP リポジトリ データおよびサーバ起動スクリプトなど、ドメインを完全に回復するために必要なコンフィグレーションデータは保持されません。コンフィグレーションとセキュリティの複数のバックアップ コピーをオフラインでソース コントロール システムに維持しておくことをお勧めします。
この節では、Oracle Communications Converged Application Server で自動的に実行されるファイルのバックアップ、および管理者が定期的に実行する手動のバックアップの手順について説明します。
ドメインの管理サーバ上で、自動ドメイン コンフィグレーション バックアップを有効するには、以下の手順に従います。
コンフィグレーション アーカイブを有効にすると、管理サーバではアクティブなコンフィグレーションを変更するために管理者が Administration Console で [Activate changes] ボタンをクリックするたびにコンフィグレーション JAR ファイル アーカイブが自動的に作成されます。JAR ファイルには前のコンフィグレーションの完全なコピー (domain-name\config ディレクトリのすべてのコンテンツ) が含まれています。JAR ファイルのアーカイブ ファイルは domain-name\configArchive ディレクトリに格納されています。ファイルは命名規則 config-number.jar を使用します。number はアーカイブの連番です。
ドメインのコンフィグレーションに対する変更を保存すると、管理サーバは変更前のコンフィグレーションを domain-name\configArchive\config.xml#n に保存します。管理サーバが configArchive ディレクトリにファイルを保存するたびに、#n サフィックスの値が、コンフィグレーション可能なコピーの数 (デフォルトでは 5) になるまで増えていきます。それ以降は、ドメインのコンフィグレーションを変更するたびに、以下のような処理が行われます。
コンフィグレーション アーカイブはドメイン ディレクトリ内にローカルに格納されるので、選択した最大改訂数を超えると上書きされることに注意してください。このため、「ドメインのコンフィグレーション オフラインの格納」で説明するように、ドメイン コンフィグレーションの独自のオフライン アーカイブも作成する必要があります。
自動バックアップにより偶発的なコンフィグレーションへの変更は防止できますが、ドメイン コンフィグレーションを格納するハード ディスクの障害によって発生するデータ損失やドメイン ディレクトリの偶発的削除は防げません。これらの障害から保護するには、できればソース コントロール システムでドメイン コンフィグレーション オフライン全体のコピーを格納する必要があります。
定期的にドメイン コンフィグレーションのコピーを保存することをお勧めます。たとえば、次の場合には、コンフィグレーションの最新の改訂をバックアップします。
ドメイン コンフィグレーションのバックアップには、domain_name/config ディレクトリのすべてのコンテンツを含める必要があります。次に例を示します。
cd ~/bea/user_projects/domains/mydomain
tar cvf domain-backup-06-17-2007.jar config
ソース コントロール システムで新しいアーカイブを格納する場合、過去のある時点のドメイン コンフィグレーションを回復するために必要な以前のバージョンを保存します。
Oracle Communications Converged Application Server デプロイメントでは、一般にエンジン層サーバおよび SIP データ層サーバの起動に使われる起動スクリプトをカスタマイズし、次のようなドメイン固有のコンフィグレーション情報を指定します。
WlssEchoServer プロセスを起動する起動オプションを指定します。
ドメイン内のエンジン層サーバ、SIP データ層サーバ、または Diameter リレー サーバの起動に使われる個別の起動スクリプトをバックアップします。
Oracle Communications Converged Application Server ロギング サーブレット (「SIP リクエストと応答のロギング」を参照) を使用して SIP メッセージの定期的なロギングや監査を行う場合は、アプリケーションのソース ファイル全体をバックアップし、ステージング サーバで障害が発生した場合や元のデプロイメント ディレクトリが破損した場合にアプリケーションを簡単に再デプロイできるようにします。
WebLogic Security サービスは、コンフィグレーション データを config.xml ファイルに保存し、さらに LDAP リポジトリや他のファイルにも保存します。
Oracle Communications Converged Application Server と共にインストールされるデフォルトの認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、自身のデータを LDAP サーバに保存します。各 Oracle Communications Converged Application Server には、組み込み LDAP サーバがあります。管理サーバにはマスター LDAP サーバがあり、このサーバがすべての管理対象サーバにレプリケートされます。セキュリティ レルムでこれらのインストール済みのプロバイダを使用する場合は、次のディレクトリ ツリーの最新のバックアップを保持しておく必要があります。
domain_name はドメインのルート ディレクトリ、adminServer は管理サーバが実行時データやセキュリティ データを保存するディレクトリです。
LDAP ディレクトリは各 Oracle Communications Converged Application Server にありますが、バックアップする必要があるのは管理サーバの LDAP データだけです。セキュリティ データに対する更新があると、マスター LDAP サーバは各管理対象サーバの LDAP データをレプリケートします。WebLogic セキュリティ プロバイダは、ドメインの管理サーバが利用不能の間はセキュリティ データを変更できません。管理対象サーバの LDAP リポジトリはレプリカであり、変更はできません。
ldap/ldapfiles サブディレクトリには、LDAP サーバのデータ ファイルがあります。このディレクトリ内のファイルには、ユーザ、グループ、グループ メンバシップ、ポリシー、およびロールの情報が定義されています。ldap ディレクトリの下の他のサブディレクトリには、LDAP サーバのメッセージ ログや、レプリケートされた LDAP サーバに関するデータが含まれています。
LDAP データのバックアップが行われている間は、セキュリティ プロバイダのコンフィグレーションを更新しないでください。ldap ディレクトリ ツリーをバックアップしている最中に、たとえば管理者がユーザを追加するなどしてコンフィグレーションを変更すると、ldapfiles サブディレクトリ内のバックアップの整合性が損なわれるおそれがあります。このような事態が生じた場合は、整合性が確保された、ただし最新でない可能性のある LDAP のバックアップを利用できます。
1 日に一度、サーバは書き込み処理を一時停止し、LDAP データの独自のバックアップを作成します。このバックアップは ldap\backup ディレクトリの下の ZIP ファイルにアーカイブされ、その後、書き込み処理が再開されます。このバックアップは整合性が確保されていますが、セキュリティ データが最新でない可能性があります。
LDAP のバックアップのコンフィグレーションについては、Oracle WebLogic Server 10g Release 3 ドキュメントの「組み込み LDAP サーバのバックアップのコンフィグレーション」を参照してください。
すべてのサーバは SerializedSystemIni.dat という名前のファイルを作成し、サーバのルート ディレクトリに保存します。このファイルには、サーバの起動時に必要な暗号化されたセキュリティ データが記載されています。このファイルをバックアップする必要があります。
サーバで SSL を使用する場合は、セキュリティ証明書とキーもバックアップします。これらのファイルの場所はユーザがコンフィグレーションできます。
オペレーティング システム レベルで保持される特定のファイルも、システム障害からの回復において非常に重要な役割を果たします。システムの必要に応じて、以下の情報をバックアップすることを検討してください。
障害が発生した管理サーバを再起動するときに、特別な手順に従う必要はありません。通常どおりの方法で管理サーバを起動してください。
管理対象サーバの実行中に管理サーバが停止した場合、ドメインの管理を回復するために、実行されている管理対象サーバを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、ドメインの開始時に実行されていたのと同じマシンで管理サーバを再起動できるかどうかによって異なります。
管理対象サーバの実行中に WebLogic 管理サーバを再起動した場合、デフォルトでは、管理サーバは実行中の管理対象サーバの存在を検出することができます。
| 注意 : | 起動コマンドまたは起動スクリプトで -Dweblogic.management.discover=false を指定しないでください。このオプションを指定すると、管理サーバは実行中の管理対象サーバを検出しなくなります。 |
ドメインのルート ディレクトリに running-managed-servers.xml というファイルがあり、このファイルにドメイン内の管理対象サーバのリストと、それらのサーバが実行中かどうかの情報が記載されています。管理サーバは再起動するときにこのファイルをチェックし、停止前に自身の管理下にあった管理対象サーバを確認します。
管理対象サーバが正常に、または強制的に停止されると、running-managed-servers.xml ファイル内のそのサーバのステータスが「not-running」に更新されます。管理サーバは再起動するときに、「not-running」ステータスの管理対象サーバの検出を試みません。システム クラッシュによって停止した管理対象サーバ、あるいはサーバを実行中の JVM またはコマンド プロンプト (シェル) が強制終了したために停止した管理対象サーバは、running-managed-servers.xml のステータスが「running」のままになります。管理サーバはそれらのサーバの検出を試みて、当該サーバがもはや実行されていないと判断すると例外を送出します。
管理サーバを再起動しても、管理対象サーバは静的な属性のコンフィグレーションを更新しません。「静的な属性」とは、サーバが起動処理時にのみ参照する属性です。静的なコンフィグレーション属性に対する変更を反映するには、サーバ インスタンスを再起動する必要があります。管理対象サーバの検出では、管理サーバは管理対象サーバをモニタするか、サーバの実行中にコンフィグレーションできる属性 (動的な属性) を実行時に変更することのみが可能です。
マシンがクラッシュし、同じマシンで管理サーバを再起動できない場合は、実行中の管理対象サーバの管理を次のような方法で回復できます。
起動コマンドまたは起動スクリプトで -Dweblogic.management.discover=false を指定しないでください。このオプションを指定すると、管理サーバは実行中の管理対象サーバを検出しなくなります。
起動時に、管理サーバは管理対象サーバと通信し、管理サーバが異なる IP アドレスで実行されていることを通知します。
障害が発生した管理サーバが実行しているマシンは、ドメインの管理サーバと連絡を取ることができる場合は、ノード マネジャーを使用して管理対象サーバを手動または自動で再起動することができます。Oracle WebLogic Server 10g Release 3 ドキュメントの「管理対象サーバを起動するため、ドメインまたはクラスタでノード マネージャの使用」に記載されているように、自動化された再起動をサポートするためノード マネージャと管理サーバをコンフィグレーションする必要があります。
起動時に管理サーバに接続できない場合、管理対象サーバはローカルにキャッシュされたコンフィグレーション データを読み込み、コンフィグレーションを取得することができます。この方法で起動した管理対象サーバは、管理対象サーバ独立 (MSI) モードで実行されます。MSI モードの説明、および管理対象サーバが MSI モードで起動するときにアクセスする必要があるファイルについては、Oracle WebLogic Server 10g Release 3 ドキュメントの「管理対象サーバ独立用のドメイン コンフィグレーション ファイルの置き換え」を参照してください。
管理対象サーバを MSI モードで起動するには、次の手順に従います。
管理対象サーバは、管理サーバからの接続があるまで MSI モードで実行されます。この状況での管理サーバの再起動については、「障害の発生した管理サーバの再起動」を参照してください。
  
|