Infrastructure as a Service szolgáltatás – Skyblocks series

A felhőt szolgáltató rendszer kiválasztása során elsődleges célom volt, hogy a lehető legkevessebb átalakítást igényelje bármely szolgáltatás igénybevétele, illetve ne kelljen rengeteg új dolgot tanulni egy szimpla tűzfalszabály létrehozásához. Lehet vitatkozni, de a VMware vSphere ESXi a legelterjedtebb virtualizációs megoldás. Ha most egy Proxmox alapú megoldást választok, akkor a be és kiköltözés – és egyéb erre épülő szolgáltatások – is transzformációt igényelnek majd. A „seamless” működés pedig mindig kifizetődik.

Az Infrastructure as a Service szolgáltatás így VMware technológiákra épül, melyek összességében vagy legalább részleteiben több ügyfélnél is szolgálnak:

  • VMware Cloud Director – mint önkiszolgáló portál és a felhő menedzsment-rétege
  • VMware vSphere ESXi és VMware vCenter Server – a háttér biztosítása
  • VMware VSAN – a tároló
  • VMware NSX (aka NSX-T, NSX Data Center) – a hálózat, a tűzfal
  • VMware NSX Advanced Load Balancer – mint load balancer és mint WAF(hamarosan)

A szolgáltatás ügyfél felé néző felülete a Cloud Director tenant portálja. (Alább egy 99999-nek hívott tenant szempontjából mutatom be a szolgáltatást.)

Az IaaS szolgáltatás Virtual DataCenter képében reprezentálódik az ügyfelek – tenant – számára. A Cloud Director tenant portálján az authenikáció után legalább egy ilyen láthatóvá válik. A VDC nem más, mint a vásárolt erőforrások csomagja, ez keretezi a használható szolgáltatásokat, azok mennyiségét.

A fenti képen két VDC látszik, melyek között rögvest látható is a differencia. A 99999 VDC 01 egy normál csomagot mutat, amiben az erőforrások 50%-a garantált. Ez nem jelent mást, hogy a 100Ghz processzor, 1TB RAM és 24 TB tárterületből – utóbbi kivételével – 50% mindenképp dedikált, a másik 50% pedig osztott. Mi, mint szolgáltató természetesen ügyelünk, arra hogy ne legyen szűkében erőforrásnak a háttérrendszer. Az 99999 VDC 02 ezzel szemben egy prémium szint, azaz a 34Ghz processzor, 128GB RAM és 9.8TB tárkapacitás dedikált. Ezt a rendszer fenntartja az tenant számára, akkor is, ha egyébként egyetlen VM sincs bekapcsolva.

Hozzunk létre egy virtuális gépet!

A kívánt VDC-t az alábbi nézetbe jutunk, ami a Virtual Machines oldal. (Alább már látható pár virtuális gép, de érhető.)

Lehetőség van vApp-ba rendezni a virtuális gépeket, azaz pont mint on premises, köztük indítási/leállítási sorrendet lehet beállítani, illetve egységként kezelni.

A virtuális gép létrehozása a „New VM” gomb kiválasztása után magától értetődik. Bekéri a VM kívánt nevét, a tényleges nevét, lehetőséget ad template-ből telepítésre, operációs rendszer kiválasztására, előre definiált méretek alapján történő (CPU és RAM) konfigurációra, diszk(ek) hozzadására és hálózati interfészek beállítására.

Ha mindent beállítottunk amit szerettünk volna, akkor a virtuális gép létrejön és meg is jelenik a listában.

Rá is lehet kattintani, de az Actions menüben majdnem minden lehetőség elérhető.

Mint látható a VM be is van kapcsolva, kérjünk egy konzolt rá.

A bal oldalon látható még pár opció, amelyek mellett nem mennék el szótlanul:

  • Affinity rules: Ha két VM-et mindenképpen azonos hoszton – egymás mellett – vagy éppen két garantáltan különböző hoszton szeretnénk futtatni, akkor ott lehet beállítani.
  • Named disks: Ha közös diszket szeretnénk adni például egy Windows Failover Cluster-nek, akkor olyan diszket(eket) ott kell létrehozni, illeve olyanokat is, amelyeket a VM-ektől függetlenül szeretnénk kezelni.

Hozzunk létre hálózatot!

Egyetlen VM sem ér semmit hálózat nélkül, hozzunk létre egyet. Végtelenül egyszerű, hiszen NSX van mögötte. Ezen a ponton el lehet dönteni, hogy ez az új hálózat csak az egyik VDC-ben – fentebb tárgyaltam – vagy mindegyikben elérhető lesz-e.

Mindkét VDC-ben szeretném használni a hálózatot – azaz bármelyikben létrehozhatok ilyen interfészt, akármelyik VM számára és azonos L2-n lesz – szóval az alsót választom.

Ezek után egy nagyon lényeges kérdés jön: Izolált – azaz kifelé nem hirdetett – hálózat vagy éppen ellenkezőleg, routed hálózat kell-e. Én a routed-et választom.

