Systemskalering. Horisontal skalering

Oleg Spiryaev

Nylig har det vært hyppige påstander om at mellom- og avanserte servere aktivt erstattes av grupper av startnivåservere, samlet i rack eller klynger. Noen eksperter er imidlertid uenige. Således, ifølge Dataquest, økte andelen av modeller priset til $500 tusen og over (dette inkluderer mellomklasse- og high-end SMP-servere) i totalt serversalg fra 2000 til 2002 fra 38 til 52%.

Andre data innhentet av IDC viser vekst (iht i det minste, etter antall maskiner) i sektoren for low-end servermodeller - med to prosessorer. IDC spår også at i 2005 vil det vanligste operativsystemet for servere som koster mellom $50 000 og $3 millioner være Unix. Sammenligner man disse dataene, er det klart at mellomklasse- og high-end Unix-servere vil forbli den dominerende plattformen for datasentre, men vil bli supplert med et økende antall mindre (vanligvis dual-prosessor) servere.

Denne trenden har utviklet seg som følge av allokeringen i datasentre ulike nivåer beregninger (fig. 1). Tier 1, eller front tier, beveger seg gradvis til en horisontal skaleringsmodell små servere, og nivå 3 (databasenivået) domineres av oppskaleringsservere. Lag 2 (applikasjonslag) blir området der vertikale og horisontale arkitekturer sameksisterer.

Vertikale og horisontale arkitekturer

La oss se på hovedforskjellene mellom vertikale og horisontale arkitekturer. Scale-out-servere er store SMP-systemer (symmetrisk multiprosessering eller delt minne) med mer enn fire sentrale prosesseringsenheter. De bruker bare én kopi av operativsystemet, arbeidsleder alle prosessorer, minne og I/O-komponenter. Vanligvis er alle disse ressursene plassert i ett stativ eller skap. Disse serverne kobles sammen over en høyhastighets sentral eller bakplan med lav ventetid og cache-koherent tilgang. Du kan legge til ressurser ved å installere ekstra systemkort inne i skapet. I vertikale arkitektursystemer (eller SMP-systemer) er minne delt, noe som betyr at alle prosessorer og I/O-komponenter har tilgang til alt minne. Brukeren "ser" minne som et enkelt stort objekt.

Som alternativ, horisontal skalering, kobles systemer sammen via et nettverk eller grupperes sammen. For sammenkoblinger, standard nettverksteknologier, for eksempel Fast Ethernet, Gigabit Ethernet(GBE) og Scalable Coherent Interconnect (SCI), som gir lavere gjennomstrømning og høyere latens sammenlignet med vertikale systemer. Ressurser i dette tilfellet er fordelt på noder, vanligvis inneholdende fra én til fire prosessorer; Hver node har sin egen prosessor og minne og kan ha sitt eget I/O-delsystem eller dele det med andre noder. Fungerer på hver node separat eksemplar OS. Ressurser utvides ved å legge til noder, men ikke ved å legge til ressurser til en node. Minne i horisontale systemer er distribuert, det vil si at hver node har sitt eget minne som er direkte tilgang til prosessorene og I/O-undersystemet. Å få tilgang til disse ressursene fra en annen node er mye tregere enn fra noden der de er plassert. I tillegg, med en horisontal arkitektur, er det ingen konsistent tilgang mellom noder til minne, og applikasjonene som brukes bruker relativt få ressurser, så de "passer" på en enkelt node og trenger ikke konsistent tilgang. Hvis en applikasjon krever flere noder, må den selv gi konsistent minnetilgang.

Hvis et horisontalt system oppfyller applikasjonskravene, er denne arkitekturen å foretrekke fordi anskaffelseskostnadene er lavere. Vanligvis er anskaffelseskostnaden per prosessor for horisontale systemer lavere enn for vertikale systemer. Forskjellen i pris skyldes det faktum at vertikale systemer bruker kraftigere RAS-funksjoner (pålitelighet, tilgjengelighet, servicevennlighet), samt høyytelsesforbindelser. Det er imidlertid en rekke restriksjoner på bruk av systemer med horisontal arkitektur. Nedenfor vil vi diskutere under hvilke forhold horisontale systemer kan brukes og når vertikal skalering er nødvendig.

I tillegg til én stor SMP-server inkluderer vertikal arkitektur også klynger av store SMP-servere som brukes til en enkelt storskala applikasjon.

Nylig introduserte modul- eller bladservere på markedet, vanligvis utstyrt med en eller to prosessorer, er et eksempel på horisontale servere. Her består klyngen av små noder, som hver har en SMP-server på inngangsnivå med antall sentrale prosessorer fra 1 til 4.

En annen måte å skalere ut på er gjennom store massivt parallelle databehandlingssystemer (MPP), som består av mange små prosessorer installert i et enkelt kabinett, hver med sin egen kopi av OS eller en kopi av OS-mikrokjerne. Foreløpig produseres det kun noen få MPP-systemer, som oftest representerer spesialiserte løsninger. Dette er for eksempel Terradata-systemer produsert av NCR, IBM RS/6000SP (SP-2) og HP Tandem non-stop.

Tabell 1. Funksjoner ved vertikale og horisontale arkitekturer

Parameter	Vertikale systemer	Horisontale systemer
Hukommelse	Stor delt	Liten dedikert
Strømmer	Mange gjensidig avhengige tråder	Mange uavhengige tråder
Sammenkoblinger	Tett koblet innvendig	Løst koblet utvendig
RAS	Kraftig RAS enkeltsystem	Kraftig RAS som bruker replikering
Sentrale behandlingsenheter	Mange standard	Mange standard
OS	Én kopi av OS for mange sentrale prosessorer	Flere kopier av operativsystemet (en kopi for 1-4 prosessorer)
Oppsett	I ett skap	Plassering av et stort antall servere i et rack
Tetthet		Høy prosessortetthet per enhet gulvareal
Utstyr	Standard og spesialdesignet	Standard
Skalering	Innenfor et enkelt serverchassis	På en multi-server skala
Utvidelse	Ved å installere tilleggskomponenter på serveren	Ved å legge til nye noder
Arkitektur	64-bit	32- og 64-bit

Bord 1 gir mulighet for en komparativ analyse av vertikale og horisontale arkitekturer.

Vertikale systemer deler minne og gir konsistent hurtigbuffertilgang.
Vertikale systemer er ideelle for oppgaveflyt som trenger å kommunisere med hverandre.
Vertikale systemer er preget av kraftige RAS-funksjoner, og i horisontale systemer implementeres tilgjengelighet ved hjelp av massiv replikering (flere noder er koblet til en klynge, så feilen til en av dem har liten innvirkning på driften av hele systemet).
I vertikale systemer dekker én kopi av OS alle ressurser. Noen vertikale systemer, for eksempel midframes og servere high-end klasse Sun Microsystems (Sun Fire 4800 til Sun Fire 15K), kan deles inn i mindre vertikale servere.
Vertikale systemer bruker så mange standardkomponenter som mulig, men noen nøkkelkomponenter (som for eksempel sammenkoblinger) er spesialdesignet.
Vertikale systemer kan utvides ved å installere ekstra komponenter i den eksisterende rammen (kraftigere prosessorer, ekstra minne, ekstra og høyere ytelse I/O-tilkoblinger, etc.). Horisontale systemer utvides ved å legge til en node eller erstatte gamle noder med nye.
Nesten alle vertikale systemer er 64-bit, mens horisontale systemer kan være enten 32-bit eller 64-bit.

Vertikale systemer er bedre egnet for noen typer bruksområder og horisontale for andre, men i mange tilfeller optimalt valg arkitektur avhenger av størrelsen på problemet. I tabellen 2 viser eksempler på bruksområder hvor vertikal eller horisontal arkitektur er optimal.

Tabell 2. Brukstyper for vertikale og horisontale arkitekturer

