Parmi de nombreuses nouvelles fonctionnalités passionnantes, la prochaine Veeam Availability Suite v9 apportera plus d’améliorations pour les environnements des grandes entreprises. Dans ces environnements, deux caractéristiques principales se distinguent habituellement et nécessitent des solutions appropriées : l’évolutivité et l’administration de plusieurs filiales ou sites distants.

L’interaction avec l’OS invité des machines virtuelles protégées pour une sauvegarde et une restauration appropriées constitue une fonctionnalité avancée et particulièrement utile de notre logiciel. Notre solution étant entièrement sans agent, nos tâches de sauvegarde déploient un « runtime process » éphémère sur chaque machine virtuelle pour laquelle l’AAIP (Application-Aware Image Processing) est activé. Ce processus est responsable de l’orchestration des traitements VSS et effectue des tâches spécifiques aux applications concernées telles que la troncature des journaux de transactions ou l’indexation des fichiers de Guest OS.

Avant la v9, toutes les interactions avec le Guest OS étaient effectuées par le serveur de sauvegarde. Pour chaque VM protégée, la console centrale déployait le « runtime process » directement dans la VM (soit par l’intermédiaire du réseau, soit en utilisant les APIs VIX en l’absence de connexion réseau à la VM). Cela a toujours parfaitement fonctionné, mais au fil de la croissance des environnements protégés en taille et en complexité, deux limites sont devenues apparentes.

Tout d’abord, l’évolutivité. Le traitement AAIP (Application-Aware Image Processing) des Guest OS est orchestré par le serveur de sauvegarde, mais le nombre de VMs protégées dans un environnement client typique est devenue si élevé avec le temps que les ressources de serveur de sauvegarde ont commencé à constituer un goulot d’étranglement qui limite le nombre possible d’interactions simultanées avec le Guest OS.

La seconde limite est en quelque sorte liée à la première. Les environnements des grandes entreprises comportent en règle générale plusieurs sites distants, avec des environnements virtualisés déployés de manière locale pour servir les utilisateurs de ces filiales. Comme dans de tels scénarios le serveur VBR est généralement déployé au siège, toutes les interactions avec l’OS invité doivent se produire par l’intermédiaire de la liaison WAN, ce qui s’avère souvent lent.

 

1

 

Ainsi, même si un proxy et un repository distants étaient déployés sur le site de la filiale pour maintenir le trafic de sauvegarde et de restauration au niveau local, le trafic des interactions avec l’OS invité devait encore traverser le WAN, ce qui générait des problèmes d’évolutivité pour ces environnements.

Pour améliorer le niveau de performance, la v9 introduira le proxy d’interaction Guest OS. Les clients pourront assigner ce rôle virtuel à tout serveur Windows administré (y compris les proxys et repositorys de sauvegarde existants). Le proxy de sauvegarde distant d’une filiale est habituellement le candidat idéal pour cela, car c’est le plus proche des machines virtuelles qu’il protège :

 

2

 

Avec le proxy d’interaction Guest OS en place, le serveur de sauvegarde ne fera qu’envoyer des commandes de contrôle par l’intermédiaire de la liaison WAN. Ce sera le proxy d’interaction Guest OS « local » qui téléchargera le « runtime process » vers les VMs traitées. En conséquence, le trafic passant par la liaison lente sera minimisé, tandis que la charge du serveur VBR sera réduite. Et comme un unique serveur de sauvegarde sera capable de contrôler plusieurs proxys d’interaction avec l’OS invité, l’évolutivité sera améliorée de manière considérable. Par exemple, pensez à un utilisateur de niveau entreprise avec 500 sites distants. Cette entreprise peut paramétrer le proxy de sauvegarde de chaque site pour agir également en tant que proxy d’interaction avec l’OS invité, et tous seront contrôlés par le serveur de sauvegarde central. Et évidemment, plusieurs proxys d’interaction avec l’OS invité pourront aussi être utilisés dans le cadre d’un grand data center pour améliorer les performances et l’évolutivité des activités d’interaction.

Un autre avantage caché de cette fonctionnalité qui n’est pas immédiatement évident est d’obtenir l’accès à l’OS invité lorsque le traitement sans réseau via VIX n’est pas possible. Par exemple, quand le compte à hauts privilèges d’interaction avec l’OS invité nécessaire ne peut être fourni en raison de considérations de sécurité. En fait, vous pouvez désormais désigner un ordinateur Windows avec NICs dans les réseaux de production et de sauvegarde, et en tirer parti en tant que proxy d’interaction avec l’OS invité pour « transférer » les communications depuis le réseau de sauvegarde vers le réseau de production.

Mais les sauvegardes ne sont jamais que la moitié de l’histoire. Une fois que les données sont stockées de manière sûre dans un repository, une restauration peut s’avérer nécessaire. Et si nous regardons une fois encore depuis l’angle du site distant, aujourd’hui, les restaurations de niveau fichier doivent être effectuées par le serveur de sauvegarde central, sur lequel les fichiers de sauvegarde sont directement montés :

 

3

 

