Betrouwbaarheid in Azure Storage Mover

Azure Storage Mover is een volledig beheerde service waarmee bestanden en mappen worden gemigreerd naar Azure Storage en bestanden worden gesynchroniseerd tussen opslagaccounts. Gebruik Storage Mover wanneer u gegevens verplaatst naar Azure of wanneer u gegevens synchroon wilt houden tussen verschillende locaties binnen Azure.

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 Azure Storage Mover reageert op verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiobrede fouten. Ook wordt beschreven hoe u uw Opslag Mover-configuratie beveiligt.

Important

In dit artikel worden alleen de betrouwbaarheid van de Azure Storage Mover-service en de bijbehorende resources beschreven. De betrouwbaarheid van een end-to-end migratie is afhankelijk van alle onderdelen: de Storage Mover-service, alle Storage Mover-agents die u implementeert, de bronomgeving en de netwerkverbinding en het doelopslagaccount. U bent verantwoordelijk voor de betrouwbaarheid van agents, bronsystemen en doelopslag. Zie Betrouwbaarheid in Azure Blob Storage en betrouwbaarheid in Azure Files voor meer informatie over Azure Storage betrouwbaarheid.

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

Azure Storage Mover is ontworpen voor het migreren en synchroniseren van gegevens tussen opslaglocaties, niet voor het verwerken van aanvragen in het runtimepad van een productieworkload. Het heeft een resourcehiërarchie die de onderdelen definieert die u implementeert en beheert. De resource op het hoogste niveau wordt een opslagmover genoemd. Binnen een opslagmover definieert u projecten die taakdefinities bevatten die beschrijven wat u wilt migreren en waar. Eindpunten definiëren de bron- en doellocaties voor een migratie- of synchronisatietaak.

Voor sommige scenario's, zoals migraties vanuit on-premises omgevingen, implementeert u ook een of meer Storage Mover-agents. Een agent is software die u uitvoert op een machine die u bepaalt, zoals een virtuele machine of fysieke machine. Voor sommige scenario's is geen agent vereist.

De service slaat configuratiemetagegevens op, waaronder projecten, eindpunten, agentregistraties, taakdefinities en taakuitvoeringsgeschiedenis. Deze metagegevens bevatten niet de gegevens die u migreert.

Fysieke architectuur

De Azure Storage Mover-service wordt uitgevoerd op Microsoft beheerde infrastructuur. Agents worden uitgevoerd op hardware die u beheert. U bent verantwoordelijk voor de betrouwbaarheid van agents, die buiten het bereik van dit artikel vallen.

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.

Als een tijdelijke fout invloed heeft op de communicatie tussen een agent en de Storage Mover-service, of wanneer verbinding wordt gemaakt met een bron of doel, probeert de agent het automatisch opnieuw. Voor Azure-naar-Azure-taken is de service ook bestand tegen veel tijdelijke fouten. Wanneer de verbinding is hersteld, worden lopende migratietaken hervat.

In sommige gevallen worden tijdelijke fouten weergegeven als fouten in de uitvoeringsgeschiedenis van de taak. Zie Azure Storage Mover-statuscodes en fouttypen voor een beschrijving van foutcodes, inclusief tijdelijke fouten. Zie Problemen met Azure Storage Mover-netwerkverbinding oplossen voor hulp bij het oplossen van permanente netwerkverbindingsproblemen.

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.

In regio's die beschikbaarheidszones ondersteunen, distribueert het platform de configuratiemetagegevens van een opslagmover over zones op basis van best effort, maar dit gedrag wordt niet gegarandeerd. Als uw opslagmigraties bestand moeten zijn tegen het verlies van een zone, ontwerpt u uw migratieproces om het verlies van een opslagmover te tolereren en bekijkt u Tolerantie voor storingen in de hele regio.

Houd rekening met het effect van een zonefout in de context van hoe u Storage Mover gebruikt. De service organiseert gegevensmigratie en -synchronisatie en bevindt zich doorgaans niet in het runtimepad van uw productieworkload. Als een opslagmover niet beschikbaar is tijdens een zonefout, wordt een migratie- of synchronisatietaak meestal vertraagd in plaats van een productiestoring te veroorzaken en kunt u de taak hervatten of opnieuw uitvoeren nadat de service is hersteld. Storage Mover biedt ook geen SLA (Availability Service Level Agreement), dus uw ontwerp mag er niet van uitgaan dat de service continu beschikbaar is. Als uw workload afhankelijk is van doorlopende synchronisatie, evalueert u of dit soort vertraging acceptabel is voor uw scenario.

