分散キャッシュによるユーザ数に応じた水平方向の拡張

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 が実質的に独自の更新バージョンに置き換えられます。

構成マージを使用すると、データ・サーバとアプリケーション・サーバに対して別個のマージ・ファイルを呼び出して順番に導入することによって、分散キャッシュ・クラスタを導入できます。

前述のように、IKO には構成マージ機能が組み込まれています。

一般的な構成マージの使用法および具体的な分散キャッシュ・クラスタの導入方法の詳細は、"構成マージを使用した InterSystems IRIS の自動構成Opens in a new tab" を参照してください。

データ・サーバの準備

InterSystems IRIS インスタンスは、アプリケーション・サーバ上で構成されるまで、分散キャッシュ・クラスタ内のデータ・サーバとして実際に動作させることはできません。ただし、インスタンスをデータ・サーバとして準備する手順には、1 つの必須アクションと 2 つのオプション・アクションが含まれています。

インスタンスをデータ・サーバとして準備するには、[ECP設定] ページに移動し (管理ポータルのホーム・ページで [システム管理]→[構成]→[接続性]→[ECP設定] の順に選択)、以下を実行します。

• 右側の [このシステムをECPデータサーバとする] ボックスで、ECP サービスの [有効] リンクをクリックすることにより、このサービスを有効にします。これにより %Service_ECP の [サービス編集] ダイアログが開きます。[サービス有効] を選択し、[保存] をクリックしてサービスを有効にします。(サービスが既に有効になっている場合 (ボックス内に [無効] リンクが存在することによって示されます)、次の手順に進みます)。

  Note:

  InterSystems サービスの詳細な説明は、"サービス" を参照してください。

• 複数のアプリケーション・サーバを同時にデータ・サーバに接続できるようにする場合は、[このシステムを ECP データサーバとする] ボックスで、[アプリケーションサーバの最大数] 設定を、構成するアプリケーション・サーバの数に変更して、[保存] をクリックし、その後、インスタンスを再起動します(アプリケーション・サーバの同時接続の数が、この設定用に入力した数よりも大きくなると、データ・サーバ・インスタンスが自動的に再起動します)。

  Note:

  アプリケーション・サーバの最大数は、UNIX® および Linux プラットフォームの構成マージ・ファイルOpens in a new tabに含まれる構成パラメータ・ファイル (CPF) の MaxServerConnOpens in a new tab 設定を使用して設定することもできます。

• [トラブル状態の時間間隔] 設定は、アプリケーション・サーバとデータ・サーバ間で中断された接続の回復を管理するために使用される 3 つのタイムアウトのうちのいずれかを決定します。長期的なクラスタの動作に関するデータを取得するまでは、既定の 60 のままとします。ECP リカバリ・タイムアウトの詳細は、"ECP リカバリ・プロトコル" を参照してください。

• TLS の使用を有効にしてアプリケーション・サーバからの接続をセキュリティ保護するには、[Set up SSL/TLS ‘%ECPServer’] リンクをクリックしてデータ・サーバの ECP TLS 構成を作成し、[ECP SSL/TLS サポート] 設定を次のように指定します。

  • [必須] — アプリケーション・サーバは、このデータ・サーバに対して [SSL/TLS 使用] が選択されている場合にのみ接続できます。

  • [有効] — アプリケーション・サーバは、このデータ・サーバに対して [SSL/TLS 使用] が選択されているかどうかに関係なく接続できます。

  • [無効] — アプリケーション・サーバは、このデータ・サーバに対して [SSL/TLS 使用] が選択されている場合 (既定)、接続できません。

  "分散キャッシュ・クラスタのセキュリティ" で説明しているとおり、TLS は ECP 通信をセキュリティ保護するためのいくつかのオプションのうちの 1 つです。ただし、TLS を有効にすると、パフォーマンスに重大な悪影響を及ぼす場合があります。クラスタのアプリケーション・サーバとデータ・サーバが同じデータ・センターに配置されることにより、最適なパフォーマンスが提供されている場合、データ・センター単独での物理的なセキュリティにより、クラスタに十分なセキュリティが提供される可能性があります。

  データ・サーバでのセキュリティで保護されたアプリケーション・サーバ接続の承認を含む、分散キャッシュ・クラスタでの TLS の有効化および使用に関する重要な情報は、"アプリケーション・サーバのデータ・サーバへの接続の TLS によるセキュリティ保護" を参照してください。

これで、データ・サーバは、有効なアプリケーション・サーバから接続できるようになります。

アプリケーション・サーバの構成

InterSystems IRIS インスタンスを分散キャッシュ・クラスタ内のアプリケーション・サーバとして構成するには、次の 2 つの手順が必要です。

• アプリケーション・サーバ・インスタンス上のデータ・サーバとして、データ・サーバ・インスタンスを追加します。

• アプリケーション・サーバ上のリモート・データベースとして、データ・サーバ上に目的のデータベースを追加します。

アプリケーション・サーバにデータ・サーバを追加するには、次の手順を実行します。

1. "データ・サーバの準備" のデータ・サーバに関する説明に従い、[ECP設定] ページに移動して、[このシステムをECPアプリケーションサーバとする] 側の設定を既定のままとします。

2. 追加しているデータ・サーバの [ECP SSL/TLS サポート] 設定が [有効] または [必須] の場合は、[Set up SSL/TLS ‘%ECPClient’] リンクをクリックして、アプリケーション・サーバの ECP TLS 構成を作成します(これは、後で [ECPデータサーバ] ダイアログでも実行できます)。詳細は、次の手順の [SSL/TLS 使用] 設定を参照してください。

