Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

ミラーリングの構成

この章では、ミラーとミラー・メンバの設定、構成、および管理に関する情報とその手順を示します。

ミラーの自動導入方法

この章では、管理ポータルを使用して、ミラーを作成し、既存のインスタンスをメンバとして構成する手順について説明します。InterSystems IRIS データ・プラットフォームでは、導入後に完全に機能するミラーの自動導入方法がいくつか提供されています。

InterSystems Cloud Manager (ICM) を使用したミラーの導入

ミラー構成を含め、InterSystems Cloud Manager (ICM) を使用して InterSystems IRIS を導入することをお勧めします。プレーン・テキストの宣言型構成ファイル、シンプルなコマンド行インタフェース、および Docker コンテナへの InterSystems IRIS の導入を組み合わせることにより、ICM では、簡単かつ直感的にクラウド・インフラストラクチャまたは仮想インフラストラクチャをプロビジョニングし、目的の InterSystems IRIS アーキテクチャを他のサービスと共にそのインフラストラクチャに導入することができます。ICM により、複雑な水平クラスタ構成の場合は特に、導入プロセスを大幅に簡素化することが可能です。

スタンドアロン・ミラー・インスタンスを導入できるほか、ICM では分散キャッシュ・クラスタをミラー・データ・サーバと共に、またシャード・クラスタをミラー・データ・ノードと共に導入することもできます。

ICM を使用して InterSystems IRIS をミラー構成で導入する方法の詳細は、"InterSystems Cloud Manager ガイド" の "ICM の使用Opens in a new tab" と "ICM クラスタのトポロジとミラーリングOpens in a new tab" を参照してください。

InterSystems Kubernetes Operator (IKO) を使用したミラーの導入

KubernetesOpens in a new tab は、コンテナ化されたワークロードとサービスの導入、拡張、および管理を自動化するためのオープンソースのオーケストレーション・エンジンです。導入するコンテナ化されたサービスと、そのサービスを管理するポリシーを定義すると、Kubernetes は、必要なリソースを可能な限り最も効率的な方法で透過的に提供します。また、導入が指定値から外れた場合は導入を修復またはリストアするほか、拡張を自動またはオンデマンドで行います。InterSystems Kubernetes Operator (IKO) は、IrisCluster カスタム・リソースで Kubernetes API を拡張します。このリソースは、InterSystems IRIS のシャード・クラスタ、分散キャッシュ・クラスタ、またはスタンドアロン・インスタンスとして、すべて任意でミラーリングした状態で、Kubernetes プラットフォームに導入できます。

Kubernetes で InterSystems IRIS を導入するのに IKO は必須ではありませんが、プロセスが大幅に簡易化され、InterSystems IRIS 固有のクラスタ管理機能が Kubernetes に追加され、クラスタにノードを追加するなどのタスクが可能になります。このようなタスクは、IKO を使わなければインスタンスを直接操作して手動で行わなければなりません。

IKO の使用法の詳細は、"InterSystems Kubernetes Operator の使用Opens in a new tab" を参照してください。

構成マージを使用したミラーの導入

Linux および UNIX® システムで利用可能な構成マージ機能を使用すると、宣言型構成マージ・ファイルを導入内の各インスタンスに適用することにより、同じイメージから導入した InterSystems IRIS コンテナや、同じキットからインストールしたローカル・インスタンスの構成を変更することができます。このマージ・ファイルは、既存のインスタンスを再起動したときに適用することもでき、インスタンスの構成パラメータ・ファイル (CPF) を更新します。CPF にはインスタンスのほとんどの構成設定が含まれており、これらの設定は、インスタンス導入後の最初の起動を含め、開始時に毎回、CPF から読み取られます。導入時に構成マージを適用すると、インスタンスと共に提供された既定の CPF が実質的に独自の更新バージョンに置き換えられます。

構成マージを使用すると、ミラーリングされたデータベースを含め、1 つ以上のミラーを導入 (または既存のインスタンスから構成) できます。それには、さまざまなミラー・ロールに別個のマージ・ファイルを適用し、最初のフェイルオーバー・メンバ、2 番目のフェイルオーバー・メンバ、DR 非同期メンバの順に導入または構成します。(ミラーの導入または構成後に、レポート非同期メンバを手動でミラーに追加する必要があります。)導入ホストの名前が特定のパターンに一致する場合、複数のフェイルオーバー・ペアを自動的に導入したり、既存のプライマリの複数のバックアップを導入することもできます。この場合、プライマリとバックアップの両方に 1 つのマージ・ファイルを使用し、フェイルオーバー・ペアの自動導入後に、DR 非同期メンバに別個のマージ・ファイルを使用できます。

構成マージ機能を使用して、分散キャッシュ・クラスタをミラー・データ・サーバと共に、またシャード・クラスタをミラー・データ・ノードと共に導入することもできます。

前のセクションで説明した ICM と IKO のどちらにも構成マージ機能が組み込まれています。

一般的な構成マージの使用法および具体的なミラーの導入方法の詳細は、"構成マージを使用した InterSystems IRIS の自動構成Opens in a new tab" を参照してください。

ミラー構成のガイドライン

強固でコスト効率のよい HA ソリューションを提供するために、ミラーリングは、さまざまなシステム構成およびアーキテクチャに適応できるように設計されています。ただし、以下の一般的な構成ガイドラインに従うことをお勧めします。

  • InterSystems IRIS インスタンスおよびプラットフォームの互換性 — ミラーに追加するシステムを特定する前に、"InterSystems IRIS インスタンスの互換性" および "メンバのエンディアンに関する考慮事項" に記載されている要件を必ず確認してください。

  • フェイルオーバー・メンバの平等性 — 1 つのミラー内の 2 つのフェイルオーバー・メンバは平等であると見なされます。一方をプライマリとする優先順位を構成することはできません。また、必要に応じてプライマリとバックアップのロールは入れ替わります。このため、最適な方法として、フェイルオーバー・システムのホストが可能な限り互いに類似するように、特に類似したコンピュータ・リソースで構成します。つまり、2 つのシステムの CPU、メモリ構成、およびディスク構成に互換性を持たせて構成します。

  • プライマリ・インスタンス構成およびセキュリティ設定 — プライマリ・フェイルオーバー・メンバ上のユーザ、ロール、ネームスペース、およびマッピング (グローバル・マッピングとパッケージマッピングを含む) などの要素の構成は、他のミラー・メンバ上のミラーにより複製されることはありません。したがって、バックアップ・フェイルオーバー・メンバまたは DR 非同期メンバが効率的にプライマリからの引き継ぎを行うために必要な設定はいずれも、必要に応じてそれらメンバに手動で複製し、更新する必要があります。

  • ミラーリングされないデータ — プライマリ・フェイルオーバー・メンバのミラーリングされるデータベースにおけるデータのみが、バックアップ・フェイルオーバー・メンバまたは非同期メンバ上で複製され、同期を保ちます。したがって、バックアップまたは DR 非同期が効率的にプライマリから引き継ぎを行うために必要なファイルはすべて (例えば、SQL ゲートウェイおよび Web サーバの構成に関連するものを含む)、必要に応じて、それらのメンバに手動でコピーして更新する必要があります。

    Note:

    ミラーリングされたデータベースのファイル・ストリームは、デフォルトではデータベース・ディレクトリの stream サブディレクトリにあり、ミラーリングされません(ファイル・ストリームの詳細は、"クラスの定義と使用" の “ストリームを使用した作業” の章を参照してください)。

  • ICMP — ミラーリングはメンバへのアクセス可否の検出をインターネット制御メッセージ・プロトコル (ICMP) に依存しているため、ミラー・メンバとして構成されているすべてのシステムで、ICMP を無効にしないでください。

  • ネットワーク — 2 つのフェイルオーバー・メンバ間で、広帯域かつ低遅延の、信頼性の高いネットワークを使用することをお勧めします。可能であれば、2 つのフェイルオーバー・メンバ用にプライベート・サブネットを作成し、このプライベート・ネットワークにデータ・チャンネル・トラフィックと制御チャンネル・トラフィックを専用でルーティングできるようにすることをお勧めします。ネットワークが遅いと、プライマリ・フェイルオーバー・メンバとバックアップ・フェイルオーバー・メンバの両方のパフォーマンスに影響する可能性があり、フェイルオーバー時にバックアップ・フェイルオーバー・メンバがプライマリを引き継ぐときに直接的な影響を及ぼす可能性があります。ネットワーキングにおける要件および構成に関する詳細は、"ネットワーク構成に関する考慮事項" および "ネットワーク遅延に関する考慮事項" を参照してください。また、VIP 使用時の重要なネットワーキング要件や考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。

  • ディスク・サブシステム — バックアップ・フェイルオーバー・メンバをプライマリ・システムと同じ状態に保つためには、両方のフェイルオーバー・メンバのディスク・サブシステムが同等である必要があります。例えば、第 1 のフェイルオーバー・メンバにストレージ・アレイを構成する場合は、第 2 のフェイルオーバー・メンバにも同様のストレージ・アレイを構成することをお勧めします。また、ネットワーク接続ストレージ (NAS) が一方または両方のシステムで使用されている場合は、ディスク I/O とミラー・データからのネットワーク負荷に対して別々のネットワーク・リンクを構成し、ネットワークのオーバーフローの可能性を最小限に抑えることを強くお勧めします。

  • ジャーナリングのパフォーマンスおよびジャーナルのストレージ — ジャーナル/ディジャーナルはミラー同期の中核を成す機能なので、フェイルオーバー・メンバのジャーナリングのパフォーマンスを監視して最適化するのは重要です。特に、すべてのミラー・メンバで共有メモリ・ヒープ (gmheap) のサイズを大きくすることをお勧めします。パフォーマンスと復元可能性の両方を高めるために、プライマリおよび代替ジャーナル・ディレクトリは、それぞれ異なるストレージ・デバイスに配置し、データベースやライト・イメージ・ジャーナル (WIJ) が使用しているストレージ・デバイスとも異なるストレージ・デバイスに配置することをお勧めします。詳細は、"データ整合性ガイド" の “ジャーナリング” の章の "ジャーナリングの最善の使用方法" と "ジャーナル・ファイルのリストア" を参照してください。

  • 仮想化 — 仮想化環境でのミラーリングの使用により、その両方の利点を併せ持つ高可用性ソリューションが提供されますが、重要な推奨事項が適用されます。詳細は、"仮想環境でのミラーリング" を参照してください。

  • タスクのスケジューリング — タスク・マネージャを使用してミラー・メンバのタスクを作成する場合、タスクを実行できるメンバを、プライマリのみ、プライマリ以外の任意のメンバ、もしくは任意のミラー・メンバのどれにするかを指定する必要があります。複数のミラー・メンバ上で実行されることが意図されているタスクは、各メンバ上で個別に作成するか、または 1 つのメンバのタスク・マネージャからエクスポートして他のメンバにインポートする必要があります。タスクの作成、インポート、およびエクスポートの詳細は、"システム管理ガイド" の “InterSystems IRIS の管理” の章にある "タスク・マネージャの使用" を参照してください。

  • 開始 — プライマリ・フェイルオーバー・メンバでは、コードを既存の ^%ZSTART ルーチンから ^ZMIRROR ルーチンに移動して、ミラーを初期化しない限りコードが実行されないようにすることができます。 詳細は、"^ZMIRROR ルーチンの使用法" を参照してください。

アービターのインストール

自動フェイルオーバーができる限り広範な停止シナリオに対処できるように、"自動フェイルオーバーのメカニズム" の説明に従って、各ミラーにアービターを構成することをお勧めします。"ミラーの可用性を最適化するためのアービターの配置" の説明にあるように、推奨されるアービターのネットワーク上の場所は、フェイルオーバー・メンバの位置によって異なります。1 つのシステムが複数のミラーそれぞれに適切な場所にあれば、そのシステムを複数のミラーのアービターとして構成できます。そのように構成するには、システムがアービターとして機能する対象の各ミラーを作成または編集するときに、"ミラーの作成" の説明にあるようにホストとポート番号を指定します。

アービターとして動作するには、システムで ISCAgent プロセスが稼働している必要があります。ISCAgent は InterSystems IRIS と共にインストールされるため、InterSystems IRIS のインスタンスを 1 つ以上ホストするシステムは、この要件を満たしていて、それ以上の準備を必要とせずにアービターとして構成できます。ただし、ミラーのフェイルオーバー・メンバまたは DR 非同期メンバを 1 つ以上ホストしているシステムは、そのミラーのアービターとして構成してはいけません

InterSystems IRIS インスタンスをホストしていないシステムを、アービターとして機能するように準備するには、次のいずれかの方法を使用します。

  • キットを使用して ISCAgent をインストールします。

    そのようなシステムの準備を整えるには、目的のアービター・システムに適した ISCAgent インストール・キットをインターシステムズからダウンロードして、以下に示すように ISCAgent をインストールします。

    • Windows システムの場合は、単にインストール・ファイル (例えば、ISCAgent-2018.1.0.540.0-win_x64.exe) を実行します。

    • UNIX®、Linux、および macOS システムの場合は、単一ファイルのインストール・キットをアンパックして (必要な場合)、インストール・キットの最上位レベル /ISCAgentagentinstall を実行します。以下に例を示します。

      [root@arbiterhost home]# gunzip ISCAgent-2020.1.0.540.0-lnxrhx64.tar.gz
      [root@arbiterhost home]# tar -xf ISCAgent-2020.1.0.540.0-lnxrhx64.tar
      [root@arbiterhost home]# ./ISCAgent/agentinstall
      
      

      ISC_PACKAGE_MODEunattended に設定することで、このインストールを自動インストールとして実行できます。以下に例を示します。

      [root@arbiterhost home]# ISC_PACKAGE_MODE="unattended" ./ISCAgent/agentinstall
      
      
  • コンテナで ISCAgent を導入します。

    アービターとして機能するように、コンテナ化された ISCAgent を任意の Linux システムに導入します。インターシステムズが提供している arbiter イメージの取得および使用の詳細は、"コンテナ内でのインターシステムズ製品の実行" の "InterSystems IRIS コンテナを使用したミラーリングOpens in a new tab" を参照してください。

Important:

システムの起動時に、アービター・システムで ISCAgent プロセスが起動するよう構成されていることを確認してください。詳細は、"ISCAgent の開始および停止" を参照してください。

ポートの設定など、ISCAgent のその他のオプションの詳細は、"ISCAgent のカスタマイズ" を参照してください。

Note:

InterSystems IRIS がサポートされるすべてのプラットフォームに向けた ISCAgent インストール・キットがあります。サポート対象プラットフォームのリストは、このリリース用のオンライン・ドキュメント "インターシステムズのサポート対象プラットフォーム" を参照してください。

アービターとして機能する ISCAgent は、構成されているミラーのメンバと同じ InterSystems IRIS バージョンでなくてもかまいません。ただし、確実に ISCAgent の最新バージョンを使用するために、ミラーのアップグレード時にアービターをアップグレードすることをお勧めします。

ISCAgent の起動

ISCAgent プロセスがホスト・システムで実行されていない限り、InterSystems IRIS インスタンスをフェイルオーバーまたは DR 非同期メンバとしてミラーに追加することはできません。ISCAgent は、システムの起動時に自動的に起動するよう構成されている必要があります。詳細は、"ISCAgent の開始および停止" を参照してください。

TLS セキュリティを使用したミラー通信の保護

ミラー内でセキュリティを実現するために、相互での通信時に TLS を使用するようにミラーのメンバを構成できます。ミラーの作成時に TLS を使用する必要がある場合は、すべてのメンバ間のすべての通信に、すべてのメンバが TLS を使用する必要があります。

TLS セキュリティを使用したミラーの作成に関する詳細は、"ミラーの作成" を参照してください。既存のミラーへの TLS セキュリティの追加に関する詳細は、"フェイルオーバー・メンバの編集または削除" を参照してください。

インターシステムズのシニア・サポート・スペシャリストが TLS セキュリティを伴ったミラーの作成手順を 1 つにまとめた包括的なガイドがあります。InterSystems Developer Community の "Creating SSL-Enabled Mirror on InterSystems IRIS Using Public Key Infrastructure (PKI)Opens in a new tab" を参照してください。

Important:

ミラーリングでは TLS を使用することを強くお勧めします。ミラーで TLS を無効にしないことを強くお勧めします。

インスタンスでジャーナルの暗号化が有効になっていて、そのインスタンスをミラーのプライマリ・フェイルオーバー・メンバに設定する場合、TLS を使用するようにミラーを構成する必要があります

ミラー・メンバのミラー通信用 TLS の使用には、ミラー・メンバ・インスタンスをホストするシステムで適切な TLS 設定が要求されます。詳細は、"ミラーリングで TLS を使用するための InterSystems IRIS の構成" を参照してください。

