la Tourmentine

Aujourd'hui je vais vous parler des serveurs qui font tourner - entre autre - ce site: "big" est un kimsufi 4G, "small" un kimsufi 2G (ancienne gamme, la nouvelle ne supportant plus l'IP Failover). big est bien sûr le serveur principal: l'IPv4 virtuelle lui est assignée, et il réponds à environ la moitié des requètes IPv6 par le mécanisme du round-robin DNS.

Sur chacun de ces serveurs un ensemble de jails accueillent les principaux services: web, mail, ftp, dns, db. Les données utilisateur, elles, sont soit gardées en local et répliquées sur l'autre serveur (dns & db), soit partagées via NFS (les autres).

Coté sécurité, les deux machines communiquent au travers d'un tunnel IPSec, et le SSH n'est bien sûr accessible que depuis des IP triées sur le volet, et uniquement via clé publique. Pour les accès nomades, un VPN est accessible.

En cas de défaillance du serveur principal, heartbeat ce charge de contacter l'API OVH afin de basculer l'IP virtuelle sur le second serveur, de démonter ses montages NFS et de remonter le dernier snapshot ZFS du premier serveur. Il ne reste plus qu'à remettre le serveur primaire en état: par sécurité, rien n'est lancé au démarrage, et les partitions contenant les précieuses données sont cryptées: une clé, non présente sur le serveur bien sûr, est nécessaire pour les débloquer et les monter...clé qui peut être envoyé via un script depuis ma machine perso

À suivre, peut être, d'autres billets qui entreront dans le détail de chaque service !

Suite au passage à nginx, je n'avais pas testé le support ActiveSync de mon webmail...

Résultat: un smartphone dont la batterie ne durait pas une journée, car il essayait continuellement de se synchroniser

Donc pour les gens qui utilisent "der schön webmail" Tine 2.0, qu'ils évitent de se perdre dans les rewrites moisies qui traînent sur le web, elles ne sont plus valables et celle qui marche est:

rewrite ^/Microsoft-Server-ActiveSync /index.php?frontend=activesync;

Et dire qu'il suffisait de lire le source (Tinebase/Core.php) où cette règle est indiquée en commentaire. Et bien sûr dans la doc, aussi. Comme quoi Google n'est pas toujours notre ami.

...ou un truc comme ça.

Donc, 10 ans après tout le monde - comme d'habitude - je me met au dernier truc qui poutre, j'ai nommé nginx, qui vient remplacer l'ami lighttpd.

Je garde Varnish pour la forme, même s'il n'est plus vraiment utile avec ce serveur.

J'ai été contraint d'adapter la conf de ce site et de quelques autres, donc si certains liens ne marchent pas, n'hésitez pas à m'en faire part !

La Tourmentine et tous ses services ont été inaccessibles pendant un peu plus de 24 heures. La faute à l'un des anciens serveurs que j'ai redémarré en vue du grand nettoyage avant de le rendre à m'sieur OVH.

Or, au démarrage mes serveurs lancent Heartbeat qui s'occupe, entre autre, de basculer l'IP failover qui sert de porte d'entrée principale à toute mon infrastructure. Le serveur en question étant l'ancien "master", il a tout naturellement squatté la VIP, en privant le serveur actif...et tout le monde arrivait sur un serveur mort

Et moi, étant connecté en ipv6, je n'ai rien vu pendant tout ce temps, car je ne passait pas par la VIP...ipv4.

Et je n'ai pas vu non plus le mail de chez OVH m'informant de la "connexion au manager" faite par le serveur. C'est un peu la lose.

Cela a eu au moins le mérite de mettre le doigt sur une méchante faille de mon système de supervision, que je vais m'empresser de corriger !

L'aventure HASTienne c'est terminé hier soir avec un gros crash du pool primaire, avec un fort peu poli "I/O Error" en tentant de ré-importer le pool HAST sur le second serveur. Malaise.

Vu les problèmes de lock que j'avais depuis la mise en prod, j'ai tenté le tout pour le tout: abandonnant HAST, j'ai créé de nouveaux datasets ZFS pour stocker mes précieuses données (que j'ai récupéré des backups de la veille, du coup), et j'ai ensuite synchronisé les deux serveurs à grands coups de snapshots ZFS différentiels.

Voici le principe: on commence par faire un snapshot (full) du dataset à répliquer, et on l'envoi sur l'autre serveur. On renomme ensuite, sur chaque serveur, le snapshot afin qu'il serve de référence pour les prochaines synchros:

serveur1# zfs snapshot servers/pool1/home@newsync
serveur1# zfs send servers/pool1/home@newsync | ssh -q serveur2 "zfs receive -vFd servers"
serveur1# zfs rename servers/pool1/home@newsync servers/pool1/home@prevsync
serveur2# zfs rename servers/pool1/home@newsync servers/pool1/home@prevsync


Un script à mettre en crontab sur le serveur maitre va se charger ensuite d'envoyer les snapshots différentiels; l'ancien snapshot est supprimé après transfert, et le nouveau est renommé afin qu'il serve de base aux suivants.

#!/bin/sh

bro="serveur2"
pools="pool1 pool2"


echo "`date`: ZFSync starting."
for pool in $pools
do
        dataset="servers/${pool}/home"
        echo "making new snapshot for ${pool}"
        zfs snapshot ${dataset}@newsync
        echo "sending snapshot"
        zfs send -i prevsync ${dataset}@newsync | ssh -q ${bro} "zfs receive -vFd servers"
        if [ $? -eq 1 ]
        then
                echo "error, exiting"
                exit $?
        fi
        echo "cleaning"
        zfs destroy ${dataset}@prevsync
        zfs rename ${dataset}@newsync ${dataset}@prevsync
        ssh -q ${bro} "zfs destroy ${dataset}@prevsync && zfs rename ${dataset}@newsync ${dataset}@prevsync"
done

echo

La gestion d'erreur, embryonnaire, demande encore a être améliorée

Avec cette méthode, la synchro de trois datasets prends moins de trois minutes, pour environ 10 Go de données.

À noter qu'en temps normal le second serveur n'utilise pas les datasets en question: ils ne sont pas montés, à la place on utilise un montage NFS hébergé sur le premier serveur (zfs set sharenfs=on $dataset) pour que les éventuelles données écrites par le second serveur ne soient pas écrasées. En cas de bascule, les montages NFS sont démontés et les montages ZFS sont remontés à leur place, via heartbeat.