Balansiranje opterećenja mreže. Što je balansiranje opterećenja? Što izabrati

O pitanju planiranja opterećenja treba odlučiti u ranoj fazi razvoja bilo kojeg web projekta. "Pad" poslužitelja (a uvijek se događa neočekivano, u najneprikladnijem trenutku) prepun je vrlo ozbiljnih posljedica - moralnih i materijalnih. U početku problemi nedovoljne performanse poslužitelja zbog povećanja opterećenja mogu se riješiti povećanjem snage poslužitelja ili optimizacijom korištenih algoritama, programskih kodova i sl. Ali prije ili kasnije dođe trenutak kada se te mjere pokažu nedovoljnima.

Moramo pribjeći klasteriranju: nekoliko poslužitelja kombinira se u klaster; opterećenje se između njih raspoređuje skupom posebnih metoda koje se nazivaju balansiranje. Osim rješavanja problema velikih opterećenja, klasteriranje također pomaže osigurati da poslužitelji budu redundantni jedni prema drugima.
Učinkovitost klasteriranja izravno ovisi o tome kako je opterećenje raspoređeno (uravnoteženo) između elemenata klastera.

Balansiranje opterećenja može se izvršiti pomoću hardvera i softverski alati. Željeli bismo govoriti o glavnim metodama i algoritmima balansiranja u ovom članku.

Ravnotežne razine

Procedura balansiranja provodi se pomoću čitavog skupa algoritama i metoda koji odgovaraju sljedećim razinama OSI modela:

mreža;
prijevoz;
primijeniti

Pogledajmo ove razine detaljnije.

Balansiranje na razini mreže

Balansiranje na razini mreže uključuje rješavanje sljedećeg problema: morate biti sigurni da su različiti poslužitelji odgovorni za jednu određenu IP adresu fizički strojevi. Ovo balansiranje može se postići na mnogo različitih načina.

Balansiranje na transportnoj razini

Ovaj tip balansiranja je najjednostavniji: klijent kontaktira balansera koji preusmjerava zahtjev na jedan od poslužitelja koji će ga obraditi. Odabir poslužitelja na kojem će se zahtjev obrađivati može se provesti u skladu s različitim algoritmima (o tome će biti riječi u nastavku): jednostavnim kružnim pretraživanjem, odabirom najmanje opterećenog poslužitelja iz skupa itd.

Ponekad balansirajući transportni sloj teško razlikovati od balansiranja na razini mreže. Razmotrimo sljedeće pravilo Za zaštita od prenapona pf u BSD sustavima: na primjer, formalno ovdje govorimo o o uravnoteženju prometa na određenom TCP priključak(primjer za pf mrežni filter na BSD sustavima):

Web_servers = "( 10.0.0.10, 10.0.0.11, 10.0.0.13 )" odgovara na $ext_if proto tcp portu 80 rdr-to $web_servers kružna ljepljiva adresa

Govori o balansiranju prometa na određenom TCP priključku.

Pogledajmo sada još jedan primjer:

Prijeđi na $int_if od $lan_net \route-to ( ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) )\ kružno

Ovo pravilo govori o balansiranju odlaznog prometa na razini mreže. Ne specificira određeni port ili određeni protokol.

Razlika između razina uravnoteženja može se objasniti na sljedeći način. Mrežna razina uključuje rješenja koja ne prekidaju korisničke sesije. Oni jednostavno preusmjeravaju promet i ne rade u proxy modu.
Na razini mreže, balanser jednostavno odlučuje kojem će poslužitelju proslijediti pakete. Sesiju s klijentom provodi poslužitelj.

Na transportnom sloju komunikacija s klijentom ograničena je na balanser koji radi kao proxy. On komunicira s poslužiteljima u svoje ime, prosljeđujući informacije o klijentu u dodatnim podacima i zaglavljima. Tako radi, primjerice, popularni softverski balanser HAProxy.

Balansiranje na razini aplikacije

Prilikom balansiranja na razina primjene Balanser radi u "pametnom proxy" načinu rada. Analizira zahtjeve klijenata i preusmjerava ih na različite poslužitelje ovisno o prirodi traženog sadržaja. Ovako, na primjer, radi web poslužitelj Nginx, distribuirajući zahtjeve između frontenda i backenda. Upstream modul odgovoran je za balansiranje u Nginxu. Možete pročitati više o značajkama Nginx balansiranja na temelju različitih algoritama, na primjer.

Drugi primjer alata za balansiranje na razini aplikacije je pgpool - srednji sloj između klijenta i PostgreSQL DBMS poslužitelja. Uz njegovu pomoć možete distribuirati zahtjeve poslužiteljima baza podataka ovisno o njihovom sadržaju: na primjer, zahtjevi za čitanje bit će poslani na jedan poslužitelj, a zahtjevi za pisanje na drugi. Više o pgpoolu i specifičnostima rada s njim možete pročitati u ovom članku).

Algoritmi i metode balansiranja

Postoji mnogo različitih algoritama i metoda za uravnoteženje opterećenja. Prilikom odabira određenog algoritma morate krenuti, prvo, od specifičnosti određenog projekta, a drugo, od ciljeva. što planiramo postići.

Među ciljevima za koje se koristi balansiranje treba istaknuti sljedeće:

pravednost: Morate osigurati da postoje dodijeljeni resursi za obradu svakog zahtjeva. resursi sustava i spriječiti situacije da se jedan zahtjev obrađuje dok svi ostali čekaju na svoj red;
učinkovitost: svi poslužitelji koji obrađuju zahtjeve moraju biti 100% zauzeti; preporučljivo je izbjegavati situaciju u kojoj jedan od poslužitelja miruje čekajući zahtjeve za obradu (odmah napravimo rezervaciju da se u stvarnoj praksi ovaj cilj ne postiže uvijek);
smanjenje vremena izvršavanja upita: morate osigurati minimalno vrijeme između početka obrade zahtjeva (ili njegovog stavljanja u red čekanja za obradu) i njegovog završetka;
smanjeno vrijeme odziva: moramo minimizirati vrijeme odgovora na zahtjev korisnika.

Također je vrlo poželjno da algoritam za uravnoteženje ima sljedeća svojstva:

predvidljivost: morate jasno razumjeti u kojim će situacijama i pod kojim opterećenjima algoritam biti učinkovit u rješavanju zadanih problema;
skalabilnost: Algoritam mora ostati operativan kako se opterećenje povećava.

Razigravanje

Round Robin, ili algoritam kružne usluge, je kružno pretraživanje: prvi zahtjev se šalje jednom poslužitelju, zatim se sljedeći zahtjev šalje drugom, i tako dalje sve dok posljednji poslužitelj, a onda sve kreće ispočetka.

