Dans Nous vous avons présenté les nouvelles fonctionnalités de la mise à jour 4 sortie en janvier pour Veeam Backup & Replication 9.5 (VBR), où nous avons intentionnellement omis de mentionner les sauvegardes sur bande magnétique. La discussion sur ce domaine mérite un article à part entière, car il y avait vraiment beaucoup de nouvelles fonctionnalités.
– Les gars du QA, allez-vous écrire un article ?
– Pourquoi pas !
Les lecteurs de bande au XXIe siècle
Le stockage de données sur bandes magnétiques (cassettes, «bandes», comme nous les appelons au R&D) ne se limite pas à l'ordinateur ZX-Spectrum, qui pouvait charger un jeu en mémoire vive de 48 ko à partir en quelques minutes. En un quart de siècle, la vitesse et la capacité des cassettes ont augmenté de 6 à 7 ordres de grandeur. Cela n'est pas tout à fait une comparaison correcte, et selon norme ne suit pas. Cela dit, les technologies modernes permettent d'enregistrer jusqu'à 12 téraoctets de données sur une bande d'un kilomètre (jusqu'à 30 téraoctets en mode compression), ce qui fait que le lecteur à 160 dollars surpasse ses concurrents en matière de coût de stockage à long terme de grandes quantités de données, même en tenant compte des investissements dans l'équipement d'enregistrement/de lecture. Les données sur ces cassettes sont fiables pendant 15 à 30 ans.
Abordons le sujet sous un autre angle. Dernièrement, ont atteint un nouveau niveau. Ils peuvent patienter dans l'infrastructure d'une grande entreprise pendant des semaines et des mois, et avec l'apparition d'une nouvelle vulnérabilité zéro jour – détruire (non sans l'aide d'un humain, car de l'argent est en jeu) non seulement toutes les données, mais aussi toutes les sauvegardes accessibles. Voici , lorsque l'entreprise a dû payer les rançons. Les soi-disant air gap, c'est-à-dire les sauvegardes physiquement isolées de l'infrastructure, sont devenues, en pratique, le seul salut fiable contre de telles situations. La bande magnétique est ici l'une des solutions intemporelles.
Mais une spécification et les nouvelles technologies des principaux fabricants (IBM, HPE, Oracle, Dell) ne suffisent pas pour assurer la protection des données, un bon logiciel est nécessaire. Chez Veeam, nous avons toute une équipe qui s'occupe des sauvegardes sur bande, environ 10 personnes analysent, planifient, recherchent, développent et testent quotidiennement. Les résultats de ce travail, vous avez pu les voir dans les articles précédents (, ). Quelles ont été les réalisations de l'année dernière ?
Glossaire
Il y a un choix à faire entre des libertés concernant la langue maternelle et des bureaucratismes qui compliquent la lisibilité. Je préfère la première option, je m'excuse donc d'avance si certains jargon ci-dessous sont désagréables à lire. Je vais brièvement rappeler ici ce que signifie chaque terme.
Les experts en VBR peuvent passer cette partieJob – job – tâche de sauvegarde. En fait, tout VBR est basé sur des jobs. En plus de la sauvegarde et de la réplication, cela peut aussi être une copie sur bande magnétique (backup to tape job, tape job). Je précise que la restauration à partir d'une sauvegarde (restore) est également un job, mais dans cet article, ce terme désignera spécifiquement la sauvegarde.
Storage – storage – terme historiquement établi. Ce sont des fichiers dans dépôts (repository – référentiel), contenant des sauvegardes – complètes et incrémentales. Un même storage peut contenir une ou plusieurs machines virtuelles.
Chaîne – chain – une séquence de storages liés les uns aux autres. Pour restaurer des données à partir d'un n-ième storage incrémental, tous les précédents de (n-1) à 1 et le storage complet référencé par le premier incrémental sont nécessaires.
Source, Cible – source, target. Source – l'entité d'origine traitée par le job. Dans le cas des sauvegardes/répliques, cela correspond généralement à une machine virtuelle dans l'hyperviseur. Pour un tape job, la source est le job de sauvegarde lui-même (ou les fichiers dans le cas d'un file to tape job). La cible pour un job de sauvegarde est le référentiel où les sauvegardes sont stockées. Pour un tape job, il s'agit d'un pool de médias.
Pool de médias – – un pool de supports d'information, dans notre cas – des cassettes. Un conteneur logique créé par l'utilisateur et contenant des cassettes d'une ou plusieurs bibliothèques. Ainsi, un tape job a toujours un media pool comme cible, c'est-à-dire que les données ne sont pas écrites sur une cassette spécifique ou sur n'importe quelle cassette de la bibliothèque, mais sur un ensemble déterminé. Un media pool a une configuration de temps de conservation des données, après quoi la cassette peut être réécrite. L'utilisateur peut créer des pools normaux (standard) et . Chacun de ces types peut désormais être soit WORM soit non-WORM, comme expliqué ci-dessous.
Ensemble de médias – – ensemble de cassettes dans le pool de médias, sur lesquelles les sauvegardes/fichiers sont écrits en continu. Pour les pools GFS, les ensembles de médias sont également liés à l'intervalle (par exemple, annuel – yearly), les cassettes ne tournent qu'à l'intérieur de leur intervalle.
– éléments de la bibliothèque de bandes. Le lecteur lit et rembobine la cassette, le changeur – c'est un robot qui déplace les cassettes entre les emplacements de stockage, les emplacements de déchargement et le lecteur. Il existe aussi des lecteurs autonomes (standalone – autonome), ici, un humain joue le rôle de changeur. Un pilote correctement installé du fabricant est obligatoire pour le lecteur sur la machine Windows à laquelle la bibliothèque est raccordée ; avec un changeur, nous pouvons travailler même sans pilotes, via SCSI natif.
Locataire vers bande. Le fournisseur est protégé – les clients sont protégés
A tout seigneur tout honneur. La fonctionnalité la plus vaste de notre mise à jour, destinée aux , utilisant VBR dans leur infrastructure. Le développement a été entamé il y a deux ans. Très vite, nous avons réalisé que nous ne serions pas en mesure de mener à bien une tâche aussi sérieuse pour la prochaine version, nous avons pris une petite pause, et finalement, nous avons lancé la fonctionnalité dans la mise à jour 9.5 Update 4.
En résumé, les fournisseurs ont désormais la possibilité de copier les sauvegardes de leurs clients sur des cassettes grâce à un travail de bande dans le pool GFS. Cela offre aux fournisseurs – qui sont des clients très importants pour nous et pour notre département commercial – deux opportunités :
- protéger leurs clients (locataires, locataire – locataire) contre la perte de données due à une suppression accidentelle ou à des problèmes d'infrastructure (« inondation dans le serveur ») ;
- fournir aux locataires un service supplémentaire de restauration de données à partir d'une ancienne sauvegarde qui a été supprimée depuis longtemps du référentiel cloud selon la politique de conservation des données, mais qui est toujours restée sur les cassettes.
D'un point de vue marketing, cette fonctionnalité est très « alléchante », et pour nous, elle est tout aussi complexe à mettre en œuvre.
Développement
Le principal problème soulevé – le chiffrement des données. La plupart des sauvegardes cloud sont chiffrées, les statistiques parlent d'un tiers des sauvegardes au total. Pour nous, ce chiffre était une surprise, nous pensions que presque tout était crypté, mais non – de nombreux clients semblent avoir une confiance absolue en leurs fournisseurs.
La prémisse est simple : le fournisseur ne doit pas être capable de déchiffrer les données de ses locataires. Dans le cadre de cette nouvelle fonctionnalité, il est nécessaire que le fournisseur ouvre des stockages avec des sauvegardes. Cela est nécessaire pour transférer des blocs de données, par exemple, pour créer . L'essentiel est de le faire indépendamment du locataire, lorsque les clés nécessaires ne sont pas transmises au fournisseur lors de l'exécution de la tâche.
La solution à ce problème, qui est également utilisée dans une autre fonctionnalité clé de l'extension sortante – – consiste à ajouter une clé de cryptage supplémentaire. La clé d'archive (Archive key) est stockée dans la base de données du fournisseur de manière cryptée. Grâce à un schéma astucieux, le fournisseur peut utiliser cette clé pour ouvrir le stockage, déplacer et recryptage des blocs de données entre les stockages (chacun ayant sa propre clé), mais il ne peut pas déchiffrer les données elles-mêmes.
Un schéma astucieux (version fonctionnelle)
Je voudrais ajouter que tous les ingénieurs de R&D adorent le cryptage dans notre produit, bien que personne ne sache exactement comment cela fonctionne dans tous ses détails. (Il y avait aussi une blague « et pourquoi cela fonctionne-t-il ? », mais les éditeurs ne l'ont pas retenue.)
Test
Des centaines de bogues ont été signalés sur la fonctionnalité. Les domaines les plus complexes sont le cryptage, l'interface utilisateur et les problèmes lors de la restauration.
D'un point de vue test, la difficulté venait de la grande variabilité, de la « combinatoire » des types et des types de tâches locataires et de dépôts – je veux dire à la fois comme source et comme cible lors de la restauration des sauvegardes dans l'infrastructure. Tout cela s'imbrique dans la logique de (y compris le nouveau - le parallélisme et les ensembles médiatiques quotidiens, à ce sujet ci-dessous), et également sur la spécificité cloud peu familière pour les types. N'oubliez pas d'assaisonner généreusement avec du cryptage. Si l'on continue la métaphore, nous avons bien dévoré ce plat – mais l'avons aussi goûté sous tous ses angles.
Un extrait du plan de test
En conséquence
Une description détaillée peut être trouvée dans le (pour l'instant en anglais) : , . Je vais m'attarder sur les points principaux.
Sauvegarde
Le fournisseur ajoute des locataires à la tâche de type avec le pool GFS en tant que cible. En cas de licence cloud, la deuxième étape de l’assistant propose l’option LocatairesIl est possible d'ajouter tous les locataires d'un coup ou un par un, et vous pouvez également sélectionner une seule quota (mais pas une sous-quota) d'un locataire spécifique. Il n'est pas permis de mélanger les sauvegardes de locataires et les sauvegardes locales ordinaires dans un même travail.
Les autres paramètres sont presque entièrement identiques à ceux d'un travail ordinaire dans un pool GFS.
La restauration des données peut se faire à la fois du côté du fournisseur et du côté du locataire lui-même.
Restauration du côté du fournisseur
Cela se fait via un nouvel assistant. Il est alors possible de descendre jusqu'à un travail spécifique, où l'ensemble de la chaîne présente dans le référentiel à un jour donné est restauré.
Il existe trois options de restauration :
- Dans l'emplacement d'origine. Dans ce cas, la sauvegarde originale, si elle existe, est supprimée ; les tâches du locataire sont automatiquement reconfigurées sur la chaîne restaurée. Cela signifie qu'une telle restauration sera en général imperceptible pour le client, qui sera uniquement déconnecté du référentiel cloud pendant un court laps de temps.
- Dans une nouvelle quota/référentiel. Le fournisseur peut, par exemple, créer un compte temporaire séparé à cet effet, qui sera ensuite supprimé. La sauvegarde apparaît dans l'infrastructure du locataire après synchronisation avec la base du fournisseur.
- Directement sur un disque du serveur Linux ou Windows enregistré dans l'infrastructure du fournisseur. Cette chaîne peut ensuite être copiée sur une clé USB et envoyée au locataire.
Restauration du côté du locataire
Cette option requiert que le client possède sa propre infrastructure de bandes et un grand volume de données à restaurer. Le fournisseur peut physiquement envoyer la cassette contenant les sauvegardes au client via un service de livraison, qui catalogue ensuite celle-ci sur son propre équipement, décrypte les cassettes et les sauvegardes, et travaille avec les copies de sécurité comme s'il les avait lui-même enregistrées sur bande. Voici un petit truc pour éviter de télécharger des téraoctets via WAN.
Améliorations majeures du pool GFS
-les pools média ont été ajoutés dans VBR il y a deux ans, dans la version 9.5. Dans la mise à jour récemment sortie, tant en raison de l'apparition de la fonctionnalité 'Tenant to tape' que par demande des utilisateurs, nous avons considérablement renforcé cette fonctionnalité.
Ensembles médiatiques quotidiens
Un nouveau quotidien (daily) ensemble de médias. Désormais, dans le pool GFS, il est possible de stocker des sauvegardes pour chaque jour, et pas seulement des complètes, mais aussi des incrémentales. Ces dernières prennent beaucoup moins de place, et cela a été fait dans un souci d'économie de bande. Il est supposé que ces cassettes sont constamment tournées dans la bibliothèque, sans être envoyées à un stockage distant. Pour restaurer à partir d'un point incrémental, il faudra des cassettes d'un des ensembles de médias supérieurs (hebdomadaire, mensuel, trimestriel ou annuel). Il n'est pas possible d'inclure un ensemble de médias quotidien sans inclure le hebdomadaire, afin que, dans la plupart des cas, la restauration à partir d'une sauvegarde incrémentale requière justement des cassettes hebdomadaires. Elles se trouvent soit toujours dans la bibliothèque, soit stockées dans un entrepôt pas trop éloigné.
La logique de fonctionnement des tâches de sauvegarde dans le pool multimédia GFS , les rédacteurs techniques ne diront pas le contraire. En résumé, sans entrer dans les détails, seules les sauvegardes complètes (y compris les sauvegardes complètes virtuelles) sont copiées dans les ensembles de médias hebdomadaires et supérieurs, une pour chaque date, tandis que dans le quotidien – toutes les sauvegardes présentes dans le référentiel pour le jour en cours, car la tâche de sauvegarde peut être lancée plus d'une fois par jour.
Parallélisme, heure de lancement et attente dans les pools GFS
Il est désormais possible d'écrire en parallèle plusieurs chaînes ou tâches sur plusieurs lecteurs de la bibliothèque, même dans les pools multimédia GFS (auparavant, cela n'était possible que dans les pools normaux). Cela s'active à l'étape Options du pool multimédia.
Important à préciser: un même fichier est toujours écrit dans un seul flux, il est donc recommandé, en cas de plusieurs grandes machines virtuelles, d'activer , afin que la sauvegarde se compose de plusieurs chaînes.
De plus, il est désormais possible de choisir l'heure de lancement de la tâche GFS elle-même. De nombreux utilisateurs n'aimaient pas le lancement à minuit et l'attente pendant presque toute une journée, jusqu'à ce que la tâche source se termine. Désormais, cette heure peut être, par exemple, fixée en fin de soirée, lorsque des données sont déjà prêtes à être copiées sur bande. De plus, à la demande des utilisateurs, nous avons déplacé dans les paramètres avancés une option qui auparavant ne pouvait être activée qu'à l'aide d'une clé de registre. Il suffit de sélectionner Traiter le point de restauration le plus récent au lieu d'attendre – et sur la cassette, ce qui se trouve dans le référentiel au moment du lancement de la tâche de sauvegarde (point de la veille, par exemple) est copié, sans attente du tout.
Amélioration du travail avec plusieurs bibliothèques
Nous allons aborder la situation dans laquelle plus d'une bibliothèque est ajoutée à un pool média. Nous avons déjà supporté cela, mais de temps en temps, des clients se plaignaient d'un comportement pas tout à fait prévisible.
Il y avait
Par exemple, un travail de tape a commencé, utilisant deux lecteurs dans la première bibliothèque, mais les réglages de parallélisme lui permettent d'utiliser jusqu'à 4 lecteurs. Ce travail doit-il basculer vers la deuxième bibliothèque du pool média et l'utiliser également, ou cela constituerait-il un surcoût en ressources ?
Un autre cas. L'option de bascule en cas de « pas de cassettes disponibles » est sélectionnée, dans la première bibliothèque, il n'y a qu'une seule cassette, mais toutes les données peuvent potentiellement y être placées. Cependant, les réglages permettent d'écrire en parallèle sur deux cassettes. Faut-il activer la deuxième bibliothèque dans ce cas ?
Nous avons décidé de mettre de l'ordre dans ce domaine, permettant de régler le comportement de manière explicite.
Il est devenu
ont maintenant des rôles – actif et passif. Et le pool média lui-même a deux modes : tolérant aux pannes, ou failover (redondance) et écriture parallèle (parallélisme). Désormais, en fonction des exigences, il est possible de configurer le pool média différemment.
- Si vous avez plusieurs bibliothèques de même niveau et devez paralléliser l'écriture en elles, activez le mode d'écriture parallèle, pour cela, il faut assigner des rôles actifs à toutes les bibliothèques. Dans ce cas, de nouvelles cassettes et lecteurs seront mobilisés dès qu'il y aura un besoin, peu importe dans quelle bibliothèque ils se trouvent. Cependant, il y a toujours une priorité – nous allons d'abord essayer de trouver des ressources dans la bibliothèque située en haut de la liste.
- Si vous avez une bibliothèque principale et un ancien lecteur ou un lecteur autonome en réserve, activez le mode de bascule, en plaçant la bibliothèque principale en haut de la liste et en choisissant un rôle passif pour les appareils de réserve. La bascule vers un tel appareil n'aura lieu que lorsque cela sera vraiment nécessaire, pour que le travail puisse, au moins, fonctionner. Une telle situation sera considérée comme anormale, et une notification sera envoyée par e-mail.
Il existe une situation plus complexe que nous ne prenons pas encore en charge : plusieurs bibliothèques actives en présence de passives. Les retours d'expérience montreront s'il y a un besoin pour de telles configurations et s'il faut améliorer cette fonctionnalité à l'avenir. C'est la pratique standard.
Support WORM
WORM – Write Once Read Many – des cassettes qui ne peuvent pas être effacées ou réécrites , on ne peut qu'ajouter des données. Leur utilisation obligatoire est régie par les règles de certaines organisations, par exemple celles opérant dans le secteur médical. Le principal problème avec ces cassettes était auparavant que le VBR lors de ou enregistrait un en-tête qui ne pouvait plus être effacé par la suite, et les travaux sur bande échouaient avec une erreur lors d'une telle tentative.
Dans la mise à jour 9.5 Update 4, un support complet pour ces cassettes a été mis en œuvre. Des pools de médias WORM ont été ajoutés, normaux et GFS, où seules des cassettes de ce type peuvent être placées.
Les nouvelles cassettes ont une icône bleue, "gelée". Du point de vue de l'utilisateur, le travail avec des cassettes WORM ne diffère pas de celui avec des cassettes normales.
La "wormabilité" des cassettes est initialement déterminée par le suffixe , si le code-barres est normal ou illisible, l'information est fournie par le pilote lors de la première insertion de la cassette. Il n'est pas possible de placer des cassettes WORM dans un pool de médias normal et d'écrire dessus. Fait amusant : des utilisateurs ont déjà collé des codes-barres WORM sur des cassettes ordinaires et ont été surpris par les changements dans leur infrastructure après la mise à jour.
La puce de la cassette
En parallèle du déploiement des cassettes non réinscriptibles, nous avons commencé à travailler avec la . Les attributs standard de la puce n'étaient pas utilisés auparavant, nous écrivons et lisons désormais dans certains d'entre eux, mais nous ne les considérons pas comme la principale source de données. L'orientation principale reste l'en-tête de la cassette. Cette décision s'est révélée correcte : un mois après la sortie, nous voyons comment le "zoo" matériel des utilisateurs présente des surprises en ce qui concerne le travail avec la puce.
Sauvegarde des volumes NDMP sur bande
En conclusion, parlons de la fonctionnalité la plus demandée selon le nombre de retours de ce Update. La sauvegarde des volumes NDMP sur cassettes est maintenant disponible. Il est nécessaire d'ajouter un serveur NDMP à l'infrastructure VBR. , après quoi il sera possible de sélectionner des volumes sur cet hôte dans le travail de bande de fichiers. Ils sont enregistrés sur des bandes sous forme de fichiers avec un attribut spécial pour les distinguer des fichiers ordinaires lors de la catalogage.
La première version présente certaines limitations : les extensions (extensions) ne sont pas prises en charge, et il est possible de faire des sauvegardes et des restaurations uniquement de volumes complets, mais pas de fichiers individuels. La sauvegarde fonctionne via (dans le cas de NetApp - ), il existe certaines particularités : le nombre maximum de points d'incrémentation est de 9, après quoi une sauvegarde complète est forcée.
En conclusion
Ce ne sont là que les innovations majeures en matière de sauvegarde sur bandes magnétiques dans VBR 9.5 Update 4. D'autres changements sont les suivants :
- la possibilité de définir l'ordre des travaux source et des fichiers dans les travaux de bande ;
- un rôle d'opérateur de bande a été ajouté (l'utilisateur peut tout faire sauf restaurer depuis la bande - cela relève de l'opérateur de restauration) ;
- des masques d'inclusion/exclusion complets ont été ajoutés dans les travaux de bande de fichiers (excepté pour NDMP) ;
- la restauration dans les travaux de bande de fichiers a été améliorée (le dossier est restauré avec les fichiers qui étaient là au moment de la sauvegarde, et non avec tous ceux qui y ont été à un moment donné dans l'historique de ses sauvegardes - une fonctionnalité très demandée, d'ailleurs) ;
- la vitesse de restauration d'un très grand nombre de fichiers à partir de bandes a été augmentée ;
- l'algorithme de sélection de la prochaine bande d'enregistrement a été affiné, en tenant compte, toutes choses égales par ailleurs, du volume de données enregistrées/lues pendant toute sa durée de vie, en sélectionnant la plus récente ;
- la stabilité du produit a été améliorée.
Liens utiles
Pour la diversité, je vais donner quelques liens vers des ressources en langue russe :
- Et nous sommes de retour à l'emplacement précédent des vidéos de présentation « Comment ça fonctionne » (malheureusement, pour l'instant en anglais) - vous pouvez les regarder . Les bandes sont abordées dans les diapositives 95 à 102.
Source : habr.com
