Glasvezelkabel van Microsoft Azure-datacenters is defect door storm Nederland

Microsoft meldt dat de verbinding tussen twee Azure-datacenters is verbroken door een gebroken glasvezelkabel. Dat is te wijten aan het noodweer in Nederland.

Azure-diensten waarvoor gecommuniceerd moet worden met andere datacenters kunnen hierdoor in West-Europa tijdelijk niet goed werken, schrijft Microsoft. Gebruikers kunnen te maken krijgen met packet drops, time-outs en hogere latenties. Ook diensten als Azure Databricks hebben hierdoor last van storingen. Hoe de kabel beschadigd is geraakt, is onbekend. Microsoft adviseert dat gebruikers die hier last van hebben, indien mogelijk met een fail-over overschakelen naar een andere regio.

Reacties (187)

[Autisme_tech]

Daarom beter niet in de cloud werken maar gewoon lokaal, alles online willen doen heeft ook nadelen

[Keypunchie]

Onzin. In dit geval, als je je zaakjes goed op orde heb, til je het gewoon op uit Amsterdam en verplaats je het naar Ierland.

Die flexibiliteit is wat "cloud native" je biedt.

Ik denk dat best veel applicaties in de komende uren die verschuiving gaan maken.

[Yalopa]

Als je je zaakjes goed op orde hebt, dan heb je een sla met je business, en op basis daarvan maak je je architectuur.

[uiltje]

Mwah, dat hangt er vanaf. Als je al een bestaande infrastructuur hebt dan heb je waarschijnlijk ook al een SLA. Maar anders lijkt me dat de eisen voor de SLA voortkomen uit beschikbaarheid van de services. En de services worden bepaald door de systeem architectuur.

[jsiegmund]

Wanneer je de SLA van je applicaties laat bepalen door de onderliggende infrastructuur ben je mijns inziens toch echt verkeerd om aan het werk. Juist door cloud diensten heb je veel beter de mogelijkheid om vanuit je business te sturen. Dat ze dat vaak niet kunnen en standaard roepen "het moet altijd in de lucht zijn" zegt wat over het volwassenheidsniveau van de organisatie. Een goede productowner ownt ook deze onderdelen van zijn of haar applicatie(s) en niet alleen welke functionaliteit er bovenaan de prioriteitenlijst staat.

[uiltje]

Ja, lekker geredeneerd. "Altijd" bestaat niet in een SLA, en als dat wel zo is dan hoef je er in je architectuur geen rekening mee te houden, dan is het een gegeven [en moet de software in een cluster draaien, hot of cold spare is dan niet voldoende].

[Reactie gewijzigd door uiltje op 22 juli 2024 15:46]

[Yalopa]

Je denkt te technisch

Het gesprek begint uiteraard met de100% sla vraag, vervolgens geef je daar een budget voor, de business wil dat natuurlijk niet betalen, maar dan gaan ze nadenken, welk business proces is hier nu echt belangrijk en welk minder belangrijk, van die belangrijke business processen onderzoek je hoe lang ze er mogen uitliggen en je hebt je business sla. Vervolgens breng je in kaart welke applicaties cruciaal zijn en welke support geven. Die applicaties ga je dan een architectuur geven die die business sla ondersteunt.

Applicaties die minder belangrijk zijn krijgen een lagere sla. Heel dikwijls gaat men een 3 tal categorieën van sla’s maken en daar, nog steeds op basis van die business sla elke applicatie in een categorie stoppen.

Typisch zoek je ook alternatieven die buiten it om het business proces tijdelijk ondersteunen voor het geval het echt fout gaat.

(In a nutshell)

Beeld je eens in wat er gebeurd als een ziekenhuis it wise volledig down gaat. De zorg stopt niet omdat de 100% redundante cluster er toch uitgaat (ja dat gebeurt wat 100% redundant bestaat niet en de infra is maar zo stabiel als de admin achter het keyboard.)

[Reactie gewijzigd door Yalopa op 22 juli 2024 15:46]

[Klauwhamer]

[edit] Nevermind. Te snel gereageerd.

[Reactie gewijzigd door Klauwhamer op 22 juli 2024 15:46]

[sebastienbo]

Onzin. In dit geval, als je je zaakjes goed op orde heb, til je het gewoon op uit Amsterdam en verplaats je het naar Ierland.

Die flexibiliteit is wat "cloud native" je biedt.

Ik denk dat best veel applicaties in de komende uren die verschuiving gaan maken.

Het is niet zwart wit
Cloud is gemakkelijker ja... Maar ten koste van je afhankelijkheid... Wij hebben al de hele morgend niet kunnen werken omdat confluence jira plat ligt... De business ligt dus al een halve dag plat.

Ik ga voorstellen om terug over te stappen naar Sharepoint met offline syncs, want dit is niet acceptabel

[Reactie gewijzigd door sebastienbo op 22 juli 2024 15:46]

[tweazer]

allestoringen.nl laat wel wat pieken zien ...

[nielsdc]

Als microsoft z'n zaken op orde had dan waren ze gewoon overgeschakeld naar de backup link en had niemand iets gemerkt.

Microsoft heeft al eens een wereldweide netwerk storing gehad en dat gaat vast nog wel vaker gebeuren.

Ik ben niet tegen de cloud, het bied heel veel voordelen, maar je moet je wel bewust zijn van de risico's

[Robbierut4]

Ik ben toch wel benieuwd welke setup jij lokaal hebt staan die net zo'n hoge uptime heeft als de azure datacentra.

[Anoniem: 1961754]

maar laten we eerlijk zijn: de Microsoft Health disruption mailtjes vliegen je dagelijks om de oren met allerlei degration van legio applicaties. 'Vroegah' had je dat niet echt toen je alles nog lekker draaiend onpremise had staan.

[Robbierut4]

'Vroegah' had je dat niet echt toen je alles nog lekker draaiend onpremise had staan.

