Meilleures pratiques pour la haute disponibilité et récupération d’urgence
Azure Managed Instance pour Apache Cassandra est un service complètement managé pour les clusters Apache Cassandra open source purs. Le service permet également de remplacer des configurations, en fonction des besoins spécifiques de chaque charge de travail, ce qui permet une flexibilité et un contrôle optimaux, le cas échéant.
Le système Apache Cassandra est un excellent choix pour créer des applications hautement résilientes. En effet, son architecture de nature distribuée et masterless (sans maître), dans laquelle n’importe quel nœud de la base de données peut offrir des fonctionnalités exactement identiques à celles d’un autre nœud, contribue à la résilience et à la robustesse de Cassandra. Cet article vous fournit des conseils sur la façon d’optimiser la haute disponibilité et sur la manière d’aborder la récupération d’urgence.
RPO et RTO
L’objectif de point de récupération (RPO) et l’objectif de temps de récupération (RTO) sont tous deux généralement faibles (proches de zéro) pour Apache Cassandra aussi longtemps que vous disposez de ce qui suit :
- Un déploiement multi-région avec une réplication inter-régionale et un facteur de réplication de 3.
- Des zones de disponibilité activées (sélectionnez une option lors de la création d’un cluster dans le portail ou via Azure CLI).
- Un basculement configuré au niveau de l’application en utilisant une stratégie d’équilibrage de charge dans le pilote client et/ou un basculement au niveau de l’équilibrage de charge en utilisant un gestionnaire de trafic/une instance Front Door Azure.
Un RTO (« durée de votre arrêt lors d’une panne ») est faible, car le cluster est résilient dans toutes les zones et régions et parce qu’Apache Cassandra est lui-même par défaut un système masterless hautement tolérant aux erreurs (tous les nœuds peuvent écrire). Un RPO (« quantité de données que vous pouvez perdre lors d’une panne ») est faible, car les données sont synchronisées entre tous les nœuds et les centres de données. La perte de données lors d’une panne sera donc minimale.
Remarque
Il n’est pas possible en théorie d’obtenir à la fois RTO=0 et RPO=0 par Théorème CAP. Vous devez évaluer le compromis entre la cohérence et les performances optimales/de disponibilité. Il sera différent pour chaque application. Par exemple, si votre application est intensive en lecture, il peut être préférable de faire face à une latence accrue des écritures inter-régionales pour éviter une perte de données (ce qui favorise la cohérence). Si l’application est intensive en écriture et sur un budget serré en latence, il est possible que le risque de perdre les écritures les plus récentes dans une panne régionale majeure soit acceptable (ce qui favorise la disponibilité).
Zones de disponibilité
L’architecture masterless de Cassandra apporte la tolérance de panne de bout en bout et Azure Managed Instance pour Apache Cassandra fournit une prise en charge pour les zones de disponibilité dans les régions sélectionnées afin d’améliorer la résilience au niveau de l’infrastructure. Pour un facteur de réplication de 3, la prise en charge de zones de disponibilité vérifie que chaque réplica se trouve dans une zone de disponibilité différente, ce qui empêche une panne zonale d’affecter votre base de données/application. Nous vous recommandons d’activer dès que possible des zones de disponibilité, le cas échéant.
Redondance multirégion
L’architecture de Cassandra, associée à la prise en charge des zones de disponibilité Azure, vous offre un certain niveau de tolérance de panne et de résilience. Cependant, il est important de considérer l’impact des pannes régionales pour vos applications. Nous vous recommandons vivement de déployer des clusters multirégions pour bénéficier d’une protection contre les pannes au niveau de la région. Bien qu’elles soient rares, leur impact éventuel est grave.
Pour la continuité d’activité, il n’est pas suffisant de rendre seulement la base de données multirégion. D’autres parties de votre application doivent également être déployées de la même manière en étant distribuées ou avec des mécanismes appropriés pour effectuer un basculement. Si vos utilisateurs sont répartis sur plusieurs emplacements géographiques, un déploiement multirégion de centre de données pour votre base de données aura l’avantage supplémentaire de réduire la latence, car l’ensemble des nœuds de tous les centres de données du cluster pourront alors servir les écritures et les lectures d’une région la plus proche d’eux. Toutefois, si l’application est configurée pour être « active-active », il est important de considérer comment le théorème CAP s’applique à la cohérence de vos données entre les réplicas (nœuds) et aux compromis requis pour livrer la haute disponibilité.
Dans les conditions générales du théorème CAP, Cassandra est par défaut un système de base de données AP (tolérant aux partitions disponibles) avec une cohérence hautement ajustable. Pour la plupart des cas d’usage, nous vous recommandons d’utiliser local_quorum pour les lectures.
- Dans un cas de configuration active-passive pour des écritures, il existe un compromis entre la fiabilité et les performances : pour la fiabilité, nous recommandons QUORUM_EACH, mais pour la plupart des utilisateurs, LOCAL_QUORUM ou QUORUM est un bon compromis. Notez que dans le cas d’une panne régionale, il est toutefois possible que certaines écritures soient perdues dans LOCAL_QUORUM.
- Dans le cas d’une application exécutée en parallèle, les écritures QUORUM_EACH sont préférables dans la majorité des cas afin de veiller à une cohérence entre les deux centres de données.
- Si votre objectif est de favoriser la cohérence (RPO plus faible) plutôt que la latence ou la disponibilité (RTO plus faible), vous devez le refléter dans vos paramètres de cohérence et votre facteur de réplication. En tant que règle de base, le nombre de nœuds de quorum requis pour une lecture et le nombre de nœuds de quorum requis pour une écriture doivent être supérieurs au facteur de réplication. Par exemple, si vous avez un facteur de réplication de 3, et quorum_one sur les lectures (un nœud), vous devez effectuer quorum_all sur les écritures (trois nœuds) pour que le total de 4 soit supérieur au facteur de réplication de 3.
Remarque
L’opérateur de plan de contrôle pour Azure Managed Instance pour Apache Cassandra ne sera déployé que dans une seule région (la région sélectionnée lors du déploiement initial du premier centre de données). Dans le cas peu probable d’une panne dans une région entière, nous nous engageons sur un délai de récupération de 3 heures pour basculer le plan de contrôle vers une autre région. Cela n’affecte pas le contrat SLA de disponibilité du service, car les centres de données devraient quand même continuer à fonctionner. Toutefois, pendant cette période, il ne sera peut-être pas possible d’apporter des modifications à la configuration de la base de données à partir des outils du portail ou du fournisseur de ressources.
Réplication
Nous vous recommandons d’auditer keyspaces et ses paramètres de réplication de temps en temps pour veiller à ce que la réplication requise entre des centres de données soit configurée. Lors des premières phases du développement, nous vous recommandons de tester que tout fonctionne comme prévu en effectuant des tests simples à l’aide de cqlsh. Par exemple, insérer une valeur en étant connecté à un centre de données et en la lisant à partir d’un autre.
En particulier, lorsque vous configurez un deuxième centre de données où un centre de données existant possède déjà des données, il est important d’établir que toutes les données ont été répliquées et que le système est prêt. Nous recommandons de monitorer la progression d’une réplication via nos commandes DBA avec nodetool netstats. Une autre approche consiste à compter les lignes de chaque table, mais de garder à l’esprit qu’avec des tailles Big Data, cette opération ne peut donner qu’une estimation approximative en raison de la nature distribuée de Cassandra.
Équilibrage du coût de la récupération d’urgence
Si votre application est « active-passive », nous continuons de recommander en général de déployer la même capacité dans chaque région afin que votre application puisse basculer instantanément vers un centre de données « serveur de secours » dans une région secondaire. Cette opération garantit l’absence d’une détérioration des performances en cas de panne régionale. La plupart des pilotes clients Cassandra fournissent des options pour lancer un basculement au niveau de l’application. Ils supposent par défaut qu’une panne régionale signifie que l’application est également en panne et qu’un basculement doit dans ce cas se produire au niveau de l’équilibreur de charge.
Cependant, vous préférez peut-être déployer une référence SKU plus petite et moins de nœuds dans votre région secondaire pour réduire le coût d’approvisionnement d’un deuxième centre de données. Quand une panne se produit, une mise à l’échelle est facilitée dans Azure Managed Instance pour Apache Cassandra par une mise à l’échelle horizontale et verticale clé en main. Pendant que vos applications basculent vers votre région secondaire, vous pouvez effectuer un scale-out et effectuer un scale-up manuellement des nœuds dans votre centre de données secondaire. Dans ce cas, votre centre de données secondaire agit comme un secours semi-automatique moins coûteux. L’adoption de cette approche nécessite d’être mise en balance avec le temps nécessaire pour restaurer votre système à sa pleine capacité en cas de panne. IL est important de tester et de pratiquer ce qui se produit en cas de perte d’une région.
Remarque
La mise à l’échelle de nœuds est plus facile qu’un scale-out. Gardez cet élément à l’esprit lorsque vous tenez compte de l’équilibre entre la mise à l’échelle horizontale et verticale et le nombre de nœuds à déployer dans votre cluster.
Planifications des sauvegardes
Les sauvegardes sont automatiques dans Azure Managed Instance pour Apache Cassandra, mais vous pouvez choisir votre planification pour les sauvegardes journalières. Nous vous recommandons de choisir des heures ayant une charge inférieure. Bien que les sauvegardes soient configurées pour ne consommer que des processeurs inactifs, elles peuvent dans certains cas déclencher des compactages dans Cassandra susceptibles d’entraîner une augmentation de l’utilisation des processeurs. Les compactages peuvent se produire à tout moment avec Cassandra et dépendent de la charge de travail et de la stratégie de compactage choisie.
Important
L’intention des sauvegardes est strictement d’atténuer les pertes de données accidentelles et les altérations des données. Nous ne recommandons pas les sauvegardes en tant que stratégie de récupération d’urgence. Les sauvegardes ne sont pas géoredondantes et, même si c’était le cas, les récupérations de bases de données à partir de sauvegardes peuvent prendre beaucoup plus de temps. Par conséquent, nous recommandons vivement des déploiements multirégions, associées à l’activation de zones de disponibilité dans la mesure du possible, pour atténuer des scénarios d’urgence et être en mesure de les corriger efficacement. Ceci est particulièrement important dans de rares scénarios dans lesquels la région en échec ne peut pas être récupérée et où, sans réplication multirégion, toutes les données peuvent être perdues.
Étapes suivantes
Dans cet article, nous avons exposé certaines des meilleures pratiques pour générer des applications résilientes avec Cassandra.