Tribulations d'un ingénieur système

Aller au contenu | Aller au menu | Aller à la recherche

lundi 18 août 2014

Manipuler les cassettes dans une VTL

[Critique] De : BMA@srvmda01 "VTL1_LIB4_D03"  Heure : 18/08/2014 15:00:46
[90:63]      By: UMA@srvmda01@/dev/tape/by-id/d2dbs-35001438028bfcf63-1
    Impossible de charger le support échangeur (Target drive is busy.)

Ce message d'erreur DataProtector peut se produire suite à une perte de communication avec une bandothèque ou le MDA associé. L'ordre d'éjection et de déplacement n'a pas été reçu par la bandothèque. La cassette utilisée par la sauvegarde est restée positionnée dans le lecteur de bande. Pour régler ce problème, il suffit de se connecter à l'interface d'administration de la bandothèque et d'effectuer un déplacement manuel de la cassette. Mais cette fonctionnalité n'existe pas sur toutes les VTL. Il va donc falloir recourir à la ligne de commande pour déplacer notre bande.

Deux voies possibles :
  1. La commande MTX : requiert le package mtx
  2. La commande UMA (Uniquement dans DataProtector) : requiert le package lsscsi et le client media agent pour DataProtector
Prérequis : Vérifier qu'aucune sauvegarde n'est en cours sur la VTL. Si vous déplacez une cassette sur une sauvegarde en cours, vous obtiendrez bien évidement un échec de la sauvegarde.

Méthode avec la commande mtx : Depuis un serveur MDA en root, taper la commande suivante :

mtx -f /dev/tape/by-id/d2dbs-35001438028bfcf63-1 status


Cette commande retourne la liste des slots mais le premier slot commence à 1 alors que votre VTL numérote potentiellement les slots à partir de 0 dans l'interface de gestion. Les drives sont également numérotés à partir de 0.
Par exemple, pour éjecter la cassette du drive 0 vers l'emplacement 40, taper la commande suivante :

mtx -f /dev/tape/by-id/d2dbs-35001438028bfcf63-1 unload 41 0


Méthode avec la commande uma (DataProtector) : Depuis un serveur MDA en root, lister les bandothèques avec la commande suivante :

lsscsi |grep medium

Cette commande retourne la liste des bandothèques. Dans le cas d'une VTL B6200, chaque VTL est vue sur chacune des cartes FC.

lsscsi |grep medium
[3:0:10:1] mediumx HP MSL G3 Series 1120 /dev/sch0
[3:0:11:1] mediumx QUANTUM Scalar i500 585G /dev/sch1
[3:0:20:0] mediumx HP D2DBS EL01 /dev/sch2
[3:0:29:0] mediumx HP D2DBS EL01 /dev/sch3
[4:0:19:0] mediumx HP D2DBS EL01 /dev/sch4
[4:0:32:0] mediumx HP D2DBS EL01 /dev/sch5

Si vous avez plusieurs VTL, l'ordre est aléatoire… il faut identifier la VTL via les lecteurs occupés et le nombre de logements cassettes. Ces informations seront affichées avec uma comme dans l'exemple ci-dessous.

Cette information est également accessible dans le panneau de contrôle des bandothèques



