Programavimas

Serverio apkrovos balansavimo architektūros. 1 dalis. Transporto lygio apkrovos balansavimas

Serverių ūkiai pasiekia aukštą mastelį ir aukštą prieinamumą balansuodami serverio apkrovą - tai leidžia serverių ūkį klientams rodyti kaip vieną serverį. Šiame dviejų dalių straipsnyje Gregoras Rothas nagrinėja serverio apkrovos balansavimo architektūras, daugiausia dėmesio skirdamas atvirojo kodo sprendimams. 1 dalyje aptariami serverio apkrovos balansavimo pagrindai ir aptariami transporto lygio serverio apkrovos balansavimo privalumai ir trūkumai. 2 dalis apima programos lygio serverio apkrovos balansavimo architektūras, kurios pašalina kai kuriuos 1 dalyje aptartų architektūrų apribojimus.

Daugeliui interneto kompanijų kliūtis patekti į rinką yra maža. Kiekvienas, turintis gerą idėją, gali sukurti nedidelę programą, nusipirkti domeno vardą ir sukurti keletą kompiuterio serverių, kurie tvarkytų gaunamą srautą. Pradinė investicija yra maža, todėl pradinė rizika yra minimali. Tačiau sėkminga pigi infrastruktūra gali greitai tapti rimta problema. Vienam serveriui, kuris tvarko visas gaunamas užklausas, gali nepavykti apdoroti didelių srautų, kai verslas tampa populiarus. Tokioje situacijoje įmonės dažnai pradeda proporcingai didinti: jie atnaujina esamą infrastruktūrą, nusipirkdami didesnę dėžę su daugiau procesorių arba prideda daugiau atminties programoms paleisti.

Tačiau didinimas yra tik trumpalaikis sprendimas. Tai ribotas požiūris, nes naujovinimo kaina yra neproporcingai didelė, palyginti su serverio pajėgumų padidėjimu. Dėl šių priežasčių sėkmingiausios interneto kompanijos laikosi a išplėsti metodas. Programų komponentai serverių ūkiuose apdorojami kaip keli egzemplioriai, kurių pagrindas yra nebrangi aparatinė įranga ir operacinės sistemos. Didėjant srautui, pridedami serveriai.

Serverio ūkio požiūris turi savo unikalius reikalavimus. Programinės įrangos srityje turite suprojektuoti programas taip, kad jos galėtų veikti kaip kelios egzemplioriai skirtinguose serveriuose. Tai darote padalydami programą į mažesnius komponentus, kuriuos galima įdiegti atskirai. Tai nereikšminga, jei programos komponentai yra be pilietybės. Kadangi komponentai neišlaiko jokios operacijos būsenos, bet kuris iš jų gali vienodai tvarkyti tuos pačius prašymus. Jei reikia daugiau apdorojimo galios, tiesiog pridėkite daugiau serverių ir įdiekite programos komponentus.

Sudėtingesnė problema kyla, kai programos komponentai yra būsenos. Pavyzdžiui, jei programos komponentas turi pirkinių krepšelio duomenis, gaunama užklausa turi būti nukreipta į programos komponento egzempliorių, kuriame yra to prašytojo pirkinių krepšelio duomenys. Vėliau šiame straipsnyje aptarsiu, kaip tvarkyti tokius programos sesijos duomenis paskirstytoje aplinkoje. Tačiau siekiant sumažinti sudėtingumą, sėkmingiausios interneto programų sistemos stengiasi vengti valstybinių programų komponentų, kai tik įmanoma.

Infrastruktūros srityje apdorojimo apkrova turi būti paskirstyta serverių grupei. Tai vadinama serverio apkrovos balansavimu. Apkrovos balansavimo technologijos taip pat yra susijusios su kitomis sritimis, pavyzdžiui, darbo paskirstymu tarp komponentų, tokių kaip tinklo saitai, procesoriai ar standieji diskai. Šiame straipsnyje pagrindinis dėmesys skiriamas serverio apkrovos balansavimui.

Prieinamumas ir mastelis

Serverio apkrovos balansavimas paskirsto paslaugų užklausas realių serverių grupei ir klientams atrodo, kad šie serveriai atrodo kaip vienas didelis serveris. Dažnai dešimtys tikrų serverių yra už URL, kuris įgyvendina vieną virtualią paslaugą.

