Programmēšana

Servera slodzes līdzsvarošanas arhitektūras, 1. daļa: Transporta līmeņa slodzes līdzsvarošana

Serveru saimniecības nodrošina augstu mērogojamību un augstu pieejamību, izmantojot servera slodzes līdzsvarošanu, paņēmienu, kas serveru saimniecību klientiem liek parādīt kā vienu serveri. Šajā divdaļīgajā rakstā Gregors Rots pēta serveru slodzes līdzsvarošanas arhitektūras, koncentrējoties uz atvērtā koda risinājumiem. 1. daļa aptver servera slodzes līdzsvarošanas pamatus un apspriež transporta līmeņa serveru slodzes līdzsvarošanas plusi un mīnusus. 2. daļa aptver lietojumprogrammu līmeņa servera slodzes līdzsvarošanas arhitektūras, kas novērš dažus 1. daļā aplūkotos arhitektūras ierobežojumus.

Barjera ienākšanai daudziem interneta uzņēmumiem ir zema. Ikviens, kam ir laba ideja, var izstrādāt nelielu lietojumprogrammu, iegādāties domēna vārdu un izveidot dažus uz PC balstītus serverus, lai apstrādātu ienākošo trafiku. Sākotnējais ieguldījums ir mazs, tāpēc sākuma risks ir minimāls. Bet veiksmīga zemu izmaksu infrastruktūra var ātri kļūt par nopietnu problēmu. Vienam serverim, kas apstrādā visus ienākošos pieprasījumus, var nebūt iespējas apstrādāt lielu trafika apjomu, tiklīdz bizness kļūst populārs. Šādās situācijās uzņēmumi bieži sāk paplašinātu: viņi uzlabo esošo infrastruktūru, nopērkot lielāku lodziņu ar vairāk procesoriem vai pievieno vairāk atmiņas, lai palaistu lietojumprogrammas.

Tomēr palielināšana ir tikai īstermiņa risinājums. Un tā ir ierobežota pieeja, jo jaunināšanas izmaksas ir nesamērīgi augstas salīdzinājumā ar servera spēju ieguvumiem. Šo iemeslu dēļ veiksmīgākie interneta uzņēmumi ievēro a mērogot pieeja. Lietojumprogrammu komponenti tiek apstrādāti kā vairāki gadījumi serveru fermās, kuru pamatā ir lēta aparatūra un operētājsistēmas. Palielinoties trafikam, tiek pievienoti serveri.

Server-farm pieejai ir savas unikālās prasības. Programmatūras pusē jums jāveido lietojumprogrammas tā, lai tās varētu darboties kā vairāki gadījumi dažādos serveros. Jūs to darāt, sadalot lietojumprogrammu mazākos komponentos, kurus var izvietot neatkarīgi. Tas ir mazsvarīgi, ja lietojumprogrammas komponentiem nav valsts. Tā kā komponenti nesaglabā nekādu darījumu stāvokli, jebkurš no tiem var vienādi apstrādāt tos pašus pieprasījumus. Ja nepieciešama lielāka apstrādes jauda, ​​vienkārši pievienojiet vairāk serveru un instalējiet lietojumprogrammas komponentus.

Izaicinošāka problēma rodas, ja lietojumprogrammas komponenti ir stāvoklī. Piemēram, ja lietojumprogrammas komponentā ir iepirkumu groza dati, ienākošais pieprasījums ir jānovirza uz lietojumprogrammas komponenta gadījumu, kurā glabājas šī pieprasītāja iepirkumu groza dati. Vēlāk šajā rakstā es apspriedīšu, kā rīkoties ar šādiem lietojumprogrammas sesijas datiem izplatītā vidē. Tomēr, lai samazinātu sarežģītību, visveiksmīgākās interneta lietojumprogrammu sistēmas cenšas izvairīties no valstiskiem lietojumprogrammu komponentiem, kad vien iespējams.

Infrastruktūras pusē apstrādes slodze jāsadala starp serveru grupu. To sauc par servera slodzes līdzsvarošanu. Slodzes līdzsvarošanas tehnoloģijas attiecas arī uz citām jomām, piemēram, darba izplatīšanu starp tādām sastāvdaļām kā tīkla saites, procesori vai cietie diski. Šis raksts koncentrējas uz servera slodzes līdzsvarošanu.

Pieejamība un mērogojamība

Servera slodzes līdzsvarošana izplata pakalpojumu pieprasījumus reālu serveru grupā un klientiem padara šos serverus par vienu lielu serveri. Bieži vien URL, kas īsteno vienu virtuālo pakalpojumu, atrodas desmitiem reālu serveru.

