Betrouwbaarheid in Azure Storage-acties

Azure Storage Actions is een volledig beheerd platform waarmee gegevensbeheertaken voor Azure Blob Storage en Azure Data Lake Storage worden geautomatiseerd. U plant opslagtaken die worden uitgevoerd op uw opslagaccounts. U kunt taken configureren om blobs te verwijderen, blobtags in te stellen en toegangslagen te wijzigen op basis van de leeftijd van uw gegevens.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Storage Actions bestand maakt tegen tijdelijke fouten, configuratieproblemen, storingen in beschikbaarheidszones, regiobrede fouten en serviceonderhoud. Ook worden opties voor back-up en herstel en belangrijke informatie over de sla (Service Level Agreement) voor Azure Storage Actions beschreven.

Important

Wanneer u rekening houdt met de betrouwbaarheid van Azure Storage Actions, moet u elk opslagaccount met een toewijzing van een opslagtaak overwegen. Microsoft beheert de beschikbaarheid van de service Opslagacties. U bent verantwoordelijk voor het kiezen van redundantieconfiguraties voor opslagaccounts die voldoen aan de betrouwbaarheidsvereisten van uw workload. Een storing in een opslagaccount kan voorkomen dat toegewezen opslagtaken worden uitgevoerd, zelfs wanneer het besturingsvlak Opslagacties beschikbaar blijft. Zie Betrouwbaarheid in Azure Blob Storage voor informatie over de betrouwbaarheidskenmerken van redundantieconfiguraties voor opslagaccounts.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productiewerkzaamheden raden we u aan het volgende te doen:

  • Configureer elk doelopslagaccount met de redundantieoptie die voldoet aan uw betrouwbaarheidsvereisten. Gebruik voor de meeste productieworkloads minimaal zone-redundante opslag (ZRS). Als u veerkracht nodig hebt tegen een regiobrede storing en uw opslagaccount zich in een gekoppelde regio bevindt, gebruikt u geografisch zone-redundante opslag (GZRS). De uitvoering van de opslagtaak neemt de betrouwbaarheidskenmerken van het doelopslagaccount over.

  • Schakel soft delete voor blobs in voordat u opslagtaken gebruikt om blobs te verwijderen. Schakel voorlopig verwijderen voor blobs in op elk doelopslagaccount, zodat u blobs kunt herstellen die een opslagtaak onbedoeld verwijdert tijdens de bewaarperiode.

  • Vermijd overlappende opslagtaken met andere beleidsregels voor levenscyclusbeheer. Configureer geen opslagtaak en een ander levenscyclusbeheerbeleid om conflicterende bewerkingen uit te voeren op dezelfde blobs. Een verwijderingsbewerking voor een opslagtaak kan bijvoorbeeld mislukken als een Blob Storage levenscyclusbeheerbeleid probeert dezelfde blob te verwijderen.

  • Valideer de configuratie van uw opslagacties voordat u deze toepast. Gebruik een voorbeeld van voorwaarde voor gerichte validatie tijdens het opstellen van taakvoorwaarden en gebruik een mock run om de volledige opdracht te valideren voordat u deze inschakelt om bewerkingen uit te voeren.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Wanneer u Azure Storage Actions gebruikt, maakt u een of meer opslagtaakresources. Elke opslagtaak bevat voorwaarden die objecten en bewerkingen selecteren die moeten worden uitgevoerd op objecten die aan de voorwaarden voldoen. Als u een opslagtaak wilt uitvoeren op een opslagaccount, maakt u een opslagtaaktoewijzing. De toewijzing wordt opgeslagen als onderdeel van de opslagaccountresource en identificeert op welke objecten de taak is gericht, wanneer en hoe vaak de taak wordt uitgevoerd en waar uitvoeringsrapporten worden opgeslagen. Wanneer een taakuitvoering de Completed status bereikt, schrijft de service een uitvoeringsrapport naar de locatie die is opgegeven in de toewijzing.

