シャーディングによるデータ量に応じた水平方向の拡張

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、次に残りのデータ・ノード、そして計算ノード (オプション) というように順番に導入できます (他のデータ・ノードを構成するには、データ・ノード 1 として構成されているインスタンスが実行されている必要があるため、他のインスタンスを導入する前に、このインスタンスを導入して正常に開始する必要があります)。導入ホストの名前が指定した正規表現で終わっていれば、1 つのマージ・ファイルを使用して、データ・ノードのクラスタを自動的に導入 (およびオプションでミラーリング) することもできます。データ・ノードの導入後、オプションで別のマージ・ファイルを使用して計算ノードを導入できます。

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

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

"InterSystems IRIS シャード・クラスタの計画" で説明しているように、理想的にデータ・ノード上のデータベース・キャッシュに割り当てる必要があるメモリ量は、予想されるシャード・データの作業セットすべてのノードへの割り当て分に、頻繁にシャード・データに結合されるシャード化されていないデータの予想される作業セットすべてを加えたものになります。

"InterSystems IRIS シャード・クラスタの計画" で説明しているように、既定のグローバル・データベースのターゲット・サイズは以下のとおりです。

• クラスタ・ネームスペース — シャード・データの合計サイズのうちの各サーバへの割り当て分 (上述のセクションで説明している計算による) に、予想を超える増大を見越したマージンを加えたもの。

• ノード 1 のマスタ・ネームスペース — シャード化されていないデータの合計サイズに、予想を超える増大を見越したマージンを加えたもの。

すべての導入方法でこれらのデータベースのサイズが既定で構成されているため、ユーザがこの構成を行う必要はありません。ただし、これらのデータベースが配置されるストレージが、ターゲット・サイズに対応できる大きさであることを確認する必要があります。

シャード・クラスタは最初のデータ・ノードを構成するときに初期化されます。最初のデータ・ノードをデータ・ノード 1、または単にノード 1 と呼びます。このデータ・ノードは、クラスタのシャード化されていないデータ、メタデータ、およびコードを格納し、すべてのデータ・ノードがそのデータにアクセスできるようにするマスタ・ネームスペースをホストするという点で、他のノードとは異なります。この区別は、より多くのデータがこの最初のノードに格納されるということ以外、ユーザに対して完全に透過的です。ただし、この違いも一般的には小さいものです。

最初の 4 つのステップ (データ・ノードの計画、データベース・キャッシュとデータベース・サイズの見積もり、インフラストラクチャのプロビジョニングまたは特定、およびデータ・ノード・ホストへの InterSystems IRIS の導入) を完了したら、この手順を使用して、前のステップで導入したインスタンス (または準備しておいた既存のインスタンス) を、管理ポータルを使用してデータ・ノードの基本の InterSystems IRIS シャード・クラスタとして構成します。

ノード 1 を構成するには、以下の手順を実行します。

1. インスタンスの管理ポータルを開き、[システム管理]→[構成]→[システム構成]→ [シャーディング]→[シャード有効] の順に選択し、表示されるダイアログで [OK] をクリックします (既定値はほぼすべてのクラスタに適しているため、[ECP 接続の最大数] 設定の値を変更する必要はありません)。

2. インスタンスを再起動します (管理ポータルが表示されているブラウザのウィンドウやタブを閉じる必要はありません。インスタンスが完全に再起動した後に再読み込みするだけでかまいません)。

3. [ノードレベルの構成] ページ ([システム管理]→[構成]→[システム構成]→[シャーディング]→[ノードレベルの構成]) に移動して、[構成] ボタンをクリックします。

4. [ノードレベルクラスタの構成] ダイアログで [このインスタンスで新しいシャードクラスタを初期化] を選択し、表示されるプロンプトに次のように応答します。

   • [クラスタネームスペース] および [マスターネームスペース] のドロップダウンからそれぞれクラスタ・ネームスペースとマスタ・ネームスペースを選択します。どちらのドロップダウンにも以下が含まれます。

     • 作成する新しいネームスペースの既定の名前 (IRISCLUSTER および IRISDM) と、その既定のグローバル・データベース。

     • 対象となるすべての既存のネームスペース。

     シャード・クラスタを初期化すると、既定で、クラスタとマスタ・ネームスペース (それぞれ IRISCLUSTER および IRISDM という名前) と共に、その既定のグローバル・データベースと必要なマッピングが作成されます。ただし、クラスタ・ネームスペースとマスタ・ネームスペースの名前、およびそのグローバル・データベースの特性を制御するため、クラスタを構成する前に一方または両方のネームスペースと既定のデータベースを作成しておき、この手順でそれらを指定できます。例えば、"グローバル・データベース・サイズ" で説明されている考慮事項を踏まえ、クラスタ・ネームスペースの既定のグローバル・データベースの特性や、クラスタ内のすべてのデータ・ノードに複製されるシャード・データベースを制御するために、この方法を実行できます。

     Note:

     クラスタ・ネームスペースとして指定した既存ネームスペースの既定グローバル・データベースになんらかのグローバルまたはルーチンがあると、初期化がエラーで失敗します。

   • 場合によっては、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。このような理由または他の理由で、代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させたい場合は、ホスト名のオーバーライドのプロンプトで IP アドレスを入力します。

   • [ミラーリング有効] は選択しないでください。ミラーリングされたシャード・クラスタの導入手順は、"ミラーによる高可用性" で説明されています。

5. [OK] をクリックして [ノードレベルの構成] ページに戻ります。2 つのタブ [シャード] と [シャードテーブル] が表示されています。ノード 1 がクラスタ・アドレス (次の手順で必要になります) を含めて [シャード] に表示されるので、参照用にノード 1 の管理ポータルで [ノードレベルの構成] ページを開いたままにしておくことができます。[シャードを検証] をクリックして、ノード 1 が正しく構成されていることを検証します。

ノードを構成したら、以下の手順を使用して追加の各データ・ノードを構成します。

1. インスタンスの管理ポータルを開き、[システム管理]→[構成]→[システム構成]→ [シャーディング]→[シャード有効] の順に選択し、表示されるダイアログで [OK] をクリックします (既定値はほぼすべてのクラスタに適しているため、[ECP 接続の最大数] 設定の値を変更する必要はありません)。

2. インスタンスを再起動します (管理ポータルが表示されているブラウザのウィンドウやタブを閉じる必要はありません。インスタンスが完全に再起動した後に再読み込みするだけでかまいません)。

3. [ノードレベルの構成] ページ ([システム管理]→[構成]→[システム構成]→[シャーディング]→[ノードレベルの構成]) に移動して、[構成] ボタンをクリックします。

4. [ノードレベルクラスタの構成] ダイアログで [このインスタンスを既存のシャードクラスタに追加] を選択し、表示されるプロンプトに次のように応答します。

   • クラスタ URL を入力します。これは、[ノードレベルの構成] ページの [シャード] タブにノード 1 に対して表示されているアドレスです (前の手順の説明を参照してください)。クラスタ URL は、ノード 1 ホストの ID (ホスト名、または前の手順で IP アドレスを指定した場合は IP アドレス) に、InterSystems IRIS インスタンスのスーパーサーバ・ポートとクラスタ・ネームスペースの名前を加えたものになります。例えば、clusternode011.acmeinternal.com:1972:IRISCLUSTER のようになります (クラスタ・ネームスペースの名前は、既定の IRISCLUSTER である場合は省略できます)。

     Note:

     もう 1 つのノード (この手順で必要なノード) から見ると、コンテナ化された InterSystems IRIS インスタンスのスーパーサーバ・ポートは、そのコンテナが作成されたときにスーパーサーバ・ポートが公開されたホスト・ポートによって異なります。この詳細および例は、"永続的な %SYS を使用した InterSystems IRIS コンテナの実行" と "InterSystems IRIS コンテナの実行 ： Docker Compose の例"、および Docker ドキュメントの "Container networkingOpens in a new tab" を参照してください。

     キットでインストールした、そのホスト上にしかない InterSystems IRIS インスタンスの既定のスーパーサーバ・ポート番号は 1972 です。複数のインスタンスがインストールされている場合、スーパーサーバ・ポート番号は 51776 以上の範囲になります。インスタンスのスーパーサーバ・ポート番号を表示または変更するには、管理ポータルで [システム管理]→[構成]→[システム構成]→[メモリと開始設定] を選択します。

   • [ロール] プロンプトで [データ] を選択して、インスタンスをデータ・ノードとして構成します。

   • 場合によっては、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。このような理由または他の理由で、代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させたい場合は、ホスト名のオーバーライドのプロンプトで IP アドレスを入力します。

   • [ミラー化クラスタ] は選択しないでください。ミラーリングされたシャード・クラスタの導入手順は、"ミラーによる高可用性" で説明されています。