A nevének megadása után bekapcsolható a dual stack (IPV6 és IPV4) mód, illetve meg kell adni a hálózat átjáróját. Nálam ez megszokás szerint a 254-re végződik /24 esetén.

A következő lépésben egy statikus IP-pool hozható létre, amiből nem DHCP-vel, de dedikáltan oszthatunk ki gépeknek IP-t. Ezt átugrom, mert DHCP lesz.

Hasonlóan a DNS beállításokat is meg tudom tenni a hálózatra vonatkozóan, de én ezt is átugrom. A hálózat azonnal létre is jön.

Kattintsunk is rá egyből és állítsuk be a DHCP-t.

Ezek után minden ami szem s száj ingere konfigurálható.

Alább egy ilyet láthatsz bekonfigolva.

Most hogy van hálózatunk, hozzunk létre egy tűzfalszabályt.

Hozzunk létre tűzfalszabályt!

Minden ami a hálózattal kapcsolatos a VDC szempontjából az a „Networking” főmenüben található. Nézzük sorban a lehetőségeket:

  • Firewall: a tűzfal maga – gateway firewall – amiben szabadon lehet felhasználni saját magunk által létrehozható dinamikus csoportokat – a Security -> Dynamic Groups” alatt, IP-ket.
  • NAT: SNAT/DNAT/NONAT-ot lehet létrehozni és kell is, mert SNAT nélkül egyetlen VM sem lesz képes elérni az internetet.
  • IPsec VPN és L2VPN: Ha on premises szeretnék összekapcsolni a Skyblocks felhőben található környezetet, akkor azt itt lehet megtenni.
  • Load Balancer: AVI Load Balancer – khm NSX Advanced Load Balancer – segítségével önkiszolgáló load balancer hozható létre. Aktív monitor stb. Minden van.
  • Routing: Ha összekapcsoljuk on premises adatközponttal, akkor akár BGP kapcsolat is beállítható a felhő és saját rendszer között.
  • Security: A csoportok létrehozásának helye, amelyeket a szabályokban lehet felhasználni. (Allocation port profile-nál saját alkalmazásokat is fel lehet venni és L4 szabályokban használni)
  • IP Management: Az 99999 által dedikált publikus IP-cím(ek) áttekintése, DNS és DHCP beállítások.

Tegyük fel, hogy van egy VM, aminek az IP-je a 192.168.61.10 és rajta fut egy webszerver. Erről https-en szolgáltatunk és szeretnénk az internet felől elérhetővé tenni.

Az alkalmazások kiválasztásánál 28 oldalnyi elérhető van, de sajátokat is lehet létrehozni és azokat L4 szabályokban használni.

Ezzel lényegében kész is a szabály és már csak egy NAT kell – vagy load balancer – hogy működjön.

Kész!

This image has an empty alt attribute; its file name is image-22-1024x781.png

Hozzunk létre egy load balancert!

Nem kötelező, de vásárolható load balancer is a Skyblocks-ban.

Ahhoz hogy használni tudjuk, először egy pool kell. Aktív monitort is állíthatunk be.

A members menüben fel tudom venni a VM01-et – és a többit ha lenne.

SSL-t is tudnék beállítani hogy aktív monitorban is használja, de kihagyom.

HTTP/HTTPS/L4TCP/L4UDP is van ha kell.

Állítsunk be mentést!

Szintén nem kötelező, de ha a felhőben magában szeretnénk mentést, akkor jó opció. Veeam-et építettem mögé, tehát a Cloud Director felületéről állítható be mentési feladat és minden egyéb. Mentsük le hát VM01-et. Bár a VM nézetből is végrehajtható én most a saját menüben mutatom be.

Job-s menüben létrehozok egy mentést és elnevezem. Megőrzési időt beállítom.

Kiválasztom a menteni kívánt gép(eket).

Ha a VM-ben van VMtools, akkor application aware mentés is konfigurálható, azaz applikáció-konzisztens mentés is készül.

Ütemezem a mentést – modelltől függ, de általában mi mint szolgáltató ütemezzük a mentést.

Értesítést is beállíthatok, hogy tudja mi lesz a mentési feladattal.

Mivel nem akarom most kivárni az estét, ezért elindítom kézzel a mentési feladatot.

Sokat nem kell várni és a mentés le is fut.

A visszaállítási lehetőségek lehetnek:

  • VM szint
  • Disk szint
  • Guest file
  • Application level

Egy másik gépen például ezt a guest file-t mutatom be.

Összefoglaló

Az Skyblocks IaaS szolgáltatásának lehetőségei bőven meghaladják az itt publikálható terjedelmet és lehetőséget. Személy szerint én büszke vagyok a platformra és ezt a visszajelzést kapom az eddigi ügyfelektől is. A további részekben IaaS kapcsán lesz még szó a DRaaS-ről is, amivel bármilyen on premises VMware rendszer esetén képesek vagyunk disaster recovery szolgáltatást nyújtani 30 perces bevezetési folyamat után.