U bent verantwoordelijk voor het configureren van elke toewijzing en het toewijzen van een geschikte Azure rol aan de beheerde identiteit van de opslagtaak.

Fysieke architectuur

Azure Storage Actions heeft twee lagen die relevant zijn voor betrouwbaarheid:

  • Besturingslaag: Aanvragen stromen via Azure Resource Manager naar de resourceprovider Azure Storage Actions, die beheerbewerkingen en asynchrone inrichtingswerkstromen voor opslagtaken en toewijzingen verwerkt.

  • Gegevensvlak: Omvat de scheduler, workers die de omstandigheden van opslagtaken evalueren en de geconfigureerde bewerkingen uitvoeren voor doelopslagaccounts en rapportageonderdelen. Deze onderdelen draaien op de Azure Storage-infrastructuur.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke fouten voor meer informatie.

Tijdelijke fouten kunnen op twee manieren van invloed zijn op Azure Storage acties:

  • Beheerbewerkingen: Als u het beheer van Storage Actions automatiseert, zoals het implementeren of wijzigen van opslagtaken, bent u verantwoordelijk voor het afhandelen van tijdelijke fouten in uw automatisering. Gebruik een beperkt aantal nieuwe pogingen met een juiste vertraging tussen pogingen.

  • Taakuitvoering: Wanneer een doelopslagaccount bewerkingen beperkt, schakelt Azure Storage Actions terug en probeert het na een vertraging opnieuw. Zolang de toewijzing voortgang blijft boeken, blijft Storage Actions het opnieuw proberen gedurende de levensduur van de werkstroom. Als de toewijzing vier uur lang geen voortgang boekt bij het weergeven of verwerken van blobs, beëindigt Storage Actions de uitvoering, zodat een andere toewijzing kan worden gestart.

Azure Storage Actions verwerkt slechts één toewijzing per keer voor elk doelopslagaccount. Het regelt zelf de taakuitvoering, zodat toepassingsworkloads in het doelopslagaccount voorrang krijgen. De uitvoeringsschaal is afhankelijk van de transactiecapaciteit die beschikbaar is in het account. Wanneer er minder transactiecapaciteit beschikbaar is, kan een taakuitvoering worden afgeknepen en kan het langer duren om te voltooien. Zie Schaalafhankelijkheid van transactiecapaciteit die beschikbaar is voor het opslagaccount voor meer informatie.

Niet alle mislukte taakuitvoeringen zijn van voorbijgaande aard. Een taak kan bijvoorbeeld mislukken omdat de beheerde identiteit niet over de vereiste machtigingen beschikt, het aantal aanvragen een schaallimiet overschrijdt, of het doelopslagaccount netwerktoegang blokkeert. U bent verantwoordelijk voor het bewaken van de taakstatus, metrische gegevens en dashboards en het corrigeren van deze fouten. Er wordt alleen een uitvoeringsrapportage gemaakt voor een run die de Completed status bereikt. Mislukte en overgeslagen uitvoeringen produceren geen uitvoeringsrapport. Vergelijk werkelijke uitvoeringstijden met het toewijzingsschema om uitvoeringen te identificeren die niet zijn uitgevoerd. Zie Probleemoplossing voor opslagtaken voor informatie over het identificeren en oplossen van taakfouten.

Tolerantie voor configuratieproblemen

Voorwaarden voor opslagtaken bepalen op welke objecten een taak werkt en een onjuiste voorwaarde of bewerking kan van invloed zijn op onbedoelde objecten. Microsoft voert elke taak uit op basis van de configuratie. U bent verantwoordelijk voor het valideren van de toekenning voordat u deze toestaat om gegevens te wijzigen, met name wanneer deze destructieve of onherstelbare bewerkingen bevat.

