• Tous nos serveurs de backups sont désormais situés chez un prestataire externe, sur un site distant (en Allemagne), pour une sécurité maximale.
• Un compte A peut déléguer un sous-domaine dont il a la gestion à un compte B.
• Il est possible qu’un domaine soit l’alias d’un second que vous détenez. Par exemple : vous êtes propriétaire des domaines example.fr et example.com et souhaitez créer la boîte aux lettres test@example.fr. Si example.com est un alias de example.fr, alors test@example.com redirigera directement les emails vers test@example.fr.
• La validation par SMS a été retirée pour les nouvelles inscriptions, sauf circonstances particulières que nous gérons au cas par cas.
• Vous pouvez configurer un certificat SSL et une adresse IP dédiée par défaut qui s’appliqueront à l’ensemble des sous-domaines d’un domaine.
• De nouvelles extensions de domaine sont disponibles : .dk, .af, .ag, .am, .bz, .pm, .cx, .fm, .gd, .jp, .pl, .im, .pe, .ru, .gs, .gr, .gy, .hn, .ht, .lc, .lv, .mn, .ms, .mu, .mx, .no, .ph, .so, .tc, .tl, .tw, .vc. Attention il y en aura pour tout le monde
• Le fait de pouvoir renouveler son nom de domaine après sa date d’expiration est désormais possible en fonction des possibilités offertes par l’extension.
• Si vous avez activé le prélèvement automatique, nous mettons à disposition le document d’autorisation de prélèvement directement dans la section Facturation.

À bientôt !

Le dimanche 21 octobre, le serveur http4 a été indisponible de 1h02 à 10h17 (UTC+2). Cet article revient sur cette panne anormalement longue : ce qui s’est passé en détails, ce que nous allons faire pour que cela ne se reproduise plus, et une mise au point sur la redondance.

Ce qui s’est passé

Samedi, à 16h51, le serveur http4 a été retrouvé totalement freezé. Nous l’avons redémarré, puis surveillé la situation — les logs n’apportaient aucune indication. Un freeze peut être causé par un problème matériel ou logiciel ; impossible à ce moment d’être certain de l’origine.

À 22h01, le problème s’est manifesté à nouveau. Les logs nous ont cette fois-ci permis d’identifier à coup sûr l’origine matérielle (carte mère en fin de vie). Nous avons donc programmé avec notre fournisseur le remplacement de la carte pour le début de la nuit, à 1h00.

À 1h02, le serveur est mis hors service pour procéder au remplacement de la carte mère. En temps normal, ce genre d’opération dure moins de 30 minutes.

Après le changement de la carte mère, le serveur refusait de démarrer. L’intégralité de la RAM a été changée, ce qui a résolu ce problème. Seconde anomalie, la carte réseau (Intel 10Gb) affichait en boucle :

ixgbe 0000:04:00.0: eth0: Reset adapter
ixgbe 0000:04:00.0: eth0: detected SFP+: 0

Le reste du système fonctionnait bien, le noyau se comportait normalement. Le technicien a donc essayé d’identifier la cause du problème et a notamment :

• vérifié le câblage ;
• vérifié la configuration du switch ;
• changé la carte réseau pour un modèle identique ;
• remis l’ancienne carte réseau ;
• remis l’ancienne carte mère ;
• remis la nouvelle carte mère ;
• mis à jour le BIOS de la carte mère ;
• mis à jour le firmware de la carte réseau.

Sans succès. Le technicien a ensuite décidé de monter en urgence un serveur neuf, à la configuration identique, et d’y insérer les disques de notre serveur. Sans que cela ne résolve le problème.

Il faut ajouter une précision importante : seul notre propre noyau Linux (celui que nous compilons et maintenons, avec notre propre configuration) présentait le bug. Le noyau standard de notre fournisseur, lui, fonctionnait correctement, ce qui semble exclure un problème matériel/câblage. Néanmoins, notre noyau fonctionnait parfaitement jusqu’à présent sur ce serveur… ce qui rend la panne d’autant plus mystérieuse.

