Blog

Internet nikoli ne spi – zakaj potrebujemo load balancer?

Kaj je uporabnikom pomembno, ko gre za aplikacije? Najpomembneje je, da so dostopne. Njihove dostopnosti uporabniki nikoli niso dojemali tako resno kot danes, ko aplikacij ne uporabljamo samo za komuniciranje, tako zasebno kot poslovno, temveč so pravzaprav prav aplikacije – naše delo. Aplikacije, ki niso vedno dostopne, ki so nezanesljive, izgubljajo svoje uporabnike ter svojo pomembnost in izginjajo. Izginejo skorajda takoj.

Internet nikoli ne spi. Dela 24 ur na dan, 7 dni v tednu, 365 dni na leto in skladno s tem enako velja tudi za aplikacije. Da bi to zagotovili, postaja skalabilnost ena od ključnih zadev za zagotavljanje dostopnosti aplikacij. Eden od osnovnih dejavnikov za zagotavljanje dostopnosti je prav load balancing. Številni ga dojemajo kot nekaj, kar je mogoče izvesti z enostavnim skriptom, prav takšni posamezniki pa tudi zmanjšujejo pomembnost naprednih sistemov za load balancing. Velik del portfelja podjetja F5 Networks se osredotoča prav na to, da bi svojim uporabnikom zagotovili dostopnost njihovih aplikacij – vedno, povsod in na vseh napravah.

Prav zato v nadaljevanju predstavljamo nekaj ključnih načinov load balancinga in njegovo pomembnost nasploh.

Global Server Load Balancing

Za začetek: tukaj sploh ne gre za server load balancing, temveč za dostopnost posamezne lokacije, tj. podatkovnega centra, kar ponovno privede do dostopnosti aplikacij. GSLB je način, s katerim lahko zagotovimo, da lahko v primeru nedostopnosti določenega podatkovnega centra, naj gre za tradicionalnega ali tistega v oblaku, najdemo drugega.

V osnovni obliki GSLB uporablja DNS-based load balancing, kar pomeni, da obstaja seznam IP-naslovov, povezanih z domeno. Če prvi ni dostopen, izbere drugega, nato tretjega itd. Ta postopek ne velja za naprednega, temveč je osnova, ki se nadgradi z naprednimi funkcionalnostmi. S tem lahko preverimo učinkovitost delovanja posameznega podatkovnega centra in se odločimo, ali bomo uporabnika usmerili glede na to informacijo ali pa na geografsko bližji podatkovni center. Ne glede na izbrano možnost GSLB omogoča, da se zahteve uporabnikov porazdelijo med fizično ločene lokacije z vrnitvijo naslova dostopne oziroma izbrane lokacije.

Old School Load Balancing

V tem primeru se aplikacije nahajajo na več strežnikih, ti pa so razdeljeni v skupine glede na aplikacije, ki jim omogočajo delovanje. Cilj je, da se uporabnika usmeri k dostopnemu viru. Vendar tudi tu obstaja več metod in dejavnikov, ki jih je mogoče upoštevati. Običajen Round Robin recimo ne upošteva učinkovitosti delovanja strežnika. Če load balancing izvajamo na podlagi najmanjšega števila povezav (Least Connection), lahko močno vplivamo na učinkovitost delovanja strežnika. To kaže na to, da lahko pravilna izbira metode za load balancing močno vpliva na dostopnost aplikacij in delovanje sistema kot celote.

.

Persistence

Večina aplikacij je sestavljenih iz treh stopenj (three-tier), aplikacije same pa so v večini primerov stateful – informacije, ki si jih uporabnik izmenjuje z aplikacijo, se hranijo med zahtevami in odgovori in so ključnega pomena za pravilno delovanje aplikacije in zadovoljstvo uporabnikov. Med te informacije spadajo podatki za prijavo, stanje nakupovalne košarice, status, zadnja obiskana stran in podobno. Zaradi navedenega morajo biti zahteve uporabnikov med trajanjem celotne seje vedno posredovane na isti strežnik.

