Mit jelent a V7 és miért fontos ez nekem?

Az Azureban verziószámozzák a virtuális gépek típusait, hogy pontosan tudjuk mikori kiadású VM-el van dolgunk (v2,v3,v4,v5,v6 és v7 típusú gépek érhetők el jelenleg, de ez régiónként változhat!)

Minél magasabb verziószámú gépet használok annál jobb „vas” van alatta, nem csak a CPU adatokat érdemes nézni, hanem a disk IOPS, a memória sebességét, a hálózati kártya konfigurációját, vagy éppen a videókártya típusát is! (ha van benne)

Hogyan árazódnak a virtuális gépek valójában?

Azt is gondolhatnánk, hogy ha magasabb a verziószám, akkor biztosan az ár is magasabb, de ez nem minden esetben igaz!

Nézzünk meg néhány példát!

Minden esetben a 3 éves rezervációval hasonlítom össze az árakat, mert a rezerváció úgy is lemondható, vagyis nulla kockázattal használható és az ár is garantált 3 évre!

West Europe

egyik leggyakrabban használt és egyben egyik legrégebbi régió, itt az alábbi VM szériák kaphatók jelenleg:

Intel

• D2s_v3    38.41 USD/hó
• D2s_v4    31.88 USD/hó
• D2s_v5    31.05 USD/hó
• D2s_v6    34.38 USD/hó

AMD

• D2as_v4 38.41 USD/hó
• D2as_v5 28.86 USD/hó
• D2as_v6 30.47 USD/hó
• D2as_v7 30.47 USD/hó

North Europe

Szintén a legrégebbi európai adatközpontok egyike, Magyarországon sokan előszeretettel használják, mert általában picit olcsóbb mint a West Europe régió! személy szerint nem annyira preferálom, mert messzebb van tőlünk (mind km-ben mind ms-ban)

Intel

• D2s_v3    33.75 USD/hó         
• D2s_v4    29.36 USD/hó
• D2s_v5    28.88 USD/hó
• D2s_v6    32.00 USD/hó

AMD

• D2as_v4 29.36 USD/hó
• D2as_v5 26.63 USD/hó
• D2as_v6 28.08 USD/hó
• D2as_v7 28.08 USD/hó

Austira East

Érdekességképpen nézzük meg a jelenleg legközelebb fekvő adatközpontot is!

Intel

• D2s_v3    44.08 USD/hó
• D2s_v4    31.88 USD/hó
• D2s_v5    31.05 USD/hó
• D2s_v6    34.38 USD/hó

AMD

• D2as_v4 28.86 USD/hó
• D2as_v5 28.86 USD/hó
• D2as_v6 30.52 USD/hó

Megj: West Europe, Germany West Central és Austria East általában egy árban van majdnem minden szolgáltatás terén! Nyilván ilyenkor célszerűbb a földrajzilag legközelebbi adatközpontot választani, figyelve rá, hogy ott az adott szolgáltatás elérhető-e? pl.: Austria East esetében sok minden még nem érhető el, figyelni kell erre is!

Nyilván a 4 magos konfigok a fenti árak duplájába kerülnek havonta, a 8 magosok pedig a négyszeresébe stb. (hatványozottan nő az ár).

