Een implementatie van Azure Files plannen

Het plannen van een Azure Files-implementatie omvat een paar belangrijke beslissingen. Gebruik dit artikel om de juiste opties voor jouw werklast te kiezen.

Je moet het volgende beslissen:

1. Hoe krijgen klanten toegang tot het deel? Rechtstreeks koppelen vanuit de cloud of on-premises clients, of lokaal cachen met Azure File Sync?
2. Welk beheermodel? Klassieke bestandsdelingen (opslagaccounts) of het nieuwe Microsoft. FileShares-resourceprovider?
3. Welk protocol?SMB (Windows/Linux/macOS) of NFS (alleen Linux)?
4. Hoe zullen gebruikers zich authenticeren?Identiteitsgebaseerde authenticatie of opslagaccountsleutel?
5. Welke netwerkconfiguratie? Publiek eindpunt, service-eindpunten of privé-eindpunten?
6. Welke prestatielaag en redundantie-optie?SSD of HDD, en welke redundantie-optie?

De volgende secties behandelen elke beslissing in detail.

Beheerconcepten

Azure Files biedt twee beheermodellen voor het uitrollen van bestandsdelingen:

• Klassieke bestandsshares (Microsoft.Storage-resourceprovider): Implementeer bestandsshares in een opslagaccount. Ondersteunt SMB en NFS, SSD en HDD, alle redundantietypes en alle regio's.
• Bestandsshares (resourceprovider Microsoft.FileShares): Implementeer bestandsshares als Azure-resources op het hoogste niveau, zonder een opslagaccount. Vereenvoudig het beheer met netwerken per deel, facturering en beveiliging. Momenteel alleen beschikbaar voor NFS-bestandsdelingen.

Voor details over resourceproviders, functievergelijkingen en regionale beschikbaarheid, zie Azure Files management concepts.

Beschikbare protocollen

Azure Files biedt twee industriestandaard bestandssysteemprotocollen voor het koppelen van Azure bestandsshares: het SMB-protocol (Server Message Block) en het NFS-protocol (Network File System). Kies het protocol dat het beste past bij uw workload. Azure bestandsshares niet zowel de SMB- als NFS-protocollen op dezelfde bestandsshare ondersteunen, hoewel u SMB- en NFS-Azure bestandsshares binnen hetzelfde opslagaccount kunt maken.

Met zowel SMB- als NFS-bestandsshares biedt Azure Files hoogwaardige bestandsshares die kunnen worden geschaald om te voldoen aan uw opslagbehoeften, en duizenden clients hebben er gelijktijdig toegang toe.

Identiteit

Als u toegang wilt krijgen tot een Azure bestandsshare, moet u worden geverifieerd en gemachtigd om toegang te krijgen tot de share. In bijna alle gevallen gebruikt u verificatie op basis van identiteit in plaats van de sleutel van het opslagaccount voor toegang tot SMB Azure bestandsshares.

Azure Files ondersteunt de volgende verificatiemethoden voor SMB-shares:

• On-premises Active Directory Domain Services (AD DS): U kunt Azure-opslagaccounts toevoegen aan een domein in Active Directory Domain Services van de klant, net zoals een Windows Server-bestandsserver of NAS-apparaat. U kunt een domeincontroller on-premises, in een Azure VM of zelfs als een VM in een andere cloudprovider implementeren. Azure Files is agnostisch voor waar uw domeincontroller wordt gehost. Nadat je een opslagaccount hebt toegewezen, kan de eindgebruiker een bestandsdeling koppelen met het gebruikersaccount waarmee hij op zijn pc is ingelogd. Verificatie op basis van AD maakt gebruik van het Kerberos-verificatieprotocol.
• Microsoft Entra Domeinservices: Microsoft Entra Domeinservices biedt een door Microsoft beheerde domeincontroller die u kunt gebruiken voor Azure resources. Het koppelen van uw opslagaccount aan Microsoft Entra Domeinservices biedt vergelijkbare voordelen als het koppelen van uw opslagaccount aan Active Directory Domain Services die eigendom is van de klant. Deze implementatieoptie is het handigst voor lift-and-shift-scenario's van toepassingen waarvoor ad-machtigingen zijn vereist. Omdat Domain Services verificatie op basis van AD biedt, gebruikt deze optie ook het Kerberos-verificatieprotocol.
• Microsoft Entra Kerberos: met Microsoft Entra Kerberos kunt u Microsoft Entra ID gebruiken om hybrid- of cloudidentiteiten te verifiëren. Deze configuratie maakt gebruik van Microsoft Entra ID om Kerberos-tickets uit te geven voor toegang tot de bestandsshare met het SMB-protocol. Dit betekent dat uw eindgebruikers toegang hebben tot Azure-bestandsshares via het internet vanaf Microsoft Entra hybride gekoppelde en Microsoft Entra gekoppelde VM's.
• Active Directory verificatie via SMB voor Linux-clients: Azure Files ondersteunt verificatie op basis van identiteiten via SMB voor Linux-clients met behulp van het Kerberos-verificatieprotocol via AD DS of Microsoft Entra Domeinservices.
• Sleutel van Azure-opslagaccount: Hoewel dit om veiligheidsredenen niet wordt aanbevolen, kunt u Azure-bestandsshares ook koppelen met een sleutel van een Azure-opslagaccount in plaats van een identiteit te gebruiken. Als u een bestandsshare wilt koppelen met behulp van de sleutel van het opslagaccount, gebruikt u de naam van het opslagaccount als de gebruikersnaam en de sleutel van het opslagaccount als wachtwoord. Het gebruik van de sleutel van het opslagaccount om de Azure bestandsshare te koppelen is in feite een beheerdersbewerking, omdat de gekoppelde bestandsshare volledige machtigingen heeft voor alle bestanden en mappen op de share, zelfs als ze ACL's hebben. Wanneer u de sleutel van het opslagaccount gebruikt om te koppelen via SMB, wordt het NTLMv2-verificatieprotocol gebruikt. Als u de sleutel van het opslagaccount moet gebruiken, gebruikt u privé-eindpunten of service-eindpunten, zoals beschreven in de sectie Netwerken .

Voor klanten die migreren vanaf on-premises bestandsservers of nieuwe bestandsshares maken in Azure Files die zich moeten gedragen als Windows Server-bestandsservers of NAS-apparaten, koppelt u uw opslagaccount aan het domein van het AD DS van de klant. Zie Overview - on-premises AD DS-verificatie via SMB voor Azure bestandsshares voor meer informatie.

Netwerken

Voor het rechtstreeks koppelen van uw Azure bestandsdeling is vaak enige aandacht nodig voor de netwerkconfiguratie, omdat:

• Veel organisaties en internetproviders blokkeren poort 445, die SMB-bestandsshares gebruiken voor communicatie, voor uitgaand (internet) verkeer.
• NFS-bestandsshares zijn afhankelijk van verificatie op netwerkniveau en zijn daarom alleen toegankelijk via beperkte netwerken. Voor het gebruik van een NFS-bestandsshare is altijd een netwerkconfiguratie vereist.

Voor het configureren van netwerken biedt Azure Files een openbaar interneteindpunt en integratie met Azure Netwerkfuncties, zoals service-eindpunten, waarmee het openbare eindpunt wordt beperkt tot opgegeven virtuele netwerken en privé-eindpunten, die uw opslagaccount een privé-IP-adres geven vanuit een IP-adresruimte van een virtueel netwerk. Hoewel er geen extra kosten in rekening worden gebracht voor het gebruik van openbare eindpunten of service-eindpunten, gelden standaardgegevensverwerkingstarieven voor privé-eindpunten.

Houd rekening met de volgende netwerkconfiguraties:

• Als het vereiste protocol SMB is en alle toegang via SMB afkomstig is van clients in Azure, is er geen speciale netwerkconfiguratie vereist.
• Als het vereiste protocol SMB is en de toegang afkomstig is van clients on-premises, is een VPN- of Azure ExpressRoute verbinding van on-premises naar uw Azure netwerk vereist, waarbij Azure Files beschikbaar is in uw interne netwerk met behulp van privé-eindpunten.
• Als het vereiste protocol NFS is, kunt u service-eindpunten of privé-eindpunten gebruiken om het netwerk te beperken tot opgegeven virtuele netwerken. Als u een statisch IP-adres nodig hebt en/of uw workload hoge beschikbaarheid vereist, gebruikt u een privé-eindpunt. Bij service-eindpunten kan een zeldzame gebeurtenis, zoals een zonestoring, ertoe leiden dat het onderliggende IP-adres van het opslagaccount wordt gewijzigd. Hoewel de gegevens nog steeds beschikbaar zijn op de bestandsshare, moet de client de share opnieuw koppelen.