(Il est possible de taper le nom cours ou l'alias si vous utiliser les alias)

Connectez-vous à la VTL avec la commande :

/opt/omni/lbin/uma -ioctl /dev/sch5
*** PROGRAM: UMA VERSION: HP Data Protector A.07.00

*** (c) Copyright Hewlett-Packard Company 2012
*** License is restricted for use with licensed
*** HP Data Protector products.

/dev/sch5> stat
Element Status (T=Transport, X=Im/Export, D=Drive, S=Storage):
0 T1 Empty "" ""

8192 X1 Empty "" ""

4096 D1 Empty "" ""
4097 D2 Full "" "" from S452
4098 D3 Full "" "" from S428
4099 D4 Full "" "" from S455
4100 D5 Full "" "" from S450
4101 D6 Empty "" ""
4102 D7 Empty "" ""
4103 D8 Empty "" ""

12288 S1 Full "" ""
12289 S2 Full "" ""
12290 S3 Full "" ""
12291 S4 Full "" ""
....


Dans cet exemple, les valeurs D1 à D8 représentent les lecteurs de bandes. Les valeurs S1 à S300 représentent les logements de cassettes.

Le programme uma existe aussi sous Windows (si le module Media Agent de Data Protector a été installé) et la syntaxe est la même. Seul le chemin d'accès a la bandothèque change de forme :
C:\Program Files\OmniBack\bin>uma.exe -ioctl scsi4:0:0:0

Pour déplacer la cassette du lecteur 2 dans son logement d'origine, utiliser la commande suivante à l'intérieur de uma :

/dev/sch13> move D2 S452

mardi 5 août 2014

Chemin persistent, Data Protector et HP B6200

Cette procédure nécessite une bonne connaissance de DataProtector, des technologies SAN et VTL (Virtual Tape Library).

Si vous administrez un serveur HP DataProtector, vous avez sûrement déjà rencontré des problèmes de décalage dans les chemins SCSI ou FiberChannel suite à l'ajout ou simplement au reboot du MediaAgent.

Ce problème est tout à fait compréhensible. L'ordre de détection des périphériques au boot par le système n'est pas maîtrisé, et la suppression d'un périphérique de sauvegarde entraînera également un décalage dans l'ordre d'affectation des noms.

Concrètement, un périphérique de sauvegarde détecté en /dev/nst4 sous Linux pourra devenir /dev/nst1 au prochain reboot pour peu que vous ayez supprimé les autres périphériques, changé l'ordre des cartes SCSI ou même mis à jour le noyau Linux. (Notez que ce problème est identique sous Windows mais sous forme encore plus torturée). Dans le meilleur des cas, DataProtector redécouvre le chemin SCSI grâce au numéro de série du lecteur de bandes. Mais dans des cas défavorables, DataProtector ne trouve plus le périphérique ou croit qu'il a été remplacé et met à jour le numéro de série avec un autre périphérique !

C'est pourquoi nous remplaçons tous les chemins d'accès au périphérique de sauvegarde dans DataProtector /dev/nstXX par le chemin /dev/tape/by-id/scsi-XXXXXXXXXXXXXXXXX-nst.

Ces liens symboliques sont construits à partir du numéro de série ou du WWN du périphérique. Donc, sauf remplacement du périphérique de sauvegarde (qui nécessitera donc réellement une prise en compte et une reconfiguration des chemins dans DataProtector), ces noms sont immuables quels que soient les ajouts, suppressions de périphériques ou mises à jour du Kernel.

De plus, dans le cas de périphériques SAN multi-chemins, ce nom sera identique pour tous les MediaAgents Linux.

Pour plus d'information : http://www.syncer.de/?p=213

Maintenant un cas plus complexe : la baie de déduplication HP B6200.

Cette baie peut être utilisée en VTL (Virtual Tape Librairie). Une librairie de sauvegarde classique dispose d'un périphérique de contrôle (/dev/sgXX) et d'un ou plusieurs lecteurs de bandes (/dev/nstXX). Traditionnellement dans un SAN, un WWN n'existe que sur une seule Fabric. Une bandothèque comportant 4 lecteurs de bandes sera donc répartie avec deux lecteurs sur la Fabric1, deux lecteurs sur la Fabric2 et le contrôle de la bandothèque sur l'une ou l'autre. En cas de panne sur une Fabric, 2 des 4 lecteurs de bandes restent accessibles. Néanmoins, si le contrôle de la bandothèque est attaché à la Fabric en panne, la bandothèque n'est plus accessible.

Sur la HP B6200, le WWN du contrôle des VTL est accessible sur les deux Fabric avec le même WWN ! Le WWN est normalement un identifiant unique et nous ne devrions pas avoir ce cas de figure. Mais vu qu'il s'agit de deux Fabric différentes, cela ne pose pas de problème technique.

Toutefois, les liens symboliques sont construits d'après le numéro de série et le WWN. Donc bien que les deux chemins apparaissent dans /dev/sgXX, un seul sera présent dans /dev/tape/by-id/.

Ces liens sont construits par les scripts udev. Nous allons donc créer notre propre script pour construire les liens symboliques vers les deux Fabric.

Ce script sera automatiquement exécuté par udev à chaque détection de périphérique, au démarrage et lors de l'ajout à chaud d'un nouveau périphérique.

/etc/udev/rules.d/50-tapedrive-persistence.rules

KERNEL=="sg*[0-9]", IMPORT{program}="scsi_id --export --whitelisted -d $tempnode"
KERNEL=="sg*[0-9]", KERNELS=="host3", ENV{ID_MODEL}=="D2DBS", SYMLINK+="tape/by-id/d2dbs-$env{ID_SERIAL}-1"
KERNEL=="sg*[0-9]", KERNELS=="host4", ENV{ID_MODEL}=="D2DBS", SYMLINK+="tape/by-id/d2dbs-$env{ID_SERIAL}-2"

Aucun des paramètres naturels utilisables dans les scripts udev ne permet de différencier les deux Fabric. Mais il est possible, lors de la découverte d'un périphérique, de lire les variables systèmes associées en vu d'une utilisation ultérieure.

Les paramètres KERNEL, KERNELS et ENV sont des filtres qui limitent l’exécution des commandes IMPORT ou SYMLYNK si tous les filtres sont vrais.

La première ligne lit et stocke les variables systèmes liées au périphérique uniquement si le périphérique est de type /dev/sgXX. Dans les deux lignes suivantes, si le périphérique est de type /dev/sgXX, raccordé à la carte FibreChannel 1 (Fabric1)(host3) ou 2 (Fabric2)(host4) et que le modèle est de type D2DBS (VTL de la HP B6200), alors le script crée un lien symbolique formé de d2dbs-XXXXXXXXXXXXXXXXX-1 ou d2dbs-XXXXXXXXXXXXXXXXX-2 suivant que le contrôle de la VTL est sur la Fabric1 ou la Fabric2.

Voilà, nous avons nos deux chemins absolus sur nos VTL HP B6200.

Pour aller plus loin : http://doc.ubuntu-fr.org/udev