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

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

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…

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

Et voila le résultat :