Najčešća implementacija ovog algoritma je, naravno, Round Robin DNS metoda balansiranja. Kao što znate, svaki DNS poslužitelj pohranjuje par "naziv glavnog računala - IP adresa" za svaki stroj u određenoj domeni. Ovaj popis može izgledati ovako, na primjer:

Primjer.com xxx.xxx.xxx.2 www.example.com xxx.xxx.xxx.3

Svako ime na popisu može imati više IP adresa povezanih s njim:

Example.com xxx.xxx.xxx.2 www.example.com xxx.xxx.xxx.3 www.example.com xxx.xxx.xxx.4 www.example.com xxx.xxx.xxx.5 www.example. com xxx.xxx.xxx.6

DNS poslužitelj prolazi kroz sve unose u tablici i vraća se na svaki novi zahtjev sljedeću IP adresu: na primjer, za prvi zahtjev - xxx.xxx.xxx.2, za drugi - xxx.xxx.xxx.3, i tako dalje. Kao rezultat toga, svi poslužitelji u klasteru primaju isti broj zahtjeva.

Među nedvojbenim prednostima ovog algoritma je, prvo, neovisnost o protokolu visoka razina. Za rad s Round Robin algoritmom koristi se bilo koji protokol u kojem se poslužitelju pristupa imenom.
Balansiranje temeljeno na Round Robin algoritmu ni na koji način ne ovisi o opterećenju poslužitelja: predmemoriranje DNS poslužitelja pomoći će u suočavanju s bilo kakvim priljevom klijenata.

Korištenje Round Robin algoritma ne zahtijeva komunikaciju između poslužitelja, tako da se može koristiti i za lokalno i za globalno balansiranje.
Konačno, rješenja koja se temelje na Round Robin algoritmu jeftina su: jednostavno trebaju dodati nekoliko unosa u DNS kako bi počela raditi.

Round Robin algoritam također ima niz značajne nedostatke nedostatke. Kako bi raspodjela opterećenja pomoću ovog algoritma zadovoljila gore navedene kriterije pravednosti i učinkovitosti, svaki poslužitelj mora imati isti skup dostupnih resursa. Sve operacije također moraju koristiti istu količinu resursa. U stvarnoj praksi ti su uvjeti u većini slučajeva neispunjeni.

Također, kod balansiranja korištenjem Round Robin algoritma uopće se ne uzima u obzir radno opterećenje pojedinog poslužitelja u klasteru. Zamislimo sljedeću hipotetsku situaciju: jedan od čvorova je 100% opterećen, dok su ostali samo 10 - 15% opterećeni. Round Robin algoritam ne uzima u obzir mogućnost nastanka takve situacije, pa će preopterećeni čvor ipak primati zahtjeve. U ovom slučaju ne može biti govora o pravdi, učinkovitosti ili predvidljivosti.

Zbog gore opisanih okolnosti, opseg primjene Round Robin algoritma je vrlo ograničen.

Ponderirani Round Robin

Ovo je poboljšana verzija algoritma Round Robin. Suština poboljšanja je sljedeća: svakom poslužitelju se dodjeljuje težinski koeficijent u skladu s njegovom izvedbom i snagom. To pomaže u fleksibilnijoj raspodjeli opterećenja: poslužitelji s većom težinom obrađuju više zahtjeva. Međutim, to ne rješava sve probleme s tolerancijom grešaka. Učinkovitije uravnoteženje osiguravaju druge metode, u kojima se pri planiranju i raspodjeli opterećenja uzima u obzir veći broj parametara.

Najmanje veza

U prethodnom odjeljku naveli smo glavne nedostatke Round Robin algoritma. Navedimo još jednu: ne uzima u obzir broj aktivnih ovaj trenutak veze.

Pogledajmo praktičan primjer. Postoje dva poslužitelja — nazovimo ih A i B. Manje je korisnika spojenih na poslužitelj A nego na poslužitelj B. U isto vrijeme poslužitelj A je preopterećeniji. Kako je ovo moguće? Odgovor je vrlo jednostavan: veze s poslužiteljem A održavaju se duže vrijeme u usporedbi s vezama s poslužiteljem B.

Opisani problem se može riješiti korištenjem algoritma poznatog kao najmanje veze (skraćeno kao minimumconn). Uzima u obzir broj veza koje podržavaju poslužitelji u trenutnom trenutku. Svako sljedeće pitanje šalje se poslužitelju s najmanje aktivnih veza.

Postoji poboljšana verzija ovog algoritma, prvenstveno namijenjena za korištenje u klasterima koji se sastoje od poslužitelja s različitim tehničke karakteristike I drugačija izvedba. Zove se Weighted Least Connections i pri raspodjeli opterećenja uzima u obzir ne samo broj aktivnih veza, već i težinski koeficijent poslužitelja.

Druge napredne verzije algoritma najmanje veze uključuju planiranje najmanje veze temeljeno na lokaciji i planiranje najmanje veze temeljeno na lokaciji s planiranjem replikacije.

Prva metoda stvorena je posebno za predmemoriranje proxy poslužitelja. Njegova suština je sljedeća: najveći broj zahtjevi se šalju poslužiteljima s najmanje aktivnih veza. Iza svake klijentski poslužitelji dodijeljena je grupa IP adresa klijenata. Zahtjevi s tih IP-ova šalju se "nativnom" poslužitelju ako nije u potpunosti učitan. U suprotnom, zahtjev će biti preusmjeren na drugi poslužitelj (trebao bi biti manje od pola učitan).

U algoritmu za planiranje najmanje veze na temelju lokacije s rasporedom replikacije, svaka IP adresa ili grupa IP adresa nije dodijeljena zasebni poslužitelj, ali iza cijele grupe poslužitelja. Zahtjev se šalje najmanje opterećenom poslužitelju u grupi. Ako su svi poslužitelji iz “native” grupe preopterećeni, tada će novi poslužitelj biti rezerviran. Ovaj novi poslužitelj bit će dodan u grupu koja opslužuje IP s kojeg je zahtjev poslan. S druge strane, najopterećeniji poslužitelj iz ove grupe bit će izbrisan - time se izbjegava suvišna replikacija.

Raspored raspršivanja odredišta i Raspored raspršivanja izvora

Algoritam odredišnog raspoređivanja raspršivanja stvoren je za rad s klasterom proksija za predmemoriju, ali se često koristi u drugim slučajevima. U ovom algoritmu, poslužitelj koji obrađuje zahtjev odabire se iz statičke tablice na temelju IP adrese primatelja.

Algoritam Source Hash Scheduling temelji se na istim principima kao i prethodni, samo se poslužitelj koji će obraditi zahtjev bira iz tablice prema IP adresi pošiljatelja.

Ljepljive sesije