5. [OK] をクリックして [ノードレベルの構成] ページに戻ります。2 つのタブ [シャード] と [シャードテーブル] が表示されています。これまでに構成したデータ・ノードが [シャード] にノード 1 から表示されます。[シャードを検証] をクリックして、データ・ノードが正しく構成されていて、他のノードと通信できることを検証します。

   Note:

   構成するデータ・ノードが多数ある場合は、[詳細設定] ボタンをクリックし、[詳細設定] ダイアログで [割り当て時に自動的にシャードを検証] を選択することにより、検証操作を自動化できます。シャード・クラスタを導入する際は、このダイアログのその他の設定は既定値のままにします。

[再分散] ボタンを使用すると、[REBALANCE] ダイアログが表示されます。このダイアログで、既存のクラスタに最近追加されたデータ・ノードを含むすべてのデータ・ノードに均等にシャード・データを再分散できます (再分散の実行中にシャード・テーブルをクエリすることはできません)。データの再分散の詳細は、"データ・ノードの追加とデータの再分散" を参照してください。

[詳細設定] ダイアログは、[ノードレベルの構成] ページの [詳細設定] ボタンを押すと表示できます。このダイアログには以下のオプションがあります。

• [割り当て時に自動的にシャードを検証] を選択すると、新しいクラスタ・ノードの構成後の検証を自動化できます。

• クラスタのシャード・クエリ実行モードOpens in a new tabを既定の非同期から同期に変更します。この効果の説明については、"ミラーリングされたクラスタに計算ノードを含めることによる、フェイルオーバー前後での透過的なクエリ実行" を参照してください。

• シャードの接続タイムアウトOpens in a new tabを既定値の 60 秒から変更します。

• ホスト名ではなく、データ・ノード 1 ホストの IP アドレスOpens in a new tabを使用してクラスタ通信中に特定します。

• クラスタがミラー・シャードへの接続を再試行するOpens in a new tab回数を既定値の 1 から変更します。

• ローカル・ノードの ECP 接続の最大数を変更します。クラスタ内のノードの合計数がこの設定を超えることはできません。このセクションの 2 つのステップそれぞれの開始時に説明したように、この設定は、管理ポータルの [シャード有効] オプションを使用した場合、64 に設定されます。

• クラスタを、DROP TABLE 操作中にエラーを無視Opens in a new tabするように設定します。

[ノードレベルの構成] ページの [シャードテーブル] タブに、クラスタ上のすべてのシャード・テーブルに関する情報が表示されます。

シャード・クラスタは最初のデータ・ノードを構成するときに初期化されます。最初のデータ・ノードをデータ・ノード 1、または単にノード 1 と呼びます。このデータ・ノードは、クラスタのシャード化されていないデータ、メタデータ、およびコードを格納し、すべてのデータ・ノードがそのデータにアクセスできるようにするマスタ・ネームスペースをホストするという点で、他のノードとは異なります。この区別は、より多くのデータがこの最初のノードに格納されるということ以外、ユーザに対して完全に透過的です。ただし、この違いも一般的には小さいものです。

ノード 1 を構成するには、インスタンスの InterSystems ターミナルを開き、$SYSTEM.Cluster.Initialize()Opens in a new tab メソッドを呼び出します。以下に例を示します。

set status = $SYSTEM.Cluster.Initialize()

Note:

これらの手順で詳述されている各 API 呼び出しの戻り値 (成功の場合は 1 など) を確認するには、以下を入力します。

zw status

状況によっては通知なしで呼び出しが失敗することがあるため、各呼び出しの後に [ステータス] を確認することをお勧めします。呼び出しが成功しなかった ([ステータス] が [1] 以外) 場合、以下を入力することにより、わかりやすいエラー・メッセージが表示されます。

do $SYSTEM.Status.DisplayError(status) 

Initialize() 呼び出しにより、マスタ・ネームスペースとクラスタ・ネームスペース (それぞれ IRISDM と IRISCLUSTER)、およびその既定のグローバル・データベースを作成し、必要なマッピングを追加します。ノード 1 はクラスタの他の部分に対してテンプレートとして機能します。クラスタ・ネームスペースの名前、既定のグローバル・データベース (シャード・データベースとも呼ばれる) の特性、およびマッピングは、2 番目に構成したデータ・ノードに直接複製され、さらにその他すべてのデータ・ノードに直接、または間接的に複製されます。インスタンスの SQL 構成設定も複製されます。

クラスタとマスタ・ネームスペースの名前、およびそれらのグローバル・データベースの特性を制御するには、クラスタのネームスペース、マスタ・ネームスペース、またはその両方として既存のネームスペースを指定 (いずれかまたは両方の名前を引数として含めることによって指定) します。以下に例を示します。

set status = $SYSTEM.Cluster.Initialize("CLUSTER","MASTER",,)

この際、指定した各ネームスペースの既存の既定グローバル・データベースは残ります。これにより、シャード・データベースの特性を制御でき、これらはクラスタ内の他のデータ・ノードに複製されます。

既定では、どのホストもクラスタ・ノードになることができます。Initialize() の 3 番目の引数で、IP アドレスまたはホスト名のコンマ区切りのリストを指定することで、クラスタに参加できるホストを指定できます。リストにないノードはクラスタに参加できません。

場合によっては、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。このような理由または他の理由で、代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させたい場合は、4 番目の引数として IP アドレスを含めます(この引数にホスト名を指定することはできません。IP アドレスのみです)。いずれの場合も、2 番目のデータ・ノードを構成する際、ホスト識別子 (ホスト名または IP アドレス) を使用してノード 1 を識別します。インスタンスのスーパーサーバ (TCP) ポートも必要です。

Initialize() メソッドは、InterSystems IRIS インスタンスが既にシャード・クラスタのノードであるか、ミラー・メンバである場合、エラーを返します。

各追加データ・ノードを構成するには、InterSystems IRIS インスタンスのターミナルを開き、既存のクラスタ・ノード (2 番目のノードを構成している場合はノード 1) のホスト名とその InterSystems IRIS インスタンスのスーパーサーバ・ポートを指定して $SYSTEM.Cluster.AttachAsDataNode()Opens in a new tab メソッドを呼び出します。以下に例を示します。

set status = $SYSTEM.Cluster.AttachAsDataNode("IRIS://datanode1:1972")

ノード 1 の初期化の際、Initialize() の 4 番目の引数として IP アドレスを指定した場合は、最初の引数でノード 1 を識別するためにホスト名の代わりに IP アドレスを使用します。以下に例を示します。

set status = $SYSTEM.Cluster.AttachAsDataNode("IRIS://100.00.0.01:1972")

AttachAsDataNode() 呼び出しは、以下を実行します。

• クラスタ・ネームスペースとシャード・データベースを作成し、それらを "ノード 1 の構成" で説明したとおり、テンプレート・ノードの設定 (最初の引数で指定) に合わせて構成し、必要なマッピングを作成して、これらをノード 1 のマスタ・ネームスペースのグローバル・データベースとルーチン・データベースに含めます (ユーザ定義のマッピングを含む)。

• すべての SQL 構成オプションを、テンプレート・ノードに合わせて設定します。

• このノードは AttachAsDataNode() のテンプレート・ノードとして後で使用される可能性があるため、クラスタに参加できるホストのリストを、ノード 1 の Initialize() 呼び出しで指定したリスト (ある場合) に設定します。

