La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: vivien le 09 novembre 2017 à 08:35:03
-
Depuis 20 minutes il est quasiment impossible d'accéder aux sites OVH depuis Orange en IPv4 comme en IPv6
Je suis le seul impacté ?
Site d'OVH :
(https://lafibre.info/images/ovh/201711_ovh_site_internet_inacessible.png)
Graphes SmokePing IPv4 :
(https://lafibre.info/images/ovh/201711_ovh_ipv4_depuis_orange.png)
Graphes SmokePing IPv6 :
(https://lafibre.info/images/ovh/201711_ovh_ipv6_depuis_orange.png)
-
(https://lafibre.info/images/ovh/201711_ovh_incident_electrique_1.jpg)
(https://lafibre.info/images/ovh/201711_ovh_incident_electrique_2.jpg)
-
Bonjour
je confirme le down de tous les site ovh même le dédié est down a rbx5
-
idem chez moi, par Orange ou Nerim, nos sites sont inacessibles ainsi que http://travaux.ovh.net :( :(
-
Dure matinée pour OVH (cf le Twitter d'octave)
-
Y'a plus de courant ! ::)
-
dure journée pour le responsable de la maintenance des 2 groupes électrogènes qui se mettent en défaut alors qu'ils sont sensés prendre le relais...
-
Tous les opérateurs semblent impactés par la/les panne(s)
-
dure journée pour le responsable de la maintenance des 2 groupes électrogènes qui se mettent en défaut alors qu'ils sont sensés prendre le relais...
Enfin je n'en voudrais pas de ce job de maintenance de groupes de ces puissances avec des fréquences d'exploitations aussi faibles.
-
dure journée pour le responsable de la maintenance des 2 groupes électrogènes qui se mettent en défaut alors qu'ils sont sensés prendre le relais...
C'est pas 2 GE mais 2 ensembles de GE !
-
1er article
Coup dur pour OVH qui connaît une grosse panne sur ses serveurs ce jeudi matin
Les réseaux sociaux trépignent. Depuis 7 h ce jeudi matin, la société OVH, l’hébergeur de sites internets installé à Roubaix, connaît une grosse panne d’alimentation électrique qui pénalise ses serveurs et donc de nombreux sites internets.
http://www.lavoixdunord.fr/261395/article/2017-11-09/coup-dur-pour-ovh-qui-connait-une-grosse-panne-sur-ses-serveurs-ce-jeudi-matin
-
Enfin je n'en voudrais pas de ce job de maintenance de groupes de ces puissances avec des fréquences d'exploitations aussi faibles.
Qu'appelles tu fréquences d'exploitations s'il te plait ? les périodes de maintenance programmées autorisées ou autre chose ?
-
Y'a plus de courant ! ::)
Pourtant dans le SFR NetCenter de Strasbourg (à qq centaines de mètres du DC OVH), on a du jus, rien à signaler :)
Limite on peut les aider à déplacer les équipements :D
-
Probablement que ces générateurs ne sont quasiment jamais utilisés hors tests forcèment pas complétement réels.
-
:o Tiens les restrictions électriques ont déjà débuté. ;D
Plus sérieusement, j'espère qu'ils arriveront à remettre le courant rapidement.
Puis dans ce genre de situation, il ne faut pas compter sur les onduleurs car leurs autonomies sont insuffisantes.
-
Le but de l'onduleur c'est juste d'être là en attendant le démarrage des GE.
-
Vous vous focalisez sur la panne électrique à SBG, mais de mon point de vue, la perte de l'intégralité du réseau optique de Roubaix (+Gravelines?) est beaucoup plus inquiétante, et impacte infiniment plus de clients.
Leon.
-
On a surtout perdu une partie importantes des liens, non ?
(https://lafibre.info/images/ovh/201711_ovh_incident_electrique_3.png)
-
Des châssis 100G dans un premier temps.
-
Et en plus, il déploient des firmwares "Demo build, unofficial Technicolor SW, not suitable for deployment!" sur les modem TG799vac !!
-
Qu'appelles tu fréquences d'exploitations s'il te plait ? les périodes de maintenance programmées autorisées ou autre chose ?
le temps et les conditions de marche du groupe
-
Et en plus, il déploient des firmwares "Demo build, unofficial Technicolor SW, not suitable for deployment!" sur les modem TG799vac !!
Bootloader OID : unofficialbuildOID0000
C'est comme ça sur tous les firmware Technicolor, idem sur ceux de l'operateur italien TIM. c'est pas OVH mais technicolor...
Mais ca n'a aucun rapport avec le problème ici présent :o
-
ca y est c'est revenu ! 8)
-
meme lemonde en parle ^^
http://www.lemonde.fr/pixels/article/2017/11/09/l-hebergeur-internet-ovh-touche-par-une-importante-panne_5212399_4408996.html
effectivement, perte des 2 arrivées + mis en défaut des 2 bloc de GE... ca fait mal... et quand en plus le réseau optique qui n'est pas censé être lié, tombe aussi... ca va faire mal aux stats de disponibilité xD
-
ca y est c'est revenu ! 8)
ca doit etre sympa le pic de conso pour tout redémarrer :D
edit:
RBX: all optical links 100G from RBX to TH2, GSW, LDN, BRU, FRA, AMS are down.
RBX: the DB of the optical node in RBX is corrupted. All links are still down. We upload the backup. ETA: 30min
ca pique :x corruption de la bd suite à la perte d'un lien de synchro vers un serveur sur un des datacenters down?? c'est moche si c'est ca :-X
-
ils devraient peut-être héberger travaux.ovh.com chez un autre hébergeur, dans un autre pays...ca permettrait de pouvoir être au courant sans devoir aller sur les réseaux sociaux.
-
On notera que c'est ce que fait Online avec status.online.net qui est hébergé chez Jaguar.
-
C'est comme chez Free, quand tout marche c'est génial mais le jour ou ça down, bin personne ne sait pourquoi c'est arrivé et comment remettre en route.
Professionnels du réseau et de l'infrastructure.
Tu parles !!!!
Une disquette dans un pc en 95 et voilà les experts d'aujourd'hui ::)
Tout est redondé au moins 3x parait il... Ah bon ???
J'ai jamais voulu avoir un quelconque service chez OVH, trop de risque que ça tombe et voilà que la vie me donne raison 8)
-
Probablement que ces générateurs ne sont quasiment jamais utilisés hors tests forcèment pas complétement réels.
Dans le petrole il est obligatoire de tester les Gen set (Diesel Generator) 1 fois tous les mois :)
-
C'est classique comme fréquence de test, ça m'étonnerait qu'ils ne fassent pas au moins un test par mois.
-
il y a des enregistrements qualité avec quelques valeurs, température, niveau, huile etc ... les équipes de maintenance doivent tout enregistrer afin de faire des éventuelles comparaisons...
Il y a meme des Diesel Fire Water Pump qui démarrent à 100% des coups pour lesquelles la configuration est marche ou crève. Meme sans huile, ou en défaut mécanique la Diesel Fire Water Pump doit tourner et pomper l'eau
-
OVH test ses groupes régulièrement :
https://lafibre.info/ovh-datacenter/test-de-groupes/
https://www.youtube.com/watch?v=6-ne4mDDdMc#ws
-
Le datacenter de Strasbourg semble toujours isolé.
-
OVH test ses groupes régulièrement :
https://lafibre.info/ovh-datacenter/test-de-groupes/
Idem, sur le site sur lequel je travail, les groupes tournent tous les 2 mois (sauf en cas de gros pic de pollution ;) ).
-
Deux alims EDF et deux groupes en pannes en meme temps, c'est simplement impossible quand on fait un design High-Availlibilité correctement, c'est une excuse bidon, ou ca été fait vraiment par des bras cassés...
Il y a un règle a respecter, c'est N+1, donc si 2 groupes sont en caraffe, ce qui peux arriver avec la loi de Murphy, il en faillait simplement trois, comme pour les clims, c'est le meme principe.
C'est impossible de planifier une maintenance avec downtime sur une clim ou un groupe, sachant qu'il y a plus de redondance en cas de panne imprévue.
Les tableaux électrique ne se mettent pas au meme endroit, les adductions dans le bâtiment sont a l’opposé, maintenant des couillons j'en ai vu, la pompe a diesiel branchée sur le réseau EDF au lieu d'un onduleur, ce qui fait que ca c'est jamais remarqué pendant les tests, jusqu'au jour ou il y a eu une panne réelle de 2 heurs dans un DC, et les deux groupes on tourné 5 minutes le temps de vider les canalisations de fioul :(
-
Mes machines à Strasbourg sont toujours down...
-
Deux alims EDF et deux groupes en pannes en meme temps, c'est simplement impossible quand on fait un design High-Availlibilité correctement, c'est une excuse bidon, ou ca été fait vraiment par des bras cassés...
Il y a un règle a respecter, c'est N+1, donc si 2 groupes sont en caraffe, ce qui peux arriver avec la loi de Murphy, il en faillait simplement trois, comme pour les clims, c'est le meme principe.
C'est impossible de planifier une maintenance avec downtime sur une clim ou un groupe, sachant qu'il y a plus de redondance en cas de panne imprévue.
Les tableaux électrique ne se mettent pas au meme endroit, les adductions dans le bâtiment sont a l’opposé, maintenant des couillons j'en ai vu, la pompe a diesiel branchée sur le réseau EDF au lieu d'un onduleur, ce qui fait que ca c'est jamais remarqué pendant les tests, jusqu'au jour ou il y a eu une panne réelle de 2 heurs dans un DC, et les deux groupes on tourné 5 minutes le temps de vider les canalisations de fioul :(
Toutes ces sociétés gérées techniquement par des baltringues.
Depuis le temps que je le dit 8)
Ils n'ont aucun bon sens et sont juste bardés de diplômes et certifications Cisco et Microsoft mais ça, ça ne suffit pas sur un CV !!!
Remember TV5 monde !!!!
Et on s'étonne que des gosses de 15 ans pénètrent dans des serveurs de sociétés.
On vie une époque formidable ::)
-
Toutes ces sociétés gérées techniquement par des baltringues.
Ce terme ne me semble pas du tout approprié.
La majorité des Datacenter qui ont eu plus de 10 ans d'exploitation ont eu des pannes qui sembles impossibles.
(https://lafibre.info/images/datacenter/200603_redbus_humour1.jpg)
Comme dans d'autres cas, je pense que nous ne connaîtrons jamais la vrai vérité.
-
Mes machines à Strasbourg sont toujours down...
Tout est maintenant reparti sur Stastbourg mais nous n'avons pas l'explication technique.
Sur l'incident plus important qui a coupé d'Internet tous les datacentre français d'OVH, on a plus d'informations :
Bonjour,
Ce matin, nous avons eu un incident sur le réseau optique qui interconnecte notre site de Roubaix (RBX) avec 6 des 33 points de présence (POP) de notre réseau : Paris (TH2 et GSW), Francfort (FRA), Amsterdam (AMS), London (LDN), Bruxelles (BRU).
Le site RBX est connecté à travers 6 fibres optiques à ces 6 POP : 2x RBX<>BRU, 2x RBX<>LDN, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). Ces 6 fibres optiques sont connectées aux systèmes de nœuds optiques qui permettent d’avoir 80 longueurs d’onde de 100Gbps sur chaque fibre optique.
Pour chaque 100G connectés aux routeurs, nous utilisons 2 chemins optiques qui sont géographiquement distincts. En cas de coupure de fibre optique, le fameux « coup de pelleteuse », le système se reconfigure en 50ms et tous les liens restent UP. Pour connecter RBX aux POP, nous avons 4.4Tbps de capacité, 44x100G : 12x 100G vers Paris, 8x100G vers London, 2x100G vers Bruxelles, 8x100G vers Amsterdam, 10x100G vers Frankfurt, 2x100G vers DC GRA et 2x100G vers DC SBG.
A 8h01, d’un coup, l’ensemble des liens 100G, les 44x 100G, ont été perdus. Étant donné le système de redondance que nous avons mis en place, l’origine du problème ne pouvait pas être la coupure physique de 6 fibres optiques simultanèment. Nous n’avons pas pu faire les diagnostiques sur les châssis à distance car les interfaces de management étaient figées. Nous avons été obligés d’intervenir directement dans les salles de routage, pour faire les manipulations sur les châssis : déconnecter les câbles entre les châssis puis faire redémarrer le système et enfin seulement faire les diagnostiques avec l’équipementier. Les tentatives de redémarrage du système ont pris beaucoup de temps, car chaque châssis a besoin de 10 à 12 minutes pour démarrer. C’est la principale raison de la durée de l’incident.
Le diagnostique : Toutes les cartes transpondeurs que nous utilisons, ncs2k-400g-lk9, ncs2k-200g-cklc, sont passées en état « standby ». L’une des origines possible d’un tel état est la perte de configuration. Nous avons donc récupéré le backup et remis en place la configuration, ce qui a permis au système de reconfigurer toutes les cartes transpondeurs. Les 100G dans les routeurs sont revenus naturellement et la connexion de RBX vers les 6 POP a été rétablie à 10h34.
Il s’agit clairement d’un bug software sur les équipements optiques. La base de données avec la configuration est enregistrée 3 fois et copiée sur 2 cartes de supervision. Malgré toutes ces sécurités, la base a disparu. Nous allons travailler avec l’équipementier pour trouver l’origine du problème et les aider à fixer le bug. Nous ne remettons pas en cause la confiance avec l’équipementier, même si ce type de bug est particulièrement critique. L’uptime est une question de design qui prend en compte tous les cas de figure, y compris quand plus rien ne marche. Le mode parano chez Ovh doit être poussé encore plus loin dans l’ensemble de nos designs.
Les bugs ça peut exister, les incidents qui impactent nos clients non. Il y a forcement une erreur chez Ovh puisque malgré tous les investissements dans le réseau, dans les fibres, dans les technologies, nous venons d’avoir 2 heures de downtime sur l’ensemble de nos infrastructures à Roubaix.
L’une des solutions est de créer 2 systèmes de nœuds optiques au lieu d’un seul. 2 systèmes, cela veut dire 2 bases de données et donc en cas de perte de la configuration, un seul système est en panne. Si 50% des liens passent par l’un des systèmes, aujourd’hui, nous aurions perdu 50% de la capacité mais pas 100% de liens. C’est l’un des projets que nous avons commencé il y a 1 mois, les châssis ont été commandés et nous allons les recevoir dans les prochains jours. Nous pourrons commencer les travaux de configuration et migration sous 2 semaines. Vu l’incident d’aujourd’hui, ce projet devient prioritaire, pour l’ensemble de nos infrastructures, tous les DCs, tous les POPs.
Dans le métier de fournisseur des infrastructures Cloud, seul ceux qui sont paranos durent. La qualité de service est une conséquence de 2 éléments. Tous les incidents anticipés « by design ». Et les incidents où nous avons appris de nos erreurs. Cet incident là nous amène à mettre la barre encore plus haut pour s’approcher du risque zéro.
Nous sommes sincèrement désolés pour les 2H33 minutes de downtime sur le site RBX. Dans les prochains jours, les clients impactés vont recevoir un email pour déclencher l’application des engagements SLA.
Amicalement
Octave
-
je me doute qu'un tel équipement ne doit pas être donné, ni fait pour s'arrêter tous le temps... mais 1 seul équipement pour faire arriver toute les fibres / 4.4tbps de son réseau... un bon gros spof :-X
après, le matos était déjà commandé pour le doubler, et minimiser les risques, mais a trop jouer a celui qui sert les fesses, ca finit par lâcher xD et jamais au bon moment...
l'avantage c'est qu'en cumulant les 2 incidents du jour, ça ne fait qu'une seule fois du downtime xD
-
Attention, il n'a pas dit que tout était sur un même équipement, mais il a dit que tout était sur un même système. C'est différent.
Un système est composé de plusieurs équipements qui peuvent être sur plusieurs sites. En cas de bug logiciel, il est possible de perte l'intégralité.
L’une des solutions est de créer 2 systèmes de nœuds optiques au lieu d’un seul. 2 systèmes, cela veut dire 2 bases de données et donc en cas de perte de la configuration, un seul système est en panne. Si 50% des liens passent par l’un des systèmes, aujourd’hui, nous aurions perdu 50% de la capacité mais pas 100% de liens. C’est l’un des projets que nous avons commencé il y a 1 mois, les châssis ont été commandés et nous allons les recevoir dans les prochains jours. Nous pourrons commencer les travaux de configuration et migration sous 2 semaines. Vu l’incident d’aujourd’hui, ce projet devient prioritaire, pour l’ensemble de nos infrastructures, tous les DCs, tous les POPs.
-
effectivement, j'ai lu trop vite :)
-
L'avantage de ce genre d'incident majeur, c'est que ça montre les SPOF (Single Points Of Failure). Certes, de manière un peu brutale, mais au moins, ça incite sérieusement à corriger.
Dans le cas présent, j'avais envie de dire qu'il est très étonnant de la part d'OVH de mettre tous ses équipements optiques de Roubaix ensembles, avec une seule config pour tous, qui constituent un seul "système".
Mais je/nous n'avons clairement pas assez d'éléments pour juger de quoi que ce soit, la critique bête et méchante est trop facile.
Et puis on ne tire pas sur les ambulances.
Dans un domaine "très haute disponibilité" que je connais, on pousse le vice jusqu'à éliminer au maximum les "défaillances systématiques" (bugs, erreur de conception), en multipliant les fournisseurs : équipements différents, groupes électrogènes et onduleurs de marques différentes, climatisation, routeurs, switches, serveurs de marques différentes, processeurs différents, et softs totalement redondants mais développés par des équipes différentes, avec des méthodes de conception différentes, avec des compilateurs différents, etc... Ca peut aller très loin.
Pour finir, la concordance entre les 2 défaillances majeures chez OVH est assez incroyable. Les 2 pannes majeures (équipements optiques à Roubaix et coupure électrique à Strasbourg) ont eu lieu à quelques dizaines de minutes d'écart. Si c'est vraiment le hasard, c'est pas de bol.
Leon.
-
La dernière phrase en dit long...
Nous sommes sincèrement désolés pour les 2H33 minutes de downtime sur le site RBX. Dans les prochains jours, les clients impactés vont recevoir un email pour déclencher l’application des engagements SLA.
Le nombre de fois ou j'ai entendu de la part des financiers "de la haute disponibilité nous coute bien plus cher que d'indemiser un SLA pas respecté"
Surtout que statistiquement les incidents a indemniser sont tres rare.
Et OVH fait plutot dans le "low cost" alors nous faire croire que la tres haute disponibilité est leur priorité, j'ai du mal a le croire.
-
Pour finir, la concordance entre les 2 défaillances majeures chez OVH est assez incroyable.
Pour une personne qui a uniquement les informations qui ont été communiqués, je ne vois pas comment le rapprochement ne peut pas être un peu évident. Base de données corrompue, shutdowns électriques, shutdowns électriques, base de données corrompue ?
S'il y a du redémarrage de masse pour diagnostiquer des problèmes dans la plus grande panique ça compte aussi.
-
Et OVH fait plutot dans le "low cost" alors nous faire croire que la tres haute disponibilité est leur priorité, j'ai du mal a le croire.
Bien dit.
-
Dans le cas présent, j'avais envie de dire qu'il est très étonnant de la part d'OVH de mettre tous ses équipements optiques de Roubaix ensembles, avec une seule config pour tous, qui constituent un seul "système".
Sauf si c'est le principe même de leur ring WDM :).
Pour finir, la concordance entre les 2 défaillances majeures chez OVH est assez incroyable. Les 2 pannes majeures (équipements optiques à Roubaix et coupure électrique à Strasbourg) ont eu lieu à quelques dizaines de minutes d'écart. Si c'est vraiment le hasard, c'est pas de bol.
Ou alors c'est (un peu) lié...
-
La dernière phrase en dit long...
Le nombre de fois ou j'ai entendu de la part des financiers "de la haute disponibilité nous coute bien plus cher que d'indemiser un SLA pas respecté"
Surtout que statistiquement les incidents a indemniser sont tres rare.
Et OVH fait plutot dans le "low cost" alors nous faire croire que la tres haute disponibilité est leur priorité, j'ai du mal a le croire.
@Miky,
Je suis assez d'accord avec toi sur la partie SLA.
Mais je ne suis pas du tout d'accord avec toi sur le fait que la "haute dispo" ne serait pas la priorité d'OVH. Ici, on parle bel et bien de la perte totale du plus gros datacenter d'OVH, de plusieurs dizaines de milliers de serveurs, dont beaucoup de serveurs à 400€ par mois!
Clairement, on ne gère pas la "haute dispo" de la même façon entre un équipement (switch) qui impacte une seule baie (quelques dizaines de serveurs) et un équipement (routeur de coeur, optique longue distance) dont la perte peut impacter des dizaines de milliers de serveurs. OVH se doit d'assurer une haute disponibilité sur son coeur de réseau, ça me semble être une évidence. Même si OVH n'avait que des serveurs low cost (ce qui n'est pas le cas), il faudrait qu'ils assurent cette haute dispo dans leur coeur de réseau, vu le volume impacté.
Leon.
-
Il y a un règle a respecter, c'est N+1, donc si 2 groupes sont en caraffe, ce qui peux arriver avec la loi de Murphy, il en faillait simplement trois, comme pour les clims, c'est le meme principe.
Hein??? :o :o Miky, tu es en train de nous réinventer la définition du N+1! C'est du n'importe quoi, ce que tu racontes.
N+1 n'est pas "LA" règle à respecter comme tu sembles dire. Tu peux avoir plein d'autres architectures de redondance : du 2N, du N+2, du 2x(N+1), etc...
Et puis N+1 n'impose absolument pas d'être robuste à une panne de 2 groupes électrogènes.
C'est impossible de planifier une maintenance avec downtime sur une clim ou un groupe, sachant qu'il y a plus de redondance en cas de panne imprévue.
Attention, N+1 est un niveau de sécurité qui n'impose pas le maintien d'une redondance systématique pendant une maintenance. Beaucoup d'architecture N+1 perdent sciemment leur redondance lors d'une maintenance.
Leon.
-
L'avantage de ce genre d'incident majeur, c'est que ça montre les SPOF (Single Points Of Failure). Certes, de manière un peu brutale, mais au moins, ça incite sérieusement à corriger.
Il y a des SPOF qu'il est impossible de supprimer. Tous les opérateurs mobiles ont un SPOF : le HLR (base de donnée comportant les informations relatives à tout abonné autorisé à utiliser ce réseau et notamment sa localisation dans le réseau)
Bouygues Telecom et Orange ont déjà eu des bug logiciels qui ont presque entièrement paralysée leur réseau mobile... (SFR je ne suis plus sur de moi). Il y a déja eu un "black-out" de 48h en Norvège à cause d'un problème logiciel sur le HLR.
Malgré toutes les redondance matérielle, un bug logicielle va impacter les différentes systèmes. Chez Orange, la fonction HLR est constituée de 27 machines réparties sur 15 sites. La redondance sert à assurer le service en cas de panne matérielle en triplant chaque machine (Stéphane Richard, PDG Orange, devant la Commission de l'assemblée nationale le 12/07/2012).
La vidéo d'Orange suite à la panne du 6 juillet 2012. C'est un exemple de vulgarisation réussi sur un sujet extrêmement complexe :
https://lafibre.info/videos/orange/201207_orange_details_panne_hlr_6_juillet_2012.mp4
-
(SFR je ne suis plus sur de moi)
Aussi mais pas de blackout total (4M clients impactés) sur la période dont je me souviens.
http://www.numerama.com/magazine/30104-sfr-panne.html
-
Attention, N+1 est un niveau de sécurité qui n'impose pas le maintien d'une redondance systématique pendant une maintenance. Beaucoup d'architecture N+1 perdent sciemment leur redondance lors d'une maintenance.
Leon.
Tout a fait je me suis tres mal exprimé, en voulant dire que N+1 est le strict minimum pour avoir une redondance, et effectivement beaucoup prennent le risque de plus avoir de redondance a chaque maintenance. Desolé ;)
-
Il y a des SPOF qu'il est impossible de supprimer. Tous les opérateurs mobiles ont un SPOF : le HLR (base de donnée comportant les informations relatives à tout abonné autorisé à utiliser ce réseau et notamment sa localisation dans le réseau)
Bouygues Telecom et Orange ont déjà eu des bug logiciels qui ont presque entièrement paralysée leur réseau mobile... (SFR je ne suis plus sur de moi). Il y a déja eu un "black-out" de 48h en Norvège à cause d'un problème logiciel sur le HLR.
Malgré toutes les redondance matérielle, un bug logicielle va impacter les différentes systèmes.
Je ne connais pas les HLR, ni la complexité de leur implèmentation, mais les SPOF logiciels peuvent clairement être supprimés!
Ca nécessite beaucoup d'énergie de développement / maintenance, ça coute donc très cher, mais c'est à priori faisable. Et j'en parle un peu ici:
Dans un domaine "très haute disponibilité" que je connais, on pousse le vice jusqu'à éliminer au maximum les "défaillances systématiques" (bugs, erreur de conception), en multipliant les fournisseurs : équipements différents, groupes électrogènes et onduleurs de marques différentes, climatisation, routeurs, switches, serveurs de marques différentes, processeurs différents, et softs totalement redondants mais développés par des équipes différentes, avec des méthodes de conception différentes, avec des compilateurs différents, etc... Ca peut aller très loin.
On impose aussi des langages de programmation différents aux différents softs redondants entre eux.
Il faut que l'interface entre les différents systèmes qui travaillent mutuellement, et qui se surveillent mutuellement soit simple, compréhensible, fiable.
C'est appliqué sur des domaines ultra sensibles : militaire, satellites (un satellite c'est 15 ans sans aucune maintenance physique possible), nucléaire, etc...
Savez-vous si ce genre de développement logiciel ultra redondé est appliqué dans le monde des télécoms? Sur des HLR ou autres?
Leon.
-
Il y a des SPOF qu'il est impossible de supprimer. Tous les opérateurs mobiles ont un SPOF : le HLR (base de donnée comportant les informations relatives à tout abonné autorisé à utiliser ce réseau et notamment sa localisation dans le réseau)
Si je ne me trompe pas, avec plusieurs instances qui dupliquent des données sur plusieurs instances qui se répartissent des ranges de SIM différentes, même s'il est en haut de la hiérarchie géographique c'est pas tant un SPOF qu'un routeur au bout d'une grosse fibre.
D'ailleurs un HLR c'est généralement plusieurs boîtiers à minima, il y a la crypto, les bases de données, le frontend/backend, l'admin... C'est pour ça que les équipementiers ont N acronymes équivalents derrière.
-
C'est un SPOF dans le fait qu'un pb logiciel peut faire tomber l'intégralité du réseau d'un opérateur.
Cf ce qu'il s'est passé avec Bouygues ou Orange en France, mais il y a de nombreux exemples chaque année à travers le monde.
Je ne sais pas si il est possible d'appliquer ce que dit Léon.
Je sais que Bouygues Telecom (a ou a eu) suite à la panne deux HLR de deux marques différentes, mais je me demande si il est possible de passer de l'un à l'autre facilement (le second ne serait là que en cas de pb grave, genre la Norvège avec un "black-out" de 48h.
La restauration d'un HLR a un étant antérieur c'est plusieurs heures, pour avoir 48h de panne, la remise dans un état antérieur n'a pas du suffire. (il me semble que pour Orange comme Bouygues c'est ce qui a été réalisé. Orage aurait commencé la remise dans un état antérieur à 17h20, si je comprends bien la vidéo)
-
Ou alors c'est (un peu) lié...
Pas impossible que la perte des connectivités avec les équipements de Strasbourg ai provoquée le "bug" des équipements optiques de Roubaix.
-
C'est un SPOF dans le fait qu'un pb logiciel peut faire tomber l'intégralité du réseau d'un opérateur.
Ca veut dire que les serveurs HLR n'emploient pas les méthodes de développement soft redondés / safe dont je parle? Si ces serveurs peuvent avoir autant d'impact, c'est assez surprenant.
(On est un peu HS, mais on déplacera si ça prend trop d'ampleur. La discussion est intéressante. )
Leon.
-
Ca veut dire que les serveurs HLR n'emploient pas les méthodes de développement soft redondés / safe dont je parle? Si ces serveurs peuvent avoir autant d'impact, c'est assez surprenant.
« Des langages de programmation différents aux différents softs redondants entre eux » : clairement pas. Un HLR typique c'est plutôt des montagnes de C qui recollent des bases Oracle entre elles, sur du PowerPC/x86/ARM, pour donner un exemple. Ça doit implèmenter des spécifications fleuves de la 3GPP, y compris pour la communication interne et pour ça je pense pas que des équipementiers se payent le luxe de le faire plusieurs fois, surtout pour ce que ça implique niveau interopérabilité.
-
dans tous les cas, bon courage aux équipes... la nuit risque d'être courte, malgré une journée déjà bien chargé...
Comment by OVH - Thursday, 09 November 2017, 22:22PM
Il reste :
- 1160 serveurs dédiés
- 200 instances PCI
- 3000 VPS
- 250 hosts PCC
Les serveurs restants sont concernés par les dysfonctionnements des switchs liés aux tâches ci-après :
http://travaux.ovh.net/?do=details&id=28269
http://travaux.ovh.net/?do=details&id=28268
http://travaux.ovh.net/?do=details&id=28267
http://travaux.ovh.net/?do=details&id=28247
edit:
Il reste :
- 1025 serveurs dédiés
- 150 instances PCI
- 2700 VPS
- 250 hosts PCC
ca continue de se résorber, mais ca semble encore bloqué sur certains points...
-
@vivien : Il me semble avoir également entendu parler d'une panne similaire chez Free, mais il est bien possible que j'aie confondu avec une panne qui n'a rien à voir avec le HLR... ???
Vous vous focalisez sur la panne électrique à SBG, mais de mon point de vue, la perte de l'intégralité du réseau optique de Roubaix (+Gravelines?) est beaucoup plus inquiétante, et impacte infiniment plus de clients.
Leon.
Disons que le titre du sujet a imposé cette focalisation dans l'instant présent de la panne : "Panne électrique majeure chez OVH (sites inacessibles)"
Mais merci ginie d'avoir reposté les tweets d'Octave Klaba.
-
On apprend finalement que le site ne disposait que d'une seule arrivée HTA
https://twitter.com/olesovhcom/status/928766504732119040
-
bon bah on a voulu éviter 2-3millions pour mettre un lien de secours sur des installations que l'on voulait démonter une fois fini d'installer les installations de remplacement... on a serré les fesses mais ca n'a pas suffit... désolé...
-
Intéressant, encore une fois. C'est appréciable autant de transparence. Mais encore une fois, comme le dit Vivien, nous ne saurons jamais tous les détails de ces incidents.
Ici, il parle de l'automate de basculement qui n'a pas fonctionné. Moi pas comprendre. Il n'y a qu'un seul et unique automate non redondant?
Est-ce qu'il faut aussi comprendre qu'il n'y a qu'un seul et unique réseau électrique non redondé à l'intérieur du datacenter de Strasbourg? Nous n'en savons rien, le billet d'Octave ne nous permet pas de le dire.
Octave dit que les containers maritimes sont un problème, mais on ne comprends pas pourquoi, il ne donne pas les détails. C'est forcèment lié à l'incident s'il dit ça, mais nous ne pouvons pas comprendre le pourquoi.
Leon.
-
Saluons le message d'Octave, qui donne une partie des piéces du puzzle pour comprendre comment l'impossible est arrivé.
Je le reprend ici pour mémoire :
Bonjour,
Ce matin à 7h23, nous avons eu une panne majeure sur notre site de Strasbourg (SBG) : une coupure électrique qui a mis dans le noir nos 3 datacentres SBG1, SBG2 et SBG4 durant 3h30. Le pire scénario qui puisse nous arriver.
Le site de SBG est alimenté par une ligne électrique de 20KVA composée de 2 câbles qui délivrent chacun 10MVA. Les 2 câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Électricité Réseaux). Ce matin, l’un des 2 câbles a été endommagé et le disjoncteur a coupé l’alimentation des datacentres.
Le site SBG est prévu pour fonctionner, sans limite de temps, sur les groupes électrogènes. Pour SBG1 et SBG4, nous avons mis en place, un premier système de 2 groupes électrogènes de 2MVA chacun, configurés en N+1 et en 20KV. Pour SBG2, nous avons mis en place 3 groupes en N+1 de 1.4MVA chacun. En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé. En moins de 30 secondes, les datacentres SBG1, SBG2 et SBG4 sont ré-alimentés en 20KV. Pour permettre toutes ces bascules sans couper l’alimentation électrique des serveurs, nous disposons d’onduleurs (UPS) sachant fonctionner sans aucune alimentation durant 8 minutes.
Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate. Il s’agit d’un automate NSM (Normal Secours Motorisé), fournit par l’équipementier des cellules haute-tension 20KV. Nous sommes en contact avec lui, afin de comprendre l’origine de ce dysfonctionnement. C’est toutefois un défaut qui aurait dû être détecté lors des tests périodiques de simulation de défaut sur la source externe. Le dernier test de reprise de SBG sur les groupes date de la fin du mois mai 2017. Durant ce dernier test, nous avons alimenté SBG uniquement à partir des groupes électrogènes durant 8H sans aucun souci et chaque mois nous testons les groupes à vide. Et malgré tout, l’ensemble de ce dispositif n’a pas suffi aujourd’hui pour éviter cette panne.
Vers 10h, nous avons réussi à basculer les cellules manuellement et nous avons recommencé à alimenter le datacentre à partir des groupes électrogènes. Nous avons demandé à ELD de bien vouloir déconnecter le câble défectueux des cellules haute tension et remettre le disjoncteur en marche avec 1 seul des 2 câbles, et donc limité à 10MVA. La manipulation a été effectuée par ELD et le site a été ré-alimenté vers 10h30. Les routeurs de SBG ont été joignables à partir de 10h58.
Depuis, nous travaillons, sur la remise en route des services. Alimenter le site en énergie permet de faire redémarrer les serveurs, mais il reste à remettre en marche les services qui tournent sur les serveurs. C’est pourquoi chaque service revient progressivement depuis 10h58. Notre système de monitoring nous permet de connaitre la liste de serveurs qui ont démarré avec succès et ceux qui ont encore un problème. Nous intervenons sur chacun de ces serveurs pour identifier et résoudre le problème qui l’empêche de redémarrer.
A 7h50, nous avons mis en place une cellule de crise à RBX, où nous avons centralisé les informations et les actions de l’ensemble des équipes. Un camion en partance de RBX a été chargé de pièces de rechange pour SBG. Il est arrivé à destination vers 17h30. Nos équipes locales ont été renforcées par des équipes du datacentre de LIM en Allemagne et de RBX, ils sont tous mobilisés sur place depuis 16H00. Actuellement, plus de 50 techniciens travaillent à SBG pour remettre tous les services en route. Nous préparons les travaux de cette nuit et, si cela était nécessaire, de demain matin.
Prenons du recul. Pour éviter un scénario catastrophe de ce type, durant ces 18 dernières années, OVH a développé des architectures électriques capables de résister à toutes sortes d’incidents électriques. Chaque test, chaque petit défaut, chaque nouvelle idée a enrichi notre expérience, ce qui nous permet de bâtir aujourd’hui des datacentres fiables.
Alors pourquoi cette panne ? Pourquoi SBG n’a pas résisté à une simple coupure électrique d’ELD ? Pourquoi toute l’intelligence que nous avons développée chez OVH, n’a pas permis d’éviter cette panne ?
La réponse rapide : le réseau électrique de SBG a hérité des imperfections de design liées à la faible ambition initialement prévue pour le site.
La réponse longue :
En 2011, nous avons planifié le déploiement de nouveaux datacentres en Europe. Pour tester l’appétence de chaque marché, avec de nouvelles villes et de nouveaux pays, nous avons imaginé une nouvelle technologie de déploiement de datacentres, basée sur les containers maritimes. Grâce à cette technologie, développée en interne, nous avons voulu avoir la souplesse de déployer un datacentre sans les contraintes de temps liées aux permis de construire. A l’origine, nous voulions avoir la possibilité de valider nos hypothèses avant d’investir durablement dans un site.
C’est comme ça que début 2012, nous avons lancé SBG avec un datacentre en containers maritimes : SBG1. Nous avons déployé 8 containers maritimes et SBG1 a été opérationnel en seulement 2 mois. Grâce à ce déploiement ultra rapide, en moins de 6 mois nous avons pu valider que SBG est effectivement un site stratégique pour OVH. Fin 2012, nous avons décidé de construire SBG2 et en 2016, nous avons lancé la construction de SBG3. Ces 2 constructions n’ont pas été faites en containers, mais ont été basées sur notre technologie de « Tour » : la construction de SBG2 a pris 9 mois et SBG3 sera mis en production dans 1 mois. Pour pallier aux problèmes de place début 2013, nous avons construit très rapidement SBG4, l’extension basée encore sur les fameux containers maritimes.
Le problème est qu’en déployant SBG1 avec la technologie basée sur les containers maritimes, nous n’avons pas préparé le site au large scale. Nous avons fait 2 erreurs :
1) nous n’avons pas remis le site SBG aux normes internes qui prévoient 2 arrivées électriques indépendantes de 20KV, comme tous nos sites de DCs qui possèdent plusieurs doubles arrivées électriques. Il s’agit d’un investissement important d’environ 2 à 3 millions d’euros par arrivée électrique, mais nous estimons que cela fait partie de notre norme interne.
2) nous avons construit le réseau électrique de SBG2 en le posant sur le réseau électrique de SBG1, au lieu de les rendre indépendant l’un de l’autre, comme dans tous nos datacentres. Chez OVH, chaque numéro de datacentre veut dire que le réseau électrique est indépendant d’un autre datacentre. Partout sauf sur le site de SBG.
La technologie basée sur les containers maritimes n’a été utilisée que pour construire SBG1 et SBG4. En effet, nous avons réalisé que le datacentre en containers n’est pas adapté aux exigences de notre métier. Avec la vitesse de croissance de SBG, la taille minimale d’un site est forcèment de plusieurs datacentres, et donc d’une capacité totale de 200.000 serveurs. C’est pourquoi, aujourd’hui, pour déployer un nouveau datacenter, nous n’utilisons plus que 2 types de conceptions largement éprouvées et prévues pour le large scale avec de la fiabilité :
1) la construction de tours de 5 à 6 étages (RBX4, SBG2-3, BHS1-2), pour 40.000 serveurs.
2) l’achat des bâtiments (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) pour 40.000 ou 80.000 serveurs.
Même si l’incident de ce matin a été causé par un automate tiers, nous ne pouvons nous dédouaner de la responsabilité de la panne. A cause du déploiement initial basé sur les containers maritimes, nous avons un historique à rattraper sur SBG pour atteindre le même niveau de normes que sur les autres sites d’OVH.
Cet après-midi, nous avons décidé du plan d’actions suivant :
1) la mise en place de la 2ème arrivée électrique, totalement séparée, de 20MVA ;
2) la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, ainsi que la séparation du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4;
3) la migration des clients de SBG1/SBG4 vers SBG3 ;
4) la fermeture de SBG1/SBG4 et la désinstallation des containers maritimes.
Il s’agit d’un plan d’investissement de 4-5 millions d’euros, que nous mettons en route dès demain, et qui, nous l’espérons, nous permettra de restaurer la confiance de nos clients envers SBG et plus largement OVH.
Les équipes sont toujours en train de travailler sur la remise en route des derniers clients impactés. Une fois l’incident clos, nous appliquerons les SLA prévus dans nos contrats.
Nous sommes profondèment désolés pour la panne générée et nous vous remercions des encouragements que vous nous témoignez durant cet incident.
Amicalement
Octave
-
Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate. Il s’agit d’un automate NSM (Normal Secours Motorisé), fournit par l’équipementier des cellules haute-tension 20KV. Nous sommes en contact avec lui, afin de comprendre l’origine de ce dysfonctionnement. C’est toutefois un défaut qui aurait dû être détecté lors des tests périodiques de simulation de défaut sur la source externe. Le dernier test de reprise de SBG sur les groupes date de la fin du mois mai 2017. Durant ce dernier test, nous avons alimenté SBG uniquement à partir des groupes électrogènes durant 8H sans aucun souci et chaque mois nous testons les groupes à vide. Et malgré tout, l’ensemble de ce dispositif n’a pas suffi aujourd’hui pour éviter cette panne.
C'est donc l'automate NSM de l'ATS (Automatic Transfer Switches) qui est en cause.
-
Quelques points m'interpellent dans ce compte-rendu et me surprennent suite aux choix faits dans la réalisation, évolution de DC et que je ne pensais pas voir possible :
Le site de SBG est alimenté par une ligne électrique de 20KVA composée de 2 câbles qui délivrent chacun 10MVA. Les 2 câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Électricité Réseaux) : architecture électrique qui ressemble à du Tier II (il faudrait voir les schémas électriques pour s'en sassurer). Le Tier II implique une maintenance avec coupure....
En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé : cette partie peut-elle être testée lors des tests de maintenance ? Cela imposerait de couper l'alimentation pour être sûr que l'automate, peuvent-ils le faire avec leur architecture ?
Nous avons déployé 8 containers maritimes et SBG1 a été opérationnel en seulement 2 mois. Grâce à ce déploiement ultra rapide, en moins de 6 mois nous avons pu valider que SBG est effectivement un site stratégique pour OVH. : Le choix de containers pour des DCs fait sens du à la rapidité de mise en place, mais les choisir pour qu'ils soient "stratégiques" est un choix rare car la sécurisation électrique et climatique (je parle des groupes froids) d'un container est plus compliqué, le container a pour but un déploiement rapide et un choix de sécurisation faible avec des environnements qui peuvent être coupés et n'ont pas de besoin de redondance forte.
Edit : @Oliviertoto92350 : Non, l'ATS est en aval de ce mécanisme, il ne commande pas le démarrage des groupes mais la bascule d'une source à une autre.
C'est donc l' ATS (Automatic Transfer Switches) qui est en cause.
-
il n'y a que moi qui trouve que 8 minutes c'est très juste comme autonomie de batterie?
si le système automatique a le moindre problème ça ne laisse aucune marge de sécu pour agir manuellement...
limite le tech de garde à a peine le temps d'acquitté l'alarme de défaut que tout est déjà dans le noir...
-
Bien vu, j'avais noté aussi mais je l'avais zappé lors de ma seconde lecture ???.
Tout dépend du temps qu'ils donnent aux GE pour démarrer, si ces derniers démarrent en moins de trois min, les huit minutes sont cohérentes.
Il ne parle pas non plus des impacts sur les machines avec la montée rapide en température du site du à l'arrêt des clims.
-
Oui 8 min c'est cohétants, sachant que les groupes sont préchauffés et stabilisés en qques minutes, et pour des puissances pareilles un plus long temps sur UPS coute une fortune en batteries, qui sont remplacée tous les 3-4 ans, et aussi la place que ca prend..
J'ai vu dans un hosting center plus petit, un temps de 30 minutes, ou les groupes ne sont pas démarrés que apres 10 minutes de coupures, ce qui suffit pour 90% des coupures reseau qui sont brèves.
Maintenant oui, ils donnent vraiment l'impression de "trop serrer les fesses" sur la fiabilité, il y a déja eu leur soucis d'inondation avec leurs raccords de flotte en plastique made in "Brico-jardin" , et maintenant avec leurs alims électrique pseudo redondante, des systèmes de commutations pas testés convenablement.
La tres haute fiabilité coute tres cher, et c'est manifestement pas le créneau de marché qu'ils ont choisit, mais faut le dire plus clairement aux clients.
-
il n'y a que moi qui trouve que 8 minutes c'est très juste comme autonomie de batterie?
si le système automatique a le moindre problème ça ne laisse aucune marge de sécu pour agir manuellement...
limite le tech de garde à a peine le temps d'acquitté l'alarme de défaut que tout est déjà dans le noir...
Pour moi il n'y a pas le temps d'agir en manuel et je ne suis pas sur que d'avoir 20 min d'autonomie change qq chose.
Il faut du personnel formé sur site et si la bascule n'est pas réalisée automatiquement, cela signifie qu'il faut investiguer et comprendre ce qui n'a pas marché pour faire la bonne action. 20 minutes, c'est très court...
Chez OVH, les onduleurs sont tombés en panne de jus à 7h23 => Ils ont basculé manuellement l’alimentation à 10h00 selon octave.
Il fallait 3 h d'autonomie sur batterie pour ne pas avoir de coupure.
Il y aurais eu deux voies (Voie A et Voie B comme dans de nombreux datacenter), il n'y aurais pas eu de pb. Une voie aurait été HS, mais pas la seconde.
Là chez OVH il y a une seule chaîne d'alimentation, et donc un seul automate.
Un schéma avec une redonance :
(https://lafibre.info/images/datacenter/201608_datacenter_delta_airlines.png)
Je remarque qu'il y a pas mal d'ATS qui sont a l'origine de coupure dans les datacenter...
=> Un ATS qui bloque des dizaines de milliers de passagers de Delta Airlines dans le monde entier, pendant 4 jours. (https://lafibre.info/electricite/panne-de-delta-airlines-lanalyse/)
Il y a déjà eu des ATS bloqué (contacts soudés) qui ont mit une pagaille pas possible...
-
les 20minutes d'autonomie peuvent éventuellement permettre de palier à une erreur humaine par exemple.
après je ne connais pas suffisamment bien les différentes procédures liées au groupe électrogène / chaines électriques pour dire si ça pourrait permettre de solutionner certains problèmes simples (genre alimentation en carburant bloquée / bascule automatique qui ne s'est pas déclenchée...)
c'est sur que ça reste très court
pour l'archi en 2N je connais assez (2 groupes sur 2 chaines d'alimentation séparée et deux alimentation edf distinctes)
si un groupe fail de mémoire on a la possibilité de basculer la chaine d'alim sur l'autre groupe pour éviter de couper une voie (vive l'autonomie des batteries :P ).
-
8 minutes ça me semble effectivement très court. Je m'étais fait la même réflexion : c'est trop court pour un rattrapage par un humain.
Surtout qu'on ne sait pas si c'est 8 minutes garanties, y compris batteries en fin de vie, ou alors si c'est 8 minutes "optimistes".
Leon.
-
à vous lire ça ne semble pas très sérieux ce qu'ils ont fait !
et pourtant on nous a toujours présenté ovh comme le summum de la qualité ! :-\
-
et pourtant on nous a toujours présenté ovh comme le summum de la qualité ! :-\
Certainement pas non...
-
Pour moi ce n'est pas du Low Cost, dans le milieu, beaucoup adorent faire payer ultra cher n'importe quoi, donc forcèment, un truc à un prix raisonnable apparait comme low.
OVH c'est des serveurs à prix raisonnable, avec une infrastructure unique et très particulière.
Comme j'aime le dire : "Il n'y a que ceux qui ne tentent rien qui ne font pas de conneries".
Là, ils ont tenté, ils ont perdu, ils vont assumer, et se relever, là ou OVH a du mérite, c'est qu'ils sont totalement transparents.
Pour avoir souvent les versions internes des évenements avant leur publication (genre la baie qui a pris la flotte), j'apprécie que la version publique soit strictement la même, sans tentative de manipulation (certains concurrents devraient s'en inspirer, suivez mon regard).
Bref, Chez OVH il y'a de tout, les serveurs à pas cher sont... pas chers.
Les vrais gros hosts, c'est juste des bons serveurs à bon prix.
-
Bonjour à tous,
Je vous propose un petit éclairage de ce qu'il s'est passé, étant moi même exploitant de datacenter (et j'en ai designer une grosse partie).
Un datacenter, de manière générale, c'est compliqué à exploiter. Entre les contraintes techniques et financières, il faut faire des choix, et en informer le client pour qu'il ai connaissance du risque.
Pour exemple chez nous, l'autonomie des batteries est en moyenne de 10-15 minutes selon les circuits. On dispose d'un transfo sur boucle directement reliée en 20 kVA au dispatch central de l'arrondissement et alimenté directement par la centrale turbien gaz de Bouchain. Temps de coupure assuré par ErDF et EDF : tranche de 1-2h par an. C'est le risque que ces partenaires nous demandent d'accepter. Connaissant Octave, ce risque était connu et assumé, mais pas expliqué aux clients. L'expression "serrer les fesses" était d'usage, surtout avec une mono adduction électrique.
Du coup, pour prendre en compte ce risque, on dispose d'un groupe électrogène de 450 KVA. C'est notre seul rempart contre la coupure totale. Il est révisé tous les trimestres, testé à vide chaque semaine, et testé en conditions réelles chaque mois. Ce test consiste à ouvrir la cellule HTA alimentant le primaire du transformateur. La détection de coupure étant sur le secondaire, l'automate (sur batterie redondée, et à moteur électrique donc) bascule alors la charge en 5 à 10 secondes. En 7 ans d'exploitations, le groupe a été obligé de démarrer automatiquement 5 fois, pour des durées moyennes de 15 mn à 1h30.
Il est arrivé qu'il ne démarre pas une seule fois. Le test a mis en évidence un problème de puissance sur l'une des batterie. L'automate ayant basculé la charge trop tôt, le moteur n'avait pas encore atteint son régime d'utilisation (1500 tr/mn) et il a calé. Il n'a jamais su redémarrer ensuite (batterie vide). Nous avons donc rebasculé immédiatement sur le secteur, changé la batterie, augmenté le temps d'attente avant bascule, et refait le test immédiatement.
Grace à ces règles strictes et imposée à tout le personnel et prestataires, la disponibilité réelle du circuit 400V dans le datacenter a été de 100 % en 7 ans. On a bien quelques onduleurs qui ont lâchés, mais c'est à ce jour la seule cause de coupure électrique.
Tout ça pour dire que ce métier est précis, sérieux, et surtout, il doit être source de franchise envers les clients. Nos produits, on les vends avec cette chaîne électrique. Elle est expliquée sur notre site. Le client sait pourquoi il paye moins cher qu'ailleurs. Si un élèment change et met en péril cette chaine, il doit être corrigé immédiatement, ou expliqué au client.
Dans cette histoire, c'est là, la vraie erreur d'Octave. Des incidents, ça arrive à tout le monde. La loi de Murphy est là pour nous le rappeler. Nous en aurons aussi un jour, et on y est JAMAIS préparé. Vouloir engager un groupe électrogène manuellement en 8 mn, c'est impossible. C'est également impossible en 15 mn. Vous êtes dans un tel état de stress et de pression que vous ne pouvez pas réfléchir dans le bon sens aussi vite. Il faut sortir la check list, et la dérouler, et ça prend un peu de temps. Pas le choix car le risque d'accident grave est là. Un onduleur, ça explose, un transfo aussi, une cellule HTA et un inverseur, ça peut faire de beaux arcs. Il y a danger pour le mec qui y va sous pression. Les check list sont là pour ça, et il vaut mieux parfois laisser un DC s'éteindre en catastrophe, et limiter cette casse, plutôt que de faire une erreur qui empirerais les choses, ou ralentirait le PRA.
Ensuite, concernant les équipements optiques, là c'est clairement un problème de design, et je suis sur à 99.99 % qu'il est lié à Strasbourg. Je sent venir l'explication de la détection de down de Strasbourg qui a surchargé le CPU en calcul de chemin optique, et qui a fini par faire planter les machines. Cisco a aussi clairement merdé sur le sujet, en ayant vendu un produit mal fini à son client. L'erreur est Humaine, mais celle ci aurait par contre pu être évité très facilement en divisant les systèmes optiques sur des châssis totalement différents. 44 waves, ça se split en 22 par système, et Cisco permet ça très très facilement (pour en avoir déjà utilisé). C'est de la fainéantise ou de l'incompétence sur ce sujet. Maintenant que ce SPOF a été vu, il sera corrigé lundi en quelques heures de taf. C'est franchement dommage à ce niveau de moyens d'ingénierie et de finances.
-
Fainéantise et incompétence.
Les deux mots qui résume parfaitement toute notre société actuelle.
Merci caaptusss, pas besoin d'en rajouter :)
-
8 minutes ça me semble effectivement très court.
Il me semble que c'est très classique comme autonomie sur onduleurs.
-
Sauf si c'est le principe même de leur ring WDM :).
Ensuite, concernant les équipements optiques, là c'est clairement un problème de design, et je suis sur à 99.99 % qu'il est lié à Strasbourg. Je sent venir l'explication de la détection de down de Strasbourg qui a surchargé le CPU en calcul de chemin optique, et qui a fini par faire planter les machines. Cisco a aussi clairement merdé sur le sujet, en ayant vendu un produit mal fini à son client. L'erreur est Humaine, mais celle ci aurait par contre pu être évité très facilement en divisant les systèmes optiques sur des châssis totalement différents. 44 waves, ça se split en 22 par système, et Cisco permet ça très très facilement (pour en avoir déjà utilisé). C'est de la fainéantise ou de l'incompétence sur ce sujet. Maintenant que ce SPOF a été vu, il sera corrigé lundi en quelques heures de taf. C'est franchement dommage à ce niveau de moyens d'ingénierie et de finances.
Le concept de ring WDM, ça existe depuis très longtemps. J'avais vu ça il y a 15 ans, donc ça doit être encore plus vieux (à l'époque c'était avec des optiques non configurables par soft, ça explique certainement des choses). Et avec un tel ring bien conçu, si chaque site vital possède bien 2 chassis optiques bien séparés mais quand même reliés entre eux pour y faire transiter toutes les longueurs d'ondes, chacun des chassis optiques étant reliés à des routeurs différents, alors il est clairement possible de faire une archi globale sans aucun SPOF.
Je ne vois vraiment pas comment on peut mettre un SPOF dans une telle archi, j'aimerais bien avoir des détails.
Le gros avantage de ce genre d'archi étant le temps très court de reprise d'une défaillance (centaines de millisecondes maxi), contre plusieurs dizaines de secondes à plusieurs minutes si on fait confiance aux protocoles de routages pour converger.
Pour exemple chez nous, l'autonomie des batteries est en moyenne de 10-15 minutes selon les circuits. On dispose d'un transfo sur boucle directement reliée en 20 kVA au dispatch central de l'arrondissement et alimenté directement par la centrale turbien gaz de Bouchain. Temps de coupure assuré par ErDF et EDF : tranche de 1-2h par an. C'est le risque que ces partenaires nous demandent d'accepter. Connaissant Octave, ce risque était connu et assumé, mais pas expliqué aux clients. L'expression "serrer les fesses" était d'usage, surtout avec une mono adduction électrique.
Du coup, pour prendre en compte ce risque, on dispose d'un groupe électrogène de 450 KVA. C'est notre seul rempart contre la coupure totale. Il est révisé tous les trimestres, testé à vide chaque semaine, et testé en conditions réelles chaque mois. Ce test consiste à ouvrir la cellule HTA alimentant le primaire du transformateur. La détection de coupure étant sur le secondaire, l'automate (sur batterie redondée, et à moteur électrique donc) bascule alors la charge en 5 à 10 secondes. En 7 ans d'exploitations, le groupe a été obligé de démarrer automatiquement 5 fois, pour des durées moyennes de 15 mn à 1h30.
[...]
Grace à ces règles strictes et imposée à tout le personnel et prestataires, la disponibilité réelle du circuit 400V dans le datacenter a été de 100 % en 7 ans. On a bien quelques onduleurs qui ont lâchés, mais c'est à ce jour la seule cause de coupure électrique.
Si je comprends bien, tu te félicites d'une dispo de quasi 100% dans ton datacenter, alors que vous n'avez qu'une seule arrivée électrique et un seul groupe électrogène... Etrange.
Donc vous êtes clairement dans une archi "on serre les fesses et on voit si ça tient", c'est bien ça?
Du coup, comme tu le préconises, est-ce que vous communiquez auprès de vos client sur le (très) faible niveau de redondance de votre chaine d'alimentation électrique, qui semble carrèment plus faible que ce que propose OVH (ou Online), pour qu'ils soient au courant de ce qu'ils achètent?
Leon.
-
Pour moi ce n'est pas du Low Cost, dans le milieu, beaucoup adorent faire payer ultra cher n'importe quoi, donc forcèment, un truc à un prix raisonnable apparait comme low.
OVH a des interconnexions et un réseau propre très important. OVH est interconnecté en direct avec tous les FAI important d'Europe et des Amérique du nord.
=> Sur les interconnexions (peering / transit), on peut donc dire que c'est du haut de gamme. Peu d'hébergeurs au niveau mondial peuvent se targuer d'avoir autant d'interconnexion directe avec les opérateurs.
Coté alimentation électrique, le fait d'avoir des datacenter avec une seule chaîne électrique, c'est rare. Sur ce point là, c'est du low-cost.
Maintenant avec deux chaînes électriques indépendantes pour alimenter les serveurs n'est pas une garantie de ne pas avoir d'incident, même si cela diminue très fortement le risque => Coupure chez Online malgré le niveau de redondance annoncé... (https://lafibre.info/online/coupure-online/)
Sur la climatisation, le fait de ne pas climatiser les serveurs, c'est rare. Sur ce point là, c'est du low-cost.
Après on peut avoir de la redondance sur la climatisation. On a vu que sur TH2, malgré deux chaînes de climatisation théoriquement indépendante, on a eu une coupure de clim => Ptit coup de chaud à Telehouse 2 (https://lafibre.info/telehouse/ptit-coup-de-chaud-a-telehouse-2/)
Sur la protection incendie, là aussi c'est du low-cost chez OVH. Il y a un sujet dédié : OVH et la protection incendie (https://lafibre.info/ovh-datacenter/ovh-et-la-protection-incendie/)
Un autre point important pour un datacenter, c'est la sécurité physique (empêcher les intrusions avec un système d’accès, des portes blindées, de la vidéo surveillance). Je n'ai pas de compétences pour évaluer ce point.
-
Coté alimentation électrique, le fait d'avoir des datacenter avec une seule chaîne électrique, c'est rare. Sur ce point là, c'est du low-cost.
Maintenant avec deux chaînes électriques indépendantes pour alimenter les serveurs n'est pas une garantie de ne pas avoir d'incident, même si cela diminue très fortement le risque => Coupure chez Online malgré le niveau de redondance annoncé... (https://lafibre.info/online/coupure-online/)
A priori, ça n'est valable que pour OVH-Strasbourg.
Sinon, OVH a déjà montré plusieurs fois des gros SPOF dans leur chaine électrique : principalement, j'avais vu des onduleurs montés en SPOF, qui ne se redondent pas les 1 les autres. 1 seul onduleur défaillant peut apparemment provoquer des milliers de serveurs HS.
Je ne sais pas s'ils ont amélioré ça dans les salles plus récentes.
Octave vient de poster les détails sur la partie panne des équipements optiques de Roubaix
http://travaux.ovh.net/?do=details&id=28244
Leon.
-
Ayant travaillé dans la maintenance électrique en milieu médicale et sidérurgique, je trouve assez abérant les délais de réalimentation, ce qui me laisse supposer comme questions : es ce que le personnel d'astreinte connait et est formé à des manoeuvres d'urgences de gestion de l'alimentation ?
On se voit mal, dans un hôpital, dire à un patient la bidoche ouvert "attends crève pas de suite, on a plus de jus pour ton respirateur". Ok je prends un exemple extrème et ces deux secteurs possèdent des équipes dédiés et formés. C'est là qu'il faut peut être travailler pour améliorer la fiabilité électrique, car on est tous tributaire de la panne matériel, même avec une maintenance préventive très sévère.
-
Ayant travaillé dans la maintenance électrique en milieu médicale et sidérurgique, je trouve assez abérant les délais de réalimentation, ce qui me laisse supposer comme questions : es ce que le personnel d'astreinte connait et est formé à des manoeuvres d'urgences de gestion de l'alimentation ?
On se voit mal, dans un hôpital, dire à un patient la bidoche ouvert "attends crève pas de suite, on a plus de jus pour ton respirateur". Ok je prends un exemple extrème et ces deux secteurs possèdent des équipes dédiés et formés. C'est là qu'il faut peut être travailler pour améliorer la fiabilité électrique, car on est tous tributaire de la panne matériel, même avec une maintenance préventive très sévère.
Attention, les équipements à secourir entre un hopital et un datacenter, ça n'est pas du tout la même puissance électrique.
Dans un hopital, c'est plus facile de faire des onduleurs qui tiennent longtemps (1/2h?).
Dans un datacenter, on parle facilement de plusieurs MW.
Bref, tout est une histoire de compromis.
Leon.
-
Et chez OVH, l’automate en cause gérait du 20 000 volts. Ce n'est pas n’importe qui qui va intervenir sur des circuits avec cette tension.
Dans un hôpital, avec du 400v, beaucoup plus de personnes peuvent intervenir sans formation poussée.
-
On se voit mal, dans un hôpital, dire à un patient la bidoche ouvert "attends crève pas de suite, on a plus de jus pour ton respirateur".
Bon faut etre clair, OVH a pris un crénaux "low cost" qui est pas du tout synonyme de "bad-quality", mais simplement "services en moins" et que c'est une demande du marché, et que tu as pas les meme prestations que un service qui coute 5x plus cher, tout comme Easyjet qui vend pas de la mer°°e, et leurs avions se crash pas plus souvent que les autres a ma conaissance, mais ca arrivera surement comme chez OVH...
Quand tu achète une Twingo tu sais que ca coute 10x mois cher que une Mercedes, seulement apres 1000Km tu as le dos en purée dans la 1ere, pas dans la 2eme :) Faut des services pour tous le monde, mais pas faire croire que c'est équivalent pour moins cher.
La haute disponiblité a un prix exponentiel , pour passer de 99% a 99.9% ca multiplie le prix par 10x, a 99.99% c'est 100x.
Le reproche est que OVH fait passer ses service equivalent a ceux vendu beaucoup plus cher, mais pas sans raisons, tout comme Free qui te fait croire qu'ils font la meme chose que Orange pour moitié prix....
Donc tu choisis ton service en fonction de tes besoins, mais meme si OVH fait des beaux communiqués de presse pour expliquer qu'il font la meme chose que les plus cher, c'est loin d'etre le cas, c'est financièrement impossible, mais faut etre honete dans la description des services, ce qui est pas le cas.
-
A priori, ça n'est valable que pour OVH-Strasbourg.
Il y a deux voies sur Roubaix ?
Les serveur haut de gamme ont deux alimentations ?
Les serveurs moyen de gamme sont connecté à un commutateur de transfert automatique dans la baie qui est connecté sur Voie A et voie B ?
Serveurs moyen de gamme chez Online avec double alimentation : (pour Dell, ce type de serveur R230 / R330 est même de l'entrée de gamme)
(https://lafibre.info/images/datacenter/201509_online_dc3_salle3_13.jpg)
Commutateur de transfert automatique pour connecter des équipements avec une seule alimentation comme les switchs ou les serveurs entrée de gamme :
(https://lafibre.info/images/datacenter/201509_online_dc3_salle3_14.jpg)
-
Je ne suis pas spécialement dans ce domaine, mais généralement tu prends un serveur tu regardes les SLA et surtout l'indemnisation si le SLA n'est pas respecté non ?
OVH est relativement clair là dessus. c'est 5 % de "réduction sur la facture" par heure et maximal 100 % dans le mois.
https://www.ovh.com/fr/serveurs_dedies/sla.xml (le lien est "donné" avant dès la 2eme ou 3eme étape de la commande.)
Si tu veux être sur et certain que celà marche 100 % du temps tu prends une société qui s'engage à plus en cas d'indisponibilité non ?
Après dans le débrief d'Octave, il explique aussi que c'est de leur faute si les routeurs ont perdu la database car ils n'ont pas appliqué la mise à jour de Cisco 10.7 qui est sorti le mois dernier. Est-ce un délai normal ou pas pour la mise à jour d'un routeur "critique" dans l'installation ...
-
Et chez OVH, l’automate en cause gérait du 20 000 volts. Ce n'est pas n’importe qui qui va intervenir sur des circuits avec cette tension.
Dans un hôpital, avec du 400v, beaucoup plus de personnes peuvent intervenir sans formation poussée.
Justement non Vivien, on ne fait pas de basculement d'alim sur du 400 en milieu hospitalier pour différentes raisons, on agit bien plus haut en HT. A Lille, la distri HT interne est à 15kV, pour une puissance d'une dizaine de MVA. Les secteurs très critiques ont des onduleurs d'une autonomie de 1h.
-
Je ne suis pas spécialement dans ce domaine, mais généralement tu prends un serveur tu regardes les SLA et surtout l'indemnisation si le SLA n'est pas respecté non ?
Tout a fait seulment payer des indémnités pour un SLA pas respecté peuvent couter tres cher (je l'ai vécu pour un operateur GSM), ca arrive une fois tous les 5 ans, et ca reste bien moins cher que une "very hight relability" qui coute 100x plus cher...
Le management regardent que les feuilles excell c'est rouge ou vert
Tu peux faire les meilleurs propositions que tu veux en temps que spécialiste ou on t'a demandé de faire un design, finalement c'est un financier qui signe les PO.
J'ai aussi eu un cas ou un UPS a betement pris feux, il était a 95% de charge depuis plusieurs mois, j'ai bien expliqué que avec 30 serveurs de plus chaques mois dans 2 mois ca serait mort, ben aucune réaction, il a fallu que une capa de filtrage contenant plusieurs litres d'huile prenne feux, panne générale dans tout le DC du a la coupure generale automatique incendie, declanchement des Sprinclair (https://fr.wikipedia.org/wiki/Extincteur_automatique_%C3%A0_eau) déversant de la flotte sur plusieurs serveurs, un faiseaux de fibre SAN et cable LAN fondu.
J'ai les photos, je vais les rerouver pour le fun :D
-
Il y a deux voies sur Roubaix ?
Je suis quasiment sur que oui. Il y a très longtemps, lors de la création puis de l'extension d'OVH RBX, Octave en avait parlé: Roubaix est raccordé au réseau ERDF 20 000V de manière redondante. Comme beaucoup de datacenters.
Leon.
-
Je pense aussi qu'il y a au moins deux lignes 20 000 v distinctes sur Roubaix.
Je suis intéressé pour comprendre à quel niveau sur Roubaix il n'y a plus de redondance électrique (vu que les serveurs n'ont pas de double alim)
-
Je suis intéressé pour comprendre à quel niveau sur Roubaix il n'y a plus de redondance électrique (vu que les serveurs n'ont pas de double alim)
Les hauts de gamme, si :)
-
Donc c'est qu'ils ont deux voies de bout en bout. Je me suis trompé.
-
Et tous les gros "hosts" bien costaud pour le cloud (public ou privé) sont en double alim chez OVH.
Pareil pour les filers.
Leon.
-
Ouverture de la liaison aérienne Roubaix-Strasbourg par OVH !
https://twitter.com/olesovhcom/status/929654854267625472
;D
La société a ouvert son porte-feuille pour le coup.
-
Sympa les photos du matériel électrique, on peut un peu mieux comprendre du coup.
-
Gouverner c'est prévoir 8)
Cela semble ne pas être le cas :-\
-
Ouverture de la liaison aérienne Roubaix-Strasbourg par OVH !
https://twitter.com/olesovhcom/status/929654854267625472
;D
La société a ouvert son porte-feuille pour le coup.
Le coût de 2 avions est ridicule par rapport à celui de la panne.
-
8 minutes ça me semble effectivement très court. Je m'étais fait la même réflexion : c'est trop court pour un rattrapage par un humain.
Surtout qu'on ne sait pas si c'est 8 minutes garanties, y compris batteries en fin de vie, ou alors si c'est 8 minutes "optimistes".
Leon.
8 min ça doit être le résultat d'une réflexion du genre "si on a pas basculé en 8 min c'est qu'il y a grosse couil... qui va prendre bien plus longtemps"
-
Bon on ne va pas dire qu'on s'est bien marré mais presque :), le seul problème c'est nos clients qui ont une partie de leur infra chez OVH qui nous ont appelé !!!!
-
Attention Lionel, sinon on ressort l'incident électrique majeur que tu as vécu il y a quelques années avec la perte de tes 2 onduleurs censés être redondants.
Leon.
-
Mais je ne crains pas la discussion :)
Si vous voulez en parler, je vais vous dire le fond de ma pensée (en ces quelques lignes...) après ces quelques années de gestion d'un DC.
1: La maintenance : ça craint, tous nos incidents (impactant la production ou pas) trouvent leur source dans la maintenance (incompétence/incompréhension) ou le mensonge (par omission bien entendu) des vendeurs/sous-traitants!
2: Les tests : ils servent.... Je sais c'est dur de l'entendre, mais sans test on ne peut pas être sur que l'infra tient. Les effets de bord étant généralement sous-estimés, les tests permettent de vérifier ce qui peut advenir lors de vrai panne. Soit l'équipe est prête, soit tu pleures.
3: Pour relativiser notre "petit" incident de moins d'une seconde ( 1 seconde sans elect = 1mn sans service si tes serveurs/switchs sont performants..)
Je parle de performance comme étant dans ce cas : le retour de service après coupure électrique en moins de une minute. Si 1 switch, 1 routeur ou 1 serveur met 30m pour reprendre son service il y a une conséquence de panne électrique qui est très impactant. Certes cela est très rare mais cela existe.
4: Le "0" panne n'existe pas car l'humain existe, je sais c'est moche mais c'est la vie :(
5: Il faut vivre (donc vendre) un produit ou il existe des concurrents qui utilisent aussi le mensonge (par omission bien entendu).
6: Dans le cas de cette panne d'OVH (ce n'est pas la première et ce ne sera pas la dernière car financièrement l'équation est mauvaise), que garantisse-t-il ? du 99.9% ou moins ?
Sur cette année il serait sur du Tier 2(!) (mais pas que cette année) https://www.ovh.com/fr/serveurs_dedies/comprendre-t3-t4.xml et ce n'est pas par ce que tu cries haut et fort que tu es le plus fort que tu l'es! Les chiffres sont là, ils parlent d'eux même. Le jour ou on pourra tuer tous les escrocs qui font "Prendre des vessies pour des lanternes" le monde ira mieux (mais on n'a pas le droit :( )
Donc il faut par conception définir ce qui peut et doit être "secouru" par un autre biais que les dépendances d'un constructeur, d'un mainteneur, ou d'un intervenant.
En résumé si quelqu'un fait une connerie, il ne faut pas que ce soit impactant, il faut rendre les services indépendant les uns des autres et si possible prévoir des doubles commandes partout ou cela est possible... et superviser tout le système tout le temps.
Cela demande un gros travail que peu d'intégrateur réalisent par soucis d'économie, donc si tu payes pas cher, tu en as pour ton prix et ce n'est pas que le matériel qui coute!
-
Une grosse partie des datacenter qui ont plus de 10ans d’exploitation ont eu des coupures sur les deux voies et/ou problèmes de climatisation.
Dans le cas d'OVH, cela a eu des impacts assez importants, bien au-delà des sites hébergés chez OVH, car les sites ont de plus en plus d'éléments hébergés en externe et certains étaient chez OVH.
Le jour où Google aura une panne globale, on verra bien qu'ils hébergent de nombreuses parties de sites (scripts, polices de caractère, publicité, bouton Google+,...)
Exemple : Pendant la panne OVH, impossible de faire un test de débit nPerf, quel que soit le serveur, et même les nPerf hébergés par des entreprises hors du site https://www.nperf.com/fr/
Voici les stats du serveur de nPerf de Massy: on voit la perte total de trafic le 9 novembre
(https://lafibre.info/images/stats/201711_nperf_trafic.png)
Inversement, on voit un pic sur SpeedTest en mode http port 80, j'imagine que c'est Speedtest-cli (https://lafibre.info/tester-son-debit/speedtest-cli/) démarré depuis des serveurs Linux ou autre hypothèse OVH est utilisé par SpeedTest pour faire des valider que le port 8080 ce qui a entraîné un fall-back sur le port 80 :
(https://lafibre.info/images/stats/201711_speedtest_apache_accesses.png)
-
Pour répondre à Vivien,
sur énormèment de site, les liens pointent vers des serveurs hébergés par google et je pense que cela représente au moins 90% des sites web.
Il faudrait faire des stats là-dessus, car la prochaine grosse panne sera celle de google.
-
3: Pour relativiser notre "petit" incident de moins d'une seconde ( 1 seconde sans elect = 1mn sans service si tes serveurs/switchs sont performants..)
Je parle de performance comme étant dans ce cas : le retour de service après coupure électrique en moins de une minute. Si 1 switch, 1 routeur ou 1 serveur met 30m pour reprendre son service il y a une conséquence de panne électrique qui est très impactant. Certes cela est très rare mais cela existe.
Je ne connais pas beaucoup de serveurs qui redémarrent en 1 minute. Sans compter les problèmes de disque dur et de corruption de RAID en cas de coupure franche.
5: Il faut vivre (donc vendre) un produit ou il existe des concurrents qui utilisent aussi le mensonge (par omission bien entendu).
Pour moi, tu fais partie des opérateurs de datacenter qui mentent. Notamment avec ton Tier-4 (by Lionel Drevon)
D'ailleurs, si tu pouvais nous expliquer ton délire, cette "certification by Adeli", stp. Perso, je n'ai toujours pas compris si c'était du second degré pour se moquer de l'uptime institute ou autre chose.
6: Dans le cas de cette panne d'OVH (ce n'est pas la première et ce ne sera pas la dernière car financièrement l'équation est mauvaise), que garantisse-t-il ? du 99.9% ou moins ?
Sur cette année il serait sur du Tier 2(!) (mais pas que cette année) https://www.ovh.com/fr/serveurs_dedies/comprendre-t3-t4.xml et ce n'est pas par ce que tu cries haut et fort que tu es le plus fort que tu l'es! Les chiffres sont là, ils parlent d'eux même. Le jour ou on pourra tuer tous les escrocs qui font "Prendre des vessies pour des lanternes" le monde ira mieux (mais on n'a pas le droit :( )
J'ai du mal à comprendre comment un opérateur officiel de datacenter (toi) te permet de traiter ouvertement OVH d'escroc. C'est facilement attaquable pour diffamation, non? Nous sommes sur un forum "peu fréquenté", donc OVH ne t'attaqueras pas, mais quand même, ça n'est pas une raison pour manquer de respect, gratuitement, sans explication, à tes concurrents.
Donc il faut par conception définir ce qui peut et doit être "secouru" par un autre biais que les dépendances d'un constructeur, d'un mainteneur, ou d'un intervenant.
En résumé si quelqu'un fait une connerie, il ne faut pas que ce soit impactant, il faut rendre les services indépendant les uns des autres et si possible prévoir des doubles commandes partout ou cela est possible... et superviser tout le système tout le temps.
Et donc là dessus, tu es meilleur que les autres? Si oui, pourquoi? N'hésites pas à nous expliquer.
C'est pas toi qui a eu de gros problèmes de routage pendant plusieurs jours en IPv6? Je sais que ça n'a rien à voir, mais ça fait partie de la qualité de service globale.
Leon.
-
Je ne connais pas beaucoup de serveurs qui redémarrent en 1 minute. Sans compter les problèmes de disque dur et de corruption de RAID en cas de coupure franche.
En fait moi non plus, meme un laptop ne redémarre pas eu une minute...
Alors un serveur UNIX qui crash c'est 15 minutes de reboot, et si dessus tu as une DB Oracle c'est minimum 1 heures de recovery ;)
Et pour les discs, une salle de 500 serveurs, c'est au minimum une 10ene de disc a remplacer apres un powerfail, souvent sans conséquences car c'est en RAID, mais les degats sont la, sur des machines qui tournes des années sans le moindre arret, ce genre de truc est fatal...
J'ai trouvé un server HP-UX avec 2100 jours de uptime sans reboot dans un DC, un record :D
-
Nous sommes sur un forum "peu fréquenté", donc OVH ne t'attaqueras pas...
Je le croyais aussi... Jusqu'à mon audience en cour d'appel où on me fout un de mes posts lafibre.info sous le pif en me demandant de m'expliquer dessus.
Donc croyez-moi, il y a beaucoup plus de monde qu'on ne le croit ici ;)
-
En fait moi non plus, meme un laptop ne redémarre pas eu une minute...
J'ai trouvé un server HP-UX avec 2100 jours de uptime sans reboot dans un DC, un record :D
On en a qui reboot en moins d'une minute et il est vrai qu'on en a d'autre qui reboot en 5mn!
Je vous ferai une vidéo. (promis)
Le raid au reboot on s'en fout (à part si un disque est mort et c'est un autre sujet), ton serveur est censé redémarrer en mode bancal sinon c'est un mauvais choix de carte/serveur.
Le seul "point" c'est le système de fichier donc exit le ext2/3/4 qui te demande de valider le check...
Si ton serveur ne supporte pas le reboot hard c'est qu'il est trop vieux et que si cela impact ta prod tu vires le DSI (ou tu te mets des baffes si tu n'as personne à "violenter" sous la main)
A chaque pbm une solution
-
Tu as raison, mais il faut pas oublier que le matos Tres Haute Dispo, comme les bays de disc SAN Hitachi, les HP aussi, les EMC je sais pas, ca se reboot JAMAIS, sauf en cas de déménagement ou arret definitif...
Il y a une procédure de shudown a respecter, assez longue, pour pouvoir la redemarer sans crash, dans le cas que je cite, "Emergency power OFF", tu coupe le jus dans toute la salle, UPS, diesel inclus, (c'est une exigence des assurances), et je t'assure que tu peux plus la redemarrer, faut faire venir l'ingénieur de support pour suivre une procédure tres complexe qui prend plusieurs heures.
joli! ;D
ne pas mettre le champignon trop proche des portes la prochaine fois + gros panneau rouge clignotant ne pas toucher ^^
Ben ca servi de lecon, le champignon est maintenant dans une box ou faut casser la vitre pour appuyer dessus, et autre dommage colatéral, le serveur qui gère les badges d'acces / controle empreinte etait mort, donc impossible de quitter ou entrer dans le DC , ils ont mis une clé pour ouverture manuelle a coté du champignon, ca aurais pu etre dramatique si c'était l'extinction Co2 qui se déclanchée et que le gas peux plus sortir ;D
-
Il y a les pros, les vrais et les baltringues, escrocs, voyous etc.
Un DC ne doit jamais être down (sauf déménagement et encore les routeurs de re-reroutage vers nouveau site non durant 2 mois).
C'est depuis que certains l'on été que c'est devenu normal et que ça passe comme fait divers.
Tout les serveurs et switch/routeurs de collecte ont mini une double alimentation qui doit être sécurisée sur des onduleurs différents et redondants en N+2.
L'alimentation de secours par générateur intervient dès que les onduleurs N+1 sont en passe de basculer sur N+2.
Un hébergement sécurisé pour sites sensibles doit être en auto replication dans un autre site avec un re-routage par 2 liens différents et activé automatiquement en cas de saut des onduleurs N+1.
En cas d'incendie, la salle doit être évacué et le feu étouffé selon les normes par dispersion de gaz à privation d'oxygène et en aucun cas une coupure électrique ne doit s'effectuer de l'intérieur de la salle et sans avis d'un professionnel du feu.
Et je ne parle pas de la séparation de l'alimentation électrique et réseau du système de gestion de l'infrastructure du bâtiment entier (générateur et onduleurs inclus).
Alors oui ça coûte de l'argent mais un professionnel ne mange pas du riz à vie parce qu'il propose de l'hébergement de cette qualité.
-
Ben ca servi de lecon, le champignon est maintenant dans une box ou faut casser la vitre pour appuyer dessus, et autre dommage colatéral, le serveur qui gère les badges d'acces / controle empreinte etait mort, donc impossible de quitter ou entrer dans le DC , ils ont mis une clé pour ouverture manuelle a coté du champignon, ca aurais pu etre dramatique si c'était l'extinction Co2 qui se déclanchée et que le gas peux plus sortir ;D
Il faut badger pour sortir de la salle ? C'est pas illégal si il n'y a pas de sortie de secours ?
Je n'ai jamais vu ça sauf certains datacenter équipé de sans unipersonnel. Tu badge en entrée en et en sortie, cela permet d'être sur que tu ne prête pas ton badge pour faire rentrer une seconde personne (car il est impossible de rentrer tant que tu n'est pas sorti)
3Dans ces cas là, il y a bien sur une sorite d'urgence via une porte, située a coté du sas unipersonnel. Tu actionne la porte par un bouton poussoir en cas d'urgence et la sécurité est prévenue.
-
Les règles de l'art sont au Archives Nationale ;D
-
Ben c'est le cas , en entrée tu badge et tu mets ton index sur le detecteur, en sortie seuelement le badge (RFID) , et c'est pas une porte mais un sas, qui en plus controle le poid (pour pas que tu passe a deux dans le sas), alors si tu as un gros carton CISCO de 30 Kg tu es pas dans la merde... faut demander au garde de t'ouvrir le sas.
Meme les assenseurs te laisse aller que la l'étage ou tu as les droits sur ton badge.
Le systeme compte les entrées et sorties, si tu entre et tu passe ton badge a un autre, ben ca marche pas, pas la bonne emprinte, et considéreé comme a l'intérieur... T'as la sécurité qui te tombe dessus.
Maintenant , il a bien sur une sortie de secour, (c'est une obligation) avec poignée plombée (comme les compteur EDF) , mais si tu sort par la tu fais hurler l'alarme du batiment, donc jamais personne s'y risque, et en plus tu peux plus etre identififé pour re-entrer par le sas.
Je supose que chez OVH ca doit etre plus "light", comme la redondance ;)
mais les prix sont pas les meme...
Et pour cerains clients qui loue des salles, les racks tres sensble sont verouillés par électroaiment, il faut l'authorisation de l'IT manager de la société pour y acceder, ca peux prendre 2 heures avant que tu arrive a la fibre que tu dois remplacer,
Mais bon quand c'est de secret de fabrications qui sont sur les serveurs, ca se comprend, et tu ressort pas avec un disque mort, il reste dans la salle et est détruit par une equipe qui fait ca.
-
Nouvel incident, de nombreux liens sont down sur TH2 :
-
Quel est l'impact en dehors de la weathermap ?
-
Nouvel incident, de nombreux liens sont down sur TH2 :
http://travaux.ovh.net/?do=details&id=28391
Bisous :)
-
Voici un nouveau compte rendu encore plus détaillé de la part d'OVH vsur l'incident majeur de Strasbourg.
http://travaux.ovh.net/?do=details&id=28247
Ce que je retiens:
* L'automate inverseur de source, qui démarre aussi les groupes (?), était dans un mode défaut. Or, ce mode défaut aurait du être remonté, et détecté. Est-ce qu'il était en défaut avant l'incident? L'histoire ne le dit pas.
* Ce même automate n'est apparemment pas redondé. C'est difficilement compréhensible pour moi. C'est "assez facile" de redonder un automate au moins pour la partie "démarrage d'un groupe électrogène". L'ordre de démarrage d'un groupe, c'est en général simplement la fermeture d'un relais, donc facile à redonder.
* L'inverseur de source HT est-il lui même redondé? Peut-être pas, difficile à dire. Il y a 1 seul ou plusieurs bus-bar HT? Pareil, pas de détails.
* Un des groupes électrogènes était en maintenance, inutilisable. Et on comprend avec tout le reste, que la redondance des groupes n'était plus assurée. C'est malheureusement assez classique : beaucoup de datacenter en N+1 perdent la redondance lors de maintenance. Dans les datacenter critiques que je connais avec une telle archi N+1, on fait impérativement venir un groupe électrogène mobile provisoire (20 tonnes le bébé), en cas de grosse maintenance qui immobilise un groupe électrogène. De plus, certaines maintenances sont réalisables "à chaud", sans désactiver le groupe. Pareil pour les grosses maintenances de transfo, on remplace le transfo par un groupe électrogène.
* Les 2 groupes électrogènes HT n'ont pas réussi à se synchroniser (en HT), on n'a pas plus de détail.
* Le mélange entre une partie de l'architecture électrique en HT (20 000V) et l'autre en BT (380V) me semble assez tordu. Il y a des groupes HT et d'autres BT. Je ne comprends pas l'intérêt, mais c'est sans doute des choix techniques "historiques" qui ont amené à cette situation bizarre. Il est fort possible que le réseau HT interne constitue un SPOF, mais nous n'avons pas les détails.
* Les temps de rétablissement des différents services me paraissent très longs. 10h après que l'alimentation électrique soit revenue, beaucoup de services sont encore HS (20% des vCenters du private cloud). Mais je ne suis pas du métier, donc difficile de juger.
En tout cas, bravo à OVH pour la transparence.
Leon.
-
On a beaucoup parlé de l’ordre de démarrage des groupes haute tension (HT) qui n’avait pas été envoyé par l’automate pilotant l’inverseur. En fait il aurait l'envoyé l'ordre cela n'aurait rien changé ! Même panne pour la même durée, vu qu'en lés démarrant manuellement, ils n'ont pas réussi à faire passer le datacenter sur groupe.
Comme les 2 groupes électrogènes HT ne sont pas parvenus à se synchroniser, nous avons alors découplé les 2 groupes électrogènes HT pour les faire fonctionner séparèment. Un groupe seul délivrant uniquement 2MVA ne peut tenir la charge demandée et il s’arrête. Nous avons effectué de multiples essais dans différentes configurations, sans succès.
Si j'ai bien compris, Les 2 groupes électrogènes HT (20 000 volts) protègent les 3 datanceter de Strasbourg (SBG1, SBG4 et SBG2).
Par contre seul SBG2 a une protection N+1 avec deux groupes électrogènes 380 volts. L’un de ces 2 groupes BT était en « mode maintenance », donc cette sécurité n'a pas pu être utilisée.
Je suis aussi étonné que l'altération d’un des 2 câbles souterrains 20 000 volts d’Électricité de Strasbourg Réseau (ESR) ait été réparée si vite (a 10h39, ESR rétablit l’alimentation secteur, permettant la remise en service des 3 datacenter). Je n'ose pas imaginer si la panne avait durée plusieurs jours...
Sinon, oui, il faut féliciter OVH pour la transparence.
PS : J'ai séparé le HS dans un sujet à part Application des patchs de sécurité sous Linux (https://lafibre.info/serveur-linux/application-patchs-de-securite/)
-
Le texte complet :
Bonjour,
Voici le post-mortem de l'incident.
Le jeudi 9 novembre, à 7 h 04, le site de Strasbourg, hébergeant 4 datacentres, a été privé d’énergie. Malgré toutes les sécurisations mises en place, la coupure électrique s’est propagée dans les datacentres et a provoqué un arrêt électrique de 40 386 serveurs hébergés sur le site.
À 10 h 39 le site a été réalimenté, puis les services ont progressivement redémarré. A 18 h 00, 71 % des serveurs étaient fonctionnels, et le vendredi 10 novembre à 23 heures, 99 % des serveurs étaient fonctionnels. Une minorité de services a été affecté jusqu’au dimanche 12 novembre.
Déroulé de l’incident en temps réel (jeudi 9 novembre) :
----------------------------------------------------------
7h04:07 : disjonction du côté d’Électricité de Strasbourg Réseau (ESR) et perte de l’alimentation électrique des deux lignes.
7h04:17 : les groupes électrogènes haute tension (HT) ne démarrent pas.
7h12:48 : l’onduleur 6 (UPS) arrive en fin d’autonomie batterie.
7h15:48 : l’onduleur 5 arrive en fin d’autonomie batterie.
7h17:25 : l’onduleur 2 arrive en fin d’autonomie batterie.
7h18:00 : les premières tentatives manuelles de redémarrage des groupes HT ont échoué.
7h18:39 : l’onduleur 1 arrive en fin d’autonomie batterie.
7h19:19 : l’onduleur 4 arrive en fin d’autonomie batterie.
7h21:00 : l’onduleur 3 arrive lui aussi en fin d’autonomie batterie.
7h21:00 : les salles de routage ne sont plus alimentées électriquement.
7h21:03 : nouvelle tentative manuelles de démarrage du groupe HT numéro 1.
7h22:42 : nouvelle tentative manuelles de démarrage du groupe HT numéro 2.
7h30 : la cellule de crise locale est opérationnelle.
7h50 : la cellule de crise centrale au siège de Roubaix est opérationnelle.
Entre 7h50 et 10h39 : multiples tentatives manuelles de redémarrage des groupes électrogènes accompagnées par nos experts en génie électrique.
10h39 : ESR rétablit l’alimentation secteur.
10h58 : les routeurs sont de nouveau joignables.
11h : les interventions sur les serveurs le nécessitant sont en cours.
14h : arrivée d’une première équipe renfort
16h : des renforts venus de nos sites de Francfort (Allemagne) et de Roubaix arrivent.
17h30 : un camion de 38 tonnes rempli de pièces détachées arrive sur place.
22h : 97 % des serveurs fonctionnent, 91 % répondent au ping.
Quelle est la cause de la disjonction côté ESR ?
------------------------------------------------
L’ensemble du site est alimenté par 1 alimentation électrique de 20MVA réalisée avec 2 câbles de 20kV. La cause de la disjonction est liée à une altération d’un des 2 câbles souterrains, qu’ESR a réparé rapidement. Les causes de l’altération de ce câble ne sont pas encore déterminées à date. Des investigations sont en cours par ESR.
Pourquoi la perte d’un câble a entraîné une coupure d’alimentation ?
--------------------------------------------------------------------
Le site de Strasbourg est alimenté par deux câbles délivrant 20MVA et donc connectés sur le même disjoncteur. Le déclenchement du disjoncteur a entraîné la coupure des deux lignes.
Pourquoi les générateurs haute tension ne se sont-ils pas mis en route ?
------------------------------------------------------------------------
SBG1 et SBG4 sont alimentés par 2 groupes électrogènes (HT), de 2MVA chacun, qui prennent le relais en cas de coupure électrique. L’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas démarré les groupes électrogènes.
Après investigation, nous avons constaté que l’ordre de démarrage des groupes haute tension (HT) n’avait pas été envoyé par l’automate pilotant l’inverseur.
Le fabriquant de cet automate est venu l’expertiser. Il s’avère qu’il était bloqué en défaut « automatisme verrouillé », ce qui explique l’absence de démarrage des groupes HT. Des investigations sont en cours pour comprendre l’origine de ce blocage.
L’équipe d’intervention du fabricant a remis l’automate en état de fonctionnement normal. Nous n’avons pour l’instant pas d’explication à cette erreur. En l’attente des conclusions, nous assurons la permanence en roulement d’une personne dédiée 24 heures/24 et 7 J/7 afin d’être en mesure de forcer la bascule manuellement pour parer à un éventuel nouveau défaut de l’automate.
Dans les prochains jours, nous allons réaliser le test en charge du site ce qui nous permettra de valider le bon fonctionnement de l’automate.
Pourquoi les tentatives de démarrage des groupes HT ont-elles échoué ?
----------------------------------------------------------------------
Le datacentre SBG2 est alimenté avec 2 groupes électrogènes BT de 1.4MVA chacun. L’un de ces 2 groupes BT était en « mode maintenance ». En « mode maintenance », dans le cas d’une coupure électrique, les 2 groupes électrogènes HT de SBG1 fournissent l’énergie à SBG2, à la place du groupe électrogènes BT en maintenance.
Jeudi le 9 novembre, lorsque que le site a été privé d’énergie, l’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas donné l’ordre de démarrage aux groupes HT.
Nous avons donc procédé à des tentatives de démarrage manuelles.
Pour faire fonctionner la charge électrique de SBG1, SBG4 et SBG2 avec l’un des deux groupes BT en « mode maintenance », il faut absolument que les 2 groupes HT fonctionnent ensemble afin de fournir 4MVA. Comme les 2 groupes électrogènes HT ne sont pas parvenus à se synchroniser, nous avons alors découplé les 2 groupes électrogènes HT pour les faire fonctionner séparèment. Un groupe seul délivrant uniquement 2MVA ne peut tenir la charge demandée et il s’arrête. Nous avons effectué de multiples essais dans différentes configurations, sans succès.
Combien de temps a-t-il fallu pour rétablir les services ?
----------------------------------------------------------
Des moyens exceptionnels ont été mis en place afin de rétablir au plus vite les services.
État des lieux général :
------------------------
Jeudi à 22 heures, 97 % des serveurs (hardware) étaient de nouveau fonctionnels ainsi que 91 % des services (software). Vendredi à minuit, 99 % des serveurs étaient de nouveau opérationnels ainsi que 96,2 % des services.
Dans le détail :
Private Cloud :
----------------
Jeudi 9 novembre
· 23h : 78,59% des vCenters opérationnels
Vendredi 10 novembre
· 5h : 100% des vCenters opérationnels
Object Storage/Cloud Archive :
-------------------------------
Jeudi 9 novembre, 13h35 : 100 % opérationnel
PCS :
-----
Jeudi 9 novembre, 13h35 : PCS/PCA 100% opérationnel
PCI/VPS* : (*zoning PCI : les « régions PCI » ont une nomenclature différente de celle des datacenters)
------------------------
11h30 : API est UP sur le région SBG1/SBG2/SBG3
17h : 98% instances OK région SBG3
20h00 : 98% instances OK région SBG1
21h00 : 92% instances OK région SBG2
Vendredi 10/11
16h00 : 100% instances OK région SBG1
16h30 : 100% instances OK région SBG2
Samedi 11/11
18h : 100% instances OK région SBG3
SD :
----
Jeudi 9/11
21h : 93,05% des serveurs dédiés sont opérationnels
Vendredi 10/11
17h : 99,1% des serveurs dédiés sont opérationnels
Comment avez-vous géré la situation ?
--------------------------------------
Dès 7 h 50, une cellule de crise est activée à Roubaix afin de coordonner toutes les actions des équipes. Octave Klaba, le CEO et fondateur d’OVH, rend compte de l’évolution de la situation en temps réel, via les réseaux sociaux. Des explications détaillées sont aussi fournies sur la tâche travaux.
En parallèle, les équipes support françaises s’organisent avec leurs homologues québécoises pour répondre à un maximum de sollicitations. Les clients Grands Comptes concernés sont contactés afin de leur apporter des solutions rapides et concrètes.
À Strasbourg, les équipes datacentres sont vite renforcées par des techniciens venus de nos centres de données allemands (Francfort) et français (Roubaix). Un véritable pont routier et ferroviaire est mis en place. Vers 17 h 30, un camion de 38 tonnes provenant du centre logistique d’OVH en métropole lilloise, leur apporte toutes les ressources matérielles additionnelles nécessaires pour les heures à venir. Plusieurs camions arriveront les jours suivants, suite à la mise en place d’une astreinte logistique à Roubaix.
Ces équipes ont ainsi travaillé sans relâche, nuit et jour, pour rétablir les services de tous les clients, allant jusqu’à justifier l’organisation et la mise en place d’un pont aérien entre Lille et Strasbourg afin d’accélérer les rotations des équipes présentes sur place durant le week-end et toute la semaine.
Quel est le plan d’action mis en place suite à cet évènement ?
---------------------------------------------------------------
Comme évoqué précédemment, nous avons immédiatement pris des mesures pour proscrire ce type d’incident à Strasbourg (SBG) ainsi que sur l’ensemble de nos sites.
Ce plan d’actions va se déployer en 2 phases.
À court terme
-------------
Nous avons demandé un rapport détaillé au fournisseur de l’automate.
Puisque le basculement de l’automate normal/secours motorisé n’a pas fonctionné, nous avons une présence dédiée 24 heures sur 24 et 7 jours sur 7, afin de pouvoir réaliser manuellement la manœuvre en cas de non-fonctionnement de l’automatisme. Cette astreinte sécurise le site en attendant qu’un test en charge puisse confirmer le bon fonctionnement de l’automate.
Pour la partie inverseur normal/secours, nous allons rapidement remplacer la partie automatisme par un automate « maison », qui nous permettra d’en maîtriser complètement le fonctionnement et de le monitorer. Un système identique est déjà en production à Gravelines.
Nous avons demandé un rapport détaillé à ESR concernant l’origine de l’avarie.
Une étude de faisabilité concernant le raccord d’une deuxième arrivée électrique de 20MVA est également lancée. En attendant, nous avons lancé une 2eme étude : la mise en place de 2 disjoncteurs isolés, un par câble, ce qui permettrait de secourir un éventuel défaut sur l’un des 2 câbles.
Nous allons effectuer la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4 ainsi que la séparation du futur SBG3, vis-à-vis de SBG2 et SBG1/SBG4. De cette manière, chaque datacentre disposera de son alimentation de secours indépendante.
Un audit électrique est également en cours pour l’ensemble de nos sites.
À noter : à l’heure actuelle, lorsqu’un serveur est commandé sur le site de Strasbourg, il apparaît par défaut au sein de l’espace client comme hébergé au sein de SBG1, même s’il est hébergé à SBG2 ou SBG4. C’est un bug d’affichage. Cette anomalie sera corrigée très rapidement afin de laisser apparaître le datacentre réel au sein duquel le serveur est hébergé.
À long terme
------------
La technologie basée sur les containers maritimes ne sera plus utilisée par OVH. En effet, elle n’a été utilisée que pour construire SBG1 et SBG4, et hérite des imperfections de design liées à la faible ambition initialement prévue pour le site. Aujourd’hui, nous réalisons qu’elle n’est plus adaptée aux exigences de notre métier et aux normes OVH. Nous allons donc démanteler SBG1 et SBG4.
Pour cela, une migration de l’ensemble des services de nos clients hébergés sur SBG1 et SBG4 sera opérée vers SBG2 et SBG3 ou sur d’autres datacentres OVH.
Nous sommes sincèrement désolés pour cette panne et nous faisons le nécessaire afin que ce type d'incident ne se reproduise plus.
Amicalement
Octave
-
Je suis aussi étonné que l'altération d’un des 2 câbles souterrains 20 000 volts d’Électricité de Strasbourg Réseau (ESR) ait été réparée si vite (a 10h39, ESR rétablit l’alimentation secteur, permettant la remise en service des 3 datacenter). Je n'ose pas imaginer si la panne avait durée plusieurs jours...
En fait, le câble n'a été réparé que 4 jours après.
Le rétablissement de 10h39 consiste simplement à isoler le câble défectueux, via une simple manipulation de sectionneurs sans doute, côté ESR, et côté OVH.
Toute la puissance peut apparemment passer par 1 seul jeu de câble tri phasé 20 000V.
Peut-être que le poste d'OVH est dans une boucle 20 000V dont les 2 bouts sont reliés au même poste haute tension côté ESR.
Les boucles 20 000V dans le réseau de distribution, c'est une architecture très courante pour pouvoir assurer un minimum de redondance sur le réseau, et surtout de "maintenabilité à chaud".
Et clairement, OVH a bel et bien avoué qu'ils n'avaient pas de redondance sur leur raccordement au réseau ESR.
https://twitter.com/olesovhcom/status/928559286288093184
SBG: ERDF repared 1 line 20KV. the second is still down. All Gens are UP. 2 routing rooms coming UP. SBG2 will be UP in 15-20min (boot time). SBG1/SBG4: 1h-2h
01:46 - 9 nov. 2017
https://twitter.com/olesovhcom/status/930351049889722368
#Ovh EU-Central (Strasbourg,FR): the external source (20MVA) was broken here, it's fixed.
00:25 - 14 nov. 2017
Leon.
-
Et ces câbles n'ont pas été posés pour OVH : OVH Strasbourg s'est installé sur une friche industrielle qui nécessitait beaucoup d'électricité.
Le site étant à proximité des fibres du backbone d'OVH (qui passait par Strasbourg avant la mise en place d'un DC sur Strasbourg)
-
Rappelons qu'à la base, SBG devait être le PRA de RBX :)
-
pour info, suite à la panne de Strasbourg, il y a eut des dégats sur des serveurs qui ont nécessité une intervention physique à postériori en fin de semaine.
Donc, encore une coupure de 30 minutes, planifié cette fois (même si à la dernière minute, genre on vous coupe dans 3 heures, ca vous va ?) pour changer des pièces (officiellement en rapport avec le refroidissement du cpu)
-
Nous avons désormais un retour détaillé sur la 2ieme panne majeure du 9 novembre, la coupure totale des interconnexions réseau à partir du site de Roubaix, le plus gros datacenter d'OVH en France.
https://www.ovh.com/fr/blog/retour-experience-incident-reseau-9-novembre-2017-site-de-roubaix/
(Google Cache si ça plante)
Je ne connais pas le domaine des réseaux télécom longue distance, mais je suis très surpris : on a ici un seul équipement optique "master" qui configure tous les équipements du site de Roubaix. Donc les équipements redondants ne sont clairement pas indépendants les uns des autres. J'ai beaucoup de mal à comprendre. Une simple erreur humaine de configuration pourrait aboutir au même problème, non?
Quelqu'un peut-il nous expliquer ce que font les processeurs de ces cartes de supervision?
Juste surveiller ce que remontent chacune des différentes cartes? Les puissances optiques observées, le taux d'erreur, et c'est tout?
Tout ça actualisé, disons toutes les 10ms?
Même pour une centaine de longueurs d'ondes redondantes, ça représente une toute petite charge CPU, on est bien d'accord?
Qu'est-ce que ces cartes de supervision permettent de configurer?
* les différentes longueur d'onde de chacun des transpondeurs?
* les atténuateurs, les amplis, les modules de compensation de dispersion?
* les switches optiques assurant la redondance?
Pourquoi centraliser ainsi la configuration des équipements? Ne peut-on pas créer des boucles optiques longue distance, où chaque noeud est totalement indépendant des autres, et réagit seulement aux coupures? Genre je ne vois plus Paris par la fibre Ouest, donc je regarde Paris par la porte Sud...
Pourquoi tous ces équipements ne sont-ils pas indépendants les uns des autres?
OK, la remontée d'informations depuis les différentes cartes / modules, c'est pratique et ça n'introduit aucun SPOF si c'est bien isolé.
Mais la configuration par un seul équipement central, c'est contraire aux règles de redondance! C'est limite choquant!
Dans des installations industrielles ultra redondantes/disponibles que je connais, on s'assure que chaque "automate" a une autonomie de décision, donc qu'il est isolé des autres automates redondants, donc non influençable par les bugs des autres (même s'ils s'échangent des informations simples entre eux pour se surveiller mutuellement).
Dans le cas de boucles optiques WDM redondantes que j'avais eu la chance de voir il y a 15 ans, tout était réalisé avec des équipements séparés, indépendant. Tout était configuré à la main (ajout d'atténuateurs, module laser spécifique pour chaque longueur d'onde). J'imagine bien que ça n'est plus forcèment possible quand on parle de 80 longueurs d'ondes différentes, et de chassis optiques denses (quoi que pour Cisco ça n'est pas si dense).
Mais il y a certainement un compromis à trouver entre
1) l'automatisation de la config qui rajoute un SPOF
2) système complexe à configurer (quasi manuellement) mais hautement redondant une fois qu'il est bien configuré
J'avais déjà vu ce genre de blagues (SPOF "logique") pour des onduleurs industriels, qui étaient censés être redondants, et qui étaient pourtant tous reliés à un seul réseau d'information logique et propriétaire, qui constituait un SPOF.
Leon.
-
Dans le cas de boucles optiques WDM redondantes que j'avais eu la chance de voir il y a 15 ans, tout était réalisé avec des équipements séparés, indépendant. Tout était configuré à la main (ajout d'atténuateurs, module laser spécifique pour chaque longueur d'onde). J'imagine bien que ça n'est plus forcèment possible quand on parle de 80 longueurs d'ondes différentes, et de chassis optiques denses (quoi que pour Cisco ça n'est pas si dense).
Mais il y a certainement un compromis à trouver entre
1) l'automatisation de la config qui rajoute un SPOF
2) système complexe à configurer (quasi manuellement) mais hautement redondant une fois qu'il est bien configuré
En 15 ans sa a totalement changé.
Première chose, l'automatisation n'est jamais un SPOF, une configuration manuelle: Oui.
Imagine plutot tes TMS comme des "controlleur", elle "juste" push la configuration sur tes équipements.
Là le "controlleur" a "buggé" et il a envoyé des "vider" la conf.
On ne veut plus utiliser cette façon de faire d'il y a 15 ans. Car c'est beaucoups trop cher et moins fiable.
Ex tu as: tu as deux fibre entre roubaix et paris, deux entre paris et strasbourg.
Si tu veux connecter un lien entre roubaix et strasbourg tu ne va pas vouloir recabler à Paris, donc tu es obligé d'avoir un "management" centralisé et imagine quand ton lien de backup fait roubaix, bruxelles, francfort, strasbourg, ...
-
Première chose, l'automatisation n'est jamais un SPOF, une configuration manuelle: Oui.
Imagine plutot tes TMS comme des "controlleur", elle "juste" push la configuration sur tes équipements.
Là le "controlleur" a "buggé" et il a envoyé des "vider" la conf.
C'est assez contradictoire, ce que tu me dis. Ici, c'est bien l'automatisme qui a été un SPOF, et je trouve ça complètement anormal.
On ne veut plus utiliser cette façon de faire d'il y a 15 ans. Car c'est beaucoups trop cher et moins fiable.
Ex tu as: tu as deux fibre entre roubaix et paris, deux entre paris et strasbourg.
Si tu veux connecter un lien entre roubaix et strasbourg tu ne va pas vouloir recabler à Paris, donc tu es obligé d'avoir un "management" centralisé et imagine quand ton lien de backup fait roubaix, bruxelles, francfort, strasbourg, ...
Faire tout ça avec une gestion centralisée non redondée, je trouve ça clairement suicidaire. On est d'accord que OVH ne rajoute pas une route optique tous les jours ni même toutes les semaines, loin de là.
Je pense vraiment que ce monde de l'informatique et des télécoms a beaucoup à apprendre du monde des industries ultra sensibles et hautement disponibles: sidérurgie, nucléaire, ferroviaire, aéronautique, spatial.
Leon.
-
Je pense vraiment que ce monde de l'informatique et des télécoms a beaucoup à apprendre du monde des industries ultra sensibles et hautement disponibles: sidérurgie, nucléaire, ferroviaire, aéronautique, spatial.
Leon.
Mais c'est pas une question d'apprendre, c'est un choix économique ;)
Le meme circuit integré coute 0.02$ dsns un TV, et 1000$ dans un satellite ou un missile...
Simplement car on demande pas la meme fiabilité, et le cout pour passer de 99.0% de fiabilité a 99.9% te mutltilplie le prix par par 2x mais par 500X.
-
Le meme circuit integré coute 0.02$ dsns un TV, et 1000$ dans un satellite ou un missile...
Simplement car on demande pas la meme fiabilité, et le cout pour passer de 99.0% de fiabilité a 99.9% te mutltilplie le prix par par 2x mais par 500X.
Où est le rapport avec l'incident d'OVH dont on parle ici, qui est dû exclusivement à un problème de conception? Problème de conception visiblement partagé entre Cisco et OVH... Ca n'est pas un problème de prix de composants, mais de conception d'architecture de systèmes complexes redondant hautement disponibles.
Leon.
-
Le raport est que OVH a choisi un créneau "low cost" qui est une demande du marché, maintenant su tu es une banque et que tu as un serveur qui gère 5000 distributeur de billet, ben tu choisis un hebergeur ou le prix a rien a voir, mais par contre tu auras pas ce genre d'incident vu que ca sera répliqué sur plusieurs sites.
-
Le raport est que OVH a choisi un créneau "low cost" qui est une demande du marché, maintenant su tu es une banque et que tu as un serveur qui gère 5000 distributeur de billet, ben tu choisis un hebergeur ou le prix a rien a voir, mais par contre tu auras pas ce genre d'incident vu que ca sera répliqué sur plusieurs sites.
Que les experts savent que OVH est middle/low cost est un fait
Mais la plupart des clients doivent croire que c'est le prix du marché pour une parfaite fiabilité.
Le jour où Google ou Amazon vont avoir un soucis, beaucoup de clients vont déchanter du all wonderfull cloud sans précautions
-
Le raport est que OVH a choisi un créneau "low cost" qui est une demande du marché, maintenant su tu es une banque et que tu as un serveur qui gère 5000 distributeur de billet, ben tu choisis un hebergeur ou le prix a rien a voir, mais par contre tu auras pas ce genre d'incident vu que ca sera répliqué sur plusieurs sites.
Mais où est le rapport avec la choucroute?
OVH fourni principalement des serveurs dédiés et des serveurs virtuels... Dans ce cas, c'est bien le client qui choisi la réplication sur plusieurs sites, voire sur plusieurs fournisseurs (Amazon, Online, etc...). Ca n'est pas OVH!
Et ça tombe bien, OVH fourni ses offres sur plusieurs sites permettant cette réplication : Gravelines et Roubaix principalement.
Encore une fois, on ne parle pas du tout de ça ici. Ici, le problème montré du doigt, c'est une architecture de réseau de télécommunication avec un SPOF. Et ce réseau n'est clairement pas "low cost"! C'est juste qu'il n'est pas bien conçu. Concevoir un réseau vraiment redondant ne couterai à priori pas plus cher, tout est déjà là : les fibres, les équipements optiques totalement doublés. Il faudrait juste isoler un peu plus les équipements entre eux. Voir créer plusieurs boucles optiques indépendantes les unes des autres.
Leon.
-
J'avais déjà vu ce genre de blagues (SPOF "logique") pour des onduleurs industriels, qui étaient censés être redondants, et qui étaient pourtant tous reliés à un seul réseau d'information logique et propriétaire, qui constituait un SPOF.
Autre exemple que j'ai déja vu : les climatisations qui sont toutes gérées par le même automate : l'automate est tombé et la clim du site est intégralement tombée.
Les clim ont été basculée en mode indépendante après 2h de coupure. La température était passée de 20 à 40°c.
Je me demande l’intérêt d'avoir un automate pour les clim, c'est assez simple et cela marche bien quand elles sont indépendantes les unes des autres. Cela ne dois pas être souvent que la température cible est changée.
Peut-être que l'automate peut éviter l'effet yoyo de la température observée dans certain datacenter.
-
ca couterait bien plus cher à maintenir ... en temps homme (bcp plus ;) (toutes les confs à faire en double à minima)
tu veux redonder encore plus ? tu prends 2 technos/constructeurs distincts et là paf, tu doubles la gestion de bugs ... (la gestion des fournisseurs aussi, car oui ca prend du temps aussi)
faut être réaliste, ils ont fait au plus simple "ils ont pris le truc all-in-one vendu par cisco" et ils font fait (trop) confiance.
tout est question de mesure risque/prix/qualité, mais ces choix sont mûrements réfléchis (mais pas assumés à mon humble avis comme l'élec de SBG...)
perso, j'ai pas de boucle niveau 1, c'est un choix que j'ai fait et que j'assume (j'estime qu'on fait au moins aussi bien en niveau 3 de nos jours, avec des trucs plus simples à comprendre ,coucou bfd, que de l'optique où tu maitrises pas grand chose au truc proprio ...)
*MAIS* j'ai un seul revendeur et c'est le même matos sur mes différentes liaisons, suis-je à l'abri du bug de "tiens ca va planter à 20h44 le 22 décembre parce que cette date là elle fait chier ADVA" , non sans doute pas, mais c'est un risque assumé, il faut bien se fixer une limite à un moment ...
Mik
-
C'est clair que la tres haute dispo coute tres cher, tu peux accepter des solution boiteuses comme mettre 4 groupes Caterpilar dans le meme garage, sachant que si un prend feux les 3 autres te servent plus a rien, de meme pour les acces fibres un coup pelteuse malheureux et tes 3 fournisseurs seront inutilisable si c'est le meme bundle de fibre, donc on met des adductions a l'opposé du batiment, pareil pour les alims.
OVH vise pas ce crénaux de clients qui reste une minorités, des sites comme Interoute Geneva GVA-004 le font, avec ceinture et bretelles, on peut voir meme des links de backup par satellite.
Safehost aussi que je connais bien offre ce genre de prestations, mais pas aux prix OVH...
-
ca couterait bien plus cher à maintenir ... en temps homme (bcp plus ;) (toutes les confs à faire en double à minima)
C'est si long à configurer, ce genre d'équipements? On est d'accord qu'on parle seulement de plusieurs dizaines de liens 100Gbps. C'est très peu! Ca me parait plutôt simple comme exercice, surtout que tu ne changes pas ces liens toutes les semaines...
Au premier abord, je vois beaucoup moins de trucs à gérer sur ce type d'équipements que sur un gros routeur qui gère des centaines de sessions BGP avec des peers et des centaines de milliers de routes.
Je dis ça, mais je ne m'y connais pas.
Pour une entreprise de la taille d'OVH, avec des milliers de salariés, c'est vraiment si difficile que ça à gérer?
perso, j'ai pas de boucle niveau 1, c'est un choix que j'ai fait et que j'assume (j'estime qu'on fait au moins aussi bien en niveau 3 de nos jours, avec des trucs plus simples à comprendre ,coucou bfd, que de l'optique où tu maitrises pas grand chose au truc proprio ...)
Après, le réseau d'Online n'est présent (allumé par vous mêmes) que sur un MAN parisien avec des liens de quelques dizaines de km. OVH autour de Roubaix, c'est un réseau qui couvre une grosse partie de l'Europe.
Donc ça peut sans doute expliquer ces choix différents.
Les risques de coupure de fibres sont beaucoup plus élevés pour des liens de plusieurs centaines/milliers de km.
Même si je te l'accorde, @AlertePelleteuz aime bien la région parisienne dense.
*MAIS* j'ai un seul revendeur et c'est le même matos sur mes différentes liaisons, suis-je à l'abri du bug de "tiens ca va planter à 20h44 le 22 décembre parce que cette date là elle fait chier ADVA" , non sans doute pas, mais c'est un risque assumé, il faut bien se fixer une limite à un moment ...
Ca veut dire que tu as définitivement mis à la casse les chassis optiques CISCO que tu installais il y a seulement 1 an 1/2?
https://twitter.com/mmarcha/status/691567750100164608
OVH vise pas ce crénaux de clients qui reste une minorités, des sites comme Interoute Geneva GVA-004 le font, avec ceinture et bretelles, on peut voir meme des links de backup par satellite.
Le backup par V-Sat, c'est ce qu'on a encore chez nous, dans ma grosse multinationale. C'est utilisé pour le backup dernier recours pour les flux financiers, ordres de production, commandes, etc...
Mais je crois qu'on va arrêter bientôt, et remplacer ça exclusivement par du backup "3 opérateurs différents, 3 chemins optiques différents" (uniquement pour ces flux ultra sensibles).
Leon.
-
C'est clair que la tres haute dispo coute tres cher, tu peux accepter des solution boiteuses comme mettre 4 groupes Caterpilar dans le meme garage, sachant que si un prend feux les 3 autres te servent plus a rien, de meme pour les acces fibres un coup pelteuse malheureux et tes 3 fournisseurs seront inutilisable si c'est le meme bundle de fibre, donc on met des adductions a l'opposé du batiment, pareil pour les alims.
OVH vise pas ce crénaux de clients qui reste une minorités, des sites comme Interoute Geneva GVA-004 le font, avec ceinture et bretelles, on peut voir meme des links de backup par satellite.
Safehost aussi que je connais bien offre ce genre de prestations, mais pas aux prix OVH...
Enfin backup sat, en attendant les satellites de classe hts en production, ça devient compliqué question bande passante.
J'ai utilisé une fois un transpondeur complet, j'avais 185Mb/s utilisable.
On va pas secourir des agrégats de 100Gb avec...
-
Ca veut dire que tu as définitivement mis à la casse les chassis optiques CISCO que tu installais il y a seulement 1 an 1/2?
https://twitter.com/mmarcha/status/691567750100164608
Le pros confirmeront mais à priori ADVA ça se monte sur du chassis Cisco.
-
Le pros confirmeront mais à priori ADVA ça se monte sur du chassis Cisco.
Euh, tu es sur? Les chassis ne se ressemblent pas trop.
OK, les équipements présentés récemment par mikmak, c'est de l'ADVA, mais c'est tout... Mais je n'ai aucun doute sur le fait que les différentes cartes présentées par mikmak il y a plus d'1 an 1/2, c'était des cartes CISCO.
Sur cette photo de début d'année, on voit un chassis ADVA et un chassis CISCO l'un au dessus de l'autre.
https://twitter.com/mmarcha/status/839379194731720705
Leon.
-
on a utilisé du cisco pour du x*10g entre DC3 et TH2 mais on n'a pas reconduit ce matériel pour DC2<->TH2<->DC5 et DC3<->DC4<->DC5
on va éteindre la partie cisco prochainement
et non ca marche pas "ensemble", ca peut se partager une fibre, mais c'est très complexe à setup
Mik
-
Enfin backup sat, en attendant les satellites de classe hts en production, ça devient compliqué question bande passante.
J'ai utilisé une fois un transpondeur complet, j'avais 185Mb/s utilisable.
On va pas secourir des agrégats de 100Gb avec...
On est tous d'accord! Dans ma grosse multinationale, ce qui est secouru par V-Sat, c'est uniquement des flux financiers et des ordres de production, des commandes. Bref, ce qui est ultra critique car peut faire perdre beaucoup d'argent.
Tout ça prend très très peu de bande passante, quelques dizaines de Mbps. Ca passe très bien sur du V-Sat.
Le backbone français de cette même multinationale, tous flux confondus, c'est plusieurs dizaines de Gbps.
Leon.
-
Quand vous êtes une grande surface, il est très important de sécuriser les flux d’autorisation carte bleu.
C'est quelques Kb/s, mais le blocage coûte cher (et cela bloque même les autres moyen de paiments, car les caisses sont bloquées par des personnes qui attendent que le paiement CB revienne)
Certains magasins, en plus d'une sécurisation type Fibre + SDSL ont une troisième sécurisation via un faisceau hertzien. Si la chambre telecom de la grande surface est endommagée et coupe la fibre et cuivre sont coupés, le FH prend le relais. Une sécurisation par la 4G est aussi possible, il fut par contre faire attention que la collecte de l'antenne 4G ne passe pas par la même chambre.
-
Euh, tu es sur? Les chassis ne se ressemblent pas trop.
Confusion de ma part, pas forcèment trop bien éclaircie dans ma tête d'ailleurs, je pensais que la partie "optique" était distincte de la partie "routage" mais se montait sur le même châssis (dans ma tête la partie "routage" ne faisait qu'un avec le châssis d'ailleurs).
Edit : Je pense que j'ai confondu les chassis WDM et leurs modules optiques avec les modules optiques (cartes ?) qui se montent sur les routeurs.
-
Confusion de ma part, pas forcèment trop bien éclaircie dans ma tête d'ailleurs, je pensais que la partie "optique" était distincte de la partie "routage" mais se montait sur le même châssis (dans ma tête la partie "routage" ne faisait qu'un avec le châssis d'ailleurs).
En fait, la plupart du temps (mais pas toujours), sur les gros réseaux, on sépare les routeurs des équipements optiques longue distance. Sachant qu'en plus, sur un même POP, tu peux avoir plusieurs étages de routeur : des routeurs de coeur et des routeurs de bordure (pour l'interconnexion avec les peers et clients).
Les équipements optiques longue distance, c'est des gros chassis. Ca permet de mettre en forme le signal optique avec une modulation avancée, de faire la détection/correction d'erreur (FEC), de sélectionner la bonne longueur d'onde, de multiplexer tout ça, d'amplifier le signal optique, de gérer la compensation de dispersion chromatique, ça intègre des atténuateurs optiques réglables, etc...
Ces équipements optiques proposent aussi d'agréger plusieurs liens côté "liaison locale" (1 ou 10Gbps par exemple) vers un seul signal de plus haut débit (100 ou 200 ou 400Gbps).
Beaucoup de ces équipements utilisent le standard "OTN" sur les liens longue distance. Mais il existe aussi des solutions 100% propriétaires pour assurer l'agrégation et le transport.
Tout ça dans des équipements hautement configurables, et c'est bien là le problème.
Mais normalement, à l'intérieur d'un lien, l'équipement ne regarde pas, ne modifie pas le contenu. Donc c'est très différent d'un routeur.
Du coup, on appelle ça du "layer 1" : sur un réseau optique réalisé avec des dizaines de ce type d'équipements répartis sur tout un continent (par exemple), tu crées des liens "transparents" à 1Gbps, 10Gbps, 40Gbps ou 100Gbps (dans le cas de l'Ethernet). Ces liens sont "transparents", le signal est transporté d'un bout à l'autre du réseau sans modification, entre 2 "ports clients" éloignés de plusieurs centaines de km.
Les plus gros systèmes permettent de transporter une 10aine de Tbps sur une seule paire de fibres.
Les équipementiers, c'est ADVA, CIENA, Infinera, et Cisco avec sa gamme "ONS". J'en oublie certainement.
Quand tu utilises ce type d'équipements optiques longue distance, alors tes liens locaux entre ton équipement optique et tes routeurs sont réalisés avec des modules standard : SFP, SFP+, QSPF, etc... On parle de "ports clients" et de "cartes clients" sur ces équipements optiques.
Les équipementiers essayent bien de proposer des solutions hybrides : des chassis optiques qui font aussi du routage (de manière perfectible)... Ou alors des gros routeurs Cisco qui sont équipés de cartes optiques complexes pour la longue distance.
Mais j'ai l'impression que ça ne prends pas trop.
Leon.
-
Les équipements DWDM haut de gamme sont capable de changer la destination d'une longueur d'onde sans intervention physique.
Si tu a un site avec 3 fibres vers 3 destinations, l'équipement est capable de changer de chemin une longueur d'onde sans la faire sortir du DWDM (donc sans conversion électrique). Il est aussi possible de ré-affecter des 100 Gb/s d'un équipement vers un autre sans intervention.
Les DWDM récents sont aussi en mesure de faire plus de 1000 km sans devoir régénérer le signal en le faisant sortir (conversion optique => électrique) et re-renter (conversion électrique => optique)
C'est un sujet où il y a eu beaucoup de progrès.
-
Que les experts savent que OVH est middle/low cost est un fait
Mais la plupart des clients doivent croire que c'est le prix du marché pour une parfaite fiabilité.
Le jour où Google ou Amazon vont avoir un soucis, beaucoup de clients vont déchanter du all wonderfull cloud sans précautions
Bonjour
Je suis ce thread avec grand intérêt, et je pense que tu soulève un point interesant, par essence le cloud ne garantie pas une disponibilité de ressources en 'local' ( un serveur peu tombé mais un autre sera dispo qq part). Et donc les applications doivent etre pensees pour le cloud de maniere a etre distribuees et resilientes. Et au vu du nombre de sites down lors du problème chez OVH pas tout le monde a encore pris conscience du probleme.
-
Je suis ce thread avec grand intérêt, et je pense que tu soulève un point interesant, par essence le cloud ne garantie pas une disponibilité de ressources en 'local' ( un serveur peu tombé mais un autre sera dispo qq part).
Voilà, c'est ce que j'essayais d'expliquer à miky01 : Cloud ou pas, si tu veux une vraie redondance entre plusieurs datacenter, il faut gérer tout ça au niveau "applicatif" dans la très grande majorité des cas. Donc c'est bien au client (ou à la SSII) de gérer ça, et d'acheter du cloud (ou serveurs dédiés) réparti dans plusieurs datacenters (proches si possible).
Il existe bel et bien des services où la redondance entre sites se fait un cran au dessous, au niveau de la couche de virtualisation et au niveau du stockage; avec redémarrage automatique de machines virtuelles sur site de secours, avec des disques synchronisés sur plusieurs sites. Mais ce genre de prestation est très cher!
La redondance au niveau applicatif est beaucoup plus efficace en général, et bouffe beaucoup moins de ressource (réseau principalement).
Et donc les applications doivent etre pensees pour le cloud de maniere a etre distribuees et resilientes. Et au vu du nombre de sites down lors du problème chez OVH pas tout le monde a encore pris conscience du probleme.
Assurer une une continuité de service lors de la perte d'un gros datacenter entier, ça peut couter très cher, s'il faut dédoubler quasiment tout sur plusieurs sites (quoi qu'on n'est pas obligé d'assurer la même qualité de service pendant l'incident).
Beaucoup de sites web n'ont tout simplement pas les moyens de le faire! Et ça n'est pas forcèment si grave que ça en fait...
OK, certains très gros sites web font un peu trop confiance à un seul prestataire. Pareil, certaines grandes entreprises migrent leurs serveurs internes vers des clouds type OVH en ne faisant pas attention au risque sur la disponibilité.
Mais ce genre d'événement reste rare. Une coupure de 2h sur une année, même en pleine journée, beaucoup de sites web peuvent se le permettre.
Leon.
-
Mais le cloud type Amazon/Google est redondé bien plus sérieusement que celui d'Ovh non?
C'est à dire que je vois le cloud Amazon/Google redondé avec des caches répartis sur différents sites, reliés par différentes boucles, contrairement à celui d'Ovh qui redonde uniquement sur site. Enfin c'est ma façon de voir les choses. Peut être que je me trompe après.
Pi sincèrement, outre la redondance machine uniquement, ils ont vraiment pas eu de chance sur ce coup là, 3 groupes qui lâchent en même temps, c'est vraiment la faute à pas de chance (bien qu'une couche supplèmentaire de redondance machine aurait changé la donne, mais bon, ça n'a plus de sens à force. Rajouter un groupe sur chaque groupe, on a pas fini...)
(Désolé si ça parait méchant pour Ovh, c'est pas le cas, je ne suis pas pour ou contre eux)
-
Il existe bel et bien des services où la redondance entre sites se fait un cran au dessous, au niveau de la couche de virtualisation et au niveau du stockage; avec redémarrage automatique de machines virtuelles sur site de secours, avec des disques synchronisés sur plusieurs sites. Mais ce genre de prestation est très cher!
La redondance au niveau applicatif est beaucoup plus efficace en général, et bouffe beaucoup moins de ressource (réseau principalement).
Assurer une une continuité de service lors de la perte d'un gros datacenter entier, ça peut couter très cher, s'il faut dédoubler quasiment tout sur plusieurs sites (quoi qu'on n'est pas obligé d'assurer la même qualité de service pendant l'incident).
Beaucoup de sites web n'ont tout simplement pas les moyens de le faire! Et ça n'est pas forcèment si grave que ça en fait...
OK, certains très gros sites web font un peu trop confiance à un seul prestataire. Pareil, certaines grandes entreprises migrent leurs serveurs internes vers des clouds type OVH en ne faisant pas attention au risque sur la disponibilité.
Leon.
Leon
Je suis d'accord que pour beaucoup de cas le manque à gagne est peu etre moins important que le re design de l'applicatif en 'mode cloud'.
Par contre si l'applicatif est designé des le depart pour en tenir compte je ne pense pas ce le cout soit beaucoup plus cher. Aujourd'hui des techno comme les microservice , s'executant sur des architecture de type cluster docker avec un ochestrateur ont le vent en poupe et ne coute pas forcement plus cher a exploiter.
Mais ce genre d'événement reste rare. Une coupure de 2h sur une année, même en pleine journée, beaucoup de sites web peuvent se le permettre.
-
Mais le cloud type Amazon/Google est redondé bien plus sérieusement que celui d'Ovh non?
C'est à dire que je vois le cloud Amazon/Google redondé avec des caches répartis sur différents sites, reliés par différentes boucles, contrairement à celui d'Ovh qui redonde uniquement sur site. Enfin c'est ma façon de voir les choses. Peut être que je me trompe après.
Je ne suis vraiment pas sur... Amazon a eu plusieurs gros incident majeurs, qui ont à chaque fois rendu indisponible de très nombreuses machines pendant plusieurs heures... Quand tu achètes un VPS à Amazon, tu choisis la "zone géographique". Et à ma connaissance, dans plusieurs des "zones géographiques AWS", il n'y a qu'un seul datacenter.
Bref, comme OVH.
Pi sincèrement, outre la redondance machine uniquement, ils ont vraiment pas eu de chance sur ce coup là, 3 groupes qui lâchent en même temps, c'est vraiment la faute à pas de chance (bien qu'une couche supplèmentaire de redondance machine aurait changé la donne, mais bon, ça n'a plus de sens à force. Rajouter un groupe sur chaque groupe, on a pas fini...)
Clairement, non, ça n'est pas 3 groupes qui lâchent. Un seul a lâché. Le site n'était plus en configuration redondante avec les groupes électrogène avant le début de l'incident et la coupure de courant, car un des groupes "basse tension" était en maintenance.
Les deux groupes HT n'avaient tout simplement pas la puissance nécessaire pour pallier au manque d'un autre groupe, bien que ces 2 groupes n'étaient pas défaillants. C'est bien pour ça qu'ils ont calé.
Comme je le mentionnais plus haut, je connais plusieurs datacenter qui font venir un groupe électrogène mobile pendant plusieurs jours pour gérer la maintenance de chacun des groupes électrogènes fixes, sans perdre la redondance pendant la maintenance.
Iliad-Online.net nous avait déjà fait le coup des multiples groupes qui lâchent en même temps : 3 groupes sur 6. Mais à ma connaissance, on n'a jamais eu le fin mot de l'histoire, et il y a des zones d'ombre dans leur explication.
https://lafibre.info/online/coupure-online/msg88844/#msg88844
Je suis d'accord que pour beaucoup de cas le manque à gagne est peu etre moins important que le re design de l'applicatif en 'mode cloud'.
Par contre si l'applicatif est designé des le depart pour en tenir compte je ne pense pas ce le cout soit beaucoup plus cher. Aujourd'hui des techno comme les microservice , s'executant sur des architecture de type cluster docker avec un ochestrateur ont le vent en poupe et ne coute pas forcement plus cher a exploiter.
Tu semble omettre un point important : en plus du développement/utilisation d'une architecture logicielle redondante, il faut bien payer mes prestataires qui hébergent tout ça de manière redondante! Et donc ça coute forcèment plus cher que si tout est sur un seul site, de manière peu redondée. Si c'est dans du cloud, il faut payer du cloud réparti sur plusieurs sites différents.
Leon.
-
Je ne suis vraiment pas sur... Amazon a eu plusieurs gros incident majeurs, qui ont à chaque fois rendu indisponible de très nombreuses machines pendant plusieurs heures... Quand tu achètes un VPS à Amazon, tu choisis la "zone géographique". Et à ma connaissance, dans plusieurs des "zones géographiques AWS", il n'y a qu'un seul datacenter.
Bref, comme OVH.
AWS,Azure , Google ont pour chaque région une notion avaibility zones (au moins 3 par région) . Et tu choisis dans quelle zone tu instancie ton service. Je ne connais pas assez OVH mais il ne me semble pas qui,il ait ce concept?
Tu semble omettre un point important : en plus du développement/utilisation d'une architecture logicielle redondante, il faut bien payer mes prestataires qui hébergent tout ça de manière redondante! Et donc ça coute forcèment plus cher que si tout est sur un seul site, de manière peu redondée. Si c'est dans du cloud, il faut payer du cloud réparti sur plusieurs sites différents.
Leon.
non pas trop d’accord. Chez au moins les 3 cités plus haut , repartir tes services / serveurs sur plusieurs zones voir région ne coûte pas plus cher.
Chez aws par exemple, il est assez facile avoir une appli web (server d’application + base de données) ou tu fais régulièrement des snapshot de ta base que tu réplique sur une autre région.
Et en cas de problème tu redémarre assez facilement dans ta nouvelle région avec le snapshot. Ça peut éviter une journée de manque à gagner d’un site de ecommerce a moindre coût.
-
Clairement, non, ça n'est pas 3 groupes qui lâchent. Un seul a lâché. Le site n'était plus en configuration redondante avec les groupes électrogène avant le début de l'incident et la coupure de courant, car un des groupes "basse tension" était en maintenance.
Les deux groupes HT n'avaient tout simplement pas la puissance nécessaire pour pallier au manque d'un autre groupe, bien que ces 2 groupes n'étaient pas défaillants. C'est bien pour ça qu'ils ont calé.
Comme je le mentionnais plus haut, je connais plusieurs datacenter qui font venir un groupe électrogène mobile pendant plusieurs jours pour gérer la maintenance de chacun des groupes électrogènes fixes, sans perdre la redondance pendant la maintenance.
Iliad-Online.net nous avait déjà fait le coup des multiples groupes qui lâchent en même temps : 3 groupes sur 6. Mais à ma connaissance, on n'a jamais eu le fin mot de l'histoire, et il y a des zones d'ombre dans leur explication.
https://lafibre.info/online/coupure-online/msg88844/#msg88844
Leon.
Désolé, j'ai confondu avec un autre DC, vu que dans le topic ça parlait d'hexaload, mais c'est Online je crois.
Mais par contre, je pensais vraiment que Amazon profitait de son implentation internationale pour proposer une redondance un peu plus serieuse au niveau des données. Au final ça ne doit pas couter bien plus cher non? C'est juste des disques durs et un petit serveur non?
Après je vois ça d'un oeil d'un mec qui travaille pas là dedans, je précise. Je passe beaucoup de temps à lire le forum, mais sans savoir si je comprends bien tout ^^
-
AWS,Azure , Google ont pour chaque région une notion avaibility zones (au moins 3 par région) . Et tu choisis dans quelle zone tu instancie ton service. Je ne connais pas assez OVH mais il ne me semble pas qui,il ait ce concept?
De ce que j'ai compris, plusieurs "availability zones" peuvent être localisées dans le même datacenter chez AWS... On garantit juste une isolation physique des réseaux électriques et télécom.
En France, chez OVH, tu as le choix entre 3 datacenters : Deux très gros (Roubaix et Gravelines) et un plus petit (Strasbourg). Tout ça avec IP failover évidemment, comme AWS.
Chez aws par exemple, il est assez facile avoir une appli web (server d’application + base de données) ou tu fais régulièrement des snapshot de ta base que tu réplique sur une autre région.
Et en cas de problème tu redémarre assez facilement dans ta nouvelle région avec le snapshot. Ça peut éviter une journée de manque à gagner d’un site de ecommerce a moindre coût.
Mais en cas de perte d'un datacenter géant tout entier, est-ce que AWS garantit qu'il aura suffisamment de ressource (serveurs) pour assurer le basculement des très nombreux clients qui veulent redémarrer sur le/les sites restants? Tous en même temps?
Je ne connais pas bien AWS, mais a-t-on une garantie de pouvoir basculer en volume des centaines d'instances en même temps?
Leon.
-
De ce que j'ai compris, plusieurs "availability zones" peuvent être localisées dans le même datacenter chez AWS... On garantit juste une isolation physique des réseaux électriques et télécom.
En France, chez OVH, tu as le choix entre 3 datacenters : Deux très gros (Roubaix et Gravelines) et un plus petit (Strasbourg). Tout ça avec IP failover évidemment, comme AWS.
l'avantage des availability zone au sein de la meme region est un temps de latence tres bas entre les different AZ , ce qui permet de faire des clusters repartis sur tes AZ, je ne sais pas quel peux etre la latence entre Strasbourg et Roubaix
Mais en cas de perte d'un datacenter géant tout entier, est-ce que AWS garantit qu'il aura suffisamment de ressource (serveurs) pour assurer le basculement des très nombreux clients qui veulent redémarrer sur le/les sites restants? Tous en même temps?
Je ne connais pas bien AWS, mais a-t-on une garantie de pouvoir basculer en volume des centaines d'instances en même temps?
Leon.
Instancier une centaine des serveurs dans une region ne doit pas poser beaucoup de probleme a mon avis
Netflix est la reference pour ce genre de probleme , par exemple avec leur theorie du Chaos Engineering il vont jusqu'a couper une region entier d'AWS sur le system de prod pour verifier que tout ce passe bien de leur cote.
Et pour situe le volume d'instanciation : Fin 2015 il instancier plus de 1 millions de container par semaine : https://medium.com/netflix-techblog/the-evolution-of-container-usage-at-netflix-3abfc096781b
-
D'ailleur pour ceux que ca interresse un tres bon ebook (gratuit) sur le sujet du chaos engineering : http://www.oreilly.com/webops-perf/free/chaos-engineering.csp
Largement inspirer des pratique de netflix
-
l'avantage des availability zone au sein de la meme region est un temps de latence tres bas entre les different AZ , ce qui permet de faire des clusters repartis sur tes AZ, je ne sais pas quel peux etre la latence entre Strasbourg et Roubaix
Instancier une centaine des serveurs dans une region ne doit pas poser beaucoup de probleme a mon avis
Netflix est la reference pour ce genre de probleme , par exemple avec leur theorie du Chaos Engineering il vont jusqu'a couper une region entier d'AWS sur le system de prod pour verifier que tout ce passe bien de leur cote.
Et pour situe le volume d'instanciation : Fin 2015 il instancier plus de 1 millions de container par semaine : https://medium.com/netflix-techblog/the-evolution-of-container-usage-at-netflix-3abfc096781b
Peut être plus maintenant,
Mais à la construction de la zone Amérique côte ouest, au lancement ( il n'y avait que EC2 et S3 ) nous avions lancé un produit ios avec "load balancer applicatif" permettant de donner des stats ( équipes /jouers etc.) et de faire des paris en direct sur le Base Ball en collaboration avec Endemol, toutes les instances devaient être lancées à la main via scripts (c'est à partir de ce moment là ou on a inventé le "scale up" avec AWS et que le concept a été repris ) et bien lors du lancement du produit sur la FOX, des équipes étaient établies aux US, Israel, France, la zone est tombée.
On avait Werner Vogels avec les équipes a essayer de remonter les services.
errare humanum est
-
Instancier une centaine des serveurs dans une region ne doit pas poser beaucoup de probleme a mon avis
Si tu perd 80 000 instances sur un datacenter, un second n'aura pas la capacité disponible (machines physiques, lien réseaux,...) pour prendre en charge le milliers d’instances supplèmentaires.
-
OVH a refait le coup de la panne du réseau optique de Roubaix, hier à l'heure de pointe cette fois-ci.
Les impacts sont à priori moindre qu'il y a 1 mois, mais ça s'est quand même bien constaté.
Franchement, j'ai mal pour eux...
Mais commencer une telle intervention risquée à 20h, c'est carrèment joueur!
http://travaux.ovh.net/?do=details&id=28864
Leon.
-
Pour moi, il faut attendre 1h du matin pour ne pas impacter les services utilisés le soir par le grand public. Il est également possible de le faire le matin tôt, le trafic grand public reste très faible le matin avant 10h00.
Vous imaginez Netflix faire un préparatif de maintenance sur les équipements à 20h20 et une maintenance avec coupure de 1/3 des liens à 23h00 ?
OVH a des plages horaires d'intervention qui correspond à un hébergeur de services pour entreprise, pas grand public.
-
Et donc une plage horaire 1h - 5h du mat pour les grosses maintenances OVH, ça conviendrait à la fois aux 2 utilisations des services hébergés chez OVH : pro et particuliers.
Et ça correspond étrangement aux horaires de maintenance privilégiées par la SNCF et a RATP...
Leon.
-
le système de Cisco à l'air super fiable quand même ;D
-
Et donc une plage horaire 1h - 5h du mat pour les grosses maintenances OVH, ça conviendrait à la fois aux 2 utilisations des services hébergés chez OVH : pro et particuliers.
Et ça correspond étrangement aux horaires de maintenance privilégiées par la SNCF et a RATP...
Leon.
OVH ne fait quasiment jamais de maintenance à ces heures là .. (même des maintenances logicielles / autres)
Pourtant avec des équipes FR et Canada, ça devrait être possible...
Après, vivien, qu'est ce que tu appelles "pro"?
Car en ce moment, les "pros" , sites qui vendent des cadeaux de noel est autre, doivent être utilisés à 20h ..
-
pro = service utilisés dans les boite sur les heures d'ouverture (en gros 8h - 19h)
des trucs genre serveurs mail d'entreprise / site web internes / outils applicatifs / SI ...
des services qui tournent quasiment à vide sur les heures non ouvrés la plupart du temps
-
Clairement, OVH adresse les 2 types d'utilisateurs finaux, c'est indéniable:
* utilisateurs pro/entreprise : serveur d'e-mail, bureaux virtuels, VPN d'entreprise, téléphonie d'entreprise, services B2B, etc...
* le grand public avec énormèment de sites web pour tout et n'importe quoi (e-commerce, porno, information, publicité, etc...), des serveurs de jeu en ligne, etc...
Donc si une entreprise vise ces 2 types d'utilisation, et qu'elle est sérieuse (ce qui n'est pas le cas d'OVH visiblement), les maintenances c'est entre 1h et 5h du matin.
Leon.
-
Iliad-Online.net nous avait déjà fait le coup des multiples groupes qui lâchent en même temps : 3 groupes sur 6. Mais à ma connaissance, on n'a jamais eu le fin mot de l'histoire, et il y a des zones d'ombre dans leur explication.
https://lafibre.info/online/coupure-online/msg88844/#msg88844
Ohhhh oui, une journée terrible, à oublier et clairement un échec pour un site que j'ai conçus personnellement.
Faire de l'infra c'est très ingrat comme métier, peu rémunérateur et à haut risque.
Tu as beau tout prévoir, n'avoir fait aucune concession, tu es toujours dépendant d'éléments extérieurs, mécaniques ou d'automatismes, qui, le jour où tu en as besoin pour de vrai, montrent leurs faiblesses, faiblesses qui s'additionnent souvent au même moment.
Le plus important est d'en tirer de l'expérience pour concevoir différemment et améliorer constamment l'existant.
-
Pour ma culture personnelle, quel est le design pour de la très haute disponibilité ?
Comment passer d'un site à un autre sans rupture de fourniture de services.
-
Ca depend juste du prix que le client est pret a payer....
Pour ce qui est critique, comme les banques qui peuvent pas se permettre d'avoir 5000 lecteurs de cartes inactifs, opérateur telecom qui perde beaucoup de poignon quand du prepayed peux plus etre facturé :)
Pour ca c'est souvent des SAN en réplication sur 2 sites, et des serveurs qui sont en mode "switch over", donc chaque site tourne ses applis, et si un tombe, le 2 eme passe en sutdown ce qui est pas critique et prend en charge les deux, ca se fait en qques minutes, mais arreter une DB SAP, faut le temps de le faire et souvent comme c'est pas prévu il y a du recovery à faire pour redémarrer sur une autre machine....
Maitenant tu peux avoir du 100% en mirroring, mais la tu mutiplie le prix par 10x.
-
Ah...
http://travaux.ovh.net/?do=details&id=29536
&
http://travaux.ovh.net/?do=details&id=29538
J'ai plus accès à mes mails pour ma part ::) ::) ::) ::)
-
c'est vraiment pas une bonne année pour ovh....
-
L'électricité chez OVH décidèment c'est pas facile ces derniers temps (pas de chance, en pleine expansion).
-
Je ne sais pas si c'est l'électricité ou plutôt un certain laisser aller..avec Ovh c'est toujours la faute à pas de chance.. Ils pourraient clairement mieux assumer.. Plutôt que de dire à chaque fois on avait prévu d'améliorer ceci justement dans quelques jours/mois..
Depuis 2 ans, dans l'ensemble de nos datacentres nous
déployons le standard électrique basé sur 2 arrivées
électriques totalement redondés par baie. Lors de cet
incident, 4 containers ont continué à fonctionner sans
souci. Par contre jusqu'au 2015, 50% des infrastructures
ont été déployées suivant un autre standard basé sur une
seule arrivée électrique par baie. Cet autre standard
nous ne utilisons plus depuis 2015. En novembre 2017,
nous avons pris la décision de recenser toutes les baies
dans l'ensemble de nos datacentres qui ont été déployées
suivant cet autre standard. Nous allons upgrader le
réseau électrique dans ces baies pour avoir partout chez
Ovh uniquement le standard basé sur 2 arrivées électrique
Si Ovh a changé son modèle il y a deux ans sûrement car ils ont estimé que ce n'était pas assez fiable pourquoi avoir attendu autant avant de faire les changements sur les anciennes ?
-
Moi je comprend rien a ce qu'ils racontent dans ce passage:
L'UPS7 alimente plusieurs containers en voie B. Il n'y
a pas eu de conséquence sur tous ces containers puisqu'un
autre onduleur UPS8 continuait à alimenter ces containers
via la voie A. Nous avons eu un impact sur la rangée B dans
3 containers, G117, G125, G126. L'ensemble de serveurs
qui se situent dans la rangée B de ces 3 containers ont
ont été impactés durant la panne.
du coup pas d'impact pour les containers mais enfaite pour 3 si?
???
-
De ce que j'ai compris en gros cet onduleur alimentait on va dire 6 containers. Pour 3 d'entre eux c'était la seule alimentation (donc en panne) et les 3 autres avaient une double alimentation donc pas de problème
-
De ce que j'ai compris en gros cet onduleur alimentait on va dire 6 containers. Pour 3 d'entre eux c'était la seule alimentation (donc en panne) et les 3 autres avaient une double alimentation donc pas de problème
donc c'est un peut la fête chez ovh? des parties sont en doubles voies et d'autres pas ?
-
L'électricité chez OVH décidèment c'est pas facile ces derniers temps (pas de chance, en pleine expansion).
Dans les 3 gros incidents dont on parle ici, ça n'est pas du tout la faute à "pas de chance". Il y avait des SPOF, des trucs non redondés.
Bref, des incidents qui auraient du être sans conséquence avec une vraie archi haute fiabilité (un onduleur qui crame sur plusieurs dizaines, ça arrive à tout le monde), ont eu un impact client important.
* panne totale du réseau optique longue distance au départ de Roubaix : Tout le réseau optique est configuré comme un seul système dont le management est centralisé. C'est couillu.
* Panne électrique Strasbourg : pendant une maintenance d'un groupe électrogène (= 1 groupe non dispo), la redondance des groupes n'était plus assurée. Un groupe a calé suite à coupure électrique (ça arrive) et c'est plusieurs grosses salles/containers qui se sont retrouvés sans électricité
* Panne électrique de janvier : un seul onduleur crame, et malheureusement de nombreuses baies sont dans une archi électrique non redondée, avec une seule ligne d'alimentation.
Si Ovh a changé son modèle il y a deux ans sûrement car ils ont estimé que ce n'était pas assez fiable pourquoi avoir attendu autant avant de faire les changements sur les anciennes ?
Si ça n'est pas pensé dès le départ, si les salles ne sont pas "urbanisées" (comme le diraient les spécialistes) pour prévoir 2 arrivées électriques dès le début, et si les salles sont très denses, pleines, encombrées, alors il est facile de comprendre que la modernisation est très complexe. Il faut passer des nouveaux câbles, sans doute des nouveaux chemins de câble, il faut installer de nouveaux tableaux électrique un peu partout (y a-t-il la place pour le faire?), des bandeaux de prises supplèmentaires dans les baies (place dispo?), etc...
Leon.
-
Ça fait peur de voir autant d'incompétences et négligences dans ces entreprises dont c'est supposèment le metier.
-
Oui c'est leur metier, seulment la cliètèle est pas la meme, tu peux pas vendre un "smsufit" a 10€ avec de la triple redondance que pour une boite de pharma ou une banque loura 1000€ pour un uptime garanti a 99.9% ;)
Et finalement le raport qualité/prix chez OVH est tout a fait correcte, et les couac ben tu sais que ca arrivera et tu fais avec, ou tu y met le prix.
Les DC qui vendent que du "high-end" ca manque pas, mais regarde le prix de la loc d'une cage, d'une salle ou d'un server, c'est pas comparable,
-
Oui c'est leur metier, seulment la cliètèle est pas la meme, tu peux pas vendre un "smsufit" a 10€ avec de la triple redondance que pour une boite de pharma ou une banque loura 1000€ pour un uptime garanti a 99.9% ;)
Et finalement le raport qualité/prix chez OVH est tout a fait correcte, et les couac ben tu sais que ca arrivera et tu fais avec, ou tu y met le prix.
Les DC qui vendent que du "high-end" ca manque pas, mais regarde le prix de la loc d'une cage, d'une salle ou d'un server, c'est pas comparable,
Miky, tu te trompes sur 2 points
1) OVH ne vend pas d'espace en datacenter, donc ça n'est pas comparable
2) OVH ne vend pas que des serveurs à 10€ par mois. Certains serveurs dépassent largement les 300€/mois. On ne parle plus de low cost à ce niveau là... Il est très probable qu'OVH fasse la majorité de son chiffre d'affaire, et surtout de sa marge, avec des serveurs à plus de 100€, plutôt qu'avec des serveurs à 10€.
Leon.
-
1) OVH ne vend pas d'espace en datacenter, donc ça n'est pas comparable
https://www.ovh.com/fr/housing/ ?
-
OK, je savais pas qu'ils faisait pas hosting.
-
https://www.ovh.com/fr/housing/ ?
Sécurité
Sécurité physique
Redondance infrastructure N+N
Gestion des incidents
Nan mais laisse moi rire ;D
-
Après il faut bien voir que tous les datacenters d'OVH ne sont pas construits pareil.
-
Et sur les deux de mon lien, Global Switch est un DC où OVH est lui-même hébergé.
-
C'est surtout un pbs de comm, jamais personne va te dire qu'il fait du "lowcost", tu vas chez Free ben tu sais (ou pas) que le peering est pourri, tu achete une poule chez LIDEL a 1€, ben tu te doute que elle vient de Roumanie piquée aux hormones et pas élevée au grain en pleine nature en Bresse , ou elle coutera 8€...
Donc un plus de transparence ferait pas de mal, il en faut pour tout le monde, mais faut le dire clairement.
-
C'est surtout un pbs de comm, jamais personne va te dire qu'il fait du "lowcost", tu vas chez Free ben tu sais (ou pas) que le peering est pourri, tu achete une poule chez LIDEL a 1€, ben tu te doute que elle vient de Roumanie piquée aux hormones et pas élevée au grain en pleine nature en Bresse , ou elle coutera 8€...
Donc un plus de transparence ferait pas de mal, il en faut pour tout le monde, mais faut le dire clairement.
Et du coup, un serveur à 300€/400€ chez OVH, c'est du low cost, pour toi?
Leon.
-
Et du coup, un serveur à 300€/400€ chez OVH, c'est du low cost, pour toi?
Leon.
Lâches l'affaire Léon, il ne connait le business que par le biais des san qui sont très conservateur et en plus pour des clients qui sont les conservateurs du milieu.
Dans le genre une location à moins de 5 chiffres mensuel, c'est suspect.
[modération : pas d'attaque SVP]