Enfin, un technicien senior a, peu avant 10h, pu récupérer un modèle de carte réseau très légèrement différent (toujours une Intel 10Gb) : cela a finalement résolu le problème.

Diminuer les risques à l’avenir

Le problème d’origine — la carte réseau qui subitement refuse de fonctionner — reste mystérieux et non élucidé. Ce peut être dû à un bug particulièrement capricieux du driver noyau, par exemple. Il est impossible de se prémunir contre ce genre d’anomalie, heureusement exceptionnellement rare.

C’est néanmoins la première fois, en 6 ans, que nous sommes confrontés à une panne sur un serveur d’une telle ampleur. Nous pouvons en tirer plusieurs conclusions.

Privilégier les serveurs des gammes les plus courantes

Notre fournisseur (OVH, en l’occurrence), propose des serveurs de différentes gammes. Le serveur http4, datant de début 2010, fait partie de la plus haute gamme, avec davantage encore de protections que les serveurs plus classiques (par exemple, ils disposent d’une double alimentation ou de connexions réseau 10 Gb/s).

D’expérience (nous avons des serveurs de toutes les gammes), nous constatons que :

• la fiabilité matérielle théoriquement supérieure des serveurs haut de gamme n’est pas significativement différente de celles des autres gammes ;
• le parc de serveurs haut de gamme de notre fournisseur est bien plus limité que celui des autres serveurs. En conséquence, et d’après notre expérience subjective et limitée :
  • ces serveurs semblent davantage susceptibles d’être victimes de certains types de bugs « rares » (matériel, routage) : plus il y a d’utilisateurs d’un équipement X, plus vite les éventuels bugs seront détectés et corrigés ;
  • les techniciens (de niveau 1) étant moins fréquemment confrontés à ces serveurs, ils ont globalement moins d’expérience dessus. Expérience précieuse en cas de problème urgent ;
  • les chances d’avoir un serveur de remplacement déjà prêt à l’emploi sont plus faibles.

En faisant le bilan, nous constatons que la fiabilité des serveurs haut de gamme aura plutôt tendance à être inférieure à celle des autres gammes, paradoxalement. Nous allons donc cesser progressivement d’utiliser ces serveurs (en mutualisé, http4 et http6 sont concernés).

Si http4 avait été sur un serveur de gamme standard, il est possible que le bug mystique de la carte réseau aurait déjà été découvert et résolu avant qu’il ne nous impacte. Par ailleurs, des serveurs de secours auraient probablement été disponibles plus rapidement.

S’assurer que nos serveurs peuvent démarrer avec le noyau de notre fournisseur

Notre fournisseur permet d’utiliser leur propre noyau Linux précompilé. Nous ne les utilisons pas pour de nombreuses raisons, notamment l’impossibilité d’en choisir la version, d’appliquer des patches ou de modifier la configuration.

S’il n’est donc pas question de nous mettre à utiliser les noyaux standards de notre fournisseur (à cause des limitations indiquées), il serait souhaitable qu’en cas d’urgence, il soit au moins possible de booter nos serveurs avec. Ne serait-ce que pour aider au débogage.

Concrètement, les modifications à apporter à la configuration de nos serveurs est minime.

Si nous avions pu démarrer http4 sur le noyau de notre fournisseur, le serveur aurait été à nouveau accessible bien plus rapidement. Quitte à ce que certaines fonctionnalités non essentielles soient désactivées.

Permettre d’accéder rapidement aux données en mode rescue

En cas de problème, il est possible de démarrer les serveurs dans un mode rescue (boot via TFTP/NFS). Les disques durs ne sont alors pas du tout utilisés par le système, ce qui garantit théoriquement que ce mode rescue est accessible même en cas de problème de configuration.

Nous allons désormais disposer de notre propre serveur de secours (spare). En cas de problème matériel ou logiciel grave qui ne peut être résolu rapidement, nous aurons alors la possibilité de démarrer le serveur en question en rescue, puis d’exporter sa partition de données vers le serveur de secours. Ce dernier prendra alors le relai du serveur en panne, lequel pourra être débogué calmement ensuite. Nous avons simulé cette bascule ces derniers jours, avec succès.

