Lastan fojon ni parolis pri la kapabloj de NSX Edge laŭ statika kaj dinamika vojigo, kaj hodiaŭ ni traktos la ŝarĝan ekvilibron.
Antaŭ ol ni komenci agordi, mi ŝatus mallonge memorigi vin pri la ĉefaj specoj de ekvilibro.
Teorio
Ĉiuj hodiaŭaj ŝarĝaj ekvilibraj solvoj estas plej ofte dividitaj en du kategoriojn: ekvilibro ĉe la kvara (transportado) kaj sepa (apliko) niveloj de la modelo. . La OSI-modelo ne estas la plej bona referencpunkto dum priskribado de ekvilibraj metodoj. Ekzemple, se L4-balancilo ankaŭ subtenas TLS-finon, ĉu ĝi tiam fariĝas L7-balancilo? Sed ĝi estas kio ĝi estas.
- Balancilo L4 plej ofte ĝi estas meza prokurilo staranta inter la kliento kaj aro de disponeblaj backends, kiu finas TCP-konektojn (tio estas, sendepende respondas al SYN), elektas backend kaj iniciatas novan TCP-sesion en ĝia direkto, sendepende sendante SYN. Ĉi tiu tipo estas unu el la bazaj; aliaj opcioj estas eblaj.
- Balancilo L7 distribuas trafikon tra disponeblaj backends "pli kompleksaj" ol la L4-balancilo faras. Ĝi povas decidi kiun backend elekti surbaze, ekzemple, de la enhavo de la HTTP-mesaĝo (URL, kuketo, ktp.).
Sendepende de la tipo, la balancilo povas subteni la sekvajn funkciojn:
- Serva malkovro estas la procezo determini la aron de disponeblaj backends (Statika, DNS, Konsulo, Ktp.).
- Kontrolante la funkciecon de la detektitaj backends (aktiva "ping" de la backend uzante HTTP-peton, pasiva detekto de problemoj en TCP-konektoj, ĉeesto de pluraj 503 HTTP-kodoj en la respondoj, ktp.).
- La ekvilibro mem (rond-subskribolista, hazarda elekto, fonto IP hash, URI).
- TLS-fino kaj atestilo.
- Sekurec-rilataj elektoj (aŭtentikigo, DoS-ataka antaŭzorgo, rapidlimigo) kaj multe pli.
NSX Edge ofertas subtenon por du disfaldaj reĝimoj de ŝarĝbalancilo:
Prokura reĝimo, aŭ unu-brako. En ĉi tiu reĝimo, NSX Edge uzas sian IP-adreson kiel la fontadreson kiam sendas peton al unu el la backends. Tiel, la ekvilibristo samtempe plenumas la funkciojn de Fonto kaj Celo NAT. La backend vidas la tutan trafikon kiel senditan de la ekvilibristo kaj respondas rekte al ĝi. En tia skemo, la ekvilibristo devas esti en la sama retsegmento kun la internaj serviloj.
Jen kiel ĝi iras:
1. La uzanto sendas peton al la VIP-adreso (ekvilibra adreso), kiu estas agordita sur la Edge.
2. Edge elektas unu el la backends kaj plenumas celon NAT, anstataŭigante la VIP-adreson per la adreso de la elektita backend.
3. Edge plenumas fonton NAT, anstataŭigante la adreson de la uzanto, kiu sendis la peton per sia propra.
4. La pako estas sendita al la elektita backend.
5. La backend ne respondas rekte al la uzanto, sed al la Rando, ĉar la origina adreso de la uzanto estis ŝanĝita al la adreso de la ekvilibristo.
6. Edge transdonas la respondon de la servilo al la uzanto.
La diagramo estas sube.
Travidebla, aŭ enlinia, reĝimo. En ĉi tiu scenaro, la ekvilibristo havas interfacojn sur la internaj kaj eksteraj retoj. Samtempe, ne ekzistas rekta aliro al la interna reto de la ekstera. La enkonstruita ŝarĝbalancilo funkcias kiel NAT-enirejo por virtualaj maŝinoj sur la interna reto.
La mekanismo estas kiel sekvas:
1. La uzanto sendas peton al la VIP-adreso (ekvilibra adreso), kiu estas agordita sur la Edge.
2. Edge elektas unu el la backends kaj plenumas celon NAT, anstataŭigante la VIP-adreson per la adreso de la elektita backend.
3. La pako estas sendita al la elektita backend.
4. La backend ricevas peton kun la origina adreso de la uzanto (fonto NAT ne estis farita) kaj respondas rekte al ĝi.
5. La trafiko denove estas akceptata de la ŝarĝbalancilo, ĉar en enlinia skemo ĝi kutime funkcias kiel la defaŭlta enirejo por la servila bieno.
6. Edge elfaras fontan NAT por sendi trafikon al la uzanto, uzante ĝian VIP kiel la fontan IP-adreson.
La diagramo estas sube.
Praktiko
Mia testbenko havas 3 servilojn kurantajn Apache, kiu estas agordita por funkcii per HTTPS. Edge faros rondan ekvilibron de HTTPS-petoj, prokurigante ĉiun novan peton al nova servilo.
Ni komencu.
Generante SSL-atestilon, kiu estos uzata de NSX Edge
Vi povas importi validan CA-atestilon aŭ uzi memsubskribitan. Por ĉi tiu testo mi uzos memsubskribitan.
- En la interfaco de vCloud Director, iru al la agordoj de Edge Services.
- Iru al la langeto Atestiloj. El la listo de agoj, elektu aldoni novan CSR.
- Plenigu la postulatajn kampojn kaj alklaku Konservi.
- Elektu la lastatempe kreitan CSR kaj elektu la memsigna CSR-opcion.
- Elektu la validecperiodon de la atestilo kaj alklaku Konservi
- La memsubskribita atestilo aperas en la listo de disponeblaj.
Agordo de Aplika Profilo
Aplikaj profiloj donas al vi pli kompletan kontrolon pri rettrafiko kaj faciligas kaj efike administri ĝin. Ili povas esti uzataj por difini konduton por specifaj specoj de trafiko.
- Iru al la langeto Load Balancer kaj ebligu la ekvilibrilon. La akcelita opcio ĉi tie permesas al la ekvilibristo uzi pli rapidan L4-ekvilibron anstataŭ L7.
- Iru al la langeto de Profilo de la aplikaĵo por agordi la profilon de la aplikaĵo. Alklaku +.
- Agordu la nomon de la profilo kaj elektu la tipon de trafiko por kiu la profilo estos aplikita. Mi klarigu kelkajn parametrojn.
persisto – stokas kaj spuras seandatumojn, ekzemple: kiu specifa servilo en la naĝejo servas la uzantan peton. Ĉi tio certigas, ke uzantpetoj estas direktitaj al la sama naĝejmembro dum la vivdaŭro de la sesio aŭ postaj sesioj.
Ebligu SSL-enirpermesilon – Kiam ĉi tiu opcio estas elektita, NSX Edge ĉesas ĉesigi SSL. Anstataŭe, ĉesigo okazas rekte sur la serviloj, kiuj estas ekvilibrigitaj.
Enmetu X-Forwarded-For HTTP-kapon – permesas vin determini la fontan IP-adreson de la kliento konektanta al la retservilo per la ŝarĝbalancilo.
Ebligu Pool Side SSL – permesas al vi specifi, ke la elektita naĝejo konsistas el HTTPS-serviloj.
- Ĉar mi ekvilibrigos HTTPS-trafikon, mi devas ebligi Pool Side SSL kaj elekti la antaŭe generitan atestilon en la langeto Atestiloj de Virtuala Servilo -> Serva Atestilo.
- Simile por Pool Certificates -> Servatestilo.
Ni kreas naĝejon de serviloj, kies trafiko estos ekvilibrigita Pools
- Iru al la langeto Pools. Alklaku +.
- Ni fiksas la nomon de la naĝejo, elektas la algoritmon (mi uzos round robin) kaj la tipon de monitorado por la sankontrola backend.La Travidebla opcio indikas ĉu la komencaj fontaj IP-oj de klientoj estas videblaj al internaj serviloj.
- Se la opcio estas malŝaltita, trafiko por internaj serviloj venas de la fonta IP de la ekvilibristo.
- Se la opcio estas ebligita, internaj serviloj vidas la fontan IP de klientoj. En ĉi tiu agordo, NSX Edge devas funkcii kiel la defaŭlta enirejo por certigi, ke resenditaj pakoj pasas tra NSX Edge.
NSX subtenas la sekvajn ekvilibrajn algoritmojn:
- IP_HASH - servila elekto surbaze de la rezultoj de hash-funkcio por la fonto kaj celo IP de ĉiu pako.
- LASTCONN – ekvilibro de envenantaj konektoj, depende de la nombro jam disponebla en aparta servilo. Novaj konektoj estos direktitaj al la servilo kun la plej malmultaj konektoj.
- ROUND_ROBIN – novaj konektoj estas senditaj al ĉiu servilo laŭvice, laŭ la pezo atribuita al ĝi.
- URI – la maldekstra parto de la URI (antaŭ la demandosigno) estas haŝita kaj dividita per la totala pezo de serviloj en la naĝejo. La rezulto indikas kiu servilo ricevas la peton, certigante ke la peto ĉiam estas direktita al la sama servilo, kondiĉe ke ĉiuj serviloj restas disponeblaj.
- HTTPHEADER – ekvilibro bazita sur specifa HTTP-kapo, kiu povas esti specifita kiel parametro. Se la kaplinio mankas aŭ havas neniun valoron, la algoritmo ROUND_ROBIN estas aplikata.
- URL – Ĉiu HTTP GET-peto serĉas la URL-parametron specifitan kiel argumenton. Se la parametro estas sekvata de egala signo kaj valoro, tiam la valoro estas haŝita kaj dividita per la totala pezo de kurantaj serviloj. La rezulto indikas kiu servilo ricevas la peton. Ĉi tiu procezo estas uzata por konservi trakon de uzantidentigiloj en petoj kaj certigi ke la sama uzantidentigilo ĉiam estas sendita al la sama servilo, kondiĉe ke ĉiuj serviloj restas disponeblaj.
- En la bloko Membroj, alklaku + por aldoni servilojn al la naĝejo.
Ĉi tie vi devas indiki:- servilo nomo;
- IP-adreso de servilo;
- la haveno sur kiu la servilo ricevos trafikon;
- haveno por sankontrolo (Monitor healthcheck);
- pezo - uzante ĉi tiun parametron vi povas ĝustigi la proporcian kvanton de trafiko ricevita por specifa naĝejo-membro;
- Max Connections - maksimuma nombro da konektoj al la servilo;
- Min Konektoj - la minimuma nombro da konektoj kiujn la servilo devas prilabori antaŭ ol trafiko estas plusendita al la sekva naĝejmembro.
Jen kiel aspektas la fina aro de tri serviloj.
Aldono de Virtuala Servilo
- Iru al la langeto Virtualaj Serviloj. Alklaku +.
- Ni aktivigas la virtualan servilon uzante Ebligu Virtualan Servilon.
Ni donas al ĝi nomon, elektas la antaŭe kreitan Aplikan Profilon, Pool kaj indikas la IP-adreson, al kiu la Virtuala Servilo ricevos petojn de ekstere. Ni specifas la HTTPS-protokolon kaj la havenon 443.
Laŭvolaj parametroj ĉi tie:
Limo de Konekto – la maksimuma nombro da samtempaj konektoj, kiujn la virtuala servilo povas prilabori;
Limo-Indico (CPS) – la maksimuma nombro da novaj envenantaj petoj sekundo.
Ĉi tio kompletigas la agordon de la ekvilibro; vi povas kontroli ĝian funkcion. La serviloj havas simplan agordon, kiu permesas vin kompreni, kiu servilo de la naĝejo prilaboris la peton. Dum aranĝo, ni elektis la Round Robin-ekvilibran algoritmon, kaj la Pezo-parametro por ĉiu servilo estas egala al unu, do ĉiu posta peto estos procesita de la sekva servilo de la naĝejo.
Ni enigas la eksteran adreson de la ekvilibristo en la retumilo kaj vidas:
Post refreŝigado de la paĝo, la peto estos procesita de la sekva servilo:
Kaj denove - por kontroli la trian servilon el la naĝejo:
Kontrolante, vi povas vidi, ke la atestilo, kiun Edge sendas al ni, estas la sama, kiun ni generis komence.
Kontrolante ekvilibran statuson de la Edge-enireja konzolo. Por fari tion, enigu montri servo loadbalancer pool.
Agordante Servan Monitoron por kontroli la staton de serviloj en la naĝejo
Uzante Service Monitor ni povas monitori la staton de serviloj en la backend pool. Se la respondo al peto ne estas tia, la servilo povas esti prenita el la naĝejo por ke ĝi ne ricevu novajn petojn.
Defaŭlte, tri konfirmmetodoj estas agorditaj:
- TCP-monitoro,
- HTTP-monitoro,
- HTTPS-monitoro.
Ni kreu novan.
- Iru al la langeto pri Monitorado de Servo, alklaku +.
- Elektu:
- nomo por la nova metodo;
- la intervalo je kiu petoj estos senditaj,
- tempodaŭro atendante respondon,
- monitora tipo - HTTPS-peto per la GET-metodo, atendata statuskodo - 200(OK) kaj peto URL.
- Ĉi tio kompletigas la agordon de la nova Serva Monitoro; nun ni povas uzi ĝin dum kreado de naĝejo.
Agordo de Aplikaj Reguloj
Aplikaj Reguloj estas maniero manipuli trafikon bazitan sur certaj ellasiloj. Per ĉi tiu ilo ni povas krei altnivelajn regulojn pri ekvilibro de ŝarĝo, kiuj eble ne eblas per Aplikaj profiloj aŭ aliaj servoj disponeblaj ĉe Edge Gateway.
- Por krei regulon, iru al la langeto Aplikaj Reguloj de la ekvilibristo.
- Elektu nomon, skripton, kiu uzos la regulon, kaj alklaku Konservu.
- Post kiam la regulo estas kreita, ni devas redakti la jam agordita Virtuala Servilo.
- En la Altnivela langeto, aldonu la regulon, kiun ni kreis.
En la supra ekzemplo ni ebligis tlsv1-subtenon.
Kelkaj pliaj ekzemploj:
Redirekta trafiko al alia naĝejo.
Kun ĉi tiu skripto ni povas redirekti trafikon al alia ekvilibra naĝejo se la ĉefa naĝejo estas malfunkcia. Por ke la regulo funkciu, pluraj naĝejoj devas esti agorditaj sur la ekvilibristo kaj ĉiuj membroj de la ĉefa naĝejo devas esti en la malsupra stato. Vi devas specifi la nomon de la naĝejo, ne ĝian ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirekta trafiko al ekstera rimedo.
Ĉi tie ni redirektas trafikon al la ekstera retejo se ĉiuj membroj de la ĉefa naĝejo estas malfunkciaj.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Eĉ pli da ekzemploj .
Tio estas ĉio por mi pri la ekvilibristo. Se vi havas demandojn, demandu, mi pretas respondi.
fonto: www.habr.com