Små og modulære servere er godt egnet for applikasjoner som er statsløse, små i skala og som er enkle å replikere. Og for applikasjoner som bruker statlig informasjon og store datamengder som krever intensiv dataoverføring i systemet, ideell løsning det vil være vertikale servere. I markedet for høy ytelse teknisk databehandling (HPTC) er det mange applikasjoner der tråder er avhengige av hverandre og utveksler data med hverandre. Det finnes også applikasjoner som krever store mengder delt minne. Store SMP-servere er best egnet for disse to typene applikasjoner. Imidlertid er det også HPTC-applikasjoner der utførelsestrådene er uavhengige og ikke krever store mengder delt minne. Slike applikasjoner kan partisjoneres, noe som gjør klynger av små servere ideelle for å kjøre dem. På samme måte er noen kommersielle applikasjoner partisjonert og drar nytte av horisontale servere, mens andre ikke kan partisjoneres, så vertikale servere er den beste plattformen for dem.

Faktorer som påvirker ytelsen

Alle store datasentre er parallelle datamaskiner. Her kan selv klynger betraktes som en spesiell type parallelle systemer. Høy ytelse krever et balansert system med kraftige prosessorer, høyhastighetsforbindelser og I/O, et skalerbart operativsystem, optimaliserte applikasjoner og avanserte RAS-funksjoner.

Prosessorer og systemforbindelser

Prosessorer er absolutt en viktig komponent, men de bestemmer bare delvis den generelle ytelsen til et system. Det er viktigere å sikre at prosessorer kjører med maksimal kapasitet. U kraftig prosessor, som bare er 50 % lastet, vil yte dårligere enn en tregere prosessor som er 80 % lastet.

Dessuten, som antall prosessorer i parallelt system Det som kommer i forgrunnen er ikke deres makt, men systemsammenkoblingene. De er ansvarlige for å flytte data fra disk, fra minne og fra nettverket til prosessoren. I en klynge er sammenkoblingen en nettverkstilkobling, for eksempel Fast Ethernet eller Gigabit Ethernet. Cluster-sammenkoblinger flytter data mellom noder, mens systemsammenkoblinger flytter data innenfor eget system. Hvis sammenkoblingen er for treg, vil prosessoren være inaktiv og vente på data.

Systemforbindelser brukes også til å flytte dataadresser, noe som er nødvendig for å støtte cache-koherens. Hvis systemforbindelsen er for treg med å overføre dataadresser, vil prosessoren igjen være inaktiv og vente på data fordi den må vite adressen sin for å få tilgang til den. Raske sammenkoblinger gir høy gjennomstrømning og lav ventetid (lav tid fra en dataforespørsel blir sendt til dataene begynner å bli overført).

Den viktigste tekniske forskjellen mellom horisontale og vertikale systemer er gjennomstrømning og forsinkelsen av deres sammenkoblinger. For klyngeforbindelser kan gjennomstrømningen variere fra 125 MB/s for Fast Ethernet til 200 MB/s for SCI, og latens kan variere fra 100 tusen ns for GBE og opptil 10 tusen ns for SCI. Ved å bruke InfiniBand-grensesnittet er det mulig å implementere raskere sammenkoblinger med topphastigheter fra omtrent 250 MB/s for den første versjonen og opptil 3 GB/s for påfølgende.

Inngang og utgang

Rask I/O er nødvendig slik at sammenkoblingen raskt kan hente data fra disk og nettverk og overføre dem til prosessorer. En flaskehals i I/O-delsystemet kan påvirke ytelsen til selv de raskeste sammenkoblingene og prosessorene negativt.

operativsystem

Selv den beste maskinvaren er ineffektiv hvis operativsystemet ikke er skalerbart nok. For horisontale systemer er OS-skalerbarhet ikke så viktig, fordi ikke mer enn fire prosessorer kjører på en enkelt node eller med en separat kopi av OS.

Systemtilgjengelighet

Generelt sett avhenger systemtilgjengeligheten i stor grad av typen arkitektur. I store SMP-systemer er RAS-funksjonalitet innebygd i systemet og supplert med failover for to til fire noder. I horisontale systemer er RAS for individuelle noder dårligere, men forbedringer i disse funksjonene oppnås ved å replikere noder flere ganger.

Optimaliserte applikasjoner

Applikasjoner må optimaliseres for arkitektur datasystem. Det er enklest å skrive og optimalisere applikasjoner for SMP-systemer. Store kommersielle applikasjoner er optimalisert spesifikt for SMP-systemer og ble til og med utviklet på dem, og det er grunnen til at SMP-er har dominert markedet for mellomklasse- og avanserte systemer de siste ti årene.

Søknadsstørrelse

Som nevnt bruker store SMP-systemer høyhastighetsforbindelser for å gi tilstrekkelig systemytelse. Horisontale systemer kan oppleve ytelsesproblemer på grunn av lav gjennomstrømning og høy interconnect latency i tilfeller der data må overføres ofte mellom noder. Noen applikasjoner krever imidlertid ikke høye sammenkoblingshastigheter for å oppnå høy ytelse – vanligvis små applikasjoner og applikasjoner som enkelt kan replikeres (for eksempel webservere, proxyer, brannmurer og små applikasjonsservere). I slike horisontale systemer utfører hver node en liten oppgave uavhengig av arbeidet til alle de andre.

For eksempel, i en horisontal (eller distribuert minne) arkitektur, kan fire prosessornoder (hver med separat RAM og dedikert eller delt I/O-undersystem) bruke en nettverksforbindelse som Gigabit Ethernet. Dette datamiljøet kjører tre typer arbeidsbelastninger. Den minste belastningen passer på én node, men når den øker, kreves det flere noder for å fullføre den. Ifølge eksperter, når du utfører en oppgave på flere noder, forringes ytelsen betydelig på grunn av langsomme sammenkoblinger mellom noder. Små arbeidsbelastninger som ikke trenger å kommunisere med hverandre fungerer godt med en horisontal arkitektur, men å kjøre store arbeidsbelastninger på den byr på utfordringer.

En stor SMP-systemkonfigurasjon kan for eksempel inkludere opptil 100 prosessorer, 576 GB delt minne og høyhastighetsforbindelser. Et slikt system kan håndtere alle typer arbeidsbelastninger fordi det ikke er kommunikasjon mellom noder og effektiv kommunikasjon mellom prosesser. Alle CPUer kan samtidig få tilgang til alle disker, alt minne og nettverkstilkoblinger- Dette nøkkelfunksjon SMP-systemer (eller vertikale systemer).

Spørsmålet oppstår ofte om det er tilrådelig å plassere små belastninger på store SMP-er. Selv om dette er teknisk mulig, er denne tilnærmingen ikke berettiget fra et økonomisk synspunkt. For store SMP-er er anskaffelseskostnaden per prosessor høyere enn for små systemer. Derfor, hvis en applikasjon kan kjøre på en liten node (eller flere små noder) uten store administrasjonsproblemer, er utskalering et bedre valg for distribusjon. Men hvis applikasjonen er for stor og ikke kan kjøre på en liten node (eller flere slike noder), vil en stor SMP-server det beste alternativet når det gjelder både ytelse og systemadministrasjon.

Ytelse på databasenivå

Hovedspørsmålet her er å sammenligne ytelsen til enkelt mellomstore og store SMP-servere med en klynge av små servere (ikke mer enn fire prosessorer).

Når man diskuterer skalerbarhet, bruker produksjonsbedrifter en rekke tekniske termer. Dermed er ytelsesvekst (Speedup) for SMP definert som forholdet mellom applikasjonsutførelseshastigheter på flere prosessorer og på én. Lineær speedup betyr for eksempel at på 40 prosessorer kjører en applikasjon 40 ganger (40x) raskere enn på én. Ytelsesøkningen avhenger ikke av antall prosessorer, dvs. for en konfigurasjon på 24 prosessorer vil den være den samme som for 48 prosessorer. Økningen i klyngeytelse (Cluster speedup) skiller seg bare ved at når den beregnes, tas antall noder, ikke antall prosessorer. I likhet med SMP-ytelsesvekst forblir klyngeytelsesveksten konstant for forskjellige tall noder

Skaleringseffektivitet karakteriserer muligheten til applikasjoner, spesielt grupperte, til å skalere over et stort antall noder. Det antas generelt at skaleringseffektivitet avhenger av antall noder som deltar i målingen. SMP-skaleringseffektivitet er økningen i ytelse delt på antall prosessorer, og klyngeeffektivitet er økningen i ytelsen til klyngen delt på antall noder i den. Du må forstå hva disse parameterne betyr slik at du ikke får feil bilde fordi 90 % skaleringseffektivitet på to noder ikke er det samme som 90 % skaleringseffektivitet på fire noder.

