Metodtips för haveriberedskap med Azure File Sync
För Azure File Sync finns det tre huvudsakliga områden att tänka på för haveriberedskap: hög tillgänglighet, dataskydd/säkerhetskopiering och dataredundans. Den här artikeln beskriver varje område och hjälper dig att bestämma vilken konfiguration som ska användas för din egen haveriberedskapslösning.
I en Azure File Sync-distribution innehåller molnslutpunkten alltid en fullständig kopia av dina data, medan den lokala servern kan ses som en engångscache för dina data. I händelse av en katastrof på serversidan kan du återställa genom att etablera en ny server, installera Azure File Sync-agenten på den och konfigurera den som en ny serverslutpunkt.
På grund av dess hybridkaraktär fungerar vissa traditionella strategier för säkerhetskopiering och haveriberedskap inte med Azure File Sync. Azure File Sync stöder inte för någon registrerad server:
Varning
Om du vidtar någon av dessa åtgärder kan det leda till problem med synkronisering eller brutna nivåindelade filer som resulterar i eventuell dataförlust. Om du har vidtagit någon av dessa åtgärder kontaktar du Azure-supporten för att säkerställa att distributionen är felfri.
- Överföra/klona diskenheter (volym) från en server till en annan medan serverslutpunkten fortfarande är aktiv
- Återställa från en säkerhetskopiering av operativsystemet
- Klona en servers operativsystem till en annan server
- Återgå till en tidigare kontrollpunkt för virtuell dator
- Återställa nivåindelade filer från lokal säkerhetskopiering (tredje part) till serverslutpunkten
Hög tillgänglighet
Det finns två olika strategier som du kan använda för att uppnå hög tillgänglighet för din lokala server. Du kan antingen konfigurera ett redundanskluster eller konfigurera en väntelägesserver. Den avgörande faktorn mellan någon av konfigurationerna är hur mycket du är villig att investera i systemet, och om du minimerar hur lång tid systemet är nere vid en katastrof är det värt den extra kostnaden.
För ett redundanskluster behöver du inte vidta några särskilda åtgärder för att använda Azure File Sync. För en väntelägesserver bör du göra följande konfigurationer:
Ha en sekundär server med olika serverslutpunkter som synkroniseras med samma synkroniseringsgrupp som din primära server, men som inte aktiverar slutanvändarens åtkomst till servern. På så sätt kan alla filer synkroniseras från den primära servern till väntelägesservern. Du kan överväga att aktivera nivåindelning endast för namnområden så att endast namnområdet laddas ned från början. Om din primära server misslyckas kan du använda DFS-N för att snabbt konfigurera om slutanvändares åtkomst till väntelägesservern.
Dataskydd/säkerhetskopiering
Att skydda dina data är en viktig komponent i en haveriberedskapslösning. Det finns två huvudsakliga sätt att göra detta med dina Azure-filresurser: du kan antingen säkerhetskopiera dina data i molnet eller lokalt. Vi rekommenderar starkt att du säkerhetskopierar dina data i molnet eftersom molnslutpunkten innehåller en fullständig kopia av dina data, medan serverslutpunkter kanske bara innehåller en delmängd av dina data.
Säkerhetskopiera dina data i molnet
Du bör använda Azure Backup som molnlösning för säkerhetskopiering. Azure Backup hanterar bland annat schemaläggning, kvarhållning och återställning av säkerhetskopior. Om du vill kan du manuellt ta resursögonblicksbilder och konfigurera din egen schemaläggnings- och kvarhållningslösning, men det här är inte idealiskt. Du kan också använda lösningar från tredje part för att säkerhetskopiera dina Azure-filresurser direkt.
Om en katastrof inträffar kan du återställa från en resursögonblicksbild, vilket är en skrivskyddad kopia av filresursen. Eftersom dessa ögonblicksbilder är skrivskyddade påverkas de inte av utpressningstrojaner. För stora datauppsättningar där återställningsåtgärder för fullständiga resurser tar lång tid kan du aktivera direkt användaråtkomst till ögonblicksbilden så att användarna kan kopiera de data de behöver till sin lokala enhet medan återställningen slutförs.
Ögonblicksbilder lagras direkt i din Azure-filresurs, oavsett om du tar dem manuellt eller om Azure Backup tar dem åt dig. Därför bör du aktivera mjuk borttagning för att skydda dina ögonblicksbilder mot oavsiktlig borttagning av filresursen.
Mer information finns i Om säkerhetskopiering av Azure-filresurser eller kontakta din säkerhetskopieringsleverantör för att se om de stöder säkerhetskopiering av Azure-filresurser.
Säkerhetskopiera dina data lokalt
Om du aktiverar molnnivåindelning ska du inte implementera en lokal säkerhetskopieringslösning. När molnnivåindelningen är aktiverad lagras endast en delmängd av dina data lokalt på servern och resten av dina data lagras i molnslutpunkten. Beroende på vilken säkerhetskopieringslösning du använder för en lokal säkerhetskopia blir nivåindelade filer antingen:
- hoppat över och inte säkerhetskopierats (på grund av deras
FILE_ATTRIBUTE_RECALL_ONDATA_ACCESSattribut) eller - säkerhetskopieras endast som en nivåindelad fil och kanske inte är tillgänglig vid återställning på grund av ändringar i den aktiva resursen, eller
- återkallas till disken, vilket resulterar i höga utgående avgifter.
Om du väljer att använda en lokal säkerhetskopieringslösning bör du utföra säkerhetskopior på en server i synkroniseringsgruppen med molnnivåinaktivering inaktiverad. När du utför en återställning använder du återställningsalternativen på volymnivå eller filnivå. Filer som återställs med återställningsalternativet på filnivå synkroniseras till alla slutpunkter i synkroniseringsgruppen och befintliga filer ersätts med den version som återställs från säkerhetskopian. Återställningar på volymnivå ersätter inte nyare filversioner i molnslutpunkten eller andra serverslutpunkter.
Ögonblicksbilder av Volume Shadow Copy Service (VSS) (inklusive fliken Tidigare versioner ) stöds på volymer med molnnivåindelning aktiverat. På så sätt kan du utföra självbetjäningsåterställningar i stället för att förlita dig på att en administratör utför återställningar åt dig. Du måste dock aktivera tidigare versionskompatibilitet via PowerShell, vilket ökar dina lagringskostnader för ögonblicksbilder. VSS-ögonblicksbilder skyddar inte mot katastrofer på själva serverslutpunkten, så de bör endast användas tillsammans med säkerhetskopieringar på molnsidan. Mer information finns i Självbetjäningsåterställning via tidigare versioner och VSS.
Dataredundans
För att säkerställa en robust haveriberedskapslösning lägger du till någon form av dataredundans i infrastrukturen. Det finns fyra redundanserbjudanden för Azure Files: Lokalt redundant lagring (LRS), zonredundant lagring (ZRS), geo-redundant lagring (GRS) och geo-zonredundant lagring (GZRS).
- Lokalt redundant lagring (LRS): Med LRS lagras varje fil tre gånger i ett Azure Storage-kluster. Detta skyddar mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof, till exempel brand eller översvämning inträffar i datacentret, kan alla repliker av ett lagringskonto som använder LRS gå förlorade eller oåterkalleliga.
- Zonredundant lagring (ZRS): Med ZRS lagras tre kopior av varje fil, men dessa kopior är fysiskt isolerade i tre distinkta lagringskluster i olika Azure-tillgänglighetszoner. Tillgänglighetszoner är unika fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. En skrivning till lagring accepteras inte förrän den har skrivits till lagringskluster i alla tre tillgänglighetszonerna.
- Geo-redundant lagring (GRS): Med GRS har du två regioner: en primär och sekundär region. Filer lagras tre gånger i ett Azure-lagringskluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region. GRS innehåller sex kopior av din dataspridning mellan två Azure-regioner.
- Geo-zonredundant lagring (GZRS): Tänk på GZRS som ZRS men med geo-redundans. Med GZRS lagras filer tre gånger i tre distinkta lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region.
För en robust haveriberedskapslösning bör de flesta kunder överväga ZRS. ZRS lägger till den minsta extra kostnaden för de extra dataredundansfördelarna och är också den mest sömlösa i händelse av ett avbrott. Om organisationens policy- eller regelkrav kräver geo-redundans för dina data bör du överväga antingen GRS eller GZRS.
Geo-redundans
Om ditt lagringskonto har konfigurerats med GRS- eller GZRS-replikering initierar Microsoft redundansväxlingen av Tjänsten för synkronisering av lagring om den primära regionen bedöms vara permanent oåterkallelig eller otillgänglig under en längre tid. Ingen åtgärd krävs från dig i händelse av en katastrof.
Även om du manuellt kan begära en redundansväxling av lagringssynkroniseringstjänsten till den länkade GRS- eller GZRS-regionen rekommenderar vi inte att du gör detta utanför storskaliga regionala avbrott eftersom processen inte är sömlös och kan medföra extra kostnader. Starta processen genom att öppna ett supportärende och begära att både dina Azure-lagringskonton som innehåller din Azure-filresurs och din Storage Sync-tjänst redväxeras.
Varning
Du måste kontakta supporten för att begära att lagringssynkroniseringstjänsten redväxeras om du initierar den här processen manuellt. Om du försöker skapa en ny tjänst för lagringssynkronisering med samma serverslutpunkter i den sekundära regionen kan det leda till att extra data finns kvar i lagringskontot eftersom den tidigare installationen av Azure File Sync inte rensas.
När en redundansväxling inträffar växlar serverslutpunkterna över till att automatiskt synkronisera med molnslutpunkten i den sekundära regionen. Serverslutpunkterna måste dock stämmas av med molnslutpunkterna. Detta kan leda till filkonflikter, eftersom data i den sekundära regionen kanske inte fångas upp till den primära.