Nem gondolom, hogy új, ha azt mondom egy VMware Cloud Foundation telepítés két fő területre bomlik, azaz két domain típus létezik:
- management domain
- workload domain
Előbbi tartalmaz mindent, amely a teljes rendszer menedzsmentjéhez szükséges, azaz az SDDC Manager-t, a saját vCenter-ét, a saját NSX Manager/Controller-eit (három van), a saját NSX EDGE-eit (ha AVN-t használunk benne), a vRealize termékeket, na és minden egyebet, amit mi a menedzsmentre gondolunk.
Utóbbi pedig igazából lehet egy környezet – DMZ, belső, teszt – de lehet akár egy alkalmazás – ERP, big data stb – is. Itt minden VCF tervezésnél egyedi a dolog, szóval hogy a workload domain az minek a szinonímája legyen. Később ez fontos lehet, mivel a legelemibb elválasztás az maga a workload domain, azonban van olyan eset amikor ez nincs így.
Management domain
A Management domain, nem kérdés, kötelező. Mindenképpen lesz benne NSX-T, bár a nem használunk AVN-t, akkor csak a Controller-ek kerülnek telepítésre, továbbá minden hosztnak lesz TEP interfésze.
WLD 1 – a teljes izoláció
A “WLD_1” nevű, zöld rész a teljes izoláció. Saját NSX telepítéssel és ennek megfelelően az azt alkotó három NSX Manager/Controller gépekkel, saját vCenter Server-rel rendelkezik, amelyek a “Management domain”-ben futnak. Saját overlay zónája van az NSX terminológia szerint és abban saját EDGE-ekkel is rendelkezik. Ez a WLD, más WLD-vel csak külső eszközön keresztül beszélhet mivel saját T0-ján keresztül lehetséges csak a kapcsolat közte és például egy másik zóna között.
WLD 2 – teljes izoláció kívülre, de bizonyos tekintetben teljes átjárhatóság belül – ha nem beszélünk DFW-ről.
A “WLD_2” nevű kék rész, szintén saját NSX instance-al rendelkezik, saját három NSX Manager/Controller géppel, saját vCenter Server-rel. Itt annyi a csavar, hogy nem egy VMware vSphere klaszter van benne, hanem kettő – de lehet több is. Bár az NSX maga lehetővé teszi egy klaszter, sőt még egy hoszt másik overlay transport zónába helyezését, a VCF esetén ez nem támogatott, tehát egy workload domain-en belül minden VMware vSphere klaszter kötelezően azonos overlay transport van -lentebb magyarázat. Ez a gyakorlatban azt jelenti, hogy egy létrehozott szegmens az a teljes WLD-ben, minden klaszterében megjeleni k és használható, ami lehet kívánt is, de rendszerek között, ha izoláció a szempont, akkor kizáró hátrány. A képen fent berajzoltam, de emiatt az azonos overlay TZ miatt, elegendő igazából egyetlen Edge klaszter is, nem kell minden VMware klaszterbe egy/több.
WLD 3 – piggyback a WLD 2-n
A “WLD_3” nevű narancs rész pedig azt jelképezi, hogy bár rendelkezik az a workload domain saját vCenter Server-rel, de a “WLD_2” NSX instance-át használja fel, ebből a szempontból a menedzsmentben nem különül el teljes mértékben. Továbbá nem elhagyagolható tény, hogy a pár sorral fentebbek miatt ez is abba az overlay transport zónába kell kerüljön, mint a “WLD_2”. Ez hozza annak hátrányait is, mivel ekkor szintén igaz, hogy már nem csak a workload domain-en belül, hanem két workload domain között is használhatóvá válik egy szegmens.Itt a WLD3-ban az Edge klaszter/VM/VMek egyáltalán nem kötelezők, mivel használhatják a WLD2 elemeit.
A három lehetőség eddig is világos volt, de pusztán a VCF-es dokumentáció ezt nem állítja nyiltan, erre magam kellett rájöjjek. Ennek fényében a “WLD_3” opció az elvetendő a legtöbb előfordulásban, a “WLD_2” is eléggé kétséges, egyedül a “WLD_1” ami teljesíti az izolációs törekvéseket, azonban a jelenlegi VCF 4.0.1 verzióban 14 darab workload domain lehet – a 15-ik az a management domain – tekintve, hogy a vCenter Server ennyi példányt képes linked mode-ban kezelni.
Érdekességek
Amit nagyon érdekesnek találok azok a következők:
- Miért nem támogatott egy workload domain-en belül a klaszterek különböző overlay transport zónába helyezése? Ez azért lenne érdekes, mert így nem lehetne véletlenül sem olyan azonos szegmensbe tenni virtuális gépeket a különböző klaszterekben. Véleményem szerint a WLD a VMware olvasatában azonos felhasználási célra szervezett, de valamilyen okból több klaszterbe szervezett erőforrások összessége. Tehát mondjuk CPU generációban, lokációban – ha nem stretched – eltérő hosztok által alkotott klaszterek alkotják, de azonos workload számára adnak erőforrást.
Főleg, hogy akár hosztonként lehetséges más és más overlay transport zónába tenni hosztokat egy klasztereken belül NSX-ben, viszont ha VCF ernyő alatt van, akkor nem “engedélyezett”.
- Miért nem lehet több T0 egy ovelay transport zónában? Ez kb azt jelenti, hogy egy teljes workload domain összes szegmense egyetlen T0-t kell használjon. Mi?
Azt jelenti, hogy adott APP_SEGMENT_01 és APP_SEGMENT_02 és mindkettő azonos T0-n fog kilépni a hálózatba. De mi történik, ha ez két szegmens mondjuk inkább CLIENT01_APP_01 és CLIENT02_APP_02 névvel fut? Még mindig jó ötlet azonos T0-n kihozni őket? Szintén elmondható, hogy NSX-el akár szegmensenként más T0-val lehetséges operálni – nyilvánvalóan a maximális szám eléréséig – viszont lehetséges. VCF esetén nem. UPDATE: 4.0.1-ben javították.
Mindkét fenti limitációt fel lehet oldani, mivel NSX-ben önmagában simán beállítható, de VCF-ben mégsem támogatott.
- Szintén a fentebbi felsorolásban írja, hogy nem lehet stretched cluster-be Edge cluster-t telepíteni, de egy nem kiterjesztett klasztert, amiben már van Edge cluster, ki lehet terjeszteni. Mi??