AttachAsDataNode() 呼び出しは、InterSystems IRIS インスタンスが既にシャード・クラスタのノードまたはミラー・メンバであるか、最初の引数で指定されたテンプレート・ノードがミラー・メンバである場合、エラーを返します。

前のステップで説明したように、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させるには、IP アドレスを 2 番目の引数として含めます(この引数にホスト名を指定することはできません。IP アドレスのみです)。

すべてのデータ・ノードを構成したら、$SYSTEM.Cluster.ListNodes()Opens in a new tab メソッドを呼び出してこれらをリストできます。以下に例を示します。

set status = $system.Cluster.ListNodes()
NodeId  NodeType    Host          Port
1       Data        datanode1     1972
2       Data        datanode2     1972
3       Data        datanode3     1972

この例のように、データ・ノードには、クラスタにアタッチされる順序を表す数値 ID が割り当てられます。

ベスト・プラクティスとして、クラスタ内のすべてのデータ・ノード間でアプリケーション接続を負荷分散することをお勧めします。

クラスタへの計算ノードの追加の詳細は、"作業負荷の分離とクエリ・スループットの向上のための計算ノードの導入" を参照してください。

既定では、シャード・テーブルを作成してシャード・キーを指定していない場合、システムにより割り当てられた RowID をシャード・キーとして使用して、データがここにロードされます。例えば、2 つのシャードがある場合、RowID=1 の行は一方のシャードに、RowID=2 の行はもう一方のシャードにロードされます。これはシステムが割り当てたシャード・キー (SASK) と呼ばれ、データの均等分散を最適に保証し、最も効率的な並列データ・ロードを可能にするため、多くの場合、最も簡単で効果的なアプローチになります。

シャード・テーブルの作成時に、シャード・キーとして 1 つ以上のフィールドを指定するオプションもあります。これはユーザ定義のシャード・キー (UDSK) と呼ばれます。スキーマに RowID に対応しない意味的に重要な一意の識別子が含まれている場合、例えば、スキーマ内のいくつかのテーブルに accountnumber フィールドがある場合は、UDSK を使用する良い機会かもしれません。

その他の考慮事項として、大きなテーブルを結合するクエリがあります。各シャード・クエリはシャードローカル・クエリに分解されます。それぞれのクエリは個々に、各シャード上でローカルに実行され、そのシャードに存在するデータを参照すればよいだけです。ただし、シャード・クエリに 1 つ以上の結合が含まれる場合、シャードローカル・クエリは一般に他のシャードのデータを参照する必要があるため、処理時間が長くなると共に、データベース・キャッシュに割り当てられたメモリをより多く使用します。この余分なオーバーヘッドは、コシャード結合を有効にすることで回避できます。コシャード結合では、結合される 2 つのテーブルの行が同じシャード上に配置されます。結合がコシャードされている場合、その結合が関与するクエリは、同じシャード上の行のみを結合するシャードローカル・クエリに分解され、他のシャード・クエリと同様に個別にローカルに実行されます。

コシャード結合は、以下の 2 つのアプローチのいずれかを使用して有効にできます。

• 2 つのテーブルに対して同等な UDSK を指定する。

• 1 つのテーブルに SASK を使用し、もう 1 つのテーブルで coshard with キーワードと適切な UDSK を使用する。

同等な UDSK を使用するには、2 つのテーブルにシャード・キーとして頻繁に結合されるフィールドを指定するだけです。例えば CITATION テーブルと VEHICLE テーブルを結合し、各車両に関連付けられた交通違反通知を返す場合、以下のようにします。

SELECT * FROM citation, vehicle where citation.vehiclenumber = vehicle.vin

この結合をコシャード結合にするには、同等なそれぞれのフィールドをシャード・キーとして使用して、両方のテーブルを作成します。

CREATE TABLE VEHICLE (make VARCHAR(30) not null, model VARCHAR(20) not null, 
  year INT not null, vin VARCHAR(17) not null, shard key (vin))

CREATE TABLE CITATION(citationid VARCHAR(8) not null, date DATE not null, 
  licensenumber VARCHAR(12) not null, plate VARCHAR(10) not null,
  vehiclenumber VARCHAR(17) not null, shard key (vehiclenumber))

シャーディング・アルゴリズムは決定的であるため、特定の VIN の VEHICLE 行と CITATION 行 (ある場合) (それぞれ vin および vehiclenumber フィールドの値) は、同じシャード上に配置されます (ただし、フィールド値そのものが、行の各セットがどのシャードに配置されるかを特定することはありません)。したがって、上記のクエリが実行されると、各シャードローカル・クエリは、ローカルに (つまり、完全にそのシャード上で) 結合を実行できます。シャード・キーとして使用される 2 つのフィールド間の等値条件が含まれていなければ、結合をこのようにコシャードすることはできません。同様に、それぞれのテーブルのシャード・キーに、フィールド値の等値性を比較できるタイプの同じフィールド番号が同じ順序で存在する限り、複数フィールドの UDSK を使用して、コシャード結合を有効にできます。

多くのケースで有効なその他のアプローチでは、SASK を使用して 1 つのテーブルを作成し、最初のテーブルと共にコシャードされることを示す coshard with キーワード、および最初のテーブルのシステムが割り当てた RowID 値に等しい値を持つシャード・キーを指定することにより、もう 1 つのテーブルを作成します。例えば、以下のように、クエリで ORDER テーブルおよび CUSTOMER テーブルを頻繁に結合しているとします。

SELECT * FROM orders, customers where orders.customer = customers.%ID

この場合、結合の片方のフィールドは RowId を表すため、テーブル CUSTOMER を SASK を使用して次のように作成することから開始します。

CREATE TABLE CUSTOMER (firstname VARCHAR(50) not null, lastname VARCHAR(75) not null, 
  address VARCHAR(50) not null, city VARCHAR(25) not null, zip INT, shard)

コシャード結合を有効にするには、CUSTOMER テーブルへの参照として customer フィールドが定義されている ORDER テーブルを、そのフィールドで CUSTOMER テーブルとのコシャードを指定することで、シャーディングします。

CREATE TABLE ORDER (date DATE not null, amount DECIMAL(10,2) not null, 
  customer CUSTOMER not null, shard key (customer) coshard with CUSTOMER)

前に説明した UDSK の例と同様、これにより、ORDER の各行は、RowID 値がその customerid 値と一致する CUSTOMER の行と同じシャード上に配置されます (例えば、customerid=427 であるすべての ORDER 行は、ID=427 の CUSTOMER 行と同じシャード上に配置されます)。このようにして有効になったコシャード結合は、SASK でシャーディングされたテーブルの ID と、そのテーブルと共にコシャードされるテーブルに対して指定されるシャード・キーとの間の等値条件を含む必要があります。

一般には、スキーマで指定した以下のいずれかを使用することで、最も有用なコシャード結合を有効にできます。

• 例に示したとおり、テーブルと coshard with キーワードとの構造的な関係を表す SASK。この例では、ORDER テーブル内の customerid が CUSTOMER テーブル内の RowId への参照となっています。

• RowID に対応しないため、VEHICLE テーブルおよび CITATION テーブルの等値の vin フィールドと vehiclenumber フィールドの使用で説明したとおりに coshard with を使用してコシャードできない、意味的に重要なフィールドを含む UDSK(多くの結合で使用されますが、表面的またはアドホックな関係を表すフィールドを含む UDSK は、通常あまり役立ちません)。

結合がないクエリやシャード・データとシャード化されていないデータを結合するクエリと同様に、コシャード結合は、シャード数の増加に伴う拡張性に優れているだけでなく、結合されるテーブルの数の増加に伴う拡張性にも優れています。コシャードされていない結合は、シャードや結合されるテーブルの数が適度であれば、優れたパフォーマンスを発揮しますが、それらの数の増加に伴う拡張性にはそれほど優れていません。こうした理由から、例えば、クエリが頻繁に実行されるフィールドのセットのパフォーマンスを向上させるためにインデックスを考慮するのと同様に、この段階でコシャード結合を慎重に検討する必要があります。

シャード・キーを選択する際は、これらの一般的な考慮事項に留意してください。

• シャード・テーブルのシャード・キーは変更できず、その値を更新することもできません。

