Lêste kear hawwe wy praat oer de mooglikheden fan NSX Edge yn termen fan statyske en dynamyske routing, en hjoed sille wy omgean mei de load balancer.
Foardat wy begjinne mei it ynstellen, wol ik jo koart herinnerje oer de wichtichste soarten balânsjen.
Teory
Alle hjoeddeistige oplossingen foar balânsjen fan lading wurde meast ferdield yn twa kategoryen: balânsjen op it fjirde (ferfier) en sânde (applikaasje) nivo fan it model . It OSI-model is net it bêste referinsjepunt by it beskriuwen fan balânsmetoaden. Bygelyks, as in L4 balancer ek stipet TLS beëiniging, wurdt it dan in L7 balancer? Mar it is wat it is.
- Balancer L4 meast faak is it in middelste proxy stean tusken de kliïnt en in set fan beskikbere backends, dy't terminates TCP ferbinings (dat is, ûnôfhinklik reagearret op SYN), selektearje in backend en inisjearret in nije TCP sesje yn syn rjochting, selsstannich stjoeren SYN. Dit type is ien fan 'e basis; oare opsjes binne mooglik.
- Balancer L7 ferspriedt ferkear oer beskikbere backends "ferfine" dan de L4 balancer docht. It kin beslute hokker backend om te kiezen basearre op bygelyks de ynhâld fan it HTTP-berjocht (URL, koekje, ensfh.).
Nettsjinsteande it type kin de balancer de folgjende funksjes stypje:
- Tsjinstûntdekking is it proses foar it bepalen fan de set fan beskikbere backends (Static, DNS, Consul, Etcd, ensfh.).
- Kontrolearje de funksjonaliteit fan 'e ûntdutsen backends (aktive "ping" fan 'e efterkant mei in HTTP-fersyk, passive deteksje fan problemen yn TCP-ferbiningen, de oanwêzigens fan ferskate 503 HTTP-koades yn 'e antwurden, ensfh.).
- De balâns sels (round robin, willekeurige seleksje, boarne IP-hash, URI).
- TLS-beëiniging en sertifikaatferifikaasje.
- Feiligens-relatearre opsjes (ferifikaasje, DoS-oanfalprevinsje, snelheidsbeheining) en folle mear.
NSX Edge biedt stipe foar twa ynsetmodi foar load balancer:
Proxy-modus, of ienarm. Yn dizze modus brûkt NSX Edge syn IP-adres as it boarneadres by it ferstjoeren fan in fersyk nei ien fan 'e backends. Sa fiert de balancer tagelyk de funksjes fan Boarne en Destination NAT. De backend sjocht alle ferkear as ferstjoerd fan 'e balancer en reagearret direkt derop. Yn sa'n skema moat de balancer yn itselde netwurksegment wêze mei de ynterne servers.
Hjir is hoe't it giet:
1. De brûker stjoert in fersyk nei de VIP adres (balancer adres) dat is konfigurearre op de Edge.
2. Râne selektearret ien fan de backends en fiert bestimming NAT, ferfanging fan de VIP adres mei it adres fan de selektearre backend.
3. Edge fiert boarne NAT, ferfangt it adres fan de brûker dy't stjoerde it fersyk mei syn eigen.
4. It pakket wurdt stjoerd nei de selektearre backend.
5. De backend reagearret net direkt oan de brûker, mar oan de Edge, sûnt de brûker syn oarspronklike adres is feroare nei de balancer syn adres.
6. Edge stjoert de tsjinner syn antwurd oan de brûker.
It diagram is hjirûnder.
Transparante, of ynline, modus. Yn dit senario hat de balancer ynterfaces op 'e ynterne en eksterne netwurken. Tagelyk is d'r gjin direkte tagong ta it ynterne netwurk fan 'e eksterne. De ynboude load balancer fungearret as in NAT-poarte foar firtuele masines op it ynterne netwurk.
It meganisme is as folget:
1. De brûker stjoert in fersyk nei de VIP adres (balancer adres) dat is konfigurearre op de Edge.
2. Râne selektearret ien fan de backends en fiert bestimming NAT, ferfanging fan de VIP adres mei it adres fan de selektearre backend.
3. It pakket wurdt stjoerd nei de selektearre backend.
4. De backend ûntfangt in fersyk mei de brûker syn oarspronklike adres (boarne NAT waard net útfierd) en reagearret direkt nei it.
5. It ferkear wurdt wer akseptearre troch de load balancer, sûnt yn in ynline skema it meastal fungearret as de standert poarte foar de tsjinner pleats.
6. Edge fiert boarne NAT om ferkear nei de brûker te stjoeren, mei syn VIP as it boarne IP-adres.
It diagram is hjirûnder.
Praktyk
Myn testbank hat 3-tsjinners mei Apache, dy't konfigureare is om te wurkjen oer HTTPS. Edge sil round robin-balancing fan HTTPS-oanfragen útfiere, en elk nij fersyk proxy nei in nije tsjinner.
Litte wy begjinne.
It generearjen fan in SSL-sertifikaat dat sil wurde brûkt troch NSX Edge
Jo kinne in jildich CA-sertifikaat ymportearje of in sels ûndertekene brûke. Foar dizze test sil ik sels ûndertekene brûke.
- Gean yn 'e vCloud Director-ynterface nei de Edge-tsjinstynstellingen.
- Gean nei it ljepblêd Sertifikaten. Selektearje it tafoegjen fan in nije CSR út 'e list mei aksjes.
- Folje de fereaske fjilden yn en klik op Keep.
- Selektearje de nij oanmakke CSR en selektearje de selsteken CSR-opsje.
- Selektearje de jildigensperioade fan it sertifikaat en klik op Bewarje
- It sels-ûndertekene sertifikaat ferskynt yn 'e list mei beskikbere.
Applikaasjeprofyl ynstelle
Applikaasjeprofilen jouwe jo folsleine kontrôle oer netwurkferkear en meitsje it behearen ienfâldich en effektyf. Se kinne brûkt wurde om gedrach te definiearjen foar spesifike soarten ferkear.
- Gean nei it ljepblêd Load Balancer en aktivearje de balancer. De opsje Acceleration ynskeakele hjir lit de balancer flugger L4-balancing brûke ynstee fan L7.
- Gean nei it ljepblêd Applikaasjeprofyl om it applikaasjeprofyl yn te stellen. Klik op +.
- Stel de namme fan it profyl yn en selektearje it type ferkear wêrfoar it profyl tapast wurdt. Lit my guon parameters útlizze.
Persistence - bewarret en folget sesjegegevens, bygelyks: hokker spesifike tsjinner yn it swimbad it brûkerfersyk betsjinnet. Dit soarget derfoar dat brûkersoanfragen wurde trochstjoerd nei itselde poollid foar it libben fan 'e sesje as folgjende sesjes.
SSL passthrough ynskeakelje - As dizze opsje selektearre is, stopet NSX Edge mei it beëinigjen fan SSL. Ynstee komt beëiniging direkt op 'e servers dy't balansearre wurde.
Foegje X-Forwarded-For HTTP-koptekst yn - lit jo it boarne IP-adres bepale fan 'e kliïnt dy't ferbine mei de webtsjinner fia de loadbalancer.
Pool Side SSL ynskeakelje - lit jo oanjaan dat it selekteare swimbad bestiet út HTTPS-tsjinners.
- Om't ik it HTTPS-ferkear balansearje sil, moat ik Pool Side SSL ynskeakelje en it earder oanmakke sertifikaat selektearje yn 'e ljepper Virtual Server Certificates -> Service Certificate.
- Lykas foar Pool Sertifikaten -> Service Sertifikaat.
Wy meitsje in pool fan tsjinners, it ferkear dêr't sil wêze balansearre Pools
- Gean nei it ljepblêd Pools. Klik op +.
- Wy sette de namme fan it swimbad yn, selektearje it algoritme (ik sil round robin brûke) en it type tafersjoch foar de sûnenskontrôle backend. De Transparante opsje jout oan oft de earste boarne IPs fan kliïnten sichtber binne foar ynterne servers.
- As de opsje is útskeakele, komt ferkear foar ynterne tsjinners fan 'e boarne IP fan' e balancer.
- As de opsje ynskeakele is, sjogge ynterne servers de boarne IP fan kliïnten. Yn dizze konfiguraasje moat NSX Edge fungearje as de standertpoarte om te soargjen dat weromjûne pakketten troch NSX Edge passe.
NSX stipet de folgjende balânsalgoritmen:
- IP_HASH - tsjinner seleksje basearre op de resultaten fan in hash funksje foar de boarne en bestimming IP fan elk pakket.
- LEASTCONN - balânsjen fan ynkommende ferbiningen, ôfhinklik fan it oantal dat al beskikber is op in bepaalde tsjinner. Nije ferbinings wurde rjochte op de tsjinner mei de minste ferbinings.
- ROUND_ROBIN - nije ferbinings wurde op beurt nei elke tsjinner stjoerd, yn oerienstimming mei it gewicht dat deroan is tawiisd.
- URI - it linker diel fan 'e URI (foar it fraachteken) wurdt hashed en dield troch it totale gewicht fan tsjinners yn it swimbad. It resultaat jout oan hokker tsjinner it fersyk ûntfangt, en soarget derfoar dat it fersyk altyd trochstjoerd wurdt nei deselde server, salang't alle servers beskikber bliuwe.
- HTTPHEADER - balânsjen basearre op in spesifike HTTP-header, dy't kin wurde opjûn as in parameter. As de koptekst ûntbrekt of gjin wearde hat, wurdt it ROUND_ROBIN-algoritme tapast.
- URL - Elk HTTP GET-fersyk siket nei de URL-parameter opjûn as argumint. As de parameter folge wurdt troch in lykweardich teken en in wearde, dan wurdt de wearde hashed en dield troch it totale gewicht fan rinnende tsjinners. It resultaat jout oan hokker tsjinner it fersyk ûntfangt. Dit proses wurdt brûkt om brûkers-ID's yn oanfragen by te hâlden en te soargjen dat deselde brûkers-id altyd nei deselde server stjoerd wurdt, salang't alle servers beskikber bliuwe.
- Klikje yn it lidblok op + om tsjinners ta te foegjen oan it swimbad.
Hjir moatte jo oanjaan:- Server Namme;
- Server IP-adres;
- de poarte wêrop de tsjinner ferkear sil ûntfange;
- haven foar sûnenskontrôle (Monitor sûnenscheck);
- gewicht - mei dizze parameter kinne jo it evenredige bedrach fan ferkear oanpasse foar in spesifike poollid;
- Max Connections - maksimum oantal ferbinings nei de tsjinner;
- Min Ferbinings - it minimum oantal ferbinings dat de tsjinner moat ferwurkje foardat ferkear wurdt trochstjoerd nei it folgjende pool lid.
Dit is hoe't de lêste pool fan trije tsjinners derút sjocht.
Firtuele tsjinner tafoegje
- Gean nei it ljepblêd Virtual Servers. Klik op +.
- Wy aktivearje de firtuele tsjinner mei help fan Firtuele tsjinner ynskeakelje.
Wy jouwe it in namme, selektearje it earder oanmakke applikaasjeprofyl, Pool en jouwe it IP-adres oan wêrop de firtuele tsjinner oanfragen fan bûten sil ûntfange. Wy spesifisearje it HTTPS-protokol en poarte 443.
Opsjonele parameters hjir:
Ferbining Limit - it maksimum oantal simultane ferbiningen dat de firtuele tsjinner kin ferwurkje;
Ferbining Rate Limit (CPS) - it maksimum oantal nije ynkommende oanfragen per sekonde.
Dit foltôget de konfiguraasje fan 'e balancer; jo kinne de funksjonaliteit kontrolearje. De tsjinners hawwe in ienfâldige konfiguraasje wêrmei jo te begripen hokker tsjinner út it swimbad ferwurke it fersyk. Tidens opset, wy keas de Round Robin balancing algoritme, en de Weight parameter foar eltse tsjinner is gelyk oan ien, sadat elk folgjende fersyk wurdt ferwurke troch de folgjende tsjinner út it swimbad.
Wy ynfiere it eksterne adres fan 'e balancer yn' e browser en sjoch:
Nei it ferfarskjen fan de side sil it fersyk ferwurke wurde troch de folgjende tsjinner:
En nochris - om de tredde tsjinner fan it swimbad te kontrolearjen:
By it kontrolearjen kinne jo sjen dat it sertifikaat dat Edge ús stjoert itselde is dat wy oan it begjin genereare.
Kontrolearje balancer status fan de Edge gateway konsole. Om dit te dwaan, enter show service loadbalancer pool.
Service Monitor konfigurearje om de status fan tsjinners yn it swimbad te kontrolearjen
Mei Service Monitor kinne wy de status fan servers yn 'e backend pool kontrolearje. As it antwurd op in fersyk net is as ferwachte, kin de tsjinner út it swimbad helle wurde, sadat it gjin nije oanfragen ûntfangt.
Standert binne trije ferifikaasjemetoaden konfigureare:
- TCP-monitor,
- HTTP monitor,
- HTTPS-monitor.
Litte wy in nije oanmeitsje.
- Gean nei it ljepblêd Service Monitoring, klikje op +.
- Kieze:
- namme foar de nije metoade;
- it ynterval wêryn fersiken sille wurde ferstjoerd,
- timeout wachtsje op in antwurd,
- monitortype - HTTPS-fersyk mei de GET-metoade, ferwachte statuskoade - 200 (OK) en fersyk URL.
- Dit foltôget de opset fan 'e nije Service Monitor; no kinne wy it brûke by it meitsjen fan in swimbad.
It ynstellen fan tapassingsregels
Applikaasjeregels binne in manier om ferkear te manipulearjen basearre op bepaalde triggers. Mei dit ark kinne wy avansearre regels foar load balancing meitsje dy't miskien net mooglik binne fia applikaasjeprofilen of oare tsjinsten beskikber op 'e Edge Gateway.
- Om in regel te meitsjen, gean nei it tabblêd Applikaasjeregels fan 'e balancer.
- Selektearje in namme, in skript dat de regel sil brûke, en klik op Keep.
- Nei't de regel makke is, moatte wy de al konfigureare Virtual Server bewurkje.
- Foegje yn it ljepblêd Avansearre de regel ta dy't wy makke hawwe.
Yn it foarbyld hjirboppe hawwe wy tlsv1-stipe ynskeakele.
In pear mear foarbylden:
Ferkear omliede nei in oar swimbad.
Mei dit skript kinne wy omliede ferkear nei in oare balancing pool as de wichtichste pool is del. Foar de regel om te wurkjen, moatte meardere pools wurde konfigurearre op 'e balancer en alle leden fan' e wichtichste swimbad moatte wêze yn 'e down state. Jo moatte de namme fan it swimbad opjaan, net har ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Ferkear omliede nei in eksterne boarne.
Hjir ferwize wy ferkear nei de eksterne webside as alle leden fan 'e wichtichste swimbad del binne.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Noch mear foarbylden .
Dat is alles foar my oer de balancer. As jo fragen hawwe, freegje dan, ik bin ree om te beantwurdzjen.
Boarne: www.habr.com