Kaip tai veikia? Plačiai naudojamoje serverio apkrovos balansavimo architektūroje gaunama užklausa nukreipiama į klientui skaidrią serverio apkrovos balansavimo priemonę. Remdamasis tokiais parametrais kaip prieinamumas ar dabartinė serverio apkrova, apkrovos balansuotojas nusprendžia, kuris serveris turi tvarkyti užklausą, ir persiunčia jį pasirinktam serveriui. Norėdami pateikti apkrovos balansavimo algoritmą su reikalingais įvesties duomenimis, apkrovos balansuotojas taip pat gauna informaciją apie serverių būklę ir apkrovą, kad patikrintų, ar jie gali reaguoti į srautą. 1 paveiksle pavaizduota ši klasikinė apkrovos balansavimo architektūra.

1 paveiksle pavaizduota krovinio dispečerio architektūra yra tik vienas iš kelių būdų. Norėdami nuspręsti, kuris apkrovos balansavimo sprendimas yra geriausias jūsų infrastruktūrai, turite apsvarstyti prieinamumas ir mastelis.

Prieinamumą apibrėžia veikimo laikas - laikas tarp nesėkmių. (Prastova yra laikas nustatyti gedimą, jį ištaisyti, atlikti reikiamą atkūrimą ir paleisti iš naujo užduotis.) Veikimo metu sistema turi atsakyti į kiekvieną užklausą per iš anksto nustatytą, tiksliai apibrėžtą laiką. Jei šis laikas viršijamas, klientas tai vertina kaip serverio gedimą. Didelis prieinamumas iš esmės yra perteklinis sistemos kiekis: jei vienas serveris sugenda, kiti skaidriai perima nepavykusio serverio apkrovą. Individualaus serverio gedimas klientui nematomas.

Mastelio mastas reiškia, kad sistema gali aptarnauti vieną klientą, taip pat tūkstančius tuo pačiu metu veikiančių klientų, tenkindama paslaugų kokybės reikalavimus, tokius kaip atsakymo laikas. Esant padidintai apkrovai, aukšto mastelio sistema gali beveik tiesiškai padidinti pralaidumą proporcingai pridėtų aparatūros išteklių galiai.

Pagal 1 paveiksle pateiktą scenarijų didelis mastelis pasiekiamas paskirstant gaunamą užklausą per serverius. Padidėjus apkrovai, galima pridėti papildomų serverių, jei apkrovos balanseris netampa kliūtimi. Kad pasiektų aukštą prieinamumą, apkrovos balansuotojas turi stebėti serverius, kad išvengtų užklausų persiuntimo perkrautiems ar neveikiantiems serveriams. Be to, pats apkrovos balanseris taip pat turi būti nereikalingas. Aš aptarsiu šį dalyką vėliau šiame straipsnyje.

Serverio apkrovos balansavimo metodai

Apskritai serverio apkrovos balansavimo sprendimai yra dviejų pagrindinių tipų:

  • Transporto lygis apkrovos balansavimas - pvz., DNS principas arba TCP / IP lygio apkrovos balansavimas - veikia nepriklausomai nuo programos naudingosios apkrovos.
  • Programos lygis apkrovos balansavimas naudoja programos naudingąją apkrovą priimdamas sprendimus dėl apkrovos balansavimo.

Apkrovos balansavimo sprendimus galima toliau skirstyti į programinės įrangos apkrovos balansavimo įrenginius ir aparatinės įrangos apkrovos balansavimo įrenginius. Aparatinės įrangos pagrindu veikiantys apkrovos balansatoriai yra specializuotos aparatinės įrangos dėžutės, kuriose yra konkrečiai programai pritaikyti integruoti grandynai (ASIC), pritaikyti konkrečiam naudojimui. ASIC leidžia greitai perduoti tinklo srautą be bendrosios paskirties operacinės sistemos pridėtinių išlaidų. Aparatūros pagrindu veikiantys apkrovos balanseriai dažnai naudojami transporto lygio krovinių balansavimui. Aparatinės įrangos apkrovos balansatoriai yra greitesni nei programinės įrangos sprendimai. Jų trūkumas yra jų kaina.

Priešingai nei aparatinės įrangos apkrovos balansatoriai, programinės įrangos pagrindu veikiantys apkrovos balansatoriai veikia naudojant standartines operacines sistemas ir standartinius aparatūros komponentus, tokius kaip asmeniniai kompiuteriai. Programine įranga pagrįsti sprendimai veikia arba tam skirtame apkrovos balansavimo aparatūros mazge, kaip parodyta 1 paveiksle, arba tiesiogiai programoje.