• 他の条件がすべて同じであれば、シャード間でのテーブルの行のバランスの取れた分散はパフォーマンスを向上させ、行の分散に使用されるアルゴリズムは、シャード・キーにさまざまな値が大量に含まれるが、主だった異常値はない場合に、最適なバランスを提供します (頻度に関して)。これは既定の RowID が一般にうまく機能するためです。類似した特性を持つ適切な UDSK は効率的であることも多いですが、不適切な UDSK はパフォーマンスの大きな向上が見られない不均衡なデータ分散につながる可能性があります。

• 大きいテーブルがはるかに小さいものに頻繁に結合されるときに、大きいテーブルをシャード化し、小さいテーブルをシャード化されないようにすると、コシャード結合を有効にするより効果的な場合があります。

シャード・テーブルに一意制約がある場合 ("フィールド制約" および "複数フィールドでの一意制約" を参照)、すべてのシャード間で一意性が保証されます。これは通常、挿入または更新される各行について、すべてのシャード全体で一意性を強制する必要があるため、挿入/更新のパフォーマンスが大幅に低下することを意味します。ただし、シャード・キーが一意キーのフィールドのサブセットである場合は、行が挿入または更新されるシャードでローカルに一意性を強制することにより、すべてのシャード全体で一意性を保証できるため、このようなパフォーマンスへの影響が回避されます。

例えば、指定したキャンパスの OFFICES テーブルに buildingnumber フィールドと officenumber フィールドが含まれているとします。建物番号はキャンパス内で一意であり、オフィス番号は各建物内で一意です。この 2 つを組み合わせて、各従業員のオフィス・アドレスをキャンパス内で一意にする必要があります。したがって、テーブルに対する一意制約を以下のように配置します。

CREATE TABLE OFFICES (countrycode CHAR(3), buildingnumber INT not null, officenumber INT not null,
  employee INT not null, CONSTRAINT address UNIQUE (buildingname,officenumber))

ただし、テーブルをシャーディングする予定で、挿入/更新のパフォーマンスへの影響を回避するには、buildingnumber、officenumber、またはその両方をシャード・キーとして使用する必要があります。例えば、buildingnumber に対してシャーディングを行う (shard key (buildingnumber) を上記の文に追加することによる) 場合、各建物のすべての行が同じシャードに配置され、アドレスが “building 10, office 27” である従業員の行を挿入する際に、buildingnumber=10 であるすべての行を含むシャードに、アドレスの一意性をローカルに適用できます。officenumber に対してシャーディングを行う場合、officenumber=27 であるすべての行が同じシャードに配置され、“building 10, office 27” の一意性を、そのシャードにローカルに適用できます。一方、SASK、または UDSK として employee を使用する場合は、buildingnumber と officenumber の任意の組み合わせが任意のシャードに現れる可能性があるため、“building 10, office 27” の一意性をすべてのシャードで適用しなければならず、パフォーマンスに影響が生じます。

このような理由により、次のいずれかが当てはまらない限り、シャード・テーブルでの一意制約の定義は避けることをお勧めします。

• すべての一意制約がサブセットとしてシャード・キーと共に定義されている (これは一般に、SASK や他の UDSK ほど効果的ではない)。

• 挿入および更新のパフォーマンスが、該当するテーブルのクエリ・パフォーマンスと比べてはるかに重要性が低いと思われる。

クラスタ内の任意のデータ・ノードのクラスタ・ネームスペースで標準の CREATE TABLE 文 ("CREATE TABLE" を参照) を使用して空のシャード・テーブルを作成します。"シャード・キーの選択" の例で示したように、テーブルを作成する際、2 種類のシャーディング仕様があります。

• システムが割り当てたシャード・キー (SASK) でシャーディングを行うには、CREATE TABLE 文に shard キーワードを含めます。

• ユーザ定義のシャード・キー (UDSK) でシャーディングを行うには、shard の後に key とシャーディングするフィールドを指定します (shard key (customerid, purchaseid) など)。

ノード 1 または別のデータ・ノードの管理ポータルの [シャード構成] ページ ([システム管理]→[構成]→[システム構成]→[シャード構成]) に移動して、クラスタ・ネームスペースを選択し、[シャードテーブル] タブを選択することによって、名前、所有者、シャード・キーを含む、クラスタ上のすべてのシャード・テーブルのリストを表示できます。データをロードしたテーブルに対し、[詳細] リンクをクリックすると、クラスタ内の各データ・ノードに格納されているテーブルの行数を確認できます。

以下の制約が、シャード・テーブルの作成に適用されます。

• ALTER TABLE を使用して既存のシャード化されていないテーブルをシャード・テーブルに入れることはできません (ただし、ALTER TABLE を使用してシャード・テーブルを変更することはできます)。

• SHARD KEY フィールドのデータ型は、数値または文字列でなければなりません。シャード・キー・フィールドについて現在サポートされている照合は、完全一致、SQLString、および SQLUpper のみで、切り捨ては行われません。

• ROWVERSION フィールドおよび SERIAL (%Counter) フィールド以外のすべてのデータ型がサポートされます。

• シャード・テーブルに %CLASSPARAMETER VERSIONPROPERTYOpens in a new tab を含めることはできません。

このセクションのトピックの詳細および例は、"CREATE TABLE" を参照してください。

DDL を使用したシャード・テーブルの定義に加え、シャード・クラス・キーワードを使用してクラスをシャード・クラスとして定義することができます。詳細は、"永続クラスの作成によるシャード・テーブルの定義" を参照してください。クラス・コンパイラが拡張され、コンパイル時にシャーディングと互換性のないクラス定義機能 (カスタマイズされたストレージ定義など) の使用に対して警告を発行するようになりました。さらに成熟した作業負荷メカニズムや一部の互換性のない機能のサポートは、InterSystems IRIS の今後のバージョンで導入される予定です。

ミラーリングされたシャード・クラスタの導入時には、以下のセクションで説明する重要なポイントに留意してください。

ブラウザで管理ポータルを開く方法の詳細は、コンテナに導入されたインスタンスの手順、またはキットからインストールしたインスタンスの手順を参照してください。

ミラーリングされたクラスタを管理ポータルを使用して構成するには、以下の手順を実行します。

1. 対象のノード 1 プライマリと対象のノード 1 バックアップの両方でインスタンスの管理ポータルを開き、[システム管理]→[構成]→[システム構成]→[シャーディング]→[シャード有効] の順に選択し、表示されるダイアログで [OK] をクリックします (ここで [ECP 接続の最大数] 設定を変更する必要はありません)。続いて、指示に従ってインスタンスを再起動します。管理ポータルが表示されているブラウザのウィンドウやタブを閉じる必要はありません。インスタンスが完全に再起動したら再読み込みするだけでかまいません。

2. 対象のプライマリで、[ノードレベルの構成] ページ ([システム管理]→[構成]→[システム構成]→[シャーディング]→[ノードレベルの構成]) に移動して、[構成] ボタンをクリックします。

3. [ノードレベルクラスタの構成] ダイアログで [このインスタンスで新しいシャードクラスタを初期化] を選択し、表示されるプロンプトに次のように応答します。

   1. [クラスタネームスペース] および [マスターネームスペース] のドロップダウンからそれぞれクラスタ・ネームスペースとマスタ・ネームスペースを選択します。どちらのドロップダウンにも以下が含まれます。

      • 作成する新しいネームスペースの既定の名前 (IRISCLUSTER および IRISDM) と、その既定のグローバル・データベース。

      • 対象となるすべての既存のネームスペース。

      シャード・クラスタを初期化すると、既定で、クラスタとマスタ・ネームスペース (それぞれ IRISCLUSTER および IRISDM という名前) と共に、その既定のグローバル・データベースと必要なマッピングが作成されます。ただし、クラスタ・ネームスペースとマスタ・ネームスペースの名前、およびそのグローバル・データベースの特性を制御するため、クラスタを構成する前に一方または両方のネームスペースと既定のデータベースを作成しておき、この手順でそれらを指定できます。例えば、"グローバル・データベース・サイズ" で説明されている考慮事項を踏まえ、クラスタ・ネームスペースの既定のグローバル・データベースの特性や、クラスタ内のすべてのデータ・ノードに複製されるシャード・データベースを制御するために、この方法を実行できます。

      Note:

      シャード・クラスタとして既存のミラーを構成する際に既存のネームスペースを使用する場合は、"導入前のクラスタおよびマスタ・ネームスペースの作成" の手順に従います。

      クラスタ・ネームスペースとして指定した既存ネームスペースの既定グローバル・データベースになんらかのグローバルまたはルーチンがあると、初期化がエラーで失敗します。

   2. 場合によっては、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。このような理由または他の理由で、代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させたい場合は、ホスト名のオーバーライドのプロンプトで IP アドレスを入力します。

   3. [ミラーリング有効] を選択し、アービターを構成する場合はその場所とポートを追加します (これは強く推奨されるベスト・プラクティスです)。