I fig. Figur 2 viser tre grafer: ideell lineær skalerbarhet, skalerbarhet for en 24-prosessor SMP-server på 95 %, og skalerbarhet for en klynge med to 4-prosessorservere på 90 %. Det kan sees at det er visse begrensninger på skalerbarheten til databaser i klynger (med horisontal skalering). Å lenke mange små servere sammen gir ikke den skalerbarheten som trengs for middels til store applikasjoner. Årsaken til dette er båndbreddebegrensningene til intra-klynge-sammenkoblinger, den ekstra belastningen på databaseprogramvare knyttet til klyngeadministrasjon, og vanskeligheten med å skrive applikasjoner for distribuerte minneklyngemiljøer.

Publiserte benchmarkresultater viser for eksempel at Oracle9i RAC (Real Application Cluster) har en ytelsesgevinst på 1,8 og en skaleringseffektivitet på 90 %. Denne skalerbarhetseffektiviteten kan virke ganske høy, men faktisk er skalerbarhet på 90 % for fire noder ineffektiv sammenlignet med resultatene til store SMP-servere.

Ytelse på applikasjonsnivå

Applikasjonslaget i et trelags datasenter er veldig forskjellig fra databaselaget. Typisk er applikasjoner på dette nivået statsløse – med andre ord, ingen data lagres på selve serveren, eller bare en liten del av den lagres. Dette laget inneholder forretningsregler for applikasjonstjenester. Transaksjoner kommer til søknadsnivå og behandles av det. Når data må skrives eller leses, sendes transaksjoner til databaselaget. Applikasjonstjenere har en tendens til å konsolidere databasetilkoblinger fordi et stort antall tilkoblinger har en negativ innvirkning på ytelsen.

I de fleste tilfeller krever applikasjonsserverlaget mye flere prosessorer enn databasenivået per individuell applikasjonstjeneste. For eksempel, i tilfellet med SAP R/3, er dette forholdet ca. 10 prosessorer for hver databaseprosessor, dvs. hvis SAP R/3 krever 20 prosessorer for databaselaget, bør det være ca. 200 prosessorer for applikasjonslaget. Spørsmålet er hva som er mer lønnsomt å distribuere - 100 to-prosessorservere eller ti 20-prosessorservere. Tilsvarende er forholdet mellom applikasjonsprosessorer og databaseprosessorer hos Oracle omtrent 5 til 1.

Det antas at applikasjonsservere ikke trenger å være distribuert over flere noder. Flere kopier av applikasjonsprogramvare kan distribueres på tvers av forskjellige fysiske servere annen kraft eller av dynamiske domener til store servere.

Antallet prosessorer som kreves for applikasjonslaget vil være omtrent det samme uavhengig av datamaskinarkitekturen. Kostnaden for å kjøpe maskinvare og programvare for en horisontal arkitektur vil være lavere, siden kostnaden per prosessor er lavere i dette tilfellet. I de fleste tilfeller kan horisontale systemer gi ytelsen som kreves for å oppfylle tjenestenivåavtalen. Kostnadene knyttet til kjøp av programvarelisenser er omtrent de samme for begge arkitekturene.

Samtidig kan kostnadene ved å administrere og vedlikeholde infrastruktur for en horisontal arkitektur bli høyere. Når den distribueres på horisontale systemer, brukes flere kopier av operativsystemet og applikasjonsserverprogramvaren. Kostnadene ved vedlikehold av infrastruktur vokser vanligvis i forhold til antall kopier av operativsystemet og applikasjonene. Dessuten for horisontal arkitektur backup og katastrofegjenoppretting blir desentralisert og nettverksinfrastruktur er vanskeligere å administrere.

Kostnaden for systemadministrasjon er vanskelig å måle. Vanligvis viser modeller som sammenligner horisontale og vertikale applikasjonstjenere at det er rimeligere å administrere færre, kraftigere servere (vertikale servere) enn å administrere mange mindre servere. Generelt, når de velger type arkitektur for å distribuere et applikasjonslag, bør IT-ledere nøye vurdere kostnadene ved anskaffelse av maskinvare.

Innvirkning av arkitektur på tilgjengelighet

Tilgjengelighet er avgjørende for moderne datasentre – applikasjonstjenester må være tilgjengelige 24x7x365 (24 timer i døgnet, 7 dager i uken, 365 dager i året). Avhengig av behovene til et bestemt datasenter, brukes forskjellige ordninger med høy tilgjengelighet. For valg spesifikk løsning det er nødvendig å bestemme akseptabel nedetid (planlagt og uplanlagt). I fig. Figur 3 viser hvordan andelen tilgjengelighet påvirker varigheten av nedetiden.

Ettersom tilgjengelighetskravene øker, øker også kostnadene for løsningen. Datasenterledere må bestemme hvilken kombinasjon av kostnad, kompleksitet og tilgjengelighet som best oppfyller kravene til tjenestenivå. Datasentre som krever omtrent 99,95 % tilgjengelighet kan distribuere én enkelt SMP-server med RAS-funksjoner som full maskinvareredundans og online vedlikehold.

For å oppnå tilgjengelighet større enn 99,95 %, vil det imidlertid være nødvendig med en klynge. Sun Cluster-programvare med HA (High Availability) failover gir 99,975 % tilgjengelighet. HA failover bruker en primær server og en varm standby; Hvis primærserveren svikter, overtar backupserveren lasten. Tiden det tar å starte en tjeneste på nytt varierer etter applikasjon og kan ta flere minutter, spesielt for databaseapplikasjoner som krever store dataintensive tilbakeføringer for å gjenopprette transaksjoner.

Hvis nedetid på noen minutter er uakseptabelt for et datasenter, kan et aktivt-aktivt system være en løsning, der applikasjonen distribueres på to eller flere noder slik at hvis en av dem mislykkes, vil de andre fortsette å kjøre applikasjonen. Som et resultat vil avbruddet være svært kort (noen klienter rapporterer at det varer mindre enn 1 minutt), noen ganger kan det hende at brukeren ikke engang legger merke til nodefeilen.

Vertikale servere gir høy tilgjengelighet ved å bygge inn mange RAS-funksjoner separat server for å minimere planlagt og uplanlagt nedetid. I horisontale servere implementeres funksjoner som gir et høyt nivå av RAS, ikke på nivået til en individuell server, men gjennom duplisering og plassering av flere servere. På grunn av ulike implementeringer RAS og sammenkoblingsmuligheter, horisontale servere er vanligvis billigere per prosessor.

Til tre-lags arkitektur godt eksempel horisontal høy tilgjengelighet er distribusjon av webservere. Du kan distribuere mange små servere, hver med en separat kopi av webserverprogramvaren installert. Hvis en webserver går ned, blir transaksjonene omfordelt mellom de gjenværende sunne serverne. Når det gjelder applikasjonsservere, kan de hostes på både horisontale og vertikale servere, og høy tilgjengelighet oppnås gjennom redundans. Enten du distribuerer noen få store SMP-servere eller mange mindre, er redundans fortsatt den primære måten å oppnå høy RAS på applikasjonsnivå.

Men på databasenivå endrer situasjonen seg. Databaser er statistiske og krever i de fleste tilfeller at data er partisjonert og tilgjengelig fra alle prosessorer/noder. Dette betyr at for høy tilgjengelighet med redundans, må du bruke klyngeprogramvare som Sun Cluster eller Oracle9i RAC (for svært høy tilgjengelighet).

konklusjoner

Både vertikale og horisontale arkitekturer har sin nisje i dagens datasenter. Mens dagens fokus er på nye teknologier som modulære servere og parallelle databaser, er markedet fortsatt etterspurt etter mid-range og high-end servere.

Vertikale og horisontale systemer kan bruke samme programvare, OS og til og med de samme prosessorene. Hovedforskjellen som påvirker pris og ytelse er sammenkoblingene som brukes i hver arkitektur. Horisontale servere bruker løst koblede eksterne sammenkoblinger, mens vertikale servere bruker tett koblede sammenkoblinger som gir mer høy hastighet Data overføring.