Sticky Sessions je algoritam za distribuciju dolaznih zahtjeva, u kojem se veze prenose na isti poslužitelj u grupi. Koristi se, primjerice, u web poslužitelju Nginx. Korisničke sesije mogu se dodijeliti određenom poslužitelju koristeći IP hash metodu ( detaljne informacije o tome vidi službenu dokumentaciju). Ovom metodom zahtjevi se distribuiraju poslužiteljima na temelju klijentove IP adrese. Kao što je navedeno u dokumentaciji (pogledajte vezu iznad), "metoda osigurava da će zahtjevi od istog klijenta biti poslani na isti poslužitelj." Ako je poslužitelj dodijeljen određenoj adresi nedostupan, zahtjev će biti preusmjeren na drugi poslužitelj. Primjer fragmenta konfiguracijske datoteke:

Upstream pozadina ( ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com; server backend4.example.com; )

Počevši od verzije 1.2.2 u Nginxu, možete odrediti težinu za svaki poslužitelj.

Postoje neki problemi s ovom metodom. Problemi s vezanjem sesije mogu se pojaviti ako klijent koristi dinamički IP. U situaciji kada veliki broj zahtjevi prolaze kroz jedan proxy poslužitelj, balansiranje se teško može nazvati učinkovitim i poštenim. Opisani problemi se, međutim, mogu riješiti korištenjem kolačića. U komercijalna verzija Nginx ima poseban ljepljivi modul koji koristi kolačiće za balansiranje. On također ima besplatni analozi- na primjer, nginx-sticky-module.
Možete koristiti metodu sticky-sessions u HAProxyju - možete pročitati više o tome, na primjer,

Zaključak

Ovaj je članak u biti uvod u balansiranje opterećenja. Nastavit ćemo raspravu o ovoj temi u budućim publikacijama. Ako imate pitanja, komentara ili dodataka, dobrodošli u komentare. Također ćemo vam biti zahvalni ako podijelite ne-trivijalne praktični primjeri organiziranje balansiranja opterećenja za razne projekte.

Čitatelji koji iz ovog ili onog razloga ne mogu ovdje ostaviti komentare, pozvani smo na naš blog.

Oznake:

uravnoteženje opterećenja
Selectel
selectel

Dodaj oznake

Balansiranje opterećenja može se izvršiti pomoću hardverskih i softverskih alata. Željeli bismo govoriti o glavnim metodama i algoritmima balansiranja u ovom članku.

Ravnotežne razine

Procedura balansiranja provodi se pomoću čitavog skupa algoritama i metoda koji odgovaraju sljedećim razinama OSI modela:

mreža;
prijevoz;
primijeniti

Pogledajmo ove razine detaljnije.

Balansiranje na razini mreže

Balansiranje na mrežnoj razini uključuje rješavanje sljedećeg problema: morate biti sigurni da su različiti fizički strojevi odgovorni za jednu specifičnu IP adresu poslužitelja. Ovo balansiranje može se postići na mnogo različitih načina.

Balansiranje na transportnoj razini

Ponekad je balansiranje na transportnom sloju teško razlikovati od balansiranja na mrežnom sloju. Razmotrite sljedeće pravilo za pf mrežni filtar u BSD sustavima: na primjer, formalno govorimo o balansiranju prometa na određenom TCP priključku (primjer za pf mrežni filtar u BSD sustavima):

Web_servers = "( 10.0.0.10, 10.0.0.11, 10.0.0.13 )" odgovara na $ext_if proto tcp portu 80 rdr-to $web_servers kružna ljepljiva adresa

Govori o balansiranju prometa na određenom TCP priključku.

Pogledajmo sada još jedan primjer:

Prijeđi na $int_if od $lan_net \route-to ( ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) )\ kružno

Ovo pravilo govori o balansiranju odlaznog prometa na razini mreže. Ne specificira određeni port ili određeni protokol.

Balansiranje na razini aplikacije

Prilikom balansiranja na razini aplikacije, balanser radi u "pametnom proxy" načinu rada. Analizira zahtjeve klijenata i preusmjerava ih na različite poslužitelje ovisno o prirodi traženog sadržaja. Ovako, na primjer, radi web poslužitelj Nginx, distribuirajući zahtjeve između frontenda i backenda. Upstream modul odgovoran je za balansiranje u Nginxu. Možete pročitati više o značajkama Nginx balansiranja na temelju različitih algoritama, na primjer.

Algoritmi i metode balansiranja

Među ciljevima za koje se koristi balansiranje treba istaknuti sljedeće:

pravednost: potrebno je osigurati da su resursi sustava alocirani za obradu svakog zahtjeva i spriječiti situacije da se jedan zahtjev obrađuje dok svi ostali čekaju u redu;
učinkovitost: svi poslužitelji koji obrađuju zahtjeve moraju biti 100% zauzeti; preporučljivo je izbjegavati situaciju u kojoj jedan od poslužitelja miruje čekajući zahtjeve za obradu (odmah napravimo rezervaciju da se u stvarnoj praksi ovaj cilj ne postiže uvijek);
smanjenje vremena izvršavanja upita: morate osigurati minimalno vrijeme između početka obrade zahtjeva (ili njegovog stavljanja u red čekanja za obradu) i njegovog završetka;
smanjeno vrijeme odziva: moramo minimizirati vrijeme odgovora na zahtjev korisnika.

Također je vrlo poželjno da algoritam za uravnoteženje ima sljedeća svojstva:

predvidljivost: morate jasno razumjeti u kojim će situacijama i pod kojim opterećenjima algoritam biti učinkovit u rješavanju zadanih problema;
skalabilnost: Algoritam mora ostati operativan kako se opterećenje povećava.

Razigravanje

Round Robin, ili round-robin algoritam, je kružno pretraživanje: prvi zahtjev se šalje jednom poslužitelju, zatim se sljedeći zahtjev šalje drugom, i tako dalje dok se ne dođe do posljednjeg poslužitelja, a onda sve počinje ispočetka.

Primjer.com xxx.xxx.xxx.2 www.example.com xxx.xxx.xxx.3

Svako ime na popisu može imati više IP adresa povezanih s njim:

Example.com xxx.xxx.xxx.2 www.example.com xxx.xxx.xxx.3 www.example.com xxx.xxx.xxx.4 www.example.com xxx.xxx.xxx.5 www.example. com xxx.xxx.xxx.6

DNS poslužitelj prolazi kroz sve unose u tablici i daje sljedeću IP adresu za svaki novi zahtjev: na primjer, za prvi zahtjev - xxx.xxx.xxx.2, za drugi - xxx.xxx.xxx.3, i tako dalje. Kao rezultat toga, svi poslužitelji u klasteru primaju isti broj zahtjeva.