4. [OK] をクリックして [ノードレベルの構成] ページに戻ります。2 つのタブ [シャード] と [シャードテーブル] が表示されています。ノード 1 がクラスタ・アドレス (次の手順で必要になります) を含めて [シャード] に表示されるので、参照用にノード 1 の管理ポータルで [ノードレベルの構成] ページを開いたままにしておくことができます。まだバックアップを追加していないため、ミラー名はまだ表示されません。

5. 対象のノード 1 バックアップで、プライマリの [ノードレベルの構成] ページに移動し、[構成] ボタンをクリックします。

6. [ノードレベルクラスタの構成] ダイアログで [このインスタンスを既存のシャードクラスタに追加] を選択し、表示されるプロンプトに次のように応答します。

   1. [ノードレベルの構成] ページの [シャード] タブに、[クラスタ URL] として、ノード 1 プライマリに対して表示されているアドレスを入力します (前のステップを参照)。

   2. [ロール] プロンプトで [データ] を選択して、インスタンスをデータ・ノードとして構成します。

   3. 場合によっては、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。このような理由または他の理由で、代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させたい場合は、ホスト名のオーバーライドのプロンプトで IP アドレスを入力します。

   4. [ミラー化クラスタ] を選択して以下を実行します。

      • [ミラーの役割] ドロップダウンから [バックアップ・フェイルオーバー] を選択します。

      • 前のステップでノード 1 を初期化する際にアービターを構成した場合は、その際に追加したものと同じアービターの場所とポートを追加します。

7. [OK] をクリックして [ノードレベルの構成] ページに戻ります。2 つのタブ [シャード] と [シャードテーブル] が表示されています。これまでに構成したノード 1 プライマリとバックアップは [シャード] のノード 1 の位置に、割り当てられているミラー名が含まれた状態で一覧表示されます。

8. 残りのミラーリングされたデータ・ノードに対し、[シャード有効] オプションの設定と両方のインスタンスの再起動から始めて、前のステップを繰り返します。プライマリをクラスタに追加する場合は、前述のように、ノード 1 プライマリのアドレスを [クラスタ URL] として入力します。ただし、バックアップを追加する場合には、先ほど追加したプライマリのアドレスを [クラスタ URL] として入力します (ノード 1 プライマリのアドレスではありません)。

9. ミラーリングされたデータ・ノードをそれぞれ追加したら、クラスタ内のプライマリの 1 つで [ノードレベルの構成] ページに移動して [シャードを検証] をクリックし、新しいミラーリングされたノードが正しく構成されていて、他のノードと通信できることを検証します。この作業は、ミラーリングされたデータ・ノードをすべて追加するまで待つこともできます。また、構成するデータ・ノードが多数ある場合は、[詳細設定] ボタンをクリックし、[詳細設定] ダイアログで [割り当て時に自動的にシャードを検証] を選択することにより、検証操作を自動化できます(シャード・クラスタを導入する際は、このダイアログのその他の設定は既定値のままにします)。

この API を使用して、ミラーリングされたクラスタを構成するには、以下の手順を実行します。

1. 対象のノード 1 プライマリで、インスタンスの InterSystems ターミナルを開き、$SYSTEM.Cluster.InitializeMirrored()Opens in a new tab メソッドを呼び出します。以下に例を示します。

   set status = $SYSTEM.Cluster.InitializeMirrored()
   

   
   Note:

   これらの手順で詳述されている各 API 呼び出しの戻り値 (成功の場合は 1 など) を確認するには、以下を入力します。

   zw status
   

   

   呼び出しが成功しなかった場合、以下を入力することにより、わかりやすいエラー・メッセージが表示されます。

   do $SYSTEM.Status.DisplayError(status) 
   

   

   "ノード 1 の構成" で説明したように、この呼び出しは、$SYSTEM.Cluster.Initialize()Opens in a new tab と同じようにノード上のクラスタを初期化します。InitializeMirrored() の最初の 4 つの引数 (必須のものはありません) の説明については、このセクションを確認してください。これらの引数は Initialize() の引数と同じです。インスタンスがまだミラー・プライマリでない場合、次の 5 つの引数を使用してこれを構成します。既にプライマリである場合、これらは無視されます。ミラー引数は以下のとおりです。

   • アービターのホスト

   • アービターのポート

   • 認証機関の証明書、ローカルな証明書、必要に応じて TLS でミラーを保護するために必要な秘密鍵ファイルを含むディレクトリ。呼び出しでは、これらのファイルがそれぞれ CAFile.pem、CertificateFile.pem、および PrivateKeyFile.pem という名前であると想定しています。

   • ミラーの名前。

   • このミラー・メンバの名前。

   Note:

   InitializeMirrored() 呼び出しは、以下の場合、エラーを返します。

   • 現在の InterSystems IRIS インスタンスが既にシャード・クラスタのノードである場合。

   • 現在のインスタンスが既にミラー・メンバであるが、プライマリではない場合。

   • (最初の 2 つの引数で) 既に存在するクラスタ・ネームスペースまたはマスタ・ネームスペースを指定し、そのグローバル・データベースがミラーリングされていない場合。

2. 対象のノード 1 バックアップで InterSystems IRIS インスタンスのターミナルを開き、最初の引数のクラスタ URL としてノード 1 プライマリのホストとスーパーサーバ・ポート、2 番目の引数にミラー・ロール backup を指定して、$SYSTEM.Cluster.AttachAsMirroredNode()Opens in a new tab を呼び出します。以下に例を示します。

   set status = $SYSTEM.Cluster.AttachAsMirroredNode("IRIS://node1prim:1972","backup")
   

   

   ノード 1 プライマリの初期化の際、InitializeMirrored() の 4 番目の引数として IP アドレスを指定した場合は、最初の引数でノード 1 を識別するためにホスト名の代わりに IP アドレスを使用します。以下に例を示します。

   set status = $SYSTEM.Cluster.AttachAsMirroredNode("IRIS://100.00.0.01:1972","backup")
   

   
   Note:

   そのホスト上にしかないコンテナ化されていない InterSystems IRIS インスタンスの既定のスーパーサーバ・ポート番号は 1972 です。インスタンスのスーパーサーバ・ポート番号を表示または設定するには、そのインスタンスの管理ポータルで [システム管理]→[構成]→[システム構成]→[メモリと開始設定] を選択します (インスタンスの管理ポータルを開いてスーパーサーバ・ポートを確認する方法の詳細は、コンテナに導入されたインスタンスの手順、またはキットからインストールしたインスタンスの手順を参照してください)。

   "残りのデータ・ノードの構成" で説明しているように、この呼び出しにより、$SYSTEM.Cluster.AttachAsDataNode()Opens in a new tab と同様、ノードがデータ・ノードとしてアタッチされ、これがノード 1 ミラーのバックアップ・メンバとなることが保証されます。この呼び出しを発行する前に、ノードがノード 1 プライマリのバックアップとなっている場合 (つまり、既存のミラーをノード 1 として初期化している場合)、ミラー構成は変わりません。これがミラー・メンバではない場合は、ノード 1 プライマリのミラーにバックアップとして追加されます。どちらの場合も、ノード 1 プライマリのネームスペース、データベース、およびマッピング構成は、このノードに複製されます。(AttachAsMirroredNode の 3 番目の引数は、AttachAsDataNode と同じです。つまり、他のクラスタ・メンバがこのノードとの通信にホストの IP アドレスを使用する場合、このアドレスを含めます。)

   ノード 1 ミラーの対象の DR 非同期メンバがある場合は、AttachAsMirroredNode() を使用してメンバをアタッチします。その際、以下の例のように、2 番目の引数として backup の代わりに drasync を使用します。

   set status = $SYSTEM.Cluster.AttachAsMirroredNode("IRIS://node1prim:1972","drasync")
   

   

   バックアップをアタッチするときと同じように、ミラーの既存のメンバをアタッチする場合、そのミラー構成が変更されるのではなく、必要なミラー構成が追加されます。どちらの場合も、ノード 1 プライマリのネームスペース、データベース、およびマッピング構成は、新しいノードに複製されます。

   Note:

   ノード 1 プライマリのミラーとは異なるミラーのメンバであるインスタンスをアタッチしようとすると、エラーが発生します。

