ArcGIS Enterprise on Kubernetes requires persistent volumes (PVs) for system storage, which can be provisioned dynamically through a storage class or statically by an administrator before creating the organization.
Provision static PVs
If you're provisioning static PVs before deployment, the specifications and labels described below are recommended.
The number of PVs required for each architecture profile are provided.
Note:
Volumes marked with an asterisk (*) are required to configure notebook services as a capability in the organization.
Volume | Enhanced availability profile | Standard availability profile | Development profile |
---|---|---|---|
in-memory-volume | 1 | 1 | 1 |
item-packages-volume | 2 | 2 | 1 |
object-volume | 8 | 3 | 1 |
queue-volume | 2 | 2 | 1 |
relational-volume | 2 | 2 | 2 |
spatiotemporal-and-index-volume | 5 | 3 | 1 |
usage-metric-volume | 1 | 1 | 1 |
arcgis-nb-workspace-volume * | 1 | 1 | 1 |
If you are configuring your organization to use existing static PVs, the following values of each persistent volume claim (PVC) are used to bind it to the PVs through label selection: size, access mode, and labels. These values can be customized in the setup wizard or the configuration properties file to match the preprovisioned PVs to each stateful-set specification.
Volume | Size in GiB (minimum) | Access mode | Label |
---|---|---|---|
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 |
arcgis-nb-workspace-volume * | 100 | ReadWriteMany | N/A |
Note:
If you are provisioning for your deployment, you must provision additional item-packages PVs with the same specifications (labels, size, and access mode) as those specified during deployment to support scaling and upgrade workflows.Create additional PVs to scale the Portal API deployment
To scale the Portal API deployment (to increase the number of participating pods), an additional item-packages PV is required for each pod that is added to the deployment. For example, if the organization requires three additional pods for the Portal API deployment, a minimum of three additional item-packages PVs must be provisioned and configured with equivalent specifications to those specified during deployment.