Beheer

Cloud
GitHub-storing

43 seconden uitval gaf GitHub 24 uur storing

Het begon met geplande vervanging van uitvallende optische 100G-netwerkapparatuur. Toen plots 43 seconden verbindingsverlies.

© GitHub
31 oktober 2018

Het begon met geplande vervanging van uitvallende optische 100G-netwerkapparatuur. Toen plots 43 seconden verbindingsverlies.

GitHub gaat met de billen bloot in een post mortem over de grote storing die de repositorysite eerder deze maand heeft getroffen. De oorzaak is een uitgevallen verbinding tussen twee locaties: beide aan de Amerikaanse oostkust. Na 43 seconden was die uitval weer hersteld, maar daarna volgde 24 uur en 11 minuten aan storing wereldwijd.

Terwijl de storing niet heel GitHub onderuit heeft gehaald, was de dienstverlening aan developers wel flink gemankeerd. Delen van het GitHub-platform werden niet beïnvloed door het incident, schrijft technologiehoofd Jason Warner, maar meerdere interne systemen zijn geraakt. "Dit resulteerde in weergave van informatie die achterhaald en inconsistent was."

Veerkrachtige systemen

Warner biedt namens GitHub oprechte excuses aan voor de impact die de storing had op alle developers die de site gebruiken voor hun ontwikkelwerk. Hij benadrukt dat het bedrijf zich bewust is van het vertrouwen dat de gebruikers hechten aan een goed werkend GitHub. "We zijn er trots op dat we veerkrachtige systemen bouwen die ervoor zorgen dat ons platform een hoge mate van beschikbaarheid heeft." Alleen lukt dat dus niet altijd, zo is eerder deze maand gebleken. "We hebben jullie teleurgesteld en dat spijt ons enorm."

GitHub kan het uitleggen, en doet dat ook. "We kunnen de problemen die zijn ontstaan door de onbruikbaarheid van GitHub's platform niet ongedaan maken", schrijft Warner in de post mortem. "Maar we kunnen wel uitleggen welke gebeurtenissen hebben geleid tot dit incident, welke lessen we hebben geleerd, en welke stappen we nemen om er beter voor te zorgen dat dit niet nog eens gebeurt."

Gepland routinewerk

Het begon allemaal, 's avonds op 21 oktober, met gepland onderhoudswerk. Dit was specifiek: het vervangen van uitvallende optische 100G-netwerkapparatuur. Deze routinewerkzaamheden hebben echter plots voor uitval gezorgd. De verbinding tussen GitHub's netwerkhub en het eigen hoofddatacenter aan de Amerikaanse oostkust werd onderbroken. Na 43 seconden was dit weer hersteld, maar het zorgde voor een domino-effect dat het datacenter aan de Amerikaanse westkust en vervolgens GitHub wereldwijd heeft geraakt.

De topologie van GitHub's datacenterfaciliteiten is wel dusdanig ontworpen dat het uitval en storingen moet kunnen opvangen. De door GitHub gebruikte high availibility tool voor MySQL, Orchestrator, beheert de complexe opstelling en zorgt normaliter voor geautomatiseerde failover. Bij de uitval, waardoor een netwerkpartitionering ontstond, heeft de Orchestrator een verschuiving geïnitieerd van welke clusters leidend zijn, voor schrijf- en ook leesacties. Tijdens de korte verbindingsuitval is er echter een datadiscrepantie ontstaan.

Nieuwe topologie ontstaan

"De databaseservers in het US East Coast datacenter bevatten een korte periode aan writes die nog niet waren gerepliceerd naar de US West Coast faciliteit", blogt GitHub's head of technology. "Doordat de databaseclusters in beide datacenters nu writes bevatten die niet aanwezig waren in het andere datacenter waren we niet in staat om de primary veilig weer over te hevelen naar het US East Coast datacenter."

Interne monitoringsystemen gaven vervolgens alarmmeldingen: meerdere systemen hadden te kampen met fouten. Onderzoek door de eigen ingenieurs die hulpverleningsdienst hadden, wees uit dat de replicatietopologie voor de databases alleen servers van het datacenter aan de westkust omvatte. Het hoofddatacenter aan de oostkust was weliswaar weer online, maar bleek buiten de boot te vallen van het replicatiegeheel.

Handmatige vergrendeling van interne deploymenttools volgde, waarna databasebeheerders erbij werden gehaald. Aan hun de complexe taak om de ontstane staat van de databaseclusters te onderzoeken, te ontwarren en opnieuw in te richten. De database-opstelling aan de oostkust moest weer worden ingesteld als primary voor elk cluster, en dan moest de replicatietopologie weer worden opgebouwd.

Data-integriteit is heilig

"Deze inspanning was een uitdaging omdat tegen die tijd het West Coast databasecluster al bijna 40 minuten schrijfacties van onze applicatielaag had opgenomen." De 43 seconden verbindingsuitval was geëscaleerd naar een datadiscrepantie van 40 minuten. "Daarnaast waren er nog de meerdere secondes aan writes die in het East Coast cluster bestonden maar die niet waren gerepliceerd naar de West Coast", legt Warner uit. Dit verhinderde weer replicatie van nieuwe schrijfacties terug naar de oostkust.

Opoffering van datasets, de één ten gunste van de ander, was niet acceptabel. "Het bewaken van de vertrouwelijkheid en integriteit van gebruikersdata is GitHub's hoogste prioriteit." Dus was failover terug geen optie. Het moest dus een fail-forward worden, om te herstellen van de grote gevolgen die de 43 seconden durende netwerkuitval had. Echter, ook deze complexe oplossing bleek makkelijker gezegd dan gedaan.

De applicaties die draaiden in het datacenter aan de oostkust konden wel hun data schrijven naar een MySQL-cluster aan de westkust, maar de latency van een transnationaal retourtje was niet te doen. De latency van kust-naar-kust heen en weer gaan van data writes viel buiten het vermogen van de meeste database-calls. Het op deze manier aanpakken zou de service voor veel gebruikers onbruikbaar maken.

Terabytes aan back-up herstellen

De keuze was dus tussen twee kwaden: een langer durende degradatie van GitHub's service of regelrechte uitval. Het alles overheersende belang van data-integriteit heeft GitHub doen kiezen voor eerstgenoemde optie. Daarvoor is toen een restore-operatie ondernomen van de reguliere back-ups, die elke vier uur plaatsvinden. Dit herstel van meerdere terabytes aan data heeft weer uren in beslag genomen, waarbij die data is ingeladen in nieuw ingerichte MySQL-servers.

Warner geeft aan dat deze procedure minstens op dagelijkse basis wordt getest, dus de benodigde recoverytijd was goed bekend. "Alleen hadden we tot dit incident nooit een volledig cluster vanaf de back-up opnieuw hoeven op te bouwen. In plaats daarvan waren we in staat om te vertrouwen op andere strategieën, zoals delayed replicas."

Maatregelen

De uitgebreide post mortem van GitHub's grote storing sluit af met maatregelen die het bedrijf nu neemt om herhaling te voorkomen of in ieder geval te beperken. Daaronder allereerst een herconfiguratie van de Orchestrator om eventuele herindeling van database-primaries te beperken tot regionale zones. Wat die tool heeft gedaan, was namelijk geheel volgens de configuratie alleen bleek de applicatielaag de resulterende topologieverandering niet aan te kunnen. Verder noemt Warner een al lopend groot project om meerdere datacenters in een active/active/active-opstelling te plaatsen.

Lees meer over Beheer OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.