Quand nous avons lancé Veeam Backup & Replication v6, une des grandes nouveautés résidait dans notre évolutivité pour l’entreprise grâce à notre architecture distribuée et notre équilibrage de charges intelligent et automatique. Passer à l’architecture proxy/référentiel a représenté un grand pas pour nous parce que toutes les activités de sauvegarde antérieures s’exécutaient au moyen d’un serveur de sauvegarde unique. Il y avait plusieurs raisons de passer à cette architecture…
- Distribuer le traitement des sauvegardes sur plusieurs serveurs proxy pour faciliter la mise à l’échelle de votre déploiement B&R.
- Atteindre une disponibilité et une redondance plus élevées : si un proxy tombe en panne, un autre peut encore terminer la tâche. Il n’y a plus de point de défaillance unique.
- Réduire l’incidence des sauvegardes sur l’infrastructure de production au moyen de l’équilibrage intelligent des charges.
- Simplifier considérablement la planification des tâches (en contrôlant automatiquement la concomitance des tâches souhaitées).
- Contrôler la saturation du stockage de sauvegarde (lorsque celui-ci est trop lent).
Avec l’équilibrage de charges automatique et intelligent, Veeam Backup & Replication choisit le meilleur serveur proxy (en termes de connectivité aux données des VM et de charge moindre sur d’autres tâches) pour effectuer la sauvegarde d’une VM à chaque exécution de la tâche. Avec la v7, nous avons amélioré encore plus les choses en ajoutant le traitement parallèle. Ainsi, une VM comportant plusieurs disques virtuels pouvait être sauvegardée par plus d’un proxy en même temps. En termes simples, voici l’ordre de priorité utilisé par un serveur de sauvegarde pour déterminer le meilleur proxy pour un disque virtuel VMware donné :
- Direct SAN (accès direct au stockage, aucun impact sur les hôtes de production)
- Ajout à chaud (accès direct au stockage par la pile I/O ESXi)
- Network Block Device – NBD- (les données des VM sont récupérées sur le réseau au moyen de l’interface d’administration ESXi)
Lorsque vous configurez un proxy Veeam pour VMware, vous pouvez choisir manuellement les modes de connexion et les datastores, ou laisser le proxy les détecter automatiquement. Vous pouvez aussi définir le nombre maximum de tâches concomitantes pour le proxy :
Le serveur de sauvegarde prend aussi en compte la charge courante (nombre maximum de tâches concomitantes) pour s’assurer que l’infrastructure n’est pas surchargée. Avec la v7, nous avons aussi amélioré nos algorithmes de compression pour réduire considérablement l’utilisation du CPU et permettre à chaque proxy d’effectuer davantage de travail. Quand les clients sont passés à la v7 et ont commencé à la faire fonctionner à son rythme, une chose est devenue claire… nous étions trop rapides !
Pour nombre de nos clients, laisser les tâches et proxys de sauvegarde en mode entièrement automatique ne constituait aucun problème. Les tâches de sauvegarde s’achevaient dans les temps et il n’y avait aucune réclamation. Mais certains clients, en particulier ceux traitant des charges 24/7 (l’activité ‘always-on’) et ayant déployé trop de proxys de sauvegarde, rencontraient des problèmes de disponibilité du stockage de production en raison de la trop grande charge liée aux tâches de sauvegarde. Les applications devenaient moins réactives pendant les sauvegardes et certains clients recevaient même des alertes dans leurs systèmes de supervision. Le problème était le manque d’IOPS. La sauvegarde peut consommer un grand nombre d’I/O et si vous avez des VM effectuant des opérations qui consomment elles aussi beaucoup d’I/O parallèlement à la sauvegarde, des problèmes peuvent survenir.
Pour résoudre ce problème, nous avons d’abord choisi la solution de « facilité ». Nous avons tout simplement imposé des limites aux datastores (« pas plus de x tâches simultanées par datastore ») dans un des premiers correctifs de la v7. Mais cette solution restait trop difficile à gérer… Que se passait-il si quelqu’un plaçait un nouveau serveur SQL sur un datastore, rendant ainsi la limite soigneusement définie auparavant trop élevée ? Et si vous définissiez une limite trop basse et trop prudente, vous pouviez ne pas disposer d’une fenêtre suffisante pour achever vos sauvegardes. Il devenait clair pour nous que les limites manuelles ne convenaient pas dans les infrastructures virtuelles hautement dynamiques.
Ainsi avec la v8, nous vous présentons Backup I/O Control (en instance de brevet), une nouvelle fonctionnalité de Veeam Backup & Replication v8. Backup I/O Control est un nouveau paramètre global qui vous permet de définir les seuils de latence tolérée pour tout datastore VMware ou Hyper-V. Vous pouvez le considérer comme un accord de niveau de service pour vos data stores.
L’idée reste assez simple et comporte deux volets. Le premier paramètre, « Stop assigning new tasks to datastore at: », signifie que lorsque le serveur de sauvegarde assigne un proxy au disque virtuel, il prend désormais en compte la latence (IOPS). La tâche de sauvegarde attendra que le datastore ne soit « pas trop occupé » avant de démarrer la sauvegarde. Le second paramètre, « Throttle I/O of existing tasks at: », permet de gérer les cas où une tâche de sauvegarde s’exécute déjà et où la latence devient problématique en raison d’une charge externe. Par exemple, si un processus de maintenance SQL devait commencer à s’exécuter dans une VM utilisant le même datastore que la tâche de sauvegarde, la tâche de sauvegarde limiterait automatiquement ses I/O de lecture à partir du data store correspondant afin que la latence chute en dessous du seuil défini. La tâche de sauvegarde pourra prendre un peu plus longtemps dans ce cas, mais au moins, elle n’affectera pas les applications.
Vous pouvez découvrir un exemple de ce paramètre en action dans le graphique ci-dessous, où le contrôle des I/O est activé :
La ligne verte du graphique représente la latence de lecture. Vous pouvez voir qu’après avoir activé Backup I/O Control, la latence de lecture chute en dessous de 20 ms, puis dérape à nouveau lorsque celui-ci est désactivé.
Dans Veeam Backup & Replication v8, Backup I/O Control constitue un paramètre global de notre Enterprise Edition. En ce qui concerne les valeurs par défaut, nous avons décidé d’employer des seuils légèrement réduits pour refléter les niveaux d’avertissement et d’erreur que nous voyons habituellement chez nos clients utilisant nos solutions de supervision. Cependant, ils restent entièrement personnalisables.
Si vous utilisez notre édition Enterprise Plus, vous pouvez utiliser Backup I/O Control pour définir la latence par datastore, plutôt que de manière globale. Ceci s’avère particulièrement utile si vous utilisez des datastores qui demandent des paramètres plus élevés ou plus bas selon leur charge ou leur importance. Par exemple, une latence plus élevée reste généralement acceptable pour les charges de test et de développement.
Comme toujours chez Veeam, nous répondons en permanence aux besoins de nos clients, et l’évolution de cette fonctionnalité ne fait pas exception à la règle. Avec l’introduction des serveurs proxy et du traitement distribué dans la v6, du traitement parallèle dans la v7, nous avons permis à nos clients de faire évoluer leur environnement plus facilement et de tirer le maximum du traitement de leurs sauvegardes dans la foulée. Désormais, avec l’ajout de Backup I/O Control dans la v8, nous donnons à nos clients les moyens de mieux personnaliser le degré auquel ils maximisent le traitement des sauvegardes. Cela leur procure la performance de sauvegarde la plus élevée possible tout en minimisant l’impact sur les charges de production – et en répondant mieux aux exigences de l’activité always-on.