また、ミラーリングにおける暗号化ジャーナル・ファイルの使用には準備が必要です。ジャーナル暗号化の詳細は、この章の "ミラー内ジャーナル暗号の有効化" および "暗号化ガイド" を参照してください。

^MIRROR ルーチンの使用法

ミラーリング構成、管理、およびステータスの操作のほとんどは管理ポータルで実行できます。また、%SYS ネームスペースで実行する ^MIRROR ルーチンでも実行できます。ただし、バックアップ・フェイルオーバー・メンバを強制的にプライマリ・フェイルオーバー・メンバにする操作 ("自動フェイルオーバーなしのプライマリ計画外停止" を参照) など、操作によっては、^MIRROR ルーチンでのみ実行可能なものもあります。この章に掲載する手順では、使用可能である場合の管理ポータルの操作を説明しますが、同等の操作を備える ^MIRROR オプションについても常に注記します。

ミラーの作成

ミラーの作成にあたっては、プライマリ・フェイルオーバー・メンバ、通常は (必須ではない) バックアップ・フェイルオーバー・メンバ、および (オプションで) 1 つ以上の非同期メンバを構成します。ミラーを作成した後、データベースをミラーに追加できます。

Important:

InterSystems IRIS インスタンスをフェイルオーバー・メンバまたは非同期メンバとしてミラーに追加する前に、この章の "ISCAgent の開始および停止" の説明に従って、ISCAgent プロセスが開始されていることを確認する必要があります。

バックアップ・メンバおよび非同期メンバを追加する手順では、推奨されているように TLS を使用するようミラーを構成する場合に、追加の手順が必要です ("TLS セキュリティを使用したミラー通信の保護" を参照)。この場合、新しいメンバをミラーに参加させる前に、プライマリでそれぞれのメンバを承認する必要があります。

ミラーを作成および構成するには、以下の手順を使用します。

  1. ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する

  2. 第 2 のフェイルオーバー・メンバを構成する

  3. 第 2 のフェイルオーバー・メンバを承認する (TLS ミラーのみ)

  4. フェイルオーバー・メンバのステータスをミラー・モニタで確認する

  5. 非同期ミラー・メンバを構成する

  6. 新しい非同期メンバを承認する (TLS ミラーのみ)

ミラーを作成して、フェイルオーバー・メンバおよび任意で 1 つ以上の非同期メンバを構成してから、この章の "ミラーへのデータベースの追加" の手順を使用して、データベースをミラーに追加します。

Important:

タスク・マネージャ ("システム管理ガイド" の “InterSystems IRIS の管理” の章にある "タスク・マネージャの使用" を参照してください) を使用してシステム・タスクをインスタンスに追加すると、以下のように、[ミラーにおけるタスクの実行方法] の設定によって、タスクが実行されるミラー メンバが決定されます。

  • プライマリ・フェイルオーバー・メンバでのみ実行

  • バックアップ・フェイルオーバー・メンバおよび非同期メンバでのみ実行 (プライマリを除くすべてのメンバ)

  • すべてのミラー・メンバで実行 (プライマリ、バックアップ、および非同期)

インスタンスがミラー・メンバでない場合、この設定は無視されます。ただし、ミラー・メンバにおいて、この設定がユーザ定義タスクで指定されていない場合、タスクは実行されません。また、インスタンスをミラーに追加しても、設定は自動更新されません。

したがって、以下のいずれかを実行する必要があります。

  • インスタンスが (まだ) ミラー内に存在しない場合でも、タスクの作成時、必ず [ミラーにおけるタスクの実行方法] を設定する。

  • インスタンスがミラーに追加されている場合は、必ずすべてのユーザ定義タスクを確認し、[ミラーにおけるタスクの実行方法] を設定する。

ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する

次の手順では、ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する方法について説明します。

  1. 第 1 のフェイルオーバー・メンバで、管理ポータルの [ミラーの作成] ページ ([システム管理][構成][ミラー設定][ミラーの作成]) に移動し、[ミラーの作成] をクリックします。このオプションがアクティブでない場合、ミラーリングが有効になっていません。[ミラーサービスを有効にする] をクリックし、[サービス有効] チェック・ボックスにチェックを付けて、[保存] をクリックしてから、[ミラーの作成] オプションを選択します。

  2. [ミラーの作成] ページで、[ミラー情報] セクションに次の情報を入力します。

    1. [ミラー名] — ミラーの名前を入力します。

      Note:

      有効な名前は、1 ~ 15 文字の英数字とする必要があります。小文字は自動的に大文字に置き換えられます。

    2. [SSL/TLS が必要] — このチェック・ボックスにチェックを付ける、または外すことにより、ミラー内のすべての通信に対して (推奨どおりに) TLS セキュリティを必要とするかどうかを指定します。[SSL/TLS が必要] を選択するときに、インスタンスでミラーリングに対する有効な TLS 構成を済ませていない場合は、手順を完了する前に、[SSL/TLS の構成] リンクをクリックして、このメンバに対して必要な TLS 構成を作成する必要があります。(TLS 構成の作成方法の詳細は、"ミラー用 TLS 構成の作成および編集" を参照してください。)[ミラーの作成] の手順をキャンセルして、[TLS 構成] ページに移動することもできます ([システム管理][セキュリティ][SSL/TLS 構成])。ミラーリングに対する有効な TLS 構成が行われているインスタンスの場合、そのリンクは [SSL/TLS 編集] になりますが、[SSL/TLS が必要] を選択している場合は、そのリンクを使用する必要はありません (その構成を変更する場合を除く)。

    3. [アービターを使用] — "自動フェイルオーバーのメカニズム" で説明したように、できる限り広範な停止シナリオに対して自動フェイルオーバーを有効にするために (推奨どおりに) アービターを構成するかどうかを指定します。[アービターを使用] を選択した場合、アービターとして構成するシステムのホスト名または IP アドレス、およびその ISCAgent プロセスで使用するポート (既定では 2188) を指定する必要があります。 アービターに関する詳細は、"ミラーの可用性を最適化するためのアービターの配置" および "アービターのインストール" を参照してください。

    4. [仮想 IP を使用] — チェック・ボックスにチェックを付ける、または外すことにより、仮想 IP アドレスを使用するかどうかを指定します。[仮想 IP を使用] を選択した場合、IP アドレス、クラスレスのドメイン間ルーティング (CIDR) マスク、およびネットワーク・インタフェースの入力を求められます。

      Important:

      VIP 構成前の要求事項や重要考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。

    5. [フェイルオーバ・メンバの圧縮モード][非同期メンバの圧縮モード] — プライマリからバックアップ・メンバおよび非同期メンバにジャーナル・データを転送する前に、データを圧縮するかどうかとそれぞれに使用する圧縮タイプを指定します。詳細は、"ミラー・トラフィックの圧縮" を参照してください。既定の設定は、どちらも [システム選択] です。この設定では、フェイルオーバー・メンバ間の応答時間と、プライマリと非同期との間のネットワーク使用率が最適化されます。

  3. [ミラー・フェイルオーバー情報] セクションに次の情報を入力します。

    • [ミラー・メンバ名] — このシステムで構成しているフェイルオーバー・メンバの名前 (既定値は、システムのホスト名と InterSystems IRIS インスタンス名の組み合わせです)。ミラー・メンバ名には、以下の後に続くスペース、タブ、および句読点文字を含めることはできません。

      : [ ] # ; / * = ^ ~ ,

      保存する前にアルファベット文字は大文字に変換されます。ミラー・メンバの名前の最大長は 32 文字です。

    • [スーパーサーバ・アドレス] — このフェイルオーバー・メンバとの通信に外部システムが使用できる IP アドレスまたはホスト名を入力します。通常は既定値を受け入れることができます。スーパーサーバ・アドレスの詳細は、"ミラー・メンバのネットワーク・アドレス" および "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

    • [エージェント・ポート] — このフェイルオーバー・メンバの ISCAgent のポート番号。プロンプトで提示される、インストールしたエージェントのポートを受け入れます。エージェント・ポートの詳細は、"ISCAgent の構成" を参照してください。

  4. [詳細設定] をクリックして、以下のように追加のミラー設定を表示および編集します。

  5. [保存] をクリックします。

Note:

ミラーの作成には、^MIRROR ルーチンも使用できます ("^MIRROR ルーチンの使用法" を参照)。既存のミラー構成なしで、InterSystems IRIS インスタンスの ^MIRROR を実行する際に、ミラーリングがまだ有効になっていない場合は、[ミラーサービスを有効にする] オプションを使用できます。ミラーが有効になると、[ミラーの作成] オプションを使用でき、ミラー作成およびプライマリ・フェイルオーバー・メンバとしてのインスタンス構成の代替手段になります。また、SYS.Mirror.CreateNewMirrorSet()Opens in a new tab ミラーリング API メソッドもこの目的に使用できます。

第 2 のフェイルオーバー・メンバを構成する

次の手順に従って、ミラーに第 2 のフェイルオーバー・メンバを構成します。

  1. 第 2 のフェイルオーバー・メンバで、[フェイルオーバーとしてミラーに参加] ページ ([システム管理][構成][ミラー設定][フェイルオーバーとして参加]) に移動します。[フェイルオーバーとして参加] オプションが使用できない場合、最初に [ミラーサービスを有効にする] をクリックし、[サービス有効] チェック・ボックスにチェックを付けて、[保存] をクリックしてから、[フェイルオーバーとして参加] オプションを選択します。

  2. [フェイルオーバーとしてミラーに参加] ページで、[ミラー情報] セクションに、第 1 のフェイルオーバー・メンバを構成したときに指定したミラー名を入力します。

  3. [他方のミラー・フェイルオーバー・メンバの情報] セクションに次の情報を入力します。

    • [その他のシステムのエージェント・アドレス] — 第 1 のフェイルオーバー・メンバを構成したときに指定した [スーパーサーバ・アドレス] を入力します。

    • [エージェント・ポート] — 第 1 のフェイルオーバー・メンバを構成したときに指定した ISCAgent のポートを入力します。

    • [InterSystems IRIS インスタンス名] — 第 1 のフェイルオーバー・メンバとして構成されている InterSystems IRIS インスタンスの名前を入力します。

  4. [次へ] をクリックして、ミラーおよび第 1 のフェイルオーバー・メンバに関する情報を取得および表示します。[ミラー・フェイルオーバー・メンバ情報] セクションには、次の情報が入力されています。

    • [ミラー・メンバ名] — このシステムで構成しているフェイルオーバー・メンバの名前を指定します (既定値は、システムのホスト名と InterSystems IRIS インスタンス名の組み合わせです)。ミラー・メンバ名には、以下の後に続くスペース、タブ、および句読点文字を含めることはできません。

      : [ ] # ; / * = ^ ~ ,

      保存する前にアルファベット文字は大文字に変換されます。ミラー・メンバの名前の最大長は 32 文字です。

    • [スーパーサーバ・アドレス] — このフェイルオーバー・メンバとの通信に外部システムが使用できる IP アドレスまたはホスト名を入力します。詳細は、"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

    • [エージェント・ポート] — このフェイルオーバー・メンバの ISCAgent のポート番号を入力します。プロンプトで提示される、インストールしたエージェントのポートを受け入れます。エージェント・ポートの詳細は、"ISCAgent の構成" を参照してください。

    • [仮想 IP 用ネットワーク・インタフェース] — 第 1 のフェイルオーバー・メンバを構成したときに指定したネットワーク・インタフェースが表示されます。この設定を第 2 のフェイルオーバー・メンバで変更することはできません。

    • [SSL/TLS の要件] — 第 1 のフェイルオーバー・メンバを構成したときに指定した設定が表示されます。この設定を第 2 のフェイルオーバー・メンバで変更することはできません。

      ミラーが TLS を要求している場合に、インスタンスでミラーリングに対する有効な TLS 構成を済ませていないときには、手順を完了する前に、[SSL/TLS の構成] リンクをクリックして、このメンバに対して必要な TLS 構成を作成する必要があります。(TLS 構成の作成方法の詳細は、"ミラー用 TLS 構成の作成および編集" を参照してください。)[フェイルオーバとして参加] の手順をキャンセルして、管理ポータルの [TLS 構成] ページに移動することもできます ([システム管理][セキュリティ][SSL/TLS 構成])。

      ミラーリングに対する有効な TLS 構成が行われているインスタンスの場合、そのリンクは [SSL/TLS 編集] になりますが、TLS が要求される場合は、そのリンクを使用する必要はありません (その構成を変更する場合を除く)。

    • [ミラー・プライベート・アドレス] — このフェイルオーバー・メンバとの通信に別のフェイルオーバー・メンバが使用できる IP アドレスまたはホスト名を入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

    • [エージェント・アドレス] — このメンバの ISCagent に別のミラー・メンバが最初に通信しようとするアドレスを入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

  5. [詳細設定] をクリックすると、第 1 のフェイルオーバー・メンバを構成したときに指定した [サービス品質タイムアウト (ミリ秒)] の設定が表示されます。この設定を第 2 のフェイルオーバー・メンバで変更することはできません。

  6. [保存] をクリックします。

TLS を使用するようにミラーを構成した場合は、以下のセクションで説明するように、第 1 のフェイルオーバー・メンバで第 2 のフェイルオーバー・メンバを承認することで、第 2 のフェイルオーバー・メンバをミラーに追加するプロセスを完了する必要があります。

Note:

第 2 のフェイルオーバー・メンバの構成には、^MIRROR ルーチンも使用できます ("^MIRROR ルーチンの使用法" を参照)。既存のミラーリング構成なしで、InterSystems IRIS インスタンスの ^MIRROR を実行する際に、ミラーリングがまだ有効になっていない場合は、[ミラーサービスを有効にする] オプションを使用できます。ミラーリングが有効になると、[フェイルオーバー・メンバとしてミラーに参加] オプションを使用でき、バックアップ・フェイルオーバー・メンバの構成とミラーへの追加の両方についての代替手段になります。また、SYS.Mirror.JoinMirrorAsFailoverMember()Opens in a new tab ミラーリング API メソッドもこの目的に使用できます。

第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (TLS ミラーのみ)

TLS を使用するようにミラーを構成した場合は、第 2 のフェイルオーバー・メンバの構成後または非同期メンバの構成後に、追加の手順が必要になります。ミラーを作成してから第 1 のフェイルオーバー・メンバを構成したシステムでは、次の手順に従って、新しいミラー・メンバを承認する必要があります。

  1. [ミラーの編集] ページ ([システム管理][構成][ミラー設定][ミラーの編集]) に移動します。

  2. ページの下部にある、[保留中の新しいメンバ] 領域には、ミラーに追加されているメンバがリスト表示されます。承認するメンバを選択し、[承認] をクリックして確定します。(第 2 のフェイルオーバー・メンバを追加する際に、そのメンバの TLS 証明書が自動的に検証されます)。

  3. [ミラーの編集] ページの [ミラーメンバ情報] セクションに示される情報には、追加したメンバが含まれています。(このリストに表示されるアドレスの詳細は、"ミラー・メンバのネットワーク・アドレス" を参照してください。)

Note:

また、第 1 のフェイルオーバー・メンバの ^MIRROR ルーチンの [ミラー構成] メニューにある [保留中の新しいメンバの承認/拒否] オプションも、TLS を要求するように構成したミラーで、新しいフェイルオーバー・メンバまたは非同期メンバを承認するために使用できます。

SYS.Mirror.AddFailoverMember()Opens in a new tab ミラーリング API メソッドは、TLS を要求するように構成したミラーで、第 2 のフェイルオーバー・メンバを承認するために使用できます。また、Config.MapMirrors.Create() API メソッドは、承認されるメンバ (フェイルオーバーまたはバックアップ) を作成するために使用できます。SYS.Mirror.VerifyMirrorSSLCertificates()Opens in a new tab は、ミラー・メンバの TLS 証明書を検証するために使用できます。

TLS を要求するミラーのメンバに対する X.509 DN 更新を承認する (メンバの証明書が置き換えられた場合など) 方法の詳細は、"X.509 DN 更新の承認 (TLS のみ)" を参照してください。

フェイルオーバー・メンバのステータスをミラー・モニタで確認する

