SheevaPlug
Tuesday, 20 October 2015
|
Écrit par
Grégory Soutadé

On ne le répétera jamais assez : avoir un serveur chez soi, c'est cool. On est réellement maître de ses données, de ce qu'on publie, de ce qu'on héberge, etc. Mais, parce qu'il y a toujours un mais, cela ne va pas sans contraintes. La première étant le débit montant. Avec une offre fibre, ce n'en est plus un (l'ADSL suffit si les fichiers ne sont pas trop gros). La seconde est l'administration. C'est une réalité, même s'il y a beaucoup de choses pour nous faciliter la vie (des paquets tout faits dans votre distribution préférée, voire une distribution dédiée). La dernière étant la disponibilité/réplication.

Disponibilité et réplication sont des notions inter dépendantes : pour avoir la première, il faut qu'en cas de panne, un autre serveur puisse prendre le relais. Donc, il y a nécessité de faire de la réplication (distante de préférence) et d'avoir un mécanisme qui permet de basculer automatiquement de l'un à l'autre. C'est le point que nous allons aborder aujourd'hui.

Pour faire de la réplication, il n'y a pas de miracles : il faut deux serveurs physiques avec (au moins) deux disques durs indépendants. Pour ma part, j'ai, d'un côté mon nouveau joujou "Déméter" (Cubox i2ex) en serveur principal (maître), et de l'autre, mon vieux Sheevaplug ("Cybelle"). Il faut ajouter à cela, un parent, un ami ou un collègue qui accepte d'héberger l'esclave.

Si la procédure est valable (et même cruciale pour un serveur), s'en est de même pour nos données personnelles en tant que particulier. Les inondations qui ont touchés la Côte d'Azur n'en sont que le triste exemple. J'habite au troisième étage ? Les canalisations du quatrième peuvent exploser, un incendie peut se déclarer, je peux être victime d'un vol. Donc dupliquez, dupliquez, dupliquez !

OpenVPN

La première étape est de configurer un tunnel OpenVPN entre les deux machines. Outre l'aspect sécurité d'un tunnel chiffré, OpenVPN est surtout très utile pour communiquer via une adresse (privée virtuelle) unique. On s'abstrait ainsi des problèmes de changement d'adresse IP, de résolution de nom.

Dans notre cas, on reporte la responsabilité de la création du tunnel sur l'esclave qui doit connaître l'IP publique du serveur maître.

Il faut ensuite mettre en place une configuration quasi similaire sur le maître et l'esclave, ce qui nécessite des petits réglages pas toujours évidents (surtout la gestion des différences).

Réplication

En ce qui concerne la réplication à proprement parler, il faudra appliquer différentes méthodes selon le service cible.

Pour un serveur web, des fichiers, des mails, on utilisera rsync.

rsync -auz root@cybelle:/var/mail /var

Pour une base de données, on s'appuiera sur le modèle maître-esclave de MySQL (dans mon cas)/PostgreSql/MariaDB...

Astuce : j'utilise une authentification SSH par clé pour l'utilisateur root sur l'esclave, valable uniquement à travers le tunnel OpenVPN.

On peut ainsi configurer un cron afin que tout soit automatique :

#!/bin/bash

HOST=soutade.fr

function cybelle_not_here()
{
    echo "Cybelle not here" | mail -s "Error" root@$HOST
    exit 0
}

# OpenVPN tunnel conectivity check
ping -c 1 cybelle >/dev/null || cybelle_not_here

# Get emails from Cybelle
rsync -auz root@cybelle:/var/mail /var
# Delete retrieved emails on Cybelle
ssh root@cybelle 'find /var/mail -name "*cybelle*" -delete'

# Push local data
rsync -auz /var/www root@cybelle:/var
rsync -auz /var/projects root@cybelle:/var
rsync -auz /home/soutade/www root@cybelle:/home/soutade

Cybelle est référencée dans /etc/hosts via son adresse privée OpenVPN.

Attention toutefois : même avec une sauvegarde distante, il est NÉCESSAIRE d'en faire une locale. Encore mieux, si elle est réalisée sur un disque chiffré. On notera que lors de la réplication (quotidienne), je lance une commande directement sur l'esclave (pour effacer les mails dans le cas présent).

DNS Failover

Maintenant que nous avons deux serveurs configurés sur deux sites distants, on peut commencer les choses sérieuses : la défaillance d'un des deux (surtout le maître). La solution proposée ici est une solution de pauvre et n'est pas recommandée pour un usage professionnel.

Nous allons discuter du DNS Failover (basculement DNS). L'idée est, qu'en cas de défaillance du serveur principal (maître), l'entrée DNS (NB: qui gère la correspondance nom de domaine/IP) soit mise à jour vers le serveur de secours (esclave). Cette solution (de pauvre) a deux inconvénients majeurs qui sont :

  • La mise à jour des serveurs DNS primaires est de l'ordre d'une demi-heure
  • Les entrées DNS peuvent être encore dans le cache du client (donc non rafraîchies)

Dans l'idéal, il aurait fallu avoir de l'IP failover, c'est-à-dire qu'un serveur frontal se charge de rediriger le trafic vers la bonne destination (celle qui est encore en vie). Mais cela nécessite des infrastructures beaucoup trop onéreuses pour les petits particuliers que nous sommes.

Pour la mise en pratique, j'ai modifié le script de mise à jour de DNS de Gandi afin qu'il retourne 34 quand une entrée vient d'être modifiée (détection d'un changement d'IP). Il affiche désormais sur la sortie standard l'ancienne et la nouvelle IP.