Gebruik de volgende validatiemethoden:

  • Preview van voorwaarde: Terwijl u taakvoorwaarden opstelt, gebruikt u de preview-functie in de Azure-portal of de Preview Actions REST API om een voorbeeld van maximaal 5000 blobs te evalueren. Een voorvertoning retourneert onmiddellijke resultaten en genereert geen uitvoeringsrapport.

  • Mock run: Voordat u de toewijzing inschakelt om bewerkingen uit te voeren, maakt u een mock run voor de definitieve validatie. Een mock-uitvoering evalueert elke blob in het toewijzingsbereik zonder de geconfigureerde bewerkingen uit te voeren. Het wordt asynchroon uitgevoerd als een normale taak en produceert een CSV-uitvoeringsrapport. Controleer het rapport om te controleren welke blobs overeenkomen met de voorwaarden en welke bewerkingen de taak zou uitvoeren.

Validatie vermindert het risico op onbedoelde handelingen, maar vervangt geen gegevensbeveiliging. Voordat u opslagtaken gebruikt om blobs te verwijderen, schakelt u zacht verwijderen voor blobs in op elk doelopslagaccount. Met zacht verwijderen kunt u verwijderde blobs herstellen tijdens de geconfigureerde bewaarperiode.

Controleer de toewijzingen van opslagtaken samen met andere beleidsregels voor gegevensbeheer die op dezelfde blobs werken. Configureer geen overlappende taken of beleidsregels die conflicterende bewerkingen uitvoeren. Een verwijderingsbewerking voor een opslagtaak kan bijvoorbeeld mislukken als een Blob Storage levenscyclusbeheerbeleid probeert dezelfde blob te verwijderen.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

De beheerlaag van Azure Storage Actions is zone-redundant. Microsoft beheert de distributie automatisch over meerdere beschikbaarheidszones en u selecteert de zones niet. Tijdens een storing in de beschikbaarheidszone kunt u opslagtaken en -toewijzingen blijven beheren.

De veerkracht van de taakuitvoering is afhankelijk van de redundantieconfiguratie van elk doelopslagaccount, omdat de taken op de gegevens in die accounts worden uitgevoerd. Als taakuitvoering moet worden voortgezet tijdens een zonefout, configureert u elk doelaccount met een zone-redundante opslagoptie (ZRS, GZRS of RA-GZRS).

In het volgende voorbeeld ziet u het besturingsvlak van Storage Actions en een taak die is gericht op een zone-redundant account in een regio met drie zones. Zowel het besturingsvlak als het doelaccount kunnen blijven werken als één zone niet beschikbaar is:

Diagram met het besturingsvlak Opslagacties en een ZRS-doelopslagaccount dat drie beschikbaarheidszones beslaat.

Een LRS-doelaccount is daarentegen niet zone-redundant. In het volgende voorbeeld omvat de control plane alle drie de zones en wordt het doelaccount weergegeven in beschikbaarheidszone 1 om een account weer te geven dat geen zones omvat. Als de zone die als host fungeert voor het doelaccount niet meer beschikbaar is, blijft het besturingsvlak beschikbaar, maar kan de taak pas worden uitgevoerd als het doelaccount weer beschikbaar is:

Diagram met het besturingsvlak Opslagacties dat drie beschikbaarheidszones en een LRS-doelaccount beslaat dat wordt weergegeven in zone 1.

Requirements

  • Regioondersteuning: Wanneer u een toewijzing van een opslagtaak configureert, moeten de opslagtaak en het doelopslagaccount zich in dezelfde regio bevinden. Als u de taakuitvoering bestand wilt maken tegen zonefouten, kiest u een regio die ondersteuning biedt voor zowel Azure Storage Actions als beschikbaarheidszones.

  • Configuratie van opslagaccount: Configureer elk doelaccount met een zone-redundante opslagoptie. Lokaal redundante opslag (LRS), geografisch redundante opslag (GRS) en geografisch redundante opslag met leestoegang (RA-GRS) bieden geen zoneredundantie in de primaire regio.

Considerations

