Skip to content

Mon site a crashé.

January 31, 2017

Mon site WEB a explosé en vol. Ou plus exactement, le serveur a eu un violent coup de chaud. Je m’apprêtais à installer la version 3.4 de MongoDB. Par simple acquis de conscience, j’ai redémarré mon serveur avant. Ce que je ne fais habituellement jamais. Sauf que, parfois, on a des idées pas très futées.

Un serveur WEB, c’est une machine. Et un serveur WEB comme le mien, c’est environ 240000 requêtes par jour (y compris les moteurs de recherche bien évidemment). Soit 10000 requêtes par heure ou 3 requêtes par seconde. Une interruption de service, ce n’est pas anodin: cela signifie que les moteurs de recherche vont indexer incorrectement (soit parce que les pages renvoient une erreur soit parce que l’information qu’elles contiennent est incorrecte).

Donc, me voici en train de me reconnecter à mon serveur et là: impossible! Le serveur a décidé que je n’avais plus les droits! Une fois connecté à la machine via ssh, je reçois un message d’erreur et je suis déconnecté. Impossible de taper une seule commande.

J’essaie toutes les solutions possibles pour redémarrer. Rien n’y fait. La galère maximum. Il y a bien une console de secours prévue dans mon hébergement mais là encore, rien n’y fait. Je change un paramètre sur le disque de boot à tout hasard: rien. Impossible de reprendre la main.

Le serveur est dans un tel état que les pages renvoyées peuvent ressembler à n’importe quoi! Pleure ton site WEB perdu. Tout est cassé.

À bout de ressources, j’envoie un e-mail circonstancié au support. Vers 22h30. En me disant: c’est mort, je n’aurais pas de réponse avant demain. Que nenni. Chez Gandi, il y a bien un service de support 24h/24 (je suppose que c’est le cas chez tous les hébergeurs). Quand vous précisez que votre serveur est bloqué, ils sont plutôt réactifs.

Je reçois la réponse à 23h30. Mais les conseils sont assez standards. On me conseille de désactiver le montage automatique du disque et de le faire à la main. Logique. Mais impossible, je suis viré avant. Rien de bien utile. Ne vous méprenez-pas: il s’agit d’un serveur sur lequel je suis seul maître à bord. Le personnel de Gandi n’est pas autorisé à se connecter, leur seule prérogative est de vérifier son état. Il ne peuvent donc intervenir qu’en cas de panne physique; au-delà se sont de simples conseils. Il faut bien comprendre que ce n’est pas un hébergement de site mais un VPS, c’est-à-dire ce qui se rapproche le plus d’une machine physique avec des droits d’administration. Cela change tout: le responsable, c’est moi! Et depuis que je possède un VPS chez eux, c’est la première fois que ce cas de figure se présente.

Que fait-on?

L’avantage de l’offre est d’avoir des disques “séparés” de la machine. Avec des possibilités de copies. Ainsi, contrairement à un serveur où le disque serait attaché physiquement à la machine, il s’agit de disque que je peux reconnecter ailleurs.

Dans la partie “Debriefing” qui suit, je vous expliquerai plus en détail les raisons du crash. Mais j’étais persuadé que ma machine avait quelques soucis. Donc, je me dis: je vais TOUT réinstaller. Solution à faible risque (au vu de l’état).

Créer un nouveau serveur est d’une simplicité enfantine. Et, grosse surprise: je trouve dans la liste des kernels disponibles le fameux Linux Ubuntu 16.04 LTS. Youpi! Bizarrement, il m’était impossible de l’installer via l’interface de Gandi sur mon ancien disque. Du coup, let’s go. Un kernel propre!

Une fois démarré, il y a de quoi se marrer. Un Linux se configure avec quelques commandes simples. Je recrée mon utilisateur fétiche (moi-même!) et je lance les installations.

Je voulais réutiliser mon ancienne adresse IP v4 avec mon nouveau serveur. De manière à avoir une continuité de service. Malheureusement, ça ne semble pas fonctionner. J’envoie un mail au support. J’apprends plus tard que changer l’adresse IP du serveur est possible mais il y a quelques modifications mineures à apporter aux fichiers de configuration. Comme je fonce et que je réfléchis après, j’opte pour une attitude plus radicale. Je mets à jour mes enregistrements DNS avec les nouvelles adresses IP de ma machine. Cela présente l’avantage de conserver l’intégrité de mon serveur. Le temps que les DNS se propagent, le serveur sera remis sur pied. C’est sauvage mais efficace et surtout je ne risque pas de faire une fausse manipulation.

Première installation: Mongo 3.2 évidemment. Installation sans souci. Je récupère les données directement de mon ancien disque de données. C’est donc avec une base de données stoppée en vol que Mongo redémarre. Il râle sur deux paramètres de configuration mais je m’en fiche. Ça fonctionne. Que demander de mieux?

Une fois MongoDB fonctionnel, je passe à Mister Apache. Apache et PHP. Évidemment, il manque toujours un truc: soit le driver SSL pour PHP, soit cUrl, soit l’extension “mbstring” (à ce propos: il faut aller la chercher dans la partie “universe” des repository Ubuntu, celle fournie dans la partie “main” est incompatible, merci StackOverflow).