De degradatie of de logging?

[Anoniem: 1961754]

het een sluit het ander niet uit.

[Mimiix]

Dat valt mijn inziens reuze mee. Ik heb alle meldingen voor Europa aan staan en deze week is networking d eerste.

[tweazer]

Hier potlood en papier

[cascer1]

Lokaal werkt prima als je het alleen thuis of op kantoor wil gebruiken, maar als je anderen wil betrekken heb je toch gewoon internet nodig? De kabel had net zo goed bij jou in de straat kapot kunnen gaan..

[Houtenklaas]

Nee hoor, er bestaat ook nog zoiets als besloten VPN's. Niet over het internet, maar 100% los daarvan. Ben je grutter en heb je een webwinkel, dan zit je vast aan internet. Maar heet je Politie en heb je een landelijk netwerk die alle bureaus ontsluit, dan gaat dat echt niet over het internet. De laatste gaan overigens vaak over zakelijke aansluitingen met betere hersteltijden, uptime en zo, maar ook over eenzelfde soort als jouw thuis-internet-lijntje, ahoewel die dan niet termineert op een internet wolk, maar een eigen besloten wolk.

Dit ging uiteraard over het stukje "internet nodig" wat lang niet altijd hoeft. "Kabel kapot" is in alle gevallen einde oefening

[Reactie gewijzigd door Houtenklaas op 22 juli 2024 15:46]

[xFeverr]

Het punt van @cascer1 is toch dat daar ook gewoon iemand zijn graafmachine in kan zetten? Of een boom die de hele boel omver kan trekken.

[MSalters]

Een "Virtual Private Network" dat niet over het internet gaat is natuurlijk onzin. Het heet "Virtual" precies omdat het niet fysiek een Private Network is.

[MSalters]

Ik ben met netwerken begonnen in de tijd van de Novell Multi Protocol Router, dus ik heb het een en ander wel gezien. Die "variant op een PC" waar jij het over hebt zijn VPN tunnels, en daar heb je een half dozijn varianten van (zoals OpenVPN en Cisco) . MPLS is een ander protocol, maar nog steeds geen fysieke scheiding. Daarom is het dus een virtueel netwerk. De scheiding van jouw verkeer gebeurt door routing-regels die beheerd worden door de aanbieder van het fysieke netwerk,

[Houtenklaas]

Je zegt zo ongeveer hetzelfde als ik daarboven al zei, maar het ging juist om dat stukje "internet" wat bij een MPLS netwerk geen enkele rol speelt, dat is net de essentie waar het om ging. De scheiding bij MPLS zit hem in de labels die worden aangebracht en niet sec in routing regels, kleine maar belangrijke nuance. Routeren gaat doorgaans op laag 3, waar MPLS zich onder bevindt. En of we dat laag 2 of 2.5 noemen, daar kunnen we nog even vrolijk over bakkeleien

[Reactie gewijzigd door Houtenklaas op 22 juli 2024 15:46]

[Stormstar3]

Alles lokaal doen ook (als we dan toch kort door de bocht gaan)

[Barsonax]

Denk dat je lokale verbinding er een stuk vaker uit zal liggen dan die van Azure.

[tweazer]