3. [データサーバ] をクリックして [ECP データサーバ] ページを表示し、[サーバ追加] をクリックします。[ECPデータサーバ] ダイアログに、データ・サーバについて次の情報を入力します。

   • サーバ名 — データ・サーバを識別する説明的な名前(この名前は 64 文字に制限されます)。

   • ホストDNS名またはIPアドレス — データ・サーバのホストまたはその IP アドレスの DNS 名を指定します (ドットで区切った十進数形式。IPv6 を有効にしている場合は、コロン区切りの形式)。DNS 名で指定した場合、アプリケーション・サーバがそのデータ・サーバ・ホストに接続するたびに、実際の IP アドレスに解決されます。詳細は、"IPv6 のサポート" を参照してください。

     Important:

     ミラー・プライマリをデータ・サーバとして追加する場合 ([ミラー接続] 設定を参照)、ミラーの仮想 IP アドレス (VIP) を入力するのではなく、現在のプライマリ・フェイルオーバー・メンバの DNS 名または IP アドレスを入力します。

   • [IP ポート] — このポート番号の既定は 1972 (既定の InterSystems IRIS スーパーサーバ (IP) ポート) です。必要に応じてデータ・サーバの InterSystems IRIS インスタンスのスーパーサーバ・ポートに変更します。

   • [ミラー接続] — データ・サーバがミラー内のプライマリ・フェイルオーバー・メンバである場合は、このチェック・ボックスにチェックを付けます (データ・サーバとしてのミラー・プライマリの構成に関する重要な情報は、"ミラーへのアプリケーション・サーバ接続の構成" を参照してください)。

   • [バッチモード] — このデータ・サーバのサーバ・プロセスをバッチ・モードで実行する必要がある場合はこのチェック・ボックスにチェックを付けます。バッチ・モードでは、データ・サーバは常にブロックをロードして、それらをバッチ・レベルでキャッシュします。ただし、ブロックがアプリケーション・サーバに戻されると、そのブロックは定期的にキャッシュされます。

   • [SSL/TLS 使用] — このチェック・ボックスは、以下のように使用します。

     • 追加しているデータ・サーバの [ECP SSL/TLS サポート] 設定が [無効] の場合、このチェック・ボックスにチェックを付けても付けなくても問題ありません。データ・サーバへの接続をセキュリティ保護するために TLS は使用されません。

     • 追加しているデータ・サーバの [ECP SSL/TLS サポート] 設定が [有効] のとき、このデータ・サーバへの接続をセキュリティ保護するのに TLS を使用する場合はこのチェック・ボックスにチェックを付け、TLS を使用しない場合はチェックを外します。

     • 追加しているデータ・サーバの [ECP SSL/TLS サポート] 設定が [必須] の場合は、このチェック・ボックスにチェックを付ける必要があります。

     追加しているデータ・サーバの [ECP SSL/TLS サポート] 設定が [有効] または [必須] で、アプリケーション・サーバに対してまだ TLS 構成を作成していない場合は、[Set up SSL/TLS ‘%ECPClient’] リンクをクリックしてこれを行います。データ・サーバでのセキュリティで保護されたアプリケーション・サーバ接続の承認を含む、分散キャッシュ・クラスタでの TLS の使用の詳細は、"アプリケーション・サーバのデータ・サーバへの接続の TLS によるセキュリティ保護" を参照してください。

4. [保存] をクリックします。データ・サーバはデータ・サーバ・リストに表示されます。利用可能なリンクを使用して、データ・サーバ定義を削除または編集したり、その状態を変更したりすることができます ("分散アプリケーションの監視" を参照)。データ・サーバ上の [ECP設定] ページに進み、[アプリケーションサーバ] ボタンをクリックすることで、データ・サーバへのすべてのアプリケーション・サーバ接続のリストを表示することもできます。

アプリケーション・サーバ上のリモート・データベースとしてデータ・サーバ上にそれぞれ必要なデータベースを追加するには、アプリケーション・サーバ上にネームスペースを作成し、次のようにそのデータベースにマッピングする必要があります。

1. 管理ポータルのホーム・ページで [システム管理]、[構成]、[システム構成]、[ネームスペース] の順に選択して、[ネームスペース] ページに移動します。[新規ネームスペース作成] をクリックして、[新規ネームスペース] ページを表示します。

2. 新規ネームスペースの名前を入力します。通常は、マッピングされるリモート・データベースの名前が反映されます。

3. [このネームスペースにおけるグローバルの既定のデータベース] で、[リモートデータベース]、[新規データベース作成] の順に選択して、[リモートデータベースを作成] ダイアログを開きます。このダイアログで、

   • [リモートサーバ] ドロップダウンからデータ・サーバを選択します。

   • [リモートディレクトリ] を [リストからディレクトリを選択] に設定し、データ・サーバ上のすべてのデータベース・ディレクトリを一覧表示する [ディレクトリ] ドロップダウンを使用して、ネームスペースにマッピングするデータ・サーバ・データベースを選択します。

   • リモート・データベースのローカル名を入力します。これは、通常、データ・サーバ上のデータベースの名前、前の手順で指定されたデータ・サーバのローカル名、またはその両方を反映します。

   • [完了] をクリックしてリモート・データベースを追加し、新しいネームスペースにマッピングします。

4. [このネームスペースでルーチンのデフォルト・データベースは] で、[リモートデータベース] を選択し、次に、ドロップダウンから作成したデータベースを選択します。

5. ネームスペースは相互運用対応である必要はありません。時間を節約するために、[相互運用プロダクション用にネームスペースを有効化] チェック・ボックスのチェックを外すことができます。

6. [保存] を選択します。[ネームスペース] リストに新規ネームスペースが一覧表示されます。

アプリケーション・サーバ上のリモート・データベースとしてデータ・サーバ・データベースを追加すると、アプリケーションは、アプリケーション・サーバにマッピングされているネーム・スペースを介してそのデータベースをクエリすることができます。

アプリケーション・サーバのデータ・サーバへの接続の TLS によるセキュリティ保護

TLS がデータ・サーバで有効な場合、これを使用してアプリケーション・サーバからそのデータ・サーバへの接続をセキュリティ保護できます。この保護には、X.509 証明書ベースの暗号化が含まれます。TLS およびインターシステムズ製品での TLS の使用の詳細は、インターシステムズの "TLS ガイド" を参照してください。

データ・サーバの構成または編集時、あるいはそれ以降であればいつでも ("データ・サーバの準備" を参照)、[ECP SSL/TLS サポート] 設定として、既定の [無効] ではなく、[有効] または [必須] を選択できます。これらの設定は、データ・サーバをアプリケーション・サーバに追加する ("アプリケーション・サーバの構成" を参照) か、既存のデータ・サーバを編集する際に、TLS によりデータ・サーバへの接続をセキュリティ保護する、[SSL/TLS 使用] チェック・ボックスの使用オプションを制御します。これら設定は、以下のように影響します。

• 無効 — アプリケーション・サーバのこのデータ・サーバへの接続に対する TLS の使用を無効にします。[SSL/TLS 使用] が選択されているアプリケーション・サーバであっても、同様です。

