Guide de l'administrateur NetBackup™ pour Apache Cassandra

• Assurez-vous que NetBackup prend en charge la version de Cassandra installée. Pour plus d'informations, reportez-vous à la Liste de compatibilité logicielle.

• À partir de NetBackup 10.5, la version minimale du système d'exploitation requise pour les nœuds Cassandra est RHEL 8.6.

• L'hôte de sauvegarde, le serveur intermédiaire de données et Cassandra sont pris en charge sur la plate-forme RHEL uniquement.

• NetBackup requiert que la distribution Apache/DataStax et la version de cluster DSS (serveur intermédiaire de données) soient identiques à celles du cluster de production qui est protégé.

  NetBackup prend en charge les déploiements basés sur yum et tar pour le cluster DataStax Cassandra dans DSS et en production. Les clusters DSS et de production doivent avoir le même type de déploiement.

• NetBackup requiert qu'environ 20 % des nœuds du datacenter soient protégés en tant que DSS.

• L'authentification SSL n'est pas prise en charge pour Apache Cassandra.

• Le déploiement tarball n'est pas pris en charge avec Apache Cassandra.

• Le DSS doit être ajouté à l'environnement de sauvegarde, afin que NetBackup puisse effectuer les opérations suivantes :

  • préparer les données dans le DSS 

  • dédupliquer l'enregistrement des données sur le stockage de sauvegarde ;

  • copier les données sur le support NetBackup.

• Le DSS doit disposer de la même version de Cassandra que le cluster de production de Cassandra.

• À partir de NetBackup 10.3, les informations d'authentification de production DSS et Cassandra doivent être ajoutées dans la console de gestion des informations d'authentification NetBackup avant l'ajout de clusters de production DSS et Cassandra. L'étape suivante du workflow d'ajout de cluster de production DSS et Cassandra consiste à sélectionner les informations d'authentification souhaitées dans la liste d'informations d'authentification existante.

• NetBackup prend en charge SSL, LDAP et DataStax Cassandra avec authentification simple. Utilisez le nom d'utilisateur et le mot de passe de la base de données pour connecter Cassandra et exécuter des commandes telles que cqlsh et nodetool utils. Configurez Cassandra dans les informations d'authentification NetBackup lors de la configuration du cluster DSS et de la configuration du cluster Cassandra.

• Activez SSH sur tous les nœuds Cassandra et nœuds DSS.

• Assurez-vous que l'heure locale des nœuds Cassandra, du DSS et des hôtes de sauvegarde est synchronisée par rapport au serveur NTP.

• Configurez un compte d'utilisateur hôte non racine pour le cluster du serveur intermédiaire de données dans le système de gestion des informations d'authentification NetBackup.

  Remarque :

  Le compte d'utilisateur hôte non racine peut être distinct ou identique. Il doit être valide et disposer d'un dossier d'origine ainsi que du droit de connexion aux nœuds correspondants avec ssh. Ajoutez l'utilisateur hôte dans le fichier sudoers sur les nœuds concernés. Le nom d'utilisateur et le mot de passe associés à la base de données doivent être identiques sur DSS et sur le cluster d'application.

• Avant d'exécuter la sauvegarde ou la restauration de Cassandra, assurez-vous d'avoir reçu une réponse ping correcte de tous les serveurs intermédiaires vers les nœuds Cassandra et l'hôte de sauvegarde.

• Sélectionnez et mettez à jour les paramètres du pare-feu afin que les hôtes de sauvegarde, les serveurs intermédiaires de données et les nœuds Cassandra puissent communiquer.

• Vérifiez que les chemins d'accès spécifiés dans la configuration de cluster DSS existent sur tous les nœuds DSS et Cassandra.

• Après la mise à niveau de Cassandra ou la modification d'un schéma (suppression d'un espace de clés ou d'une famille de colonnes, par exemple), lancez une sauvegarde complète avant tout travail de sauvegarde incrémentielle.

• Assurez-vous que le compte d'utilisateur hôte spécifié pour le cluster dispose d'un accès en lecture et en écriture aux dossiers spécifiés dans la configuration de cluster DSS.

• Le mappage d'hôte doit être effectué selon les préférences d'adresse IP.

• Assurez-vous que l'utilitaire SStableloader fonctionne entre les nœuds de production et le serveur intermédiaire de données.

• Vérifiez que l'espace libre et la mémoire sur le DSS sont trois fois supérieurs à la famille de colonnes dans le cluster Cassandra. Conservez une taille de mémoire similaire sur tous les nœuds DSS.

  Remarque :

  L'opération de compactage sur le DSS nécessite plus de mémoire. Le déploiement d'un volume de mémoire RAM plus important sur les nœuds DSS améliorera les performances de sauvegarde et de restauration.

• Conservez au moins 20 % d'espace libre sur les nœuds Cassandra durant les opérations de sauvegarde.