3. ノード 1 以外のミラーリングされたデータ・ノードを構成するには、以下のように、$SYSTEM.Cluster.AttachAsMirroredNode()Opens in a new tab を使用してフェイルオーバー・ペアと DR 非同期の両方をクラスタにアタッチします。

   1. プライマリを追加する際には、既存のプライマリをクラスタ URL に指定し、2 番目の引数として primary を指定します。インスタンスがまだミラーのプライマリではない場合、4 番目の引数と続く 4 つの引数を使用してこれを新しいミラーの最初のメンバとして構成します。引数は、前述の InitializeMirrored() 呼び出しでリストされているとおりです。インスタンスが既にミラー・プライマリの場合、ミラー引数を指定しても無視されます。

   2. バックアップを追加する際には、対象のプライマリをクラスタ URL に指定し、2 番目の引数として backup を指定します。指定したノードがプライマリであるミラーに、バックアップとして既にインスタンスが構成されている場合、そのミラー構成は変わりません。インスタンスがまだミラー・メンバではない場合、これは 2 番目のフェイルオーバー・メンバとして構成されます。

   3. DR 非同期を追加する際には、対象のプライマリをクラスタ URL に指定し、2 番目の引数として drasync を指定します。指定したノードがプライマリであるミラーに、DR 非同期として既にインスタンスが構成されている場合、そのミラー構成は変わりません。インスタンスがまだミラー・メンバではない場合、これは DR 非同期として構成されます。

   Note:

   AttachAsMirroredNode() 呼び出しは、以下の場合、エラーを返します。

   • 現在の InterSystems IRIS インスタンスが既にシャード・クラスタのノードである場合。

   • primary のロールが指定され、クラスタ URL (最初の引数) で指定されたクラスタ・ノードがミラー・プライマリではないか、現在のインスタンスがプライマリ以外のロールのミラーに属している場合。

   • backup のロールが指定され、最初の引数で指定されたクラスタ・ノードがミラー・プライマリではないか、バックアップ・フェイルオーバー・メンバを既に持つミラーのプライマリである場合。

   • drasync のロールが指定され、最初の引数で指定されたクラスタ・ノードがミラー・プライマリではない場合。

   • backup または drasync のロールが指定され、追加するインスタンスが既に、指定したプライマリを持つミラー以外のミラーに属している場合。

   • クラスタ・ネームスペース (または、ノード 1 バックアップを追加している場合はマスタ・ネームスペース) が現在のインスタンスに既に存在し、そのグローバル・データベースがミラーリングされていない場合。

4. すべてのデータ・ノードを構成したら、$SYSTEM.Cluster.ListNodes()Opens in a new tab メソッドを呼び出してこれらをリストできます。クラスタがミラーリングされている場合、このリストはミラーリングされているデータ・ノードの各メンバのミラー名とロールを示します。以下に例を示します。

   set status = $system.Cluster.ListNodes()
   NodeId  NodeType    Host          Port   Mirror  Role
   1       Data        node1prim     1972   MIRROR1 Primary
   1       Data        node1back     1972   MIRROR1 Backup
   1       Data        node1dr       1972   MIRROR2 DRasync
   2       Data        node2prim     1972   MIRROR2 Primary
   2       Data        node2back     1972   MIRROR2 Backup
   2       Data        node2dr       1972   MIRROR2 DRasync
   

   

ここでは、既存のミラーリングされていないシャード・クラスタをミラーリングされたクラスタに変換する手順を説明します。以下に、関連するタスクの概要を示します。

• 少なくとも十分な数の新しいノードをプロビジョニングして準備し、クラスタ内の既存のデータ・ノードそれぞれにバックアップを提供します。

• 既存のデータ・ノードそれぞれにミラーを作成してから、ノード 1 で $SYSTEM.Sharding.AddDatabasesToMirrors()Opens in a new tab を呼び出して、クラスタをミラーリングされた構成に自動的に変換します。

• 既存のデータ・ノード上に、ミラーリングされていないマスタ・データベースとシャード・データベースの調整されたバックアップを作成します (各ミラーの最初のフェイルオーバー・メンバ)。"シャード・クラスタの調整されたバックアップとリストア" を参照してください。

• 対象の 2 番目のフェイルオーバー・メンバ (新しいノード) それぞれに対して、参加させる最初のフェイルオーバー・メンバ (既存のデータ・ノード) を選択してから、最初のフェイルオーバー・メンバ上のミラーリングされたデータベースに対応するデータベースを新しいノード上に作成します。続いて、そのミラーに新しいノードを 2 番目のフェイルオーバー・メンバとして追加し、最初のフェイルオーバー・メンバ上に作成したバックアップからデータベースをリストアして、そのデータベースを自動的にミラーに追加します。

• データ・ノード・ミラー内に作成したフェイルオーバー・ペアに DR 非同期を追加するには、最初のフェイルオーバー・メンバ上のミラーリングされたデータベースに対応する新しいノード上にデータベースを作成します。続いて、そのミラーに新しいノードを DR 非同期として追加し、最初のフェイルオーバー・メンバ上に作成したバックアップからデータベースをリストアして、そのデータベースを自動的にミラーに追加します。

• 任意のミラー・プライマリ (元のデータ・ノード) で $SYSTEM.Sharding.VerifyShards()Opens in a new tab を呼び出して、バックアップに関する情報を検証し、その情報をシャーディング・メタデータに追加します。

手順全体を 1 つのメンテナンス時間枠 (つまり、アプリケーションがオフラインで、クラスタ上にユーザのアクティビティがない予定期間) で実行することも、ここで説明するように手順を 2 つのメンテナンス時間枠に分割することもできます。

詳細なステップを以下に示します。まだ十分に理解していない場合は、続行する前に "%SYSTEM.Cluster API を使用したクラスタの構成" を確認してください。"ミラーリングの構成" で説明されているミラーの構成手順に関する知識も役に立ちますが、必須ではありません。この手順の各ステップには、必要に応じてリンクが記載されています。

1. この手順を使用するには、クラスタのクラスタ・ネームスペースおよびマスタ・ネームスペースの名前がわかっている必要があります。これらの名前は、クラスタの導入時に指定されています。例えば、"データ・ノード 1 の構成" の手順 4 では、クラスタ・ネームスペースとマスタ・ネームスペースの選択について説明しています。同様に、"ノード 1 の構成" の初期 API 呼び出しの説明には、クラスタ・ネームスペースとマスタ・ネームスペースの指定が含まれています。

2. "インフラストラクチャのプロビジョニングまたは特定" および "データ・ノード・ホストへの InterSystems IRIS の導入" の指示に従って、クラスタにバックアップ・フェイルオーバー・メンバとして追加するノードを準備します。想定されるバックアップのホストの特性と InterSystems IRIS の構成は、すべての点で既存のデータ・ノードと同じである必要があります ("ミラー構成のガイドライン" を参照)。

   Note:

   各フェイルオーバー・ペアに含まれる対象の最初のフェイルオーバー・メンバ (既存のデータ・ノード) および 2 番目のフェイルオーバー・メンバ (新しく追加したノード) をホスト名または IP アドレスで記録しておくと役に立ちます。

3. シャード・クラスタのメンテナンス時間枠を開始します。