Grote partijen, grote verstoringen. Verbindings issues zijn wsl makkelijk op te lossen. Data issues zijn de echte uitdagingen (blikseminslag in storage nodes, lekkages in- human intervention (marktplaats tweedehandjes ) ..
Persoonlijk vind ik het erg knullig, amateuristisch...

[eNaSnI]

Heeft niet iedere oplossing zowel voor- als nadelen?

[IStealYourGun]

Tiental jaar terug heb ik in alle haast naar de UK mogen vliegen omdat BT een fiber had geraakt tussen onze gebouwen. Dus je kan dat on-prem ook voorhebben.

[Andreplusplus]

met een koffer vol floppy disks?

[ultimasnake]

Door deze storm zal ongetwijfeld her en der ook stroomuitval zijn… kunnen we beter gewoon met pen en papier alles schrijven, want alles op de computer doen heeft ook nadelen

[jpsch]

We zijn veel te afhankelijk van elektriciteit geworden.

[Misterven1]

Ja inderdaad, dat is altijd een groot risico.

Als elektriciteit uitvalt, gaan alle servers offline, afhankelijk van datacenter in een plaats en dan is mogelijk wel een probleem als server weer opstart, waar gegevens mogelijk hierdoor beschadigd worden. Bedrijven en instellingen hebben altijd back-up achter rug zodat die gegevens teruggezet worden naar een reserveschijf in een server, dan kunnen ze dan weer snel aan slag.

Mogelijk heeft ieder bedrijf of een instelling een reserveserver bij datacenter van Microsoft, ene server A doet als eerste server, andere server B is voor back-up, 3de server leent zich als reserveserver waar als server A of B offline zou gaan. Je hebt maximaal 5 servers nodig om bij bedrijfsgegevens te komen via gesloten netwerk via Azure-diensten van Microsoft.

[Andreplusplus]

fiber is licht, geen stroom

[Frame164]

Het voordeel van lokaal werken is dat outages niet in het nieuws komen. Maar het zal mij niet verbazen als de totale downtime van lokaal werken groter is dan de enkele keer dat een cloud service uit de lucht is. Mijn n=1 ervaring is dat bij mij op het werk de beschikbaarheid van services groter is nu het meeste gebruikt maakt van Azure.

[bush]

Wat een onzin, het hangt allemaal af van je architectuur. Als jouw setup GEO-redundant is opgezet is er helemaal niks aan de hand. Dat betekent in dit geval een deployment in zowel AMS als Dublin.
Bovendien als je het artikel leest gaat het over een fiber tussen DC's in AMS. Met andere woorden als je een "simpele VM" draait in één DC zal het waarschijnlijk nog allemaal werken, maar als je een Azure Service hebt in één DC die gebruikt maakt van een service in een andere geïmpacteerde DC heb je er last van latency, door de verminderde bandbreedte tussen de DC's.
Het is nu niet dat Azure in AMS volledig "uit" ligt.

[Houtenklaas]

Als er een vliegtuig op je pand valt, een tankwagen naar binnen rijdt, er brand uitbreekt zoals vorige week in Rotterdam ben je lokaal letterlijk alles kwijt. Redundantie qua datacenters is geen enkel issue, maar dat kost wel het één en ander. Datacenters hebben altijd twee "meet-me" rooms waar partijen geografisch gescheiden van elkaar binnen komen. Dingen enkelvoudig ophangen is een keuze, net zoals een dual datacenter oplossing met meerdere volledig gescheiden aanvoer van data, eventueel darkfibre voor realtime database synchronisatie en dergelijke. En ja, dat kost inderdaad wat. Dat laatste geeft je een zekerheid van vele "negens" achter de komma die je lokaal in de verste verte niet zal halen.

[Rolfie]

Totdat je bedrijf bijvoorbeeld in Purmerend had zitten

https://www.nhnieuws.nl/n...er-stroom-door-storm-poly

[DeeD2k2]

Wij maken ook gebruik van deze Azure regio. Niets van gemerkt dat er iets kapot was...

Inmiddels is alles weer opgelost door Microsoft en werken alle diensten weer zoals vanouds. Binnen 1 dag dus! Ik durf mijn had er voor in het vuur te steken dat dit ons zelf, in alle ellende van gisteren, niet was gelukt als de glasvezel naar een van onze vestigingen kapot gegaan was. Dan waren ze vandaag aan het graven geweest en waren wij nog niet up-and-running. Die verbinding hebben we niet alleen maar nodig om thuis te kunnen werken, ook voor de communicatie/VPN verbinding tussen de vestigingen...

Dan ben ik blij dat wij deze problemen bij Microsoft kunnen laten liggen. Gaan wij zorgen dat we het uitgevallen transport van gisteren weer in gaan halen. Liever één probleem dan twee.

[robertlinke]

als je gewoon availability zones en zone-redundancy hebt geregeld dan hoef je nauwelijks tot geen downtime te ondervinden, en desnoods ga je over tot handmatige fail-over.

zelfde als er bij jouw eigen infrastructuur de kabel naar buiten breekt

[Marchel]

Andere regio?.... wel GDPR compliant graag!

[lenwar]

De Azure-regio "Europe" omvat West-Europa (Amsterdam) en Noord-Europa (Dublin). Dit zijn als het ware 'buddy-regios' voor Azure (ben even kwijt hoe ze het offcieel noemen). Als je failovers in je Azure hebt gezet, dan werk je in principe met die twee samen.

De namen zijn wat ongelukkig, maar dat is een historisch iets
https://azure.microsoft.c.../geographies/#geographies

Frankrijk, Duitsland, Griekenland, enz vallen dus niet onder de Azure-regio "Europe", maar onder andere Azure-regio's. (het is puur een naam-ding)

[Wafeltje]

De naam die je zoekt is Region Pair. Zoals de naam doet vermoeden, en jij ook aangeeft, kun je binnen een pair relatief makkelijk een redundante omgeving opzetten. Buiten het paar wordt het een stuk(je) ingewikkelder.

[BenoitRoosens]

Klopt niet volledig naar mijn mening (de naam is wel degelijk region pair, ik heb het over het tweede deel van jouw bericht)... Het is waar dat, voornamelijk voor PaaS resources, geographical redundancy opties (dus tussen WEU en NEU) ingesteld kunnen worden maar het blijft de eer aan Microsoft om de failover uit te voeren. In mijn 10 jaar ervaring met Azure heb ik Microsoft dit nog nooit weten doen (zelf na outage can 16+ uur op een bepaalde Azure Service). Daarnaast heb je geen enkele capacity guarantee. Dit wil zeggen dat in het onwaarschijnlijk verlies van een complete regio (die bestaat uit meerdere Availability Zones, AZ's, die elk bestaan uit meerdere autonome datacenters) er onvoldoende capaciteit zal zijn in de region pair (tenzij je capacity reservations hebt gedaan, wat belange niet bestaat voor alle Azure resources).

Voor belangrijke zaken zal Microsoft zijn "mission critical design" aanraden. Concreet is dit een 2X design waar je een 2 regions een active/active of active/hot|cold standby setup doet. Dit hoeven geen regions in een region pair te zijn... Je kan dit perfect opzetten tussen South France and West EU bijvoorbeeld.

Wat mij voornamelijk verbaasd in dit verhaal (bedrijf waarvoor ik werk was geïmpacteerd door deze storing) is dat Microsoft dit niet heeft kunnen opvangen met de AZ's. Dit is net de reden waarom Microsoft (en AWS en Google ook trouwens) berusten op AZ's. Wij hebben impact gehad op services die multi-AZ gedeployed zijn. Ik verwacht toch meer redundatie, niet dat één fiber de volledige region in de soep doet draaien.

[Reactie gewijzigd door BenoitRoosens op 22 juli 2024 15:46]

[cascer1]

Er zijn een aantal Europese Azure regio's, dan mag het toch gewoon volgens GDPR?

[bassiej19]

Niet redundant?

[lenwar]

Jawel:
https://azure.status.microsoft/nl-nl/status

We determined a number of links between two datacenters have become unavailable due to a fiber cut, caused by severe weather conditions in the Netherlands, predominantly impacting communications between these datacenters in the West Europe region. As a result of this interruption, Azure services that rely on internal communications with other services may experience degraded performance.

Er zijn meerdere links geraakt. Dit doet dus suggereren dat het wel redundant is.

[latka]

Redundant maar fysiek op een plek is niet de redundantie die je wil. Net zoals offsite backups in het kantoor naast de serverruimte geen goed plan is en een fail-over datacenter op je main-datacenter niet heel slim is. Formeel redundant, maar je hebt er niets aan.

[Croga]

Het feit dat er meerdere links geraakt zijn betekend nog niet dat ze op één plek zitten....
Zo'n beetje de hele Noordzee was een zootje dus zelfs als ze 100km uit elkaar lagen kunnen ze alsnog beiden beschadigt zijn.

[lenwar]

Een Azure-site heeft drie data centres. Je kan verschillende maten van redundantie kopen. Binnen een data centre, verdeeld over de drie, of een variant over twee regio’s.
Alles heeft een ander prijskaartje

[iam2noob4u]

"a fiber cut" is enkelvoud. Als één enkele breuk het kan verpesten, is dat niet redundant.

[Caelestis]

enkelvoud = due to a cut fiber
meervoud = due to a fiber cut

[DeTeraarist]

Nee hoor, zodra je 'a' of 'an' gebruikt is het altijd enkelvoud.

[Caelestis]

Nee de meervoud verplaatst in dit geval naar het object.
Bij de eerste is het "a fiber"
Bij de tweede is het "a cut"
Dat is je enkelvoud.
In dit geval gaat het om een type, namelijk een fiber cut. Het wordt zo gebruikt om aan te geven dat het meerdere fibers kan betreffen maar hoeveel is niet duidelijk. De snede blijft enkelvoud

[kimjongdaillest]

Incorrect, confrère. Het is in beide gevallen enkelvoud.

[Caelestis]

En wat denk je dat de meervoud versie is? "due to fibers cuts"?

[firest0rm]

due to multiple fiber cables cut.
meervoud word het pas bij het aangeven van het type object.
Je moet in dit geval echt meer informatie over het object vertellen anders word het lastig begrijpen.

[Reactie gewijzigd door firest0rm op 22 juli 2024 15:46]

[Caelestis]

waarom dan geen
due to a single fiber cut?

[firest0rm]

omdat fiber enkelvoud is.
Fibres is meervoud.

[Caelestis]

Het gaat om de context wat verstaan wordt onder een "fiber cut" en dit is hoe amerikanen praten. Veel nederlanders denken dat ze het kunnen vergelijken met bijvoorbeeld brits engels maar slaan dan vaak de plank mis.
Het is een beetje hetzelfde als een "Lumber cut"
Ze zeggen ook niet "due to multiple Lumbers cut" maar "due to a lumber cut" kunnen meerdere planken tegelijk gesneden/gezaagd worden met 1 snede.

Buiten dat om zou het ronduit debiel zijn als het halve Azure verbinding weg valt als er 1 enkele fiber kapot gaat. Het gaat om de context.
Letterlijk de enige juist manier om een enkel fiber aan te geven is "due to a cut fiber" en dat zeggen ze niet.

[bassiej19]

In mijn ogen nog steeda onvoldoende redundant. Want het doel is juist normaliter dat je meerdere uitgang locaties hebt rondom een locatie, dat een bulldozer niet meerdere kabels tegelijk kan beschadigen.

Wij hebben tussen alle datacenters een ring voor dit. A->B->C->D en D weer naar A. Hoewel sommige onderling ook nog een verbinding hebben. Hier hebben we bewust naar locaties gezocht waar bij bijvoorbeeld B de verbinding naar A en naar C niet op exact de identieke plek liggen.

Dus bij een gebroken schakel zijn alle datacenters nog steeds bereikbaar.

[michaelkamen]

Wij hebben de situatie gehad dat we servers in twee datacenters hadden, bij Amsterdam, die met twee verbindingen van twee verschillende providers onderling verbonden waren. Volgens mij ging de ene verbinding langs de oostkant van Amsterdam, en de andere langs de westkant.
Uiteindelijk bleek dat er toch ergens een plekje was waar ze samenkwamen, en precies daar groef een graafmachine alle kabels stuk...

[supersnathan94]

Is een paar jaar geleden ook gebeurd bij werkzaamheden rond almere. Net op data ene stukje alle kabels naar de bertverderrie.

Alleen jammer dat ze tijdens reparatie met een “one-off” fout zaten waardoor alle lijnen verkeerd weer aangezet waren. Na 256 lassen pas getest en dan kun je gewoon weer opnieuw beginnen.

[tweazer]

Auw, dat is flink wat knippen, clampen, lassen etc etc ...

[Aaargh!]

Uiteindelijk bleek dat er toch ergens een plekje was waar ze samenkwamen

M.a.w. het systeem was niet redundant.

[michaelkamen]

Wij waren in de beleving van wel. Een van de providers had de locatie van de verbinding niet correct doorgegeven.

[osluis]

Die situatie hebben wij ook wel eens gehad. We hadden zelfs contractual vastgesteld bij de leverancier van de fibers dat ze fysiek twee verschillende trajecten zouden volgen en niet eens aan de zelfde kant van het gebouw het DC binnen mochten komen. Je komt er helaas pas achter dat het niet zo is op het moment dat het kapot getrokken wordt.

[Mellow Jack]

Mja de keuze om alles in 1 stad te draaien zegt al genoeg. Dit soort risico's horen bij die keuze (niet negatief bedoeld hoor, wij hebben eenzelfde constructie aangevuld met wat uitwijk richting clouds)

[cHoc]

Dat maakt niet uit, dan nog kan alles zo lopen dat je een Singel Point of Failure krijgt.

12 jaar terug gezien met een klant, alles was gescheiden zowel contractueel vast gelegd als fysiek aangelegd, maar door migraties door de jaren heen waarbij er niet is opgelet op wat voor verbindingen er werden gemigreerd kwamen alle verbindingen van de klant samen door 1 apparaat, en die ging onderuit, al het verkeer van alle 13 locaties door heel Nederland gingen plat...

[Ruuuuuubje]

En daarom moet je je documentatie op orde houden. Ik hoop dat de klant er van heeft geleerd

[psdata]

Niets met dit topic temaken maar wel leuk:

Heb ik ook eens mee gemaakt bij klant waarbij ik betrokken was, provider offerende en factureerde de path gescheiden fiber's (dark icw DWDM) om Amsterdam heen.
Bij een standaard onderhoud op een fiber punt van de provider ging toch alles plat, bleek dat men het van af het begin al verkeerd geschakeld had.
Behoorlijk wat gesteggel om geweest, a- om het op te lossen en b- om een financiële genoeg doening.
Kwam er later op neer dat ze de verbinding daarna 2 jaar lang niet gefactureerd hebben.
een jaar later gingen we deze partij verhuizen naar een ander DC, dus nieuwe verbindingen.

[tweazer]

Dat gaat ergens geld kosten en pijn doen ....
"The cloud is just someone else's computer"

[well0549]

Het systeem wel, maar ze kregen stroom van hetzelfde transformator huis. Een die ging volgens mij toen plat

[iRob87]

Uit het artikel:

“Microsoft adviseert dat gebruikers die hier last van hebben, indien mogelijk met een fail-over overschakelen naar een andere regio.”

[Marchel]

Een fail-over naar een ander DC, kan dat met een standaard dienstverlening binnen Azure? Heeft dat impact op je maandfactuur?

[supersnathan94]

Euhm. Zou bij default moeten zijn toch?

Normaliter zet je workloads minstens dubbel neer in een AZ (availability zone) dat houd in dat je in NL dus in twee datacenters je workload hebt draaien. Fikt er eentje af dan wordt alles overgezet naar een andere.

In AWS heb je bijvoorbeeld de AZ (EU-west-1) die weer is onderverdeeld in 1a, 1b en 1c. Drie DCs ergens in Ierland.

Ik weet niet hoe men dit bij azure doet, maar ik zou zeggen ongeveer gelijk. 1 DC in degraded state zou geen verstoring moeten opleveren. Het wordt alleen vervelend als het net niet degraded is. Dus veel packetloss en hoge latency, maar het werkt nog wel.

Dan liever gewoon de hele boel om zeep helpen en alles verhuizen.

[GeertJohan]

Bijna. Paar kleine kanttekeningen. Wat je een AZ noemt is eigenlijk een Region. En een Region is weer onderverdeeld in losse AZ's. Heel simpel gezegd is een Region een DC of groep DC's dicht bij elkaar met razendsnelle interconnects (fiber van de operator zelf). Ieder AZ heeft vaak eigen stroom en networking/core-routers, en kan dus onafhankelijk van andere AZ's falen.

Bijvoorbeeld bij Google Cloud Platform heb je de Region eu-west4 (NL/Groningen) En daar zijn 3 AZ's: eu-west4-a, eu-west4-b, eu-west4-c. Deze terminologie word ook bij Azure en AWS zo gebruikt. Een Region is overigens niet beperkt tot 3 AZ's. Bijvoorbeeld eu-west1 (BE/St. Ghislain) heeft 4 AZ's, dus ook een eu-west1-d.

In de regel is het verstandig om je servers dus te verdelen onder de verschillende AZ's van een Region. Netwerk verkeer binnen een Region is vaak erg goedkoop of zelfs gratis. Zo kan je meerdere servers clusteren zonder voor verkeer binnen je cluster te hoeven betalen. In principe zou je op die manier veilig moeten zijn voor dingen als brand en stukke uplinks.

Een multi-region setup is vaak moeielijker en complexer. Daar komen dingen als latency om de hoek kijken wat niet ideaal is in veel situaties.

Als ik het bericht van Micro$oft goed lees gaat het hier om stukke interconnect(s?) tussen verschillende AZ's binnen de West Europe Region. Dan is het vaak het best om de workload in de geisoleerde AZ uit te schakelen, zodat de andere twee AZ's door kunnen zonder blok aan het been. Echter, het bericht van MS is erg beknopt... Niet helemaal duidelijk welke lijnen/AZ's er nu precies stuk zijn..

AWS: https://docs.aws.amazon.c...s-availability-zones.html
GCP: https://cloud.google.com/compute/docs/regions-zones
Azure: https://learn.microsoft.c...ailability-zones-overview

[mac1987]

Nuttige toevoeging, maar ik weet niet of ik nu een +2 moet geven voor de inhoud of 0 voor de kinderachtige "Micro$oft"...

[supersnathan94]

Bijna. Paar kleine kanttekeningen. Wat je een AZ noemt is eigenlijk een Region. En een Region is weer onderverdeeld in losse AZ's. Heel simpel gezegd is een Region een DC of groep DC's dicht bij elkaar met razendsnelle interconnects (fiber van de operator zelf). Ieder AZ heeft vaak eigen stroom en networking/core-routers, en kan dus onafhankelijk van andere AZ's falen.

Mjaa is ook.

Laat we het er op houden dat ik niet meer helemaal scherp was .

[Dutch2007]

Zo goed als t zelfde l, maar dan ook 2, of 3x de kosten, dus zal t me verbazen als daar niet altijd voor gekozen wordt.

[supersnathan94]

Qua kosten valt het wel mee hoor. Als je namelijk je workload in bijvoorbeeld Kubernetes cluster verdeelt over 2 AZs dan kan de provider zelf kiezen in welke AZ ie het dan neer zet. Hoef jij niks voor te doen. Sterker nog. Dat wordt al voor je gedaan afhankelijk van het aantal nodes dat je afneemt.

Bij AWS zet je bijvoorbeeld 3 nodes neer in EU-West-1 en dan zet AWS ze (als het goed is) zelf neer in de 3 AZs van de regio. Fikt er een datacenter af dan wordt die node vanzelf verplaatst naar 1 van de andere twee AZs.

Maar je moet je workload natuurlijk dan wel dubbel uitvoeren. Dat kan soms lastiger zijn dan gedacht (door sessions van de client, of state in je applicatie bijvoorbeeld), maar meestal is het vrij simpel te regelen. Automatisch loadbalancen zorgt er dan voor dat het aan de client zijde gewoon transparant wordt doorgezet.

[Dutch2007]

Ah oké, doe niet zo heel veel met kubernetes.

Doelde zelf meer op een Windows vm.

[supersnathan94]

Het verplaatsen van een windows VM zou in principe ook redelijk vlot moeten kunnen zonder extra kosten toch?

De redundancy daarin zit hem meer in de synchroniseren van de virtuele HDD right?

Compute heb je alleen nodig als ie aanstaat en dat doe je ws niet dubbel (aangezien je niet twee keer met dezelfde VM kan gaan knutselen met dezelfde backing qua storage). Duss dubbel of drie keer zou ik niet zo zeggen. Misschien paar procent extra oid.

[aadje93]

En dan heb je dus ineens een DC dat dubbele lading nodes krijgt en dus fysiek overbelast word waardoor ineens 2x zoveel klanten last ondervinden, die er al zaten en die er dus bij gepropt worden

[supersnathan94]

Niet iedereen heeft dezelfde specificaties draaien. Sws heb je meer dan 2 DCs om over te verdelen en kan men er voor kiezen om globaal uitgerolde services dan niet in deze regio te draaien maar te rerouten naar andere regios waar ze ook draaien. Zo maakt het qua latency erg weinig uit of je in Ierland of in Frankfurt draait (voor AWS) dus daar heb je kog wel wat speling in.

[Mellow Jack]

Ja en ja

Je moet wel goed nadenken. Redundantie kan je op elke laag uitwerken. Je kan zelfs over verschillende clouds fail overs doen

[roccothehelper]

Binnen Azure kan je iets Locally redundant, Zone redundant en zelfs globally redundant draaien. Die laatste 2 die bijna niks meer kosten zouden dit probleem verhelpen.

[Reactie gewijzigd door roccothehelper op 22 juli 2024 15:46]

[OruBLMsFrl]

Global redundancy verdubbelt toch vaak wel de prijs vergeleken met local redundancy. Maar tegelijk is dat voor een productieomgeving best practice en vaak het geld domweg waard. Net een brandverzekering, die hoop je ook nooit nodig te hebben. En als je applicatie stack echt gaaf is, dan kun je zelfs active-active draaien en komen je kosten waarschijnlijk nog wat gunstiger uit. Blijft altijd inter-region traffic betalen.

[Mellow Jack]

Valt reuze mee hoor. Het is de meest makkelijke best practice

Een productie systeem is maar relatief. Een website met miljoenen bezoekers is iets anders dan een document archivering systeem

Voor het ene systeem wil je misschien wel dat het altijd werkt. Bij het andere systeem is het prima als je 5, 10, 15 etc etc minuten aan data kwijt bent als je maar snel weer online bent. Bij een nog ander systeem mag het best 2 weken eruit liggen maar moet de data altijd 100% kloppen.

Elk smaakje heeft een andere prijs

[OruBLMsFrl]

Zeker eens dat elk systeem ook productiesystemen hun unieke vereisten kunnen hebben, vaak het geld waard ergo niet altijd. Plus blijft geo replicatie in cloud altijd extra geld kosten. Dat is wel goed voor mensen mee te nemen in hun plannen, het is niet inbegrepen bij de basisprijs.

[wiseger]

Actice-active geldt niet voor je database. Die is nog altijd je single point of failure. Dus blijf je zitten met realtime replicatie van je data naar je pasive database als je bv SQL Server gebruikt.

[OruBLMsFrl]

https://learn.microsoft.c...transactional-replication

Kan wel active-active, maar niet met realtime consistency, wel al eventual consistency. Goed genoeg voor veruit de meeste (web) toepassingen. Steeds meer werkt toch met append only.

[Reactie gewijzigd door OruBLMsFrl op 22 juli 2024 15:46]

[Mimiix]

Gaat helaas niet voor alle diensten op.

[Andreplusplus]

GRS=Geo redundant

[Mimiix]

Kan helaas niet met alle diensten zonder de dienst daadwerkelijk nogmaals neer te zetten.

[Mimiix]

Dat gaat helaas niet altijd. Databricks authenticatie kan je dat niet mee doen, mits je echt in een aparte regio gaat zitten. Je ziet wel dat MS dit zelf doet met de kabels en daardoor ook zaken trager worden.

[eNaSnI]

Je krijgt waar je voor betaald

https://learn.microsoft.c...er?source=recommendations

[Keypunchie]

Volgens mij is er wel redundantie, want wij zien dat onze applicatie wel zijn ding doet, alleen lijkt het erop dat de lijn nu praktisch volledig volgetrokken is, dus er is veel vertraging en veel timeouts en dan later haalt de applicatie het wel bij.

[Frame164]

Redundantie zonder dat iemand we wat van merkt is echt heel complex. Het is meer dan alles dubbel (of meer) uitvoeren.

[Scriptkid]

je moet alles x4 uitvoeren want je krijgt de load van het andere data center er bij ten tijde van uitval dus bijde data centers mogen maar met 50% load draaien anders kom je bij een outage uit op boven de 100%, en dat is dus not sustainable.

[init6]

Zeer relevante vraag, het is niet ongebruikelijk dat datacenters meerdere kabels hebben lopen. Soms zelfs aan elke kant van het gebouw zodat tijdens graafwerkzaamheden dit soort problemen niet kunnen ontstaan.

[vincedd]

zo te zien niet, of flat redunant. Maar niet geografisch

[Pilovali]

Hoe kan een glasvezelkabel stuk gaan? In Nederland hebben we toch zowat alles onder de grond?

[InsanelyHack]

Een omgewaaide boom die met zijn wortels wat meeneemt? Niet geheel ondenkbaar toch?

[Pilovali]

Nee zeker niet, maar ik ga er stiekem wel van uit dat cruciale glasvezelverbindingen niet dicht bij bomen loopt. De glasvezellijn van Henk en Ingrid kan ik begrijpen, maar van een grote DC niet.

[hulseman]

Cruciale kabels liggen gewoon in woonwijken, langs dijken en door bosgebied. Daar ontkom je niet aan. In dit geval kan het goed zijn dat een grote boom is omgevallen en in zijn val wat ducts mee naar boven heeft genomen. Datakabels liggen gemiddeld op 60cm diepte binnen Nederland.

Doorgaans mogen wij geen vezel neerleggen direct naast een boom, maar als er geen alternatief is, dan zal de gemeente gewoon de vergunning toekennen. Dit heeft meer te maken dat tijdens t graven de wortels worden aangetast en daardoor de boom doodgaat en niet omdat het risico kan vormen voor de duct.

[Mankersmit]

Ik beheer en laat kilometers per jaar aan glasvezel infrastructuur aanleggen. Maar heb nog geen gemeente gehad die akkoord geeft binnen de kern van de boom open te ontgraven. Dan zijn het toch echt boomboringen, of is het minstens twee meter uit de kern blijven.

[bouwfraude]

Een gemeente kan ook heel moeilijk doen over een per ongeluk gesneuvelde boom bij graafwerkzaamheden, alleen is het zo jammer dat je later leest dat ze wel een kapvergunning afgegeven hadden om er 40.000 te laten kappen voor de biomassa.

[hulseman]

Zoals ik zeg, de boom gaat anders dood. Wij hebben genoeg zaken waarbij boringen niet mogelijk zijn en we de wortels bloot hebben moeten leggen in overleg met de toezichthouder van de gemeente. Vooral gangen in monumentale wijken waarbij nog een oude en ondiepe riolering en gasleidingen liggen ontkom je er niet aan.

[Robbierut4]

Er staan heel veel bomen in nederland. Een volledig boomvrije route lijkt me dan ook vrij lastig te realiseren. Zeker als je ook nog zit met afstand (hoe korter hoe beter) en vergunningen.

[jpsch]

Schijnbaar, bij elke storm hebben ze het over bomen die weggehaald moeten worden bij spoorwegen en snelwegen. Je zou toch verwachten dat die inmiddels allemaal wel gesneuveld zijn.

[hulseman]

Bomen leven en groeien dus. Een boom die over 15 jaar omvalt moet misschien zelfs nog gepland worden of is nu nog te klein.

[jpsch]

Maar als een boom langs het spoor staat, ga je de vervanger toch niet op dezelfde plek zetten? Dat ga je toch niet plannen, laat staan planten?

[frennek]

Als we elke boom gaan analyseren op potentieel gevaar bij omvallen, blijft er geen boom meer over in Nederland. Ik vind bomen langs het spoor een mooie opvulling van het landschap, we hebben er al zo weinig.

[jpsch]

Hoezo, ze schouwen toch?

https://www.bnnvara.nl/ka...eien-tegen-treinstoringen

[sfranken]

Het zou je ook verbazen hoe diep boomwortels soms zitten, of hoe ver. Vandaar het woord "diepgeworteld".

[Frame164]

In bijvoorbeeld Schiphol-Rijk staan veel datacenters en ook heel veel bomen. Gelukkig wel.

[RefriedNoodle]

Dan is het nog niet 'geknipt', tenzij twee worteltakken misschien vlak langs elkaar schuurden (als een schaar) waar toevallig een glasvezel tussen zat.

Dit is gewoon één van de letterlijke vertalingen van 'cut'. 'Onderbroken' was denk ik een betere vertaling geweest in deze context.

Dit is ook voor het eerst dat ik iemand het woord 'latentie' zie gebruiken in een Nederlandstalig IT-artikel.

[InsanelyHack]

Op een glasvezel zit geen rek. Wortels nemen de mantel mee en de glasvezel breekt simpelweg door de enorme kracht van de wortels. Iets met F x l of zoiets.

[RefriedNoodle]

Waar heb ik het over rek?

[loekf2]

Vertel mij wat. Reperatie van een glasveze kabel hier in de straat waar een heel appartementen complex doorheen ging duurde 2 maanden.

Succes Microsoft... bij KPN kan je een noodpakket krijgen (bundels op je mobiel abbo, Digitenne of een dongle/mobiel modem met 100GB/week).

[Het.Draakje]

Nog even afgezien van het feit dat, in de zakelijke markt, er wel wat meer partijen zijn die glasvezel verbindingen opleveren. Trouwens KPN Wholesale is een heel andere tak van sport dan KPN Particulieren.

Ik denk dat er voor die kabel naar het datacentrum wel een fatsoenlijke SLA afgesproken is. Reparatie zal echt geen week duren.

[fvanbrugge]

Hangt er soms van af waar de kabel gebroken is.Is de lokatie gemakkelijk te vinden en toegangelijk?
Je zal maar een breuk hebben bij een grote ondergrondse boring onder een breed kanaal vb.
Dit is andere koek dan zomaar ergens langs de weg. Heb de kabel door door vb verweven in boomwortels van omgevallen bomen dan kunnen er meerdere beschadigingen zijn. Een voor een op te lossen.
En voor iets of wat grotere werken zijn plannen en toelatingen nodig.

[ArcticWolf]

Bij coax hebben ze zo'n tool en die kan op de meter nauwkeurig laten zien waar de breuk zit. Weet niet of dat bij glasvezel ook is?
Vond het wel bijzonder om te zien toen de Ziggo monteur hier aan het werk was. Uiteindelijk zat er 6 meter van m'n huis onder de stoep een kabel breuk.

[DeVins]

Single ended line tool. Werkte ook op koper.

Glasvezel is wel door te lichten, denk ik

[dastdast78]

Tot op de centimeter met een goede OTDR meter

[Het.Draakje]

Nood breekt wet. In het geval van een storing bij een datacentrum is een vergunning behoorlijk snel geregeld. Een beetje (kabel)provider heeft wel een aparte afdeling die de storingen verhelpt. En dat zal niet afhankelijk zijn van de serviceafdeling van de particuliere divisie.

Materiaal, mensen en vergunningen zijn geen probleem in het afhandelen van groot zakelijk (netwerk)storingen.

Ik verwacht niet dat een storm even de kabel onder een kanaal beschadigd. Alles daarvoor en daarachter is snel op te lossen.

[Andreplusplus]

Dit lijkt me een bundeltje in MS eigen beheer

[Keypunchie]

Mijn verwachting is dat Microsoft gewoon zijn eigen glasvezel-teams heeft, danwel direct inhuurt.

In zo’n geval als dit is het hooguit een kwestie van de portemonnee trekken en ze gaan aan de slag.

[jongetje]

in 2 maanden leg je een woonwijk aan met glasvezel. Denk dat het meer met prioriteit te maken heeft.

Ik heb ook in de zakelijke glasvezelwereld gewerkt en daar zat gewoon een SLA van 24uur op. En na melden van een kabelbreuk staat er dan letterlijk binnen 3 a 4 uur een ploeg te graven en te lassen/herstellen. Betaal je alleen geen 3 a 4 tientjes per maand voor...

[marcop23]

Voor zover ik weet liggen de meeste kabels maar op 0,5 meter diepte. Een boom die omvalt en daarbij met de wortels naar boven komt, verstoort de bodem veel dieper.

[Jean luc Picard]

Bij ons gaan de kabels onder het twente kanaal door, gedaan met zo'n robot. Succes!

[georgekoeneman]

iets met boompjes, worteltjes, windje en kapot is de bende....

[Mimiix]

Wat je in dit geval ziet is dat door het wegvallen van de verbindingen, de beschikbare bandbreedte te kort komt. Ik sprak een medewerker van Microsoft, die gaf aan dat bepaald verkeer ook vertraagd wordt om op die manier te helpen met de doorstroming.

[RefriedNoodle]

Je hebt helemaal gelijk, maar mag je het dan nog redundant noemen?

Als je een verbinding tweevoudig uitvoert, maar beiden hebben niet genoeg reservecapaciteit om de andere over te nemen, dan heb je geen volledige redundantie. Je kunt de gevraagde capaciteit niet halen zonder dat beide lijnen actief zijn.

[tweazer]

Dat is een 1 voudige redundantie.Je kunt ook 2, 3, N voudig redundant zijn. Als je niet / weinig test hebben verstoringen meestal grotere impact ....

[Mimiix]

Ja en nee. Het lastige was bij Databricks dat de auth server er uit lag in zowel north als west eu.

Dat is dan duidelijk niet redundant, gezien het een paired region is.

[Frame164]

Je zou eigenlijk moeten dimensioneren op een piek die je krijgt bij een failover. Denk aan alle registraties op diverse diensten. Normaal gaan registraties geleidelijk, maar bij een failover krijg je een burst. Best wel lastig om dat perfect te dimensioneren.

[Andreplusplus]

en dan piepen over extra hyperscales ivm stroom- en waterverbruik...

[Zenix]

Klopt. Wij hebben bijvoorbeeld ook een Expressroute met 1Gb en twee vezels, dus kunnen 2Gb doen. Maar we beperken ons verkeer tot 1Gb, want als een kabel stuk is wil je niet tegen dit soort problemen aanlopen.

[Andreplusplus]

Klopt, ik eet ook maar de helft van elk brood dat ik koop.

[Falcon]

Ik bemerk in ieder geval bij onze Azure Container apps, SQL, CosmosDB in location/region "westeurope" nog vrij weinig. Ze hebben ook lage load i.v.m. Test/Staging omgeving.

Dus ik vraag mij even af hoe groot de impact is.

[Buitenaerts]

Wij hebben ook weinig last, MariaDB, AKS, public cotainer storage en Redis op Azure. Ook west Europa, maar ik zag vanochtend in Sentry wel het een en andere aan een aantal vage database meldingen voorbij komen... Maar dat aantal was te verwaarlozen...

[MornixRS]

Heeft iemand een idee hoe een glasvezelkabel door storm beschadigd kan raken?

[EliteGhost]

Boomwortels die de kabel meenemen wanneer de boom omwaait.
Over het algemeen worden bomen vermeden bij aanleg. Maar bomen naast een kabel (en in het algemeen) willen nog wel eens groeien en soms planten ze een boom bovenop kabels en / of leidingen.

[dasiro]

daarom dus dat onze topdesk instance zo crap was, zal dus wel om hetzelfde datacenter gaan, aangezien de melding van MS al om 7u22 UTC en die van topdesk 10:33 CEST, dus omgerekend een uurtje later.

nu vraag ik me af waar het zo lelijk gedaan heeft dat fibers geraakt kunnen worden, want ben niet echt mee met geografie in nederland

[Zenix]

Prachtig dit, denk aan overheid die vanwege regelgeving niet buiten West Europa kan, die hebben nu problemen. Toch wel slecht dat de kabel trajecten niet redundant zijn en dubbel zijn uitgevoerd. Azure kost al genoeg.

[Archcry]

Azure-diensten waarvoor gecommuniceerd moet worden met andere datacenters kunnen hierdoor in West-Europa tijdelijk niet goed werken

Welke storm gaat het hier precies over? De Azure dienst die ik veel gebruik (Microsoft Teams) werkt voor mij sinds de inceptie eigenlijk al tijdelijk niet goed.