Sujets-libres.fr

Informatique, logiciels libres, internet, humeurs et… le reste !

Anticiper les ennuis en auto-hébergement

Rédigé par -Fred- / 25 avril 2016 / 4 commentaires

Introduction

L'auto-hébergement permet de retrouver un certain contrôle sur ses données et c'est le gros intérêt de la démarche. Mais, l'auto-hébergement implique, et c'est le revers de la médaille, d'assumer seul plusieurs risques supplémentaires. Il est donc utile de se poser quelques questions à un moment.

Précisions

Précision importante, l'auto-hébergement dont je parle ici est typiquement celui mis en œuvre par un particulier dans un cadre privé par exemple. C'est la forme qui m'intéresse là.

Venons en à mon cas

Google, Yahoo!, ou n'importe quel autre fournisseur habituel de mail n'est pas responsable si mon serveur de mail n'est plus accessible ou si mes données sont perdues par exemple. Les ressources physiques sous mon contrôle sont sous ma responsabilité. Cela couvre à la fois les problèmes logiciels et les problèmes matériels qui pourraient intervenir.

Méthode d'analyse

Je ne passe pas vraiment par une méthode particulière mais par simplement un peu de bon sens. L'idée, c'est d'anticiper ce que je peux et d'avoir déjà des réponses à apporter lorsque je me trouverai réellement en situation. Avant de proposer des réponses, il faut se poser les bonnes questions et pour se poser les bonnes questions. Je vais donc procéder comme suit :

  • Identifier le système sur lequel je veux agir.
  • Estimer les impacts des défaillances sur ce système complet.
  • Indiquer ce qui est déjà prévu en cas de défaillance.
  • Identifier les "trous dans la raquette".
  • Identifier les actions à mener afin de combler ces faiblesses.

Vue assez fidèle de mon réseau :

note : pour ce schéma, j'ai utilisé dia et les icônes de Jean Cartier.

Estimation de l'impact des défaillances :

Chaque élément sur ce réseau peut tomber en panne. Que le problème soit d'origine logiciel ou matériel importe peu, la seule chose importante est que l'élément considéré peut ne plus fonctionner à un moment donné. Élément par élément, quels sont donc les impacts d'une panne sur le système entier ? C'est aussi l'occasion d'estimer le niveau de gravité des impacts causés par chaque panne. J'en profite donc pour classifier chaque impact avec un niveau allant de 1 (impact mineur) à 3 (impact majeur). J'ai estimé qu'il était possible de fonctionner avec un effet de niveau 1. Pour les effets de niveau 2, j'ai considéré qu'une gène était visible que ce soit à l'intérieur ou à l'extérieur de mon réseau et qu'il n'était de fait pas possible de fonctionner en l'état. Enfin, les effets de niveau 3 traduisent un risque irréversible de perte de donnée. Voyons voir :

Modem ADSL HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus visible de l'extérieur.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (1) Téléphonie fixe non fonctionnelle.
Parefeu HS :
  • (2) Plus de connexion à internet possible depuis mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 16 ports HS :
  • (2) Plus de connexion à internet possible pour le serveur auto-hébergé, le serveur NAS et les autres postes sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible, y compris depuis le réseau local.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
Switch 8 ports HS :
  • (2) Plus de connexion à internet possible les postes bureautique sur mon réseau.
  • (2) Serveur auto-hébergé n'est plus du tout accessible en local.
  • (2) Serveur NAS inaccessible en local.
  • (1) Téléphonie fixe non fonctionnelle.
  • (1) Impression sur l'imprimante réseau locale impossible.
Serveur public HS :
  • (2) Services auto-hébergé non fonctionnels.
  • (3) Si la situation se prolonge, risque de perte des nouveaux mails entrant.
  • (3) Selon la panne du serveur, risque possible de perte des données stockées dessus.
Serveur NAS HS :
  • (2) Serveur NAS inaccessible en local.
  • (3) Selon la panne du NAS, risque possible de perte des données stockées dessus.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Reprendre l'ensemble des points listés précédemment.

Je ne traite pas le cas d'une panne sur la box OVH car la maintenance de cet appareil n'est pas à ma charge. En cas de défaillance, le problème est à traiter par OVH.