Ainsi, même si le repository de sauvegarde lui-même était « local » par rapport à l’environnement virtualisé distant, pendant les restaurations de niveau fichier à l’emplacement d’origine, les données doivent passer deux fois par la liaison WAN : la première pour être acheminée vers le serveur de sauvegarde, la seconde pour être renvoyées vers la machine virtuelle du site distant. Une solution de contournement répandue consiste à utiliser un assistant de restauration de niveau fichier (FLR) multi-OS avec appliance auxiliaire lancée sur le site distant. Toutefois, cette approche a ses propres inconvénients.

Avec la v9, ce n’est plus nécessaire grâce à un nouveau paramètre de serveur de montage pour chaque repository de sauvegarde. En fait, tout serveur Windows administré par Veeam peut désormais être désigné en tant que point de montage FLR pour les sauvegardes Veeam. Et bien sûr, il n’y a pas de meilleur choix pour un site distant qu’un repository Windows déjà existant jouant lui-même le rôle d’hôte de montage!

 

4

 

Maintenant, grâce à ce nouveau rôle virtuel, le serveur VBR central enverra uniquement des commandes de contrôle sur la liaison WAN, tandis que la sauvegarde distante sera montée par le serveur de montage « local » désigné pour restaurer les fichiers nécessaires directement sur la machine virtuelle distante, avec tous les transferts de données restant dans les limites du site distant.

Tant que nous parlons d’opérations « distantes », un nouvel élément très important à venir dans la v9 est la console autonome. Oui, nous parlons bien de la console Veeam Backup & Replication tant attendue que les administrateurs Veeam pourront installer séparément de leur serveur de sauvegarde, par exemple sur leur propre station de travail, et qui permettra l’administration du serveur de sauvegarde à distance à travers le réseau. Vous pouvez dire « au revoir » aux sessions RDP ou aux utilisateurs multiples qui se chassent les uns les autres en se connectant au même serveur de sauvegarde, car chaque opérateur pourra désormais disposer de sa propre console. Notamment, la console assume aussi le rôle de serveur de montage dans les scénarios de restauration avancés nécessitant le montage local des sauvegardes (tels que les Veeam Explorers), une fonctionnalité qui s’avérera très utile dans les scénarios ROBO.

Mais ce n’est pas tout pour aujourd’hui ! Comme vous avez déjà pu le voir dans la v8, nous nous employons pleinement à vous fournir la meilleure prise en charge de bandes du marché indépendamment de la taille de votre entreprise – et la v9 apportera de nombreuses améliorations supplémentaires à ce sujet que nos clients entreprise ont toujours voulu avoir. J’aborderai seulement les principales, mais je peux vous assurer qu’il y a beaucoup plus d’améliorations mineures !

D’abord, et c’est la plus importante de toutes, il y a la possibilité de créer un pool de supports détaché d’une seule bibliothèque physique et capable de s’étendre sur plusieurs bibliothèques. Ce « pool de supports global » deviendra la cible principale des tâches de sauvegarde sur bande et permettra d’améliorer les performances ainsi que l’expérience administrative dans son ensemble.

 

5

 

Une tâche de sauvegarde sur bande pointant vers le « pool de supports global » pourra utiliser plusieurs bibliothèques ou lecteurs autonomes selon l’ordre de basculement configuré pour les bibliothèques et basculer vers une des bibliothèques disponibles si un événement de basculement se produit. Par exemple, imaginez qu’une bibliothèque n’ait plus de supports vides ou que tous les lecteurs de bandes soient occupés. Grâce aux pools de supports globaux, une tâche de sauvegarde sur bande pourra désormais basculer vers une autre bibliothèque disposant de supports ou de lecteurs utilisables.

Quelles autres fonctionnalités exceptionnelles ajoutons-nous en ce qui concerne la performance opérationnelle des bandes ? Le traitement parallèle entre plusieurs lecteurs de bande tant demandé est une réalité avec la v9! Ce qui nécessitait auparavant de configurer plusieurs pools de supports et tâches de sauvegarde sur bande (augmentant ainsi la complexité) est désormais disponible dès l’installation!

 

6

 

Ce sera une option simple mais puissante qui vous permettra d’exécuter des tâches de sauvegarde sur bande pointant simultanément vers le même pool de supports ou de répartir l’archivage des fichiers de sauvegarde sources entre plusieurs lecteurs.

Ensuite, parlons de la rotation des bandes. Je suis sûr que nombre d’entre vous seront heureux d’apprendre qu’un nouveau type de pool de supports sera disponible dans la v9 : le pool de supports GFS dédié pour les sauvegardes complètes. Encore une fois, alors qu’il était possible d’aboutir largement au même résultat avec plusieurs pools de supports dans la v8, la v9 va encore plus loin en supprimant entièrement la complexité administrative associée à cette activité.

Si vous connaissez notre mécanisme existant de rotation des tâches de copie des sauvegardes (grand-père – père – fils [GFS]) de la v8, le concept reste le même ici, et il devrait donc être facile à comprendre. Lorsque les sauvegardes complètes sont dirigées vers le pool de supports GFS dans la configuration de la tâche de sauvegarde sur bande, les bandes correspondantes seront conservées selon un modèle de rétention spécifié en semaines, mois, trimestres ou même en années, aussi longtemps que votre stratégie de rétention des données l’exige.

