Common URL for Portal HA Setup for the Internal Load Balancer

Question

Question 1 — Internal Load Balancer Common URL If the Portal for ArcGIS is deployed across two machines with FQDNs such as portal1. and portal2., is it supported to configure the Portal’s common URL (i.e., the internal load balancer endpoint) using a pattern like https://portal.{env}.:7443/arcgis? Question 2 — Certificate SAN Entries If the answer of question 1 is yes then what entries are required as Subject Alternative Names (SANs) on the certificate from below? * portal.{env}. * each individual Portal machine's FQDN (.)? * Or both?

TimoT · Answer

Hi @PinakiPalAccenture, Question 1 — Internal Load Balancer Common URL Yes. Using an internal load balancer endpoint such as https://portal.{env}.:7443/arcgis is a common and supported pattern for highly available ArcGIS Enterprise deployments. Refer to this document for more information - Highly available ArcGIS Enterprise deployment scenarios | ArcGIS Enterprise on Windows and Linux documentation Esri’s HA architecture documentation commonly illustrates the use of using an internal load balancer as the shared endpoint for inter-component communication, for example: * https://internalloadbalancer.example.com:7443/arcgis as the privatePortalURL * https://internalloadbalancer.example.com:6443/arcgis as the ArcGIS Server Administration URL In this model, Portal and Server communicate to each other through the internal load balancer and not directly with one another. Question 2 — Certificate SAN Entries The SAN entries required depend on which component presents the certificate for a given HTTPS connection and where TLS is terminated. In the common case where the internal load balancer terminates TLS, the front-end certificate presented by the load balancer must include the load balancer hostname (e.g. portal.{env}.), since this is the hostname used by both the privatePortalURL and the ArcGIS Server Administration URL. If the load balancer is configured for TLS pass-through, or for TLS bridging with backend certificate validation, then the Portal and ArcGIS Server machine certificates will also need to be valid for the hostnames used in those backend HTTPS connections. The key principle is that certificate validation is based on the hostname used by the TLS client when connecting to the endpoint presenting the certificate. One additional consideration is certificate design. While a single multi-SAN certificate containing the load balancer hostname and all Portal machine FQDNs can be used in some deployments, many organizations prefer to use separate certificates for the load balancer and backend machines. This reduces exposure of internal hostnames in externally presented certificates and allows certificates to be managed and rotated independently. The appropriate approach will vary depending on each organization's requirements.