ICM リファレンス

一般パラメータ

以下のテーブルのフィールドはすべて、あらゆるクラウド・プロバイダで使用されます。一部のフィールドは、vSphere と PreExisting でも使用されます。

右端の 2 つの列は、各パラメータがすべての導入環境で必須であるか、オプションであるか、および defaults.json と definitions.json のどちらで指定する必要があるか (使用する場合)、どちらで推奨されるか、どちらでも使用できるかを示します。以下はその例です。

• 単一の導入環境は常に、(後で別のものとマージしてマルチプロバイダ導入環境を作成する場合でも) 選択した単一のプロビジョニング・プラットフォームを対象とするため、Provider パラメータは必須であり、既定値ファイルで指定する必要があります。

• それぞれのノード・タイプを指定する必要がありますが、1 つの導入環境に複数のノード・タイプを含めることができるため、Role パラメータは、定義ファイル内のそれぞれの定義で必須です。

• InterSystems IRIS を実行する各ノードにはライセンスが必要ですが、他のノードはライセンスを必要としないので、LicenseKey 設定は必須であり、通常は定義ファイル内の該当する定義で指定します。

• 少なくとも 1 つのコンテナを導入環境内の各ノードに導入する必要がありますが、単一のコンテナをすべてのノードに導入することもあれば (DATA ノードのみで構成されるシャード・クラスタ全体に iris/iris-arm64 を導入する場合など)、それぞれのノード・タイプに異なるコンテナを導入することもあります (分散キャッシュ・クラスタ内の DM と AM には iris/iris-arm64 を、WS には webgateway を、AR には arbiter を導入する場合など)。そのため、DockerImage パラメータは必須であり、既定値ファイル、定義ファイル、またはその両方で指定できます (両方で指定する場合は、既定のイメージを指定しますが、1 つ以上のノード・タイプについてそのイメージをオーバーライドします)。

• 導入するイメージと同様に、OS ボリュームのサイズも、既定値ファイルですべてのノードについて指定することも、定義ファイルで 1 つ以上のノード・タイプについて指定することも、両方で指定することもできます。ただし、既定値があるので、このパラメータはオプションです。

セキュリティ関連のパラメータ

以下のテーブルのパラメータは、プロビジョニングされたノードおよび導入されたコンテナと ICM が安全に通信できるように、アクセスを提供し、必要なファイルと情報を指定するために使用されます。これらはすべて必須で、既定値ファイルのみで指定します。

• ICM で提供されているスクリプトを使用してこれらのファイルを生成する方法については、“ICM の使用” の章にある "セキュリティ関連ファイルの入手" を参照してください。

• プロビジョニングされたノードおよびそれらのノード上のサービスと安全に通信するために、提供されたセキュリティ・ファイルを ICM がどのように使用するかについては、この章の "ICM セキュリティ" を参照してください。

• SSH プロトコルの一般的な使用法については、SSH Communications Security の "SSH PROTOCOLOpens in a new tab" を参照してください。

• Docker での TLS 証明書の使用を含め、Docker セキュリティの詳細は、Docker ドキュメントの "Docker securityOpens in a new tab" を参照してください。

• InterSystems IRIS での TLS の使用に関する一般情報は、インターシステムズの "TLS ガイドOpens in a new tab" と "インターシステムズ公開鍵インフラストラクチャOpens in a new tab" を参照してください。SSLConfig パラメータによって指定されるファイルの内容については、"クライアント構成の生成Opens in a new tab" を参照してください。

• TLS を使用してミラー・メンバ間の接続を保護する方法については、"高可用性ガイド" の "TLS セキュリティを使用したミラー通信の保護Opens in a new tab" を参照してください。

ポートおよびプロトコルのパラメータ

通常、これらのパラメータについては既定値で十分です。これらのパラメータのいくつかを指定する必要が生じる可能性がある 2 つの使用事例については、付録 “カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用” の "ポート" および付録 “既存のクラスタへの導入” の "ポート" を参照してください。

* ICM がコンテナ・モードであり (Containerless が false であるか、指定されていない)、Overlay が weave に設定されている場合 ("一般パラメータ" を参照)、このポートはノードのファイアウォールで閉じられています。

CPF パラメータ

"カスタマイズされた InterSystems IRIS 構成を使用した導入" の説明に従って、UserCPF プロパティによって指定された構成マージ・ファイルを使用して、導入時に 1 つ以上の InterSystems IRIS インスタンスの CPF をカスタマイズする場合、含めることができない CPF 設定があります。ICM は先にそれらの値を読み取る必要があり、そのうえで後から CPF に追加するためです。したがって、構成ファイルで以下のパラメータ ("一般パラメータ" および "ポートおよびプロトコルのパラメータ" を参照) を指定することによって、これらの設定をカスタマイズする必要があります。

プロバイダ固有のパラメータ

このセクションの表は、各種クラウド・プロバイダに固有な、ICM で使用されるパラメータの一覧です。これらのパラメータの中には、複数のプロバイダで使用されるものがあります。例えば、InstanceType、ElasticIP、および VPCId の各パラメータは AWS と Tencent の両方の導入で使用できます。プロバイダ固有のパラメータの中には、名前が違っても目的が同じものがあります。例えば、AWS の AMI と InstanceType、GCP の Image と MachineType、および Tencent の ImageId と InstanceType です。一方、これらのそれぞれに対応する 4 つの Azure パラメータがあります。

"一般パラメータ" のテーブルと同様に、このセクションのテーブルには、各パラメータがすべての導入環境で必須であるか、オプションであるか、および defaults.json と definitions.json のどちらで指定する必要があるか (使用する場合)、どちらで推奨されるか、どちらでも使用できるかを示します。それぞれのタイプの例については、"一般パラメータ" を参照してください。

デバイス名パラメータ

以下に示すパラメータでは、/dev に配置されるデバイス・ファイルを指定します。これらのファイルは、ICM によって作成され、InterSystems IRIS によって使用される永続ボリュームを表します。これらの永続ボリュームと、これらのパラメータのプロバイダおよび OS 固有の既定値のテーブルについては、"ICM によってマウントされるストレージ・ボリューム" を参照してください。PreExisting の導入については、付録 “既存のクラスタへの導入” の "ストレージ・ボリューム" を参照してください。

ユーザ・パラメータのアルファベット順のリスト

以下のテーブルは、このセクションの前述のテーブルで説明したすべてのパラメータをアルファベット順にリストしたものです。それぞれの定義を含むテーブルへのリンクも用意されています。

ロール DATA ： シャード・クラスタ・データ・ノード

"スケーラビリティ・ガイド" の “シャーディングによるデータ量に応じた水平方向の拡張” の章の "InterSystems IRIS のシャーディングの概要Opens in a new tab" などのセクションに記載されているように、一般的なシャード・クラスタはデータ・ノードのみで構成され、それらのノード間でシャード・データが分割されるため、definitions.json ファイルに必要なのは DATA ノードの定義のみです。DATA ノードを定義する場合、導入環境はシャード・クラスタである必要があり、DATA ノードと共に定義できる他のノード・タイプは COMPUTE のみです。

ノード定義の MirrorMap の設定と一致する数でプロビジョニングする場合、DATA ノードをミラーリングすることができます ("ミラーリングの規則" を参照)。クラスタ内の DATA ノードは、すべてをミラーリングするか、すべてをミラーリングしないかのどちらかにする必要があります。

シャード・クラスタ内のデータ・ノード間の唯一の相違は、最初に構成されたノード (ノード 1 と呼ばれる) には、そのノードへのシャード・データの割り当て分に加えて、クラスタのシャード化されていないデータ、メタデータ、およびコードがすべて格納される点です。ただし、ストレージ要件の違いは一般的にごくわずかです。すべてのデータ、メタデータ、およびコードをクラスタ内のいずれのノードでも認識できるので、すべてのノード間でアプリケーション接続を負荷分散して、クエリの並列処理や分割されたキャッシュを最大限に活用することができます。ロード・バランサを DATA ノードに割り当てることができます。"ロール LB ： ロード・バランサ" を参照してください。

ロール COMPUTE ： シャード・クラスタ計算ノード

常に大量のデータが取り込まれるような状況でも、クエリの遅延がきわめて小さいことが求められる高度な使用事例では、計算ノードをシャード・クラスタに追加して、クエリを処理するための透過的なキャッシュ層を提供することで、クエリとデータ取り込みの作業負荷を分離し、両方のパフォーマンスを向上させることができます (詳細は、"スケーラビリティ・ガイド" の "作業負荷の分離とクエリ・スループットの向上のための計算ノードの導入Opens in a new tab" を参照してください)。

計算ノードを追加することによってパフォーマンスが大幅に向上するのは、データ・ノードごとに計算ノードが少なくとも 1 つある場合のみです。したがって、少なくとも DATA ノードと同数の COMPUTE ノードを定義する必要があります。定義ファイル内の DATA ノードの数が COMPUTE ノードの数よりも多い場合、ICM は警告を発行します。1 つのデータ・ノードに対して複数の計算ノードを構成すると、クラスタのクエリ・スループットをさらに向上させることができます。その際、ベスト・プラクティスとして、ICM が定義された COMPUTE ノードを DATA ノード全体にできるだけ均等に分散できるように、各データ・ノードの計算ノードの数が同じになるように構成することをお勧めします。