"ミラーの監視" で説明しているように、ミラー内のフェイルオーバー・メンバに関する情報を、ミラーにおけるその現行ステータス (ロール) を含め、ミラー・モニタを使用して確認できます。以下の手順に従い、ミラー・モニタを使用して、ミラーおよびそのフェイルオーバー・メンバが本来の意図どおりに設定されていることを確認します。

  1. 構成した第 1 のフェイルオーバー・メンバで、[ミラー・モニタ] ページを表示します ([システム処理][ミラー・モニタ])。

  2. [ミラー・フェイルオーバー・メンバ情報] 領域に、2 つのフェイルオーバー・メンバのミラー・メンバ名およびネットワーク・アドレスがリストされます。

  3. [ミラー・メンバ・ステータス] 領域の [ステータス] 列に、構成した第 1 のフェイルオーバー・メンバが [プライマリ] として表示され、第 2 のフェイルオーバー・メンバが [バックアップ] として表示されます。"ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" で説明しているように、バックアップの [ジャーナル転送] ステータスが [アクティブ] で、[デジャーナリング] ステータスが [キャッチアップ済み] になっているはずです。

  4. アービターが構成されている場合、[アービター接続ステータス] 領域に、アービターのネットワーク・アドレスとエージェント・ポート番号が表示されます。[フェイルオーバー・モード][アービター制御] で、[接続ステータス][両方のフェイルオーバー・メンバがアービターに接続されている] になっているはずです。そのようになっていない場合、アービターが正しくインストールされていないか、アービターの ISCAgent プロセスが実行されていないか、または入力したネットワーク・アドレスかポート番号が正しくない可能性があります。ネットワーク上の問題により、一方または両方のフェイルオーバー・メンバがアービターと通信できなくなっている場合も、[フェイルオーバー・モード][エージェント制御] になる可能性があります。

バックアップ・フェイルオーバー・メンバのミラー・モニタにも同じ情報が表示されます。

非同期ミラー・メンバを構成する

構成する各非同期メンバに対して、以下の手順を使用します。フェイルオーバーのペアを使用するミラーには、レポート非同期メンバまたは災害復旧 (DR) 非同期メンバを最大 14 含めることができます。単一の InterSystems IRIS インスタンスは、最大で 10 個のミラーのレポート非同期メンバになれます。ただし、インスタンスは 1 つのミラーでのみ、DR 非同期になれます。読み取り専用または読み書き可能いずれかのレポート非同期としてインスタンスを構成すれば、そのいずれかのタイプのレポート非同期メンバとしてのみ、他のミラーに追加することができます(ただし、"非同期メンバのミラー構成の編集" の説明のとおり、レポート非同期メンバのタイプをそのメンバの属するすべてのミラーに対して変更することはできます)。

Note:

レポート非同期メンバとしてインスタンスをミラーに追加する手順は、ここで説明する [非同期として参加] オプションを使用する場合も、"非同期メンバのミラー構成の編集" で説明する [非同期構成の編集] ページの [ミラーに参加] ボタンを使用する場合も同じです。ただし、DR 非同期が所属できるのは 1 つのミラーにのみであるため、[非同期構成の編集] ページの [ミラーに参加] ボタンは、レポート非同期メンバにのみ使用できます。

  1. [非同期としてミラーに参加] ページ ([システム管理][構成][ミラー設定][非同期として参加]) に移動します。[非同期として参加] オプションを選択できない場合は、[ミラーサービスを有効にする] を選択して、サービスを有効化します。

  2. [非同期としてミラーに参加] ページにて、[ミラー名] プロンプトで、ミラーの作成時に指定したミラー名を入力します。

  3. プライマリまたはバックアップ・フェイルオーバー・メンバを選択し、[ミラー・フェイルオーバー・メンバの情報] セクションで、以下のプロンプトそれぞれに、選択したメンバの情報を入力します。

    1. [フェイルオーバー・システムのエージェント・アドレス] — 選択したフェイルオーバー・メンバを構成したときに指定した [スーパーサーバ・アドレス] を入力します。

    2. [エージェント・ポート] — 選択したフェイルオーバー・メンバに指定した ISCAgent のポートを入力します。

    3. [InterSystems IRIS インスタンス名] — 選択したフェイルオーバー・メンバとして構成されている InterSystems IRIS インスタンスの名前を入力します。

  4. [次へ] をクリックして、フェイルオーバー・メンバの情報を確認した後、[非同期メンバ情報] セクションに移動します。このセクションで、次の情報を入力します。

    1. [非同期メンバ名] — 対象のシステムで構成している非同期メンバの名前を指定します (既定値は、システムのホスト名と InterSystems IRIS インスタンス名の組み合わせです)。ミラー・メンバの名前には、英数文字、下線文字、およびハイフンが使用できます。

      Note:

      ミラー・メンバ名を変更することはできないので、この名前はレポート非同期メンバが将来、他のミラーに参加する際にも使用されることになります。

    2. [非同期メンバ・アドレス] — この非同期メンバと通信するために外部システムが使用できる IP アドレスまたはホスト名を入力します。

      Note:

      入力した [非同期メンバ・アドレス] は、非同期メンバのスーパーサーバ・アドレスおよびミラー・プライベート・アドレスになります ("ミラー・メンバのネットワーク・アドレス" を参照)。例えば、DR 非同期のミラー・プライベート・アドレスをミラー・プライベート・ネットワークに配置し、そのスーパーサーバ・アドレスを外部ネットワークに置いたままにするなど、これらのアドレスを異なったものにするには、ミラーに追加後、非同期のアドレスをプライマリで更新できます。詳細は、"ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

    3. [エージェント・アドレス] — このメンバの ISCagent に別のミラー・メンバが最初に通信しようとするアドレスを入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

    4. [非同期メンバのシステム・タイプ] — ドロップダウン・リストから以下のタイプのいずれかを選択します。単一の InterSystems IRIS インスタンスは、複数のミラーのレポート非同期メンバになれます。ただしインスタンスは 1 つのミラーでのみ、DR 非同期になれます。

      • [災害復旧 (DR)]単一ミラー内のミラーリングされるデータベースすべてを読み取り専用コピーとして維持するシステムに対するオプションです。これにより、いずれかのフェイルオーバー・メンバの障害時に、DR 非同期メンバがフェイルオーバー・メンバに昇格することができます。DR 非同期の昇格に関する詳細は、この章の "DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください。

        Important:

        VIP を使用するようにミラーが構成されている場合、災害復旧の非同期メンバには、フェイルオーバー・メンバへの TCP/IP 直接接続性を備える必要となります。詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。

      • [読み取り専用のレポート] — このオプションを使用して、1 つ以上のミラーからのミラーリングされるデータベースの読み取り専用コピー (すなわちミラーリングされるデータベースのサブセット) を維持し、データの変更/追加の必要性のないデータ・マイニングおよび企業レポートを利用します。

      • [読み書き可能のレポート] — このオプションを使用して、1 つ以上のミラーからのミラーリングされるデータベースの読み書き可能コピー (すなわちミラーリングされるデータベースのサブセット) を維持します。それらのデータベースは、解析中にデータの変更や追加が可能であることが必要なレポート/ビジネス・インテリジェンス業務のデータ・ソースとして利用されます。

    5. [SSL/TLS の構成] — ミラーが TLS を要求するときに、インスタンスでミラーリングに対する有効な TLS 構成を済ませていない場合は、エラー・メッセージと、このリンクが含まれるようになります。手順を完了する前に、このリンクをクリックして、このメンバに対して必要な TLS 構成を作成する必要があります。(TLS 構成の作成方法の詳細は、"ミラー用 TLS 構成の作成および編集" を参照してください。)[非同期として参加] の手順をキャンセルして、管理ポータルの [TLS 構成] ページに移動することもできます ([システム管理][セキュリティ][SSL/TLS 構成])。

    6. [SSL/TLS 編集] — ミラーリングに対する有効な TLS 構成が行われているインスタンスの場合、このリンクが [SSL/TLS の構成] の代わりに表示されます。必要な場合は、このリンクを使用して、既存の TLS 構成を編集できます。インスタンスの X.509 識別名も表示されます。

  5. [保存] をクリックします。

TLS を使用するようにミラーを構成した場合は、"第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (TLS ミラーのみ)" で説明するように、第 1 のフェイルオーバー・メンバで非同期メンバを承認することで、非同期メンバをミラーに追加するプロセスを完了する必要があります。

Note:

非同期ミラー・メンバの構成には、^MIRROR ルーチンも使用できます ("^MIRROR ルーチンの使用法" を参照)。ミラーリングが有効化された InterSystems IRIS インスタンスで ^MIRROR ルーチンを実行すると、[ミラー構成] メニューの [非同期メンバとしてミラーに参加] (または [非同期メンバとして他のミラーに参加]) オプションが選択でき、非同期メンバを構成してミラーに追加するための代替手段になります。また、SYS.Mirror.JoinMirrorAsAsyncMember()Opens in a new tab ミラーリング API メソッドを使用して、非同期メンバを構成することもできます。

このセクションで説明する手順を使用して、インスタンスを非同期メンバとして 1 つのミラーに追加した後に、[非同期の編集] ページ ("非同期メンバのミラー構成の編集" を参照) の [ミラーに参加] ボタンを使用してインスタンスを他のミラーも追加できますが、同じタイプの非同期に限られます。

ミラーへのデータベースの追加

ミラーに追加できるのは、現在のプライマリ・フェイルオーバー・メンバのローカル・データベースのみです。最初はプライマリ上、その次にバックアップ上、さらにその次に任意の非同期メンバ上で追加します。すべてのミラーリングされるデータベースはジャーナリングされる必要があります。

ミラーリングされるデータベースの同一セットをプライマリおよびバックアップ・フェイルオーバー・メンバの両方、ならびにあらゆる DR 非同期メンバに追加する必要があります。いずれのミラーリングされるデータベースをレポート非同期メンバに追加するかは、レポートのニーズによって異なります。ミラーリングされるデータベースに関連付けられるネームスペースやグローバル/ルーチン/パッケージのマッピングは、すべてのミラー・メンバで同じである必要があります。メンバにはそのデータベースが存在するすべての非同期メンバも含まれます。バックアップ・フェイルオーバー・メンバのミラーリングされるデータベースをマウントおよびキャッチアップして ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)、フェイルオーバー時にプライマリを引き継げるようにする必要があります。DR 非同期メンバのミラーリングされるデータベースをマウントおよびキャッチアップして、フェイルオーバー・メンバへの昇格に適するようにする必要があります。

ミラーリングされるデータベースの作成手順 (つまり、データが含まれない新規データベースの追加) は、ミラーへの既存データベース追加の手順とは異なります。ミラーリングされるデータベースとして作成されたデータベースでのグローバル操作は、始めからミラー・ジャーナル・ファイルに記録されるので、ミラーはミラー・メンバ全体のデータベースと同期する必要があるデータすべてに対するアクセス権を備えています。しかし、ミラーへ追加される前の既存データベースのグローバル操作は非ミラー・ジャーナル・ファイルに含まれるので、ミラーにはアクセス権がありません。この理由から、既存のデータベースは、ミラーに追加した後にプライマリ・フェイルオーバー・メンバにバックアップし、データベースを置くことになるバックアップ・フェイルオーバー・メンバおよび非同期メンバにリストアする必要があります。これを実行した後には、データベースをアクティブにしてキャッチアップし、プライマリと同じ最新状態にする必要があります。

ミラーリングされたデータベースの考慮事項

ミラーリング・データベースを作成および追加する際は、以下の点に注意してください。

  • ミラーリングできるのは、IRIS.DAT ファイル内のデータのみです。外部データ (すなわち、ファイル・システムに保存されているデータ) は、InterSystems IRIS ではミラーリングできません (詳細は、"ミラー構成のガイドライン" を参照してください)。

  • システム・データベース (IRISSYSIRISLIBIRISLOCALDATAIRISTEMPIRISAUDIT、および ENSLIB) はミラーリングできません。

  • Foundation ネームスペースをミラーリングするには、WRC に HSHC-3009 のアドホック・パッチの提供を求め、提供されるアドホックに関する指示に従ってください。

  • ミラーリングされたデータベースにはさらに多くのデータベース・ディレクトリ情報が格納されるので、InterSystems IRIS インスタンス内に構成可能なデータベースの最大数は減ります。詳細は、"システム管理ガイド" の “InterSystems IRIS の構成” の章にある "データベースの構成" を参照してください。

  • ミラーは、バックアップまたは非同期のミラーされたデータベースの以下のプロパティを、プライマリのデータベースのプロパティと自動的にかつ継続的に同期します。

    • 最大サイズ

    • 拡張サイズ

    • リソース名

    • 照合

    例えば、プライマリで、ミラーリングされたデータベースの [最大サイズ] が増やされた場合、必要に応じて、プライマリと一致するようにその他のメンバ上のミラーリングされたデータベースも自動的に増やされます。非同期で [最大サイズ] が減らされた場合、同期によってプライマリ上の値もその値まで自動的に増やされます。データベースのプロパティがプライマリまたは別のミラー・メンバで変更され、そのメンバが切断されている場合、そのメンバがミラーに再接続したときに自動的に同期されます。これらのデータベースのプロパティの自動同期には、次の 2 つの例外があります。

    • 非同期の [最大サイズ] プロパティと [拡張サイズ] プロパティの値は、同期によって増加することがありますが、減少することはありません。例えば、プライマリ上のデータベースの [最大サイズ] が減らされた場合、バックアップのこのプロパティ値は減らされますが、ミラーに属している非同期のこのプロパティ値は減らされません。非同期のデータベースの [最大サイズ] がプライマリのものより増やされた場合、この値が同期によってプライマリの値にまで減らされることはありません。

    • データベースの [リソース名] プロパティは、フェイルオーバー・データベースとしてマークされている指定のデータベースを持つミラー・メンバでプライマリと同期します。実際には、読み書き可能レポート非同期メンバを除くすべてのミラー・メンバに [リソース名] が同期することになります。

    Important:

    InterSystems IRIS for Health または HealthShare® Health Connect を実行している場合は、"インターシステムズの医療製品のミラーリングに関する考慮事項" で追加のデータベースの考慮事項を参照してください。

    ミラーリングされるデータベースのプロパティの詳細は、"システム管理ガイド" の “InterSystems IRIS の構成” の章にある "ミラーされているローカル・データベース・プロパティの編集" を参照してください。

ミラーリングされるデータベースを作成する

ミラーリングされるデータベースを作成するには、以下の手順に従います。

Note:

^DATABASE ルーチンを使用して、ミラーリングされるデータベースを作成することもできます。この章の "^DATABASE ルーチンを使用したミラーリングされるデータベースの作成" を参照してください。

  1. 現在のプライマリ・フェイルオーバー・メンバで、管理ポータルの [ローカルデータベース] ページ ([システム管理][構成][システム構成][ローカルデータベース]) に移動し、[新規データベース作成] ボタンをクリックします。

  2. "システム管理ガイド" の “InterSystems IRIS の構成” の章にある "ローカル・データベースの作成" セクションの手順に従います。2 番目のパネルで、[ミラーリングされるデータベース] に対して [はい] を選択して、ミラー内のデータベースの名前を入力します。既定はユーザが提供したローカル・データベース名となります(ミラー・データベース名の先頭文字は、英字またはアンダースコアである必要があり、残りの部分は、英字、ハイフン、およびアンダースコアである必要があります)。ミラー・データベース名では大文字と小文字が区別されないため、2 つの名前を大文字と小文字の違いだけで区別することはできません。既にミラーに含まれているミラー・データベース名を入力した場合、新規データベースをミラーに追加できないので、削除する必要があります(以前のバージョンの InterSystems IRIS で作成しミラーリングされるデータベースの名前は、大文字と小文字の混在状態または小文字で保存されている可能性がありますが、重複する大文字の名前が付いたデータベースの追加は、これまでどおりに防止されます)。

    複数のミラーに属している非同期メンバでは、そのデータベースが属することになるミラーも選択する必要があります。

    Note:

    [ミラーされたデータベース] に対して [はい] を選択した場合、[ジャーナルグローバル] は自動で [はい] に固定されます。

  3. 手順によってデータベースが作成されたことを確認し、そのデータベースをプライマリのミラーに追加します。

  4. バックアップ・フェイルオーバー・メンバ、およびミラーリングされるデータベースを追加する各非同期メンバで、前述の 3 つのステップに従います。それぞれの他のメンバのミラーリングされるデータベース名として、プライマリの正しいミラー・データベース名を入力するよう注意してください(ローカル・データベース名と一致する必要はありません)。

    Note:

    プライマリ上のミラーリングされるデータベースとして作成されていないが作成後にミラーに追加した非プライマリ・メンバ上のミラーに新しいデータベースを追加しようとすると、これについて知らせるエラー・メッセージが表示され、操作は完了できません。

Important:

ミラーリングされたデータベースの最初のミラー・ジャーナル・ファイルがプライマリから削除されると、別のメンバでデータベースをミラーリングされたデータベースとして作成できなくなります。その代わり、"ミラーへ既存データベースを追加する" の説明のとおり、プライマリにバックアップを作成し、バックアップまたは非同期でリストアする必要があります。このため、プライマリでデータベースを作成した後は、できるだけすぐにバックアップと非同期メンバでデータベースを作成することをお勧めします。(プライマリでミラー・ジャーナル・ファイルが削除された場合の詳細は、"データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナル・ファイルの削除" を参照してください。)