Među nedvojbenim prednostima ovog algoritma je, prvo, neovisnost o protokolu visoke razine. Za rad s Round Robin algoritmom koristi se bilo koji protokol u kojem se poslužitelju pristupa imenom.
Balansiranje temeljeno na Round Robin algoritmu ni na koji način ne ovisi o opterećenju poslužitelja: predmemoriranje DNS poslužitelja pomoći će u suočavanju s bilo kakvim priljevom klijenata.

Round Robin algoritam također ima niz značajnih nedostataka. Kako bi raspodjela opterećenja pomoću ovog algoritma zadovoljila gore navedene kriterije pravednosti i učinkovitosti, svaki poslužitelj mora imati isti skup dostupnih resursa. Sve operacije također moraju koristiti istu količinu resursa. U stvarnoj praksi ti su uvjeti u većini slučajeva neispunjeni.

Zbog gore opisanih okolnosti, opseg primjene Round Robin algoritma je vrlo ograničen.

Ponderirani Round Robin

Najmanje veza

U prethodnom odjeljku naveli smo glavne nedostatke Round Robin algoritma. Navedimo još jednu: uopće ne uzima u obzir broj trenutno aktivnih veza.

Postoji poboljšana verzija ovog algoritma, namijenjena prvenstveno za korištenje u klasterima koji se sastoje od poslužitelja različitih tehničkih karakteristika i različitih performansi. Zove se Weighted Least Connections i pri raspodjeli opterećenja uzima u obzir ne samo broj aktivnih veza, već i težinski koeficijent poslužitelja.

Druge napredne verzije algoritma najmanje veze uključuju planiranje najmanje veze temeljeno na lokaciji i planiranje najmanje veze temeljeno na lokaciji s planiranjem replikacije.

Prva metoda stvorena je posebno za predmemoriranje proxy poslužitelja. Njegova je bit sljedeća: najveći broj zahtjeva šalje se poslužiteljima s najmanje aktivnih veza. Svakom klijentskom poslužitelju dodijeljena je grupa klijentskih IP adresa. Zahtjevi s ovih IP-ova šalju se "nativnom" poslužitelju ako nije u potpunosti učitan. U suprotnom, zahtjev će biti preusmjeren na drugi poslužitelj (trebao bi biti manje od pola učitan).

U algoritmu za planiranje najmanje veze na temelju lokacije s rasporedom replikacije, svaka IP adresa ili grupa IP adresa nije dodijeljena pojedinačnom poslužitelju, već cijeloj grupi poslužitelja. Zahtjev se šalje najmanje opterećenom poslužitelju u grupi. Ako su svi poslužitelji iz “native” grupe preopterećeni, tada će novi poslužitelj biti rezerviran. Ovaj novi poslužitelj bit će dodan u grupu koja opslužuje IP s kojeg je zahtjev poslan. S druge strane, najopterećeniji poslužitelj iz ove grupe bit će izbrisan - time se izbjegava suvišna replikacija.

Raspored raspršivanja odredišta i Raspored raspršivanja izvora

Algoritam Source Hash Scheduling temelji se na istim principima kao i prethodni, samo se poslužitelj koji će obraditi zahtjev bira iz tablice prema IP adresi pošiljatelja.

Ljepljive sesije

Sticky Sessions je algoritam za distribuciju dolaznih zahtjeva, u kojem se veze prenose na isti poslužitelj u grupi. Koristi se, primjerice, u web poslužitelju Nginx. Korisničke sesije mogu se dodijeliti određenom poslužitelju koristeći IP hash metodu (za detalje pogledajte službenu dokumentaciju). Ovom metodom zahtjevi se distribuiraju poslužiteljima na temelju klijentove IP adrese. Kao što je navedeno u dokumentaciji (pogledajte vezu iznad), "metoda osigurava da će zahtjevi od istog klijenta biti poslani na isti poslužitelj." Ako je poslužitelj dodijeljen određenoj adresi nedostupan, zahtjev će biti preusmjeren na drugi poslužitelj. Primjer fragmenta konfiguracijske datoteke:

Upstream pozadina ( ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com; server backend4.example.com; )

Počevši od verzije 1.2.2 u Nginxu, možete odrediti težinu za svaki poslužitelj.

Postoje neki problemi s ovom metodom. Problemi s vezanjem sesije mogu se pojaviti ako klijent koristi dinamički IP. U situaciji kada veliki broj zahtjeva prolazi kroz jedan proxy poslužitelj, balansiranje se teško može nazvati učinkovitim i poštenim. Opisani problemi se, međutim, mogu riješiti korištenjem kolačića. Komercijalna verzija Nginxa ima poseban ljepljivi modul koji koristi kolačiće za balansiranje. Također ima besplatne analoge - na primjer, nginx-sticky-module.
Možete koristiti metodu sticky-sessions u HAProxyju - možete pročitati više o tome, na primjer,

Zaključak

Ovaj je članak u biti uvod u balansiranje opterećenja. Nastavit ćemo raspravu o ovoj temi u budućim publikacijama. Ako imate pitanja, komentara ili dodataka, dobrodošli u komentare. Također ćemo vam biti zahvalni ako podijelite ne-trivijalne praktične primjere organiziranja uravnoteženja opterećenja za različite projekte.

Čitatelji koji iz ovog ili onog razloga ne mogu ovdje ostaviti komentare, pozvani smo na naš blog.

Oznake: Dodajte oznake

U terminologiji računalnih mreža, uravnoteženje opterećenja je raspodjela procesa izvršenja zadatka između nekoliko mrežnih poslužitelja kako bi se optimiziralo korištenje resursa i smanjilo vrijeme računanja.

Vrste poslužitelja koje treba balansirati:

klasteri poslužitelja;

vatrozidi;

poslužitelji za pregled sadržaja (kao što su AntiVirus ili AntiSpam poslužitelji).

Tipično, sustavi za uravnoteženje opterećenja poslužitelja koriste L4 mogućnosti (UDP/TCP). U tom se slučaju dostupnost poslužitelja prati prema IP adresi i broju porta te se donosi odluka: koji od dostupnih poslužitelja zahtjev treba proslijediti. Najčešće se za odabir poslužitelja koristi kružni algoritam. Ova opcija pretpostavlja da svi zahtjevi generiraju isto opterećenje i trajanje izvršenja. Naprednije verzije algoritma koriste razinu popunjenosti poslužitelja i broj aktivnih veza.

Prethodno su mogućnosti balansiranja opterećenja bile ugrađene u aplikacijski program ili operativni sustav. Suvremeni sustavi za uravnoteženje opterećenja moraju ispunjavati sljedeće zahtjeve:

pružiti upravljanje prometom jamčiti dostupnost aplikacije i raspodjelu opterećenja u farmi poslužitelja (skupina poslužitelja povezanih podatkovnom mrežom i rade kao jedna cjelina);

ubrzati izvršenje aplikacije nekoliko puta;

jamčiti zaštita aplikacije, sigurnost podataka i nadzor prometa.

Ovdje je važno napomenuti da dostupnost IP adrese i priključka ne jamči pristup aplikaciji.

Nedavno se aplikacijski sloj sve više koristi za rješavanje problema uravnoteženja opterećenja. Proces donošenja odluke uzima u obzir vrstu klijenta, traženi URL, informacije iz kolačića, mogućnosti konkretnog poslužitelja i vrstu aplikacijskog programa, što omogućuje optimizaciju korištenja resursa sustava.

Prilično značajne prednosti može pružiti sustav GSLB (Global Server Load Balancing), koji je sposoban riješiti problem balansiranja za nasumično locirane farme poslužitelja, uzimajući u obzir njihovu udaljenost od klijenta. Ovaj sustav može podržati nekoliko različitih algoritama za uravnoteženje opterećenja i pružiti optimalnu uslugu klijentima razasutim diljem svijeta. Za administratore, sustav omogućuje stvaranje fleksibilne politike upravljanja resursima.

Jedan od načina da se ubrza usluga je predmemorija. U slučaju dobro konfigurirane predmemorije, postotak zahtjeva koje je predmemorija zadovoljila može doseći 40%. U isto vrijeme, ubrzanje usluge može se poboljšati za 30 puta.

Drugi način za ubrzavanje usluge može biti arhiviranje podataka, budući da se ovom opcijom smanjuje razina zagušenja mrežnih kanala.

Upravljanje balansiranjem opterećenja može se kombinirati s funkcijom vatrozida aplikacije (70% uspješnih upada iskorištava ranjivosti aplikacije) i korištenjem SSL-a preko VPN tunela. SSL – Secure Sockets Layer – je kriptografski protokol koji osigurava uspostavljanje sigurne veze između klijenta i poslužitelja.

Kako bi se postigla maksimalna propusnost i tolerancija na pogreške, vatrozidi vam omogućuju distribuciju ili ravnotežu opterećenja korištenjem svih dostupnih internetskih kanala (poslužitelja) istovremeno. Na primjer, možete izbjeći situaciju da paketi koji se prenose preko mreže prolaze preko jednog pružatelja usluga, dok je pristup Internetu preko drugog pružatelja usluga u stanju mirovanja. Ili distribuirati usluge i usmjeravati promet kroz sve dostupne internetske kanale. Moguće je konfigurirati balansiranje opterećenja ako se veze s pružateljima ostvaruju s različitim tipovima veze (Statični IP, PPPoE, PPTP/L2TP), kao i balansirati promet koji prolazi kroz VPN tunele instalirane na različitim fizičkim sučeljima.

Riža. 4.12. Balansiranje opterećenja na više ruta

D-Link NetDefend serija vatrozida pruža funkciju dizajniranu za ravnotežu mrežnog opterećenja na različitim rutama - Ruta Opterećenje Balansiranje (RLB) , čije mogućnosti pružaju:

balansiranje prometa između sučelja na temelju politika;

uravnoteženje opterećenja prometa uz istovremeni višestruki pristup Internetu, koristeći usluge dvaju ili više pružatelja;

balansiranje prometa koji prolazi kroz VPN tunele instalirane na različitim fizičkim sučeljima.

Značajka uravnoteženja opterećenja u vatrozidima NetDefend omogućena je na temelju tablice usmjeravanja stvaranjem RLB objekta Primjer, u kojem su definirana dva parametra: tablica usmjeravanja i RLB algoritam. Samo jedan objekt instance može biti povezan s tablicom usmjeravanja.

Riža. 4.13. Odabir algoritma za uravnoteženje opterećenja u NetDefend vatrozidima

Moguće je odabrati jedan od algoritama raspodjele opterećenja između internetskih sučelja:

Algoritam Razigravanje raspodjeljuje opterećenje između WAN1 i WAN2 sučelja sekvencijalno (naizmjenično). Svaki put kada se pojavi nova odlazna sesija s LAN sučelja, sučelje WAN1 ili WAN2 odabire se za slanje paketa. Ubuduće će paketi iz ove sesije koristiti prethodno definirano WAN sučelje. TCP sesija se otvara i zatvara na istom WAN sučelju.

Algoritam Odredišteće izbjeći probleme s nekim protokolima pri korištenju balansiranja, na primjer FTP. Ovaj algoritam radi slično kao Round Robin algoritam, osim što svi podaci do udaljenog računala idu kroz sučelje preko kojeg je veza uspostavljena.

Značenje Prelijevanje definira ograničenje opterećenja za glavni WAN port ( Usmjeravanje → Balansiranje opterećenja rute > Postavke algoritma) . Kada se ovo opterećenje dosegne unutar navedenog razdoblja, drugi WAN port će se početi koristiti (za nove sesije). Čim opterećenje glavnog kanala padne, na njemu će se otvoriti nove sesije.

KrugRobin

Zadana metrika svake rute je nula. Pri korištenju međusobno povezanih algoritama Krug Robin I Odredište Možete postaviti različite metričke vrijednosti kako biste stvorili prioritet za odabir ruta. Rute s minimalnom metričkom vrijednošću birat će se češće nego rute s višom metričkom vrijednošću.

Ako u scenariju s dva davatelja internetskih usluga (često se koristi izraz "ISP"), tj. davatelj internetskih usluga, želite da većina prometa ide kroz jednu od ISP veza, tada biste trebali omogućiti RLB i dodijeliti nižu metriku vrijednost za rutu veze glavnog ISP-a (na primjer, 90) u odnosu na drugu (na primjer, 100).

Ako je zadatak ravnomjerno uravnotežiti promet između dva pružatelja internetskih usluga, tada bi metrička vrijednost za obje rute trebala biti dodijeljena ista.

Korištenje metrike rute s algoritmomPrelijevanje

Prilikom korištenja algoritma Prelijevanje Za svaku rutu mora se definirati metrika. U ovom slučaju, NetDefendOS uvijek odabire rutu s najnižom metričkom vrijednošću. Algoritam nije dizajniran za rad s istim metričkim vrijednostima ruta, stoga bi administrator trebao postaviti različite metričke vrijednosti za sve rute na koje se algoritam primjenjujePrelijevanje.

Vrijednost metričke vrijednosti određuje redoslijed kojim se promet preusmjerava na drugu rutu nakon što odabrana ruta premaši ograničenje prometa.