COMPUTE ノードではクエリの実行のみがサポートされ、データは格納されないので、メモリと CPU を重視し、ストレージを最小限に抑えるなど、ニーズに合わせてインスタンス・タイプやその他の設定を調整できます。COMPUTE ノードにはデータが格納されないので、ミラーリングすることはできません。

ロード・バランサを COMPUTE ノードに割り当てることができます。"ロール LB ： ロード・バランサ" を参照してください。

ロール DM ： 分散キャッシュ・クラスタ・データ・サーバ、スタンドアロン・インスタンス、シャード・マスタ・データ・サーバ

ロール AM の複数のノードと DM ノード (ミラーリングなし、またはあり) が指定された場合、これらは InterSystems IRIS 分散キャッシュ・クラスタとして導入され、前者はアプリケーション・サーバ、後者はデータ・サーバとして動作します。

単独で導入されるロール DM のノード (ミラーリングなし、またはあり) は、スタンドアロン InterSystems IRIS インスタンスになります。

DM ノード (ミラーリングあり、またはミラーリングなし)、DS ノード (ミラーリングあり、またはミラーリングなし)、および (オプションで) QS ノードが指定されている場合、これらはネームスペース・レベルOpens in a new tabのシャード・クラスタとして導入されます。

ロール DS ： シャード・データ・サーバ

ネームスペース・レベルOpens in a new tabのアーキテクチャでは、シャード・クラスタにロードされた各シャード・テーブルの行分割がデータ・シャードに 1 つ格納されます。データ・シャードをホストするノードは、シャード・データ・サーバと呼ばれます。1 つのクラスタに複数 (最多で 200 台超) のシャード・データ・サーバを含めることができます。偶数台のシャード・データ・サーバを導入しミラーリングを指定することで、シャード・データ・サーバをミラーリングできます。

ロール QS ： シャード・クエリ・サーバ

ネームスペース・レベルのアーキテクチャでは、シャード・クエリ・サーバが、割り当てられたデータ・シャードへのクエリ・アクセスを提供することにより、クエリとデータ取り込みの作業負荷間の干渉を最小限に抑え、マルチユーザによる大量のクエリ作業負荷を処理するシャード・クラスタの処理能力を高めます。シャード・クエリ・サーバが導入されている場合、導入されたシャード・データ・サーバにラウンドロビン方式で割り当てられます。ミラーリングされたシャード・データ・サーバのフェイルオーバー時に、シャード・クエリ・サーバはアプリケーションの接続を自動的にリダイレクトします。

ロール AM ： 分散キャッシュ・クラスタ・アプリケーション・サーバ

ロール AM の複数のノードと DM ノードが指定された場合、これらは InterSystems IRIS 分散キャッシュ・クラスタとして導入され、前者はアプリケーション・サーバ、後者はデータ・サーバとして動作します。データ・サーバがミラーリングされている場合は、フェイルオーバー後のアプリケーション接続のリダイレクトが自動的に行われます。

ロード・バランサを AM ノードに割り当てることができます。"ロール LB ： ロード・バランサ" を参照してください。

ロール AR ： ミラー・アービター

DATA ノード (シャード・クラスタ DATA ノード)、DM ノード (分散キャッシュ・クラスタ・データ・サーバ、スタンドアロン InterSystems IRIS インスタンス、またはネームスペース・レベルのシャード・マスタ・データ・サーバ)、または DS ノード (ネームスペース・レベルのシャード・データ・サーバ) がミラーリングされている場合は、自動フェイルオーバーを円滑に行うためにアービター・ノードを導入することを強くお勧めします。クラスタ内のすべてのミラーに対してアービター・ノードは 1 つあれば十分で、複数のアービターはサポートされておらず、ICM によって無視されます (ミラーリングされていないクラスタ内のアービター・ノードも同様に無視されます)。

AR ノードは InterSystems IRIS インスタンスを含んでおらず、別のイメージを使用して ISCAgent コンテナを実行します。このアービター・イメージは、AR ノードの定義ファイル・エントリ内の DockerImage フィールドを使用して指定する必要があります。詳細は、"icm run コマンド" を参照してください。

アービターの詳細は、"高可用性ガイド" の “ミラーリングOpens in a new tab” の章を参照してください。

ロール WS ： Web サーバ

1 つの導入環境に Web サーバをいくつでも含めることができます。各 Web サーバ・ノードには、Apache Web サーバと共にインターシステムズの Web ゲートウェイのインストールが含まれます。ICM は、インターシステムズの Web ゲートウェイのリモート・サーバ・リストを以下のように生成します。

• DATA ノードと COMPUTE ノードを導入する場合 (ノード・レベルのシャード・クラスタ)、すべての DATA ノードと COMPUTE ノード。COMPUTE ノードを導入しない場合は、すべての DATA ノード。

• AM ノードを導入する場合 (分散キャッシュ・クラスタ)、すべての AM ノード。

• それ以外の場合は、DM ノード (スタンドアロン・インスタンスまたはネームスペース・レベルのシャード・クラスタ)。

  Note:

  Web サーバ層でネームスペース・レベルのシャード・クラスタを導入する場合、カスタムまたはサードパーティのロード・バランサを手動で導入して、クラスタ内の DS ノードおよび (存在する場合) QS ノードの間で接続を分散し ("スケーラビリティ・ガイド" の "ネームスペース・レベル・アーキテクチャの導入Opens in a new tab" で推奨されているとおり)、Web ゲートウェイ構成を手動で編集して、リモート・サーバのリストにロード・バランサのアドレスを入力できます (詳細は、"Web ゲートウェイ構成ガイド" の "ミラー構成、フェイルオーバー、および負荷分散Opens in a new tab" を参照)。

ミラーリングされた DATA ノードと DM ノードについては、ミラー認識接続が作成され、フェイルオーバー後のアプリケーション接続のリダイレクトが自動的に行われます。Web サーバとリモート・サーバの間の通信は TLS モードで動作するように構成されます。

ロード・バランサを WS ノードに割り当てることができます。"ロール LB ： ロード・バランサ" を参照してください。

WS ノードは InterSystems IRIS インスタンスを含んでおらず、別のイメージを使用して Web ゲートウェイ・コンテナを実行します。"icm run コマンド" で説明しているように、webgateway イメージは、definitions.json ファイルの WS ノード定義に DockerImage フィールドを含めることで指定できます。以下に例を示します。

{
    "Role": "WS",
    "Count": "3",
    "DockerImage": "intersystems/webgateway:2022.2.0.221.0",
    "ApplicationPath": "/acme",
    "AlternativeServers": "LoadBalancing"
}

ApplicationPath フィールドを指定する場合、その値は、Web ゲートウェイのインスタンスごとのアプリケーション・パスの作成に使用されます。このアプリケーション・パスの既定のサーバは、ラウンドロビン方式で Web ゲートウェイ・インスタンス間で割り当てられ、それ以外のリモート・サーバは代替サーバ・プールを構成します。 例えば、前の例の WS ノード定義が 3 つの AM ノードの分散キャッシュ・クラスタの一部である場合、割り当ては以下のようになります。

AlternativeServers フィールドには、Web ゲートウェイがターゲット・サーバ・プールに要求をどのように分散するかを指定します。有効な値は、LoadBalancing (既定) と FailOver です。 ApplicationPath フィールドを指定しない場合、このフィールドは無効です。

インターシステムズの Web ゲートウェイの使用法の詳細は、"Web ゲートウェイ構成ガイドOpens in a new tab" を参照してください。

ロール SAM ： System Alerting and Monitoring ノード

SAM ノードを定義すると、System Alerting and Monitoring (SAM) クラスタ・モニタリング・ソリューションが導入環境に追加されます。SAM の追加の詳細は、"ICM でのモニタリング"、SAM の詳細は、"System Alerting and Monitoring GuideOpens in a new tab" を参照してください。

ロール LB ： ロード・バランサ

プロビジョニング・プラットフォームが AWS、GCP、Azure、または Tencent であり、定義ファイル内のタイプ DATA、COMPUTE、DM、AM、または WS のノードの定義で LoadBalancer が true に設定されている場合、ICM は、事前定義されたロード・バランサ・ノードを自動的にプロビジョニングします。VM ノードまたは CN ノードの汎用ロード・バランサについては、追加のパラメータを指定する必要があります。

事前定義されたロード・バランサ

ロール LB のノードの場合、ICM は転送するポートとプロトコル、および対応する正常性チェックを構成します。導入されたロード・バランサに対するクエリは、シャード・クラスタ内のデータ・ノードまたは分散キャッシュ・クラスタ・アプリケーション・サーバに対して行う場合と同じように実行できます。

DATA、COMPUTE、DM、AM、または WS のノードの定義にロード・バランサを追加するには、LoadBalancer フィールドを追加します。以下に例を示します。

{
    "Role": "AM",
    "Count": "2",
    "LoadBalancer": "true"
}

以下の例は、この定義によって作成および導入されるノードを示しています。

