"Vous rendez les choses si intuitives et si faciles qu'elles me donnent confiance. Pourquoi tout ne peut-il pas être aussi facile ?"
- Client anonyme
Dans ma première poste lors de notre discussion sur les mises à niveau, nous avons terminé par quelques mises en garde concernant la réplication. Cette fois-ci, nous allons nous pencher sur quelques problèmes rencontrés par les clients et sur la meilleure façon de les résoudre.
Reprenons là où nous nous sommes arrêtés : le versionnage. À partir de la version 5.0.1, Qumulo applique une règle de deux trimestres en matière de réplication (si vous vous souvenez du mois dernier, les versions trimestrielles sont désignées par le troisième chiffre, un 0). Si nous prenons la version 5.3.0, cela correspondrait à deux trimestres avant (5.1.0 et 5.2.0) et deux trimestres après (6.0.0 et 6.1.0). Il est important de noter qu'une publication de points au-dessus du 0 n'est pas comprise dans la fourchette. Si l'on reprend l'exemple précédent de la version 5.3.0, la version 6.1.0 est la limite stricte puisqu'il s'agit de la version trimestrielle. 6.la version 1.1 est tout à fait nouvelle en ce qui concerne la réplication et la version 5.3.0 refusera catégoriquement de lui parler.
Vous pouvez vous demander quelles sont mes options si nous procédons par inadvertance à une mise à niveau en dehors de la fenêtre de deux trimestres ? Dans ce cas, vous devrez mettre à niveau le côté source de la relation. Dans le même ordre d'idées, l'équipe de réussite des clients de Qumulo est souvent interrogée sur la question suivante : "Dois-je interrompre la réplication pendant la mise à niveau ?" Non, monsieur, vous ne devriez pas. Le moteur de réplication est un cookie intelligent et reprendra lorsque la mise à niveau sera terminée. Lorsqu'il s'agit de mises à niveau et de réplications, il n'y a rien d'autre à faire que de le faire.
Une autre question qui revient souvent dans les couloirs de Customer Success concerne la modification des éléments de la source, par exemple le renommage d'un répertoire source. Disons, par exemple, que nous répliquons `/financials/current_fiscal' et que nous voulons le renommer en '/financials/FY2023'. Allons-nous finir par répliquer toutes les données ? Il s'agit là d'un gros point négatif. Puisque nous avons changé le nom, cela déclenchera une vérification, mais ne répliquera rien en réalité. Au lieu de cela, dans les journaux de réplication, vous verrez la valeur "Skipped" augmenter au fur et à mesure que le "petit moteur de réplication" parcourt les données et s'assure que rien n'attend d'être transféré.
Que se passe-t-il si vous avez une structure de répertoire `/zoo/animals/mammals/capybara, mais que vous souhaitez uniquement mettre en place une politique spéciale pour les "mammifères" ? La structure du répertoire sera-t-elle copiée pour vous ou devrez-vous la créer ? Notre équipe de développement a veillé sur vous ce jour-là - le moteur de réplication Qumulo créera les répertoires précédents pour vous, recréant l'arbre en tant que "/zoo/animaux/mammifères/" sur la destination lorsque cette politique prend effet.
Arrêtons-nous un instant sur les politiques. Ai-je besoin de politiques instantanées ? Pas du tout. Vous pouvez mettre en place une relation de réplication continue sans aucune politique. C'est à l'entreprise de décider s'il est judicieux ou non de le faire sans politique. Cependant, nous recommandons généralement l'utilisation de règles, principalement pour des raisons de configuration étendue.
Avec les politiques, vous pouvez configurer la réplication en tant que "politique+continue". Cela vous permettra de prendre et de transférer des instantanés sur la source à des moments précis, ainsi que de fixer une date d'expiration pour les instantanés du côté de la cible. Sans politique, vous serez limité à l'unique instantané de réplication du côté de la destination (à moins que vous n'activiez l'instantané à cet endroit). Au fur et à mesure que vous augmentez le nombre de réplications vers votre site de reprise après sinistre, vous voudrez probablement envisager de mettre en œuvre des règles, si ce n'est pas déjà fait.
Enfin, considérons les utilisateurs locaux et la réplication. Si vous avez défini des utilisateurs locaux sur le cluster source, devez-vous définir les mêmes utilisateurs locaux sur le cluster de destination ? La meilleure pratique est de le faire. Le cluster va référencer l'UID NFS si des permissions locales ont été définies sur les fichiers. En répliquant ces fichiers, si l'UID n'est pas défini du côté de la destination, le cluster ne saura pas qui doit obtenir les permissions, arrêtera la réplication et enverra une erreur du type
" Dernière tentative : /data/ ne peut pas être répliqué car il appartient à un utilisateur local. Supprimez tous les utilisateurs et groupes locaux du fichier ou assurez-vous que tous les utilisateurs et groupes locaux sont associés à des identifiants NFS et modifiez la relation pour permettre le mappage des identifiants locaux aux identifiants NFS."
Vous devez également vérifier les utilisateurs locaux sur la source (Cluster -> Utilisateurs et groupes locaux) et les recréer sur la destination. Dans la relation, vous devrez modifier la case à cocher pour "Map Local User/Group IDs to Associated NFS IDs". Le moteur de réplication réessayera automatiquement après 60 secondes, donc si vous avez fait tout ce qu'il fallait, la réplication reprendra et continuera à fonctionner.
Idéalement, cela a dissipé certaines confusions sur la réplication et la manière dont elle est liée à votre cluster Qumulo. Comme toujours, si vous avez des questions, n'hésitez pas à contacter votre canal Slack et votre ingénieur de succès client Qumulo sera heureux de vous aider. Revenez bientôt, et nous plongerons dans le monde merveilleux des instantanés.
Jusqu'à la prochaine fois !