Vous le savez sans doute si vous me suivez sur ce blog depuis quelques mois, l’année 2014 aura été l’occasion, au sein de notre production, de repenser entièrement notre approche “stockage primaire” via le déroulement d’un schéma directeur stockage. Ce projet a conduit, en Juillet 2014, à l’acquisition de nouveaux équipements et à la mise en place progressive de niveaux de services associés. Pour plus d’information à ce sujet, je vous renvoie à ces billets sur ce même blog : ici, ici ou encore ici.
Pour autant le travail est loin d’être terminé car cette restructuration s’accompagne aussi nécessairement d’une ré-évaluation de nos capacités de sauvegarde associées. En effet, nos différents systèmes actuels ont été pensés il y a de cela plus de 5 ans et ne sont clairement plus adaptés à notre nouvelle approche. De plus, l’augmentation très forte de nos volumes de sauvegarde depuis 24 mois (plus de 30% par an) nous oblige à réinvestir massivement dans le support “back-end”. Ces contraintes pratiques et stratégiques nous ont poussé à dérouler un deuxième schéma directeur orienté “sauvegarde”, sur le même principe que celui du stockage primaire, à savoir : audit de l’existant, rencontres et interview des différents acteurs et décideurs, synthèse de recommandations en terme d’architecture, de volumétrie, vision long-terme.
Ce projet a abouti en fin d’année dernière et nous travaillons désormais à construire la nouvelle solution. Celle-ci doit respecter l’ensemble des préconisations faites lors de la phase d’étude, à savoir :
– Consolidation de tous les outils actuels (au nombre de 7 chez nous … un cauchemar pour nos équipes de MCO/Production) vers un ou deux maximum, gérant l’ensemble des sauvegardes de l’institution (serveurs, bases de données, NAS, postes de travail spécifiques, sites périphériques etc. …)
– Simplification des politiques de sauvegardes via des grandes classes de rétention
– Grande richesse et souplesse fonctionnelle pour les machines virtuelles (90% de notre production aujourd’hui)
– Automatisation maximum des tests de restauration, dans la mesure du possible
– Reporting riche et capacity planning
– Evolutivité très forte de la solution pour maintenir le rythmes de 4/5 prochaines années (volumétrie, performances)
Coté volumétrie, tous nos indicateurs nous poussent à envisager, via une croissance moyenne de 30% par an, à atteindre un volume brut protégé de l’ordre de 0,7 Po d’ici 2018. Autant dire que la future architecture doit être taillé pour absorber cette masse de données.
Les technologies sur lesquelles nous envisageons de nous appuyer sont : des back-end Datadomain, des front-end Veeam et Avamar. La nouveauté, pour nous (mais sans doute moins pour vous … ^^), c’est Veeam Backup & Replication. En effet, nous utilisons déjà depuis plusieurs années les VTL Datadomain et les appliances Avamar mais nous n’avons jamais eu l’occasion jusqu’à présent de concrétiser nos PoC et divers maquettes Veeam Backup. Malgré tout, la firme leader dans le monde du backup de VM apparait de plus en plus comme un outil parfaitement taillé pour assumer les enjeux décrits plus haut mais également susceptible de nous fournir des opportunités importantes en matière d’industrialisation et de nouvelles fonctionnalités.
Premier exemple, nos tests de restauration sont réalisés totalement manuellement aujourd’hui, VM par VM ou serveur par serveur, avec toute la lourdeur associée (restauration, démarrage en environnement isolé, tests fonctionnels très limités). La fonction SureBackup apporte une réponse “limpide” et industrielle à cette problématique, en tout cas sur le papier.
Second exemple : vCloud Director. Aujourd’hui, il ne nous est pas possible de restaurer facilement une VM géré par vCloud Director avec les outils en production chez nous. Il faut forcément passer par du scripting ou à défaut des procédure lourdes de restauration vSphere puis de ré-import dans vCloud de la VM à réintégrer. Veeam, quant à lui, dispose nativement de cette fonction de restauration intégrée vSphere/vCloud Director, ce qui permet d’envisager beaucoup plus sereinement des restaurations “cloud” en cas de besoin.
Il nous reste bien entendu, via un traditionnel PoC, à valider tout cela en environnement réel. Ce sera fait dans les prochains jours et je ne manquerai pas de vous en parler.
Bonjour,
On vient de tester la version 8 de Veeam Backup et réplication.
On utilise la fonction réplication depuis prêt d’un an pour ‘rapatrier’ de plusieurs datacenter vers un seul et ça marche très bien.
Je viens de tester la fonction de Backup sur du disque SATA sur un stockage Netapp et là surprise : c’est une grande réussite.
Par exemple, un serveur NAS (bientôt migré sur le NAS d’un VNX) était sauvegardé par TINA avec un agent, 700Go de données, prêt d’un million de fichiers, la sauvegarde complète prenait prêt de 40h et une incrémentale 20h. Avec Veeam, 6h pour la complète qui n’a lieu qu’une seul fois, et 30 à 40 minutes pour l’incrémentale et ça sur des disques 7200tr/min.
Mais en fait, c’est l’importance des montages des volumes de sauvegardes qui fait la différences, le serveur Veeam est une VM Windows 2012r2 et chaque volume de sauvegarde est créé dans sa propore LUN puis monté directement dans le Windows comme disque local.
Cerise sur le gateau, c’est super simple à mettre en oeuvre !