Az Azure Accelerated Networking funkció még 2018 januárjában jelent meg, de az utóbbi fél évben most jutottunk el olyan projektekig, ahol igénybe is vettük.

Összefoglalnám a tapasztalatainkat, hogy mire is jó ez a funkció, mikor érdemes használni és milyen előnyükkel jár pontosan, ha az Azure VM hálózati sebessége drasztikusan megnő.

Az AN SR-IOV-t használ, ebből következően jóval nagyobb hálózati sebesség érhető el, kisebb válaszidővel és kevesebb/alacsonyabb CPU terheléssel.

Az Azure AN pontos felépítése és múködési modelje így néz  ki szemben a “normál” Azure hálózattal:

Comparison

 

A kép forrása és a működés pontos leírása itt.

A mi szempontunkból az a fontos, hogy ez az opció nem minden géptípusnál használható! Elsősorban a CPU intenzív gépekhez lehet bekapcsolni, melyek általában a drágább kategóriába tartoznak. Édemes a D, E, F, M, G típusú gépekkel próbálkozni.

Az Azure AN amúgy külön költséggel nem jár.

Az opció bekapcsolható portálról, ha a megfelelő VM-et választjuk a Marketplace-ből, vagy később, utólag méreteztük fel a gépet, akkor marad a jó öreg PowerShell.

KB így be is tudjuk kapcsolni:

Leállítjuk a gépet:

Stop-AzureRmVM -ResourceGroup “myResourceGroup” `
-Name “myVM”

Kijelöljük a hálókártyát:

$nic = Get-AzureRmNetworkInterface -ResourceGroupName “myResourceGroup” `
-Name “myVMNIC”

bekapcsoljuk az AN-t:

$nic.EnableAcceleratedNetworking = $true

vagy ki is kapcsolhatjuk, ha a gépet kisebbre szeretnénk visszavenni:

$nic.EnableAcceleratedNetworking = $false

véglelegesítjük a konfigot:

$nic | Set-AzureRmNetworkInterface

Elindítjuk a gépet:

Start-AzureRmVM -ResourceGroup “myResourceGroup” `
-Name “myVM”

Ha a gépen be van kapcsolva az AN és át akarjuk mértezni nem AN kompatibilis mértre, akkor hibát fogunk kapni, hogy nem lehetséges a méret váltás.

Miért érdemes Azure Accelereted Networking-et használni?

Elsősorban azért, mert az Azure VM hálózaton keresztül éri el a HDD-t és SSD-t is, vagyis nagymértékben függ a diszk sebesség a hálózati kártya típusától.

Mérjük meg a különbséget!

A tesztgép: Standard F2s (2 vcpus, 4 GB memory) és Windows Server 2016, 64GB SSD.

Azure AN nélkül:

Name Block size Operation Read / Write IOPS MB/sec Latency CPU %
Database Server 8K Random 70% Read / 30% Write 527.16 4,12 15.173 1.15%
Email Server 4K Random 60% Read / 40% Write 508.50 1.99 15.731 0.91%
Archical FileServer 64K Sequential 90% Read / 10% Write 447.09 27.94 17.895 0.78%
Streaming Media Server 5120K Random 80% Read / 20% Write 12,27 61.33 655.243 0.31%
VDI workload 4K Random 20% Read / 80% Write 622.19 2.43 12.856 1.51%
Azure AN-el:
Name Block size Operation Read / Write IOPS MB/sec Latency CPU %
Database Server 8K Random 70% Read / 30% Write 1671.25 13,06 4.786 2.29%
Email Server 4K Random 60% Read / 40% Write 1242.75 4.85 6.436 2.16%
Archical FileServer 64K Sequential 90% Read / 10% Write 1019.70 63.73 7.844 1.54%
Streaming Media Server 5120K Random 80% Read / 20% Write 12.73 63.66 628.250 0.60%
VDI workload 4K Random 20% Read / 80% Write 623.83 2.44 12.822 1.15%

Érdemes megfigyelni, hogy a diszk elérése, a késleltetés mennyire leesett és az IOPS értékek hogy megnőttek az alsó táblázat esetében!

Érdekes, hogy a CPU terhelés nem nagyon változott, sőt nem is csökkent.

Mikor érdemes használni Azure AN-t?

  1. SQL
  2. SAP
  3. Oracle
  4. MySQL
  5. Exchange
  6. SOFS

Ha már most is rendelkezünk a megfelelő konfiggal, vagyis a jelenlegi VM méret ezt megengedi, akkor mindenképp kapcsoljuk be, mert jobb lesz a gép teljesítménye és plusz költséget nem jelent!

Király István

Azure MVPr