構成マージを使用した InterSystems IRIS の自動構成

構成マージとは

構成マージ機能により、InterSystems IRIS® インスタンスの構成に対して、1 回の操作で任意の数の変更を加えることができます。 これを使用するには、導入時または後の任意の時点で、宣言型の構成マージ・ファイルに加える変更を記録し、そのファイルをインスタンスに適用するだけです。簡単に使用できる構成マージにより、同じコンテナ・イメージまたはキットからさまざまな構成の複数のインスタンスを自動的に導入でき、同時に複数のインスタンスを再構成し、自動化されたクラスタの再構成またはその他の複数インスタンスの導入を可能にします。構成マージは、サポートされている任意の UNIX®、または Linux プラットフォーム (Linux クラウド・ノードを含む) 上の、コンテナ化された、あるいはローカルにインストールされた、任意の InterSystems IRIS インスタンスで使用できます。

コンテナの導入に使用される構成マージ・ファイルの例は、"自動導入での有用なパラメータ" を参照してください。"構成パラメータ・ファイル・リファレンスOpens in a new tab" には、すべての InterSystems IRIS 構成パラメータの包括的な説明が含まれています。

InterSystems IRIS を構成する方法

InterSystems IRIS インスタンスの構成は、インストール・ディレクトリにある、名前と値のペアの構成パラメータを含む、iris.cpf という名前のファイルで指定されます。導入後に初めて起動する場合も含め、インスタンスは、起動するたびにこの構成パラメータ・ファイル (CPF) を読み取って設定値を取得します。このため、CPF を変更してインスタンスを再起動すれば、いつでもインスタンスを再構成できます。

例えば、CPF の [config] セクションにある globalsOpens in a new tab 設定は、インスタンスのデータベース・キャッシュのサイズを指定します。新たにインストールされたインスタンスの CPF の設定では、初期キャッシュ・サイズは合計システム・メモリの 25% に指定されています。これは、実稼働環境での使用を対象としていません。データベース・キャッシュのサイズを変更するには、インスタンスの CPF を任意のテキスト・エディタで開き、目的のキャッシュ・サイズを globals の値として指定してインスタンスを再起動します。ほとんどのパラメータは他の方法でも変更できます。例えば、globals の値は、管理ポータルを使用Opens in a new tabするか、永続クラス Config.configOpens in a new tab のメソッドを使用して変更できます。ただし、1 つのインスタンスに 1 回の操作で複数の構成変更を加える場合、および複数のインスタンスの同時構成を自動化する場合、これを実行できる一般的な方法はインスタンスの CPF を更新する方法だけです。

CPF の使用と内容については、"構成パラメータ・ファイル・リファレンスOpens in a new tab" を参照してください。

構成マージの仕組み

構成マージ・ファイルは、必要な InterSystems IRIS 構成パラメータおよび値のサブセットを含む部分的な CPF です。構成マージでマージ・ファイルがインスタンスに適用されると、CPF を手動で編集して値を変更しているかのように、これらの設定がインスタンスの CPF にマージされ、値が置き換えられます。元の CPF に存在しないパラメータがマージ・ファイルにある場合、そのパラメータは適切な場所に追加されます。

例えば、シャード・クラスタOpens in a new tab内のデータ・ノードと計算ノードは通常、他の目的のために構成されたデータベース・キャッシュよりもはるかに大きいデータベース・キャッシュを必要とし、共有メモリもより多く構成されます。導入時に大きなデータベース・キャッシュと多くの共有メモリを持つようにインスタンスを構成するには、あるいは既存のインスタンスをこのように再構成するには、globals パラメータ (データベース・キャッシュのサイズを指定) と gmheapOpens in a new tab パラメータ (共有メモリの容量を指定) に目的の値を指定した構成マージ・ファイルを適用します。インスタンスの CPF 内の既定値がこれらの値で置換されます。以下に、インスタンスの導入時に、マージ・ファイルを使用してこれらのパラメータを更新する方法について説明します。

構成マージで、構成以上のカスタマイズは可能か

構成パラメータの値の変更に加え、構成マージによって、多種多様な InterSystems IRIS オブジェクト (ネームスペースおよびデータベース、ユーザ、ロール、リソースなど) や、ミラーおよびミラー・メンバを作成、変更、削除できます。これは、[Actions]Opens in a new tab セクションにあるパラメータを使用して実行します。このセクションは、マージ・ファイル内でのみ有効で、インスタンスの CPF には表示されません (追加することもできません)。例えば、インスタンスにグローバル・マッピングを追加するには、マージ・ファイルに CreateMapGlobal パラメータを含む [Actions] セクションを含めます。システム・オブジェクトを作成、変更、削除するこのセクションのパラメータは、更新パラメータと呼ばれるパラメータ値を更新するパラメータと区別するために、アクション・パラメータと呼ばれることがあります。

アクション・パラメータを使用して、新しいインスタンスと既存のインスタンスの両方でオブジェクトを管理できます。アクション・パラメータで指定された操作はベキ等であり、変更が加えられる場合にのみ実行されます。具体的には、以下のとおりです。

• 指定したオブジェクトが存在する場合、作成アクションは実行されません。

• 指定したオブジェクトが存在しない場合、変更アクションは実行されません。(オブジェクトは存在するが、アクションがそのオブジェクトのプロパティに追加されない/そのプロパティを変更しない場合、アクションは実行されますが効果はありません。)

• 指定したオブジェクトが存在しない場合、削除アクションは実行されません。

• オブジェクトが存在し、かつアクションがそのオブジェクトのプロパティに追加されない/そのプロパティを変更しない場合、構成アクションは実行されません。オブジェクトが存在しない場合、またはオブジェクトが存在し、アクションがプロパティに追加される/そのプロパティを変更する場合、アクションは実行されます。