• Veillez à ce qu'il y ait suffisamment d'espace libre sur les nœuds de cluster cibles durant la restauration, en fonction de la taille des données restaurées.

• Avant de procéder à la restauration, veillez à ce que la version cible de Cassandra dispose de la même version que celle à partir de laquelle vous avez procédé à la sauvegarde.

• Avant de procéder à la restauration, vérifiez que le cluster cible et le cluster de serveur intermédiaire de données cible sont entièrement configurés dans NetBackup.

• L'annulation d'un travail parent dans un travail de restauration composé n'annule pas les travaux de restauration enfants. Vous devez annuler manuellement les travaux de restauration enfants.

• Assurez-vous que le nombre de connexions par hôte (cph) est défini sur 1 dans les paramètres DSS pour la sauvegarde Datastax Cassandra.

Autorisations RBAC pour un rôle Cassandra :

• Veillez à attribuer les autorisations de création et de mise à jour à :

  • Ajouter un cluster DSS ;

  • Ajouter le cluster Apache Cassandra.

  • Ajouter des nœuds DSS ;

  • Modifier le cluster Apache Cassandra.

• Les informations d'authentification de base de données du cluster DSS doivent être identiques à celles du cluster de production Cassandra.

• Vous devez désactiver l'option requiretty globalement et remplacer Defaults requiretty par Defaults !requiretty dans le fichier sudoers.

  Remarque :

  Cette action modifie la configuration globale de sudo.

• Dans le cas d'une installation basée sur tarball, vous devez toujours démarrer les services Cassandra à partir du chemin d'accès des fichiers binaires de l'installation basée sur tarball.

• Pour le compte utilisateur de base de données, si default_scheme est défini sur internal pour authentication_options dans le fichier dse.yaml, spécifiez l'utilisateur soumis à une authentification interne. Si default_scheme est défini sur LDAP, spécifiez le compte utilisateur LDAP.

• Pour les mises à niveau de NetBackup à partir de versions antérieures à la 10.2.1, vous devez déclencher manuellement la découverte pour les clusters DSS et de production.

• Le compte utilisateur de base de données configuré dans NetBackup pour les éléments suivants doit disposer de toutes les autorisations requises dans le cluster :

  • Cluster DSS

  • Sauvegarde et restauration du cluster de production Cassandra

  L'utilisateur doit pouvoir créer, afficher, mettre à jour et supprimer des ressources dans le cluster. Sur le cluster DSS, vous pouvez accorder des autorisations spécifiques ou attribuer le rôle de superutilisateur au compte utilisateur de base de données configuré.

• Assurez-vous que les chemins du répertoire de distribution DSS, du répertoire de travail et du répertoire d'origine du script ne sont pas identiques dans la configuration Cassandra.

  Remarque :

  Le chemin du répertoire de travail ne peut pas être défini sur /root.

• Veillez à mettre à jour la liste secure_path avec le chemin de l'exécutable Java dans le fichier /etc/sudoers.

• Modifiez le fichier cassandra.yaml pour définir les paramètres suivants sur tous les nœuds DSS :

  Paramètres	Description/valeur
  cluster_name	Nom du cluster. cluster_name : <Indiquez le nom du cluster DSS>
  num_tokens	Définissez num_tokens sur 1. num_tokens: 1
  initial_token	Calculez et définissez initial_token à l'aide de la commande suivante : python -c "print [str(((2**64 / number_of_nodes_in_cluster) * i) - 2**63) for i in range(number_of_nodes_in_cluster)]" initial_token: <To be calculated>
  incremental_backups	Désactivez incremental_backups. incremental_backups: false
  snapshot_before_compaction	Désactivez la création d'un snapshot avant chaque compactage. snapshot_before_compaction: false
  auto_snapshot	Désactivez la création automatique de snapshots. auto_snapshot: false
  compaction_throughput_mb_per_sec	Désactivez la limitation de compactage. compaction_throughput_mb_per_sec: 0 Remarque : Pour Cassandra 4.1 et versions ultérieures, définissez le paramètre sur compaction_throughput : 0MiB/s
  hinted_handoff_enabled	Désactivez les transferts suggérés. hinted_handoff_enabled: false
  cdc_enabled	Désactivez la fonctionnalité CDC. cdc_enabled: false
  enable_user_defined_functions	Activez les fonctions définies par l'utilisateur. enable_user_defined_functions: true Remarque : Pour Cassandra 4.1 et versions ultérieures, définissez le paramètre sur user_defined_functions_enabled : true
  enable_scripted_user_defined_functions	Activez les fonctions scriptées définies par l'utilisateur. enable_scripted_user_defined_functions: true Remarque : Pour Cassandra 4.1 et versions ultérieures, définissez le paramètre sur scripted_user_defined_functions_enabled: true