Auteur Sujet: Incendie OVH à Strasbourg: SBG2 complètement détruit. SBG1 détruit à 42%. (Lu 311665 fois)

butler_fr · « **Réponse #588 le:** 17 mars 2021 à 17:45:28 »

ça troll sévère:
http://watercooling.ovh/

vivien · « **Réponse #589 le:** 17 mars 2021 à 17:58:15 »

Point journalier.

Je suis étonné par "SBG4 tous les serveurs et tous les étages sont préservés" : SBG4 n'est pas déployé sur un seul niveau ?

Il faut comprendre par contre que le dernier étage de SBG3, celui qui a le plus souffert, tous les serveurs ne sont pas préservés ?

SBG4 étant peu touché par l'incendie (il est physiquement éloigné du feu, alors que SBG1 et SBG3 touche SBG2), c'est étonnant de ne pas le remettre rapidement en service si tout est prêt. Il ne devait pas y avoir de nettoyage et séchage de serveur sur SBG4, non ? SBG4 sera pourtant le dernier à redémarrer si je comprends bien.

Les bulletins précédents :
- 16 mars 2021
- 15 mars 2021
- 14 mars 2021
- 13 mars 2021
- 12 mars 2021
- 11 mars 2021
- 10 mars 2021

Vidéos :
- Vidéo du 11 mars 2021
- Vidéo du 16 mars 2021

underground78 · « **Réponse #590 le:** 17 mars 2021 à 18:06:47 »

C'est pas juste que SBG4 est considéré comme moins prioritaire car plus petit ou contenant moins de services importants ?

Leon · « **Réponse #591 le:** 17 mars 2021 à 18:17:00 »

Je pense la même chose : SBG4, c'est tout petit à priori, et c'est exclusivement du SoYouStart et du Kimsufi. Si j'ai bien compris...
SBG4 c'est 80 baies, contre 600 baies pour feu SBG2.

Leon.

joel19 · « **Réponse #592 le:** 17 mars 2021 à 18:25:14 »

Panique chez les clients d'OVH en défaut de sauvegarde

Moins d'une semaine après le terrible incendie qui a frappé le datacenter d'OVH à Strasbourg, la tension est vive. Les raisons de l'incident ne sont pas encore pour l'heure établies clairement.
L'hypothèse d'un acte malveillant ne peut pas être totalement écarté.Des scellées sont effectuées sur les onduleurs, batteries, vidéo surveillance afin de faire avancer l'enquête. « On pense avoir été très transparents et au-dessus des standards de l'industrie, il faut monter ces standards pour que ces types d'incidents n'arrivent plus jamais et que pour des pertes de disques, les données puissent toujours être récupérées », a indiqué dans une dernière vidéo le fondateur d'OVH Octave Klaba. Au dessus des standards de l'industrie ?
Pas vraiment, puisque OVH ne souscrit pas aux onéreuses certifications de l'Uptime Institute.

(....)

