Arhitekture za uravnoteženje opterećenja poslužitelja, 1. dio: Uravnoteženje opterećenja na transportnoj razini

Farme poslužitelja postižu visoku skalabilnost i visoku dostupnost uravnoteženjem opterećenja poslužitelja, tehnikom koja farmu poslužitelja klijentima čini jedinstvenim. U ovom dvodijelnom članku Gregor Roth istražuje arhitekture za uravnoteženje opterećenja poslužitelja s naglaskom na rješenja otvorenog koda. Prvi dio obuhvaća osnove uravnoteženja opterećenja poslužitelja i razmatra prednosti i nedostatke uravnoteženja opterećenja poslužitelja na razini transporta. Dio 2 pokriva arhitekture za uravnoteženje opterećenja poslužitelja na razini aplikacije, koje se bave nekim ograničenjima arhitektura raspravljenih u 1. dijelu.

Zapreka ulasku za mnoge internetske tvrtke je niska. Svatko s dobrom idejom može razviti malu aplikaciju, kupiti ime domene i postaviti nekoliko poslužitelja temeljenih na računalu za obradu dolaznog prometa. Početna ulaganja su mala, tako da je početni rizik minimalan. No uspješna jeftina infrastruktura može brzo postati ozbiljan problem. Jedan poslužitelj koji obrađuje sve dolazne zahtjeve možda neće moći obrađivati ​​velike količine prometa nakon što posao postane popularan. U takvim se situacijama tvrtke često počinju povećavati : nadograđuju postojeću infrastrukturu kupujući veći okvir s više procesora ili dodaju više memorije za pokretanje aplikacija.

Povećavanje je, međutim, samo kratkoročno rješenje. A to je ograničeni pristup jer su troškovi nadogradnje nerazmjerno visoki u odnosu na dobitak u mogućnostima poslužitelja. Iz tih razloga najuspješnije internetske tvrtke slijede opsežni pristup. Komponente aplikacije obrađuju se kao višestruki primjerci na farmama poslužitelja, a koji se temelje na jeftinom hardveru i operativnim sustavima. Kako se promet povećava, dodaju se poslužitelji.

Pristup farmi poslužitelja ima svoje jedinstvene zahtjeve. Na softverskoj strani morate dizajnirati aplikacije tako da mogu raditi kao više instanci na različitim poslužiteljima. To radite dijeljenjem aplikacije na manje komponente koje se mogu samostalno implementirati. To je trivijalno ako su komponente aplikacije bez državljanstva. Budući da komponente ne zadržavaju nijedno stanje transakcije, bilo koja od njih može podjednako obrađivati ​​iste zahtjeve. Ako je potrebna veća procesorska snaga, samo dodajte još poslužitelja i instalirajte komponente aplikacije.

Najizazovniji problem nastaje kada su komponente aplikacije sa statusom. Na primjer, ako komponenta aplikacije sadrži podatke o košarici, dolazni zahtjev mora biti preusmjeren na instancu komponente aplikacije koja sadrži podatke o košarici zahtjevatelja. Dalje u ovom članku raspravit ću o tome kako postupati s takvim podacima sesije aplikacije u distribuiranom okruženju. Međutim, kako bi se smanjila složenost, najuspješniji internetski sustavi aplikacija pokušavaju izbjegavati komponente aplikacija sa stanjem kad god je to moguće.

S infrastrukturne strane, opterećenje obrade mora se rasporediti između grupe poslužitelja. To je poznato kao uravnoteženje opterećenja poslužitelja. Tehnologije za uravnoteženje opterećenja također se odnose na druge domene, na primjer širenje posla među komponentama poput mrežnih veza, CPU-a ili tvrdih diskova. Ovaj se članak usredotočuje na uravnoteženje opterećenja poslužitelja.

Dostupnost i skalabilnost

Balansiranje opterećenja poslužitelja distribuira zahtjeve za uslugom kroz skupinu stvarnih poslužitelja i čini te poslužitelje klijentima poput jednog velikog poslužitelja. Često su deseci stvarnih poslužitelja iza URL-a koji implementira jednu virtualnu uslugu.