• 有効 — データ・サーバでアプリケーション・サーバの接続に対する TLS の使用が有効になります。[SSL/TLS 使用] が選択されているアプリケーション・サーバからの接続に対して TLS が使用され、[SSL/TLS 使用] が選択されていないアプリケーション・サーバからの接続に対しては、SSL/TLS は使用されません。

• 必須 — データ・サーバではアプリケーション・サーバの接続に TLS を使用する必要があります。アプリケーション・サーバは、データ・サーバに対して [SSL/TLS 使用] が選択されている場合のみ、データ・サーバに接続できます。この場合、すべての接続に対して TLS が使用されます。

TLS を使用してアプリケーション・サーバからデータ・サーバへの接続を確立するには、次の 3 つの要件があります。

• データ・サーバでは、スーパーサーバ・クライアントに対して TLS 接続を有効にする必要があります。そのためには、データ・サーバで、システムの既定のスーパーサーバの構成ページ ([システム管理]→[セキュリティ]→[スーパーサーバ]) に移動して、[SSL/TLS support level] 設定に [有効] を選択します。詳細は、"スーパーサーバの管理" を参照してください。

• 両方のインスタンスに ECP TLS 構成が必要です。

  このため、[ECP設定] ページ ([システム管理]→[構成]→[接続性]→[ECP設定]) の両側の [このシステムをECPアプリケーションサーバとする] と [このシステムをECPデータサーバとする] には、[SSL/TLS の構成] リンクが含まれており、これを使用してインスタンスに適した ECP TLS 構成を作成できます。このためには、以下の手順を実行します。

  1. [ECP設定] ページのアプリケーション・サーバ側の [Set up SSL/TLS ‘%ECPClient’] リンク、またはデータ・サーバ側の [Set up SSL/TLS ‘%ECPServer’] リンクをクリックします。

  2. [ECP用 SSL/TLS 構成を編集] ダイアログ内のフォームの各フィールドに入力します。これらは [新規 SSL/TLS 構成] ページに似ています ("TLS 構成の作成または編集" を参照)。ただし、[構成名]、[説明]、[有効] のいずれのフィールドもありません。また、秘密鍵パスワードに関しては、このページでパスワードの入力または置き換え ([新規パスワード入力])、パスワードを使用しないことの指定 ([パスワードクリア])、あるいは既存のパスワードをそのまま使用すること ([そのままにする]) の指定を行えます。

     このページのフィールドは以下のとおりです。

     • [信頼された証明書機関 X.509 証明書を含むファイル]

       この構成が信頼する 1 つまたは複数の認証機関 (CA) の X.509 証明書 (PEM 形式) が含まれているファイルのパスと名前。絶対パス、または install-dir/mgr/ ディレクトリを基準とした相対パスで指定できます。X.509 証明書とそれらの生成および使用の詳細は、インターシステムズの "TLS ガイド" を参照してください。

       Note:

       このファイルには、他のミラー・メンバに属する X.509 証明書の検証に使用できる証明書が含まれている必要があります。ファイルに複数の証明書が含まれている場合は、それらの証明書を正しい順序で (現在のインスタンスの証明書が最初になるように) 並べる必要があります。詳細は、"必須証明書チェーンの確立" を参照してください。

     • [この構成のX.509 証明書を含むファイル]

       構成独自の X.509 証明書 (PEM 形式) の場所。これは、絶対パスと相対パスのいずれかとして指定できます。

       Note:

       証明書の識別名 (DN) は証明書のサブジェクト・フィールドに表示する必要があります。

     • [関連づけられた秘密鍵を含むファイル:]

       構成の秘密鍵ファイルを格納する場所。絶対パスまたは相対パスで指定します。

     • [秘密鍵タイプ]

       秘密鍵の生成に使用するアルゴリズム。有効なオプションは [DSA] と [RSA] です。

     • [パスワード]

       ECP TLS 構成を作成している場合、[新規パスワード入力] を選択すると、証明書に関連付けられた秘密鍵のパスワードの入力および確認のための再入力を実行できます。

     • [プロトコル]

       構成で有効と見なされる通信プロトコル TLSv1.1 および TLSv1.2 は、既定で有効となります。

     • [有効な暗号スイート]

       クライアントとサーバ間の通信の保護に使用される暗号スイート・セット。通常、これは既定の設定のままにできます。

     フォームの入力が完了したら [保存] をクリックします。

• アプリケーション・サーバは、TLS を使用して接続する前に、データ・サーバで承認する必要があります。

  アプリケーション・サーバが最初に TLS を使用してデータ・サーバに接続を試みると、その SSL (TLS) コンピュータ名 (その X.509 証明書の所有者識別名) とそのホストの IP アドレスが、データ・サーバの [アプリケーションサーバ] ページ ([システム管理]→[構成]→[接続性]→[ECP設定]→[アプリケーションサーバ]) の、承認または拒否が決まっていない保留中の ECP アプリケーション・サーバのリストに表示されます。[承認] および [拒否] リンクを使用して、リスト内の要求に対応します(保留中の要求がない場合、リストは表示されません)。

  TLS を使用して接続することが承認されているアプリケーション・サーバが 1 つ以上存在する場合、その SSL (TLS) コンピュータ名が、[アプリケーションサーバ] ページの、ECP アプリケーション・サーバとして承認された SSL コンピュータ名のリストに表示されます。承認をキャンセルするには [削除] リンクを使用します(承認されたアプリケーション・サーバがない場合、リストは表示されません)。

データ・サーバへのアクセスの制限

既定では、(前のセクションで説明したように) データ・サーバ・インスタンスがデータ・サーバとして構成されている InterSystems IRIS インスタンスは、データ・サーバに接続できます。ただし、許可される着信接続元となるホストを指定することによって、データ・サーバに対するアプリケーション・サーバとして機能できるインスタンスを制限できます。これを行う場合、明示的にリストされていないホストは、データ・サーバに接続できません。これを行うには、データ・サーバ上で次の手順を実行します。

1. [サービス] ページ (ポータルのホーム・ページから、[セキュリティ]、[サービス] の順に選択) で、[%Service_ECP] をクリックします。[サービス編集] ダイアログが表示されます。

2. 既定では、[許可済みの接続元] ボックスは空です。つまり、ECP サービスが有効な場合、すべてのアプリケーション・サーバがこのインスタンスに接続できます。[追加] をクリックして、単一の IP アドレス (192.9.202.55 など) または完全修飾ドメイン名 (mycomputer.myorg.com など)、あるいは IP アドレスの範囲 (例えば、8.61.202–210.* や 18.68.*.*) を入力します。リストに 1 つ以上のエントリがあるときに、[サービス編集] ダイアログで [保存] をクリックすると、これらのエントリで指定されたホストのみが接続できます。