Des techniciens de niveau 2, 24h/24

À l’heure actuelle, des techniciens de niveau 2 ne sont pas systématiquement présents chaque nuit. En l’occurrence, la panne est arrivée un dimanche, les techniciens de niveau 2 n’arrivaient pas avant 10h. Notre fournisseur nous a indiqué travailler sur ce point et procéder actuellement à de nombreux recrutements pour atteindre l’objectif d’avoir des techniciens de niveau 2, 24h/24.

Et la redondance ?

Nos serveurs étaient jusqu’à peu redondés en Irlande, utilisant la technologie DRBD. Cette redondance en temps réel, mise en place dès le début d’alwaysdata, avait pour but de pallier les pannes graves (matérielles, réseau) qui pourraient s’éterniser en basculant vers le datacenter de secours. Pourquoi ce basculement n’a pas été fait ?

Après plusieurs années équipés de cette redondance, nous avons progressivement commencé à la désactiver sur certains serveurs. Les raisons sont les suivantes :

• la stabilité n’est pas suffisante. DRBD a trop souvent été la source de blocages/plantages sur le serveur primaire, et ce malgré les mises à jour fréquentes. Il suffit de regarder le changelog pour constater que chaque nouvelle version corrige des bugs assez graves. Nous utilisons DRBD dans un mode WAN qui n’est pas le plus fréquent, ce qui pourrait expliquer la relative instabilité ;
• nous n’avions jamais eu, en 6 ans, de panne exceptionnelle justifiant de basculer vers le datacenter de secours (la panne de http4 est la toute première). C’est une bonne nouvelle : cela signifie que la stabilité de notre fournisseur principal est très bonne ;
• la redondance a un coût :
  • (assez faible) sur les performances IO des serveurs,
  • (non négligeable) sur la complexité de notre architecture,
  • (faible) financier ;
• moins on a l’occasion d’effectuer en situations réelles la bascule vers le datacenter secondaire, plus on court de risques que tout ne se passe pas parfaitement le jour où on doit le faire – malgré les simulations.

Le bilan est donc sans appel : la redondance ne nous a jamais servi, mais a causé à plusieurs reprises des pannes. C’est indiscutablement un paradoxe : la redondance a diminué la disponibilité moyenne.

On peut toutefois se demander pourquoi ne pas avoir activé la redondance lors de pannes de plus petite ampleur (>= 30 minutes) :

• les pannes de petite ampleur d’origine matérielle ou réseau (les seules susceptibles d’être éliminées par un basculement) sont tout d’abord très rares. Sur les 64 pannes référencées depuis que nous avons notre page d’état des services, seules 3 ont duré plus de 30 minutes et auraient pu être éligibles à un basculement vers le serveur secondaire ;
• le basculement n’est pas instantané : le serveur secondaire doit prendre le relai, et surtout les DNS doivent être mis à jour. En pratique, sur du HTTP, il faut environ 30 minutes pour que la grande majorité des nouvelles connexions soient effectuées sur la nouvelle IP ;
• conséquence du point précédent : le basculement peut être contre-productif. Si on décide le basculement après 30 minutes de panne, mais que cette dernière est résolue 5 minutes après, on va devoir rebasculer vers le serveur primaire. Au final, il aurait mieux fallu ne rien faire. Or la plupart des pannes qui durent plus de 30 minutes durent moins de 60 minutes ;
• le basculement présente des risques de split-brain si on ne peut pas s’assurer que la machine primaire est hors service. Cela rend la bascule assez risquée lors d’une panne de réseau, notamment.

Au final, même si la panne de http4 aurait justifié de basculer (panne longue, serveur hors service), nous ne remettons pas en cause notre décision d’arrêter la redondance.

Une erreur toutefois : nous aurions dû annoncer publiquement l’arrêt de cette redondance, fut-elle partielle (certains serveurs ont encore la redondance d’activée à l’heure actuelle). C’est désormais chose faite.

D’autres formes de redondance à l’avenir ?