En attendant, on peut quand même s'interroger sur les circonstances de cet incident qui ont clairement été mal maitrisées par OVH. Plusieurs points de faiblesse peuvent expliquer la situation. En adoptant un modèle low cost, la société fait sans aucun doute ressortir des lacunes en termes de sécurité incendie mais aussi de certifications. Par rapport à d'autres opérateurs comme Equinix ou Interxion, OVH n'a par exemple pas pris le train de l'Uptime Institute, organisme mondialement reconnu pour ses benchmarks de datacenters, allant même jusqu'à revendiquer s'y conformer sans en être certifié. Le monde à l'envers.
De même, toujours afin de comprimer les coûts, de possibles défaillances des maigres systèmes de sécurité incendie [des extincteurs à mains obligatoires], qui se sont révélés incapables de circonscrire le sinistre sur un périmètre restreint, doivent être éclaircies. Le manque de technologies de détection, atténuation ou lutte contre les incendies (brouillard d'eau, sprinkler, gaz, mousse mais aussi détecteur de chaleur, fumée ou flamme...) est un vrai problème dans le datacenter strasbourgeois d'OVH. De conception ancienne ( 10 ans) et low cost, ce dernier ne bénéficie pas des avancées présentes chez d'autres opérateurs de datacenters.

(....)

Parmi les clients touchés, on trouve de nombreuses mairies (Artenay, Arras, Saint-Ouen, Cherbourg, Vichy, Vitry-sur-Seine...), des clubs sportifs (AS Cannes, ASM Rugby, l'US Créteil Handball, l'AS Saint-Priest, club de rugby de Clermont-Ferrand....). Des PME (Nautex International, Duysens Immobilier, Groupe Gorioux, BEG Ingénierie, bureau d'études d'Orléans-La Source, le fabricant de monuments funéraires Stonest...) et éditeurs de services en ligne (Rust, Freshmile Direct, The Artist Academy...). Ou encore des organismes culturels, religieux et touristiques (Frac Bretagne, Centre Pompidou à Paris, Office de tourisme de Colmar et de Saverne, Diocèse de StBrieuc...), des médias (Maddyness, Agro Distribution, L'Essor Isère, La Semaine ...), des services administratifs (datagouv, plateforme de dématérialisation des marchés publics, défenseur des droits...) et de nombreuses associations (CRAIF, CIRSES, Ligue contre l'obésité...), l'aéroport de Strasbourg...

(....)

Suite à ce ravage, 3,6 millions de sites web et sous-domaines auraient ainsi été impactés avec des problèmes d'accès de quelques dizaines de minutes ou plusieurs heures pour les plus chanceuses, quand d'autres connaissent l'angoisse d'une indisponibilité totale parfois pour toujours.

https://www.lemondeinformatique.fr/actualites/lire-incendie-ovh-strasbourg-des-sites-toujours-touches-les-dirigeants-s-expliquent-82266.html

vivien · « **Réponse #593 le:** 17 mars 2021 à 18:57:59 »

Citation de: Leon le 17 mars 2021 à 18:17:00

Je pense la même chose : SBG4, c'est tout petit à priori, et c'est exclusivement du SoYouStart et du Kimsufi. Si j'ai bien compris...
SBG4 c'est 80 baies, contre 600 baies pour feu SBG2.

Non, il y a également du VPS sur SBG4, ceux qui sont nommés SBG6 il me semble.

eahlys · « **Réponse #594 le:** 17 mars 2021 à 19:45:49 »

Vraiment celui qui a eu l'idée d'utiliser la même nomenclature pour l'infra physique et l'infra logique, je sais pas ce qu'il se passe de mal dans sa vie mais il a pas l'air d'être en grande forme je pense

vivien · « **Réponse #595 le:** 17 mars 2021 à 19:47:41 »

Je ne retrouve plus la correspondance entre la région VPS et la localisation physique.

Localisations VPS SBG1, SBG2 et SBG4 => Datacenter SBG2
Localisations VPS SBG6 => Datacenter SBG3

Par contre cet article dit bien qu'il y a des VPS à SBG4 :

Citation de: dj54 le 12 mars 2021 à 20:15:03

quelques infos a 20h

Etat des sauvegardes de données suite à l'incendie sur le campus d'OVHCloud à Strasbourg

Si il n'y a pas de VPS dans le DC SBG4 il faut que je recontacte mon service informatique, https://jalerte.arcep.fr/ est censé être un VPS sur le DC SBG4 (prod et pré-prod)
Comme ce n'est pas critique, ils attendent que le VPS soit remis en service.

il y a peut être eu une confusion avec la région VPS SBG4 qui est dans le datacentre SBG4, donc détruite.
Dans ce cas là, il faut partir des sauvegardes.

Leon · « **Réponse #596 le:** 17 mars 2021 à 20:11:28 »

Citation de: vivien le 17 mars 2021 à 19:47:41

Je ne retrouve plus la correspondance entre la région VPS et la localisation physique.

Tout est ici
https://www.ovhcloud.com/fr/lp/status-services-backup-strasbourg/
Je ne vois aucun VPS à SBG4.

Leon.

vivien · « **Réponse #597 le:** 18 mars 2021 à 02:43:07 »

J'ai demandé à mon SI de vérifier où est l'hébergement de J'alerte l'Arcep.

Les snapshots des VPS SBG1, SBG3 et SBG4, (serveur hôte physiquement à SBG2) il y a deux cas :
- Si les offres « VPS Snapshot Cloud/CloudRam » / « VPS Snapshot SSD Range » ont été souscrites avant le 23 avril 2020, elles sont stockés sur des baies de disques d’appoint juste à côté des VPS, donc dans SBG2 et ils sont détruits.
- Si les offres « VPS Snapshot Cloud/CloudRam » / « VPS Snapshot SSD Range » ont été souscrites après le 23 avril 2020, elles sont stockés sur des baies de disques qui bénéficient de la technique d’Erasure Coding réparties sur SBG2 et SBG3 permettant une redondance comme un RAID5 de 5 disques physique. Si les morceaux répliqués sur SBG3 équivalent à 80% des données d’un serveur, alors ces VPS sont restaurable à 100%, car il y a 20% de redondance (il faut que tous les disques sur SBG3 redémarrent).

Pour le service de stockage « Public Cloud Archive » (PCA), c'est aussi des baies de disques en Erasure Coding réparties sur SBG2 et SBG3, mais SBG3 ne contient que 68 % de leurs morceaux, donc cela serait perdu.

Pour le service de stockage « Public Cloud Storage » (PCS), on reste en Erasure Coding, mais SBG3 contient 99,5 % des morceaux de la globalité du stockage, il est donc possible de restaurer la plupart des fichiers, sauf ceux dont plus de 20% du contenu dans SBG2.

alain_p · « **Réponse #598 le:** 18 mars 2021 à 08:30:04 »

C'est vrai que je n'avais pas vu que le site 'J'alerte l'ARCEP' était indisponible.
https://jalerte.arcep.fr/

ezivoco_163 · « **Réponse #599 le:** 18 mars 2021 à 09:12:07 »

Citation de: vivien le 18 mars 2021 à 02:43:07

J'ai demandé à mon SI de vérifier où est l'hébergement de J'alerte l'Arcep.

Les snapshots des VPS SBG1, SBG3 et SBG4, (serveur hôte physiquement à SBG2) il y a deux cas :
- Si les offres « VPS Snapshot Cloud/CloudRam » / « VPS Snapshot SSD Range » ont été souscrites avant le 23 avril 2020, elles sont stockés sur des baies de disques d’appoint juste à côté des VPS, donc dans SBG2 et ils sont détruits.
- Si les offres « VPS Snapshot Cloud/CloudRam » / « VPS Snapshot SSD Range » ont été souscrites après le 23 avril 2020, elles sont stockés sur des baies de disques qui bénéficient de la technique d’Erasure Coding réparties sur SBG2 et SBG3 permettant une redondance comme un RAID5 de 5 disques physique. Si les morceaux répliqués sur SBG3 équivalent à 80% des données d’un serveur, alors ces VPS sont restaurable à 100%, car il y a 20% de redondance (il faut que tous les disques sur SBG3 redémarrent).

Pour le service de stockage « Public Cloud Archive » (PCA), c'est aussi des baies de disques en Erasure Coding réparties sur SBG2 et SBG3, mais SBG3 ne contient que 68 % de leurs morceaux, donc cela serait perdu.

Pour le service de stockage « Public Cloud Storage » (PCS), on reste en Erasure Coding, mais SBG3 contient 99,5 % des morceaux de la globalité du stockage, il est donc possible de restaurer la plupart des fichiers, sauf ceux dont plus de 20% du contenu dans SBG2.

euh j'ai des connaissances basique mais ça veut dire qu'il n'y avait donc pas de vraie sauvegarde vers un autre site physiquement distant d'au moins plusieurs kilomètres

Auteur Sujet: Incendie OVH à Strasbourg: SBG2 complètement détruit. SBG1 détruit à 42%. (Lu 311665 fois)

butler_fr

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

vivien

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

underground78

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

Leon

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

joel19

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

vivien

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

eahlys

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

vivien

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

Leon

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

vivien

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

alain_p

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.

ezivoco_163

Incendie OVH à Strasbourg: SBG2 complétement détruit. SBG1 détruit à 30%.