リストには説明に従っていつでもアクセスすることができます。リストからホストを削除するには [削除] を使用し、ホストに関連付けられたロールを指定するには [編集] リンクを使用します ("ロールと権限によるアクセスの制御" を参照)。

ロールと権限によるデータベースへのアクセスの制御

インターシステムズが使用するセキュリティ・モデルでは、データベースを含むアセットがリソースに割り当てられ、リソースには読み取りや書き込みなどの許可が割り当てられます。リソースと許可の組み合わせを権限と呼びます。権限は、ユーザが所属できるロールに割り当てられます。このように、リソースへのユーザ・アクセスを制御するためにロールが使用されます。このモデルの詳細は、"承認 ： ユーザ・アクセスの制御" を参照してください。

データ・サーバにあるデータベースへのアクセス許可を取得するには、アプリケーション・サーバ上のプロセスを開始するユーザが保持するロールと、データ・サーバ上の ECP 接続に対して設定されたロールの両方に、そのデータベースを表す同じリソースに対する許可が指定されている必要があります。例えば、あるユーザが、特定のデータベース・リソースに対する読み取り許可の権限を付与するアプリケーション・サーバ上のロールに所属し、データ・サーバ上の ECP 接続に設定されているロールにもこの権限が含まれている場合、そのユーザは、アプリケーション・サーバ上のデータベースからデータを読み取ることができます。

アプリケーション・サーバの代わりにデータ・サーバを実行する場合、既定では、InterSystems IRIS は、データ・サーバ上の ECP 接続に %All 特権を与えます。つまり、アプリケーション・サーバ上のユーザが持つ権限はすべて、データ・サーバ上で照合され、アクセスはアプリケーション・サーバ上でのみ制御されます。例えば、%DB_USER リソースに対する特権のみを持っており、%DB_IRISLIB リソースに対する特権を持っていない、アプリケーション・サーバのユーザは、データ・サーバの USER データベースにあるデータにアクセスできますが、データ・サーバの IRISLIB データベースにアクセスしようとすると、<PROTECT> エラーとなります。アプリケーション・サーバの別のユーザが、%DB_IRISLIB リソースに対する特権を持っている場合、そのユーザは IRISLIB データベースを利用できます。

ただし、アプリケーション・サーバのホストに基づいて、データ・サーバ上の ECP 接続で使用できるロールを制限することもできます。例えば、データ・サーバで、特定のアプリケーション・サーバと対話するときに使用できるロールを %DB_USER のみとすることを指定できます。この場合、アプリケーション・サーバで %DB_USER ロールが与えられているユーザは、データ・サーバの USER データベースにアクセスできますが、アプリケーション・サーバ上のユーザは、付与されたロールに関係なく、データ・サーバ上の他のデータベースにアクセスすることはできません。

以下は、この動作に対する例外です。

• InterSystems IRIS は必ずデータ・サーバに %DB_IRISSYS ロールを与えます。これは、このデータ・サーバが稼動するには、IRISSYS データベースへの Read アクセスが必要なためです。つまり、アプリケーション・サーバ上で %DB_IRISSYS ロールを持つユーザは、データ・サーバの IRISSYS データベースにアクセスできます。

  このアプリケーション・サーバのユーザが、データ・サーバの IRISSYS データベースにアクセスできないようにする方法には次の 2 とおりがあります。

  • %DB_IRISSYS リソースに対する特権をユーザに与えない。

  • データ・サーバで、IRISSYS データベースのリソース名を、%DB_IRISSYS 以外の名前に変更する。このとき、アプリケーション・サーバのユーザが変更後の名前を持つリソースに対する特権を持っていないことを確認してください。

• データ・サーバにパブリック・リソースが存在する場合、アプリケーション・サーバのロールや、ECP 接続用に構成されたロールに関係なく、ECP アプリケーション・サーバ上のすべてのユーザはこのパブリック・リソースを使用できます。

データ・サーバ上の特定のアプリケーション・サーバからの ECP 接続に使用可能なロールを指定するには、以下の操作を行います。

1. [サービス] ページ (ポータルのホーム・ページから、[セキュリティ]、[サービス] の順に選択) に移動して、[%Service_ECP] をクリックし、[サービス編集] ダイアログを表示します。

2. 制限するアプリケーション・サーバ・ホストの [編集] リンクをクリックして、[ロールの選択] 領域を表示します。

3. ホストのロールを指定するには、[使用可能] の下に一覧表示されるロールから必要なロールを選択し、右矢印をクリックして、選択したロールを [選択済み] リストに追加します。

4. [選択済み] リストからロールを削除するには、削除するロールを選択し、左矢印をクリックします。

5. [選択済み] リストにすべてのロールを追加するには、二重右矢印をクリックします。また、[選択済み] リストからロールをすべて削除するには、二重左矢印をクリックします。

6. [保存] をクリックして、IP アドレスとロールを関連付けます。

既定では、リストされたホストは %All ロールを保持していますが、その他のロールを 1 つまたは複数指定すると、この接続は指定したそれらのロールのみを持つことになります。したがって、%Operator ロールを持つホストまたは IP 範囲からの接続が持つ特権は、そのロールに関連付けられているもののみです。一方、ロールが関連付けられていない (つまり、%All ロール) ホストからの接続はすべての特権を持つことになります。

アプリケーション・サーバのホストで使用可能なロールに対する変更、およびデータ・サーバのリソース上のパブリック許可に対する変更を有効にするには、InterSystems IRIS の再起動が必要です。

セキュリティ関連のエラー報告

ECP で発生するセキュリティ関連のエラー報告の動作は、アプリケーション・サーバとデータ・サーバのどちらでチェックが失敗したか、またどのような操作が行われたかによって次のように異なります。

• アプリケーション・サーバでチェックに失敗した場合は、直ちに <PROTECT> エラーとなります。

• データ・サーバでの同期操作の場合は、直ちに <PROTECT> エラーとなります。

• データ・サーバでの非同期操作の場合は、<NETWORK DATA UPDATE FAILED> エラーが遅延時間の後で表示されることがあります。このような操作には、例えば Set 操作があります。

データ・サーバ接続

[ECPデータサーバ] ページに、各データ・サーバ接続について次の情報が表示されます。

アプリケーション・サーバ接続

