Delen via


Best practices voor SMB-prestaties voor Azure NetApp Files

Dit artikel helpt u inzicht te hebben in de prestaties en aanbevolen procedures voor SMB voor Azure NetApp Files.

SMB Multikanaal

SMB Meerdere kanalen is standaard ingeschakeld in SMB-shares. Alle SMB-shares die vooraf uitgaan van bestaande SMB-volumes hebben de functie ingeschakeld; alle nieuw gemaakte volumes hebben ook de functie ingeschakeld op het moment van maken.

Elke SMB-verbinding die tot stand is gebracht voordat de functie wordt ingeschakeld, moet opnieuw worden ingesteld om te profiteren van de SMB-functionaliteit voor meerdere kanalen. Als u het opnieuw wilt instellen, kunt u de verbinding met de SMB-share verbreken en opnieuw verbinden.

Windows ondersteunt SMB meerdere kanalen sinds Windows 2012 om de beste prestaties mogelijk te maken. Zie SMB meerdere kanalen en de basisprincipes van SMB meerdere kanalen implementeren voor meer informatie.

Voordelen van SMB meerdere kanalen

Met de functie SMB meerdere kanalen kan een SMB3-client een groep verbindingen tot stand brengen via één netwerkinterfacekaart (NIC) of meerdere NIC's en deze gebruiken om aanvragen voor één SMB-sessie te verzenden. SMB1 en SMB2 vereisen daarentegen dat de client één verbinding tot stand brengt en al het SMB-verkeer voor een bepaalde sessie via die verbinding verzendt. Deze enkele verbinding beperkt de algehele protocolprestaties die kunnen worden bereikt vanaf één client.

Prestaties voor SMB meerdere kanalen

In de volgende tests en grafieken ziet u de kracht van SMB Meerdere kanalen voor workloads met één exemplaar.

Willekeurige I/O

Met SMB Multichannel uitgeschakeld op de client werden pure 4 KiB-lees- en schrijftests uitgevoerd met fio en een 40 GiB-werkset. De SMB-share is tussen elke test losgekoppeld, met stappen van het aantal SMB-clientverbindingen per RSS-netwerkinterface-instellingen van 1,4 en set-SmbClientConfiguration -ConnectionCountPerRSSNetworkInterface <count>816. De tests tonen aan dat de standaardinstelling 4 voldoende is voor I/O-intensieve werkbelastingen. 8 16 Dit heeft een verwaarloosbaar effect.

De opdracht netstat -na | findstr 445 heeft aangetoond dat er extra verbindingen tot stand zijn gebracht met stappen van 1 , 4 naar 48en 8 naar 16. Tijdens elke test zijn er vier CPU-kernen volledig gebruikt voor SMB, zoals bevestigd door de perfmonstatistiek Per Processor Network Activity Cycles (niet opgenomen in dit artikel.)

Grafiek met een willekeurige I/O-vergelijking van SMB meerdere kanalen.

De virtuele Azure-machine (VM) heeft geen invloed op de I/O-limieten voor SMB-opslag (noch NFS). Zoals wordt weergegeven in de volgende grafiek, heeft het exemplaartype D32ds een beperkte snelheid van 308.000 voor IOPS voor in de cache opgeslagen opslag en 51.200 voor IOPS voor niet-cacheopslag. In de bovenstaande grafiek ziet u echter aanzienlijk meer I/O via SMB.

Grafiek met een willekeurige I/O-vergelijkingstest.

Sequentiële I/O

Tests die vergelijkbaar zijn met de eerder beschreven willekeurige I/O-tests zijn uitgevoerd met 64-KiB-sequentiële I/O. Hoewel de toename van het aantal clientverbindingen per RSS-netwerkinterface buiten vier geen merkbaar effect had op willekeurige I/O, geldt hetzelfde niet voor sequentiële I/O. Zoals in de volgende grafiek wordt weergegeven, wordt elke toename gekoppeld aan een overeenkomstige toename van de leesdoorvoer. Schrijfdoorvoer bleef vlak vanwege netwerkbandbreedtebeperkingen die door Azure worden geplaatst voor elk exemplaartype en elke grootte.

Grafiek waarin de vergelijking van de doorvoertest wordt weergegeven.

