Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure Storage Mover är en fullständigt hanterad tjänst som migrerar filer och mappar till Azure Storage och håller filer synkroniserade mellan lagringskonton. Använd Storage Mover när du flyttar data till Azure eller när du behöver synkronisera data mellan olika platser inom Azure.
När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.
Den här artikeln beskriver hur Azure Storage Mover svarar på en mängd olika potentiella avbrott och problem, inklusive tillfälliga fel, fel i tillgänglighetszonen och regionomfattande fel. Den beskriver också hur du skyddar din Storage Mover-konfiguration.
Important
Den här artikeln beskriver tillförlitligheten för tjänsten Azure Storage Mover och dess resurser. Tillförlitligheten för en migrering från slutpunkt till slutpunkt beror på alla komponenter: Storage Mover-tjänsten, alla Storage Mover-agenter som du distribuerar, källmiljön och nätverksanslutningen och mållagringskontot. Du ansvarar för tillförlitligheten hos agenter, källsystem och mållagring. Mer information om Azure Storage tillförlitlighet finns i Tillförlitlighet i Azure Blob Storage och tillförlitlighet i Azure Files.
Översikt över tillförlitlighetsarkitektur
I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.
Logisk arkitektur
Azure Storage Mover är utformat för att migrera och synkronisera data mellan lagringsplatser, utan för att betjäna förfrågningar i körvägen för en produktionsarbetslast. Den har en resurshierarki som definierar de komponenter som du distribuerar och hanterar. Resursen på den översta nivån kallas för en lagringsflyttare. I en lagringsflyttare definierar du projekt som innehåller jobbdefinitioner som beskriver vad som ska migreras och var. Slutpunkter definierar käll- och målplatserna för ett migrerings- eller synkroniseringsjobb.
I vissa scenarier, till exempel migreringar från lokala miljöer, distribuerar du även en eller flera Storage Mover-agenter. En agent är programvara som du kör på en dator som du styr, till exempel en virtuell dator eller fysisk dator. Vissa scenarier kräver ingen agent.
Tjänsten lagrar konfigurationsmetadata, inklusive projekt, slutpunkter, agentregistreringar, jobbdefinitioner och jobbkörningshistorik. Dessa metadata innehåller inte de data som du migrerar.
Fysisk arkitektur
Tjänsten Azure Storage Mover körs på Microsoft hanterad infrastruktur. Agenter körs på maskinvara som du hanterar. Du ansvarar för agenternas tillförlitlighet, vilket ligger utanför omfånget för den här artikeln.
Motståndskraft mot tillfälliga fel
Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.
Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av övergående fel.
Om ett tillfälligt fel påverkar kommunikationen mellan en agent och Storage Mover-tjänsten, eller när du ansluter till en källa eller ett mål, försöker agenten automatiskt igen. För Azure-till-Azure-jobb är tjänsten också motståndskraftig mot många tillfälliga fel. När anslutningen återställs återupptas pågående migreringsjobb.
I vissa fall visas tillfälliga fel som fel i jobbkörningshistoriken. En beskrivning av felkoder, inklusive tillfälliga fel, finns i Azure Storage Mover-statuskoder och feltyper. Information om hur du löser problem med beständiga nätverksanslutningar finns i Felsöka Azure Storage Mover-nätverksanslutning.
Motståndskraft mot fel i tillgänglighetszonen
Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.
I regioner som stöder tillgänglighetszoner distribuerar plattformen en lagringsflyttares konfigurationsmetadata mellan zoner på bästa sätt, men det här beteendet är inte garanterat. Om dina lagringsmigreringar behöver klara förlusten av en zon utformar du migreringsprocessen så att den tolererar förlust av en lagringsflyttare och granskar Motståndskraft mot regionomfattande fel.
Tänk på effekten av ett zonfel i kontexten för hur du använder Storage Mover. Tjänsten samordnar datamigrering och synkronisering, och den finns vanligtvis inte i körningssökvägen för din produktionsarbetsbelastning. Om en lagringsflyttare inte är tillgänglig under ett zonfel fördröjs vanligtvis ett migrerings- eller synkroniseringsjobb i stället för att orsaka ett produktionsfel, och du kan återuppta eller försöka utföra jobbet igen när tjänsten har återställts. Storage Mover erbjuder inte heller något serviceavtal (SLA) för tillgänglighet, så din design bör inte förutsätta att tjänsten är kontinuerligt tillgänglig. Om din arbetsbelastning är beroende av pågående synkronisering utvärderar du om den här typen av fördröjning är acceptabel för ditt scenario.
Följande diagram visar en lagringsflyttare med infrastruktur- och konfigurationsmetadata fördelade på tre zoner:
Note
Tillförlitligheten för all datamigrering beror också på de lagringskonton och agenter som du använder. Om ditt mållagringskonto till exempel använder lokalt redundant lagring (LRS) är det inte motståndskraftigt mot ett zonfel. Om du vill göra en migrering motståndskraftig mot fel i en zon använder du ett zonredundant mållagringskonto.
Requirements
Regionstöd: Bästa möjliga distribution av konfigurationsmetadata mellan zoner kan endast ske i en region som stöder både Storage Mover och tillgänglighetszoner. Kontrollera tillgängligheten för Storage Mover-regionen och jämför den med listan över regioner som stöder tillgänglighetszoner. Inte ens i dessa regioner garanteras zonresiliens.
Cost
Storage Mover erbjuder inte konfigurerbar stöd för tillgänglighetszoner, så du får inga extra kostnader relaterade till tillgänglighetszoner. Mer information om hur Storage Mover faktureras finns i Förstå Azure Storage Mover-fakturering.
Konfigurera stöd för tillgänglighetszoner
Storage Mover erbjuder inte konfigurerbar stöd för tillgänglighetszoner, så det finns inget som du kan aktivera eller välja. Mer information om hur du skapar en Storage Mover-resurs finns i Distributionsplanering för Azure Storage Mover.
Beteende när alla zoner är felfria
I det här avsnittet beskrivs vad du kan förvänta dig när en lagringsflyttare finns i en region som stöder tillgänglighetszoner och alla zoner är i drift.
Åtgärd mellan zoner: Infrastruktur i någon av tillgänglighetszonerna i regionen kan hantera hanteringsåtgärder och metadataåtkomst. Agentanslutningar kan nå tjänsten via valfri zon.
Datadistribution mellan zoner: Tjänsten syftar till att synkront replikera konfigurationsmetadata mellan tillgänglighetszoner i regionen.
Beteende vid ett zonfel
Det här avsnittet beskriver vad du kan förvänta dig när en lagringsflyttare finns i en region som stöder tillgänglighetszoner och det uppstår ett avbrott i någon av zonerna.
- Detektering och respons: Plattformen är utformad för att upptäcka bortfall av en tillgänglighetszon och dirigera om trafik till fungerande zoner, men denna respons sker efter bästa förmåga och kan inte garanteras.
- Notification: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health-aviseringar för att meddela dig om problem. Du kan också använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.
Aktiva begäranden: Hanteringsåtgärder som pågår som är beroende av infrastruktur i den berörda zonen kan misslyckas och du måste försöka igen. Aktiva datamigreringsjobb som körs på agenter kan fortsätta att köras, men hanteringsåtgärder som är beroende av metadatatjänsten kanske inte är tillgängliga.
Förväntad dataförlust: Data som en lagringsflyttare migrerar går inte förlorade vid ett zonfel.
Eftersom Storage Mover inte garanterar att konfigurationsmetadata distribueras mellan zoner kan ett zonfel göra vissa av lagringsflyttarens konfigurationsmetadata tillfälligt otillgängliga tills zonen återställs.
Förväntad stilleståndstid: Plattformen försöker återställa åtgärder med hjälp av en annan zon, men i vissa situationer kan åtgärder vara otillgängliga tills den berörda zonen återställs. Förbered arbetsbelastningen genom att följa vägledningen för tillfällig felhantering.
Omfördelning: Om plattformen omdirigerar trafik till felfria tillgänglighetszoner gör den det på bästa sätt.
Zonåterställning
När en tillgänglighetszon återställs syftar plattformen till att återställa kapaciteten i den återställda zonen och balansera om trafiken mellan zoner. Det här beteendet sker i mån av möjlighet och garanteras inte. Du behöver inte vidta några åtgärder för att initiera zonåterställningen.
Test för zonfel
Du kan inte initiera eller testa ett fel i tillgänglighetszonen för en lagringsflyttare. Eftersom Storage Mover inte garanterar zonresiliens förutsätter du inte att en lagringsflyttare överlever ett zonfel. Om din migreringsprocess behöver kunna hantera bortfall av en zon bör du själv validera processens heltäckande motståndskraft och läsa Motståndskraft mot regionomfattande fel om metoder som låter dig styra redundansväxling.
Motståndskraft mot regionomfattande fel
Azure Storage Mover är en tjänst för en region. När du distribuerar en Azure Storage Mover-resurs väljer du en region för att lagra resursens konfigurationsmetadata. Om lagringsflyttarens region upplever ett avbrott kan det hända att hanteringsåtgärder som agenten utför och som förlitar sig på Azure inte slutförs. Dessutom kan alla aktiva datamigreringar till lagringskonton som finns i den berörda regionen misslyckas.
Om din lagringsflyttare finns i en Azure-region som ingår i ett regionalt par replikeras dess konfigurationsmetadata till den parkopplade Azure-regionen för haveriberedskap, och Microsoft kan växla över till den parkopplade regionen vid en katastrof som påverkar din primära region.
Om lagringsflyttaren finns i en icke-trappad region replikerar Microsoft inte konfigurationsmetadata och det finns ingen inbyggd redundansväxling till en annan region. Du kan dock distribuera separata resurser till flera regioner. I det här scenariot är det ditt ansvar att hantera replikering, trafikdistribution och redundans. Om du använder en icke-trappad region, eller om den inbyggda metadatareplikeringen inte uppfyller dina behov, kan du skapa en anpassad redundansstrategi för flera regioner.
Note
Du ansvarar för haveriberedskap för dina datakällor (inklusive Azure och lokala datakällor), mål och agenter.
Microsoft-hanterad redundansväxling till en länkad region
Om din Storage Mover-resurs finns i en region som parkopplas med en annan region replikerar Microsoft lagringsflyttarens konfigurationsmetadata till den kopplade regionen.
I händelse av ett regionfel kan Microsoft utföra en redundansväxling till den kopplade regionen med hjälp av replikerade konfigurationsmetadata. Den här processen är ett standardalternativ och kräver inget ingripande från dig.
Redundansväxling av Storage Mover-resurser kan ske vid en annan tidpunkt än någon redundansväxling av andra Azure tjänster.
Important
Microsoft kommer sannolikt inte att initiera redundansväxling annat än efter en betydande fördröjning, och då endast i mån av möjlighet. Om du behöver uppfylla specifika tidsramar för Storage Movers återställning, eller om standardbeteendet för replikering och redundans inte uppfyller dina behov, använder du anpassade lösningar för flera regioner för återhämtning för att planera för och initiera din egen redundansväxling.
Replikering mellan regioner gäller endast för konfigurationsmetadata. Den gäller inte för källdata eller för mållagringskontot, som har sina egna tillförlitlighets- och replikeringsalternativ. Mer information finns i Tillförlitlighet i Azure Blob Storage och tillförlitlighet i Azure Files.
Requirements
Regionstöd: Microsoft-hanterad replikering mellan regioner är endast tillgänglig för Storage Mover-resurser som du distribuerar till en region som har en länkad region. För resurser i regioner som inte ingår i ett regionpar tillhandahålls varken replikering mellan regioner eller redundansväxling. För att uppnå resiliens över regioner i oparade regioner använder du en anpassad lösning för flera regioner.
Cost
Storage Mover tar inte betalt för Microsoft-hanterad replikering över regioner av Storage Movers konfiguration. Det kan dock finnas en liten avgift för replikering mellan regioner. Mer information finns i Bandbreddspriser.
Konfigurera stöd för flera regioner
Microsoft-hanterad replikering mellan regioner aktiveras automatiskt för Storage Mover-resurser i parkopplade regioner. Du konfigurerar eller väljer inte det här beteendet.
Beteende när alla regioner är felfria
Det här avsnittet beskriver vad du kan förvänta dig när en lagringsflyttare har konfigurerats för replikering och redundans mellan regioner, och den primära regionen är i drift.
Åtgärd mellan regioner: Din Storage Mover-resurs i den primära regionen hanterar alla begäranden. Den kopplade regionen används endast i händelse av en Microsoft initierad redundansväxling.
Datareplikering mellan regioner: Den primära regionen replikerar konfigurationen asynkront till den kopplade regionen. Eftersom replikeringen är asynkron kanske de senaste konfigurationsändringarna inte återspeglas i den kopplade regionen vid tidpunkten för ett fel.
Beteende under ett regionfel
Det här avsnittet beskriver vad du kan förvänta dig när en lagringsflyttare har konfigurerats för replikering och redundans mellan regioner, och det finns ett avbrott i den primära regionen.
- Identifiering och svar: Microsoft identifierar regionfel och avgör om en redundansväxling ska initieras. Microsoft kommer sannolikt inte att initiera redundans, förutom efter en betydande fördröjning, och redundans utförs på bästa sätt.
Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Observera följande:
Du kan använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs och du kan konfigurera Resource Health-aviseringar för att meddela dig om problem.
Du kan använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.
Aktiva förfrågningar: Aktiva hanteringsförfrågningar avbryts och måste skickas igen när redundansväxlingen har slutförts. Pågående datamigreringsjobb som körs på agenter kan misslyckas om de är beroende av den region som påverkas av avbrottet.
Förväntad dataförlust: Eftersom replikering mellan regioner är asynkron kan eventuella ändringar av konfigurationsmetadata som inte replikeras till den kopplade regionen vid tidpunkten för avbrottet gå förlorade.
Förväntad stilleståndstid: Växling till reservregion kan ta upp till 24 timmar att slutföras. Under den här tiden är lagringsflyttaren inte tillgänglig.
Omfördelning: När redundansväxlingen är klar börjar Storage Mover köra jobb från den kopplade regionen.
Du måste dock registrera om agenter mot lagringsflyttaren i den parkopplade regionen.
Regionåterställning
När den ursprungliga primära regionen återställs samordnar Microsoft återställning efter fel. Du måste registrera om agenter mot lagringsflyttaren i den primära regionen.
Test för regionfel
Azure Storage Mover-plattformen hanterar replikering, redundans och regionåterställning mellan regioner. Eftersom Microsoft fullständigt hanterar den här funktionen kan du inte initiera eller testa en regionredundans.
Anpassade lösningar för flera regioner för återhämtning
Om du behöver styra när redundansväxling inträffar, eller om du befinner dig i en icke-parad region men ändå behöver att din Storage Mover ska vara motståndskraftig mot regionala avbrott, distribuerar du oberoende Storage Mover-resurser i flera Azure-regioner. Du ansvarar för alla aspekter av den här metoden, inklusive:
- Skapa och underhålla motsvarande projekt, slutpunkter, agenter och jobbdefinitioner i varje region.
- Identifiering av regionfel och beslut om när växling till redundantsystem ska ske.
- Omdirigera agenter och migreringsjobb till den sekundära regionen.
- Synkronisering av jobbstatus och körhistorik mellan regioner.
En anpassad lösning för flera regioner fungerar för både kopplade och icke-kopplade regioner och ger dig fullständig kontroll över redundansväxlingsprocessen.
Mer information finns i kundinitierad haveriåterställning för Azure Storage Mover.
Säkerhetskopiering och återställning
Azure Storage Mover är en migrerings- och dataförflyttningsorkestreringstjänst. Den lagrar inte de data som du migrerar. Tjänsten lagrar endast konfigurationsmetadata, till exempel projekt, slutpunkter, jobbdefinitioner och jobbkörningshistorik. Det finns inga migreringsdata att säkerhetskopiera.
För att skydda din Storage Mover-konfiguration definierar du dina resurser med hjälp av infrastruktur som kod, till exempel Bicep filer, och lagrar dessa definitioner i källkontrollen. Om du behöver återskapa en resurs kan du distribuera om den från den lagrade konfigurationen.
För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.
Motståndskraft mot serviceunderhåll
Microsoft tillämpar regelbundet tjänstuppdateringar och utför annat underhåll. Den Azure plattformen hanterar dessa aktiviteter automatiskt, vilket säkerställer att underhållet är sömlöst och transparent för dig. Ingen driftstopp förväntas under underhållshändelser om du inte har blivit informerad via Azure Service Health planerat underhåll.
Storage Mover-agenter uppgraderas automatiskt.
Serviceavtal
Storage Mover är en migreringstjänst och erbjuder inget serviceavtal (SLA) för tillgänglighet. Dokumentationen för Storage Mover beskriver dock förväntade skalnings- och prestandamål. Dessa mål baseras på simulerade migreringar och är inte en garanti eller ett åtagande.