Comment le CNRS a résolu le casse-tête de ses sauvegardes

Plus de 24 heures pour une sauvegarde

En termes de sauvegarde, le CNRS utilisait une solution sur bande. Avec les inconvénients qui vont avec : système de file d’attente et délais de sauvegarde/restauration élevés. La situation n’était plus tenable : « les sauvegardes avaient lieu normalement la nuit, mais certaines dépassaient les 24 heures », rappelle David Bercot.

Plusieurs critères ont guidé le responsable dans le choix d’une nouvelle solution. La DSI – qui ne gère que les applications de gestion soit une centaine au total, et non les logiciels scientifiques des laboratoires – souhaitait une solution compatible avec l’état de l’art de ce qui se fait en matière de cloud privé, avec une automatisation poussée. Les équipes d’exploitation et d’experts ne devaient pas perdre leur temps sur des tâches répétitives. De plus, la sauvegarde devait tirer parti au maximum des fonctionnalités disponibles avec l’environnement « full VMware » du CNRS.

« Les solutions des éditeurs historiques fonctionnent sur tous les environnements, mais ne sont pas vraiment optimisées pour les environnements virtuels », constate David Bercot. 

Au final, deux fournisseurs figurent dans la short-list : Veeam évidemment, le plus connu, et Rubrik. « En creusant, nous avons constaté un certain nombre d’avantages intéressants avec Rubrik, en particulier l’intégration complète à vRA à vRO », justifie David Bercot.

Le CNRS a donc acquis deux appliances matérielles Rubrik, qui contiennent le stockage directement, pour l’instant installées toutes les deux à l’IN2P3. Les deux serveurs fonctionnent en mode réplication synchrone, ce qui permet de travailler sur l’une ou l’autre appliance de manière transparente, sans intervention humaine en cas de problème.

Le jour et la nuit

La première appliance est chargée de la sauvegarde des VM qui sont sur le site principal et les deux appliances se synchronisent. Au total, le cloud privé interne s’appuie sur 30 serveurs physiques, 563 machines virtuelles, sauvegardées sur les 67 To des appliances Rubrik.

« Nous n’avons plus à nous préoccuper des machines qui ne seraient pas sauvegardées. Quand une VM est créée, une politique de sauvegarde lui est appliquée automatiquement, en fonction de son statut : machine de production, recette, développement, etc. », indique David Bercot.

Du coup, au quotidien, c’est le jour et la nuit par rapport à la solution précédente pour les sept personnes en charge de l’exploitation à la DSI : « nous pouvons effectuer des sauvegardes en journée et plus seulement la nuit, car c’est extrêmement rapide (sauvegarde à base de snapshots). Les restaurations sont simples : il suffit de parcourir l’arborescence, de choisir les fichiers à restaurer et la bonne date », continue le responsable. 

Pour quelques millisecondes de plus

À l’origine, les deux appliances devaient être installées sur deux sites distants : Villeurbanne donc, et Grenoble. Mais cela ne fut pas possible… à 5 millisecondes près.

« C’est une contrainte de latence de VMware vSAN, qui fait que les deux sites ne peuvent pas être éloignés de plus d’une centaine de kilomètres. La solution de réplication supporte une latence maximum de 50 ms. Nous avions 55 ms avec le site de Grenoble… », relate David Bercot. L’une des appliances sera donc sans doute déplacée prochainement de l’IN2P3 dans l’agglomération lyonnaise.

Aux inconvénients supposés des disques par rapport aux bandes – plus grande fiabilité pour ces dernières et possibilité de les déconnecter du réseau pour plus de sécurité –, David Bercot argumente : « J’ai eu une mauvaise expérience avec des bandes illisibles au moment de la restauration. Je n’ai jamais eu ce problème avec des disques. Quant à la sécurité, on peut chiffrer les sauvegardes ».

Du moins en théorie. En 2019, le CNRS a demandé à la DSI de crypter des applications sensibles. « Nous pensions qu’avec Rubrik, le chiffrement était actif par défaut. Or ce n’est pas le cas. Et pour chiffrer a posteriori, il faut effectuer un reset complet du cluster Rubrik avec perte de l’intégralité des données », regrette David Bercot.

Du coup, un peu de « bricolage » va être nécessaire pour résoudre ce problème. À savoir déconnecter une appliance, faire un reset, resynchroniser avec l’autre appliance rn activant le chiffrement. Et même opération avec la deuxième appliance. Pas de quoi tempérer la satisfaction du responsable : « La prochaine étape sera d’intégrer notre base Oracle à notre cloud privé. Pour l’instant, elle est toujours sur une machine physique pour des questions de licences », affirme-t-il. Et là, c’est un tout autre challenge qui s’annonce.