Share, , Google Plus, Pinterest,

Print

Posted in:

Datele: esentiale in viitorul solutiilor de load balancing

Cu toate ca nu sunt inca dominante in portofoliile producatorilor, numarul aplicatiilor native cloud este in crestere. Interesul crescut pentru containere este strans legat de arhitecturi native cloud (bazate pe microservicii) din cauza dependentei acestora de infrastructura pentru comunicatii.

In mod obisnuit, scalarea microserviciilor se obtine prin clonare pe orizontala. Ceea ce inseamna ca, daca un anumit serviciu este necesar in mai multe instante, tot ce ramane de facut este clonarea acestuia si adaugarea sa ca serviciu disponibil, asa incat load balancer-ul sa poata raspunde cererilor sale. Simplu ca buna ziua. Cand aceste microservicii reprezinta elemente functionale, modelul functioneaza de minune.

Load balancer-ul in cauza este adesea o componenta a orchestratorului de containere si se rapoarteaza implicit la algoritmul standard din industrie, respectiv TCP. Asta inseamna ca atunci cand o solicitare intra, load balancer-ul alege resursa „urmatoare” pentru a raspunde.

Aceasta metoda este comparata adesea cu o coada la ghiseul unei banci. Dar comparatia nu este tocmai corecta. Intr-un scenariu real, nu sunteti directionat catre „urmatoarea resursa disponibila”. Sunteti directionat ca fiind „urmatorul la rand” in relatie cu o resursa – chiar daca aceasta resursa este ocupata. In mod ironic, metodele de distributie din cadrul bancii sunt mai eficiente decat un altgoritm true round robin.

Bizar, nu-i asa? Situatia este similara si in cazul aplicatiilor.

Acelasi serviciu – chiar si la nivel functional – poate fi clonat deoarece deserveste acelasi set de cereri. Dar aceste solicitari nu se impart intotdeauna in mod egal din punct de vedere al executiei, din cauza datelor. Da, despre date este vorba. Aceeasi solicitare functionala – sau API – poate dura mai mult sau mai putin timp ca executie in functie de datele trimise sau solicitate. Astfel spus, va dura mai putin timp pentru a prelua si serializa o inregistrare a unui singur client decat pentru a recupera si serializa zece sau o suta de inregistrari de client.

Si de aici, round robin se descompune si introduce o variabilitate care poate afecta performanta. Axioma operationala # 2 se aplica in continuare arhitecturilor native cloud si celor bazate pe microservicii: pe masura ce incarcarea creste, performanta scade.

Round robin este ca o avalansa. Nu-i pasa daca o resursa este supraincarcata de solicitari cu seturi de date semnificative ca raspunsuri. Round robin spune ca „esti urmatorul”, indiferent daca esti pregatit sau nu. Aceasta poate duce la performante inegale pentru acei utilizatori ale caror solicitari ajung intr-o coada asociata unei resursa supraincarcate.

Daca performanta este prioritara – si ar trebui sa fie – atunci o alternativa mai buna consta in alegerea aproape a oricarui alt algoritm standard, cum ar fi numarul cel mai mic de conexiuni sau timpul de raspuns cel mai rapid. Practic, doriti ca algoritmul dvs. sa ia in considerare incarcarea si / sau viteza.

Viitorul in Load Balancing

Unii ar putea crede ca, pe masura ce avansam de la TCP la HTTP la HTTP +, aceasta problema se va rezolva. Nicidecum. Metoda de distributie – algoritmul de load balancing – este inca relevanta indiferent de layerul pe care il bazati. Round robin nu tine cont de arhitectura, ci de resurse si ia decizii pe baza de disponibilitate. Daca acel pool poate sa scaleze un singur apel API sau un bloc intreg, algoritmul nu face aceasta diferenta.

Asadar, ar fi de preferat ca load balancer-ul sa fie suficient de inteligent pentru a recunoaste cand o interogare ar rezulta in date „peste medie” inainte de a executa operatiunile. Solutiile firewall de aplicatii web, precum F5 WAF, sunt capabile sa recunoasca atunci cand un rezultat este iesit din comun si in principiu permite o mai buna securitate a aplicatiei. Ceea ce avem nevoie este ca load balancer-ul sa devina suficient de inteligent pentru a prezice un raspuns legitim „super-mare”.

Daca solutia de load balancing ar fi capabila sa faca astfel de catalogari si introduce acest lucru in luarea deciziilor sale, cererile alocate resurselor disponibile s-ar putea distribui mai uniform. Ceea ce ne dorim cu adevarat este sa nu fim obligati sa alegem un algoritm rigid pentru luarea de decizii. Ar fi mai bine daca load balancer-ul ar putea lua decizii plecand de la tipicul afacerii si de la caracteristicile tehnice, cum ar fi timpii de raspuns, timpul de executie anticipat, dimensiunea datelor returnate si incarcarea actuala pentru fiecare resursa.

Acest tip de inteligenta poate fi obtinut doar printr-o mai buna vizibilitate si invatare automata. Daca solutia de load balancing poate invata din experienta sa recunoasca ce interogari necesita mai mult timp decat altele, atunci poate aplica aceasta informatie pentru a distribui mai corect cererile, astfel incat sa se ajunga la un timp de raspuns consistent si previzibil.

Solutiile de load balancing raman o necesitate. Este cea mai buna replica tehnica pe care o putem da pentru a scala totul – de la retea, pana la aplicatii. Dar trebuie sa evolueze, odata cu infrastructura, pentru a fi mai dinamice, autonome si inteligente.

Articol preluat de pe blogul F5.

Share, , Google Plus, Pinterest,

Lasă un răspuns