Címke archívum: Azure Managed Disk

Azure ultra SSD

Folytatjuk a diszk teljesítmény sorozatot, ezúttal megint egy preview szolgáltatás: Azure ULTRA SSD

Az előző postban már volt szó az Azure Standard SS-ről, de a világ és az Azure gyorsan változik és már itt van a küszöbön az Ultra SSD funkció.

Egyelőre nagyon előzetes formában:

  • előzetes feliratkozás szükséges a funkció használatához (feliratkozás)
  • csak bizonyos régióban lehet kipróbálni (EAST US 2)
  •  csak bizonyos méretű gépekkel (ES/DS v3 VM instances)

Az Ultra SSD teljesen új méretezési és teljesítmény rugalmasságot ad az eddig megszokottakhoz képest. Nem csak a diszk méretezését választhatjuk meg, hanem annak teljesítményét is. Minden szükséges információt ezzel kapcsolatban megtaláltok a dokumentációs oldalon: https://aka.ms/UltraSSDDocs

Teszt környezet:

  •  EAST US 2 régió
  •  Standard D8s v3 (8 vcpus, 32 GB memory)
  •  512 MB-os data disk, 80.000 IOPS, 2000 MB/s értékre konfigurálva

Teszt eredmények:

Storage Performance Report – ultrassd

 

Generated on 28/Oct/2018 at 07:08:36 AM
Performance Tests

 

Name

Path Block size Operation Read / Write Outstanding IO Threads IOPS MB/sec Latency CPU %

Database Server

F:\ 8K Random 70% Read / 30% Write 8 1 96095.94 750.75 0.083 14.23%

Email Server

F:\ 4K Random 60% Read / 40% Write 8 1 102696.33 401.16 0.078 14.62%

Archical FileServer

F:\ 64K Sequential 90% Read / 10% Write 8 1 38843.32 2427.71 0.206 12.84%

Streaming Media Server

F:\ 5120K Random 80% Read / 20% Write 8 1 496.90 2484.50 16.099 12.79%

VDI workload

F:\ 4K Random 20% Read / 80% Write 8 1 122837.69 479.83 0.065 13.14%

 

ScriptVersion: 0.9 | Created By: Darryl van der Peijl – Hyper-V MVP – @DarrylvdPeijl | Feedback: DarrylvanderPeijl@outlook.com

A környezet elkészítéséhez kész JSON templatet pedig az alábbi URL-en érhetitek el: https://aka.ms/UltraSSDTemplate

További jó Azureozást!

Király István

Azure MVPr

Azure Standard SSD

Ebben a posztban egy jelenleg előzetes fázisban lévő szolgáltatásról lesz szó.

Jelenleg több opciónk is van, hogy az Azure Virtual Machine alatt hogyan kezeljük a storage-t:

  • Unamanged disk formájában (nincs fix méret, a használat alapján fizetek, storage account kell hozzá)
  • Managed disk formájában (fix méretek, nincs storage account, helyette van pl.: snapshot stb.)
  • Ezek a diskek lehetnek Preimum (SSD) vagy Standard típusúak (HDD)

Ebbe az állóvízbe köpött bele a Azure Standard SSD ami egy pici állatorvosi ló is, ez eddig megszokottakkal szemben:

  • A Stadard disk-el szemben (HDD) a Standard SSD és a Premium SSD is kap SLA-t. (default: havi 99,9)
  • A Standard SSD ugyan olyan gyors, mint a HDD: 500 IOPS és 60MB/sec throughtput, de jobb latency-vel rendelkezik
  • A Standard SSD természetesen olcsóbb mint a Premium, de más méretekkel is rendlkezik, nincs belőle 32 és 64 GB-os méret

Jelnleg minden lényges információt itt lehet megtalálni erről a diszk típusról.

A bekapcsolása most még PowerShell segítségével lehetséges, de nem is ez az érdekes információ jelneleg, hanem az, hogy milyen telejsítményt lehet kicsikarni belőle és a gyakorlatban hogyan üzemel?

Az előző postban megmutattuk, hogy miért is érdemes használni az Azure Accelereted Networking-et, most készítsünk egy tesztet a Standard SSD-vel is az alábbi beállításokkal:

  1. Sebesség teszt Standard HDD, normál üzemmódban
  2. Sebesség teszt Standard HDD, acceleretaed networking-el
  3. Sebesség teszt Standard SSD, normál üzemmódban
  4. Sebesség teszt standard SSD, accelereted networking-el
  5. Sebesség teszt Premium HDD, normál üzemmódban
  6. Sebesség teszt Premium SSD, accelereted networking-el