Zie Azure Files netwerkoverwegingen voor meer informatie.

Naast rechtstreeks verbinding maken met de bestandsshare via het openbare eindpunt of via een VPN/ExpressRoute-verbinding met een privé-eindpunt, biedt SMB een extra clienttoegangsstrategie: SMB via QUIC. SMB via QUIC biedt zero-config 'SMB VPN' voor SMB-toegang via het QUIC-transportprotocol. Hoewel Azure Files SMB niet direct ondersteunt via QUIC, kun je een lichtgewicht cache van je Azure bestandsshares maken op een Windows Server 2022 Azure Edition VM door Azure File Sync te gebruiken. Voor meer informatie over deze optie, zie SMB over QUIC met Azure File Sync.

Versleuteling voor Azure Files

Azure Files ondersteunt twee verschillende typen versleuteling:

• Versleuteling tijdens overdracht, die betrekking heeft op de versleuteling die wordt gebruikt bij het koppelen of openen van de Azure bestandsshare
• Versleuteling in rust, die betrekking heeft op de wijze waarop de gegevens worden versleuteld wanneer ze op schijf worden opgeslagen

Versleuteling tijdens transport

Standaard zijn voor alle Azure opslagaccounts versleuteling in transit ingeschakeld. Deze functie betekent dat wanneer u een bestandsshare koppelt via SMB of deze opent via het FileREST-protocol (zoals via de Azure-portal, PowerShell/CLI of Azure-SDK's), Azure Files alleen de verbinding toestaat als deze is gemaakt met SMB 3.x met versleuteling of HTTPS. Clients die geen ondersteuning bieden voor SMB 3.x of clients die SMB 3.x ondersteunen, maar geen SMB-versleuteling, kunnen de Azure bestandsshare niet koppelen als versleuteling tijdens overdracht is ingeschakeld. Zie de documentatie voor Windows, macOS en voor meer informatie over welke besturingssystemen SMB 3.x met versleuteling ondersteunen. Alle huidige versies van PowerShell, CLI en SDK's ondersteunen HTTPS.

U kunt versleuteling tijdens overdracht uitschakelen voor een Azure opslagaccount. Wanneer u versleuteling uitschakelt, staat Azure Files ook SMB 2.1 en SMB 3.x zonder versleuteling en niet-versleutelde FileREST API-aanroepen via HTTP toe. De primaire reden voor het uitschakelen van versleuteling tijdens overdracht is het ondersteunen van een verouderde toepassing die moet worden uitgevoerd op een ouder besturingssysteem, zoals Windows Server 2008 R2 of een oudere Linux-distributie. Azure Files staat alleen SMB 2.1-verbindingen toe binnen dezelfde Azure regio als de Azure bestandsshare. Een SMB 2.1-client buiten de Azure regio van de Azure bestandsshare, zoals on-premises of in een andere Azure regio, heeft geen toegang tot de bestandsshare.

Zorg ervoor dat versleuteling van gegevens tijdens overdracht is ingeschakeld.

Zie vereiste beveiligde overdracht in Azure-opslag en Versleuteling tijdens overdracht voor NFS Azure-bestandsshares voor meer informatie over versleuteling tijdens transport.

Versleuteling in rusttoestand

Azure Files gebruikt hetzelfde versleutelingsschema als de andere Azure-opslagservices, zoals Azure Blob Storage. Alle gegevens die zijn opgeslagen in Azure Files worden in rust versleuteld via service-side encryption (SSE), wat vergelijkbaar is met BitLocker op Windows.

Omdat gegevens worden versleuteld onder het bestandssysteem van de Azure-bestandsshare, omdat deze zijn gecodeerd op schijf, hebt u geen toegang nodig tot de onderliggende sleutel op de client om naar de Azure-bestandsshare te lezen of schrijven. Inactieve versleuteling geldt voor zowel SMB- als NFS-protocollen.

Standaard worden gegevens die zijn opgeslagen in Azure Files versleuteld met Microsoft beheerde sleutels. Met Microsoft beheerde sleutels bevat Microsoft de sleutels voor het versleutelen en ontsleutelen van de gegevens. Microsoft is verantwoordelijk voor het regelmatig roteren van deze sleutels.

Voor Azure klassieke bestandsshares kunt u ervoor kiezen om uw gegevens te versleutelen met behulp van customer beheerde sleutels. Als u door de klant beheerde sleutels kiest, is Azure Files gemachtigd om toegang te krijgen tot uw sleutels om te voldoen aan lees- en schrijfaanvragen van uw clients. Met door de klant beheerde sleutels kunt u deze autorisatie op elk gewenst moment intrekken. Maar zonder deze autorisatie is uw Azure bestandsshare niet meer toegankelijk via SMB of de FileREST-API.

U kunt door de klant beheerde sleutels niet gebruiken voor versleuteling in rust met Azure bestandsshares die zijn gemaakt met behulp van de Microsoft. FileShares-resourceprovider. U moet door Microsoft beheerde sleutels gebruiken.

Gegevensbescherming

Azure Files maakt gebruik van een meerlaagse benadering om ervoor te zorgen dat er een back-up van uw gegevens wordt gemaakt, herstelbaar en beschermd tegen beveiligingsrisico's. Zie Azure Files overzicht van gegevensbeveiliging.

Zacht verwijderen

Voorlopig verwijderen is een instelling op opslagaccountniveau die u kunt gebruiken om uw bestandsshare te herstellen wanneer deze per ongeluk wordt verwijderd. Wanneer u een bestandsshare verwijdert, wordt deze overgezet naar een voorlopig verwijderde status in plaats van permanent te worden gewist. U kunt configureren hoe lang voorlopig verwijderde shares kunnen worden hersteld voordat ze permanent worden verwijderd en de share op elk gewenst moment tijdens deze bewaarperiode ongedaan maken.

Voorlopig verwijderen is standaard ingeschakeld voor nieuwe opslagaccounts. Als u een workflow hebt waarin het verwijderen van shares gebruikelijk en te verwachten is, kunt u besluiten een korte bewaarperiode in te stellen of soft delete niet in te schakelen.

Voor meer informatie over voorlopig verwijderen, zie Onopzettelijke gegevensverwijdering voorkomen.

Back-up

Maak een back-up van uw Azure-bestandsshares met share-snapshots, dit zijn alleen-lezenkopieën van uw share op een bepaald tijdstip. Momentopnamen zijn incrementeel, dus ze bevatten alleen gegevens die zijn gewijzigd sinds de vorige momentopname. Elke bestandsshare ondersteunt maximaal 200 momentopnamen en u kunt ze maximaal 10 jaar bewaren. U kunt handmatig momentopnamen maken in de Azure-portal of PowerShell of de opdrachtregelinterface (CLI) gebruiken. U kunt ook Azure Backup gebruiken.

Azure Backup voor SMB-Azure-bestandsshares verwerkt de planning en retentie van momentopnamen. De mogelijkheden van grootvader-vader-zoon (GFS) betekenen dat u dagelijkse, wekelijkse, maandelijkse en jaarlijkse momentopnamen kunt maken, elk met een eigen afzonderlijke bewaarperiode. Azure Backup coördineert ook de inschakeling van soft delete en neemt een verwijderingsvergrendeling op een opslagaccount zodra een bestandsshare binnen het account is geconfigureerd voor back-up. Azure Backup biedt bepaalde belangrijke bewakings- en waarschuwingsmogelijkheden waarmee klanten een geconsolideerde weergave van hun back-upomgeving kunnen hebben.

U kunt zowel herstelbewerkingen op item- als shareniveau uitvoeren in de Azure-portal met behulp van Azure Backup. Kies het herstelpunt (een specifieke snapshot), het betreffende bestand of de map indien relevant, en vervolgens de locatie (origineel of alternatief) waar je naartoe wilt herstellen. De back-upservice verwerkt het kopiëren van de momentopnamegegevens en toont uw herstelvoortgang in de portal.

Azure Files beveiligen met Microsoft Defender voor Opslag

Microsoft Defender voor Storage is een Azure systeemeigen beveiligingsinformatielaag waarmee potentiële bedreigingen voor uw opslagaccounts worden gedetecteerd. Het biedt uitgebreide beveiliging door de telemetrie van het gegevensvlak en het besturingsvlak te analyseren die zijn gegenereerd door Azure Files. Het maakt gebruik van geavanceerde mogelijkheden voor bedreigingsdetectie, mogelijk gemaakt door Microsoft Bedreigingsinformatie om contextuele beveiligingswaarschuwingen te bieden, waaronder stappen om de gedetecteerde bedreigingen te beperken en toekomstige aanvallen te voorkomen.

Defender voor Storage analyseert continu de telemetriestroom die door Azure Files wordt gegenereerd. Wanneer mogelijk schadelijke activiteiten worden gedetecteerd, worden beveiligingswaarschuwingen gegenereerd. Deze waarschuwingen worden weergegeven in Microsoft Defender voor Cloud, samen met de details van de verdachte activiteit, onderzoeksstappen, herstelacties en beveiligingsaanbeveling.

Defender voor Storage detecteert bekende malware, zoals ransomware, virussen, spyware en andere malware die is geüpload naar een opslagaccount op basis van volledige bestands-hash (alleen ondersteund voor REST API). Dit helpt voorkomen dat malware de organisatie binnenkomt en zich verspreidt naar meer gebruikers en resources. Zie Inzicht in de verschillen tussen malwarescans en hashreputatieanalyse.

Defender voor Storage heeft geen toegang tot de gegevens van het opslagaccount en heeft geen invloed op de prestaties. U kunt Microsoft Defender voor Storage inschakelen op abonnementsniveau (aanbevolen) of op hulpbronniveau.

Opslagniveaus

Azure Files biedt twee medialagen van opslag: SSD (solid-state disk) en harde schijf (HDD). Met deze lagen kunt u uw shares aanpassen aan de prestatie- en prijsvereisten van uw scenario:

• SSD (premium): SSD-bestandsshares bieden consistente hoge prestaties en lage latentie, binnen milliseconden met één cijfer voor de meeste I/O-bewerkingen, voor I/O-intensieve workloads. SSD-bestandsshares zijn geschikt voor een groot aantal workloads, zoals databases, websitehosting en ontwikkelomgevingen.

  U kunt SSD-bestandsshares gebruiken met zowel de SMB- als NFS-protocollen. SSD-bestandsshares zijn beschikbaar in de geprovisioneerde v2 en geprovisioneerde v1 factureringsmodellen. SSD-bestandsshares bieden een SLA met een hogere beschikbaarheid dan HDD-bestandsshares.

• HDD (standaard): HDD-bestandsshares bieden een rendabele opslagoptie voor bestandsshares voor algemeen gebruik. HDD-bestandsdeling is beschikbaar met de voorzien v2 en betalen-naar-gebruik-factureringsmodellen, hoewel we het voorzien v2-model aanbevelen voor nieuwe implementaties van bestandsdeling. Zie de pagina Azure SLA voor onlineservices voor informatie over de SLA.

Wanneer u een medialaag voor uw workload selecteert, moet u rekening houden met uw prestatie- en gebruiksvereisten. Als voor uw workload latentie van één cijfer is vereist of als u on-premises SSD-opslagmedia gebruikt, zijn SSD-bestandsshares waarschijnlijk het meest geschikt. Als lage latentie niet zo belangrijk is, zijn HDD-bestandsshares mogelijk beter geschikt vanuit kostenperspectief. Lage latentie is bijvoorbeeld minder zorgwekkend bij teamshares die on-premises zijn gekoppeld vanuit Azure of opgeslagen in de cache op locatie via Azure File Sync.

Nadat u een bestandsshare in een opslagaccount hebt gemaakt, kunt u deze niet rechtstreeks verplaatsen naar een andere medialaag. Als u bijvoorbeeld een HDD-bestandsshare naar de SSD-medialaag wilt verplaatsen, moet u een nieuwe SSD-bestandsshare maken en de gegevens van de oorspronkelijke share naar de nieuwe bestandsshare kopiëren.

Meer informatie over de ssd- en HDD-medialagen vindt u in Onderstand Azure Files factureringsmodellen en Onderstand en optimaliseren Azure prestaties van bestandsshares.

Redundantie

Om te helpen de gegevens in uw Azure bestandsshares te beschermen tegen gegevensverlies of beschadiging, slaat Azure Files meerdere kopieën van elk bestand op op het moment dat ze worden geschreven. Afhankelijk van uw vereisten kunt u de mate van redundantie selecteren. Azure Files ondersteunt momenteel de volgende opties voor gegevensredundantie:

• Lokaal redundante opslag (LRS): Met lokale redundantie wordt elk bestand drie keer opgeslagen in een Azure-opslagcluster. Deze aanpak helpt u te beschermen tegen gegevensverlies als gevolg van hardwarefouten, zoals een ongeldig schijfstation. Als er echter een noodgeval optreedt, zoals brand of overstromingen in het datacenter, kunnen alle replica's van een opslagaccount dat gebruikmaakt van LRS verloren gaan of onherstelbaar zijn.

• Zone-redundante opslag (ZRS): Met zoneredundantie worden drie kopieën van elk bestand opgeslagen. Deze kopieën worden echter fysiek geïsoleerd in drie afzonderlijke opslagclusters in Azure beschikbaarheidszones. Beschikbaarheidszones zijn unieke fysieke locaties in een Azure regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke stroomvoorziening, koeling en netwerken. Een schrijfbewerking naar de opslag wordt pas geaccepteerd wanneer deze is uitgevoerd naar opslagclusters in alle drie de beschikbaarheidszones.

• Geografisch redundante opslag (GRS): Met georedundantie hebt u een primaire regio en een secundaire regio. Bestanden worden drie keer opgeslagen in een Azure opslagcluster in de primaire regio. Schrijfbewerkingen worden asynchroon gerepliceerd naar een Microsoft gedefinieerde secundaire regio.

  Georedundantie biedt zes kopieën van uw gegevens verspreid over de twee Azure regio's. Als er een grote ramp optreedt, zoals het permanente verlies van een Azure regio vanwege een natuurramp of een andere soortgelijke gebeurtenis, Microsoft een failover uitvoert. In dit geval wordt de secundaire server de primaire en vervult alle taken.

  Omdat de replicatie tussen de primaire en secundaire regio's asynchroon is, gaan gegevens die nog niet zijn gerepliceerd naar de secundaire regio verloren als er een grote noodgeval optreedt. U kunt ook een handmatige failover uitvoeren van een geografisch redundante opslagaccount.

• Geografisch zone-redundante opslag (GZRS):met redundantie op geo-zone worden bestanden drie keer opgeslagen in drie afzonderlijke opslagclusters in de primaire regio. Alle schrijfbewerkingen worden vervolgens asynchroon gerepliceerd naar een Microsoft gedefinieerde secundaire regio. Het failoverproces voor geozoneredundantie werkt hetzelfde als voor geo-redundantie.

HDD-bestandsshares ondersteunen alle vier de redundantietypen. SSD-bestandsshares ondersteunen alleen LRS en ZRS.

Opslagaccounts voor betalen per gebruik bieden twee andere redundantieopties die Azure Files niet ondersteunen: geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslag met leestoegang (RA-GZRS). U kunt Azure bestandsshares inrichten in opslagaccounts met deze opties ingesteld, maar Azure Files biedt geen ondersteuning voor lezen vanuit de secundaire regio. Azure bestandsshares die zijn geïmplementeerd in RA-GRS of RA-GZRS opslagaccounts, worden respectievelijk gefactureerd als geografisch redundant of geografisch zone-redundant.

Zie Azure Files gegevensredundantie voor meer informatie over redundantie.

Beschikbaarheid van zoneredundante SSD-bestandsshares

Zoneredundante SSD-bestandsshares zijn beschikbaar voor een deelverzameling van Azure-regio’s.

Herstel na noodgevallen en overgangsfalen

In het geval van een niet-geplande regionale servicestoring moet u een noodherstelplan (DR) hebben voor uw Azure bestandsshares. Zie Noodherstel en failover voor Azure Files voor meer informatie over de concepten en processen die betrokken zijn bij failover van noodherstel- en opslagaccounts.

Migratie

In veel gevallen maakt u geen netto nieuwe bestandsshare voor uw organisatie, maar migreert u in plaats daarvan een bestaande bestandsshare vanaf een on-premises bestandsserver of NAS-apparaat naar Azure Files. Het kiezen van de juiste migratiestrategie en het juiste hulpprogramma is belangrijk voor het succes van uw migratie.

Zie voor SMB-migraties een overzicht van SMB-migraties met een tabel die u naar migratiehandleidingen leidt die waarschijnlijk betrekking hebben op uw scenario.

Raadpleeg Migreren naar NFS Azure-bestandsshares voor NFS-migraties.

Volgende stappen

• Plan voor een Azure File Sync-implementatie
• Azure Files implementeren
• Azure File Sync implementeren