4. 現在のデータ・ノードそれぞれで ISCAgent を開始し、ミラーを作成して最初のフェイルオーバー・メンバを構成します。

5. このクラスタをミラーリングされた構成に変換する、つまり、前のステップで作成したミラーをクラスタの構成およびメタデータに組み込むには、ノード 1 のインスタンスの InterSystems ターミナルを開き、以下のようにマスタ・ネームスペースで $SYSTEM.Sharding.AddDatabasesToMirrors() メソッドを呼び出します ("%SYSTEM.Sharding API" を参照)。

   set status = $SYSTEM.Sharding.AddDatabasesToMirrors()
   

   
   Note:

   これらの手順で詳述されている各 API 呼び出しの戻り値 (成功の場合は 1 など) を確認するには、以下を入力します。

   zw status
   

   

   状況によっては通知なしで呼び出しが失敗することがあるため、各呼び出しの後に [ステータス] を確認することをお勧めします。呼び出しが成功しなかった ([ステータス] が [1] 以外) 場合、以下を入力することにより、わかりやすいエラー・メッセージが表示されます。

   do $SYSTEM.Status.DisplayError(status) 
   

   

   AddDatabasesToMirrors() 呼び出しは、以下を実行します。

   • ノード 1 でマスタ・データベースとシャード・データベースを追加し ("ノード 1 の構成" を参照)、他のデータ・ノードでシャード・データベースをそのそれぞれのミラーに追加します。

   • ノード間のすべての ECP 接続をミラー接続として再構成します。計算ノード (該当する場合) とその関連データ・ノード間の ECP 接続も対象です。

   • すべてのデータ・ノード上でリモート・データベースを再構成し、それに応じて関連するすべてのマッピングを調整します。

   • シャーディング・メタデータを更新し、再構成した接続、データベース、およびマッピングを反映させます。

   呼び出しが正常に完了すると、シャード・クラスタは完全に使用可能な状態になります (ただし、バックアップ・フェイルオーバー・メンバをまだ追加していないため、フェイルオーバーはまだ実行できません)。

6. データ・ノードの調整されたバックアップを実行します (つまり、すべてのノードが論理的な同じ時点でバックアップされているバックアップ)。具体的には、最初のフェイルオーバー・メンバ (既存のデータ・ノード) のそれぞれでシャード・データベースをバックアップし、ノード 1 でマスタ・データベースもバックアップします。バックアップの前に、以下のようにインスタンスの構成パラメータ・ファイル (CPF) を確認して、適切なデータベースを特定しておきます。

   • CPF の [Map.clusternamespace] セクションを探して (例えば、クラスタ・ネームスペースが CLUSTERNAMESPACE の場合、このセクションは [Map.CLUSTERNAMESPACE])、IRIS.SM.Shard と IS.* グローバル接頭語のマッピング (このターゲットがシャード・データベース) を見つけることで、シャード・データベースを特定します。以下に示すように、他のグローバル接頭語もこのシャード・データベースにマッピングできます。シャード・データベースは SHARDDB として識別されます。

     [Map.CLUSTERNAMESPACE]
     Global_IRIS.SM.Shard=SHARDB
     Global_IRIS.Shard.*=SHARDDB
     Global_IS.*=SHARDDB
     Package_IRIS.Federated=SHARDDB
     

     

   • ノード 1 で、[Namespaces] セクションも見つけます。ここには、マスタ・ネームスペースの後に、その既定のグローバル・データベースとしてマスタ・データベースが表示されます。例えば、以下では、マスタ・データベース MASTERDB が、MASTERNAMESPACE の既定のグローバル・データベースとして表示されています。

     [Namespaces]
     %SYS=IRISSYS
     CLUSTERNAMESPACE=SHARDDB
     MASTERNAMESPACE=MASTERDB
     USER=USER
     

     

7. オプションで、想定される 2 番目のフェイルオーバー・メンバと DR 非同期ミラー・メンバ (該当する場合) を以降のステップで準備する間、現在のメンテナンス時間枠を終了してアプリケーションのアクティビティを許可します。

8. 2 番目のフェイルオーバー・メンバまたは DR 非同期としてクラスタに追加する各ノードで、以下を実行します。

   1. ISCAgent を起動します。

   2. 目的の最初のフェイルオーバー・メンバ (前述の例では、CLUSTERNAMESPACE) 上のクラスタ・ネームスペースと同じ名前でネームスペースを作成し、その既定のグローバル・データベースとして、最初のフェイルオーバー・メンバ (例では、SHARDDB) 上のシャード・データベースと同じ名前でローカル・データベースを構成します。

   3. ノード 1 に追加する目的の 2 番目のフェイルオーバー・メンバまたは DR 非同期でも、目的の最初のフェイルオーバー・メンバ上のマスタ・ネームスペースと同じ名前でネームスペースを作成し、その既定のグローバル・データベースとして、マスタ・データベースと同じ名前でローカル・データベースを構成します。前述の例を使用すると、既定のグローバル・データベースとして MASTERDB という名前のデータベースを持つ MASTERNAMESPACE ネームスペースを作成することになります。

9. メンテナンス時間枠内ではない場合は、新しいメンテナンス時間枠を開始します。

10. 新しいノードそれぞれで、データが含まれるミラーリングされたデータベースを含む既存のミラーの 2 番目のフェイルオーバー・メンバまたは DR 非同期メンバとして、ミラーリングされていないインスタンスを追加するために必要なタスクを実行します。

    • 対象のミラーの 2 番目のフェイルオーバー・メンバとしてノードを構成するか、または (2 番目のフェイルオーバー・メンバの構成後に) ノードを DR 非同期メンバとして構成します。

    • 新しく構成したメンバ上で、最初のフェイルオーバー・メンバ上に作成したバックアップからシャード・データベースをリストアします。ノード 1 ミラー (2 番目のフェイルオーバーまたは DR 非同期) の新しく構成したメンバ上で、ノード 1 の最初のフェイルオーバー・メンバ上に作成したバックアップからマスタ・データベースもリストアします。

    • マスタ・データベースとクラスタ・データベースを有効化してキャッチアップします (オンライン・バックアップを使用してバックアップを作成した場合は必要ありません)。

    Note:

    シャーディングによって自動的に、クラスタ・ネームスペース定義が更新され、必要なすべてのマッピング、ECP サーバ定義、およびリモート・データベース定義が作成され、マスタ・ネームスペース内のユーザ定義マッピングがシャードに伝播されます。したがって、このプロセスで手動で作成する必要があるマッピングは、マスタ・ネームスペース内のユーザ定義マッピングだけです。このマッピングは、ノード 1 の 2 番目のフェイルオーバー・メンバ上のマスタ・ネームスペース内にのみ作成する必要があります。ECP サーバ定義とリモート・データベース定義は手動でコピーする必要はありません。

11. いずれかのプライマリ (元のデータ・ノード) のインスタンスに対して InterSystems ターミナルを開き、以下のように、クラスタ・ネームスペース (またはノード 1 のマスタ・ネームスペース) で $SYSTEM.Sharding.VerifyShards()Opens in a new tab メソッドを呼び出します ("%SYSTEM.Sharding API" を参照)。

    set status = $SYSTEM.Sharding.VerifyShards()
    

    

    この呼び出しにより、ミラーの 2 番目のフェイルオーバー・メンバについての必要な情報がシャーディング・メタデータに自動的に追加されます。

    Note:

    この呼び出しを実行する場合、元のすべてのクラスタ・ノードがそのミラーの現在のプライマリである必要があります。したがって、2 番目のフェイルオーバー・メンバの追加後にミラーがフェイルオーバーした場合は、このステップを実行する前に、元のフェイルオーバー・メンバへの計画的フェイルバックを準備する必要があります (計画的フェイルオーバーの手順は、"プライマリ・フェイルオーバー・メンバのメンテナンス" を参照してください。iris stop コマンドを使用して、その手順で参照されている適切なシャットダウンを行う方法は、"InterSystems IRIS インスタンスの制御" を参照してください)。

