OVHcloud Web Hosting Status
Current status
Legend
- Operational
- Degraded performance
- Partial Outage
- Major Outage
- Under maintenance
filer 90plan
Scheduled Maintenance
Report for Web Cloud
Completed
Cette nuit nous allons intervenir sur un filer de 90plan dans une optique d'amélioration des performances. Certains sites seront inaccessibles pendant l'intervention.
Update(s):
Date: 2007-11-20 14:52:38 UTC
Suite au probleme sur le serveur de fichier sur 90plan et comme
annoncé, veillez utiliser le lien ci-joint pour generer le PDF
d'Indemnisation de 90plan suite à l'incident du 1791:
https://www.ovh.com/cgi-bin/procedure/90plan/index.cgi
(il suffit de donner le nom du domaine et le PDF est generé
en 1 clic, il faut l'imprimer et nous l'envoyer)
Date: 2007-11-15 23:45:57 UTC
Bonjour,
Les opérations ont pris fin. Tous les sites sont à nouveau en place
et fonctionnent. Nous ne relevons plus des erreurs 404 sur aucun
site de 90plan dû à l'incident (il reste encore 11 sites dans l'état
404 mais ce sont les cas particuliers). Nous sommes en train de
vérifier TOUS les sites 90plan pour retrouver éventuellement des
sites en 404, mais on pense que le chiffre sera proche de 0.
Il est temps d'en tirer des conclusions.
Le principal problème est que nous avons mis un temps fou pour
remettre le backup de vos sites en place. La panne pour certains
sites a été de 2-3 heures (dans la nuit de l'incident) jusqu'à
il y a moins d'1h soit environ 36h. C'est beaucoup trop lent et
donc la remise en place des données à partir de backup n'est pas
du tout adaptée à nos besoins. Mais comme c'est la première fois
en 8 ans que nous avons dû chercher les backups pour remettre une
partie des installations en place, la question reste ouverte:
comment réduire le temps de la panne lorsqu'il y a une destruction
des données ? C'est évidement mieux d'avoir un système qui ne tombe
pas en panne dans sa globalité (il faut savoir que c'est déjà le cas,
sauf cet incident, car on change environ 4 disques par semaine sur
nos systèmes de stockage en mutualisé, c'est un fonctionnement habituel),
mais malgré tout la destruction peut arriver. Cette problématique
de la remise en place de backup d'avoir une bonne réponse avec les
technologies que nous sommes en train de mettre au point. A cause de
l'incident, nous vous devons de la transparence et vous rassurer sur
nos travaux en cours et voici ce qu'on devait vous dire/annoncer dans un
mois: depuis 6-12 mois, nous travaillons avec Sun et son système
d'exploitation Solaris/OpenSolaris pour mettre au point de structures
de stockage de plusieurs centaines de To sur un filesystem de Sun ZFS.
Il s'agit des baies complètes de disques qui fonctionnent ensemble et
à haute vitesse en RAID-1 (plusieurs copies de disques en parallèle).
Ces technologies fonctionnent déjà en backup de l'hébergement dédié
avec 50To de données distribués sur plusieurs dizaines de serveurs.
Nous avons encore besoins d'un peu de temps pour débugger quelques
fonctionnalités de Solaris et Opensolaris avec d'autres technologies
mais surtout améliorer les performances du code lors des basculements
fail-over (le code source de Solaris est disponible, ça aide). Ceci
nous permettra proposer RPS 2008 puis adapter encore ces technologies
à l'hébergement mutualisé (on veut par exemple éviter d'utiliser NFS
mais d'avoir un accès simultanée sur les données à partir de plusieurs
serveurs ... oui c'est possible, on y travaille)
En conclusion sur ce point: nous pensons disposer d'une excellente
technologie de backup qui, en cas d'une destruction de données, permet
remettre le backup en place en minimum de temps.
Le problème de backup qui sont plus ou moins anciens rejoint le
premier point dans la mesure où le backup n'est jamais à jour. En améliorant
la vitesse de backup (création d'une image de vos sites et la remise
en place de l'image de vos sites) nous allons réduire les préjudices
sans jamais atteindre la perfection. En effet, entre les clients qui
nous disent \"oui le site marche mais je l'ai mis à jour Lundi et le
backup est de Lundi soir\" et les clients qui nous disent \"oui le site
marche mais il date de mois de septembre ou le mois d'avril\", la
problématique reste la même (dans l'absolue), même si c'est mieux
d'avoir le backup de Lundi que de mois d'avril. On peut aussi dire que
dans l'absolue le backup (peu importe lequel) a été remis en place et
le site fonctionne donc tout va bien. A ce niveau là, la solution
n'est pas évidente à trouver puisque tout dépend du type de site,
des technos qu'il utilise (le sql n'a pas été touché par la panne et donc
si vous avez un site full dynamique il remarche sans problème) mais
aussi du prix de backup et son rafraîchissement. Même si nous cherchons
la perfection et un idéal, il faut garder à l'esprit un compromis entre
le prix de l'hébergement par mois (moins de 4euro HT/mois pour 90plan)
et les services de cet hébergement. Ce compromis n'est jamais simple
à trouver: certains clients préfèrent beaucoup d'espace, mais lent
avec de sécurité, d'autres préfèrent peu d'espace mais ultra
rapide, avec une sécurité optimales mais sans plus ou d'autres la
sécurité très très importante sans la recherche de performance. Nous
allons mettre plus en avant les caractérises qui vous intéressent
et donner le choix. En effet, proposer une seule offre généraliste
pour répondre à autant des besoins n'est pas réaliste. Par contre l'un
de paramètre n'entre pas dans le compris: la sécurité de vos données.
Le client qui est prêt à perdre les données n'existe pas. Soyez rassuré:
on le savait déjà.
Cette panne nous a permit de voir que la meilleure manière de faire
les backups des installations n'est pas d'utiliser toujours le même serveur
de backup mais de faire tourner les serveurs de backup. Ainsi, même si le
serveur de backup est mort (comme c'était le cas la semaine passée), il faut
disposer des autres backups et donc utiliser les serveurs de backup à tour de rôle.
Le geste commercial.
Nous proposons à nos clients le geste commercial sur 2 niveaux:
1.) pour le temps de la remise en route du site, le temps que nous avons
mis à remettre vos données sur nos serveurs de fichier
2.) le rafraîchissement du backup que nous avons mis en place sur vos
site
Pour le 1.), nous appliquons le SLA, à savoir nous avons droit à une
panne de 43minutes par mois (99.9% de disponibilité). Au delà, vous
avez droit à des jours gratuits allant jusqu'au mois gratuit. C'est
le contrat. On l'applique. Par contre, nous allons faire simple: si
vous avez subit plus que 43 minutes de panne, vous avez droit directement
au mois gratuit.
Pour le 2.), le contrat ne dit rien à ce sujet. Au contraire il dit que
le client doit maintenir le backup de son site. Par contre, il nous est
impossible de faire comme si de rien n'était sur ce point là. Après des
discutions en interne, nous avons estimé que 3 mois gratuits était la
proposition la moins pire.
Sous 2 jours, nous allons vous proposer un PDF à telecharger et il suffira
mettre votre nom de domaines pour faire jouer le point 1.) et 2.) puis nous
l'envoyer. Les montants ne sont pas forcement importants mais sont proportionnels
à ce que nous vous facturons. Dans l'absolue, il faut oublier ces montants
et nous envoyer ce PDF. Car pour nous c'est une manière de dire que nous
reconnaissons le problème et que, vous, vous avez des droits. Ni l'un ni
l'autre n'est pas discutable. Et c'est le but de ce geste commercial.
Encore une fois nous sommes désolés pour cette contre performance. Soyez
rassuré: nous allons bosser dur pour enlever cette tache ... et dans peu
de temps, nous allons revenir vers vous avec le mutu 2008 opérationnel
(au lieu d'un long email).
Amicalement
Octave
Date: 2007-11-15 08:04:53 UTC
Bonjour,
Cet email fait suite à l'incident sur 90plan et complète le
task 1791:
http://travaux.ovh.com/?do=details&id=1791
La remise en place de vos sites est terminé à 94%. Il nous
reste quelques centaines de sites, suivant les lettres, qui
attendent son tour. Parfois nous avons un blocage sur la
remise en place d'un site et ceci bloque toute la lettre. Nous
sommes en train de reverifier tous les processes de remise en
place de vos sites.
En tout, sur 90plan nous avons 16 serveurs de stockage. L'un
de ce serveurs de stockage a été touché. Oui il s'agit d'un
netapp avec 28 disques où nous avons une tolérance de panne
de 2 disques (le serveur fonctionne même s'il a perdu 2 disques
et ceci grâce au raid). Dans notre cas, après le reboot du serveur,
3 disques se sont déclarés en panne et le raid a été rendu
inopérationel.
Sur ce serveur sont hébergés, nos clients historiques de 90plan
à savoir les plus anciens sites de 90plan. En tout environ 10000
sites. Sur ces 10000 sites, nous avons un backup de la semaine sur
1500 sites environ puis des backups de plus en plus anciens
jusqu'au mois d'avril où nous avons l'ensemble de 10000 sites.
Le site que nous avons remise en place est la version la plus
récente.
Bien sûr nous allons faire un geste commercial.
Il s'agit de la panne la plus grave vécue chez Ovh depuis le
démarrage de l'entreprise il y a 8ans. La panne redouté, qui est un
cauchemar à prévoir et qu'on espère que jamais ça n'arrivera. Mais
ça arrive et c'est là qu'on se doit de montrer ce qu'on a prévu et
finalement voir à quel point nous avons été réalistes ou pessimistes
lorsque nous avons créé les offres. Jusqu'au maintenant jamais un
serveur de stockage n'a rendu l'âme et encore moins un serveur spécialisé
dans le stockage. Mais ce sont les choses que nous avons prévu
et c'est pourquoi nous avons les backups (on sort les backups
quand c'est la cata, et ça ne sert que dans ce cas là) faits à de
différents dates. Le vrai problème, en dehors des dates de backup,
est le temps de remise en place des sites. Clairement les procédures
actuelles même si testées plusieurs fois et prévues, ne donnent pas
de satisfaction à la problématique de l'hébergement mutualisé.
Depuis 6-12 mois, nous remettons en cause le stockage actuel et
nous travaillons sur les nouvelles solutions de stockage. Notamment
pour franchir la barre de plusieurs To de stockage par site. La
technologie est déjà en place pour les backups de serveurs dédiés
(un système de stockage de plus de 50To). Puis ça viendra pour RPS
et enfin le mutu 2008.
Ces technologies sont en train d'être finalisées et déjà en fonctionnement.
Quelques principes:
- raid-1 sur plusieurs disques (par exemple 8 disques ce qui permet
d'avoir le débit de lecture 8 fois supérieure au débit d'écriture)
avec une sécurité importante des données (chaque disque a 8 copies).
et donc ne plus utiliser de raid-X (logiques), juste raid-1 simple et
efficace
- le système de snapshot de l'ensemble des sites lié au système de
backup externalisé. Sur le nouveau système de stockage, la photo
(le snap) de tous les sites est faite à minuit puis nous lançons
une copie en stream (bit par bit et non fichiers par fichier) d'un
datacentre à l'autre. La remise en place à partir d'un backup est
nettement plus rapide.
- une structure distribuée. au lieu d'utiliser 1 serveurs de fichier
avec plein de disques nous passons sur une structure de plusieurs
serveurs de fichiers avec plein de disques chaque. Les raid-1 sont
fait entre les disques de différents serveurs et donc si une baie
ou une salle d'hébergement tombe, tout continue à fonctionner
sur les installations qui sont toujours en place.
- la taille de stockage ne sera plus un problème du tout. On parlera
en To à partir de mois de janvier. Normalement ça devait rester
confidentiel jusqu'au mois de janvier. La panne nous oblige d'être
transparent jusqu'au bout.
Cet incident arrive au moment de changement technologiques. On aurait
aimé passer ce cap sans des telles histoires et une dégradation de
service pour nos clients. Mais ces histoires nous permettront aussi de
tirer les bonnes conclusions et avoir une solution de stockage qui
répond à des vrais besoins actuels et pour quelques années.
Nous allons faire un update de task dés que tout est remise en place.
Si vous avez des questions et pour aller plus vite, envoyez nous un
email directement sur oles@ovh.net, lau@ovh.net, tony@ovh.net qui
gèrent directement l'incident.
Amicalement
Octave
Date: 2007-11-14 17:20:17 UTC
merci d'envoyer les emails sur
oles@ovh.net, tony@ovh.net, lau@ovh.net
on traite vos emails en priorité haute pour la remis en
route de vos sites. en parallele les 10 process tournent
en parallele sur les autres sites qui attendent la remise
en place.
Date: 2007-11-14 16:47:04 UTC
Nous continuons la copie de sites sur le nouveau filer. Il y a
beaucoup de données à remettre en place. Nous avons augmenté la
taille de connexion interne entre les routeurs pour augmenter
la vitesse de basculement des données. Nous avons installé 3
filers au lieu d'1 pour augmenter la vitesse aussi.
Si vous avez le moindre probleme ou la question, envoyez nous
un email sur oles@ovh.net
Date: 2007-11-14 12:35:59 UTC
Le nouveau serveur a été instalé cette nuit et la restauration
des backup est en cours. Due à la charge occasionnée par la restauration,
le nouveau filer est utilisé a 100%.
Des ralentissements sont présent pour les sites se trouvant sur ce
serveur.
Date: 2007-11-14 03:32:04 UTC
Bonjour,
Cette nuit, pendant une maintenance de routine sur l'un des serveurs de
stockage de 90plan, nous avons connu un incident grave. 3 disques sont
devenus morts d'un coup après le reboot du serveur. Le filesystem a cassé.
Nous avons changé l'électronique des disques mais les disques sont toujours
morts. Nous sommes en train de construire un nouveau serveur et nous
allons remettre les sites hébergés sur ce serveur à partir de backup.
Nous avons plusieurs backup fait à des différents périodes (jusqu'au mois
d'avril). On devrait pouvoir remettre 100% des sites hébergés sur ce
serveur sous 2-3 heures mais tous les sites remis ne seront pas remis avec
les données de cette semaine. En effet, le backup de cette semaine a commencé
sur un nouveau serveur de backup le 11 novembre et n'a pas fini alors
que l'ancien serveur de backup a cassé la semaine passée. Heureusement
nous avons une stratégie de backup incrémentable et nous avons des backups
plus anciens et nous allons utiliser dans le cas où le backup récent ne
soit pas opérationnel.
Les autres serveurs de stockage du 90plan ne sont pas touchés. Les autres
plan ne sont pas touchés.
En savoir plus:
http://travaux.ovh.net/?do=details&id=1791
Toute l'équipe d'hébergement mutu est mobilisée actuellement pour rendre
90plan pleinement opérationnel au plus vite. Nous pensons d'avoir besoins
encore environ 2-3 heures pour remettre les 300Go de données hébergés sur
le serveur qui a cassé.
Sincèrement désolé pour cet incident. Avant de tirer de conclusions nous
allons finir les opérations.
Amicalement
Octave
Date: 2007-11-14 03:14:21 UTC
3 disques ont laché dans le netapp qui gere le repertoire
principal de 90plan. Même après le changement de l'electronique
des disques, les disques ne veulent pas demarrer. Le raid est
mort.
Nous avons plusieurs serveur de backup avec les données enregistrés
à plusieurs dates. Nous allons remettre les données sur un nouveau
filer principal avec ce que nous avons backupé sachant que le backup
de cette semaine a commencé sur un nouveau serveur de backup le 11
novembre et n'a pas fini. Alors que l'ancien serveur de backup a
cassé la semaine passée. Mais nous avons aussi les backups plus anciens
sur d'autres serveurs jusqu'au mois d'avril 2007. Avec tous ces backups
on devrait pouvoir remettre 99% des données en place sous 2-3 heures.
Date: 2007-11-14 01:14:56 UTC
Nous avons un probleme hardware sur le serveur de fichier.
Le raid est casse et non recuperable.
2 disques on lache lors de l'arret de la tete du serveur.
Nous sommes en train de mettre le backup sur un nouveau filer.
Date: 2007-11-13 23:33:58 UTC
Nous commencons la maintenance.
Update(s):
Date: 2007-11-20 14:52:38 UTC
Suite au probleme sur le serveur de fichier sur 90plan et comme
annoncé, veillez utiliser le lien ci-joint pour generer le PDF
d'Indemnisation de 90plan suite à l'incident du 1791:
https://www.ovh.com/cgi-bin/procedure/90plan/index.cgi
(il suffit de donner le nom du domaine et le PDF est generé
en 1 clic, il faut l'imprimer et nous l'envoyer)
Date: 2007-11-15 23:45:57 UTC
Bonjour,
Les opérations ont pris fin. Tous les sites sont à nouveau en place
et fonctionnent. Nous ne relevons plus des erreurs 404 sur aucun
site de 90plan dû à l'incident (il reste encore 11 sites dans l'état
404 mais ce sont les cas particuliers). Nous sommes en train de
vérifier TOUS les sites 90plan pour retrouver éventuellement des
sites en 404, mais on pense que le chiffre sera proche de 0.
Il est temps d'en tirer des conclusions.
Le principal problème est que nous avons mis un temps fou pour
remettre le backup de vos sites en place. La panne pour certains
sites a été de 2-3 heures (dans la nuit de l'incident) jusqu'à
il y a moins d'1h soit environ 36h. C'est beaucoup trop lent et
donc la remise en place des données à partir de backup n'est pas
du tout adaptée à nos besoins. Mais comme c'est la première fois
en 8 ans que nous avons dû chercher les backups pour remettre une
partie des installations en place, la question reste ouverte:
comment réduire le temps de la panne lorsqu'il y a une destruction
des données ? C'est évidement mieux d'avoir un système qui ne tombe
pas en panne dans sa globalité (il faut savoir que c'est déjà le cas,
sauf cet incident, car on change environ 4 disques par semaine sur
nos systèmes de stockage en mutualisé, c'est un fonctionnement habituel),
mais malgré tout la destruction peut arriver. Cette problématique
de la remise en place de backup d'avoir une bonne réponse avec les
technologies que nous sommes en train de mettre au point. A cause de
l'incident, nous vous devons de la transparence et vous rassurer sur
nos travaux en cours et voici ce qu'on devait vous dire/annoncer dans un
mois: depuis 6-12 mois, nous travaillons avec Sun et son système
d'exploitation Solaris/OpenSolaris pour mettre au point de structures
de stockage de plusieurs centaines de To sur un filesystem de Sun ZFS.
Il s'agit des baies complètes de disques qui fonctionnent ensemble et
à haute vitesse en RAID-1 (plusieurs copies de disques en parallèle).
Ces technologies fonctionnent déjà en backup de l'hébergement dédié
avec 50To de données distribués sur plusieurs dizaines de serveurs.
Nous avons encore besoins d'un peu de temps pour débugger quelques
fonctionnalités de Solaris et Opensolaris avec d'autres technologies
mais surtout améliorer les performances du code lors des basculements
fail-over (le code source de Solaris est disponible, ça aide). Ceci
nous permettra proposer RPS 2008 puis adapter encore ces technologies
à l'hébergement mutualisé (on veut par exemple éviter d'utiliser NFS
mais d'avoir un accès simultanée sur les données à partir de plusieurs
serveurs ... oui c'est possible, on y travaille)
En conclusion sur ce point: nous pensons disposer d'une excellente
technologie de backup qui, en cas d'une destruction de données, permet
remettre le backup en place en minimum de temps.
Le problème de backup qui sont plus ou moins anciens rejoint le
premier point dans la mesure où le backup n'est jamais à jour. En améliorant
la vitesse de backup (création d'une image de vos sites et la remise
en place de l'image de vos sites) nous allons réduire les préjudices
sans jamais atteindre la perfection. En effet, entre les clients qui
nous disent \"oui le site marche mais je l'ai mis à jour Lundi et le
backup est de Lundi soir\" et les clients qui nous disent \"oui le site
marche mais il date de mois de septembre ou le mois d'avril\", la
problématique reste la même (dans l'absolue), même si c'est mieux
d'avoir le backup de Lundi que de mois d'avril. On peut aussi dire que
dans l'absolue le backup (peu importe lequel) a été remis en place et
le site fonctionne donc tout va bien. A ce niveau là, la solution
n'est pas évidente à trouver puisque tout dépend du type de site,
des technos qu'il utilise (le sql n'a pas été touché par la panne et donc
si vous avez un site full dynamique il remarche sans problème) mais
aussi du prix de backup et son rafraîchissement. Même si nous cherchons
la perfection et un idéal, il faut garder à l'esprit un compromis entre
le prix de l'hébergement par mois (moins de 4euro HT/mois pour 90plan)
et les services de cet hébergement. Ce compromis n'est jamais simple
à trouver: certains clients préfèrent beaucoup d'espace, mais lent
avec de sécurité, d'autres préfèrent peu d'espace mais ultra
rapide, avec une sécurité optimales mais sans plus ou d'autres la
sécurité très très importante sans la recherche de performance. Nous
allons mettre plus en avant les caractérises qui vous intéressent
et donner le choix. En effet, proposer une seule offre généraliste
pour répondre à autant des besoins n'est pas réaliste. Par contre l'un
de paramètre n'entre pas dans le compris: la sécurité de vos données.
Le client qui est prêt à perdre les données n'existe pas. Soyez rassuré:
on le savait déjà.
Cette panne nous a permit de voir que la meilleure manière de faire
les backups des installations n'est pas d'utiliser toujours le même serveur
de backup mais de faire tourner les serveurs de backup. Ainsi, même si le
serveur de backup est mort (comme c'était le cas la semaine passée), il faut
disposer des autres backups et donc utiliser les serveurs de backup à tour de rôle.
Le geste commercial.
Nous proposons à nos clients le geste commercial sur 2 niveaux:
1.) pour le temps de la remise en route du site, le temps que nous avons
mis à remettre vos données sur nos serveurs de fichier
2.) le rafraîchissement du backup que nous avons mis en place sur vos
site
Pour le 1.), nous appliquons le SLA, à savoir nous avons droit à une
panne de 43minutes par mois (99.9% de disponibilité). Au delà, vous
avez droit à des jours gratuits allant jusqu'au mois gratuit. C'est
le contrat. On l'applique. Par contre, nous allons faire simple: si
vous avez subit plus que 43 minutes de panne, vous avez droit directement
au mois gratuit.
Pour le 2.), le contrat ne dit rien à ce sujet. Au contraire il dit que
le client doit maintenir le backup de son site. Par contre, il nous est
impossible de faire comme si de rien n'était sur ce point là. Après des
discutions en interne, nous avons estimé que 3 mois gratuits était la
proposition la moins pire.
Sous 2 jours, nous allons vous proposer un PDF à telecharger et il suffira
mettre votre nom de domaines pour faire jouer le point 1.) et 2.) puis nous
l'envoyer. Les montants ne sont pas forcement importants mais sont proportionnels
à ce que nous vous facturons. Dans l'absolue, il faut oublier ces montants
et nous envoyer ce PDF. Car pour nous c'est une manière de dire que nous
reconnaissons le problème et que, vous, vous avez des droits. Ni l'un ni
l'autre n'est pas discutable. Et c'est le but de ce geste commercial.
Encore une fois nous sommes désolés pour cette contre performance. Soyez
rassuré: nous allons bosser dur pour enlever cette tache ... et dans peu
de temps, nous allons revenir vers vous avec le mutu 2008 opérationnel
(au lieu d'un long email).
Amicalement
Octave
Date: 2007-11-15 08:04:53 UTC
Bonjour,
Cet email fait suite à l'incident sur 90plan et complète le
task 1791:
http://travaux.ovh.com/?do=details&id=1791
La remise en place de vos sites est terminé à 94%. Il nous
reste quelques centaines de sites, suivant les lettres, qui
attendent son tour. Parfois nous avons un blocage sur la
remise en place d'un site et ceci bloque toute la lettre. Nous
sommes en train de reverifier tous les processes de remise en
place de vos sites.
En tout, sur 90plan nous avons 16 serveurs de stockage. L'un
de ce serveurs de stockage a été touché. Oui il s'agit d'un
netapp avec 28 disques où nous avons une tolérance de panne
de 2 disques (le serveur fonctionne même s'il a perdu 2 disques
et ceci grâce au raid). Dans notre cas, après le reboot du serveur,
3 disques se sont déclarés en panne et le raid a été rendu
inopérationel.
Sur ce serveur sont hébergés, nos clients historiques de 90plan
à savoir les plus anciens sites de 90plan. En tout environ 10000
sites. Sur ces 10000 sites, nous avons un backup de la semaine sur
1500 sites environ puis des backups de plus en plus anciens
jusqu'au mois d'avril où nous avons l'ensemble de 10000 sites.
Le site que nous avons remise en place est la version la plus
récente.
Bien sûr nous allons faire un geste commercial.
Il s'agit de la panne la plus grave vécue chez Ovh depuis le
démarrage de l'entreprise il y a 8ans. La panne redouté, qui est un
cauchemar à prévoir et qu'on espère que jamais ça n'arrivera. Mais
ça arrive et c'est là qu'on se doit de montrer ce qu'on a prévu et
finalement voir à quel point nous avons été réalistes ou pessimistes
lorsque nous avons créé les offres. Jusqu'au maintenant jamais un
serveur de stockage n'a rendu l'âme et encore moins un serveur spécialisé
dans le stockage. Mais ce sont les choses que nous avons prévu
et c'est pourquoi nous avons les backups (on sort les backups
quand c'est la cata, et ça ne sert que dans ce cas là) faits à de
différents dates. Le vrai problème, en dehors des dates de backup,
est le temps de remise en place des sites. Clairement les procédures
actuelles même si testées plusieurs fois et prévues, ne donnent pas
de satisfaction à la problématique de l'hébergement mutualisé.
Depuis 6-12 mois, nous remettons en cause le stockage actuel et
nous travaillons sur les nouvelles solutions de stockage. Notamment
pour franchir la barre de plusieurs To de stockage par site. La
technologie est déjà en place pour les backups de serveurs dédiés
(un système de stockage de plus de 50To). Puis ça viendra pour RPS
et enfin le mutu 2008.
Ces technologies sont en train d'être finalisées et déjà en fonctionnement.
Quelques principes:
- raid-1 sur plusieurs disques (par exemple 8 disques ce qui permet
d'avoir le débit de lecture 8 fois supérieure au débit d'écriture)
avec une sécurité importante des données (chaque disque a 8 copies).
et donc ne plus utiliser de raid-X (logiques), juste raid-1 simple et
efficace
- le système de snapshot de l'ensemble des sites lié au système de
backup externalisé. Sur le nouveau système de stockage, la photo
(le snap) de tous les sites est faite à minuit puis nous lançons
une copie en stream (bit par bit et non fichiers par fichier) d'un
datacentre à l'autre. La remise en place à partir d'un backup est
nettement plus rapide.
- une structure distribuée. au lieu d'utiliser 1 serveurs de fichier
avec plein de disques nous passons sur une structure de plusieurs
serveurs de fichiers avec plein de disques chaque. Les raid-1 sont
fait entre les disques de différents serveurs et donc si une baie
ou une salle d'hébergement tombe, tout continue à fonctionner
sur les installations qui sont toujours en place.
- la taille de stockage ne sera plus un problème du tout. On parlera
en To à partir de mois de janvier. Normalement ça devait rester
confidentiel jusqu'au mois de janvier. La panne nous oblige d'être
transparent jusqu'au bout.
Cet incident arrive au moment de changement technologiques. On aurait
aimé passer ce cap sans des telles histoires et une dégradation de
service pour nos clients. Mais ces histoires nous permettront aussi de
tirer les bonnes conclusions et avoir une solution de stockage qui
répond à des vrais besoins actuels et pour quelques années.
Nous allons faire un update de task dés que tout est remise en place.
Si vous avez des questions et pour aller plus vite, envoyez nous un
email directement sur oles@ovh.net, lau@ovh.net, tony@ovh.net qui
gèrent directement l'incident.
Amicalement
Octave
Date: 2007-11-14 17:20:17 UTC
merci d'envoyer les emails sur
oles@ovh.net, tony@ovh.net, lau@ovh.net
on traite vos emails en priorité haute pour la remis en
route de vos sites. en parallele les 10 process tournent
en parallele sur les autres sites qui attendent la remise
en place.
Date: 2007-11-14 16:47:04 UTC
Nous continuons la copie de sites sur le nouveau filer. Il y a
beaucoup de données à remettre en place. Nous avons augmenté la
taille de connexion interne entre les routeurs pour augmenter
la vitesse de basculement des données. Nous avons installé 3
filers au lieu d'1 pour augmenter la vitesse aussi.
Si vous avez le moindre probleme ou la question, envoyez nous
un email sur oles@ovh.net
Date: 2007-11-14 12:35:59 UTC
Le nouveau serveur a été instalé cette nuit et la restauration
des backup est en cours. Due à la charge occasionnée par la restauration,
le nouveau filer est utilisé a 100%.
Des ralentissements sont présent pour les sites se trouvant sur ce
serveur.
Date: 2007-11-14 03:32:04 UTC
Bonjour,
Cette nuit, pendant une maintenance de routine sur l'un des serveurs de
stockage de 90plan, nous avons connu un incident grave. 3 disques sont
devenus morts d'un coup après le reboot du serveur. Le filesystem a cassé.
Nous avons changé l'électronique des disques mais les disques sont toujours
morts. Nous sommes en train de construire un nouveau serveur et nous
allons remettre les sites hébergés sur ce serveur à partir de backup.
Nous avons plusieurs backup fait à des différents périodes (jusqu'au mois
d'avril). On devrait pouvoir remettre 100% des sites hébergés sur ce
serveur sous 2-3 heures mais tous les sites remis ne seront pas remis avec
les données de cette semaine. En effet, le backup de cette semaine a commencé
sur un nouveau serveur de backup le 11 novembre et n'a pas fini alors
que l'ancien serveur de backup a cassé la semaine passée. Heureusement
nous avons une stratégie de backup incrémentable et nous avons des backups
plus anciens et nous allons utiliser dans le cas où le backup récent ne
soit pas opérationnel.
Les autres serveurs de stockage du 90plan ne sont pas touchés. Les autres
plan ne sont pas touchés.
En savoir plus:
http://travaux.ovh.net/?do=details&id=1791
Toute l'équipe d'hébergement mutu est mobilisée actuellement pour rendre
90plan pleinement opérationnel au plus vite. Nous pensons d'avoir besoins
encore environ 2-3 heures pour remettre les 300Go de données hébergés sur
le serveur qui a cassé.
Sincèrement désolé pour cet incident. Avant de tirer de conclusions nous
allons finir les opérations.
Amicalement
Octave
Date: 2007-11-14 03:14:21 UTC
3 disques ont laché dans le netapp qui gere le repertoire
principal de 90plan. Même après le changement de l'electronique
des disques, les disques ne veulent pas demarrer. Le raid est
mort.
Nous avons plusieurs serveur de backup avec les données enregistrés
à plusieurs dates. Nous allons remettre les données sur un nouveau
filer principal avec ce que nous avons backupé sachant que le backup
de cette semaine a commencé sur un nouveau serveur de backup le 11
novembre et n'a pas fini. Alors que l'ancien serveur de backup a
cassé la semaine passée. Mais nous avons aussi les backups plus anciens
sur d'autres serveurs jusqu'au mois d'avril 2007. Avec tous ces backups
on devrait pouvoir remettre 99% des données en place sous 2-3 heures.
Date: 2007-11-14 01:14:56 UTC
Nous avons un probleme hardware sur le serveur de fichier.
Le raid est casse et non recuperable.
2 disques on lache lors de l'arret de la tete du serveur.
Nous sommes en train de mettre le backup sur un nouveau filer.
Date: 2007-11-13 23:33:58 UTC
Nous commencons la maintenance.
This scheduled maintenance affected: Web Hosting || Datacenter GRA (Cluster002, Cluster003, Cluster006, Cluster007, Cluster011, Cluster012, Cluster013, Cluster014, Cluster015, Cluster017, Cluster020, Cluster021, Cluster023, Cluster024, Cluster025, Cluster026, Cluster027, Cluster028, Cluster029, Cluster030, Cluster031).