$ icm inventory
Machine           IP Address    DNS Name                              Region   Zone
-------           ----------    --------                              ------   ----
ANDY-AM-TEST-0001 54.214.230.24 ec2-54-214-230-24.amazonaws.com       us-west1 c
ANDY-AM-TEST-0002 54.214.230.25 ec2-54-214-230-25.amazonaws.com       us-west1 c
ANDY-LB-TEST-0000 (virtual AM)  ANDY-AM-TEST-1546467861.amazonaws.com us-west1 c

このクラスタに対するクエリは、AM ノードに対して行う場合と同じように、ロード・バランサに対して実行できます。

ミラーリングした DATA ノードと DM ノードに事前定義したロード・バランサはミラー認識ロード・バランサとなり、必ず現在のプライマリにトラフィックを転送します。

LoadBalancer フィールドは、1 つの導入環境の複数の定義に追加できます。例えば、負荷分散されたアプリケーション接続を受け取る WS 層から負荷分散された接続を受け取る AM ノードを分散キャッシュ・クラスタに含めることができます。

現在、自動的にプロビジョニングされた単一のロード・バランサを複数のノード・タイプ (例えば、DATA ノードと COMPUTE ノードの両方) で共有することはできないため、それぞれに専用のロード・バランサが必要です。目的のロール用にユーザがカスタムまたはサードパーティのロード・バランサを手動で導入してもかまいません。別の有用なアプローチは、WS ノードのロード・バランサをプロビジョニングすることです。これにより、"ロール WS ： Web サーバ" で説明しているように、アプリケーションの接続を複数のノード・タイプに分散できます。

Note:

AWS でプロビジョニングする場合、LoadBalancer を True に設定した定義で LoadBalancerInternal を True に設定することにより、"internal" タイプのロード・バランサを指定できます。

汎用ロード・バランサ

以下の追加キーを指定することにより、ロード・バランサを VM (仮想マシン) ノードおよび CN (コンテナ) に追加できます。

• ForwardProtocol

• ForwardPort

• HealthCheckProtocol

• HealthCheckPath

• HealthCheckPort

以下に例を示します。

{
    "Role": "VM",
    "Count": "2",
    "LoadBalancer": "true",
    "ForwardProtocol": "tcp",
    "ForwardPort": "443",
    "HealthCheckProtocol": "http",
    "HealthCheckPath": "/csp/status.cxw",
    "HealthCheckPort": "8080"
}

ForwardPort には、転送するポートのコンマ区切りリストを指定できます。その場合、転送するポートすべてで同じ ForwardProtocol を共有していることが条件になります。

これらのキーの詳細は、“ICM の構成パラメータ” の "ポートおよびプロトコルのパラメータ" のテーブルを参照してください。

ロール VM ： 仮想マシン・ノード

クラスタには仮想マシン・ノードをいくつでも含めることができます。仮想マシン・ノードは、InterSystems IRIS クラスタ内で事前定義されたロールを持たないホスト・ノードを割り振るための手段です。これらのノードに Docker はインストールされませんが、ユーザは任意のカスタムまたはサードパーティのソフトウェア (Docker を含む) を自由に導入できます。

仮想マシン・ノードでは以下のコマンドがサポートされます。

• icm provision

• icm unprovision

• icm inventory

• icm ssh

• icm scp

ロード・バランサを VM ノードに割り当てることができます。"ロール LB ： ロード・バランサ" を参照してください。

ロール CN ： コンテナ・ノード

クラスタにはコンテナ・ノードをいくつでも含めることができます。コンテナ・ノードは、Docker がインストールされている汎用ノードです。

CN ノードを定義して、IAM および IAMImage フィールドを含めることで、InterSystems API Manager (IAM) を任意の導入環境に追加できます。詳細は、“ICM リファレンス” の "InterSystems API Manager の導入" を参照してください。任意のカスタム・コンテナやサードパーティ・コンテナも CN ノードに導入できます。指定されている場合、iris (InterSystems IRIS) コンテナは導入されません。コンテナ・ノードではすべての ICM コマンドがサポートされていますが、-container オプションを使用して iris 以外のコンテナを指定する場合や、-role オプションまたは -machine オプションを使用して CN ノードに対するコマンドに限定する場合を除き、ほとんどの ICM コマンドがフィルタで除外されます ("ICM コマンドとオプション" を参照)。

ロード・バランサを CN ノードに割り当てることができます。"ロール LB ： ロード・バランサ" を参照してください。CN ノードはコンテナレス・モードでは導入できません。

ロール BH ： 要塞ホスト

パブリック・ネットワーク・アクセスを提供しない構成を導入することもできます。既存のプライベート・ネットワークがある場合、そのネットワーク上のノードで ICM を起動し、その中で導入を行うことができます。そのようなネットワークがない場合は、ICM によってプライベート・サブネットが構成され、そこに構成が導入されるようにすることができます。ただし、ICM はそのプライベート・サブネット内で実行されていないので、構成のプロビジョニング、導入、および管理を行うためのアクセス手段が必要です。この目的を果たすのが BH ノードです。

要塞ホストは、ICM によって構成されたプライベート・サブネットとパブリック・ネットワークの両方に属し、それらの間の通信を仲介できるホスト・ノードです。要塞ホストを使用するには、定義ファイルで 1 つの BH ノードを定義し、既定値ファイルで PrivateSubnet を true に設定します。詳細は、"プライベート・ネットワークへの導入" を参照してください。

ミラーリングの規則

シャード・クラスタ内のデータ・ノードは、すべてをミラーリングするか、すべてをミラーリングしないかのどちらかにする必要があります。この要件は、以下の ICM トポロジ検証規則に反映されています。

既定値ファイルで Mirror フィールドが false に設定されている場合 (既定値)、ミラーリングは構成されず、定義ファイルに複数の DM ノードが指定されているとプロビジョニングは失敗します。

Mirror フィールドが true に設定されている場合、可能であればミラーリングが構成され、DATA、DS、または DM ノードのミラー・ロール (プライマリ、バックアップ、または DR 非同期) がノード定義の MirrorMap フィールドの値 ("一般パラメータ" を参照) によって、次のように決定されます。

• MirrorMap が関連するノード定義に含まれていない場合、ノードは MirrorMap の既定の値 primary,backup を使用して、ミラー・フェイルオーバー・ペアとして構成されます。

  • 偶数個の DATA ノードまたは DS ノードが定義されている場合、これらはすべてフェイルオーバー・ペアとして構成されます。例えば、6 つの DATA ノードを指定すると、フェイルオーバー・ペアを含み、DR 非同期を含まない 3 つのデータ・ノード・ミラーが導入されます。奇数個の DATA ノードまたは DS ノードが定義されている場合、プロビジョニングは失敗します。

  • 2 つの DM ノードが定義されている場合、これらはフェイルオーバー・ペアとして構成されます。それ以外の数が定義されている場合、プロビジョニングは失敗します。

• ノード定義に MirrorMap が含まれている場合、ノードはその値に基づいて次のように構成されます。

  • DATA ノードまたは DS ノードの個数は、MirrorMap の値で指定されたロールの数以下の倍数である必要があります。例えば、次に示すように、MirrorMap の値が primary,backup,async であるとします。

    "Role": "DATA",
    "Count": "",
    "MirrorMap": "primary,backup,async"
    
    

    

    この場合、DATA ノードまたは DS ノードは次のように構成されます。

    Count の値	結果
    3 または 3 の倍数	フェイルオーバー・ペアと DR 非同期を含む 1 つ以上のミラー
    2	フェイルオーバー・ペアを含む 1 つのミラー
    1、4 以上 (3 の倍数以外)	プロビジョニング失敗

  • DM ノードの数は、MirrorMap の値で指定されたロールの数以下である必要があります。DM ノードを 1 つだけ指定すると、プロビジョニングは失敗します。

• 複数の AR (アービター) ノードが指定されている場合、プロビジョニングは失敗します。(ベスト・プラクティスではありますが、アービターの使用は任意であるため、ミラー構成に AR ノードを含める必要はありません。)

ICM によって導入される非同期はすべて DR 非同期です。レポート非同期はサポートされていません。1 つのミラーに最大 14 個の非同期を含めることができます。ミラー・メンバと可能な構成の詳細は、"高可用性ガイド" の "ミラー・コンポーネントOpens in a new tab" を参照してください。

DATA ノード、DS ノード、または DM ノードのプロビジョニングや構成が行われた順序とミラー内でのそれらのロールとの間に関係性はありません。プロビジョニングの後、icm inventory コマンドを使用して、各ペアのどのメンバがプライマリ・フェイルオーバー・メンバとなり、どのメンバがバックアップとなる予定かを確認できます。ミラーリングが有効な場合に、導入された構成で各ノードのミラー・メンバ・ステータスを確認するには、icm ps コマンドを使用します。

ミラーリングされていない構成の要件

ミラーリングされていないクラスタは以下で構成されます。

• 1 つ以上の DATA (シャード・クラスタ内のデータ・ノード)。

• DATA ノードが含まれている場合、ゼロ個以上の COMPUTE (シャード・クラスタ内の計算ノード)。ベスト・プラクティスは、少なくとも DATA ノードと同数の COMPUTE ノードを含め、各 DATA ノードの COMPUTE ノードの数を同じにすることです。