Sur l'esclave, un script est exécuté toutes les dix minutes. Il est chargé de vérifier que le maître est toujours vivant. Si ce n'est pas le cas, il change l'entrée DNS vers son IP actuelle (il réalise le basculement) :

#!/bin/bash

HOST=soutade.fr
MASTER_ADDRESS="10.8.0.1"

ping -c 4 checkip.dyndns.com 2>/dev/null || exit 0 # No internet connexion at all                                                          
ping -c 4 $MASTER_ADDRESS 2>/dev/null && exit 0 # Master is up, ouf !                                                                      
python /home/soutade/gandi.py || exit 0
echo `date` | mail -s "Fallback server (cybelle) activated" root@$HOST

Sur le maître, un autre script est exécuté toutes les dix minutes également :

#!/bin/bash

HOST=soutade.fr

vals=`python /home/soutade/gandi.py`
if [ $? -eq 34 ] ; then
    old_ip=`echo $vals | cut -d' ' -f9`
    new_ip=`echo $vals | cut -d' ' -f5`
    ssh -oStrictHostKeyChecking=no root@${old_ip} "sed -i -e 's/^remote .*$/remote ${new_ip}/g' /etc/openvpn/cybelle.conf ; service openvp\
n restart"
    echo `date` | mail -s "Master server (demeter) activated" root@$HOST
fi

Si le changement d'IP est effectif (changement d'IP au niveau FAI ou redémarrage du serveur), on va modifier la configuration OpenVPN de l'esclave avec notre nouvelle IP et relancer le service.

Un petit dessin pour bien visualiser les différentes situations :

Infrastructure dans le cas normal

Et en cas de défaillance du maître :

Basculement en cas de défaillance du maître

Tuesday, 04 August 2015
|
Écrit par
Grégory Soutadé

Gâteau anniversaire 5 ans

Déjà 5 ans ! Les nostalgiques diraient que le temps passe vite. C'est vrai. Il s'en est passé des choses depuis août 2010. Des bonnes, des moins bonnes, la vie quoi... 5 ans, c'est le début de la maturité, du moins pour le blog et les services associés !

Pour cet anniversaire, et parce que les conditions physiques le permettent, je me suis fait un petit cadeau : Déméter.

Quésako ? C'est mon nouveau serveur qui remplace désormais Cybelle. Comme je l'avais annoncé précédemment, il s'agit d'une Cubox i2ex (sans Wifi & bluetooth). On passe ainsi d'un arm11 1,2Ghz avec 512MB de mémoire à un double cortex A9 1Ghz et 1GB de mémoire. La différence ? Trois à quatre fois plus rapide (à la louche) pour une taille diminuée par deux ! C'est surtout visible pour toute la partie dynamique (recherche/forge...). Autre avantage : la Cubox chauffe moins. La fréquence n'est pas plus haute, mais l'architecture est plus optimisée (ARMv6 vs ARMv7), la mémoire plus importante et surtout plus rapide.

SheevaPlug vs Cubox

Point important indirectement lié au nouveau serveur : le temps de présence en ligne (uptime) est maintenant de 24h dans une journée ! Au revoir Orange et son changement d'IP qui nous grève d'une heure. Et bientôt, il y aura même de l'IPv6 (si SFR se décide à mettre à jour ses box Virgin...).

Je dois dire que la migration ne s'est pas faite sans douleur. L'avantage est que j'avais des configurations déjà toutes prêtes, mais, ne pas suivre la procédure d'installation depuis le début amène d'autres problèmes (oubli de modules, de paramètres...). J'ai eu la joie de replonger dans la configuration de postfix/dovecot... aïe ! Aujourd'hui tout semble stabilisé.

Rassurez-vous, Cybelle ne part pas au rebut ! Elle servira de serveur de secours distant en cas de défaillance de Déméter. D'ailleurs, un article est prévu pour parler des mécanismes mis en place à ce sujet.

Concernant le blog en lui même : moins d'articles, mais plus intéressants. Particulièrement tout ce qui tourne autour des liseuses Bookeen avec un jailbreak à la clé (ce qui a demandé pas mal de travail).

L’outil de statistique (iwla) arrive également à maturation. Pour autant, le passage à Debian 8 a fortement perturbé le mois de mai (merci logrotate et la nouvelle conf Apache). Il a donc été moyenné par rapport aux trois mois précédents.

Revenons aux statistiques pures avec les 10 articles les plus consultés (en gras, consultation principalement pour les images. Entre parenthèses, l'année de publication) :

Il y a beaucoup de visites qui se font sur la page d'accueil (donc non comptabilisées). Mais, avec 5 articles de moins d'un an dans le top 11, c'est vraiment pas mal. Le top 2 reste inchangé. Ces 11 articles représentent 27% des pages affichées (au moins).

Des chiffres, encore (entre parenthèses, les années précédentes) :

  • 34 articles publiés (49, 50, 60, 60)
  • 21 300 visites (25 000, 12 000, 18 000, 9 000)
  • 9 Go de données envoyées (5.5, 2.7, 2.5)
  • 23 000 pages affichées

Des chiffres plutôt stables (hormis le nombre d'articles), avec une moyenne de 58 visites par jour, ce qui est plutôt bien.

Quid de la suite ? Améliorer l'existant (passage en Python 3), une petite application de notes en vue et, dans l'idéal, refaire le style CSS du blog. Vu le temps disponible, ce sont des objectifs réalisables sur ... un an, à moins qu'il ne commence enfin à pleuvoir en continu durant trois/quatre mois :)