Veeam – Nouveauté Veeam v9 : ROBO

Veeam – Nouveauté Veeam v9 : ROBO

15 septembre 2015 0 Par Michael PERES

Veeam – Nouveauté Veeam v9 : ROBO

Parmi de nombreuses nouvelles fonctionnalités, la prochaine version de Veeam Availability Suite (v9), apportera plus d'améliorations pour les environnements d'entreprise. Dans ces environnements, deux caractéristiques principales surgissent habituellement, et exigent des solutions appropriées à savoir l'évolutivité et la gestion de plusieurs succursales ou bureaux distants.
Veeam reste une solution entièrement sans agent. Les jobs de sauvegarde déployent un processus d'exécution temporaire dans chaque machine virtuelle pour laquelle "Application Aware image Processing" est activé. Ce processus est responsable du traitement de "VSS orchestration", c'est à dire l'exécution des étapes de sauvegarde spécifiques aux applications telles que l'indexation du système de fichiers des machines virtuelles.
Avant la v9, toutes les interactions avec les VMs étaient effectuées depuis le serveur de sauvegarde. Pour chaque VM protégée, la console centrale déployait le processus d'interaction des clients directement dans la machine virtuelle (soit directement dans l'OS de la VM via le réseau, ou en utilisant l'API VIX via une connexion hôte pour les VMs sur des réseaux isolés). Cela a toujours fonctionné parfaitement, mais comme les environnements protégés ont augmenté en taille et en complexité, deux limites sont devenues inévitables.
Tout d'abord, l'évolutivité.
Le traitement des machines virtuelles est géré par le serveur de sauvegarde, mais la quantité de machines virtuelles protégées dans un environnement de client type a augmenté de manière significative au fil du temps, les ressources du serveur de sauvegarde a commencé à devenir un goulot d'étranglement – en limitant la quantité possible d'interactions simultanées avec les VMs avant que les jobs ne commencent à ressentir des délais d'attente (timeout).
La seconde limite est quelque peu liée à la première.
En général, les environnements d'entreprise ont également plusieurs bureaux distants, avec des environnements virtualisés, déployés localement et destinés aux utilisateurs de ces succursales. Etant donné que dans de tels scénarios, le serveur VBR est généralement déployé à un seul endroit, toutes les interactions avec les VMs se produisent via une liaison WAN, qui est généralement lente.

1Donc, même si à la fois un proxy distant et un "repository" ont été déployés sur site afin que le trafic de la sauvegarde et de la restauration soit exécuté en local, le trafic qui concerne l'interaction entre le serveur et les VMs, a encore besoin de franchir la liaison WAN. Ce qui jusque là, entraînait des problèmes d'évolutivité pour ces types d'environnements.
Afin d'améliorer ces performances, Veeam a mis en place en place un rôle de type "proxy d'interaction", dans la v9.
L'utilisateur peut attribuer ce rôle à un serveur virtuel Windows géré par Veeam (y compris à un "Backup Proxy" ou à un "repository" existant). Le Backup proxy d'un site distant est généralement le client idéal, puisqu'il est le plus proche des machines virtuelles qu'il protège:

2Grâce à ce rôle de proxy d'interaction sur le site distant, le serveur Veeam Backup n'envoie uniquement que les commandes de contrôle à travers le lien WAN. Ce sera le proxy d'interaction local qui prendra en charge le processus d'interaction afin d'effectuer les jobs de sauvegarde des machines virtuelles. Par conséquent, le trafic traversant la liaison lente (WAN) sera minimisé, tandis que la charge sur le serveur Veeam Backup sera réduite. Il sera donc possible depuis un seul serveur de backup de contrôler plusieurs rôles proxy d'interaction, ce qui peut énormément améliorer l'évolutivité de certaines infrastructures de sauvegarde.

Cette fonctionnalité cache un autre avantage (pas nécessairement évident à voir), qui concerne l’accès au système d'exploitation d’une VM lorsque le traitement d’un job de sauvegarde ne peut pas passer par le réseau VIX. Par exemple, lorsqu’un compte disposant de privilèges élevés est requis pour interagir avec une VM, mais ne peut être fourni pour des raisons de sécurité.
Vous pouvez maintenant désigner un ordinateur Windows avec un port réseau à la fois sur le LAN de production et sur le LAN de sauvegarde, et qui, comme un proxy d'interaction, va transférer la communication à partir du réseau de sauvegarde vers le réseau de production.
Cependant, une fois que les données sont stockées et en sécurité, une restauration peut être nécessaire.
A ce jour, la restauration d’une VM dans une infrastructure de type « site distant », est exécuté depuis un serveur de sauvegarde centralisé, possédant des fichiers de sauvegarde directement « mappés » sur ce serveur de sauvegarde centralisé:

3Donc, même si sur un site distant, le repository de sauvegarde est lui-même "local", durant la restauration de fichiers, les données doivent traverser la liaison WAN à deux reprises. Un premier flux depuis la machine virtuelle vers le serveur de sauvegarde, puis un second flux (retour) vers la machine virtuelle située le site distant.
Avec Veeam v9, ces échanges ne sont plus nécessaires puisqu’un nouveau type de serveur appelé « serveur de montage » ou « Mount server » pour chaque repository de sauvegarde. N’importe quel serveur Windows géré par Veeam peut maintenant être désigné comme un point de montage FLR pour les sauvegardes Veeam. Il est évident, qu’il n'y a pas de meilleur choix pour un site distant que d'utiliser un repository de type Windows déjà existant, et qui soit lui-même son propre « Mount Server ».

4Grâce à ce nouveau rôle, le serveur VBR centralisé n’enverra plus de commandes de contrôle sur la liaison WAN, et la sauvegarde distante sera montée par le serveur local, désigné comme Mount Server pour restaurer les fichiers nécessaires directement dans la VM, tout en conservant les transferts de données sur le site distant.
Une autre nouveauté très importante arrive en v9, c’est la console autonome. Cette fameuse console Veeam Backup & Replication que les administrateurs Veeam pourront installer séparément à partir du serveur de sauvegarde, par exemple sur leur propre poste de travail, permet de gérer le serveur de sauvegarde à distance sur le réseau. Plus de sessions RDP ou multi-utilisateurs de déconnexion entre plusieurs connexions sur le même serveur de sauvegarde. Chaque opérateur sera désormais en mesure d'avoir sa propre console. La console porte également le rôle de « Mount Server » pour les restaurations de type avancées (telle que FLR) et qui requièrent l’accès aux sauvegardes afin d’y être monté en locale (comme Veeam Explorer par exemple). Une possibilité qui sera très utile dans les scénarios de type ROBO (Remote Office – Branch Office).