Multiple data center architecture

The multiple data center Access Gateway architecture represents the set of components required to deploy Access Gateway in a high performing, fault tolerant multi-data center environment.

Typically this architecture is where active-active or active-warm standby data centers are required, although fail over can be provided at multiple levels in this architecture. As shown this architecture depicts an active-active configuration where each datacenter has fault tolerance built in. This architecture is for highly available applications where the application is configured to run in both datacenters at the same time.
This architecture is designed to meet the following requirements:

  • Providing secure access to a set of applications, accessed from the external internet, although a similar approach can be done for internal only accessible applications.
  • Support user access by data centers, selected by location, or other criteria to improve access rates
  • Provide a high level of performance, including fault tolerant load balancers both within each data center and across data centers (the app will remain accessible if any single component is lost inside the DC, or if an entire DC is not available)
  • Provide a high level of fault tolerance inside of each data center:
    • Load balancer level - one load balancer per data center at the Access Gateway and protected application levels
    • Access Gateway workers segmented by data center, with a single admin node
    • Protected web resources replicated at the data center level

BenefitsDrawbacks
  • Extremely fault tolerant
  • Extremely high performing
  • Provides failover at multiple levels or locations within the architecture
  • Complex
  • Additional hardware / virtual servers needed for redundancy

Architecture

Components

Location Component Description
External internet Web clients

Traditional client browser accessing Access Gateway using known as [appN|consumer-app1].example.com URLs.

appN.example.com
URLs not shown
URL representing one of the applications an external web client would enter to access one of the applications secured by Access Gateway. Typically all URLs of this nature are served by, and resolve to, the Access Gateway instance.
Okta org

Your Okta org, providing identity services.

Okta org Universal Directory

Okta universal directory, housed within an Okta org, containing users outside other LDAP/AD implementations. Typically these include other customer accounts, partner accounts and more.

Firewall

External internet to DMZ

Traditional firewall between the external internet and the DMZ hosting Access Gateway.

DMZ

Pre Access Gateway load balancers

Load balancers for the DMZ based Access Gateway cluster.
Potentially providing failover between data centers.

Access Gateway workers Access Gateway instances, distributed in both data centers but sharing an administration instance.
Workers use DNS to select the appropriate protected web resources.

Firewall

DMZ to internal firewall

Traditional firewall between DMZ and the internal network.

Internal network Access Gateway admin Access Gateway admin node, in any of the data centers handling configuration, configuration backups, log forwarding and similar activities.
Access by administrators within the internal network.

Pre internal Access Gateway load balancers

Load balancers between Access Gateway and the protected web resources.
Potentially providing failover between data centers.
See Load balancing.

Protected applications
URLs not shown

The set of protected web resources, accessed using the protd-N.internal-example.com URLs.
Replicated set of highly available back end protected web resources.

Other considerations

Geographic or other load balancing techniques such as DNS round robin have been deployed to route session traffic to the different data centers. This data center routing should be “sticky” (session affinity) and route the user to the same data center for the life of the session or until a data center is no longer accessible.
SSL may be terminated on either the Load balancers or the Access Gateway servers themselves. if SSL is terminated on the Load balancers the communications from the LB to OAG must be over SSL, but a self signed certificate on Access Gateway may be used.

Most architectures forward log events to an external syslog component. Okta strongly recommends that a logging server be configured for all Access Gateway environments. See Configure log forwarders.

Related topics

Common Access Gateway flows

DNS use

High availability

About Access Gateway prerequisites