• DATA ノードが含まれていない場合は以下のとおりです。

  • 1 つの DM (分散キャッシュ・クラスタ・データ・サーバ、スタンドアロン InterSystems IRIS インスタンス、ネームスペース・レベルOpens in a new tabのシャード・クラスタ内のシャード・マスタ・データ・サーバ)。

  • ゼロ個以上のAM (分散キャッシュ・クラスタ・アプリケーション・サーバ)。

  • ゼロ個以上の DS (ネームスペース・レベルのシャード・クラスタ内のシャード・データ・サーバ)。

  • ゼロ個以上の QS (ネームスペース・レベルのシャード・クラスタ内のシャード・クエリ・サーバ)。

• ゼロ個以上の WS (Web サーバ)。

• ゼロ個以上の LB (ロード・バランサ)。

• ゼロ個以上の VM (仮想マシン・ノード)。

• ゼロ個以上の CN (コンテナ・ノード)。

• ゼロ個または 1 個の BH (要塞ホスト)。

• ゼロ個の AR (アービター・ノードはミラーリングされた構成の場合のみ)。

これらの一部のノード・タイプ間の関係を以下の例に図示します。

ミラーリングされた構成の要件

ミラーリングされたクラスタは、以下で構成されます。

• DATA ノード (ノード・レベルのシャード・クラスタ内のデータ・ノード) が含まれる場合は以下のとおりです。

  • 既定でまたは明示的に、MirrorMap の値と一致する個数の DATA。("ミラーリングの規則" を参照)。

  • ゼロ個以上の COMPUTE (ノード・レベルのシャード・クラスタ内の計算ノード)。ベスト・プラクティスは、DATA ノード・ミラーごとに少なくとも 1 つの COMPUTE ノードを含め、各 DATA ノード・ミラーの COMPUTE ノードの数を同じにすることです。

• DATA ノードが含まれていない場合は以下のとおりです。

  • ネームスペース・レベルのシャード・クラスタ内のミラーリングされたシャード・マスタ・データ・サーバ、分散キャッシュ・クラスタ内のデータ・サーバ、またはスタンドアロンの InterSystems IRIS インスタンスとしての 2 つの DM。DR 非同期が "ミラーリングの規則" の説明のとおり MirrorMap フィールドで指定されている場合は、2 つを超える DM。

  • ネームスペース・レベルのシャード・クラスタの場合は以下のとおりです。

    • 既定でまたは明示的に、MirrorMap の値と一致する個数の DS (シャード・データ・サーバ)。("ミラーリングの規則" を参照。)

    • ゼロ個以上の QS (シャード・クエリ・サーバ)。(前述の COMPUTE ノードの説明を参照。)

  • 分散キャッシュ・クラスタ内のアプリケーション・サーバとしてのゼロ個以上の AM。

• ゼロ個または 1 個の AR (アービター・ノードはオプションですが、ミラーリングされた構成の場合は推奨されます)。

• ゼロ個以上の WS (Web サーバ)。

• ゼロ個以上の LB (ロード・バランサ)。

• ゼロ個以上の VM (仮想マシン・ノード)。

• ゼロ個以上の CN (コンテナ・ノード)。

• ゼロ個または 1 個の BH (要塞ホスト)。

ミラーリングには、以下のフィールドを指定する必要があります。

• ミラーリングを有効にするには、defaults.json ファイルのキー Mirror を true に設定します。

  "Mirror": "true"
  

  

• DATA、DS、または DM ミラーに DR 非同期を含めるには、定義ファイルに MirrorMap フィールドを含めて、最初の 2 個以外が DR 非同期メンバであることを指定する必要があります。MirrorMap の値は、常に primary,backup で始まる必要があります。以下に例を示します。

  "Role": "DM",
  "Count": "5”,
  "MirrorMap": "primary,backup,async,async,async",
  ...
  

  

  MirrorMap の値と定義されている DATA、DS、または DM ノードの数との関係の詳細は、"ミラーリングの規則" を参照してください。MirrorMap を Zone フィールドおよび ZoneMap フィールドと組み合わせて使用して、複数のゾーンにわたって非同期インスタンスを導入することができます。"複数ゾーンにわたる導入" を参照してください。

LB の自動導入 ("ロール LB ： ロード・バランサ" を参照) は、AWS、GCP、Azure、および Tencent の各プロバイダについてサポートされています。独自のロード・バランサを作成する場合、組み込む IP アドレスのプールは、構成およびアプリケーションの要件に応じて、DATA ノード、COMPUTE ノード、AM ノード、または WS ノードのものです。

これらの一部のノード・タイプ間の関係を以下の例に図示します。

ホスト・ノードの通信

ホスト・ノードは、コンテナが導入されるホスト・マシンです。これは仮想マシンまたは物理マシンで、クラウド内またはオンプレミスで実行されます。

ICM は、SSH を使用してホスト・ノードにログインし、それらに対してリモートでコマンドを実行します。また、SCP を使用して、ICM コンテナとホスト・ノードの間でファイルをコピーします。このセキュリティ保護された通信を有効にするには、SSH 公開/秘密鍵ペアを提供し、これらの鍵を defaults.json ファイルで SSHPublicKey および SSHPrivateKey として指定する必要があります。構成フェーズ中に、ICM は各ホスト・ノードでパスワード・ログインを無効にし、秘密鍵をノードにコピーし、ポート 22 を開いて、対応する公開鍵を持つクライアントが SSH および SCP を使用してノードに接続できるようにします。

ホスト・マシン上で開かれるその他のポートについては、以降のセクションで説明します。

Docker

プロビジョニング時に、ICM は GPG 指紋を使用して Docker 公式 Web サイトから Docker の特定バージョンをダウンロードし、インストールします。ICM はその後、提供された TLS 証明書 (既定値ファイルの TLSKeyDir フィールドで指定されたディレクトリに配置されている) をホスト・マシンにコピーし、TLS を有効にして Docker デーモンを起動して、ポート 2376 を開きます。この時点で、対応する証明書を持つクライアントは、ホスト・マシンに Docker コマンドを発行できます。

Weave Net

プロビジョニング時に、Weave ネットワークに接続する各マシンからパスワード (ユーザが提供する) を要求するオプションとトラフィック暗号化オプションで、Weave Net を ICM は起動します。これらのオプションを有効にするには、defaults.json ファイルで WeavePassword を null 以外の任意の値に設定します。

InterSystems IRIS

InterSystems IRIS のセキュリティの包括的な概要については、"インターシステムズのセキュリティについてOpens in a new tab" を参照してください。

プライベート・ネットワーク

ICM は、インターネットからアクセスできない既存のプライベート・ネットワークで導入を行うことができます (必要なアクセスが構成されている場合)。また、導入を行うプライベート・ネットワークを作成し、要塞ホストを介した独自のアクセスを構成することもできます。プライベート・ネットワークの使用の詳細は、"プライベート・ネットワークへの導入" を参照してください。

GCP での複数のリージョンにわたる導入

GCP で複数のリージョンにわたる導入を行うには、既定値ファイルの Region フィールドで、以下のように目的のリージョンをコンマ区切りリストとして指定します。

{
    "Provider": "GCP",
    "Label": "Sample",
    "Tag": "multi",
    "Region": "us-east1,us-west1",
    "Zone": "us-east1-b,us-west1-a",
    ...
}

既定では、各定義内のノードに、ラウンドロビン方式でリージョンが割り当てられます。例えば、上の defaults.json と下の definitions.json に示すフィールドを使用して導入するとします。

[
  {
    "Role": "DATA",
    "Count": "2"
  },
  {
    "Role": "AR",
    "Count": "1",
    "DockerImage": "intersystems/arbiter:2022.2.0.221.0"
  }
]

この場合、 icm inventory コマンドの出力は次のようになります。

$ icm inventory
Machine               IP Address    DNS Name              Region    Zone
-------               ----------    --------              ------    ----
Acme-AR-multi-0001    35.179.173.90 acmear1.google.com    us-east1     b
Acme-DATA-multi-0001- 35.237.131.39 acmedata1.google.com  us-east1     b
Acme-DATA-multi-0002+ 35.233.223.64 acmedata2.google.com  us-west1     a

ノードが導入されるリージョンを制御するために、RegionMap フィールドを使用して、定義されたノードを指定のリージョンにマップすることができます。RegionMap をノード定義に含めたら、ZoneMap (前のセクション "複数ゾーンにわたる導入" を参照) も含めて、ノード (複数可) を目的のゾーン (複数可) にマップする必要があります。例えば、フェイルオーバー・ペアと DR 非同期がアービターと共に含まれるミラーを導入するとします。フェイルオーバー・ペアは同じリージョンの異なるゾーンに、非同期とアービターは異なるリージョンの異なるゾーンに導入します。使用するファイルおよび icm inventory コマンドと icm ps コマンドの出力を、以下に示します。

defaults.json

{
    "Provider": "GCP",
    "Label": "Sample",
    "Tag": "multi",
    "Region": "us-east1,us-west1",
    "Zone": "us-east1-a,us-east1-b,us-west1-a,us-west1-b",
    ...
}

definitions.json