[ECP設定]ページ ([システム管理]→[構成]→[接続性]→[ECP設定]) で [ECP アプリケーションサーバ] をクリックして、このデータ・サーバ上のアプリケーション・サーバ接続のリストを含む [ECP アプリケーションサーバ] ページを表示します。

アプリケーション・サーバの接続状態

以下のエントリは、アプリケーション・サーバ側のそれぞれの接続状態を示します。提示される数値によって、ログ・メッセージに示された接続状態を判断できます。例えば、以下のメッセージは、アプリケーション・サーバの障害状態 ： jojo96HABER を表します。

01/28/24-00:00:11:859 (6552) 2 [SYSTEM MONITOR] ECPClientState Alert: ECP reports Clients state 6

• 初期化されていない (0)

• 未接続 (1)

• 接続中 (2)

• 接続失敗 (3)

• 無効 (4)

• 正常 (5)

• 障害 (6)

• リカバリ中 (7)

データ・サーバの接続状態

以下のセクションでは、データ・サーバ側の各接続状態について説明します。

• 解放

• 正常

• 障害

• リカバリ

複数の ECP チャネルを使用しない

帯域幅を増やすためにアプリケーション・サーバとデータ・サーバとの間に複数の重複した ECP チャネルを確立しないでください。1 つの論理トランザクションに対するロックや更新がデータ・サーバ上で非同期になり、データが不整合になるリスクがあります。

ECP 制御構造用のデータ・サーバ・データベース・キャッシュの増大

ECP 経由で提供されるブロックをバッファリングする処理に加え、データ・サーバでは、さまざまな ECP 制御構造を格納するのにグローバル・バッファを使用します。この構造に必要なメモリ量を決定する要素はいくつかありますが、最も重要なものは、クライアントのキャッシュの集約サイズの関数です。要求サイズを概算するために、必要に応じてデータ・サーバのデータベース・キャッシュを調整できます。以下のガイドラインを使用してください。

例えば、既定の 8 KB のブロック・サイズに加えて 16 KB のブロック・サイズが有効になっていて、6 つのアプリケーション・サーバがあり、それぞれに 2 GB の 8 KB データベース・キャッシュおよび 4 GB の 16 KB データベース・キャッシュがある場合、データ・サーバの 8 KB データベース・キャッシュを調整して制御構造用に 52 MB (50MB + [12 GB * .01]) を使用できるようにし、16 KB キャッシュを調整して制御構造用に 2 MB (24 GB * .005) を使用できるようにする必要があります (どちらの場合も小数点以下は切り上げます)。

データベース・キャッシュの割り当てに関する詳細は、"メモリと開始設定" を参照してください。

負荷分散のユーザ要求の影響の評価

ラウンドロビンまたは負荷分散方式でユーザをアプリケーション・サーバに接続すると、アプリケーション・サーバ上でキャッシュから得られる利点が減る可能性があります。ユーザが機能グループに属しており、機能グループで同一のデータを読み取る必要がある場合は、特にこれに該当します。これらのユーザは、複数のアプリケーション・サーバに分散しているため、各アプリケーション・サーバが、データ・サーバに同一のデータを要求する可能性があり、それによって、同じデータに対して複数のキャッシュを使用して分散キャッシュの効率を低下させるだけでなく、ブロックの無効化が増加する可能性もあります。ブロックは、1 つのアプリケーション・サーバで変更されると、他のアプリケーション・サーバでも更新されるためです。これはいくらか主観的ですが、アプリケーションの特性に詳しい人がこの可能性について検討する必要があります。ロード・バランサを構成する場合は、"負荷分散、フェイルオーバー、ミラー構成Opens in a new tab" を参照して、複数のアプリケーション・サーバにわたってアプリケーション接続を分散する Web サーバ層の負荷分散に関する重要な説明を確認してください。

トランザクションを単一のデータ・サーバに制限する

単一トランザクション内の更新を、単一のリモート・データ・サーバまたはローカル・サーバに制限します。トランザクションに複数のサーバ (ローカル・サーバを含む) に対する更新が含まれており、TCommit が正常に完了できないと、トランザクションに含まれるサーバによっては、更新をコミットしたものと、ロールバックしたものがある場合があります。詳細は、"コミットの保証" を参照してください。

アプリケーション・サーバでの一時グローバルの配置

一時 (スクラッチ) グローバルは、グローバルに共有する必要があるデータを含まない場合、アプリケーション・サーバのローカルに配置する必要があります。多くの場合、一時グローバルは、とてもアクティブで、書き込みが集中します。一時グローバルがデータ・サーバ上に配置されていると、これによって ECP 接続を共有する他のアプリケーション・サーバに不利となります。

未定義のグローバルに対する繰り返し参照の回避

未定義のグローバル (例えば、^x が未定義の $Data(^x(1)) など) が繰り返し参照される場合、グローバルがデータ・サーバで定義されているかどうかをテストするネットワーク処理が常に起こります。

それとは対照的に、定義されたグローバル内の未定義のノード (例えば、^x の他のノードが定義済みの $Data(^x(1)) など) が繰り返し参照される場合、グローバル (^x) がアプリケーション・サーバ・キャッシュに格納されると、ネットワーク処理は要求されません。

この動作は、ネットワークに接続されていないアプリケーションの場合と大きく異なります。ローカル・データでは、未定義のグローバルに対する参照の繰り返しは、最適化され、不要な作業は排除されます。アプリケーションをネットワーク環境に移植する設計者の場合、グローバルの使用が定義されていたり、定義されていなかったりするため、確認が必要になる場合があります。通常は、グローバルの他の特定のノードが常に定義されていることを確認するだけで十分です。

ストリーム・フィールドの使用の回避

ストリーム・フィールドOpens in a new tabがクエリにあると読み込みロックが発生し、データ・サーバへの接続が必要になります。このことから、このようなクエリではデータベース・キャッシュの利点が得られず、2 回目以降の実行でもパフォーマンスが向上しません。

アプリケーション・カウンタでの $Increment 関数の使用

オンライン・トランザクション処理システムの共通の動作は、レコード番号などに使用する一意の値を生成することです。これは、一般的なリレーショナル・アプリケーションで、“次に使用可能な” カウンタ値を含むテーブルを定義して行います。アプリケーションに新規の識別子が必要な場合、カウンタを含む列をロックし、カウンタ値をインクリメントし、ロックを解放します。これは、シングル・サーバ・システムであっても並行処理障害を引き起こします。つまり、アプリケーション・プロセスは、共通カウンタ上のロックが解放されるのを、より長時間待機するようになります。ネットワーク環境では、これはある時点でさらに障害となります。