Load balancerji implementirajo trajnost v različnih oblikah, med katerimi je najbolj priljubljena metoda cookie-based trajnost – informacije o seji uporabnika se shranijo v piškotek, ki se nato uporabi za to, da load balancer zahtevo pravilno usmeri na ustrezni strežnik. Danes, ko je uporaba protokola SSL/TLS skorajda obvezna, je treba prilagoditi način vzpostavitve trajnosti. SSL/TLS omogoča varno sejo med odjemalcem in strežnikom. Da bi zagotovili, da lahko obe strani dešifrirata in uporabljata podatke, izmenjane prek te povezave, mora biti load balancer zmožen poslati zahteve na isti strežnik, na katerem se je seja tudi začela – zato se uporablja SSL/TLS based trajnost. Pri uporabi trajnosti je treba skrbneje razmisliti o metodi za load balancing, ki se bo uporabljala, predvsem ker load balancer upošteva tabelo trajnih zapisov. V takšnem primeru je lahko Least Connection dobra izbira, saj zagotavlja, da noben posamezni vir ne postane prezaseden s sejami, medtem ko bi drugi »počivali«. Druge metode lahko hitro privedejo do tega, da posamezni vir obdeluje veliko sej uporabnikov, kar nato poslabša učinkovitost delovanja in nenazadnje izkušnjo končnega uporabnika.

Host-based load balancing

Host-based load balancing je eden od najpogostejših načinov za doseganje skalabilnosti. Pogosta predpostavka je, da v tem primeru load balancerji niso potrebni, saj to funkcionalnost podpirajo vsi spletni strežniki. A to dejansko ne drži. Čeprav lahko spletni ali aplikacijski strežnik gosti več virtualnih strežnikov, še ni nujno, da obremenitev razporedi med njimi, zato tudi v tem primeru potrebujete load balancer.

Seveda lahko spletni/aplikacijski strežniki sami usmerijo zahteve uporabnikov na določen virtualni strežnik, a se z uporabo load balancerja učinkovitost poveča, število strežnikov in potrebne strojne opreme pa zmanjša. Load balancerji tudi v takšnem primeru omogočijo preprostejše načrtovanje obremenitve in zagotovijo, da se za obdelavo zahteve uporabnika vedno izbere optimalni vir.

Route and Return – L7 (HTTP) Load Balancing

Load balancinga na podlagi informacij na ravni aplikacij ne omogoča samo protokol HTTP, temveč tudi drugi protokoli. Drži pa, da je danes protokol HTTP verjetno najbolj razširjen in najpogosteje uporabljen.

Protokol HTTP je izrazito prilagodljiv, zato omogoča load balancing povsod, vključno s HTTP payloadom. Večina uporabnikov odločitev o load balancingu sprejme glede na to, kar je zapisano v enem od HTTP headerjev: host, cookie, user agent itd.

Obsežnost protokola HTTP pa omogoča load balancing absolutno povsod. V primeru load balancinga pri protokolu HTTP gre v prvi vrsti za usmerjanje zahtev uporabnikov in šele nato za load balancing. Po prejemu zahteve uporabnika se najprej izbere virtualni strežnik, na katerega bo zahteva poslana, nato pa se iz skupine strežnikov izbere optimalen vir za obdelavo zahteve uporabnika. HTTP omogoča recimo tudi load balancing po API-različici, kjer je API-različica vgrajena v URI ali poseben HTTP header. Na ta način lahko load balancer razlikuje med zahtevami uporabnikov in zagotovi, da je zahteva poslana ustrezni zaledni storitvi v obdelavo.

In tik pred koncem še vprašanje – še vedno mislite, da LB-ja ne potrebujete? Navedli smo samo nekaj značilnosti load balancerja, če pa si ogledate portfelj F5 in njihov produkt F5 Local Traffic Manager, boste videli, da obstaja še nekaj dodatnih funkcionalnosti. Drži, da je bila osnovna naloga load balancerja vedno porazdelitev prometa na zaledne strežnike. Osnovna naloga load balancerja danes, v tem zahtevnem spletnem svetu, pa je napredna porazdelitev tega istega prometa. Vendar load balanceri, kot je produkt F5 LTM, ponujajo tudi napredne optimizacije prometa, ki prehaja skoznje – od optimizacij na TCP-ravni pa vse do številnih optimizacij na ravni aplikacij. Ponujajo monitoring vseh delov sistema in offload posameznih funkcij s strežnika, da bi zagotovili, da je za obdelavo zahteve uporabnika vedno izbran najboljši vir in da strežniki počnejo točno to, za kar so bili ustvarjeni – dostavljajo aplikacije uporabnikom.

Za več informacij o produktu F5 LTM ter ostalih produktih iz portfelja F5 se obrnite na nas!

Share on LinkedInShare on FacebookShare on Google+Tweet about this on Twitter
Potrebujete ponudbo ali pomoč pri konfiguraciji rešitve? Iščete partnerja za implementacijo?
Kontaktirajte nas!