ここで説明されている API または管理ポータルによる手順以外の方法 (つまり、管理ポータルのミラーリングのページ、^MIRROR ルーチン、または SYS.MIRROR API) を使用して、ミラーリングされたクラスタ内の 1 つ以上のデータ・ノードのミラー構成を変更する場合は、クラスタのメタデータを更新する必要があります。そのためには、クラスタ・ネームスペース内で $SYSTEM.Sharding.VerifyShards()Opens in a new tab を呼び出すか ("%SYSTEM.Sharding API" を参照)、またはクラスタ内の現在のプライマリ・フェイルオーバー・メンバ上で管理ポータルの [ノードレベルの構成] ページの [シャードを検証] ボタンを使用します ("管理ポータルを使用したミラーリングされたクラスタの構成" を参照)。例えば、計画的フェイルオーバーを実行する場合は、DR 非同期を追加するか、バックアップ・メンバを DR 非同期に降格させるか、または DR 非同期をフェイルオーバー・メンバに昇格させて、シャードによってメタデータが更新されて変更が反映されることを検証します。データ・ノード・ミラーに DR 非同期を含めることによって設定した災害復旧機能を維持・活用するうえで、クラスタ・メタデータを更新することは重要な要素です。詳細は、"ミラーリングされたシャード・クラスタの災害復旧" を参照してください。

クラスタのシャードは、ミラーリング構成操作のたびに検証することも、一連の操作の完了後に一度だけ検証することもできますが、クラスタのオンライン中に操作を実行した場合は、フェイルオーバー・メンバを追加または削除する操作の実行後すぐにシャードを検証することをお勧めします。

クラスタに計算ノードを追加すると、データ・ノード間で計算ノードを自動的に分散するため、計算ノードは、前に関連付けられていた計算ノード数が最小だったデータ・ノードに割り当てられます。この手順は、クラスタをミラーリングするかどうかに関係なく同じです。

ブラウザで管理ポータルを開く方法の詳細は、コンテナに導入されたインスタンスの手順、またはキットからインストールしたインスタンスの手順を参照してください。

ネットワーク・システム上のインスタンスを計算ノードとしてクラスタに追加するには、以下の手順を使用します。

1. インスタンスの管理ポータルを開き、[システム管理]→[構成]→[システム構成]→ [シャーディング]→[シャード有効] の順に選択し、表示されるダイアログで [OK] をクリックします (既定値はほぼすべてのクラスタに適しているため、[ECP 接続の最大数] 設定の値を変更する必要はありません)。

2. インスタンスを再起動します (管理ポータルが表示されているブラウザのウィンドウやタブを閉じる必要はありません。インスタンスが完全に再起動した後に再読み込みするだけでかまいません)。

3. [ノードレベルの構成] ページ ([システム管理]→[構成]→[システム構成]→[シャーディング]→[ノードレベルの構成]) に移動して、[構成] ボタンをクリックします。

4. [ノードレベルクラスタの構成] ダイアログで [このインスタンスを既存のシャードクラスタに追加] を選択し、表示されるプロンプトに次のように応答します。

   • クラスタ URL を入力します。この URL は、既にクラスタに属しているインスタンスの [ノードレベルの構成] ページの [シャード] タブに、すべてのノードに対して表示されるアドレスです。"残りのデータ・ノードの構成" を参照してください。

     Note:

     クラスタがミラーリングされている場合は、プライマリ・データ・ノードまたは計算ノードのアドレスを入力します。バックアップ・データ・ノードのアドレスではありません。

   • [ロール] プロンプトで [計算] を選択して、インスタンスをデータ・ノードとして構成します。

   • 場合によっては、InterSystems IRIS に認識されているホスト名が適切なアドレスに解決されないことや、ホスト名が利用できないことがあります。このような理由または他の理由で、代わりに IP アドレスを使用して他のクラスタ・ノードをこのノードと通信させたい場合は、ホスト名のオーバーライドのプロンプトで IP アドレスを入力します。

   • [ミラー化クラスタ] チェック・ボックスは利用できません。計算ノードの構成はミラーリングに関係なく同じであるためです (ただし、前述のようにクラスタ URL が指定されている場合を除きます)。

5. [OK] をクリックして [ノードレベルの構成] ページに戻ります。2 つのタブ [シャード] と [シャードテーブル] が表示されています。これまでに構成したデータ・ノードと計算ノードが [シャード] にノード 1 から表示され、各計算ノードがどのデータ・ノードに割り当てられているかを示します。

   [シャードを検証] をクリックして、計算ノードが正しく構成されていて、他のノードと通信できることを検証します。

   Note:

   構成する計算ノードが多数ある場合は、[詳細設定] ボタンをクリックし、[詳細設定] ダイアログで [割り当て時に自動的にシャードを検証] を選択することにより、検証操作を自動化できます(シャード・クラスタを導入する際は、このダイアログのその他の設定は既定値のままにします)。

ネットワーク・システム上のインスタンスをクラスタに計算ノードとして追加するには、そのインスタンスの InterSystems ターミナルを開き、既存のクラスタ・ノードのホスト名とその InterSystems IRIS インスタンスのスーパーサーバ・ポートを指定して $SYSTEM.Cluster.AttachAsComputeNode()Opens in a new tab メソッドを呼び出します。以下に例を示します。

set status = $SYSTEM.Cluster.AttachAsComputeNode("IRIS://datanode2:1972")

Note:

これらの手順で詳述されている各 API 呼び出しの戻り値 (成功の場合は 1 など) を確認するには、以下を入力します。

zw status

呼び出しが成功しなかった場合、以下を入力することにより、わかりやすいエラー・メッセージが表示されます。

do $SYSTEM.Status.DisplayError(status) 

テンプレート・ノードの構成時にこの IP アドレスを指定した場合 ("ノード 1 の構成" を参照) は、ホスト名ではなく、その IP アドレスを使用します。

set status = $SYSTEM.Cluster.AttachAsComputeNode("IRIS://100.00.0.01:1972")

他のノードに、IP アドレスを使用してこのノードと通信させる場合は、2 番目の引数として IP アドレスを指定します。

最初の引数で指定したクラスタ・ノードがデータ・ノードの場合、これがテンプレートとして使用されます。計算ノードの場合は、これが割り当てられているデータ・ノードがテンプレートとして使用されます。AttachAsComputeNode() 呼び出しは、以下を実行します。

• ECP およびシャーディング・サービスを有効にします。

• データ・ノード間で計算ノードを自動的に分散するため、新しい計算ノードを、前に関連付けられた計算ノード数が最小だったデータ・ノードに関連付けます。

• クラスタ・ネームスペースを作成し、"ノード 1 の構成" で説明したとおり、それをテンプレート・ノード (最初の引数で指定) の設定に合わせて構成し、必要なすべてのマッピングを作成します。

• すべての SQL 構成オプションを、テンプレート・ノードに合わせて設定します。

クラスタ・ネームスペースと同じ名前のネームスペースが新しい計算ノードに既に存在する場合は、そのネームスペースがクラスタ・ネームスペースとして使用され、マッピングのみが複製されます。

他のクラスタ・ノードに、ホスト名ではなく IP アドレスを使用してこのノードと通信させる場合は、2 番目の引数として IP アドレスを指定します。

AttachAsComputeNode() 呼び出しは、InterSystems IRIS インスタンスが既にシャード・クラスタのノードである場合、エラーを返します。

すべての計算ノードを構成したら、$SYSTEM.Cluster.ListNodes()Opens in a new tab メソッドを呼び出してこれらをリストできます。以下に例を示します。

set status = $system.Cluster.ListNodes()
NodeId  NodeType    DataNodeId    Host          Port
1       Data                      datanode1     1972
2       Data                      datanode2     1972
3       Data                      datanode3     1972
1001    Compute     1             computenode1  1972
1002    Compute     2             computenode2  1972
1003    Compute     3             computenode3  1972

計算ノードが導入されると、このリストに各計算ノードが割り当てられるデータ・ノードのノード ID が示されます。$SYSTEM.Cluster.GetMetadata()Opens in a new tab を使用して、クラスタおよびマスタ・ネームスペースの名前、それらの既定のグローバル・データベース、および呼び出しを発行するノードの設定を含む、クラスタのメタデータを取得することもできます。