In het volgende diagram ziet u een opslagmover met infrastructuur- en configuratiemetagegevens verspreid over drie zones:

Schema van een zone-redundante opslagmigrator die is verspreid over drie beschikbaarheidszones.

Note

De betrouwbaarheid van elke gegevensmigratie is ook afhankelijk van de opslagaccounts en agents die u gebruikt. Als uw doelopslagaccount bijvoorbeeld lokaal redundante opslag (LRS) gebruikt, is het niet bestand tegen een zonefout. Gebruik een zone-redundant doelopslagaccount om een migratie tolerant te maken voor een zonefout.

Requirements

Regioondersteuning: De best effort-distributie van configuratiemetagegevens tussen zones kan alleen plaatsvinden in een regio die ondersteuning biedt voor opslag-Mover en beschikbaarheidszones. Controleer de beschikbaarheid van storage Mover-regio's en vergelijk deze met de lijst met regio's die beschikbaarheidszones ondersteunen. Zelfs in deze regio's is veerkracht op zoneniveau niet gegarandeerd.

Cost

Storage Mover biedt geen configureerbare ondersteuning voor beschikbaarheidszones, dus er worden geen extra kosten in rekening gebracht met betrekking tot beschikbaarheidszones. Zie Inzicht in Azure Storage Mover-facturering voor meer informatie over hoe Opslag Mover wordt gefactureerd.

Ondersteuning voor beschikbaarheidszones configureren

Storage Mover biedt geen configureerbare ondersteuning voor beschikbaarheidszones, dus u hoeft niets in te schakelen of aan te kiezen. Zie Implementatieplanning voor Azure Storage Mover voor meer informatie over het maken van een Storage Mover-resource.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een opslagmover zich in een regio bevindt die beschikbaarheidszones ondersteunt en alle zones operationeel zijn.

  • Bewerking tussen zones: Infrastructuur in een van de beschikbaarheidszones in de regio kan beheerbewerkingen en toegang tot metagegevens leveren. Agentverbindingen kunnen de service bereiken via elke zone.

  • Distributie van gegevens in meerdere zones: De service is erop gericht om configuratiemetagegevens synchroon te repliceren in beschikbaarheidszones in de regio.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een opslagmover zich in een regio bevindt die beschikbaarheidszones ondersteunt en er een storing is in een van de zones.

  • Detectie en reactie: Het platform is ontworpen om het verlies van een beschikbaarheidszone te detecteren en verkeer om te leiden naar gezonde zones, maar dit antwoord is het beste en wordt niet gegarandeerd.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook 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: Beheerbewerkingen die worden uitgevoerd die afhankelijk zijn van de infrastructuur in de betrokken zone, kunnen mislukken en u moet ze opnieuw proberen. Actieve gegevensmigratietaken die worden uitgevoerd op agents, kunnen blijven worden uitgevoerd, maar beheerbewerkingen die afhankelijk zijn van de metagegevensservice zijn mogelijk niet beschikbaar.

  • Verwachte gegevensverlies: De gegevens die door een opslagmover worden gemigreerd, gaan niet verloren tijdens een zonefout.

    Omdat Storage Mover niet garandeert dat configuratiemetagegevens over zones worden gedistribueerd, kan een zonefout ervoor zorgen dat sommige configuratiemetagegevens van de opslagmover tijdelijk niet beschikbaar zijn totdat de zone wordt hersteld.

  • Verwachte downtime: Het platform probeert bewerkingen te herstellen met behulp van een andere zone, maar in sommige gevallen zijn bewerkingen mogelijk niet beschikbaar totdat de getroffen zone wordt hersteld. Bereid uw workload voor door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

  • Herverdeling: Als het platform verkeer omleidt naar gezonde beschikbaarheidszones, doet het dit op basis van best effort.

Zoneherstel

Wanneer een beschikbaarheidszone wordt hersteld, is het platform erop gericht om de capaciteit in de herstelde zone te herstellen en verkeer tussen zones opnieuw te verdelen. Dit gedrag is best-effort en is niet gegarandeerd. U hoeft geen actie te ondernemen om het zoneherstel te starten.

Testen op zonefouten

U kunt voor een opslagmover geen uitval van een beschikbaarheidszone initiëren of testen. Omdat Storage Mover geen zonetolerantie garandeert, moet u er niet van uitgaan dat een opslagmover een zonefout overleeft. Als uw migratieproces bestand moet zijn tegen het verlies van een zone, valideert u de end-to-end-tolerantie van dat proces zelf en controleert u Tolerantie op regiobrede fouten voor benaderingen waarmee u failover kunt beheren.