ミラーへ既存データベースを追加する

以下の手順を使用して、1 つ以上の既存データベースをミラーに追加します。

Note:

SYS.Mirror.AddDatabase()Opens in a new tab ミラーリング API メソッドは、既存のデータベースをミラーに追加するための代替手段を提供します。

  1. 現在のプライマリ・フェイルオーバー・メンバで、管理ポータルの [ローカルデータベース] ページ ([システム管理][構成][システム構成][ローカルデータベース]) に移動し、[ミラーに追加] ボタンをクリックします。

  2. リストのデータベース (システム・データベース以外はまだミラーに存在しない) から、追加するものを選択して、[追加] をクリックします。ミラー内の各データベースの名前を入力する必要があります。既定はユーザが提供したローカル・データベース名となります(ミラー・データベース名の先頭文字は、英字またはアンダースコアである必要があり、残りの部分は、英字、ハイフン、およびアンダースコアである必要があります)。ミラー・データベース名では大文字と小文字が区別されないため、2 つの名前を大文字と小文字の違いだけで区別することはできません。既にミラーに含まれているミラー・データベース名を入力した場合、操作は失敗します (以前のバージョンの InterSystems IRIS で作成しミラーリングされるデータベースの名前は、大文字と小文字の混在状態または小文字で保存されている可能性がありますが、重複する大文字の名前が付いたデータベースの追加は、これまでどおりに防止されます)。

    タスクをバックグラウンドで実行するには、[バックグラウンドで追加を実行] を選択します。5 つ以上のデータベースを選択する場合、タスクはバックグラウンドで自動的に実行されます。手順により、プライマリ上で選択したデータベースがミラーに追加されたことを確認します。

    また、個々のデータベースをミラーに追加するには、名前のクリックによりプロパティを編集してから、[ミラー <mirrorname> に追加] リンクをクリックし、その後、[追加] をクリックして、手順を確認することでも行えます(データベースでジャーナリングが有効になっていない場合、このリンクの代わりに [ミラーリングのためにデータベースをジャーナリングする必要があります] と表示されるので、[グローバルジャーナル状態] ドロップダウン・リストから [はい] を選択します)。また、^MIRROR ルーチンの [ミラー管理] メニューの [ミラーリングされるデータベースの追加] オプションでも、個々のデータベースを追加できます。どちらの場合も、ローカル名と同じ既定のミラー・データベース名をそのまま使用することも、別の名前を入力することもできます。

    Note:

    バックアップ・フェイルオーバー・メンバまたは非同期メンバにプライマリ・フェイルオーバー・メンバとは異なるエンディアンがある場合は、"メンバのエンディアンに関する考慮事項" での手順に従って、データベースをプライマリに追加してから、バックアップまたは非同期メンバに追加する必要があります。以下の手順では、データベースをバックアップまたは非同期メンバ上で追加します。

  3. データベースがミラーに追加されたら、プライマリ・フェイルオーバー・メンバ上でバックアップを行います。各種バックアップ技術および関連するリストア手順の詳細は、"データ整合性ガイド" の “バックアップとリストア” の章にある "バックアップの方法"、"バックアップからのリストア"、および "ミラーリングされたデータベースの考慮事項" を確認してください。

    Important:

    コピーしているデータベースをプライマリで暗号化する場合、暗号化に使用したキーをバックアップ (および非同期 (存在する場合)) で有効化するか、宛先システムで有効化されたキーを使用するようデータベースを変換する必要があります (これについては、"新しいキーを使用するように暗号化データベースを変換する" で説明しています)。

    バックアップからのミラーリングされるデータベースのリストア後 (以下のステップを参照)、そのデータベースが確実に同期するには、プライマリ・フェイルオーバー・メンバ上でのバックアップ時点よりジャーナル・ファイルが使用可能かつオンラインである必要があります。例えば、関連ジャーナル・ファイルが削除されてしまった場合、より最新のバックアップを作成およびリストアする必要があります。ミラー・ジャーナル・ファイルのリストアについての一般事項は、"データ整合性ガイド" の “ジャーナリング” の章にある "ミラー・ジャーナル・ファイルのリストア" を参照してください。ミラー・ジャーナル・ファイルの削除に関する詳細は、"データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナル・ファイルの削除" を参照してください。

  4. バックアップ・フェイルオーバー・メンバおよび接続された各非同期メンバでは、以下の手順を実行します。

    1. プライマリ・フェイルオーバー・メンバ上で追加したばかりのミラーリングされるデータベースと同じローカル名とデータベース・ディレクトリを持つローカル・データベースがまだ存在しない場合は、それを作成します。

    2. プライマリ上のミラーリングされるデータベースで作成したバックアップをリストアして、既存のデータベースを上書きします。この手順は、以下のように使用しているリストア方法によって異なります。

      • オンライン・バックアップ・リストア (^DBREST ルーチン) — このルーチンは、バックアップおよび非同期メンバのミラーリングされるデータベースを自動的に認識、有効化、およびキャッチアップします。詳細は、"データ整合性ガイド" の “バックアップとリストア” の章の "ミラーリングされたデータベースの考慮事項" を参照してください。

        Note:

        ミラーリングされるデータベースが非プライマリ・メンバ上でリストアされる場合、自動同期プロセスを開始するためのデータがまだ送信されていない場合があります。必要なデータが 60 秒以内に到着しない場合、プロセスはとりあえず開始されます。データが必要となる前に到着しない場合、それらのデータベースがキャッチアップしないことがあります。ただしその場合は、問題のあるデータベースに関するメッセージが messages.log ファイルにロギングされます(データベース作成中は、このプロセスに影響されるデータベースは 1 つのみとなります。ただし、これは複数のデータベースが関係するその他の状況のキャッチアップにも適用されます)。

      • 外部バックアップ・リストアまたはコールド (オフライン) バックアップ・リストア — これらのどちらの方法でも、ミラーリングされるデータベースを、バックアップ・フェイルオーバー・メンバまたは非同期メンバ上でリストアし、かつマウントした後に、手動で有効化し、キャッチアップする必要があります。これについては、直後の "ミラーリングされるデータベースの有効化とキャッチアップ" で説明しています。

前述の手順の代わりとして、既存のデータベースをプライマリ上のミラーに追加した後で、データベースのバックアップとリストアを実行するのではなく、データベースの IRIS.DAT ファイルをプライマリからバックアップ・メンバと非同期メンバにコピーすることもできます。この操作には、以下の手順を使用します。

  1. バックアップ・メンバまたは各非同期メンバ上にプレースホルダのターゲット・データベースが存在することを確認します。

  2. 両方のフェイルオーバー・メンバと各非同期メンバで、ソース・データベースとターゲット・データベースがマウントされていないことを確認します ("システム管理者ガイド" の “InterSystems IRIS の管理” の章にある "ローカル・データベースの管理" を参照してください)。

  3. ミラーリングされる IRIS.DAT ファイルをプライマリ・フェイルオーバー・メンバから、バックアップおよび各非同期メンバ上のプレースホルダ・ターゲット・データベースのデータベース・ディレクトリにコピーして、既存の IRIS.DAT ファイルを上書きします。

    Note:

    コピーしているデータベースをプライマリで暗号化する場合、暗号化に使用したキーをバックアップ (および非同期 (存在する場合)) で有効化するか、宛先システムで有効化されたキーを使用するようデータベースを変換する必要があります (これについては、"新しいキーを使用するように暗号化データベースを変換する" で説明しています)。

  4. すべてのメンバにデータベースをマウントします。

  5. バックアップ・フェイルオーバー・メンバおよび非同期メンバ上のミラーリングされるデータベースを有効化してキャッチアップします。詳細は、この章の "ミラーリングされるデータベースの有効化とキャッチアップ" を参照してください。

Note:

既存のミラーリングされるデータベースを非同期メンバに追加するときに、完全にキャッチアップされているものと仮定すると、プライマリではなく、バックアップ・フェイルオーバー・メンバまたは別の非同期メンバ上でデータベースをバックアップする (または、それらのメンバから IRIS.DAT ファイルをコピーする) ことができます。バックアップをリストアする非同期とは異なるデータ・センタにプライマリがある場合など、これは便利な場合があります。ただし、データベースの整合性に高度な信頼性がない限り、メンバをソースとして使用しないでください。

ミラーリングされるデータベースの有効化とキャッチアップ

ミラー・モニタを使用して、バックアップ・フェイルオーバー・メンバおよび非同期メンバ上のミラーリングされるデータベースの有効化またはキャッチアップ、あるいはその両方を実行できます。

"ミラーへ既存データベースを追加する" でも記載していますが、データを含んでいてミラーリングされる新規追加データベースは、^DBREST ルーチンの使用を通してプライマリと自動的に同期して、プライマリ・フェイルオーバー・メンバからバックアップをリストアできます。その他の手段を使用する場合、バックアップ・フェイルオーバー・メンバおよび非同期メンバ上で有効化およびキャッチアップする必要があります。

ミラーリングされるデータベースを有効化およびキャッチアップするには、バックアップ・フェイルオーバー・メンバおよび非同期メンバで次の手順を実行します。

  1. [ミラー・モニタ] ページ ([システム処理][ミラー・モニタ]) に移動します。

  2. 必要に応じて、非同期メンバ上で、実行するデータベースを含むミラーの [詳細] リンクをクリックします。

  3. "ミラー・モニタの使用法" で説明しているように、[ミラーリングされるデータベース] リストに、各データベースのステータスが表示されます。ここに表示される可能性のあるステータスの中で特に、[要キャッチアップ] はキャッチアップ処理が必要であることを示し、[要有効化] は有効化とキャッチアップの両方の処理が必要であることを示し、[キャッチアップ実行中] はデータベースで現在キャッチアップ処理が実行中であることを示します。

  4. 1 つのデータベースに対してのみ処理を実行する場合、[有効化] リンクまたは [キャッチアップ] リンクを選択します。または、アクションの対象として該当するすべてのデータベースのリストから複数のデータベースを選択できるダイアログを開いて、選択したすべてのデータベースに一度にアクションを適用する場合、[アクションを選択してください] ドロップダウンから [有効化] または [キャッチアップ] を選択して、[進む] をクリックします。これを実行する場合、[有効化] および [キャッチアップ] タスクはバックグラウンドで実行されます。[キャッチアップ] を選択すると、[要有効化] ステータスのデータベースと [要キャッチアップ] ステータスのデータベースが表示されます。[有効化][キャッチアップ] の両方が、選択したすべての [要有効化] データベースに適用されます。

[ミラーリングされるデータベース] リストを使用して、1 つ以上のミラーリングされたデータベースをマウントまたはディスマウントするか、またはミラーから 1 つ以上のデータベースを削除することもできます。これについては "ミラーリングされるデータベースをミラーから削除する" で説明します。

Note:

データベース内のエラーが原因でミラーリングされたデータベースをキャッチアップできない場合、影響を受けたデータベースのホスト・メンバがプライマリになっても、そのデータベースはアクティブにはなりません。"自動フェイルオーバーのルール" で説明しているように、データベースが [開始時にマウントが必要] とマークされている場合は、そのメンバがプライマリになることはなくなります。

^MIRROR ルーチンの [ミラー管理] メニューの [ミラーリングされるデータベースの有効化/キャッチアップ] オプション、および SYS.Mirror.ActivateMirroredDatabase()Opens in a new tabSYS.Mirror.CatchupDB()Opens in a new tab ミラーリング API メソッドは、ミラーリングされるデータベースを有効化/キャッチアップするための代替手段となります。

[ミラーされたデータベース] リスト、管理ポータルの [データベース] ページ ("システム管理ガイド" の “InterSystems IRIS の管理” の章を参照)、または ^DATABASE ルーチン (コマンド行セキュリティ管理ユーティリティ を参照) を使用して、ミラーリングされたデータベースをマウントする場合、マウント操作後にデータベースをキャッチアップするかどうかを選択できます。

並列デジャーナリング ("並列デジャーナリングの構成" を参照) は、有効になっていて、使用可能なリソースによってサポートされている場合、ミラーリングされるデータベースをキャッチアップするときに使用されます。

ミラー・メンバの編集または削除

以下の手順は、ミラーをまとめて削除する処理も含め、ミラー・メンバでミラー構成を編集または削除する方法と、ミラー構成を削除しない場合にミラーからデータベースを削除する方法を示しています。

Note:

^MIRROR ルーチンの [ミラーの構成] メニューにあるいくつかのオプションでは、ミラー構成の編集のための代替手段を用意しています。使用可能な具体的オプションは、ルーチンがフェイルオーバー・メンバまたは非同期メンバのいずれにより使用されるかによって異なります。

レポート非同期ミラー・メンバの FailoverDB フラグのクリア

"非同期ミラー・メンバ" の説明にあるように、非同期メンバは、以下の 3 つのタイプのいずれかであることが必要です。

  • 災害復旧 (DR) — プライマリ上のミラーリングされるデータベースのすべての読み取り専用コピーを維持します。フェイルオーバー・メンバに昇格する条件を満たしています (詳細は、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照)。

  • 読み取り専用のレポート — ミラーリングされるデータベースの読み取り専用コピーを維持します。フェイルオーバー・メンバに昇格する条件を満たしていません。

  • 読み書き可能のレポート — ミラーリングされるデータベースの読み書き可能のコピーを維持します。フェイルオーバー・メンバに昇格する条件を満たしていません。

ミラーリングされるデータベースが DR または読み取り専用のレポート非同期に追加されると、そのデータベースは読み取り専用としてマウントされ、プライマリでデータベースを作成したときに設定される [FailoverDB] フラグは、以下の目的で非同期のコピーに設定されたままになります。

  • データベースが読み取り専用の状態を維持するようにして、プライマリ上のデータベースの正確なコピーであることを保証します (デジャーナリングがキャッチアップされることが前提)。

  • DR 非同期メンバがフェイルオーバー・メンバに昇格したときに、データベースがミラー内でプライマリ・コピーになれることを示します。DR 非同期メンバは、ミラー内のすべてのデータベースを含んでいて、そのすべてのデータベースに [FailoverDB] フラグが設定されている場合にのみ昇格できます。

その一方で、ミラーリングされるデータベースが、読み書き可能のレポート非同期に追加されるときには、データベースを読み書き可能でマウントできるように、[FailoverDB] フラグがクリアされます。ミラーリングされるデータベースは、[FailoverDB] フラグがクリアされていると、ミラーのプライマリ・コピーとして使用できなくなります。

DR 非同期の場合、[FailoverDB] フラグはクリアできません。ただし、レポート非同期では、このフラグを手動でクリアできます。

読み取り専用のレポート非同期の場合、[FailoverDB] フラグをクリアすると、データベースは読み書き可能に変更されますが、一般に、これは推奨されません。そのため、非同期のタイプを [災害復旧 (DR)] から [読み取り専用のレポート] に変更する場合を含めて ("非同期メンバの編集または削除" を参照)、ほとんどの場合、読み取り専用レポート非同期のすべてのデータベースでは、[FailoverDB] フラグを設定したままにできます。

非同期メンバのタイプを [災害復旧 (DR)] または [読み取り専用のレポート] から [読み書き可能のレポート] に変更する場合は、すべての [FailoverDB] フラグをクリアするオプションが使用可能です。ミラーリングされるデータベースの [FailoverDB] フラグは読み取り専用を維持する必要があるため、一般に、このオプションを使用することになります。ただし、読み書き可能のレポート非同期で、1 つ以上のミラーリングされるデータベースを読み取り専用のままにする必要がある場合は、[ミラーリングされるデータベース] リストにある個別の [フラグのクリア] リンクを使用して、一部のデータベースを読み書き可能にし、それ以外のものを読み取り専用のままにすることができます。

タイプを変更した後の非同期メンバに追加したデータベースは、前述したように、メンバの新しいタイプに従ってマウントされ、フラグが設定されます。[FailoverDB フラグのクリア] ボタンを使用すると、どちらのタイプのレポート非同期でも、すべてのデータベースから、いつでもフラグをクリアできます。

[FailoverDB] フラグを手動で設定することはできません。このフラグは、ミラーリングされるデータベースが DR または読み取り専用のレポート非同期に追加されるときにのみ設定されます。

ミラー・メンバ削除時のミラーされるデータベースの属性の削除

