Pourquoi une bande virtuelle ?

message « Load next volume » ou de manquer de volumes disponibles ? Ces risques disparaissent avec la bande virtuelle. Jusqu’à 256 volumes virtuels (1 Tb maxi pour chaque volume) peuvent être ajoutés en une seule fois dans un catalogue d’images. L’unité de bande virtuelle peut passer directement au catalogue LOADED suivant dès que l’actuel est rempli. Mieux encore, si la sauvegarde utilise tous ses volumes et déborde sur un volume supplémentaire, un nouveau volume virtuel sera aussitôt créé. Mais, pas d’inquiétude : IBM vous protège contre le remplissage complet du système, en empêchant toute écriture sur un volume virtuel dès lors que l’espace libre du système tombe à 5 % ou à 5 Go, la plus petite de ces deux valeurs étant retenue. Le taux de réussite des sauvegardes/restaurations tient beaucoup au fait que la bande virtuelle risque beaucoup moins de rencontrer des erreurs de support, d’unité de bande, de câble ou d’IOP. On leur doit la plupart des problèmes physiques lors des sauvegardes ou restaurations. Lors d’un échange entre disques, les erreurs physiques sont extrêmement réduites.

Temps de sauvegarde/reprise réduit. L’un des principaux arguments en faveur de la bande virtuelle est la réduction du temps de sauvegarde et de reprise. C’est aussi l’un des aspects les plus mal compris. En effet, comme avec toute opération, de nombreux facteurs affectent la performance. L’utilisation de la bande virtuelle peut s’avérer beaucoup plus rapide mais, dans certains cas, elle peut être plus lente que la bande physique. La bande virtuelle peut être aussi rapide que les lecteurs les plus rapides et, parfois, encore plus rapide.De nombreux éléments augmentent la performance de la bande virtuelle : beaucoup de mémoire, davantage de CPU, la création de catalogues d’images dans un ASP (auxiliary storage pool) utilisateur ou un ASP indépendant, la réduction des autres activités du système, l’ajout de bras aux unités de disque, et des IOP plus rapides. L’une des précautions les plus importantes à prendre est de s’assurer que le paramètre ALCSTG sur la commande ADDIMGCLGE est réglé sur *IMGSIZ plutôt que *MIN. Avec *IMGSIZ, vous allouerez vraiment tout le stockage quand un volume sera créé ; tandis qu’avec *MIN, vous allouerez dynamiquement le stockage à la volée, ce qui réduira la performance de jusqu’à 30 %. Voici un conseil : créez le volume avec *IMGSIZ, mais après la sauvegarde, réglez Change Image Catalog Entry (CHGIMGCLGE) sur ALCSTG(*MIN) afin que la taille allouée « rétrécisse » jusqu’à la taille utilisée. Si la performance n’est pas une priorité, vous pouvez utiliser la valeur par défaut *MIN.

Temps d’immobilisation de sauvegarde/reprise réduit. Dès lors que la bande virtuelle est plus rapide que les unités de bandes physiques, on réduit évidemment le temps d’immobilisation qu’entraîne une sauvegarde. S’il faut restaurer un objet critique, la bande virtuelle est presque toujours plus rapide. Tout simplement parce qu’un volume virtuel est déjà sur le système et peut sauter immédiatement à la séquence correcte pour démarrer immédiatement la restauration. En revanche, une bande physique passe par la séquence suivante : trouver et monter manuellement la bande dans le lecteur, lancer la recherche sur la bande et obtenir la bonne séquence, puis enfin démarrer la restauration.

Polyvalence. Depuis que la fonction bande virtuelle a été intégrée au système d’exploitation, aucun produit supplémentaire n’est nécessaire : la bande virtuelle est compatible avec tout autre système V5R4. D’ailleurs, les volumes virtuels peuvent être rendus compatibles avec toute unité de bande supportée. Qui plus est, les volumes virtuels sont compatibles entre eux et avec tout catalogue d’images. Il s’en suit que, même si vos unités de bandes physiques ne sont pas compatibles entre deux systèmes, vous pouvez facilement envoyer vos sauvegardes de données à restaurer sur le système cible. Comment ? Sachez que l’envoi de votre bande virtuelle à un autre système est tout aussi simple que l’envoi d’autres objets System i. Vous devez envoyer l’objet catalogue d’images de type *IMGCLG qui se trouve dans QUSRSYS, et envoyer le répertoire de catalogues d’images avec les images du fichier stream. Si le système cible n’est pas déjà doté d’une unité de bande virtuelle, vous pouvez en créer une ou utiliser SAVCFG puis restaurer la description d’unité de bande virtuelle. Plusieurs méthodes permettent de transporter des données d’un système à un autre : FTP, save et restore, OptiConnect, ObjectConnect, iSeries Navigator et autres. Pour déplacer des catalogues d’images d’un système à un autre, voir le lien « Transporting virtual images to another system » de l’Information Center ou le document IBM iSeries Software Knowledgebase 30852541.