InterSystems IRIS は、アプリケーション・レベルのロックを一切必要とせずに、(グローバルに格納される) カウンタ値を自動的にインクリメントする $Increment 関数を提供することでこれに対処します。$Increment の並行処理は、InterSystems IRIS データベース・エンジンと ECP の両方に組み込まれており、シングル・サーバや分散アプリケーションで使用した場合に非常に高い効率性が実現されます。

InterSystems IRIS オブジェクト (あるいは SQL) から提供される既定構造を使用して構築されたアプリケーションは、$Increment を自動的に使用して、オブジェクト識別子の値を割り当てます。$Increment は、ECP 上で実行された場合のジャーナル同期に関わる同期処理です。このため、ECP 上での $Increment は比較的低速の処理となり、とりわけ他の比較対象が (アプリケーション・サーバ・データベース・キャッシュまたはデータ・サーバ・データベース・キャッシュのいずれかに) キャッシュ済みのデータを持っているかどうかにより違いが出ます。この影響は、フェイルオーバー・メンバ間のネットワーク遅延により、ミラーリング環境においてさらに大きくなります。このため、アプリケーションを再設計して $Increment を $Sequence 関数に置き換えると便利な場合があります。こうすると、新しい値のバッチは各アプリケーション・サーバ上で各プロセスに自動的に割り当てられ、データ・サーバは新規に値のバッチが必要になった場合にのみ処理に参加します(ただし、連続したアプリケーション・カウンタ値が必要な場合、この手法は使用できません。)$Sequence は $Increment と組み合わせて使用することもできます。

<NETWORK> エラー

<NETWORK> エラーは、通常の ECP リカバリ・メカニズムで処理できなかったエラーを示します。

アプリケーション内で <NETWORK> エラーを受け取った場合は常に、プロセスの停止や未実行処理のロールバックが可能です。<NETWORK> エラーの中には、本質的に致命的なエラー状態になるものもあります。すぐに解決する一時的な状態を示すものもあります。しかし、理想的なプログラミング手法とは、<NETWORK> エラーの発生時、未実行処理をロールバックし、現在のトランザクションを最初から開始することです。

$Data や $Order など get 型要求の <NETWORK> エラーは、即座にトランザクションをロールバックするのではなく、手動で再試行できます。ECP は、データを損失する <NETWORK> エラーの発生を避けようとしますが、読み取り専用の要求に多くのエラーを生じます。

Rollback Only 条件

アプリケーション側の rollback-only 条件は、アプリケーション・サーバによって開始されたトランザクション中にデータ・サーバがネットワーク障害を検出したときに発生し、トランザクションがロールバックされるまですべてのネットワーク要求でエラーが発生した状態になります。

更新順の保証

Process A が 2 つのデータ要素を続けて更新したとします。最初にグローバル ^x を、次にグローバル ^y を更新します。このとき、^x と ^y は、同じデータ・サーバにあります。

Process B は ^y への変更を確認できる場合、^x への変更も確認できます。これは、Process A と Process B が同じアプリケーション・サーバ上にあるかどうかにかかわらず、2 つのデータ・アイテムが同じデータ・サーバにあり、データ・サーバが起動している限り保証されます。

Process B が Process A によって変更されたデータを表示できるからといって、Process A からの Set オペレーションの後に、Process B からの Set オペレーションがリストアされることが保証されるわけではありません。クラスタのフェイルオーバー時またはクラスタのリカバリ時に 2 つの異なるプロセスからの Set や Kill オペレーションが競合する場合、適切な順序を保証できるのは、Lock または $Increment オペレーションのみです。

クラスタのデジャーナル時とクラスタのフェイルオーバー時に異なるプロセスからの Set と Kill オペレーションが競合している場合に適用される順序については、"クラスタのフェイルオーバー時やリストア時の緩やかな順序" の制限を参照してください。

ECP ロックの保証

Process B (DataServer S 上) が、Process A によってロックされたことがあるグローバル ^x のロックを取得したとします。

Process B は、(^x へのロックを保持している間) Process A によって行われたすべての更新を DataServer S で表示できますまた、Process C が、(^x へのロックを保持している間) Process B によって行われた更新をDataServer S で表示した場合、Process C は、(^x へのロックを保持している間) Process A によって行われた更新も DataServer S で表示することが保証されます。

このシリアル化機能は、Process A、Process B、Process C が同じアプリケーション・サーバ、または DataServer S 自体に属するかどうかにかかわらず、DataServer S がその間常に起動している限り保証されます。

クラスタ・ロックの保証

クラスタ・メンバの Process B が、Process A によってロックされたことがあるクラスタ・データベースのグローバル ^x へのロックを取得したとします。

この場合、Process B は、(^x へのロックを取得している間、) Process A によっていずれかのクラスタ・データベースに行われたすべての更新を表示できます。

また、クラスタ・メンバの Process C が、(^x へのロックを取得した場合、) Process B によってクラスタ・データベースに行われた更新を表示できるだけでなく、Process C は、(^x へのロックを保持した状態で、) Process A によっていずれかのクラスタ・データベースに行われた更新も表示できます。

このシリアル化機能は、Process A、Process B、Process C が同じクラスタ・メンバに属すかどうか、またはクラスタ・メンバがクラッシュしているかどうかにかかわらず保証されます。

ロールバックの保証

Process A が、一連の更新の後に、TStart コマンドを実行してから、TCommit を発行する前に中断したか、TCommit を実行する前に TRollback を実行したとします。

Process A により、トランザクションの一部として行われた更新はすべて、最初とは逆の順序でロールバックされます。

コミットの保証

Process A が DataServer S で一連の更新を行い、TCommit の実行を開始した後に中断したとします。

トランザクションに含まれる DataServer S それぞれで、DataServer S でのデータの変更がコミットまたはロールバックされます。TCommit を実行するプロセスの Perform Synchronous Commit プロパティがオンになっている場合に (構成ファイル内で SynchCommit=1 に設定)、TCommit オペレーションから正常に値が返されると、そのトランザクションは、トランザクションの一部であるすべてのデータ・サーバで確実にコミットされたことが保証されます。

トランザクションとロックの保証

Process A では Transaction T のために TStart を実行し、DataServer S でグローバル ^x をロックした後、^x をロック解除します (ロック解除しても、“即時アンロック” ロック・タイプは指定されません)。

