ICM の分散管理モードでは、Hashicorp の Consul サービス検出ツールを使用して、ネットワーク接続された任意の場所にいる複数のユーザに、単一の ICM 導入環境への管理アクセス権が付与されます。これは、複数の ICM コンテナを使用することで実行されます。各 ICM コンテナには、必要な状態ファイルを保存する 1 つ以上の Consul サーバでクラスタ化された Consul クライアントが 1 つずつ含まれます。
分散管理モードの構成
プライマリ ICM コンテナおよび Consul クラスタを作成するには、以下の操作を行います。
-
ConsulServers フィールドを defaults.json ファイルに追加して、以下のように Consul サーバの数を指定します。
“ConsulServers”: “3”
指定可能な値は、1、3、および 5 です。単一 Consul サーバは、単一障害点となるため、お勧めしません。5 台のサーバによるクラスタは、3 台のサーバによるクラスタより信頼性が高まりますが、コストも高くなります。
-
definitions.json ファイルに、CN ノード定義を追加します。このとき、ConsulServers フィールドの値以上の数の CN ノードを指定します。以下に例を示します。
{
"Role": "CN",
"Count": "3",
"StartCount": "7",
"InstanceType": "t2.small"
}
-
ICM コンテナで、プライマリ ICM の docker run コマンドに consul.sh スクリプトを追加します。
docker run --name primary-icm --init -d -it --cap-add SYS_TIME
intersystems/icm:2022.2.0.221.0 consul.sh
プライマリ ICM コマンド行で、icm provision コマンドを発行すると、各 CN ノードがプロビジョニングされる際に、それらの各 CN ノードに Consul サーバが、指定したサーバ台数に達するまで導入されます。このコマンドが正常に完了すると、プライマリ ICM は状態ファイルを Consul クラスタにプッシュします。その出力にはセカンダリ ICM の作成コマンドが含まれます。プライマリ ICM で、インスタンス・ファイルを変更する可能性のあるコマンド (icm run や icm upgrade など) を次に発行すると、プライマリ ICM は新しいファイルを Consul クラスタにプッシュします。プライマリ ICM で icm unprovision コマンドを使用して導入のプロビジョニング解除を行うと、その状態ファイルは Consul クラスタから削除されます。
icm provision コマンドによる出力で提供されるセカンダリ ICM の icm run コマンドには暗号化キー (16 バイト、Base64 でエンコードされたもの) が含まれ、新しい ICM コンテナは Consul クラスタに参加することができます。以下に例を示します。
docker run --name icm --init -d -it --cap-add SYS_TIME intersystems/icm:2022.2.0.221.0
consul.sh qQ6MPKCH1YzTb0j9Yst33w==
セカンダリ ICM 作成コマンドは、必要なだけ何回でも、導入へのネットワーク・アクセスがある任意の場所で使用できます。
プライマリ ICM コンテナとセカンダリ ICM コンテナの両方で、consul members コマンドを使用して、Consul クラスタに関する情報を表示できます。以下に例を示します。
/Samples/GCP # consul members
Node Address Status Type Build Protocol DC Segment
consul-Acme-CN-TEST-0002.weave.local 104.196.151.243:8301 failed server 1.1.0 2 dc1 <all>
consul-Acme-CN-TEST-0003.weave.local 35.196.254.13:8301 alive server 1.1.0 2 dc1 <all>
consul-Acme-CN-TEST-0004.weave.local 35.196.128.118:8301 alive server 1.1.0 2 dc1 <all>
3be7366b4495 172.17.0.4:8301 alive client 1.1.0 2 dc1 <default>
e0e87449a610 172.17.0.3:8301 alive client 1.1.0 2 dc1 <default>
以下に示したように、Consul コンテナは、icm ps コマンドの出力にも含まれます。
Samples/GCP # icm ps
Pulling from consul cluster...
CurrentWorkingDirectory: /Samples/GCP
...pulled from consul cluster
Machine IP Address Container Status Health Image
------- ---------- --------- ------ ------ -----
Acme-DM-TEST-0001 35.227.32.29 weave Up weaveworks/weave:2.3.0
Acme-DM-TEST-0001 35.227.32.29 weavevolumes-2.3.0 Created weaveworks/weaveexec:2.3.0
Acme-DM-TEST-0001 35.227.32.29 weavedb Created weaveworks/weavedb:2.3.0
Acme-CN-TEST-0004 35.196.128.118 consul Up consul:1.1.0
Acme-CN-TEST-0004 35.196.128.118 weave Up weaveworks/weave:2.3.0
Acme-CN-TEST-0004 35.196.128.118 weavevolumes-2.3.0 Created weaveworks/weaveexec:2.3.0
Acme-CN-TEST-0004 35.196.128.118 weavedb Created weaveworks/weavedb:2.3.0
Acme-CN-TEST-0002 104.196.151.243 consul Up consul:1.1.0
Acme-CN-TEST-0002 104.196.151.243 weave Up weaveworks/weave:2.3.0
Acme-CN-TEST-0002 104.196.151.243 weavevolumes-2.3.0 Created weaveworks/weaveexec:2.3.0
Acme-CN-TEST-0002 104.196.151.243 weavedb Created weaveworks/weavedb:2.3.0
Acme-CN-TEST-0003 35.196.254.13 consul Up consul:1.1.0
Acme-CN-TEST-0003 35.196.254.13 weave Up weaveworks/weave:2.3.0
Acme-CN-TEST-0003 35.196.254.13 weavevolumes-2.3.0 Created weaveworks/weaveexec:2.3.0
Acme-CN-TEST-0003 35.196.254.13 weavedb Created weaveworks/weavedb:2.3.0
Note:
ICM コマンドには並行処理の制御が適用されないため、複数の ICM コンテナで競合するコマンドを同時に発行すると、一部のコマンドが失敗します。結果はタイミングに基づき、エラーが含まれる場合があります。例えば、異なるコンテナの 2 人のユーザが同時に icm rm -machine Acme-DM-TEST-0001 コマンドを発行したとします。一方のユーザには、以下が表示されます。
Removing container iris on Acme-DM-TEST-0001...
...removed container iris on Acme-DM-TEST-0001
他方のユーザには、以下が表示されます。
Removing container iris on Acme-DM-TEST-0001...
Error: No such container: iris
ただし、競合が存在しない場合、同じコマンドを同時にエラーなしに実行することができます。例えば、icm rm -machine Acme-DM-TEST-0001 コマンドや icm rm -container customsensors -machine Acme-DM-TEST-0001 コマンドです。
分散管理モードを使用した ICM のアップグレード
"分散管理モードの概要" で説明したように、分散管理モードでは導入の状態ファイルが Consul クラスタに保存されるので、これらのファイルを失うことなく、ICM コンテナを簡単にアップグレードできます。
最新バージョンを使用するという利点のほかに、インターシステムズのコンテナをアップグレードするときにも ICM のアップグレードが必要になります。ICM を起動するイメージと導入するインターシステムズのイメージのメジャー・バージョンが一致している必要があるためです。例えば、2022.1 バージョンの ICM を使用して 2022.2 バージョンの InterSystems IRIS を導入することはできません。そのため、インターシステムズのコンテナをアップグレードする前に ICM をアップグレードする必要があります。
分散管理モードで ICM コンテナをアップグレードするには、以下の手順を使用します。
-
プライマリ ICM コンテナによるプロビジョニングの終了時に提供されるセカンダリ ICM の icm run コマンドを使用して ("分散管理モードの構成" を参照)、アップグレード先の ICM イメージからセカンダリ ICM コンテナを作成します (異なる ICM イメージから作成されたプライマリ ICM コンテナとセカンダリ ICM コンテナは互換性があります)。
-
プライマリ ICM コンテナで、コマンド consul.sh show-master-token を発行して Consul トークンの値を取得します。
-
アップグレードされたセカンダリ ICM コンテナで、コマンド consul.sh convert-to-thick Consul_token を発行して、それをプライマリ ICM コンテナに変換します。
-
docker stop と docker rm を使用して、古いプライマリ ICM コンテナを停止して削除します。
現在の導入環境を管理している ICM コンテナをアップグレードする際にはこの方法が推奨されるので、分散管理を使用するかどうかに関係なく、このオプションを使用できるように、ICM を使用するたびにプライマリ ICM コンテナを作成することをお勧めします。