Zoneredundantie op het besturingsvlak maakt taakuitvoering niet zone-tolerant wanneer een doelopslagaccount niet beschikbaar is. Evalueer de redundantieconfiguratie van elk doelaccount afzonderlijk.

Cost

Zoneredundantie voor het besturingsvlak van Storage Actions is automatisch en er zijn geen extra kosten voor Storage Actions om dit in te schakelen. Standaardgebruikskosten voor taakuitvoeringen, doelobjecten en aangeroepen bewerkingen zijn nog steeds van toepassing. Zie Azure Storage Actions pricing voor meer informatie.

De redundantieoptie die u voor elk doelopslagaccount selecteert, is van invloed op uw Azure Storage kosten. Zie De prijzen van Blob Storage voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

Zoneredundantie is automatisch voor het besturingsvlak van Storage Actions. U configureert zoneredundantie niet afzonderlijk voor opslagtaken of toewijzingen.

Als u taakuitvoering bestand wilt maken tegen uitval van beschikbaarheidszones, selecteert u een zone-redundante opslagoptie wanneer u elk doelopslagaccount maakt of de redundantieconfiguratie van een bestaand account wijzigt.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer het control plane van Storage Actions beschikbaar is, doelopslagaccounts een zone-redundante opslagoptie gebruiken en alle beschikbaarheidszones operationeel zijn.

  • Bewerking over meerdere zones: Microsoft distribueert de besturingsvlakinfrastructuur van Storage Actions over beschikbaarheidszones. Taakuitvoeringen worden uitgevoerd op elk doelopslagaccount en Azure Storage distribueert transparant aanvragen over de infrastructuur die als host fungeert voor het account.

  • Replicatie van gegevens in meerdere zones: Met Storage Actions worden de blobgegevens die door taken worden verwerkt, niet opgeslagen of gerepliceerd.

    Azure Storage repliceert synchroon gegevens in accounts die gebruikmaken van een zone-redundante opslagoptie over beschikbaarheidszones heen in de primaire regio. Azure Storage voltooit geen schrijfbewerking totdat de gegevens worden gerepliceerd in de zones die door het account worden gebruikt.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer het besturingsvlak voor Opslagacties beschikbaar is, doelopslagaccounts een zone-redundante opslagoptie gebruiken en er een storing is in één beschikbaarheidszone.

  • Detectie en respons: Microsoft detecteert en reageert op storingen die van invloed zijn op de controlelaag van Storage Actions.

    Voor doelaccounts die gebruikmaken van een zone-redundante opslagoptie, routeert Azure Storage automatisch taakuitvoering en opslagbewerkingen naar zones die in orde zijn. U hoeft geen failover te initiëren.

  • Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Opslagtaken die zijn gericht op beschikbare zone-redundante accounts blijven vorderen. Taken die zijn gericht op een niet-beschikbaar account, kunnen mislukken.

    In behandeling zijnde run-once-toewijzingen kunnen nog steeds worden opgepakt. Voor runs die zijn onderbroken of mislukt, moet u deze mogelijk handmatig opnieuw plannen, afhankelijk van waar de verwerking is gestopt.

  • Verwacht gegevensverlies: Storage Actions slaat geen afzonderlijke kopie van uw blobgegevens op. Het verwachte gegevensverlies is afhankelijk van de redundantieconfiguratie van elk doelaccount. Wanneer een account gebruikmaakt van een zone-redundante opslagoptie, repliceert Azure Storage synchroon de gegevens tussen beschikbaarheidszones in de primaire regio, zodat een zonefout naar verwachting geen gegevensverlies voor voltooide schrijfbewerkingen veroorzaakt.

  • Verwachte downtime: Het control plane van Storage Actions blijft beschikbaar tijdens een zonefout.

    Taakuitvoering gaat door zolang het doelopslagaccount toegankelijk blijft. Als het account niet meer beschikbaar is, zoals een LRS-opslagaccount in een getroffen zone, kunnen de betrokken uitvoeringen mislukken.

  • Herdistributie: Microsoft beheert de respons en de herdistributie van het besturingsvlak van Storage Actions.

    Azure Storage stuurt automatisch bewerkingen door voor accounts die gebruikmaken van een zone-redundante opslagoptie naar gezonde zones. Er is geen actie van de klant vereist.