[
  {
    "Role": "DATA",
    "Count": "3",
    "MirrorMap": "primary,backup,async",
    "RegionMap": "1,1,2",
    "ZoneMap": "1,2,3",
  },
  {
    "Role": "AR",
    "Count": "1",
    "DockerImage": "intersystems/arbiter:2022.2.0.221.0",
    "RegionMap": "2",
    "ZoneMap": "4"
  }
]

icm inventory

Machine               IP Address    DNS Name              Region    Zone
-------               ----------    --------              ------    ----
Acme-AR-multi-0001    35.179.173.90 acmear1.google.com    us-west1     b
Acme-DATA-multi-0001+ 35.237.131.39 acmedata1.google.com  us-east1     b
Acme-DATA-multi-0002- 35.233.223.64 acmedata2.google.com  us-east1     a
Acme-DATA-multi-0003  35.166.127.82 acmedata3.google.com  us-west1     a

icm ps

Machine              IP Address    Container Status Health  Mirror    Image
-------              ----------    --------- ------ ------  ------    -----
Acme-AR-multi-0001   35.179.173.90 arbiter   Up     healthy           intersystems/arbiter:2022.2.0.221.0
Acme-DATA-multi-0001 35.237.131.39 iris      Up     healthy PRIMARY   intersystems/iris:2022.2.0.221.0
Acme-DATA-multi-0002 35.233.223.64 iris      Up     healthy BACKUP    intersystems/iris:2022.2.0.221.0
Acme-DATA-multi-0003 35.166.127.82 iris      Up     healthy CONNECTED intersystems/iris:2022.2.0.221.0

Network フィールド ("Google Cloud Platform (GCP) パラメータ" を参照) を使用して、マルチリージョン導入で使用する既存のネットワークを指定するには、GCP Subnet フィールドを使用して、Region フィールドで指定されたリージョンごとに一意のサブネットを指定することも必要です。例えば、ここで示したリージョン us-west1 および us-east1 への導入の場合は、既定値ファイルに以下を含める必要があります。

"Network": "acme-network",
"Subnet": "acme-subnet-data-east,acme-subnet-data-west"

Azure での複数のリージョンにわたる導入

Azure で複数のリージョンにわたる導入を行うには、既定値ファイルの Location フィールドで、以下のように目的のリージョンをコンマ区切りリストとして指定します。

{
    "Provider": "Azure",
    "Label": "Sample",
    "Tag": "multi",
    "Location": "East US,Central US",
    ...
}

既定では、各定義内のノードに、ラウンドロビン方式で場所が割り当てられます。例えば、上の defaults.json と下の definitions.json に示すフィールドを使用して導入するとします。

[
  {
    "Role": "DATA",
    "Count": "2"
  },
  {
    "Role": "AR",
    "Count": "1",
    "DockerImage": "intersystems/arbiter:2022.2.0.221.0"
  }
]

この場合、 icm inventory コマンドの出力は次のようになります。

$ icm inventory
Machine               IP Address    DNS Name             Region    Zone
-------               ----------    --------             ------    ----
Acme-AR-multi-0001    35.179.173.90 acmear1.azure.com    East US    1
Acme-DATA-multi-0001- 35.237.131.39 acmedata1.azure.com  East US    1
Acme-DATA-multi-0001+ 35.233.223.64 acmedata2.azure.com  Central US 1

ノードが導入されるリージョンを制御するために、LocationMap フィールドを使用して、定義されたノードを指定のリージョンにマップすることができます。LocationMap をノード定義に含めたら、ZoneMap (前のセクション "複数ゾーンにわたる導入" を参照) も含めて、ノード (複数可) を目的のゾーン (複数可) にマップする必要があります。例えば、フェイルオーバー・ペアと DR 非同期がアービターと共に含まれるミラーを導入するとします。フェイルオーバー・ペアは同じリージョンの異なるゾーンに、非同期とアービターは異なるリージョンの異なるゾーンに導入します。使用するファイルおよび icm inventory コマンドと icm ps コマンドの出力を、以下に示します。(Azure のゾーンはすべてのリージョンで同じ整数によって識別されるため、ZoneMap は LocationMap でどのリージョンが指定されていてもその中の目的のゾーンのみを識別します。)

defaults.json

{
    "Provider": "Azure",
    "Label": "Sample",
    "Tag": "multi",
    "Location": "East US,Central US",
    "Zone": "1,2",
    ...
}

definitions.json

[
  {
    "Role": "DATA",
    "Count": "3",
    "MirrorMap": "primary,backup,async",
    "LocationMap": "1,1,2",
    "ZoneMap": "1,2,1"
  },
  {
    "Role": "AR",
    "Count": "1",
    "DockerImage": "intersystems/arbiter:2022.2.0.221.0",
    "RegionMap": "2",
    "ZoneMap": "2"
  }
]

icm inventory

Machine               IP Address    DNS Name             Region     Zone
-------               ----------    --------             ------     ----
Acme-AR-multi-0001    35.179.173.90 acmear1.azure.com    Central US 2
Acme-DATA-multi-0001+ 35.237.131.39 acmedata1.azure.com  East US    1
Acme-DATA-multi-0002- 35.233.223.64 acmedata2.azure.com  East US    2
Acme-DATA-multi-0003  35.166.127.82 acmedata3.google.com Central US 1

icm ps

Machine              IP Address    Container Status Health  Mirror    Image
-------              ----------    --------- ------ ------  ------    -----
Acme-AR-multi-0001   35.179.173.90 arbiter   Up     healthy           intersystems/arbiter:2022.2.0.221.0
Acme-DATA-multi-0001 35.237.131.39 iris      Up     healthy PRIMARY   intersystems/iris:2022.2.0.221.0
Acme-DATA-multi-0002 35.233.223.64 iris      Up     healthy BACKUP    intersystems/iris:2022.2.0.221.0
Acme-DATA-multi-0003 35.166.127.82 iris      Up     healthy CONNECTED intersystems/iris:2022.2.0.221.0

Azure マルチリージョン導入環境で既存の仮想ネットワークを使用する場合は、既定値ファイルに ResourceGroupName および VirtualNetwork フィールドを含めて ("Microsoft Azure (Azure) パラメータ" を参照)、Location フィールドで指定されたリージョンごとにネットワークを指定する必要があります。以下に例を示します。

{
    "Provider": "Azure",
    "Label": "Sample",
    "Tag": "multi",
    "Location": "East US,Central US",
    "Zone": "1,2",
    "ResourceGroupName": "sample-resource-group",
    "VirtualNetworkName": "sample-vnet-east,sample-vnet-central"
    ...
}

指定したネットワークは、重複しないアドレス空間を持つ必要があります。付随する定義ファイルでは、各定義に、Location フィールドで指定されたリージョンごとに一意のサブネットを指定する Subnetname フィールドを含める必要があります。例えば、このセクションで説明するミラーリングされた導入で、既定値ファイルに ResourceGroupName および VirtualNetwork フィールドが含まれる場合、定義ファイルは次のようになります。AR 定義は Central US リージョンにのみ導入するため、この定義で必要なサブネットは 1 つだけです。

[
  {
    "Role": "DATA",
    "Count": "3",
    "MirrorMap": "primary,backup,async",
    "RegionMap": "1,1,2",
    "ZoneMap": "1,2,1",
    "SubnetName": "acme-subnet-data-east,acme-subnet-data-central"
  },
  {
    "Role": "AR",
    "Count": "1",
    "DockerImage": "intersystems/arbiter:2022.2.0.221.0",
    "RegionMap": "2",
    "ZoneMap": "2",
    "SubnetName": "acme-subnet-arbiter-central"
  }
]

AWS と Tencent での複数のリージョンにわたる導入

AWS と Tencent で複数のリージョンにわたって導入するには、ICM はまず必要なインフラストラクチャを別個のリージョンにプロビジョニングし、次に、そのインフラストラクチャをマージして、あたかも既存のインフラストラクチャであるかのようにそこにサービスを導入します。

この手順は、複数のプロバイダにわたる導入にも使用できます。この説明では、"リージョンまたはプロバイダ" を示す場合に "リージョン" を使用し、マルチプロバイダと AWS/Tencent マルチリージョンとの違いは必要に応じて記載します。

マージされたマルチリージョン導入を作成する手順は、以下のステップで構成されます。

1. 別個の ICM セッションでリージョンごとにインフラストラクチャをプロビジョニングします。

2. icm merge コマンドを使用して、マルチリージョン・インフラストラクチャをマージします。

3. マージされた definitions.json ファイルを確認し、必要に応じて順序変更や更新を行います。

4. icm provision コマンドを使用して、マージされたインフラストラクチャを再プロビジョニングします。

5. icm run コマンドを使用し、PreExisting 導入として、マージされたインフラストラクチャにサービスを導入します。

6. インフラストラクチャをプロビジョニング解除する場合は、元のセッション・ディレクトリで別途 icm unprovision コマンドを発行します。

インフラストラクチャのプロビジョニング

