Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Managed Instance pour Apache Cassandra est un service complètement managé pour les clusters Apache Cassandra open source purs. Le service permet aux configurations d’être remplacées, en fonction des besoins de chaque charge de travail, ce qui permet une flexibilité et un contrôle maximum si nécessaire.
Apache Cassandra est un excellent choix pour la création d’applications hautement résilientes en raison de sa nature distribuée et de son architecture d’égal à égal. Tout nœud de la base de données peut fournir les mêmes fonctionnalités que tout autre nœud. Cette conception contribue à la robustesse et à la résilience 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.
Objectif de point de récupération et objectif de temps de récupération
Tant que vous disposez des éléments suivants, l’objectif de point de récupération (RPO) et l’objectif de temps de récupération (RTO) sont généralement bas, proches de zéro :
- Déploiement de plusieurs régions avec réplication interrégion et facteur de réplication de 3.
- Zones de disponibilité activées. Configurez cette option lorsque vous créez un cluster dans le portail Azure ou à l’aide d’Azure CLI.
- Basculement au niveau de l’application configuré à l’aide de la stratégie d’équilibrage de charge dans le pilote client ou basculement au niveau de l’équilibrage de charge à l’aide d’Azure Traffic Manager ou d’Azure Front Door.
RTO est la durée pendant laquelle vous êtes en panne. C'est bas, car le cluster est résilient entre les zones et les régions. En outre, Apache Cassandra est un système pair à pair hautement tolérant aux pannes, où tous les nœuds peuvent écrire par défaut.
RPO est la quantité de données que vous pouvez perdre en panne. Il 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 dans une panne serait minimale.
Remarque
Il n’est pas possible d’atteindre à la fois RTO=0 et RPO=0 par théorème CAP. Évaluez le compromis entre cohérence et disponibilité ou performances optimales.
Cet équilibre semble différent pour chaque application. Par exemple, si votre application est en lecture lourde, il peut être préférable de faire face à une latence accrue des écritures inter-régions pour éviter la perte de données, ce qui favorise la cohérence. Si l’application est intensive en écriture avec des besoins stricts 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 pair-à-pair de Cassandra apporte une tolérance aux pannes dès le départ. Azure Managed Instance pour Apache Cassandra prend en charge les zones de disponibilité dans les régions sélectionnées. Cette prise en charge améliore la résilience au niveau de l’infrastructure. Pour un facteur de réplication de 3, la gestion des zones de disponibilité garantit que chaque réplica se trouve dans une zone de disponibilité différente. Cette approche empêche une panne zonale d’affecter votre base de données ou votre 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 niveau de tolérance de panne et de résilience. Tenez également compte de l’impact des pannes régionales pour vos applications. Pour vous protéger contre les pannes au niveau de la région, nous vous recommandons vivement de déployer plusieurs clusters de région. Bien qu’elles soient rares, leur impact éventuel est grave.
Pour la continuité d’activité, il n’est pas suffisant d’utiliser une base de données de plusieurs régions. D’autres parties de votre application doivent également être distribuées ou équipées de mécanismes adéquats pour basculer en cas de défaillance. Si vos utilisateurs sont répartis dans de nombreux emplacements géographiques, un déploiement de centre de données de plusieurs régions pour votre base de données offre l’avantage supplémentaire de réduire la latence. Tous les nœuds de tous les centres de données du cluster peuvent servir les opérations de lecture et d'écriture en provenance de la région la plus proche.
Si l’application est configurée pour être active-active, réfléchissez à la façon dont le théorème CAP s’applique à la cohérence de vos données entre les réplicas (nœuds) et les compromis nécessaires à la haute disponibilité.
En termes de théorème CAP, Cassandra est par défaut un système de base de données à tolérance de partition disponible (AP), avec une cohérence hautement paramétrable. Pour la plupart des cas d'utilisation, nous recommandons d'utiliser LOCAL_QUORUM pour les lectures.
En mode actif-passif pour les opérations d'écriture, il existe un compromis entre la fiabilité et les performances. Pour plus de fiabilité, nous vous recommandons le QUORUM_EACH, mais pour la plupart des utilisateurs, LOCAL_QUORUM ou QUORUM est un bon compromis. En cas de panne régionale, certaines écritures peuvent être perdues dans LOCAL_QUORUM.
Si une application s’exécute en parallèle, préférez les écritures QUORUM_EACH dans la plupart des cas pour garantir la cohérence entre les deux centres de données.
Si votre objectif est de favoriser la cohérence, ou un RPO inférieur, plutôt que la latence ou la disponibilité, ou un RTO inférieur, vos paramètres de cohérence et facteur de réplication doivent refléter cet objectif.
En général, le nombre de nœuds de quorum requis pour une lecture plus le nombre de nœuds de quorum requis pour une écriture doit être supérieur 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 est déployé uniquement dans une seule région. La région est celle sélectionnée lorsque vous déployez le 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.
Étant donné que les centres de données doivent continuer à fonctionner, ce problème n’affecte pas le contrat SLA de disponibilité pour le service. Pendant cette période, il peut être impossible d’apporter des modifications à la configuration de la base de données à partir du portail Azure ou des outils du fournisseur de ressources.
Réplication
Nous vous recommandons d’auditer keyspaces et de configurer leurs paramètres de réplication de temps à autre pour vous assurer que la réplication requise entre les centres de données est configurée. Au début du développement, nous vous recommandons d’effectuer des tests simples à l’aide cqlshde . Par exemple, insérez une valeur lors de la connexion à un centre de données et lisez-la à partir de l’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, déterminez que vous avez répliqué toutes les données et que le système est prêt. Nous vous recommandons de surveiller la progression de la réplication via nos commandes DBA avec nodetool netstats. Une autre approche consiste à compter les lignes de chaque table. Gardez à l’esprit qu’avec les tailles de Big Data, en raison de la nature distribuée de Cassandra, cette approche ne peut donner qu’une estimation approximative.
Équilibrage du coût de la récupération d’urgence
Si votre application est active-passive, nous vous recommandons toujours généralement de déployer la même capacité dans chaque région. Cette approche permet à votre application de basculer instantanément vers un centre de données de secours à chaud dans une région secondaire. Si une panne régionale se produit, cette approche ne garantit aucune dégradation des performances. La plupart des pilotes clients Cassandra fournissent des options pour lancer un basculement au niveau de l’application. Par défaut, ils supposent que la panne régionale signifie que l’application est également en panne. Par conséquent, le basculement doit se produire au niveau de l’équilibreur de charge.
Pour réduire le coût d’approvisionnement d’un deuxième centre de données, 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. Quand une panne se produit, une mise à l’échelle horizontale et verticale clé en main rend la mise à l’échelle plus facile dans Azure Managed Instance pour Apache Cassandra. Pendant que vos applications basculent vers votre région secondaire, vous pouvez effectuer un scale-out et un scale-up manuellement des nœuds dans votre centre de données secondaire. Votre centre de données secondaire agit comme une veille chaude à moindre coût. L’application de cette approche doit être équilibrée par rapport au temps nécessaire pour restaurer votre système en capacité totale si une panne se produit. IL est important de tester et de pratiquer ce qui se produit en cas de perte d’une région.
Remarque
Le scale-up de nœuds est beaucoup plus rapide que le scale-out. Gardez cet élément en tête lorsque vous pensez à 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. Vous pouvez choisir votre propre planification pour les sauvegardes quotidiennes. 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. Elles dépendent de la charge de travail et de la stratégie de compactage choisie.
Important
L’intention des sauvegardes est uniquement d’atténuer la perte accidentelle de données ou la corruption 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. Même s’ils l’étaient, il peut prendre beaucoup de temps pour récupérer une base de données à partir de sauvegardes. Par conséquent, nous recommandons vivement des déploiements dans plusieurs régions, couplés à l’activation des zones de disponibilité dans la mesure du possible, afin d’atténuer les scénarios d’urgence et de pouvoir s'en relever efficacement. Cette approche est particulièrement importante dans les scénarios rares où la région ayant échoué ne peut pas être récupérée. Sans réplication multirégion, toutes les données peuvent être perdues.
