A felhőt szolgáltató rendszer kiválasztása során elsődleges célunk volt, hogy a lehető legkevessebb átalakítást tegye szükségessé 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 Proxmox alapú megoldást választunk, akkor a be és kiköltözés – és egyéb erre épülő szolgáltatások – is tranfszormá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.
Szerzőnk:
Neumann Péter
Solution Architect
Legújabb blogjaink:
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ést 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.
- a képen nem látszik, mert a szegmensek menüjében van, de mikroszegmentáció is van, amit az nsx distributed firewall képessége biztosít!
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!
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.
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.
