La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
Scaleway => Discussion démarrée par: Leon le 04 octobre 2020 à 09:07:35
-
Bonjour à tous,
Scaleway annonce une 2ieme "availability zone" avec un datacenter bien séparé.
https://blog.scaleway.com/fr/fr-par2-pour-vos-instances-virtuelles/
Ces deux lancements partagent un objectif commun : vous proposer des services toujours plus stables, performants et efficients pour construire une infrastructure résiliente. Comme les instances DEV & GP peuvent désormais fonctionner sur deux AZs différentes (fr-par1 et fr-par2), vous pouvez répartir vos applications sur plusieurs datacenters en région parisienne afin d'offrir une plus grande disponibilité et d'assurer une tolérance aux pannes optimale. Ces zones de disponibilité sont totalement isolées et séparées par une distance de plus de 10 km, afin de vous garantir une infrastructure résiliente.
Si je comprends bien :
* Availability zone PAR-1 = DC2+DC3 (Vitry)
* Availability zone PAR-2 = DC5 (à Pontoise)
Mais pour moi il y a un énorme problème, un énorme non dit, dans cette annonce:
Le réseau et le routage reste centré autour d'un seul et unique datacenter: DC3.
DC5 n'a pas de routeur de coeur. Il a uniquement des switch d'agrégation raccordés sur les routeurs de coeur de DC3.
http://netmap.online.net/
Ca me semble vraiment contraire au principe d'Availability Zone.
La perte totale de DC3, ou de gros problème réseau à DC3 ou autour suffirait à faire tomber les 2 availability zones.
Bref, je ne comprends pas l'annonce. Ca ne me semble pas super honnête comme annonce.
Je ne sais pas si Scaleway a prévu ou non de changer cette situation bancale, en répartissant mieux son réseau, et en rendant les 2 "availability zones" vraiment indépendantes.
Leon.
-
C'est effectivement potentiellement trompeur mais je ne suis pas sûr que "availability zone" soit à prendre ici au sens de l'accessibilité réseau mais bien de la zone physique de disponibilité.
Pour les clients ça n'apporte rien, pour Scaleway ça permet de mettre en avant la conception différente de DC5 et d'appliquer un tarif horaire plus élevé pour les instances hébergées dans ce datacenter.
-
DC5 a en effet un coût inférieur à DC2/DC3.
La redondance est aussi un poil inférieure sur DC5.
Pour ceux pour qui l'aspect écologique est important, DC5 est le plus respectueux dans ce domaine.
-
C'est effectivement potentiellement trompeur mais je ne suis pas sûr que "availability zone" soit à prendre ici au sens de l'accessibilité réseau mais bien de la zone physique de disponibilité.
Pour les clients ça n'apporte rien, pour Scaleway ça permet de mettre en avant la conception différente de DC5 et d'appliquer un tarif horaire plus élevé pour les instances hébergées dans ce datacenter.
Je n'ai pas compris ce que tu essayes de dire.
Le terme "availability / disponibilité" est assez clair, non? Ca sert à assurer la redondance entre plusieurs zones sensées avoir une grande indépendance entre elles. C'est bel et bien décrit dans l'article de Scaleway.
https://blog.scaleway.com/fr/fr-par2-pour-vos-instances-virtuelles/
Ces deux lancements partagent un objectif commun : vous proposer des services toujours plus stables, performants et efficients pour construire une infrastructure résiliente. Comme les instances DEV & GP peuvent désormais fonctionner sur deux AZs différentes (fr-par1 et fr-par2), vous pouvez répartir vos applications sur plusieurs datacenters en région parisienne afin d'offrir une plus grande disponibilité et d'assurer une tolérance aux pannes optimale. Ces zones de disponibilité sont totalement isolées et séparées par une distance de plus de 10 km, afin de vous garantir une infrastructure résiliente.
"Totalement isolées", c'est un gros mensonge : si un des éléments (le réseau) n'est pas indépendant, ça me semble vraiment trompeur.
Pour les clients, c'est bel et bien censé apporter de la redondance / disponibilité. Exactement comme les autres cloud-provider qui manipulent le concept de "availability zones".
Leon.
-
@Vivien : Attention, le tarif à DC5 est supérieur à celui à DC2/DC3 !
@Leon : J'ai retrouvé l'annonce pour PAR-2 (https://blog.scaleway.com/fr/fr-par2-pour-vos-instances-virtuelles/) et c'est effectivement particulièrement trompeur vu comme c'est formulé.
PS : C'est clairement un sujet sur lequel il serait intéressant d'avoir la position officielle de Scaleway.
-
Hello,
Oui, vous avez raison, et c'est le design cible à terme : chaque AZ constituant une région doit avoir des points d'entrée / sortie réseau répartis depuis plusieurs AZ - et chaque région à son propre réseau indépendant et non connecté aux autres régions.
Maintenant, il va se passer un certain temps avant d'y arriver c'est sur :-)
Donc OUI, concernant le point "central" que constitue DC3, c'est tout à fait vrai.
On a fait le choix il y a 8 ou 9 ans avec Mikmak de centraliser notre coeur de réseau à DC3 en architecture true-mirror en doublant toute l'agg vers ces deux coeurs de réseau.
Autrement dit, le coeur est splité en deux (bb1 en OPE1, bb2 en OPE2), sur les deux salles opérateur du DC, sont autonomes et indépendantes au niveau énergie (C+D pour OPE1, A+B pour OPE2), refroidissement (S/S C) et trans/fibres (adductions fibre extérieures indépendantes et distinctes avec le principe de NORD/SUD).
PAR2 (DC5 donc) est double-adducté depuis bb1/bb2 avec deux tracés distincts.
Bref, c'est pas state-of-art et plutôt legacy et on va tendre vers mieux avec le temps avec une logique plus "cloud" (Région vs AZ vs Edge), mais nous n'avons pas à rougir de ce qui existe : c'est un design éprouvé depuis très longtemps chez nous, très opérateur/hébergeur certes mais qui à fait ses preuves avec 0 incident réseau depuis notre adolescence et qui à survécu aux pires incidents (comme l'énorme fiber-cut de DC2 pendant le confinement par exemple).
A+
Arnaud
-
Question supplémentaire : Pourquoi DC5 (Availability zone PAR-2) est plus cher que DC2/DC3 (Availability zone PAR-1) ?
-
Merci Arnaud pour la réponse. Techniquement c'est valable.
Mais je trouve vraiment dommage que le communiqué soit réellement en écart par rapport à la réalité actuelle du réseau Scaleway.
J'attends avec impatience de voir l'évolution du réseau pour s'adapter à ces contraintes "cloud".
EDIT: pour le "zéro incident réseau", là aussi j'ai un gros doute.
Bref, c'est pas state-of-art et plutôt legacy et on va tendre vers mieux avec le temps avec une logique plus "cloud" (Région vs AZ vs Edge), mais nous n'avons pas à rougir de ce qui existe : c'est un design éprouvé depuis très longtemps chez nous, très opérateur/hébergeur certes mais qui à fait ses preuves avec 0 incident réseau depuis notre adolescence et qui à survécu aux pires incidents (comme l'énorme fiber-cut de DC2 pendant le confinement par exemple).
En février 2019, suite à une coupure de fibre, Scaleway a perdu (quasi?) totalement DC2 pendant 45 min, car la bascule automatique n'a pas correctement fonctionné.
https://lafibre.info/scaleway/coupure-832fo-entre-dc2-et-dc3/
45 min sur plusieurs années, ça n'est pas énorme, mais c'est infiniment supérieur à zéro.
Leon.
-
Salut.
Je me permet de déterrer ce sujet 10 mois plus tard.
La situation ne semble pas avoir changée :
* Scaleway parle toujours de 2 "availability zone" autour de Paris (Paris 1 / Paris 2)
* et le réseau est toujours centré sur DC3, et ce pour les 3 datacenters (DC2, DC3, DC5), ce qui est contraire au concept d'availability-zone inventé par les fournisseurs de cloud.
Est-ce qu'on a une échéance (date) de remise en conformité du réseau par rapport au concept d'availability-zone?
Ou alors est-ce que la situation restera telle quelle ad viatam aeternam?
Est-ce qu'il n'y a tout simplement pas encore assez de serveurs Scaleway (Elements + Dedibox) à DC5 pour justifier le fait de monter un coeur de réseau dédié sur ce datacenter?
Leon.
-
La salle réseau de DC5 sera toujours bien plus petite que les deux grandes salles réseau de DC3.
J'imaginais plus DC4 (les étages supérieur) comme second point réseau, mais visiblement Scaleway n'arrive pas à avoir l'authorisation de mettre en place un data-center dans ces locaux.
-
Est-ce qu'on a une échéance (date) de remise en conformité du réseau par rapport au concept d'availability-zone?
Ou alors est-ce que la situation restera telle quelle ad viatam aeternam?
C'est bien prévu d'avoir du peering/transit sur d'autres DC.
Impossible cependant de donner une date pour le moment. (car ça ne dépend pas forcément de nous)
-
C'est bien prévu d'avoir du peering/transit sur d'autres DC.
C'est possible d'en savoir un peu plus, stp?
"D'autres DC" étant DC5? Ou des datacenters tiers?
Non parce que pour rendre la Availability-zone "Paris 2" indépendante de "Paris 1", il faut forcément être ailleurs que DC2 et DC3, qui sont tous les 2 annoncés comme "Paris 1".
Impossible cependant de donner une date pour le moment. (car ça ne dépend pas forcément de nous)
Et le "ça ne dépend pas de nous", c'est un peu fort... C'est bien Scaleway qui a décidé de lancer ce service d'Availability-Zone sur la région "Paris" !
Pourquoi avoir lancé un service sans avoir l'infrastructure derrière, tout en continuant à partager l'architecture du réseau avec les clients de manière transparente grâce à une Weathermap? C'est quand même très étrange comme stratégie d'entreprise. Je ne comprends pas.
Leon.
-
Non parce que pour rendre la Availability-zone "Paris 2" indépendante de "Paris 1", il faut forcément être ailleurs que DC2 et DC3.
Les cibles pourraient être DC2 (j'en doute) et DC5 (surement).
-
DC5 a peu de place pour des équipements réseau.
A l'origine c'est DC4 qui devait devenir un second point de peering / transit.
Problème : Scaleway n'a toujours pas obtenu autorisation d'utiliser le bâtiment en datacenter, donc seul le sous-sol fonctionne et les étages sont vides.
-
Chaque AZ devrait normalement avoir ses propres peers et transitaires à terme. Je parle donc bien de nos DC quand je parle des autres DC que ceux qui ont actuellement du peering.
Je pourrais pas vraiment en dire plus car je n’en sait pas plus (je ne m’occupe pas du tout de cette partie la)
-
Allez Leon, c'est pour toi ça :)
https://blog.scaleway.com/meet-fr-par-3/
-
Allez Leon, c'est pour toi ça :)
https://blog.scaleway.com/meet-fr-par-3/
Merci Hugues, j'avais loupé ça. Ca me fait plaisir que tu penses à moi. ;)
Bon, si même les fournisseurs de Cloud sérieux s'amusent à mélanger volontairement les concepts (AZ c'est pour du PCA en théorie), on n'est pas dans la merde.
DC4 sera une "zone" géniale pour de la sauvegarde et du PRA. Mais pas pour du PCA.
En tout cas, j'espère de tout coeur qu'un incident majeur (type incendie OVH Strasbourg ou autre) ne frappera jamais DC3, en prouvant l'aspect "perfectible" des AZ de Scaleway.
Scaleway ne s'en remettrait très certainement pas du tout.
Et ça m'inquiète que Scaleway utilise les méthodes de son concurrent principal. Genre "promis, demain on fera ça"... "promis demain on rase gratis".
Leon.
-
J'ai commenté un article de NextInpact (https://www.inpact-hardware.com/article/2655/scaleway-ouvre-son-abri-anti-atomique-dc4-a-iaas-setend-en-europe-et-embauche#comment/59945) qui parlait de DC4 notamment et qui passait à côté de cette limitation de la zone de Paris, Mikmak a réagi en commentaire et confirme en gros ce que disait Kedare :
Salut Underground78 ;)
tu as raison sur le fond meme si pour que DC3 soit "éteint" on serait probablement dans un niveau de catastrophe industriel assez majeur sur la région parisienne (DC3 est quand meme Tier-3)
sache néanmoins que le design de nos régions prévoit 2 POPs réseaux redondants sur plusieurs DCs (pas forcément commun avec les déploiements d'AZ d'ailleurs, par ex on aurait pu choisir un POP network sur un DC plus "telco historique", on fera sans doute ce choix dans des régions où les DCs sont moins nombreux/diverses qu'en France),
et c'est donc bien ce que nous sommes en train de faire sur Paris également: nos transitaires sont en train de se déployer sur DC5 et nous pourrons doubler(enfin tripler) l'entête network sur DC5 d'ici quelques mois (c'est déjà dans la roadmap de nos équipes réseaux), toutes les AZ seront ensuite double attachées sur les 2 POPs network de la région (pour le moment elles sont double attachées sur les 2 POPs réseaux présents à DC3 dans les 2 salles OPs qui sont déjà elles-memes en totale redondance l'une de l'autre...)
et comme le dit David, la logique "globale" la plus sécurisante pour le client ca reste le multi cloud (et/ou multi région), même si aujourd'hui ca implique encore un investissement technique et une charge/responsabilité coté client plus forte
-
Merci underground!
Donc le 2ieme POP de Scaleway à Paris, ça sera bel et bien DC5.
Personnellement, je me suis toujours interrogé sur la stratégie "réseau/POP" de Scaleway à Paris.
Leur philosophie a été de réaliser la très grande majorité des interconnexions à DC3, et d'attirer un maximum d'opérateur à DC3 en leur offrant le loyer les premières années.
C'est louable, pour un opérateur de datacenter, ça a fait de DC3 un datacenter carrier-neutral plutôt intéressant, que pas mal de clients "housing" utilisent comme site d'interconnexion.
Mais pour un opérateur de cloud, c'est plus difficilement compréhensible, à mon avis.
Si pour arriver à déployer un vrai POP multi térabits à DC5, il faut attendre plus de 2 ans de travaux après le lancement officiel du datacenter, le jeu en vaut-il vraiment la chandelle?
Une alternative intéressante, et certainement plus souple, aurait été de déployer dès le début (il y a 10 ans) un vrai MAN parisien de grosse capacité (multi Tb/s), pour aller chercher les interconnexions là où elles sont déjà, dans les gros datacenters "carrier hotel" de Paris (TH2), d'Aubervilliers, etc... Un tel MAN parisien, de très grosse capacité, est probablement plus rapide à réaliser. "Il suffit" de louer 3 ou 4 baies dans chaque POP, et des fibres noires. Et surtout, l'avantage d'être présent dans ces gros datacenters parisiens, c'est que ça rend les nouvelles interconnexions plus faciles et plus rapides à réaliser. Un cross-connect supplémentaire, c'est plus rapide à déployer. Et ça rendrait Scaleway indépendant du bon vouloir d'un Level 3.
Est-ce que Scaleway a fait ce choix initial uniquement pour éviter de donner du pognon à leurs concurrents sur le marché "datacenter" (TH2, Equinix, Interxion, etc... ), et éviter de renforcer la position dominante de ces concurrents? Ca serait vraiment dommage si c'était le cas.
Leon.
-
Je dirais plutôt que Scaleway souhaite voir venir beaucoup d'opés chez eux.
J'imagine que leur activité housing est importante
PS : on sera bientôt à DC5 ;)
-
A DC5, le plan initial était la location de grande salles (278 baies sur 550 m² par salle) sans possibilité de division possible en espace plus petit.
DC3 étant privilégie pour les cages de plus petite capacité (132 baies) et pour les besoin d'une bai ou de quelques baies, c'était DC2.
Cela a changé ?
Même salle aujourd'hui :
Scaleway ne propose pas de location à la baie sur DC3 : Il faut prendre un espace de 250m² au minimum (soit 132 baies dans une configuration standard). Pour louer à la baie, Scaleway a le data center DC2 situé dans la même commune et hérité du rachat par Iliad du FAI Alice.
Par contre des sociétés qui louent un espace de 250m² peuvent sous-louer. C'est le cas de Scaleway/Online qui a proposé à une époque "Dedirack" : 1/4 de baie, deux badges, l'énergie et un transit de 1 Gb/s pour 300€/mois. Ceux qui connaissent les prix du marché savent que ce n'est pas vraiment pas cher, généralement on dépasse ce prix pour 1/4 de baie sans l'énergie ni le transit. Le transit de 1 Gb/s seul peut être proposé à plus de 1000€/mois par certains acteurs.
L’arrivée des fibres / cuivre passe par le haut des baies par des chemins de câbles suspendus. On repère les fibres à leur couleur jaune sur la photo :
(https://lafibre.info/images/datacenter/201509_online_dc3_salle3_01.jpg)
-
On y sera en tant qu'opérateur. Je ne sais pas pour le reste
-
Bon, ça a évolué récemment, je ne sais pas quand.
Scaleway a désormais une PETITE partie de ses interconnexions, transit uniquement, en local à DC5 à Pontoise.
Rappel : DC5 héberge leur 2ieme Availability-Zone de la région "Paris", censée être indépendante de l'availability-zone [DC2 + DC3].
Donc ça progresse, mais le réseau de la région Scaleway-Paris reste très centré sur un DC3 (Vitry sur Seine).
https://netmap.scaleway.com/
Les capacités d'interconnexion :
DC5 : Je compte 10 x 100Gbps = 1Tbps de transit "seulement".
DC3 : plus de 5.2Tbps en local
- 38 x 100Gbps = 3.8Tbps de transit
- 14 x 100Gbps = 1.4Tbps de peering
- plus d'autres interconnexions moins importantes (TH2, private peering DC3), qui aboutissent toutes à DC3.
Sachant que le trafic pointe généré par Scaleway DC5 tutoie les 2Tb/s (4Tb/s pour toute la région Paris), ça semble insuffisant si l'interconnexion vers DC3 vient à tomber, ou si DC3 tombe entièrement.
(https://netmap.scaleway.com/graph/dc5?)
Oui, je pense qu'il faut se poser la question d'une perte totale de DC3, vu les incendies récents d'OVH Strasbourg, Maxnod, et Global-Switch.
Après, évidemment, le réseau ne survivrait pas à une coupure totale des interconnexions DC3 - DC5 (network brain split) vu que les range IP sont communs à toute la région "Paris", donc impossible d'annoncer individuellement les IP avec les transitaires en BGP...
En tout cas, en l'état, on reste dans la situation précédente : si DC3 tombe totalement, Scaleway meurt très rapidement.
Je ne comprends pas pourquoi Scaleway continue à parler d'Availability Zone pour DC5, vu qu'elle n'est pas indépendante de DC3.
La zone de défaillance unique pour Scaleway, ca reste tout Paris (DC2 + DC3 + DC5). Contrairement à ce qu'ils annoncent aux clients.
Vu ce que Google a vécu récemment, ça devrait les faire réfléchir, je l'espère.
https://lafibre.info/datacenter/incendie-maitrise-globalswitch-clichy/
Rappel du marketing Bullshit de Scaleway:
Ces deux lancements partagent un objectif commun : vous proposer des services toujours plus stables, performants et efficients pour construire une infrastructure résiliente. Comme les instances DEV & GP peuvent désormais fonctionner sur deux AZs différentes (fr-par1 et fr-par2), vous pouvez répartir vos applications sur plusieurs datacenters en région parisienne afin d'offrir une plus grande disponibilité et d'assurer une tolérance aux pannes optimale. Ces zones de disponibilité sont totalement isolées et séparées par une distance de plus de 10 km, afin de vous garantir une infrastructure résiliente.
Leon.
-
Il me semble que dans les plans initiaux, les peering devaient être sur DC3 et DC4.
DC4 qui a une situation idéale en plein Paris, mais il semble que la mairie de Paris refuse que les bâtiments soient utilisés en Data center (excepté l'abri anti-atomique).
DC5 est clairement moins intéressant que DC4 pour faire du peering.
-
Il me semble que dans les plans initiaux, les peering devaient être sur DC3 et DC4.
DC4 qui a une situation idéale en plein Paris, mais il semble que la mairie de Paris refuse que les bâtiments soient utilisés en Data center (excepté l'abri anti-atomique).
DC5 est clairement moins intéressant que DC4 pour faire du peering.
Mouais...
Ca fait 6 ans qu'on sait que Online/Scaleway DC4, partie "en surface", ne va pas ouvrir dans les 5 ans à venir. C'est toujours valable en 2023... Il est totalement improbable que DC4 "en surface" ouvre dans les 5 ans à venir.
Encore une fois, si Scaleway (branche Datacenter) a du mal à faire venir les opérateurs à DC5, il "suffirait" que Scaleway (branche cloud-provider) se construise un MAN parisien , en louant 2 ou 3 baies dans chacun des gros "carrier hotel" de Paris, et on n'en parle plus... Un MAN parisien de grosse capacité avec 3 POPs (dont DC3), ça serait largement suffisant.
Scaleway est un Cloud provider, il lui faut une bonne connectivité Internet. Tous les gros Cloud provider sérieux procèdent comme ça, avec des MAN allumés en propre.
Là, ça fait 3 ans que Scaleway vend une availability zone qui n'en n'est pas une...
Regardez le réseau OVH, chaque DC a ses propres interconnexions vers les POPs les plus proches, et de manière redondante. Aucun DC ne dépend d'un autre.
Leon.
-
Aucun DC ne dépend d'un autre.
SBG1, SBG3 et SBG4 dépendaient des 2 salles réseau de SBG2 il me semble.
-
On est hors sujet... mais c'est pas grave
SBG1, SBG3 et SBG4 dépendaient des 2 salles réseau de SBG2 il me semble.
Ca n'a rien à voir, Vivien.
OVH ne vend pas les différents bâtiments/salles d'un même campus comme des Availability Zones différentes/indépendantes. Et c'est bien normal.
Aucun Cloud provider sérieux n'oserait faire une connerie pareille... LOL.
OVH a 3 gros campus en France : Roubaix, Gravelines, Strasbourg. C'est à ce niveau que se fait la high-availability chez OVH, les campus étant au maximum indépendant entre eux.
Dans ce sujet, on parle bien de la "zone de défaillance unique" de Scaleway région "Paris".
Scaleway vend bel et bien 2 availability zones (3 en fait) dans la région "Paris"
- Paris 1 = DC2 + DC3
- Paris 2 = DC5
-(Paris 3 = DC4 sous terrain mais uniquement pour du backup, donc ça n'a rien à voir avec le concept d'Availability)
Paris-1 et Paris-2 ne sont pas assez indépendantes, d'un point de vue réseau, c'est anormal.
Leon.
-
On dirait plus un problème de comm et de définition de 'availability' zone. Tu as l'air focalisé sur une définition très particulière et très théorique.
Il faudrait la définir plus formellement et voir quels sont les cloud providers qui la respecte ou pas...
-
Je comprend la coté définition différente mais la si je comprend bien, DC3 brule DC5 n'a plus de connectivité par consequent ne sert a rien
Or un AZ c'est l'assurance que si une zone tombe l'autre "survis" ce qui n'a pas l'air d'être le cas au niveau de la connectivité.
-
On dirait plus un problème de comm et de définition de 'availability' zone. Tu as l'air focalisé sur une définition très particulière et très théorique.
Euh, je ne te comprends pas. Le président de Scaleway, Arnaud de Bermingham, a l'air d'accord avec ma définition. Donc je n'ai aucun doute. Je ne vois pas comment on peut avoir des doutes sur la définition d'une "Availability Zone", sur un sujet aussi clair, aussi critique pour un Cloud Provider.
Tout le monde a la même définition de ce qu'est une Availability Zone, il ne peut pas y avoir de toute sur le sujet.
Voir le message d'Arnaud de Bermingham il y a 2 ans:
Hello,
Oui, vous avez raison, et c'est le design cible à terme : chaque AZ constituant une région doit avoir des points d'entrée / sortie réseau répartis depuis plusieurs AZ - et chaque région à son propre réseau indépendant et non connecté aux autres régions.
Maintenant, il va se passer un certain temps avant d'y arriver c'est sur :-)
[...]
Bref, c'est pas state-of-art et plutôt legacy et on va tendre vers mieux avec le temps avec une logique plus "cloud" (Région vs AZ vs Edge), mais nous n'avons pas à rougir de ce qui existe : c'est un design éprouvé depuis très longtemps chez nous, très opérateur/hébergeur certes mais qui à fait ses preuves avec 0 incident réseau depuis notre adolescence et qui à survécu aux pires incidents (comme l'énorme fiber-cut de DC2 pendant le confinement par exemple).
A+
Arnaud
Leon.
-
Tout le monde a la même définition de ce qu'est une Availability Zone, il ne peut pas y avoir de toute sur le sujet.
quand t'as une vue "DC traditionnel" oui (machines physiques). Tu parles de "zones physiques". Si tu te restreint ta définition a 'x sources d'électricité' et 'x adductions réseau' etc c'est vague et trop "physique" sauf si on parle DC traditionnel mais la tu parle de "Scaleway Cloud" non ?
Quand on parle Cloud, c'est des vm, des briques managées, applications, etc ce n'est plus pareil.
La latence, les couts de transfert entre zones inclus ou pas, quel débit pour ces transferts ? sont-ils garantis ? (Azure par exemple, indique "2ms max" entre zone d'une même région, ca fait parti de ta définition ?).
Le load-balancing ou pas des IPs public/privés, etc
La définition même de "zone" devient plus complexe et moins consensuelle. Ce n'est pas juste des DC et du hardware. loin de la.
Pour certains services tu n'as même plus la notion de "zone", y'a que région.
Apres c'est certain chacun voit son bout du sujet. Du coté application/dev, la HA ce n'est pas juste du hardware dispo "ailleurs" en cas de panne. C'est bien plus complexe à faire.
En plus les zones (en vue Cloud) sont de plus en plus "virtuelles" que physiques. Scaleway est petit donc j'imagine que la zone "paris-1" est la même pour tout le monde et correspond toujours a DCx ?
Chez AWS d'un compte a l'autre, la même zone "us-east-1a" peut être physiquement ailleurs.
Bref la définition de zone n'est pas a ma connaissance standardisée.
-
Je ne comprends pas le rapport avec ce qui est discuté ici.
Ici on parle de la notion de défaillance unique entre 2 "availability zones". Le terme Availability est le plus important. Tous les acteurs qui emploient le terme "availability zone" parlent clairement du même concept : répartition entre zones pour assurer le maximum de disponibilité, de résilience aux défaillances, sans point de défaillance unique entre zones. Clair, net, précis.
Tout le reste de ta prose, c'est une autre discussion.
Oui, la notion de zones varie entre acteurs, on est d'accord, mais ça n'est pas l'objet de la discussion.
Oui, la notion de latence c'est important, pour des services de réplication synchrone notamment.
Ici, on parle de Scaleway, pas d'AWS ou Google-Cloud.
Et d'autres acteurs cloud (OVH) ne parlent pas du tout d'Availability Zones, oui, mais on ne parle pas d'eux ici.
Oui, différents cloud provider offrent des services différents inter-zones, inter-région, mais ça n'est pas l'objet de la discussion ici.
Franchement, si même le président de Scaleway dit qu'ils ne sont pas actuellement dans les bons standards d'isolation réseau entre les Availability Zones, je ne sais pas ce qu'il te faut de plus.
Leon.
-
Si le transit de DC5 est suffisamment dimensionné, en cas de perte de DC3 et donc de tous les peering, DC5 serait toujours joignable via ses transits.
Pour les grands acteurs, c'est toujours le transit qui est le backup des peering (et non les points d'échange, dont les liens ne sont pas suffisamment dimensionnés).
-
Salut Vivien,
Si le transit de DC5 est suffisamment dimensionné, en cas de perte de DC3 et donc de tous les peering, DC5 serait toujours joignable via ses transits.
J'ai déjà répondu à cette question un peu plus haut. Aujourd'hui, le transit DC5 n'est clairement pas dimensionné pour reprendre tout DC5.
Il faut bien voir que DC5 est devenu le plus gros DC de Scaleway (branche cloud-provider) en terme de trafic.
Les capacités d'interconnexion :
DC5 : Je compte 10 x 100Gbps = 1Tbps de transit "seulement".
DC3 : plus de 5.2Tbps en local
- 38 x 100Gbps = 3.8Tbps de transit
- 14 x 100Gbps = 1.4Tbps de peering
- plus d'autres interconnexions moins importantes (TH2, private peering DC3), qui aboutissent toutes à DC3.
(https://lafibre.info/index.php?action=dlattach;topic=44621.0;attach=137400;image)
Sachant que le trafic pointe généré par Scaleway DC5 tutoie les 2Tb/s (4Tb/s pour toute la région Paris), ça semble insuffisant si l'interconnexion vers DC3 vient à tomber, ou si DC3 tombe entièrement.
https://netmap.scaleway.com/
(https://netmap.scaleway.com/graph/dc5?)
-
Voici la définition de Scaleway: https://www.scaleway.com/en/blog/design-considerations-and-our-recommendations-for-data-protection/ (signalée par un lecteur):
C'est daté d'avril 2021:
5km with a maximum internal latency of 1.4 ms and situated at least 50km from another availability zone in the same region
...
The physical fault domain is the availability zone and the network failure area is the region
...
As a customer, you are responsible for the redundancy and the management of the services that run on top of your infrastructure products. The highest level of redundancy is obtained by developing your application across several distinct regions.
...
To avoid misleading our customers, we systematically recommend that they build their infrastructure across multiple regions
-
Voici la définition de Scaleway: https://www.scaleway.com/en/blog/design-considerations-and-our-recommendations-for-data-protection/ (signalée par un lecteur):
OK, merci pour ça.
C'est malheureusement noyé au milieu d'un blog post chez Scaleway, Ca n'est même pas dans la documentation officielle de Scaleway sur les Availability-Zones!
C'est quand même limite...
https://www.scaleway.com/en/docs/console/my-account/reference-content/products-availability/
Scaleway n'en finit pas de descendre dans mon estime. C'est dommage, c'était une belle entreprise il y a quelques années.
Leon.