Jól látható, hogy van olyan eset is, amikor az újabb gépek ténylegesen olcsóbbak, vagy csak nagyon kis %-ban drágábbak, mint a jóval régebbi társaik (ennek egyik oka, hogy v3-as vagy v4-es hardverből már nem tud bővíteni a Microsoft, míg v6 vagy v7-es konfigokat bármikor tud rendelni a gyártóktól.

Mire kell figyelni v6 vagy v7-es gépek használatakor?

Az új konfigurációk már használják az Azure Boost technológiát, így vannak a konfigurációknak sajátosságaik!

Az egyik ilyen a temp diskek kezelése!

Minden olyan azure konfiguráció, mely a nevében tartalmaz „d” jelölést is, pl.: D2ads_v6, tartalmaz egy local temp disket is. (jellemzően ezeket swap-ra vagy SQL Server esetében TempDB tárolására használjuk).

A v6 vagy v7-es gépek esetében ezek a Temp diskek RAW lemezként csatolódnak, külön kell őket inicializálni, formázni stb. minden egyes deallokáció után!

1. ábra: D4ads_v7 VM disk konfiguráció deallokációt követően

A másik fontos változás a hálózati kártyák esetében tapasztalható. Megjelentek az Azure Boost technológiával párhuzamosan az ún MANA adapterek. Itt fontos, hogy figyeljünk a megfelelő driver ellátottságra, mert jelenleg nem minden OS támogatott!

• Linux support
• Windows support

2. ábra: MANA adapter egy v7-es gépben

Milyen hátránya van, ha v6-os vagy v7-es VM méretet használok?

Hátránynak nem nevezhetjük, de jó, ha tudtok róla: Azure Boost gépeket nem lehet visszaméretezni korábbi B, vagy D konfigurációkra! Mi is azt javasoljuk és a Microsoft is, hogy ha tehetjük mindig használjuk a legújabb generációs gépeket, mert a következő években megjelenő új „vasak” is már ezekkel a konfigokkal fognak megjelenni (v8-as vagy v9-es gépek)

Megj: Vannak olyan workloadok amikor teljesen megfelel, ha B (burstable) gépeket használunk! Ár/érték arányban az egyik legjobb konfigurációk! Ezen gépek esetében figyeljünk rá, hogy B_v2-es gépeket használjunk, a korábbi konfigurációknál gyorsabbak és árban is nagyon kedvezőek (nem beszélve arról, hogy a burst crediteket is gyorsabban töltik ezek a gépek, vagyis jobban terhelhetőek!).

3. ábra: V7-es VM már nem méretezhető vissza a korábbi konfigurációkra!

Miért nem tudom átváltani a meglévő v3-v4-v5-ös gépem v6 vagy v7 konfigra?

Gyakran szembesülünk azzal, hogy szeretnénk gép méretet váltani, de sajnos a VM Size menüpontban nem tudom kiválasztani ezeket az új gépeket:

4. ábra: Nem tudok v6 vagy v7-es gépre váltani

Ennek több oka is lehet:

• Fut a VM, le kell állítani és akkor több konfigurációból tudok választani (az ábrán is jelöltük ezt).
• A gép nincs Zónázva
• A gép nem Gen2-es, hanem Gen1-es (Hyper-V) generációjú (nem összekeverendő a gép méret verziózással!)
• A gép még a régi (SCSI) csatolóval rendelkezik és nem az újabb (NVMe) interfésszel

Hogy mi ilyenkor a teendő? Ezzel fogunk foglalkozni a következő blog bejegyzésünkben!

A V7-es Virtuális Gépek az Azureban bejegyzés először HRP Services-én jelent meg.

1. Hogyan fognak küldeni levelet a 3rd party üzleti alkalmazások?
2. Hogyan fogok tudni scan-to-mail-t használni?
3. Kamera/riasztó/szünetmentes hogyan fog küldeni levelet Exchange online-on keresztül?
4. Nem tudok mindenhol OAuth-ot használni, mégis tudok majd levelet küldeni a felhőből?
5. stb.

SMTP levélküldés az Exchange Online-ból

A Microsoft már többször nekiszaladt, hogy megszünteti az ún. Basic Auth-ot az SMTP mailküldés esetében – ezt egyelőre halasztották – most 2027 közepe a végleges dátum. Ettől függetlenül nem mindig tudjuk használni ezt a megoldást, mert:

• A tenant sztintű „Security Defaults” megakadályozza
• Nincs Entra P1 licencünk, így a Security Defaults helyett nem tudunk használni Conditional Access-t, hogy kivételre tehessük a küldőt

Természetesen OAuth segítségével továbbra is használhatjuk az smtp.office365.com címet és küldhetünk is levelet, „csak” a Basic auth nem fog működni.

Jellemzően se az MFP-k se egyéb régi cuccok nem fognak tudni küldeni levelet OAuth-al.

Levélküldési lehetőségek az M365-ben és azon túl

A következő lehetőségeket természetesen kombinálhatjuk is:

Mikor melyik megoldást érdemes használni?

1. Client SMTP submission – ha fontos, hogy külön postafiókban a „Sent Items”-ben akarjuk tárolni a kimenő leveleket. (pl.: további feldolgozás miatt, vagy egyéb levél beolvasás miatt). Hátránya, hogy OAuth kell neki és egy darab Exchange Online licence is.
2. SMTP Relay – Nyomtatókhoz, kamerához, 3rd party alkalmazásokhoz kiváló, figyelni rá, hogy az SMTP server az M365-ös MX rekordod lesz! (pl.: contoso-com.mail.protection.outlook.com). Hátránya, hogy kell neki egy FIX IP cím a telephelyen és az SPF rekordba is vegyük fel ezt az IP-t! (Exchange admin centerben készíteni kell egy vagy több konnektort!)
3. Direct Send – Microsoft terve, hogy ez defaultban ki lesz kapcsolva, csak bentre küld, de magasabbak a limitációi mint a Client SMTP submission-nak!
4. High Volume E-mail – belső nagytömegű e-mailküldés, akár 50 postafiók is létrehozható, nincs licence költsége!
5. Azure Communication Services – külön költsége van, Azureban számolódik el. Jellemzően nagytömegű külső levélküldésre használjuk (Webshop, E-számla stb.)

A SMTP levélküldés a Microsoft felhőből bejegyzés először HRP Services-én jelent meg.

Mi az a BLOB?

Binary Large Object storage – az egyik legrégebbi Azure szolgáltatás, segítségével strukturálatlan adattömeget (fájlok, videók, képek, logok, mentések stb.) tárolhatunk hatékonyan a felhőben. 3 típusa van:

• Block
• Page
• Append

Ebben a bejegyzésben nem részletezem a különbségeket a 3 típus között, legyen most annyi elég, hogy IT üzemeltetési szempontból nekünk a Block Blob a lényeges.

Mi az a Storage Tiering?

Azt jelenti, hogy a felhőben tárolt Block Blobjaimat mindig az aktuális igényeknek megfelelően tárolhatom:

• Elérés sebessége és módja
• Árazás

Típusai:

• Hot
• Cool
• Cold
• Archive
• Smart (erről lesz szó, hamarosan!)

A storage tiering úgy működik, hogy ha nincs szükségem valamilyen adatra sokáig (pl.: logok, régi filmek) akkor „hátra” sorolom másik rétegbe (tier-be). Így olcsóbb lesz a tárolásom, de lassabb vagy éppen költséges az elérésem. Archive rétegbe például akkor érdemes adatokat átmozgatni, ha minimum 180-360 napig biztosan nem fogunk hozzá férni.

Mi az a Storage Lifecycle Manager?

Olyan Azure szolgáltatás („felhős job”) melynek segítségével az automatikus adatmozgatást elvégezhetem valamilyen szabályok szerint, pl.:

ha az adott BLOB-on nem volt se írási olvasási művelet 30 napig, akkor mozgasd át Cool-ba, majd 60 nap után Cold-ba, majd 180 nap után Archive-ba stb.

Figyeljünk rá, hogy az adatmozgatásnak is van díja, hiszen folyamatosan írjuk/olvassuk az adott fájlt, vagyis blob-ot!

Ezen kívül, ha egy rétegbe túl korán mozgatunk át adatokat (pl.: HOT-ból Cool-ba 15 nap után) akkor korai törlési díjat is felszámolnak!

Hogyan működik a Storage Smart Tiering?

Ezzel az új rétegezési megoldással nem kell manuálisan létrehozzunk Storage Lifecycle manager szabályokat, nincs adatmozgatási díj, nincs korai törlési díj, nem kell mindenféle táblázatot böngésznünk!

Nagyon egyszerű a működési modell:

• minden 30 napnál régebbi adat mozog automatikusan Cool rétegbe
• minden 90 napnál régebbi adat mozog automatikusan Cold rétegbe
• minden adat „visszaugrik” HOT rétegbe a hozzáféréskor
• nincs korai törlési díj
• van egy minimális „Monitoring fee” minden olyan BLOB-ra, mely nagyobb mint 128 KiB (minden 10 000 objektumonként 0,04 EUR/hó)

Nézzük az árakat!

A következő feladatot kaptuk az egyik partnertől/ügyféltől:

Van egy Veeam backup szerver, a heti mentés nagysága 15TB, ezt kellene kitolni Azure-ba hetente és megőrizni az adatokat 180 napig! Azt, hogy mennyi BLOB-ot hoz majd létre a szoftver nem tudjuk.

Első kalkuláció Lifecycle Manager használatával

HOT mentés 30 napig: 15 TB – kb 300 EUR/hó és az írási olvasási tranzakciók számát nem ismerjük!

Cool mentés 60 napig: 30 TB – kb 341 EUR/hó

Cold mentés 90 napig: 45 TB – kb 195 EUR/hó

összesen: 90 TB kb. 900 EUR/hó és nem tudjuk, hogy mennyi lesz az írási olvasási tranzakciók száma és költsége sem az első mentéskor, sem később a tiering során! Ez az ismeretlen szám nagyon magas is lehet és nagyon nehéz becsülni! (a költség nem azonnal jelentkezik, hanem fokozatosan növekszik 180 napig, míg be nem áll a végleges állapot)

Smart Tier kalkuláció

Lesz egy ismeretlenem az egyenletben szintén: blobok száma a mentés után. (első alkalommal kiderül, érdemes egy POC keretében kipróbálni!)

Tárolási díj ugyanúgy 90 TB kb. 900 EUR, viszont nem lesz tranzakciós díjam és korai törlési díjam sem + nincs munka a Lifecycle manager beállítással és annak módosításával: minden automatikusan fog történni! (szintén fokozatosan fog nőni a számla, nem azonnali költség!)

A költségek korai megfigyelése sok segítséget adhat a további beállítások helyes kiválasztásában!

Beállítása

Minden zóna redundáns storage account-on bekapcsolható, vagy új storage fiók létrehozásakor is kiválasztható:

1. ábra Storage Smart Tier forrás: https://techcommunity.microsoft.com/blog/azurestorageblog/unlocking-storage-optimizations-smart-tiering-for-blobs-and-adls-in-azure-storag/4469811

Mikor használjunk Smart Tiering-et?

Amikor nem tudjuk pontosan, hogy az Azureba mentett vagy archivált adatokra pontosan mikor van szükségünk, nem határolhatók el az egyes rétegek egzakt módon.

Amikor ad hoc gyorsan és olcsón kell hozzáférni 30, 60, 90 napos adatokhoz.

Mikor ne használjuk? – Amikor valamit archiválni szeretnénk és teljesen biztosak vagyunk benne, hogy több mint 180 napig az adathoz biztosan nem kell hozzáférnünk! ebben az esetben ott van az Archive Tier – szuper olcsón!

A Storage Smart Tiering avagy hogyan tárolhatok több petabájtnyi adatot költséghatékonyan a felhőben? bejegyzés először HRP Services-én jelent meg.

A NAT Gateway egy hálózati címfordítási (NAT) szolgáltatás, ami a belső IP címeket fordítja egy publikus IP-re, lehetővé téve pl. az internet elérését. A NAT szolgáltatáson keresztül NEM érhetők el a belső hálózati erőforrások az internet felől (csak a kimenő csomagokra érkező válaszok engedélyezettek).

Két típusa:

• Standard
• StandardV2

Természetesen a V2-es megoldás az újabb és természetesen „többet tud” mint az előző verzió:

• Zónaredundáns (már nem kell külön meghatározni zónánként)
• IPV6-támogatás
• Nagyobb sávszélesség (100Gb/s a korábbi 50Gb/s helyett)
• Forgalom naplózása

Miért van most aktualitása a NAT GW-nek?

A Microsoft 2026. március 31-től megváltoztatja az alapértelmezett hálózati üzemeltetési módot és nem engedélyezi az implicit Internet hozzáférést (a korábbi erőforrások működnek tovább).

Vagyis a fenti dátumtól, ha létrehozunk egy új hálózatot, akkor az sokkal „szigorúbb lesz” és a benne lévő VM-ek nem kapnak default NATolást az internet felé.

A jövőben az alábbi módokon biztosíthatunk „internetet” az Azure VM-nek:

1. ábra: forrás: https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access?tabs=portal

Hogyan működik a NAT GW?

A NAT GW szolgáltatás létrehozásakor meg kell adnunk, hogy mely hálózatban és azon belül mely alhálózatokban (subnetekben) végezzen címfordítást, természetesen több subnet is megadható, de több VNET nem! (VNET peering megengedett)

2. ábra: NAT GW v2 Zóna támogatással

Használatához válasszuk az Azure portálon a NAT Gateways menüpontot (felső menübe beírni)

3. ábra: NAT GW Standard V2

Ki kell választani, hogy milyen publikus IP címet használjon az átjáró, ez megtörténhet a NAT GW létrehozásakor, vagy korábban is elkészíthetjük a Publikus IP-t külön is!  IPV6 támogatás beállításához Standard V2 Public IP kell!

Standard V2 Public IP

Az új NAT GW megoldáshoz új IP cím típust is bevezettek, de erről túl sok dokumentációt nem lehet találni jelenleg, ami fontos információ, hogy az új NAT GW-hez ezt az új Public IP típust KELL használni.

4. ábra: V2-es Public IP létrehozása

Árak

Ami jó hír, hogy mind a NAT GW-ből, mind az IP-ből nyugodtan választhatjuk az új V2-es verziót, mert az ára ugyan az, mint az előző verziónak! NAT GW esetében az ár két tényezőből rakódik össze:

1. GW ára óránként/havonta
2. Adatforgalmi díj – GW-n átmenő adatforgalom GB-ban

5. ábra: Azure NAT GW és adatforgalom költségek West Europe-ban

6. ábra: Publikus IP árazása West Europe-ban

Előnye

A NAT GW használata sokkal biztonságosabb, mint ha minden VM dedikált Publikus IP-t kapna! A felügylete is jóval egyszerűbb és nincs az a veszély, hogy a VM-ek (vagy egyéb szolgáltatások) közvetlenül Internet felől is megszólíthatóak. (nem kell vesződni az NSG-vel vagy az Azure FW-vel sem!)

Jelen esetben pedig az ügyfél külön kérése volt, hogy akkor mostantól mind az AVD VM-ek, mind az adatbázis szerver azonos IP-ről látszódjon az Internet felé. Bővebb információ és összehasonlítás a NAT GW-ről: https://learn.microsoft.com/en-us/azure/nat-gateway/nat-sku#sku-comparison

A NAT Gateway v2 és a Standard v2 Publikus IP használata bejegyzés először HRP Services-én jelent meg.