Beheer

Cloud
CloudFlare-storing

Cloudflare-storing veroorzaakt door eigen antistoringsproject

Nieuwe mesh-architectuur voor Cloudflare-datacenters down door BGP-fout.

© CloudFlare
22 juni 2022

Nieuwe mesh-architectuur voor Cloudflare-datacenters down door BGP-fout.

De wereldwijde internetstoring die is veroorzaakt door een storing bij webinfrastructuuraanbieder Cloudflare is te wijten aan een fout bij een groot project om juist beter bestand te zijn tegen storingen. De fout is opgetreden in negentien Cloudflare-datacenters, die slechts 4% van het totale netwerk vormen, maar de storing daar heeft wel 50% van het Cloudflare-verkeer geraakt. Het bedrijf zet openlijk uiteen wat er is gebeurd.

"Deze uitval is veroorzaakt door een wijziging die onderdeel was van een langlopend project om resilience op onze drukste locaties te verhogen", schrijven netwerkexpert Tom Strickx en hoofdingenieur Jeremy Hartman van Cloudflare. Een verandering in de netwerkconfiguratie voor die datacenters is verkeerd gegaan en heeft een storing in het content distribution network (CDN) van Cloudflare veroorzaakt. Uiteindelijk heeft de storing bij dat infrastructuurbedrijf een uur en een kwartier geduurd, maar de externe impact en nasleep waren groot.

Al anderhalf jaar bezig

Wereldwijd zijn uiteenlopende websites, webapps, SaaS-diensten en apps onderuit gegaan. Eindgebruikers en klanten van die derde partijen konden de sites en services van hun aanbieders niet bereiken. Ironisch genoeg gebruiken de getroffen content- en app-aanbieders het platform van Cloudflare juist om beter bereikbaar te zijn. Dit omvat naast het mirroren en cachen van content en app-code ook het afweren van DDoS-aanvallen. Ook ironisch is dat de storing bij Cloudflare zelf voortkomt uit een ambitieus project om veerkrachtiger te kunnen zijn.

Cloudflare is al anderhalf jaar bezig met een project om al zijn drukste locaties over te hevelen naar een nieuwe architectuur, die meer flexibiliteit en veerkracht moet geven. Tot op heden zijn al negentien datacenters geconverteerd naar wat het bedrijf intern MCP (Multi-Colo PoP (ofwel multi-colocated point-of-presence) noemt. Deze locaties zijn: Amsterdam, Atlanta, Ashburn, Chicago, Frankfurt, Londen, Los Angeles, Madrid, Manchester, Miami, Milan, Mumbai, Newark, Osaka, São Paulo, San Jose, Singapore, Sydney, en Tokyo. Bij die negentien drukke punten in het wereldomspannende Cloudflare-netwerk is het begin deze week mis gegaan.

Mesh-opzet voor netwerk

De nieuwe architectuur bevat een mesh-opzet voor het routeren van dataverkeer. Door gebruik van een mesh-topologie kan Cloudflare makkelijker delen van het interne netwerk in een datacenter uitschakelen en weer inschakelen. Dit kan dan worden gedaan om onderhoud uit te voeren of om een probleem op te vangen, leggen Strickx en Hartman uit. Tot de grote storing van dinsdag heeft deze opzet "aanzienlijke betrouwbaarheidsverbeteringen" opgeleverd. Daarbij kon Cloudflare ook onderhoudswerk uitvoeren zonder dat het verkeer van klanten werd verstoord.

Tot dinsdag dus. Toen is het misgegaan. Een wijziging in de netwerkconfiguratie voor het fundamentele internetrouteringsprotocol BGP (Border Gateway Protocol) heeft onvoorziene uitval veroorzaakt, juist in het netwerkdeel met de MCP-nieuwe architectuur. Door de wijziging is een verzameling van 'naast elkaar liggende' IP-adressen ingetrokken qua bereikbaarheid. Die verzameling, een zogeheten prefix, werd niet langer 'geadverteerd' voor routering van netwerkverkeer. En daarmee waren de negentien locaties, behorende tot de drukste van Cloudflare, ineens offline.

De negentien getroffen datacenters waren qua aantal niet heel groot, maar qua afhandeling van Cloudflare's https-verkeer wél:

CloudFlare-storing https-verkeer ingestort

Na 5 minuten alarm

Deze plotse uitval is ontstaan enkele uren nadat de - fataal blijkende - wijziging is doorgevoerd. De configuratieverandering is namelijk om 3:56 ingezet, en geleidelijk aan 'doorgedruppeld' in de infrastructuur van het internetbedrijf. De initiële uitrol was bij locaties die nog de oude architectuur gebruiken. Pas om 6:17 is de wijziging toegepast op de drukste locaties, die overigens nog niet alleen 'MCP-enabled' zijn. Pas toen de verandering bij de locaties met MCP arriveerde, is "het incident begonnen", zoals Cloudflare het zelf omschrijft.

Dat was om 6:27 uur, waarna de negentien locaties in rap tempo offline zijn gegaan. Slechts vijf minuten nadat de wijziging 'toesloeg' bij de negentien datacenters is intern bij Cloudflare het alarm afgegaan. Maar het kwaad was toen al geschied. Nog geen half uur nadat de storing is ontstaan, hebben beheerders van het bedrijf de eerste, corrigerende wijziging doorgevoerd op een router. Dit was om de oorzaak van de grote uitval te kunnen verifiëren.

Bevindingen en verbeteringen

De eigenlijke oorzaak is daarmee achterhaald en zeven minuten later (om 06:58 uur) is het echte herstelwerk begonnen. Het eerste van de offline geschopte datacenter is toen weer online gekregen. Zo'n drie kwartier later (om 7:42 uur) is het laatste terugzetten van de "problematische wijziging" gerealiseerd. Daarbij is er nog enige vertraging opgelopen, omdat netwerkingenieurs elkaar in de weg zaten. Ze hadden eerdere corrigerende wijzigingen gewijzigd, en daarmee dus verricht herstelwerk weer ongedaan gemaakt. Om 8:00 uur is het incident officieel voor gesloten verklaard.

CloudFlare geeft in zijn post mortem over de grote storing nog meer technische details. Het sluit die blogpost af met een aantal bevindingen die het heeft gedaan en verbeteringen die het gaat doorvoeren. Daaronder een betere opzet van de gefaseerde uitrol voor veranderingen, waarbij ditmaal de nieuwe MCP-architectuur pas 'aan het eind' aan de beurt kwam. Verder gaat het infrastructuurbedrijf ook een automatische hersteloptie ('commit-confirm' rollback) instellen. Eerstgenoemde verbetering zou de impact van deze storing aanmerkelijk hebben verminderd, terwijl de tweede verbetering zou hebben gezorgd voor een veel sneller herstel.

Tijdens de storing is Cloudflare's interne systeem voor load-balancing zwaar overbelast geraakt en onderuit gegaan:

CloudFlare-storing overbelasting load-balancing

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.