メンバをミラーから削除するときには、そのミラーに属するミラーリングされるデータベースからミラー属性を削除するためのオプションが常に提供されます。その結果は、以下のとおりです。

  • ミラー属性を保持しておいて、後で InterSystems IRIS インスタンスをそのミラーにリストアする場合、データベースはミラーに自動的に追加されますが、キャッチアップして同期するにはそれらのデータベースを有効化する必要があります ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照してください)。

    ただし、ミラー属性を維持すると、以下のいずれかを先に実行しない限り、そのデータベースは削除できなくなります。

    • メンバを削除した同じミラーにメンバを復元する (メンバがプライマリ・フェイルオーバー・メンバであった場合、ミラーは存在しなくなっているため、この方法は選択できません)。そうすると、1 つ以上のデータベースをミラーから削除できるようになり ("ミラーリングされるデータベースのミラーからの削除" を参照)、必要な場合は消去します。

    • ^MIRROR ルーチンの [1 つ以上のミラーリングされるデータベースの削除] オプションを使用して ("^MIRROR ルーチンの使用法" を参照)、1 つ以上のデータベースからミラー属性を削除し、必要に応じてデータベースを削除する。

  • ミラー属性を削除すると、そのデータベースは永久にミラーリングされなくなり、ローカル・データベースのように使用できるようになります。インスタンスがミラー・メンバとして再び参加した後にミラーに戻す場合、最初にデータベースを既存データベースとしてミラーに追加するための手順を使用する必要があります。

バックアップまたは非同期メンバのミラーから個別のデータベースを削除すると、ミラーリングされるデータベースの属性は、自動的に削除されます。

非同期メンバの編集または削除

  1. [非同期構成の編集] ページ ([システム管理][構成][ミラー設定][非同期の編集]) に移動します。

  2. [ミラー構成を削除する] ボタンを使用して、DR 非同期をミラーから削除するか、レポート非同期をすべての所属先ミラーから削除して、インスタンスのミラー構成全体を削除します。(単一ミラーからレポート非同期を削除するには、この手順の後半で述べる [ミラーから脱退] リンクを使用します)。

    メンバ上のミラーリングされるデータベースからミラー属性を削除するためのオプションが選択できます。この選択の判断に関する詳細は、"ミラー・メンバ削除時のミラーリングされるデータベースの属性の削除" を参照してください。

    また、インスタンスの TLS 構成を削除するというオプションを選択することもできます ("TLS セキュリティを使用したミラー通信の保護" を参照)。

    [ミラー構成を削除する] ボタンを使用して、インスタンスのミラー構成全体を削除した後は、InterSystems IRIS を再起動する必要があります。

    Note:

    ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) の [ミラー構成] メニューにある [ミラー構成を削除する] オプションおよび SYS.Mirror.RemoveMirrorConfiguration()Opens in a new tab API 呼び出しでは、非同期メンバのミラー構成全体を削除するための代替手段が提供されます。

  3. [ミラーに参加] ボタンを使用して、レポート非同期メンバを他のミラーに追加します (最大で 10 個まで所属できます)。非同期メンバを最初のミラーに追加するための手順は、"非同期ミラー・メンバを構成する" で説明したものと同じですが、メンバ名と非同期タイプ (読み取り専用または読み書き可能) の変更は不可能です。このボタンは、DR 非同期メンバには使用できません。別のミラーに参加するには、まず、後述の手順で説明するように、[非同期メンバのシステム・タイプ] を変更しておく必要があります。

  4. "レポート非同期ミラー・メンバの FailoverDB フラグのクリア" の説明にあるように、[FailoverDB フラグのクリア] ボタンを使用すると、読み取り専用のレポート非同期にあるすべてのミラーリングされるデータベースの [FailoverDB] フラグをクリアできます。または、非同期システム・タイプを [災害復旧 (DR)] から [読み書き可能] または [読み取り専用のレポート] に変更した後で、このボタンを使用するとフラグをクリアできます。

  5. [ミラー・メンバ情報] セクションの以下の設定は、編集中の非同期メンバに対して変更可能ですが、ミラー・メンバ名は例外です。1 つ以上変更した後に、[保存] をクリックします。

    • [ミラー・メンバ名] — 非同期メンバが最初のミラーへ参加したときに、与えられる名前。変更はできません。

    • [非同期メンバのシステム・タイプ] — ドロップダウン・リストを使用して、非同期メンバのタイプを変更できます。 以下の条件が適用されます。

      • [災害復旧 (DR)] から [読み書き可能のレポート] に変更すると、すべてのミラーリングされるデータベースに対して、[FailoverDB] フラグをクリアするよう促されます。これについては、"レポート非同期ミラー・メンバの FailoverDB フラグのクリア" で説明しています。

      • [読み書き可能のレポート] から [読み取り専用のレポート] (またはその逆) へ変更した場合、変更はレポート非同期メンバが属するすべてのミラーに対して施されます。

      • [読み書き可能] または [読み取り専用のレポート] から [災害復旧 (DR)] に変更することはできません。ただし、以下の条件がすべて当てはまる場合は変更できます。

        • ジャーナル暗号化を使用している場合、非同期はフェイルオーバー・メンバと同じジャーナル暗号化キーを使用していること ("ミラー内ジャーナル暗号の有効化" を参照)。

        • [FailoverDB] フラグが、ミラーリングされるデータベースのすべてに設定されていること(一度クリアすると、このフラグはリセットできません。これに対処するには、[FailoverDB] が設定されている別のメンバから取ったデータベースのコピーを代わりに使用できます)。

        • メンバば別のミラーに属していないこと。

        • ISCAgent を実行していること ("ISCAgent の開始および停止" を参照)。

        デジャーナル・フィルタが非同期に対して設定されている場合 ("レポート非同期に対するデジャーナル・フィルタの使用" を参照)、そのフィルタは、[非同期メンバのシステム・タイプ][災害復旧 (DR)] に変更するときに削除されます。

        Important:

        レポート非同期を DR 非同期に変換する前に、昇格が必要な災害が発生した場合にそのメンバがフェイルオーバー・メンバになる準備が整っていることを確認してください ("DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照)。 このときに確認する事項は次のとおりです。

    • [ミラー・ジャーナル・ファイルの保有] (レポート非同期のみ) — ミラー・ジャーナル・ファイルがデジャーナルされた直後にミラー・ジャーナル・ファイルを削除するか、またはインスタンスのローカル削除ポリシーに従ってミラー・ジャーナル・ファイルを削除するか。 この設定は、レポート非同期にのみ使用できます。ジャーナル・ファイルの削除方法についての詳細は、"データ整合性ガイド" の “ジャーナリング” の章にある "ミラー・ジャーナル・ファイルの削除" を参照してください。

    • [SSL/TLS構成] — TLS が要求される場合は ("TLS セキュリティを使用したミラー通信の保護" を参照)、X.509 識別名 (DN) と共に [SSL を検証] ボタンが表示されます。このボタンを使用すると、編集中の非同期と通信可能な、現在のすべてのミラー・メンバの TLS 証明書を検証できます。有効でない証明書があった場合、情報メッセージが表示されます (証明書は、^Mirror ルーチンを使用して検証することもできます)。

      ミラーで TLS を使用していないときに、ミラーに TLS を追加する場合は、TLS を構成するための [SSL/TLS] リンクを使用できます ("フェイルオーバー・メンバの編集または削除" を参照)。

      Note:

      SYS.Mirror.UpdateMirrorSSL()Opens in a new tab ミラーリング API メソッドおよび ^SECURITY ルーチンを使用して、ミラー・メンバの TLS 設定を更新することもできます。

  6. [この非同期メンバが属するミラー] リストにより、非同期メンバとしてインスタンスが属するすべてのミラーが表示されます。各エントリには、変更のための 3 つのリンクがあります。

    • [ミラー名][名前] 列に表示されるミラーの名前をクリックすると、[ミラーの編集] ダイアログが開き、ミラーのすべてのメンバのインスタンス・ディレクトリおよびネットワーク・アドレスが表示されます ("ミラー・メンバのネットワーク・アドレス" を参照)。

      現時点で非同期がミラーに接続されている場合、非同期のスーパーサーバ・ポートを除いて、表示されているネットワーク情報は一切変更できません。非同期メンバが切断されているときに、プライマリのネットワーク情報を更新した場合、ここでプライマリの情報を更新できるので、必要に応じて非同期を再接続できます。ミラー・メンバのネットワーク・アドレスの更新に関する重要な情報は、"ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

    • [ミラーから脱退] — クリックしたリンク先のミラーから、およびそのミラーのみから非同期メンバを削除します。(DR 非同期の場合、これは所属ミラーのみになります。)

      非同期メンバ上のミラーリングされるデータベースからミラー属性を削除するためのオプションが提供されます。このときの判断に関する詳細は、"ミラーリングされるデータベースの属性の保持または削除" を参照してください。

      Note:

      ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) の [ミラー構成] メニューにある [ミラーからこのメンバを削除する] オプションおよび SYS.Mirror.RemoveOneMirrorSet()Opens in a new tab API 呼び出しでは、非同期メンバをミラーから削除するための代替手段が提供されます。フェイルオーバー・メンバ上で [ミラーの編集] ページの [他のミラー・メンバを削除する] ボタンを使用して、ミラーから非同期メンバを削除することもできます。

      あらゆる非同期メンバで、ミラーリングを一時停止できます (1 つのレポート非同期が複数ミラーに所属している場合は、ミラーごとに一時停止できます)。詳細は、"バックアップおよび非同期メンバのミラーリングの停止" を参照してください。

    • [デジャーナル・フィルタの編集] (レポート非同期のみ) — 非同期に対するデジャーナル・フィルタを設定または削除できます。詳細は、"レポート非同期に対するデジャーナル・フィルタの使用" を参照してください。

  7. [ミラーリングされるデータベース] リストにより、非同期メンバのミラーリングされるデータベースがすべて表示されます。インスタンスが DR 非同期メンバの場合は、インスタンスにミラーのフェイルオーバー・メンバ上のミラーリングされるデータベースをすべて含める必要があります。また、それぞれに [FailoverDB] フラグが設定される必要があります。

  8. TLS を使用するミラーで、[保留中の DN 更新を承認] を選択し (表示されている場合)、プライマリからの保留中の DN 更新を承認して、非同期がプライマリとの通信を継続できるようにします。DN 更新の承認の詳細は、"X.509 DN 更新の承認 (TLS のみ)" を参照してください。

フェイルオーバー・メンバの編集または削除

  1. [ミラーの編集] ページ ([システム管理][構成][ミラー設定][ミラーの編集]) に移動します。

  2. バックアップ・フェイルオーバー・メンバで [ミラー構成を削除する] ボタンを使用すると、ミラーから削除され、InterSystems IRIS インスタンスのミラー構成全体が削除されます。

    Important:

    ミラー全体を削除する場合、ミラーからまずすべての非同期メンバを削除してから、バックアップ・フェイルオーバー・メンバを削除し、最後にプライマリ・フェイルオーバー・メンバを削除します。

    ミラーからフェイルオーバー・メンバを削除するときには、そのメンバ上のミラーリングされるデータベースからミラー属性を削除するオプションが選択できます。この選択の判断に関する詳細は、"ミラー・メンバ削除時のミラーリングされるデータベースの属性の削除" を参照してください。これは、プライマリ・フェイルオーバー・メンバを削除することで、ミラーを永久に削除する場合は特に重要です。

    バックアップでは、インスタンスの TLS 構成を削除するオプションを選択することもできます ("TLS セキュリティを使用したミラー通信の保護" を参照)。

    プライマリで [他のミラー・メンバを削除する] ボタンを使用して、ミラーからバックアップまたは非同期を削除することもできます。バックアップで [他のミラー・メンバを削除する] ボタンを使用すると、ミラーから非同期を削除できます。

    [ミラー構成を削除する] ボタンまたは [他のミラー・メンバを削除する] ボタンを使用して、非同期またはバックアップ・メンバのミラー構成全体を削除した場合は、InterSystems IRIS を再起動する必要があります。

    Note:

    ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) の [ミラー構成] メニューにある [ミラー構成を削除する] オプションおよび SYS.Mirror.RemoveMirrorConfiguration()Opens in a new tab API 呼び出しでは、フェイルオーバー・メンバのミラー構成全体を削除するための代替手段が提供されます。

    バックアップ・フェイルオーバー・メンバのミラーリングは一時的に停止できます。詳細は、"バックアップおよび非同期メンバのミラーリングの停止" を参照してください。

  3. ミラーからプライマリ・フェイルオーバー・メンバを削除して、ミラー全体を削除するには、以下の手順を使用します (プライマリがミラー内に残された最後のメンバである場合にのみ実行できます)。

    1. [ミラーの編集] ページの [ミラー構成を削除する] ボタンを使用します。ダイアログが表示され、インスタンスの [JoinMirror] フラグをクリアできます。

    2. フラグをクリアした後で、インスタンスを再起動します。

    3. [ミラーの編集] ページに移動して、[ミラー構成を削除する] ボタンを再び使用します。

  4. [ミラー情報] セクションで [ミラー名] を編集することはできません。それ以外の設定は、プライマリ・フェイルオーバー・メンバでのみ変更できます。

    • [SSL/TLS 使用] — ミラー作成時に TLS セキュリティを選択しなかった場合 ("TLS セキュリティを使用したミラー通信の保護" を参照)、以下の手順に従ってミラーに TLS セキュリティを追加できます。

      1. プライマリ、バックアップ、およびすべての非同期 (存在する場合) を含む各ミラー・メンバで、ミラーを編集し、[SSL/TLS 使用] チェック・ボックスの右にある [SSL/TLS の構成] リンクをクリックし、"ミラー用 TLS 構成の作成および編集" セクションの説明に従って、メンバに対してミラーの TLS 構成を作成してください。(リンクが [SSL/TLS を設定] ではなく [SSL/TLS を編集] である場合、構成は既に存在するため、そのメンバに対しては作成する必要はありません。)

      2. プライマリでミラーを編集し、[SSL を検証] ボタンをクリックします。これにより、編集中のフェイルオーバー・メンバが通信できる現在のすべてのミラー・メンバの証明書を検証できます。(証明書は、^MIRROR ルーチンを使用して検証することもできます)。無効な証明書がある場合、通知メッセージが表示されます。構成を確認し、必要に応じて証明書を置き換えてください。それ以外の場合は、次のステップに進みます。

      3. [SSL/TLS を使用] チェック・ボックスにチェックを付けて、[保存] をクリックします。

      4. "第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (TLS ミラーのみ)" に説明されているとおり、バックアップおよび非同期のメンバを承認します。

      Note:

      この手順で TLS セキュリティを追加する際、ミラーが稼働している必要はありません。

      SYS.Mirror.UpdateMirrorSSL()Opens in a new tab ミラーリング API メソッドおよび ^SECURITY ルーチンを使用して、ミラー・メンバの TLS 設定を更新することもできます。

    • アービターを使用 — ミラー作成時にアービターを構成しなかった場合は、この設定をプライマリで選択し、アービターとして構成するシステムのホスト名または IP アドレス、およびその ISCAgent プロセスで使用するポート (既定では 2188) を入力することで、アービターを構成できます。 アービターに関する詳細は、"自動フェイルオーバーのメカニズム"、"ミラーの可用性を最適化するためのアービターの配置"、および "アービターのインストール" を参照してください。

    • 仮想 IP を使用 — このチェック・ボックスにチェックを付ける、または外すことにより、仮想 IP アドレスを使用するかどうかを変更します。[仮想 IP を使用] を選択した場合、IP アドレス、クラスレスのドメイン間ルーティング (CIDR) マスク、およびネットワーク・インタフェースを与える必要があります (提供済みの場合は変更可能)。

      Important:

      VIP 構成前の要求事項や重要考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。

    • サービス品質のタイムアウト (msec) — フェイルオーバー・メンバが、アクションを実行する前に、他のフェイルオーバー・メンバからの応答を待機する最大時間 (ミリ秒単位)。さらに、フェイルオーバー・メンバの応答をアービターが待機する場合にも適用されます。詳細は、"サービス品質 (QoS) タイムアウトの構成" を参照してください。この設定は、プライマリ・フェイルオーバー・メンバでのみ変更できます。

    • [フェイルオーバ・メンバの圧縮モード][非同期メンバの圧縮モード] — プライマリからバックアップ・メンバおよび非同期メンバそれぞれにジャーナル・データを転送する前にデータを圧縮するかどうかと、それぞれに使用する圧縮タイプを指定する設定を変更します。詳細は、"ミラー・トラフィックの圧縮" を参照してください。一方または両方の圧縮設定を変更すると、その影響を受けるすべてのメンバ (バックアップや非同期) のミラー接続が再起動され、新しい圧縮モードがすぐに使用できるようになります。

    • [並列デジャーナリングを許可する] — 並列デジャーナリングを有効にする対象をフェイルオーバー・メンバおよび DR 非同期にする (既定) か、レポート非同期を含むすべてのメンバにするか、またはフェイルオーバー・メンバのみにするかを指定する設定を変更します。並列デジャーナリングではミラーのスループットが向上しますが、複数のデータベースが関与するクエリまたはレポートの結果の一貫性が損なわれる可能性が若干高まる場合があります。詳細は、"並列デジャーナリングの構成" を参照してください。

  5. [ミラー・メンバ情報] セクションには、各ミラーメンバのメンバ名とタイプ、インスタンス・ディレクトリ、およびネットワーク・アドレスが表示されます。プライマリで、メンバ名をクリックして、そのメンバのネットワーク情報を更新します (メンバのスーパーサーバ・ポートを除きます。このポートは、ローカルに更新する必要があります。詳細は、"ミラー・メンバのネットワーク・アドレス"の更新" を参照してください)。

    現時点でバックアップがミラーに接続されている場合、ネットワーク情報は一切変更できません (バックアップのスーパーサーバ・ポートを除く)。バックアップを切断して、プライマリのネットワーク情報を変更した場合は、ここでプライマリの情報を更新できるので、必要に応じてバックアップが再接続できます。ミラー・メンバのネットワーク・アドレスの更新に関する重要な情報は、"ミラー・メンバのネットワーク・アドレスの更新" を参照してください。

  6. TLS を使用するミラー内のプライマリで、[保留中の新しいメンバの承認/拒否] リンクを選択し (表示されている場合)、新しいメンバを承認して、ミラーに参加できるようにします。または、[保留中の DN 更新の承認/拒否] リンクを選択し (表示されている場合)、その他のメンバの DN 更新を承認して、ミラーの通信を継続できるようにします。バックアップで、[保留中の DN 更新の承認] を選択し (表示されている場合)、プライマリからの保留中の DN 更新を承認して、バックアップがプライマリとの通信を継続できるようにします。DN 更新の承認の詳細は、"X.509 DN 更新の承認 (TLS のみ)" を参照してください。

  7. [保存] をクリックします。

Note:

プライマリの [ミラーの編集] ページにある [新規非同期メンバの追加] ボタンは、他の InterSystems 製品で使用するために予約されています。今回のバージョンの InterSystems IRIS では、このボタンを使用しないでください。

ミラーリングされるデータベースをミラーから削除する

ミラー・モニタを使用して、データベースをミラーから削除することにより、データベースをミラーリングされる状態から、ミラーリングされないローカル用に変換できます (ミラー・モニタに関する詳細は、"ミラーの監視" を参照してください)。

Note:

あるいは、ミラーリングされるデータベースをミラーから複数削除するには、^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) の [ミラー管理] メイン・メニュー・リストから [ミラーリングされるデータベースの削除] オプションを選択するか、SYS.Mirror.RemoveMirroredDatabase()Opens in a new tab API 呼び出しを使用できます。

