Tribulations d'un ingénieur système

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

jeudi 7 août 2014

BTRFS, Snapshot journalier et comparaison de date

Je dispose d'un filesystem BTRFS pour lequel je souhaite créer un snapshot journalier.
L'heure du snapshot n'ayant pas besoin d'être fixe, le script pourra être placé dans /etc/cron.daily/snapshot

#!/bin/bash

BTRFS=/mnt
SNAPSHOT=/snapshot
LOG=/var/log/snapshot.log

PATH=/usr/sbin:/usr/bin:/sbin:/bin
echo "---------------------------------------------------------------" >> $LOG
echo $(date) >> $LOG
for l in $(ls $SNAPSHOT); do
    t=$(echo $l $(date --date '-2 months' +%F) | awk '$2<$1{print -1;next}{print ($2>$1)}')
    if [[ $t == 1 ]]; then
        btrfs subvolume delete $SNAPSHOT/$l >> $LOG
    fi
done
btrfs subvolume snapshot -r $BTRFS $SNAPSHOT/$(date +%F) >> $LOG

Je commence par déclarer les variables qui devront être adaptées en fonction du serveur.

Ensuite, je spécifie le PATH, un grand classique du Cron.

Je liste chaque snapshot et pour chacun des noms de dossier, je le compare à la date du jour - 2 mois. Le résultat du awk retourne 1 si le snapshot a plus de 2 mois, 0 s'il a exactement 2 mois et -1 s'il a moins de 2 mois.

Si le résultat est 1, alors je supprime le snapshot.

Et dans tous les cas, à la fin je crée un nouveau snapshot en lecture seule (option -r).

J'aurais pu me contenter de supprimer le snapshot égal à la date du jour - 2 mois. Mais, si pour une raison quelconque, le serveur est arrêté pour maintenance pendant plus d'une journée, un snapshot ne sera pas supprimé. Et si je l'oublie, le différentiel des données entre le snapshot et les données vivantes va augmenter, occupant de plus en plus d'espace disque. Donc un petit effort aujourd'hui, m'évitera peut-être la saturation d'espace disque ou l'extension prématurée du filesystem BTRFS.

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

vendredi 25 juillet 2014

Remplacer les caractères Windows dans les noms de fichiers déposés sur un serveur Linux

Parce que des fois, les utilisateurs ne respectent pas la consigne et ne modifient pas le jeu de caractères par défaut dans Filezilla. Je me retrouve alors avec des noms de fichiers illisibles sur mon Linux. Tous les caractères incorrectes sont alors remplacés par des points d’interrogation.

Exemple : R?union pr?paratoire aux ouvrages de ma?onneries

Je lance donc la commande ci-dessous dans un Cron (quoi qu'un déclenchement sur un inotify serait plus judicieux)

find /data ! -name "*" -exec convmv -f iso-8859-15 -t utf8 -r --nosmart --notest '{}' \;

Cette ligne de commande est d'autant plus imbitable que vous ne trouverez pas les astuces utilisées ici dans le Man de find.

La commande find avec comme paramètre name "*" renvoie tous les fichiers. Vraiment tous ? Non ! Les fichiers dont le codage n'est pas correct ne sont pas renvoyés par find. le point d'exclamation inverse le filtre d'un paramètre dans find. Ainsi, la commande find . ! -name "*" retourne tous les fichiers dont le codage est incorrect.

La commande convmv permet de renommer un fichier d'un encodage vers un autre. A ne pas confondre avec iconv qui modifie le contenu du fichier.

jeudi 24 juillet 2014

Modification de la taille ou ajout d'un disque dur à chaud !

La méthode pour que Linux détecte à chaud un nouveau disque dur sans reboot.

echo "- - -" > /sys/class/scsi_host/host0/scan


Chaque périphérique SATA, SCSI ou FiberChannel correspond à un numéro de Host différent : host0, host1, host2....
Si on ne connaît pas la correspondance entre le numéro du host et le disque associé, on peut lancer un scan sur tous les host scsi sans risque en abusant de cette chère commande find :

Pour Redhat 5:
find /sys/class/scsi_host -type f -name scan -exec sh -c 'echo "- - -" > {}' \;

Pour Redhat 6:
find /sys/devices -type f -name scan -exec sh -c 'echo "- - -" > {}' \;


L'emplacement des entrées host0, host1... a été déplacé quelque part entre le Kernel 2.6.18 et 2.6.35 vers /sys/devices. Il reste des liens symboliques de /sys/class vers /sys/devices mais find ne les suit pas sauf si l'on ajoute l'option -follow, ce que je ne conseille pas en raison des liens récursifs.

La méthode pour que Linux détecte à chaud la nouvelle taille d'un disque dur sans reboot.

echo "1" > /sys/class/scsi_device/0\:0\:0\:0/device/rescan

Le code 0\:0\:0\:0 dépend du numéro de la carte SCSI (ou SATA) et doit être modifié en fonction du besoin. Si on ne connaît pas la correspondance entre le numéro du device et le disque, on peut lancer un scan sur tous les device sans risque avec la commande
find /sys/class/scsi_device -name '*:*' -exec sh -c 'echo "1" > {}/device/rescan' \;


Si vous êtes sur un serveur physique avec le multipath, il faut relancer le service multipath après la détection des disques.
service multipath-tools restart

page 3 de 3 -