Si nous arrêtons aujourd’hui la redondance via DRBD, il est possible que nous nous dirigions à l’avenir vers d’autres formes de redondance — par exemple une réplication des bases de données ou une synchronisation systématique des systèmes de fichiers. Le but ne serait toutefois pas uniquement d’améliorer la disponibilité mais d’offrir d’autres avantages, par exemple en termes de performances.

Précisons que la suppression de la redondance en temps réel n’a strictement aucun lien avec les sauvegardes, toujours effectuées quotidiennement et conservées pendant 30 jours.

En conclusion

Nous présentons toutes nos excuses à nos clients pour cette panne exceptionnelle. Ceux qui ont été impactés peuvent ouvrir un ticket en demandant le remboursement intégral du mois d’octobre, comme nos conditions générales de vente le stipulent.

Rappelons notre attachement à fournir le meilleur taux de disponibilité possible, même sur un environnement mutualisé. C’est un challenge quotidien, compte tenu de la grande souplesse que nous offrons (e.g. ouvrir un compte sans payer, pouvoir faire tourner n’importe quel processus sur son compte).

Promettre qu’il n’y aura plus jamais de grosse panne serait illusoire : personne ne peut garantir cela. Ce que nous promettons, c’est une transparence totale, durant l’incident et après, avec des mesures concrètes pour éviter que cela ne se reproduise. Et des réponses à vos questions, si vous en avez.

PS : l’évènement est gratuit et libre d’accès, mangez-en !

Cette simplicité séduit non seulement les clients légitimes, mais aussi de nombreux clients aux activités illicites (spam, phishing, etc.). Ces comptes indésirables deviennent de plus en plus nombreux et nous conduisent aujourd’hui à prendre des nouvelles mesures.

Désormais, nous envoyons un code de validation par SMS durant l’inscription : vous devez le saisir avant de poursuivre. Cet inconvénient mineur pour la majorité des clients de bonne foi devrait drastiquement limiter les abus. Parce que nous préférons passer du temps à améliorer notre service plutôt que courir après les comptes frauduleux

Si vous participez également à ce week-end d’échanges autour du web, alors j’espère vous y croiser !

• configurer le prélèvement automatique par une carte bleue (jusqu’à présent le prélèvement s’effectuait uniquement sur un compte bancaire français) ;
• enregistrer une ou plusieurs cartes bleues pour des paiements ultérieurs.

Nous permettons ainsi à nos clients qui disposent d’un compte étranger de configurer le prélèvement, et facilitons leurs achats à l’ensemble de nos clients. Pour information, nous ne stockons pas les numéros des cartes bleues, c’est le rôle du prestataire « PCI compliant » avec lequel nous nous sommes interfacé.

• Adresses IP
• Certificats SSL

Désormais, vous pouvez vous-même réserver une adresse IP en choisissant son pays (peut être utile pour le référencement mais n’a aucune influence sur les performances ou la localisation réelle des serveurs) et déclarer votre certificat SSL au format .pem.

Vous pourrez ensuite configurer vos sous-domaines (via la page de détail de votre domaine ou encore depuis l’édition de votre Site) afin d’y activer votre adresse IP, avec ou sans SSL. À noter que l’activation d’un certificat SSL requiert une adresse IP dédiée.

• il est nécessaire d’ajouter préalablement le domaine en gestion, ce qui n’est pas particulièrement intuitif ;
• lorsqu’un site est accessible par plusieurs sous-domaines (www.example.org et example.org), il faut saisir le répertoire de destination pour chacun d’eux ;
• la configuration d’un sous-domaine est limitée à son répertoire de destination. Depuis quelques mois, il est toutefois possible de nous demander d’activer Passenger ou mod_wsgi en nous contactant ;
• il est fastidieux d’héberger plusieurs sites sur un même sous-domaine, dans des répertoires distincts.

Place aux « sites »

Oubliez ce système et découvrez la nouvelle section de l’administration alwaysdata : les Sites. Au lieu de manipuler des sous-domaines comme auparavant, c’est désormais des « sites » que vous créez. Un site est constitué de :