InterSystems IRIS では、^x へのロックは、トランザクションがコミットされるかロールバックされるまで解除されないことが保証されます。Transaction T が DataServer S でコミットするか、ロールバックするまで、他のプロセスは、^x へのロックを取得できません。

Transaction T が DataServer S でコミットすると、Process B では、^x へのロックを取得し、Transaction T の間に、Process A によって DataServer S に行われた変更が表示されます。また、他のプロセスが、(^x へのロックを保持している間) Process B によって DataServer S に行われた変更を表示した場合、(Transaction T 実行中に) Process A によって DataServer S に行われた変更が表示されます。逆に、Transaction T が DataServer S でロールバックした場合、^x へのロックを取得した Process B が、Process A によって DataServer S に行われた変更を表示しようとしても、何も表示されません。

ECP Rollback Only の保証

Process A (AppServer C 上) が、Transaction T の一部である変更を DataServer S で行い、DataServer S が一方的にその変更をロールバックします (これは、特定のネットワーク障害やデータ・サーバ障害で発生する場合がある)。

その後 Process A による DataServer S に対するネットワーク要求はすべて、Process A が明示的に TRollback コマンドを実行しない限り、<NETWORK> エラーによって拒否されます。

また、AppServer C のプロセスが、DataServer S のロールバックと Transaction T の TCommit の間に、DataServer S へのネットワーク要求を完了した場合 (AppServer C が TCommit の前に rollback-only 条件を検出した場合)、Transaction T には、Transaction T の一部であるすべてのデータ・サーバにロールバックが行われることが保証されます

ECP トランザクション・リカバリの保証

データ・サーバが、アプリケーション・サーバのトランザクションの途中でクラッシュし、その後再起動して、アプリケーション・サーバのリカバリ・タイムアウト時間内にリカバリを完了します。

この場合、トランザクションは、保証されているとおりに、正常に完了できます。データ・サーバは、ロック定義によって定義されている順番の制約に違反するようなデータ処理は実行しません。唯一の例外は、$Increment 関数です (詳細は、"ECP とクラスタの $Increment 制限" を参照してください)。リカバリできないトランザクションは、ロック定義を保護するようにロールバックされます。

ECP ロック・リカバリの保証

DataServer S に計画外のシャットダウンが発生したため、再起動して、リカバリ時間内にリカバリを完了しました。

この場合、ECP ロックの保証は、変更されたデータがジャーナルされている限り適用されます。データがジャーナルされていない場合、クラッシュの前のデータ・サーバに対する更新は、アプリケーション・サーバに通知されることなく、失われます。InterSystems IRIS では、ロックを取得したプロセスが、そのロックを保持している間に、他のプロセスによって以前に行われたすべての更新を表示できることは保証されません。

DataServer S を正しくシャットダウンし、再起動し、リカバリ時間内にリカバリを完了した場合は、データがジャーナルされているかどうかにかかわらず、ECP ロックの保証は適用されます。

トランザクションの一部である更新は、常にジャーナルされ、ECP トランザクション・リカバリの保証は確実に適用されます。他のジャーナルは、目的のデータベース内のグローバルがジャーナリングとマークされているかどうかによって、ジャーナルされる場合とされない場合があります。

$Increment 順序の保証

$Increment 関数には、異なるプロセスからの Set や Kill オペレーションがロックで保護されていなくても、それらの一連のオペレーションに対する緩やかな順序があります。

例えば、Process A が、DataServer S で、Set と Kill オペレーションを実行し、DataServer S でグローバル ^x に $Increment オペレーションを実行します。Process B は、その後に、同じグローバル ^x に $Increment を実行します。Process B を含むどのプロセスからでも、^x をインクリメントした Process B の結果を表示する場合、^x をインクリメントする前に Process A が DataServer S に実行したすべての変更も表示されます。

ECP Sync メソッドの保証

プロセス A は、データ・サーバ S にあるグローバルを更新し、$system.ECP.Sync() 呼び出しを S に対して発行します。続いて、プロセス B は $system.ECP.Sync() を S に対して発行します。プロセス B は、$system.ECP.Sync() 呼び出しの前に、プロセス A がデータ・サーバ S で実行したすべての更新を表示できます。

$system.ECP.Sync() は、アプリケーション・サーバで実行しているプロセスにのみ関係があります。プロセス A または B のいずれかがデータ・サーバ S 自体で実行している場合、そのプロセスは $system.ECP.Sync() を発行する必要はありません。両方のプロセスがデータ・サーバ S で実行している場合、どちらも $system.ECP.Sync を必要としません。これは、同じサーバで実行しているプロセスがグローバル更新を直ちに見ることができることを示す文に過ぎません。

ECP とクラスタの $Increment 制限

データ・サーバに対する未実行 $Increment 要求がアプリケーション・サーバにあり、グローバルがジャーナリングされたとき、データ・サーバがクラッシュすると、InterSystems IRIS は、$Increment 結果をジャーナルから回復しようとし、参照を再びインクリメントしません。

ECP Cache の最新性の制限

障害が継続して発生していない場合は、アプリケーション・サーバは数秒以内にデータの更新を参照できますが、これは保証されていません。特に、ECP のデータ・サーバとの接続が中断した場合 (ネットワーク障害、データ・サーバのシャットダウン、データ・サーバのバックアップ処理など)、ユーザ・プロセスはアプリケーション・サーバの接続タイムアウト値を限度に古いデータを参照する場合があります。データが古くないことを確認するには、Lock コマンドをデータ・フェッチ操作で使用するか、または $system.ECP.Sync を使用します。アプリケーション・サーバとデータ・サーバ間を往復するネットワーク要求によって、アプリケーション・サーバ ECP ネットワーク・キャッシュのコンテンツが更新されます。

ECP ルーチンの再検証の制限

アプリケーション・サーバがデータ・サーバからルーチンをダウンロードして、データ・サーバが (計画的または計画外に) 再起動されると、データ・サーバからダウンロードされたルーチンは編集済みであるかのようにマークされます。

また、データ・サーバとの接続にネットワーク障害 (アプリケーション・サーバかデータ・サーバのシャットダウン) が発生した場合も、データ・サーバからダウンロードされたルーチンは編集済みであるかのようにマークされます。この動作は、場合によっては、実体を伴わない <EDITED> エラーや <ERRTRAP> エラーが発生させることがあります。

非ロック状態の変更により競合が発生した場合のロールバック

InterSystems IRIS では、Lock コマンドはアドバイスに過ぎません。Process A が、グローバル ^y へのロックが保護された状態で、グローバル ^x を更新するトランザクションを開始し、別のプロセスが、^y へのロックが保護されていない状態で、^x を変更した場合、^x のロールバックは機能しません。

Set と Kill オペレーションのロールバックでは、データ・アイテムの現在の値がオペレーションによって設定された値である場合、その値は、オペレーションの前の値にリセットされます。現在の値が Set や Kill オペレーションによって設定された値とは異なる場合、現在の値は変更されません。

データ・アイテムが、ある時点でトランザクションの内部で変更され、別の時点でトランザクションの外部で、Lock コマンドで保護されずに変更されるような場合は、ロールバック機能は保証されません。ロールバックを有効にするには、データ・アイテムを変更する場合に必ずロックを使用する必要があります。

ジャーナルが中断した場合のロールバック

ロールバックは、ジャーナルの信頼性と完全性に依存しています。ジャーナルのデータが何かによって中断された場合、その中断した時点以降のロールバックは行えません。InterSystems IRIS では、このようなトランザクションのロールバックは暗黙的に無視されます。

ジャーナルの中断が発生する可能性がある場合は、InterSystems IRIS の動作中に ^JRNSTOP を実行した場合、InterSystems IRIS がシャットダウンした後や再起動する前に Write Image Journal (WIJ) ファイルを削除した場合、またはジャーナルのエラー時にシステムをフリーズするように設定されていないシステムで、ジャーナリング中に入出力エラーが発生した場合です。

ECP のリカバリ後に検出されないエラー

Set や Kill オペレーションが、データ・サーバで完了した後、エラーが発生したとします。データ・サーバはそのパケットの処理は完了していますが、アプリケーション・サーバ・システムに送信する前にクラッシュします。

この場合、ECP リカバリではそのパケットを再生しませんが、アプリケーション・サーバはそのエラーを検出していないため、アプリケーション・サーバは、データ・サーバ側の Set または Kill オペレーションを失います。

部分的 Set または Kill によるジャーナルの不一致

Set や Kill オペレーションを問題なくジャーナルできても、実際にデータベースを変更する前にエラーが発生するケースがあります。データのロールバックを定義する特別な方法があっても、それによって、トランザクションのロールバックが行われなくなることはありませんが、ジャーナルのリストア後のデータベースの状態は、リストア前のデータベースの状態と一致しなくなる場合があります。

クラスタのフェイルオーバーまたはリストア時の緩やかな順序

クラスタのデジャーナリングは緩やかに順序付けられます。異なるクラスタ・メンバのジャーナル・ファイルが同期化されるのは、ロック、$Increment、またはジャーナル・マーカー・イベントが発生した場合のみです。これは、クラスタ全体を停止してリストアする必要があるクラスタのフェイルオーバーやクラスタのクラッシュ後のデータベース状態に影響します。その場合、データベースは、クラッシュ前の状態と異なる状態にリストアされる場合があります。$Increment 順序の保証には、リストアされたデータベースがクラッシュ前の元の状態と異なる度合いに関する新たな制約があります。

Process B が Process A によって変更されたデータを表示できるからといって、Process A からの Set オペレーションの後に、Process B からの Set オペレーションがリストアされることが保証されるわけではありません。クラスタのフェイルオーバー時またはクラスタのリカバリ時に 2 つの異なるプロセスからの Set や Kill オペレーションが競合する場合、適切な順序を保証できるのは、Lock または $Increment オペレーションのみです。

クラスタ・メンバのクラッシュ時のダーティ・データの読み取り

クラスタ・メンバ Member A が Transaction T1 で更新を完了し、そのトランザクションが非同期のトランザクション・コミット・モードでコミットされたとします。別のクラスタ Member B の Transaction T2 が、Transaction T1 によって所有されていたロックを取得したとします。そして、Transaction T1 からのすべての情報がディスクに書き込まれる前に、クラスタ・メンバ Member A がクラッシュしたとします。

この場合、Transaction T1 は、クラスタ・フェイルオーバーの一部としてロールバックされます。しかし、Member B の Transaction T2 では、ロック・プロトコルの規則に従って、Transaction T1 の情報を表示できたはずであるのに、後でクラスタ・フェイルオーバーの一部としてロールバックされています。また、Transaction T2 で Transaction T1 と同じデータ・アイテムが一部変更された場合、Transaction T1 のロールバックは、一部のトランザクション・データしかロールバックできないため、失敗する可能性があります。

これを回避する方法は、クラスタ・メンバ Member A のトランザクションを同期コミット・モードで行うことです。同期コミット・モードを使用した場合、Transaction T1 はロックが解除される前にディスクに保存され、アプリケーションが Transaction T1 が完全であることを認識すれば、ロールバックされることはありません。

ECP でのロックしないダーティ・データの読み取り

ECP トランザクションがロックしないでデータを読み取る場合、ディスクに保存されていないデータを読み取りますが、データ・サーバがクラッシュするとそのデータは失われる可能性があります。そのようなデータを読み取れるのは、他の ECP 接続やローカル・データ・サーバ・システム自体によって、データの場所が設定されている場合のみです。保存されていないデータが、その接続自体によって設定されている場合は表示できません。また、データを読み取るプロセスとデータを書き込むプロセスの両方にロックが使用されている場合、保存されていないデータを表示することはできません。ここでは、更新順の保証が適用されず、ロックを使用する以外に簡単に解決できる方法はありません。

非同期のエラーが TCommit で検出された場合のロールバック

データ・サーバ側のトランザクションが、データベースの更新中に、<FILEFULL> などの非同期のエラー状況に遭遇し、アプリケーション・サーバが TCommit 時までそのエラーを認識できなかった場合、トランザクションは自動的にデータ・サーバ側でロールバックされます。ただし、TCommit オペレーションは通常は非同期ですが、ロールバックは同期です。これは、アプリケーション・サーバ・プロセスがロックを解除するまでにアプリケーション・サーバに通知しておく必要があるブロックが、ロールバックによって変更されるためです。

データ・サーバとデータベースには問題はありませんが、アプリケーション・サーバ側では、ロックが別のプロセスに移った場合、アプリケーション・サーバはロールバックされようとするデータを一時的に参照する場合があります。しかし、アプリケーション・サーバでは、非同期エラーを発生させることを通常は行いません。