アクションのパラメータは導入時に非常に有用です。例えば、ConfigMirror アクションと、CreateDatabase アクションの MirrorSetName および MirrorDBName プロパティを使用して、導入された複数のインスタンスをミラーとして構成し、導入後すぐに、ミラーリングされたデータベースを配置して、新しいミラーを完全に機能させることができます。一方、iris merge コマンドを使用した既存のインスタンスの再構成では、アクション・パラメータにより、直ちに変更を加えることができます。このパラメータを使用しない場合は、管理ポータルでの手順またはクラス・メソッドの呼び出しが必要になります。主な例としては、ModifyDatabase アクションの MirrorSetName および MirrorDBName プロパティを使用し (実行中のプライマリ・インスタンスで行う必要があります)、既存のミラーに新しいデータベースを追加することで、既存のミラーにアービターを追加するなどが挙げられます。

アクション・パラメータによって実行される操作は、Config および Security クラスと、SYS.DatabaseOpens in a new tab および %SYSTEM.SQL.SecurityOpens in a new tab クラスのクラスのメソッド、および 2 つの SQL コマンドを呼び出すことで制御されます。

アクション・パラメータの使用例は、"自動導入での有用なパラメータ" を参照してください。

管理されるオブジェクト別、対応するクラス別、処理順、および名前別のアクション・パラメータのリストは、[Actions] パラメータ・リファレンスを参照してください。

構成マージの使用法

構成マージの主な用途としては、以下の 2 つがあります。

• 導入時の複数インスタンス・トポロジとスタンドアロン・インスタンスの構成

• 導入された複数インスタンス・トポロジとスタンドアロン・インスタンスの再構成

構成マージ機能のアプリケーションに関係なく、関係するマージ・ファイルをバージョン管理下に置き、インスタンスまたは複数インスタンス・トポロジの導入以降の継続期間を通して、すべての構成変更のレコードを提供することをお勧めします。

自動導入または再構成プロセスに構成マージを組み込むと、適用するマージ・ファイルを更新するだけでそのプロセスを更新できます。開発やテストなどの目的で使用される個々のインスタンスにおいても、ユーザはインスタンスの導入または再構成の前に適切なマージ・ファイルの最新バージョンを取得し、その構成を一元的な仕様に確実に一致させる必要がある場合があります。バージョン管理により、以前のバージョンのマージ・ファイルを選択して、古い構成に戻すこともできます。

導入での構成マージの使用法

導入時に構成マージ・ファイルを適用することにより、導入したインスタンスを初めて開始する前に、その既定の構成を変更できます。これにより、同じイメージからさまざまな構成でコンテナを導入したり、同じキットから構成の異なるインスタンスを直接複数インスタンス・トポロジにインストールすることができ、導入後に目的のトポロジにインスタンスを構成する必要はありません。例えば、計算ノードを含むシャード・クラスタOpens in a new tabのコンテナ化された自動導入では、次の図に示すように、データ・ノード 1、残りのデータ・ノード、および計算ノードに、この順序で異なるマージ・ファイルを適用することができます。すべてのインスタンスが起動および実行されると、シャード・クラスタも起動され、実行されます。

同様に、ミラーOpens in a new tabを導入する場合、プライマリ、バックアップ、および非同期メンバに対して異なる構成マージ・ファイルを適用できます。ミラーリングされたシャード・クラスタでも、このアプローチを使用して簡単に導入できます。

構成マージを有効にするには、導入時に、環境変数 ISC_CPF_MERGE_FILE、または InterSystems IRIS の自動化された導入ツール、InterSystems Cloud Manager (ICM) または InterSystems Kubernetes Operator (IKO) のいずれかのこの目的に使用されるフィールドによってマージ・ファイルの場所を指定するだけです。例えば、手動またはスクリプト化された導入で、以下のように指定します。

ISC_CPF_MERGE_FILE=/home/user/mergefiles/cmf_090821.cpf

マージ・ファイルを指定する具体的な方法は、使用する導入メカニズムと、インスタンスがコンテナ化されているかどうかによって異なります。

• InterSystems IRIS コンテナの導入

• キットからの InterSystems IRIS のインストール

• InterSystems Cloud Manager を使用した導入

• InterSystems Kubernetes Operator を使用した導入

構成マージを使用して既存のインスタンスを再構成する方法

実行している複数のインスタンスに対する同じマージ・ファイルの適用を自動化することによって、これらのインスタンスすべてを同時に同じ方法で再構成でき、アプリケーションまたはクラスタ全体にわたって同じ一連の構成変更を適用できます。インスタンスごとにカスタマイズされている可能性があるため変更すべきではない設定がある場合は、それらの設定を更新しないようにすることができます。その場合、該当する設定をマージ・ファイルから除外し、変更しても安全で、変更することが望ましいとわかっている設定のみを含めます。前のセクションで説明したとおり、自動化された 1 つのプログラムを使用して、インスタンスのグループごとに (異なるミラー・メンバやクラスタ・ノード・タイプなど) 異なるマージ・ファイルを提供することもできます。

マージ・ファイルを使用したすべての構成変更の適用は、変更のプロセスを合理化するのに役立ち、インスタンスの構成に対する高度な制御を維持できます。ターミナルからの多くの個別の変更を、管理ポータルの複数のページで、またはインスタンスの CPF を手動で編集することによって行うのではなく、マージ・ファイル内の同一の構文を使用して、一度にすべての変更を実行することができます。マージ・ファイルをバージョン管理下に置くことで、構成履歴や以前の構成のリストアのオプションを確実に利用できます。

