Nous profitons de la récente disponibilité de NexentaStor 3.1.4 (toujours pas disponible en version CE) pour vous faire partager le modus operandi de l’installation de SABnzbd sur NexentaStor 3.1 qui nous a été transmis par Brenn Oosterbaan et que nous n’avons que très peu modifié pour le rendre utilisable par (à peu près) tous. Thanks Breen!

Breen nous a aussi fourni le fichier xml permettant de configurer SABnzbd en tant que service mais nous avons été contraint de forcer l’adresse et le port d’écoute dans la commande de démarrage (0.0.0.0:8080) ce qui rend toute modification (lié au host:port d’écoute) dans l’interface de configuration de SABnzbd non persistante. Si vous avez l’intention de changer le port, faites le dans le fichier sabnzbd.xml fourni et relancer la commande d’import.

Une fois l’installation terminée et le service démarré, vous devriez observer quelque chose de similaire à cela dans le log du service :

_yenc module... found!
par2 binary... found (/usr/local/bin/par2)
unrar binary... found (/usr/bin/unrar)
unzip binary... found (/usr/bin/unzip)
nice binary... found (/usr/bin/nice)
ionice binary... NOT found!
pyOpenSSL... found (True)
Starting web-interface on 0.0.0.0:8080
ENGINE Bus STARTING
ENGINE Started monitor thread '_TimeoutMonitor'.
ENGINE Serving on 0.0.0.0:8080
ENGINE Bus STARTED
Starting SABnzbd.py-0.7.11
Dirscanner starting up
URLGrabber starting up

Comme toujours il faudra passer par le fameux mode “expert” pour accéder au shell. Et gare à la Hadopi !

install.txt

Tous ceux qui ont eu à affronter un manque d’espace critique sur un zpool se sont au moins une fois posé la question suivante : Pourquoi ZFS n’est il pas capable de supprimer automatiquement les plus anciens snapshot pour libérer de l’espace en cas de besoin ?

La réponse est évidement parce que ce n’est pas (encore) intégré à ZFS mais peut être que le futur principe de “feature flags” (qui remplacera la fameuse “version” de ZFS) facilitera la naissance de cette fonctionnalité tant espérée. En attendant, il y a toujours la bonne vielle crontab toujours très pratique et si on pimente à la sauce oneliner, ça donne quelque chose d’un peu trash mais fonctionnel :

for zpool in `zpool list -H -o name,capacity | sed "s/%//g" | awk '{ if ( $2 > 80 ) { print $1; } }'`; do zfs list -H -o name -t snapshot | grep -E "^$zpool" | head -n $[$(zfs list -H -o name -t snapshot | grep -E "^$zpool"|wc -l) / 5 + 1]  | xargs -n1 zfs destroy -R ; done

Ce oneliner détruira récursivement 25% des plus vieux snapshots (+1 pour éviter les cas ou 25% feraient moins d’1 snapshot) d’un zpool si le remplissage dépasse les 80%.

Voici une démo de ce script sur un zpool soumis à remplissage perpétuel (dd en boucle + snapshot toutes les minutes) :

Observations du graphique : jusqu’à 10h nous avons programmé le script toutes les minutes, puis toutes les 5min jusqu’à 15h30, puis nous l’avons désactivé et le zpool sature presque immédiatement après.

Voici l’extrait de la crontab de notre nexenta de test :

* * * * * for zpool in `zpool list -H -o name,capacity | sed "s/\%//g" | awk '{ if ( \$2 > 80 ) { print \$1; } }'`; do zfs list -H -o name -t snapshot | grep -E "^$zpool" | head -n $[$(zfs list -H -o name -t snapshot | grep -E "^$zpool"|wc -l) / 5 + 1]  | xargs -n1 zfs destroy -R ; done

A la lecture du release notes, on remarque tout de suite qu’il est globalement question de nouveaux drivers dont vmxnet3 (très attendu) et pvscsi, derniers maillons manquant à Nexenta pour être une pure appliance de stockage VMware.

Pour ceux qui passeraient par le processus d’upgrade, il est fort probable que vous ayez à lancer les commandes suivantes (suivit d’un reboot) pour installer les 2 packages contenant les pilotes :

apt-get install nexenta-vmxnet3
apt-get install nexenta-pvscsi

