Microsoft Azure West-Europa getroffen door stroomstoring

Microsoft meldt: 'Hoewel het overgrote deel van de impact op de klant om 09:15 UTC was verzacht, herstelde een langdurig herstel voor een kleine subset van opslagdiensten de volledige beschikbaarheid rond 17:10 UTC. Afgezien van de servicespecifieke gevolgen, moet u er rekening mee houden dat het Azure Resource Manager (ARM)-besturingsvlak een kleine dip in de beschikbaarheid heeft ondervonden (totale beschikbaarheid daalde tot ongeveer 98,9%) als gevolg van problemen veroorzaakt door een downstream-afhankelijkheid van Cosmos DB, waarbij fouten terugkeerden naar pre- incidentniveaus tegen 08:05 UTC.

Wat ging er mis en waarom?

We hebben instabiliteit van het elektriciteitsnet gedetecteerd in de vorm van spanningsdalingen/-stijgingen naar een van onze datacenters binnen fysieke AZ-01, een van de drie beschikbaarheidszones in de regio. Houd er rekening mee dat de 'logische' zones die door elk klantabonnement worden gebruikt, kunnen overeenkomen met verschillende fysieke zones. Klanten kunnen de Locations API gebruiken om deze mapping te begrijpen en om te bevestigen welke bronnen in de getroffen fysieke AZ worden uitgevoerd, zie: https://learn.microsoft .com/rest/api/resources/subscriptions/list-locations . Vanwege de langdurige aard van de instabiliteit hebben we besloten de belasting van het elektriciteitsnet over te dragen naar onze back-upgeneratoren. Tijdens dit proces deed zich echter een kritieke storing voor in een deel van het elektriciteitsdistributiesysteem, waardoor 10% van onze generatoren niet kon worden belast. Door deze storing was het hoofddistributiesysteem offline en het redundante systeem ontoegankelijk. Als gevolg van deze storing verloor ongeveer 1% van onze serverracks in deze Beschikbaarheidszone stroom.

Hoe reageerden wij?

Het probleem werd onmiddellijk door ons datacenterteam gemeld aan ons incidentbeheerteam, zodat relevante oproepbare technici de getroffen apparatuur bijna in realtime begonnen te onderzoeken. Tijdens het onderzoek hebben we bevestigd dat de netstroom was gestabiliseerd, dus hebben we de stroom om ongeveer 08:00 UTC terug naar het net overgedragen. Vervolgens zijn we begonnen de getroffen infrastructuur weer online te brengen, volgens onze standaardprocedures. Nadat de netwerk- en opslaginfrastructuur was hersteld, werden compute-schaaleenheden weer online gebracht, waardoor de service voor de overgrote meerderheid van de Azure-services om 09:15 UTC werd hersteld. In totaal werden vijf opslagschaaleenheden getroffen door dit incident. Na het herstel van de stroomvoorziening waren er vier volledig hersteld om 09:10 UTC, terwijl bij de vijfde hardwarediagnostiek en vervanging van onderdelen nodig was op ongeveer 5% van de opslagknooppunten. Als gevolg hiervan duurde het langer om de beschikbaarheid van de laatste <1% van de opslagaccounts te herstellen, met downstream-impact voor klanten en services die afhankelijk waren van deze laatste opslagschaaleenheid. Om 14:30 UTC was de beschikbaarheid van alle opslagaccounts, op enkele na, hersteld, en om 17:10 UTC was het volledige herstel voltooid.

Hoe kunnen we dit soort incidenten minder waarschijnlijk of minder impactvol maken?

Dit is onze “voorlopige” PIR die we proberen te publiceren binnen drie dagen na het beperken van de incidenten, om te delen wat we tot nu toe weten. Nadat onze interne retrospective is voltooid (doorgaans binnen 14 dagen) zullen we een “definitieve” PIR publiceren met aanvullende details/kennis – inclusief reparatie-items gerelateerd aan de datacenter/power trigger-gebeurtenis, en eventuele reparatie-items voor downstream-services om te herstellen van scenario’s zoals deze sneller.

Hoe kunnen klanten dit soort incidenten minder impactvol maken?

Overweeg het gebruik van Beschikbaarheidszones (AZ's) om uw services op fysiek gescheiden locaties binnen een Azure-regio uit te voeren. Om services beter bestand te maken tegen storingen op datacenterniveau zoals deze, biedt elke AZ onafhankelijke stroom, netwerken en koeling. Veel Azure-services ondersteunen zonegebonden, zone-redundante en/of altijd beschikbare configuraties: https://docs.microsoft.com/azure/availability-zones/az-overview

Voor bedrijfskritieke workloads moeten klanten een geodiversiteitsstrategie voor meerdere regio's overwegen om de gevolgen van incidenten zoals deze die gevolgen hadden voor één regio te voorkomen: https://learn.microsoft.com/training/modules/design-a-geographically-distributed -application/ en https://learn.microsoft.com/azure/architecture/patterns/geodes

Meer in het algemeen kunt u overwegen de betrouwbaarheid van uw toepassingen te evalueren met behulp van richtlijnen van het Azure Well-Architected Framework en de interactieve Well-Architected Review: https://docs.microsoft.com/azure/architecture/framework/resiliency

Overweeg ten slotte ervoor te zorgen dat de juiste mensen in uw organisatie op de hoogte worden gesteld van eventuele toekomstige serviceproblemen – door Azure Service Health-waarschuwingen te configureren. Deze kunnen e-mails, sms-berichten, pushmeldingen, webhooks en meer activeren: https://aka.ms/ash-alerts

Hoe kunnen we onze incidentcommunicatie nuttiger maken?

U kunt deze PIR beoordelen en eventuele feedback geven met behulp van onze snelle enquête met 3 vragen: https://aka.ms/AzPIR/MM12-HSG'