Salut, tout le monde.
Et bienvenue à nouveau.
Dans cette vidéo, nous allons aborder les déploiements de zones de disponibilité multiples
des idées Amazon, également appelés déploiements multiples.
Avant d'en parler plus en détail, examinons un défi typique.
Supposons donc que vous avez une base de données qui fonctionne dans la zone de disponibilité, numéro un.
Maintenant, pour une raison quelconque, si cette zone de disponibilité 1 tombe en panne ou si le matériel sur lequel la base de données
fonctionne tombe en panne, alors toute votre application tombera en panne car le cœur de l'application où
les données sont principalement stockées est la base de données.
Si la base de données est en panne, c'est tout le site web qui peut tomber en panne.
Et c'est quelque chose que vous ne voulez pas vraiment pour les environnements de production.
Et c'est la raison pour laquelle il est très important, lorsque vous utilisez des idées pour la production,
d'éviter les déploiements basés sur une seule zone de disponibilité.
Et la meilleure architecture est d'utiliser des déploiements à zones de disponibilité multiples.
Ainsi, dans une architecture de déploiement basée sur des CA multiples, vous avez la base de données primaire
ici et une base de données secondaire qui fonctionne dans une zone de disponibilité différente de la même région
et il y a une réplication qui se produit entre ces deux bases de données.
Maintenant, pour une raison quelconque, disons que la base de données primaire tombe en panne dans de tels cas, les idées redirigeront
toutes les demandes vers l'instance de secours.
Très bien.
C'est donc le processus automatisé.
En tant qu'utilisateur ou qu'application, vous n'avez pas vraiment besoin de vous en préoccuper.
Maintenant, l'une des questions qui se pose est la suivante : dans quel scénario ce basculement automatique a-t-il lieu
de l'instance primaire à l'instance de secours ?
Maintenant, avant de nous pencher sur le domaine de la condition, révisons rapidement qu'en cas d'interruption planifiée
ou non planifiée de votre instance de base de données, celle-ci bascule automatiquement vers la réplique en attente dans une autre zone
de disponibilité dans les déploiements multi AC.
C'est quelque chose que nous avons vu.
Maintenant, examinons certaines des conditions.
La première est que s'il y a une perte de disponibilité dans la zone de disponibilité primaire.
Deuxièmement, s'il y a une perte de connectivité réseau à l'instance primaire, s'il y a une défaillance de l'unité
de calcul sur l'instance primaire, là encore, la condition de basculement a lieu.
Dans ce cas, s'il y a une défaillance de stockage sur l'instance de base de données primaire, le basculement automatique a
également lieu.
Et lorsque nous examinons le temps de basculement, il est généralement compris entre 60 et 1 à 20 secondes.
Maintenant, faisons une chose.
Allons-y et comprenons cela du point de vue de la démo pour que notre concept soit clair.
Maintenant, pour la démonstration d'aujourd'hui, j'ai une base de données qui est créée sur la base du déploiement multi AC.
Le nom de la base de données est Demo DB, Multi AC.
Maintenant, si vous regardez dans cette base de données spécifique, laissez-moi aller à la configuration.
Allons un peu plus bas.
Vous voyez qu'il est indiqué que le multi AC est activé, donc il est indiqué que oui.
Voyons donc comment il fonctionne exactement.
Nous allons donc passer à la connectivité ici.
Je vais copier le point final de l'instance IDs.
Et faisons rapidement une recherche pour voir quelle est l'adresse IP qui est retournée ici.
L'adresse IP est un 7231 37. 32.
Donc à ce stade, si je dois vous montrer cela en termes de diagramme, vous pouvez considérer que cette adresse
IP qui a été retournée est celle de l'instance primaire ici.
Maintenant, pour la démonstration, nous allons faire un basculement et nous allons voir comment l'adresse IP change pour celle
de l'instance secondaire.
Alors faisons une chose.
Allons-y et redémarrons l'instance de la base de données.
Maintenant, chaque fois que vous redémarrez, vous avez l'option de redémarrer avec Failover.
Alors allons-y et confirmons.
Il s'agit donc d'un moyen simple d'identifier comment le déploiement multi CA fonctionne dans des scénarios réels.
S'il y a un problème lié au réseau et que le basculement se fait automatiquement, vous n'avez pas vraiment besoin
de vous en préoccuper.
Alors laissez-moi faire une confirmation rapide.
Très bien.
La reconstruction est donc en cours.
Alors attendons rapidement un moment ici.
Donc sur le rafraîchissement, notre statut est maintenant disponible.
À ce stade, si vous effectuez à nouveau la recherche NSS pour trouver l'adresse IP associée à l'instance de la base de données,
vous constaterez cette fois que l'adresse IP est différente.
Avant c'était un 7231 3732 maintenant c'est un 7231 79. 1 47.
Donc, en coulisses, RDC a automatiquement redirigé la demande vers l'instance de secours ici.
Il est important de noter que l'URL du point de terminaison dont nous
parlons ici reste la même.
Ainsi, même si la base de données primaire tombe en panne et si les demandes sont adressées à ce point de terminaison, les idées dirigeront
automatiquement la demande vers l'instance de secours.
Et c'est la raison pour laquelle la haute disponibilité orale fonctionne dans une architecture basée sur plusieurs CA.