• une ou plusieurs adresses. Une adresse, c’est un sous-domaine plus, éventuellement, un chemin. Voici quelques exemples : www.example.net, example.com, forum.example.org, www.example.com/forum/ ;
• un type. Nous proposons à l’heure actuelle 5 types, détaillés plus bas ;
• des options de configuration qui dépendent du type.

Les avantages de ce nouveau système sont nombreux :

• il n’est plus nécessaire d’ajouter préalablement votre domaine. L’ajout d’un domaine en gestion n’est désormais requise que lorsque vous souhaitez utiliser nos serveurs DNS ;
• quel que soit le nombre d’adresses de votre site, il n’y a plus de configuration à dupliquer ;
• vous pouvez préciser un chemin dans vos adresses. Vous pouvez ainsi avoir une application Django sur www.example.net et une application PHP sur www.example.net/blog sans avoir à bidouiller ;
• il n’est plus nécessaire de nous contacter pour activer Passenger ou mod_wsgi ;
• vous pouvez créer une redirection HTTP sans avoir à créer laborieusement un .htaccess ;
• vous pouvez partager un domaine au sein de plusieurs comptes appartenant à un même client.

L’installation d’applications en 1 clic a été intégré à cette section Sites : vous avez un bouton Installer une application qui vous permet d’installer, comme auparavant, un WordPress, phpBB, DokuWiki… de manière automatique. La suppression des applications a toutefois été retirée : peu intuitive et prêtant à confusion, vous devrez désormais supprimer manuellement une application dont vous n’avez plus besoin.

Types de sites

Nous proposons, pour démarrer, 5 types :

• Apache standard : correspond au type utilisé jusqu’à présent sur l’ensemble des sous-domaines. Il convient pour les fichiers statiques, PHP ou toute application utilisant FastCGI. En cas de doute, c’est le type que vous devrez utiliser ;
• Apache personnalisé : vous permet d’indiquer vos propres directives Apache, sans aucune limite. Attention à ne rien casser ;
• Redirection : comme son nom l’indique, vous permet de mettre en place des redirections HTTP. 3 modes sont possibles : 301 (permanent), 302 (temporaire) et transparent (reverse proxy) ;
• Ruby on Rails : indiquez simplement le répertoire de votre application Rails, elle sera déployée via Passenger. À l’avenir, il sera possible d’opter pour un autre mécanisme de déploiement que Passenger, pour ceux qui préfèrent d’autres technologies (Unicorn, par exemple) ;
• WSGI : votre application WSGI sera déployée avec mod_wsgi. Même chose, la technologie pourra être changée plus tard (hello gunicorn).

Migration des comptes existants

Les sous-domaines existants ont été convertis automatiquement en sites. Si vous aviez plusieurs sous-domaines pointant vers un même répertoire, nous n’avons créé qu’un seul site. Les noms des sites générés sont peu originaux (Site 01, Site 02, etc.), libre à vous de les modifier à votre guise. Si malgré toutes nos précautions vous constatez la moindre anomalie, contactez-nous.

Et ensuite…

Cette nouvelle interface, sur laquelle nous avons commencé à travailler il y a longtemps, va nous permettre d’ajouter de nombreuses fonctionnalités : cache HTTP, IP dédiées (déjà disponibles sur demande), certificats SSL (idem). L’interface de statistiques (Piwik) sera également modifiée pour que chaque site ait ses propres statistiques. Surtout, de nouveaux types de sites vont être ajoutés : Django (qui tourne déjà parfaitement en FastCGI), Node.js, Java, Erlang…

Suivez notre Twitter pour participer aux prochains beta tests

Désormais, les emails sortants seront classés en 3 catégories, suivant leur qualité. Les emails considérés comme de bonne qualité partiront d’une IP A, ceux considérés comme de qualité moyenne partiront d’une IP B, et ceux qui sont de qualité médiocre partiront d’une IP C. Les emails de très mauvaise qualité continueront d’être bloqués – le seuil a d’ailleurs été abaissé.

