Azure IaaS virtuális gépet ide nekem – de milyet?

Lassan 2 éve megy éles üzemmódban az Azure IaaS (ha jól tudom májusban lesz az), de sokszor olyan mintha már 20 éve lenne. Különösen azért, mert az újdonságak beborítanak, elárasztanak bennünket, a 6 hetes fejlesztési ciklusnak érthetően van egy ilyesfajta mellékhatása.

Éppen ezért időnként nem árt egy kis vérfrissítés, nézzük meg tehát rövid leírások illetve sok pepecselésselt elkészített táblázatok formájában, hogy jelenleg milyen sorozatú – és így milyen teljesítményű, kapacitású – virtuális gépeket választhatunk.

Tehát jelenleg 4 fő sorozatból áll az Azure IaaS géppark:

– “A” sorozat: Az átlagos gépek, a legtöbb felhasználó számára
– “D” sorozat: A gyorsítótárak királya
– “DS” sorozat: SSD gyorsítótárral az OS és az adatlemezek tekintetében
– “G” sorozat: A Godzilla típus, full extra

A száraz részletek előtt pár útbaigazító magyarázat:

– Egy Azure virtuális gép esetén minden erőforrás a géphez van rendelve, pl. egy logikai processzor esetén nincs time-sharing, vagy bármi más, közös használatra utaló megoldás.

– Nincs dinamikus memória, mint a Hyper-V-nél, minden gép fix memóriát kap, annyit, amennyit megjelölünk. Ennek előnye, hogy minden VM NUMA-val konfigurált, azaz képes kihasználni a NUMA előnyeit (pontosabban a NUMA érzékeny guest alkalmazások képesek erre), így a CPU és a RAM között a legjobb hozzárendelés érhető el.

– Az IOPS minden sorozatnál garantált az adatlemezek esetén (sorozattól függő a mértéke persze), azaz a Hyper-V-ben is egy ideje használható Storage QoS működik (vagy hasonló, ez elsősorban az én feltételezésem, nem teljesen kideríthető).

– Árakat direkt nem írok, mert ez nem az a blog :), másrészt regiónként és valutatípusonként is eltérőek lehetnek.

Az “A” sorozat

Ez a normál, legrégebbi típus. Nincs sok extra, van viszont sokféle gép, és olcsó. Sőt, egy ideje két ágra szakadt, a különbség egyszerűen definiálható:

– Basic: 300 IOPS adatlemezenként, nincs load-balancing (sem internal, sem external) és autoscale (de azért egy Availability Set-be rakható!), viszont átlagban 27%-kal olcsóbb mint az eredeti Standard

Azure-Basic-A-Series-VMs

– Standard: 500 IOPS, és minden fenti hiányzó képesség rendelkezésre áll. És ha jól megnézzül, azért itt is van egy hármas tagozódás, amit ezért 3 különböző színnel jelöltem ezeket. A nagy hálózati igényre kialakított A8/A9 igazi csemege 🙂

Azure-Standard-A-Series-VMs

A “D” sorozat

Viszonylag új sorozat, ami 2 extrával is bír, sokkal jobb CPU-ja van (kb. 60% az “A” sorozathoz képest), illetve az ideiglenes lemeze SSD, ergo az ide helyezhető, tipikusan nem maradandó fájlok (pagefile, SQL temp db), ultra gyorsak lesznek.

Azure-Standard-DS-Series-VMs

A “DS” sorozat

A Premium Storage bemutatkozó sorozata, minden adatlemez SSD! Megosztott, ezért kis mérettel indul, viszont akár 50000 IOPS és 512 MB/sec átviteli sebesség is elérhető így, ami igen szép eredmény., illetve nem-nem, ez nagyon durván szép eredmény!

Azure-Standard-DS-Series-VMs

A “G” sorozat

Nem véletlenül Godzilla a kódneve a tavaly novemberben, a barcelonai TechEd-en bemutatkozott sorozatnak. Ha pl. komplett SQL 2014 adatbázisokat akarunk a RAM-ban tartani, vagy tényleg durván nagy számításigényű gépekre van szükség (pl. HDInsight, Hadoop), akkor ez a mi terepünk.

A DS-hez hasonlóan itt is SSD fókusz van, de jóval több RAM-mal, és persze még újabb CPU-kal (Intel E5 v3). Ezek a virtuális gépek a legnagyobbak jelenleg, amit publikus felhőben (Azure, AWS, Google) megvehet az emberfia.

Azure-Standard-G-Series-VMs

A szokásos záró szlogen: minden sorozathoz, VM típushoz, mutatóhoz tegyük hozzá fejben a jelenleg szót 🙂

Gál Tamás

Reklámok

Az új Windows Server-ben…

… már Azure-ban is lehet a cluster-nél a quorum, úgy hívják Cloud Witness Disk. Teljes mértékben helyettesíti a Disk/File Share witness disk-et, és gyakorlatilag csak internet elérés egy Azure Storage fiók kell hozzá, semmi más.

Telephelyi clustereknél, vagy egy szabályos multisite cluster-nél a harmadik site-on elhelyezett file share witness-t például kiválóan tudja majd helyettesíteni, ami nyilván komoly anyagi megtakarítást is jelenthet. Én azért egy kicsit remélem, hogy idővel visszafelé is sikerül majd implementálni ezt a lehetőséget, azaz pl. egy Windows Server 2012 R2 failover cluster alá.