Azure plaatst netwerksnelheidslimieten voor elk VM-type en elke grootte. De frequentielimiet wordt alleen opgelegd aan uitgaand verkeer. Het aantal NIC's dat aanwezig is op een virtuele machine heeft geen invloed op de totale hoeveelheid bandbreedte die beschikbaar is voor de machine. Het exemplaartype D32ds heeft bijvoorbeeld een netwerklimiet van 16.000 Mbps (2000 MiB/s). Zoals in de bovenstaande sequentiële grafiek wordt weergegeven, is de limiet van invloed op het uitgaande verkeer (schrijfbewerkingen) maar niet op leesbewerkingen met meerdere kanalen.

Grafiek met een sequentiële I/O-vergelijkingstest.

SMB-ondertekening

Het SMB-protocol biedt de basis voor het delen van bestanden en afdrukken en andere netwerkbewerkingen, zoals extern Windows-beheer. Om man-in-the-middle-aanvallen te voorkomen die SMB-pakketten in transit wijzigen, ondersteunt het SMB-protocol de digitale ondertekening van SMB-pakketten.

SMB-ondertekening wordt ondersteund voor alle SMB-protocolversies die worden ondersteund door Azure NetApp Files.

Invloed van de prestaties van SMB-ondertekening

SMB-ondertekening heeft een verwijderbaar effect op SMB-prestaties. Naast andere mogelijke oorzaken van de prestatievermindering verbruikt de digitale ondertekening van elk pakket extra CPU aan de clientzijde, zoals hieronder wordt weergegeven in de uitvoer van de prestatie. In dit geval wordt Core 0 verantwoordelijk weergegeven voor SMB, inclusief SMB-ondertekening. Een vergelijking met de niet-meerdere kanalen sequentiële leesdoorvoernummers in de vorige sectie laat zien dat SMB-ondertekening de totale doorvoer vermindert van 875MiB/s tot ongeveer 250MiB/s.

Grafiek met invloed op de prestaties van SMB-ondertekening.

Prestaties voor één exemplaar met een gegevensset van 1 TB

Om gedetailleerder inzicht te krijgen in workloads met lees-/schrijfmixen, tonen de volgende twee grafieken de prestaties van één cloudvolume op ultraserviceniveau van 50 TB met een gegevensset van 1 TB en met SMB meerdere kanalen van 4. Er werd een optimale IODepth van 16 gebruikt; Er zijn flexibele I/O-parameters (FIO) gebruikt om het volledige gebruik van de netwerkbandbreedte (numjobs=16) te garanderen.

In de volgende grafiek ziet u de resultaten voor 4k willekeurige I/O, met één VM-exemplaar en een combinatie van lees-/schrijfbewerkingen met intervallen van 10%:

Grafiek met windows 2019-standaard _D32ds_v4 4K willekeurige IO-test.

In de volgende grafiek ziet u de resultaten voor sequentiële I/O:

Grafiek met Windows 2019-standaard _D32ds_v4 64.000 sequentiële doorvoer.

Prestaties bij het uitschalen met 5 VM's met een gegevensset van 1 TB

Deze tests met vijf VM's gebruiken dezelfde testomgeving als de enkele VM, waarbij elk proces naar een eigen bestand wordt geschreven.

In de volgende grafiek ziet u de resultaten voor willekeurige I/O:

Grafiek met windows 2019-standaard _D32ds_v4 randio IO-test met 4K 5-exemplaren.

In de volgende grafiek ziet u de resultaten voor sequentiële I/O:

Grafiek met windows 2019-standaard _D32ds_v4 64K 5-exemplaar sequentiële doorvoer.

Hyper-V-ethernetadapters bewaken

Eén strategie die wordt gebruikt bij het testen met FIO, is om in te stellen numjobs=16. Als u dit doet, wordt elke taak in 16 specifieke exemplaren gesplitst om de Microsoft Hyper-V-netwerkadapter te maximaliseren.

U kunt controleren op activiteit op elk van de adapters in Windows Performance Monitor door Prestatiemeter prestatiemeter toevoegen > netwerkinterface > Microsoft Hyper-V-netwerkadapter te selecteren.>

Schermopname van de interface Prestatiemeter Teller toevoegen.

Nadat u gegevensverkeer in uw volumes hebt uitgevoerd, kunt u uw adapters bewaken in Windows Performance Monitor. Als u niet al deze 16 virtuele adapters gebruikt, hebt u mogelijk geen maximale netwerkbandbreedtecapaciteit.

Schermopname van de uitvoer van De prestatiemeter.

SMB-versleuteling

Deze sectie helpt u inzicht te hebben in SMB-versleuteling (SMB 3.0 en SMB 3.1.1)

SMB-versleuteling biedt end-to-end-versleuteling van SMB-gegevens en beschermt gegevens tegen het afluisteren van exemplaren op niet-vertrouwde netwerken. SMB-versleuteling wordt ondersteund in SMB 3.0 en hoger.