非同期メンバ上でミラーからデータベースを削除しても、フェイルオーバー・メンバは影響を受けません。データベースは機能しているミラーの一部として残ります。ただし、データベースをフェイルオーバー・メンバから削除した場合、データベースがミラーリングされる他のフェイルオーバー・メンバや非同期メンバからもデータベースを削除する必要があります。データベース全体をミラーから削除するには、プライマリ・フェイルオーバー・メンバ、バックアップ・フェイルオーバー・メンバ、任意の非同期メンバの順でデータベースの削除を行います。

Important:

プライマリでミラーからデータベースを削除すると、データベースは完全に削除されます。プライマリで、ミラーリングされるデータベースを削除して、後でミラーに戻すには、最初に既存のデータベースをミラーに追加するために使用した手順が必要になります。

データベースをミラーから削除するには、いずれかのフェイルオーバー・システムで次の手順を実行します。

  1. プライマリ・フェイルオーバー・メンバの [ミラー・モニタ] ページ ([システム処理][ミラー・モニタ]) に移動します。

  2. [ミラーリングされるデータベース] リスト内で、ミラーから削除するデータベースの行の [削除] をクリックします。

    一度に複数のデータベースを削除する場合は、[アクションを選択してください] ドロップダウンから [削除] を選択し、[検索] をクリックしてダイアログを開き、そこで複数のミラーリングされたデータベースを選択してすべてを一度に削除できます。

ミラーでのマネージド・キー暗号化の使用法

"暗号化ガイド" に説明されているように、個々の InterSystems IRIS データベースを暗号化して保護することができます。任意の InterSystems IRIS インスタンスでジャーナル・ファイルの暗号化を有効にすることもできます。以下のセクションでは、ミラーでこれらの機能を使用する方法を説明します。

ミラーリングされたデータベースの暗号化

ミラー・メンバ上のデータベース暗号化には、いずれのシステムでも準備が必要ですが、データベース暗号化についてはミラーリングに関する特定の要件はありません。ただし、最高度のセキュリティを実施するには、すべてのミラー・メンバ上のミラーリングされたデータベースを暗号化することをお勧めします。この理由から、別のメンバを暗号化せずにプライマリ上で暗号化されているミラーリング・データベースをそのメンバに追加する場合、セキュリティ警告がメッセージ・ログに送信されます。

"ミラー構成のガイドライン" で説明しているように、フェイルオーバー・メンバの平等性のベスト・プラクティスに基づいて、所定のデータベースは通常、両方のフェイルオーバー・メンバおよび DR 非同期メンバ (フェイルオーバーに昇格する可能性のあるメンバ) と同じ暗号化キーを使用して暗号化されます。

少なくとも 1 つの暗号化キーが有効化されると、新規作成するいずれのデータベースでも暗号化することを選択できます。したがって、"ミラーリングされるデータベースを作成する" で示している手順を使用する場合は、各ミラー・メンバでデータベースを作成する際に暗号化オプションを選択します。"ミラーへ既存データベースを追加する" で説明しているように既存のデータベースをプライマリ上のミラーに追加する場合に、そのデータベースが暗号化されているときは、追加先の各メンバで暗号化に使用されたキーを有効にするか、またはデータベースの追加後に各ミラー・メンバ上でデータベースを新しいキーに変換する必要があります。後者を実行する手順については、"新しいキーを使用するように暗号化データベースを変換する" を参照してください。(この手順を使用して、1 つ以上の既存の暗号化されたミラーリング済みデータベースを新しい暗号化キーに切り替えることや、データベースから暗号化を削除することもできます)。

既存のミラーのフェイルオーバー・メンバで 1 つ以上の暗号化されていないミラーリング済みデータベースを暗号化するには、以下の手順を使用します。

  1. "キー・ファイル内のキーの管理" の説明に従って、両方のフェイルオーバー・メンバで使用するために暗号化キーをロードして有効にします。

  2. バックアップでは、以下を実行します。

    1. "バックアップおよび非同期メンバのミラーリングの停止" の説明に従って、ミラーリングを停止します。

    2. "暗号化されていないデータベースを暗号化データベースに変換する" の説明に従って、各データベースを暗号化します。

    3. ミラーリングを開始します。

    4. "ミラーリングされるデータベースのステータス" の説明に従って、[ミラー・モニタ] ページ ([システム処理][ミラー・モニタ]) に進み、ミラーリングされたすべてのデータベースのステータスが [デジャーナリング] になるまで待機します。

  3. iris stop コマンドを使用して、プライマリを適切にシャットダウンし ("システム管理ガイド" の “InterSystems IRIS 複数インスタンスの使用法” の章にある "InterSystems IRIS インスタンスの制御" を参照)、ミラーがフェイルオーバーして、バックアップが新しいプライマリになるようにします。

  4. プライマリを再起動します。プライマリがバックアップになると、前の手順で元のバックアップについて説明した手順に従って、同じキーを使用して同じデータベースを暗号化します。

  5. 現在のバックアップをシャットダウンして、元のプライマリがもう一度プライマリになるようにします。

  6. 元のバックアップを再起動して、これがもう一度バックアップになるようにします。

非同期メンバで、ミラーリングされたデータベースを暗号化するには、前の手順でバックアップについて説明した手順に従って、ミラーリングを停止し、データベースを暗号化し、ミラーリングを開始します。ベスト・プラクティスは、フェイルオーバーに昇格する可能性のある DR 非同期上のフェイルオーバー・メンバで使用されたキーを使用することです。

ミラー内ジャーナル暗号の有効化

ミラー・メンバでジャーナル暗号化を有効にする場合、次の 3 つの重要な考慮事項に留意してください。

  • ミラーが TLS セキュリティを要求しない場合、フェイルオーバー・メンバおよび DR 非同期でジャーナル・ファイルの暗号化を有効にすることはできません。

  • ジャーナル暗号化がプライマリで有効化されている場合は、ミラーに属しているレポート非同期でも有効化されている必要があります。さらに、バックアップ非同期および DR 非同期も同様にジャーナル暗号化を有効化することが最善策になります。これにより、フェイルオーバーまたは DR 昇格の発生時に、ジャーナル暗号化の強制実施が継続されます。

  • フェイルオーバー・メンバ間または DR 非同期間でのジャーナル暗号化には、あるメンバで有効化されるジャーナル暗号化に使用する暗号化キー (ただし、必ずしもジャーナル暗号化に使用されている必要はありません) が別のメンバで、受信したジャーナル・ファイルの解読に (必要に応じて) 使用するために必要になります。具体的には以下の処理を行います。

    • ジャーナル暗号化がプライマリで有効化されている場合、プライマリでジャーナル暗号化に使用されているキーは、バックアップおよびすべての DR 非同期にロードされていて有効化されている必要があります。(プライマリのジャーナル暗号化キーがアクティブ化されていないレポート非同期が DR 非同期に変更されると、警告が生成されます。その非同期は一時的にミラーに接続された状態を維持できますが、次回の再接続ができなくなります。キーがアクティブ化されている場合を除いて、これが必要になります。)

    • バックアップまたは DR 非同期でジャーナル暗号化がアクティブ化されている場合は、そのメンバでジャーナル暗号化に使用されているキーはプライマリにロードされていてアクティブ化されている必要があります。

    繰り返しになりますが、フェイルオーバーまたは昇格の準備をする際の最善策として、フェイルオーバー・メンバであるメンバ (プライマリ、バックアップ) またはフェイルオーバー・メンバになる可能性のあるメンバ (DR 非同期) にジャーナル暗号化キーが指定されている場合、そのようなメンバのすべて (複数の DR 非同期を含む) に、このキーをロードしておく必要があります。

    Note:

    レポート非同期のみでジャーナル暗号化を有効にする場合、ミラーで TLS セキュリティを要求する必要はなく、唯一の暗号化キー要件は、有効化する各レポート非同期でジャーナル暗号化用のキーを選択することです。

以下は、フェイルオーバー・メンバ A (現在のプライマリ) と B (現在のバックアップ)、DR 非同期 D、およびレポート非同期 R で構成されるミラーでジャーナル暗号化を有効にする手順を説明しています。

  1. 現時点でミラーに TLS セキュリティが必要ない場合は ("TLS セキュリティを使用したミラー通信の保護" を参照)、"フェイルオーバー・メンバの編集または削除" で説明している手順を使用して、そのようにミラーを構成します。

  2. A、B、および D の暗号化ジャーナル・ファイルに使用する 1 つまたは複数の暗号化キーを選択します。これらは、別々のものにすることができます (必要な場合)。

  3. A、B、D、およびオプションで R を DR 非同期に変換できる場合は、それぞれで次の手順を実行します。

    1. A、B、D (およびオプションで R) で、ジャーナル・ファイルの暗号化に使用するすべてのキーをロードして、まだ有効にしていない場合は有効にします。

    2. "インスタンスの既定のデータベース暗号化キーまたはジャーナル暗号化キーの指定" の説明に従って、インスタンスでジャーナル暗号化に使用する目的のキーを選択します。

  4. 前の手順でまだ実行していない場合は、R でジャーナル暗号化キーをロードし、有効にして、選択します。

  5. "暗号化の起動設定の構成" の説明に従って、A、B、D、および R で、この順にジャーナル暗号化を有効にします。

    インスタンスでジャーナル暗号化を有効にすると、インスタンスの再起動か次のジャーナル切り替えのいずれか先に生じた方の後に暗号化が開始します。ミラー・メンバを再起動せずに変更がすぐに生じるようにするには、"データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナル・ファイルの切り替え" で説明しているように、各メンバでジャーナル・ファイルを手動で切り替えます。

    Note:

    ^JOURNAL ルーチン ("データ整合性ガイド" の “ジャーナリング” の章を参照) には、ジャーナル暗号化を有効化/無効化する際に、管理ポータルの代わりに使用できるオプションが含まれます。このオプションを使用して暗号化を有効化すると、インスタンスは直ちに暗号化ジャーナル・ファイルに切り替わり、暗号化の起動設定が [インタラクティブ] に設定されます。

インスタンスでジャーナル暗号化キーを切り替えるには、新しいキーをロードして、有効にし、選択します。この新しいキーは、インスタンスの再起動か次のジャーナル切り替えのいずれか先に生じた方の後に暗号化に使用されます。

ジャーナル暗号化を有効にした後で、ミラーに DR 非同期を追加するときに、A、B、および D で使用しているジャーナル暗号化キー (1 つまたは複数) が、追加前の新しい DR 非同期で有効化されていることを確認してください。

ミラーへのアプリケーション・サーバ接続の構成

"ミラーの自動導入方法" に説明されているいずれかの方法を使用して、ミラーリングされたデータ・サーバと共に分散キャッシュ・クラスタを導入する場合、必要な構成はすべて自動化されます。管理ポータルを使用してクラスタを導入する場合は、各アプリケーション・サーバに追加するときにデータ・サーバがミラーであることを示す必要があります。いずれかの方法によって、データ・サーバがミラー接続として構成されている場合、各アプリケーション・サーバは、ミラーについて更新された情報をプライマリから定期的に収集し、フェイルオーバーを自動的に検出し、必要に応じて新しいプライマリに接続をリダイレクトします。

自動導入方法を使用した、ミラーリングされたデータ・サーバの構成の詳細は、"ミラーの自動導入方法" にリストされているドキュメントを参照してください。分散キャッシュ・クラスタ内のデータ・サーバとしてミラーを手動で構成するには、次の手順を実行します。

  1. "スケーラビリティ・ガイド" の同じ章の "データ・サーバの準備" の説明に従って、フェイルオーバー・メンバと DR 非同期メンバの両方をデータ・サーバとして準備します。これらのインスタンスはすべて、同じ [アプリケーションサーバの最大数] 設定で構成する必要があります。

  2. 各アプリケーション・サーバで、以下を実行します。

    • "スケーラビリティ・ガイド" の同じ章の "アプリケーション・サーバの構成" の説明に従って、データ・サーバを追加します。このとき、必ず [ミラー接続] チェック・ボックスにチェックを付けてください。また、[ホスト DNS 名または IP アドレス] に、ミラーの仮想 IP アドレス (VIP) ではなく (ある場合でも)、現在のプライマリ・フェイルオーバー・メンバの DNS 名または IP アドレスを入力してください。

    • "アプリケーション・サーバの構成" の説明に従って、データ・サーバ上の 1 つ以上のリモート・データベースにマッピングされた 1 つ以上のネームスペースを作成します。ミラーリングされているデータベース (:mirror:mirror_name:mirror_DB_name としてリストされているデータベース) とミラーリングされていないデータベース (:ds:DB_name としてリストされているデータベース) の両方を選択できます。ミラーのフェイルオーバーの発生時には、ミラーリングされているデータベースにのみアプリケーション・サーバがアクセス可能な状態が維持されます。データ・サーバがフェイルオーバー・メンバの場合、ミラーリングされているデータベースは読み取り/書き込みとして追加され、ミラーリングされていないデータベースは、ジャーナリングされている場合は読み取り専用、ジャーナリングされていない場合は読み取り/書き込みとして追加されます。データ・サーバが DR 非同期メンバの場合、すべてのデータベースが読み取り専用として追加されます。

    Note:

    ミラーリングされるデータベースの「:mirror:mirror_name:mirror_DB_name:」というパス形式は、暗示的なネームスペース拡張グローバル参照に使用することもできます ("グローバルの使用法" の “グローバル構造” の章の "拡張グローバル参照" を参照してください)。

Important:

フェイルオーバー・ミラー・メンバは、前記したようにミラー接続として構成されていない ECP 接続を受け入れません。また、ミラー・メンバではないデータ・サーバは、ミラー接続として構成されている ECP 接続を受け入れません。つまり、既存のデータ・サーバをミラーに追加する場合、またはデータ・サーバをミラーから削除する場合、すべてのアプリケーション・サーバのリモート・データ・サーバとしてデータ・サーバを削除してから、適切な手順、つまり、ここで説明したミラー接続として、またはフェイルオーバー・メンバへの接続がない場合には [ミラー接続] のチェック・ボックスのチェックを外して、再度データ・サーバを追加します。