clustercloudwittness

image

image

Gál Tamás

Azure Files – beindítva

Sokat beszélünk egy új Azure tárolási képességről, a jelenleg még preview állapotban lévő Azure Files-ról (alulról a második). Az Azure Files a Blobs/Tables/Queues szentháromságot kicsit felborító, az IaaS-hoz közelebb álló tárolási megoldás, ami SMB alapú (egyelőre 2.1), és VM független fájlszerver elérést jelent – csak úgy mint egy helyi rendszerben.

Vagyis inkább mégsem, hanem úgy képzeljük inkább el mint egy SMB hozzáféréssel is rendelkező storage-ot (pl. a NetApp-ok, akár SMB3-mal is már), hiszen nem valamelyik gépünk megosztásáról van szó, hanem direkt tároló eléréséről.

A kialakításhoz szükségesek a következőek:

– Egy új Storage Account, a neve és 1 access key

– Egy újabb Azure Powershell (célszerű a legfrissebbet felrakni, a lenti linkeken elérhető)

– Egy Azure VM a teszthez

 

Powershell manőverek

– Be kell importálni a szokásos módon az előfizetést PS-be

– Be kell rakni az új storage típust egy változóba

– Létre kell hozni a megosztást és a mappá(kat)

 

Ezután a VM-ről már a net use-zal (ha huzamosabb ideig használjuk), vagy csak simán betallózva érjük el az új fájlszerverünket.

 

Íme a bizonyítékok, arra, hogy mivel töltöm a szombat délutánt 🙂

af01

A negyedik tárolótípus

af02

Itt már kész van, mappát hozok létre, feltöltök és listázok

af03

Egy Azure VM-ből (helyi rendszerből nem is megy!) már így érem el

 

A forrásaim a következőek:

http://robertsmit.wordpress.com/2014/06/16/microsoft-azure-file-server-system-error64-or-new-azurestorageshare-cannot-bind-parameter-context-azure-cloud-mvpbuzz/

http://blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/introducing-microsoft-azure-file-service.aspx

Ámen.

Gál Tamás

ASR SAN replikációval is

A szinte csak most véglegesített* (GA, General Availability) Azure Site Recovery (ASR, szervezett illetve teljes replikáció Azure<>Hyper-V és VMWare<>VMWare között) hamarosan kibővül a SAN replikáció integrációval.

Ez azt jelenti, hogy a helyi és a felhő közötti Disaster Recovery forgatókönyvekben szerepet kaphat a szinkron és aszinkron storage replikáció is. Az EMC, a NetApp, a HP 3PAR, és mások is egymás után frissítik emiatt a kvázi szabványként használt SMI-S providereiket, azért hogy az ASR-rel és a System Center Virtual Machine Manager komponensekkel kompatibilisek legyenek. Alakul szépen az ASR sztori, és még nincs vége, gondoljunk az InMage adta lehetőségekre, amelyek közül még alig használhatunk valamit, de ez ugye szintén változni fog 🙂

További, részletesebb olvasnivaló a témában.

*Jó marketingesként hadd jegyezzem meg, hogy a GA-tól függetlenül még Preview árakon lehet használni november 30-ig 🙂

Gál Tamás

Azure Operational Insights

A mai nap kissé produktívra sikeredett (3. WS03 EOS webinár befejezése*, Channel 9 regisztráció és videó, és még sok-sok minden más, ami nem ide tartozik :)), de a végére jutott egy kis plusz Azure is, méghozzá a TechEd-en bejelentett Azure Operational Insights bekötése egyelőre 2 darab szerverre.

Nem volt túl bonyolult, regelni kellett a Preview-ra, készíteni egy workspace-t, egy monitoring agent telepítés ment az Azure-ban lévő VM-re meg egy a lokálisra, kis konfigurálás itt és ott, felvettem pár Intelligence Pack-ot és most várom, hogy beinduljon. Egyelőre direktben, de majd egy SCOM Mgmt group-pal is letesztelem (van itthon is :D).

Jól néz ki, egészen látványos és logikus, tetszik, majd ha lesz benne adat, rakok fel képeket, de egyelőre csak a frissített MMA-t, ami már nemcsak a SCOM-hoz passzol.

MMA

Gál Tamás

* Jövő hét csütörtökön lesz publikálva

Azure új portál meglepi

Esküszöm, ártatlan vagyok.

Én csak végigkattingattam egy gusztusos varázslót az új portálon (egyelőre még preview), aztán leültem vacsorázni, majd megnéztem egy Downton Abbey részt, és közben, kicsit több mint 2 óra alatt lett az Azure-ban egy 9 virtuális gépes (DC+SQL+SPS gépek), magas rendelkezésre állású, full redundáns Sharepoint farmom hálózattal, DNS szerverekkel, cloud service-ekkel és domain nevekkel.

Ennyi történt. Mást nem tettem, esküszöm ártatlan vagyok 🙂

image

 

* Persze ezt helyi környezetben, Hyper-V-vel, Failover Cluster-rel, SCVMM-mel és Azure Pack-kal is meg tudom csinálni, na de 2 óra alatt a nulláról?

Gál Tamás