For grensesnittet gir horisontale servere vanligvis den optimale løsningen når det gjelder ytelse, total anskaffelseskostnad og tilgjengelighet. For påføringslaget kan både vertikale og horisontale arkitekturer brukes effektivt. For databasenivå optimal løsning det vil være bruk av vertikale servere, uavhengig av nødvendig tilgjengelighetsnivå.

Systemer, programvaresystemer, databasesystemer, rutere, nettverk osv., dersom de krever evnen til å arbeide under stor belastning. Systemet kalles skalerbar, hvis det er i stand til å øke produktiviteten i forhold til tilleggsressursene. Skalerbarhet kan vurderes gjennom forholdet mellom økningen i systemytelse og økningen i brukte ressurser. Jo nærmere dette forholdet er én, jo bedre. Skalerbarhet betyr også muligheten til å øke ytterligere ressurser uten strukturelle endringer i den sentrale noden i systemet.

I et system med dårlig skalerbarhet fører å legge til ressurser til kun en liten økning i ytelsen, og etter et visst "terskel"-punkt har ikke å legge til ressurser noen gunstig effekt.

Vertikal skalering

Øke ytelsen til hver systemkomponent for å forbedre den generelle ytelsen.

Horisontal skalering

Dele opp systemet i mindre strukturelle komponenter og distribuere dem over separate fysiske maskiner (eller grupper av dem) og/eller øke antall servere som utfører samme funksjon parallelt.

Notater

se også

Linker

Wikimedia Foundation. 2010.

Se hva "Skalerbarhet" er i andre ordbøker:

skalerbarhet- utvidbarhet Egenskaper for en applikasjon som kjører på forskjellige plattformer og varierer i størrelse (for eksempel på en PC som kjører Windows og på arbeidsstasjon Sol under Unix). For maskinvare, forutsigbar vekst i systemytelse med... ...

skalerbarhet- 3.1.43 skalerbarhet: Evnen til å gi funksjonalitet opp og ned en rekke applikasjonsplattformer som varierer i hastighet og ressurser. Kilde … Ordbok-referansebok med vilkår for normativ og teknisk dokumentasjon

Programvarens evne til å kjøre riktig på små og store systemer med ytelse som øker proporsjonalt med prosessorkraften til systemet. På engelsk: Skalerbarhet Se også: Programvare for åpne systemer... Finansiell ordbok

systemskalerbarhet (i SCADA)- system skalerbarhet [Intent] System skalerbarhet. Dette betyr at det utviklede prosjektet kan testes på én datamaskin eller et lite nettverk og deretter utvide systemet (i henhold til utviklingsprogram, budsjett osv.) uten... ... Teknisk oversetterveiledning

skalerbarhet (i informasjonsteknologi)- Evnen til en IT-tjeneste, prosess, konfigurasjonselement, etc., til å utføre sin tidligere avtalte funksjon når arbeidsmengde eller omfang endres. [ITIL Glossary of Terms versjon 1.0, 29. juli 2011] NO skalerbarhet Evnen til en IT... ... Teknisk oversetterveiledning

skalerbarhet (applikasjoner)- skalerbarhet utvidbarhet Kjennetegn ved en applikasjon som kjører på forskjellige plattformer og varierer i størrelse (for eksempel på en PC under Windows og på en Sun-arbeidsstasjon under Unix). For maskinvare, forutsigbar vekst i systemet... ... Teknisk oversetterveiledning

