Auteur Sujet: Incendie Global Switch Clichy du 26 avril 2023 et ses impacts sur Google Cloud  (Lu 39426 fois)

0 Membres et 1 Invité sur ce sujet

halesk2k

  • Abonné Sosh fibre
  • *
  • Messages: 57
  • Brétigny-sur-Orge (91)
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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 104
  • Paris (75)
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

Citer
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.


halesk2k

  • Abonné Sosh fibre
  • *
  • Messages: 57
  • Brétigny-sur-Orge (91)
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?

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 6 010
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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 104
  • Paris (75)
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.

halesk2k

  • Abonné Sosh fibre
  • *
  • Messages: 57
  • Brétigny-sur-Orge (91)
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:

Citer
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

Citer
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.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 677
  • La Madeleine (59)
Quel est l'objectif de cet échange, précisément ?

halesk2k

  • Abonné Sosh fibre
  • *
  • Messages: 57
  • Brétigny-sur-Orge (91)
Quel est l'objectif de cet échange, précisément ?

Comme tous les topics qui dépassent 1 page: corriger l'Internet

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 104
  • Paris (75)
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.



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 ?

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 6 010
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.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 677
  • La Madeleine (59)
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 🧐

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 104
  • Paris (75)
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.