ArcGIS Enterprise on Kubernetes 11.0 を実行するために必要な最低限のハードウェアおよびインフラストラクチャについて以下に説明します。 これらの要件は、インターネット非接続環境にデプロイする場合にも適用されます。
サポート環境
システム要件および仕様は、注意書きがない限りサポートされているすべての環境に適用されます。 このリリースでは、次の環境がサポートされています。
- オンプレミス データ センター
- Red Hat OpenShift Container Platform
- クラウド上のマネージド Kubernetes サービス
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
このリリースでは、各環境の次のバージョンはテスト済みで、サポートされています。
| ArcGIS Enterprise on Kubernetes | AKS | EKS | GKE | Red Hat OpenShift |
|---|---|---|---|---|
既存の Kubernetes クラスターに 11.0 をデプロイ | 1.21 - 1.24 | 1.21 - 1.24 | 1.21 - 1.24 | 4.7 ～ 4.10 |
11.0 のデプロイメント後に既存の Kubernetes クラスターをアップグレード | サポート対象外 | サポート対象外 | サポート対象外 | N/A |
注意:
GIS サービスで自動スケーリングを有効化するには、ノード指標を収集するためのメトリクス サーバーが必要です。 EKS 環境にデプロイする場合、kube-system 名前空間にメトリクス サーバーをクラスターレベルの権限でインストールする必要があります。 その他のサポート環境では、メトリクス サーバーはデフォルトでインストールされます。
コンテナー レジストリ
ArcGIS Enterprise on Kubernetes のコンテナー イメージは、プライベートの Docker Hub リポジトリからアクセスできます。 Esri は、ArcGIS Enterprise on Kubernetes をデプロイしているユーザーに、このリポジトリへのアクセス権を提供します。 非接続環境にデプロイする場合、組織のコンテナー レジストリを使用する必要があります。
Esri ライセンスの取得
デプロイの際に ArcGIS Enterprise 組織を認証するには、JSON 形式 (.json ファイル) の ArcGIS Enterprise on Kubernetes ライセンス ファイルが必要です。 このライセンス ファイルを取得するには、ライセンス アクションを実行する権限を使用して My Esri にアクセスします。
Kubernetes クラスター
ArcGIS Enterprise on Kubernetes をデプロイするには、上記の環境のいずれかに Kubernetes クラスターが必要です。
注意:
GKE でクラスターを作成するときは、Standard mode でオペレーションを使用する必要があります。 Autopilot モードはサポートされていません。
注意:
EKS で Kubernetes 1.23 以降でクラスターを作成またはアップロードするときは、Amazon EBS Container Storage Interface (CSI) アドオンをインストールする必要があります。 詳細については、Amazon EKS のドキュメントをご参照ください。
名前空間
ArcGIS Enterprise on Kubernetes は、独自の専用名前空間が必要です。 名前空間は、デプロイメントスクリプトの実行前に作成しておく必要があります。 また、ArcGIS Enterprise on Kubernetes の各デプロイメントに専用の名前空間が必要です。
CPU とメモリ
ArcGIS Enterprise on Kubernetes は、3 つのアーキテクチャ プロファイルのいずれかを使用してデプロイされます。 リソース (CPU とメモリ) の要求と制限および全体的な計算要件の推奨事項は、選択したプロファイルによって異なります。 各プロファイルの推奨事項を以下に示します。
各アーキテクチャ プロファイルの最小ノード要件は以下のとおりです。 各ワーカー/エージェント ノードには、8 CPU および 32 GiB のメモリ以上を推奨します。
| アーキテクチャ プロファイル | 最小ワーカー/エージェント ノード | 最小 CPU の合計 | 最小 GiB の合計 |
|---|---|---|---|
Standard availability | 4 | 32 | 128 |
Enhanced availability | 5 | 40 | 160 |
開発 | 3 | 24 | 96 |
注意:
ArcGIS Enterprise on Kubernetes は、x86_64 アーキテクチャ (64 ビット) に準拠した CPU のみでサポートされています。
ArcGIS Enterprise on Kubernetes デプロイメント内のポッドは、クラスター内のワーカー ノード全体に分散しています。 デプロイメントをスケーリングする場合や、別の ArcGIS Enterprise デプロイメントをクラスターに追加する場合は、ハードウェアを適切にプロビジョニングする必要があります。 これには、ノードあたりの最大ポッド数のデフォルト値を増やす必要がある場合があります。 最初に作成されるポッドの数は、アーキテクチャ プロファイルによって異なります。 水平方向にスケールするか、新しい機能を追加すると、ポッド数が増加します。
注意:
ArcGIS Enterprise on Kubernetes は、GKE 環境で Windows Server ノードの画像をサポートしていません。
リソース クォータ オブジェクト
ArcGIS Enterprise on Kubernetes のポッドは、CPU およびメモリへの要求と制限を定義しています。 名前空間に ResourceQuota オブジェクトがある場合は、クォータはすべてのポッドの要求と制限の合計より高い必要があります。 これらの値は、下で説明するように、選択したアーキテクチャ プロファイルによって異なります。
注意:
11.0 へのアップグレードを実行している場合は、まず名前空間のリソース クォータ値を 11.0 の要件に更新する必要があります。
クラスター ノードが適切に機能するように、要求リソースの少なくとも 10% は確保しておくことをお勧めします。
上記の確保に基づくと、各プロファイルのクォータの推奨事項は次のとおりです。 示されている制限値はプレースホルダーで、自社のスケーラビリティ要件に基づいて構成する必要があります。
標準の可用性プロファイル:
spec:
hard:
limits.cpu: "164"
limits.memory: 272Gi
requests.cpu: "24"
requests.memory: 108Gi
高い可用性プロファイル:
spec:
hard:
limits.cpu: "192"
limits.memory: 328Gi
requests.cpu: "30"
requests.memory: 156Gi
開発プロファイル:
spec:
hard:
limits.cpu: "120"
limits.memory: 188Gi
requests.cpu: "16"
requests.memory: 72Gi
セキュリティ
以下に、ArcGIS Enterprise on Kubernetes のセキュリティ要件を説明します。
ロールベースのアクセス制御
Kubernetes クラスターでロールベースのアクセス制御 (RBAC) が有効になっている必要があります。 ArcGIS Enterprise on Kubernetes のデプロイでは、cluster-admin 権限は必要ありません。 cluster-admin 権限がない場合、ユーザーは最小の名前空間管理権限を持っている必要があります。 名前空間に RoleBinding を作成することで、ユーザーに defaultClusterRole 管理権限を割り当てることができます。
Pod セキュリティ ポリシー (OpenShift のセキュリティコンテキストの制約) と仮想メモリ
ArcGIS Enterprise on Kubernetes は Elasticsearch をデプロイして ArcGIS Enterprise の組織のさまざまな機能をサポートします。 デフォルトでは、Elasticsearch は mmapfs ディレクトリを使用して必要なインデックスを格納します。 オペレーティング システムのデフォルトのマップ数の制限は、デプロイメントには不十分です。 Elasticsearch は、vm.max_map_count のデフォルト値として 262144 を推奨します。 デフォルト値を変更するには、各ノードで上位 (ルート) 権限が必要です。
Kubernetes クラスターにポッド セキュリティ ポリシーが含まれており、コンテナーを権限付きまたは権限なしとして実行できるかどうかに応じて、次のアクションが必要です。
- Kubernetes クラスターにポッド セキュリティ ポリシーが含まれていないが、コンテナーを権限付きとして実行できる場合は、アクションは必要ありません。
- 権限付きで実行 - Kubernetes クラスターにポッド セキュリティが定義されており、コンテナーを権限付きとして実行できる場合は、Elasticsearch サービス アカウントがコンテナーを権限付きとして実行できるようにする必要があります。 他のサービス アカウントは、コンテナーを権限付きとして実行する必要はありません。 ArcGIS Enterprise on Kubernetes は Elasticsearch を実行しているノードで権限付きの init コンテナーを実行できます。これにより、vm.max_map_count 値が変更されます。 ArcGIS Enterprise on Kubernetes デプロイメントスクリプトが名前空間の下にサービス アカウントを作成し、ポッド内のプロセスに対して API Server 認証を使用します。 Elasticsearch のポッドでは独自のサービス アカウントを使用しますが、これは他のワークロードとは共有されません。 デフォルトの Elasticsearch サービス アカウントは arcgis-elastic-serviceaccount です。 RBAC ロールと RoleBindings を使用し、サービス アカウントにポッド セキュリティ ポリシーへのアクセス権を付与できます。 OpenShift の場合は、ユーザー セクションに以下を追加することで、このサービス アカウントに、権限付きのセキュリティ コンテキスト制約へのアクセスを許可することができます。
“-system:serviceaccount: <Namespace>:arcgis-elastic-serviceaccount" - 権限なしで実行 - Kubernetes クラスターにポッド セキュリティが定義されており、ElasticSearch サービス アカウントでコンテナーを権限付きで実行することを許可できない場合、ルートで次のコマンドを実行し、各ノードを手動で準備する必要があります。
sysctl -w vm.max_map_count=262144 - PodSecurityPolicy リソースを作成した場合、ArcGIS Enterprise 名前空間で次のサービス アカウントを認証する必要があります。
- arcgis-admin-serviceaccount
- arcgis-elastic-serviceaccount
- arcgis-ingress-serviceaccount
- arcgis-prometheus-serviceaccount
- arcgis-queue-serviceaccount
- default
ArcGIS Enterprise on Kubernetes コンテナーは、ルート権限なしで実行できます。 ただし、PodSecurityPolicy の fsGroup および supplementalGroups の制御面には、以下の例に示すように、RunAsAny か、値 117932853 を含む範囲が必要です。
supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny'supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 117932853 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 117932853
Kubernetes の NetworkPolicies を使用する場合、中断されないポッド間通信とポッドからサービスへの通信が ArcGIS Enterprise の名前空間で許可されていることを確認します。
また、名前空間内のポッドが Kubernetes API サーバーにアクセスできることを確認します。 API サーバーには、デフォルトの名前空間内にある Kubernetes という名前のサービスを通じてアクセス可能です。 ArcGIS Enterprise ポッドでは完全修飾ドメイン名 (FQDN) kubernetes.default.svc.cluster.local を使用して API サーバーのクエリを実行します。
注意:
クラスターのデフォルト ドメインは cluster.local です。
注意:
クラスター内のポッドは、FSGroup および SupplementalGroup ID が 117932853 での実行を許可されている必要があります。
データ フォルダーの登録
ファイルベースのデータ (ファイル ジオデータベースから公開されたアイテムなど) を使用してアイテムを公開するには、データを NFS で共有された位置に配置する必要があります。 データの公開中にデータがサーバーにコピーされないよう、この NFS 共有を ArcGIS Enterprise 組織に登録する必要があります。 共有フォルダーを正常に登録するには、他のユーザーにファイル レベルの読み取り権限を付与する必要があります。 ポッドの IP 範囲へのネットワーク アクセスを許可することで、ネットワークまたはインフラストラクチャ レベルで NFS 共有を保護できます。
ネットワーク
ネットワーク要件には、FQDN とロード バランサーが含まれます。 それぞれの詳細を以下に示します。
完全修飾ドメイン名
ArcGIS Enterprise on Kubernetes は FQDN (たとえば map.company.com) が必要です。 完全修飾ドメイン名は、既存のドメイン名システム (DNS)、または Amazon Route 53 などのクラウド DNS サービスを使用して作成することができます。 デプロイ後、DNS レコードを作成できますが、その値はデプロイしている間に指定する必要があります。 このリリースでは、デプロイ後に FQDN を変更することはできません。
ロード バランサー
各ワーカー ノードでトラフィックを転送するには、ロード バランサーが必要です。 AKS または EKS を使用している場合は、デプロイメントスクリプトから次のロード バランサーをプロビジョニングできます。手動による構成は不要です。
- Azure Load Balancer (パブリック向けまたは内部向け) - プロビジョニングされる静的なパブリック IP アドレスおよび DNS ラベルは、デプロイメントスクリプトで指定できます。
- AWS Network Load Balancer (インターネット向けまたは内部向け) - その他のロード バランシング サービスを使用できます。ただし、クラスター ノードごとに手動で構成する必要があります。
注意:
パブリックまたはプライベート サブネットにネットワーク ロード バランサーを作成するには、AWS Load Balancer Controller アドオンが必要です。
OpenShift Container Platform は、ingress コントローラー サービスに向いているときにルートを設定できます。
ingress コントローラー サービスの NodePort のワーカー ノードに向いている自己管理ロード バランサーを使用することができます。 詳細については、ロード バランサーのデプロイメントガイドのパラメーターの説明をご参照ください。
セルフマネージド ロード バランサーまたは NGINX などのリバース プロキシを使用している場合は、次の接続を指定します。proxy_set_header X-Forwarded-Host $host; このヘッダーは、トラフィックが ArcGIS Enterprise 組織の URL に適切にルーティングされるようにするために必要です。
IP 要件
正常なデプロイメント、適切なスケーリング要件、アップグレード機能を確保するためには、クラスター ネットワークを事前に計画することが必要です。 ArcGIS Enterprise on Kubernetes が最初にデプロイするポッドの数は、アーキテクチャ プロファイルに応じて 47 ～ 66 個です。 機能の追加、デプロイメントのスケーリング、アップグレード処理に伴い、ポッドの数が増加します。
各ポッドには一意の IP アドレスが割り当てられます。また、クラスター ネットワークの構成に応じて、ポッドは、ホスト ネットワーク (オーバーレイ ネットワーク) とは論理的に異なるアドレス空間から、またはホスト サブネットから IP アドレスを取得できます。 たとえば、Azure で Kubernet を使用するようクラスターを構成した場合 (デフォルト)、ポッドは論理的に異なるアドレス空間から IP アドレスを取得し、NAT を使用して Azure リソースにアクセスできるようになります。
Kubernetes は CNI (Container Network Interface) と、プラットフォーム固有の CNI プラグインをクラスター ネットワークで使用するプラットフォーム (AKS や EKS など) をサポートしています。 たとえば、EKS クラスターはデフォルトで VPC (Virtual Private Cloud) CNI を使用します。 クラスターに CNI プラグインが構成されている場合、ポッドは、ホスト サブネットと、VPC/VNet で利用可能な対応 IP プールから IP アドレスを取得します。
ホスト サブネットで使用できる IP の数が十分ではない場合、デプロイメントは失敗するか、デプロイメントをスケーリングできません。 たとえば、EKS クラスターにそれぞれ 2 個のサブネットと /26 IPv4 アドレス接頭辞 (それぞれ 64 個の IPv4 アドレスを使用可能) が構成されている場合、ポッドで使用できる IP アドレス数は 126 個を超えることはできません。 このクラスターに ArcGIS Enterprise on Kubernetes をデプロイできますが、80 個のフィーチャ サービス ポッドを持つようこのデプロイメントをスケーリングすることはできません。このスケーリング要件では、利用可能な IP アドレスの数を超過してしまいます。
システム ストレージ
ArcGIS Enterprise on Kubernetes は、システム ストレージとして永続ボリューム (PVs) が必要です。 PVs は動的または静的なボリュームとしてプロビジョニングできます。 いずれのタイプの PVs を作成する場合も、サイズを大きくしたりラベルを変更したりしてカスタマイズできます。 ArcGIS Enterprise のステートフル ワークロードには、リレーショナル データベース管理システムと NoSQL データベースが含まれます。 EBS ボリューム、Azure ディスク、vSphereVolume など、低遅延のブロック ストレージ デバイスの使用をお勧めします。
これらの永続ボリュームはデータと設定を格納するため、制限付きセキュリティ ポリシーを使用して保護する必要があります。 NFS、Azure ファイル、Gluster など、ファイル ベースのストレージに基づく永続ボリュームの場合、ディレクトリに対する権限が不正なアクセスを防ぐように設定されていることを確認します。 EBS ボリューム、Azure ディスク、iSCSI などのブロック ストレージの場合は、ブロック デバイスがアクセスを必要とするユーザーのみに制限されていることを確認します。
ストレージ ボリュームの説明と使用目的は次のとおりです。
注意:
11.0 の永続ボリューム要件が記載されており、前のバージョンとは異なる可能性があります。
- インメモリー - 一時システム リソースを格納します。
- アイテム パッケージ - 公開ワークフローをサポートするサイズの大きいアップロードとパッケージを格納します。
- オブジェクト - アップロードおよび保存されたコンテンツ、ホスト タイル/イメージ レイヤー キャッシュ、およびジオプロセシングの出力を格納します。 デプロイメント用に 4 つ必要です。
- キュー - 非同期ジオプロセシング ジョブを格納します。
- リレーショナル - ホスト フィーチャ データと、カスタマイズや構成設定などの管理面の情報を格納します。 デプロイメント用に 2 つ必要です。
- 時空間およびインデックス - ログとインデックスのほか、ホストフィーチャ データを格納します。
- Usage metric data - GIS サービス使用状況データを格納します。
組織に合ったストレージ要件を検討し、各 PV のサイズを状況に応じて適切に定義してください。
静的 PVs
デプロイの前に静的 PV のプロビジョニングを行っている場合は、次の仕様およびラベルの使用をお勧めします。
各アーキテクチャ プロファイルに必要な PVs の数が提供されています。
| 体積 | Development プロファイル | Standard availability プロファイル | Enhanced availability プロファイル |
|---|---|---|---|
in-memory-volume | 1 | 1 | 1 |
item-packages-volume | 1 | 2 | 2 |
object-volume | 1 | 3 | 8 |
queue-volume | 1 | 2 | 2 |
relational-volume | 2 | 2 | 2 |
spatiotemporal-and-index-volume | 1 | 3 | 5 |
usage-metric-volume | 1 | 1 | 1 |
セットアップ ウィザードを使用して組織サイトを構成するとき、次のような仕様 (ボリューム名、サイズ、アプリ、層) をボリュームのバインドに使用できます。ただし、これらは必要に応じてカスタマイズできます。
| 体積 | GiB 単位の容量 (最小) | アクセス モード | ラベル |
|---|---|---|---|
in-memory-volume | 16 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=ignite |
item-packages-volume | 16 | ReadWriteOnce | arcgis/tier=api, arcgis/app=sharing |
object-volume | 32 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=ozone |
queue-volume | 16 | ReadWriteOnce | arcgis/tier=queue, arcgis/app=rabbitmq |
relational-volume | 16 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=postgres |
spatiotemporal-and-index-volume | 16 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=elasticsearch |
usage-metric-volume | 30 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=prometheus |
静的 PVs のその他の注意事項
デプロイしている間に構成したプロビジョニング済みのストレージのタイプは、アップグレードと拡張の要件を決定します。
ポータル API デプロイメントを拡張するための静的 PVs の調整
ポータル API デプロイメントを拡張する (関連するポットの数を増やす) には、デプロイメントに追加される追加のポッドごとに、追加のアイテムパッケージ PV が必要です。 たとえば、組織のポータル API デプロイメントに 3 つのポッドが追加で必要な場合、デプロイしている間の指定と同等の仕様を使用して、最低 3 つのアイテムパッケージ PVs をプロビジョニングおよび構成する必要があります。
動的 PVs
動的なプロビジョニングの場合、StorageClass が必要です。
StorageClass の reclaimPolicy パラメーターは retain に設定する必要があります。
注意:
すべての VM タイプが Azure のプレミアム ディスクをサポートしているわけではありません。 プレミアム ディスクは、VM タイプがサポートしている場合に使用します。- 以下は、AKS で Azure Premium ディスクにより StorageClass を定義した例です。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: arcgis-storage-default provisioner: kubernetes.io/azure-disk parameters: kind: Managed storageaccounttype: Premium_LRS reclaimPolicy: Retain allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer - 以下は、EKS で、GP2 タイプの EBS ボリュームにより StorageClass を定義した例です。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: arcgis-storage-default provisioner: kubernetes.io/aws-ebs parameters: fsType: ext4 type: gp2 reclaimPolicy: Retain allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer
AKS または EKS クラスターとともに提供されるデフォルトのストレージクラスを使用することもできます。 AKS では、default (Azure disk) または managed-premium ストレージ クラスです。 EKS では、GP2 ストレージ クラスです。
クライアント ワークステーション
デプロイメント スクリプトは、リモートのクライアント ワークステーションから実行できる Bash スクリプトです。
注意:
使用されるクライアント ワークステーションは、サポートされている環境に準拠している必要があります。 ArcGIS Enterprise on Kubernetes のデプロイでは、Linux エミュレーターはサポートされていません。
クライアント ワークステーションの設定時に以下が必要です (ダウンロード用リンクを記載しています)。
- Kubectl
- 環境固有のコマンド ライン インターフェイス (CLI)
Kubectl は、デプロイメントスクリプトの実行前に必ず必要です。 Kubectl のインストールとセットアップを使用して Kubernetes コマンド ライン ツールをダウンロードします。
デプロイメントを管理する場合は、環境固有のコマンド ライン ツールを使用できます。 次のリンクを使用して、環境固有の CLI をダウンロードしてください。
TLS 証明書
ArcGIS Enterprise on Kubernetes は、NGINX ベースの ingress コントローラーを使用します。 この ingress コントローラーは、スコープされた名前空間であり、ArcGIS Enterprise の名前空間への ingress トラフィックのみを待機するようにデプロイされます。 TLS 証明書は、証明書の共通名と Subject Alternative Names (サブジェクトの代替名) に FQDN が含まれている必要があります。 CA 署名証明書または自己署名証明書を使用できますが、セキュリティ上の理由から、CA 署名証明書をお勧めします。 これは、ingress コントローラーのデフォルトの TLS 証明書です。 デプロイメントスクリプトでは、次の証明書オプションを使用して ingress トラフィックに TLS 証明書を適用できます。
- プライベート キーと証明書を含む既存の TLS シークレット
- プライベート キーと証明書を含む .pfx ファイル
- PEM 形式のプライベート キーと証明書
- 自己署名証明書
ArcGIS Enterprise on Kubernetes では、ingress コントローラーに対し、Kubernetes cert-manager によって発行および管理された TLS 証明書を使用できます。 この証明書は、ArcGIS Enterprise と同じ名前空間の TLS シークレットに格納する必要があります。 TLS シークレットは、デプロイしている間または ArcGIS Enterprise 組織の作成後に参照される可能性があります。
ArcGIS Pro
- ArcGIS Pro 3.0 は ArcGIS Enterprise on Kubernetes 11.0 のコンパニオン リリースです。 利用可能な最新機能を入手するには、ArcGIS Pro 3.0 をご使用ください。
- ArcGIS Enterprise on Kubernetes にサービスを公開するには、ArcGIS Pro 2.8 以降が必要です。
- ArcGIS Enterprise on Kubernetes のサービスを使用するには、ArcGIS Pro 2.7 以降が必要です。
エンタープライズ ジオデータベースからデータ ストア アイテムを登録する場合、ジオデータベースのバージョンは 10.9.0.2.8 以降でなければなりません。
注意:
利用可能な最新機能を活用するには、ジオデータベースのバージョンを 11.0.0.3.0 にアップグレードしてください。アップデートとアップグレードの要件
アップグレードを実行する前に、次のようないくつかの要件を満たす必要があります。
- 必要なアップデートが利用可能であれば、このリリースにアップグレードする前に適用する必要があります。 最新の必要なアップデートの詳細については、リリース ノートをご参照ください。
- このリリースには、ArcGIS Enterprise on Kubernetes の統合ライセンスが必要です。
- 現在の要件を満たすには、名前空間のリソース クォータ値を更新する必要があります。
- 静的 PVs をプロビジョニングした場合、アップグレード要件に対応できるよう、追加のストレージをプロビジョニングする必要があります。 詳細については「アップグレードのための静的 PVs の調整」セクションをご参照ください。
- プロビジョニングしたストレージに動的 PVs がある場合、追加のアイテムパッケージ、オブジェクト ボリューム、キュー ボリュームに十分なストレージを提供できることを確認する必要があります。
- バージョン 10.9.1 からアップグレードする場合、各アーキテクチャ プロファイルの新しいオブジェクト ストア PVs に対応できるよう、50% 以上のストレージを追加でプロビジョニングする必要があります。 たとえば、各オブジェクト ストア ポッドに対し、オブジェクト ストア PV に 100GB のストレージを割り当てた場合、少なくとも 150GB の追加ストレージをプロビジョニングする必要があります。
- プレアップグレード スクリプトを実行します。 このスクリプトは、現在のソフトウェア リリースに対応するよう、さまざまな機能要件を検出し、対処します。
- 組織で Web Adaptor を構成した場合は、インストールとアップグレードの要件をご確認ください。
- 非接続環境の組織の場合、非接続環境でアップグレードまたはアップデートを適用する手順を実行します。
- ArcGIS Enterprise on Kubernetes のデプロイ時に組織のコンテナー レジストリを使用した場合は、アップデートやアップグレードを実行する前に、必要なコンテナー イメージを Esri リポジトリから組織のレジストリへコピーする必要があります。
アップグレードのための静的 PVs の調整
アップグレードの前には、組織のポータル API とキュー ストアのデプロイメント内の各ポッドは、それぞれアイテムパッケージまたはキューボリューム PV を使用して構成されています。 アップグレードの準備中は、追加の PV を使用して、ポータル API およびキュー ストアのデプロイメント内の各ポッドを構成する必要があります。
たとえば、アップグレードの前にキュー ストアまたはポータル API デプロイメントが 3 つの実行中のポッドで構成されている場合、デプロイしている間の指定と同等の仕様を使用して、追加で 3 つの PVs をプロビジョニングおよび構成する必要があります。
アップグレードが完了すると、ポータル API またはキュー ストアのデプロイメントは新たにプロビジョニングされた永続ボリュームと永続ボリューム クレームを使用するようになり、元のセットは削除できます。
以下のテーブルに従ってアップグレードする際は、オブジェクト ストアのデプロイメントに対して静的 PVs を追加でプロビジョニングする必要があります。
| デプロイメントのタイプ | デフォルトの静的オブジェクトボリューム PVs | アップグレードのために必要な追加の静的 PVs |
|---|---|---|
Development プロファイル | 1 | 1 つの PV を追加で作成 |
Standard availability プロファイル | 3 | 3 つの PV を追加で作成 |
Enhanced availability プロファイル | 8 | 8 つの PV を追加で作成 |