Herstel van zone

Wanneer de uitgevallen zone wordt hersteld, herstelt Microsoft de normale distributie van het besturingsvlak. Azure Storage herstelt de normale werking voor zone-redundante accounts. Geplande taaktoewijzingen worden volgens hun schema's voortgezet.

Terugkerende toewijzingen worden hervat volgens hun geconfigureerde planningen. In behandeling zijnde run-once-toewijzingen kunnen nog steeds worden opgepikt. Controleer de status van runs die worden beïnvloed door de storing. Afhankelijk van waar de verwerking is gestopt, moet u mogelijk onderbroken of mislukte runs opnieuw plannen.

Testen op zonefouten

Microsoft beheert zonedistributie, failover en herstel voor het besturingsvlak Opslagacties en voor zone-redundante opslagaccounts. U hoeft uitval van platformzones niet te testen. Test uw operationele procedures door te controleren of u mislukte taakbewerkingen kunt identificeren en deze veilig opnieuw kunt uitvoeren.

Tolerantie voor storingen in de hele regio

De veerkracht van de uitvoering van opslagtaken tijdens een regiobrede storing is afhankelijk van de redundantieconfiguratie van elk doelopslagaccount. Als een doelaccount gebruikmaakt van een geografisch redundante opslagoptie (GRS, GZRS, RA-GRS en RA-GZRS), kan het opslagaccount een failover uitvoeren naar de gekoppelde regio en kunnen toekomstige opslagtaken worden uitgevoerd in de nieuwe primaire regio.

Geografisch redundante opslagaccounts als doel

Voor een geografisch redundant opslagaccount is de regio die momenteel schrijfbewerkingen accepteert de primaire regio. Azure Storage repliceert gegevens asynchroon naar de gekoppelde regio van het account, de secundaire regio.

Opslagtaken worden uitgevoerd op het account in de primaire regio. Nadat er een failover van het account heeft plaatsgevonden, wordt de vorige secundaire regio de nieuwe primaire regio en worden toekomstige uitvoeringen van de opslagtaak daar automatisch uitgevoerd. Azure Storage Actions hebben geen afzonderlijke failover-actie nodig.

Requirements

Cost

Voor geografisch redundante opslagconfiguraties worden kosten in rekening gebracht voor replicatie en opslag in de secundaire regio. Zie De prijzen van Blob Storage voor meer informatie.

Ondersteuning voor meerdere regio's configureren

Selecteer een optie voor geografisch redundante opslag wanneer u het doelopslagaccount maakt of de redundantieconfiguratie van een bestaand account wijzigt.

