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 :
1 2 | 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.
Explications super clair, pro et transparentes, merci !
Je ne sais pas si c’est possible techniquement, mais faire une sorte de clustering des serveurs http (redistribuer les requêtes sur différents http en fonction de la charge?), cela permettrait d’améliorer les performances (peut-être) et d’avoir une certaine redondance (sans doute) ?
Philippe : la partie applicative (Apache, PHP, etc.) est en effet triviale à dupliquer. Ce qui est complexe, ce sont les données (i.e. vos fichiers) : elles doivent forcément être stockées quelque part. Et vous aurez beau avoir une couche applicative dupliquée, si elle ne peut pas accéder aux données, ça ne servira à rien.
On en revient donc à la question de la duplication des données. DRBD est une solution, mais qui ne nous convient pas après l’avoir utilisée durant plusieurs années. Les systèmes de fichiers distribués sont, quant à eux, très peu adaptés à des utilisations généralistes comme du Web. Sans compter que dès qu’on utilise du NAS/SAN plutôt que du stockage local, on perd d’un côté (performances, simplicité, fiabilité) ce qu’on gagne de l’autre (souplesse).
Quant à l’amélioration des performances via un cluster : nos serveurs HTTP tournent en moyenne à 30 % d’occupation maximum, donc ce n’est pas de ce côté que ça rame. Et qui dit cluster, dit NAS, et donc petite perte de performances.
Le seul cas où ce serait vraiment légitime, c’est pour aider à absorber de très gros pics de trafic, ce qui se produit extrêmement rarement. Et même dans ce cas-là, la partie purement applicative (e.g. PHP) n’est pas nécessairement ce qui coince – c’est souvent la base de données.
Bravo à Alwaysdata qui fait preuve d’une belle transparence, et qui n’hésite pas à prendre du recul pour que ses services soient toujours meilleurs !
Certains devraient en prendre de la graine…
Merci Cyril pour ces explications.
Je rebondi sur la question de Philippe et ta réponse. Avez-vous fait des tests de performance sur le stockage des données sur un filer ? Est-ce vraiment la cata ? L’utilisation de DRDB, c’était entre Roubaix et l’Irlande ?
Avec une architecture de type cluster on serait quand même un peu à l’abri de ce type de longue panne matériel.
Dire que les systèmes de fichier distribués ne sont pas adaptés au web, c’est un peu abusé non ;) ? Comment font les autres hébergeurs ?!
Je lis sur le site « Suivant la gravité de l’incident et le temps estimé de réparation, nous pourrons décider de basculer votre architecture vers notre datacenter secondaire pour remettre votre infrastructure en marche au plus vite. » Est-ce effectif ?
Question subsidiaire : quand est-il des sauvegardes ? sont-elles stockées ailleurs que chez OVH ?
Plein de questions donc !
Merci
YvesTan : on a l’expérience des filers depuis le début, puisque quand vous vous connectez en SSH, les données ne sont pas locales mais montées par NFS (depuis le serveur HTTP, donc). C’est donc évidemment utilisable, des tas de gens le font :) Il y a des inconvénients :
– oui, les performances sont inférieures. Ce n’est pas catastrophique, mais il est évidemment plus coûteux d’aller chercher des données sur un autre serveur qu’en local. Sur une requête IO, ça va, sur des centaines (*cough* PHP), ça commence à se faire sentir ;
– NFS, en tout cas sous Linux, n’est pas d’une très grande stabilité. Dites-vous qu’avec notre minuscule expérience, nous avons déjà rapporté 2 bugs sérieux NFS au noyau Linux (l’un provoquait un freeze, l’autre était un memory leak grave). Sans compter tous les autres bugs, et les désagréments inhérents mêmes au protocole (synchronisation par exemple) ;
– on introduit une nouvelle cause de panne/lenteurs : le réseau entre le filter et le serveur applicatif.
Mais surtout, utiliser un filer résout quoi ? Aujourd’hui, le SPOF est sur le serveur HTTP. Avec un filer, il est déporté sur le filer. Rien n’aurait empêché le filer d’avoir une panne similaire à celle qu’a eue http4, avec la même indisponibilité.
Oui, l’utilisation de DRBD, c’était entre Roubaix et l’Irlande (EC2). Si c’est pour faire Roubaix/Roubaix, on diminue drastiquement l’intérêt de la réplication à mes yeux. Et ça n’élimine pas les bugs de DRBD de toute façon.
Quand je dis que les systèmes de fichiers distribués ne sont pas adaptés au Web, je pense à des choses comme GlusterFS, et je maintiens que c’est pas adapté à du Web (avec un besoin de latence faible), mais plutôt à du stockage. Ensuite il y a des choses comme GFS2 ou OCFS : en 2006, on voulait partir dessus, et après quelques semaines à galérer, on s’est dit que vraiment, le jeu n’en valait pas la chandelle. Sans compter qu’avec btrfs qui arrive (et sur lequel on va basculer), on va avoir un paquet de fonctionnalités géniales, qui en sont pas dispos avec GFS2 ou OCFS.
Concernant la phrase « Suivant la gravité de l’incident… », sur quelle page est-elle ? Ce n’est plus effectif (nous avons normalement retiré tout ce qui parlait du second datacenter).
Bonne question pour les sauvegardes. Historiquement, elles étaient chez OVH. Récemment, on a pris un serveur ailleurs (Hetzner, Allemagne), pour plus de sécurité (on a toujours un serveur de backup chez OVH). Mais on se demande si on va continuer dans ce sens : la latence élevée pose problème, d’une part pour la sauvegarde quotidienne des bases de données, mais aussi parce que le jour où on a besoin de récupérer 2 To de backups en urgence (ce n’est encore jamais arrivé), on gagnerait à ce que le serveur soit proche. On réfléchit donc à ce qu’on va faire.
Bravo pour la transparence, mais carton jaune pour la suppression (silencieuse) de la redondance (il y a toujours en signature « Nos serveurs sont situés en France, redondés en Irlande »).
Perso, j’attends de AD un mutualisé avec de la redondance. Pas forcément au niveau Internet (l’architecture historique), mais au moins locale.
J’entends tous les soucis énoncés relatifs à la maintenance d’un cluster. N’y aurait-il pas un juste milieu, du genre « syncro fichier type rsync croisée entre 2 hosts, et basculement de l’IP du host en rade sur le second host (cluster actif/actif) » quitte à entrer en mode dégradé ? Ou alors, pour limiter les coûts, maintenir chez OVH une (ou plusieurs) VM « serveur » qui demeure éteinte en temps normal, et serait allumée en cas de besoin, recevrait l’IP failover et monterait le système de fichier dupliqué « quelque part » via rsync (ou autre)?
Savoir que l’offre mutu n’est plus redondée me fait rétrograder l’offre AD, aussi séduisante soit-elle par ailleurs : pour moi, une offre mutu *doit* être redondée, ce n’est pas une option dans mes critères de choix.
Wally : pour la signature, on doit la retirer partout, pour l’instant certains sites annexes (blog, forum) l’ont encore. Je vais m’en charger.
Le rsync « continu » pose 2 problèmes : d’une part, ça introduit une perte de données si on doit basculer. Ça convient à certains, mais pas à d’autres, pour qui mieux vaut 2h de panne que des pertes de données. En mutualisé, c’est difficile de faire du cas par cas. D’autre part, c’est impossible techniquement aujourd’hui : un simple rsync d’un serveur mutualisé prend 12h.
La VM éteinte, c’est ce qu’on faisait avec EC2. Le problème c’est la réplication des données. DRBD, ça plante. rsync c’est pas faisable. Et puis si c’est pour rester dans le même datacenter, on limite l’intérêt.
Vous dites qu’une offre mutu doit être redondée. Je pense qu’on ne comprend pas la notion de « redondance » de la même manière. Quels hébergeurs mutus font de la redondance temps réel des fichiers, à votre connaissance ?
Merci Cyril pour les précisions.
La phrase est sur cette page (en français) : https://www.alwaysdata.com/features/ha/
OVH ne propose pas du iSCSI ou du Fiber Channel ?
Merci Yves, c’est corrigé.
L’iSCSI est faisable sans besoin de support explicite d’OVH (c’est de l’IP). Mais ça ne résout aucune solution, ce n’est pas de la redondance.
Bonjour Cyril,
Pourquoi cette réticence à dupliquer dans le même datacenter ? Comme tu l’expliques, la fiabilité d’OVH est excellente, et faire de la duplication « locale » permettrait d’avoir d’excellentes performances. Quel risque penses-tu limiter en changeant de fournisseur (tu peux rester chez OVH et avoir une baie dans un autre datacenter aussi) ? Quelle est la probabilité pour que cet aléa survienne ?
A plus
Guillaume : en gros, quelles pannes une redondance (dans un datacenter distant) permet d’éviter ?
1. panne matérielle (locale) d’une machine qui s’éternise. C’est le cas de http4. C’est arrivé une seule fois en 6 ans, et encore, c’était davantage logiciel que matériel. En implémentant ce qu’on suggère dans le billet de blog (principalement, accès rescue + machine de spare), pas besoin de redondance.
2. panne globale réseau ou datacenter qui s’éternise. Type inondation à la Sandy. OVH n’a jamais connu de panne de cette ampleur ou même vaguement proche, et Roubaix ne semble pas être une zone particulièrement à risques. Seule une redondance vers un datacenter secondaire permet de s’en sortir.
3. Perte de données. Si c’est à cause d’une corruption de système de fichiers, c’est répliqué via DRBD, donc la redondance n’aide en rien. Si c’est une double perte de disques durs simultanée (RAID1), la redondance permet de s’en sortir. Probabilité très faible – plus faible qu’une corruption de système de fichiers.
Donc on a d’un côté, toute une gamme de pannes potentielles qu’une redondance (locale ou distante) ne permet de toute façon pas de pallier (corruption de systèmes de fichiers, erreur humaine, piratage, DDoS). De l’autre, le fait d’utiliser DRBD provoque des pannes (avec une fréquence pas si faible).
Au final, je continue fermement à penser que le jeu n’en vaut objectivement pas la chandelle, et que la réticence est davantage psychologique (ce qui n’est pas rien, je l’admets).
Est-ce que le fait de savoir qu’on peut remonter rapidement un serveur opérationnel dans un datacenter de secours, mais en partant des dernières sauvegardes (et non pas des données répliquées en temps réel), vous rassurerait ?
Pour le point 2 > c’est justement lié à ma question sur les sauvegardes hors OVH ou OVH mais à Strasbourg ou au Canada.
De mon côté en effet de simples sauvegardes suffiraient. J’en fait aussi de mon côté d’ailleurs ;-)
La redondance est un argument majeur, mais elle a un coût… Dès qu’on mirrore deux serveurs sur deux datacenters différents, $$$. J’ai un fournisseur allemand qui fait ça à pas trop trop cher mais ce n’est quand même pas accessible à tout le monde.
Pour les mutualisés, je me souviens l’an dernier ou il y a deux ans chez infomaniak, leur datacenter pourtant hyper protégé – et situé dans un pays neutre- est tombé en rade. Une pelleteuse avait donné un coup dans la ligne d’alimentation et tranché dans le même temps le câble d’arrivée réseau électrique, et le câble du groupe électrogène. Bad trip.. Bilan, il faut redonder aussi l’alim électrique dans des gaines différentes et dans des tranchées différentes… Et Roubaix n’est pas à l’abri de ce genre de vétille…
Bref si vous voulez du réel 99.9999 il faut se lever tôt et penser à tout.
Du coup effectivement la remarque de Wally me parait étrange « pour moi, une offre mutu *doit* être redondée, ce n’est pas une option » alors dans ce cas ce n’est pas du mutualisé, sauf à confondre RAID et redondance.
Je pense que même avec les changements tarifaires qui s’annoncent chez AlwaysData, l’offre reste pertinente par sa souplesse et son kernel administré de façon très propre.
En réalité cette histoire démontre aussi des trous chez OVH : technicien de niveau 2 pas présent mais surtout ce que je trouve inacceptable c’est le planning de changement de la carte : 3 heures entre reprise du problème et intervention, c’est d’une lenteur hallucinante.
Gil : le coût est sincèrement un argument très faible dans notre cas. Avec EC2, on ne payait que le coût du disque (et du réseau), pas le coût de la machine secondaire elle-même (on démarrait la VM à la volée, en cas de besoin).
Concernant le datacenter qui tombe en rade, oui ça peut arriver. J’ignore OVH serait prémuni contre ce cas précis ; il y aura de toute façon toujours des vraies catastrophes possibles. Mais le risque est à mes yeux trop faible pour justifier la redondance, sauf à avoir un vrai besoin critique de dispo 99,999 % (hors mutualisé donc). Si un client nous le demande en dédié, on le fait (après en avoir toutefois discuté).
Et comme vous dites, on parle ici de redondance totale, pas de RAID (qu’on a évidemment sur toutes nos machines, il n’y a même pas de débat possible).
Concernant le couac nocturne chez OVH : j’ai eu 2 infos depuis la publication de l’article. D’une part, les techniciens niveau 1 n’ont pas le droit de faire certaines opérations, dont manifestement celui de mettre une carte réseau différente des modèles « homologués ». D’autre part, on m’a confirmé que sur les HG (serveurs haut de gamme), toutes les opérations sont carrément plus délicates. Au point de me décourager de planifier des maintenances la nuit s’il n’y a pas de technicien niveau 2 présent. Ce qui conforte totalement notre choix de ne plus utiliser ces gammes de serveurs.
@cyril (« Quels hébergeurs mutus font de la redondance temps réel des fichiers, à votre connaissance ? ») : l’offre OVH mutu ; Pour ceux qui ne connaissent pas leur infra mutualisée : pour chaque offre mutualisée, des clusters (grappes) de serveurs qui jouent les serveurs web, d’autres qui contiennent les bases de données, et enfin des filers pour le stockage. Bien sûr, ce modèle a aussi ses limites, comme on peut le constater régulièrement (je suis aussi client chez eux). Mais : une baie du mutu OVH peut brûler (voir : un bâtiment), le service continuera d’être opérationnel à 100% (car tous les services sont redondés).
Ma définition de « hébergement mutualisé », c’est partage des ressources en vue d’avoir une prestation d’hébergement « gold » à un tarif accessible aux petits budgets. Et pour moi, partager un serveur dédié (je caricature) aussi bien administré soit-il ne relève pas de l’hébergement « gold », mais d’une prestation inférieure.
Ceci étant dit, comme vous le soulignez, il n’y a pas de solution parfaite ; et de surcroît, je ne suis pas assez compétent pour vous proposer quelque chose de pertinent, juste assez pour vous poser des questions ;-)
Si on reprend l’architecture de AD avant, avec une redondance hors site (chez online ou chez EC2): elle répondait aux problématiques de panne totale dans le datacenter (comme la panne réseau OVH d’il y a quelques temps). Je n’ai jamais été à l’aise avec cette approche, car il me manquait (pour me rassurer) une redondance locale : il suffit d’une panne d’alimentation, de carte mère, un incendie, une fuite du refroidissement, etc… pour que l’hébergement associé soit down, et ce, pour plusieurs heures (c’est la loi de Murphy), là où cela pourrait être imperceptible avec une redondance locale (un simple N+1, genre cluster actif/actif). Même si comprend les risques associés (split-brain et autres).
Enfin, si on « objective » les choses : dans l’absolu, peut importe les moyens, seul le résultat compte. Mais : à défaut d’avoir la « chance » de subir une panne, le client doit se faire son opinion en se basant sur l’offre. Et pas de redondance (en dehors du RAID des disques, si j’ai bien compris), cela me fait trop de SPOF à mon goût pour être serein. Pour répondre à Gil : Sans attendre du 99.9999%, j’ai besoin d’être rassuré sur le fait qu’un incident (cf liste non exhaustive ci-dessus) ne va pas entraîner une indisponibilité de mes sites pour plusieurs heures.
Encore une fois, ce n’est qu’un point de vue, qui se veut constructif !
Willy : sauf erreur, leurs filers ne sont pas redondés, donc ce n’est pas mieux que nous. Il suffit d’aller sur leur page de travaux pour le constater : quand ils ont une panne de filer, le service est down. Je n’ai jamais vu mention d’une quelconque redondance des filers nulle part.
N’oublions pas dans cette discussion que la raison première pour laquelle on a coupé la redondance, c’est qu’elle provoquait des bugs/pannes. Ce n’est *pas* pour une raison de coûts.
Donc plutôt qu’une redondance temps-réel pas fiable, on va sans doute s’orienter vers la possibilité de repartir des backups très rapidement, avec des backups effectués par exemple toutes les demi-heures. Et évidemment, en parallèle, tout faire pour que les pannes de plusieurs heures n’arrivent plus.
Je suis assez d’accord avec Wally sur le fait qu’on risque de se retrouver (en caricaturant fortement) sur des serveurs dédiés en co-locations administrés.
Je repose ma question : y a t‑il au minimum des sauvegardes à l’extérieur d’OVH en cas d’attaque de zombies sur roubaix ;) ?
Merci pour le billet.
Un mois après l’incident, la signature dit toujours « France + Irlande » sur le blog et le forum. Par ailleurs, « nos serveurs sont situés en Europe » c’est un poil trop vendeur surtout si c’est juste un serveur de backup en Allemagne. Enfin bref.
Sinon, petit souci de traduction de l’article en anglais : « Our provider advised us to work on this point and to proceed with the current, numerous recruitments to reach the target of having level 2 technicians 24/7. » On comprend que OVH vous conseille de recruter vous-même des techniciens !
YvesTan : je ne vous suis pas, quel rapport entre le fait de supprimer une redondance et avoir un dédié co-loué ? La redondance concerne d’ailleurs aussi bien nos serveurs mutualisés que dédiés.
Concernant les sauvegardes, comme je le disais (peut-être pas assez clairement), aujourd’hui 50 % sont déjà hors OVH (en Allemagne), et à terme ce sera 100 %.
Quentin : c’est corrigé pour le blog/forum. Nos serveurs sont en Europe, ce n’est pas vendeur, c’est la réalité. On ne dit pas qu’on a des serveurs partout en Europe (ce qui serait, pour le coup, vendeur). Tout est question d’échelle : doit-on dire qu’ils sont à Roubaix ? Dans le Nord-Pas-de-Calais ? En France ? On a une clientèle mondiale, donc on se place au niveau continental.
Bien vu pour la mauvaise tournure anglaise, c’est corrigé.