iris merge コマンドは、マージ・ファイルを実行しているインスタンスに適用します。以下のように実行されます。

iris merge instance [merge-file] [target-CPF]

説明 ：

• instance は、InterSystems IRIS インスタンスの名前です。

• merge-file は、ファイル名を含む、マージ・ファイルのパスです。merge-file が指定されていない場合は、ISC_CPF_MERGE_FILE 環境変数の値が使用されます (設定されている場合)。

• target-CPF は、instance インスタンスのアクティブな CPF の場所で、iris.cpf という名前であると見なされます。target-CPF が指定されていない場合、既定では以下のとおりです。

  • コンテナ化されていないインスタンスの場合、ISC_PACKAGE_INSTALLDIR 環境変数 (設定されている場合) で指定されたディレクトリにある iris.cpf ファイル。ほとんどの既存のインスタンスでは、この変数は設定されていないため、対象の CPF の場所を明示的に指定する必要があります。

  • コンテナ化されたインスタンスの場合、ISC_DATA_DIRECTORY 環境変数で指定されたディレクトリにある iris.cpf ファイル。この変数が設定されていない (永続的な %SYS が使用されていないため) 場合は、ISC_PACKAGE_INSTALLDIR 環境変数 (この変数は常に InterSystems IRIS コンテナに設定されています)。

以下の場合、マージは実行されません。

• 指定したマージ・ファイルが存在しない場合、または merge-file 引数が省略され、ISC_CPF_MERGE_FILE が存在しない場合。

• 指定した対象の場所に CPF がない場合、または対象の場所が指定されておらず、ISC_DATA_DIRECTORY も ISC_PACKAGE_INSTALLDIR も存在しない場合。

終了コード 3 は、マージが成功したことを示します。

CPF にマージされる一部の変更はすぐには適用されず、再起動が必要です。例えば、インスタンスの共有メモリ・ヒープのサイズを指定する gmheapOpens in a new tab パラメータの値の変更は、そのインスタンスが再起動されるまで適用されません。マージ・ファイルにそのようなパラメータが 1 つ以上含まれる場合、次のサンプル・スクリプトの抜粋のように、再起動の一部としてマージ・ファイルを適用する必要が生じることがあります。

# restart instance with  the necessary parameters (all on one line)
sudo ISC_CPF_MERGE_FILE=/net/merge_files/config_merge.cpf iris stop IRIS restart

一方、iris merge コマンドを使用してマージ・ファイルを適用すると、再起動しなくても設定 (インスタンスの起動時に設定できないものを含む) をすぐに変更できます。"構成マージで、構成以上のカスタマイズは可能か" に記載している例では、既存のミラーにデータベースを追加しています。

構成変更の管理

導入において、または既存のインスタンスで、iris merge コマンドにより、または再起動時に構成マージを使用することに加え、管理ポータル、Config.* クラス、またはテキスト・エディタを使用してインスタンスの CPF を変更することができます。これらの方法は通常、複数のインスタンスを再構成する場合ではなく、必要に応じて個々のインスタンスの設定を個別に変更する場合に使用します。複数のインスタンスを自動的に導入したり再構成する場合、推奨されるベスト・プラクティスは、すべての構成の変更をこの方法に限定することです。これは、例えば iris merge マージを使用して 1 つのインスタンスの 1 ～ 2 個のパラメータのみを変更するような場合にも当てはまります。そのようにして、使用するマージ・ファイルのバージョンを管理して保存することで、各インスタンスの構成のレコードを時系列的に維持できると共に、構成マージ以外の方法で加えた変更を構成マージで上書きしてしまう可能性を回避できます。

コンテナでは、ISC_CPF_MERGE_FILE 変数によって指定されたマージ・ファイルの継続的な監視およびマージにより、後者の可能性が非常に大きくなります (前のセクションの説明を参照)。これにより、構成マージとマージ・ファイルの一元管理リポジトリを使用すると、マージ・ファイルを更新するだけで、いつでも既存のインスタンスにさらに変更を適用することができます。ただし、マージ・ファイルに含まれる構成パラメータが導入時以降にコンテナ内のインスタンス上で別の方法で変更されている場合、更新マージによってこれらの変更が消去されてしまい、変更のレコードがまったく残らない可能性があります。すべての構成変更を構成マージに限定することで、これを回避できます (マージ・ファイルが存在しない場合は、起動時にエラー・メッセージが表示され、続行されます)。

変更を構成マージに限定しない場合、インスタンスの起動後に、以下のスクリプトのどちらかまたは両方を (例えば iris-main --afterOpens in a new tab オプションを使用して) 自動化に含めることで、構成マージで不要な変更が行われる可能性を回避できます。

• 導入済みの各コンテナ内の ISC_CPF_MERGE_FILE 環境変数を削除する。(マージ・ファイルが存在しない場合は、起動時にエラー・メッセージが表示され、続行されます。)

• 各コンテナ内のマージ・ファイルを空のファイルで置き換える。

自動導入での有用なパラメータ

構成マージ機能を使用して、インスタンスの CPF 内にある設定を任意の組み合わせで更新し、[Actions] セクションで指定されているとおりにインスタンス上で特定の操作を実行することができます。いくつかの自動導入のユース・ケースは有用で、構成マージ機能と関連するパラメータの高度な性能を示す良い例となっています。このセクションでは、以下のようなこれらのユース・ケースについて説明します。

更新パラメータ

• 既定のパスワードの変更

• メモリの構成と割り当て

• SQL および SQL シェル・オプションの構成と SQL データ型のマッピング

• 更新パラメータの例

アクション・パラメータ

• セキュリティ・オブジェクトの作成、変更、削除

• データベース・オブジェクトの作成、変更、削除