Als u een toewijzing van een opslagtaak maakt terwijl het doelaccount gebruikmaakt van een niet-geografisch redundante optie en het account later wordt omgezet naar GRS, GZRS, RA-GRS of RA-GZRS, werkt u de toewijzing bij voordat u failover van door de klant beheerde accounts start. U kunt elke toewijzingseigenschap wijzigen. De update zorgt ervoor dat het besturingsvlak Opslagacties de nieuwe geografisch redundante configuratie van het account detecteert.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een doelopslagaccount gebruikmaakt van een geografisch redundante opslagoptie en zowel de primaire als de secundaire regio's operationeel zijn.

  • Bewerking voor meerdere regio's: Tijdens de normale bewerking bevinden de definitie, toewijzing en doelopslagaccount van de opslagtaak zich in de primaire regio. De secundaire regio verwerkt geen opslagtaakbewerkingen.

  • Replicatie van gegevens in meerdere regio's: Azure Storage Actions repliceert niet onafhankelijk de blobgegevens die door taken worden verwerkt.

    Azure Storage repliceert gegevens asynchroon van de primaire regio naar de secundaire regio. Omdat replicatie asynchroon is, zijn recente wijzigingen mogelijk nog niet aanwezig in de secundaire regio.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer de primaire regio van een doelopslagaccount dat gebruikmaakt van een geografisch redundante opslagoptie niet beschikbaar is.

  • Detectie en reactie: Failover van opslagaccounts kan door de klant worden beheerd of Microsoft beheerd. Microsoft beheerde failover is gereserveerd voor uitzonderlijke omstandigheden en kan zich pas voordoen na een uitgebreide storing, dus vertrouw er niet op voor uw noodherstelplan. Volg de Blob Storage failoverrichtlijnen om te bepalen of en wanneer u door de klant beheerde failover moet initiëren.

    Azure Storage Actions vereist geen afzonderlijke failover-actie. Als u de toewijzing echter hebt gemaakt terwijl het doelaccount LRS gebruikte en u het account later hebt geconverteerd naar GRS of GZRS, werkt u de toewijzing bij voordat u failover van door de klant beheerde accounts start. Zie Ondersteuning voor meerdere regio's configureren voor meer informatie.

  • Notification: Microsoft geeft u niet automatisch een melding wanneer een regio uitvalt. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Tijdens een failover van het opslagaccount zijn de eindpunten van het primaire en secundaire opslagaccount tijdelijk niet beschikbaar. Uitvoeringen van opslagtaken die worden uitgevoerd, kunnen mislukken. Na een failover controleert u de status van de betrokken taakuitvoeringen en voert u de mislukte of onvolledige bewerkingen opnieuw uit, indien van toepassing.

    Als voor een terugkerende toewijzing de vorige iteratie nog bezig is wanneer de volgende iteratie is gepland, slaat Storage Actions de nieuwe iteratie over. De volgende iteratie wordt uitgevoerd op de aangewezen triggertijd nadat de vorige iteratie is voltooid.

  • Verwacht gegevensverlies: Azure Storage Actions onderhoudt geen afzonderlijke kopie van uw blobgegevens.

    Tijdens een niet-geplande failover kunnen recente wijzigingen verloren gaan als ze niet naar de secundaire regio zijn gerepliceerd. Een taak die mislukt terwijl deze wordt uitgevoerd, kan ook bewerkingen hebben voltooid op slechts enkele van de doelobjecten. Na een failover controleert u de status van de betrokken taakuitvoeringen en voert u de mislukte of onvolledige bewerkingen opnieuw uit, indien van toepassing. Zie Verwacht gegevensverlies tijdens een storing in een Blob Storage-regio voor meer informatie over herstelpunten en gegevensverlies van opslagaccounts.

  • Verwachte downtime: Voordat u een failover uitvoert, kunnen opslagtaken geen voortgang boeken terwijl het doelopslagaccount niet beschikbaar is.

    Tijdens een failover blijven de eindpunten van het opslagaccount niet beschikbaar, zodat taakuitvoeringen geen voortgang kunnen maken en kunnen mislukken.

    Nadat de failover is voltooid, verwerken de data-plane-onderdelen van Storage Actions in de nieuwe primaire regio van het opslagaccount toekomstige uitvoeringen van taaktoewijzingen. De opslagtaakresource blijft in de oorspronkelijke regio staan, dus rapportage voor de taakdefinitie mogelijk beïnvloed blijft terwijl die regio niet beschikbaar is. Rapportage voor andere secties van de resource blijft werken.

    De totale onderbreking omvat de tijd voor het detecteren van de storing, het bepalen of de failover van het opslagaccount moet worden gestart en het voltooien van de failover van het opslagaccount.

    Als er geen failover plaatsvindt, blijft taakuitvoering onbeschikbaar totdat de oorspronkelijke primaire regio wordt hersteld.

    Beheerbewerkingen blijven beschikbaar tijdens een uitval van een regio.

  • Herdistributie: Azure Storage werkt de eindpunten van het opslagaccount bij wanneer de failover is voltooid. Toekomstige uitvoeringen van taaktoewijzingen worden automatisch uitgevoerd op het account in de nieuwe primaire regio. U hoeft de opslagtaak of toewijzing niet opnieuw te configureren.

