Címke archívum: Azure VPS

WordPress tuning Azure CDN-el

Mire jó az Azure CDN?

CDN = Content Delivery Network egy olyan disztribúciós hálózat, mely elsősorban weboldalak és egyéb webes tartalmak (képek, videók, nagytömegű fájl letöltések) terítésére szolgál. Célja, hogy a fogyasztóhoz minél közelebb jutassuk el a “contentet” és a kiszolgálás ne a webszervert terhelje. Ezzel a megoldással minden látogató a földrajzi helyéhez legközelebb eső cache központból kapja meg a webtartalmat, részben vagy egészben.

Miért érdemes használni Azure CDN-t?

Sok CDN szolgáltató található, választék van bőven:

A Microsoft Azure esetében abban a szerencsés helyzetben vagyunk, hogy az Azure előfizetésen belül egyből 3 szolgáltatót is kipróbálhatunk és az igényeink szerint tesztelhetjük. Másik előnye, hogy sok más szolgáltatóval szemben itt nincs hűségidő. Nézzük az Azure választékot:

  • Microsoft
  • Akamai
  • Verizon

Másik nagyon fontos előny, hogy az Azure CDN könnyen és gyorsan integrálható Web Apps-al, a Media Services-el, a Storage-val vagy a Cloud Services-ekkel.

Most mégis egy általános forgatókönyvet szeretnék bemutatni a kingsol.hu példáján keresztül.

Környezet:

Természetesen a saját weboldalunkat is Azure-ben hostoljuk. Jelen esetben nem WebApp-ban, hanem sima Azure VPS formájában, hogy miért így alakult? Csak pár mondatban: az volt a terv, hogy a VM egyéb feladatokat is el fog látni és ezért nem lesz WebApp. Jelenleg több weboldalt is hostolunk itt.

A környezet:

Azure CDN integráció WordPress-el

Első lépésként hozzunk létre egy CDN profilt az Azure portálon:

Azure CDN profile

Majd készítsünk egy új Endpoint-ot:

Név: valami.azureedge.net

Origin type: custom

Origin hostname: weboldaladneve.hu

Origin host header: weboldaladneve.hu

Origin path: üres, nem kell kitölteni

Azure CDN endpoint

Utolsó lépésként pedig adjunk hozzá egy custom domain-t (a mi esetünkben a cdn.kingsol.hu):

Azure CDN custom domain

Az egyedi domain esetében bekapcsoltuk a HTTPS támogatást, ebben az esetben várnunk kell pár órát, míg a tanúsítvány elkészül!

Ha elkészültünk ezzekkel, akkor már csak egy WordPress CDN modulra van szükségünk, mellyel beállíthatjuk, hogy a weboldal tartalom a CDN cache-ből töltődjön majd be.

Az alábbi WordPress modulokkal teszteltünk:

Végül a Swift-et választottuk a sokoldalúsága miatt. A Swift-ben csak kapcsoljuk be a CDN támogatást és írjuk be azt a custom domaint melyet létrehoztunk:

Swift Azure CDN

Már csak arra van szükségünk, hogy várjunk egy picit és leteszteljük az oldal sebességét a Google PageSpeed segítségével!

Konklúzió

Azure CDN segítségével könnyen, gyorsan és költséghatékonyan gyorsíthatjuk a weboldalunkat. Csökkenthetjük a webszerver terhelését. Gyorsabban kiszolgálhatjuk a látogatóinkat, nem szükséges adatközpontonként VPS-t üzemeltetni és ezek között elosztani a forgalmat. Ezzel a megoldással gyorsabbá tehetjük a fájl letöltéseket a videó lejátszásokat stb. Nem mellesleg SEO szempontból is hasznos CDN-t használni.

Jó Azureozást!

Király István

Azure MVPr

Azure ephemeral disk a gyakorlatban

Az Azure ephemeral disk bemutatása

Az Azure ephemeral diszk funkció 2019 májusában jelent meg preview módban, majd 2019 júliusától már végleges fázisban is elérhető. Mint a nevéből is látható nem egy tartós lemezről beszélünk. Ennek oka, hogy ezen OS diszkek nem az Azure Storage-ban tárolódnak, hanem azon hostokon ahol éppen a VM is fut. Több előnye is van a megoldásnak.

Mire jó az Azure ephemeral disk megoldás?

