When deploying ArcGIS Enterprise on Kubernetes, select an architecture profile to suit your organization. Architecture profiles are predefined deployment profiles that correlate to varying levels of redundancy across pods. The profile you choose determines which pods are automatically replicated during setup. Because some organizations require increased levels of resiliency and availability to others, architecture profiles provide flexibility across several known variables such as requirements for hardware, redundancy, and organizational use.
The predefined architecture profiles are described below. The first two are for high availability and the third is for development and nonproduction use.
Architecture profile | Use case | Hardware requirements | Predefined redundancy across pods |
---|---|---|---|
Enhanced availability | Designed for use in business or mission-critical production environments. This profile is designed for the highest level of availability, as it includes increased and expanded redundancy across critical pods. | Maximum | Maximum |
Standard availability | Designed for use in production environments and for those wanting to minimize unplanned downtime with redundancy across many pods. This is the default profile. | Moderate | Moderate |
Development | Designed for use in nonproduction environments, including those for testing and evaluation. This profile is not supported for production environments. | Minimal | Minimal |
When deploying ArcGIS Enterprise on Kubernetes in nonproduction or test environments, use the development option. It requires the least amount of hardware and resources. When deploying to production environments, both high-availability profiles provide continued use and availability in the event of a failure; however, the enhanced profile requires additional hardware.
Replicated pods per architecture profile
As described above, each architecture profile provides a predefined set of replicated pods to support continued workflows in the event of an unexpected failure. An example of a supported workflow for each is provided.
- Enhanced availability—Replicated pods are provided for publishing tools, storage, APIs, and ingress controllers with increased redundancy to support uninterrupted use in the event of unexpected failure or downtime.
- Standard availability—Replicated pods are provided for publishing tools and other essential pods such as storage, APIs, and ingress controllers to support continued use in the event of unexpected failure or downtime.
- Development—Publishing tools are replicated to support multiple publishers in an organization.
A description of each replicated pod-per-architecture profile is provided below.
Replicated pods | Enhanced availability profile | Standard availability profile | Development profile |
---|---|---|---|
Publishing tools | 4 | 3 | 3 |
Relational data store | 2 | 2 | 2 |
Private ingress controller | 3 | 2 | 2 |
Ingress controller | 3 | 2 | |
Administrator API | 2 | 2 | |
Portal API | 2 | 2 | |
Services API | 2 | 2 | |
Notebook automation service | 2 | ||
Queue store | 2 | 2 | |
Object store: mixed | 3 | ||
Object store: metadata | 3 | ||
Object store: data server | 5 | ||
Spatiotemporal and index store: mixed | 3 | ||
Spatiotemporal and index store: coordinator | 3 | ||
Spatiotemporal and index store: data | 2 | ||
Shared feature service | 2 | 2 | |
Shared image service | 2 | 2 | |
Shared map service | 2 | 2 | |
Shared tile service | 2 | 2 |