Kako ovo radi? U široko korištenoj arhitekturi za uravnoteženje opterećenja poslužitelja, dolazni se zahtjev usmjerava na namjenski uravnoteživač opterećenja poslužitelja koji je klijentu transparentan. Na temelju parametara kao što su dostupnost ili trenutno opterećenje poslužitelja, uravnoteživač opterećenja odlučuje koji poslužitelj treba obraditi zahtjev i prosljeđuje ga odabranom poslužitelju. Da bi algoritam za uravnoteženje opterećenja pružio potrebne ulazne podatke, uravnoteživač tereta također dohvaća informacije o zdravstvenom stanju i opterećenju poslužitelja kako bi potvrdio mogu li reagirati na promet. Slika 1 ilustrira ovu klasičnu arhitekturu uravnoteživača opterećenja.

Arhitektura dispečera tereta prikazana na slici 1 samo je jedan od nekoliko pristupa. Da biste odlučili koje je rješenje uravnoteženja opterećenja najbolje za vašu infrastrukturu, morate uzeti u obzir dostupnost i skalabilnost .

Dostupnost se definira neprekidnim radom - vremenom između kvarova. (Zastoj je vrijeme otkrivanja kvara, popravljanja, izvršenja potrebnog oporavka i ponovnog pokretanja zadataka.) Tijekom prekida rada sustav mora odgovoriti na svaki zahtjev u unaprijed određenom, točno definiranom vremenu. Ako se prekorači ovo vrijeme, klijent to vidi kao kvar na poslužitelju. Visoka dostupnost je u osnovi suvišnost u sustavu: ako jedan poslužitelj zakaže, drugi transparentno preuzimaju opterećenje neuspjelog poslužitelja. Neuspjeh pojedinog poslužitelja nevidljiv je za klijenta.

Skalabilnost znači da sustav može služiti jednom klijentu, kao i tisućama istodobnih klijenata, zadovoljavajući zahtjeve kvalitete usluge, poput vremena odziva. Pod povećanim opterećenjem, visoko skalabilni sustav može povećati protok gotovo linearno proporcionalno snazi ​​dodanih hardverskih resursa.

U scenariju sa slike 1, velika skalabilnost postiže se distribucijom dolaznog zahtjeva preko poslužitelja. Ako se opterećenje poveća, mogu se dodati dodatni poslužitelji, sve dok uravnoteživač opterećenja ne postane usko grlo. Da bi postigao visoku dostupnost, uravnoteživač opterećenja mora nadzirati poslužitelje kako bi izbjegao prosljeđivanje zahtjeva preopterećenim ili mrtvim poslužiteljima. Nadalje, i sam uravnoteživač tereta mora biti suvišan. O ovome ću raspravljati kasnije u ovom članku.

Tehnike uravnoteženja opterećenja poslužitelja

Općenito, rješenja za uravnoteženje opterećenja poslužitelja su dvije glavne vrste:

  • Uravnoteženje opterećenja na transportnoj razini - kao što je pristup zasnovan na DNS-u ili uravnoteženje opterećenja na TCP / IP-u - djeluje neovisno o korisnom opterećenju aplikacije.
  • Uravnoteženje opterećenja na razini aplikacije koristi korisni teret aplikacije za donošenje odluka o uravnoteženju opterećenja.

Rješenja za uravnoteženje opterećenja mogu se dalje klasificirati u softverske uravnoteživače opterećenja i hardverske uravnoteživače opterećenja. Hardverski uravnoteživači opterećenja su specijalizirani hardverski okviri koji uključuju integrirane sklopove (ASIC) specifične za aplikaciju prilagođene određenoj uporabi. ASIC-ovi omogućuju brzo prosljeđivanje mrežnog prometa bez dodatnih troškova operativnog sustava opće namjene. Hardverski uravnoteživači opterećenja često se koriste za uravnoteženje opterećenja na transportnoj razini. Općenito, hardverski uravnoteživači opterećenja brži su od softverskih rješenja. Njihov nedostatak je njihov trošak.

