Planifier une haute disponibilité et Disaster Recovery
Les critères uniques de votre org déterminent la façon dont vous mettez en œuvre les processus en matière de haute disponibilité et de Disaster Recovery. Ce guide vise à vous aider à déterminer quelles options sont disponibles.
L'agent AD d'Okta n'effectue pas d'équilibrage de la charge. Le trafic est redirigé vers le premier agent disponible.
Pour commencer, réflechissez aux questions suivantes :
- Qui est responsable de la Disaster Recovery ou des processus de haute disponibilité dans votre entreprise, et qui doit être consulté ?
- De combien de centres de données disposez-vous ?
- Comment sont-ils utilisés ? En d'autres termes, lesquels sont utilisés à chaud, et lesquels sont utilisés à froid (en sauvegarde) ?
- Quel type de basculement souhaitez-vous planifier ? Vous pouvez bénéficier d'une redondance d'agent, en cas de défaillance touchant un unique agent. Ou vous pouvez prévenir une défaillance touchant l'ensemble d'un centre de données (soit l'ensemble des agents du centre de données).
- Les contrôleurs de domaine AD fonctionnent-ils de façon dynamique en continu ?
- La réplication vers ces contrôleurs est-elle effectuée de façon active ,
- Existe-t-il une latence significative en matière de réplication entre les centres de données ? Cela peut entraîner des problèmes de réplication.
Cas d'utilisation
Un cas d'utilisation constitue bien souvent la meilleure façon de montrer comment la haute disponibilité et une politique Disaster Recovery efficace peuvent aider votre organisation à tirer le meilleur parti de son intégration AD. Dans ce cas d'utilisation, l'entreprise Exemple dispose de trois centres de données :
- Un centre de données physique à Atlanta, qui est toujours disponible.
- Un centre de données Amazon AWS toujours disponible.
- Un centre de données à froid utilisé pour les Disaster Recovery en cas d'indisponibilité des deux centres de données à chaud.
Avec l'intégration, le fait que les centres de données soient physiques ou des instances virtuelles n'entraîne aucune différence. On leur confère la même importance.
Si les centres de données d'Atlanta et d'AWS sont toujours disponibles et que chaque instance dispose d'un ou plusieurs agents AD Okta installés, alors le trafic est redirigé vers les agents actifs, peu importe leur localisation.
N'importe lequel agent AD d'Okta installé sur les serveurs de centres de données à froid sont listés comme inactifs dans la Okta Admin Console. Après 30 jours d'inactivité, les jetons API attribués arrivent à expiration. Si l'entreprise Exemple a besoin de rediriger son trafic vers un centre de données de récupération à froid, elle devra réinstaller les Agents AD d'Okta. C'est pour cette raison qu'Okta recommande à l'entreprise Exemple d'installer les agents AD d'Okta sur les serveurs de ses centres de données lorsque cela est nécessaire.
Afin de déterminer le nombre d'agents que l'entreprise Exemple doit installer dans chaque centre de données, elle devra prendre en compte sa tolérance de panne et les scénarios de Disaster Recovery ainsi que la haute disponibilité pour lesquels elle souhaite se préparer.
- Le centre de données d'Atlanta rencontre une défaillance générale, le trafic est redirigé vers le centre de données Amazon AWS. Si la défaillance touche également Amazon AWS, le trafic est redirigé vers le centre de données à froid.
- En cas de défaillance du centre d'Atlanta ou Amazon AWS, le centre de données à froid est mis en ligne.
La réponse à ces questions peut vous aider à élaborer la politique adéquate pour votre intégration AD :
- Quelle est votre tolérance au risque ?
- Pensez-vous prévoir une indisponibilité d'agents individuels, des machines sur lesquels ils sont installés ou des centres de données dans leur intégralité ?
- Dans quelle mesure les recommandations d'Okta correspondent à vos procédures en place pour la haute disponibilité et la Disaster Recovery ?