Vanliga frågor och svar om Azure Files

  • Artikel

Azure Files erbjuder fullständigt hanterade filresurser i molnet som är tillgängliga via SMB-protokollet(Server Message Block) och NFS-protokollet (Network File System). Du kan montera Azure-filresurser samtidigt i molnbaserade eller lokala distributioner av Windows, Linux och macOS. Du kan också cachelagrar Azure-filresurser på Windows Server-datorer med hjälp av Azure File Sync för snabb åtkomst nära där data används.

Azure File Sync

  • Kan jag ha domänanslutna och icke-domänanslutna servrar i samma synkroniseringsgrupp?
    Ja. En synkroniseringsgrupp kan innehålla serverslutpunkter som har olika 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 Active Directory-skog, mellan servrar som finns i olika 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 hur du lägger till ändringsidentifiering 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 serverslutpunkten 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.
    • Synkroniseringsdatabasen återskapades på grund av skador eller nådd kunskapsgräns. När databasen har återskapats går synkroniseringen in i avstämningsläge. Om filstorleken och/eller tiden för senaste ändring inte är samma för filen på servern och Azure-filresursen när avstämningen utförs, skapas en konfliktfil.

    När den första uppladdningen till Azure-filresursen är klar skriver Azure File Sync inte över några filer i synkroniseringsgruppen. 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>

    Exempel: den första konflikten i CompanyReport.docx blir CompanyReport-CentralServer.docx, om den äldre skrivningen inträffade i CentralServer. Den andra konflikten namnges då CompanyReport-CentralServer-1.docx. Azure File Sync stöder 100 konfliktfiler per fil. När det maximala antalet konfliktfiler har nå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 serverslutpunkt i en befintlig synkroniseringsgrupp visas filer som nivåindelade tills de laddas ned lokalt om du väljer alternativet för att återkalla namnområdet för första namnrymden. 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).

    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.

  • Varför finns nivåindelade filer utanför serverslutpunktens namnområde?
    Innan Azure File Sync-agent version 3 blockerade Azure File Sync flytten av nivåindelade filer utanför serverslutpunkten men på samma volym som serverslutpunkten. Kopieringsåtgärder, flytt av icke-nivåindelade filer och flyttningar av nivåindelade filer till andra volymer påverkades inte. Orsaken till det här beteendet var det implicita antagandet att Utforskaren och andra Windows-API:er har som flyttar åtgärder på samma volym är (nästan) omedelbara namnbytesåtgärder. Det innebär att flyttningar gör att Utforskaren eller andra flyttmetoder (till exempel kommandoraden eller PowerShell) inte svarar medan Azure File Sync återkallar data från molnet. Från och med Azure File Sync-agent version 3.0.12.0 gör Azure File Sync att du kan flytta en nivåindelad fil utanför serverslutpunkten. Vi undviker de negativa effekter som tidigare nämnts genom att tillåta att den nivåindelade filen finns som en nivåindelad fil utanför serverslutpunkten och sedan återkalla filen i bakgrunden. Det innebär att flyttningar på samma volym är omedelbara, och vi gör allt arbete för att återkalla filen till disken när 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. Mer information finns i varför nivåindelade filer finns utanför serverslutpunktsnamnområdet för mer information. 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-portalen och välj Åtkomstkontroll (IAM) i det vänstra navigeringsfältet.

    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 inte visas i listan utför du följande 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.

      Kommentar

      När du skapar molnslutpunkten måste lagringssynkroniseringstjänsten och lagringskontot finnas i samma Microsoft Entra-klientorganisation. När molnslutpunkten har skapats kan lagringssynkroniseringstjänsten och lagringskontot flyttas till olika Microsoft Entra-klienter.

  • 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.

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 på bästa sätt.
    • 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?

    Användning av ABE med Azure Files stöds inte för närvarande, men du kan använda DFS-N med SMB Azure-filresurser.

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 miljöer med en skog och flera skogar för SMB Azure-filresurser. 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 filresursen. 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öder lokal AD DS-autentisering för Azure-filresurser integrering med en AD DS-miljö med flera skogar?

    Azure Files lokala AD DS-autentisering integreras endast med skogen för domäntjänsten 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 Active Directory-skogar.

    Kommentar

    Använd inte Utforskaren för att konfigurera Windows ACL/NTFS-behörigheter på rot-, katalog- eller filnivå i en installation med flera skogar. 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 AD?

    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.

  • Så här tar du bort cachelagrade autentiseringsuppgifter med lagringskontonyckeln och tar bort befintliga SMB-anslutningar innan du initierar en ny anslutning med Microsoft Entra-ID eller AD-autentiseringsuppgifter?

    Följ tvåstegsprocessen nedan för att ta bort de sparade autentiseringsuppgifterna som är associerade med 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.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

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

      net use <drive-letter/share-path> /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

Network File System (NFS v4.1)

Resursögonblicksbilder

Skapa resursögonblicksbilder

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

Rensa resursögonblicksbilder

  • Kan jag ta bort min resurs men inte ta bort mina resursögonblicksbilder?
    Om du har aktiva resursögonblicksbilder på din resurs kan du inte ta bort din resurs. Du kan använda ett API för att ta bort resursögonblicksbilder tillsammans med resursen. Du kan också ta bort både resursögonblicksbilderna och resursen i Azure-portalen.

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 azure-standardfilresurser som faktureras i en betala per användning-modell har olika typer av transaktioner olika priser baserat på deras inverkan på filresursen. Transaktioner påverkar inte faktureringen för premiumfilresurser, som faktureras med en etablerad modell. Mer information finns i Förstå fakturering.

  • Hur mycket kostar resursögonblicksbilder?
    Resursögonblicksbilder är inkrementella till sin natur. Ögonblicksbilden av basresursen är själva resursen. Alla efterföljande resursögonblicksbilder är inkrementella och lagrar endast skillnaden från föregående ögonblicksbild av resursen. Du debiteras endast för det ändrade innehållet. Om du har en resurs med 100 GiB data men endast 5 GiB har ändrats sedan din senaste resursögonblicksbild förbrukar resursögonblicksbilden endast 5 ytterligare GiB och du debiteras för 105 GiB. Mer information om transaktions- och standardavgifter för utgående trafik finns på sidan Prissättning.

Samverkan med andra tjänster

Se även