Kā tas darbojas? Plaši izmantotajā servera slodzes līdzsvarošanas arhitektūrā ienākošais pieprasījums tiek novirzīts uz īpašu servera slodzes līdzsvarotāju, kas klientam ir pārredzams. Pamatojoties uz tādiem parametriem kā pieejamība vai pašreizējā servera slodze, slodzes līdzsvarotājs izlemj, kuram serverim jāapstrādā pieprasījums, un pārsūta to uz izvēlēto serveri. Lai nodrošinātu slodzes līdzsvarošanas algoritmu ar nepieciešamajiem ievades datiem, slodzes līdzsvarotājs arī iegūst informāciju par serveru stāvokli un slodzi, lai pārliecinātos, ka tie var reaģēt uz trafiku. 1. attēlā ir parādīta šī klasiskā slodzes līdzsvarošanas arhitektūra.

Kravas dispečera arhitektūra, kas parādīta 1. attēlā, ir tikai viena no vairākām pieejām. Lai izlemtu, kurš slodzes līdzsvarošanas risinājums ir labākais jūsu infrastruktūrai, jums jāapsver pieejamība un mērogojamība.

Pieejamību nosaka uptime - laiks starp neveiksmēm. (Dīkstāves laiks ir laiks, lai atklātu kļūmi, to labotu, veiktu nepieciešamo atkopšanu un restartētu uzdevumus.) Darbības laikā sistēmai ir jāatbild uz katru pieprasījumu iepriekš noteiktā, precīzi noteiktā laikā. Ja šis laiks tiek pārsniegts, klients to uzskata par servera darbības traucējumiem. Augsta pieejamība būtībā ir atlaišana sistēmā: ja viens serveris neizdodas, citi pārredzami pārņem neveiksmīgā servera slodzi. Atsevišķa servera kļūme klientam nav redzama.

Mērogojamība nozīmē, ka sistēma var apkalpot vienu klientu, kā arī tūkstošiem vienlaicīgu klientu, izpildot tādas pakalpojumu kvalitātes prasības kā atbildes laiks. Ar paaugstinātu slodzi augsta mērogojama sistēma var palielināt caurlaidspēju gandrīz lineāri proporcionāli pievienoto aparatūras resursu jaudai.

1. attēla scenārijā augsta mērogojamība tiek sasniegta, ienākošo pieprasījumu sadalot pa serveriem. Ja slodze palielinās, var pievienot papildu serverus, ja vien slodzes līdzsvarotājs nekļūst par sašaurinājumu. Lai sasniegtu augstu pieejamību, slodzes līdzsvarotājam ir jāuzrauga serveri, lai izvairītos no pieprasījumu pārsūtīšanas uz pārslogotiem vai beigtiem serveriem. Turklāt pašam slodzes līdzsvarotājam jābūt liekam. Es apspriedīšu šo punktu vēlāk šajā rakstā.

Servera slodzes līdzsvarošanas paņēmieni

Parasti servera slodzes līdzsvarošanas risinājumi ir divu veidu:

  • Transporta līmenis slodzes līdzsvarošana - piemēram, uz DNS balstīta pieeja vai TCP / IP līmeņa slodzes līdzsvarošana - darbojas neatkarīgi no lietojumprogrammas lietderīgās slodzes.
  • Lietojumprogrammas līmenis slodzes līdzsvarošana izmanto lietojumprogrammas lietderīgo slodzi, lai pieņemtu lēmumus par slodzes līdzsvarošanu.

Slodzes līdzsvarošanas risinājumus var sīkāk klasificēt uz programmatūru balstītiem slodzes līdzsvarotājiem un aparatūras balstītiem slodzes līdzsvarotājiem. Uz aparatūras balstīti slodzes līdzsvarotāji ir specializētas aparatūras kastes, kurās ietilpst lietojumprogrammām paredzētas integrētās shēmas (ASIC), kas pielāgotas konkrētai lietošanai. ASIC nodrošina ātrdarbīgu tīkla trafika pārsūtīšanu bez vispārējas nozīmes operētājsistēmas pieskaitāmās daļas. Transporta līmeņa slodzes līdzsvarošanai bieži izmanto aparatūras bāzes slodzes līdzsvarotājus. Parasti aparatūras bāzes slodzes līdzsvarotāji ir ātrāki nekā programmatūras risinājumi. Viņu trūkums ir to izmaksas.

Atšķirībā no aparatūras slodzes līdzsvarotājiem, programmatūras bāzes slodzes līdzsvarotāji darbojas ar standarta operētājsistēmām un standarta aparatūras komponentiem, piemēram, personālajiem datoriem. Uz programmatūru balstīti risinājumi darbojas vai nu īpašā slodzes līdzsvarošanas aparatūras mezglā, kā parādīts 1. attēlā, vai tieši lietojumprogrammā.