Tolerantie voor storingen in de hele regio

Azure Storage Mover is een service met één regio. Wanneer u een Azure Storage Mover-resource implementeert, selecteert u een regio om de configuratiemetagegevens van de resource op te slaan. Als de regio van de opslagmover een storing ondervindt, worden beheerbewerkingen die de agent uitvoert en die afhankelijk zijn van Azure mogelijk niet voltooid. Bovendien kunnen actieve gegevensmigraties naar opslagaccounts in de betrokken regio mislukken.

Als uw opslagmover zich in een Azure regio met een paar bevindt, worden de configuratiemetagegevens gerepliceerd naar de gekoppelde Azure regio voor herstel na noodgevallen en kan Microsoft failover naar de gekoppelde regio activeren tijdens een noodgeval dat van invloed is op uw primaire regio.

Als uw opslagmover zich in een niet-gepairede regio bevindt, repliceert Microsoft geen configuratiemetagegevens en is er geen ingebouwde failover naar een andere regio. U kunt echter afzonderlijke resources implementeren in meerdere regio's. In dit scenario is het uw verantwoordelijkheid om replicatie, verkeersdistributie en failover te beheren. Als u een niet-geairede regio gebruikt of als de ingebouwde metagegevensreplicatie niet aan uw behoeften voldoet, kunt u een aangepaste failoverstrategie voor meerdere regio's maken.

Note

U bent verantwoordelijk voor herstel na noodgevallen voor uw gegevensbronnen (inclusief Azure en on-premises gegevensbronnen), doelen en agents.

Microsoft-beheerd failover naar een gekoppelde regio

Als uw Storage Mover-resource zich in een regio bevindt die is gekoppeld aan een andere regio, repliceert Microsoft de configuratiemetagegevens van uw opslagmover naar de gekoppelde regio.

Diagram van een opslagmover die de metagegevens repliceert naar een gekoppelde regio.

In het geval van een storing in een regio kan Microsoft een failover uitvoeren naar de gekoppelde regio met behulp van de gerepliceerde configuratiemetagegevens. Dit proces is een standaardoptie en vereist geen tussenkomst van u.

Diagram waarop een storage mover te zien is die failovert naar een gepaarde regio.

Failover van Storage Mover-resources kan op een ander moment plaatsvinden dan een failover van andere Azure-services.

Important

Het is onwaarschijnlijk dat Microsoft een failover initieert, behalve na een aanzienlijke vertraging, en dit gebeurt naar beste vermogen. Als u moet voldoen aan specifieke tijdsbestekken voor het herstel van Storage Mover, of als het standaardreplicatie- en failovergedrag niet aan uw behoeften voldoet, gebruikt u aangepaste oplossingen voor meerdere regio's voor tolerantie om uw eigen failover te plannen en te initiëren.

Replicatie tussen regio's is alleen van toepassing op configuratiemetagegevens. Deze is niet van toepassing op de brongegevens of op het doelopslagaccount, dat eigen betrouwbaarheids- en replicatieopties heeft. Zie betrouwbaarheid in Azure Blob Storage en betrouwbaarheid in Azure Files voor meer informatie.

Requirements

Regioondersteuning: Microsoft beheerde replicatie tussen regio's is alleen beschikbaar voor Storage Mover-resources die u implementeert in een regio met een gekoppelde regio. Voor resources in niet-gekoppelde regio's is geen replicatie tussen regio's of failover beschikbaar. Gebruik een aangepaste oplossing voor meerdere regio's om tolerantie tussen regio's te bereiken in niet-geairede regio's.

Cost

Storage Mover brengt geen kosten in rekening voor door Microsoft beheerde replicatie tussen regio's van de configuratie van uw Storage Mover. Er kunnen echter kleine kosten in rekening worden gebracht voor replicatie tussen regio's. Zie bandbreedteprijzen voor meer informatie.

Ondersteuning voor meerdere regio's configureren