Za razliku od hardverskih uravnoteživača opterećenja, softverski uravnoteživači opterećenja rade na standardnim operativnim sustavima i standardnim hardverskim komponentama poput računala. Rješenja temeljena na softveru rade ili unutar namjenskog hardverskog čvora uravnoteživača opterećenja kao na slici 1 ili izravno u aplikaciji.

DNS uravnoteženje opterećenja

DNS uravnoteženje opterećenja predstavlja jedan od ranih pristupa uravnoteženju opterećenja poslužitelja. Internetski sustav naziva domena (DNS) povezuje IP adrese s imenom hosta. Ako u svoj preglednik upišete ime hosta (kao dio URL-a), preglednik traži da DNS poslužitelj naziv hosta razriješi na IP adresu.

Pristup zasnovan na DNS-u temelji se na činjenici da DNS omogućuje da se više IP adresa (stvarnih poslužitelja) dodijeli jednom imenu hosta, kao što je prikazano u primjeru pretraživanja DNS-a na popisu 1.

Popis 1. Primjer DNS pretraživanja

>nslookup amazon.com Server: ns.box Address: 192.168.1.1 Name: amazon.com Addresses: 72.21.203.1, 72.21.210.11, 72.21.206.5

Ako DNS poslužitelj implementira kružni pristup, redoslijed IP adresa za dani host mijenja se nakon svakog DNS odgovora. Obično se klijenti poput preglednika pokušavaju povezati na prvu adresu vraćenu iz DNS upita. Rezultat je da se odgovori na više klijenata distribuiraju među poslužiteljima. Za razliku od arhitekture uravnoteženja opterećenja poslužitelja na slici 1, nije potreban hardverski čvor srednjeg uravnoteživača opterećenja.

DNS je učinkovito rješenje za globalno uravnoteženje opterećenja poslužitelja, pri čemu se opterećenje mora raspodijeliti između podatkovnih centara na različitim lokacijama. Često se globalno uravnoteženje opterećenja poslužitelja temeljeno na DNS-u kombinira s drugim rješenjima za uravnoteženje opterećenja poslužitelja radi raspodjele opterećenja unutar namjenskog podatkovnog centra.

Iako je jednostavan za primjenu, DNS pristup ima ozbiljnih nedostataka. Da bi smanjio DNS upite, klijent nastoji predmemorirati DNS upite. Ako poslužitelj postane nedostupan, klijentska predmemorija, kao i DNS poslužitelj, i dalje će sadržavati mrtvu adresu poslužitelja. Iz tog razloga, DNS pristup malo čini za postizanje visoke dostupnosti.

Uravnoteženje opterećenja TCP / IP poslužitelja

TCP / IP uravnoteživači opterećenja poslužitelja rade na prebacivanju slojeva na niskoj razini. Popularni uravnoteživač opterećenja poslužitelja na niskoj razini je Linux Virtual Server (LVS). Stvarni poslužitelji izgledaju vanjskom svijetu kao jedan "virtualni" poslužitelj. Dolazni zahtjevi na TCP vezi prosljeđuju se stvarnim poslužiteljima pomoću uravnoteživača opterećenja koji pokreće Linux jezgru zakrpanu kako bi uključio kod IP virtualnog poslužitelja (IPVS).

Kako bi se osigurala visoka raspoloživost, u većini slučajeva postavlja se par čvorova za uravnoteženje opterećenja, s jednim čvorom za uravnoteženje opterećenja u pasivnom načinu. Ako uravnoteži opterećenje ne uspije, program otkucaja srca koji se izvodi na oba uravnoteživača opterećenja aktivira čvor pasivnog uravnoteživača opterećenja i započinje preuzimanje virtualne IP adrese (VIP). Iako je otkucaj srca odgovoran za upravljanje prebacivanjem između balansa opterećenja, jednostavne skripte za slanje / očekivanje koriste se za praćenje zdravlja stvarnih poslužitelja.