skalerbarhet (nettverk og kommunikasjonssystemer)- Kriterium for et kostnadseffektivtm, tatt i betraktning div funksjonelle egenskaper, ulike intellektuelle elektroniske enheter, nettstasjonsstørrelse og nettstasjonsspenningsområder. [GOST R 54325 2011... ... Teknisk oversetterveiledning

Bredt skalerbar- - [L.G. Sumenko. Engelsk-russisk ordbok om informasjonsteknologi. M.: State Enterprise TsNIIS, 2003.] Emner informasjonsteknologi generelt EN terabyte skalerbarhet ... Teknisk oversetterveiledning

horisontal skalerbarhet- Øke systemkapasiteten ved å legge til noder til klyngen. Emner informasjonsteknologi generelt EN horisontal skalerbarhet ... Teknisk oversetterveiledning

SKALERBARHET - skalerbarhet- et av de grunnleggende prinsippene for å bygge åpne systemer, garanterer bevaring av investeringer i informasjon og programvare når du flytter til en kraftigere maskinvareplattform... E-Business ordbok

Bøker

Microsoft SharePoint 2010. Den komplette guiden, Michael Noel, Colin Spence. Boken utforsker alle de nye funksjonene i SharePoint – fra nye sosiale nettverksfunksjoner til forbedret søk – som hjelper deg å få mest mulig ut av både SharePoint...

Så du har laget en nettside. Det er alltid interessant og spennende å se hvordan besøkstelleren sakte men sikkert kryper opp og viser bedre resultater hver dag. Men en dag, når du ikke forventer det, vil noen legge ut en lenke til ressursen din på noen Reddit eller Hacker News (eller på Habré - ca. lane), og serveren din vil krasje.

I stedet for å få nye vanlige brukere, vil du sitte igjen med Tom side. På dette tidspunktet vil ingenting hjelpe deg med å gjenopprette serverens funksjonalitet, og trafikken vil gå tapt for alltid. Hvordan unngå slike problemer? I denne artikkelen vil vi snakke om optimalisering og skalering.

Litt om optimalisering

Alle vet de grunnleggende tipsene: oppdater til siste versjon PHP (5.5 har nå OpCache innebygd), håndtere indekser i databasen, cache statisk (sjelden endrede sider, som "Om oss", "FAQ", etc.).

Det er også verdt å nevne ett spesielt aspekt ved optimalisering - visning av statisk innhold med en ikke-Apache-server, som for eksempel Nginx. Konfigurer Nginx til å håndtere alt statisk innhold (*.jpg, *.png, *.mp4, *.html. ..), og filene som krever serverbehandling la ham sende den til den tunge Apache. Det kalles omvendt proxy.

Skalering

Det er to typer skalering - vertikal og horisontal.
Etter min forståelse er et nettsted skalerbart hvis det kan håndtere trafikk uten å endre programvaren.

Vertikal skalering.

Se for deg en server som betjener en nettapplikasjon. Den har 4GB RAM, i5-prosessor og 1TB HDD. Den gjør jobben sin bra, men for bedre å takle høyere trafikk, bestemmer du deg for å øke RAM-en til 16 GB, installere en i7-prosessor og gå ut for SSD-stasjon. Nå er serveren mye kraftigere og kan håndtere høye belastninger. Dette er vertikal skalering.

Horisontal skalering.

Horisontal skalering er opprettelsen av en klynge av sammenkoblede (ofte ikke veldig kraftige) servere som sammen betjener nettstedet. I dette tilfellet brukes den lastbalanser(aka lastbalanser) - en maskin eller et program hvis hovedfunksjon er å bestemme hvilken server en forespørsel skal sendes til. Servere i en klynge deler vedlikeholdet av applikasjonen uten å vite noe om hverandre, og øker dermed gjennomstrømningen og feiltoleransen til nettstedet ditt betydelig.

Det finnes to typer balansere - maskinvare og programvare. Programvare - installert på vanlig server og aksepterer all trafikk, og sender den videre til riktige behandlere. En slik balanserer kan for eksempel være Nginx. I "Optimalisering"-delen fanget den opp alle forespørsler om statiske filer, og serverte disse forespørslene selv, uten å belaste Apache. En annen populær programvare for å implementere lastbalansering er Squid. Personlig bruker jeg det alltid, fordi... det gir et flott, brukervennlig grensesnitt for å kontrollere de dypeste aspektene ved balansering.

En hardware balancer er en dedikert maskin hvis eneste formål er å fordele belastningen. Vanligvis kjører denne maskinen ikke lenger annen programvare enn den som er utviklet av produsenten. Du kan lese om maskinvarelastbalansere.

Vær oppmerksom på at disse to metodene ikke utelukker hverandre. Du kan skalere hvilken som helst maskin vertikalt (aka Nodu) på systemet ditt.
I denne artikkelen diskuterer vi horisontal skalering fordi... det er billigere og mer effektivt, men vanskeligere å implementere.

Permanent tilknytning

Når du skalerer PHP-applikasjoner, oppstår det flere vanskelige problemer. En av dem jobber med brukersesjonsdata. Tross alt, hvis du logget inn på nettstedet, og balansereren sendte din neste forespørsel til en annen maskin, da ny bil vil ikke vite at du allerede er pålogget. I dette tilfellet kan du bruke permanent tilkobling. Dette betyr at balansereren husker hvilken node brukerens forespørsel ble sendt til sist, og sender neste forespørsel dit. Imidlertid viser det seg at balanseren er for overbelastet med funksjoner; i tillegg til å behandle hundretusenvis av forespørsler, må den også huske nøyaktig hvordan den behandlet dem, som et resultat av at balanseren selv blir flaskehals i systemet.

Lokal datautveksling.

Å dele brukerøktdata mellom alle noder i klyngen virker som en god idé. Og selv om denne tilnærmingen krever noen endringer i arkitekturen til applikasjonen din, er det verdt det - lastbalanseren er avlastet, og hele klyngen blir mer feiltolerant. Dødsfallet til en av serverne påvirker ikke driften av hele systemet i det hele tatt.
Som vi vet, lagres øktdata i en superglobal matrise $_SESSION, som skriver og henter data fra en fil på disk. Hvis denne stasjonen er på én server, kan åpenbart ikke andre servere få tilgang til den. Hvordan kan vi gjøre det tilgjengelig på flere maskiner?
For det første, vær oppmerksom på det Sesjonsbehandleren i PHP kan overstyres. Du kan implementere din egen øktklasse.

Bruke en database til å lagre økter

Ved å bruke vår egen sesjonsbehandler kan vi lagre dem i databasen. Databasen kan være på en separat server (eller til og med en klynge). Vanligvis fungerer denne metoden utmerket, men med veldig høy trafikk, Databasen blir en flaskehals(og hvis databasen går tapt, mister vi fullstendig funksjonalitet), fordi den må betjene alle serverne, som hver prøver å skrive eller lese øktdata.

Distribuert filsystem

Du tenker kanskje at det ville være fint å sette opp et nettverksfilsystem der alle servere kan skrive øktdata. Ikke gjør det! Dette er en veldig langsom tilnærming, som fører til skade eller til og med tap av data. Hvis du av en eller annen grunn fortsatt bestemmer deg for å bruke denne metoden, anbefaler jeg deg GlusterFS

Membufret

Du kan også bruke memcached til å lagre øktdata i RAM. Dette er imidlertid ikke trygt, fordi dataene i memcached blir overskrevet hvis ledig plass går tom. Du lurer sikkert på om ikke RAM deles på tvers av maskiner? Hvordan brukes det på hele klyngen? Memcached har muligheten til å kombinere tilgjengelig på forskjellige biler RAM i ett basseng.

Jo flere maskiner du har, jo mer kan du allokere til denne minnepoolen. Du trenger ikke samle alle maskinenes minne, men du kan, og du kan donere en vilkårlig mengde minne fra hver maskin til bassenget. Så det er en mulighet til å forlate b O mesteparten av minnet for normal bruk, og tildel en del for cachen, som lar deg cache ikke bare økter, men annen relevant informasjon. Memcached er en utmerket og utbredt løsning.

For å bruke denne tilnærmingen, må du redigere php.ini litt

Session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"

Redis klynge

Redis - NoSQL-datalagring. Lagrer databasen i tilfeldig tilgangsminne. I motsetning til memcached, støtter den vedvarende datalagring og mer komplekse datatyper. Redis støtter ikke klynging, så å bruke den for horisontal skalering er noe vanskelig, men dette er midlertidig, og alfaversjonen av klyngeløsningen er allerede utgitt.

Andre løsninger

Total

Som du kan se, er horisontal skalering av PHP-applikasjoner ikke så lett. Det er mange vanskeligheter, de fleste løsninger er ikke utskiftbare, så du må velge en og holde deg til den til slutten, for når trafikken går av skala, er det ikke lenger mulighet til å bytte til noe annet problemfritt.

Jeg håper denne lille guiden vil hjelpe deg å velge en skaleringsmetode for prosjektet ditt.

I den andre delen av artikkelen vil vi snakke om skalering av databasen.

La oss tenke oss at vi har laget en nettside. Prosessen var spennende og det var flott å se antall besøkende øke.

Men på et tidspunkt begynner trafikken å vokse veldig sakte, noen publiserte en lenke til applikasjonen din på Reddit eller Hacker News, noe skjedde med prosjektets kildekode på GitHub, og generelt så alt ut til å gå imot deg.

På toppen av det har serveren din krasjet og kan ikke håndtere den stadig økende belastningen. I stedet for å skaffe nye kunder og/eller vanlige besøkende, sitter du igjen med ingenting og dessuten en tom side.

Alle dine anstrengelser for å gjenoppta arbeidet er forgjeves - selv etter en omstart kan ikke serveren takle strømmen av besøkende. Du mister trafikk!

Ingen kan forutse trafikkproblemer. Svært få mennesker engasjerer seg i langsiktig planlegging når de jobber med et potensielt høyavkastningsprosjekt for å overholde en fastsatt tidsfrist.

Hvordan kan du da unngå alle disse problemene? For å gjøre dette må du løse to problemer: optimalisering og skalering.

Optimalisering

Først av alt bør du oppdatere til den nyeste PHP-versjoner (Gjeldende versjon 5.5, bruker OpCache), indekser databasen og cachen statisk innhold(endrer sjelden sider som Om , FAQ og så videre).

Optimalisering påvirker mer enn bare bufring av statiske ressurser. Det er også mulig å installere en ekstra ikke-Apache-server (for eksempel Nginx) spesielt utviklet for å behandle statisk innhold.

Ideen er denne: du setter Nginx foran Apache-serveren din (Ngiz vil være frontend-serveren og Apache backend), og oppgave den med å avskjære forespørsler om statiske ressurser (f.eks. *.jpg, *.png, *. mp4 , *.html ...) og deres tjeneste UTEN Å SENDE en forespørsel til Apache.

Denne ordningen kalles omvendt proxy (den nevnes ofte sammen med lastbalanseringsteknikken, som er beskrevet nedenfor).

Skalering

Det er to typer skalering - horisontal og vertikal.

Vi sier at et nettsted er skalerbart når det kan håndtere økt belastning uten behov for programvareendringer.

Vertikal skalering

Tenk deg at du har en webserver som betjener en webapplikasjon. Denne serveren har følgende spesifikasjoner: 4GB RAM, i5 CPU og 1TB HDD.

Den gjør jobben sin bra, men for å håndtere den økende trafikken bedre, bestemmer du deg for å erstatte 4 GB RAM med 16 GB, installere en ny i7 CPU og legge til en PCIe SSD/HDD hybridstasjon.

Serveren har nå blitt kraftigere og tåler økt belastning. Dette er det som kalles vertikal skalering eller " skalering i dybden"- du forbedrer egenskapene til bilen for å gjøre den kraftigere.

Dette er godt illustrert i bildet nedenfor:

Horisontal skalering

På den annen side har vi mulighet til å skalere horisontalt. I eksemplet ovenfor er det usannsynlig at kostnaden for å oppgradere maskinvaren vil være mindre enn kostnaden for den opprinnelige kostnaden for å kjøpe en serverdatamaskin.

Dette er svært økonomisk dyrt og gir ofte ikke den effekten vi forventer – de fleste skaleringsproblemene knytter seg til parallell utførelse av oppgaver.

Hvis antall prosessorkjerner ikke er nok til å kjøre de tilgjengelige trådene, spiller det ingen rolle hvor kraftig CPU-en er - serveren vil fortsatt kjøre sakte og la besøkende vente.

Horisontal skalering innebærer å bygge klynger av maskiner (ofte ganske laveffekt) koblet sammen for å betjene et nettsted.

I i dette tilfellet, brukes en lastbalanser - en maskin eller et program som bestemmer hvilken klynge som skal sende neste innkommende forespørsel.

Og maskinene i klyngen deler automatisk oppgaven seg imellom. I dette tilfellet øker nettstedets gjennomstrømning med en størrelsesorden sammenlignet med vertikal skalering. Dette er også kjent som " skaleringsbredde».

Det finnes to typer lastbalansere - maskinvare og programvare. En programvarebalansering er installert på en vanlig maskin og aksepterer all innkommende trafikk, og omdirigerer den til riktig behandler. For eksempel kan Nginx fungere som en programvarelastbalanserer.

Den aksepterer forespørsler om statiske filer og betjener dem selv uten å belaste Apache. En annen populær myk balanseringsprogramvare er Squid, som jeg bruker i firmaet mitt. Det gir deg full kontroll over alt mulige spørsmål gjennom et svært brukervennlig grensesnitt.

Maskinvarebalansere er en egen spesialmaskin som utelukkende utfører balanseoppgaven og som som regel ikke er installert annen programvare på. Mest populære modeller designet for å håndtere stor mengde trafikk.

Når du skalerer horisontalt, skjer følgende:

Merk at de to skaleringsmetodene som er beskrevet ikke utelukker hverandre - du kan forbedre maskinvareegenskapene til maskinene (også kalt noder) som brukes i et utskaleringssystem.

I denne artikkelen vil vi fokusere på horisontal skalering, siden det i de fleste tilfeller er å foretrekke (billigere og mer effektivt), selv om det er vanskeligere å implementere med teknisk poeng syn.

Vansker med dataseparasjon

Det er noen få punkter som dukker opp når du skalerer PHP-applikasjoner. Flaskehalsen her er databasen (vi skal snakke mer om dette i del 2 av denne serien).

Det oppstår også problemer med å administrere sesjonsdata, siden du har logget inn på én maskin, vil finne deg selv uautorisert hvis balanseringsenheten overfører deg til en annen datamaskin neste gang du ber om det. Det er flere måter å løse dette problemet på - du kan overføre lokale data mellom maskiner, eller bruke en vedvarende lastbalanser.

Vedvarende belastningsbalanser

En vedvarende lastbalanser husker hvor den forrige forespørselen fra en bestemt klient ble behandlet, og ved neste forespørsel sender den forespørselen dit.

For eksempel, hvis jeg besøkte siden vår og logget på der, omdirigerer lastbalanseren meg til for eksempel Server1, husker meg der, og neste gang jeg klikker, vil jeg bli omdirigert til Server1 igjen. Alt dette skjer helt transparent for meg.

Men hva om Server1 krasjet? Naturligvis vil alle sesjonsdata gå tapt, og jeg må logge inn igjen på en ny server. Dette er svært ubehagelig for brukeren. Dessuten dette ekstra belastning til lastbalanseren: ikke bare trenger den å omdirigere tusenvis av mennesker til andre servere, men den må også huske hvor den omdirigerte dem.

Dette blir nok en flaskehals. Hva om den eneste belastningsbalanseren selv mislykkes og all informasjon om plasseringen til klientene på serverne går tapt? Hvem skal styre balanseringen? Det er en komplisert situasjon, er det ikke?

Lokal datadeling

Å dele øktdata i en klynge ser definitivt ut ikke en dårlig løsning, men krever endringer i applikasjonsarkitekturen, selv om det er verdt det fordi flaskehalsen blir bred. Feilen på en server slutter å ha en fatal effekt på hele systemet.

Det er kjent at øktdata er lagret i den superglobale PHP-arrayen $_SESSION . Det er heller ingen hemmelighet at denne $_SESSION-arrayen er lagret på harddisken.

Følgelig, siden disken tilhører en eller annen maskin, har ikke andre tilgang til den. Så hvordan kan vi organisere det? generell tilgang for flere datamaskiner?

Merk at sesjonsbehandlere i PHP kan overstyres - du kan definere din egen klasse/funksjon for å administrere økter.

Bruk av databasen

Ved å bruke vår egen sesjonsbehandler kan vi være sikre på at all sesjonsinformasjon er lagret i databasen. Databasen må være på en egen server (eller i sin egen klynge). I dette tilfellet vil jevnt belastede servere bare behandle forretningslogikk.

Selv om denne tilnærmingen fungerer ganske bra, hvis det er mye trafikk, blir databasen ikke bare sårbar (hvis du mister den, mister du alt), den vil være gjenstand for mye tilgang på grunn av behovet for å skrive og lese økten data.

Dette blir nok en flaskehals i systemet vårt. I dette tilfellet kan du bruke breddeskalering, noe som er problematisk når du bruker tradisjonelle databaser som MySQL, Postgre og lignende (dette problemet vil bli dekket i andre del av serien).

Bruke et delt filsystem

Du kan sette opp et nettverksfilsystem som alle servere får tilgang til og arbeider med øktdata. Du bør ikke gjøre det. Dette er en helt ineffektiv tilnærming, med stor sannsynlighet for tap av data, og det hele fungerer veldig sakte.

Dette er en annen potensiell fare, enda farligere enn databasetilfellet beskrevet ovenfor. Aktivering av det delte filsystemet er veldig enkelt: endre verdien av session.save_path i php.ini-filen, men det anbefales sterkt å bruke en annen metode.

Hvis du fortsatt vil implementere alternativet for delt filsystem, er det mye mer Den beste avgjørelsen- GlusterFS.

Membufret

Du kan bruke memcached til å lagre øktdata i RAM. Dette er en veldig usikker metode, siden øktdata vil bli overskrevet så snart ledig diskplass går tom.

Det er ingen utholdenhet - påloggingsdata vil bli lagret så lenge den minnebuffrede serveren kjører og er tilgjengelig ledig plasså lagre disse dataene.

Du lurer kanskje på – er ikke RAM spesifikk for hver maskin? Hvordan søke denne metoden til klyngen? Memcached har muligheten til å praktisk talt kombinere all tilgjengelig RAM fra flere maskiner til en enkelt lagring:

Jo flere maskiner du har, desto større er størrelsen på den delte lagringen som opprettes. Du trenger ikke å tildele minne manuelt innenfor lagring, men du kan kontrollere prosessen ved å spesifisere hvor mye minne som kan tildeles fra hver maskin for å opprette en delt plass.

Dermed forblir den nødvendige mengden minne til disposisjon for datamaskiner for deres egne behov. Resten brukes til å lagre øktdata for hele klyngen.

I tillegg til økter kan cachen også inneholde alle andre data du ønsker, det viktigste er at det er nok ledig plass. Memcached er en utmerket løsning som har blitt mye brukt.

Det er veldig enkelt å bruke denne metoden i PHP-applikasjoner: du trenger bare å endre verdien i php.ini-filen:

session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"

Redis Cluster

Redis er et ikke-SQL-datalager i minnet som Memcached, men det er vedvarende og støtter mer komplekse datatyper enn bare PHP-array-strenger i form av "nøkkel => verdi"-par.

Denne løsningen støtter ikke klynger, så å implementere den i et horisontalt skaleringssystem er ikke så enkelt som det kan virke ved første øyekast, men det er ganske gjennomførbart. Faktisk er alfaversjonen av klyngeversjonen allerede ute, og du kan bruke den.

Sammenlignet med løsninger som Memcached, er Redis en krysning mellom en vanlig database og Memcached.

Skalerbarhet - en enhets evne til å øke sin
muligheter
ved å øke antall funksjonsblokker,
opptrer alene og
de samme oppgavene.
Glossary.ru

Vanligvis begynner folk å tenke på skalering når man
serveren kan ikke takle arbeidet som er tildelt den. Hva er det han egentlig ikke er med?
håndtere? Driften av enhver webserver koker i stor grad ned til det grunnleggende
Okkupasjonen av datamaskiner er databehandling. Svar på en HTTP (eller en annen) forespørsel
innebærer å utføre noen operasjoner på enkelte data. Henholdsvis
vi har to hovedenheter - data (preget av volumet) og
beregninger (preget av kompleksitet). Serveren kan kanskje ikke takle det
fungerer på grunn av den store datamengden (det kan hende at den ikke fysisk passer på
server), eller på grunn av stor databelastning. Praten her er
selvfølgelig, om den totale belastningen - kompleksiteten av å behandle en forespørsel kan være
er liten, men et stort antall av dem kan overvelde serveren.

Vi vil hovedsakelig snakke om skalering ved å bruke et eksempel
typisk voksende webprosjekt, men prinsippene beskrevet her egner seg også for
andre bruksområder. Først skal vi se på prosjektets arkitektur og enkel
distribuere komponentene på tvers av flere servere, og så skal vi snakke om
skalering av databehandling og data.

Typisk stedsarkitektur

Livet til et typisk nettsted begynner med en veldig enkel arkitektur
- dette er én nettserver (vanligvis spiller Apache sin rolle),
som håndterer alt arbeidet med å betjene HTTP-forespørsler,
mottatt fra besøkende. Han gir kundene såkalt "statikk", da
det er filer liggende på serverdisken som ikke krever behandling: bilder (gif,
jpg, png), stilark (css), klientskript (js, swf). Samme server
svarer på spørsmål som krever beregninger - vanligvis forming
html-sider, selv om noen ganger bilder og andre dokumenter blir opprettet på flukt.
Oftest blir svar på slike forespørsler generert av skript skrevet i PHP,
perl eller andre språk.

Ulempen med et så enkelt arbeidsopplegg er så annerledes
arten av forespørslene (opplasting av filer fra disk og beregningsarbeid av skript)
behandlet av samme webserver. Beregningsspørringer krever
holde mye informasjon i serverminnet (skriptspråktolk,
selve skriptene, dataene de jobber med) og kan ta mye
dataressurser. Utstedelse av statiske data krever tvert imot få ressurser
prosessor, men kan ta opp lang tid, hvis klienten har lav
kommunikasjonshastighet. Intern organisasjon Apache server antar at hver
forbindelsen håndteres av en egen prosess. Dette er praktisk for å kjøre skript,
den er imidlertid ikke optimal for å behandle enkle spørsmål. Det viser seg at det er tungt (fra
skript og andre data) Apache-prosesser bruker mye tid på å vente (først når de mottar
forespørsel, deretter når du sender et svar), sløsing med serverminne.

Løsningen på dette problemet er å fordele bearbeidingsarbeidet
forespørsler mellom to forskjellige programmer- dvs. inndeling i frontend og
baksiden En lett frontend-server utfører oppgavene med å levere statisk innhold, og resten
forespørsler omdirigeres (proxy) til backend, hvor formasjonen utføres
sider. Å vente på trege klienter blir også tatt hånd om av frontend, og hvis den bruker
multipleksing (når en prosess betjener flere klienter - altså
arbeid, for eksempel nginx eller lighttpd), så er ventetiden praktisk talt ingenting
kostnader.

Blant andre komponenter på nettstedet, bør databasen nevnes, i
som vanligvis lagrer hovedsystemdataene - de mest populære her er
gratis MySQL DBMS og PostgreSQL. Lagring er ofte tildelt separat
binære filer, som inneholder bilder (for eksempel illustrasjoner for artikler
nettsted, avatarer og brukerbilder) eller andre filer.

Dermed fikk vi et arkitekturdiagram bestående av
flere komponenter.

Vanligvis, i begynnelsen av et nettsteds liv, alle komponentene i arkitekturen
ligger på samme server. Hvis den slutter å takle belastningen, da
Det er en enkel løsning - flytt de lettest separerte delene til en annen
server. Den enkleste måten å starte med en database på er å flytte den til en egen server og
endre tilgangsdetaljer i skript. Forresten, i dette øyeblikket står vi overfor
viktigheten av riktig arkitektur programkode. Hvis du arbeider med en database
flyttet til en egen modul, felles for hele nettstedet - korriger deretter parameterne
tilkoblinger vil være enkle.

Måtene å skille komponentene ytterligere er også klare - for eksempel kan du flytte frontend til en egen server. Men vanligvis frontend
krever lite systemressurser og på dette stadiet vil fjerningen ikke gi betydelig
produktivitetsgevinster. Oftest er nettstedet begrenset av ytelse.
skript - å generere et svar (html-side) tar for lang tid.
Derfor er neste trinn vanligvis å skalere backend-serveren.

Beregningsfordeling

En typisk situasjon for et voksende nettsted - databasen er allerede
flyttet til en egen maskin, er inndelingen i frontend og backend fullført,
trafikken fortsetter imidlertid å øke og backend har ikke tid til å behandle
forespørsler. Det betyr at vi må fordele beregningene på flere
servere. Dette er enkelt å gjøre - bare kjøp en ekstra server og installer den på
Den inneholder programmer og skript som er nødvendige for at backend skal fungere.
Etter dette må du sørge for at brukerforespørsler er distribuert
(balansert) mellom de mottatte serverne. OM på forskjellige måter balansering
vil bli diskutert nedenfor, men foreløpig merker vi at dette vanligvis gjøres av frontend,
som er konfigurert slik at den fordeler forespørsler jevnt mellom
servere.

Det er viktig at alle backend-servere er i stand til riktig
svare på forespørsler. Dette krever vanligvis hver av dem å jobbe med
samme oppdaterte datasett. Hvis vi lagrer all informasjon i en enkelt
database, så vil DBMS selv sørge for delt tilgang og datakonsistens.
Hvis noen data er lagret lokalt på serveren (for eksempel php-økter
klient), bør du tenke på å overføre dem til en delt lagring, eller mer
kompleks forespørselsfordelingsalgoritme.

Ikke bare arbeid kan fordeles på flere servere
skript, men også beregninger utført av databasen. Hvis DBMS yter mye
komplekse spørringer, tar opp server CPU-tid, kan du opprette flere
kopier av databasen til forskjellige servere. Dette reiser spørsmålet om synkronisering
data ved endringer, og flere tilnærminger er aktuelt her.

Synkronisering på søknadsnivå. I dette tilfellet vårt
skript skriver uavhengig endringer til alle kopier av databasen (og bærer selv
ansvar for riktigheten av dataene). Dette er ikke det beste alternativet fordi det
krever forsiktighet ved implementering og er svært feiltolerant.
Replikering- det vil si automatisk replikering
endringer gjort på én server påvirker alle andre servere. Vanligvis når
Når du bruker replikering, blir endringer alltid skrevet til samme server - det kalles master, og de resterende kopiene kalles slave. De fleste DBMS-er har
innebygd eller eksterne midlerå organisere replikering. Skille
synkron replikering - i dette tilfellet vil en forespørsel om å endre data vente
inntil dataene er kopiert til alle servere, og først da vil de fullføres vellykket - og asynkront - i dette tilfellet kopieres endringene til slaveserverne fra
forsinkelse, men skriveforespørselen fullføres raskere.
Multi-master replikering. Denne tilnærmingen er lik
den forrige, men her kan vi endre dataene uten tilgang
én bestemt server, men til en hvilken som helst kopi av databasen. Samtidig endres
synkront eller asynkront vil bli overført til andre kopier. Noen ganger kalles denne ordningen
begrepet "databaseklynge".

Mulig forskjellige varianter distribusjon av systemet mellom servere.
For eksempel kan vi ha én databaseserver og flere backends (very
typisk skjema), eller omvendt - en backend og flere databaser. Hva om vi skalerer
både backend server og database, så kan du kombinere backend og en kopi av databasen på
én bil. I alle fall så snart vi har flere eksemplarer
hvilken som helst server, oppstår spørsmålet om hvordan man fordeler dem riktig
laste.

Balansemetoder

La oss lage flere servere (for ethvert formål - http, database, etc.), som hver kan behandle forespørsler. Før
vi står overfor oppgaven om hvordan vi skal fordele arbeid mellom dem, hvordan finne ut hvilke
server sende en forespørsel? Det er to hovedmåter å distribuere forespørsler på.

Balanseringsenhet. I dette tilfellet sender klienten en forespørsel til en
en fast server kjent for ham, og den omdirigerer allerede forespørselen til en av
fungerende servere. Et typisk eksempel er et nettsted med én frontend og flere
backend-servere som forespørsler sendes til. Det kan imidlertid "klienten".
være inne i systemet vårt - for eksempel kan et script sende en forespørsel til
til en databaseproxy-server som sender forespørselen til en av DBMS-tjenerne.
Selve balanseringsnoden kan fungere både på en egen server og på en
fra fungerende servere.
Fordelene med denne tilnærmingen er
som klienten ikke trenger å vite noe om intern struktur systemer - om mengde
servere, om deres adresser og funksjoner - bare
balanserer Ulempen er imidlertid at balanseringsenheten er en enkelt
feilpunkt for systemet - hvis det svikter, vil hele systemet være det
uvirksom. I tillegg kan balanseren ganske enkelt stoppe under stor belastning
takle arbeidet sitt, så denne tilnærmingen er ikke alltid aktuelt.
Balansering på klientsiden. Hvis vi vil unngå
enkelt punkt for feil, det er et alternativt alternativ - å betro valget av serveren
til klienten selv. I dette tilfellet må klienten kjenne til den interne strukturen til vår
systemer for å kunne velge riktig hvilken server som skal kontaktes.
En utvilsom fordel er fraværet av et feilpunkt - hvis en av de
servere klienten vil kunne kontakte andre. Prisen for dette er imidlertid
mer kompleks klientlogikk og mindre balanseringsfleksibilitet.

Selvfølgelig finnes det også kombinasjoner av disse tilnærmingene. For eksempel,
en så velkjent metode for lastfordeling som DNS-balansering er basert på
at når du bestemmer IP-adressen til et nettsted, gis klienten
adressen til en av flere identiske servere. Dermed fungerer DNS som en
rollen til balanseringsnoden som klienten mottar "distribusjonen" fra. derimot
selve strukturen til DNS-servere innebærer fravær av et feilpunkt pga
duplisering - det vil si at fordelene med to tilnærminger kombineres. Selvfølgelig, denne
Det er også ulemper med balanseringsmetoden - for eksempel er et slikt system vanskelig å dynamisk
gjenoppbygge.

Arbeid med et nettsted er vanligvis ikke begrenset til én forespørsel.
Derfor, når du designer, er det viktig å forstå om sekvensielle spørringer kan
klient behandles riktig av forskjellige servere, eller klienten må være det
knyttet til én server mens du arbeider med nettstedet. Dette er spesielt viktig hvis
nettstedet lagrer midlertidig informasjon om brukerens økt (i denne
tilfelle er også mulig gratis distribusjon- men da er det nødvendig å lagre
økter (lagring felles for alle servere). "Bind" den besøkende til
du kan spesifisere en spesifikk server ved dens IP-adresse (som imidlertid kan endres),
eller via informasjonskapsel (hvor serveridentifikatoren er forhåndsinnspilt), eller til og med
ganske enkelt ved å omdirigere den til ønsket domene.

På den annen side kan det hende at dataservere ikke har like rettigheter.
I noen tilfeller er det fordelaktig å gjøre det motsatte, å tildele en egen server til
behandle forespørsler av én type – og få en vertikal inndeling
funksjoner. Deretter vil klienten eller balanseringsnoden velge serveren i
avhengig av typen mottatt forespørsel. Denne tilnærmingen lar oss skille
viktige (eller omvendt, ikke kritiske, men vanskelige) forespørsler fra andre.

Datadistribusjon

Vi har lært å fordele beregninger, så en stor
oppmøte er ikke et problem for oss. Datavolumet fortsetter imidlertid å vokse,
lagring og behandling av dem blir stadig vanskeligere - noe som betyr at det er på tide å bygge
distribuert datalagring. I dette tilfellet vil vi ikke lenger ha en eller
flere servere som inneholder en fullstendig kopi av databasen. I stedet dataene
vil bli distribuert over forskjellige servere. Hvilke distribusjonsordninger er mulig?

Vertikal fordeling(vertikal partisjonering) - i det enkleste tilfellet
utgjør en kjennelse separate tabeller database til en annen server. På
I dette tilfellet må vi endre skriptene for å få tilgang til forskjellige servere
forskjellige data. I grensen kan vi lagre hvert bord på en separat server
(selv om dette i praksis neppe er gunstig). Tydeligvis med dette
distribusjon, mister vi muligheten til å lage SQL-spørringer som kombinerer data fra
to bord plassert på forskjellige servere. Om nødvendig kan du implementere
flette logikk i applikasjonen, men det vil ikke være like effektivt som i et DBMS.
Derfor, når du partisjonerer en database, må du analysere relasjonene mellom tabeller,
å distribuere så uavhengige tabeller som mulig.
Mer kompleks sak
vertikal basefordeling er en dekomponering av en tabell når en del
noen av kolonnene havner på én server, og noen av dem ender opp på en annen. Denne teknikken
er mindre vanlig, men kan for eksempel brukes til å skille små
og hyppig oppdaterte data fra et stort volum av sjelden brukte data.
Horisontal fordeling(horisontal partisjonering) - består av
distribuere data fra én tabell over flere servere. Faktisk på
hver server lager en tabell med samme struktur og lagrer
en viss del av data. Du kan distribuere data på tvers av servere på forskjellige måter
kriterier: etter område (poster med id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, resten - til server B) eller ved hash-verdien til et bestemt felt
poster. Horisontal partisjonering av data lar deg lagre ubegrenset
antall poster kompliserer imidlertid utvalget. Den mest effektive måten å velge på
registrerer kun når det er kjent på hvilken server de er lagret.

For å velge riktig datadistribusjonsskjema må du
analyser strukturen til databasen nøye. Eksisterende tabeller (og ev
individuelle felt) kan klassifiseres etter frekvens av tilgang til poster, etter frekvens
oppdateringer og relasjoner (behovet for å gjøre valg fra flere
tabeller).

Som nevnt ovenfor, i tillegg til en database, trenger et nettsted ofte
lagring for binære filer. Distribuerte fillagringssystemer
(faktisk filsystemer) kan deles inn i to klasser.

Arbeider på nivået operativsystem . Dessuten for
applikasjoner som jobber med filer i et slikt system er ikke forskjellig fra vanlig arbeid Med
filer. Utveksling av informasjon mellom servere håndteres av operativsystemet.
Som eksempler på slike filsystemer vi kan sitere det som har vært kjent i lang tid
NFS familie eller mindre kjent, men mer moderne system Glans.
Implementert på søknadsnivå distribuert
arkiver innebærer at arbeidet med å utveksle informasjon utføres av seg selv
applikasjon. Vanligvis er funksjoner for arbeid med oppbevaring plassert i
eget bibliotek. Et av de slående eksemplene på slik lagring er MogileFS, utviklet av
av skaperne av LiveJournal. Et annet vanlig eksempel er bruk
WebDAV-protokoll og lagring som støtter det.

Det skal bemerkes at datadistribusjon ikke bare bestemmer
et spørsmål om lagring, men også delvis et spørsmål om lastfordeling - på hver
Det er færre poster på serveren, og derfor behandles de raskere.
Kombinasjonen av metoder for fordeling av beregninger og data gjør det mulig å bygge
potensielt ubegrenset skalerbar arkitektur som er i stand til å jobbe med
enhver mengde data og enhver belastning.

konklusjoner

For å oppsummere det som er sagt, la oss formulere konklusjoner i form av korte avhandlinger.

De to viktigste (og relaterte) skaleringsutfordringene er datadistribusjon og datadistribusjon
Typisk stedsarkitektur innebærer separasjon av roller og
inkluderer frontend, backend, database og noen ganger fillagring
For små mengder data og tunge belastninger søke om
databasespeiling - synkron eller asynkron replikering
For store datamengder er det nødvendig å distribuere databasen - delt
den vertikalt eller horisontalt
Binærfiler lagres på distribuerte filsystemer
(implementert på OS-nivå eller i applikasjonen)
Balansering (fordeling av forespørsler) kan være enhetlig eller
delt etter funksjonalitet; med en balanserende node, eller på klientsiden
Den riktige kombinasjonen av metoder vil tillate deg å tåle enhver belastning;)

Linker

Du kan fortsette å studere dette emnet på interessante engelskspråklige nettsteder og blogger.