Škálovateľnosť – schopnosť zariadenia zvýšiť svoju
možnosti
zvýšením počtu funkčných blokov,
vystupovanie samostatne a
rovnaké úlohy.
Glossary.ru
Zvyčajne ľudia začnú premýšľať o škálovaní, keď jeden
server sa nedokáže vyrovnať s prácou, ktorá mu bola pridelená. S čím presne nie je?
vyrovnať sa? Prevádzka akéhokoľvek webového servera sa z veľkej časti scvrkáva na základy
Povolanie počítačov je spracovanie údajov. Odpoveď na požiadavku HTTP (alebo akúkoľvek inú).
zahŕňa vykonávanie niektorých operácií s niektorými údajmi. resp.
máme dve hlavné entity – dáta (charakterizované svojim objemom) a
výpočty (charakterizované zložitosťou). Server sa s tým nemusí vedieť vyrovnať
pracovať kvôli veľkému množstvu dát (nemusí sa fyzicky zmestiť
server) alebo z dôvodu veľkej výpočtovej záťaže. Hovorí sa tu
samozrejme o celkovej záťaži - náročnosť spracovania jednej požiadavky môže byť
je malý, ale veľký počet z nich môže zahltiť server.
Budeme hovoriť hlavne o škálovaní pomocou príkladu
typický rastúci webový projekt, ale tu opísané princípy sú vhodné aj pre
iné oblasti použitia. Najprv sa pozrieme na architektúru projektu a jednoduchosť
jeho distribúciu komponentov na niekoľko serverov a potom sa o tom porozprávame
škálovanie výpočtovej techniky a údajov.
Typická architektúra stránok
Život typického webu začína veľmi jednoduchou architektúrou
- toto je jeden webový server (zvyčajne hrá svoju úlohu Apache),
ktorý sa stará o všetku prácu pri obsluhe požiadaviek HTTP,
prijaté od návštevníkov. Klientom teda dáva takzvanú „statiku“.
na disku servera ležia súbory, ktoré nevyžadujú spracovanie: obrázky (gif,
jpg, png), štýly (css), klientské skripty (js, swf). Rovnaký server
odpovedá na otázky, ktoré vyžadujú výpočty - zvyčajne formovanie
html stránky, aj keď niekedy sa obrázky a iné dokumenty vytvárajú za chodu.
Najčastejšie odpovede na takéto požiadavky generujú skripty napísané v PHP,
perl alebo iné jazyky.
Nevýhodou takejto jednoduchej pracovnej schémy je, že odlišná
charakter požiadaviek (nahrávanie súborov z disku a výpočtová práca skriptov)
spracovávané tým istým webovým serverom. Výpočtové otázky vyžadujú
uchovávať veľa informácií v pamäti servera (tlmočník skriptovacieho jazyka,
samotné skripty, dáta, s ktorými pracujú) a dá zabrať
výpočtových zdrojov. Vydávanie statických údajov si naopak vyžaduje málo zdrojov
procesor, ale môže zabrať na dlhú dobu, ak má klient nízku
rýchlosť komunikácie. Vnútorný dizajn servera Apache predpokladá, že každý
pripojenie je riešené samostatným procesom. To je vhodné pre spúšťanie skriptov,
nie však optimálne na spracovanie jednoduché otázky. Ukazuje sa, že ťažké (od
skripty a iné údaje) Procesy Apache trávia veľa času čakaním (najprv pri prijímaní
žiadosť, potom pri odosielaní odpovede), plytvanie pamäťou servera.
Riešením tohto problému je rozloženie spracovateľskej práce
žiadosti medzi dvoma rôzne programy- t.j. rozdelenie na frontend a
backend Ľahký frontend server vykonáva úlohy poskytovania statického obsahu a ostatné
požiadavky sú presmerované (proxy) na backend, kde sa formácia vykonáva
stránky. O čakanie na pomalých klientov sa stará aj frontend, a ak využíva
multiplexovanie (keď jeden proces obsluhuje viacerých klientov – tzv
práca, napríklad nginx alebo lighttpd), potom čakanie prakticky nič
náklady.
Medzi ostatnými súčasťami stránky je potrebné uviesť databázu, v
ktorý zvyčajne ukladá hlavné systémové údaje - najobľúbenejšie sú tu
bezplatné DBMS MySQL a PostgreSQL. Úložný priestor sa často prideľuje samostatne
binárne súbory, ktorý obsahuje obrázky (napríklad ilustrácie k článkom
stránky, avatary a fotografie používateľov) alebo iné súbory.
Takto sme dostali schému architektúry pozostávajúcu z
niekoľko komponentov.
Typicky, na začiatku života lokality, všetky komponenty architektúry
umiestnené na rovnakom serveri. Ak sa prestane vyrovnávať so záťažou, tak
Existuje jednoduché riešenie – premiestnite najľahšie oddelené časti na iné
server. Najjednoduchší spôsob, ako začať s databázou, je presunúť ju na samostatný server a
zmeniť prístupové údaje v skriptoch. Mimochodom, v tejto chvíli čelíme
dôležitosť správnej architektúry programový kód. Ak pracujete s databázou
presunuté do samostatného modulu, spoločného pre celý web – potom opravte parametre
spojenia budú jednoduché.
Spôsoby ďalšieho oddelenia komponentov sú tiež jasné - napríklad môžete presunúť frontend na samostatný server. Ale zvyčajne frontend
vyžaduje málo systémových prostriedkov a v tejto fáze jeho odstránenie nebude znamenať významné
zvýšenie produktivity. Najčastejšie je stránka obmedzená výkonom.
skripty - generovanie odpovede (html stránky) trvá príliš dlho.
Ďalším krokom je preto zvyčajne škálovanie backendového servera.
Rozdelenie výpočtu
Typická situácia pre rastúci web - databáza už existuje
odovzdané do samostatné auto, je dokončené rozdelenie na frontend a backend,
návštevnosť však stále rastie a backend nestíha spracovať
žiadosti. To znamená, že výpočty musíme rozdeliť do niekoľkých
serverov. Je to jednoduché – stačí si kúpiť druhý server a nainštalovať ho
Obsahuje programy a skripty potrebné na fungovanie backendu.
Potom sa musíte uistiť, že požiadavky používateľov sú distribuované
(vyvážené) medzi prijatými servermi. O rôznymi spôsobmi vyrovnávanie
bude diskutované nižšie, ale teraz si všimneme, že to zvyčajne robí frontend,
ktorý je nakonfigurovaný tak, aby rovnomerne rozdeľoval požiadavky medzi
serverov.
Je dôležité, aby všetky backend servery boli schopné správne
reagovať na žiadosti. To zvyčajne vyžaduje, aby s každým z nich pracoval
rovnaký aktuálny súbor údajov. Ak všetky informácie uložíme do jedného
databázu, potom zabezpečí samotný DBMS zdieľanie a konzistentnosť údajov.
Ak sú niektoré údaje uložené lokálne na serveri (napríklad relácie php
klient), potom by ste mali uvažovať o ich prenose na zdieľané úložisko, alebo o viac
komplexný algoritmus distribúcie požiadaviek.
Nielen práca môže byť distribuovaná na niekoľko serverov
skripty, ale aj výpočty vykonávané databázou. Ak DBMS vykonáva veľa
zložitých dotazov, ktoré zaberajú čas procesora servera, môžete vytvoriť niekoľko
kópie databázy na rôznych serveroch. To vyvoláva problém synchronizácie
údaje pri zmenách a tu je možné použiť niekoľko prístupov.
- Synchronizácia na aplikačnej úrovni. V tomto prípade náš
skripty nezávisle zapisujú zmeny do všetkých kópií databázy (a sami nesú
zodpovednosť za správnosť údajov). Toto nie je najlepšia možnosť pretože on
vyžaduje opatrnosť pri implementácii a je vysoko odolný voči chybám. - Replikácia- teda automatická replikácia
zmeny vykonané na jednom serveri ovplyvnia všetky ostatné servery. Zvyčajne keď
Pri použití replikácie sa zmeny vždy zapisujú na ten istý server – nazýva sa master a zvyšné kópie sa nazývajú slave. Väčšina DBMS má
vstavaný resp externé fondy organizovať replikáciu. Rozlišovať
synchrónna replikácia – v tomto prípade počká požiadavka na zmenu údajov
kým sa údaje neskopírujú na všetky servery a až potom sa úspešne a asynchrónne dokončia, v tomto prípade sa zmeny skopírujú na podriadené servery z
oneskorenie, ale žiadosť o zápis sa dokončí rýchlejšie. - Multi-majster replikácie. Tento prístup je podobný
predchádzajúci, ale tu môžeme zmeniť údaje bez prístupu
jeden konkrétny server, ale na akúkoľvek kópiu databázy. Zároveň zmeny
synchrónne alebo asynchrónne budú prenesené do iných kópií. Niekedy sa táto schéma nazýva
pojem "databázový klaster".
možné rôzne možnosti distribúcia systému medzi servery.
Napríklad môžeme mať jeden databázový server a niekoľko backendov (veľmi
typická schéma), alebo naopak - jeden backend a niekoľko databáz. Čo keby sme škálovali
backend server aj databázu, potom môžete skombinovať backend a kópiu databázy
jedno auto. V každom prípade, hneď ako budeme mať niekoľko kópií
akýkoľvek server, vyvstáva otázka, ako medzi nimi správne distribuovať
zaťaženie.
Metódy vyvažovania
Vytvorme niekoľko serverov (na akýkoľvek účel - http, databáza atď.), z ktorých každý môže spracovávať požiadavky. Predtým
stojíme pred úlohou, ako medzi nich rozdeliť prácu, ako zistiť ktorú
server poslať požiadavku? Existujú dva hlavné spôsoby distribúcie žiadostí.
- Vyvažovacia jednotka. V tomto prípade klient pošle požiadavku jednému
pevný server, ktorý pozná, a ten už presmeruje požiadavku na jeden z
fungujúce servery. Typickým príkladom je stránka s jedným frontendom a viacerými
backend servery, na ktoré sa odosielajú požiadavky. „Klient“ však môže
byť v našom systéme – napríklad skript môže odoslať požiadavku
na databázový proxy server, ktorý odošle požiadavku jednému zo serverov DBMS.
Samotný vyvažovací uzol môže pracovať na samostatnom serveri aj na jednom
z fungujúcich serverov.Výhody tohto prístupu sú
že klient nemusí vedieť nič o vnútornej štruktúre systému – o množstve
o ich adresách a funkciách - iba
vyvažovačka Nevýhodou však je, že vyvažovacia jednotka je jednoduchá
bod zlyhania systému – ak zlyhá, bude ním celý systém
nefunkčný. Navyše, pri veľkom zaťažení sa balancer môže jednoducho zastaviť
vyrovnať sa s ich prácou, takže tento prístup nie je vždy použiteľný. - Vyvažovanie na strane klienta. Ak sa chceme vyhnúť
jediný bod zlyhania, existuje alternatívna možnosť - zveriť výber servera
samotnému klientovi. V tomto prípade musí klient vedieť o vnútornej štruktúre našej
aby ste si mohli správne vybrať, na ktorý server sa obrátiť.
Nepochybnou výhodou je absencia bodu zlyhania - ak je jedným z
servery, klient bude môcť kontaktovať ostatných. Cena za to však je
zložitejšia logika klienta a menšia flexibilita vyrovnávania.
Samozrejme, existujú aj kombinácie týchto prístupov. napr.
taký známy spôsob vyvažovanie záťaže, podobne ako vyvažovanie DNS, je založené na
že pri určovaní IP adresy stránky je daný klient
adresu jedného z niekoľkých rovnakých serverov. DNS teda funguje ako
úloha vyrovnávacieho uzla, z ktorého klient prijíma „distribúciu“. Avšak
samotná štruktúra serverov DNS naznačuje absenciu bodu zlyhania v dôsledku
duplikácia – to znamená, že sa spájajú výhody dvoch prístupov. Samozrejme, tento
Metóda vyvažovania má aj nevýhody – napríklad takýto systém sa dynamicky ťažko robí
prestavať.
Práca so stránkou sa zvyčajne neobmedzuje na jednu požiadavku.
Preto je pri navrhovaní dôležité pochopiť, či môžu sekvenčné dotazy
klienta správne spracovať rôzne servery, alebo to musí byť klient
viazané na jeden server počas práce s webom. Toto je obzvlášť dôležité, ak
Stránka ukladá dočasné informácie o relácii používateľa (v tomto
prípad je tiež možný bezplatná distribúcia- vtedy je však potrebné skladovať
relácie (úložisko spoločné pre všetky servery). „Pripútať“ návštevníka
konkrétny server môžete špecifikovať podľa jeho IP adresy (ktorá sa však môže zmeniť),
alebo súborom cookie (v ktorom je vopred zaznamenaný identifikátor servera), alebo dokonca
jednoduchým presmerovaním na požadovanú doménu.
Na druhej strane, počítačové servery nemusia mať rovnaké práva.
V niektorých prípadoch je výhodné urobiť opak, vyčleniť preň samostatný server
spracovanie žiadostí jedného typu - a získajte vertikálne rozdelenie
funkcie. Potom klient alebo vyvažovací uzol vyberie server
v závislosti od typu prijatej žiadosti. Tento prístup nám umožňuje oddeliť sa
dôležité (alebo naopak, nie kritické, ale náročné) požiadavky od ostatných.
Distribúcia údajov
Naučili sme sa distribuovať výpočty, takže veľké
dochádzka nám nerobí problém. Objemy dát však stále rastú,
ich skladovanie a spracovanie je čoraz náročnejšie – čo znamená, že je čas stavať
distribuované úložisko dát. V tomto prípade už nebudeme mať jeden resp
obsahuje niekoľko serverov úplná kópia databázy. Namiesto toho dáta
budú distribuované na rôznych serveroch. Aké distribučné schémy sú možné?
- Vertikálna distribúcia(vertikálne rozdelenie) - v najjednoduchšom prípade
predstavuje prenos jednotlivých databázových tabuliek na iný server. O
V tomto prípade budeme musieť zmeniť skripty na prístup k rôznym serverom
rozdielne údaje. V limite môžeme uložiť každú tabuľku na samostatnom serveri
(hoci v praxi to pravdepodobne nebude prospešné). Očividne s týmto
distribúcie, strácame možnosť vytvárať SQL dotazy, ktoré kombinujú dáta z
dve tabuľky umiestnené na rôznych serveroch. V prípade potreby môžete implementovať
zlučovanie logiky v aplikácii, ale nebude to také efektívne ako v DBMS.
Preto pri rozdeľovaní databázy musíte analyzovať vzťahy medzi tabuľkami,
distribuovať čo najviac nezávislé tabuľky.Zložitejší prípad
vertikálna základná distribúcia je rozkladom jednej tabuľky, keď časť
niektoré z jeho stĺpcov končia na jednom serveri a niektoré z nich na inom. Táto technika
je menej častý, ale dá sa použiť napríklad na oddeľovanie malých
a často aktualizované údaje z veľkého objemu zriedka používaných údajov. - Horizontálne rozdelenie(horizontálne členenie) – pozostáva z
distribúcia údajov z jednej tabuľky na niekoľko serverov. V skutočnosti na
každý server vytvorí tabuľku rovnakej štruktúry a uloží ju
určitý údaj. Údaje môžete distribuovať medzi servery rôznymi spôsobmi
kritériá: podľa rozsahu (záznamy s id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, zvyšok - na server B) alebo podľa hash hodnoty určitého poľa
záznamy. Horizontálne rozdelenie dát vám umožňuje ukladať neobmedzené množstvo
množstvo záznamov však výber komplikuje. Najefektívnejší spôsob výberu
záznamy iba vtedy, keď je známe, na ktorom serveri sú uložené.
Ak chcete vybrať správnu schému distribúcie údajov, musíte
dôkladne analyzovať štruktúru databázy. Existujúce tabuľky (a príp
jednotlivé polia) možno klasifikovať podľa frekvencie prístupu k záznamom, podľa frekvencie
aktualizácie a vzťahy (potreba urobiť výber z niekoľkých
tabuľky).
Ako už bolo spomenuté vyššie, okrem databázy stránka často potrebuje
úložisko pre binárne súbory. Distribuované systémy na ukladanie súborov
(v skutočnosti súborové systémy) možno rozdeliť do dvoch tried.
- Pracovné na úrovni operačného systému. Navyše pre
aplikáciách sa práca so súbormi v takomto systéme nelíši od bežnej práce s
súbory. Výmenu informácií medzi servermi zabezpečuje operačný systém.
Príklady takýchto súborových systémov zahŕňajú dlho známe
rodina NFS alebo menej známy, no modernejší systém Luster. - Realizované na aplikačnej úrovni distribuované
repozitárov znamená, že prácu na výmene informácií vykonáva sám
aplikácie. Spravidla sú umiestnené funkcie na prácu s úložiskom
samostatná knižnica. Jedným z nápadných príkladov takéhoto úložiska je MogileFS, vyvinutý spoločnosťou
od tvorcov LiveJournalu. Ďalším bežným príkladom je použitie
Protokol WebDAV a jeho podporné úložisko.
Treba si uvedomiť, že distribúcia dát rozhoduje nielen
otázka skladovania, ale čiastočne aj otázka rozloženia nákladu - na každom
Na serveri je menej záznamov, a preto sa spracúvajú rýchlejšie.
Kombinácia metód pre distribúciu výpočtov a dát umožňuje stavať
potenciálne neobmedzene škálovateľná architektúra schopná pracovať
akékoľvek množstvo dát a akékoľvek zaťaženie.
Závery
Aby sme zhrnuli povedané, sformulujme závery vo forme stručných téz.
- Dve hlavné (a súvisiace) výzvy škálovania sú distribúcia výpočtov a distribúcia údajov
- Typická architektúra lokality zahŕňa oddelenie rolí a
zahŕňa frontend, backend, databázu a niekedy aj úložisko súborov - Pre malé množstvo dát a veľkú záťaž použite
zrkadlenie databázy - synchrónna alebo asynchrónna replikácia - Pre veľké množstvo dát je potrebné databázu distribuovať – rozdeliť
to vertikálne alebo horizontálne - Binárne súbory sú uložené v distribuovaných súborových systémoch
(implementované na úrovni OS alebo v aplikácii) - Bilancovanie (rozdelenie požiadaviek) môže byť jednotné resp
rozdelené podľa funkčnosti; s vyrovnávacím uzlom, alebo na strane klienta - Správna kombinácia metód vám umožní vydržať akúkoľvek záťaž;)
Odkazy
V štúdiu tejto témy môžete pokračovať na zaujímavých anglicky písaných stránkach a blogoch.
Oleg Spiryaev
IN v poslednej dobeČasto sa uvádza, že servery strednej a vyššej triedy sú aktívne nahradené skupinami serverov základnej úrovne, združených v stojanoch alebo klastroch. Niektorí odborníci však nesúhlasia. Podľa Dataquestu sa teda podiel modelov s cenou 500 000 USD a viac (vrátane serverov strednej a vyššej triedy SMP) na celkovom predaji serverov od roku 2000 do roku 2002 zvýšil z 38 na 52 %.
Ďalšie údaje získané IDC naznačujú rast (aspoň čo sa týka počtu strojov) v sektore low-end modelov serverov - s dvoma procesormi. IDC tiež predpovedá, že v roku 2005 najčastejšie operačný systém pre servery s cenou od 50 tisíc do 3 miliónov dolárov bude Unix. Z porovnania týchto údajov je zrejmé, že prevládajúcou platformou pre dátové centrá zostanú servery strednej a vyššej kategórie Unix, ale budú doplnené o rastúci počet menších (zvyčajne dvojprocesorových) serverov.
Tento trend sa objavil v dôsledku oddelenia rôznych vrstiev výpočtovej techniky v dátových centrách (obr. 1). Úroveň 1 alebo predná vrstva postupne prechádza na model horizontálneho škálovania malé servery a Trieru 3 (databázová vrstva) dominujú škálovateľné servery. Vrstva 2 (aplikačná vrstva) sa stáva oblasťou, kde koexistujú vertikálne a horizontálne architektúry.
Vertikálne a horizontálne architektúry
Pozrime sa na hlavné rozdiely medzi vertikálnou a horizontálnou architektúrou. Škálovateľné servery sú veľké systémy SMP (symetrický multiprocesing alebo zdieľaná pamäť) s viac ako štyrmi centrálnymi procesorovými jednotkami. Používajú iba jednu kópiu OS na ovládanie všetkých procesorov, pamäte a I/O komponentov. Všetky tieto zdroje sú zvyčajne umiestnené v jednom stojane alebo skrinke. Tieto servery sú prepojené cez vysokorýchlostnú centrálu alebo backplane s nízkou latenciou a koherentným prístupom k vyrovnávacej pamäti. Zdroje môžete pridať inštaláciou ďalších prostriedkov do skrinky základné dosky. V systémoch vertikálnej architektúry (alebo SMP systémoch) je pamäť zdieľaná, čo znamená, že všetky procesory a I/O komponenty majú prístup k celej pamäti. Používateľ „vidí“ pamäť ako jeden veľký objekt.
Alternatívne, horizontálne škálovanie, sú systémy prepojené cez sieť alebo klastrované dohromady. Pre prepojenia štandardné sieťové technológie ako napríklad Fast Ethernet, Gigabit Ethernet(GBE) a Scalable Coherent Interconnect (SCI), čím je menej priepustnosť a väčšie oneskorenie v porovnaní s vertikálne systémy. Zdroje sú v tomto prípade rozdelené medzi uzly, ktoré zvyčajne obsahujú jeden až štyri procesory; každý uzol má svoj vlastný procesor a pamäť a môže mať svoj vlastný I/O subsystém alebo ho zdieľať s inými uzlami. Každý uzol spúšťa samostatnú kópiu OS. Zdroje sa rozširujú pridávaním uzlov, ale nie pridávaním zdrojov do uzla. Pamäť v horizontálnych systémoch je distribuovaná, t.j. každý uzol má vlastnej pamäti, ku ktorému majú priamy prístup jeho procesory a I/O subsystém. Prístup k týmto prostriedkom z iného uzla je oveľa pomalší ako z uzla, kde sa nachádzajú. Navyše pri horizontálnej architektúre neexistuje konzistentný prístup medzi uzlami do pamäte a používané aplikácie spotrebúvajú relatívne málo zdrojov, takže sa „zmestia“ na jeden uzol a nepotrebujú konzistentný prístup. Ak aplikácia vyžaduje viacero uzlov, musí sama poskytovať konzistentný prístup k pamäti.
Ak horizontálny systém spĺňa požiadavky aplikácie, potom je táto architektúra výhodnejšia, pretože jej obstarávacie náklady sú nižšie. Obvykle sú obstarávacie náklady na procesor pre horizontálne systémy nižšie ako pre vertikálne systémy. Rozdiel v cene je spôsobený tým, že vertikálne systémy využívajú výkonnejšie funkcie RAS (spoľahlivosť, dostupnosť, servisovateľnosť), ako aj vysokovýkonné prepojenia. Existuje však množstvo obmedzení pri používaní systémov s horizontálnou architektúrou. Nižšie si rozoberieme, za akých podmienok je možné použiť horizontálne systémy a kedy je potrebné vertikálne škálovanie.
Vertikálna architektúra okrem jedného veľkého SMP servera zahŕňa aj klastre veľkých SMP serverov používaných pre jednu rozsiahlu aplikáciu.
Príkladom horizontálnych serverov sú nedávno uvedené modulárne alebo blade servery na trhu, zvyčajne vybavené jedným alebo dvoma procesormi. Tu klaster pozostáva z malých uzlov, z ktorých každý má SMP server základnej úrovne s počtom centrálnych procesorov od 1 do 4.
Ďalším spôsobom škálovania sú veľké masívne paralelné výpočtové systémy (MPP), ktoré pozostávajú z mnohých malých procesorov inštalovaných v jednej skrini, z ktorých každý má svoju vlastnú kópiu OS alebo kópiu mikrojadra OS. V súčasnosti sa vyrába len niekoľko MPP systémov, ktoré najčastejšie predstavujú špecializované riešenia. Ide napríklad o systémy Terradata vyrábané spoločnosťami NCR, IBM RS/6000SP (SP-2) a HP Tandem nonstop.
Tabuľka 1. Vlastnosti vertikálnych a horizontálnych architektúr
| Parameter | Vertikálne systémy | Horizontálne systémy |
| pamäť | Veľké zdieľané | Malý oddaný |
| Prúdy | Mnoho vzájomne závislých vlákien | Mnoho nezávislých vlákien |
| Vzájomné prepojenia | Pevne spojené vnútorné | Voľne spojené externé |
| RAS | Výkonný RAS jednotný systém | Výkonný RAS využívajúci replikáciu |
| Centrálne procesorové jednotky | Veľa štandardných | Veľa štandardných |
| OS | Jedna kópia OS pre mnoho centrálnych procesorov | Niekoľko kópií operačného systému (jedna kópia pre 1-4 procesory) |
| Rozloženie | V jednej skrini | Umiestnenie veľkého počtu serverov do stojana |
| Hustota | Vysoká hustota procesora na jednotku podlahovej plochy | |
| Vybavenie | Štandardné a špeciálne navrhnuté | Štandardné |
| Škálovanie | V rámci jedného serverového šasi | V multiserverovom meradle |
| Rozšírenie | Inštaláciou ďalších komponentov na server | Pridaním nových uzlov |
| Architektúra | 64-bitový | 32- a 64-bitové |
Tabuľka 1 vám umožňuje vykonať komparatívna analýza vertikálne a horizontálne architektúry.
- Vertikálne systémy zdieľajú pamäť a poskytujú konzistentný prístup k vyrovnávacej pamäti.
- Vertikálne systémy sú ideálne pre toky úloh, ktoré potrebujú navzájom komunikovať.
- Vertikálne systémy sa vyznačujú výkonnými funkciami RAS a v horizontálnych systémoch je dostupnosť implementovaná pomocou masívnej replikácie (do klastra je pripojených niekoľko uzlov, takže výpadok jedného z nich má malý vplyv na chod celého systému).
- Vo vertikálnych systémoch jedna kópia OS pokrýva všetky zdroje. Niektoré vertikálne systémy, ako sú midframe a high-end servery Sun Microsystems (Sun Fire 4800 až Sun Fire 15K), možno rozdeliť na menšie vertikálne servery.
- Vertikálne systémy využívajú maximálny možný počet štandardné komponenty, ale niektoré základné komponenty (napríklad prepojenia) sú špeciálne navrhnuté.
- Vertikálne systémy je možné rozšíriť inštaláciou do existujúceho rámu dodatočné komponenty(výkonnejšie procesory, dodatočná pamäť, dodatočné a výkonnejšie I/O pripojenia atď.). Horizontálne systémy sa rozširujú pridaním uzla alebo nahradením starých uzlov novými.
- Takmer všetky vertikálne systémy sú 64-bitové, zatiaľ čo horizontálne systémy môžu byť 32-bitové alebo 64-bitové.
Vertikálne systémy sú vhodnejšie pre niektoré typy aplikácií a horizontálne pre iné, ale v mnohých prípadoch optimálna voľba architektúra závisí od veľkosti problému. V tabuľke 2 sú uvedené príklady aplikácií, pre ktoré je optimálna vertikálna alebo horizontálna architektúra.
Tabuľka 2. Typy aplikácií pre vertikálne a horizontálne architektúry
Malé a modulárne servery sú vhodné pre aplikácie, ktoré sú bezstavové, majú malý rozsah a ľahko sa replikujú. A pre aplikácie, ktoré využívajú informácie o stave a veľké objemy údajov vyžadujúce intenzívny prenos údajov v rámci systému, ideálne riešenie budú vertikálne servery. Na trhu vysokovýkonných technických výpočtov (HPTC) existuje veľa aplikácií, v ktorých sú vlákna na sebe závislé a vymieňajú si medzi sebou údaje. Existujú aj aplikácie, ktoré vyžadujú veľké množstvo zdieľanej pamäte. Pre tieto dva typy aplikácií sú najvhodnejšie veľké servery SMP. Existujú však aj aplikácie HPTC, v ktorých sú vykonávacie vlákna nezávislé a nevyžadujú veľké množstvo zdieľanej pamäte. Takéto aplikácie môžu byť rozdelené, vďaka čomu sú klastre malých serverov ideálne na ich spustenie. Podobne, niektoré komerčné aplikácie sú rozdelené na oddiely a horizontálne servery sú pre ne optimálne, zatiaľ čo iné nie je možné rozdeliť a podobne
najlepšia platforma
- toto sú vertikálne servery. Faktory ovplyvňujúce výkon Všetky veľké dátové centrá sú paralelné počítače. Tu možno dokonca klastre považovať za špeciálny typ paralelných systémov. Vysoký výkon vyžaduje vyvážený systém s výkonnými procesormi, vysokorýchlostným prepojením a I/O, škálovateľným operačným systémom, optimalizovanými aplikáciami a
perfektné funkcie
Procesory sú určite základnou súčasťou, ale len čiastočne určujú celkový výkon systému. Dôležitejšie je zabezpečiť, aby procesory bežali na maximálnu kapacitu. U výkonný procesor, ktorý je zaťažený len na 50 %, bude fungovať horšie ako pomalší procesor, ktorý je zaťažený na 80 %.
Navyše, so zvyšujúcim sa počtom procesorov v paralelnom systéme sa do popredia dostáva skôr vzájomné prepojenie systému ako výkon procesora. Sú zodpovedné za presun dát z disku, z pamäte a zo siete do procesora. V klastri je prepojením sieťové pripojenie, ako napríklad Fast Ethernet alebo Gigabit Ethernet. Klaster prepája presun dát medzi uzlami, zatiaľ čo systém prepája presun dát v rámci samostatný systém. Ak je prepojenie príliš pomalé, procesor bude nečinný čakať na dáta.
Systémové prepojenia sa používajú aj na presun dátových adries, čo je nevyhnutné na podporu koherencie vyrovnávacej pamäte. Ak je prepojenie systému pri prenose dátových adries príliš pomalé, procesor bude opäť nečinne čakať na dáta, pretože na prístup k nim potrebuje poznať svoju adresu. Rýchle prepojenia poskytujú vysokú priepustnosť a nízku latenciu (krátky čas od zadania požiadavky na údaje až po začiatok prenosu údajov).
Hlavným technickým rozdielom medzi horizontálnymi a vertikálnymi systémami je priepustnosť a latencia ich prepojení. Pri prepojení klastrov sa priepustnosť môže pohybovať od 125 MB/s pre Fast Ethernet do 200 MB/s pre SCI a latencia sa môže pohybovať od 100 tisíc ns pre GBE a až 10 tisíc ns pre SCI. Pomocou rozhrania InfiniBand je možné realizovať rýchlejšie prepojenia so špičkovými rýchlosťami od približne 250 MB/s pre prvú verziu a až do 3 GB/s pre ďalšie verzie.
Vstup a výstup
Rýchly I/O je potrebný na to, aby prepojenie mohlo rýchlo získať dáta z disku a siete a preniesť ich do procesorov. Úzke miesto v I/O subsystéme môže negatívne ovplyvniť výkon aj tých najrýchlejších prepojení a procesorov.
operačný systém
Dokonca aj ten najlepší hardvér je neúčinný, ak OS nie je dostatočne škálovateľný. Pre horizontálne systémy nie je škálovateľnosť OS taká dôležitá, pretože na jednom uzle alebo so samostatnou kópiou OS nepracujú viac ako štyri procesory.
Dostupnosť systému
Vo všeobecnosti dostupnosť systému do značnej miery závisí od typu architektúry. Vo veľkých SMP systémoch je funkcionalita RAS zabudovaná do systému a doplnená o failover pre dva až štyri uzly. V horizontálnych systémoch je RAS jednotlivých uzlov horší, ale zlepšenie týchto funkcií sa dosahuje viacnásobnou replikáciou uzlov.
Optimalizované aplikácie
Aplikácie je potrebné optimalizovať pre architektúru výpočtový systém. Najjednoduchšie je písať a optimalizovať aplikácie pre SMP systémy. Hlavné komerčné aplikácie sú optimalizované špeciálne pre SMP systémy a boli na nich dokonca vyvinuté, čo je dôvod, prečo SMP dominujú trhu so strednými a špičkovými systémami za posledných desať rokov.
Veľkosť aplikácie
Ako bolo uvedené, veľké systémy SMP používajú vysokorýchlostné prepojenia na zabezpečenie dostatočného výkonu systému. Horizontálne systémy môžu mať problémy s výkonom v dôsledku nízkej priepustnosti a vysokej latencie prepojenia v prípadoch, keď je potrebné často prenášať údaje medzi uzlami. Niektoré aplikácie však na dosiahnutie vysokého výkonu nevyžadujú vysoké rýchlosti prepojenia – zvyčajne ide o malé aplikácie a aplikácie, ktoré sa dajú ľahko replikovať (napríklad webové servery, proxy, brány firewall a malé aplikačné servery). V takýchto horizontálnych systémoch každý uzol vykonáva malú úlohu nezávisle od práce všetkých ostatných.
Napríklad v horizontálnej (alebo distribuovanej pamäti) architektúre môžu štyri uzly procesora (každý so samostatnou RAM a vyhradeným alebo zdieľaným I/O subsystémom) využívať sieťové prepojenie, ako je gigabitový Ethernet. Toto výpočtové prostredie spúšťa tri typy pracovných zaťažení. Najmenšie zaťaženie sa zmestí na jeden uzol, ale ako sa zvyšuje, na jeho dokončenie je potrebných niekoľko uzlov. Podľa odborníkov sa pri vykonávaní jednej úlohy na viacerých uzloch výkon výrazne zhoršuje v dôsledku pomalých medziuzlových prepojení. Malé pracovné zaťaženia, ktoré spolu nepotrebujú komunikovať, fungujú dobre s horizontálnou architektúrou, ale prevádzkovanie veľkých pracovných zaťažení na nej predstavuje výzvy.
Konfigurácia veľký systém SMP môže obsahovať napríklad až 100 procesorov, 576 GB zdieľanej pamäte a vysokorýchlostné prepojenia. Takýto systém dokáže zvládnuť všetky typy pracovných zaťažení, pretože neexistuje žiadna komunikácia medzi uzlami a efektívna komunikácia medzi procesmi. Všetky centrálne procesorové jednotky môžu súčasne pristupovať ku všetkým diskom, všetkej pamäti a sieťovým pripojeniam – to je kľúčová vlastnosť SMP systémov (alebo vertikálnych systémov).
Často vyvstáva otázka o vhodnosti umiestnenia malých nákladov na veľké SMP. Hoci v technicky To je možné z ekonomického hľadiska, tento prístup sa neospravedlňuje. Pri veľkých SMP sú obstarávacie náklady na procesor vyššie ako pri malých systémoch. Ak teda aplikácia môže bežať na malom uzle (alebo niekoľkých malých uzloch) a toto sa nevytvorí vážne problémy s manažmentom je pre jeho nasadenie vhodnejšie horizontálne škálovanie. Ak je však aplikácia príliš veľká a nemôže bežať na malom uzle (alebo niekoľkých takýchto uzloch), veľký SMP server najlepšia možnosť z hľadiska výkonu aj správy systému.
Výkon na úrovni databázy
Hlavnou otázkou je porovnanie výkonu jednotlivých stredných a veľkých SMP serverov s klastrom malých serverov (nie viac ako štyri procesory).
Pri diskusii o škálovateľnosti používajú výrobné spoločnosti množstvo odborných výrazov. Rast výkonu (Speedup) pre SMP je teda definovaný ako pomer rýchlosti vykonávania aplikácií na niekoľkých procesoroch a na jednom. Lineárne zrýchlenie napríklad znamená, že na 40 procesoroch beží aplikácia 40-krát (40x) rýchlejšie ako na jednom. Nárast výkonu nezávisí od počtu procesorov, t.j. pri konfigurácii 24 procesorov to bude rovnaké ako pri 48 procesoroch. Zvýšenie výkonu klastra (zrýchlenie klastra) sa líši len tým, že pri jeho výpočte sa berie počet uzlov, nie počet procesorov. Rovnako ako rast výkonnosti SMP, rast výkonnosti klastrov zostáva konštantný rôzne čísla uzly
Efektívnosť škálovania charakterizuje schopnosť aplikácií, najmä klastrových, škálovať cez veľký počet uzlov. Všeobecne sa verí, že účinnosť škálovania závisí od počtu uzlov zúčastňujúcich sa merania. Efektivita škálovania SMP je zvýšenie výkonu delené počtom procesorov a efektívnosť klastra je zvýšenie výkonu klastra delené počtom uzlov v ňom. Musíte pochopiť, čo tieto parametre znamenajú, aby ste nezískali nesprávny obraz, pretože 90% účinnosť škálovania na dvoch uzloch nie je to isté ako 90% účinnosť škálovania na štyroch uzloch.
Na obr. Obrázok 2 zobrazuje tri grafy: ideálnu lineárnu škálovateľnosť, škálovateľnosť 24-procesorového SMP servera na úrovni 95 % a škálovateľnosť klastra dvoch 4-procesorových serverov na úrovni 90 %. Je vidieť, že existujú určité obmedzenia škálovateľnosti databáz v klastroch (s horizontálnym škálovaním). Spojenie mnohých malých serverov dohromady neposkytuje škálovateľnosť potrebnú pre stredné až veľké aplikácie. Dôvodom sú obmedzenia šírky pásma prepojení v rámci klastra, dodatočná záťaž databázového softvéru spojená so správou klastrov a ťažkosti pri písaní aplikácií pre prostredia s distribuovanými pamäťovými klastrami.
Publikované výsledky benchmarkov napríklad ukazujú, že Oracle9i RAC (Real Application Cluster) má nárast výkonu o 1,8 a efektivitu škálovania 90 %. Táto efektívnosť škálovateľnosti sa môže zdať dosť vysoká, ale v skutočnosti je škálovateľnosť 90 % pre štyri uzly neúčinná v porovnaní s výsledkami veľkých SMP serverov.
Výkon na úrovni aplikácie
Aplikačná vrstva v trojvrstvovom dátovom centre je veľmi odlišná od databázovej vrstvy. Aplikácie na tejto úrovni sú zvyčajne bezstavové – inými slovami, na samotnom serveri nie sú uložené žiadne údaje alebo je uložená len ich malá časť. Táto vrstva obsahuje obchodné pravidlá pre aplikačné služby. Transakcie prichádzajú na aplikačnú úroveň a sú ňou spracovávané. Keď je potrebné údaje zapísať alebo prečítať, transakcie sa prenesú do databázovej vrstvy. Aplikačné servery majú tendenciu konsolidovať databázové pripojenia, pretože veľký počet pripojení má negatívny vplyv na výkon.
Vo väčšine prípadov vrstva aplikačného servera vyžaduje oveľa viac procesorov ako vrstva databázy na jednotlivca aplikačná služba. Napríklad v prípade SAP R/3 je tento pomer približne 10 procesorov na každý databázový procesor, t.j. ak SAP R/3 vyžaduje 20 procesorov pre databázovú vrstvu, potom by pre aplikačnú vrstvu malo byť približne 200 procesorov. Otázkou je, čo je výhodnejšie nasadiť – 100 dvojprocesorových serverov alebo desať 20-procesorových serverov. Podobne v Oracle je pomer aplikačných procesorov k databázovým procesorom približne 5 ku 1.
Predpokladá sa, že aplikačné servery nemusia byť distribuované cez viacero uzlov. Viacero kópií aplikačného softvéru môže byť distribuovaných medzi rôznymi fyzické servery rôznych kapacít alebo naprieč dynamickými doménami veľkých serverov.
Počet procesorov potrebných pre aplikačnú vrstvu bude približne rovnaký bez ohľadu na architektúru počítača. Náklady na nákup hardvéru a softvéru pre horizontálnu architektúru budú nižšie, keďže náklady na procesor sú v tomto prípade nižšie. Vo väčšine prípadov môžu horizontálne systémy poskytnúť výkon požadovaný na splnenie dohody o úrovni služieb. Náklady spojené s nákupom softvérových licencií sú približne rovnaké pre obe architektúry.
Zároveň môžu byť náklady na správu a údržbu infraštruktúry pre horizontálnu architektúru vyššie. Pri nasadení na horizontálnych systémoch sa používa viacero kópií operačného systému a softvéru aplikačného servera. Náklady na údržbu infraštruktúry zvyčajne rastú úmerne s počtom kópií OS a aplikácií. Navyše pre horizontálnu architektúru zálohovanie a obnova po havárii sa stáva decentralizovanou a sieťovú infraštruktúru je ťažšie spravovať.
Náklady na správu systému je ťažké merať. Modely porovnávajúce horizontálne a vertikálne nasadenia aplikačných serverov zvyčajne ukazujú, že spravovať menej znamená viac výkonné servery(vertikálne servery) je lacnejšia ako správa mnohých malých serverov. Vo všeobecnosti by IT manažéri pri výbere typu architektúry na nasadenie aplikačnej vrstvy mali dôkladne zvážiť náklady na obstaranie hardvéru.
Vplyv architektúry na dostupnosť
Pre moderné dátové centrá je kľúčová dostupnosť – aplikačné služby musia byť dostupné 24x7x365 (24 hodín denne, 7 dní v týždni, 365 dní v roku). V závislosti od potrieb konkrétneho dátového centra, rôzne schémy zabezpečenie vysokej dostupnosti. Pre výber konkrétneho riešenia je potrebné určiť platný čas prestoje (plánované a neplánované). Na obr. Obrázok 3 ukazuje, ako percento dostupnosti ovplyvňuje trvanie prestojov.
S rastúcimi požiadavkami na dostupnosť sa zvyšujú aj náklady na riešenie. Manažéri dátových centier musia určiť kombináciu nákladov, zložitosti a dostupnosti najlepším možným spôsobom spĺňa požiadavky na úroveň služieb. Dátové centrá, ktoré vyžadujú približne 99,95 % dostupnosť, môžu nasadiť jeden SMP server s funkciami RAS, ako je plná redundancia hardvéru a online údržba.
Ak však chcete dosiahnuť dostupnosť vyššiu ako 99,95 %, bude potrebný klaster. Softvér Sun Cluster so zlyhaním HA (High Availability) poskytuje 99,975% dostupnosť. Prepnutie pri zlyhaní HA používa primárny server a pohotovostný režim; Ak primárny server zlyhá, jeho zaťaženie prevezme záložný server. Čas potrebný na reštartovanie služby sa líši v závislosti od aplikácie a môže trvať niekoľko minút, najmä pri databázových aplikáciách, ktoré na obnovenie transakcií vyžadujú veľké návraty, ktoré sú náročné na údaje.
Ak je pre dátové centrum niekoľkominútový výpadok neakceptovateľný, riešením môže byť aktívny-aktívny systém, kde je aplikácia nasadená na dvoch alebo viacerých uzloch, takže ak jeden z nich zlyhá, ostatné budú pokračovať v prevádzke aplikácie. V dôsledku toho bude výpadok veľmi krátky (niektorí klienti uvádzajú, že trvá menej ako 1 minútu), niekedy si používateľ výpadok uzla ani nemusí všimnúť.
Vertikálne servery poskytujú vysokú dostupnosť vďaka zabudovaniu mnohých funkcií RAS do jedného servera, aby sa minimalizovali plánované a neplánované prestoje. V horizontálnych serveroch funkcie, ktoré poskytujú vysokej úrovni RAS nie sú implementované na úrovni jednotlivého servera, ale duplikáciou a umiestnením viacerých serverov. V dôsledku rôznych implementácií funkcií RAS a prepojení sú horizontálne servery zvyčajne lacnejšie na procesor.
Pre trojvrstvovú architektúru dobrý príklad horizontálna vysoká dostupnosť je nasadenie webových serverov. Môžete nasadiť mnoho malých serverov, každý so samostatnou kópiou nainštalovaného softvéru webového servera. Ak jeden webový server vypadne, jeho transakcie sa prerozdelia medzi zostávajúce zdravé servery. V prípade aplikačných serverov môžu byť hostované na horizontálnych aj vertikálnych serveroch a vysoká dostupnosť je dosiahnutá vďaka redundancii. Či už ide o nasadenie niekoľkých veľkých serverov SMP alebo mnohých menších, hlavným spôsobom dosiahnutia vysokého RAS na aplikačnej úrovni zostáva redundancia.
Na úrovni databázy sa však situácia mení. Databázy sú stavové a svojou povahou vo väčšine prípadov vyžadujú, aby boli údaje rozdelené a prístupné zo všetkých procesorov/uzlov. To znamená, že pre vysokú dostupnosť s redundanciou je potrebné použiť klastrovací softvér, ako je Sun Cluster alebo Oracle9i RAC (pre veľmi vysokú dostupnosť).
Závery
Vertikálna aj horizontálna architektúra má svoje miesto v dnešnom dátovom centre. Zatiaľ čo sa dnes zameriavame na nové technológie, ako sú modulárne servery a paralelné databázy, na trhu zostáva vysoký dopyt po serveroch strednej a vyššej kategórie.
Vertikálne a horizontálne systémy môžu používať rovnaký softvér, OS a dokonca identické procesory. Hlavným rozdielom, ktorý ovplyvňuje cenu a výkon, sú prepojenia použité v každej architektúre. Horizontálne servery používajú voľne spojené externé prepojenia, zatiaľ čo vertikálne servery používajú tesne spojené prepojenia, ktoré poskytujú viac vysoká rýchlosť dátový prenos.
Pre frontend poskytujú horizontálne servery zvyčajne optimálne riešenie z hľadiska výkonu, celkových obstarávacích nákladov a dostupnosti. Pre aplikačnú vrstvu môžete efektívne použiť vertikálne aj horizontálna architektúra. Pre databázovú vrstvu je optimálnym riešením použitie vertikálnych serverov bez ohľadu na požadovanú úroveň dostupnosti.
Takže ste si vytvorili webovú stránku. Je vždy zaujímavé a vzrušujúce sledovať, ako sa počítadlo návštevníkov pomaly, ale isto približuje a každý deň ukazuje všetko najlepšie výsledky. Ale jedného dňa, keď to nečakáte, niekto zverejní odkaz na váš zdroj na Reddit alebo Hacker News (alebo na Habré - približne pruh) a váš server spadne.
Namiesto získavania nových bežných používateľov, zostane vám prázdna strana. V tomto bode vám nič nepomôže obnoviť funkčnosť servera a prevádzka bude navždy stratená. Ako sa takýmto problémom vyhnúť? V tomto článku budeme hovoriť o optimalizácia a škálovanie.
Trochu o optimalizácii
Každý pozná základné tipy: aktualizovať na najnovšiu verziu PHP (5.5 má teraz zabudovanú OpCache), pracuje s indexmi v databáze, vyrovnáva statické údaje (zriedkavo upraviteľné stránky, ako napríklad „O nás“, „Časté otázky“ atď.).
Za zmienku stojí aj jeden konkrétny aspekt optimalizácie – údržba statický obsah server iný ako Apache, ako je napríklad Nginx Nakonfigurujte Nginx na spracovanie všetkého statického obsahu (*.jpg, *.png, *.mp4, *.html...) a odosielanie súborov, ktoré vyžadujú spracovanie serverom. ťažký Apache. Volá sa reverzný proxy.
Škálovanie
Existujú dva typy škálovania - vertikálne a horizontálne.
Podľa môjho názoru je stránka škálovateľná, ak dokáže zvládnuť návštevnosť bez zmeny softvéru.
Vertikálne škálovanie.
Predstavte si server obsluhujúci webovú aplikáciu. Má 4GB RAM, i5 procesor a 1TB HDD. Robí svoju prácu dobre, ale aby ste sa lepšie vyrovnali s vyššou prevádzkou, rozhodnete sa zvýšiť RAM na 16 GB, nainštalovať procesor i7 a SSD disk. Teraz je server oveľa výkonnejší a dokáže si poradiť aj s vysokým zaťažením. Toto je vertikálne škálovanie.
Horizontálne škálovanie.
Horizontálne škálovanie je vytvorenie zhluku vzájomne prepojených (často málo výkonných) serverov, ktoré spoločne obsluhujú stránku. V tomto prípade sa používa vyrovnávač zaťaženia(aka vyrovnávač zaťaženia) - stroj alebo program, ktorého hlavnou funkciou je určiť, na ktorý server sa má poslať požiadavka. Servery v klastri zdieľajú údržbu aplikácie bez toho, aby o sebe čokoľvek vedeli, čím sa výrazne zvyšuje priepustnosť a odolnosť vašej lokality voči chybám.
Existujú dva typy balancerov – hardvérové a softvérové. Softvér - nainštalovaný na bežnom serveri a prijíma všetku komunikáciu a odovzdáva ju príslušným obslužným programom. Takým balancérom by mohol byť napríklad Nginx. V sekcii „Optimalizácia“ zachytil všetky požiadavky na statické súbory a sám tieto požiadavky obslúžil bez toho, aby zaťažoval Apache. Ďalším populárnym softvérom na implementáciu vyrovnávania záťaže je Squid. Osobne ho používam vždy, pretože... poskytuje vynikajúce užívateľsky prívetivé rozhranie, na kontrolu najhlbších aspektov vyvažovania.
Hardvérový balancer je vyhradený stroj, ktorého jediným účelom je rozložiť záťaž. Tento stroj už zvyčajne nepoužíva žiadny iný softvér ako ten, ktorý vyvinul výrobca. Môžete si prečítať o nástrojoch na vyrovnávanie záťaže hardvéru.
Upozorňujeme, že tieto dve metódy sa navzájom nevylučujú. Môžete vertikálne zmenšiť ľubovoľný stroj (aka Nodu) vo vašom systéme.
V tomto článku diskutujeme o horizontálnom škálovaní, pretože... je to lacnejšie a efektívnejšie, aj keď náročnejšie na implementáciu.
Trvalé pripojenie
Pri škálovaní aplikácií PHP vzniká niekoľko zložitých problémov. Jedným z nich je práca s údajmi o reláciách používateľa. Koniec koncov, ak ste sa prihlásili na stránku a balancer odoslal vašu ďalšiu požiadavku na iný počítač nové auto nebude vedieť, že ste už prihlásený. V tomto prípade môžete použiť trvalé pripojenie. To znamená, že balancer si pamätá, na ktorý uzol bola žiadosť používateľa odoslaná naposledy, a tam pošle ďalšiu požiadavku. Ukazuje sa však, že balancer je príliš preťažený funkciami okrem spracovania státisícov požiadaviek si musí pamätať aj to, ako presne ich spracovával, v dôsledku čoho sa samotný balancer stáva úzkym hrdlom systému.
Lokálna výmena dát.
Zdieľanie údajov relácie používateľa medzi všetkými uzlami v klastri sa javí ako dobrý nápad. A hoci tento prístup vyžaduje určité zmeny v architektúre vašej aplikácie, stojí to za to – vyrovnávač zaťaženia sa uvoľní a celý klaster bude odolnejší voči chybám. Smrť jedného zo serverov vôbec neovplyvní chod celého systému.
Ako vieme, údaje relácie sú uložené v superglobálne pole $_SESSION, ktorý zapisuje a získava dáta zo súboru na disku. Ak je tento disk na jednom serveri, ostatné servery k nemu samozrejme nemajú prístup. Ako ho môžeme sprístupniť na viacerých strojoch?
Po prvé, uvedomte si to Obslužný program relácie v PHP je možné prepísať. Môžete implementovať svoju vlastnú triedu relácie.
Použitie databázy na ukladanie relácií
Pomocou vlastného obslužného programu relácie ich môžeme uložiť do databázy. Databáza môže byť na samostatnom serveri (alebo dokonca klastri). Zvyčajne táto metóda funguje skvele, ale keď naozaj vysoká návštevnosť, Databáza sa stáva prekážkou(a ak dôjde k strate databázy, úplne stratíme funkčnosť), pretože musí obsluhovať všetky servery, z ktorých každý sa pokúša zapisovať alebo čítať dáta relácie.
Distribuovaný súborový systém
Možno si myslíte, že by bolo dobré nastaviť sieťový súborový systém, kde by všetky servery mohli zapisovať dáta relácie. Nerobte to! Ide o veľmi pomalý prístup, ktorý vedie k poškodeniu alebo dokonca strate údajov. Ak sa z nejakého dôvodu predsa len rozhodnete použiť túto metódu, odporúčam vám GlusterFS
Memcached
Môžete tiež použiť memcached na ukladanie údajov relácie do pamäte RAM. To však nie je bezpečné, pretože dáta v memcached sa v prípade ich vyčerpania prepíšu voľný priestor. Vy pravdepodobne čudujem sa, nie je RAM rozdelená podľa stroja? Ako sa aplikuje na celý klaster? Memcached má možnosť kombinovať dostupnú na rôzne autá RAM v jednom fonde.
Čím viac strojov máte, tým viac môžete alokovať do tejto pamäťovej oblasti. Nemusíte združovať pamäť všetkých počítačov, ale môžete a môžete darovať ľubovoľné množstvo pamäte z každého počítača do oblasti. Je tu teda možnosť opustiť b O väčšina pamäte pre bežné používanie a prideľte časť pre vyrovnávaciu pamäť, ktorá vám umožní ukladať do vyrovnávacej pamäte nielen relácie, ale aj ďalšie relevantné informácie. Memcached je vynikajúce a rozšírené riešenie.
Ak chcete použiť tento prístup, musíte mierne upraviť php.ini
Session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"
Klaster Redis
Redis - NoSQL dátové úložisko. Uloží databázu do RAM. Na rozdiel od memcached podporuje trvalé ukladanie údajov a komplexnejšie typy údajov. Redis nepodporuje klastrovanie, takže použitie na horizontálne škálovanie je trochu ťažké, je to však dočasné a alfa verzia klastrového riešenia už bola vydaná.
Iné riešenia
Celkom
Ako vidíte, horizontálne škálovanie PHP aplikácií nie je také jednoduché. Existuje veľa ťažkostí, väčšina riešení nie je zameniteľná, takže si musíte vybrať jedno a držať sa ho až do konca, pretože keď sa premávka zmenší, už nie je možnosť plynule prejsť na niečo iné.
Dúfam, že vám tento malý sprievodca pomôže pri výbere škálovacieho prístupu pre váš projekt.
V druhej časti článku si povieme škálovanie databázy.
) Dobrý deň! Som Alexander Makarov a možno ma poznáte z rámca Yii – som jedným z jeho vývojárov. Mám aj prácu na plný úväzok – a to už nie je startup – Stay.com, ktorý sa zaoberá cestovaním.
Dnes budem hovoriť o horizontálnom škálovaní, ale veľmi, veľmi všeobecne.
Čo je to vlastne škálovanie? Toto je príležitosť na zvýšenie produktivity projektu v minimálnom čase pridaním zdrojov.
Škálovanie zvyčajne nezahŕňa prepisovanie kódu, ale buď pridanie serverov alebo zvýšenie zdrojov existujúceho servera. Tento typ zahŕňa vertikálne a horizontálne škálovanie.
Vertikálne je, keď sa pridá viac pamäte RAM, diskov atď. na už existujúcom serveri a horizontálne je, keď do dátových centier umiestnia viac serverov a servery tam už nejako interagujú.
Najzaujímavejšia otázka, ktorú si kladú, je: prečo je to potrebné, ak mi všetko funguje dobre na jednom serveri? V skutočnosti musíme skontrolovať, čo sa stane. To znamená, že teraz to funguje, ale čo bude neskôr? Existujú dva úžasné nástroje - ab a siege, ktoré, ako sa zdá, dobiehajú mrak používateľov konkurencie, ktorí začínajú narážať na server, pokúšajú sa žiadať stránky, posielať nejaké požiadavky. Musíte im povedať, čo majú robiť, a obslužné programy vygenerujú takéto správy:
Hlavné dva parametre: n - počet požiadaviek, ktoré je potrebné vykonať, c - počet simultánnych požiadaviek. Takto preveria konkurenciu.
Na výstupe dostaneme RPS, t.j. počet požiadaviek za sekundu, ktoré je server schopný spracovať, z ktorých bude zrejmé, koľko používateľov dokáže spracovať. Všetko, samozrejme, závisí od projektu, líši sa, ale zvyčajne si to vyžaduje pozornosť.
Je tu ešte jeden parameter – Čas odozvy – čas odozvy, počas ktorého server v priemere obsluhoval stránku. Líši sa, ale je známe, že okolo 300 ms je norma a čokoľvek vyššie nie je veľmi dobré, pretože týchto 300 ms spracuje server a k tomu sa pridá ďalších 300 – 600 ms, ktoré spracuje klient. , t.j. Kým sa všetko načítava – štýly, obrázky a ostatné – plynie aj čas.
Stáva sa, že v skutočnosti sa ešte nie je potrebné starať o škálovanie - ideme na server, aktualizujeme PHP, získame 40% nárast výkonu a všetko je v pohode. Ďalej nakonfigurujeme Opcache a vyladíme ju. Mimochodom, Opcache je vyladená rovnakým spôsobom ako APC, so skriptom, ktorý nájdete v úložisku Rasmusa Lerdorfa a ktorý zobrazuje hity a miss, kde hity sú koľko krát PHPšiel do vyrovnávacej pamäte a misa - koľkokrát šiel do systému súborov, aby získal súbory. Ak spustíme celý web alebo spustíme nejaký prehľadávač odkazov, alebo ho prepichneme manuálne, potom budeme mať štatistiky o týchto zásahoch a zmeškaniach. Ak je 100 % zásahov a 0 % nezdarov, potom je všetko v poriadku, ale ak sa vyskytnú chyby, musíme alokovať viac pamäte, aby sa celý náš kód zmestil do Opcache. Toto je bežná chyba - zdá sa, že existuje Opcache, ale niečo nefunguje...
Často sa tiež začnú škálovať, ale vôbec sa na to nepozerajú, a preto všetko funguje pomaly. Najčastejšie ideme do databázy, pozrieme sa - neexistujú žiadne indexy, vložíme indexy - všetko funguje hneď, stačí ďalšie 2 roky, krása!
Musíte tiež povoliť vyrovnávaciu pamäť, nahradiť apache nginx a php-fpm, aby ste ušetrili pamäť. Všetko bude skvelé.
Všetky vyššie uvedené sú celkom jednoduché a dajú vám čas. Je čas na to, že jedného dňa to nebude stačiť, a musíme sa na to pripraviť už teraz.
Ako vo všeobecnosti chápete, v čom je problém? Buď už máte vysoké zaťaženie, a to nie je nutne nejaký šialený počet požiadaviek atď., je to vtedy, keď váš projekt nedokáže zvládnuť záťaž a to sa už nedá vyriešiť triviálnymi spôsobmi. Musíte rásť buď širšie, alebo vyššie. Niečo treba urobiť a s najväčšou pravdepodobnosťou je na to málo času, treba niečo vymyslieť.
Prvým pravidlom je nikdy nič nerobiť naslepo, t.j. potrebujeme vynikajúci monitoring. Najprv získame čas na zrejmú optimalizáciu, ako je povolenie vyrovnávacej pamäte alebo ukladanie domovskej stránky do vyrovnávacej pamäte atď. Potom nastavíme monitoring, ten nám ukáže, čo chýba. A to všetko sa mnohokrát opakuje – nikdy nemôžete prestať sledovať a zlepšovať.
Čo môže monitorovanie ukázať? O disk sa môžeme oprieť, t.j. do súborového systému, do pamäte, do procesora, do siete... A môže sa stať, že sa všetko zdá byť viac-menej, ale objavia sa nejaké chyby. Toto všetko sa rieši rôznymi spôsobmi. Problém s diskom môžete vyriešiť napríklad pridaním nového disku na ten istý server, alebo môžete nainštalovať druhý server, ktorý bude pracovať iba so súbormi.
Na čo by ste si mali dať pri monitorovaní práve teraz pozor? toto:
- dostupnosť, t.j. či je server nažive alebo nie;
- nedostatok diskových prostriedkov, procesora atď.;
- chyby.
Tu je zoznam skvelých nástrojov, ktoré vám umožňujú monitorovať zdroje a zobrazovať výsledky veľmi pohodlným spôsobom:
Táto správa je prepisom jednej z najlepších prezentácií na školiacej konferencii pre vývojárov vysoko zaťažených systémov v roku 2015.Staré veci! - hovoríš.
- Večné hodnoty! - odpovieme.vysokozáťažový junior Pridajte značky
S rastúcou popularitou webovej aplikácie si jej podpora nevyhnutne začína vyžadovať čoraz viac zdrojov. Najprv sa záťaž dá (a nepochybne by mala) vysporiadať optimalizáciou algoritmov a/alebo architektúry samotnej aplikácie. Čo však robiť, ak už bolo optimalizované všetko, čo sa dalo optimalizovať, no aplikácia si stále nevie poradiť so záťažou?
Optimalizácia
Prvá vec, ktorú by ste mali urobiť, je sadnúť si a zamyslieť sa, či sa vám už podarilo všetko optimalizovať:- Sú databázové dotazy optimálne (analýza EXPLAIN, použitie indexov)?
- sú údaje uložené správne (SQL vs NoSQL)?
- používa sa ukladanie do vyrovnávacej pamäte?
- Existujú nejaké zbytočné požiadavky na súborový systém alebo databázu?
- Sú algoritmy spracovania údajov optimálne?
- Sú nastavenia prostredia optimálne: Apache/Nginx, MySQL/PostgreSQL, PHP/Python?
Škálovanie
Povedzme teda, že optimalizácia už bola vykonaná, ale aplikácia sa stále nedokáže vyrovnať so záťažou. V tomto prípade môže byť riešením problému jeho distribúcia medzi niekoľko hostiteľov, aby sa zvýšil celkový výkon aplikácií zvýšením dostupných zdrojov. Tento prístup má oficiálny názov– „zmenšenie“ aplikácie. Presnejšie povedané, „škálovateľnosť“ sa vzťahuje na schopnosť systému zvyšovať svoj výkon so zvyšujúcim sa počtom zdrojov, ktoré sú mu pridelené. Existujú dva spôsoby škálovania: vertikálne a horizontálne. Vertikálne škálovanie znamená zvýšenie výkonu aplikácie pri pridávaní zdrojov (procesor, pamäť, disk) v rámci jedného uzla (hostiteľa). Horizontálne škálovanie je typické pre distribuované aplikácie a znamená zvýšenie výkonu aplikácie pri pridávaní ďalšieho uzla (hostiteľa).Je jasné, že najjednoduchšie by bolo jednoducho aktualizovať hardvér (procesor, pamäť, disk) – teda vertikálne škálovanie. Okrem toho tento prístup nevyžaduje žiadne úpravy aplikácie. Vertikálne škálovanie však veľmi rýchlo dosiahne svoj limit, po ktorom vývojárovi a správcovi nezostáva nič iné, len prejsť na horizontálne škálovanie aplikácie.
Architektúra aplikácie
Väčšina webových aplikácií je distribuovaná a priori, pretože v ich architektúre možno rozlíšiť najmenej tri vrstvy: webový server, obchodná logika (aplikácia), dáta (databáza, statika).Každá z týchto vrstiev môže byť škálovaná. Ak teda vo vašom systéme aplikácia a databáza žijú na tom istom hostiteľovi, prvým krokom by samozrejme mala byť distribúcia medzi rôznymi hostiteľmi.
Úzke miesto
Keď začínate škálovať systém, prvým krokom je určiť, ktorá vrstva je „úzkym hrdlom“ – to znamená, že funguje pomalšie ako zvyšok systému. Na začiatok môžete použiť banálne nástroje ako top (htop) na odhad spotreby procesora/pamäte a df, iostat na odhad spotreby disku. Je však vhodné vyčleniť samostatný hostiteľ s emuláciou bojového zaťaženia (pomocou alebo JMeter), na ktorom bude možné profilovať chod aplikácie pomocou utilít ako xdebug a pod. Na identifikáciu úzkych dopytov do databázy môžete použiť pomocné programy ako pgFouine (je jasné, že je lepšie to urobiť na základe protokolov z produkčného servera).Zvyčajne to všetko závisí od architektúry aplikácie, ale najpravdepodobnejších kandidátov na úzke miesto všeobecný prípad sú databáza a kód. Ak vaša aplikácia pracuje s veľkým množstvom používateľských dát, potom bude úzkym miestom s najväčšou pravdepodobnosťou statické úložisko.
Škálovanie databázy
Ako už bolo spomenuté vyššie, často je prekážkou v moderné aplikácie je databáza. Problémy s ním sú spravidla rozdelené do dvoch tried: požiadavky na výkon a skladovanie veľké množstvoúdajov.Zaťaženie databázy môžete znížiť jej rozložením na niekoľko hostiteľov. Zároveň sa stáva akútnym problém synchronizácie medzi nimi, ktorý možno vyriešiť implementáciou schémy master/slave so synchrónnou alebo asynchrónnou replikáciou. V prípade PostgreSQL môžete implementovať synchrónnu replikáciu pomocou Slony-I, asynchrónnu replikáciu pomocou PgPool-II alebo WAL (9.0). Problém oddeľovania požiadaviek na čítanie a zápis, ako aj vyrovnávania záťaže medzi existujúcimi podriadenými jednotkami je možné vyriešiť nastavením špeciálnej vrstvy prístupu k databáze (PgPool-II).
Problém s ukladaním veľkého množstva údajov pri používaní relačný DBMS možno vyriešiť pomocou mechanizmu delenia (“partitioning” v PostgreSQL), alebo nasadením databázy na distribuované súborové systémy, ako je Hadoop DFS.
Avšak na ukladanie veľkého množstva dát najlepšie riešenie Dôjde k „shardingu“ údajov, čo je vstavaná výhoda väčšiny databáz NoSQL (napríklad MongoDB).
Okrem toho databázy NoSQL vo všeobecnosti pracujú rýchlejšie ako ich SQL bratia kvôli absencii režijných nákladov na analýzu/optimalizáciu dotazov, kontrolu integrity dátovej štruktúry atď. Téma porovnávania relačných a NoSQL databáz je tiež pomerne rozsiahla a zaslúži si samostatný článok.
Samostatne stojí za zmienku skúsenosť Facebooku, ktorý používa MySQL bez výberu JOIN. Táto stratégia im umožňuje oveľa jednoduchšie škálovať databázu a zároveň prenášať zaťaženie z databázy do kódu, ktorý, ako bude popísané nižšie, sa škáluje ľahšie ako databáza.
Škálovanie kódu
Náročnosť pri škálovaní kódu závisí od toho, koľko zdieľaných prostriedkov hostitelia potrebujú na spustenie vašej aplikácie. Pôjde len o relácie, alebo to bude vyžadovať zdieľanú vyrovnávaciu pamäť a súbory? V každom prípade je prvým krokom spustenie kópií aplikácie na niekoľkých hostiteľoch s rovnakým prostredím.Ďalej musíte nakonfigurovať vyrovnávanie záťaže/požiadavky medzi týmito hostiteľmi. Dá sa to urobiť na úrovni TCP (haproxy), ako aj na HTTP (nginx) alebo DNS.
Ďalší krok musíte sa uistiť, že na každom hostiteľovi sú dostupné statické súbory, vyrovnávacia pamäť a relácie webovej aplikácie. Pre relácie môžete použiť server bežiaci cez sieť (napríklad memcached). Je celkom rozumné použiť rovnaký memcached ako cache server, ale, samozrejme, na inom hostiteľovi.
Statické súbory je možné pripojiť zo zdieľaného úložiska súborov cez NFS/CIFS alebo pomocou distribuovaného súborového systému (HDFS, GlusterFS, Ceph).
Môžete tiež ukladať súbory do databázy (napríklad Mongo GridFS), čím sa vyriešia problémy s dostupnosťou a škálovateľnosťou (berúc do úvahy skutočnosť, že v prípade databáz NoSQL je problém škálovateľnosti vyriešený z dôvodu shardingu).
Samostatne stojí za zmienku problém nasadenia na viacerých hostiteľoch. Ako to urobiť, aby používateľ nevidel, keď klikne na „Aktualizovať“ rôzne verzie aplikácie? Najviac jednoduché riešenie Podľa môjho názoru bude existovať výnimka z konfigurácie vyrovnávača zaťaženia (webového servera) neaktualizovaných hostiteľov a ich postupného zaraďovania pri ich aktualizácii. Môžete tiež prepojiť používateľov s konkrétnymi hostiteľmi pomocou súboru cookie alebo adresy IP. Ak si aktualizácia vyžaduje významné zmeny v databáze je najjednoduchším spôsobom dočasne úplne zatvoriť projekt.
FS škálovanie
Ak je potrebné ukladať veľké množstvo statických údajov, možno identifikovať dva problémy: nedostatok miesta a rýchlosť prístupu k údajom. Ako už bolo napísané vyššie, problém s nedostatkom miesta sa dá vyriešiť minimálne tromi spôsobmi: distribuovaným súborovým systémom, ukladaním dát do databázy s podporou shardingu a organizovaním shardingu „ručne“ na úrovni kódu.Zároveň stojí za to pochopiť, že rozdelenie statiky tiež nie je najlepšie jednoduchá úloha keď príde na to vysoké zaťaženie. Preto je celkom rozumné mať veľa serverov vyhradených na distribúciu statických súborov. Navyše, ak máme zdieľané dátové úložisko (distribuovaný súborový systém alebo databázu), pri ukladaní súboru môžeme uložiť jeho názov bez toho, aby sme brali do úvahy hostiteľa, a nahradiť ho názvom hostiteľa náhodne pri vytváraní stránky (náhodne vyvažujem zaťaženie medzi webovými servermi distribuujúcimi statiku). V prípade, že sa sharding implementuje manuálne (to znamená, že logika v kóde je zodpovedná za výber hostiteľa, do ktorého sa budú údaje nahrávať), informácie o hostiteľovi nahrávania sa musia vypočítať buď na základe samotného súboru, alebo vygenerovať na základe na tretie údaje (informácie o používateľovi, množstvo miesta na úložných diskoch) a uložené spolu s názvom súboru do databázy.
Prečo Vodafone kráča v stopách MTS a zavádza regionalizáciu?
Bitdefender Antivirus: Efektívny Defender bez otázok
Význam slova neúspešný
Recenzia Samsung Galaxy A7 (2017): nebojte sa vody a šetrite Oplatí sa kúpiť samsung a7
Vytvorenie zálohy firmvéru v systéme Android