Možete stvoriti nekoliko alternativnih ruta s različitim metričkim vrijednostima, za svaku od kojih je definirana vrijednost praga za postavke algoritma - Prelijevanje Postavka– za svako sučelje. Prvo se odabire ruta s minimalnom metrikom; Nakon što se prekorači dopušteni prag postavki algoritma, bit će odabrana sljedeća ruta.

Ako su sve alternativne rute dosegle pragove postavki prelijevanja, ruta se ne mijenja.

PAŽNJA: Vrijednost metrike na sučeljima (rutama) koja se koriste u balansiranju treba postaviti više nego za druga sučelja (rute). Što je niža metrička vrijednost na sučelju (ruti), to će se ovo sučelje (ruta) češće koristiti za uspostavljanje veze, u odnosu na sučelje (rutu) s višom metričkom vrijednošću. Udio iskorištenosti sučelja (ruta) bit će proporcionalan razlici između metričkih vrijednosti na tim sučeljima (rutama).

Balansiranje opterećenja mreže i NA-klasteriranje (redundancija uređaja) vatrozidaNetDefend

Visoka razina tolerancije mrežnih grešaka postiže se upotrebom dva NetDefend vatrozida: glavni uređaj (master) i rezervni uređaj(rob). Primarni i rezervni vatrozid međusobno su povezani i čine logičan HA klaster.

Vatrozidi NetDefend ne podržavaj uravnoteženje opterećenja u HA-grupiranje uređaja, tj. raspodjela opterećenja između njih nije predviđeno, budući da je jedan uređaj uvijek aktivan (aktivan), dok je drugi u stanju mirovanja (pasivan).

Riža. 4.14. HA klasteriranje NetDefend vatrozida

Što je balansiranje opterećenja? Zapravo, ovo je raspodjela dolaznih mrežne veze između više računalnih čvorova. Istodobno, korištenje hardvera odn programska rješenja, kao i algoritam koji se koristi za distribuciju esencije, uopće se ne mijenja. Ali zahvaljujući raspodjeli opterećenja mogu se riješiti dva prilično ozbiljna problema.
Prvo, to je raspodjela opterećenja između računalnih čvorova u situaciji kada resursi jednog poslužitelja nisu dovoljni i vertikalno širenje njegove snage više nije moguće. U tom slučaju potrebno je dodati još jednu računsku jedinicu i koristiti jednu od vrsta balansiranja.
Drugo, osiguravanje pristupačnosti. Kao što je poznato, otpornost na pogreške bilo kojeg sustava hardversko rješenje ili softver se postiže dupliciranjem glavnih komponenti. Nažalost, apsolutno ne postoji pouzdan tvrdi diskovi, RAID kontroleri i druga oprema, i moderna razina programiranje ne jamči nepostojanje kvarova u softveru. Iz tog razloga, prilikom izgradnje servisa otpornih na pogreške, sve se duplicira, mrežni kontroleri, preklopnici i, u konačnici, sami računalni čvorovi. Na primjer, opterećenje stvoreno na jednom poslužitelju možda nije veliko, ali u isto vrijeme želite osigurati da kvar jednog ili više čvorova ne dovede do prekida usluge. U ovom slučaju, balanser opterećenja opet može biti rješenje.

Osnovne vrste i tehnike balansiranja

Uglavnom sve postojeće vrste balansiranje se može podijeliti na tri globalne grupe razlikuju se u "dubini" analize pristiglih zahtjeva i stupnju provjere dostupnosti poslužitelja.

Primitivne metode

U ovu skupinu spadaju metode balansiranja koje se ni na koji način ne analiziraju dolazni promet i ne provjeravaju dostupnost računalnih čvorova koji se nalaze iza njih. Najviše svijetli predstavnik dana grupa, ovo je distribucija zahtjeva sa koristeći DNS o čemu u nastavku.

Round robin DNS

Možda najčešća metoda. To se temelji na činjenici da DNS specifikacija dopušta stvaranje više identičnih A zapisa s različitim IP adresama. Na primjer, možete stvoriti dva unosa za čvor srv-01.company.com s različitim IP adresama koje pripadaju, različite poslužitelje. Dodatno, posebna opcija (Round robin) mora biti uključena na DNS poslužitelju. Kao rezultat toga, sa svakim novim zahtjevom za zapis srv-01.company.com, dat će se različite IP adrese, što će dovesti do ravnomjerne raspodjele veza između čvorova.
Ali, unatoč svoj lakoći i jeftinoći ovu odluku, postoje brojna ograničenja. Prvo, ne postoje metode za provjeru dostupnosti čvorova. To jest, poslužitelj može pasti, ali DNS će i dalje davati svoju IP adresu klijentima. Drugo, broj trenutnih sesija na određenom čvoru se ne uzima u obzir. Može doći do situacije kada jedan od poslužitelja ima značajno više otvorenih sesija od ostalih, ali će veze i dalje biti ravnomjerno raspoređene. I treće, DNS ne uzima u obzir na koji je poslužitelj korisnik bio spojen posljednji put. Moguće je da će se sa svakom novom vezom, na primjer, na terminal ili na web poslužitelj, otvoriti nova sesija na drugom čvoru, što možda nije poželjno.
Zasebno, u ovom trenutku želio bih istaknuti usluge poput Amazon Route 53. Ovo je DNS hosting u oblaku koji vam omogućuje osim standardne karakteristike, označavaju "težinu" identičnih A-zapisa, što vam omogućuje fleksibilniju distribuciju dolaznih zahtjeva. Osim toga, moguće je integrirati s balanserom opterećenja u oblaku Elastic Load Balancing koji je dostupan u Amazon Web Services, što vam omogućuje postizanje još finijeg balansiranja.

Također, primitivne metode uključuju ručno balansiranje.

Bit metode je podijeliti sve korisnike u nekoliko grupa i povezati ih razne servere. Na primjer, organizacija zapošljava dvoje terminalski poslužitelji jednake performanse se stvara prečac na radnoj površini za polovicu korisnika za spajanje na prvi poslužitelj, a za preostale korisnike na drugi. Dodatno, u slučaju kvara trenutnog čvora, kreira se prečac za povezivanje s drugim poslužiteljem koji će služiti kao rezerva. Možda je takva metoda primjenjiva samo u malim organizacijama, a svrha takve distribucije je upravo tolerancija na greške, a ne balansiranje. U ovom slučaju nema potrebe za dodatna oprema I softver, ali morat ćete malo ručno raditi.

Balansiranje transportne razine (L4)

