Noong nakaraang pagkakataon, napag-usapan natin ang tungkol sa mga kakayahan ng NSX Edge sa mga tuntunin ng static at dynamic na pagruruta, at ngayon ay haharapin natin ang load balancer.
Bago tayo magsimulang mag-set up, nais kong ipaalala sa iyo ang tungkol sa mga pangunahing uri ng pagbabalanse.
Π’Π΅ΠΎΡΠΈΡ
Ang lahat ng mga solusyon sa pagbabalanse ng payload ngayon ay kadalasang nahahati sa dalawang kategorya: pagbabalanse sa ikaapat (transportasyon) at ikapitong (application) na antas ng modelo . Ang modelo ng OSI ay hindi ang pinakamahusay na reference point kapag naglalarawan ng mga paraan ng pagbabalanse. Halimbawa, kung sinusuportahan din ng L4 balancer ang pagwawakas ng TLS, magiging L7 balancer ba ito? Ngunit ito ay kung ano ito.
- Balanse L4 kadalasan ito ay isang gitnang proxy na nakatayo sa pagitan ng kliyente at isang hanay ng mga available na backend, na nagwawakas ng mga koneksyon sa TCP (iyon ay, independiyenteng tumugon sa SYN), pumipili ng isang backend at nagpasimula ng bagong session ng TCP sa direksyon nito, nang nakapag-iisa na nagpapadala ng SYN. Ang ganitong uri ay isa sa mga pangunahing; iba pang mga opsyon ay posible.
- Balanse L7 namamahagi ng trapiko sa mga available na backend na "mas sopistikado" kaysa sa ginagawa ng L4 balancer. Maaari itong magpasya kung aling backend ang pipiliin batay sa, halimbawa, sa mga nilalaman ng HTTP na mensahe (URL, cookie, atbp.).
Anuman ang uri, maaaring suportahan ng balancer ang mga sumusunod na function:
- Ang pagtuklas ng serbisyo ay ang proseso ng pagtukoy sa hanay ng mga available na backend (Static, DNS, Consul, Etcd, atbp.).
- Sinusuri ang functionality ng mga nakitang backend (aktibong "ping" ng backend gamit ang HTTP request, passive detection ng mga problema sa TCP connections, ang pagkakaroon ng ilang 503 HTTP code sa mga tugon, atbp.).
- Ang pagbabalanse mismo (round robin, random selection, source IP hash, URI).
- Pagwawakas ng TLS at pag-verify ng sertipiko.
- Mga opsyon na nauugnay sa seguridad (pagpapatotoo, pag-iwas sa pag-atake ng DoS, paglilimita sa bilis) at marami pang iba.
Nag-aalok ang NSX Edge ng suporta para sa dalawang load balancer deployment mode:
Proxy mode, o isang braso. Sa mode na ito, ginagamit ng NSX Edge ang IP address nito bilang source address kapag nagpapadala ng kahilingan sa isa sa mga backend. Kaya, sabay-sabay na ginagawa ng balancer ang mga function ng Source at Destination NAT. Nakikita ng backend ang lahat ng trapiko bilang ipinadala mula sa balancer at direktang tumutugon dito. Sa gayong pamamaraan, ang tagabalanse ay dapat na nasa parehong segment ng network kasama ang mga panloob na server.
Narito kung paano ito napupunta:
1. Nagpapadala ang user ng kahilingan sa VIP address (balancer address) na naka-configure sa Edge.
2. Pinipili ng Edge ang isa sa mga backend at nagsasagawa ng destination NAT, na pinapalitan ang VIP address ng address ng napiling backend.
3. Gumaganap ang Edge ng source NAT, na pinapalitan ang address ng user na nagpadala ng kahilingan gamit ang sarili nitong address.
4. Ang package ay ipinadala sa napiling backend.
5. Ang backend ay hindi direktang tumutugon sa user, ngunit sa Edge, dahil ang orihinal na address ng user ay binago sa address ng balancer.
6. Ipinapadala ng Edge ang tugon ng server sa user.
Nasa ibaba ang diagram.
Transparent, o inline, mode. Sa sitwasyong ito, ang balancer ay may mga interface sa panloob at panlabas na mga network. Kasabay nito, walang direktang pag-access sa panloob na network mula sa panlabas. Ang built-in na load balancer ay gumaganap bilang isang NAT gateway para sa mga virtual machine sa panloob na network.
Ang mekanismo ay ang mga sumusunod:
1. Nagpapadala ang user ng kahilingan sa VIP address (balancer address) na naka-configure sa Edge.
2. Pinipili ng Edge ang isa sa mga backend at nagsasagawa ng destination NAT, na pinapalitan ang VIP address ng address ng napiling backend.
3. Ang package ay ipinadala sa napiling backend.
4. Tumatanggap ang backend ng kahilingan kasama ang orihinal na address ng user (hindi isinagawa ang source NAT) at direktang tumugon dito.
5. Ang trapiko ay muling tinatanggap ng load balancer, dahil sa isang inline na pamamaraan ay kadalasang nagsisilbi itong default na gateway para sa server farm.
6. Ginagawa ng Edge ang source NAT para magpadala ng trapiko sa user, gamit ang VIP nito bilang source IP address.
Nasa ibaba ang diagram.
Pagsasanay
Ang aking test bench ay may 3 server na nagpapatakbo ng Apache, na naka-configure upang gumana sa HTTPS. Magsasagawa ang Edge ng round robin na pagbabalanse ng mga kahilingan sa HTTPS, na i-proxy ang bawat bagong kahilingan sa isang bagong server.
Magsimula tayo.
Pagbuo ng SSL certificate na gagamitin ng NSX Edge
Maaari kang mag-import ng valid CA certificate o gumamit ng self-signed. Para sa pagsusulit na ito gagamitin ko ang self-signed.
- Sa interface ng vCloud Director, pumunta sa mga setting ng mga serbisyo ng Edge.
- Pumunta sa tab na Mga Certificate. Mula sa listahan ng mga aksyon, piliin ang pagdaragdag ng bagong CSR.
- Punan ang mga kinakailangang field at i-click ang Keep.
- Piliin ang bagong likhang CSR at piliin ang self-sign CSR na opsyon.
- Piliin ang panahon ng bisa ng certificate at i-click ang Panatilihin
- Lumilitaw ang self-signed certificate sa listahan ng mga available.
Pagse-set up ng Application Profile
Binibigyan ka ng mga profile ng application ng mas kumpletong kontrol sa trapiko sa network at ginagawang simple at epektibo ang pamamahala nito. Magagamit ang mga ito upang tukuyin ang gawi para sa mga partikular na uri ng trapiko.
- Pumunta sa tab na Load Balancer at paganahin ang balancer. Ang opsyong pinagana ang Acceleration dito ay nagbibigay-daan sa balancer na gumamit ng mas mabilis na pagbabalanse ng L4 sa halip na L7.
- Pumunta sa tab na Application profile upang itakda ang profile ng application. I-click ang +.
- Itakda ang pangalan ng profile at piliin ang uri ng trapiko kung saan ilalapat ang profile. Hayaan akong ipaliwanag ang ilang mga parameter.
Pagtitiyaga β nag-iimbak at sumusubaybay ng data ng session, halimbawa: kung aling partikular na server sa pool ang nagseserbisyo sa kahilingan ng user. Tinitiyak nito na ang mga kahilingan ng user ay iruruta sa parehong miyembro ng pool para sa habambuhay ng session o mga kasunod na session.
Paganahin ang SSL passthrough β Kapag napili ang opsyong ito, hihinto ang NSX Edge sa pagwawakas ng SSL. Sa halip, ang pagwawakas ay nangyayari nang direkta sa mga server na binabalanse.
Ipasok ang X-Forwarded-For HTTP header β nagbibigay-daan sa iyo upang matukoy ang pinagmulan ng IP address ng kliyente na kumokonekta sa web server sa pamamagitan ng load balancer.
Paganahin ang Pool Side SSL β nagbibigay-daan sa iyong tukuyin na ang napiling pool ay binubuo ng mga HTTPS server.
- Dahil babalanse ko ang trapiko ng HTTPS, kailangan kong paganahin ang Pool Side SSL at piliin ang dati nang nabuong certificate sa Virtual Server Certificates -> Service Certificate tab.
- Katulad din para sa Pool Certificates -> Sertipiko ng Serbisyo.
Lumilikha kami ng pool ng mga server, ang trapiko kung saan magiging balanseng Pool
- Pumunta sa tab na Mga Pool. I-click ang +.
- Itinakda namin ang pangalan ng pool, piliin ang algorithm (gagamitin ko ang round robin) at ang uri ng pagsubaybay para sa backend ng pagsusuri sa kalusugan. Isinasaad ng Transparent na opsyon kung ang mga paunang pinagmulang IP ng mga kliyente ay nakikita ng mga panloob na server.
- Kung hindi pinagana ang opsyon, ang trapiko para sa mga internal na server ay nagmumula sa pinagmulang IP ng balancer.
- Kung pinagana ang opsyon, makikita ng mga panloob na server ang pinagmulang IP ng mga kliyente. Sa pagsasaayos na ito, dapat kumilos ang NSX Edge bilang default na gateway upang matiyak na ang mga ibinalik na packet ay dumaan sa NSX Edge.
Sinusuportahan ng NSX ang mga sumusunod na algorithm ng pagbabalanse:
- IP_HASH β pagpili ng server batay sa mga resulta ng hash function para sa source at destination IP ng bawat packet.
- LEASTCONN β pagbabalanse ng mga papasok na koneksyon, depende sa numerong available na sa isang partikular na server. Ang mga bagong koneksyon ay ididirekta sa server na may kaunting mga koneksyon.
- ROUND_ROBIN β ang mga bagong koneksyon ay ipinapadala sa bawat server, alinsunod sa bigat na itinalaga dito.
- URI β ang kaliwang bahagi ng URI (bago ang tandang pananong) ay hina-hash at hinati sa kabuuang bigat ng mga server sa pool. Ang resulta ay nagpapahiwatig kung aling server ang makakatanggap ng kahilingan, na tinitiyak na ang kahilingan ay palaging iruruta sa parehong server, hangga't ang lahat ng mga server ay mananatiling available.
- HTTPHEADER β pagbabalanse batay sa isang partikular na header ng HTTP, na maaaring tukuyin bilang isang parameter. Kung ang header ay nawawala o walang anumang halaga, ang ROUND_ROBIN algorithm ay ilalapat.
- URL β Ang bawat kahilingan sa HTTP GET ay naghahanap para sa parameter ng URL na tinukoy bilang isang argumento. Kung ang parameter ay sinusundan ng isang pantay na tanda at isang halaga, pagkatapos ay ang halaga ay na-hash at hinati sa kabuuang bigat ng mga tumatakbong server. Ang resulta ay nagpapahiwatig kung aling server ang tumatanggap ng kahilingan. Ginagamit ang prosesong ito upang subaybayan ang mga user ID sa mga kahilingan at matiyak na ang parehong user id ay palaging ipinapadala sa parehong server, hangga't ang lahat ng mga server ay mananatiling available.
- Sa block ng Mga Miyembro, i-click ang + upang magdagdag ng mga server sa pool.
Dito kailangan mong tukuyin:- pangalan ng server;
- IP address ng server;
- ang port kung saan makakatanggap ang server ng trapiko;
- port para sa pagsusuri sa kalusugan (Monitor healthcheck);
- timbang β gamit ang parameter na ito maaari mong ayusin ang proporsyonal na dami ng trapikong natanggap para sa isang partikular na miyembro ng pool;
- Max Connections β maximum na bilang ng mga koneksyon sa server;
- Min Connections β ang pinakamababang bilang ng mga koneksyon na dapat iproseso ng server bago maipasa ang trapiko sa susunod na miyembro ng pool.
Ito ang hitsura ng huling pool ng tatlong server.
Pagdaragdag ng Virtual Server
- Pumunta sa tab na Mga Virtual Server. I-click ang +.
- Ina-activate namin ang virtual server gamit ang Enable Virtual Server.
Binibigyan namin ito ng pangalan, piliin ang naunang nilikha na Application Profile, Pool at ipahiwatig ang IP address kung saan makakatanggap ang Virtual Server ng mga kahilingan mula sa labas. Tinukoy namin ang HTTPS protocol at port 443.
Mga opsyonal na parameter dito:
Limitasyon ng Koneksyon β ang maximum na bilang ng mga sabay-sabay na koneksyon na maaaring iproseso ng virtual server;
Limitasyon sa Rate ng Koneksyon (CPS) β ang maximum na bilang ng mga bagong papasok na kahilingan sa bawat segundo.
Kinukumpleto nito ang pagsasaayos ng balancer; maaari mong suriin ang paggana nito. Ang mga server ay may simpleng configuration na nagbibigay-daan sa iyong maunawaan kung aling server mula sa pool ang nagproseso ng kahilingan. Sa panahon ng setup, pinili namin ang Round Robin balancing algorithm, at ang Weight parameter para sa bawat server ay katumbas ng isa, kaya ang bawat kasunod na kahilingan ay ipoproseso ng susunod na server mula sa pool.
Ipinasok namin ang panlabas na address ng balancer sa browser at tingnan ang:
Pagkatapos i-refresh ang pahina, ang kahilingan ay ipoproseso ng sumusunod na server:
At muli - upang suriin ang ikatlong server mula sa pool:
Kapag nagsusuri, makikita mo na ang certificate na ipinadala sa amin ni Edge ay pareho sa aming nabuo sa simula pa lang.
Sinusuri ang status ng balancer mula sa Edge gateway console. Upang gawin ito, ipasok ipakita ang serbisyo loadbalancer pool.
Pag-configure ng Service Monitor para suriin ang status ng mga server sa pool
Gamit ang Service Monitor, masusubaybayan namin ang status ng mga server sa backend pool. Kung ang tugon sa isang kahilingan ay hindi tulad ng inaasahan, ang server ay maaaring alisin sa pool upang hindi ito makatanggap ng anumang mga bagong kahilingan.
Bilang default, tatlong paraan ng pag-verify ang na-configure:
- TCP-monitor,
- HTTP monitor,
- HTTPS-monitor.
Gumawa tayo ng bago.
- Pumunta sa tab na Pagsubaybay sa Serbisyo, i-click ang +.
- Pumili:
- pangalan para sa bagong pamamaraan;
- ang pagitan kung kailan ipapadala ang mga kahilingan,
- timeout na naghihintay ng tugon,
- uri ng pagsubaybay β HTTPS na kahilingan gamit ang GET method, inaasahang status code β 200(OK) at humiling ng URL.
- Kinukumpleto nito ang pag-setup ng bagong Service Monitor; ngayon ay magagamit na natin ito kapag gumagawa ng pool.
Pag-set up ng Mga Panuntunan sa Application
Ang Mga Panuntunan sa Application ay isang paraan upang manipulahin ang trapiko batay sa ilang partikular na trigger. Sa tool na ito makakagawa tayo ng mga advanced na panuntunan sa pagbalanse ng load na maaaring hindi posible sa pamamagitan ng mga profile ng Application o iba pang mga serbisyong available sa Edge Gateway.
- Upang gumawa ng panuntunan, pumunta sa tab na Mga Panuntunan sa Application ng balancer.
- Pumili ng pangalan, isang script na gagamit ng panuntunan, at i-click ang Keep.
- Pagkatapos malikha ang panuntunan, kailangan nating i-edit ang na-configure na Virtual Server.
- Sa tab na Advanced, idagdag ang panuntunang ginawa namin.
Sa halimbawa sa itaas pinagana namin ang suporta sa tlsv1.
Ilan pang halimbawa:
I-redirect ang trapiko sa isa pang pool.
Gamit ang script na ito maaari naming i-redirect ang trapiko sa isa pang balanseng pool kung ang pangunahing pool ay down. Para gumana ang panuntunan, dapat na i-configure ang maraming pool sa balancer at lahat ng miyembro ng pangunahing pool ay dapat nasa down na estado. Kailangan mong tukuyin ang pangalan ng pool, hindi ang ID nito.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
I-redirect ang trapiko sa isang panlabas na mapagkukunan.
Dito namin nire-redirect ang trapiko sa panlabas na website kung ang lahat ng miyembro ng pangunahing pool ay down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Higit pang mga halimbawa .
Iyon lang ang para sa akin tungkol sa balancer. Kung mayroon kang anumang mga katanungan, magtanong, handa akong sagutin.
Pinagmulan: www.habr.com