• 分散キャッシュ・クラスタの導入

• クラスタのデータ・サーバのミラーリング

更新パラメータ

以降のセクションで説明するパラメータは、導入されたインスタンスを起動する前に、インスタンスの CPF の値を変更して、導入ソース (インストール・キットまたはコンテナ) の既定の CPF を更新するために使用するパラメータです。以下の各パラメータ名は、"構成パラメータ・ファイル・リファレンスOpens in a new tab" 内のリストにリンクされているため、パラメータの目的とその使用法の詳細を容易に参照できます。

既定のパスワードの変更

"コンテナ内でのインターシステムズ製品の実行" の "認証とパスワードOpens in a new tab" で説明しているように、[Startup] セクションの PasswordHash 設定を使用して、導入時にインスタンスの事前定義アカウントの既定のパスワードをカスタマイズすることができます。そうすることで、SYS の既定のパスワードを有効なままにしておくことに伴う重大なセキュリティ・リスクを排除できます(各事前定義アカウントのパスワードは、導入後に個別に変更する必要があります)。

Password パラメータ

[Startup] パラメータ	指定する内容
PasswordHashOpens in a new tab	値の暗号化ハッシュとそのソルトに基づく、事前定義のユーザ・アカウントの既定のパスワード

Note:

[Actions]/CreateUser パラメータは、パラメータと同等の PasswordHash 引数も取ります ("[Actions] パラメータ・リファレンス" を参照)。

メモリの構成と割り当て

InterSystems IRIS インスタンスのメモリ使用率に影響するパラメータは多数あり、その最適な値は使用可能な物理メモリ、クラスタ内でのインスタンスのロール、関連するワークロード、およびパフォーマンスの要件によって異なります。

例えば、インスタンスのデータベース・キャッシュの最適なサイズ (globals パラメータを使用して指定可能) は、インスタンスのロールによって大きく異なる可能性があります。前述のように、通常、シャード・クラスタのデータ・ノードには比較的大きなキャッシュが必要です。しかしそのロール内であっても、最適なサイズはクラスタのシャード・データ・セットのサイズによって異なり、さらに実装されるサイズはリソースの制約のために最適な値よりも小さくなる可能性があります (詳細は、"スケーラビリティ・ガイド" の "InterSystems IRIS シャード・クラスタの計画Opens in a new tab" を参照してください)。また、データベース・キャッシュのサイズ設定は通常慎重に行う必要があるため、既定のデータベース・キャッシュ設定 (コンテナで提供される iris.cpf ファイル内の globals の値) は、インスタンスのロールに関係なく、意図的に実稼働環境に適さないものになっています。

以下の表に、CPF の [Config] セクション内にある、導入の一環として更新できるメモリ使用率のいくつかの設定を示します。

メモリ・パラメータ

[Config] パラメータ	指定する内容
bbsizOpens in a new tab	プロセスあたりのプロセス・プライベート・メモリの最大値
globals	データベース・キャッシュに割り当てられる共有メモリ (共有メモリ・ヒープからではない)
routinesOpens in a new tab	ルーチン・キャッシュに割り当てられる共有メモリ (共有メモリ・ヒープからではない)
gmheapOpens in a new tab	共有メモリ・ヒープとして構成される共有メモリ
jrnbufsOpens in a new tab	共有メモリ・ヒープからジャーナル・バッファに割り当てられる共有メモリ
locksizOpens in a new tab	共有メモリ・ヒープからロックに割り当てられる共有メモリの最大値

これらのパラメータおよびメモリ関連のその他のパラメータの詳細は、"システム・リソースの計画と管理Opens in a new tab"、"メモリと開始設定Opens in a new tab"、"ジャーナル設定の構成Opens in a new tab"、および "ロックの監視Opens in a new tab" を参照してください。

SQL および SQL シェル・オプションの構成と SQL データ型のマッピング

CPF の [SQL]Opens in a new tab セクションにあるパラメータを 1 つ以上マージすることによって、導入するインスタンスの SQL および SQL シェルの設定を指定できます。管理ポータルの [SQL] ページ ([システム管理]→[構成]→[SQL とオブジェクトの設定]→[SQL]) で、これらの設定を確認および変更できます。CPF の [SqlSysDatatypes]Opens in a new tab および [SqlUserDatatypes]Opens in a new tab セクションを使用して、SQL システム・データ型と SQL ユーザ・データ型を、導入されたインスタンス上で InterSystems SQL の同等のデータ型にマッピングできます。SQL シェルの設定およびデータ型マッピングの詳細は、それぞれ "SQL シェルの構成" と "データ型 (SQL)Opens in a new tab" を参照してください。

更新パラメータの例

以下のサンプル CPF マージ・ファイルには、前のセクションで説明したいくつかの更新パラメータが含まれています。SystemMode パラメータは、管理ポータルの上部に表示されるラベルを指定します。

[Startup]
SystemMode=TEST
PasswordHash=FBFE8593AEFA510C27FD184738D6E865A441DE98,u4ocm4qh

[config]
bbsiz=-1
globals=0,0,900,0,0,0
routines=64
gmheap=256000
jrnbufs=96
locksiz=1179648

[SQL]
DefaultSchema=user
TimePrecision=6

[SqlSysDatatypes]
TIMESTAMP=%Library.PosixTime

セキュリティ・オブジェクトの作成、変更、削除

導入または再構成の一環として、セキュリティ・オブジェクトを作成および変更するには、以下の表で説明する操作を [Actions] セクションに含めます。

セキュリティ・オブジェクト作成パラメータのサンプル