Transparentnost za klijenta postiže se korištenjem VIP-a koji je dodijeljen uravnoteživaču tereta. Ako klijent izda zahtjev, prvo se traženo ime hosta prevodi u VIP. Kad primi paket zahtjeva, uravnoteživač opterećenja odlučuje koji bi pravi poslužitelj trebao obrađivati ​​paket zahtjeva. Ciljna IP adresa paketa zahtjeva prepisuje se u Real IP (RIP) stvarnog poslužitelja. LVS podržava nekoliko algoritama rasporeda za distribuciju zahtjeva na stvarne poslužitelje. Često se postavlja za korištenje zaokruženog rasporeda, slično uravnoteženju opterećenja na DNS-u. S LVS-om odluka o uravnoteženju opterećenja donosi se na TCP razini (sloj 4 OSI referentnog modela).

Nakon primanja paketa zahtjeva, stvarni poslužitelj to obrađuje i vraća paket odgovora. Da bi prisilio povrat paketa odgovora putem uravnoteživača opterećenja, stvarni poslužitelj koristi VIP kao zadani put odgovora. Ako uravnoteživač tereta primi paket odgovora, izvorni IP odgovora paketa prepisuje se s VIP-om (OSI Model Layer 3). Ovaj način usmjeravanja LVS naziva se usmjeravanje prevođenja mrežnih adresa (NAT). Slika 2 prikazuje implementaciju LVS-a koja koristi NAT usmjeravanje.

LVS također podržava druge načine usmjeravanja kao što je Direct Server Return. U ovom slučaju stvarni poslužitelj paket odgovora šalje izravno klijentu. Da biste to učinili, VIP mora biti dodijeljen i svim stvarnim poslužiteljima. Važno je učiniti VIP poslužitelja nerješivim za mrežu; u suprotnom, uravnoteživač tereta postaje nedostižan. Ako uravnoteživač tereta primi paket zahtjeva, MAC adresa (OSI Model Layer 2) zahtjeva se prepisuje umjesto IP adrese. Pravi poslužitelj prima paket zahtjeva i obrađuje ga. Na temelju izvorne IP adrese, paket odgovora šalje se klijentu izravno, zaobilazeći uravnoteživač opterećenja. Za web promet ovaj pristup može dramatično smanjiti radno opterećenje uravnoteživača. Tipično se prenosi mnogo više paketa odgovora nego paketa zahtjeva. Na primjer, ako zatražite web stranicu, često se šalje samo jedan IP paket. Ako se traži veća web stranica,za prijenos tražene stranice potrebno je nekoliko IP paketa odgovora.

Predmemoriranje

Rješenja za uravnoteženje opterećenja poslužitelja niske razine, poput LVS, dosežu svoje ograničenje ako je potrebno predmemoriranje na razini aplikacije ili podrška za sesiju aplikacija. Keširanje je važno načelo skalabilnosti za izbjegavanje skupih operacija koje opetovano dohvaćaju iste podatke. Predmemorija je privremeno spremište koje sadrži suvišne podatke koji su rezultat prethodne operacije dohvaćanja podataka. Vrijednost predmemorije ovisi o cijeni dohvaćanja podataka naspram stope učitavanja i potrebne veličine predmemorije.

Na temelju algoritma za planiranje uravnoteživača opterećenja, zahtjevima korisničke sesije upravljaju različiti poslužitelji. Ako se predmemorija koristi na strani poslužitelja, zalutali zahtjevi postat će problem. Jedan pristup rješavanju ovoga je postavljanje predmemorije u globalni prostor. memcached je popularno rješenje raspodijeljene predmemorije koje pruža veliku predmemoriju na više računala. To je particionirana, distribuirana predmemorija koja koristi dosljedno raspršivanje za određivanje poslužitelja predmemorije (demon) za zadani unos predmemorije. Na temelju hash koda ključa predmemorije, klijentska knjižnica uvijek preslikava isti hash kôd na istu adresu poslužitelja predmemorije. Ta se adresa zatim koristi za spremanje unosa predmemorije. Slika 3 ilustrira ovaj pristup predmemoriranju.

Popis 2 koristi spymemcached, memcachedklijenta napisanog na Javi, za predmemoriranje HttpResponseporuka na više računala. U spymemcachedbiblioteke provodi potrebna klijent logike Samo sam opisao.

Popis 2. Predmemorija HttpResponse na temelju memcached-a