リージョン (Region フィールドで指定されたもの) ごとにインフラストラクチャをプロビジョニングするための別個のセッションを、同じ ICM コンテナ内の別個の作業ディレクトリで実行する必要があります。例えば、提供されている /Samples/AWS ディレクトリ (“ICM の使用” の章にある "導入の定義" を参照) を /Samples/AWS/us-east-1 および /Samples/AWS/us-west–1 にコピーすることから始めることができます。それぞれの既定値ファイルと定義ファイルで、最終的なマルチリージョン導入環境に合わせて、目的のリージョン、ノード定義、および機能を指定します。例えば、一方のリージョンにミラー・フェイルオーバー・ペアを導入し、もう一方のリージョンにミラーの DR 非同期メンバを導入する場合、適切なリージョンとゾーン、および "Mirror": "true" を既定値ファイルに含め、一方のリージョンの定義ファイルで 2 つの DM (フェイルオーバー・ペア用) を、他方の定義ファイルで 3 つ目の DM (非同期用) を、どちらかで 1 つの AR (アービター) ノードを定義します。リソースの競合を回避するために、マルチリージョン導入環境の既定値ファイルにはそれぞれ、一意の Label または Tag、あるいはその両方が必要です。マルチプロバイダ導入環境では、その必要はありません。この例を以下に示します。

Note:

Mirror が true に設定されている場合に DM ノードが 1 つしか定義されていないなど、指定された定義が単一リージョン導入環境のトポロジ要件を満たしていない場合は、/Samples/AWS/us-west-1/defaults.json に示すように、既定値ファイルに "SkipTopologyValidation": "true" を含めることによって、トポロジ検証を無効にします。

/Samples/AWS/us-east-1

defaults.json

{
    "Provider": "AWS",
    "Label": "Sample",
    "Tag": "east1",
    "Region": "us-east-1",
    "Zone": "us-east1-a,us-east1-b",
    "Mirror": "true",
    ...
}

definitions.json

[
  {
    "Role": "DM",
    "Count": "2",
    "ZoneMap": "1,2"
  }
]

/Samples/AWS/us-west-1/

defaults.json

{
    "Provider": "AWS",
    "Label": "Sample",
    "Tag": "west1",
    "Region": "us-west-1",
    "Zone": "us-west1-a,us-west1-b",
    "Mirror": "true",
    "SkipTopologyValidation": "true"},
    ...
}

definitions.json

[
  {
    "Role": "DM",
    "Count": "1",
    "ZoneMap": "1"
  }
  {
    "Role": "AR",
    "Count": "1",
    "ZoneMap": "2"
  }
]

各作業ディレクトリで icm provision コマンドを使用して、リージョンごとにインフラストラクチャをプロビジョニングします。各ディレクトリで実行された icm inventory コマンドの出力には、作業しているインフラストラクチャが表示されます。以下に例を示します。

/Samples/AWS/us-east-1

$ icm inventory
Machine             IP Address    DNS Name                        Region    Zone
-------             ----------    --------                        ------    ----
Acme-DM-east1-0001+ 54.214.230.24 ec2-54-214-230-24.amazonaws.com us-east-1 a
Acme-DM-east1-0002- 54.129.103.67 ec2-54-129-103-67.amazonaws.com us-east-1 b

/Samples/AWS/us-west-1

$ icm inventory
Machine             IP Address    DNS Name                        Region    Zone
-------             ----------    --------                        ------    ----
Acme-AR-west1-0001  54.181.212.79 ec2-54-181-212-79.amazonaws.com us-west-1 b
Acme-DM-west1-0002  54.253.103.21 ec2-54-253-103-21.amazonaws.com us-west-1 a

プロビジョニングされたインフラストラクチャのマージ

icm merge コマンドは、現在の作業ディレクトリおよび指定された追加のディレクトリ内の構成ファイルをスキャンして、指定の新しいディレクトリ内に、PreExisting 導入に使用できるマージされた構成ファイルを作成します。例えば、/Samples/AWS/us-east–1 および /Samples/AWS/us-west–1 内の定義ファイルと既定値ファイルをマージして /Samples/AWS/merge 内に新しいセットを作成するには、以下のコマンドを発行します。

$ cd /Samples/AWS/us-east-1
$ mkdir ../merge
$ icm merge -options ../us-west1 -localPath /Samples/AWS/merge

icm merge コマンドで、-options はローカル・ディレクトリとマージされるプロビジョニング・ディレクトリのコンマ区切りリストを指定し、--localPath はマージされる定義のマージ先ディレクトリを指定します。(ICM コマンド行に Docker 引数を含めることを可能にする -options オプションの詳細は、"カスタム・コンテナおよびサードパーティ・コンテナでの ICM の使用" を参照してください。)

マージされた定義ファイルの確認

新しい構成ファイルを調べると、マージされた既定値ファイルで Provider が PreExisting に変更されていることがわかります (以前の Provider フィールドや他のフィールドは定義ファイルに移動されています。これらは icm inventory コマンドによって表示されますが、それ以外の影響はありません)。必要に応じて、Label または Tag (あるいはその両方) を変更できます。

マージされた定義ファイル内の定義は、プロバイダ PreExisting で使用するように変換されています。付録 “既存のクラスタへの導入” の "PreExisting の定義ファイル" に記載されているように、PreExisting 導入の definitions.json ファイルには、ノードごとにエントリが 1 つずつ含まれます (ロールごとに 1 つのエントリがあり、そのロールのノード数を指定する Count フィールドが含まれるわけではありません)。それぞれのノードは、IP アドレスまたは完全修飾ドメイン名によって識別されます。IPAddress フィールドまたは DNSName フィールドに加えて、SSHUser フィールドがそれぞれの定義に含まれている必要があります (“既存のクラスタへの導入” の "SSH" に記載されているように、後者では、パスワードを使用しない sudo アクセス権を持つ非 root ユーザを指定します)。マージされたファイルでは、定義がリージョン別に (マルチプロバイダ導入環境ではプロバイダ別に) グループ化されています。ミラー・メンバの目的の配置を反映するように必要に応じて順序を変更し、適切なミラー・マップを定義する必要があります ("ミラーリングされた構成の要件" および "複数ゾーンにわたる導入" を参照)。確認が完了すると、この例の定義ファイルは以下のようになります。

[
    {
        "Role":"DM",
        "IPAddress":"54.214.230.24",
        "LicenseKey": "ubuntu-sharding-iris.key",
        "SSHUser": "icmuser",
        "MirrorMap": "primary,backup,async"
    },
    {
        "Role":"DM",
        "IPAddress":"54.129.103.67",
        "LicenseKey": "ubuntu-sharding-iris.key",
        "SSHUser": "icmuser",
        "MirrorMap": "primary,backup,async"
    },
    {
        "Role":"DM",
        "IPAddress":"54.253.103.21",
        "LicenseKey": "ubuntu-sharding-iris.key",
        "SSHUser": "icmuser",
        "MirrorMap": "primary,backup,async"
    },
    {
        "Role":"AR",
        "IPAddress":"54.181.212.79",
        "SSHUser": "icmuser",
        "StartCount": "4"
    }
]

マージされたインフラストラクチャの再プロビジョニング

新しいディレクトリ (この例では /Samples/AWS/merge) で icm provision コマンドを発行して、マージされたインフラストラクチャを再プロビジョニングします。icm inventory コマンドの出力には、マージされたインフラストラクチャが 1 つのリストとして表示されます。

$ icm inventory
Machine             IP Address     DNS Name                       Region    Zone
-------             ----------     --------                       ------    ----
Acme-DM-east1-0001+ 54.214.230.24 ec2-54-214-230-24.amazonaws.com us-east-1 a
Acme-DM-east1-0002- 54.129.103.67 ec2-54-129-103-67.amazonaws.com us-east-1 b
Acme-AR-west1-0001  54.181.212.79 ec2-54-181-212-79.amazonaws.com us-west-1 b
Acme-DM-west1-0002  54.253.103.21 ec2-54-253-103-21.amazonaws.com us-west-1 a

マージされたインフラストラクチャへのサービスの導入

いずれの導入環境でも行うように、icm run コマンドを使用して、マージされたインフラストラクチャにサービスを導入します。以下に例を示します。

$ icm run
...
-> Management Portal available at: http://112.97.196.104.google.com:52773/csp/sys/UtilHome.csp
$ icm ps
Machine            IP Address    Container Status Health  Mirror    Image
-------            ----------    --------- ------ ------  ------    -----
Acme-AR-multi-0001 35.179.173.90 arbiter   Up     healthy           intersystems/arbiter:2022.2.0.221.0
Acme-DM-multi-0001 35.237.131.39 iris      Up     healthy PRIMARY   intersystems/iris:2022.2.0.221.0
Acme-DM-multi-0002 35.233.223.64 iris      Up     healthy BACKUP    intersystems/iris:2022.2.0.221.0
Acme-DM-multi-0003 35.166.127.82 iris      Up     healthy CONNECTED intersystems/iris:2022.2.0.221.0

マージされたインフラストラクチャのプロビジョニング解除

マルチリージョン導入環境をプロビジョニング解除する時期が来たら、元の作業ディレクトリに戻って icm unprovision コマンドを発行した後、マージされた作業ディレクトリを削除します。この例では、以下のようにします。