[Actions] パラメータ	指定する内容
CreateUser	作成するユーザ・アカウントの名前とプロパティ。ModifyUser および DeleteUser も使用できます。
CreateRole	作成するロールの名前とプロパティ。ModifyUser および DeleteUser も使用できます。
CreateResource	作成するリソースの名前とプロパティ。ModifyUser および DeleteUser も使用できます。
GrantAdminPrivilege、GrantPrivilege	SQL 特権と SQL 管理特権を付与するユーザ・アカウント、付与する特権、およびそれらを付与するネームスペース。RevokeAdminPrivlege および RevokePrivilege も使用できます。
ModifyService	有効または無効にするサービス。
CreateApplication	作成するアプリケーションの名前とプロパティ。ModifyApplication および DeleteApplication も使用できます。
CreateSSLConfig	作成する TLS/SSL 構成の名前、場所、およびプロパティ。ModifySSLConfig および DeleteSSLConfig も使用できます。
CreateLDAPConfig	作成する LDAP 構成の名前とプロパティ。ModifyLDAPConfig および DeleteLDAPConfig も使用できます。
CreateEvent	作成するシステム監査イベントの名前、プロパティ、およびステータス。ModifyEvent および DeleteEvent も使用できます。

セキュリティ・オブジェクトでのアクション・パラメータの使用法を説明するために、導入されたインスタンスに、以下の SQL 管理者ユーザの事前定義アカウントを追加するとします。

• %Service_Bindings サービス (%SQL ロール) を介した SQL アクセスを持っている。

• USER データベースに対する読み取りまたは書き込みが可能 (%DB_USER ロール)。

• テーブル、ビュー、プロシージャ、関数、メソッド、クエリ、トリガを作成および削除でき (%DB_OBJECT_DEFINITION 特権)、USER ネームスペースで BUILD INDEX コマンドを使用できる (%BUILD_INDEX 特権)。

これを行うために、以下のように、CreateUser パラメータを使用してパスワードを持つユーザ・アカウントを作成して必要なロールを割り当て、GrantAdminPrivilege パラメータを使用してこれに必要な SQL 特権を付与できます。

[Actions]

CreateUser:Name=SQLAdmin,
  PasswordHash="cec6638a357e7586fddfb15c0e7dd5719a1964e774cd37466fb0c49c05,
  323cb89148c887166dd2be61c107710539af2c01b43f07dccc8d030ac2c1a8cf7c5ace4a00d57e3780f,10000,SHA512",
  Roles="%SQL,%DB_USER"

GrantAdminPrivilege:Grantee=SQLAdmin,Namespace=USER,AdminPriv="%DB_OBJECT_DEFINITION,%BUILD_INDEX"

これらのアクション・パラメータによって実行される操作と、そのプロパティの値の詳細は、"認証とパスワードOpens in a new tab"、"インターシステムズの承認についてOpens in a new tab"、および "SQL のユーザ、ロール、および特権Opens in a new tab" を参照してください。

データベース・オブジェクトの作成、変更、削除

導入または再構成の一環として、データベース (ローカルとリモートの両方)、ネームスペース、マッピングを作成するには、以下の表で説明する操作を [Actions] セクションに含めます。

データベースおよびネームスペースのアクションのパラメータのサンプル

[Actions] パラメータ	指定する内容
CreateDatabase	InterSystems IRIS に登録するデータベースの名前とプロパティ、および作成するデータベース・ファイルのホスト・ファイル・システム上の場所。ModifyDatabase および DeleteDatabase も使用できます。
CreateDatabaseFile	(データベースを InterSystems IRIS に登録せずに) 作成するデータベース・ファイルのホスト・ファイル・システム上の場所。ModifyDatabaseFile および DeleteDatabaseFile も使用できます。
CreateNamespace	InterSystems IRIS で作成するネームスペースの名前とプロパティ。ModifyNamespace および DeleteNamespace も使用できます。
ModifyNamespace	変更する既存の InterSystems IRIS ネームスペースの名前とそのプロパティ。CreateNamespace および DeleteNamespace も使用できます。
CreateMapGlobal	マッピングを作成するネームスペース、マッピングするグローバルの仕様、そのグローバルが存在するデータベース。ModifyMapGlobal および DeleteMapGlobal も使用できます。さらに、Create/Modify/DeleteMapRoutine および Create/Modify/DeleteMapPackage を使用して、ルーチンおよびパッケージのマッピングを作成、変更、削除できます。

データベース関連オブジェクトでのアクション・パラメータの使用法を説明するために、以下を行うとします。

• データベースとそのリソースを作成してから、既存のネームスペースを変更し、作成したデータベースをグローバル・データベースにして相互運用性を有効にします。

• 2 番目のデータベースとリソースを作成し、そのデータベースを既定のグローバル・データベースにして、相互運用対応ネームスペースを作成します。

以下の例は、マージ・ファイルでこれを行う方法を示しています。

[Actions]

CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Directory=/database-path/APPA
ModifyNamespace:Name=APPA,Globals=APPA,Interop=1

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Directory=/database-path/APPB
CreateNamespace:Name=APPB,Globals=APPB,Interop=1

後から、データベース APPA 内のグローバルおよびルーチンのネームスペース APPB へのマッピングを追加するとします。これは、マージ・ファイルで以下のように行うことができます。

[Actions]
CreateMapGlobal:Namespace=APPB,Name=global-spec,Database=APPA
CreateMapRoutine:Namespace=APPB,Name=routine-spec,Database=APPA

これらのアクション・パラメータによって実行される操作と、そのプロパティの値の詳細は、"ネームスペースの作成/変更Opens in a new tab"、"ローカル・データベースの作成Opens in a new tab"、および "ネームスペースへのグローバル、ルーチン、およびパッケージ・マッピングの追加Opens in a new tab" を参照してください。