Avec un pool de supports GFS, moins de bandes sont nécessaires pour obtenir une rétention plus longue. Par exemple, le modèle de rotation GFS configuré pour maintenir 4 années de sauvegardes complètes ne demandera que 19 bandes : 4 hebdomadaires, 12 mensuelles et 3 annuelles. Un pool de supports simple est encore disponible pour la rétention de sauvegardes complètes à court terme et les sauvegardes incrémentielles, et vous pouvez donc décider quel pool de supports correspond le mieux à votre scénario de rétention des données.

Et vous pouvez voir grâce à ce seul article de blog qu’il y a plusieurs améliorations importantes des fonctionnalités destinées aux grandes entreprises à venir dans la v9. Et croyez-moi, nous ne faisons que commencer à publier les annonces, car les fonctionnalités de niveau entreprise les plus intéressantes restent encore à dévoiler. J’espère que nos efforts démontrent clairement que nous attachons une grande importance aux besoins uniques de nos clients entreprise, et nous sommes déterminés à vous fournir un produit adapté à 100 % à vos attentes, et qui pourra facilement évoluer pour maintenir un niveau de disponibilité constant pour votre activité en expansion.

GD Star Rating
loading...
Améliorations de niveau entreprise dans la v9 — ROBO et bande, 5.0 out of 5 based on 1 rating
Veeam Availability Suite — Télécharger gratuitement

  • Olivier MOUTRET

    Cycle de vie des bandes.Cette présentation indique 19 bandes pour 5 ans, mais cela n’est pas une vu bande, car il ne faut pas oublier le cycle de vie (nombre d’écriture) préconisé par les constructeurs.
    4 hebdomadaires : donc, pour la bande du lundi, par exemple, 1 jours par semaine sur 5 ans = 1 * 52 * 5 = 260 cycles d’écritures. J’ai souvenir d’une préconisation de 60 à 80 cycles d’écriture.

    P1/ le GFS oblige de désigné des bandes jours, mois, ans, donc, c’est l’utilisateur qui devra comptabilité les cycles.
    P2/ Je n’ai pas trouvé de « carnet de santé » des bandes : date de premier formatage (mise en service), nombre d’écriture, nombre de lecture, nombre d’anomalie constaté, nombre d’effacement rapide/totale
    P3/ Sans gestion des cycles, il n’est pas possible de définir des stratégies d’optimisations des bandes : utiliser les hebdomadaire jusqu’à 60 cycles ; privilégier la/les bandes avec le plus grand nombre de cycle pour les sauvegardes à longues rétentions (bande année) ; privilégier les cycles entres 60 et 80 pour les mois.
    P4/ prévoir une vue « gestion des stock de bandes » afin que les utilisateurs y indique la localisation physique de la bande lorsque sera sortie de la bandothèque (information géographique du rangement de la bande) ; visualisation synthétique des cycles de vies, avec pourquoi pas des couleurs de criticités : vert, jaune, orange, rouge.
    P5/ optimiser et prévoir le nombre de bande a acheter par an en fonction de la consommation en cycle : prévision du budget ; voir même commande automatique des bandes auprès du fournisseurs.

    Voila l’idée de l’optimisation des bandes que j’attends d’un logiciel (sinon, je suis obliger de le faire avec mon tableur et j’aimerais vraiment ne plus avoir a le faire).

    Mais peut-être est-ce prévu ?

    GD Star Rating
    loading...
    • Dmitry Popov

      Bonjour Olivier,

      Merci pour vos commentaires. Nous n’avons pas pris en compte le cycle de vie des bandes lors de la rédaction de cet article de blog pour une raison très simple. Le GFS est principalement conçu pour l’archivage à long terme des sauvegardes complètes et donc prévu pour avoir une sauvegarde complète par bande. En parlant de recommandations, les spécifications LTO 6 indiquent 136 passes de bout en bout. Le bout en bout représente une lecture ou une écriture complète. Vos calculs sont exacts pour la sauvegarde hebdomadaire, mais uniquement si vous remplissez la bande de données.

      P1 – P3 : Ces fonctionnalités sont déjà prévues pour une date ultérieure, merci. En attendant, si je ne me trompe pas, vous pouvez utiliser les outils natifs pour suivre l’état d’intégrité de la bande. Cependant, nous ne suivons pas les supports marqués comme retirés.

      P4 : Bonne suggestion, merci – nous allons en discuter avec l’équipe.

      P5 : Avez-vous vu les récents rapports Veeam ONE pour les bandes ? Ils devraient offrir une visibilité complète en ce qui concerne l’exportation et la rotation des bandes.

      P.-S. Merci d’utiliser les forums de la communauté pour les demandes de fonctionnalités telles que celles-ci. Les forums sont administrés par l’équipe de gestion des produits, ce qui vous donne l’assurance que chacun de vos messages sera entendu.

      GD Star Rating
      loading...
Luca Dell'Oca
Author: Luca Dell'Oca

Publié: août 6, 2015