Ovo je najuniverzalniji i najrašireniji mehanizam. Jednako primjenjivo za TCP i UDP protokoli, te sukladno tome mogu distribuirati promet s gotovo bilo koje usluge. Na ovoj se razini u dolaznim paketima provjeravaju samo IP adresa i broj odredišnog priključka. Ako odgovara jednom od pravila, promet će jednostavno biti preusmjeren na navedeni poslužitelji, koristeći sNAT mehanizam u na propisani način. Sadržaj paketa se ne provjerava. Također ne postoje posebne tehnike za provjeru dostupnosti računalnih čvorova. Izvedena jednostavna provjera dostupnost adrese i porta. Ako je port otvoren, poslužitelj se smatra dostupnim i zahtjevi mu se nastavljaju slati.
Većina popularnih softverskih i hardverskih balansera radi pomoću ovog mehanizma, uključujući balansiranje mrežnog opterećenja (NLB) koji se koristi u Windows poslužitelj. Ova kategorija također uključuje trenutno popularne usluge u oblaku kao što je gore spomenuto Elastic Load Balancing iz Amazona.

Balansiranje aplikacijskog sloja (L7)

Dinamički razvijajući oblik uravnoteženja opterećenja na razini aplikacije. Takvi balanseri se također nazivaju kontroleri isporuke aplikacija. Usmjeren na rad s protokolima visoke razine. Uglavnom HTTP\HTTPS. Ovdje su, kao iu slučaju prethodnog prikaza, opisana pravila. Kada se veza uspostavi na određenom portu, paketi se prosljeđuju na navedene adrese i portovi računalnih čvorova. No, prilikom odabira određenog poslužitelja za preusmjeravanje prometa na njega, u obzir se uzimaju vrsta klijenta, URL, sadržaj kolačića, traženi sadržaj i neki drugi parametri. Osim toga, provjera dostupnosti usluge na računalnim čvorovima provjerava se puno inteligentnije. Na primjer, može se zatražiti određeni URL i provjeriti njegov sadržaj.
Još jedan razlikovna značajka Ova vrsta iz L4 je da poslužitelji u klasteru možda nisu identični. Na primjer, neki čvorovi mogu posluživati statične podatke kao što su fotografije i videozapisi, dok drugi poslužitelji isporučuju sadržaj koristeći skripte, HTML i CSS. U tom slučaju se mogu kreirati pravila za svaku vrstu sadržaja s posebnim algoritmima za preusmjeravanje prometa razne skupine poslužitelji. U ovoj kategoriji postoji još jedna klasa balansera profila, kao što je Citrix NetScaler. Ovo rješenje je specijalizirano za uravnoteženje opterećenja i poboljšanje performansi Citrix proizvoda (XenApp, XenDesktop), kao i web aplikacija. Osim naprednog balansiranja, može izvršiti kompresiju sadržaja, moćno predmemoriju, osigurati enkripciju, kao i analizu i filtriranje prometa. To je samo mali dio njegove mogućnosti, koje zaslužuju poseban članak.

Kada kapacitet poslužitelja više nije dovoljan, postavlja se pitanje kojim putem dalje. Nadogradnja često ne osigurava proporcionalno povećanje i, štoviše, ne pruža potrebnu toleranciju na pogreške. Stoga, najviše pravi korak Bit će instaliran drugi poslužitelj koji će preuzeti dio opterećenja. Ostaje samo odabrati aplikaciju koja će omogućiti balansiranje.

Što izabrati?

Rješenja za uravnoteženje mrežnog opterećenja na prvi pogled izgledaju isto. Zapravo, mnoge tehnologije i algoritmi su uključeni u proces, tako da je nemoguće pronaći dva identična proizvoda. Neočigledne značajke mogu biti podrška za određene protokole (na primjer, samo HTTP ili bilo koji), postoje mnogi drugi parametri.

Osim toga, balanseri opterećenja mogu preusmjeriti klijentski promet na željeni poslužitelj na nekoliko načina. Najpopularnije: emitiranje mrežne adrese(Network Address Translation) i slanje putem TCP pristupnika. U prvom slučaju, balanser zamjenjuje IP adrese u paketu u hodu, čime skriva IP poslužitelja od klijenta i obrnuto. Ako je klijentov IP potreban krajnjoj aplikaciji za statistiku ili bilo koje druge operacije, obično se pohranjuje u X-Forwarded-for HTTP zaglavlju. Ako koristite drugi protokol, trebali biste osigurati implementaciju ove značajke. U slučaju TCP pristupnika, balanser može upravljati prometom na razini L4 (transport), pa čak i na razini aplikacije (L7). Da bi to učinio, uspostavlja vezu i gleda unutar paketa. Tipično, klijent i aplikacija razmjenjuju informacije putem balansera. No nedavno je konfiguracija poslužitelja s izravnim povratom (DSR) postala sve popularnija, kada odgovor s poslužitelja ide izravno klijentu, a ne preko uređaja za uravnoteženje opterećenja. Korištenje DSR-a smanjuje opterećenje balansera, ali ne dopušta korištenje kolačića i SSL dešifriranja. Ova metoda je red veličine brža od korištenja NAT balansiranja i omogućuje uslugama da vide stvarne IP adrese klijenata.

Također u sustavima možete pronaći različite metode balansiranje. Pogledajmo svrhu nekih od njih. U postavkama proizvoda mogu imati različita imena ili vlastite značajke implementacije, ali često im je bit ista.
Najjednostavniji je Round Robin DNS, to je poseban DNS poslužitelj koji sadrži nekoliko A-zapisa i njihovu težinu (opcionalno) te izdaje različite IP adrese kada to klijenti zatraže. Nedostaci su očiti. Nema apsolutno nikakve informacije o trenutnom opterećenju i stanju pozadine i ne uzima u obzir prethodne veze klijenata (DNS predmemorija malo izglađuje situaciju).

Postoji algoritam sličnog naziva, ali ostvarena sredstvima sam balanser - Round Robin. Svi su klijenti ravnomjerno raspoređeni po pozadinama i obično se nikakvi drugi parametri ne uzimaju u obzir. Ponderirani algoritam Round Robin uzima u obzir parametar težine naveden za svaki poslužitelj. Dodjeljujući veću težinu snažnijem poslužitelju, moći ćemo na njega usmjeriti više klijenata. Prioritetna distribucija funkcionira nešto drugačije. U ovom algoritmu radi samo poslužitelj s visokim prioritetom; ostali se povezuju, u pravilu, samo ako ne uspije. Ova vam opcija omogućuje izgradnju klastera s jednim aktivni čvor, na primjer, kada drugi poslužitelj obavlja drugu ulogu i samo sigurnosno kopira prvi. Druga opcija je najmanja veza (najmanja sesija) - vezu prihvaća poslužitelj koji opslužuje najmanji broj veza (sesija), ali veze mogu biti različite (korisnik je aktivan ili pasivan) i, sukladno tome, različito opteretiti poslužitelj. Ali algoritam najmanje propusnosti uzima u obzir stvarno opterećenje mreže.