分散キャッシュ・クラスタの導入 (ミラーリングなし)

前のセクションのマージ・ファイルの例に簡単な変更をいくつか加えることで、分散キャッシュ・クラスタを導入するためのマージ・ファイルを作成できます。

データ・サーバの導入

以下のマージ・ファイルを使用して、ミラーリングされていないデータ・サーバを導入します。このマージ・ファイルは、アプリケーション・データベースと関連するリソースおよびネームスペースの作成に加え、以下を行います。

• アクション・パラメータを使用して ECP サービスを有効にします。

• 更新パラメータを使用して、データ・サーバが受け入れることができる同時アプリケーション・サーバ接続の最大数を 16 に設定します。

前のサンプル・マージ・ファイルとの違いが強調表示されています。

# nonmirrored data server merge file

[Config]

MaxServerConn=16

[Actions]

ModifyService:Name=%service_ecp,Enabled=1

CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Directory=/database-path/APPA
CreateNamespace:Name=APPA,Globals=APPA

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Directory=/database-path/APPB
CreateNamespace:Name=APPB,Globals=APPB

アプリケーション・サーバの導入

すべてのアプリケーション・サーバの導入に使用されるこのマージ・ファイルは、以下を行います。

• 更新パラメータを使用して、データ・サーバをリモート・サーバとして追加します。

• Server および LogicalOnly プロパティを追加し、ローカル・データベースを作成するローカル・ディレクトリではなくリモート・サーバ上の既存のデータベースを指すように Directory プロパティを更新して、上述の CreateDatabase アクションを変更します。

前のセクションのサンプル・マージ・ファイルとの違いが強調表示されています。

# app servers merge file

[ECPServers]

dataAB=dataserver-address,port,0

[Actions]

CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Server=dataAB,Directory=/database-path-on-dataserver-dataAB/APPA,ResourceName=%DB_%APPA,
  LogicalOnly=1,
CreateNamespace:Name=APPDBA,Globals=APPA

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Server=dataAB,Directory=/database-path-on-dataserver-dataAB/APPB,ResourceName=%DB_%APPB,
  LogicalOnly=1
CreateNamespace:Name=APPB,Globals=APPB

これらのアクション・パラメータによって実行される操作と、そのプロパティの値の詳細は、"リモート・データベースOpens in a new tab" と "分散キャッシュ・クラスタの導入Opens in a new tab" を参照してください。

クラスタのデータ・サーバのミラーリング

1 つ以上の InterSystems IRIS ミラーを導入するには、異なるミラー・ロールに対して、それぞれに ConfigMirror アクション・パラメータを含む別個の構成マージ・ファイルを使用して、最初のフェイルオーバー・メンバ、2 番目のフェイルオーバー・メンバ、DR 非同期メンバの順に導入します (レポート非同期メンバは、導入後にミラーに追加できます)。

1 つのマージ・ファイルとホスト名のマッチングを使用して導入することもできます。これにより、名前が必要なパターンに一致する各ホスト・セットに、どのメンバを導入するかが決まります。

このセクションでは、各アプローチの例と、ConfigMirror パラメータのよく使用されるプロパティを示す表を提供します。

ミラー構成の詳細は、"ミラーリングのアーキテクチャおよび計画Opens in a new tab" と "ミラーの作成Opens in a new tab" を参照してください。コンテナ化されたミラーの導入を計画する前、またはコンテナ化された既存のインスタンスをミラーに再構成する前は、必ず "InterSystems IRIS コンテナを使用したミラーリングOpens in a new tab" を参照してください。特に、フェイルオーバー用のコンテナまたは DR 非同期ミラー・メンバを起動する場合は常に ISCAgent が起動することを確認する必要があります。

別個のマージ・ファイルを使用したミラーの導入

別個のマージ・ファイルを使用した導入を計画する際、他のメンバを追加する前に、ミラー・プライマリとして構成されるインスタンスが実行されている必要がある点に留意してください。このため、他のインスタンスを残りのメンバとして導入する前に、このインスタンスが導入され、正常に起動されていることを確認する必要があります。

データ・サーバのミラー・メンバの導入

以下のマージ・ファイルは、以下を行うことで、分散キャッシュ・クラスタのデータ・サーバを DR 非同期メンバを持つミラーとして導入します。

• ミラーを作成し、メンバを追加する ConfigMirror アクション・パラメータを含めます。

• プライマリで、作成したデータベースをミラーに追加します (他のメンバに自動的に追加されます)。

前のセクションの対応するマージ・ファイルとの違いが強調表示されています。

# mirrored data server primary merge file

[Config]
MaxServerConn=16

[Actions]

ModifyService:Name=%service_ecp,Enabled=1 

ConfigMirror:Name=CLUSTERAB,SSLDir=ssl-directory-path,
  Member=primary,Primary=localhost,ArbiterURL=address:port

CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Directory=/ddatabase-path/APPA,
  MirrorSetName=CLUSTERAB,MirrorDBName=APPA
CreateNamespace:Name=APPA,Globals=APPA

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Directory=/ddatabase-path/APPB,
  MirrorSetName=CLUSTERAB,MirrorDBName=APPB
CreateNamespace:Name=APPB,Globals=APPB

# mirrored data server backup/DR async merge file;
# for ConfigMirror Member property enter either =backup or =drasync as appropriate

[Config]
MaxServerConn=16

[Actions]

ModifyService:Name=%service_ecp,Enabled=1

ConfigMirror:Name=CLUSTERAB,SSLDir=ssl-directory-path,
  Member=backup|drasync,Primary=primary-address:,ArbiterURL=address:port

CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Directory=/ddatabase-path/APPA,
  MirrorSetName=CLUSTERAB,MirrorDBName=APPA
CreateNamespace:Name=APPA,Globals=APPA

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Directory=/ddatabase-path/APPB,
  MirrorSetName=CLUSTERAB,MirrorDBName=APPB
CreateNamespace:Name=APPB,Globals=APPB

ミラーリングされたデータ・サーバを持つアプリケーション・サーバの導入

このマージ・ファイルは、強調表示されているように、[ECPServers] のリモート・サーバ定義アクションの末尾の 0 を 1 に変更するだけで、上記のアプリケーション・サーバのマージ・ファイルを変更します。これは、リモート・サーバがミラーで、フェイルオーバー後にアプリケーション接続を透過的に新しいプライマリに切り替え可能であることを示します。

# app servers merge file

[ECPServers]

dataAB=dataserver-address,port,1

[Actions]

CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Directory=/database-path-on-dataserver-dataAB/APPA,ResourceName=%DB_%APPA,
  Server=dataAB,LogicalOnly=1
CreateNamespace:Name=APPDBA,Globals=APPA

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Directory=/database-path-on-dataserver-dataAB/APPB/,ResourceName=%DB_%APP,B
  Server=dataAB,LogicalOnly=1
CreateNamespace:Name=APPB,Globals=APPB

ホスト名マッチングを使用したミラーの導入

導入ホストの名前が -number (または正規表現 .*-[0-9]+$ として) で終了する場合 (iris-000、iris-001、iris-002 ... など)、または -number-number で終了する場合 (iris-0-0、iris-0-1、iris-1-0、iris-1-1 ... など)、1 つのマージ・ファイルから 1 つ以上のミラーを自動的に導入できます。そのためには、以下を行います。

• 必要なパターンに Map プロパティ (別個のマージ・ファイル・アプローチで使用されていない) を設定します (既定では primary,backup ですが、primary,backup,drasync,... のように最大 14 の DR 非同期メンバを含めることもできます)

• Member および Primary プロパティを auto に設定します。

例えば、以下の ConfigMirror アクション・パラメータを使用する場合、例の後の表に示すように、ミラー・メンバは適切な名前のホストに導入されます。

ConfigMirror:Name=AUTOMIRROR,SSLDir=ssl-directory-path,
  Map=”primary,backup,drasync”,
  Member=auto,Primary=auto,ArbiterURL=address:port

ホスト名によるミラーの導入

番号が 1 つのホスト名	番号が 2 つのホスト名	ミラー・メンバのロール
mirror-000	mirror-0-0	プライマリ
mirror-002	mirror-0-1	バックアップ
mirror-003	mirror-0–2	DR 非同期
mirror-005	mirror-1-0	プライマリ
mirror-006	mirror-1-1	バックアップ
mirror-007	mirror-1-2	DR 非同期

ホスト名によるミラー・メンバの導入

前のセクションで示したように 3 つのマージ・ファイルを使用するのではなく、iris-001、iris-002、iris-003 のような連続する名前の 3 つのホストに対して以下の単一のマージ・ファイルを使用して、前述のような ConfigMirror アクションを組み込み、ホスト名マッチングを使用して 3 メンバのミラーリングされたデータ・サーバを導入できます。

# mirrored data server using single merge file and hostname mapping

[Config]
MaxServerConn=16

[Actions]

ModifyService:Name=%service_ecp,Enabled=1
 
ConfigMirror:Name=CLUSTERAB,SSLDir=ssl-directory-path,
  Map=”primary,backup,drasync”,Member=auto,
  Primary=auto,ArbiterURL=address:port
CreateResource:Name=%DB_%APPA,Description="APPA database"
CreateDatabase:Name=APPA,Directory=/ddatabase-path/APPA,
  MirrorSetName=CLUSTERAB,MirrorDBName=APPA
CreateNamespace:Name=APPA,Globals=APPA

CreateResource:Name=%DB_%APPB,Description="APPB database"
CreateDatabase:Name=APPB,Directory=/ddatabase-path/APPB,
  MirrorSetName=CLUSTERAB,MirrorDBName=APPB
CreateNamespace:Name=APPB,Globals=APPB

ConfigMirror のプロパティ

以下の表に、よく使用される ConfigMirror アクション・パラメータのプロパティを示します。InterSystems IRIS の以前のリリースでは、これらの多くは CPF の [Startup] セクションのパラメータでした。そのため、表には、対応する以前の [Startup] パラメータの名前を示しています。

ConfigMirror のプロパティ

プロパティ	別個のマージ・ファイルを使用して導入	1 つのマージ・ファイルとホスト名マッピングを使用して導入
Name (以前は [Startup]/MirrorSetName)	新しいミラー (プライマリを導入する場合) または参加するミラー (バックアップまたは DR 非同期を導入する場合) の名前	ミラーの名前
Map	(使用されていません)	ミラー・メンバとホスト名とのマッチングに使用されるパターンを設定します。既定は Map="primary,backup" です。
Member (以前は [Startup]/MirrorMember)	導入時のミラー・メンバのロール (primary、backup、または drasync)	ミラー・メンバをホスト名に自動的にマッチングするには、auto に設定します。
Primary (以前は [Startup]/MirrorPrimary)	プライマリのホストの名前または IP アドレス	ミラー・メンバをホスト名に自動的にマッチングするには、auto に設定します。
SSLDir (以前は [Startup]/MirrorSSLDir)	インスタンスのミラー TLS/SSL 構成Opens in a new tabのホスト上の場所	(前の列を参照。TLS 構成はすべてのホスト上で同一に配置されている必要があります。)
ArbiterURL (以前は [Startup]/ArbiterURL)	ミラー (プライマリの導入時) または既存のプライマリ (バックアップまたは DR 非同期の導入時) に構成するアービターのホスト (ホスト名または IP アドレス) とポート	ミラーに構成するアービターのホスト (ホスト名または IP アドレス) とポート

