Opérations de gestion dans Azure Managed Instance pour Apache Cassandra

Azure Managed Instance pour Apache Cassandra est un service complètement managé pour les clusters Apache Cassandra open source purs. Le service permet également aux configurations d’être remplacées, en fonction des besoins spécifiques de chaque charge de travail, ce qui permet une flexibilité et un contrôle maximum, le cas échéant.

Cet article définit les opérations et les fonctionnalités de gestion fournies par le service. Elle explique également la séparation des responsabilités entre l’équipe de support Azure et les clients lors de la gestion de clusters hybrides.

Compactage

• Il existe différents types de compactage. Ce service effectue actuellement un compactage mineur en utilisant la réparation. Pour plus d’informations, consultez Maintenance. Cette opération effectue un compactage d’arbre Merkle, qui est un type spécial de compactage.

• Selon la stratégie de compactage définie sur la table à l’aide de CQL, par exemple WITH compaction = { 'class' : 'LeveledCompactionStrategy' }, Cassandra compacte automatiquement lorsque la table atteint une taille spécifique. Nous vous recommandons de sélectionner soigneusement une stratégie de compactage pour votre charge de travail. Ne faites pas de compactage manuel en dehors de la stratégie.

Application de correctifs

• Les correctifs au niveau du système d’exploitation sont effectués automatiquement à une cadence de deux semaines.

• Les correctifs de niveau logiciel Apache Cassandra sont effectués lorsque des failles de sécurité sont identifiées. La cadence de mise à jour corrective peut varier.

• Lors de la mise à jour des correctifs, les machines sont redémarrées un rack après l'autre. Vous ne devez pas rencontrer de dégradation côté application tant que le paramètre ALL de quorum n’est pas utilisé et que le facteur de réplication est 3 ou supérieur.

• La version dans Apache Cassandra est au format X.Y.Z. Vous pouvez contrôler manuellement le déploiement de versions majeures (X) et mineures (Y) à l’aide d’outils de service. Les correctifs Cassandra (Z) qui peuvent être requis pour cette combinaison de versions majeures/mineures sont effectués automatiquement.

Entretien

• Le service exécute nodetool repair à l’aide de reaper. Cet outil est exécuté une fois par semaine. Si vous utilisez votre propre service pour un déploiement hybride, vous souhaiterez peut-être désactiver l'analyseur.

• La surveillance de l’intégrité des nœuds se compose des éléments suivants :

  • Surveillance active de l’appartenance de chaque nœud à l’anneau Cassandra.
  • Détection automatique et correction automatique des problèmes d’infrastructure tels que la machine virtuelle, le réseau, le stockage, Linux et la prise en charge des défaillances logicielles.
  • Surveillance proactive des problèmes d’UC, de disque, de perte de quorum et d’autres problèmes de ressources.
  • Afficher automatiquement les nœuds ayant échoué, dans la cas où cela est possible, et afficher manuellement les nœuds en réponse aux avertissements générés automatiquement.

Soutien

Azure Managed Instance pour Apache Cassandra fournit un contrat SLA pour la disponibilité des centres de données dans un cluster managé. Si vous rencontrez des problèmes lors de l’utilisation du service, effectuez unedemande de support dans le portail Azure.

Nos avantages de support sont les suivants :

• Point de contact unique pour les problèmes d’infrastructure Cassandra. Il n’est pas nécessaire de déclencher des cas de support avec des équipes IaaS telles que le disque, le calcul et la mise en réseau séparément.
• Conseils proactifs par courriel sur les goulets d'étranglement de performance, le dimensionnement des ressources et d'autres problèmes de contraintes de ressources.
• Prise en charge 24 h/24 et 7 j/7, y compris les incidents générés automatiquement pour les pannes graves.
• Prise en charge des correctifs approuvés par la communauté. Voir Mise à jour corrective.
• Prise en charge de l’équipe d’ingénierie Java JDK/JVM interne.
• Prise en charge du système d’exploitation Linux avec la sécurité de la chaîne logistique logicielle.

Sauvegarde et restauration

Les sauvegardes d’instantanés sont activées par défaut et effectuées toutes les 24 heures. Les sauvegardes sont stockées dans un compte de stockage Blob Azure interne et sont conservées pendant jusqu’à deux jours (48 heures). Il n’y a aucun coût pour les deux sauvegardes initiales. Des sauvegardes supplémentaires sont facturées. Consultez les tarifs. Pour modifier l’intervalle de sauvegarde ou la période de rétention, vous pouvez modifier la stratégie dans le portail Azure :

Pour effectuer une restauration à partir d’une sauvegarde existante, effectuez une demande de support dans le portail Azure. Lorsque vous déposez un cas de support, vous devez :

1. Indiquer l’ID de sauvegarde à partir du portail pour la sauvegarde que vous souhaitez restaurer. Vous trouverez cet ID dans le portail Azure :

   

2. Indiquez-nous si le centre de données source a été supprimé. Ce fait est important d’identifier le compte de sauvegarde approprié à partir duquel effectuer la restauration.

3. Si vous n'avez pas besoin de restaurer l'ensemble du cluster, indiquez l'espace-clé et la table, le cas échéant, qui doivent être restaurés.

4. Indiquez si vous souhaitez restaurer la sauvegarde dans le cluster existant ou dans un nouveau cluster.

5. Si vous souhaitez restaurer sur un nouveau cluster, vous devez d’abord créer ce cluster. Assurez-vous que le cluster cible correspond au cluster source en termes de nombre de centres de données. Vérifiez que le centre de données correspondant a le même nombre de nœuds. Vous pouvez également décider s’il faut conserver les informations d’identification dans le nouveau cluster cible. Vous pouvez également permettre à la fonction de restauration de remplacer le nom d'utilisateur et le mot de passe par ceux qui ont été créés à l'origine.

6. Vous pouvez également décider s’il faut conserver l’espace de clés system_auth dans le nouveau cluster cible ou autoriser la restauration à le remplacer par les données de la sauvegarde. L’espace de clés system_auth dans Cassandra contient des données d’autorisation et d’authentification interne, notamment des rôles, des autorisations de rôle et des mots de passe. Notre processus de restauration par défaut remplace l’espace de clés system_auth.

Sécurité

Azure Managed Instance pour Apache Cassandra fournit de nombreux contrôles et fonctionnalités de sécurité explicites intégrés :

• Images de machines virtuelles Linux renforcées avec une chaîne d’approvisionnement contrôlée.
• Surveillance commune des vulnérabilités et de l’exposition (CVE) au niveau du système d’exploitation.
• La rotation des certificats pour les logiciels Apache Cassandra et Prometheus hébergés sur les machines virtuelles gérées.
• Analyse active des vulnérabilités.
• Analyse active de virus.
• Pratiques de codage sécurisées.

Pour plus d’informations sur les fonctionnalités de sécurité, consultez Sécurité dans Azure Managed Instance pour Apache Cassandra.

Support hybride

Lorsqu’un cluster hybride est configuré, les opérations de reaper automatisées qui s’exécutent dans le service bénéficient à l’ensemble du cluster. Cet aspect inclut les centres de données qui ne sont pas approvisionnés par le service. Il vous incombe de maintenir votre centre de données local ou hébergé en externe.

Contenu connexe

• Créer un cluster Managed Instance à partir du portail Azure
• Déployer un cluster Apache Spark managé avec Azure Databricks
• Gérer les ressources Azure Managed Instance pour Apache Cassandra à l’aide d’Azure CLI