Wanneer een aanvraag naar de opslag wordt verzonden, versleutelt de client de aanvraag, die vervolgens door de opslag wordt ontsleuteld. Reacties worden op dezelfde manier versleuteld door de server en ontsleuteld door de client.

Windows 10, Windows 2012 en latere versies ondersteunen SMB-versleuteling.

SMB-versleuteling en Azure NetApp Files

SMB-versleuteling is ingeschakeld op shareniveau voor Azure NetApp Files. SMB 3.0 maakt gebruik van het AES-CCM-algoritme, terwijl SMB 3.1.1 gebruikmaakt van het AES-GCM-algoritme.

SMB-versleuteling is niet vereist. Als zodanig is het alleen ingeschakeld voor een bepaalde share als de gebruiker vraagt dat Azure NetApp Files deze inschakelt. Azure NetApp Files-shares worden nooit blootgesteld aan internet. Ze zijn alleen toegankelijk vanuit een bepaald VNet, via VPN of expressroute, zodat Azure NetApp Files-shares inherent veilig zijn. De keuze om SMB-versleuteling in te schakelen, is volledig aan de gebruiker. Houd rekening met de verwachte prestatiestraf voordat u deze functie inschakelt.

Impact van SMB-versleuteling op clientworkloads

Hoewel SMB-versleuteling invloed heeft op zowel de client (CPU-overhead voor het versleutelen en ontsleutelen van berichten) als de opslag (vermindering van de doorvoer), wordt in de volgende tabel alleen de impact op de opslag gemarkeerd. U moet de impact van de versleutelingsprestaties op uw eigen toepassingen testen voordat u workloads in productie implementeert.

I/O-profiel Impact
Workloads lezen en schrijven 10% tot 15%
Metagegevensintensief %5

Versneld netwerken

Voor maximale prestaties is het raadzaam om waar mogelijk versneld netwerken op uw VM's te configureren. Houd de volgende overwegingen in gedachten:

  • Azure Portal maakt versneld netwerken standaard ingeschakeld voor VM's die deze functie ondersteunen. Andere implementatiemethoden, zoals Ansible en vergelijkbare configuratiehulpprogramma's, kunnen echter niet. Als u versneld netwerken niet inschakelt, kunnen de prestaties van een machine worden gekrabbeld.
  • Als versneld netwerken niet is ingeschakeld op de netwerkinterface van een virtuele machine vanwege het gebrek aan ondersteuning voor een exemplaartype of -grootte, blijft deze uitgeschakeld met grotere exemplaartypen. In deze gevallen hebt u handmatige tussenkomst nodig.
  • U hoeft geen versneld netwerken in te stellen voor de NIC's in het toegewezen subnet van Azure NetApp Files. Versneld netwerken is een mogelijkheid die alleen van toepassing is op Azure-VM's. NIC's voor Azure NetApp Files zijn standaard geoptimaliseerd.

Schalen aan de ontvangstzijde

Azure NetApp Files biedt ondersteuning voor schalen aan de ontvangstzijde (RSS).

Als SMB meerdere kanalen is ingeschakeld, brengt een SMB3-client meerdere TCP-verbindingen tot stand met de Azure NetApp Files SMB-server via een netwerkinterfacekaart (NIC) die geschikt is voor één RSS.

Voer de opdracht Get-SmbClientNetworkInterface als volgt uit om te zien of uw Azure VM-NIC's RSS ondersteunen en controleer het veld RSS Capable:

Schermopname van RSS-uitvoer voor Azure VM.

Meerdere NIC's op SMB-clients

U moet niet meerdere NIC's op uw client configureren voor SMB. De SMB-client komt niet overeen met het aantal NIC's dat wordt geretourneerd door de SMB-server. Elk opslagvolume is toegankelijk vanaf één en slechts één opslageindpunt, wat betekent dat er slechts één NIC wordt gebruikt voor een bepaalde SMB-relatie.

Zoals in de onderstaande uitvoer Get-SmbClientNetworkInterace wordt weergegeven, heeft de VIRTUELE machine twee netwerkinterfaces: 15 en 12. Zoals wordt weergegeven onder de volgende opdracht Get-SmbMultichannelConnection, ook al zijn er twee NIC's die geschikt zijn voor RSS, wordt alleen interface 12 gebruikt in verbinding met de SMB-share; interface 15 wordt niet gebruikt.

Schermopname van uitvoer voor NIC's die geschikt zijn voor RSS.

Volgende stappen