Door Microsoft beheerde replicatie tussen regio's wordt automatisch ingeschakeld voor Storage Mover-resources in gekoppelde regio's. U configureert of meldt zich niet aan voor dit gedrag.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een opslagmover is geconfigureerd voor replicatie en failover tussen regio's en de primaire regio operationeel is.

  • Bewerking tussen regio's: Uw Storage Mover-resource in de primaire regio dient alle aanvragen. De gekoppelde regio wordt alleen gebruikt in het geval van een door Microsoft geïnitieerde failover.

  • Replicatie van gegevens in meerdere regio's: De primaire regio repliceert configuratie asynchroon naar de gekoppelde regio. Omdat replicatie asynchroon is, worden recente wijzigingen in de configuratie mogelijk niet doorgevoerd in de gekoppelde regio op het moment van een fout.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een opslagmover is geconfigureerd voor replicatie en failover tussen regio's en er een storing is in de primaire regio.

  • Detectie en reactie: Microsoft detecteert regiofouten en bepaalt of er een failover moet worden gestart. Microsoft zal waarschijnlijk pas na een aanzienlijke vertraging een failover initiëren, en failover wordt naar beste vermogen uitgevoerd.

  • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Aan de andere kant:

  • Actieve aanvragen: Actieve beheeraanvragen worden verwijderd en moeten opnieuw worden geprobeerd nadat de failover is voltooid. Actieve gegevensmigratietaken die op agents worden uitgevoerd, kunnen mislukken als ze afhankelijk zijn van de regio waarin de storing zich voordoet.

  • Verwachte gegevensverlies: Omdat replicatie tussen regio's asynchroon is, kunnen wijzigingen in de metagegevens van de configuratie die niet worden gerepliceerd naar de gekoppelde regio op het moment van de storing verloren gaan.

  • Verwachte downtime: Het kan tot 24 uur duren voordat een regiofailover is voltooid. Gedurende deze tijd is uw opslagmover niet beschikbaar.

  • Herverdeling: Nadat de failover is voltooid, begint Storage Mover taken uit te voeren vanuit de gekoppelde regio.

    U moet echter agents opnieuw registreren bij de opslagmover in de gekoppelde regio.

Herstel van de regio

Wanneer de oorspronkelijke primaire regio weer beschikbaar is, coördineert Microsoft de failback. U moet agents opnieuw registreren bij de opslagmover in de primaire regio.

Test voor regiofouten

Het Azure Storage Mover-platform beheert replicatie tussen regio's, failover en regioherstel. Omdat Microsoft deze functie volledig beheert, kunt u een regiofailover niet initiëren of testen.

Aangepaste multiregionale oplossingen voor veerkracht

Als u wilt bepalen wanneer een failover optreedt of als u zich in een niet-gepairede regio bevindt, maar uw opslagmover nog steeds nodig hebt om bestand te zijn tegen storingen in regio's, implementeert u onafhankelijke Storage Mover-resources in meerdere Azure regio's. U bent verantwoordelijk voor alle aspecten van deze aanpak, waaronder:

  • Gelijkwaardige projecten, eindpunten, agents en taakdefinities in elke regio maken en onderhouden.
  • Regiofouten detecteren en bepalen wanneer een failover moet worden uitgevoerd.
  • Agents en migratietaken worden omgeleid naar de secundaire regio.
  • Taakstatus en uitvoeringsgeschiedenis tussen regio's afstemmen.

Een aangepaste oplossing voor meerdere regio's werkt voor zowel gekoppelde als niet-gekoppelde regio's en biedt u volledige controle over uw failoverproces.

Zie Door de klant geïnitieerde herstel na noodgevallen voor Azure Storage Mover voor meer informatie.

Back-up maken en terugzetten

Azure Storage Mover is een indelingsservice voor migratie en gegevensverplaatsing. De gegevens die u migreert, worden niet opgeslagen. De service slaat alleen configuratiemetagegevens op, zoals projecten, eindpunten, taakdefinities en taakuitvoeringsgeschiedenis. Er zijn geen migratiegegevens om een back-up van te maken.

Voor het beveiligen van uw Opslag Mover-configuratie definieert u uw resources met infrastructuur als code, zoals Bicep bestanden, en slaat u deze definities op in broncodebeheer. Als u een resource opnieuw moet maken, kunt u deze opnieuw implementeren vanuit uw opgeslagen configuratie.

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? 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.

Storage Mover-agents worden automatisch bijgewerkt.

Diensteniveau-overeenkomst

Storage Mover is een migratieservice en biedt geen SLA (Availability Service Level Agreement). In de documentatie van Storage Mover worden echter de verwachte schaal- en prestatiedoelen beschreven. Deze doelen zijn gebaseerd op gesimuleerde migraties en zijn geen garantie of toezegging.

Verwante onderwerpen

  • Last updated on