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
| Benefits | Drawbacks |
|---|---|
|
|
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 in an Okta org, containing users outside other LDAP or Active Directory 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. |
| 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. |
|
|
Protected applications |
The set of protected web resources, accessed using the protd-N.internal-example.com URLs. |
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.