DNS balstīta slodzes līdzsvarošana

Uz DNS balstīta slodzes līdzsvarošana ir viena no agrīnajām servera slodzes līdzsvarošanas pieejām. Interneta domēnu vārdu sistēma (DNS) saista IP adreses ar resursdatora nosaukumu. Ja pārlūkprogrammā ierakstāt resursdatora nosaukumu (kā daļu no URL), pārlūkprogramma pieprasa, lai DNS serveris resursdatora nosaukumu pārvērš par IP adresi.

Uz DNS balstītā pieeja ir balstīta uz faktu, ka DNS ļauj piešķirt vairākas IP adreses (reālos serverus) vienam resursdatora nosaukumam, kā parādīts DNS uzmeklēšanas piemērā 1. sarakstā.

Saraksts 1. DNS uzmeklēšanas piemērs

> nslookup amazon.com serveris: ns.box adrese: 192.168.1.1 Nosaukums: amazon.com adreses: 72.21.203.1, 72.21.210.11, 72.21.206.5

Ja DNS serveris ievieš apaļo pieeju, noteiktā resursdatora IP adrešu secība mainās pēc katras DNS atbildes. Parasti klienti, piemēram, pārlūkprogrammas, mēģina izveidot savienojumu ar pirmo adresi, kas atgriezta no DNS vaicājuma. Rezultāts ir tāds, ka atbildes uz vairākiem klientiem tiek sadalītas starp serveriem. Atšķirībā no servera slodzes līdzsvarošanas arhitektūras 1. attēlā nav nepieciešams starpslodzes līdzsvarotāja aparatūras mezgls.

DNS ir efektīvs risinājums globālai servera slodzes līdzsvarošanai, kur slodze jāsadala starp datu centriem dažādās vietās. Bieži vien uz DNS balstīta globālā servera slodzes līdzsvarošana tiek kombinēta ar citiem servera slodzes līdzsvarošanas risinājumiem, lai sadalītu slodzi tam veltītā datu centrā.

Lai arī DNS pieeja ir viegli īstenojama, tai ir nopietni trūkumi. Lai samazinātu DNS vaicājumus, klients mēdz saglabāt DNS vaicājumus kešatmiņā. Ja serveris kļūst nepieejams, klienta kešatmiņā, kā arī DNS serverī joprojām būs mirusi servera adrese. Šī iemesla dēļ DNS pieeja maz palīdz sasniegt augstu pieejamību.

TCP / IP servera slodzes līdzsvarošana

TCP / IP servera slodzes līdzsvarotāji darbojas ar zemu slāņu pārslēgšanu. Populārs programmatūras bāzes zema līmeņa serveru slodzes līdzsvarotājs ir Linux virtuālais serveris (LVS). Īstie serveri ārējai pasaulei parādās kā viens "virtuāls" serveris. Ienākošos pieprasījumus par TCP savienojumu reālajiem serveriem pārsūta slodzes līdzsvarotājs, kurš palaiž Linux kodolu, kas ir salāpīts, lai iekļautu IP virtuālā servera (IPVS) kodu.

Lai nodrošinātu augstu pieejamību, vairumā gadījumu tiek izveidoti pāris slodzes līdzsvarošanas mezglu, ar vienu slodzes līdzsvarošanas mezglu pasīvā režīmā. Ja slodzes balansētājs neizdodas, sirdsdarbības programma, kas darbojas abos slodzes līdzsvarotājos, aktivizē pasīvo slodzes līdzsvarošanas mezglu un sāk virtuālās IP adreses (VIP) pārņemšanu. Lai gan sirdsdarbība ir atbildīga par kļūdu pārsūtīšanas pārvaldīšanu starp slodzes līdzsvarotājiem, reālu serveru stāvokļa uzraudzībai tiek izmantoti vienkārši sūtīšanas / gaidīšanas skripti.

Pārredzamība klientam tiek sasniegta, izmantojot VIP, kas piešķirts slodzes līdzsvarotājam. Ja klients izsniedz pieprasījumu, vispirms pieprasītais resursdatora nosaukums tiek tulkots VIP. Saņemot pieprasījuma paketi, slodzes līdzsvarotājs izlemj, kuram īstajam serverim jāapstrādā pieprasījuma pakete. Pieprasījuma paketes mērķa IP adrese tiek pārrakstīta reālā servera reālajā IP (RIP). LVS atbalsta vairākus plānošanas algoritmus pieprasījumu izplatīšanai reālajos serveros. Tas bieži tiek iestatīts, lai izmantotu apļveida plānošanu, līdzīgi kā uz DNS balstītu slodzes līdzsvarošanu. Izmantojot LVS, slodzes līdzsvarošanas lēmums tiek pieņemts TCP līmenī (OSI atsauces modeļa 4. slānis).

