Architecture de centres de données multiples

L'architecture Access Gateway multi-centres de données désigne l'ensemble des composants nécessaires au déploiement d'Access Gateway dans un environnement multi-centres de données hautement performant et tolérant aux pannes.

En général, cette architecture est utilisée lorsque des centres de données en configuration actif-actif ou actif-veille sont requis, bien que le basculement puisse être assuré à plusieurs niveaux dans cette architecture. Comme le montre cette architecture, il s'agit d'une configuration actif-actif dans laquelle chaque centre de données intègre une tolérance aux pannes. Cette architecture est destinée aux applications à haut niveau de disponibilité dont l'application est configurée pour s'exécuter dans les deux centres de données en même temps.

Cette architecture est conçue pour répondre aux exigences suivantes :

Fournir un accès sécurisé à un ensemble d'applications accessibles depuis l'Internet externe, bien qu'une approche similaire puisse être mise en œuvre pour des applications accessibles uniquement en interne.
Faciliter l'accès des utilisateurs aux centres de données, sélectionnés en fonction de leur emplacement ou d'autres critères, afin d'améliorer les taux d'accès
Assurer un niveau de performance élevé, notamment grâce à des équilibreurs de charge tolérants aux pannes, tant au sein de chaque centre de données qu'entre les centres de données (l'app restera accessible en cas de défaillance d'un composant au sein d'un centre de données ou si un centre de données entier n'est pas disponible).
Fournir un niveau élevé de tolérance aux pannes à l'intérieur de chaque centre de données :
- Niveau d'équilibreur de charge – un équilibreur de charge par centre de données aux niveaux des application Access Gateway et protégées
- Nœuds de travails Access Gateway segmentés par centre de données, avec un seul nœud d'administration
- Ressources Web protégées répliquées au niveau du centre de données

Avantages	Inconvénients
Très haute tolérance aux pannes Très haute performance Fournit le basculement à plusieurs niveaux ou emplacements au sein de l'architecture	Complexe Matériel/serveurs virtuels supplémentaires nécessaires pour la redondance

Architecture

Composants

Emplacement	Composant	Description
Internet externe	Clients Web	Le navigateur client traditionnel accède à Access Gateway en utilisant les URL connues sous le nom de `[appN\|consumer-app1].example.com`.
	URL `appN.example.com` non affichées	URL représentant les applications qu'un client Web externe saisirait pour accéder à l'une des applications sécurisées par Access Gateway. Généralement, toutes les URL de cette nature sont fournies par l'instance Access Gateway et se résolvent vers cette dernière.
	Org Okta	Votre org Okta, qui fournit des services d'identité.
	Universal Directory Org Okta	Okta Universal Directory, hébergé au sein d'une org Okta, contenant des utilisateurs en dehors des autres implémentations LDAP ou Active Directory. Il s'agit généralement d'autres comptes clients, de comptes partenaires, etc.
Pare-feu	Internet externe vers DMZ	Pare-feu traditionnel entre l'Internet externe et l'hébergement DMZ Access Gateway.
DMZ	Équilibreur de charge en amont d'Access Gateway	Équilibreurs de charge pour le cluster Access Gateway basé sur DMZ Permet potentiellement le basculement entre les centres de données.
DMZ	Nœuds de travail Access Gateway	Instances Access Gateway, réparties dans les deux centres de données, mais partageant une instance d'administration. Les nœuds de travail utilisent le DNS pour sélectionner les ressources Web protégées appropriées.
Pare-feu	DMZ vers pare-feu interne	Pare-feu traditionnel entre la DMZ et le réseau interne.
Réseau interne	Administrateur Access Gateway	Le nœud d'administrateur Access Gateway, dans n'importe quel centre de données qui s'occupe de la configuration, des sauvegardes de configuration, du transfert de journal, etc. Accès par des administrateurs au sein du réseau interne.
	Équilibreur de charge en amont d'Access Gateway interne	Équilibreurs de charge entre Access Gateway et les ressources Web protégées. Permet potentiellement le basculement entre les centres de données. Consultez À propos de l'équilibrage de charge Access Gateway.
	Les URL d'applications protégées ne sont pas affichées	L'ensemble des ressources Web protégées, accessibles à l'aide des URL `protd-N.internal-example.com`. Un ensemble répliqué de ressources Web protégées, hautement disponibles, situées dans le back‑end.

Autres considérations

Des techniques de répartition de charge géographique ou autres, telles que le round-robin DNS, ont été déployées pour acheminer le trafic de session vers les différents centres de données. Ce routage vers les centres de données doit être de type « sticky » (affinité de session) et diriger l'utilisateur vers le même centre de données pendant toute la durée de la session ou jusqu'à ce que ce centre de données ne soit plus accessible. SSL peut être arrêté sur les équilibreurs de charge ou sur les serveurs Access Gateway eux-mêmes. Si SSL est arrêté sur les équilibreurs de charge, les communications entre l'équilibreur de charge et l'OAG doivent s'effectuer via SSL, mais un certificat auto-signé sur l'Access Gateway peut être utilisé.

La plupart des architectures transfèrent les événements du journal à un composant de journal système externe. Okta recommande fortement qu'un serveur de journalisation soit configuré pour tous les environnements Access Gateway. Consultez Configurer des redirecteurs de journaux.