$ cd /Samples/AWS/us-east-1
$ icm unprovision -force -cleanUp
...
...completed destroy of Acme-east1
$ cd /Samples/AWS/us-west-1
$ icm unprovision -force -cleanUp
...
...completed destroy of Acme-west1
$ rm -rf /Samples/AWS/merge

既存のプライベート・ネットワーク内での導入

以下の図のように、ICM を既存のプライベート・ネットワークに導入し、そのネットワークでプロビジョニングと導入を行う場合は、導入する構成の既定値ファイルと定義ファイルにフィールドを追加する必要があります。

既存のプライベート・ネットワークで導入を行うには、以下の手順に従います。

1. プライベート・ネットワーク内にあるノードにアクセスできるようにします。これには、VPN または中間ホストの使用が必要な場合があります。

2. “ICM の使用” の章にある "ICM の起動" の説明に従って、そのノードに Docker と ICM をインストールします。

3. 以下のフィールドを defaults.json ファイルに追加します。

   "PrivateSubnet": "true",
   "net_vpc_cidr": "10.0.0.0/16",
   "net_subnet_cidr": "10.0.2.0/24"
   

   

   net_vpc_cidr フィールドと net_subnet_cidr フィールド (サンプル値が示されている) では、プライベート・ネットワークの CIDR とそのネットワーク内のノードのサブネットの CIDR を指定します。

4. 適切な共通フィールドとプロバイダ固有のフィールドを以下のように defaults.json ファイルに追加します。

   プロバイダ	キー	説明
   すべて	PrivateSubnet	true に設定する必要があります。
   	net_vpc_cidr	プライベート・ネットワークの CIDR
   	net_subnet_cidr	プライベート・ネットワーク内の ICM ノードのサブネットの CIDR ("メモ" を参照)
   GCP	Network	Google の VPC
   	Subnet	Google のサブネットワーク
   Azure	ResourceGroupName	AzureRM のリソース・グループ
   	VirtualNetworkName	AzureRM の仮想ネットワーク
   	SubnetName	AzureRM のサブネット ("メモ" を参照)
   AWS ("メモ" を参照)	VPCId	AWS の VPC ID
   	SubnetIds	AWS のサブネット ID のコンマ区切りリスト。Zone フィールドによって指定された要素ごとに 1 つずつサブネット ID を追加します。
   Tencent	VPCId	Tencent の VPC ID
   	SubnetIds	Tencent のサブネット ID のコンマ区切りリスト。Zone フィールドによって指定された要素ごとに 1 つずつサブネット ID を追加します。

   Note:

   ICM は Azure 上で、SubnetName で指定されたサブネットにセキュリティ・グループを割り当てますが、これがサブネット上の無関係のマシンの動作に影響を与える可能性があります。このため、定義ファイル内でそれぞれのエントリについて、専用のサブネット (一意の SubnetName および対応する net_subnet_cidr で指定) を指定する必要があります (ただし、ResourceGroupName と VirtualNetworkName は既定値ファイル内で指定します)。以下のセクションの説明に従って要塞ホストを導入する場合、これには BH の定義も含まれます。

   AWS 上の既存のプライベート VPC 内に InterSystems IRIS を導入するには、ICM を導入して使用できるノードをその VPC 内に作成する必要があります。VPC の外部からこの ICM ホストにアクセスする場合は、ICM が独自のものを作成する代わりに使用するルート・テーブルとインターネット・ゲートウェイを指定できます。そのためには、RouteTableId フィールドと InternetGatewayId フィールドを defaults.json ファイルに追加します。以下に例を示します。

   "RouteTableID": "rtb-00bef388a03747469",
   "InternetGatewayId": "igw-027ad2d2b769344a3"
   

   

   GCP でプロビジョニングを行う場合、net_subnet_cidr フィールドは、禁令的ではなく叙述的です。これは、ノードのサブネットを含むアドレス空間である必要があると同時に、ネットワーク内の他のすべてのノードが、導入された構成にアクセスできる必要があります。

5. icm provision および icm run を使用して、構成のプロビジョニングと導入を行います。

プライベート・ネットワークで導入を行う際には、以下の点に留意してください。

• 管理ポータルなどの Web ページをプライベート・ネットワーク内のノードで表示するには、同様にプライベート・ネットワーク内にあるブラウザか、プロキシまたは VPN が構成されているブラウザが必要です。

• ICM コマンドの出力に表示される DNS 名は、単にローカル IP アドレスのコピーです。

• 現在、プライベート・ネットワークを複数のリージョンまたはプロバイダにわたって導入することはサポートされていません。

要塞ホストを使用したプライベート・ネットワークへの導入

既定値ファイルで PrivateSubnet フィールドを true に設定しているにもかかわらず、既存のネットワークを使用するために必要なフィールドを含めていない場合、ICM によってプライベート・ネットワークが作成されます。ただし、ICM は、割り振ったマシンを構成したり、それらのマシンとやり取りしたりすることができないので、この状態ではプロビジョニング・フェーズを完了することはできません。作成したプライベート・ネットワーク上のノードとやり取りできるようにするために、ICM ではオプションで要塞ホストを作成できます。これは、プライベート・サブネットとパブリック・ネットワークの両方に属し、それらの間の通信を仲介できるホスト・ノードです。

プライベート・ネットワークと、そのネットワークへのアクセスを ICM に提供する要塞ホストを作成するには、タイプ BH の 1 つのノードの定義を definitions.json ファイルに追加します。以下に例を示します。

   {
       "Role": "DATA",
       "Count": "3"
   },
   {
       "Role": "BH",
       "Count": "1",
       "StartCount: 4"
   }

要塞ホストを導入し、既存のプライベート・ネットワークで使用するには、前述のように BH 定義を定義ファイルに追加し、ネットワークを指定するために必要なフィールドを既定値ファイルに含めます (前のセクションを参照)。BH ノードの定義が definitions.json に含まれている場合、ICM は自動的に "PrivateSubnet" オプションを "true" に設定します。

要塞ホストには SSH を使用してアクセスでき、ユーザは要塞ホストを介して SSH コマンドをプライベート・ネットワークにトンネリングすることができます。この手法を使用することで、ICM はプライベート・ネットワーク内の計算インスタンスを外部から割り振って構成し、プロビジョニングを正常に完了することができます。以下に例を示します。

$ icm inventory
Machine             IP Address     DNS Name                     Region   Zone
-------             ----------     --------                     ------   ----
Acme-BH-TEST-0004   35.237.125.218 218.125.237.35.bc.google.com us-east1 b
Acme-DATA-TEST-0001 10.0.0.2       10.0.0.2                     us-east1 b
Acme-DATA-TEST-0002 10.0.0.3       10.0.0.3                     us-east1 b
Acme-DATA-TEST-0003 10.0.0.4       10.0.0.4                     us-east1 b

構成が導入されたら、ノードに対して ssh コマンドを実行できます。以下に例を示します。

# icm ssh -role DATA -interactive
ubuntu@ip-10.0.0.2:~$

ただし、コマンドが実行されていることを確認すると、要塞ホストを介してルーティングされていることがわかります。

$ icm ssh -role DATA -interactive -verbose
ssh -A -t -i /Samples/ssh/insecure -p 3022 ubuntu@35.237.125.218
ubuntu@ip-10.0.0.2:~$

一方、他のコマンドが成功するためには、ICM は SSH 以外のポートおよびプロトコルへのアクセスを必要とします。 そのために、ICM は、Docker、JDBC、および HTTP について要塞ホストとクラスタ内のノードとの間のトンネルを構成します。 これにより、icm run、icm exec、icm sql などのコマンドを正常に実行することができます。

要塞ホストを導入する際には、以下の点に留意してください。

• 構成の管理ポータルのアドレスは要塞ホストのものです。

• セキュリティ上の理由から、秘密鍵が要塞ホストに保存されることはありません。

• ICM コマンドの出力に表示される DNS 名は、単にローカル IP アドレスのコピーです。

• 要塞ホストを含む導入環境でのロード・バランサのプロビジョニングはサポートされていません。

• 現在、マルチリージョン導入環境 ("複数のリージョンまたはプロバイダにわたる導入" を参照) および分散管理モード (付録 “ICM 導入環境の共有” を参照) での要塞ホストの使用はサポートされていません。

  Note:

  Google ポータルでカスタム VPC を作成する際には、既定のサブネットを作成する必要があります。要塞ホストを使用してプロビジョニングを行い、ICM によって作成されたサブネットを使用する場合は、プロビジョニングの前にこの既定のサブネットを削除する必要があります (または、既定のアドレス空間 10.0.0.0/16 と競合しないアドレス空間を提供します)。

System Alerting and Monitoring

System Alerting and Monitoring (SAM) は、InterSystems IRIS® データ・プラットフォーム用のクラスタ・モニタリング・ソリューションです。InterSystems IRIS ベースのアプリケーションが動作する構成やプラットフォームに関係なく、SAM を使用して監視することができます。SAM の詳細は、"System Alerting and Monitoring GuideOpens in a new tab" を参照してください。

SAM が ICM 導入環境に組み込まれるのは、定義ファイルに SAM ノードを含めた場合です。DockerImage フィールドは必須で、InterSystems IRIS sam イメージを指定する必要があります。以下に例を示します。