DNS pagrįstas apkrovos balansavimas

DNS pagrįstas apkrovos balansavimas yra vienas išankstinių serverio apkrovos balansavimo būdų. Interneto domenų vardų sistema (DNS) susieja IP adresus su pagrindinio kompiuterio vardu. Jei į savo naršyklę įvedate pagrindinio kompiuterio pavadinimą (kaip URL dalį), naršyklė prašo, kad DNS serveris pagrindinio kompiuterio pavadinimą pakeistų į IP adresą.

DNS pagrįstas požiūris grindžiamas tuo, kad DNS leidžia priskirti kelis IP adresus (tikrus serverius) vienam pagrindinio kompiuterio vardui, kaip parodyta 1 sąrašo DNS paieškos pavyzdyje.

Sąrašas 1. DNS paieškos pavyzdys

> nslookup amazon.com serveris: ns.box adresas: 192.168.1.1 pavadinimas: amazon.com adresai: 72.21.203.1, 72.21.210.11, 72.21.206.5

Jei DNS serveris įgyvendina „round-robin“ metodą, po kiekvieno DNS atsakymo pasikeičia nurodyto kompiuterio IP adresų tvarka. Paprastai klientai, pvz., Naršyklės, bando prisijungti prie pirmo adreso, grąžinto iš DNS užklausos. Rezultatas yra tas, kad atsakymai keliems klientams yra paskirstomi tarp serverių. Skirtingai nuo 1 paveiksle rodomos serverio apkrovos balansavimo architektūros, tarpinio apkrovos balansavimo aparatūros mazgo nereikia.

DNS yra efektyvus pasaulinio serverio apkrovos balansavimo sprendimas, kai apkrova turi būti paskirstyta tarp skirtingų centrų duomenų centrų. Dažnai DNS pagrindu sukurtas pasaulinis serverio apkrovos balansavimas yra derinamas su kitais serverio apkrovos balansavimo sprendimais, siekiant paskirstyti apkrovą tam skirtame duomenų centre.

Nors DNS metodas yra lengvai įgyvendinamas, jis turi rimtų trūkumų. Norėdami sumažinti DNS užklausas, klientas linkęs talpinti DNS užklausas. Jei serveris tampa nepasiekiamas, kliento talpykloje ir DNS serveryje ir toliau bus negyvas serverio adresas. Dėl šios priežasties DNS metodas mažai padeda įgyvendinti aukštą prieinamumą.

TCP / IP serverio apkrovos balansavimas

TCP / IP serverio apkrovos balansatoriai veikia perjungdami žemo lygio sluoksnius. Populiarus programinės įrangos pagrindu sukurtas žemo lygio serverio apkrovos balansatorius yra „Linux Virtual Server“ (LVS). Tikrieji serveriai išoriniam pasauliui atrodo kaip vienas „virtualus“ serveris. Gaunamas užklausas dėl TCP ryšio perduoda tikriesiems serveriams apkrovos balansuotojas, kuris paleidžia „Linux“ branduolį, užtaisytą įtraukti IP virtualaus serverio (IPVS) kodą.

Siekiant užtikrinti aukštą prieinamumą, daugeliu atvejų nustatoma pora apkrovos balansavimo mazgų, kurių vienas apkrovos balansavimo mazgas yra pasyvus. Jei apkrovos balanseris nepavyksta, širdies ritmo programa, vykdoma abiem apkrovos balansatoriais, suaktyvina pasyvų apkrovos balansavimo mazgą ir inicijuoja virtualaus IP adreso (VIP) perėmimą. Nors širdies plakimas yra atsakingas už perkrovos tarp balansavimo įtaisų valdymą, tikrųjų serverių būklei stebėti naudojami paprasti siuntimo / laukimo scenarijai.

