Pár éve már annak, hogy a VMware megvásárolta az AVI Networks nevű céget, akik a terheléselosztó rendszereik kapcsán közel sem ismeretlen szereplők. Azóta nem állt meg az idő, átnevezéssel alig, képességeben viszont próbálták mélyebben integrálni a saját termékeikbe. Az átnevezés során lett az AVI Load Balancer-ből, NSX Advanced Load Balancer. Félrevezető kicsit mert az NSX-nek nem kell köze legyen egy működő telepítéshez, de itt inkább arról van szó, hogy a software defined networking portfióióban már bejáratott „NSX” név utóvizén, az abban elérhető load balancer funkció mellé, egy fejltettebb opciót is tudjon adni.
Nem arról van szó, hogy egy NSX telepítésben az Edge komponensekben realizálható – Tanzu esetén mondjuk van distributed load balancer is – terheléselosztó kivezetésre kerülne vagy nem szabadna használni. Az AVI annak kellhet, akinél például olyan funkciók kellenek, amiket az NSX LB-je nem tud vagy éppen nincs is NSX a rendszerében, de az AVI jól jöhetne.
A multicloud load balancing, a DDoS, a WAF, a GSLB, az elképesztő mély analitika és az automatikus skálázódás mind olyan lehetőség, amelyet az NSX-be épített LB ilyen formában nem tud megvalósítani. Ezt pedig erre tervezték és „építették”. Nekem pont ez az automatikus skálázódás ragadta meg a képzeletemet.
Egy telepítésben van egy Controller klaszter, ami nevéből kitalálható módon a control és management plane-t funkciókat adja. Gyakorlott szakemberek már szisszennek is fel, hogy akkor itt legalább páratlan számú kell a redundanciához. Nem is tévednek, szóval egy elég, de tényleg három kell a hibatűréséhez. (Ha egy van és az elérhetetlenné válik, akkor sincs baj a terheléselosztásban, viszont a menedzselhetőség és az analitika nem fog működni.)
És van egy vagy több Service Engine, amik a terhelés elosztását végzik. Ezek lehetnek igen sokféle platformon virtuális gépek, bare metal kiszolgálók, felhőben is futhatnak. https://avinetworks.com/docs/20.1/system-requirements-ecosystem/ Egy ilyen service engine mérete mindössze 1 vCPU és 2GB RAM – VM esetén.
Ami elég király képesség, hogy általunk megadható határokat meghaladva képes skálázni a kívánt szolgáltatást, na de még olyat is, hogy idővel megtanulja mikor vannak a csúcsok és előre skálázza a még nem is tapasztalható, de nagy bizonyossággal várható terhelés elében.
Ily módon képes:
- további service engine-re is kiterjeszteni az adott LB-t – scale out.
- nagyobb kapacitású service engine-re mozgatni az adott LB-t – migrate
- csökkenteni a fenti kettőt, ha alacsony a terhelés – scale in
Használni ezt az automatikus skálázást nem kötelező, de mivel a Service Engine-ek életciklusát kezelni képes – hacsak nem kézzel telepítettük őket – miért ne tennénk?
Annyi dolgot tud az AVI – NSX Advanced Load Balancer – hogy felsorolni sem lehet, de leírni is csak egy könyvben. Kitapasztalni, kipróbálni pedig most úgy tűnik lesz idő, mivel A VMware most 2035. január 1-ig használható, 2 vCPU licenszet ad. minden aktuális ügyfele számára.
Fentebb látható, hogy ha két darab 1 vCPU/2GB RAM méretű VM-et használhatunk – a kontrollereket nem kell licenszelni -, akkor azokat aktív-aktív modell-ben üzemeltetve, elég korrekt kapacitást kapunk. Ha nem kell redundancia, akkor 2 vCPU/4GB RAM verzió jöhet számításba. Az összes kapacitás amire szükség van (8 vCPU/24 GB RAM és 128 GB tároló (SSD elég erősen javasolt) az egy kontroller-nek és maximum 2 vCPU/2-4GB RAM, illetve 20GB tároló (szintén SSD).
Keressétek a preferált partnereteket és VMware kapcsolattartótokat!