Bref, ça prend un peu de temps. Et une fois le serveur Apache lancé, il renvoie le code source des pages PHP. Débâcle complète. Youpi, tralala! Bon, c’est juste un problème de modules mal installés. Du coup, je note les modules à installer pour la prochaine fois. Et pour ceux qui ne le savent pas, il faut TOUJOURS stocker l’information sensible dans un répertoire à l’extérieur de la partie visible du site. Ce qui permet de contourner le fait que certaines pages ont été indexées avec du code source: C’est particulièrement vrai pour WordPress.

Apache et PHP sont bien relancés. Tout fonctionne à merveille: j’en profite pour ré-installer mon serveur de messagerie Postfix. Sinon, comment gérer mes adresses e-mail spéciales (différents organismes ont comme adresse une adresse dédiée: par exemple EDF m’écrit sur edf1@XXX.com), cela me permet de filtrer les tentatives d’hameçonnage.

Tout roule: le serveur est de nouveau actif.

Débriefing

La question: que s’est-il passé? Pourquoi mon serveur est tombé en rade?

Il y a plusieurs explications. Tout d’abord, j’utilise MongoDB. Sauf que dans mon cas, je suis passé de la version 2.6 avec une distribution Ubuntu à la version 3.2 avec une distribution officielle. Ces mises à jour successives (passage de 2.6 à 3.0, puis de 3.0 à 3.2) n’ont pas été sans soucis. Peut-être parce que les fichiers de configuration n’ont pas le même nom et que les version 3 utilisent YAML.

La tentative d’utiliser WiredTiger avec MongoDB 3.0 s’est avérée catastrophique. J’ai eu des “out-of-memory”. Du coup, je suis repassé sur la structure de fichier classique. J’avais prévu de faire un article sur le sujet. Car, il faut bien l’avouer, le passage de la version 2.6 à la version 3.0 s’est relativement bien passée. En revanche, la montée en charge sur la version 3.2 s’est avéré assez catastrophique. Au point de douter de l’avancée de cette nouvelle version.

Dans le désordre: une utilisation plus corrosive de la mémoire. Bizarrement, mon serveur a utilisé beaucoup plus de mémoire pour utiliser la base de données. Ainsi qu’une réponse beaucoup plus lentes sur certaines recherches. Jusqu’à présent, je pensais que ce genre de problèmes était limitées aux bases de données SQL qui optimisent différemment les requêtes à chaque nouvelles version.

Et surtout, l’installation des versions 3.0 et 3.2 m’a encouragé à modifier certains paramètres en lien direct avec le kernel. Ce qui, d’une façon générale, n’est pas très conseillé. Surtout lorsqu’on est pas expert en Linux. Autant, je sais comment gérer une machine, autant modifier le preload des secteurs du disque est une opération non pas délicate mais assez hasardeuse.

Et si ce n’était que cela…

Bref, depuis l’installation de Mongo 3.0 et 3.2, j’avais observé des comportements légèrement suspects. Mais quand on a confiance dans un système d’exploitation, on se dit que c’est juste un couac sans importance. Et puis le serveur continuait à fonctionner normalement sans donner de signes particuliers d’hérésie.

Mais, une fois que tout est planté, on s’aperçoit que ces petits détails (Apache qui écrit dans le fichier de log de la veille par exemple), sont des signes avant-coureur d’un incident grave. On est jamais trop attentifs aux détails.

Mais je vous cache autre chose: mon répertoire utilisateur résidait sur un disque distant monté au démarrage. Et franchement, ce n’était pas une très bonne idée. Du coup, j’ai changé cela: car je soupçonne que cette idiotie a lourdement contribué au problème.

Dur… Dur… Alors, voici un premier conseil: ne transférez pas votre répertoire utilisateur sur un disque distant. Gardez bien votre répertoire “/home” sur le disque de démarrage. Je pense que le problème majeur rencontré était dû à un souci au montage du second disque après mes manipulations bas niveau du filesystem.

Prologue

Après quelques jours, je me suis aperçu qu’il manquait des choses: comme le calculateur “bc”, “webalizer” et des petits détails de ce genre qui empêchaient certains scripts de fonctionner correctement. Et un gros ralentissement sur la recherche via la localisation (bizarrement, cela semble dû à MongoDB 3.2). Mais dans l’ensemble, c’est très stable. Cette installation a été aussi l’occasion de faire du ménage et de préparer le passage à Miongo 3.2 version WiredTiger et Mongo 3.4

Finalement, la ré-installation complète a plutôt été une bonne chose. Au niveau de mon hébergeur, je dois noter que les réponses ont été plutôt rapides et complètes. Mais l’échange de mails n’est finalement pas le modèle le plus adapté. Le chat ou le support téléphonique aurait été plus efficace. Dans un moment de panique, surtout. Le principal problème de l’échange e-mail c’est qu’on ne connaît pas vraiment le niveau d’expertise qu’on a en face de soi (cela vaut encore plus pour la personne qui fait le support). En fait, j’avais le niveau pour résoudre le problème moi-même. C’est ce que j’ai fait — à ma façon.

Mais grâce à l’aide de l’infrastructure de Gandi. Grâce au cloud, j’ai pu détacher le disque de données pour le rattacher au nouveau serveur et j’ai récupéré les fichiers de configuration sur le disque de boot. Merci Linux et merci la virtualisation. Si les disques avaient été physiquement attachés à mon serveur, rien de tout cela n’aurait été possible. C’est la beauté du cloud et du VPS.

 

Advertisements

From → Other

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: