Vanliga frågor och svar om Azure Files och Azure File Sync

Azure Files erbjuder fullt hanterade fildelningar i molnet som du kan nå via branschstandarden Server Message Block (SMB)-protokollet och Network File System (NFS)-protokollet. Du kan montera Azure-filresurser samtidigt i molnbaserade eller lokala distributioner av Windows, Linux och macOS. Genom att använda Azure File Sync kan du cacha Azure-fildelningar på Windows Server-maskiner för snabb åtkomst till data nära där den används.

Azure File Sync FAQ

  • Kan jag ha domänanslutna och icke-domänanslutna servrar i samma synkroniseringsgrupp?
    Ja. En synkroniseringsgrupp kan innehålla serverslutpunkter som har olika služba Active Directory-medlemskap, även om de inte är domänanslutna. Även om den här konfigurationen fungerar tekniskt rekommenderar vi inte detta som en typisk konfiguration eftersom åtkomstkontrollistor (ACL: er) som har definierats för filer och mappar på en server kanske inte kan tillämpas av andra servrar i synkroniseringsgruppen. För bästa resultat rekommenderar vi att du synkroniserar mellan servrar som finns i samma služba Active Directory-skog, mellan servrar som finns i olika služba Active Directory-skogar men som har upprättat förtroenderelationer eller mellan servrar som inte finns i en domän. Vi rekommenderar att du undviker att använda en blandning av dessa konfigurationer.

  • Jag skapade en fil direkt i min Azure-filresurs med hjälp av SMB eller i portalen. Hur lång tid tar det för filen att synkroniseras med servrarna i synkroniseringsgruppen?

    Ändringar som görs i Azure-filresursen med hjälp av Azure Portal eller SMB identifieras inte omedelbart och replikeras som ändringar i serverslutpunkten. Azure Files har ännu inte ändringsmeddelanden eller journaler, så det finns inget sätt att automatiskt initiera en synkroniseringssession när filer ändras. På Windows Server använder Azure File Sync Windows USN-journaler för att automatiskt initiera en synkroniseringssession när filer ändras.

    Om du vill identifiera ändringar i Azure-filresursen har Azure File Sync ett schemalagt jobb som kallas ändringsidentifieringsjobb. Ett ändringsidentifieringsjobb räknar upp varje fil i filresursen och jämför den sedan med synkroniseringsversionen för filen. När ändringsidentifieringsjobbet fastställer att filer har ändrats initieras en synkroniseringssession av Azure File Sync. Ändringsidentifieringsjobbet initieras var 24:e timme. Eftersom ändringsidentifieringsjobbet räknar upp varje fil i Azure-filresursen tar ändringsidentifieringen längre tid i större namnområden än i mindre namnområden. För stora namnområden kan det ta längre tid än en gång var 24:e timme att avgöra vilka filer som har ändrats.

    Om du vill synkronisera filer som ändras i Azure-filresursen omedelbart kan du använda PowerShell-cmdleten Invoke-AzStorageSyncChangeDetection för att manuellt initiera identifieringen av ändringar i Azure-filresursen. Den här cmdleten är avsedd för scenarier där någon typ av automatiserad process gör ändringar i Azure-filresursen eller ändringarna görs av en administratör (som att flytta filer och kataloger till resursen). För slutanvändarändringar rekommenderar vi att du installerar Azure File Sync-agenten på en virtuell IaaS-dator och att slutanvändarna får åtkomst till filresursen via den virtuella IaaS-datorn. På så sätt synkroniseras alla ändringar snabbt med andra agenter utan att du behöver använda cmdleten Invoke-AzStorageSyncChangeDetection. Mer information finns i dokumentationen Invoke-AzStorageSyncChangeDetection .

    Vi undersöker möjligheten att lägga till ändringsdetektering för en Azure-filresurs som liknar USN för volymer på Windows Server. Hjälp oss att prioritera den här funktionen för framtida utveckling genom att rösta på den i Azure Community Feedback.

  • Vad händer om samma fil ändras nästan samtidigt på två servrar?
    Filkonflikter uppstår när filen i Azure-filresursen inte matchar filen på serverns slutpunktsplats (olika storlek och/eller tid för senaste ändring).

    Följande scenarier kan orsaka filkonflikter:

    • En fil skapas eller ändras i en slutpunkt (till exempel Server A). Om samma fil ändras på en annan slutpunkt innan ändringen på Server A synkroniseras till slutpunkten, skapas en konfliktfil.
    • Filen fanns i Azure-filresursen och på serverslutpunktens plats innan serverslutpunkten skapades. Om filstorleken och/eller tiden för senaste ändring inte är samma för filen på servern och Azure-filresursen när serverslutpunkten skapas, skapas en konfliktfil.
    • Du återskapar synkroniseringsdatabasen på grund av korruption eller att kunskapsgränsen har uppnåtts. Efter att du återskapat databasen går synkroniseringen in i ett läge som kallas avstämning. Om filstorleken och den senaste modifieringstiden skiljer sig mellan filen på servern och Azure-fildelningen när avstämningen sker, skapas en konfliktfil.

    Efter att den initiala uppladdningen till Azure-fildelningen är klar, skriver Azure File Sync inte över några filer i din synkroniseringsgrupp. I stället använder den en enkel strategi för konfliktlösning: den behåller båda ändringarna i filer som ändras i två slutpunkter samtidigt. Den senast skrivna ändringen behåller det ursprungliga filnamnet. Den äldre filen (bestäms av LastWriteTime) har slutpunktsnamnet och konfliktnumret som läggs till i filnamnet. För serverslutpunkter är slutpunktsnamnet namnet på servern. För molnslutpunkter är slutpunktsnamnet Moln. Namnet följer denna taxonomi:

    \<FileNameWithoutExtension\>-\<endpointName\>\[-#\].\<ext\>

    Till exempel blir den första konflikten i CompanyReport.docx CompanyReport-CentralServer.docx om CentralServer är där den äldre skrivningen ägde rum. Den andra konflikten heter CompanyReport-CentralServer-1.docx. Azure File Sync stöder 100 konfliktfiler per fil. När det maximala antalet konfliktfiler uppnåtts synkroniseras inte filen förrän antalet konfliktfiler är mindre än 100.

  • Jag har inaktiverat molnnivåindelning, varför finns det nivåindelade filer på serverslutpunktens plats?
    Det finns två orsaker till att nivåindelade filer kan finnas på serverslutpunktens plats:

    • När du lägger till en ny serverendpoint i en befintlig synkroniseringsgrupp, om du väljer antingen alternativet att återkalla namnområdet först eller alternativet att endast återkalla namnområdet för initial nedladdningsläge, visas filer som nivåer tills de laddas ner lokalt. Undvik detta genom att välja alternativet Undvik nivåindelade filer för det inledande nedladdningsläget. Om du vill återkalla filer manuellt använder du cmdleten Invoke-StorageSyncFileRecall .

    • Om molnnivåindelning har aktiverats på serverslutpunkten och sedan inaktiverats förblir filerna nivåindelade tills de nås.

  • Varför visar inte mina nivåindelade filer miniatyrbilder eller förhandsversioner i Windows Utforskaren?
    För nivåindelade filer visas inte miniatyrbilder och förhandsgranskningar på serverslutpunkten. Detta är ett förväntat beteende eftersom funktionen för miniatyrcache i Windows avsiktligt hoppar över att läsa filer med offlineattributet. Med molnnivåindelning aktiverat skulle läsning via nivåindelade filer leda till att de laddas ned (återkallas). Du kan dock konfigurera Azure File Sync för att hoppa över att ange offlineattributet.

    Det här beteendet är inte specifikt för Azure File Sync. Windows Utforskaren visar ett "grått X" för alla filer som har offlineattributet inställt. Du ser X-ikonen när du kommer åt filer via SMB. En detaljerad förklaring av det här beteendet finns i Varför får jag inte miniatyrbilder för filer som är markerade offline?

    Frågor om hur du hanterar nivåindelade filer finns i Hantera nivåindelade filer.

  • Finns det något alternativ för att hoppa över offlineattributet för nivåindelade filer?

    Om du föredrar att göra miniatyrbilder och förhandsgranskningar synliga för nivåindelade filer kan du konfigurera Azure File Sync för att hoppa över inställningen av offlineattributet.

    1. Lägg till följande registernyckel på servern:

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t REG_DWORD /d 1 /f

    2. Starta om FileSyncSvc-tjänsten .

    Efter konfigurationen:

    • Nya nivåindelade filer har inte längre offlineattributet.
    • Befintliga nivåindelade filer uppdateras under nästa underhållskörning (inträffar var 24:e timme).

    Anteckning

    Den här inställningen tillämpas globalt för alla filer, inte på specifika tillägg. Utan offlineattributet visar Windows Utforskaren en annan ikon. Du kan lägga till kolumnen Attribut i Utforskaren för att identifiera nivåindelade filer (attribut ALM). Baserat på användningsmönster kan det öka antalet filåterkallningar om du hoppar över offlineattributet, så du bör övervaka återkallningsaktiviteten och se till att utgående kostnader förblir inom ett acceptabelt intervall. Se Hantera nivåindelade filer.

  • Varför finns nivåindelade filer utanför serverslutpunktens namnområde?
    Före Azure File Sync agent version 3 blockerade Azure File Sync att flytta nivådelade filer utanför serverändpunkten men på samma volym som serverns slutpunkt. Kopieringsåtgärder, flytt av icke-tierade filer och flytt av tierade filer till andra volymer påverkades inte. Orsaken till det här beteendet var det implicita antagandet att Utforskaren och andra Windows API:er utgår från att flyttoperationer på samma volym är (nästan) omedelbara namnbytesåtgärder. Detta antagande innebär att flyttar gör att File Explorer eller andra flyttmetoder (såsom kommandoraden eller PowerShell) verkar oresponsiva medan Azure File Sync hämtar data från molnet. Från och med Azure File Sync-agent version 3.0.12.0 tillåter Azure File Sync dig att flytta en nivådelad fil utanför serverns endpoint. De negativa effekterna som nämnts tidigare undviks genom att låta den nivåindelade filen finnas kvar som en nivåindelad fil utanför serverslutpunkten och sedan hämta tillbaka filen i bakgrunden. Detta tillvägagångssätt innebär att flyttningar på samma volym sker omedelbart, och Azure File Sync återhämtar filen till disk efter att flytten är klar.

  • Jag har problem med Azure File Sync på min server (synkronisering, molnnivåindelning osv.). Ska jag ta bort och återskapa min serverslutpunkt?

    Nej: att ta bort en serverslutpunkt är inte som att starta om en server! Att ta bort och återskapa serverslutpunkten är nästan aldrig en lämplig lösning för att åtgärda problem med synkronisering, molnnivåindelning eller andra aspekter av Azure File Sync. Att ta bort en serverslutpunkt är en destruktiv åtgärd. Det kan leda till dataförlust om nivåindelade filer finns utanför serverslutpunktens namnområde. För mer information, se varför nivåindelade filer finns utanför serverslutpunktsnamnområdet. Eller så kan det resultera i otillgängliga filer för nivåindelade filer som finns i serverslutpunktens namnområde. De här problemen löser inte när serverslutpunkten återskapas. Nivåindelade filer kan finnas i serverslutpunktens namnområde även om du aldrig har aktiverat molnnivåindelning. Därför rekommenderar vi att du inte tar bort serverslutpunkten om du inte vill sluta använda Azure File Sync med den här mappen eller uttryckligen har instruerats att göra det av en Microsoft-tekniker. Mer information om hur du tar bort serverslutpunkter finns i Ta bort en serverslutpunkt.

  • Kan jag flytta lagringssynkroniseringstjänsten och/eller lagringskontot till en annan resursgrupp, prenumeration eller Microsoft Entra-klientorganisation?
    Ja, du kan flytta lagringssynkroniseringstjänsten och/eller lagringskontot till en annan resursgrupp, prenumeration eller Microsoft Entra-klientorganisation. När du har flyttat lagringssynkroniseringstjänsten eller lagringskontot måste du ge programmet Microsoft.StorageSync åtkomst till lagringskontot. Följ de här stegen:

    1. Logga in på Azure Portal och välj Åtkomstkontroll (IAM) på tjänstmenyn.

    2. Välj fliken Rolltilldelningar för att visa en lista över användare och program (tjänstens huvudnamn) som har åtkomst till ditt lagringskonto.

    3. Kontrollera om Microsoft.StorageSync eller Hybrid File Sync Service (gammalt programnamn) visas i listan med rollen Läs- och dataåtkomst.

      Om Microsoft. StorageSync eller Hybrid File Sync Service finns inte med i listan, följ dessa steg:

      • Markera Lägga till.
      • I fältet Roll väljer du Läs- och dataåtkomst.
      • I fältet Välj skriver du Microsoft.StorageSync, väljer rollen och väljer sedan Spara.

      Anteckning

      När du skapar molnslutpunkten måste lagringssynkroniseringstjänsten och lagringskontot finnas i samma Microsoft Entra-klientorganisation. Efter att molnendpointen har skapats kan du flytta lagringssynkroniseringstjänsten och lagringskontot till olika Microsoft Entra-tenants.

  • Bevarar Azure File Sync NTFS-ACL:er på katalog-/filnivå tillsammans med data som lagras i Azure Files?

    Från och med den 24 februari 2020 sparas nya och befintliga ACL:er som är nivåindelade i Azure-filsynkronisering i NTFS-format, och ACL-ändringar som görs direkt till Azure-filresursen synkroniseras med alla servrar i synkroniseringsgruppen. Ändringar i ACL:er som görs i Azure-filresurser synkroniseras via Azure File Sync. När du kopierar data till Azure Files ska du använda ett kopieringsverktyg som stöder nödvändig "återgivning" för att kopiera attribut, tidsstämplar och ACL:er till en Azure-filresurs – antingen via SMB eller REST. När du använder Azure-kopieringsverktyg som AzCopy är det viktigt att använda den senaste versionen. Kontrollera tabellen filkopieringsverktyg för att få en översikt över Azure-kopieringsverktygen så att du kan kopiera alla viktiga metadata för en fil.

    Om du har aktiverat Azure Backup på dina hanterade filresurser för Azure File Sync kan fil-ACL:er fortsätta att återställas som en del av arbetsflödet för säkerhetskopieringsåterställning. Detta fungerar antingen för hela resursen eller enskilda filer/kataloger.

    Om du använder ögonblicksbilder som en del av den självhanterade säkerhetskopieringslösningen för filresurser som hanteras av Azure File Sync kanske dina ACL:er inte återställs korrekt till NTFS-ACL:er om ögonblicksbilderna togs före den 24 februari 2020. Om detta inträffar bör du kontakta Azure Support.

  • Synkroniserar Azure File Sync LastWriteTime för kataloger? Varför uppdateras inte tidsstämpeln för datum för en katalog när filer i den ändras?
    Nej, Azure File Sync synkroniserar inte LastWriteTime för kataloger. Dessutom uppdaterar Azure Files inte datummodifierad tidsstämpel (LastWriteTime) för kataloger när filer i katalogen ändras. Det här beteendet är förväntat.

  • Hur fungerar volymutrymme för molnnivåindelning som en del av interop med Deduplicering?
    I vissa fall där Dedup är installerat kan det tillgängliga volymutrymmet öka mer än väntat efter att Dedup garbage collection har aktiverats. Anta till exempel att principen för ledigt utrymme för molnnivåindelning är inställd på 20%. Azure File Sync meddelas när det finns lågt ledigt utrymme (till exempel när ledigt utrymme är 19%). Tiering innebär att 1% mer utrymme måste frigöras, men som buffert finns det 5% extra, så det går upp till 25% (till exempel 30 GiB). Filerna placeras i nivåer upp till 30 GiB. Som en del i samverkan med Dedup initierar Azure File Sync skräpinsamling i slutet av nivålagringssessionen.

  • Varför hämtar antivirusprogrammet på servern för Azure File Sync nivåindelade filer?
    När användare får tillgång till nivådelade filer kan vissa antivirusprogram (AV) orsaka oavsiktliga filåterkallelser. Detta problem uppstår om antivirusprogrammet inte är konfigurerat för att ignorera nivådelade filer (de med attributet RECALL_ON_DATA_ACCESS ). Så här händer det:

    1. En användare försöker komma åt en nivåindelad fil.
    2. AV-programvaran blockerar läshandtaget.
    3. AV-mjukvaran utför sedan sin egen läsning för att skanna filen efter virus.

    Denna process kan verka som om antivirusprogrammet återkallar de nivådelade filerna, men det triggas faktiskt av användarens åtkomstförsök. För att undvika detta problem, se till att din AV-leverantör konfigurerar sin mjukvara för att ignorera skanning av nivådelade filer med attributet RECALL_ON_DATA_ACCESS .

  • Kan SSL-inspektionsprogramvara blockera åtkomst till Azure File Sync-servrar? Se till att din SSL-inspektionsprogramvara (såsom Zscaler eller FortiGate) tillåter Azure File Sync-serverns endpoints att komma åt Azure. Dessa SSL-inspektionsverktyg kan åsidosätta brandväggsinställningarna och selektivt tillåta trafik. Kontakta nätverksadministratören för att lösa problemet. Använd kommandot testnet för att avgöra om din Azure File Sync-server upplever detta problem.

Resursleverantörer och klassiska fildelningar

  • Vad är skillnaden mellan resursleverantörerna Microsoft.Storage och Microsoft.FileShares? Vad är en Azure-fildelning jämfört med en Azure Classic-fildelning?

    Resursleverantörer är förvaltningstjänster som levererar specifika typer av resurser i Azure. Du driftsätter klassiska Azure-filresurser i ett lagringskonto, som är en resurs på högsta nivån som använder resursleverantören Microsoft.Storage. Alla lagringsresurser i ett lagringskonto delar de begränsningar som gäller för det lagringskontot. Fildelningar erbjuds av Microsoft. FileShares-resursleverantörer är en ny toppnivåresurs som förenklar fildelningsdistribution genom att eliminera behovet av ett lagringskonto. För närvarande Microsoft. FileShares stöder endast NFS-fildelningsprotokollet. Klassiska fildelningar stöder både SMB och NFS.

Säkerhet, autentisering och åtkomstkontroll

  • Hur kan jag granska filåtkomst och ändringar i Azure Files?

    Det finns två alternativ som tillhandahåller granskningsfunktioner för Azure Files:

    • Om användarna kommer åt Azure-filresursen direkt kan du använda Azure Storage-loggar för att spåra filändringar och användaråtkomst i felsökningssyfte. Begäranden loggas i mån av möjlighet.
    • Om användarna kommer åt Azure-filresursen via en Windows Server som har Azure File Sync-agenten installerad använder du en granskningsprincip eller produkt från tredje part för att spåra filändringar och användaråtkomst på Windows Server.

  • Stöder Azure Files åtkomstbaserad uppräkning (ABE) för att styra synligheten för filer och mappar i SMB Azure-filresurser?

    Azure Files stöder inte användning av ABE, men du kan använda DFS-N med SMB- Azure fildelningar.

  • Kan jag spara till en Azure-filresurs med hjälp av en skrivare eller skanner?

    Azure Files stöder endast Windows, Linux och macOS. Åtkomst till en Azure-filresurs direkt från en skrivare eller skanner stöds inte. Men om du redan använder Azure File Sync kan du skriva ut eller skanna till Windows-filservern och sedan synkronisera filen till en Azure-filresurs.

  • Stöder Azure Files alternativa dataströmmar?

Azure Files stöder inte alternativa dataströmmar. Överföring av data via SMB genererar ett meddelande om att det redan finns en fil om en alternativ dataström hittas. Du kan kontrollera alternativa strömmar med hjälp av följande PowerShell-kommando:

get-item <file path+name> -Stream *

Om mer än en ström visas kan du ta bort dem med hjälp av följande PowerShell-kommando:

remove-Item <file path+name> -Stream *

Alternativa dataströmmar bevaras lokalt när Azure File Sync används.

Identitetsbaserad autentisering

  • Stöder Microsoft Entra Domain Services SMB-åtkomst med Microsoft Entra-autentiseringsuppgifter från enheter som är anslutna till eller registrerade med Microsoft Entra-ID?

    Nej, det här scenariot stöds inte.

  • Kan jag använda det kanoniska namnet (CNAME) för att montera en Azure-filresurs när jag använder identitetsbaserad autentisering?

    Ja, det här scenariot stöds nu i både enskilda och flera domänträd för SMB Azure-fildelningar. Azure Files stöder dock endast konfigurering av CNAME:er med lagringskontonamnet som ett domänprefix. Om du inte vill använda lagringskontots namn som prefix kan du överväga att använda DFS-namnområden i stället.

  • Kan jag komma åt Azure-filresurser med Microsoft Entra-autentiseringsuppgifter från en virtuell dator under en annan prenumeration?

    Om den prenumeration under vilken filresursen distribueras är associerad med samma Microsoft Entra-klientorganisation som Microsoft Entra Domain Services-distributionen som den virtuella datorn är domänansluten till, kan du sedan komma åt Azure-filresurser med samma Microsoft Entra-autentiseringsuppgifter. Begränsningen tillämpas inte på prenumerationen utan på den associerade Microsoft Entra-klientorganisationen.

  • Kan jag aktivera antingen Microsoft Entra Domain Services eller lokal AD DS-autentisering för Azure-filresurser med hjälp av en Microsoft Entra-klient som skiljer sig från Azure-filresursens primära klientorganisation?

    Nej. Azure Files stöder endast Microsoft Entra Domain Services eller lokal AD DS-integrering med en Microsoft Entra-klientorganisation som finns i samma prenumeration som fildelningen. En prenumeration kan bara associeras med en Microsoft Entra-klientorganisation. När du använder lokal AD DS för autentisering ska AD DS-autentiseringsuppgifterna synkroniseras med det Microsoft Entra-ID som lagringskontot är associerat med.

  • Stödjer lokal AD DS-autentisering för Azure-fildelningar integrering med en AD DS-miljö som använder flera skogar?

    Azure Files lokala AD DS-autentisering integreras endast med domäntjänstens forest som lagringskontot är registrerat på. Om du vill stödja autentisering från en annan skog måste din miljö ha ett skogsförtroende korrekt konfigurerat. Detaljerade anvisningar finns i Använda Azure Files med flera služba Active Directory-skogar.

    Anteckning

    Använd inte Utforskaren i en miljö med flera skogar för att konfigurera Windows ACL/NTFS-behörigheter på rot-, katalog- eller filnivå. Använd icacls i stället.

  • Finns det någon skillnad i att skapa ett datorkonto eller tjänstinloggningskonto för att representera mitt lagringskonto i služba Active Directory?

    Att skapa antingen ett datorkonto (standard) eller ett tjänstinloggningskonto har ingen skillnad på hur autentisering fungerar med Azure Files. Du kan välja själv hur du ska representera ett lagringskonto som en identitet i DIN AD-miljö. Standardinställningen DomainAccountType i Join-AzStorageAccountForAuth cmdlet är datorkonto. Lösenordets förfalloålder som konfigurerats i DIN AD-miljö kan dock skilja sig åt för dator- eller tjänstinloggningskonton, och du måste ta hänsyn till detta för att uppdatera lösenordet för din lagringskontoidentitet i AD.

  • Hur tar jag bort cachade inloggningsuppgifter genom att använda lagringskontonyckeln och tar bort befintliga SMB-anslutningar innan jag initierar en ny anslutning med Microsoft Entra ID eller AD-uppgifter?

    Följ tvåstegsprocessen för att ta bort den sparade inloggningsinformationen kopplad till lagringskontonyckeln och ta bort SMB-anslutningen:

    1. Kör följande kommando från en Windows-kommandotolk för att ta bort autentiseringsuppgifterna. Om du inte hittar någon innebär det att du inte har sparat autentiseringsuppgifterna och kan hoppa över det här steget.

      Använd följande kommando för att ta bort autentiseringsuppgifterna: cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Ta bort den befintliga anslutningen till fildelningen. Du kan ange monteringssökvägen som antingen den monterade enhetsbeteckningen eller storage-account-name.file.core.windows.net-sökvägen.

      net use <enhetsbokstav/delningsväg> /delete

  • Går det att visa userPrincipalName (UPN) för en fil-/katalogägare i Utforskaren i stället för säkerhetsidentifieraren (SID)?

    Utforskaren anropar ett RPC-API direkt till servern (Azure Files) för att översätta SID till ett UPN. Azure Files stöder inte det här API:et, så i Utforskaren visas SID för en fil-/katalogägare i stället för UPN för filer och kataloger som finns i Azure Files. Från en domänansluten klient kan du dock använda följande PowerShell-kommando för att visa alla objekt i en katalog och deras ägare, inklusive UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Nätverksfilsystem (NFS v4.1)

Dela ögonblicksbild FAQ

Skapa delade ögonblicksbilder

  • Är mina delningsögonblicksbilder geo-redundanta?
    Ögonblicksbilder har samma redundans som den Azure-fildelning för vilken de togs. Om du har valt geo-redundant lagring för ditt konto lagras även delningsögonblicksbilden redundant i den kopplade regionen.

Rensa delningsögonblicksbilder

  • Kan jag ta bort min delning men inte ta bort mina delningsögonblicksbilder?
    Nej. Arbetsflödet för att ta bort fildelning tar automatiskt bort snapshots när du tar bort delningen.

Azure Files fakturering och prissättning

  • Vad är transaktioner i Azure Files och hur faktureras de? Protokolltransaktioner sker när en användare, ett program, ett skript eller en tjänst interagerar med Azure-filresurser (skriva, läsa, visa, ta bort filer osv.). Det är viktigt att komma ihåg att vissa åtgärder som du kan uppfatta som en enda åtgärd faktiskt kan omfatta flera transaktioner. För betala per användning-filresurser har olika typer av transaktioner olika priser baserat på deras inverkan på filresursen. Transaktioner påverkar inte faktureringen för etablerade filresurser. Mer information finns i Förstå fakturering.

Azure Files-interoperabilitet med andra tjänster

  • Vad är skillnaden mellan Azure Files och Azure NetApp Files?
    Azure Files och Azure NetApp Files är olika fillagringstjänster i Azure och de är utformade för olika arbetsbelastningar och prestandakrav. Azure Files tillhandahåller serverlösa SMB- och NFS-filresurser och erbjuder Azure File Sync som ett alternativ för cachelagring av SMB-filresurser på Windows Server. Azure NetApp Files är en högpresterande fillagringstjänst utan operativsystem som drivs av NetApp-teknik som stöder filresurser med NFS, SMB och dubbla protokoll. Mer information finns i Compare Azure Files och Azure NetApp Files.

  • Kan jag använda min Azure-fildelning som en fildelningsvittne för mitt Windows Server-failoverkluster?
    Denna konfiguration stöds inte för Azure Files. För att lära dig hur du sätter upp denna konfiguration med Azure Blob-lagring, se Deploy a Cloud Witness for a Failover Cluster.

Se även

  • Last updated on