Haute disponibilité et récupération d’urgence avec Azure Managed Redis (préversion)
Comme pour tous les systèmes cloud, des interruptions non planifiées peuvent se produire, entraînant l’arrêt d’une instance de machine virtuelle (VM), d’une zone de disponibilité ou d’une région Azure complète. Nous recommandons aux clients de mettre en place un plan pour gérer les pannes de zone ou de région.
Cet article présente les informations permettant aux clients de créer un plan de continuité d’activité et reprise d’activité pour leur implémentation d’Azure Managed Redis (préversion).
Options de haute disponibilité :
| Option | Description | Disponibilité |
|---|---|---|
| Réplication standard | Configuration répliquée à deux nœuds dans un centre de données avec basculement automatique | 99.9 % (voir les détails) |
| Redondance de zone | Configuration répliquée à plusieurs nœuds dans les zones de disponibilité, avec basculement automatique | 99,99 % (voir les détails) |
| Géoréplication | Instances de cache liées dans deux régions, avec basculement contrôlé par l’utilisateur | Actif (voir les détails) |
| Import/Export | Instantané à un point dans le temps des données dans le cache. | 99.9 % (voir les détails) |
| Persistance | Enregistrement périodique des données dans le compte de stockage. | 99.9 % (voir les détails) |
Réplication standard pour la haute disponibilité
Recommandé pour : Haute disponibilité
Azure Managed Redis a une architecture à haute disponibilité qui garantit le fonctionnement de votre instance gérée, même quand des pannes affectent les machines virtuelles sous-jacentes. Qu’il s’agisse d’interruptions planifiées ou non, Azure Managed Redis offre des pourcentages de disponibilité supérieurs à ceux qui peuvent être atteints en hébergeant Redis sur une seule machine virtuelle. Une configuration Azure Managed Redis s’exécute par défaut sur une paire de serveurs Redis. Les deux serveurs sont hébergés sur des machines virtuelles dédiées.
Avec Azure Managed Redis, un serveur est le nœud principal, tandis que l’autre est le nœud de réplica. Après avoir approvisionné les nœuds de cluster, Azure Managed Redis leur attribue les rôles de nœuds principaux et de nœuds de réplica. Le nœud principal est généralement chargé de traiter les requêtes d’écriture et de lecture des clients. Lors d’une opération d’écriture, il valide une nouvelle clé et une mise à jour de clé dans sa mémoire interne et répond immédiatement au client. Il transfère l’opération au réplica de manière asynchrone.
Si le nœud principal d’un cache n’est pas disponible, le réplica se promeut automatiquement pour devenir le nouveau nœud principal. Ce processus s’appelle le basculement. Un basculement consiste simplement en deux nœuds, principal/réplica, échange de rôles, réplica/principal, avec l’un des nœuds pouvant être hors connexion pendant quelques minutes. Dans la plupart des basculements, les nœuds principal et réplica coordonnent la remise afin que ne soyez quasiment jamais sans principal.
L’ancien principal passe brièvement hors connexion pour recevoir les mises à jour du nouveau principal. Ensuite, le réplica revient en ligne et rejoint le cache entièrement synchronisé. La clé est que, lorsqu’un nœud n’est pas disponible, il s’agit d’une condition temporaire et il revient en ligne.
Une séquence de basculement classique ressemble à ceci lorsqu’un principal doit être arrêté pour maintenance :
- Les nœuds principal et réplica négocient un basculement coordonné et échangent les rôles.
- Le réplica (anciennement principal) passe hors connexion pour un redémarrage.
- Quelques secondes ou quelques minutes plus tard, le réplica revient en ligne.
- Le réplica synchronise les données à partir du principal.
Un nœud principal peut être mis hors service dans le cadre d’une activité de maintenance planifiée, telle qu’une mise à jour du logiciel Redis ou du système d’exploitation. Il peut également cesser de fonctionner en raison d’événements imprévus tels que des défaillances du matériel, du logiciel ou du réseau sous-jacent. Basculement et mise à jour corrective pour Azure Managed Redis fournit une explication détaillée sur les types de basculements. Une instance d’Azure Managed Redis passe par de nombreux basculements au cours de sa durée de vie. La conception de l’architecture de haute disponibilité rend ces modifications à l’intérieur d’un cache aussi transparentes que possible pour ses clients.
Redondance de zone
Recommandé pour : Haute disponibilité, Reprise d’activité - intra-région
Azure Managed Redis prend en charge la configuration redondante interzone par défaut. Un cache redondant interzone place automatiquement ses nœuds dans différentes zones de disponibilité Azure de la même région. Lorsqu’une zone tombe en panne, des nœuds de cache dans d’autres zones sont disponibles pour que le cache continue à fonctionner normalement. Ainsi, les pannes du centre de donnée ou de la zone de disponibilité ne constituent plus un point de défaillance unique et la disponibilité globale de votre cache en est accrue.
Expérience en cas de panne de zone
Lorsqu’un nœud de données devient indisponible ou qu’un fractionnement du réseau se produit, un basculement similaire à celui décrit dans Réplication standard a lieu. Le cluster utilise un modèle basé sur le quorum pour déterminer quels sont les nœuds survivants qui participent à un nouveau quorum. Il promeut également des partitions de réplica au sein de ces nœuds vers les principaux, le cas échéant.
Disponibilité régionale
Les caches redondants interzones sont disponibles dans les régions suivantes :
| Amérique | Europe | Moyen-Orient | Afrique | Asie-Pacifique |
|---|---|---|---|---|
| Canada Centre* | Europe Nord | Australie Est | ||
| USA Centre* | Sud du Royaume-Uni | Inde centrale | ||
| USA Est | Europe Ouest | Asie Sud-Est | ||
| USA Est 2 | Japon Est* | |||
| États-Unis - partie centrale méridionale | Asie Est* | |||
| USA Ouest 2 | ||||
| USA Ouest 3 | ||||
| Brésil Sud |
Persistance
Recommandé pour : Durabilité des données
Étant donné que vos données de cache sont stockées en mémoire, une défaillance rare et non planifiée de plusieurs nœuds peut entraîner la suppression de toutes les données. Pour éviter de perdre complètement les données, la persistance Redis vous permet de prendre des captures instantanées périodiques des données en mémoire, et de les stocker sur un disque managé attaché directement à l’instance de cache. En cas de perte de données, les données du cache sont restaurées automatiquement à l’aide de la capture instantanée sur le disque managé. Pour plus d’informations, consultez Configurer la persistance des données pour une instance d’Azure Managed Redis.
Import/Export
Recommandé pour : Reprise d’activité
Azure Managed Redis prend en charge l’option permettant d’importer et d’exporter des fichiers de base de données Redis (RDB) pour assurer la portabilité des données. Cela vous permet d’importer des données dans Azure Managed Redis, ou d’exporter des données à partir d’Azure Managed Redis à l’aide d’une capture instantanée RDB. La capture instantanée RDB d’un cache est exportée vers un objet blob dans un compte Stockage Azure. Vous pouvez créer un script pour déclencher régulièrement une exportation vers votre compte de stockage. Pour plus d’informations, consultez Importer et exporter des données dans Azure Managed Redis.
Compte de stockage pour l’exportation
Envisagez de choisir un compte de stockage géoredondant pour garantir la haute disponibilité de vos données exportées. Pour plus d’informations, consultez Redondance de Stockage Azure.
Géo-réplication active
Recommandé pour : Haute disponibilité, Reprise d’activité - multirégion
La géoréplication est un mécanisme permettant de lier des instances d’Azure Managed Redis dans plusieurs régions Azure. Azure Managed Redis prend en charge une forme avancée de géoréplication appelée géoréplication active, qui offre à la fois une plus grande disponibilité et une récupération d’urgence inter-région. Le logiciel Azure Managed Redis utilise des types de données répliqués sans conflit pour prendre en charge les écritures dans plusieurs instances de cache, fusionne les changements et résout les conflits. Vous pouvez joindre jusqu’à cinq instances de cache dans différentes régions Azure pour former un groupe de géoréplication.
Une application qui utilise ce type de cache peut lire et écrire des données dans l’une des instances de cache géodistribuées via leurs points de terminaison correspondants. L’application doit utiliser ce qui se trouve le plus près de chaque instance d’application, pour vous assurer le temps de latence le plus court. Pour plus d’informations, consultez Configurer la géoréplication active pour les instances d’Azure Managed Redis.
Si une région de l’un des caches de votre groupe de réplication tombe en panne, votre application doit basculer vers une autre région disponible.
Lorsqu’un cache dans votre groupe de réplication n’est pas disponible, nous vous recommandons d’analyser l’utilisation de la mémoire d’autres caches dans le même groupe de réplication. Lorsque l’un des caches est en panne, tous les autres caches dans le groupe de réplication commencent à enregistrer les métadonnées qu’ils n’ont pas pu partager avec le cache en panne. Si l’utilisation de la mémoire des caches disponibles commence à augmenter à un taux élevé après une panne de l’un des caches, envisagez de dissocier le cache qui n’est pas disponible du groupe de réplication.
Pour plus d’informations sur la dissociation forcée, consultez Forcer la dissociation en cas de panne d’une région.
Supprimer et recréer un cache
Si vous rencontrez une panne de région, vous pouvez recréer votre cache dans une autre région et mettre à jour votre application pour qu’elle se connecte au nouveau cache à la place. Il est important de comprendre que les données sont perdues en cas de panne régionale, sauf si vous utilisez la géoréplication active. Votre code d’application doit être résilient à la perte de données.
Une fois la région affectée restaurée, votre service Azure Managed Redis non disponible est automatiquement restauré, et est à nouveau prêt à être utilisé. Pour plus d’informations sur les stratégies de déplacement de votre cache vers une autre région, consultez Déplacer des instances d’Azure Managed Redis vers d’autres régions.