[Actions] パラメータ・リファレンス

"構成マージで、構成以上のカスタマイズは可能か" で説明したように、[Actions]Opens in a new tab パラメータを使用すると、構成マージによって多種多様な InterSystems IRIS オブジェクトを管理できます。このセクションは、必要な [Actions] パラメータをできる限り速く識別するのに役立ちます。各表には、使用可能なすべてのパラメータが以下の順序で一覧表示されています。

• パラメータが作用するオブジェクト別。例えば、パラメータを使用してデータベースを作成、削除、変更することはできますが、サービスを作成または削除することはできません。これらは変更のみ可能です。

• パラメータが処理される順。これは、構成マージ・ファイル内の順序によって決定されるのではなく、固定されています。例えば、CreateNamespace パラメータに指定する既定のデータベースは実行時に存在している必要があるため、CreateDatabase は CreateNamespace の前に処理されます。このため、ネームスペースとその既定のグローバル・データベースまたはルーチン・データベースの両方を作成する場合、マージ・ファイルで CreateNamespace が CreateDatabase の上に表示されていても、指定したデータベースが先に作成されます。

• パラメータが対応するクラスまたはコマンド別。例えば、ミラーを作成、削除、変更するためのパラメータは、クラス Config.mirrors のメソッドの呼び出しによって制御されます。

• アルファベット順では、アクションのタイプ (作成、削除、変更) によってもパラメータを分けています。

[Actions] パラメータの引数は、次のアクションで示す形式で指定されます。ここでは、CreateNamespace パラメータを使用して、APPDATA データベースを既定のグローバル・データベース、USER データベースを既定のルーチン・データベースとして、APPDATA ネームスペースが作成されます。

[Actions]
CreateNamespace:Name=APPDATA,Globals=APPDATADB,Routines=USER

各 [Actions] パラメータで使用できる引数を確認するには、クラス・リファレンスでベースとなるクラスのプロパティ・インベントリを参照してください。(対応するクラス別の表では、リストされるクラスは、クラス・リファレンスのエントリにリンクされています。)例えば、Config.NamespacesOpens in a new tab クラスのインベントリには、以下のプロパティが含まれます。

• Globals — ネームスペースの既定のグローバル・データベース

• Interop (ブーリアン) — ネームスペースが相互運用対応かどうか (ブーリアン)

• Routines — ネームスペースの既定のルーチン・データベース

• TempGlobals — 一時グローバル・ストレージの既定のデータベース

上述の一般的な説明には、以下のようないくつかの例外があります。

• Config パッケージのクラスから派生したすべてのパラメータの場合、オブジェクトの名前の Name プロパティは、Create()、Modify()、Delete() メソッドを含む Config.CommonMultipleMethodsOpens in a new tab クラスから継承されます。

• ConfigMirrors および ConfigShardedCluster パラメータは 1 つのクラスに基づくのではなく、多数の異なる API コールを順番に呼び出します。例へのリンク

• 分散キャッシュ・クラスタ・アプリケーション・サーバで CreateDatabase パラメータを使用してリモート・データベースを追加する場合、2 つの一意の引数があり、Config.DatabasesOpens in a new tab プロパティ・インベントリにあるのは 1 つ目の引数のみです。

  • Server — リモート・データベースがあるデータ・サーバの名前を指定します (必須)。

  • LogicalOnly (ブーリアン) — アクションがアプリケーション・サーバ・ホストのファイル・システムでデータベースを作成しないことを指定します (オプション、既定 (0) ではデータベース・ファイルを作成します)。

• CreateUser パラメータを使用する場合、Security.UsersOpens in a new tab プロパティ・インベントリにない PasswordHash 引数がハッシュ化されたパスワード、作業係数、アルゴリズムを指定します ("構成マージで、構成以上のカスタマイズは可能か" を参照)。PasswordHash が、Security.UsersOpens in a new tab に一覧表示されている Password、PasswordHashAlgorithm、および PasswordHashWorkFactor プロパティの代わりに使用されます。

• SQL 特権のすべてのパラメータ — GrantPrivilege、RevokePrivilege、GrantAdminPrivilege、RevokeAdminPrivilege — は引数 Namespace を取ります。この引数はクラス・メソッドのプロパティ・インベントリ、またはコマンドを制御するためのコマンド引数リストにはありません。これらのクラスやコマンドは、呼び出しまたは実行されるネームスペースで適用されるように設計されているためです。Namespace 引数を使用すると、特権を付与または取り消す際に、任意のネームスペースを指定できます。

• SQL 管理特権パラメータ、GrantAdminPrivilege および RevokeAdminPrivilege は、クラスではなく、SQL コマンド GRANTOpens in a new tab および REVOKEOpens in a new tab に基づいており、管理者レベルの特権にのみ影響します。このため、利用可能な引数 (Namespace のほかに) には AdminPriv、Grantee、WithGrant のみが含まれます。この最後の引数は GrantAdminPrivilege 専用であり、WITH ADMIN OPTION 節を追加します (標準の WITH GRANT と同等)。

• GrantPrivilege パラメータは 2 つのメソッド %SYSTEM.SQL.Security.GrantPrivilegeWithGrant()Opens in a new tab と %SYSTEM.SQL.Security.GrantPrivilege()Opens in a new tab を組み合わせているため、追加のブーリアン引数 withGrant (wGrant も可能) を取り、withgrant=1 は前者の使用を選択し、withgrant=1 は後者の使用を選択します。