ミラーに接続するようアプリケーション・サーバを構成した後に、現在のプライマリを適切にシャットダウンすることによってリダイレクト・テストを実施し、アプリケーション・サーバが目的のミラー・メンバに接続していることを確認してください。

アプリケーション・サーバの ECPServer 定義の Address プロパティおよび Port プロパティによって指定されたミラー・メンバに接続を制限している間には、データ・サーバをミラー接続として識別することもできます。つまり、アプリケーション・サーバは、指定されたメンバがプライマリではない場合でも接続をリダイレクトしません。このように接続を構成すると、以下のルールが適用されます。

  • 指定されたメンバがプライマリの場合、アプリケーション・サーバからの接続を通常として受け入れます。メンバがフェイルオーバー・メンバだがプライマリではない場合 (前のプライマリが再起動されてバックアップになったときなど)、これがプライマリになったときに接続を受け入れます。

  • 指定されたメンバが前のプライマリで、再起動されて再びプライマリになった場合、アプリケーション・サーバのこのメンバへの接続はリカバリされます。メンバがフェイルオーバー・メンバだがプライマリではない場合、これがプライマリになるまで接続を受け入れません。

  • 指定されたメンバが DR 非同期の場合、接続を受け入れ、ミラーリングされるデータベースへの読み取り専用アクセス権をアプリケーション・サーバに付与します (また、アプリケーション・サーバでリモート・データベースとして構成されているその他すべてのデータベースにも付与します)。

指定されたミラー・メンバに接続を制限することは、他のメンバに接続をリダイレクトすることが望ましくないとき (接続が高遅延 ECP 接続になるなど) に、ある特別な構成で役に立ちます。2 つの使用例を以下に示します。

  • ミラー・プライマリがデータ・センタ A (DCA) にあり、バックアップまたは DR 非同期がリモート・データ・センタ (DCB) にあるとします。各メンバにアプリケーション・サーバが構成された独自のバンクがあるとします。 ネットワーク・ロード・バランサが接続を正しいデータ・センタに接続します。ただし、プライマリが使用できなくなり、DCB のメンバがフェイルオーバーまたは昇格によってプライマリになった場合、DCA のアプリケーション・サーバが DCB のメンバに接続することを望みません。DCA と DCB の間で高遅延接続が発生することになるからです。この状況では、DCA のアプリケーション・サーバで、フェイルオーバー発生時に DCB にリダイレクトしないようにミラー接続をプライマリに制限し、DCA のメンバが再びプライマリになるときにデータセンタ間の接続をリカバリできるようにします。

  • プライマリとバックアップが DCA にあり、DR 非同期が災害発生時に使用する独自のアプリケーション・サーバと共にリモート DCB にあるとします。 DCA のアプリケーション・サーバでは、プライマリは標準のミラー接続で構成されます。これは、フェイルオーバー時に DCA 内で接続をリダイレクトするためです。 ただし、DCB のアプリケーション・サーバでは、ミラー接続は DR 非同期にリダイレクトされます。このようにすれば、災害リカバリ準備の一環としてまたは実際の災害時のカット・オーバーの前に読み取り専用ベースでミラー接続をテストできます。DR 非同期が昇格された後、DCA のアプリケーション・サーバは接続を DCB の新しいプライマリにリダイレクトしますが (ネットワーク・レベルで妨げられていない場合)、まだ降格されていない場合には、降格してこの動作を妨げることができます。

管理ポータルを使用してアプリケーション・サーバの接続を指定ミラー・メンバに制限できません。代わりに、以下の手順を実行します。

  1. このセクションで説明した手順を使用してフェイルオーバー・メンバおよび DR 非同期をデータ・サーバとして準備し、各アプリケーション・サーバでデータ・サーバへの接続を構成します (この手順をまだ実行していない場合)。

  2. Config.ECPServer クラスを使用してアプリケーション・サーバの MirrorConnection プロパティを変更し、その値として -1 を指定します。アプリケーション・サーバ・インスタンスの iris.cpf ファイルを編集することもできます。ファイルの [ECPServers] セクションで、3 番目のパラメータを 0 から -1 に変更します。詳細は、"構成パラメータ・ファイル・リファレンス" の "ECPServers" を参照してください。

    いずれかの方法で MirrorConnection プロパティを変更したら、管理ポータルを使用して [ミラー接続] チェック・ボックスの設定を変更しないでください。

ミラー仮想 IP (VIP) の構成

"ミラー仮想 IP (VIP) の計画" で説明しているように、フェイルオーバーで継続的なアクセスを確保するために、外部アプリケーションが単一のアドレスを使用してミラーと対話できるようにするミラー仮想アドレスを構成することができます。

ミラー VIP を使用するよう InterSystems IRIS を構成してからミラー VIP を構成した後に、現在のプライマリを適切にシャットダウンすることによってフェイルオーバー・テストを実施し ("計画的停止の手順" に記載)、どちらのフェイルオーバー・メンバがプライマリであるかに関係なく、アプリケーションが引き続きミラーに接続できることを確認してください。

Important:

Linux プラットフォームでミラー VIP を構成する前に、該当するパッケージ (例えば、Debian iputils-arping パッケージOpens in a new tab) をインストールすることによって arping コマンドを使用可能にしておいてください。

1 つ以上のミラー・メンバが、UNIX® または Linux システム上の非 root InterSystems IRIS インスタンスの場合、"インストール・ガイド" の “UNIX® および Linux への InterSystems IRIS のインストール” の章にある、"InterSystems IRIS 非 root インストール" で説明されているように、ミラー VIP は使用できません。

Note:

VIP 使用時に DR 非同期をプライマリに昇格する処理に関する重要な情報は、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください。

ミラー VIP の InterSystems IRIS 構成

現在どちらのフェイルオーバー・メンバがプライマリとなっているのかに関係なく、管理ポータルとスタジオが、確実にミラーにシームレスにアクセスできるようにするために、同じスーパーサーバ・ポート番号および Web サーバ・ポート番号を使用するように、フェイルオーバー・メンバを構成することをお勧めします。

ミラーリングされたデータ・サーバと組み合わせた分散キャッシュ・クラスタ内のアプリケーション・サーバは、ミラーの VIP を使用しません。データ・サーバとしてミラーを追加する場合は ("ミラーへのアプリケーション・サーバ接続の構成" を参照)、ミラーの仮想 IP アドレス (VIP) を入力するのではなく、現在のプライマリ・フェイルオーバー・メンバの DNS 名 または IP アドレスを入力します。アプリケーション・サーバは、指定のホストからミラーに関する更新情報を定期的に収集しているので、フェイルオーバーを自動的に検出し、新しいプライマリ・フェイルオーバー・メンバに切り替えます。この理由から、フェイルオーバー・メンバとすべての DR 非同期メンバは、データ・サーバとして、同じ [アプリケーションサーバの最大数] 設定で準備する必要があります。詳細な分散キャッシュに関する考慮事項については、"ミラーへのアプリケーション・サーバ接続の構成" を参照してください。

1 つまたは両方のフェイルオーバー・メンバをライセンス・サーバとして構成する場合 ("システム管理ガイド" の “InterSystems IRIS ライセンスの管理” の章で説明しています)、[ホスト名/IP アドレス] として構成するシステムの実際のホスト名または IP アドレスを指定します。VIP アドレスは入力しないでください。

ミラー VIP の構成

ミラー VIP を構成するには、次の情報を入力する必要があります。

  • ミラー VIP として使用可能な IP アドレス。VIP を予約して、その他のシステムが使用できないようにしておくことが重要です。例えば、動的ホスト構成プロトコル (DHCP) のネットワーク構成では、この VIP を予約し DNS テーブルから削除して、ネットワークに参加しているホストに動的に割り当てられないようにする必要があります。

  • クラスレスのドメイン間ルーティング (CIDR) 表記での指定が必要な適正ネットワーク・マスク。CIDR 表記の形式は、ip_address/CIDR_mask です。ip_address は、システムのベース IP アドレスです。CIDR_mask は、次のようにプラットフォームによって異なります。

    • macOS/32 である必要があります。

    • 他のすべてのプラットフォーム — ベース・インタフェースに割り当てられた IP アドレスのマスクと一致する必要があります。以下はその例です。

      bash-2.05b# uname -a
      AIX apis 3 5 00C0B33E4C00
      bash-2.05b# ifconfig en1
      en1:
      flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,
      GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
              inet 10.0.2.11 netmask 0xffffff00 broadcast 10.0.2.255
              tcp_sendspace 131072 tcp_recvspace 65536 rfc1323
      
      

      この例では、[en1] インタフェースは、ベース・アドレスが 10.0.2.11 でネットマスクが 0xffffff00 となっており、ネットマスクは /24 に変換されます。したがって、[en1] インタフェースに 10.0.2.100 を VIP として割り当てるには、ネットワーク・マスクを 10.0.2.100/24 (CIDR 表記) と指定します。

  • 各フェイルオーバー・メンバで使用可能なネットワーク・インタフェース2 つのシステムで選択されたインタフェースは、VIP と同じサブネットとする必要があります。

    ネットワーク・インタフェースを選択するときには、そのインタフェースを正しく動作させるために、以下のプラットフォーム固有の規則に従う必要があります。

    • IBM AIX®、Linux (Red Hat、SuSE、Ubuntu)、Apple macOS、および Windows — VIP を構成するときに、既存の物理ネットワーク・インタフェースを使用できるように設定する必要があります。これらのプラットフォームでは、IP アドレスのエイリアスは、IP アドレス (すなわち VIP) を既存の物理ネットワーク・インタフェースにバインドするために使用されます。また、このプラットフォームでは、単一の物理ネットワーク・インタフェースで複数の IP アドレスをホストできます。

ISCAgent の構成

ISCAgent の実行は、各ミラー・メンバ上の構成可能な専用ポート (既定値は 2188) で安全に行われます。このエージェントがネットワーク接続を受信してミラーリングされたインスタンスにつながると、そのインスタンスの irisuxagent を実行して、ミラー・メンバの管理に必要な特権にエスカレートします。ミラーが TLS を要求する構成の場合、何らかのアクションを実行する前に、受信接続が認証されます。

1 つ以上のミラーに属する複数の InterSystems IRIS インスタンスが、1 つのシステムでホストされている場合、それらのインスタンスは、1 つの ISCAgent を共有します。

ここでは、以下の方法で ISCAgent を管理するための情報を提供します。

ISCAgent の開始および停止

InterSystems IRIS のインストール時またはアップグレード時にインストールされる ISCAgent は既定により、ユーザ [ISCAgent] として、かつ [ISCAgent] グループのメンバとして動作します。InterSystems IRIS インスタンスへのアクセスを提供する irisuxagent ユーティリティの実行に必要なグループ特権 ("ISCAgent" を参照してください) を取得するために、ISCAgent は、システム起動時に自動で開始されるようにするか、root 特権を持つユーザが開始する必要があります。ISCAgent は、自身に必要なユーザ特権およびグループ特権を割り当てると、すべての root 特権を破棄します。

ISCAgent の構成により、各フェイルオーバー・メンバおよび DR 非同期ミラー・メンバでのシステム起動時に、ISCAgent を自動で開始させる必要があります。システム管理者が初期化プロセスに追加できるプラットフォーム固有の制御スクリプトが提供されています。これについて、以下の節で説明します(システム起動の構成手順の詳細は、オペレーティング・システムのドキュメントを参照してください)。

UNIX® および macOS システムでの ISCAgent の開始

UNIX® および macOS のプラットフォームでは、オペレーティング・システムに応じて、次の場所にインストールされる ISCAgent の開始および停止スクリプトを実行します。

  • IBM AIX® : /etc/rc.d/init.d/ISCAgent

  • macOS : /Library/StartupItems/ISCAgent/ISCAgent

例えば、IBM AIX® プラットフォームで ISCAgent を開始する場合は、root としてコマンド /etc/rc.d/init.d/ISCAgent start を実行します。このサービスを停止するには、コマンド /etc/rc.d/init.d/ISCAgent stop を実行します。

UNIX®/Linux のプラットフォームでの ISCAgent に関するその他の考慮事項としては、以下のものがあります。

  • 前述したように、ISCAgent は、各フェイルオーバー・メンバまたは DR 非同期メンバで、システム起動時に自動的に開始される必要があります。また、ユーザがこのエージェントを開始、停止、または再開するのが便利なときもあります。これは以下の方法で実行できます。

    • 前の手順で説明したように、root ユーザが直接的に実行します。

    • InterSystems IRIS インスタンスの開始と停止が可能なユーザが、InterSystems IRIS インスタンスの /bin ディレクトリにある agentctrl 実行ファイルを使用します。例えば、エージェントを開始するには、以下のコマンドを実行します。

      /iris/bin$ ./agentctrl start
      

      このコマンドは、引数 [停止] および [再開始] を取ります。

  • InterSystems IRIS では、ISCAgent のステータスを追跡するために iscagent.status ファイルを使用します。このファイルは、IRISSYS 環境変数で指定されるディレクトリ内にあります ("インストール・ガイド" の “インストールの準備” の章にある "インストール・ディレクトリ" を参照してください)。IRISSYS が定義されていない場合は、/var/run にあります。エージェントは、このファイルに対する排他的ロックを取得できる必要があるため、iscagent.status ファイルが /var/run に配置されていて、/var/run が NFS でマウントされたファイルシステムにある場合は、その NFS 構成が fcntl ファイル・ロックをサポートしている必要があります。

  • 前述したように、ISCAgent は irisuxagent を使用して、InterSystems IRIS インスタンスの管理に必要な特権を取得します。既定により、エージェントは irisuxagent の実行に必要な特権 ([ISCAgent] ユーザまたは [ISCAgent] グループ) を所有しており、標準的な構成においては変更が不要です。

    ただし、ユーザ・システムのセキュリティ構成により、ユーザ・サイトのインスタンスには、irisuxagent を実行するにあたって、ミラーリングされるインスタンスの /bin ディレクトリに移動するための追加特権が必要になる場合があります。この場合、ISCAgent の特権がコマンドの実行に十分なものであるかを確認する必要があります。そのためには、以下の手順に従って、エージェントの特権を変更できます。

    1. /etc/iscagent/iscagent.conf ファイルを作成します。ファイルが既に存在する場合は、それを編集します (例えば、以前にファイルを作成して、ISCAgent のポート番号やインタフェースをカスタマイズした場合)。

    2. グループ特権を追加するには、以下の行を追加して、irisuxagent の実行が必要なグループを 1 つ以上指定します。

      privileges.group=iscagent,<groupname>[,<groupname>[,...]]
      

      通常は、グループ特権の追加で十分となります。しかし、一部の構成では、別のユーザとして ISCAgent を実行することが必要になる場合もあります。これは、/etc/iscagent/iscagent.conf で、以下のように実行することもできます。

      privileges.user= <username>
      
      Note:

      irisuxagent には、[ISCAgent] グループ特権が必要なので、[ISCAgent] はグループ・リストに残る必要があります。

  • ISCAgent はオペレーティング・システムのシステム・エラー・ログ (Linux では /var/log/messages など) にメッセージを書き込みます。

Linux システムでの ISCAgent の開始

systemd をサポートしている Linux システム (SUSE Linux Enterprise Server 12 SP1 以降など) の場合は、/etc/systemd/system/ISCAgent.service ファイルがインストールされています。これにより、systemd を使用した ISCAgent の管理がサポートされるようになります。このようなシステムでは、ISCAgent の開始、停止およびステータスの表示に、以下のコマンドを使用できます。

systemctl start ISCAgent.service
systemctl stop ISCAgent.service
systemctl status ISCAgent.service

systemd をサポートするシステムの場合、システムのブート時に ISCAgent を開始するかどうかを制御するには、以下のコマンドを使用します。

sudo systemctl enable ISCAgent.service
sudo systemctl disable ISCAgent.service

既定では、systemd サービスは無効化されています。このサービスが無効化されている場合でも、systemctl を使用すると、必要に応じてサービスを開始および停止できます。

ISCAgent.service ファイルは、InterSystems IRIS レジストリ・ファイルと共有サポート・ファイルの場所を IRISSYS 環境変数から読み込みません ("インストール・ガイド" の “インストールの準備” の章にある "インストール・ディレクトリ" を参照してください)。代わりに、その場所として /usr/local/etc/irissys が指定されてインストールされます。ISCAgent.service を編集して、別のレジストリ・ディレクトリを指定することもできます (必要な場合)。

どの Linux システムでも、ISCAgent の開始/停止スクリプトは、/etc/init.d/ISCAgent にインストールされます。このスクリプトについては、"UNIX® および macOS システムでの ISCAgent の開始" を参照してください。systemd がサポートされていない場合は、上記のセクションで説明している ISCAgent の開始および停止コマンドを使用します。