Sok olyan workload előfordul, ahol úgynevezett stateless megoldásra van szükség. Ezekben az esetekben az operációs rendszer diszken semmilyen adatot nem tárolunk. Pl.: webszerver farm, DevOps környezet, VDI vagy RDSH megoldások, media encoding vagy rendelerés stb. Ezekben a megoldásokban az a közös, hogy a gép vagy gépek elvesztése esetén percek alatt tudjunk új környezetet felépíteni és folytatni a munkánkat. Az Azure ephemeral disk pont ezt biztosítja számunkra.

Előnyei

Az alábbi előnyöket tudjuk felsorolni a megoldás mellett: gyors, ingyenes, saját lemezképekkel is használható, támogatja a Shared Image Gallery megoldást is!

Miért gyorsabb, mint a “hagyományos” azure disk? Mert a VM hoston ül, ezrért a VM host SSD-t használja, nincs ISCSI kapcsolat és késleltetés a backen felé.

Miért ingyenes? Mert úgy is ott van, eddig is kihasználatlanul ott “hevert” a szerverekben. (Az Azure temporary diszk területek is jellemzően innen származnak).

Hátrányok

Hátrányként hozható fel, hogy az Ephemeral disk -el szerelt VM nem leállítható (nem deallokálható) vagyis ezzel költséget nem spórolhatunk meg. Ha nincs szükség a VM-re, akkor le kell törölni és lemezképből újra építeni.

Másik “hátránya” is a működéséből adódik: meg kell oldani, hogy minden fontos, perzisztens adat a data diszkre kerüljön, semmi ne tárolódjon az OS lemezen. (viszont korrekt, hogy ugyan úgy kaphat data diszket, többet is természetesen 🙂 )

Fontos, hogy nem minden gépméret támogatott, a legkisebb használható VM size: Standard_DS2_v2.

Ephemeral disk beállítása

Az Azure ephemeral disk kezelhető API, PS, CLI vagy portál segítségével is.

Azure portál esetében, ha megfelelő gépméretet használunk rádiógomb segítségével engedélyezhető a funkció (de csak a gép készítésekor!)

Azure ephemeral disk portal

 

 

 

 

 

 

 

 

 

 

 

 

 

VM Scale Set esetében szintén engedélyezhetjük a GUI-n:

Ephemeral disk scale set

PowerShell esetében pedig:

Set-AzVMOSDisk -DiffDiskSetting Local -Caching ReadOnly

parancsmagot kell használni.

Egyéb működési sajátosságok:

Az Ephemeral diszk-el felszerelt gépek OS lemeze nem támogatja:

  • OS Capture
  • Snapshot
  • Azure Disk Encryption
  • Azure Backup
  • Azure Site Recovery
  • OS Disk Swap

Bővebben ebben a cikkben tájékozódhattok a megoldásról.

Jó Azureozást!

Király István

Azure MVPr

KingSol Zrt.

 

 

Instance size flexibility for Azure Reserved Virtual Machine Instances

Az Azure Reserved Instance azt jelenti, hogy egy bizonyos méretű virtuális gépet megvásárolunk a Microsoft-tól 1 vagy 3 évre, jelentős kedvezménnyel (30-50%) és ezt használjuk. Alkamazható mind Linux, mind Windows-os gépekre, azzal a megkötéssel, hogy a Windows licence árát (illetve más licence-t is) perc alapon továbbra is fizetnünk kell.

Ezt a funkciót bővítették most tovább, hogy nem egy fix méretet kell megvennünk, hanem egy kategóriát foglalunk le és annak x %-át használjuk fel gépenként.

Vagy veszünk “nagy” kapacitást és elhasználjuk sok kis gépre, vagy fordítva, amire éppen szükségünk van!

Az egyes resered kategóriák alkmazkodnak a gépek elnevezéseihez és méretéhez.

Vásárolhatunk “D”, “F”, “G” stb kapacitásokat is:

Ezekről a kategóriákról bővebben itt olvashattok!

Természetesen továbbra is visszaválthatók ez egyes rezervásiók, vagy átcserélhetők más méretre is!

Ami még újdonság, hogy a “foglalást” többféleképpen is elvégezhetjük:

  • Hatókör szerint (Egy vagy több előfizetés) Nem mindenhol alkalmazható, csak: EA
  • Megosztott vagy dedikált (biztosan kérem a foglalást, vagy csak ha rendelkezésre áll)
Azure Reserved Virtual Machine Instances
Azure Reserved Virtual Machine Instances

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