Herstel van de regio

Het failbackproces is afhankelijk van het failovertype van het opslagaccount. Volg de Blob Storage-richtlijnen voor regioherstel om een failback van het doelopslagaccount uit te voeren. Azure Storage Actions vereist geen extra configuratie na failback van het opslagaccount.

Test voor regiofouten

Als u uw herstelproces wilt testen zonder het gegevensverlies dat is gekoppeld aan een niet-geplande failover, maakt u representatieve toewijzingen van opslagtaken voor een niet-productieopslagaccount dat gebruikmaakt van een geografisch redundante opslagoptie en start u vervolgens een door de klant beheerde geplande failover. Controleer een lopende uitvoering en controleer of een toekomstige geplande uitvoering wordt uitgevoerd voor het account in de nieuwe primaire regio. Zie Testen op regiostoringen in Azure Blob Storage voor richtlijnen voor failovertests.

Aangepaste multiregionale oplossingen voor veerkracht

Ondersteuning voor ingebouwde regiofailover voor Azure Storage Acties is alleen beschikbaar wanneer het doelopslagaccount zich in een gekoppelde regio bevindt en een geografisch redundante opslagoptie gebruikt.

Als uw oplossing voor meerdere regio's gebruikmaakt van onafhankelijke opslagaccounts in elke regio in plaats van failover van het opslagaccount, kunt u een opslagtaak implementeren in dezelfde regio als elk doelaccount en een toewijzing voor elk account maken. U bent verantwoordelijk voor het repliceren van gegevens tussen de accounts, het gesynchroniseerd houden van taakdefinities en toewijzingen en het beheren van welke toewijzingen worden uitgevoerd tijdens de normale werking en failover. Zorg ervoor dat taken in verschillende regio's geen conflicterende bewerkingen uitvoeren op gerepliceerde gegevens.

Back-up maken en terugzetten

Als u de configuratie van uw Azure Storage Actions wilt herstellen na onbedoelde verwijdering, definieert u uw opslagtaken en toewijzingen als infrastructuur als code (IaC) en slaat u de definities op in broncodebeheer. Neem taakvoorwaarden en -bewerkingen, planningen, scopes van het doelopslagaccount, rapportcontainerinstellingen, beheerde identiteiten en vereiste roltoewijzingen op. U kunt een opslagtaak implementeren met behulp van Bicep en u kunt opslagtaaktoewijzingen definiëren in Bicep.

Opslagtaken en -toewijzingen bestaan uit configuratie en bevatten niet de klantgegevens die door taken worden verwerkt. Gebruik de IaC-benadering die eerder is beschreven om deze configuratie te herstellen. U bent verantwoordelijk voor het afzonderlijk beveiligen en herstellen van de gegevens in uw doelopslagaccounts. Zie Overzicht van gegevensbescherming voor meer informatie over opties voor gegevensbescherming van Azure Storage.

Test uw herstelprocedure in een niet-productieomgeving. Voordat u opnieuw aangemaakte toewijzingen inschakelt, gebruikt u previews van voorwaarden en mock-uitvoeringen om te controleren of de taak is gericht op de beoogde blobs. Zie Aanbevolen procedures voor het gebruik van opslagtaken voor meer informatie.

Tolerantie voor serviceonderhoud

Microsoft past regelmatig service-updates toe en voert ander onderhoud uit. Het Azure platform verwerkt deze activiteiten automatisch en zorgt ervoor dat onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsgebeurtenissen, tenzij u op de hoogte bent gesteld via Azure Service Health gepland onderhoud.

Diensteniveau-overeenkomst

Azure Storage Actions biedt geen SLA (Service Level Agreement) voor beschikbaarheid.

Verwante onderwerpen

  • Laatst bijgewerkt om