« Vous le rendez si intuitif et trop facile, cela me donne confiance. Pourquoi tout ne peut-il pas être aussi simple ? »
— Client anonyme
Dans mon premier poster, notre discussion sur les mises à niveau s'est terminée par quelques mises en garde à garder à l'esprit concernant la réplication. Cette fois, nous allons nous plonger dans quelques éléments qui ont frappé la table de réussite des clients et la meilleure façon de les résoudre.
Commençons là où nous nous sommes arrêtés : le versioning. À 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 étant un 0). Si nous regardons la version 5.3.0, cela concernerait 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 version de point au-dessus du .0 n'est pas dans la plage. En utilisant notre exemple précédent de 5.3.0, 6.1.0 est la limite stricte car c'est le trimestriel. 6.1.1 est un tout nouveau stade en ce qui concerne la réplication et 5.3.0 refusera catégoriquement de lui parler.
Vous vous demandez peut-être quelles sont mes options si nous effectuons une mise à niveau par inadvertance en dehors de la fenêtre de deux trimestres ? Dans ce cas, vous devrez mettre à niveau le côté source de la relation. Dans ce sens, on demande souvent à l'équipe de réussite client de Qumulo, "devrais-je suspendre la réplication pendant la mise à niveau?" Non monsieur, vous ne devriez pas. Le moteur de réplication est un cookie intelligent et reprendra une fois la mise à niveau terminée. En ce qui concerne les mises à niveau et les réplications, il n'y a rien d'autre à faire que de le faire.
Une autre question qui frappe les couloirs de Customer Success concerne la modification des éléments de la source, comme renommer un répertoire source. Disons, par exemple, que nous reproduisons `/financials/current_fiscal' et que nous voulons le renommer en '/financials/FY2023'. Allons-nous finir par re-répliquer toutes les données ? Gros négatif là. Puisque nous avons changé le nom, cela déclenchera une vérification, mais ne reproduira rien. Au lieu de cela, dans les journaux de réplication, vous finirez par voir la valeur "Skipped" augmenter en taille alors que le "petit moteur de réplication qui pourrait" traverser les données et s'assurer que rien n'attend d'être transféré.
Que se passe-t-il si vous avez une structure de répertoires de `/zoo/animals/mammals/capybara, mais que vous souhaitez uniquement mettre en place une politique spéciale sur les 'mammifères' ? Copiera-t-il la structure du répertoire pour vous ou dois-je le créer ? Notre équipe de développement s'occupait de vous ce jour-là - le moteur de réplication Qumulo créera les répertoires précédents pour vous, recréant l'arborescence sous la forme '/zoo/animals/mammals/' sur la destination lorsque cette politique entrera en vigueur.
Arrêtons-nous un instant et discutons des politiques. Ai-je besoin de politiques d'instantanés ? Pas du tout. Vous pouvez configurer une relation de réplication continue vanille sans qu'aucune stratégie ne soit requise. Qu'il soit logique ou non de le faire sans politique est une décision commerciale. Cependant, nous recommandons généralement des stratégies, principalement à des fins de configuration étendue.
Avec les stratégies, vous pouvez configurer la réplication en tant que "stratégie + continue". Cela vous donnera la possibilité de prendre et de transférer des instantanés sur la source à des moments précis, ainsi que de définir une expiration d'instantané du côté cible. Sans politique, vous serez limité à l'instantané de réplication unique côté destination (sauf si vous y activez l'instantané). Au fur et à mesure que vous augmentez le nombre de réplications sur votre site de reprise après sinistre, vous souhaiterez probablement étudier la mise en œuvre de stratégies si vous ne l'avez pas déjà fait.
Enfin, considérons les utilisateurs locaux et la réplication. Si des utilisateurs locaux sont définis sur le cluster source, devez-vous définir les mêmes utilisateurs locaux sur la destination ? En tant que meilleure pratique, vous devriez. Le cluster va référencer l'UID NFS si des autorisations locales ont été définies sur les fichiers. En répliquant ceux-ci, si l'UID n'est pas défini du côté de la destination, le cluster ne saura pas qui doit obtenir les autorisations, arrêter la réplication et renvoyer 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 ont des ID NFS associés et modifiez la relation pour permettre le mappage des ID locaux aux ID NFS.
Vous devrez également vérifier les utilisateurs locaux sur la source (Cluster -> Utilisateurs et groupes locaux) et recréer ceux sur la destination. Dans la relation, vous devrez la modifier pour cocher la case "Map Local User/Group IDs to Associated NFS IDs". Le moteur de réplication réessayera automatiquement après 60 secondes, donc tant que vous avez tout fait correctement, la réplication reprendra et continuera à fonctionner.
Idéalement, cela a dissipé une certaine confusion sur la réplication et son lien avec votre cluster Qumulo. Comme toujours, si vous avez des questions, n'hésitez pas à nous contacter sur votre canal Slack, et votre sympathique ingénieur de la réussite client de Qumulo se fera un plaisir de vous aider. Revenez bientôt, et nous plongerons dans le monde merveilleux des instantanés.
Jusqu'à la prochaine fois!
