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 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. 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. Nous effectuons actuellement un compactage mineur par réparation (voir Maintenance). Effectue un compactage de l’arborescence 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 se 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 et de ne pas effectuer de compactages manuels 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 2 semaines environ.

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

• Lors de la mise à jour corrective, les machines sont redémarrées dans un rack à la fois. Vous ne devriez pas rencontrer de dégradation au niveau de l’application tant que le paramètre quorum ALL n’est pas utilisé, et que le facteur de réplication est supérieur ou égal à 3.

• La version dans Apache Cassandra est au format X.Y.Z. Vous pouvez contrôler le déploiement des versions majeures (X) et mineures (Y) manuellement via les outils de service. Tandis que les correctifs Cassandra (Z) qui peuvent être nécessaires pour cette combinaison de version majeure/mineure sont effectués automatiquement.

Maintenance

• La réparation Nodetool est exécutée automatiquement par le service à l’aide du réparer. Cet outil est exécuté une fois par semaine. Vous souhaiterez peut-être la désactiver si vous utilisez votre propre service pour un déploiement hybride.

• 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.
  • La détection et l’atténuation automatiques des problèmes d’infrastructure telle que les machines virtuelles, 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.
  • Affichage automatique des nœuds ayant échoué dans la cas où cela est possible, et affichage manuel des nœuds en réponse aux avertissements générés automatiquement.

Support

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 (disque, calcul, mise en réseau) séparément.
• Conseils pro-actifs par e-mail sur les goulots de bouteille de performance, le dimensionnement et d’autres problèmes de contrainte 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 2 jours (48 heures). Les 2 premières sauvegardes sont gratuites. Les sauvegardes supplémentaires sont facturées, consultez la tarification. Pour modifier l’intervalle de sauvegarde ou la période de rétention, vous pouvez modifier la stratégie dans le portail :

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

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

   

2. Indiquez-nous si le centre de données source a été supprimé. Il est important d’identifier le compte de sauvegarde approprié à partir duquel restaurer.

3. Si la restauration de l’ensemble du cluster n’est pas nécessaire, fournissez l’espace de clés 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. Vérifiez que le cluster cible correspond au cluster source en termes de nombre de centres de données et que le centre de données correspondant possède le même nombre de nœuds. Vous pouvez également décider de conserver les informations d’identification (nom d’utilisateur/mot de passe) dans le nouveau cluster cible ou d’autoriser la restauration à remplacer le nom d’utilisateur/mot de passe par ce qui a été créé à 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. Notez que 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 des vulnérabilités courantes & 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 antivirus active.
• Pratiques de codage sécurisées.

Pour plus d’informations sur les fonctionnalités de sécurité, consultez notre article ici.

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. Cela comprend les centres de données qui ne sont pas approvisionnés par le service. En dehors de cela, il vous incombe de gérer votre centre de données local ou hébergé en externe.

Étapes suivantes

Démarrez avec l’un de nos guides de démarrage rapide :

• 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