Pendant notre échange avec les gens de chez Nexenta (qui nous ont confirmé la sortie de Nexenta 4.0 basé sur illumos d’ici la fin de l’année), nous avons pu apercevoir la nouvelle version de NexentaVSA for View (une appliance dédié au VDI)  mais surtout l’intégration d’une version++ d’Aura, l’interface de monitoring révolutionnaire développé à l’arrache pendant le VMworld 2011 :

D’après le sales manager présent lors de notre discussion, l’intégration d’Aura serait prévue dans la version 4.0 de Nexenta et le support de VAAI NFS sera pour la suivante mais surtout inclut dans la version Community Edition comme pour le VAAI en mode block depuis la 3.1.3. D’ici la, nous aurons tout de même droit à la version 3.1.4

Durant l’OpenStorage Summit EMEA 2012, Andy Bennett raconte comment VMware a sollicité Nexenta pour pondre une solution de stockage comparable aux Vblocks d’EMC et FlexPods de NetApp mais à un coût radicalement inférieur (l’objectif était le meilleur prix au Téraoctet) et comment cette solution s’est retrouvée à héberger une partie des “Hands on lab” des 2 VMworld 2011 avec des disques NL-SAS 7500 rpm en face d’EMC et NetApp avec des baies remplies de SAS 15K et de SSD.

Résultat, plus de de 10 milliards d’IOPS NFS sur les 2 VMworld à 2ms en moyenne (~1,2 VM déployées par seconde !) avec une solution à 330K$ face à NetApp et EMC avec des solution à 2M$…

Il raconte également comment un module de RAM défectueux a fait planter un des nœuds de leur cluster sans conséquence sur les labs mais aussi comment, en quelques heures seulement, l’un des membres de l’équipe a designé et codé la fameuse interface Aura (basé sur DTrace) contenant les metrics les plus importants pour les équipes d’experts VMware qui monitoraient l’infrastructure sur place. Du caviar pour les plus curieux d’entre nous…

Keep pool space under 80% utilization to maintain pool performance.

[...]

If the primary workload is immutable files (write once, never remove), then you can keep a pool in the 95-96% utilization range.

Le 95-96% correspond au changement de block allocation contrôlé par le paramètre metaslab_df_alloc_threshold :

The minimum free space, in percent, which must be available in a space map to continue allocations in a first-fit fashion. Once the space_map’s free space drops below this level we dynamically switch to using best-fit allocations.

Vous l’aurez compris, le monitoring des zpool est primordiale. Sous Nexenta ce n’est pas chose facile car seuls les point de montage sont visibles par défaut en snmp, mais nous avons une solution simple n’impliquant que peux de modifications.

• ajouter les lignes suivantes dans votre conf snmp :

extend .1.3.6.1.4.1.2021.87 zpool_name /bin/bash -c “zpool list -H -o name”
extend .1.3.6.1.4.1.2021.87 zpool_capacity /bin/bash -c “zpool list -H -o capacity”

• copier le fichier zpool_capacity.xml dans le répertoire /resource/snmp_queries de votre cacti
• importer les templates cacti_data_query_zfs_-_zpool_capacity.xml et cacti_graph_template_zfs_-_zpool_capacity.xml dans l’interface web cacti
• choisissez les zpool à monitorer sur votre/vos nexenta (y compris le syspool)

• en option, créez un Threshold Template pour recevoir une alerte en cas de dépassement de 80%

zpool capacity

Voila maintenant 1 mois que nous participons à des tests avec les gens de chez nexenta concernant un problème lié à la routine Atomic Test & Set (ATS) de VAAI. Le symptôme est assez radical : lors de certaines opérations courantes (svmotion par ex.), la LUN reste lockée donc inaccessible jusqu’à ce qu’elle soit “re-maskée” ou que le serveur nexenta soit rebooté.

Jusqu’à ce que le bug soit corrigé, l’option la plus rapide est de désactiver l’ATS. L’idéal c’est un petit one-liner powershell qui le fait sur tous vos ESX :

Get-VMHost|Set-VMHostAdvancedConfiguration -name VMFS3.HardwareAcceleratedLocking -Value 0

Attention aux LUN en VMFS5 natives qui ont été créées avec VAAI actif car elles sont tagguées “ATS-only”, ce qui veux dire qu’il n’est pas possible de les réserver en SCSI-2 classique. Pour désactiver ce mode, il faut utiliser la commande vmkfstools avec le paramètre ”configATSOnly“.

Nous tenons à préciser que ce problème n’est pas lié à celui du UNMAP.