On peut déjà voir que certains éléments sont plus critiques que d'autres mais ils ont tous ou presque la possibilité d'entrainer des pertes de données. Si je n'en avais pas conscience avant, au moins là, c'est clairement établi. A y regarder de plus près, je vois deux types de problèmes sur les données. La non récupération de données externe et la perte de données préalablement récupérées. Dans le premier cas, c'est la conséquence d'une défaillance réseau et dans le second cas, il s'agit de la défaillance du système de stockage.

Ce qui est prévu en cas de défaillance :

S'il me faut maintenant assumer la défaillance d'un équipement, comment est-ce que j'ai prévu de réagir ? Voici ma réponse élément par élément :

Modem ADSL :
  • J'ai un modem équivalent de rechange.
Parefeu :
  • Aie ! Pas de machine de remplacement.
  • Configuration sauvegardée.
Switch 16 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Switch 8 ports :
  • Aie ! Pas de switch manageable de remplacement.
  • Configuration sauvegardée.
Serveur public :
  • Aie ! Pas de machine identique de remplacement.
  • Sauvegarde journalière des données importantes sur DD USB externe
  • Sauvegarde journalière des données importantes sur le NAS
Serveur NAS :
  • Aie ! Pas de machine identique de remplacement.
  • NAS deux baies en RAID 1. Réduction du risque de perte des données.
  • Les données les plus importantes stockées sur le NAS sont aussi sauvegardées sur une machine bureautique.
Ensemble des équipements réseau, serveur, bureautique HS :
  • Aie ! Pas de solution de remplacent de matériel.
  • Perte de toutes mes données.

Comme on peut le voir, je ne dispose pratiquement pas d'équipements "sur étagère" afin d'intervenir immédiatement en cas de défaillance, ceci afin de repartir sur une configuration strictement identique. Ça ne veut pas dire que je suis bloqué mais ça demande quelques aménagements.

Mon réseau actuel n'est que l'évolution d'un réseau à plat. Si mon parefeu ou l'un de mes switchs manageable venait à dysfonctionner, j'ai la possibilité de basculer rapidement vers une architecture réseau plus simple. Je dispose d'un switch de secours et mon modem ADSL étant un modem/routeur en mode bridge, je n'ai qu'à en modifier la configuration si besoin pour le repasser en routeur. Reste ensuite simplement à revoir l'adressage IP. Ces manipulations ne sont pas longues à réaliser et me permettent de passer facilement dans un mode dégradé.

Les données importantes sur le NAS ou le serveur public sont aussi stockées ailleurs.

Globalement donc, je sais quoi faire si un élément de mon réseau tombe et mes données sont protégées contre une défaillance isolée de matériel.

Les trous dans la raquette :

Bien que le NAS soit en mesure d'assurer mon hébergement web et mail, tout comme il est possible au serveur public d'assurer le stockage des données actuellement sur le NAS, je préfère si possible éviter de rassembler l'ensemble de ces usages sur une même machine. Une défaillance du NAS n'est pas dramatique mais une défaillance du serveur public l'est plus dans la mesure où je ne peux m'en passer et parce que je ne dispose pas de solution à déployer rapidement s'il venait à me lâcher.

Le problème le plus important pourrait se produire en cas d'incendie ou de vol de matériel. Je ne dispose pas aujourd'hui de moyen de repartir même en mode fortement dégradé après ce type de problème. Pire, je perds toutes mes données puisque je ne dispose que de sauvegardes locales.

Actions à mener afin de combler ces faiblesses :

Je vais prévoir assez rapidement une machine supplémentaire que je serai en mesure de configurer rapidement en cas de défaillance de mon serveur public ou de mon parefeu.

Je vais prévoir de placer une sauvegarde récente de mes données sur un autre lieu, de sorte que les pertes de données soient minimes même en cas de problème grave.

Dernier point, je vais aussi réfléchir à une solution permettant de poursuivre mon activité ailleurs en cas de problème grave chez moi.

Conclusion