[
    {
        "Role": "DM",
        "Count": "4",
        "LicenseKey": "ubuntu-sharding-iris.key"
    },
    {
        "Role": "SAM",
        "Count": "1",
        "DockerImage": "intersystems/sam:2.0"
    }
]

SAM アプリケーションは、5 つのコンテナで構成されます。SAM マネージャ・コンテナは、導入フェーズで導入されます ("icm run コマンド" を参照)。

他の 4 つのコンテナ (Prometheus、Alertmanager、Grafana、Nginx) は、プロビジョニング・フェーズで導入されます ("icm provision コマンド" を参照)。これらのコンテナの導入元のイメージは、PrometheusImage、AlertmanagerImage、GrafanaImage、NginxImage フィールドを使用して指定できます。これらの既定値は、"一般パラメータ" に示されています。

導入に成功すると、下の例のようなメッセージが表示されます。

$ icm run
...
-> SAM Portal available at: http://112.97.196.104.google.com:8080/api/sam/app/index.csp#

ICM でのサードパーティ・モニタリングの導入

サードパーティの好みのモニタリング・パッケージ (または、その他のサードパーティ・パッケージ) を ICM 構成の一部として導入できます。以下の例は、icm ssh コマンドを使用して、導入環境内のすべてのホストに Weave Scope モニタリングを追加する方法を示しています。

icm ssh -command "sudo curl -L git.io/scope -o /usr/local/bin/scope 2>&1"
icm ssh -command "sudo chmod +x /usr/local/bin/scope"
icm ssh -command "sudo /usr/local/bin/scope launch 2>&1"

これらのコマンドの実行後、icm inventory コマンドで表示された任意のホスト上のポート 4040 (http://hostname:4040) を経由して、Weave Scope にアクセスできます。

ホスト・ノードの再起動とリカバリ

計画外停止、またはクラウド・プロバイダ (予防メンテナンスの場合など) やユーザ (コスト削減のためなど) による計画的な措置によってクラウド・ホスト・ノードがシャットダウンされ、再起動された場合、その IP アドレスとドメイン名が変更されることがあります。これにより、ICM と導入されたアプリケーション (InterSystems IRIS を含む) の両方で問題が生じます。

この動作は、クラウド・プロバイダによって異なります。GCP および Azure では、既定で、ホスト・ノードの再起動後も IP アドレスとドメイン名が保持されますが、AWS と Tencent ではこの機能はオプションです ("Elastic IP 機能" を参照)。

ホスト・ノードがシャットダウンされる理由としては、以下のものがあります。

• 計画外停止

  • 停電

  • カーネル・パニック

• プロバイダが開始した予防メンテナンス

• ユーザが開始したコスト削減戦略

ホスト・ノードを意図的にシャットダウンする方法としては、以下のものがあります。

• クラウド・プロバイダのユーザ・インタフェースの使用

• ICM の使用 ：

  icm ssh -command 'sudo shutdown'
  

  

時刻スキューの訂正

ICM コンテナ内のシステム時刻が標準時刻と数分以上異なる場合は、各種クラウド・プロバイダが ICM からの要求を拒否する可能性があります。これは、コンテナが起動時 (初期、または停止や一時停止の後) に NTP サーバに到達できない場合に起こることがあります。このエラーは、terraform.err ファイルに以下のような差異として示されます。

Error refreshing state: 1 error(s) occurred:

    # icm provision
    Error: Thread exited with value 1
    Signature expired: 20170504T170025Z is now earlier than 20170504T171441Z (20170504T172941Z   15 min.)
    status code: 403, request id: 41f1c4c3-30ef-11e7-afcb-3d4015da6526 doesn’t run for a period of time

解決法は、NTP を手動で実行することです。例を以下に示します。

ntpd -nqp pool.ntp.org

その後、時刻が正しくなったことを確認します。("ICM の起動" の --cap-add オプションに関する説明も参照してください。)

ICM でのタイムアウト

ターゲット・システムに過大な負荷がかかっている場合、ICM のさまざまな操作がタイムアウトになることがあります。これらのタイムアウトの多くは、ICM の直接の制御下にありません (例えば、クラウド・プロバイダから制御される)。SSH 接続や JDBC 接続など、その他の操作は何度か再試行されます。

SSH のタイムアウトは、場合によっては正しく認識されないことがあります。例えば、以下の例では、SSH タイムアウトは基礎となるライブラリからの一般例外として現れています。

# icm cp -localPath foo.txt -remotePath /tmp/
2017-03-28 18:40:19 ERROR Docker:324 - Error: 
java.io.IOException: com.jcraft.jsch.JSchException: channel is not opened. 
2017-03-28 18:40:19 ERROR Docker:24 - java.lang.Exception: Errors occurred during execution; aborting operation 
        at com.intersystems.tbd.provision.SSH.sshCommand(SSH.java:419) 
        at com.intersystems.tbd.provision.Provision.execute(Provision.java:173) 
        at com.intersystems.tbd.provision.Main.main(Main.java:22)

この場合に推奨される対処法は、操作を再試行することです (最も近い原因を特定して解決した後)。

セキュリティ上の理由から、ICM はアイドル・セッションの既定の SSH タイムアウトを 10 分に設定します (60 秒 x 10 回の再試行)。これらの値は、/etc/ssh/sshd_config ファイル内で以下のフィールドを修正することによって変更できます。

ClientAliveInterval 60
ClientAliveCountMax 10

Docker ブリッジ・ネットワーク IP アドレス範囲の競合

コンテナ・ネットワークの場合、Docker では、既定で、サブネット 172.17.0.0/16 でブリッジ・ネットワークが使用されます (Docker ドキュメントの "Use bridge networksOpens in a new tab" を参照)。このサブネットを既にネットワークで使用している場合は、競合が発生して、Docker が起動しなくなったり、導入したホスト・ノードにアクセスできなくなったりすることがあります。この問題は、ICM コンテナをホストしているマシンと InterSystems IRIS クラスタ・ノードのどちらかまたは両方で生じる可能性があります。

これを解決するには、使用している IP アドレスと競合しない範囲にサブネットを割り当て直すように、Docker 構成ファイルのブリッジ・ネットワークの IP 構成を編集できます (ユーザの組織の IT 部門がこの値の指定を支援できる場合があります)。この変更を行うには、Docker デーモン構成ファイルに以下のような行を追加します。

"bip": "192.168.0.1/24"

ICM コンテナでこの問題が生じる場合は、コンテナのホストで /etc/docker/daemon.json ファイルを編集します。導入された構成内のホスト・ノードでこの問題が生じる場合は、ICM コンテナ内の /ICM/etc/toHost/daemon.json ファイルを編集します。既定でこのファイルには前述の例で示した値が含まれています。この値によって、PreExisting 以外の導入タイプで問題を回避できる可能性があります。

daemon.json ファイルのコンテンツに関する詳細は、Docker ドキュメントの "Daemon configuration fileOpens in a new tab" に記載されています。また、"Configure and troubleshoot the Docker daemonOpens in a new tab" も参照してください。

Weave ネットワーク IP アドレス範囲の競合

既定では、Weave ネットワークは IP アドレス範囲 10.32.0.0/12 を使用します。これが既存のネットワークと競合する場合は、ログ・ファイル installWeave.log に以下のようなエラーが表示されることがあります。

Network 10.32.0.0/12 overlaps with existing route 10.0.0.0/8 on host
ERROR: Default --ipalloc-range 10.32.0.0/12 overlaps with existing route on host.
You must pick another range and set it on all hosts.

このエラーは、指定されたマシンが他のソフトウェアやローカル・ポリシーをサポートするためにカスタム・ネットワーク構成を行っている場合に、プロバイダ PreExisting で発生することが考えられます。他のネットワークを無効にしたり移動したりすることができない場合は、以下の手順を使用して Weave 構成を代わりに変更できます。

1. ICM コンテナでローカルにある以下のファイルを編集します。

   /ICM/etc/toHost/installWeave.sh
   

   

2. 文字列 weave launch を含む行を見つけます。Weave と既存のネットワークの間に重複が生じる危険がないことが確実ならば、以下に示す下線の付いたテキストを追加することによって、既定の範囲を引き続き使用するように Weave に強制できます。

   sudo /usr/local/bin/weave launch --ipalloc-range 10.32.0.0/12 --password $2 
   

   

   以下のように、Weave を別のプライベート・ネットワークに単に移動することもできます。

   sudo /usr/local/bin/weave launch --ipalloc-range 172.30.0.0/16 --password $2
   

   

3. ファイルを保存します。

4. クラスタの再プロビジョニングを行います。

巨大なページ

一部のアーキテクチャでは、InterSystems IRIS メッセージ・ログに以下のようなエラーが表示される場合があります。

0 Automatically configuring buffers 
1 Insufficient privileges to allocate Huge Pages; nonroot instance requires CAP_IPC_LOCK capability for Huge Pages. 
2 Failed to allocate 1316MB shared memory using Huge Pages. Startup will retry with standard pages. If huge pages 
  are needed for performance, check the OS settings and consider marking them as required with the InterSystems IRIS 
  'memlock' configuration parameter.

icm run コマンドに以下のオプションを指定することによって、このエラーを解消できます。

-options "--cap-add IPC_LOCK"