Pēc pieprasījuma paketes saņemšanas reālais serveris to apstrādā un atdod atbildes paketi. Lai piespiestu atbildes paketi atgriezt caur slodzes līdzsvarotāju, reālais serveris izmanto VIP kā noklusējuma atbildes maršrutu. Ja slodzes līdzsvarotājs saņem atbildes paketi, atbildes paketes avota IP tiek pārrakstīts ar VIP (OSI 3. modeļa slānis). Šo LVS maršrutēšanas režīmu sauc par tīkla adreses tulkošanas (NAT) maršrutēšanu. 2. attēlā parādīta LVS ieviešana, kas izmanto NAT maršrutēšanu.

LVS atbalsta arī citus maršrutēšanas režīmus, piemēram, Tieša servera atgriešana. Šajā gadījumā atbildes paketi reālais serveris nosūta tieši klientam. Lai to izdarītu, VIP jāpiešķir arī visiem reālajiem serveriem. Ir svarīgi padarīt servera VIP tīklā neatrisināmu; pretējā gadījumā slodzes līdzsvarotājs kļūst nesasniedzams. Ja slodzes līdzsvarotājs saņem pieprasījuma paketi, IP adreses vietā tiek pārrakstīta pieprasījuma MAC adrese (OSI 2. modeļa slānis). Īstais serveris saņem pieprasījuma paketi un to apstrādā. Pamatojoties uz avota IP adresi, atbildes pakete tiek nosūtīta klientam tieši, apejot slodzes līdzsvarotāju. Web pieejai šī pieeja var dramatiski samazināt līdzsvarotāja darba slodzi. Parasti tiek pārsūtīti daudz vairāk atbildes pakešu nekā pieprasījuma paketes. Piemēram, ja pieprasāt Web lapu, bieži tiek nosūtīts tikai viens IP pakete. Ja tiek pieprasīta lielāka tīmekļa lapa, pieprasītās lapas pārsūtīšanai ir nepieciešamas vairākas atbildes IP paketes.

Kešatmiņa

Zema līmeņa serveru slodzes līdzsvarošanas risinājumi, piemēram, LVS, sasniedz savu robežu, ja ir nepieciešama lietojumprogrammu līmeņa kešatmiņa vai lietojumprogrammu sesiju atbalsts. Kešatmiņa ir svarīgs mērogojamības princips, lai izvairītos no dārgām darbībām, kuras atkārtoti iegūst vienus un tos pašus datus. Kešatmiņa ir pagaidu krājums, kurā glabājas lieki dati, kas iegūti iepriekšējās datu ienešanas operācijas rezultātā. Kešatmiņas vērtība ir atkarīga no datu izguves izmaksām, salīdzinot ar trāpījumu līmeni un nepieciešamo kešatmiņas lielumu.

Pamatojoties uz slodzes līdzsvara plānošanas algoritmu, lietotāja sesijas pieprasījumus apstrādā dažādi serveri. Ja servera pusē tiek izmantota kešatmiņa, klaiņojoši pieprasījumi kļūs par problēmu. Viena pieeja, kā rīkoties, ir kešatmiņas ievietošana globālā telpā. memcached ir populārs izplatīts kešatmiņas risinājums, kas nodrošina lielu kešatmiņu vairākās mašīnās. Tā ir sadalīta, sadalīta kešatmiņa, kas izmanto konsekventu jaukšanu, lai noteiktu kešatmiņas serveri (dēmonu) dotajam kešatmiņas ierakstam. Pamatojoties uz kešatmiņas atslēgas jaukšanas kodu, klienta bibliotēka vienmēr kartē vienu un to pašu hash kodu uz to pašu kešatmiņas servera adresi. Pēc tam šo adresi izmanto kešatmiņas ieraksta glabāšanai. Šo attīrīšanas pieeju ilustrē 3. attēls.

Uzskaitot 2 lietojumus spymemcached, a atmiņā klients, kas rakstīts Java valodā, lai saglabātu kešatmiņu HttpResponse ziņojumus vairākās mašīnās. The spymemcached bibliotēka ievieš nepieciešamo klienta loģiku, kuru es tikko aprakstīju.

Uzskaita 2. Memcached bāzes HttpResponse kešatmiņu

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