Tant que ça marche, on ne se pose pas de question mais dès que ça ne marche plus, il peut être trop tard pour chercher des réponses. Cette petite analyse me montre quels sont les points à travailler sur mon installation. Chaque installation auto-hébergée est différente mais je pense qu'elles méritent toutes une petite réflexion de ce type.

4 commentaires

#1 mardi 26 avril 2016 @ 07:32 philb a dit :

merci d'avoir partager ce post. De mon coté, j’héberge à titre pro des solutions pour mes clients chez moi et au bureau (avec 2 accès en fibre situés à 10km de distance), Sur chaque site j'ai une debian avec des containers LXC pour mes applications (firewall, serveur web, base de données,....) en loadbalancing via HAproxy. Le site principale est un vrai serveur de production le site de secours est un portable gonflé en RAM). Un rsync des data est réalisé entre les machines (toutes les nuits mais pourrait être tous les 15 minutes). Un DNS est hebergé dans le cloud sur une VPS de base qui consiste à rediriger le flux vers les IP des serveurs disponibles avec une priorité sur le serveur de prod (et à éviter des attaques DDOS,...). En cas de problème de ce DNS j'utilise freeDNS pour basculer (pire des cas: jusqu'à 24h sans accès de l'exterieur). La solution n'est pas parfaite mais est simple et j'ai en plus sur mon portable de dev une machine virtuelle identique à celle de prod pour remonter en urgence les clones (lxc-clones) des machines LXC (dernier back-up de la nuit des sites disponibles, ça prend le temps de downloader des .tar), puis rediriger le flux du VPS vers l'IP où je me trouve (y compris si c'est une IP dynamique). J'ai une alerte sur mon smartphone si mes serveurs ne sont pas disponibles plus de 5 minutes. Heureusement que tout fonctionne plutôt bien, mais le pire m'est déjà arrivé: plus de DNS car l'hébergeur de ma VPS s'est fait poutrer et tous ses serveurs sont restés inaccessibles pendant plus d'une semaine ... (c'est ce qui m'a fait découvrir freeDNS, que je continue à utiliser en dev). Si je veux diminuer le risque, il me suffit de rajouter des machines (voir même un raspberryPi pour mes sites web en node.js, pour des bd ce n'est pas suffisant) dans d'autres lieux. Le jour ou mes bases de données dbMaria seront critiques (à la minute), je prendrais le temps de les configurer en cluster avec des noeuds distants, mais pas critique pour la moment )

#2 jeudi 28 avril 2016 @ 16:06 -Fred- a dit :

C'est certain qu'à titre pro, la partie qui concerne le comportement face aux pannes doit être prévue et testée, surtout si, comme dans ton cas, les services commencent à être variés et un poil critiques. Dans le cas que j'ai présenté, c'est heureusement pour moi bien plus simple comme environnement (d'autant que je n'ai pas de comptes à rendre à des clients derrière). Ça ne m’empêche pas de réfléchir à l'utilisation notamment de machines virtuelles en local. C'est probablement ce que je ferai à moyen terme (à court terme, j'ai à mettre en place les quelques trucs dont j'ai parlé à la fin de mon billet). Merci de ton retour d'expérience.

#3 mardi 26 avril 2016 @ 10:45 racam a dit :

Concernant le problème du :
"Je vais prévoir de placer une sauvegarde récente de mes données sur un autre lieu, de sorte que les pertes de données soient minimes même en cas de problème grave."

J'ai personnellement opté pour un backup chiffré de mes données sur une plateforme cloud. Normalement ton FAI t'en propose un : OVH dispose de Hubic par exemple. En conséquence, un simple .tar.gz chiffré de mes données se trouve sur le cloud.

#4 jeudi 28 avril 2016 @ 16:12 -Fred- a dit :

Tout ça demande réflexion puisque l'une des motivation de mon auto-hébergement est justement de ne pas dépendre d'une solution dans le cloud. Ceci dit, c'est une solution technique pertinente et il est vrai que si l'on chiffre convenablement ses données avant de les y envoyer, normalement c'est bon. Je pense que je testerai, rien que pour me forger un vrai avis.

Écrire un commentaire

Quelle est la quatrième lettre du mot gjdwgn ? :