Hash sticky client - klijent je vezan za jedan poslužitelj; za to se hash string koji označava njegovu IP adresu stavlja u posebnu tablicu. Varijacije su moguće. Klijent uvijek ide na jedan poslužitelj, a ako ode, veza je nemoguća. Ili, kada "nativni" ne reagira, povezuje se s drugim sustavima.

Dostupnost pozadina određena je s dva: aktivnim (keepalives, sam balanser provjerava poslužitelje) i pasivnim (In-Band, trenutne veze i odgovori servisa se prate).

BalanceNG

Projekt broj jedan na listi - BalanceNG, je razvoj Otvoreni izvor Balance rješenja, ali će se distribuirati pod dvostrukom licencom (komercijalnom i besplatno Osnovna licenca). U besplatna verzija možete spojiti jedan virtualni poslužitelj i dva čvora, što je s obzirom na mogućnosti dovoljno da se lako nosite s prosječnim, a ponekad težak teret. To je IP rješenje za uravnoteženje opterećenja koje podržava IPv6 i nudi nekoliko metoda kontrole odabira pozadine (Round Robin, Random, Weighted Random, Least Session, Least Bandwidth, Hash, Agent i Randomized Agent).

Proizvod koristi izvorni mehanizam koji radi na sloju 2 (Ethernet), balansiranje se temelji na klijentovoj IP adresi i može raditi s bilo kojom uslugom bez vezanja za portove. Podržava konfiguraciju poslužitelja DNS GSLB (Global Server Load-Balancing) i Direct Server Return (DSR), gdje odgovor s poslužitelja ide izravno klijentu, a ne kroz balanser opterećenja. Sadrži prilagođeni UDP agent za inspekciju, podržava VRRP za instaliranje vrlo dostupnih konfiguracija na više čvorova. Ugrađeni mehanizmi omogućuju vam snimanje i spremanje paketa pomoću pcap-a za daljnje istraživanje. Postoji nekoliko opcija za provjeru funkcionalnosti krajnji sustavi: agent, ping, TCP Open, skripta i drugi alati poput wget.

Moguće je rezervirati balanser s replikacijom NAT stanja između glavnog i rezervnog čvora; prilikom ponovnog povezivanja klijent se spaja na isti poslužitelj. Za spremanje sesije koristi se klijentova IP adresa i odredišni port. Linux povezivanje je podržano. Sve tablice su pohranjene u RAM-u, ali zahtjevi su mali; 512 MB memorije dovoljno je za 4 milijuna sesija.
Može raditi na Linuxu (koristeći PF_PACKET API utičnicu) i SPARC/Intel Solaris (Streams/DLPI API). Za instalaciju su ponuđeni paketi rpm (Red Hat RHEL 6 / CentOS) i deb (Debian/Ubuntu) te tarball za ostale distribucije. Dostupna je i gotova slika virtualni stroj(temeljen na Ubuntu 8.04), koji vam omogućuje brzu implementaciju potrebne funkcionalnosti. Tijekom preuzimanja bit će prikazane sve lozinke za prijavu. Agent (bngagent) je otvorenog koda i podržava Linux, Solaris, OS X, HP-UX i druge.
Ne postoji sučelje za konfiguraciju; sve postavke se rade pomoću konfiguracijske datoteke /etc/bng.conf. U principu, ne može se nazvati složenim, pogotovo s obzirom na to da ih je više od desetak dostupno na web stranici projekta gotove primjere, često samo trebate odabrati najprikladniji i urediti ga za sebe.

HAProxy

Radi na nekoliko x86, x86_64, Alpha, SPARC, MIPS, PARISC arhitektura. Službeno podržava Linux 2.6.32+ (preporučeno za maksimalne performanse) i 2.4, Solaris 8–10, FreeBSD, OpenBSD. Instalacija i konfiguracija su trivijalne, iako paket nije prisutan u spremištima. Projekt nudi izvor licenciran pod GPL v2 i gotove binarne datoteke za Linux/x86 Glibc 2.2 i Solaris8/Sparc.

Pound - proxy i balansiranje HTTP i HTTPS

Izvorni cilj projekta Pound bio je raspodijeliti opterećenje na više Zope poslužitelja, što je rezultiralo visoko fokusiranim alatom koji je obrnuti proxy i balanser opterećenja za HTTP i HTTPS.

Balansiranje se vrši na temelju stanja sesije i drugih parametara (URL, autentifikacija, kolačići, HTTP zaglavlja). Potpuna podrška WebDAV. Za razliku od HAProxy, on obrađuje SSL. Razvila ga je IT tvrtka koja se bavi sigurnošću, što je također utjecalo na mogućnosti proizvoda. Posebna značajka je prisutnost osnovnih Web funkcije Application Firewall, Pound može kontrolirati ispravnost HTTP i HTTPS zaglavlja, odbacujući netočna. Prema zadanim postavkama, svi se zahtjevi zanemaruju, ali možete stvoriti URL obrasce i vrste zahtjeva (standardni, napredni, RPC i WebDAV) za koje će se provjeravati podudaranja. Na temelju rezultata odabire se konačni poslužitelj ili se veza blokira. Dizajn u početku omogućuje minimalno ometanje prometa (na primjer, ugradnja kolačića), ali može odrediti X-Forwarded-for za prijenos korisničke IP adrese na pozadinski poslužitelj.

Podržava IPv6, može prenijeti IPv6 klijente na IPv4 poslužitelje. Podaci o sesiji se pohranjuju i klijent se zatim povezuje sa svojim poslužiteljem.

Što se tiče specifičnosti, moguće je ne samo poslati vezu na backend, već i preusmjeriti na drugi URL.

Pound ne zahtijeva mnogo resursa; važno je napomenuti da osim za čitanje SSL certifikata, demon ne pristupa tvrdom disku. Može se pokrenuti u chroot i koristiti setuid/setgid. Ne postoje ugrađeni mehanizmi tolerancije grešaka. Funkcionalnost pozadine uvijek se provjerava putem HTTP-a.

Na procesoru razine Pentium D može postići približno 600–800 HTTP i 200–300 HTTPS veza u sekundi. Stoga su Poundova jača strana mali projekti s naglaskom na pristupačnost, sigurnost i više kontrole preko prometa. Za više veliko opterećenje Sami programeri Pounda preporučuju korištenje drugih rješenja.

Instalacija i konfiguracija nisu jako teške, iako se rade pomoću konfiguracijskih datoteka (dokumentacija je vrlo detaljna). Službeno testiran na Linuxu, Solarisu i OpenBSD-u. Projekt nudi samo izvorne kodove; gotovi paketi se mogu naći u SUSE, Debian i Ubuntu repozitoriju, osim toga, stranica ima veze za Red Hat i gotovu distribuciju kompajliranu na FreeBSD.