La Fibre
Datacenter et équipements réseaux => Datacenter => 
Datacenter => Discussion démarrée par: bertrandep le 26 avril 2023 à 09:09:43
-
il semble y avoir eu un incendie ce matin (26/04/2023) dans le data center de Global Switch à Clichy qui a été maitrisé par les pompiers.
Les pompiers ont tout de même demandé à couper l'alim du batiment.
Voici la communication reçu de notre partenaire hébergeur (je ne pourrai pas donner plus de détails..) :
Chers clients,
Ce matin, vers 5h, un départ d’incendie a eu lieu au sous-sol du bâtiment de global switch, rue Petit à Clichy.
Les pompiers sont intervenus et l’incendie a été maitrisé vers 7h.
Aucun des équipements de notre salle qui se trouve au [...] étage ne semble impacté.
Par mesure de sécurité, les pompiers ont demandé à ce que le courant du bâtiment soit intégralement interrompu à 8h30.
[...]
-
Édit Vivien 22h00 : Déroulé des événements, on remercie les experts du FRnOG pour le partage d'information
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_resume.webp)
Voici les informations diffusées. L'heure est celle de la diffusion de l'information. L'incident sur le circuit de refroidissement se serait déclenché à 3h00, en pleine nuit.
10h21 :
Problème de pompe d'eau du circuit de refroidissement, ce qui a généré une accumulation de d'eau et qui a déclenché la fuite.
L'eau de la fuite est descendue sur le local batterie et a provoqué un incendie.
Le directeur du site de GS est toujours en discussion avec les pompiers pour savoir si ils coupent completement le courant du batiment concerné pour l'intervention des pompiers.
Pas de fummée dans les autres salles, c'est confiné à la salle technique où se trouvent les batterie.
Les pompiers sont obligés de laisser bruler les batteries avant d'intervenir.
Prochain point à 11h
11h38 :
La climatisation est revenue et la température dans les salle sont à nouveau OK.
Le local batteries du niveau 1 au sous-sol n'est pas accessible par les pompiers. Ils refroidissent les parois pour contenir le feu mais l'incendie n'est toujours pas maîtrisé.
La coupure électrique est toujours envisagée.
13h : Communication officielle sur Linkedin (https://www.linkedin.com/posts/global-switch_statement-in-relation-to-incident-in-our-activity-7056941925844541440-kzzQ)
Information Suite A L’incident Survenu sur Notre Site de Paris
Un départ d’incendie s'est déclaré ce matin dans une salle de l’un des deux centres de données de notre site parisien. Les pompiers sont intervenus rapidement et l'incendie est désormais maitrisé. Les dispositifs anti-incendie du bâtiment ont parfaitement fonctionné, personne n'a été blessé. Le service de certains de nos clients a été temporairement affecté et notre équipe sur site travaille à le rétablir le plus rapidement possible.
15h15 :
Il semblerait que certaines équipes techniques puissent rentrer dans des salles du L5. Je vous tiens au courant si l'accès redevient possible pour tout le monde.
15h19 :
L’incendie est éteint.
Les pompiers ne peuvent pas encore accéder à la salle des onduleurs/batteries du niveau 1 car la température à l’intérieur était à plus de 65°C (il y a 1h).
Au niveau des impacts, la MRR étant accolée à la salle qui a bien chauffé, l'opérateur Zayo aurait été touché.
Les onduleurs/batteries qui ont brulés sont dédiés au niveau 1 donc les autres niveaux ne sont pas concernés par d'éventuels problèmes de power.
17h22 :
Meeting de crise de 17h00 anticipé à 16h30 suite GO de Global Switch :
Pas de coupure planifiée sur PAR E (cooling/électricité)
L’infrastructure technique est opérationnelle (clim, électricité, sparkshield, …)
Tous les clients de Clichy 1 peuvent donc redémarrer leurs serveurs
Les niveaux L4, L5 et L6 sont accessibles pour les clients MAIS avec un accompagnant GS
Les bureaux sont accessibles à tous
Le L1 (onduleurs et MMR1) reste sous surveillance, seuls les Sapeurs-Pompiers sont autorisés à y pénétrer -> attente de leur validation
-
Incendie déclaré à 5h, mais apparemment la température a bien monté cette nuit avant 5h du matin, dans (au moins une des) salles d'hébergement de GlobalSwitch.
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_1.webp)
Ca sent la coupure de clim suite à l'incident initial. Espérons que ça tienne le coup !
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_2.jpg)
Source : Twitter Clément Cavadore (https://twitter.com/acontios_net/status/1651127892057661440)
Selon Guillaume Genty, c'est un incendie sur le TGBT cette nuit, qui aurait coupé une partie des voies électriques et cela pourrait expliquer l'arrêt d'une partie des clims.
Il faudrait donc élucider l'heure du départ, car le graphique mentionne clairement 4h et non 5h pour la coupure de climatisation
Photo d'illustration de Globalswitch Clichy :
(https://lafibre.info/images/datacenter/202304_global_switch_clichy.jpg)
(source: Globalswitch)
-
🔴 [Info] Indisponibilité de notre site Internet Cybermalveillance.gouv.fr➡️ Incendie désormais maîtrisé dans un centre de données où nos serveurs sont hébergés. Le courant a été interrompu à 8h30 par mesure de sécurité. Nous avons déclenché notre plan de reprise d’activité.
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_3.webp)
https://twitter.com/cybervictimes/status/1651129543812345857
-
19:00 PDT = 04H du matin.
26 Apr 2023 00:35 PDT
Summary: Multiple Google Cloud services in the europe-west9 region are impacted.
Description: Water intrusion in europe-west9-a has caused a multi-cluster failure and has led to an emergency shutdown of multiple zones. We expect general unavailability of the europe-west9 region. There is no current ETA for recovery of operations in the europe-west9 region at this time, but it is expected to be an extended outage. Customers are advised to failover to other regions if they are impacted.
We will provide an update by Wednesday, 2023-04-26 02:00 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9 region
Workaround: Customers can failover to zones in other regions
25 Apr 2023 23:05 PDT
Summary: Multiple Google Cloud services in the europe-west9 region are impacted
Description: Water intrusion in europe-west9-a has caused a multi-cluster failure and has led to an emergency shutdown of multiple zones. We expect general unavailability of the europe-west9 region. There is no current ETA for recovery of operations in the europe-west9 region at this time, but it is expected to be an extended outage. Customers are advised to failover to other regions if they are impacted.
We will provide an update by Wednesday, 2023-04-26 00:30 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9 region
Workaround: Customers can failover to zones in other regions
25 Apr 2023 22:21 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: Water intrusion in europe-west9-a led to an emergency shutdown of some hardware in that zone. There is no current ETA for recovery of operations in europe-west9-a, but it is expected to be an extended outage. Customers are advised to fail over to other zones if they are impacted.
We will provide an update by Wednesday, 2023-04-26 00:30 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other zones
25 Apr 2023 22:18 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: Water intrusion in europe-west9-a led to an emergency shutdown of some hardware in that zone. There is no current ETA for recovery of operations in europe-west9-a, but it is expected to be an extended outage. Customers are advised to fail over to other zones in europe-west9 if they are impacted.
We will provide an update by Wednesday, 2023-04-26 00:30 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other zones within europe-west9
25 Apr 2023 22:16 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: Water intrusion in europe-west9-a led to an emergency shutdown of some hardware in that zone. There is no current ETA for recovery of operations in europe-west9-a, but it is expected to be an extended outage. Customers are advised to fail over to other zones in europe-west9 if they are impacted.
We will provide an update by Wednesday, 2023-04-26 00:30 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other available zones
25 Apr 2023 20:51 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: Water intrusion in europe-west9-a led to an emergency shutdown of some hardware in that zone. There is no current ETA for recovery of operations in europe-west9-a, but it is expected to be an extended outage. Customers are advised to fail over to other zones in europe-west9 if they are impacted.
We will provide an update by Tuesday, 2023-04-25 22:30 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other zones within europe-west9
25 Apr 2023 19:56 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone Our engineering team continues to investigate the issue.
We will provide an update by Tuesday, 2023-04-25 21:00 US/Pacific with current details.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other zones within europe-west9
25 Apr 2023 19:25 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Our engineering team continues to investigate the issue.
We will provide an update by Tuesday, 2023-04-25 20:00 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other zones within europe-west9
25 Apr 2023 19:00 PDT
Summary: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Description: We are investigating an issue affecting multiple Cloud services in the europe-west9-a zone
Our engineering team continues to investigate the issue.
We will provide an update by Tuesday, 2023-04-25 19:30 US/Pacific with current details.
We apologize to all who are affected by the disruption.
Diagnosis: Customers may be unable to access Cloud resources in europe-west9-a
Workaround: Customers can fail over to other zones within europe-west9
https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPfkY#73mBtVKKfeJGJ1yaY7hV
-
Point à 9h51
Une solution de contournement est en cours entre Global Switch et les pompiers.
La température de notre salle est stable. L’électricité n’a pas été coupée à cette heure.
Les bascules PRA ont néanmoins été activées quand c’était possible.
Prochain point à 10h30
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_4.webp)
Source : twitter Audrey Louail (https://twitter.com/AudreyLouail)
-
10h30
Clim rallumée et température en cours de baisse. Pas de coupure élec de la salle envisagée pour le moment. Certains équipements se sont mis en sécurité suite à la hausse des températures.
Nous n’avons pour le moment pas l’autorisation d’y accéder. Prochaine com à 11h15
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_5.webp)
-
Apparemment Mailo est impacté, plus de mails et leur site ne répond pas...pas de secours dans d'autres datacenters :o
-
Hello,
Les premiers incidents de température trop hautes sont arrivés vers 3h ici..
-
19:00 PDT = 04H du matin.
https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPfkY#73mBtVKKfeJGJ1yaY7hV
Petit effet dominos sur les autres régions d'Europe et du monde chez Google cloud ?
:o
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_7.jpg)
-
Problème de scope sur le dashboard, ca impacte toutes les régions à cause de la console web qui est down, la CLI marche toujours. Ils ont rectifié a priori.
-
11h15 Température toujours en cours de baisse. Pas de coupure élec de la salle envisagée. Aucun dommage sur les équipements IT et élec. Nous n’avons toujours pas l’autorisation d’accéder à la salle pour les redémarrer les équipements en sécurité. Prochaine com à 12h
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_6.webp)
On voit bien une baisse de la température :
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_8.webp)
Source: Twitter @jaxxdotred (https://twitter.com/jaxxdotred/status/1651158846298107906)
-
On rigole bien avec les VE...
Impact majeur de l'incident Google/Global Switch sur le réseau de recharge @Izivia ⬇️ du groupe @EDFofficiel : Impact sur les paiements et les cartes tierces ! (Cc @Chargemap @Auto_Propre )
https://twitter.com/MCCob/status/1651184183912325126
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_12.webp)
-
Dites @payplug et @GroupeBPCE Nous approchons 7h de panne totale des acquisitions de paiement CB en raison de votre choix de travailler avec GCP, sans redondance. Vous n’avez aucun PCA ? C’est des stagiaires à la gouvernance IT et conformité chez vous ? Vous plaisantez j’espère.
https://twitter.com/a_bermingham/status/1651220617469870081
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_9.webp)
-
RTFM: https://cloud.google.com/compute/docs/regions-zones?hl=fr
Ca me paraît inimaginable une telle erreur de "design", pour un service de paiement supposé disponible 24x7.
-
Dites @payplug et @GroupeBPCE Nous approchons 7h de panne totale des acquisitions de paiement CB en raison de votre choix de travailler avec GCP, sans redondance. Vous n’avez aucun PCA ? C’est des stagiaires à la gouvernance IT et conformité chez vous ? Vous plaisantez j’espère.
https://twitter.com/a_bermingham/status/1651220617469870081
Il lui est proposé de passer chez Stancer (Iliad Bank) ! ;D
(https://i.ibb.co/3mJ26Dv/screencapture-twitter-pfhugues-status-1651221221889941507-2023-04-26-17-27-19.png)
https://twitter.com/pfhugues/status/1651221221889941507
https://twitter.com/vincib/status/1651235237031026693
-
Pouahahahaha, excellent !
-
N'empêche que ce genre d'incident impacte la vie de tous les jours.
Tout à l'heure je n'arrivais pas à payer quelque chose, c'était ma première commande sur ce site et en bon parano je suis parti en vrille.
Je me suis excusé depuis.
-
Je ... non rien.
Nous avions bien de la redondance entre plusieurs datacenters. Nous faisons face à une défaillance physique d’un datacenter qui a déclenché une défaillance logique de toute la région. C’est un scénario hautement improbable et inexpliqué à ce stade par notre prestataire.
https://twitter.com/payplug/status/1651243791066562563
-
Chez un client, j'ai fait reboot les switchs du site secondaire.
Cela a fait tomber la baie SAN du site primaire donc la prod est tombé.
En théorie, ce n'était pas possible.
En pratique, on a des surprises.
-
Mais là, on est sur un acteur probablement opérateur d'importance vitale, qui doit avoir un très haut niveau de disponibilité et de résilience.
Aujourd'hui c'est une journée particulière, on peut penser que des clients Google Cloud cherchent à migrer chez Scaleway qui propose des services conçurent.
Que Scaleway ne soit pas en mesure de vendre est critique pour tous les clients Google qui cherchent une solution alternative. Amazon a dû faire une bonne journée.
-
Statu à 21h00 : A l’heure qu’il est, des serveurs de bases de données ont été créés sur la région Belgique et la migration des données de production essentielles au processing est terminée. La réactivation des services devrait avoir lieu de manière progressive au plus vite.
Toutes les équipes sont pleinement mobilisées, l'urgence étant la stabilisation de l’ensemble de notre service.
Ils rejettent la faute sur Google qui aurait perdu toute la région (3 datacenter).
Sinon, top leur système de monitoring qui indique qu'il n'y a eu aucune coupure - disponibilité aujourd'hui de 99,8% (les graphiques en bas de ma copie d'écran)
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_10.webp)
-
Pour revenir à Global Switch, on ne sait toujours pas la cause de l'incendie.
On sait juste que c'est au sous-sol et l'eau a entraîné l'arrêt d'urgence de certains équipements dans cette zone.
Le porte-parole de Global Switch a déclaré ceci : « Un départ d’incendie s'est déclaré ce matin dans une salle de l’un des deux centres de données de notre site parisien. Les pompiers sont intervenus rapidement et l'incendie est désormais maitrisé. Les dispositifs anti-incendie du bâtiment ont parfaitement fonctionné, personne n'a été blessé. Le service de certains de nos clients a été temporairement affecté et notre équipe sur site travaille à le rétablir le plus rapidement possible ».
-
Hmm si ? Y a eu des retours détaillés sur frnog.
Problème de pompe d'eau du circuit de refroidissement, ce qui a généré une
accumulation de d'eau et qui a déclenché la fuite.
L'eau de la fuite est descendue sur le local batterie et a provoqué un
incendie.
Le directeur du site de GS est toujours en discussion avec les pompiers
pour savoir si ils coupent completement le courant du batiment concerné
pour l'intervention des pompiers.
Pas de fummée dans les autres salles, c'est confiné à la salle technique où
se trouvent les batterie.
Les pompiers sont obligés de laisser bruler les batteries avant
d'intervenir.
https://www.mail-archive.com/frnog@frnog.org/msg72320.html
https://www.mail-archive.com/frnog@frnog.org/msg72330.html
https://www.mail-archive.com/frnog@frnog.org/msg72334.html
-
Est-ce que quelqu'un sait nous dire si l'incident a impacté les 3 "Availability zones" de Google à Paris, simultanément?
* europe-west9-a
* europe-west9-b
* europe-west9-c
Si c'est le cas, et si les acteurs impactés avaient bien une redondance répartie sur plusieurs zones, alors la faute est 100% chez Google!
C'était bien la promesse du concept d'Availability-Zones : des zones indépendantes les unes des autres, et redondantes entre elles, permettant d'atteindre une disponibilité extrêmement élevée, dans le cas d'une infra client redondée sur plusieurs zone.
Leon.
-
La communication de Google Cloud à 21h40 (traduite en Français) :
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_11.webp)
-
Ca fait beaucoup là non ?
-
Hmm si ? Y a eu des retours détaillés sur frnog.
Exact. Voici les informations diffusées :
10h21 :
Problème de pompe d'eau du circuit de refroidissement, ce qui a généré une accumulation de d'eau et qui a déclenché la fuite.
L'eau de la fuite est descendue sur le local batterie et a provoqué un incendie.
Le directeur du site de GS est toujours en discussion avec les pompiers pour savoir si ils coupent completement le courant du batiment concerné pour l'intervention des pompiers.
Pas de fummée dans les autres salles, c'est confiné à la salle technique où se trouvent les batterie.
Les pompiers sont obligés de laisser bruler les batteries avant d'intervenir.
Prochain point à 11h
11h38 :
La climatisation est revenue et la température dans les salle sont à nouveau OK.
Le local batteries du niveau 1 au sous-sol n'est pas accessible par les pompiers. Ils refroidissent les parois pour contenir le feu mais l'incendie n'est toujours pas maîtrisé.
La coupure électrique est toujours envisagée.
13h : Communication officielle sur Linkedin (https://www.linkedin.com/posts/global-switch_statement-in-relation-to-incident-in-our-activity-7056941925844541440-kzzQ)
Information Suite A L’incident Survenu sur Notre Site de Paris
Un départ d’incendie s'est déclaré ce matin dans une salle de l’un des deux centres de données de notre site parisien. Les pompiers sont intervenus rapidement et l'incendie est désormais maitrisé. Les dispositifs anti-incendie du bâtiment ont parfaitement fonctionné, personne n'a été blessé. Le service de certains de nos clients a été temporairement affecté et notre équipe sur site travaille à le rétablir le plus rapidement possible.
15h15 :
Il semblerait que certaines équipes techniques puissent rentrer dans des salles du L5. Je vous tiens au courant si l'accès redevient possible pour tout le monde.
15h19 :
L’incendie est éteint.
Les pompiers ne peuvent pas encore accéder à la salle des onduleurs/batteries du niveau 1 car la température à l’intérieur était à plus de 65°C (il y a 1h).
Au niveau des impacts, la MRR étant accolée à la salle qui a bien chauffé, l'opérateur Zayo aurait été touché.
Les onduleurs/batteries qui ont brulés sont dédiés au niveau 1 donc les autres niveaux ne sont pas concernés par d'éventuels problèmes de power.
17h22 :
Meeting de crise de 17h00 anticipé à 16h30 suite GO de Global Switch :
Pas de coupure planifiée sur PAR E (cooling/électricité)
L’infrastructure technique est opérationnelle (clim, électricité, sparkshield, …)
Tous les clients de Clichy 1 peuvent donc redémarrer leurs serveurs
Les niveaux L4, L5 et L6 sont accessibles pour les clients MAIS avec un accompagnant GS
Les bureaux sont accessibles à tous
Le L1 (onduleurs et MMR1) reste sous surveillance, seuls les Sapeurs-Pompiers sont autorisés à y pénétrer -> attente de leur validation
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_resume.webp)
-
Si on regarde l'incendie, c'est catastrophique pour Google qui a eu une cascade d'incidents.
Pour Global Switch Clichy, il ne s'en sort pas trop mal avec un seul étage HS, l'étage 1. Il y a eu des pannes de climatisation aux étages supérieurs, mais pas de coupure électrique. C'est quand même une prouesse de continuer à faire tourner les serveurs dans un bâtiment où une salle batterie est en feu.
Un facteur à participer à limiter l'impact : la salle au niveau 1 (ou au sous-sol). L'impact aurait été peut-être été différent si c'était la salle batterie de 4ème étage qui avait pris feu, vu les quantités d'eau déversé par les pompiers pour refroidir les murs, je pense qu'il aurait fallu éteindre le bâtiment.
Quelle était la technologie de batterie ? Au plomb ? On voit qu'il n'a pas été possible d'éteindre l'incendie : les pompiers ont laissé brûler en empêchant la propagation. Les murs coupe-feu ont montré toute leur efficacité, même au-delà de 2 heures.
-
Espérons que « l’épidémie d’incendies de locaux de batteries » cesse car cela commence à faire beaucoup.. :-\
Espérons également que tous les exploitants de centres de données aient bien pris conscience que ces locaux batteries sont des endroits très critiques et qu’ils sont à surveiller de très près et à construire dorénavant le plus loin possible des infrastructures.
Sans cela, les exploitants s’exposent à de tragiques conséquences d’un point de vu opérationnel, matériel, financier, humain ou réputationnel.
-
Ce matin Google communique sur une amélioration, avec des services europe-west9 de nouveau disponible. On ne sait pas pourquoi la perte d'une datacenter sur les trois que comporte europe-west9 a été à ce point catastrophique.
- europe-west9-a = Global Switch Clichy
- europe-west9-b = autre availability zone en région parisienne non affectée par l'incendie
- europe-west9-c = autre availability zone en région parisienne non affectée par l'incendie
Résumé : plusieurs services Google Cloud dans la région europe-west9 sont concernés.
Description : une intrusion d'eau dans un centre de données en europe-west9 a provoqué une défaillance multi-cluster qui a entraîné l'arrêt de plusieurs zones. Nous nous attendons à une certaine indisponibilité dans la région europe-west9. Il n'y a pas actuellement d'ETA pour la reprise complète des opérations dans la région europe-west9. Nous nous attendions à une interruption prolongée de certains services. Les clients sont invités à basculer vers d'autres régions s'ils sont concernés.
Les services suivants ont entièrement récupéré en europe-west9 : Google Cloud Storage (GCS) Cloud Key Management Service (KMS) Cloud Identity and Access Management (IAM) Google Kubernetes Engine (GKE)
Les services suivants ont récupéré dans europe-west9-b et europe-west9-c, mais continuent d'être impactés dans europe-west9-a : Google Compute Engine (GCE) Cloud Run Google Cloud Load Balancer (GCLB) DataProc Cloud SQL
Cloud Console : panne globale, qui a été atténuée. Les tâches de gestion devraient être à nouveau opérationnelles pour les opérations en dehors de la région touchée (europe-west9). L'impact principal a été observé du 2023-04-25 23:15:30 PDT au 2023-04-26 03:38:40 PDT.
GCE Global Control Plane : a connu une panne globale, qui a été atténuée. L'impact principal a été observé du 2023-04-25 23:15:20 PDT au 2023-04-26 03:45:30 PDT et a impacté les clients utilisant Global DNS (gDNS). Un impact mondial secondaire pour les échecs d'opération de liste agrégée pour les clients disposant de ressources en europe-west9 a également été atténué. Veuillez consulter le guide de migration de gDNS vers le DNS zonal pour plus d'informations : https://cloud.google.com/compute/docs/internal-dns#migrating-to-zonal
Cloud Pub/Sub : pour plus d'informations sur l'impact continu de Cloud Pub/Sub, veuillez consulter le dernier état ici : https://status.cloud.google.com/incidents/j6LfsjxCXhVDjmGGPhS7#2c2sBHWU84yPDJ8y1ar4
BigQuery : le problème avec Google BigQuery a été résolu pour tous les utilisateurs concernés depuis le mercredi 26/04/2023 à 17h05, États-Unis/Pacifique. Pour plus d'informations, veuillez consulter ici : https://status.cloud.google.com/incidents/TbcwMSkKy8MTmeeEiqaq#scTMecZFsPpiygYrQ9sG
Nous fournirons une mise à jour d'ici le jeudi 2023-04-27 03:00 US/Pacific, ou lors de tout développement significatif.
Diagnostic : les clients peuvent ne pas être en mesure d'accéder aux ressources Cloud dans la région europe-west9.
Solution : les clients peuvent basculer vers des zones situées dans d'autres régions.
-
Ce matin Google communique sur une amélioration, avec des services europe-west9 de nouveau disponible. On ne sait pas pourquoi la perte d'une datacenter sur les trois que comporte europe-west9 a été à ce point catastrophique.
- europe-west9-a = Global Switch Clichy
- europe-west9-b = autre datacenter en région parisienne non affecté par l'incendie
- europe-west9-c = autre datacenter en région parisienne non affecté par l'incendie
Qu'est-ce qui te permet d'affirmer que west9-b et west9-c sont dans d'autres datacenters, hors du campus de Global Switch ?
Global Switch évoque (https://www.globalswitch.fr/about-us/news/26-04-23-statement-in-relation-to-incident-in-our-paris-campus/) "un départ d’incendie (...) dans une salle de l’un des deux centres de données de notre site parisien".
Par ailleurs, il me semble qu'une zone GCP doit être considérée comme "un domaine de défaillance unique au sein d'une région". Si Global Switch avait indiqué à Google que concernant les adductions électriques, réseau et le froid, il n'y avait pas de SPOF entre des salles distinctes du campus, plusieurs zones GCP ont pu être déployées sur ce site.
-
Qu'est-ce qui te permet d'affirmer que west9-b et west9-c sont dans d'autres datacenters, hors du campus de Global Switch ?
Global Switch évoque (https://www.globalswitch.fr/about-us/news/26-04-23-statement-in-relation-to-incident-in-our-paris-campus/) "un départ d’incendie (...) dans une salle de l’un des deux centres de données de notre site parisien".
Par ailleurs, il me semble qu'une zone GCP doit être considérée comme "un domaine de défaillance unique au sein d'une région". Si Global Switch avait indiqué à Google que concernant les adductions électriques, réseau et le froid, il n'y avait pas de SPOF entre des salles distinctes du campus, plusieurs zones GCP ont pu être déployées sur ce site.
+1
Les "availability zones" ne sont pas forcément des datacenters différents. Pour moi, il faut que tu modifies ton texte, Vivien, pour parler d'availability zone, et non de datacenter.
Il est très probable que ces "availability zones" soient dans des zones différentes du même datacenter.
Leon.
-
J'ai corrigé, mais availability zone est un terme technique qui limite la compréhension du geek moyen.
Ceux qui ne sont pas du métiers ne comprennent pas le terme.
Oui, deux availability zone peuvent être deux salles dans un même datacenter, même si souvent les acteurs essayent d'avoir au minimum des bâtiments différents.
-
Il est très probable que ces "availability zones" soient dans des zones différentes du même datacenter.
C'est pour ça que je ne suis pas complètement d'accord avec ce que tu as écrit hier :
Si c'est le cas, et si les acteurs impactés avaient bien une redondance répartie sur plusieurs zones, alors la faute est 100% chez Google!
La faute est dans ce cas partagée avec Global Switch qui n'a pas respecté une "promesse" d'isolation entre des salles du même campus.
-
Payplug, la solution de paiement utilisée par de nombreux sites web marchants, dont Scaleway et qui est resté en panne toute la journée d'hier (ce n'est pas encore totalement rétabli) parlait aussi de datacenter pour parler d'availability zones :
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_13.webp)
-
Qu'est-ce qui te permet d'affirmer que west9-b et west9-c sont dans d'autres datacenters, hors du campus de Global Switch ?
https://www.lemondeinformatique.fr/actualites/lire-google-cloud-sous-l-eau-suite-a-un-incendie-chez-global-switch-clichy-90281.html (https://www.lemondeinformatique.fr/actualites/lire-google-cloud-sous-l-eau-suite-a-un-incendie-chez-global-switch-clichy-90281.html)
Pour rappel, il s’agit de l’un des plus gros datacenters de la région parisienne aux côtés d’Interxion et Equinix. Google Cloud est présent dans 4 zones autour de Paris : chez Interxion (à la Courneuve), chez GlobalSwitch (à Clichy), chez Data4 (à Marcoussis) et chez Telehouse (à Paris).
Et concernant l'incident en cascade sur les autres zones de la région :
Dans son diagnostic, la firme ajoute qu’au-delà de l’incapacité des clients à accéder aux ressources Cloud dans la région europe-ouest9, ceux qui utilisent Cloud Console dans le monde ne peuvent pas ouvrir ni afficher les pages associées à Compute Engine. Cela concerne notamment la page de création d'instance, la page de création de disque, la page des modèles d'instance, la page des groupes d'instances. En guise de solution, « les clients peuvent basculer vers des zones situées dans d'autres régions. Le client doit utiliser les commandes gcloud au lieu de Cloud Console pour les tâches de gestion ». A 14h52, la firme de Mountain View indique que pour les tâches de gestion, la console Cloud devrait être à nouveau opérationnelle pour les opérations en dehors de la région affectée (europe-west9).
-
https://www.lemondeinformatique.fr/actualites/lire-google-cloud-sous-l-eau-suite-a-un-incendie-chez-global-switch-clichy-90281.html (https://www.lemondeinformatique.fr/actualites/lire-google-cloud-sous-l-eau-suite-a-un-incendie-chez-global-switch-clichy-90281.html)
Pour rappel, il s’agit de l’un des plus gros datacenters de la région parisienne aux côtés d’Interxion et Equinix. Google Cloud est présent dans 4 zones autour de Paris : chez Interxion (à la Courneuve), chez GlobalSwitch (à Clichy), chez Data4 (à Marcoussis) et chez Telehouse (à Paris).
Pour moi c'est pas forcément clair que les AZ sont dans d'autres DC.
-
Pour moi c'est pas forcément clair que les AZ sont dans d'autres DC.
C'est vrai que le Monde Informatique peut être sujet à question car il évoque 4 zones alors qu'il n'en existe que 3.
Autre source allant dans le sens de sites distants (le commentaire sur la résilience et la tolérance aux pannes fait rire jaune à postériori) :
https://siecledigital.fr/2022/07/01/google-cloud-ouvre-sa-nouvelle-region-en-france/ (https://siecledigital.fr/2022/07/01/google-cloud-ouvre-sa-nouvelle-region-en-france/)
Basée intégralement en Île-de-France, l’infrastructure proposée par Google Cloud comporte trois zones de disponibilité (AZ) réparties dans trois centres de données différents, distants d’au moins dix kilomètres les uns des autres. Ces AZ promettent de proposer une architecture résiliente, tolérante aux pannes, offrant une haute disponibilité, tout en étant au mieux protégé contre les défaillances inattendues. Il ne sera pas possible pour les clients de Google Cloud de choisir leur AZ, tout comme pour les régions France de Microsoft et Oracle.
(https://lafibre.info/images/datacenter/202207_siecledigital_google_cloud_ouvre_sa_region_en_france.webp)
-
Pour moi c'est pas forcément clair que les AZ sont dans d'autres DC.
Il ya surtout une contradiction dans l'article entre :
Google Cloud est présent dans 4 zones autour de Paris : chez Interxion (à la Courneuve), chez GlobalSwitch (à Clichy), chez Data4 (à Marcoussis) et chez Telehouse (à Paris).
et
L'intrusion d'eau dans europe-west9-a a provoqué une défaillance de plusieurs clusters et a entraîné l'arrêt d'urgence de plusieurs zones
Pourquoi un "arrêt d'urgence" d'une infrastructure à distance du site touché par l'incendie ?
-
Pourquoi un "arrêt d'urgence" d'une infrastructure à distance du site touché par l'incendie ?
Tu peux avoir plusieurs DC mais un SPOF au niveau du réseau ou autre.
-
Tu peux avoir plusieurs DC mais un SPOF au niveau du réseau ou autre.
Un éventuel SPOF peut créer une indisponibililté mais ne nécessite pas un "arrêt d'urgence".
GCP indique "Water intrusion in a data center in europe-west9 caused a multi-cluster failure that led to a shutdown of multiple zones". Ce qui est insuffisant pour comprendre ce qu'il s'est passé réellement.
-
https://www.lemondeinformatique.fr/actualites/lire-google-ouvre-enfin-ses-datacenters-en-france-87237.html (https://www.lemondeinformatique.fr/actualites/lire-google-ouvre-enfin-ses-datacenters-en-france-87237.html)
En tout, trois zones de disponibilité dans trois datacenters sont annoncées. « Il y a trois zones réparties autour de Paris avec des distances de sécurité nécessaires et suffisantes », fait savoir Anthony Cirot. 70 km selon les critères habituels de Google Cloud.]En tout, trois zones de disponibilité dans trois datacenters sont annoncées. « Il y a trois zones réparties autour de Paris avec des distances de sécurité nécessaires et suffisantes », fait savoir Anthony Cirot. 70 km selon les critères habituels de Google Cloud.
Il sera difficile de savoir avec précision dans quels DC sont les zones, sauf en cas d'incident évidemment ;D.
C'est le même souci avec d'autres acteurs qui restent évasifs quand on leur pose la question (j'ai eu le cas avec Oracle OCI à Francfort).
On sera tous d'accord qu'idéalement, la meilleure architecture de PRA doit être basée sur 2 fournisseurs Cloud distincts sur deux régions distinctes, mais c'est beaucoup plus compliqué à concevoir qu'une simple réplication entre deux zones d'un même fournisseur avec un outillage unifié.
-
Il faudrait donc élucider l'heure du départ, car le graphique mentionne clairement 4h et non 5h pour la coupure de climatisation
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_14.webp)
Pour info voila ce qu'on avait sur les inlets de nos servers (salle florence) et c'est en UTC donc le 1er pic etait à 5h GMT+1 et le 2eme à 10h GMT+1
-
Merci. Le problème serait donc plus à 3h UTC (5h) et pas 3h heure locale.
C'est quel niveau la salle florence ? L2, L3, L4 ou L5 ?
-
Merci. Le problème serait donc plus à 3h UTC (5h) et pas 3h heure locale.
Ca commence à monter à partir de 4h avec pic à 5h heure locale oui
C'est quel niveau la salle florence ? L2, L3, L4 ou L5 ?
L2
-
Hello,
Effectivement Google est bien présent dans 4 datacenters différents sur Paris pour avoir monté le produit Google Cloud Interconnect Partner chez un opérateur.
Je suppose qu'ils ont aussi des ressources pour les autres produits dans les ces quatre là.
Vous avez ici la liste ici : https://cloud.google.com/network-connectivity/docs/interconnect/concepts/choosing-colocation-facilities?hl=fr
- Interxion Paris 7 (La Courneuve)
- Global Switch (Paris)
- DATA4 Paris Marcoussis
- Telehouse - Paris 2 (Voltaire - Léon Frot)
-
- Interxion Paris 7 (La Courneuve)
- Global Switch (Paris)
- DATA4 Paris Marcoussis
- Telehouse - Paris 2 (Voltaire - Léon Frot)
Il me semble que ce sont les intercos, pas les localisations des service cloud (engine, etc).
Je crois qu'il n'y a que 3 zones sur la région en question.
Elles sont j'imagine sur 3 de ces 4 DC.
-
Telehouse2 serait uniquement un POP réseau.
-
On me dit que les batteries de Global Switch Clichy seraient... des batteries au lithium ! (comme au Maxnod)
Chaque technologie a ses avantages et ses inconvénients.
Les avantages du lithium :
- Encombrement 1,8x inférieur au plomb
- 3x plus léger que les batteries au plomb
- Capacité constante à tous niveaux de puissance
- Durée de vie Environ 10x supérieure en nombre de cycles
- La charge des batteries Lithium a un rendement proche de 100% alors que le plomb avoisine 80%
- Les batteries Lithium-ion sont bien plus performantes à basse température que celles au plomb
- Les batteries Lithium peuvent être déchargées quasi totalement (de 90% à 100%) sans se dégrader
- Pas de production de gaz en charge
Ces points expliquent pourquoi les voitures électriques sont toutes au lithium. Maintenant, c'est pas forcément des avantages décisifs en datacenter ou les batteries ne sont utilisées qu'en cas de coupure de courant.
Les inconvénients du lithium :
Les batteries lithium ont un risque plus important d'incendie et en emballement, elles génèrent du comburant, beaucoup de chaleur et leur électrolyte est combustible. C'est impossible à éteindre.
Par rapport au cloisonnement de batteries au plomb il y a statistiquement très peu d'incendie / explosion de ce type de batterie, raison pour laquelle on peut en aligner des tonnes sans que ça ne pose de gros problèmes aux assureurs jusqu'ici.
Le problème vient plutôt du fait que les batteries au plomb génèrent de l'hydrogène pendant leur cycle de charge, donc trop de cloisonnement peut aussi être un facteur de risque, surtout en cas de mauvaise ventilation, le moindre court circuit va générer une explosion, pas de la batterie mais du gaz qui l'entoure.
-
Pour se cultiver sur ce type de bombes, un fil intéressant
https://forums.futura-sciences.com/electronique/754239-discutons-batteries-lithium-faire-faire-securite.html
et un pdf récapitulatif : https://forums.futura-sciences.com/attachments/electronique/334015d1486202403-discutons-batteries-lithium-faire-faire-securite-debut_lithium_hulk_002_45.pdf
-
https://www.lemondeinformatique.fr/actualites/lire-google-ouvre-enfin-ses-datacenters-en-france-87237.html (https://www.lemondeinformatique.fr/actualites/lire-google-ouvre-enfin-ses-datacenters-en-france-87237.html)
En tout, trois zones de disponibilité dans trois datacenters sont annoncées. « Il y a trois zones réparties autour de Paris avec des distances de sécurité nécessaires et suffisantes », fait savoir Anthony Cirot. 70 km selon les critères habituels de Google Cloud.]En tout, trois zones de disponibilité dans trois datacenters sont annoncées. « Il y a trois zones réparties autour de Paris avec des distances de sécurité nécessaires et suffisantes », fait savoir Anthony Cirot. 70 km selon les critères habituels de Google Cloud.
Il sera difficile de savoir avec précision dans quels DC sont les zones, sauf en cas d'incident évidemment ;D.
C'est le même souci avec d'autres acteurs qui restent évasifs quand on leur pose la question (j'ai eu le cas avec Oracle OCI à Francfort).
On sera tous d'accord qu'idéalement, la meilleure architecture de PRA doit être basée sur 2 fournisseurs Cloud distincts sur deux régions distinctes, mais c'est beaucoup plus compliqué à concevoir qu'une simple réplication entre deux zones d'un même fournisseur avec un outillage unifié.
Pour moi, c'est totalement anormal ce manque de communication sur la localisation physique exacte des services cloud, malgré les "availability zones".
Si les cloud-provider veulent vraiment promouvoir le "multi cloud" comme ils le disent tous depuis quelques années, alors il faut impérativement qu'ils communiquent sur les localisations exactes
* des serveurs
* des points d'interconnection
La localisation exacte incluant le datacenter, et la salle du datacenter.
C'est la seule manière pour les clients de savoir s'ils montent une architecture multi-cloud réellement redondante, résiliente, ou non.
Et quasiment tous les gros acteurs sont en faute sur le sujet
- les Google / AWS
- OVH avec Strasbourg : il était impossible de comprendre quelles salles du datacenter étaient utilisées pour les VM, les backup
- Scaleway avec leur "DC5 bis" qui était dans un datacenter tiers dont ils n'ont jamais officiellement publié le nom
- etc...
Leon.
-
Pour moi, c'est totalement anormal ce manque de communication sur la localisation physique exacte des services cloud, malgré les "availability zones".
Si les cloud-provider veulent vraiment promouvoir le "multi cloud" comme ils le disent tous depuis quelques années, alors il faut impérativement qu'ils communiquent sur les localisations exactes
* des serveurs
* des points d'interconnection
C'est la seule manière pour les clients de savoir s'ils montent une architecture multi-cloud réellement redondante, résiliente, ou non.
Et quasiment tous les gros acteurs sont en faute sur le sujet
- les Google / AWS
- OVH avec Strasbourg : il était impossible de comprendre quelles salles du datacenter étaient utilisées pour les VM, les backup
- Scaleway avec leur "DC5 bis" qui était dans un datacenter tiers dont ils n'ont jamais officiellement publié le nom
- etc...
Leon.
On est d'accord.
-
Pourquoi ?
Dans tout rapport fournisseur, il y a une notion de confiance
Je ne demande pas le code source utilisé par ma banque : je fais confiance
C'est pareil pour les datacenters
-
Curieux la non dispo d'un systeme de paiement.
Les docs GCP précisent pourtant bien de faire du multi-region si on veut de la haute dispo et de la reprise...
https://cloud.google.com/architecture/framework/reliability/design-scale-high-availability#replicate_data_across_regions_for_disaster_recovery
-
Payplug, la solution de paiement utilisée par de nombreux sites web marchants, dont Scaleway et qui est resté en panne toute la journée d'hier (ce n'est pas encore totalement rétabli) parlait aussi de datacenter pour parler d'availability zones :
(https://lafibre.info/images/datacenter/202304_global_switch_clichy_incendie_13.webp)
A propos de Payplug, allez voir les avis trustpilot, c'est pas glorieux et en plus ils ne respectent pas leurs propres interdictions : https://support.payplug.com/hc/fr/articles/360021080112-Refus-d-entr%C3%A9e-en-relation-et-activit%C3%A9s-interdites
Qu'ils balancent à tout les mécontents ayant vu leur compte fermé et leur fonds bloqués (leurs pratiques vont jusqu'à contacter les clients des e-commerces pour leurs demander si ils ont reçu leur produit - édifiants les retours).
Services informatiques
- Plateformes pouvant être utilisées pour du piratage, par exemple le partage de fichiers vidéos, musicaux ou logiciels,
- Ventes de produits ou services informatiques pour lesquels le marchand ne disposerait pas des droits de diffusion (par exemple Antivirus),
- Services de VPN,
- Hébergement (cloud, etc.),
- Envois massifs d'emails.
Ce que Scaleway fait h24/7/365 !
Scaleway travaille avec Payplug depuis 13 ans !
https://twitter.com/a_bermingham/status/1651299467927093258
-
Mais y'a t-il un seul acteur de l'informatique moderne qui soit un minimum sérieux ?
J'aime bien chier sur les "ingénieurs logiciel" mais là on est sur du hardware est c'est juste ridicule le degré d'incompétence.
Problème de pompe = pas de redondance sur la pompe.
Problème de batterie, sérieux, en 2023 ? On va faire simple, si tu peux pas faire dormir un bébé dessus en pleine confiance, le fout pas dans ton datacenter. J'ai jamais été sur site, mais j'ai des connaissances qui vont à Clichy semi-régulièrement. Ça me fait penser à un épisode de la série BUGS ou au premier Mission Impossible. Les gars se prennent pour des espions avec des contrôle d'accès à la con mais te laissent une bombe dans le bâtiment.
Mais qu'est ce qui empêche de foutre les batterie dans un autre bâtiment, hors de portée du premier.
Et pour Google, et les zones, c'est comme tout le Cloud, et l'IA, un jour va falloir arrêter de suivre les conneries du marketing. Si t'est pas foutu d'avoir les coordonnées GPS de ton serveur, tu sais pas ou il est, et donc tu ne sais rien, basta.
-
Pourquoi ?
Dans tout rapport fournisseur, il y a une notion de confiance
Je ne demande pas le code source utilisé par ma banque : je fais confiance
C'est pareil pour les datacenters
Bonjour Jack,
Tu as compris ce que j'essayais de dire?
Avec le "multi-Cloud", les clients doivent acheter des services cloud auprès de plusieurs acteurs différents.
S'ils achètent auprès de 2 acteurs qui sont situés dans le même datacenter, voire dans la même salle du même datacenter, ils ne le sauront pas forcément.
Du coup, impossible de garantir une vraie redondance/résilience dans ces conditions.
Leon.
-
Mais qu'est ce qui empêche de foutre les batterie dans un autre bâtiment, hors de portée du premier.
En zone très dense comme Clichy, cela semble difficilement possible. Il faut être réaliste.
Les groupes ont dû être mis sur le toit :
(https://lafibre.info/images/datacenter/202304_global_switch_clichy.jpg)
Même OVH qui cherche depuis l'incendie de Strasbourg à faire sortir tous les locaux batteries et onduleurs de ses datacenter n'arrive pas à le faire systématiquement et OVH demande même une dérogation pour un local batterie non accessible en façade, une obligation (depuis quand ?) :
Autres nouveautés mises en place par OVH :
Des plans d'intervention interne sont mis en place sur tous les sites, mais il y a un travail préparatoire avec les pompiers (SDIS ci-dessous, pour Service départemental d'incendie et de secours) au cas où...
Cela fait nul doute que l'électricité pourra être coupé rapidement si c'est nécessaire.
(https://lafibre.info/images/ovh/202207_sppi_ovh_gravelines_rex_incendie_strasbourg_5.webp)
À Global Switch Clichy la salle batterie n'était visiblement pas accessible en façade (elle est en sous-sol).
Ces incendies vont changer les pratique de construction de nouveaux DC.
-
Mais y'a t-il un seul acteur de l'informatique moderne qui soit un minimum sérieux ?
J'aime bien chier sur les "ingénieurs logiciel" mais là on est sur du hardware est c'est juste ridicule le degré d'incompétence.
Problème de pompe = pas de redondance sur la pompe.
Problème de batterie, sérieux, en 2023 ? On va faire simple, si tu peux pas faire dormir un bébé dessus en pleine confiance, le fout pas dans ton datacenter. J'ai jamais été sur site, mais j'ai des connaissances qui vont à Clichy semi-régulièrement. Ça me fait penser à un épisode de la série BUGS ou au premier Mission Impossible. Les gars se prennent pour des espions avec des contrôle d'accès à la con mais te laissent une bombe dans le bâtiment.
Mais qu'est ce qui empêche de foutre les batterie dans un autre bâtiment, hors de portée du premier.
Et pour Google, et les zones, c'est comme tout le Cloud, et l'IA, un jour va falloir arrêter de suivre les conneries du marketing. Si t'est pas foutu d'avoir les coordonnées GPS de ton serveur, tu sais pas ou il est, et donc tu ne sais rien, basta.
MilkyWan ? :P
-
A propos de Payplug, allez voir les avis trustpilot, c'est pas glorieux et en plus ils ne respectent pas leurs propres interdictions : https://support.payplug.com/hc/fr/articles/360021080112-Refus-d-entr%C3%A9e-en-relation-et-activit%C3%A9s-interdites
Qu'ils balancent à tout les mécontents ayant vu leur compte fermé et leur fonds bloqués (leurs pratiques vont jusqu'à contacter les clients des e-commerces pour leurs demander si ils ont reçu leur produit - édifiants les retours).
Services informatiques
- Plateformes pouvant être utilisées pour du piratage, par exemple le partage de fichiers vidéos, musicaux ou logiciels,
- Ventes de produits ou services informatiques pour lesquels le marchand ne disposerait pas des droits de diffusion (par exemple Antivirus),
- Services de VPN,
- Hébergement (cloud, etc.),
- Envois massifs d'emails.
Ce que Scaleway fait h24/7/365 !
Scaleway travaille avec Payplug depuis 13 ans !
https://twitter.com/a_bermingham/status/1651299467927093258
J'ai également été très surpris d'apprendre que Scaleway utilisait Payplug.
J'ai déjà eu l'occasion de travailler avec Payplug il y a quelques années, je ne peux que corroborer ces avis. Du grand n'importe quoi.
-
MilkyWan ? :P
Quel rapport ? On ne fait pas (peu) d'hébergement et globalement on fait le choix (assumé) de ne pas doubler le matos et d'accepter de perdre un DC
-
intéressant cet incendie et surtout l'impact pour les utilisateurs.
d'autres par l'incendie n'est pas très bien compris semble t il!
-
Pourquoi ?
Dans tout rapport fournisseur, il y a une notion de confiance
Je ne demande pas le code source utilisé par ma banque : je fais confiance
C'est pareil pour les datacenters
Sérieux ?
Quand j'étais petit ma cheffe me disait toujours "la confiance n'exclut pas le contrôle". Je pense qu'aujourd'hui c'est encore plus valable qu'à l'époque.
On peut croire que les commerciaux disent toujours la vérité et que nous vivons (et surtout, travaillons) dans un monde des bisounours, mais dans ce cas qu'ils se dénoncent pour que je ne fasse jamais appel à eux...
-
Pour moi, c'est totalement anormal ce manque de communication sur la localisation physique exacte des services cloud, malgré les "availability zones".
Si les cloud-provider veulent vraiment promouvoir le "multi cloud" comme ils le disent tous depuis quelques années, alors il faut impérativement qu'ils communiquent sur les localisations exactes
* des serveurs
* des points d'interconnection
La localisation exacte incluant le datacenter, et la salle du datacenter.
C'est la seule manière pour les clients de savoir s'ils montent une architecture multi-cloud réellement redondante, résiliente, ou non.
Et quasiment tous les gros acteurs sont en faute sur le sujet
- les Google / AWS
- OVH avec Strasbourg : il était impossible de comprendre quelles salles du datacenter étaient utilisées pour les VM, les backup
- Scaleway avec leur "DC5 bis" qui était dans un datacenter tiers dont ils n'ont jamais officiellement publié le nom
- etc...
Leon.
je ne sais pas pour OVH et Scaleway, mais Google et AWS communiquent clairement la dessus.
Si on sous-traitre a un cloud public ce n'est pas justement pour forcement connaitre précisément le DC, la localisation précise. On fait confiance a son hébergeur on suit sa doc (RTFM quoi).
Dans le cas présent ici, Google a de suite indiqué que toute la région était down et ils ont de suite bien annoncé:
Customers are advised to failover to other regions if they are impacted
Quand ton hébergeur, suite a un incident, te recommande de suite de basculer sur une autre région ce n'est pas anodin. loin de la.
Ils savaient que c'était grave et que cela allait prendre du temps a remonter.
Maintenant si t'avais pas prévu d'être multi-région parce que t'as pas lu la doc et mal compris ce qu'est une haute dispo a qui la faute ?
-
On me dit que les batteries de Global Switch Clichy seraient... des batteries au lithium ! (comme au Maxnod)
Chaque technologie a ses avantages et ses inconvénients.
...
Les inconvénients du lithium :
Les batteries lithium ont un risque plus important d'incendie et en emballement, elles génèrent du comburant, beaucoup de chaleur et leur électrolyte est combustible. C'est impossible à éteindre.
Et aussi, nettement plus chères que les batteries au plomb (j'ai essayé d'acheter un onduleur lithium/ion, c'était nettement plus cher qu'avec une batterie plomb).
-
L'argument économique doit comparer puissance identique et sur une même période d'utilisation.
Les batteries au plomb nécessitent d'être remplacée plus fréquemment.
J'ai entendu des exploitants de datacenter dire que le lithium revenait moins cher.
-
Quel rapport ? On ne fait pas (peu) d'hébergement et globalement on fait le choix (assumé) de ne pas doubler le matos et d'accepter de perdre un DC
en réponse à : Mais y'a t-il un seul acteur de l'informatique moderne qui soit un minimum sérieux ?
rien de plus rien de moin
-
L'argument économique doit comparer puissance identique et sur une même période d'utilisation.
Les batteries au plomb nécessitent d'être remplacée plus fréquemment.
J'ai entendu des exploitants de datacenter dire que le lithium revenait moins cher.
La différence de prix se réduit ces 2-3 dernières années, mais les batteries Lithium restent plus chères à puissance identique (35% de plus environs), le gain économique lié à la durée de vie n'est pas garantis non plus. La plupart des fournisseurs d'onduleurs intègrent du Samsung avec des blocs de 67Ah, et poussent énormément à ce type de solution (sans doutes les marges sont plus élevées que les batteries au plomb, dont la valeur est en quasi totalité liée au coût des matières premières).
Bien évidemment les assureurs sont totalement opposés au déploiement de ce type de solution, donc généralement les constructeurs fournissent des attestations et certificats concernant le délicat sujet de l'emballement thermique des batteries Lithium ... (et il faut croire que ça marche avec certains DC ...)
-
Pour moi, c'est totalement anormal ce manque de communication sur la localisation physique exacte des services cloud, malgré les "availability zones".
Si les cloud-provider veulent vraiment promouvoir le "multi cloud" comme ils le disent tous depuis quelques années, alors il faut impérativement qu'ils communiquent sur les localisations exactes
* des serveurs
* des points d'interconnection
La localisation exacte incluant le datacenter, et la salle du datacenter.
C'est la seule manière pour les clients de savoir s'ils montent une architecture multi-cloud réellement redondante, résiliente, ou non.
je ne sais pas pour OVH et Scaleway, mais Google et AWS communiquent clairement la dessus.
Si on sous-traitre a un cloud public ce n'est pas justement pour forcement connaitre précisément le DC, la localisation précise. On fait confiance a son hébergeur on suit sa doc (RTFM quoi).
Euh, tu as vraiment lu mon message précédent auquel tu réponds? J'ai l'impression que non.
Si le client veut faire de la redondance avec du "multi-cloud", il fait comment? Comment peut-il savoir si ses instances achetées auprès de 2 cloud-provider différents sont dans le même datacenter ou non? Comment savoir s'il y a un SPOF entre 2 cloud-providers?
La seule solution serait que les cloud-providers communiquent sur la localisation exacte (Datacenter + Salle) de chaque service.
Leon.
-
La seule solution serait que les cloud-providers communiquent sur la localisation exacte (Datacenter + Salle) de chaque service.
Et les Telcos sur le cheminement de leurs adductions ?
-
Y a pas forcément besoin de connaitre la localisation exacte.
Par contre, j'imagine aisément que si le prestataire de paiement a tout foutu dans la même "region", c'est notamment pour avoir des coûts moindres. J'ai souvenir que mettre des VM multi-régionalisées, le transfert entre elles était douloureux pour les fesses.
Quant à sortir carrément du réseau du provider, là, ça pique comme jamais sur la facture.
-
Simon, une personne du forum qui a pas mal d'expérience dans les systèmes de stockage d'énergie argumente pour expliquer que le départ du feu à Global Switch Clichy pourrait être lié à de l'eau sur un onduleur et non de l'eau sur les batteries.
Il n'a pas d'information sur ce qu'il s'est passé à Global Switch Clichy, il se base uniquement sur ses connaissances et son expérience :
Une batterie li-ion (ou plomb d'ailleurs) ne prendrait pas feu au contact de l'eau car la conductivité de l'eau ne serait pas suffisante pour créer un court-circuit. Peut-être avec une eau très conductrice (salée, bourrée d'impuretés, etc.) à la limite, mais honnêtement, je n'y crois pas. Chimiquement, il n'y a pas de réaction avec l'eau.
J'ai été dans des containers remplis de rack li-ion sur lesquels l'eau du circuit de refroidissement avait coulé (eau glycolée) sans que ça ne pose de problème particulier. Normalement, un contrôleur d'isolement détectera la chute de la résistance d'isolement bien avant qu'un court-circuit ne se produise et mettra le système en sécurité en ouvrant tous les contacteurs.
LG-Chem fournit pour leurs racks batterie des systèmes d'extinction incendie par noyage des modules en cas de dégagement de chaleur détecté. Tu penses bien que ce système ne serait pas bien efficace si cela suffisait à créer un court circuit :-)
Par contre, côté onduleurs, l'eau peut largement altérer multiples signaux de commande (car ces signaux sont très faibles), et là :
- soit on fait un shoot trough, où l'un des deux IGBT reste fermé ou se ferme alors qu'il devrait être ouvert, et on connecte directement le + et le - de la batterie, créant ainsi un court-circuit de plusieurs dizaines de milliers d'ampères (~6000-8000 ampères de courant de court-circuit par rack, habituellement),
- soit un IGBT se ferme à moitié à la place de se fermer totalement, chauffe très rapidement du fait de l'effet de joule et explose/prend feu,
- soit on va perturber les mesures de tension/courant, auquel cas l'onduleur va générer un courant et/ou appliquer une tension anormalement élevée, générant un échauffement des batteries,
- pas mal d'autres trucs auxquels je pourrais penser, mais qui sont non triviaux à expliquer :)
D'ailleurs, sur frnog, Ludovic Scotti disait (https://www.mail-archive.com/frnog@frnog.org/msg72330.html) : "Les onduleurs/batteries qui ont brulés sont dédiés au niveau 1 donc les autres niveaux ne sont pas concernés par d'éventuels problèmes de power."
Si les onduleurs ont brulés avec les batteries, ils étaient colocalisés dans la même salle. Un feu d'onduleur qui se propage aux batteries me semble bien plus probable qu'un feu de batterie déclenché par une fuite d'eau.
-
Si le client veut faire de la redondance avec du "multi-cloud", il fait comment? Comment peut-il savoir si ses instances achetées auprès de 2 cloud-provider différents sont dans le même datacenter ou non? Comment savoir s'il y a un SPOF entre 2 cloud-providers?
La seule solution serait que les cloud-providers communiquent sur la localisation exacte (Datacenter + Salle) de chaque service.
Le "multi-cloud" dans un objectif de redondance n'a aucun sens
Le multi-cloud a du sens dans un objectif d'utiliser les meilleurs services de chacun
Comme le dit kgersen, si tu veux de la redondance plus importante, la bonne méthode est d'aller sur plusieurs régions
Quant à l'incident en question, il ne faut pas non plus se prendre la tête ..
La solution parfaite n'existe pas, et nous avons déjà plein d'exemple permettant de souligner l'absurdité du "100% dispo" (un CDN tombe -> plusieurs providers tombent -> ton machin tombe, par exemple ?)
Quand les providers promeuvent le multicloud, ils ne sont pas pour intrinséquement
Ce qu'ils veulent, c'est que toi, qui est chez X, on te facilite la vie pour venir chez moi
Le fait de faciliter ton transfert de chez moi vers Y est un effet de bord qui n'est pas du tout désiré
L'argument économique doit comparer puissance identique et sur une même période d'utilisation.
Les batteries au plomb nécessitent d'être remplacée plus fréquemment.
J'ai entendu des exploitants de datacenter dire que le lithium revenait moins cher.
Ces exploitants ont-ils bien pris en compte le coût d'un datacenter qui brûle ? Je taquine ;)
-
Euh, tu as vraiment lu mon message précédent auquel tu réponds? J'ai l'impression que non.
Si le client veut faire de la redondance avec du "multi-cloud", il fait comment? Comment peut-il savoir si ses instances achetées auprès de 2 cloud-provider différents sont dans le même datacenter ou non? Comment savoir s'il y a un SPOF entre 2 cloud-providers?
La seule solution serait que les cloud-providers communiquent sur la localisation exacte (Datacenter + Salle) de chaque service.
Leon.
Effectivement j'ai mal lu désolé.
Tu ne peux pas figer une instance sur un DC/Salle précis ... c'est tout le principe des public cloud providers multizone...(répartition/équilibrage/maintenance/upgrade au sein d'une meme zone qui peut être sur plusieurs DC/salles).
Apres la redondance multi-cloud c'est plus en mode d'avoir un scénario (PRA) prêt sur un autre provider que l'actif. Du coup c'est au moment du PRA que tu choisi un qui marche ...
Sinon y'a des trucs du style GCP Anthos mais j'ai pas de retex concret la dessus et ta question y reste valide.
-
Les wave EXA Infra qui passaient par Global Switch Clichy sont toujours down ce 29/04. Et ça ne va pas remonter tout de suite visiblement.
Update 25: (2023/04/28 16:45 UTC): EXA has received the following update from our site provider in relation to the current actions; Repair work and clean up of the facility: - Following the incident on the 26th April, there is a lot of smoke damage inside the facility - A section of dry wall has fallen onto Airco units inside the carrier room - Contractors are on site carrying out the clean up and repair operations. Due to air quality, for health and safety reasons they are required to wear protective gear. - Works are ongoing and this will take several days to complete (expected to be completed by Tuesday 2nd May) - Air quality tests will be performed following cleanup. Scheduled for Wednesday morning 3rd May. - If tests pass the H&S requirements, our site partner will provide an escorted access to EXA to support recovery process. Critical sparing: - EXA has confirmed critical sparing is in place to cover / replace all of our equipment if required. - Once the site is deemed safe to access, we will coordinate the full assessment and the path to recovery with local teams. We will continue to follow up with our partner for progress updates and will advise if there is any change to this expected timeline. Next update will be provided at 08:00 GMT on the 29th of April.
-
Chez GCP non plus, ça ne va pas remonter tout de suite selon leur bulletin (https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPfkY#73mBtVKKfeJGJ1yaY7hV) d'hier soir :
Impact is now limited to services in europe-west9-a. There is no ETA for full recovery of operations in europe-west9-a at this time. We expect to see extended outages for some services.
-
Maintenant si t'avais pas prévu d'être multi-région parce que t'as pas lu la doc et mal compris ce qu'est une haute dispo a qui la faute ?
Puisque de toute façon il faut faire une archi multi-région puisque les "availibility zone" ne sont pas des "availability zone". Quel est l’intérêt d'avoir plusieurs availability zone au sein d'une même région dans ce cas?
C'est même contre-productif. Pourquoi redonder sur les 3 AZ de la même région et augmenter les chances de panne sur la région s'il faut de toute façon faire son BCP sur une (voire deux, because quorum) autres régions?
-
Puisque de toute façon il faut faire une archi multi-région puisque les "availibility zone" ne sont pas des "availability zone". Quel est l’intérêt d'avoir plusieurs availability zone au sein d'une même région dans ce cas?
C'est même contre-productif. Pourquoi redonder sur les 3 AZ de la même région et augmenter les chances de panne sur la région s'il faut de toute façon faire son BCP sur une (voire deux, because quorum) autres régions?
+1
Sachant que certaines applications supportent mal la latence entre région, genre des base de données répliquées synchrones.
Demander au client de redonder entre régions, c'est mesquin.
La notion d'Availability Zone, c'est assez explicite, on est tous d'accord (sauf KGersen). Après, si aucun des cloud-provider ne sait / ne veut garantir une vraie indépendance entre ses Availability Zones d'une même région... On est mal.
Chez Scaleway, toutes les Availability Zones de Paris sont routées à DC3, et uniquement à DC3...
Et pour redonder avec plusieurs cloud-provider de la même région, il faudrait savoir où les AZ de chacun se situe très précisément.
Leon.
-
C'est une histoire du prix qu'on est prêt à mettre pour se protéger des risques.
Avoir de la redondance au sein d'une même AZ limite les risque, mais ne les éliminent pas.
On peut rappeler que les avions de Delta Airlines ont été cloués au sol dans le monde entier suite à... la perte d'une chaine électrique dans le datacenter où ils étaient hébergés. Ils avaient tous mis dans un même datacetner qui proposait deux chines électriques, mais il est supposé qu'ils n'avaient pas fait le nécessaire pour connecter tous les serveurs / swithcs aux deux chaines : La perte d'une chaine électrique a cloué les avions au sol.
=> Panne de Delta Airlines: l'analyse (incendie dans le datacenter sur une chaine) (https://lafibre.info/electricite/panne-de-delta-airlines-lanalyse/)
-
Avoir de la redondance au sein d'une même AZ limite les risque, mais ne les éliminent pas.
Vivien, on ne parle pas de redondance au sein d'une AZ ici.
Ici, dans ce fil de discussion, on parle d'indépendance entre les AZ d'une même région, d'absence de SPOF entre 2 AZ d'une même région. C'est très différent.
Désolé, mais la panne de Google du 26 avril est totalement anormale.
Leon.
-
Puisque de toute façon il faut faire une archi multi-région puisque les "availibility zone" ne sont pas des "availability zone". Quel est l’intérêt d'avoir plusieurs availability zone au sein d'une même région dans ce cas?
Le prix ? ;)
-
Le prix ? ;)
C'est à dire? Ça coûte moins cher a Google de faire des AZ que du mono-dc ?
-
C'est à dire? Ça coûte moins cher a Google de faire des AZ que du mono-dc ?
2 hypothèses d'interprétations
- Soit c'est du second degré de la part d'Optix, pour dire que ça sert à Google à facturer des trucs en plus à leur client... Même s'ils n'assurent pas derrière.
- Soit c'est pour rappeler que le trafic intra région, entre AZ est moins cher pour un client, par rapport à du traffic inter région.
Leon.
-
Le prix ? ;)
C'est une histoire du prix qu'on est prêt à mettre pour se protéger des risques.
Version courte:
Pour moi, ce n'est pas une question de prix. Combien de sociétés dépendantes de leurs infra, sont prêtes à la mettre sur une plateforme qui possède une dispo globale de 99,5%, même gratuitement? En dehors de mini-business ou de vente de seedbox, pas beaucoup à mon avis.
Je m'explique:
Je me réfère au status de l'incident: https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPfkY#73mBtVKKfeJGJ1yaY7hV
Google a réouvert la région (2 zones sur 3) au bout de 40h d'incident et la communication ne semble pas montrer de signe de remise en cause de leur offre (produits/tarif).
Depuis l'incident, Google reste droit dans ses baskets et ne semble pas se remettre en cause. Autrement dit, cet incident régional de 40h (quel-qu’en soit la cause) se reproduira.
Pour moi, ce n'est donc pas une question de prix. Je ne pense pas que beaucoup de sociétés acceptent un incident de 40h consécutives, alors même que ces sociétés auraient leur infra correctement HA sur les 3 zones de la région.
Quel est donc l’intérêt de dépenser du temps et de l'argent pour faire une archi redondante sur 3 zones d'une région qui possède une dispo global de 99,5%... avec l'épée de Damocles au dessus de la tête qui pourrait tomber et générer une indispo de 40h consécutive...
L'incident montre clairement que chez GCP, les zones d'une même région sont interdépendantes, et sont donc inutiles.
Une infra sur GCP doit donc être répartie sur plusieurs régions. D'où ma conclusion, sous forme de question rhétorique à kgersen. Les zones GCP sont inutiles, voire même contreproductive, étant donné qu'il faut de toute façon, prévoir une archi redondante sur 2, voire 3 régions.
-
Je ne sais pas pourquoi vous parlez d'"availability zone" concercant GCP... ce terme n'existe pas chez eux.
Ce terme vient d'AWS et ne concerne pas GCP. c'est peut-être la que y'a confusion ...
Il y a des zones et des régions mais pas d'"availability zones".cf: https://cloud.google.com/docs/geography-and-regions
A zone is a deployment area for Google Cloud resources within a region. Zones should be considered a single failure domain within a region. To deploy fault-tolerant applications with high availability and help protect against unexpected failures, deploy your applications across multiple zones in a region.
To protect against the loss of an entire region due to natural disaster, have a disaster recovery plan and know how to bring up your application in the unlikely event that your primary region is lost. See application deployment considerations for more information.
La reco c'est HA sur les zones et PRA sur une autre région ou meme HA sur plusieurs régions si on a un service critique comme un système de paiement.
La non dispo d'une région est donc rare mais pas impossible. Les contrats SLA de chaque service GCP prévoient d'ailleurs cela. Ceux concernés auront des remboursement si le downtime a dépassé le SLA.
-
Je ne sais pas pourquoi vous parlez d'"availability zone" concercant GCP... ce terme n'existe pas chez eux.
Ce terme vient d'AWS et ne concerne pas GCP. c'est peut-être la que y'a confusion ...
Il y a des zones et des régions mais pas d'"availability zones".cf: https://cloud.google.com/docs/geography-and-regions
La reco c'est HA sur les zones et PRA sur une autre région ou meme HA sur plusieurs régions si on a un service critique comme un système de paiement.
La non dispo d'une région est donc rare mais pas impossible. Les contrats SLA de chaque service GCP prévoient d'ailleurs cela. Ceux concernés auront des remboursement si le downtime a dépassé le SLA.
Sur le plan technique une zone GCP, c'est une quasi availability zone AWS, tu chipotes un peu là.
Une SLA, c'est juste contractuel, ça n'engage à rien techniquement. Par exemple, en réseau, une même connexion peut-être vendu avec une SLA de 99% ou 100%. Concernant l'application de la SLA pour les remboursements, encore heureux qu'ils l'appliquent, mais là n'est pas le débat.
Concernant les préco sur GCP, tu peux m'envoyer ton lien qui dit de faire son BCP sur les zone et le DRP sur les régions?
-
Je ne sais pas pourquoi vous parlez d'"availability zone" concercant GCP... ce terme n'existe pas chez eux.
[...]
La recommandation c'est H[igh] A[vailability] sur les zones et PRA sur une autre région ou meme HA sur plusieurs régions si on a un service critique comme un système de paiement.
OK, donc ça veut bien dire que les zones de GCP servent à faire de la "high availability", donc que ce sont des "availability zones" comme chez Azure ou AWS ou Scaleway.
Je ne vois pas pourquoi tu essayes de chipoter là dessus
Leon.
-
Sur le plan technique une zone GCP, c'est une quasi availability zone AWS, tu chipotes un peu là.
Chacun son avis la. Meme si c'est du marketing pour AWS, pour moi les termes ont du sens et mettre 'availability' dans la désignation c'est important , surtout de nos jours ou lire la doc est devenu optionnel pour certains.
Concernant les préco sur GCP, tu peux m'envoyer ton lien qui dit de faire son BCP sur les zone et le DRP sur les régions?
C'est indiqué dans le lien que j'ai fourni.
-
C'est indiqué dans le lien que j'ai fourni.
Je suis désolé mais la documentation que tu pointes dit l'inverse de ce que tu dis ici:
Les zones servent au déploiement des ressources Google Cloud dans une région. Elles doivent être considérées comme un domaine de défaillance unique au sein d'une région. Pour déployer des applications tolérantes aux pannes et à haute disponibilité, et être mieux protégé contre les défaillances inattendues, déployez vos applications sur plusieurs zones d'une région.
C'est très clair.
40h d'indispo, je n’appelle pas ça de la HA.
40h, c'est une éternité. Sur une infra correctement designée, ok un paramètre a sauté, le load balancer bascule pas, un gus a mis une route statiques, ou que sais-je, mais on trouve le problème qui empêche que ca switch, et on corrige. Au pire 1h après, c'est basculé. Là on parle de 40h, on dirait que les mecs ont juste attendus que les pompiers éteignent l'incendie en salle batterie et reboot les serveurs comme s'il ne s'était rien passé. Franchement, c'est la honte. Cet incident montre que by-design, l'infra n'est pas prévu, ni testé, pour que les zones soient comme ils l'écrivent dans leur doc: des domaines de défaillance uniques au sein d'une région
Pour empêcher la perte d'une région entière à la suite d'une catastrophe naturelle, vous devez disposer d'un plan de reprise après sinistre et savoir comment remettre en service votre application dans le cas peu probable de la perte de votre région principale.
Le cas de Global Switch n'est pas une catastrophe naturelle. C'est un "simple" incendie, mais ça aurait pu être une panne de clim, une panne électrique ou un coup de pelleteuse isolant la zone des deux autres, c'est pareil, perte d'une zone = perte de la région.
Et concernant le déclenchement d'un PRA/DRP, c'est facile de brandir cette carte. Mais un DRP est surtout prévu lors d'une perte définitive. Le déclenchement d'un PRA, c'est procédure de rebuild de la plateforme, restauration des backup, etc... Au niveau décisionnel, étant donné que la source est un incendie qui ne touche supposément qu'une zone, tout les voyants sont aux rouges quant à l'activation d'un PRA.
Et là, on ne parle que des Compute Engine qui est un service "zonale". Car GCP propose d'autres service comme du Pub/Sub, qui sont "régional". Donc perte de la région = perte du service, sans ne pouvoir rien y faire puisqu'on n'a pas la main dessus, c'est GCP qui doit déclencher son PRA... et qui ne l'a pas fait d'ailleurs.
-
Quel est l'objectif de cet échange, précisément ?
-
Quel est l'objectif de cet échange, précisément ?
Comme tous les topics qui dépassent 1 page: corriger l'Internet
-
Je ne sais pas ou il veut en venir.
Ceux qui utilisent GCP voient clairement a quoi sert une zone et une région (la plupart des services ne permettent pas de choisir la zone, que la région).
Par exemple si tu crée un bucket de storage tu choisi la région et si tu veut une réplication sur 2 régions ou plus. On ne choisi donc pas la zone.
(https://i.imgur.com/kPCBaD2.png)
Cela me semble clair comment se fait donc l'HA d'un storage.
Pourquoi des zones alors ?
Le choix de zone c'est pour des VMs par exemple (compute) qui en terme de HA ne se gèrent pas comme de la data de toute façon.
Apres si tu place au même niveau "HA storage" et "HA compute" c'est peut-être la qu'on tourne en rond... on n'est pas sur des services applicatifs managés mais sur des briques de bases d'infra.
Pour moi et depuis toujours donc une région GCP = un DC (meme si dans certains cas il peut y avoir plusieurs DC physiques). A partir de la on construit sa dispo avec cette notion. Si on est mono-DC ou pas = multi-region ou pas.
La perte de tout un DC est tres rare mais cela arrive. 40 heures c'est beaucoup mais y'a eu pire (cf OVH par exemple). Google a réagit vite en disant au gens d'activer leur PRA ce qui comme j'ai déjà indiqué n'est pas anodin loin de la.
En plus y'a PRA et PRA, j'en connais avec 3 niveaux de PRA différents suivant la gravité: bascule d'une zone a l'autre des computes par exemple.
Dans l'esprit : un PRA = je dois agir pour ma continuité de service, ce n'est pas 100% automatique ou géré par mon provider. Souvent de simple scripts suffisent pour reprendre ou basculer.
Si t'as une définition théorique/"ISO machin"/"ITIL truc" /grand groupe du CAC40 d'un PRA c'est sur qu'on se comprendra pas. De toute facon, en IT y'a rien de pire que les dogmes et les "best practices" des cabinets de conseil.
bref, on est sur un phénomène exceptionnellement rare , multi-facteurs et tu cherches un coupable unique. why ?
-
Quel est l'objectif de cet échange, précisément ?
Comme tous les topics qui dépassent 1 page: corriger l'Internet
+1
Il faut rétablir la vérité sur Internet, c'est notre mission! LOL
Notre ami KGersen prétend que les "zones" de GCP ne sont pas le même concept que les AZ d'AWS, et que ça ne sert pas à la disponibilité.
Je ne sais pas pourquoi vous parlez d'"availability zone" concercant GCP... ce terme n'existe pas chez eux.
Ce terme vient d'AWS et ne concerne pas GCP. c'est peut-être la que y'a confusion ...
Il y a des zones et des régions mais pas d'"availability zones".cf: https://cloud.google.com/docs/geography-and-regions
Ce qui est faux, donc on le corrige.
Les 2 acteurs (Google et AWS) utilisent des définitions semblables. Donc Zones-GPC et AZ-AWS, c'est la même chose, ça sert explicitement à assurer de la disponibilité = availability, contrairement à ce que prétend KGersen.
https://cloud.google.com/docs/geography-and-regions
Les zones servent au déploiement des ressources Google Cloud dans une région. Elles doivent être considérées comme un domaine de défaillance unique au sein d'une région. Pour déployer des applications tolérantes aux pannes et à haute disponibilité, et être mieux protégé contre les défaillances inattendues, déployez vos applications sur plusieurs zones d'une région.
Leon.
-
Mais je ne comprends pas
Si je lance 10 bombes sur les capitales d'Europe, alors plusieurs régions sont down en même temps
Ça peut arriver
Dois-je en conclure que la notion de région n'a rien à voir avec la disponibilité ?
Ha mais en plus, les autres providers seront down
Finalement, dois-je conclure que la notion de disponibilité n'existe pas ?
Ou alors il y aurai des nuances possibles 🧐
-
Comme tous les topics qui dépassent 1 page: corriger l'Internet
+1
Il faut rétablir la vérité sur Internet, c'est notre mission! LOL
Notre ami KGersen prétend que les "zones" de GCP ne sont pas le même concept que les AZ d'AWS, et que ça ne sert pas à la disponibilité. Ce qui est faux, donc on le corrige.
Les 2 acteurs (Google et AWS) utilisent des définitions semblables. Donc Zones-GPC et AZ-AWS, c'est la même chose, ça sert explicitement à assurer de la disponibilité = availability, contrairement à ce que prétend KGersen.
https://cloud.google.com/docs/geography-and-regions
Les zones servent au déploiement des ressources Google Cloud dans une région. Elles doivent être considérées comme un domaine de défaillance unique au sein d'une région. Pour déployer des applications tolérantes aux pannes et à haute disponibilité, et être mieux protégé contre les défaillances inattendues, déployez vos applications sur plusieurs zones d'une région.
Leon.
De l'art de déformer mes propos. En plus a lire cela, "je suis Internet" ... :o
Je n'ai jamais dit que "ça ne sert pas à la disponibilité".
J'ai juste dit que Google contrairement a AWS n’appelle pas ses zones des "availability zones".
car Google ne prétend pas avoir plus d'un DC par "zone", contrairement aux prétentions d'AWS et Azure.
Donc que c'est dangereux de comparer les providers sur les "mots" plutôt que de regarder en détail comment ils font les choses.
-
En plus a lire cela, "je suis Internet" ... :o
Ca serait plutôt flateur non? 8) mais ce n'est pas bijectif.
regarder en détail comment ils font les choses.
On va arriver bientôt à boucler la boucle. On ne sait justement pas comment c'est fait. Pour la répartition de charge, europe-west1 pour toi sera peut-être europe-west2 pour moi, et inversement. Google ne dit rien, et on n'arrive même pas à avoir le certitude si deux zones étaient hébergés dans le même datacenter GlobalSwitch ou pas. Même en multi-cloud, tu peux très bien te retrouver à avoir ton infra hébergée sur le même DC sans le savoir, ni même pouvoir le savoir.
A mon sens, google ne respecte pas ses engagements. Je ne suis pas expert en juridique, mais je pense que ça pourrait aller au delà des pénalités prévues par le SLA, puisque le service vendu à la base n'est pas conforme.
J'espère qu'on aura un jour le détail de ce qu'il s'est passé et pourquoi google n'a pas réussi a isoler son DC.
-
Notre forum préféré est mentionné sur The Register (https://www.theregister.com/2023/05/10/google_cloud_paris_outage_persists/).
-
& par LMI
https://www.lemondeinformatique.fr/actualites/lire-des-services-de-google-cloud-toujours-sous-l-eau-apres-l-incendie-de-global-switch-maj-90387.html