Loading...
Loading...
Loading...
L’On-Demand Sandbox permet d’effectuer des tests sur des VM en production. L'On-Demand Sandbox est un environnement virtuel isolé dans lequel il est possible de démarrer une ou plusieurs VMs à partir de sauvegardes, de réplicas ou de snapshots de stockage. Il est possible d’utiliser l’On-Demand Sandbox pour effectuer les tâches suivantes :
Troubleshooting sur les VMs
Tester les correctifs et les mises à jour de logiciels
Installer de nouveaux logiciels, etc.
L'On-Demand Sandbox utilise un Virtual Lab - un environnement isolé qui est entièrement clôturé de l'environnement de production. Les machines virtuelles démarrées dans le Virtual Lab restent en état de lecture seule. Toutes les modifications apportées aux machines virtuelles sont écrites dans les redo logs (pour les sauvegardes de machines virtuelles et les snapshots de stockage) ou enregistrées dans des fichiers delta (pour les réplicas). Les redo logs et les fichiers delta sont supprimés une fois que le travail avec l'On-Demand Sandbox est fini et éteint.
Dans l'On-Demand Sandbox, des VM peuvent être démarrées à partir de snapshots existant sur la baie de stockage de production.
Veeam Backup & Replication propose la fonctionnalité On-Demand Sandbox pour les systèmes de stockage suivants :
Dell EMC VNX(e), Unity XT/Unity
HPE 3PAR StoreServ and Primera, including secondary volumes — HPE 3PAR Peer Persistence
HPE StoreVirtual P4000 series and HPE StoreVirtual VSA (Virtual Storage Appliance)
IBM Spectrum Virtualize, including secondary IBM volumes — IBM Spectrum Virtualize HyperSwap • NetApp, including secondary arrays — NetApp SnapMirror and NetApp SnapVault
HPE Nimble storage, including secondary arrays — Nimble Snapshot Replicated Copy
Universal Storage API Integrated Systems
Il est possible de démarrer des VMs à partir de différentes sources dans l'On-Demand Sandbox :
Sauvegardes VM
Réplicas
VMs à partir de snapshots de stockage
Par exemple, peuvent être ajoutées des machines virtuelles provenant de sauvegardes et des machines virtuelles provenant de snapshot de stockage dans un même groupe d'applications et lier un job de réplication au job SureBackup.
SureBackup est la technologie de Veeam qui permet de tester les sauvegardes des machines et de vérifier s’il est possible de récupérer des données à partir de celles-ci. N'importe quel point de restauration d'une machine sauvegardée peut être vérifié.
La tâche SureBackup peut fonctionner selon deux modes différents de vérification de la restauration :
Test de restauration complet. Veeam Backup & Replication exécute des machines dans un environnement isolé directement à partir de la sauvegarde et effectue des tests contre des applications en direct.
Vérification des sauvegardes et analyse du contenu uniquement. Veeam Backup & Replication effectue une vérification de l'intégrité des sauvegardes et une analyse de leur contenu pour détecter des traces de malware ou toute autre donnée indésirable ou sensible. Ces tests ne nécessitent pas la mise en place d'un laboratoire virtuel ou d'un groupe d'application.
Lors d'un job SureBackup (test de restauration complet), Veeam Backup & Replication effectue une vérification "en direct" : il analyse les données sauvegardées à la recherche de malwares, démarre la machine à partir de la sauvegarde dans l'environnement isolé, exécute des tests pour la machine, éteint la machine et crée un rapport sur les résultats de la vérification de la restauration.
Historiquement, Surebackup testait les sauvegardes de VMs VMware et Hyper-V, les jobs SureBackup peuvent désormais traiter les sauvegardes basées sur des agents des machines Windows et Linux basés dans le cloud, physiques et virtuelles.
Pour vérifier les VMs avec un job SureBackup, Veeam Backup & Replication peut exécuter des tests prédéfinis pour les VMs ou utiliser des scripts de vérification personnalisés.
Veeam Backup & Replication peut vérifier les VMs avec les tests prédéfinis suivants :
Test Hearthbeat : Lorsque la VM démarre, Veeam Backup & Replication effectue un test de hearthbeat. Il attend un signal de hearthbeat de la part des VMware Tools installés dans la VM pour déterminer que le système d'exploitation de la VM est en cours d'exécution. Si le signal est émis régulièrement à des intervalles de temps spécifiques, le test est réussi.
Test Ping : Veeam Backup & Replication envoie des requêtes ping à la VM depuis le serveur de sauvegarde et vérifie si la VM peut y répondre. Si la VM répond aux requêtes ping, le test est réussi.
Test applicatif : Veeam Backup & Replication attend le démarrage des applications à l'intérieur de la VM et exécute un script sur ces applications. Veeam Backup & Replication utilise deux types de scripts prédéfinis :
Pour les serveurs DNS, les contrôleurs de domaine, les serveurs Global Catalog, les serveurs de messagerie et les serveurs Web, Veeam Backup & Replication utilise un script qui sonde un port spécifique à l'application. Par exemple, pour vérifier un contrôleur de domaine, Veeam Backup & Replication sonde le port 389 pour obtenir une réponse. Si la réponse est reçue, le test est réussi.
Pour Microsoft SQL Server, Veeam Backup & Replication utilise un script qui tente de se connecter aux instances et aux bases de données sur le Microsoft SQL Server.
Pour vérifier un serveur Microsoft SQL virtualisé, Veeam Backup & Replication peut exécuter le script Microsoft SQL Server Checker au sein du job SureBackup. Le script exécute séquentiellement les opérations suivantes :
Connexion aux instances de Microsoft SQL Server
Énumération des bases de données sur ces instances
Utilisation de l'instruction USE SQL pour se connecter aux bases de données et vérifier leur disponibilité.
En plus des tests de vérification de la restauration, Veeam Backup & Replication permet d'effectuer une validation des fichiers de sauvegarde. Pour la validation des fichiers de sauvegarde, Veeam Backup & Replication effectue une vérification CRC pour les fichiers de sauvegarde des VMs vérifiées par le job SureBackup. Il est également faisable de valider les fichiers de sauvegarde de VMs au sein d’un groupe d’application.
Pour valider le fichier de sauvegarde, Veeam Backup & Replication utilise un algorithme de checksum. Lorsque Veeam Backup & Replication crée un fichier de sauvegarde pour une VM, il calcule un checksum pour chaque bloc de données dans le fichier de sauvegarde et stocke ces données dans le fichier de sauvegarde, avec les données de la VM. Pendant le test de validation du fichier de sauvegarde, Veeam Backup & Replication décompresse le fichier de sauvegarde, recalcule les checksums pour les blocs de données dans le fichier de sauvegarde décompressé et les compare aux valeurs initiales de ces checksums. Si les résultats correspondent, le test est réussi.
Dans la plupart des cas, une VM ne fonctionne pas seule mais en coopération avec d'autres services et composants. Pour vérifier une telle VM, il est important de démarrer tous les services et composants dont cette VM dépend. C’est dans ce cas de figure que Veeam Backup & Replication utilise le groupe d'applications.
Le groupe d'applications crée une « entité logique » / un « environnement » pour la vérification de cette VM. Le groupe d'applications contient une ou plusieurs machines virtuelles dont la VM à vérifier dépend. Ces machines virtuelles exécutent des applications et des services qui doivent être lancés pour permettre à cette VM de fonctionner pleinement. Généralement, le groupe d'applications contient au moins un contrôleur de domaine, un serveur DNS et un serveur DHCP.
Un groupe d'applications permet de spécifier le rôle de chaque VM, sa priorité de démarrage ainsi que son délai de démarrage. De plus, il est possible de spécifier quels tests doivent être effectués pour vérifier les VMs au sein du groupe d'applications.
Lorsqu'un job SureBackup est lancé, Veeam Backup & Replication démarre d'abord, dans le Virtual Lab, les VMs du groupe d'application dans l'ordre requis et effectue les tests nécessaires. Veeam Backup & Replication s’occupe de créer l'environnement nécessaire pour la VM à vérifier. Ce n'est qu'après avoir démarré et testé toutes les machines virtuelles du groupe d'applications que Veeam Backup & Replication démarre la VM à vérifier dans le lab virtuel.
Par exemple, pour vérifier la restauration d’un serveur Microsoft Exchange, il est important de tester son interopérabilité avec le contrôleur de domaine et le serveur DNS. Il faudra donc ajouter au groupe d'applications un contrôleur de domaine et un serveur DNS virtualisés. Lorsque Veeam Backup & Replication exécute le job SureBackup, il démarre et vérifie d'abord le contrôleur de domaine et le serveur DNS dans le lab virtuel pour rendre ensuite possible la vérification du serveur Microsoft Exchange.
Le Virtual Lab est un environnement virtuel isolé dans lequel Veeam Backup & Replication vérifie les VMs. Dans le Virtual Lab, Veeam Backup & Replication démarre les VMs du groupe d'applications ainsi que la VM à vérifier. Le Virtual Lab est utilisé non seulement pour la procédure de vérification SureBackup, mais aussi pour le test U-AIR, l’On-Demand Sandbox et le Staged Restore.
Le Virtual Lab lui-même ne nécessite pas de provisionner des ressources supplémentaires. Cependant, les machines virtuelles fonctionnant dans le Virtual Lab consomment des ressources CPU et mémoire de l'hôte ESXi où le Virtual Lab est déployé. Tous les changements de VMs qui ont lieu pendant la vérification de la restauration sont écrits dans des fichiers redo log.
Le Virtual Lab est entièrement isolé de l'environnement de production. La configuration du réseau du Virtual Lab reflète la configuration du réseau de production. Par exemple, si les VMs vérifiées et les VMs du groupe d'applications sont situées dans deux réseaux logiques dans l'environnement de production, le Virtual Lab aura également deux réseaux. Les réseaux du Virtual Lab seront mappés aux réseaux de production correspondants.
Les VMs dans les réseaux isolés ont les mêmes adresses IP que dans le réseau de production. Cela permet aux VMs du Virtual Lab de fonctionner comme si elles fonctionnaient dans l'environnement de production.
Pour permettre la communication entre l'environnement de production et les réseaux isolés dans le Virtual Lab, Veeam Backup & Replication utilise une Proxy Appliance.
La Proxy Appliance est une VM auxiliaire basée sur Linux qui est déployée sur l'hôte ESXi où le Virtual Lab est créé. La VM Proxy Appliance reçoit une adresse IP du réseau de production et est placée dans le dossier et le pool de ressources dédiés au Virtual Lab sur l'hôte ESXi.
La Proxy Appliance est connectée au réseau de production et au réseau isolé, elle a donc à la fois une visibilité sur l'environnement de production et le Virtual Lab. La Proxy Appliance agit comme une passerelle entre les deux réseaux - elle achemine les demandes de l'environnement de production vers les machines virtuelles du Virtual Lab.
La Proxy Appliance est un composant optionnel dans le processus de vérification de restauration. Techniquement, un Virtual Lab peut être créé sans Proxy Appliance. Cependant, dans ce cas, il ne sera pas possible d'effectuer une vérification automatique de la récupération des VMs. Les VMs seront démarrées à partir de sauvegardes dans le Virtual Lab ; et seront accessibles via leur console VM pour effectuer les tests nécessaires manuellement.
Pour laisser entrer le trafic dans le Virtual Lab, Veeam Backup & Replication utilise de l’adressage IP Masquering.
Chaque machine virtuelle dans le Virtual Lab a une adresse IP de mascarade, ainsi que l'adresse IP du réseau de production. L'adresse IP de mascarade ressemble à l'adresse IP du réseau de production. Par exemple, si l'adresse IP d'une VM est 172.16.1.13, l'adresse IP de mascarade peut être 172.18.1.13.
L'adresse IP de mascarade est un "point d'entrée" vers la VM dans le Virtual Lab depuis l'environnement de production. Lorsque l’on veut accéder à une VM spécifique dans le Virtual Lab, Veeam Backup & Replication l'adresse par son adresse IP de mascarade.
Il est parfois nécessaire de fournir à de nombreux clients l'accès à une VM restaurée, ce qui est particulièrement le cas pour la restauration granulaire à l’item d'application dirigée par l'utilisateur (user-directed application). Par exemple, fournir aux utilisateurs un accès au serveur Microsoft Exchange démarré dans le Virtual Lab via un accès Web (comme Outlook Web Access). Techniquement, il est possible de mettre à jour la table de routage sur chaque machine cliente ; cependant, cela demanderait beaucoup d'efforts administratifs.
Pour de telles situations, Veeam Backup & Replication permet d'accéder à une VM dans le Virtual Lab directement depuis l'environnement de production. Pour cela, il faut réserver une adresse IP statique dans le pool d'adresses IP de production et mapper cette adresse IP à l'adresse IP d'une VM dans le Virtual Lab.
L'adresse IP statique est attribuée à la carte réseau de la Proxy Appliance connectée au réseau de production. Le trafic IP dirigé vers l'adresse IP statique spécifiée est acheminé par la Proxy Appliance vers la VM du réseau isolé.
Par exemple, pour une VM avec l'adresse IP 192.168.1.20 dans le réseau isolé, il est possible de réserver l'adresse IP 192.168.1.99 (une adresse IP libre du réseau de production). En conséquence, sera utilisé l'adresse IP 192.168.1.99 pour accéder à la VM dans le lab virtuel depuis le côté production.
Un alias peut également être enregistré dans le serveur DNS de production pour l'adresse IP réservée. Par exemple, configurer backup.exchange.local comme alias de l'adresse IP 192.168.1.99, les utilisateurs pourront accéder à Microsoft Exchange Server par cet alias.
Pour vérifier un réplica, Veeam Backup & Replication effectue les mêmes tests que pour la vérification de la sauvegarde de VM (Surebackup), à l'exception du test de validation de la sauvegarde. Veeam Backup & Replication peut exécuter des tests prédéfinis pour les VMs ou utiliser des tests personnalisés. Les tests prédéfinis sont les suivants :
Test Hearthbeat
Test Ping
Test Applicatif
Il est possible d’ajouter à un même groupe d'applications à la fois des machines virtuelles provenant de sauvegardes et des machines virtuelles provenant de réplicas.
Toutes les VM du groupe d'applications doivent avoir au moins un point de restauration valide créé au moment où le job SureBackup démarre. (cf. Groupes d’applications développé dans le chapitre SureBackup)