Les emails « propres » seront ainsi expédiés depuis une IP dont la réputation sera meilleure qu’actuellement, améliorant donc la délivrabilité. Bien sûr, l’adresse IP n’est qu’un facteur parmi d’autres : envoyer depuis une IP ayant très bonne réputation ne garantit pas que les emails ne seront pas considérés comme spam, mais cela aide.

Par ailleurs, nous proposons désormais la possibilité de souscrire à une IP dédiée pour l’envoi des emails. Facturée au même prix que les IP dédiées HTTP – 5 €/mois – cela vous permettra d’avoir une réputation qui ne dépend que de vos propres envois.

Avant

Jusqu’alors, le système était relativement simple : un seul point d’entrée pour se connecter (via l’interface d’administration) en saisissant  votre adresse email renseignée lors de l’inscription. Une fois connecté, vous aviez alors accès à l’ensemble de ce que nous proposons dans cette interface : gestion de vos informations, vos factures, vos comptes, et toute la technique (domaines, emails, FTP, etc.) pour chacun de vos comptes. À noter qu’il était également possible de se connecter en spécifiant un nom du compte plutôt que votre adresse email ; cet accès était alors limité à toute la partie technique du compte en question.

Cette manière de faire a récemment atteint ses limites : vous êtes aujourd’hui très nombreux à utiliser nos services et par conséquent, nous disposons désormais de profils d’utilisateurs bien différents, avec des besoins spécifiques. Ainsi, il a fallu concentrer nos efforts d’amélioration sur les deux points suivants :

• affiner les droits des utilisateurs de manière bien plus précise (commercial, technique, par compte) ;
• repenser techniquement le système afin qu’il s’ouvre à d’autres points d’entrée (comme notre API qui arrive en bêta très bientôt).

Maintenant

Bien évidemment, le moyen de se connecter à l’interface d’administration n’a pas changé : il vous suffit toujours de saisir votre adresse email ainsi que le mot de passe que vous aviez choisi lors de votre inscription. Ce que vous verrez de nouveau, à gauche, c’est le menu Permissions. Vous aurez alors la possibilité d’administrer les permissions attribuées à chaque utilisateur (y compris vous-même). Voici la liste des permissions qui ont été introduites :

Permissions globales

• Gestion des comptes
• Facturation
• Accès technique total

Permissions techniques

Ces permissions ne sont nécessaires que si l’utilisateur n’a pas l’accès technique total.

• Consommation
• Statistiques
• Domaines
• Emails
• Bases de données
• FTP
• SSH
• WebDAV
• Environnement
• Applications
• Processus

Bon, je ne prends pas la peine de les expliquer chacune, elles sont assez explicites : si vous avez par exemple la permission FTP vous pourrez alors consulter/administrer vos comptes FTP et ainsi de suite pour les autres permissions.

Cas pratiques

Il est possible que pour nombre d’entre vous, l’utilisation des permissions ne soit pas franchement utile. Mais il est certain que cela va l’être dans quelques cas bien précis que nos utilisateurs rencontrent.

• Distinction commerciale/technique : en n’attribuant par exemple que la gestion des comptes et la facturation à un utilisateur et l’accès technique total à un autre , il est désormais possible et très simple de séparer les reponsabilités dites commerciales de celles techniques, permettant (entre autres) d’éviter les accidents…
• Accès « développeur » : vous disposez de plusieurs comptes que vous souhaiteriez attribuer à des développeurs précis, donnez leur un accès technique (total ou partiel) sans qu’ils ne soient concernés par la gestion commerciale.
• Permissions limitées : vous hébergez chez alwaysdata de nombreux comptes pour vos clients. Vous pouvez par exemple leur laisser la main sur les emails afin qu’ils puissent créer leurs adresses sans passer systématiquement par vous…

Demain

Vous l’aurez compris, ce nouveau système est beaucoup plus souple et fin en terme de permissions. Il a été pensé pour que nous puissions, dès que le besoin s’en fera sentir, en rajouter de nouvelles. C’est donc assez rapidement, grâce à votre utilisation puis surement aussi avec l’introduction de notre API, que nous pourrons encore l’améliorer et l’affiner.

Bref. On a rajouté des permissions.