Haute disponibilité et récupération d’urgence
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 Azure Cache pour Redis ou Azure Cache pour Redis Enterprise.
Diverses options de haute disponibilité sont disponibles dans les niveaux Standard, Premium et Entreprise :
| Option | Description | Disponibilité | standard | Premium | Enterprise |
|---|---|---|---|---|---|
| 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) | Oui | Oui | Oui |
| Redondance de zone | Configuration répliquée à plusieurs nœuds dans les zones de disponibilité, avec basculement automatique | 99,9 % dans Premium ; 99,99 % dans Enterprise (voir les détails) | Oui | Oui | Oui |
| Géoréplication | Instances de cache liées dans deux régions, avec basculement contrôlé par l’utilisateur | Premium ; Enterprise (voir les détails) | Non | Passif | Actif |
| Import/Export | Instantané à un point dans le temps des données dans le cache. | 99.9 % (voir les détails) | Non | Oui | Oui |
| Persistance | Enregistrement périodique des données dans le compte de stockage. | 99.9 % (voir les détails) | Non | Oui | Aperçu |
Réplication standard pour la haute disponibilité
Niveaux applicables : Standard, Premium, Enterprise, Enterprise Flash
Recommandé pour : Haute disponibilité
Azure Cache pour Redis dispose d’une architecture de haute disponibilité qui garantit le fonctionnement de votre instance gérée, même lorsque des pannes affectent les machines virtuelles sous-jacentes. Qu’il s’agisse d’interruptions planifiées ou non, Azure Cache pour Redis offre des taux de pourcentage de disponibilité supérieurs à ce qui est réalisable avec l’hébergement de Redis sur une seule machine virtuelle.
Une instance Azure Cache pour Redis dans les niveaux applicables 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. Le logiciel Redis open source permet à un seul serveur de traiter les demandes d’écriture de données.
Avec Azure Cache pour Redis, un serveur est le nœud principal, tandis que l’autre est le réplica. Après avoir configuré les nœuds de serveur, Azure Cache pour Redis leur attribue des rôles principaux et 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.
Notes
Normalement, une application cliente Azure Cache pour Redis communique avec le nœud principal dans un cache pour toutes les requêtes de lecture et d’écriture. Certains clients peuvent être configurés pour lire à partir du nœud de réplica.
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. L’article Basculement et mise à jour corrective pour Azure Cache pour Redis fournit une explication détaillée sur les types de basculements. Une instance Azure Cache pour Redis connaît de nombreux basculements au cours de sa 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.
Azure Cache pour Redis fournit également plus de nœuds de réplica dans le niveau Premium. Un cache à réplicas multiples peut être configuré avec un maximum de trois nœuds de réplica. Le fait de disposer d’un plus grand nombre de réplicas améliore généralement la résilience, car les nœuds supplémentaires viennent en renfort du nœud principal. Même avec davantage de réplicas, une instance Azure Cache pour Redis peut toujours être gravement affectée par une panne du centre de données ou de la zone de disponibilité. Vous pouvez augmenter la disponibilité du cache en utilisant plusieurs réplicas avec la redondance de zone.
Redondance de zone
Niveaux applicables : Standard, Premium, Enterprise, Enterprise Flash
Recommandé pour : Haute disponibilité, Reprise d’activité - intra-région
Azure Cache pour Redis prend en charge les configurations de redondance de zone dans les niveaux Standard, Premium et Enterprise. Un cache redondant interzone peut placer ses nœuds dans différentes Zones de disponibilité Azure au sein de la même région. 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.
Si un cache est configuré pour utiliser deux zones ou plus comme décrit précédemment dans cet article, les nœuds de cache sont créés dans des zones différentes. Lorsqu’une zone tombe en panne, des nœuds de cache dans d’autres zones sont disponibles pour que le cache continue à fonctionner normalement.
Important
Azure Cache pour Redis crée par défaut des caches redondants interzones pour les niveaux Premium et Standard à l’aide de Automatic_Zonal_Allocation dans les régions qui prennent en charge les zones. Pour plus d’informations, consultez Activer la redondance de zone pour Azure Cache pour Redis.
Niveau Premium
Le diagramme suivant illustre la configuration redondante interzone pour le niveau Premium :
Azure Cache pour Redis distribue les nœuds dans un cache redondant interzone de manière alternée sur les zones de disponibilité sélectionnées. Il détermine également le nœud qui sert initialement de nœud principal.
Expérience de défaillance de zone pour le niveau Premium
Un cache redondant interzone assure le basculement automatique. Lorsque le nœud principal actuel n’est pas disponible, l’un des réplicas prend le relais. Le temps de réponse du cache de votre application peut être plus long si le nouveau nœud principal se trouve dans une autre zone de disponibilité. Les zones de disponibilité se trouvent à des endroits différents. Passer d’une zone de disponibilité à une autre modifie la distance physique entre les emplacements où votre application et votre cache sont hébergés. Cette modification a un impact sur les latences réseau aller-retour entre votre application et le cache. La latence supplémentaire devrait se situer dans une fourchette acceptable pour la plupart des applications. Nous vous recommandons de tester votre application pour vous assurer qu’elle fonctionne correctement avec un cache redondant interzone.
Niveaux Entreprise et Enterprise Flash
Un cache dans l’un ou l’autre des niveaux Enterprise s’exécute sur un cluster Redis Entreprise. Il nécessite toujours un nombre impair de nœuds de serveur pour former un quorum. Par défaut, il est composé de trois nœuds, chacun étant hébergé sur une machine virtuelle dédiée.
- Un cache Entreprise a deux nœuds de données de taille identique et un nœud de quorum plus petit.
- Un cache Enterprise Flash comporte trois nœuds de données de même taille.
Le cluster Enterprise divise les données Azure Cache pour Redis en partitions internes. Chaque partition possède un principal et au moins un réplica. Chaque nœud de données contient une ou plusieurs partitions. Le cluster Entreprise s’assure que le principal et les réplicas de n’importe quelle partition ne sont jamais colocalisés sur le même nœud de données. Les partitions répliquent les données de manière asynchrone des principaux vers leurs réplicas correspondants.
Expérience de défaillance de zone pour les niveaux Entreprise
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 Enterprise utilise un modèle basé sur le quorum pour déterminer les nœuds survivants qui font partie d’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 de niveau Premium et Standard redondants interzone sont disponibles dans les régions suivantes :
| Amérique | Europe | Moyen-Orient | Afrique | Asie-Pacifique |
|---|---|---|---|---|
| Brésil Sud | France Centre | Qatar Central | Afrique du Sud Nord | Australie Est |
| Centre du Canada | Italie Nord | Émirats arabes unis Nord | Inde centrale | |
| USA Centre | Allemagne Centre-Ouest | Israël Central | Japon Est | |
| USA Est | Norvège Est | |||
| USA Est 2 | Europe Nord | Asie Sud-Est | ||
| États-Unis - partie centrale méridionale | Sud du Royaume-Uni | Asie Est | ||
| Gouvernement américain - Virginie | Europe Ouest | Chine Nord 3 | ||
| USA Ouest 2 | Suède Centre | Centre de la Corée | ||
| USA Ouest 3 | Suisse Nord | Nouvelle-Zélande Nord | ||
| Mexique Centre | Pologne Centre | |||
| Espagne Centre |
Les caches de niveau Entreprise er Enterprise Flash 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 |
* Le niveau Enterprise Flash n’est pas disponible dans cette région.
Redéploiement et migration des zones de disponibilité
Actuellement, la seule façon de convertir votre cache d’une configuration sans zones de disponibilité (non AZ) en configuration avec zones de disponibilité (AZ) consiste à redéployer le cache. Pour savoir comment redéployer votre cache actuel, consultez Migrer une instance Azure Cache pour Redis vers la prise en charge de la zone de disponibilité.
Persistance
Niveaux applicables : Premium, Enterprise (préversion), Enterprise Flash (préversion)
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 la perte complète des données, Persistance Redis vous permet de prendre des instantanés périodiques de données en mémoire et de les stocker dans votre compte de stockage. Si vous rencontrez une défaillance sur plusieurs nœuds entraînant une perte de données, votre cache charge l’instantané à partir du compte de stockage. Pour plus d’informations, consultez Configurer la persistance des données pour une instance Azure Cache pour Redis Premium.
Compte de Stockage pour la persistance
Envisagez de choisir un compte de stockage géoredondant pour garantir la haute disponibilité des données persistantes. Pour plus d’informations, consultez Redondance de Stockage Azure.
Importer/Exporter
Niveaux applicables : Premium, Enterprise, Enterprise Flash
Recommandé pour : Reprise d’activité
Le cache Azure pour 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. Elle vous permet d’importer des données dans Azure Cache pour Redis ou d’exporter des données à partir d’Azure Cache pour Redis à l’aide d’un instantané RDB. L’instantané RDB d’un cache Premium est exporté vers un objet blob dans un compte de 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 Cache pour 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éoréplication passive
Niveau applicable : Premium
Recommandé pour : Reprise d’activité - région unique
La géoréplication est un mécanisme de liaison de deux (ou plus) instances Azure Cache pour Redis, couvrant généralement deux régions Azure. La géoréplication est conçue principalement pour la reprise d’activité inter-région. Deux instances de cache de niveau Premium sont connectées via la géoréplication de sorte à fournir des lectures et des écritures dans votre cache principal, et les données sont répliquées dans le cache secondaire.
Pour plus d’informations sur sa configuration, consultez Configurer la géoréplication pour des instances Azure Cache pour Redis Premium.
Si la région hébergeant le cache principal tombe en panne, vous devez commencer le basculement en : dissociant tout d’abord le cache secondaire, puis en mettant à jour votre application pour qu’elle pointe vers le cache secondaire pour les lectures et les écritures.
La géoréplication active
Niveaux applicables : Enterprise, Enterprise Flash
Recommandé pour : Haute disponibilité, Reprise d’activité - multirégion
Les niveaux Entreprise prennent en charge une forme plus avancée de géoréplication appelée géoréplication active qui offre à la fois une plus haute disponibilité et une reprise d’activité inter-région dans plusieurs régions. Le logiciel Azure Cache pour Redis Enterprise utilise des types de données répliquées non conflictuels pour prendre en charge les écritures dans plusieurs instances de cache, fusionner les modifications et résoudre les conflits. Vous pouvez joindre jusqu’à cinq instances de cache de niveau Enterprise 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 Azure Cache pour Redis Enterprise.
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
Niveaux applicables : Standard, Premium, Enterprise, Enterprise Flash
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 des données sont perdues lors d’une panne de région. Votre code d’application doit être résilient à la perte de données.
Une fois la région affectée restaurée, votre Azure Cache pour Redis non disponible est automatiquement restauré et peut être à nouveau 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 Azure Cache pour Redis vers différentes régions.
Étapes suivantes
En savoir plus sur la configuration des options de haute disponibilité d’Azure Cache pour Redis.