Mérési környezet:

  • Standard F4s_v2 (4 vcpus, 8 GB memory)
  • 1 TB managed diszk, Read/Write cache-el, de csak Azure oldalon, OS oldalon nem használunk semmilyen gyorsítótárat!
  • Windows Server 2016
  • A méréshez használt ezsköz: DiskSpeed
  • EAST US 2 régió (nincs még mindenhol Standard SSD!)

Nézzük az eredményeket:

Standard HDD  Operation  Access  Blocks  IOPS  MB/sec  Latency ms  CPU %
Database Server Random 70% Read / 30% Write 8K 520.79 4.07 15.351 1.98%
Email Server Random 60% Read / 40% Write 4K 509.18 1.99 15.710 0.31%
Archical FileServer Sequential 90% Read / 10% Write 64K 489.59 30.60 16.332 0.09%
Streaming Media Server Random 80% Read / 20% Write 5120K 12.57 62.83 636.807 0.05%
VDI workload Random 20% Read / 80% Write 4K 621.68 2.43 12.881 0.16%
Standard HDD + AN  Operation  Access  Blocks  IOPS  MB/sec  Latency ms  CPU %
Database Server Random 70% Read / 30% Write 8K 748.48 5.85 10.685 2.11%
Email Server Random 60% Read / 40% Write 4K 1129.40 4.41 7.079 4.89%
Archical FileServer Sequential 90% Read / 10% Write 64K 527.62 32.98 15.154 0.78%
Streaming Media Server Random 80% Read / 20% Write 5120K 12.53 62.66 637.910 0.10%
VDI workload Random 20% Read / 80% Write 4K 619.42 2.42 12.912 0.22%
Standard SSD  Operation  Access  Blocks  IOPS  MB/sec  Latency ms  CPU %
Database Server Random 70% Read / 30% Write 8K 578.57 4.52 13.821 0.59%
Email Server Random 60% Read / 40% Write 4K 455.13 1.78 18.575 0.36%
Archical FileServer Sequential 90% Read / 10% Write 64K 11713.99 732.12 0.683 5.90%
Streaming Media Server Random 80% Read / 20% Write 5120K 263.51 1317.54 30.773 10.20%
VDI workload Random 20% Read / 80% Write 4K 69716.08 272.33 0.114 12.12%
Standard SSD + AN  Operation  Access  Blocks  IOPS  MB/sec  Latency ms  CPU %
Database Server Random 70% Read / 30% Write 8K 590.46 4.61 13.567 1.29%
Email Server Random 60% Read / 40% Write 4K 622.91 2.43 12.878 0.53%
Archical FileServer Sequential 90% Read / 10% Write 64K 9407.00 587.94 0.850 4.78%
Streaming Media Server Random 80% Read / 20% Write 5120K 303.51 1517.54 26.771 11.56%
VDI workload Random 20% Read / 80% Write 4K 99011.67 386.76 0.076 14.49%
Premium SSD  Operation  Access  Blocks  IOPS  MB/sec  Latency ms  CPU %
Database Server Random 70% Read / 30% Write 8K 4870.83 38.05 1.642 1.51%
Email Server Random 60% Read / 40% Write 4K 3562.22 13.91 2.245 1.00%
Archical FileServer Sequential 90% Read / 10% Write 64K 1016.43 63.53 7.876 0.42%
Streaming Media Server Random 80% Read / 20% Write 5120K 12.76 63.81 627.719 0.10%
VDI workload Random 20% Read / 80% Write 4K 3823.30 14.93 2.092 1.20%
Premium SSD + AN  Operation  Access  Blocks  IOPS  MB/sec  Latency ms  CPU %
Database Server Random 70% Read / 30% Write 8K 8096.80 63.26 0.988 2.40%
Email Server Random 60% Read / 40% Write 4K 6871.66 26.84 1.164 2.08%
Archical FileServer Sequential 90% Read / 10% Write 64K 1017.42 63.59 7.861 0.29%
Streaming Media Server Random 80% Read / 20% Write 5120K 12.77 63.83 627.674 0.12%
VDI workload Random 20% Read / 80% Write 4K 3862.24 15.09 2.071 1.05%

Az Azure Standard SSD megjelenésével, egy olcsóbb, valamivel gyorsabb (jobb elérésű) tárolótípust vehetünk majd igénybe korrekt SLA mellett, a Microsoft által javasolt szcenáriók: Dev+Test, kisebb DB workloadok, Linux alapú webszerverek stb.

További jó Azureozást! 🙂

Király István

Azure MVPr

 

 

 

 

 

 

 

 

Azure Accelerated Networking (AN)

Az Azure Accelerated Networking (AN) 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