Skaidrumas klientui pasiekiamas naudojant VIP, kuris priskiriamas krūvio balansuotojui. Jei klientas pateikia užklausą, pirmiausia prašomas pagrindinio kompiuterio vardas išverčiamas į VIP. Gavęs užklausos paketą, apkrovos balansuotojas nusprendžia, kuris tikrasis serveris turėtų tvarkyti užklausos paketą. Užklausos paketo tikslinis IP adresas perrašomas į tikrojo serverio tikrąjį IP (RIP). LVS palaiko kelis planavimo algoritmus, skirtus užklausoms paskirstyti į tikrus serverius. Jis dažnai nustatomas naudoti planavimą iš eilės, panašų į DNS pagrįstą apkrovos balansavimą. Naudojant LVS, apkrovos balansavimo sprendimas priimamas TCP lygiu (OSI pamatinio modelio 4 sluoksnis).

Gavęs užklausos paketą, tikrasis serveris jį tvarko ir grąžina atsakymo paketą. Norėdami priversti atsakymo paketą grąžinti per apkrovos balansavimo priemonę, tikrasis serveris naudoja VIP kaip numatytąjį atsakymo kelią. Jei apkrovos balansuotojas gauna atsakymo paketą, atsakymo paketo šaltinio IP perrašomas VIP (OSI modelio 3 sluoksnis). Šis LVS maršruto režimas vadinamas tinklo adreso vertimo (NAT) maršrutu. 2 paveiksle parodytas LVS diegimas, kuriame naudojamas NAT maršrutas.

LVS taip pat palaiko kitus maršruto režimus, tokius kaip Tiesioginis serverio grąžinimas. Šiuo atveju tikrasis serveris atsakymo paketą siunčia tiesiogiai klientui. Norėdami tai padaryti, VIP turi būti priskirtas ir visiems tikriems serveriams. Svarbu, kad serverio VIP nebūtų išspręstas tinklui; priešingu atveju apkrovos balansatorius tampa nepasiekiamas. Jei apkrovos balanseris gauna užklausos paketą, vietoj IP adreso perrašomas užklausos MAC adresas (2 OSI modelio sluoksnis). Tikrasis serveris gauna užklausos paketą ir jį apdoroja. Pagal šaltinio IP adresą atsakymo paketas siunčiamas tiesiogiai klientui, apeinant apkrovos balansavimo priemonę. Šis metodas gali labai sumažinti balanserio darbo krūvį žiniatinklio srautui. Paprastai perduodama daug daugiau atsakymo paketų nei užklausų paketai. Pavyzdžiui, jei prašote tinklalapio, dažnai siunčiamas tik vienas IP paketas. Jei prašoma didesnio tinklalapio, norint perkelti prašomą puslapį, reikia kelių atsakymo IP paketų.

Talpykla

Žemo lygio serverio apkrovos balansavimo sprendimai, pvz., LVS, pasiekia ribą, jei reikalingas programos lygio talpinimas ar programos sesijos palaikymas. Talpykla yra svarbus mastelio principas, siekiant išvengti brangių operacijų, kurios tuos pačius duomenis gauna pakartotinai. Talpykla yra laikina saugykla, kurioje laikomi nereikalingi duomenys, atsirandantys dėl ankstesnės duomenų gavimo operacijos. Talpyklos vertė priklauso nuo duomenų gavimo kainos, palyginti su įvykių dažniu ir reikalaujamu talpyklos dydžiu.

Remiantis apkrovos balanserio planavimo algoritmu, vartotojo sesijos užklausas tvarko skirtingi serveriai. Jei serverio pusėje naudojama talpykla, klaidingos užklausos taps problema. Vienas būdas tai tvarkyti yra talpyklos talpinimas pasaulinėje erdvėje. „memcached“ yra populiarus paskirstytos talpyklos sprendimas, suteikiantis didelę talpyklą keliose mašinose. Tai yra padalinta, paskirstyta talpykla, kuri naudoja nuoseklų maišymą, kad nustatytų talpyklos serverį (deemoną) tam tikram talpyklos įrašui. Remiantis talpyklos rakto maišos kodu, kliento biblioteka visada susieja tą patį maišos kodą į tą patį talpyklos serverio adresą. Šis adresas tada naudojamas saugoti talpyklos įrašą. 3 paveiksle pavaizduotas šis spartinimo būdas.

Išvardinus 2 naudojimo būdus spymemcached, a prisegta klientas, parašytas Java kalba, į talpyklą HttpResponse pranešimus keliose mašinose. spymemcached biblioteka įgyvendina reikalingą kliento logiką, kurią ką tik aprašiau.

Sąrašas 2. „memcached“ pagrindu sukurta „HttpResponse“ talpykla

$config[zx-auto] not found$config[zx-overlay] not found