Tout à commencé à partir d’un post qui traite de la customization du snmpd.conf en vue de faire un joli graph de l’ARC de ZFS avec cacti et d’un autre au sujet de smartmontools sous Solaris. En mixant les 2, nous sommes arrivé à un moyen simple de remonter la moyenne des températures des disques d’un Nexenta dans cacti via SNMP.

• Installez smartmontools en mode expert : “apt-get install smartmontools”
• Ajoutez la ligne suivante dans la configuration snmp de Nexenta (“setup network service snmp-agent edit-settings snmpd.conf” dans la NMC) :

extend .1.3.6.1.4.1.2021.87 smart_temp /bin/bash -c "find /dev/rdsk/ -name \"*p0\" -exec /usr/sbin/smartctl -a -d scsi {} \\;|grep -E \"Temperature:.*C\"| awk 'BEGIN { n=0; sum=0; } { n++; sum += \$(NF-1); } END { printf (\"%.2f\",sum / n); }'"

• Importez notre template dans cacti et créez le graphique sur votre Nexenta

]]> http://www.hypervisor.fr/?feed=rss2&p=3335 2 http://www.hypervisor.fr/?p=3239 http://www.hypervisor.fr/?p=3239#comments Sat, 20 Aug 2011 00:30:47 +0000 NiTRo http://www.hypervisor.fr/?p=3239 Après un faux départ, NexentaStor 3.1 est enfin (re)disponible ! En plus des quelques nouvelles features et corrections de bug, la grosse bonne nouvelle c’est le support de VAAI pour ESXi 5+ (contrairement à ce qui avait été annoncé) y compris pour la version Community Edition. Ce qui en fait la toute première et seule solution VAAI gratuite, pour le mode block uniquement. Voici la liste des routines VAAI supportées :

• SCSI Write Same (zeroing)
• SCSI ATS (lock only the specific region on the LUN)
• SCSI Block Copy (instruct the array to perform a block copy)
• SCSI Unmap (return freed blocks in a zvol)

Je vous laisse imaginer l’intérêt d’une solution gratuite (jusqu’à 18To raw max pour la CE) supportant VAAI et reposant sur ZFS (ARC, L2ARC, in-line deduplication, in-line compression, snapshots and copy-on-write clones, RAID-Z, native NFSv4 ACLs, continuous integrity checking and automatic repair, …) face à toutes les appliances payantes du marché.

Et juste pour le plaisir des yeux :

Et justement, en ce moment nous sommes en pleine découverte de la configuration FC sur Nexenta (plus particulièrement sur la configuration du mode target) qui est un Unified Storage System  tout à fait capable de présenter la même LUN (un zvol pour être précis) via FC et iSCSI. Voici donc une petite démo en 4 étapes :

1. Coupure de vmhba1 (prefered path) > Bascule sur vmhba2
2. Coupure de vmhba2 > Bascule sur vmhba32 (iSCSI)
3. Restauration de vmhba2 > Aucun effet
4. Restauration de vmhba1 > bascule sur vmhba1

Tout d’abord, vous remarquerez que ça bombarde à 10k+ IOPS (alors que le serveur Nexenta est une petite VM), remettez vous, c’est l’effet ZFS

Plus sérieusement, on remarque que le failover se fait dans le sens croissant des vmhba, ce qui règle le problème du choix d’iSCSI qu’en dernier recours étant donné que l’initiateur est toujours à 32 ou plus. De plus le failover se fait dans un délais raisonnable de 10 secondes (contre 30sec pour MPIO de Windows 2008 R2 et donc d’Hyper-V) mais cette solution pose un réel problème si le chemin préféré venait a être le seul à ne PAS être restauré car le chemin iSCSI est considéré comme les autres donc restera “valable” (cf FC to iSCSI failover : MRU ranking). Mais nous pensons que cela reste néanmoins une solution à connaitre et peut être à envisager pour les plus parano du HA.

Et le plus drôle dans l’histoire c’est que vous n’avez rien à configurer !

PS: Ça doit être possible à faire avec les autres hyperviseurs évidement…

One major feature that distinguishes ZFS from other file systems is that ZFS is designed from the ground up with a focus on data integrity

Et parce que c’est toujours bon de terminer par une touche d’humour, un petit extrait de l’article “RAID-Z” écrit par Jeff Bonwick (le “papa” de ZFS) :

The original promise of RAID (Redundant Arrays of Inexpensive Disks) was that it would provide fast, reliable storage using cheap disks. The key point was cheap; yet somehow we ended up here.

setup network service snmp-agent edit-settings snmpd.conf

Et voila le résultat :