"UNIX® および macOS システムでの ISCAgent の開始" に記載されたそれ以外の情報は、systemd をサポートする Linux システムにも適用されます。

Important:

systemd をサポートする Linux システムでは、systemctl コマンドと /etc/init.d/ISCAgent スクリプトのどちらを使用することも可能ですが、どちらか一方の方法に決めて、それを切り替えることなく排他的に使用する必要があります。ISCAgent を停止する際には、常に、それを開始した方法を使用する必要があります。

こういった Linux システムで InterSystems IRIS をアップグレードすると、実行されている ISCAgent は、systemd を使用して自動的に再起動されます。ISCAgent の管理に /etc/init.d/ISCAgent スクリプトを使用している場合は、このエージェントが自動的に再起動されないように、エージェントを停止してからアップグレードを実行し、アップグレードの後に、このスクリプトを使用してエージェントを再起動します。

/etc/init.d/ISCAgent スクリプトの使用から systemctl コマンドの使用に変更したら、初めて systemctl でエージェントを開始する前に root として以下を実行します。

  1. 以下のコマンドを実行します。

    systemctl status ISCAgent
    
  2. このコマンドの出力に以下の警告が含まれている場合:

    Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
    

    以下のコマンドを実行します。

    systemctl daemon-reload
    
  3. 上記のコマンドが完了したら、systemctl status ISCAgent を再実行し、警告が表示されないことを確認します。

UNIX®/Linux および macOS システムでの非 root インスタンス用 ISCAgent の開始

通常、InterSystems IRIS は root としてインストールされますが、UNIX®/Linux および macOS システムでは、それとは別のユーザがインスタンスをインストールして実行することが可能です。非 root インストールの詳細は、"インストール・ガイド" の “UNIX® および Linux への InterSystems IRIS のインストール” の章にある "InterSystems IRIS 非 root インストール" を参照してください。

非 root インスタンス用の ISCAgent は、インストール・ユーザが ISCAgentUser スクリプト (IRISSYS 環境変数で定義されたディレクトリにある) を実行すると、バックグラウンドで開始されます。以下に例を示します。

nohup <IRISSYS_directory>/ISCAgentUser &

システム起動時に、ISCAgent が自動的に開始するように構成することはできないかもしれませんが、それが実現可能ならば、そちらを選択してください。ミラーに 2 つのフェイルオーバー・メンバが含まれている場合のベスト・プラクティスは、システムの起動後に、InterSystems IRIS を開始するつもりがない場合でも、できるだけ早くエージェントを起動することです。これは、"両方のフェイルオーバー・メンバの計画外停止" の説明にあるような特定の状況で、復旧の支援になります。

Microsoft Windows システムでの ISCAgent の開始

Microsoft Windows システムでは、次の方法で ISCAgent プロセスを開始します。

  1. Microsoft Windows の [コントロール・パネル][システムとセキュリティ] メニューをクリックして開きます。

  2. [システムとセキュリティ] で、[管理ツール] メニューをダブルクリックし、表示されるサブメニューから [サービス] を選択します。

  3. [サービス] で [ISCAgent] をダブルクリックして、[ISCAgent のプロパティ] ウィンドウを表示します。

  4. [全般] タブの [スタートアップの種類] ドロップダウン・リストから [自動] を選択します。

  5. [全般] タブで [開始] をクリックして、ISCAgent を開始するか、[停止] をクリックして停止します。

ISCAgent のカスタマイズ

ISCAgent の以下の属性をカスタマイズできます。

  • ポート番号

    この章で前述のとおり、既定の ISCAgent ポートは 2188 です。通常はこれで十分ですが、このポート番号は必要に応じて変更できます。

  • インタフェース

    ISCAgent は使用可能なインタフェースすべての既定 (もしくは構成された) ポートに結合します。通常はこれで十分ですが、必要に応じて、特定のアドレスに対応するインタフェースに結合するよう ISCAgent を変更することができます。

  • SYSLOG 深刻度レベル

    既定で、ISCAgent は、すべてのログ・メッセージを SYSLOG とも呼ばれる InterSystems IRIS システム・エラー・ログに送信します ("監視ガイド" の “管理ポータルを使用した InterSystems IRIS の監視” の章にある "InterSystems IRIS システム・エラー・ログ" を参照してください)。必要に応じて、最小の深刻度設定を構成できます。そうすることで、設定した深刻度より低いメッセージがシステム・エラー・ログに渡されることがなくなります。

ISCAgent をカスタマイズする手順は以下のとおりです。

  1. iscagent.conf ファイルを作成します。ファイルが既に存在する場合は、そのファイルを編集します。

    • UNIX/Linux/macOS : /etc/iscagent/iscagent.conf

    • Windows : windir\system32\iscagent.conf (windir はシステムのルート・ディレクトリ)

  2. ポートをカスタマイズするには、以下の行を追加して、<port> を目的のポート番号に置き換えます。

    application_server.port=<port>
    
  3. インタフェースをカスタマイズするには、以下の行を追加して、<ip_address> を目的のインタフェースが対応するアドレスに置き換えます。

    application_server.interface_address=<ip_address>
    

    使用可能なすべてのインタフェースに明示的に結合するには (既定)、IP アドレスとして * を指定します。

  4. SYSLOG 深刻度レベルをカスタマイズするには、以下の行を追加して、<severity> を目的の最小深刻度レベルに置き換えます。1 = 警告、2 = 重大、および 3 = 致命的です。

    logging.minimum_severity=<severity>
    

サービス品質 (QoS) タイムアウトの構成

[サービス品質タイムアウト] (QoS タイムアウト) は、フェイルオーバー・メンバとアービターの動作を管理する際に重要な役割を果たすものであり、ミリ秒単位の時間の範囲を定義します。ミラー・メンバは、この時間の範囲内で別のミラー・メンバからの応答を待機し、その範囲を超えると対応策を実行します。QoS タイムアウト自体は、最大待機時間を表します。最小待機時間は、その半分になります。QoS タイムアウトの値を大きくすると、ホストやネットワークが停止と見なされるまでの無応答時間の許容範囲が広くなります。QoS の値を小さくすると、ミラーは迅速に停止に対応できるようになります。具体的には、QoS タイムアウトは以下の状況に作用します。

  • バックアップ・フェイルオーバー・メンバが、プライマリからのデータに対して QoS タイムアウトで定義した範囲内に受信確認を行わないと、プライマリはバックアップとの接続を切断して、バックアップが停止したと見なしてアクションを取ります。

  • バックアップが、プライマリからのメッセージを QoS タイムアウトで定義した範囲内に受信できなかった場合、バックアップは接続を切断して、プライマリが停止したと見なしてアクションを取ります。

  • アービターが、フェイルオーバー・メンバからの応答を QoS タイムアウトで定義した範囲内に受信できなかった場合、アービターは、そのフェイルオーバー・メンバとの接続が失われていると見なします。

  • フェイルオーバー・メンバのホストで実行される処理により、QoS タイムアウトで定義した範囲内の期間、ホストが完全に無反応になると、不要なフェイルオーバーやアラートが発生することがあります。これは、バックアップや移行を伴う処理を実行する仮想化プラットフォームで特に問題になります。詳細は、"仮想環境でのミラーリング" を参照してください。

フェイルオーバー・メンバとアービターの動作に関して QoS タイムアウトが果たす役割についての完全な詳細は、"自動フェイルオーバーのメカニズム" を参照してください。

既定の QoS は 8 秒 (8000 ミリ秒) です。これは、一部のハードウェア構成で発生する数秒間の断続的な無応答状態を考慮に入れたものです。一般に、専用のローカル・ネットワークに接続された物理 (仮想化されていない) ホストへの配置では、停止に対するより迅速な対応が必要な場合に、この設定を短くすることができます。

[サービス品質タイムアウト] の設定は、[ミラーの作成] ページ、またはプライマリ・フェイルオーバー・メンバの [ミラーの作成] ページで調整できます。

Note:

QoS タイムアウトは、^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) の [ミラー構成] メニューにある [サービス品質タイムアウト・パラメータの調整] オプションを使用して調整することもできます。

並列デジャーナリングの構成

"ミラー同期" で説明したように、バックアップ・フェイルオーバー・メンバおよびミラーの非同期メンバのミラーリングされるデータベースは、デジャーナリングによってプライマリとの同期状態が維持されます。これは、プライマリで実行され、プライマリのジャーナル・ファイルに記録されるデータベース更新を他のメンバの対応するデータベースに適用する動作です。十分な処理能力があり、十分なメモリ・リソースを利用できる場合、1 回のデジャーナリング・オペレーションで最大 16 件のデジャーナリング・ジョブが更新を並列実行できます ("並列デジャーナリングのシステム要件" を参照してください)。この機能は、並列デジャーナリングと呼ばれ、特にデータベースの更新頻度が高いミラーのスループットを向上させます。並列デジャーナリングはジャーナル・リストア中にも使用されます。詳細は、"データ整合性ガイド" の “ジャーナリング” の章にある "^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" を参照してください。

並列デジャーナリングはミラーのフェイルオーバー・メンバでは常に有効になっているため、必要なリソースが利用可能な場合は使用されます。既定では、DR 非同期メンバでも有効になっています。レポート非同期についても有効にすることができます (つまり、すべてのメンバについて有効にできます)。また、フェイルオーバー・メンバのみに制限することもできます。そのためには、第 1 のフェイルオーバー・メンバを構成するときに [並列デジャーナリングを許可する] 設定を変更 ("ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する" を参照)、またはプライマリでミラーを編集 ("フェイルオーバー・メンバの編集または削除" を参照) します。並列デジャーナリングが有効になっている場合 (また利用可能なリソースが対応している場合)、1 回の操作で複数のデータベースをキャッチアップするときに使用されます。"ミラーリングされるデータベースの有効化とキャッチアップ" を参照してください。

レポート非同期に対して並列デジャーナリングを有効にすると、パフォーマンスの観点では有利ですが、クエリまたはレポートで予期しない結果になる可能性が高まる場合があります。これは、別個のデジャーナリング・ジョブによって更新されるデータベースまたはデータベース内のグローバルが、デジャーナリングの順序において若干異なる可能性があるためです。例えば、データベース A に 11:45:30 にプライマリで実行される更新が含まれているときに、データベース B は 11:45:28 からの更新に対してのみ準備できているような場合です。この場合、同一のトークンによって、あるグローバルは前者の時間に従って更新され、同じデータベース内の別のグローバルは後者の時間に従って更新される可能性があります。ただし、並列デジャーナリングが原因の不確実性は、デジャーナリング処理において変化するデータに対してレポートまたはクエリを実行するときに常に発生する不確実性と同様です。したがって、インターシステムズは、並列デジャーナリングが有効になっている、ミラーリングされるデータベースに対して実行されるほとんどのレポート・アプリケーションでは、その影響を無視できると考えています。データベース内の 1 つのグローバルに対するすべての更新は常に 1 つのデジャーナリング・ジョブによって適用され、これらの更新は順番に行われます。

^ZMIRROR ルーチンの使用法

ユーザ定義の ^ZMIRROR ルーチンにより、特定のミラーリング・イベント用の (フェイルオーバー・メンバがプライマリになるなど)、独自のカスタムで構成固有のロジックおよびメカニズムを実装できます。

^ZMIRROR ルーチンには、次のエントリ・ポイントが含まれています。値を省略した場合、これらすべては、適切な既定値が指定されます。

  • $$CanNodeStartToBecomePrimary^ZMIRROR() — インスタンスで以下のことと判断された場合、このプロシージャが呼び出されます。

    • 他方のフェイルオーバー・メンバが現在プライマリとして動作しておらず、手動操作なしではプライマリになれない。

    • ローカル・メンバはプライマリになることが可能で、引き継ぎのプロセスを開始しようとしている。

    CanNodeStartToBecomePrimary は、起動時またはバックアップとしての接続時のいずれかに、フェイルオーバー・メンバが自動的にプライマリになることをブロックするロジックのエントリ・ポイントを提供し、フェイルオーバーを手動制御できるようにします。これはほとんどの ^ZMIRROR ルーチンには組み込まれていません。

    CanNodeStartToBecomePrimary1 を返すと、ローカル・インスタンスがプライマリ・フェイルオーバー・メンバとして完全初期化され、プライマリになるプロセスを続行できます。つまり、ミラーリングされるデータベースすべてが読み書き可能となり、ECP セッションが回復またはロールバックされていて、以前のプライマリからのローカル・トランザクション (存在する場合) がロールバックされています。ユーザのログインは許可されておらず、スーパーサーバ接続は阻止され、かつ ECP が復旧途中にあるので、新規の処理は実行されていません。

    このエントリ・ポイントが 0 (False) を返す場合、インスタンスは再試行ループに入り、CanNodeStartToBecomePrimary の呼び出しを 30 秒ごとに、以下のことが生じるまで続けます。

    • CanNodeStartToBecomePrimary1 (True) を返し、ローカル・メンバがプライマリになるプロセスを続行する。

    • インスタンスで、他方のフェイルオーバー・メンバがプライマリになったこと (手動操作による必要があります) が検出され、この時点でローカル・メンバがバックアップになる。

  • $$CheckBecomePrimaryOK^ZMIRROR() — このプロシージャは CanNodeStartToBecomePrimary1 (True) を返した後に呼び出されます。

    CheckBecomePrimaryOK が存在し、1 を返すと、ミラーはローカル・メンバをプライマリとして動作を再開します。この時点で、任意のローカル・プロセスを開始でき、またユーザのアプリケーション環境を整えるために必要な初期化ができます。ただし、CheckBecomePrimaryOK を実行するプロセスのみが、1 を返した後に、ミラーリングされるデータベースに実際に書き込み、その時点でミラーリングされるデータベースが一般の使用のために更新されることに注意してください。

    CanNodeStartToBecomePrimary と同様に、CheckBecomePrimaryOK0 (False) を返すと、インスタンスはプライマリになるプロセスを中止して、CheckBecomePrimaryOK の呼び出しを 30 秒ごとに、以下のことが生じるまで再試行します。

    • エントリ・ポイントが 1 を返し、ミラーがローカル・メンバをプライマリとして動作を再開する。

    • インスタンスで、他方のフェイルオーバー・メンバがプライマリになったこと (手動操作による必要があります) が検出され、この時点でローカル・メンバがバックアップになる。

    通常、CheckBecomePrimaryOK は正常に実行されます。ノードがプライマリ・メンバにならない “事例がよく起こる” 場合は、CheckBecomePrimaryOK ではなく、CanNodeStartToBecomePrimary を使用して処理する必要があります。

    プライマリの既存の ^%ZSTART ルーチンから ^ZMIRROR にコードを移動することで、ミラーを初期化しない限りコードが実行されないようにする場合は、CheckBecomePrimaryOK が最適な位置となります。ただし、job コマンドを使用してその他のジョブを開始する場合、そのジョブは $SYSTEM.Mirror.IsPrimary() が true を返すまで待機します。これは CheckBecomePrimaryOK が 1 を返した後に行われます。または、代わりに $$NotifyBecomePrimary^ZMIRROR() でジョブを開始できます。

    Note:

    CheckBecomePrimaryOK が False を返す場合、ECP セッションはリセットされます。ノードのプライマリ化が成功すると、ECP クライアントは再接続され、ECP トランザクションが (保持ではなく) ロールバックされます。クライアント・ジョブは、TRollback コマンドが明示的に実行されるまで、<NETWORK> エラーを受信します ("スケーラビリティ・ガイド" の “InterSystems 分散キャッシュによるユーザ数に応じたシステムの水平方向の拡張” の章にある "ECP Rollback Only の保証" のセクションを参照)。

  • $$NotifyBecomePrimary^ZMIRROR() — このプロシージャは、プライマリ・フェイルオーバー・メンバになるプロセスの最後に情報提供を目的として呼び出されます (つまり、ユーザが許可された後、かつ ECP セッションが (存在する場合) アクティブになった後)。このエントリ・ポイントは値を返しません。コードを組み込むことにより、必要に応じた通知の生成やアプリケーション・ログインの有効化ができます。

  • $$NotifyBecomePrimaryFailed^ZMIRROR() — このプロシージャは、以下の場合に情報提供を目的として呼び出されます。

    • フェイルオーバー・メンバが起動したが、プライマリまたはバックアップ・メンバになれなかった。

    • バックアップがプライマリの失敗を検出し、バックアップがプライマリになろうとしたが、なれなかった。

    このエントリ・ポイントは、各問題の発生に対して 1 回だけ呼び出されます。メンバがプライマリになるか、プライマリが検出されるまで再度呼び出されることはありません。

FeedbackOpens in a new tab