Shkallueshmëria është një veti e një sistemi kompjuterik që siguron rritje të parashikueshme në karakteristikat e sistemit, për shembull, numrin e përdoruesve të mbështetur, shpejtësinë e përgjigjes, performancën e përgjithshme, etj., kur i shtohen burimet llogaritëse. Në rastin e një serveri DBMS, mund të merren parasysh dy metoda shkallëzimi - vertikale dhe horizontale (Fig. 2).

Me shkallëzimin horizontal, rritet numri i serverëve DBMS, duke komunikuar ndoshta me njëri-tjetrin në mënyrë transparente, duke ndarë kështu ngarkesën e përgjithshme të sistemit. Kjo zgjidhje ka të ngjarë të bëhet gjithnjë e më popullore ndërsa mbështetja për arkitekturat e lidhura lirshëm dhe bazat e të dhënave të shpërndara rritet, por priret të jetë e vështirë për t'u administruar.

Shkallëzimi vertikal përfshin rritjen e fuqisë së një serveri të veçantë DBMS dhe arrihet duke zëvendësuar harduerin (procesor, disqe) me më të shpejtë ose duke shtuar nyje shtesë. Një shembull i mirë është rritja e numrit të procesorëve në platformat simetrike me shumëprocesorë (SMP). Në këtë rast, softueri i serverit nuk duhet të ndryshohet (në veçanti, blerja e moduleve shtesë nuk mund të kërkohet), pasi kjo do të rriste kompleksitetin e administrimit dhe do të përkeqësonte parashikueshmërinë e sjelljes së sistemit. Pavarësisht se cila metodë e shkallëzimit përdoret, fitimi përcaktohet nga sa plotësisht programet e serverit përdorin burimet e disponueshme kompjuterike. Në vlerësimet e mëtejshme, do të shqyrtojmë shkallëzimin vertikal, i cili, sipas analistëve, po përjeton rritjen më të madhe në tregun modern të kompjuterave.

Vetia e shkallëzueshmërisë është e rëndësishme për dy arsye kryesore. Para së gjithash, kushtet moderne të biznesit ndryshojnë aq shpejt, saqë bëjnë një planifikim afatgjatë, i cili kërkon një analizë gjithëpërfshirëse dhe të gjatë të të dhënave tashmë të vjetruara, e pamundur, edhe për ato organizata që mund ta përballojnë atë. Në këmbim vjen një strategji e rritjes gradualisht, hap pas hapi, të fuqisë së sistemeve të informacionit. Nga ana tjetër, ndryshimet në teknologji çojnë në shfaqjen e gjithnjë e më shumë zgjidhjeve të reja dhe çmimeve më të ulëta të harduerit, gjë që potencialisht e bën arkitekturën e sistemeve të informacionit më fleksibël. Në të njëjtën kohë, ndërveprueshmëria dhe hapja e produkteve softuerike dhe harduerike nga prodhues të ndryshëm po zgjerohet, megjithëse deri më tani përpjekjet e tyre për të përmbushur standardet janë koordinuar vetëm në sektorë të ngushtë të tregut. Pa marrë parasysh këta faktorë, konsumatori nuk do të jetë në gjendje të përfitojë nga teknologjitë e reja pa ngrirjen e fondeve të investuara në teknologji që nuk janë mjaft të hapura ose që janë dëshmuar se nuk janë premtuese. Në fushën e ruajtjes dhe përpunimit të të dhënave, kjo kërkon që si DBMS ashtu edhe serveri të jenë të shkallëzuar. Sot, parametrat kryesorë të shkallëzueshmërisë janë:

• mbështetje për multiprocessing;
• fleksibilitet arkitektonik.

Sistemet multiprocesorike

Për shkallëzimin vertikal gjithnjë e më shumë po përdoren sistemet simetrike multiprocesorike (SMP), pasi në këtë rast nuk ka nevojë të ndërrohet platforma, d.m.th. aftësitë e sistemit operativ, harduerit dhe administrimit. Për këtë qëllim, është gjithashtu e mundur të përdoren sisteme me paralelizëm masiv (MPP), por deri më tani përdorimi i tyre është i kufizuar në detyra të veçanta, për shembull, ato llogaritëse. Kur vlerësoni një server DBMS me një arkitekturë paralele, këshillohet t'i kushtoni vëmendje dy karakteristikave kryesore të shtrirjes së arkitekturës: përshtatshmërisë dhe transparencës.

Vetia e përshtatshmërisë kërkon që arkitektura e serverit të mbështesë në mënyrë të barabartë një ose dhjetë procesorë pa riinstalim ose ndryshime të rëndësishme në konfigurim, si dhe module shtesë softuerësh. Një arkitekturë e tillë do të jetë po aq e dobishme dhe efektive si në një sistem me një procesor të vetëm ashtu edhe, me rritjen e kompleksitetit të detyrave që zgjidhen, në disa ose edhe të shumëfishta procesorë (MPP). Në përgjithësi, konsumatori nuk duhet të blejë ose të mësojë opsione të reja softuerësh.

Sigurimi i transparencës për arkitekturën e serverit, nga ana tjetër, bën të mundur fshehjen e ndryshimeve të konfigurimit të harduerit nga aplikacionet, d.m.th. garanton transportueshmëri të sistemeve softuerike aplikative. Në veçanti, në arkitekturat e shumëprocesorëve të lidhur ngushtë, aplikacioni mund të komunikojë me serverin përmes një segmenti të memories së përbashkët, ndërsa në sistemet e multiserverëve të lidhur lirshëm (grupe), një mekanizëm mesazhi mund të përdoret për këtë qëllim. Aplikacioni nuk duhet të marrë parasysh aftësitë e zbatimit të arkitekturës së harduerit - metodat e manipulimit të të dhënave dhe ndërfaqja e softuerit për të hyrë në bazën e të dhënave duhet të mbeten të njëjta dhe po aq efektive.

Mbështetja me cilësi të lartë për multiprocessing kërkon që serveri i bazës së të dhënave të jetë në gjendje të planifikojë në mënyrë të pavarur ekzekutimin e shumë pyetjeve që do të shërbehen, gjë që do të siguronte ndarjen më të plotë të burimeve të disponueshme kompjuterike midis detyrave të serverit. Kërkesat mund të përpunohen në mënyrë sekuenciale nga disa detyra ose të ndahen në nën-detyra, të cilat, nga ana tjetër, mund të ekzekutohen paralelisht (Fig. 3). Kjo e fundit është më optimale sepse zbatimi i duhur i këtij mekanizmi ofron përfitime që janë të pavarura nga llojet e kërkesave dhe aplikacionet. Efikasiteti i përpunimit ndikohet shumë nga niveli i granularitetit të operacioneve të konsideruara nga detyra e planifikuesit. Me granularitet të trashë, për shembull, në nivelin e pyetjeve individuale SQL, ndarja e burimeve të sistemit kompjuterik (procesorët, memoria, disqet) nuk do të jetë optimale - detyra do të jetë boshe, duke pritur për përfundimin e operacioneve I/O të nevojshme. për të përfunduar pyetjen SQL, të paktën në radhë për të Kishte pyetje të tjera që kërkonin punë të rëndësishme llogaritëse. Me një shkallëzim më të imët, ndarja e burimeve ndodh edhe brenda një pyetjeje të vetme SQL, e cila është edhe më e qartë kur disa pyetje përpunohen paralelisht. Përdorimi i një planifikuesi siguron që burimet e mëdha të sistemit të përdoren për të zgjidhur detyrat aktuale të mirëmbajtjes së bazës së të dhënave dhe minimizon kohën e ndërprerjes.

Fleksibilitet arkitektonik

Pavarësisht nga shkalla e transportueshmërisë, mbështetja për standardet, paralelizmi dhe cilësitë e tjera të dobishme, performanca e një DBMS, e cila ka kufizime të rëndësishme arkitekturore të integruara, nuk mund të rritet lirshëm. Prania e kufizimeve të dokumentuara ose praktike në numrin dhe madhësinë e objekteve të bazës së të dhënave dhe buferëve të memories, numrin e lidhjeve të njëkohshme, thellësinë e rekursionit të procedurave të thirrjes dhe pyetjeve të nënshtruara ose ndezjes së aktivizuesve të bazës së të dhënave është i njëjti kufizim në zbatueshmërinë e DBMS, si p.sh. , për shembull, pamundësia e transferimit në disa platforma kompjuterike. Parametrat që kufizojnë kompleksitetin e pyetjeve të bazës së të dhënave, veçanërisht madhësitë e buferave dinamike dhe madhësia e stivës për thirrjet rekursive, duhet të jenë të konfigurueshme në mënyrë dinamike dhe të mos kërkojnë ndalimin e sistemit për rikonfigurim. Nuk ka kuptim të blini një server të ri të fuqishëm nëse pritjet nuk mund të përmbushen për shkak të kufizimeve të brendshme të DBMS.

Në mënyrë tipike, pengesa është pamundësia për të rregulluar në mënyrë dinamike karakteristikat e programeve të serverit të bazës së të dhënave. Aftësia për të përcaktuar parametrat në lëvizje të tilla si sasia e memories së konsumuar, numri i procesorëve të zënë, numri i fijeve paralele të punës (qofshin fijet reale, proceset e sistemit operativ ose procesorët virtualë) dhe numri i fragmenteve të tabelave të bazës së të dhënave dhe indekset, si dhe shpërndarja e tyre në disqe fizike PA ndalimin dhe rinisjen e sistemit është një kërkesë që rrjedh nga thelbi i aplikacioneve moderne. Në mënyrë ideale, secili prej këtyre parametrave mund të ndryshohet në mënyrë dinamike brenda kufijve specifikë të përdoruesit.

Oleg Spiryaev

Kohët e fundit, ka pasur pretendime të shpeshta se serverët e nivelit të mesëm dhe të lartë po zëvendësohen në mënyrë aktive nga grupe serverësh të nivelit fillestar, të bashkuar në rafte ose grupe. Megjithatë, disa ekspertë nuk pajtohen. Kështu, sipas Dataquest, pjesa e modeleve me çmim prej 500 mijë dollarë e lart (kjo përfshin serverët SMP të nivelit të mesëm dhe të nivelit të lartë) në shitjet totale të serverëve nga viti 2000 në 2002 u rrit nga 38 në 52%.

Të dhëna të tjera të marra nga IDC tregojnë rritje (të paktën për sa i përket numrit të makinerive) në sektorin e modeleve të serverëve të nivelit të ulët - me dy procesorë. IDC gjithashtu parashikon që në vitin 2005 sistemi operativ më i zakonshëm për serverët që kushtojnë nga 50,000 deri në 3 milionë dollarë do të jetë Unix. Duke krahasuar këto të dhëna, është e qartë se serverët Unix të nivelit të mesëm dhe të nivelit të lartë do të mbeten platforma mbizotëruese për qendrat e të dhënave, por do të plotësohen nga një numër në rritje i serverëve më të vegjël (zakonisht me përpunues të dyfishtë).

Ky trend është shfaqur si rezultat i ndarjes së shtresave të ndryshme të llogaritjes në qendrat e të dhënave (Fig. 1). Niveli 1, ose niveli i përparmë, gradualisht kalon në një model të shkallëzuar të serverëve të vegjël, ndërsa Niveli 3 (niveli i bazës së të dhënave) dominohet nga serverët e shkallëzuar. Shtresa 2 (shtresa e aplikimit) bëhet zona ku bashkëjetojnë arkitekturat vertikale dhe horizontale.

Arkitektura vertikale dhe horizontale

Le të shohim ndryshimet kryesore midis arkitekturave vertikale dhe horizontale. Serverët e shkallëzimit janë sisteme të mëdha SMP (simetrike me shumë përpunim ose memorie të përbashkët) me më shumë se katër njësi përpunimi qendror. Ata përdorin vetëm një kopje të OS për të kontrolluar të gjithë procesorët, memorien dhe komponentët I/O. Në mënyrë tipike, të gjitha këto burime janë të vendosura në një raft ose kabinet. Këta serverë ndërlidhen në një qendër me shpejtësi të lartë ose në planin e pasëm me vonesë të ulët dhe akses koherent në cache. Ju mund të shtoni burime duke instaluar pllaka amë shtesë brenda kabinetit. Në sistemet e arkitekturës së kullave (ose SMP), memoria është e përbashkët, që do të thotë se të gjithë procesorët dhe komponentët I/O kanë akses në të gjithë memorien. Përdoruesi "e sheh" kujtesën si një objekt të vetëm të madh.

Në alternativë, shkallëzimi horizontal, sistemet lidhen nëpërmjet një rrjeti ose grumbullohen së bashku. Ndërlidhjet zakonisht përdorin teknologji standarde të rrjetit si Fast Ethernet, Gigabit Ethernet (GBE) dhe Scalable Coherent Interconnect (SCI), të cilat ofrojnë xhiro më të ulët dhe vonesë më të lartë se sistemet vertikale. Burimet në këtë rast shpërndahen midis nyjeve, që zakonisht përmbajnë nga një deri në katër procesorë; Çdo nyje ka procesorin dhe memorien e vet dhe mund të ketë nënsistemin e vet I/O ose ta ndajë atë me nyje të tjera. Çdo nyje drejton një kopje të veçantë të OS. Burimet zgjerohen duke shtuar nyje, por jo duke shtuar burime në një nyje. Kujtesa në sistemet horizontale është e shpërndarë, domethënë secila nyje ka memorien e saj që aksesohet drejtpërdrejt nga procesorët e saj dhe nënsistemi I/O. Qasja në këto burime nga një nyje tjetër është shumë më e ngadaltë sesa nga nyja ku ato ndodhen. Përveç kësaj, me një arkitekturë horizontale, nuk ka qasje të qëndrueshme midis nyjeve në memorie dhe aplikacionet e përdorura konsumojnë relativisht pak burime, kështu që ato "përshtaten" në një nyje të vetme dhe nuk kanë nevojë për qasje të qëndrueshme. Nëse një aplikacion kërkon shumë nyje, ai duhet të sigurojë vetë akses të qëndrueshëm në memorie.

Nëse një sistem horizontal plotëson kërkesat e aplikimit, atëherë kjo arkitekturë është e preferueshme sepse kostot e blerjes së tij janë më të ulëta. Në mënyrë tipike, kostoja e blerjes për procesor për sistemet horizontale është më e ulët se për sistemet vertikale. Dallimi në çmim është për shkak të faktit se sistemet vertikale përdorin veçori më të fuqishme RAS (besueshmëria, disponueshmëria, shërbimi), si dhe ndërlidhje me performancë të lartë. Megjithatë, ekzistojnë një sërë kufizimesh në përdorimin e sistemeve me arkitekturë horizontale. Më poshtë do të diskutojmë se në çfarë kushtesh mund të përdoren sistemet horizontale dhe kur është i nevojshëm shkallëzimi vertikal.

Përveç një serveri të madh SMP, arkitektura vertikale përfshin gjithashtu grupime të serverëve të mëdhenj SMP të përdorura për një aplikacion të vetëm në shkallë të gjerë.

Serverët modularë ose blade të prezantuar së fundi në treg, zakonisht të pajisur me një ose dy procesorë, janë një shembull i serverëve horizontalë. Këtu grupi përbëhet nga nyje të vogla, secila prej të cilave ka një server SMP të nivelit të hyrjes me numrin e përpunuesve qendrorë nga 1 në 4.

Një mënyrë tjetër për t'u zmadhuar është përmes sistemeve të mëdha të llogaritjes masivisht paralele (MPP), të cilat përbëhen nga shumë procesorë të vegjël të instaluar në një kabinet të vetëm, secili me kopjen e vet të OS ose një kopje të mikrokernelit të OS. Aktualisht prodhohen vetëm disa sisteme MPP, të cilat më së shpeshti përfaqësojnë zgjidhje të specializuara. Këto janë, për shembull, sistemet Terradata të prodhuara nga NCR, IBM RS/6000SP (SP-2) dhe HP Tandem pa ndërprerje.

Tabela 1. Veçoritë e arkitekturave vertikale dhe horizontale

Parametri	Sistemet vertikale	Sistemet horizontale
Kujtesa	Të mëdha të përbashkëta	I vogël i përkushtuar
Rrjedhat	Shumë fije të ndërvarura	Shumë fije të pavarura
Ndërlidhjet	E brendshme e lidhur ngushtë	E jashtme e lidhur lirshëm
RAS	Sistem i vetëm i fuqishëm RAS	RAS i fuqishëm duke përdorur përsëritje
Njësitë qendrore të përpunimit	Shumë standarde	Shumë standarde
OS	Një kopje e OS për shumë procesorë qendrorë	Disa kopje të OS (një kopje për 1-4 procesorë)
Paraqitja	Në një dollap	Vendosja e një numri të madh serverësh në një raft
Dendësia		Dendësi e lartë e procesorit për njësi sipërfaqe dyshemeje
Pajisjet	Standard dhe i projektuar posaçërisht	Standard
Shkallëzimi	Brenda një shasi të vetme serveri	Në një shkallë me shumë serverë
Zgjerim	Duke instaluar komponentë shtesë në server	Duke shtuar nyje të reja
Arkitekturë	64-bit	32- dhe 64-bit

Tabela 1 lejon një analizë krahasuese të arkitekturave vertikale dhe horizontale.

• Sistemet vertikale ndajnë memorien dhe ofrojnë akses të qëndrueshëm në cache.
• Sistemet vertikale janë ideale për rrjedhat e detyrave që duhet të komunikojnë me njëri-tjetrin.
• Sistemet vertikale karakterizohen nga funksione të fuqishme RAS, dhe në sistemet horizontale, disponueshmëria zbatohet duke përdorur përsëritje masive (disa nyje janë të lidhura me një grup, kështu që dështimi i njërit prej tyre ka pak ndikim në funksionimin e të gjithë sistemit).
• Në sistemet vertikale, një kopje e OS mbulon të gjitha burimet. Disa sisteme vertikale, të tilla si serverët e kornizës së mesme dhe të nivelit të lartë të Sun Microsystems (Sun Fire 4800 në Sun Fire 15K), mund të ndahen në serverë vertikalë më të vegjël.
• Sistemet vertikale përdorin sa më shumë komponentë standardë të jetë e mundur, por disa komponentë kryesorë (të tillë si ndërlidhjet) janë projektuar posaçërisht.
• Sistemet vertikale mund të zgjerohen duke instaluar komponentë shtesë në kornizën ekzistuese (procesorë më të fuqishëm, memorie shtesë, lidhje shtesë I/O me performancë më të lartë, etj.). Sistemet horizontale zgjerohen duke shtuar një nyje ose duke zëvendësuar nyjet e vjetra me të reja.
• Pothuajse të gjitha sistemet vertikale janë 64-bit, ndërsa sistemet horizontale mund të jenë ose 32-bit ose 64-bit.

Sistemet vertikale janë më të përshtatshme për disa lloje aplikacionesh dhe sistemet horizontale për të tjerët, por në shumë raste zgjedhja optimale e arkitekturës varet nga madhësia e problemit. Në tabelë 2 tregon shembuj të aplikacioneve për të cilat arkitektura vertikale ose horizontale është optimale.

Tabela 2. Llojet e aplikacioneve për arkitekturat vertikale dhe horizontale

Serverët e vegjël dhe modularë janë të përshtatshëm për aplikacione që janë pa shtetësi, të vogla në shkallë dhe lehtësisht të përsëritura. Dhe për aplikacionet që përdorin informacione të gjendjes dhe vëllime të mëdha të dhënash që kërkojnë transferim intensiv të të dhënave brenda sistemit, serverët vertikal janë zgjidhja ideale. Në tregun e llogaritjeve teknike me performancë të lartë (HPTC), ka shumë aplikacione në të cilat thread-et varen nga njëri-tjetri dhe shkëmbejnë të dhëna me njëri-tjetrin. Ka edhe aplikacione që kërkojnë sasi të mëdha memorie të përbashkët. Serverët e mëdhenj SMP janë më të përshtatshëm për këto dy lloje aplikacionesh. Megjithatë, ka edhe aplikacione HPTC në të cilat thread-et e ekzekutimit janë të pavarura dhe nuk kërkojnë sasi të mëdha memorie të përbashkët. Aplikacione të tilla mund të ndahen, duke i bërë grupet e serverëve të vegjël idealë për ekzekutimin e tyre. Po kështu, disa aplikacione komerciale janë të ndarë dhe përfitojnë nga serverët horizontalë, ndërsa të tjerët nuk mund të ndahen, kështu që serverët vertikalë janë platforma më e mirë për ta.

Faktorët që ndikojnë në performancën

Të gjitha qendrat e mëdha të të dhënave janë kompjuterë paralelë. Këtu, edhe grupimet mund të konsiderohen si një lloj i veçantë i sistemeve paralele. Performanca e lartë kërkon një sistem të balancuar me procesorë të fuqishëm, ndërlidhje me shpejtësi të lartë dhe I/O, një OS të shkallëzuar, aplikacione të optimizuara dhe veçori të avancuara RAS.

Procesorët dhe ndërlidhjet e sistemit

Procesorët janë sigurisht një komponent thelbësor, por ata vetëm pjesërisht përcaktojnë performancën e përgjithshme të një sistemi. Është më e rëndësishme të sigurohet që procesorët të funksionojnë me kapacitet maksimal. Një procesor i fuqishëm që është i ngarkuar vetëm 50% do të funksionojë më keq se një procesor më i ngadalshëm që është i ngarkuar 80%.

Përveç kësaj, me rritjen e numrit të procesorëve në një sistem paralel, ndërlidhet sistemi në vend të fuqisë së procesorit. Ata janë përgjegjës për lëvizjen e të dhënave nga disku, nga memoria dhe nga rrjeti në procesor. Në një grup, ndërlidhja është një lidhje rrjeti, siç është Fast Ethernet ose Gigabit Ethernet. Ndërlidhjet e grupeve lëvizin të dhënat ndërmjet nyjeve, ndërsa ndërlidhjet e sistemit lëvizin të dhënat brenda një sistemi të vetëm. Nëse ndërlidhja është shumë e ngadaltë, procesori do të jetë i papunë duke pritur për të dhëna.

Ndërlidhjet e sistemit përdoren gjithashtu për të lëvizur adresat e të dhënave, gjë që është e nevojshme për të mbështetur koherencën e cache. Nëse ndërlidhja e sistemit është shumë e ngadaltë në transmetimin e adresave të të dhënave, procesori do të jetë sërish i papunë duke pritur për të dhëna sepse duhet të dijë adresën e tij për t'iu qasur. Ndërlidhjet e shpejta sigurojnë xhiro të lartë dhe vonesë të ulët (kohë e ulët nga momenti kur bëhet një kërkesë për të dhëna derisa të dhënat të fillojnë të transmetohen).

Dallimi kryesor teknik midis sistemeve horizontale dhe vertikale është xhiroja dhe vonesa e ndërlidhjeve të tyre. Për ndërlidhjet e grupimeve, xhiroja mund të variojë nga 125 MB/s për Fast Ethernet në 200 MB/s për SCI, dhe vonesa mund të variojë nga 100 mijë ns për GBE dhe deri në 10 mijë ns për SCI. Duke përdorur ndërfaqen InfiniBand, është e mundur të zbatohen ndërlidhje më të shpejta me shpejtësi maksimale që variojnë nga afërsisht 250 MB/s për versionin e parë dhe deri në 3 GB/s për versionet pasuese.

Input dhe output

I/O i shpejtë është i nevojshëm në mënyrë që ndërlidhja të mund të marrë shpejt të dhënat nga disku dhe rrjeti dhe t'i transferojë ato te procesorët. Një pengesë në nënsistemin I/O mund të ndikojë negativisht në performancën edhe të ndërlidhjeve dhe procesorëve më të shpejtë.

sistemi operativ

Edhe pajisja më e mirë është e paefektshme nëse OS nuk është mjaftueshëm i shkallëzuar. Për sistemet horizontale, shkallëzueshmëria e OS nuk është aq e rëndësishme, sepse jo më shumë se katër procesorë funksionojnë në një nyje të vetme ose me një kopje të veçantë të OS.

Disponueshmëria e sistemit

Në përgjithësi, disponueshmëria e sistemit varet kryesisht nga lloji i arkitekturës. Në sistemet e mëdha SMP, funksionaliteti RAS është i integruar në sistem dhe plotësohet me dështim për dy deri në katër nyje. Në sistemet horizontale, RAS e nyjeve individuale është më e keqe, por përmirësimet në këto funksione arrihen duke riprodhuar nyjet shumë herë.

Aplikacionet e optimizuara

Aplikacionet duhet të optimizohen për arkitekturën e sistemit kompjuterik. Është më e lehtë të shkruash dhe të optimizosh aplikacionet për sistemet SMP. Aplikacionet kryesore komerciale janë optimizuar posaçërisht për sistemet SMP dhe madje janë zhvilluar në to, kjo është arsyeja pse SMP-të kanë dominuar tregun e sistemeve të nivelit të mesëm dhe të nivelit të lartë për dhjetë vitet e fundit.

Madhësia e aplikimit

Siç u përmend, sistemet e mëdha SMP përdorin ndërlidhje me shpejtësi të lartë për të siguruar performancë të mjaftueshme të sistemit. Sistemet horizontale mund të kenë probleme me performancën për shkak të xhiros së ulët dhe vonesës së lartë të ndërlidhjes në rastet kur të dhënat duhet të transferohen shpesh midis nyjeve. Megjithatë, disa aplikacione nuk kërkojnë shpejtësi të lartë të ndërlidhjes për të arritur performancë të lartë—zakonisht aplikacione dhe aplikacione të vogla që mund të përsëriten lehtësisht (për shembull, serverët e uebit, proxies, muret e zjarrit dhe serverët e vegjël të aplikacioneve). Në sisteme të tilla horizontale, çdo nyje kryen një detyrë të vogël në mënyrë të pavarur nga puna e të gjithë të tjerëve.

Për shembull, në një arkitekturë horizontale (ose memorie të shpërndarë), katër nyje procesori (secila me RAM të veçantë dhe nënsistem I/O të dedikuar ose të përbashkët) mund të përdorin një ndërlidhje rrjeti si Gigabit Ethernet. Ky mjedis kompjuterik ekzekuton tre lloje ngarkesash pune. Ngarkesa më e vogël përshtatet në një nyje, por ndërsa rritet, kërkohen disa nyje për ta përfunduar atë. Sipas ekspertëve, kur kryeni një detyrë në disa nyje, performanca përkeqësohet ndjeshëm për shkak të ndërlidhjeve të ngadalta ndërmjet nyjeve. Ngarkesat e vogla të punës që nuk kanë nevojë të komunikojnë me njëra-tjetrën funksionojnë mirë me një arkitekturë horizontale, por ekzekutimi i ngarkesave në shkallë të gjerë në të paraqet sfida.

Një konfigurim i madh i sistemit SMP mund të përfshijë, për shembull, deri në 100 procesorë, 576 GB memorie të përbashkët dhe ndërlidhje me shpejtësi të lartë. Një sistem i tillë mund të përballojë të gjitha llojet e ngarkesave të punës sepse nuk ka komunikim midis nyjeve dhe komunikim efikas midis proceseve. Të gjitha njësitë qendrore të përpunimit mund të aksesojnë njëkohësisht të gjithë disqet, të gjitha lidhjet e memories dhe rrjetit - kjo është një veçori kryesore e sistemeve SMP (ose sistemeve vertikale).

Shpesh lind pyetja për këshillueshmërinë e vendosjes së ngarkesave të vogla në SMP të mëdha. Edhe pse kjo është teknikisht e mundur, nga pikëpamja ekonomike kjo qasje nuk është e justifikuar. Për SMP-të e mëdha, kostoja e blerjes për procesor është më e lartë se për sistemet e vogla. Prandaj, nëse një aplikacion mund të ekzekutohet në një nyje të vogël (ose disa nyje të vogla) pa probleme të mëdha menaxhimi, shkalla e zvogëlimit është një zgjedhje më e mirë për vendosje. Por nëse aplikacioni është shumë i madh për t'u ekzekutuar në një nyje të vogël (ose disa nyje të tilla), atëherë një server i madh SMP do të jetë alternativa më e mirë për sa i përket performancës dhe administrimit të sistemit.

Performanca e nivelit të bazës së të dhënave

Pyetja kryesore këtu është të krahasojmë performancën e serverëve të vetëm të mesëm dhe të mëdhenj SMP me një grup serverësh të vegjël (jo më shumë se katër procesorë).

Kur diskutohet për shkallëzueshmërinë, kompanitë prodhuese përdorin një sërë termash teknikë. Kështu, rritja e performancës (Speedup) për SMP përcaktohet si raporti i shpejtësive të ekzekutimit të aplikacionit në disa procesorë dhe në një. Përshpejtimi linear do të thotë, për shembull, që në 40 procesorë një aplikacion funksionon 40 herë (40x) më shpejt se në një. Rritja e performancës nuk varet nga numri i procesorëve, d.m.th. për një konfigurim prej 24 procesorësh do të jetë i njëjtë si për 48 procesorë. Rritja e performancës së grupit (Cluster speedup) ndryshon vetëm në atë që gjatë llogaritjes së tij merret numri i nyjeve dhe jo numri i përpunuesve. Ashtu si rritja e performancës SMP, rritja e performancës së grupit mbetet konstante nëpër numra të ndryshëm nyjesh.

Efikasiteti i shkallëzimit karakterizon aftësinë e aplikacioneve, veçanërisht të atyre të grupuara, për të shkallëzuar në një numër të madh nyjesh. Në përgjithësi besohet se efikasiteti i shkallëzimit varet nga numri i nyjeve që marrin pjesë në matje. Efikasiteti i shkallëzimit të SMP është rritja e performancës pjesëtuar me numrin e procesorëve, dhe efikasiteti i grupit është rritja e performancës së grupit pjesëtuar me numrin e nyjeve në të. Ju duhet të kuptoni se çfarë nënkuptojnë këto parametra në mënyrë që të mos merrni pamjen e gabuar sepse 90% e efikasitetit të shkallëzimit në dy nyje nuk është e njëjtë me efikasitetin e shkallëzimit 90% në katër nyje.

Në Fig. Figura 2 tregon tre grafikë: shkallëzueshmëria ideale lineare, shkallëzueshmëria e një serveri SMP me 24 procesorë në 95%, dhe shkallëzueshmëria e një grupi prej dy serverësh me 4 procesorë në 90%. Mund të shihet se ka kufizime të caktuara në shkallëzueshmërinë e bazave të të dhënave në grupe (me shkallëzim horizontal). Lidhja e shumë serverëve të vegjël së bashku nuk siguron shkallëzueshmërinë e nevojshme për aplikacione të mesme dhe të mëdha. Arsyeja për këtë janë kufizimet e gjerësisë së brezit të ndërlidhjeve brenda grupimeve, ngarkesa shtesë në softuerin e bazës së të dhënave që lidhet me menaxhimin e grupimeve dhe vështirësia e shkrimit të aplikacioneve për mjediset e grumbullimit të memories së shpërndarë.

Rezultatet e publikuara të standardeve tregojnë, për shembull, se Oracle9i RAC (Real Application Cluster) ka një rritje të performancës prej 1.8 dhe një efikasitet të shkallëzimit prej 90%. Ky efikasitet i shkallëzueshmërisë mund të duket mjaft i lartë, por në fakt, shkallëzueshmëria prej 90% për katër nyje është joefektive kur krahasohet me rezultatet e serverëve të mëdhenj SMP.

Performanca e Nivelit të Aplikimit

Shtresa e aplikacionit në një qendër të dhënash me tre nivele është shumë e ndryshme nga shtresa e bazës së të dhënave. Në mënyrë tipike, aplikacionet në këtë nivel janë pa shtetësi - me fjalë të tjera, nuk ruhen të dhëna në vetë serverin, ose ruhet vetëm një pjesë e vogël e tyre. Kjo shtresë përmban rregullat e biznesit për shërbimet e aplikacionit. Transaksionet vijnë në nivelin e aplikimit dhe përpunohen prej tij. Kur të dhënat duhet të shkruhen ose lexohen, transaksionet kalohen në shtresën e bazës së të dhënave. Serverët e aplikacioneve priren të konsolidojnë lidhjet e bazës së të dhënave sepse një numër i madh i lidhjeve kanë një ndikim negativ në performancën.

Në shumicën e rasteve, niveli i serverit të aplikacionit kërkon shumë më tepër përpunues sesa niveli i bazës së të dhënave për çdo shërbim aplikimi individual. Për shembull, në rastin e SAP R/3, ky raport është afërsisht 10 procesorë për çdo procesor të bazës së të dhënave, d.m.th., nëse SAP R/3 kërkon 20 procesorë për shtresën e bazës së të dhënave, atëherë duhet të ketë afërsisht 200 procesorë për shtresën e aplikacionit. Pyetja është se çfarë është më fitimprurëse për t'u vendosur - 100 serverë me dy procesorë ose dhjetë serverë me 20 procesorë. Në mënyrë të ngjashme, në Oracle raporti i përpunuesve të aplikacioneve me përpunuesit e bazës së të dhënave është afërsisht 5 me 1.

Besohet se serverët e aplikacioneve nuk kanë nevojë të shpërndahen nëpër nyje të shumta. Kopje të shumta të softuerit aplikativ mund të shpërndahen nëpër serverë të ndryshëm fizikë me kapacitete të ndryshme ose nëpër domene dinamike të serverëve të mëdhenj.

Numri i procesorëve të kërkuar për shtresën e aplikimit do të jetë afërsisht i njëjtë pavarësisht nga arkitektura e kompjuterit. Kostoja e blerjes së harduerit dhe softuerit për një arkitekturë horizontale do të jetë më e ulët, pasi kostoja për procesor është më e ulët në këtë rast. Në shumicën e rasteve, sistemet horizontale mund të ofrojnë performancën e kërkuar për të përmbushur marrëveshjen e nivelit të shërbimit. Kostot që lidhen me blerjen e licencave të softuerit janë afërsisht të njëjta për të dyja arkitekturat.

Në të njëjtën kohë, kostot e menaxhimit dhe mirëmbajtjes së infrastrukturës për një arkitekturë horizontale mund të jenë më të larta. Kur vendosen në sisteme horizontale, përdoren kopje të shumta të OS dhe softuerit të serverit të aplikacionit. Kostot e mirëmbajtjes së infrastrukturës zakonisht rriten në raport me numrin e kopjeve të OS dhe aplikacioneve. Për më tepër, me një arkitekturë horizontale, rezervimi dhe rikuperimi nga fatkeqësitë bëhet i decentralizuar dhe infrastruktura e rrjetit është më e vështirë për t'u menaxhuar.

Kostoja e administrimit të sistemit është e vështirë të matet. Në mënyrë tipike, modelet që krahasojnë vendosjet e serverëve të aplikacioneve horizontale dhe vertikale tregojnë se menaxhimi i më pak serverëve, më të fuqishëm (serverët vertikalë) është më pak i kushtueshëm sesa menaxhimi i shumë serverëve më të vegjël. Në përgjithësi, kur zgjedhin llojin e arkitekturës për të vendosur një shtresë aplikacioni, menaxherët e IT duhet të marrin parasysh me kujdes koston e blerjes së harduerit.

Ndikimi i Arkitekturës në Disponueshmëri

Disponueshmëria është kritike për qendrat moderne të të dhënave - shërbimet e aplikacionit duhet të jenë të disponueshme 24x7x365 (24 orë në ditë, 7 ditë në javë, 365 ditë në vit). Në varësi të nevojave të një qendre të caktuar të dhënash, përdoren skema të ndryshme të disponueshmërisë së lartë. Për të zgjedhur një zgjidhje specifike, është e nevojshme të përcaktohet koha e pranueshme e ndërprerjes (të planifikuar dhe të paplanifikuar). Në Fig. Figura 3 tregon se si përqindja e disponueshmërisë ndikon në kohëzgjatjen e joproduktive.

Me rritjen e kërkesave për disponueshmërinë, rritet edhe kostoja e zgjidhjes. Menaxherët e qendrave të të dhënave duhet të përcaktojnë se cili kombinim i kostos, kompleksitetit dhe disponueshmërisë i plotëson më mirë kërkesat e nivelit të shërbimit. Qendrat e të dhënave që kërkojnë afërsisht 99,95% disponueshmëri mund të vendosin një server të vetëm SMP me veçori RAS si teprica e plotë e harduerit dhe mirëmbajtja në internet.

Megjithatë, për të arritur disponueshmëri më të madhe se 99,95%, do të kërkohet një grup. Softueri Sun Cluster me dështim HA (High Availability) siguron disponueshmëri 99,975%. Dështimi i HA përdor një server primar dhe një gatishmëri të nxehtë; Nëse serveri primar dështon, serveri rezervë merr përsipër ngarkesën e tij. Koha që duhet për të rifilluar një shërbim ndryshon sipas aplikacionit dhe mund të zgjasë disa minuta, veçanërisht për aplikacionet e bazës së të dhënave që kërkojnë rikthime të mëdha me të dhëna intensive për të rivendosur transaksionet.

Nëse ndërprerja prej disa minutash është e papranueshme për një qendër të dhënash, një sistem aktiv-aktive mund të jetë një zgjidhje, ku aplikacioni vendoset në dy ose më shumë nyje në mënyrë që nëse njëra prej tyre dështon, të tjerët do të vazhdojnë të ekzekutojnë aplikacionin. Si rezultat, ndërprerja do të jetë shumë e shkurtër (disa klientë raportojnë se zgjat më pak se 1 minutë), ndonjëherë përdoruesi mund të mos e vërejë as dështimin e nyjes.

Serverët vertikalë ofrojnë disponueshmëri të lartë duke futur shumë veçori RAS në një server të vetëm për të minimizuar kohën e planifikuar dhe të paplanifikuar të ndërprerjes. Në serverët horizontalë, funksionet që ofrojnë një nivel të lartë të RAS zbatohen jo në nivelin e një serveri individual, por përmes dyfishimit dhe vendosjes së disa serverëve. Për shkak të zbatimeve të ndryshme të veçorive dhe ndërlidhjeve të RAS, serverët horizontalë janë zakonisht më të lirë për procesor.

Për një arkitekturë me tre nivele, një shembull i mirë i disponueshmërisë së lartë horizontale është vendosja e serverëve në internet. Mund të vendosni shumë serverë të vegjël, secili me një kopje të veçantë të softuerit të serverit në ueb të instaluar. Nëse një server në ueb prishet, transaksionet e tij rishpërndahen midis serverëve të mbetur të shëndetshëm. Në rastin e serverëve të aplikacioneve, ata mund të strehohen si në serverë horizontal ashtu edhe në vertikal, dhe disponueshmëria e lartë arrihet përmes tepricës. Qoftë duke vendosur disa serverë të mëdhenj SMP ose shumë më të vegjël, teprica mbetet mënyra kryesore për të arritur RAS të lartë në nivelin e aplikacionit.

Megjithatë, në nivelin e bazës së të dhënave situata ndryshon. Bazat e të dhënave janë të gjendjes dhe nga natyra e tyre kërkojnë, në shumicën e rasteve, të dhënat të jenë të ndara dhe të aksesueshme nga të gjithë përpunuesit/nyjet. Kjo do të thotë që për disponueshmëri të lartë me tepricë, duhet të përdorni softuer grupimi si Sun Cluster ose Oracle9i RAC (për disponueshmëri shumë të lartë).

konkluzionet

Të dyja arkitekturat vertikale dhe horizontale kanë vendin e tyre në qendrën e sotme të të dhënave. Ndërsa fokusi i sotëm është në teknologjitë e reja si serverët modularë dhe bazat e të dhënave paralele, tregu mbetet në kërkesë të lartë për serverë të rangut të mesëm dhe të nivelit të lartë.

Sistemet vertikale dhe horizontale mund të përdorin të njëjtin softuer, OS dhe madje të njëjtët procesorë. Dallimi kryesor që ndikon në çmim dhe performancë është ndërlidhjet e përdorura në secilën arkitekturë. Serverët horizontalë përdorin ndërlidhje të jashtme të lidhura lirshëm, ndërsa serverët vertikal përdorin ndërlidhje të lidhura ngushtë që ofrojnë shpejtësi më të larta të transferimit të të dhënave.

Për pjesën e përparme, serverët horizontalë zakonisht ofrojnë zgjidhjen optimale për sa i përket performancës, kostos totale të blerjes dhe disponueshmërisë. Për shtresën e aplikimit, të dyja arkitekturat vertikale dhe horizontale mund të përdoren në mënyrë efektive. Për shtresën e bazës së të dhënave, zgjidhja optimale është përdorimi i serverëve vertikal, pavarësisht nga niveli i kërkuar i disponueshmërisë.

Alexander Makarov, zhvilluesi i kornizës popullore Yii, do të flasë për shkallëzimin e projekteve në internet.

Shkallëzimi është aftësia për të zgjeruar sistemin për të përpunuar më shumë trafik pa humbur cilësitë e përdoruesit: shpejtësinë dhe reagimin.

Ekzistojnë dy lloje të shkallëzimit: vertikal (më shumë memorie, disk, procesor më i mirë) dhe horizontal (më shumë serverë në grup).

• Pse është e nevojshme nëse gjithçka funksionon kështu?
• Kur? Monitorimi, vendimet e nxituara, optimizimi dhe jeta me një server.
• Skema tipike.
• Balancimi i ngarkesës.
• Cilat janë problemet në anën e aplikimit në përgjithësi?
• Pse PHP është kaq i mirë për shkallëzim.
• Sesionet.
• Baza e të dhënave.
• Skedarët.
• Po statistikat?

Alexander Makarov (Yii, Stay.com)

Përshëndetje! Unë jam Alexander Makarov dhe ju mund të më njihni nga kuadri Yii - unë jam një nga zhvilluesit e tij. Unë gjithashtu kam një punë me kohë të plotë - dhe kjo nuk është më një startup - Stay.com, e cila merret me udhëtimet.

Sot do të flas për shkallëzimin horizontal, por në terma shumë, shumë të përgjithshëm.

Çfarë është shkallëzimi, gjithsesi? Kjo është një mundësi për të rritur produktivitetin e projektit në një kohë minimale duke shtuar burime.

Në mënyrë tipike, shkallëzimi nuk përfshin rishkrimin e kodit, por shtimin e serverëve ose rritjen e burimeve të një ekzistues. Ky lloj përfshin shkallëzim vertikal dhe horizontal.

Vertikale është kur shtohen më shumë RAM, disqe, etj. në një server tashmë ekzistues, dhe horizontale është kur ata vendosin më shumë serverë në qendrat e të dhënave, dhe serverët atje tashmë ndërveprojnë disi.

Pyetja më interesante që ata bëjnë është: pse është e nevojshme nëse gjithçka funksionon mirë për mua në një server? Në fakt, ne duhet të kontrollojmë se çfarë do të ndodhë. Domethënë funksionon tani, por çfarë do të ndodhë më vonë? Ekzistojnë dy shërbime të mrekullueshme - ab dhe siege, të cilat duket se kapin një re të përdoruesve të konkurrentëve që fillojnë të godasin serverin, përpiqen të kërkojnë faqe, të dërgojnë disa kërkesa. Ju duhet t'u tregoni atyre se çfarë të bëjnë dhe shërbimet gjenerojnë raporte si kjo:

Dy parametrat kryesorë: n - numri i kërkesave që duhet të bëhen, c - numri i kërkesave të njëkohshme. Në këtë mënyrë ata kontrollojnë konkurrencën.

Në dalje marrim RPS, d.m.th. numri i kërkesave në sekondë që serveri është në gjendje të përpunojë, nga të cilat do të bëhet e qartë se sa përdorues mund të trajtojë. Gjithçka, natyrisht, varet nga projekti, ndryshon, por zakonisht kjo kërkon vëmendje.

Ekziston edhe një parametër tjetër - Koha e përgjigjes - koha e përgjigjes gjatë së cilës serveri shërbeu një faqe mesatarisht. Ndryshon, por dihet se rreth 300 ms është normë dhe çdo gjë më e lartë nuk është shumë mirë, sepse këto 300 ms përpunohen nga serveri, dhe kësaj i shtohen edhe 300-600 ms të tjera, të cilat përpunohen nga klienti. , d.m.th. Ndërsa gjithçka po ngarkohet - stilet, imazhet dhe pjesa tjetër - koha gjithashtu kalon.

Ndodh që në fakt nuk ka nevojë të shqetësohemi ende për shkallëzimin - ne shkojmë në server, përditësojmë PHP, marrim një rritje prej 40% të performancës dhe gjithçka është e mirë. Tjetra, ne konfigurojmë Opcache dhe akordojmë atë. Opcache, meqë ra fjala, është akorduar në të njëjtën mënyrë si APC, me një skript që mund të gjendet në depon e Rasmus Lerdorf dhe që tregon goditjet dhe gabimet, ku janë hitet sa herë PHP shkoi në cache, dhe gabimet janë sa herë shkoi në sistemin e skedarëve merrni skedarë. Nëse e drejtojmë të gjithë faqen, ose ekzekutojmë një lloj zvarritësi në lidhje, ose e hapim manualisht, atëherë do të kemi statistika për këto goditje dhe humbje. Nëse ka 100% goditje dhe 0% gabime, atëherë gjithçka është në rregull, por nëse ka mungesa, atëherë duhet të ndajmë më shumë memorie në mënyrë që i gjithë kodi ynë të futet në Opcache. Ky është një gabim i zakonshëm që bëhet - duket sikur Opcache është aty, por diçka nuk funksionon...

Ata gjithashtu shpesh fillojnë të shkallëzohen, por nuk e shikojnë fare, kjo është arsyeja pse gjithçka funksionon ngadalë. Më shpesh ne hyjmë në bazën e të dhënave, shikojmë - nuk ka indekse, vendosim indekse - gjithçka funksionon menjëherë, mjafton për 2 vjet të tjera, bukuri!

Epo, ju gjithashtu duhet të aktivizoni cache, të zëvendësoni apache me nginx dhe php-fpm për të kursyer kujtesën. Gjithçka do të jetë e mrekullueshme.

Të gjitha sa më sipër janë mjaft të thjeshta dhe ju japin kohë. Ka kohë për faktin se një ditë kjo nuk do të jetë e mjaftueshme, dhe ne duhet të përgatitemi për këtë tani.

Si mund ta kuptoni në përgjithësi se cili është problemi? Ose tashmë keni një ngarkesë të lartë, dhe kjo nuk është domosdoshmërisht një numër i çmendur kërkesash, etj., është kur projekti juaj nuk mund të përballojë ngarkesën dhe kjo nuk mund të zgjidhet më në mënyra të parëndësishme. Ju duhet të rriteni ose më gjerë ose më lart. Diçka duhet bërë dhe, me shumë mundësi, ka pak kohë për të.

Rregulli i parë është të mos bëni kurrë asgjë verbërisht, d.m.th. kemi nevojë për monitorim të shkëlqyer. Së pari, ne fitojmë kohë në disa optimizime të dukshme, siç është aktivizimi i një cache ose ruajtja e faqes kryesore, etj. Pastaj vendosim monitorimin, na tregon se çfarë mungon. Dhe e gjithë kjo përsëritet shumë herë - nuk mund të ndaloni kurrë monitorimin dhe përmirësimin.

Çfarë mund të tregojë monitorimi? Ne mund të pushojmë kundër diskut, d.m.th. te sistemi i skedarëve, te memoria, te procesori, te rrjeti... Dhe mundet që gjithçka duket pak a shumë, por shfaqen disa gabime. E gjithë kjo zgjidhet në mënyra të ndryshme. Ju mund të zgjidhni një problem, të themi, me një disk duke shtuar një disk të ri në të njëjtin server, ose mund të instaloni një server të dytë që do të merret vetëm me skedarë.

Çfarë duhet t'i kushtoni vëmendje tani kur monitoroni? Kjo:

1. aksesueshmëria, d.m.th. nëse serveri është i gjallë apo jo;
2. mungesa e burimeve të diskut, procesorit, etj.;
3. gabimet.

Si të monitorohet e gjithë kjo?

Këtu është një listë e mjeteve të shkëlqyera që ju lejojnë të monitoroni burimet dhe të tregoni rezultatet në një mënyrë shumë të përshtatshme:

• Monit - http://mmonit.com/monit/
• Zabbix - http://www.zabbix.com/
• Munin - http://munin-monitoring.org/
• Nagios - http://www.nagios.org/
• Dendësia e Serverit - https://www.serverdensity.com/

4 mjetet e para mund të instalohen në server, ato janë të fuqishme dhe të lezetshme. Dhe ServerDensity është pritur nga dikush, d.m.th. ne paguajmë para për të, dhe ai mund të mbledhë të gjitha të dhënat nga serverët dhe t'i shfaqë ato për analizë.

Ekzistojnë dy shërbime të mira për monitorimin e gabimeve:

• Rollbar - https://rollbar.com/
• Sentry - https://getsentry.com/

Zakonisht ne monitorojmë gabime të tilla - ose shkruajmë gjithçka në regjistër dhe më pas i shikojmë, ose përveç kësaj fillojmë t'u dërgojmë email ose SMS zhvilluesve. Kjo është e gjitha normale, por sapo kemi një turmë njerëzish vjen në shërbim, dhe ka një lloj - ky gabim fillon të përsëritet një numër shumë të madh herë, emaili fillon të spam marrë çmendurisht, ose në përgjithësi bëhet i plotë, ose zhvilluesi humbet plotësisht vëmendjen dhe fillon të injorojë shkronjat Shërbimet e mësipërme marrin dhe mbledhin gabime të të njëjtit lloj në një paketë të madhe, plus ato numërojnë sa herë kanë ndodhur gabime dhe e ngrenë automatikisht të gjithë çështjen në përparësi.

Sentry mund të instalohet në serverin tuaj, ka një kod burim, por Rollbar jo, por Rollbar është më i mirë sepse tarifon para për numrin e gabimeve, d.m.th. i inkurajon t'i korrigjojnë ato.

Përsa i përket njoftimeve, do të përsëris se nuk duhet të dërgoni mesazhe të padëshiruara, pasi vëmendja juaj do të humbasë.

Çfarë duhet analizuar në përgjithësi?

RPS dhe koha e përgjigjes - nëse koha jonë e përgjigjes fillon të bjerë, atëherë duhet të bëjmë diçka.

Numri i proceseve, fijeve dhe madhësive të radhëve - nëse gjithçka fillon të shumëzohet, bllokohet, etj., Atëherë diçka nuk është në rregull këtu përsëri, ne duhet ta analizojmë atë në mënyrë më të detajuar dhe disi të ndryshojmë infrastrukturën.

Gjithashtu ia vlen të shikohet analiza e biznesit. Google Analytics është i shkëlqyeshëm për llojet e faqeve të internetit, dhe mixpanel është i shkëlqyeshëm për regjistrimin e ngjarjeve, ai funksionon në aplikacionet e desktopit, aplikacionet celulare dhe ueb. Ju mund të shkruani bazuar në disa nga të dhënat tuaja, por unë do të rekomandoja shërbime të gatshme. Çështja është se monitorimi ynë mund të tregojë që shërbimi është i gjallë, se gjithçka funksionon, se koha e përgjithshme e përgjigjes është normale, por kur ne, të themi, fillojmë të gjurmojmë regjistrimet në mixpanel, kjo tregon se ato nuk janë disi të mjaftueshme. Në këtë rast, ju duhet të shikoni se sa shpejt përpunohen ngjarje dhe faqe të caktuara, dhe cilat janë problemet Projekti duhet të "varet" gjithmonë me analiza në mënyrë që të dini gjithmonë se çfarë po ndodh, dhe të mos funksionojë verbërisht.

Ngarkesa, në përgjithësi, lind ose e planifikuar ose jo, mund të lindë gradualisht, jo gradualisht:

Si të merreni me ngarkesën? Biznesi vendos gjithçka, dhe vetëm çmimi i çështjes është i rëndësishëm. E rëndësishme:

1. që shërbimi të funksionojë,
2. në mënyrë që të mos kushtojë shumë dhe të mos e prishë kompaninë.

Pjesa tjetër nuk është shumë e rëndësishme.

Nëse është më e lirë për të profilizuar, për të optimizuar, për të shkruar në cache, për të korrigjuar disa konfigurime, atëherë kjo duhet të bëhet, pa menduar për shkallëzimin ose blerjen e pajisjeve shtesë, etj. Por ndodh që hardueri të bëhet më i lirë se puna e një programuesi, veçanërisht nëse programuesit janë shumë të zgjuar. Në këtë rast, shkallëzimi tashmë fillon.

Në foto gjëja blu është interneti nga vijnë kërkesat. Është instaluar një balancues, detyra e vetme e të cilit është shpërndarja e kërkesave në serverë të ndarë të frontit, pranimi i përgjigjeve prej tyre dhe dërgimi i tyre te klienti. Çështja këtu është se 3 serverë mund të përpunojnë (idealisht) 3 herë më shumë kërkesa, duke përjashtuar çdo kosto të përgjithshme për rrjetin dhe punën e vetë balancuesit.

Çfarë na jep kjo? Aftësia e lartpërmendur për të përpunuar më shumë kërkesa, si dhe besueshmëria. Nëse në skemën tradicionale nginx ose një aplikacion rrëzohet, ose disku ka probleme, etj., atëherë gjithçka ndalon. Këtu, nëse një nga frontet tona dështon, atëherë është në rregull, balancuesi ka shumë të ngjarë ta kuptojë këtë dhe të dërgojë kërkesa te 2 serverët e mbetur. Mund të jetë pak më e ngadaltë, por kjo nuk është një punë e madhe.

Në përgjithësi, PHP është e shkëlqyeshme për shkallëzim sepse ndjek parimin Share asgjë si parazgjedhje. Kjo do të thotë që nëse marrim, të themi, Java për ueb, atëherë aplikacioni fillon atje, lexon të gjithë kodin, shkruan sa më shumë të dhëna të jetë e mundur në memorien e programit, gjithçka rrotullohet atje, funksionon, shumë pak kohë shpenzohet në kërkesë. , shumë pak burime shtesë. Megjithatë, ka një pritë - sepse. Aplikacioni është i shkruar në atë mënyrë që duhet të ekzekutohet në një shembull, të ruhet në memorie, të lexohet nga memoria e tij, atëherë asgjë e mirë nuk do të vijë prej tij gjatë shkallëzimit. Por në PHP nuk ka asgjë të zakonshme si parazgjedhje, dhe kjo është mirë. Çdo gjë që duam të ndajmë, e vendosim në memcached dhe memcached mund të lexohet nga shumë serverë, kështu që gjithçka është e shkëlqyer. ato. Lidhja e lirshme arrihet për shtresën e serverit të aplikacionit. Kjo eshte e mrekullueshme.

Si të balanconi ngarkesën në përgjithësi?

Më shpesh kjo bëhej nga Squid ose HAProxy, por kjo ishte më parë. Tani autori i nginx mori dhe ndau balancuesin nga nginx+ në nginx, kështu që tani mund të bëjë gjithçka që bënte Squid ose HAProxy. Nëse fillon të dështojë, mund të instaloni një balancues të shtrenjtë të harduerit.

Problemet që zgjidh balancuesi janë si të zgjidhni një server dhe si të ruani seancat? Problemi i dytë është thjesht PHP, dhe serveri mund të zgjidhet ose një nga një nga lista, ose nga gjeografia e disa IP-ve, ose nga disa statistika (nginx mbështet më pak lidhjet, d.m.th. cili server ka më pak lidhje, ai do të hedhë atë mbi të). Ne mund të shkruajmë një kod për balancuesin që do të zgjedhë se si duhet të funksionojë.

Po sikur të godasim një balancues?

Ekziston një gjë e tillë si DNS Round Robin - ky është një mashtrim i mrekullueshëm që na lejon të mos shpenzojmë para për një balancues harduerësh. Cfare po bejme? Ne marrim një server DNS (zakonisht askush nuk pret një server DNS, është i shtrenjtë, jo shumë i besueshëm, nëse dështon, atëherë asgjë e mirë nuk do të vijë prej tij, të gjithë përdorin një lloj kompanie), ne regjistrojmë më shumë se një server në A rekord, por disa. Këto do të jenë të dhëna A nga balancues të ndryshëm. Kur shfletuesi shkon atje (në fakt, nuk ka garanci, por të gjithë shfletuesit modern veprojnë në këtë mënyrë), ai zgjedh një nga një një adresë IP nga rekordet A dhe përfundon ose në një balancues ose në të dytin. Ngarkesa mund të mos përhapet në mënyrë të barabartë, natyrisht, por të paktën ajo përhapet dhe balancuesi mund të përballojë pak më shumë.

Çfarë të bëni me seancat?

Ne kemi sesione në skedarë si parazgjedhje. Ky nuk është rasti, sepse secili nga serverët tanë front-end do të mbajë sesione në sistemin e vet të skedarëve dhe përdoruesi mund të shkojë fillimisht te një, pastaj te i dyti, pastaj te i treti, d.m.th. ai do të humbasë seancat çdo herë.

Ekziston një dëshirë e dukshme për të krijuar një sistem skedar të përbashkët dhe për të lidhur NFS. Por ju nuk keni nevojë ta bëni këtë - është jashtëzakonisht e ngadaltë.

Mund ta shkruani në bazën e të dhënave, por gjithashtu nuk ia vlen, sepse Baza e të dhënave nuk është optimale për këtë punë, por nëse nuk keni zgjidhje tjetër, atëherë, në parim, do të ndodhë.

Mund të shkruani në memcached, por me shumë, shumë kujdes, sepse memcached është, në fund të fundit, një cache dhe tenton të fshihet sapo të ketë pak burime, ose nuk ka ku të shkruani çelësa të rinj - atëherë fillon të humbasë të vjetrat pa paralajmërim, seancat fillojnë të humbasin. Ju duhet ose ta monitoroni këtë ose të zgjidhni të njëjtin Redis.

Redis është një zgjidhje e mirë. Çështja është se ne kemi Redis në një server të veçantë, dhe të gjithë frontendët tanë nxitojnë atje dhe fillojnë të lexojnë sesionet e tyre nga Redis i njëjti nginx është i instaluar dhe informohet se duhet të bëjë një seancë në mënyrë që kur përdoruesi të vijë në server dhe t'i jepet një skedar sesioni, ai më pas merr vetëm në këtë server Rezulton se nëse Redis është në çdo instancë, në përputhje me rrethanat, ka sesione të veçanta atje dhe xhiroja e leximit-shkrimit do të jetë shumë më e mirë.

Po biskotat? Mund të shkruani te cookie-t, nuk do të ketë hapësirë ​​ruajtëse, gjithçka është në rregull, por, së pari, ne ende duhet t'i vendosim të dhënat e sesionit diku dhe nëse fillojmë të shkruajmë në cookie, ato mund të rriten dhe të mos futen në memorie, por . së dyti, vetëm ID-të mund të ruhen në cookie dhe ne do të duhet të kontaktojmë përsëri bazën e të dhënave për disa të dhëna sesioni. Në parim, kjo është normale, e zgjidh problemin.

Ekziston një gjë interesante - një përfaqësues për memcached dhe Redis:

Ata duket se mbështesin paralelizimin jashtë kutisë, por kjo është bërë në një mënyrë që nuk do të thoja se është shumë optimale. Por kjo gjë - twemproxy - funksionon afërsisht si nginx me PHP, d.m.th. sapo merret pergjigja dergon menjehere te dhenat dhe mbyll lidhjen ne sfond, del me shpejt dhe harxhon me pak burime. Gjë shumë e mirë.

Shumë shpesh, ky gabim i "ciklizmit" ndodh kur ata fillojnë të shkruajnë, si "Nuk kam nevojë për seanca, tani do të bëj një shenjë të mrekullueshme që do të transferohet përpara dhe mbrapa"... Por, nëse mendoni për këtë, atëherë! kjo është përsëri një seancë.

PHP ka një mekanizëm të tillë si mbajtës i sesioneve, d.m.th. ne mund të vendosim mbajtësin tonë dhe të shkruajmë në cookies, në bazën e të dhënave, në Redis - kudo, dhe e gjithë kjo do të funksionojë me fillimin standard të sesionit, etj.

Seancat duhet të mbyllen duke përdorur këtë metodë të mrekullueshme.

Sapo të kemi lexuar të gjitha nga seanca, nuk do të shkruajmë aty, duhet të mbyllet, sepse shpesh seanca bllokohet. Në fakt duhet të bllokohet, sepse pa bllokim do të ketë probleme me konkurrencën. Kjo është menjëherë e dukshme në skedarët në ruajtje të tjera, bllokuesit nuk janë të disponueshëm për të gjithë skedarin menjëherë, dhe kjo është pak më e lehtë.

Çfarë të bëni me skedarët?

Ju mund t'i trajtoni ato në dy mënyra:

1. disa zgjidhje të specializuara që ofron një abstraksion, dhe ne punojmë me skedarët si një sistem skedari. Është diçka si NFS, por NFS nuk është e nevojshme.
2. "sharding" duke përdorur PHP.

Zgjidhjet e specializuara nga ajo që funksionon vërtet është GlusterFS. Kjo është diçka që mund ta vendosni për veten tuaj. Funksionon, është i shpejtë, jep të njëjtën ndërfaqe si NFS, vetëm se funksionon me një shpejtësi normale të tolerueshme.

Dhe Amazon S3, nëse jeni në cloud të Amazon, është gjithashtu një sistem i mirë skedarësh.

Nëse po zbatoni nga ana PHP, ekziston një bibliotekë e mrekullueshme Flysystem, e mbuluar me teste të shkëlqyera, mund të përdoret për të punuar me të gjitha llojet e sistemeve të skedarëve, gjë që është shumë e përshtatshme. Nëse shkruani menjëherë të gjithë punën me skedarët me këtë bibliotekë, atëherë transferimi nga sistemi lokal i skedarëve në Amazon S3 ose të tjerët do të jetë i thjeshtë - rishkruani rreshtin në konfigurim.

Si punon? Një përdorues shkarkon një skedar nga një shfletues, ai ose mund të shkojë në frontend dhe prej andej të përhapet në serverët e skedarëve, ose në secilin server skedari krijohet një skrip ngarkimi dhe skedari ngarkohet drejtpërdrejt në sistemin e skedarëve. Epo, paralelisht, shkruhet në bazën e të dhënave se cili skedar është në cilin server, dhe ne mund ta lexojmë atë direkt nga atje.

Është më mirë të shpërndani skedarë me nginx ose llak, por është më mirë të bëni gjithçka me nginx, sepse ne të gjithë e duam dhe e përdorim atë - mund ta trajtojë atë, është mirë.

Çfarë po ndodh me bazën tonë të të dhënave?

Nëse gjithçka zbret në kodin PHP, ne krijojmë një sërë frontesh dhe ende kthehemi në një bazë të dhënash - ajo do të përballojë për një kohë mjaft të gjatë. Nëse ngarkesa nuk është e tmerrshme, atëherë baza e të dhënave jeton mirë. Për shembull, ne bëmë JOIN të 160 milion rreshtave në një tabelë, dhe gjithçka ishte e shkëlqyeshme, gjithçka funksionoi mirë, por atje, sidoqoftë, më shumë RAM duhet të ndahet në buferë, në cache...

Çfarë të bëjmë me bazën e të dhënave nëse hasim në të? Ka teknika të tilla si replikimi. Zakonisht ka replikim master-slave dhe ka replikim master-master. Ju mund të bëni replikim me dorë, mund të bëni ndarje dhe mund të bëni ndarje.

Çfarë është një skllav i zoti?

Një server zgjidhet si kryesor dhe një grup serverësh zgjidhen si dytësorë. Shkruhet te kryesorja dhe mund të lexojmë nga zotëria, ose mundemi edhe nga skllevërit (në foto shigjetat e kuqe janë ato që shkruajmë, ato jeshile janë ato që lexojmë). Në një projekt tipik, ne kemi shumë më tepër lexime sesa shkrime. Ka projekte atipike.

Në rastin e një projekti tipik, një numër i madh skllevërsh ju lejon të lehtësoni si masterin dhe, në përgjithësi, të rrisni shpejtësinë e leximit.

Kjo gjithashtu siguron tolerancë ndaj gabimeve - nëse njëri prej skllevërve dështon, atëherë asgjë nuk duhet të bëhet. Nëse zotëria bie, ne mund ta bëjmë shpejt një nga skllevërit zot. Vërtetë, kjo zakonisht nuk bëhet automatikisht, kjo është një situatë emergjente, por ekziston një mundësi.

Epo, dhe kopjet rezervë. Të gjithë bëjnë kopje rezervë të bazës së të dhënave ndryshe, ndonjëherë kjo bëhet me një hale MySQL dhe ngrin të gjithë projektin, gjë që nuk është shumë e mirë. Por nëse bëni një kopje rezervë nga ndonjë skllav, pasi e keni ndaluar së pari, përdoruesi nuk do të vërejë asgjë. Kjo eshte e mrekullueshme.

Për më tepër, llogaritjet e rënda mund të bëhen në skllevër në mënyrë që të mos prekin bazën kryesore, projektin kryesor.

Ekziston një gjë e tillë si ndarja e leximit/shkrimit Ka 2 grupe serverësh - master, skllav, lidhje sipas kërkesës dhe logjika e përzgjedhjes së lidhjes ndryshon. Çështja është se nëse lexojmë gjithmonë nga skllevërit dhe gjithmonë i shkruajmë zotërisë, atëherë do të ketë një pritë të vogël:

ato. përsëritja nuk është e menjëhershme dhe nuk ka asnjë garanci që ai të ketë përfunduar kur bëjmë ndonjë kërkesë.

Ekzistojnë dy lloje të mostrave:

1. për lexim ose dalje;
2. për regjistrim, d.m.th., kur kemi zgjedhur diçka dhe atëherë kjo diçka duhet të ndryshohet dhe të shkruhet përsëri.

Nëse mostra është për shkrim, atëherë ne mund të lexojmë gjithmonë nga master dhe t'i shkruajmë masterit, ose mund të ekzekutojmë "SHOW STATUS SLAVE" dhe të shikojmë Seconds_Behind_Master atje (për PostgreSQL ka gjithashtu një super-pyetje në foto) - do të na tregojë numrin. Nëse është 0 (zero), atëherë gjithçka tashmë është përsëritur dhe mund të lexoni me siguri nga skllavi. Nëse numri është më i madh se zero, atëherë duhet të shikojmë vlerën - ose duhet të presim pak dhe pastaj të lexojmë nga skllav, ose menjëherë të lexojmë nga master. Nëse kemi NULL, do të thotë se nuk e kemi përsëritur ende, diçka ka ngecur dhe duhet të shikojmë regjistrat.

Arsyet për një vonesë të tillë janë ose një rrjet i ngadaltë, ose një kopje nuk mund të përballojë, ose shumë skllevër (më shumë se 20 për 1 master). Nëse rrjeti është i ngadalshëm, atëherë është e qartë se duhet të përshpejtohet disi, të mblidhet në qendra të vetme të të dhënave, etj. Nëse një kopje dështon, atëherë duhet të shtoni kopje. Nëse ka shumë skllevër, atëherë duhet të dilni me diçka interesante, ka shumë të ngjarë, të krijoni një lloj hierarkie.

Çfarë është një mjeshtër mjeshtër?

Kjo është një situatë ku ka disa serverë, dhe gjithçka shkruhet dhe lexohet kudo. Avantazhi është se mund të jetë më i shpejtë, është tolerant ndaj gabimeve. Në parim, gjithçka është e njëjtë si për skllevërit, por logjika është përgjithësisht e thjeshtë - ne thjesht zgjedhim një lidhje të rastësishme dhe punojmë me të. Disavantazhet: vonesa e replikimit është më e lartë, ekziston mundësia për të marrë një lloj të dhënash jokonsistente, dhe nëse ndodh një lloj prishjeje, atëherë ajo fillon të përhapet në të gjithë masterat, dhe askush nuk e di se cili master është normal, cili është e thyer... Këtu fillon e gjithë puna replikuar në një rreth, d.m.th. Ajo bllokon shumë mirë rrjetin. Në përgjithësi, nëse duhet të bëni një master-mjeshtër, duhet të mendoni 100 herë. Me shumë mundësi, ju mund të kaloni me një skllav master.

Ju gjithmonë mund të bëni replikimin me dorë, d.m.th. organizoni disa lidhje dhe shkruani në 2, 3 menjëherë ose bëni diçka në sfond.

Çfarë është sharding?

Në fakt, kjo po përhap të dhëna nëpër disa serverë. Ju mund të copëtoni tabela individuale. Le të marrim, për shembull, një tabelë fotografish, një tabelë përdoruesish, etj., dhe t'i tërheqim ato në serverë të veçantë. Nëse tabelat ishin të mëdha, atëherë gjithçka bëhet më e vogël, harxhohet më pak memorie, gjithçka është në rregull, por ju nuk mund të JOIN dhe duhet të bëni pyetje si WHERE IN, d.m.th. së pari zgjedhim një grup ID, pastaj zëvendësojmë të gjitha këto ID në pyetje, por në një lidhje tjetër, në një server tjetër.

Ju mund të copëtoni një pjesë të të njëjtave të dhëna, d.m.th., për shembull, ne marrim dhe krijojmë disa baza të dhënash me përdoruesit.

Ju thjesht mund të zgjidhni një server - pjesa e mbetur e ndarjes me numrin e serverëve. Një alternativë është të merrni një kartë, d.m.th. Për çdo rekord, mbani çelësin e vlerës në disa Redis ose të ngjashme, d.m.th. ku ndodhet secili rekord.

Ekziston një mundësi më e lehtë:

Është më e vështirë kur nuk mund të gruposh të dhënat. Duhet të dini ID-në e të dhënave për ta marrë atë. Nuk ka BASHKIM, POROSIS, etj. Në fakt, ne e reduktojmë MySQL ose PostgreSQL tonë në një dyqan me vlerë kyçe, sepse nuk mund të bëjmë asgjë me to.

Detyrat e zakonshme bëhen të jashtëzakonshme:

• Zgjidhni TOP 10.
• Zbërthimi i faqes.
• Zgjidhni atë me koston më të ulët.
• Zgjidhni postimet nga përdoruesi X.

Nëse e kemi copëtuar aq shumë sa gjithçka shpërndahet në të gjithë serverët, kjo fillon të zgjidhet në një mënyrë shumë jo të parëndësishme. Në këtë situatë, lind pyetja - pse na duhet fare SQL? A nuk duhet t'i shkruajmë menjëherë Redisit? A kemi zgjedhur objektin e duhur të ruajtjes?

Jashtë kutisë, ndarja mbështetet nga gjëra të tilla si:

• memcache;
• Redis;
• Cassandra (por ajo, thonë ata, në një moment nuk mund të përballojë dhe fillon të bjerë).

Po statistikat?

Shpesh u pëlqen të llogarisin statistikat nga serveri kryesor - nga një server i vetëm i bazës së të dhënave. Kjo është e mrekullueshme, por pyetjet në statistika janë zakonisht rrëqethëse, me shumë faqe, etj., kështu që llogaritja e statistikave nga të dhënat kryesore është një gabim i madh. Në shumicën e rasteve, koha reale nuk nevojitet për statistikat, kështu që ne mund të vendosim replikimin në skllavin kryesor dhe t'i llogarisim këto statistika në skllav. Ose mund të marrim diçka të gatshme - Mixpanel, Google Analytics ose të ngjashme.

Kjo është ideja kryesore që ndihmon për të shpërndarë gjithçka nëpër serverë dhe shkallë të ndryshme. Së pari, fitimi nga kjo është menjëherë i dukshëm - edhe nëse keni një server dhe filloni të bëni diçka në sfond, përdoruesi merr një përgjigje shumë më shpejt, por gjithashtu shpërndan më pas ngarkesën, d.m.th. ne mund ta zvarritim gjithë këtë përpunim në një server tjetër, madje mund ta përpunojmë jo në PHP. Për shembull, në Stay.com, madhësia e imazheve ndryshohet në Go.

Ju mund të merrni menjëherë Gearman. Kjo është një gjë e gatshme për përpunim në sfond. Ka librari dhe drejtues për PHP... Ose mund të përdorni radhët, d.m.th. ActiveMQ, RabbitMQ, por rradhët përcillen vetëm mesazhet, ata nuk i thërrasin apo ekzekutojnë vetë mbajtësit, dhe më pas ju duhet të gjeni diçka.

Kuptimi i përgjithshëm është gjithmonë i njëjtë - ekziston softueri kryesor që vendos disa të dhëna në radhë (zakonisht kjo është "çfarë duhet të bëj?" dhe të dhëna për këtë), dhe një shërbim - ose i merr ose i dërgohet (nëse radha mund të kryejë në mënyrë aktive) këto të dhëna, ajo përpunon gjithçka në sfond.

Le të kalojmë në arkitekturë.

Gjëja më e rëndësishme gjatë shkallëzimit është që ta bëni projektin sa më pak të lidhur. Sa më pak lidhje, aq më e lehtë është të ndryshosh një zgjidhje në një tjetër, aq më e lehtë është të zhvendosësh një pjesë në një server tjetër.

Kohezioni ndodh në kod. SOLID, GRASP janë parime që ju lejojnë të shmangni bashkimin në kod. Por lidhja në kod, natyrisht, ndikon në shpërndarjen nëpër serverë, por jo aq shumë sa lidhja e shtresës së domenit me mjedisin tonë. Nëse shkruajmë shumë kode në kontrollues, rezulton se me shumë mundësi nuk do të jemi në gjendje ta përdorim diku tjetër. Nuk do të jetë e lehtë për ne që t'i transferojmë të gjitha këto nga kontrolluesi i uebit në tastierë dhe, në përputhje me rrethanat, do të jetë më e vështirë ta transferojmë atë në serverë të tjerë dhe ta përpunojmë ndryshe atje.

Arkitektura e orientuar nga shërbimi.

Ekzistojnë 2 qasje për ndarjen e sistemeve në pjesë:

kur fokusohen në pjesë teknike, d.m.th., ka një radhë, kanë hequr shërbimin e radhës, ka përpunim imazhi, e kanë hequr këtë shërbim, etj.

Kjo është mirë, por kur këto radhë, imazhe, etj. ndërveproni brenda dy zonave të domenit... Për shembull, në një projekt ka një zonë shitjesh dhe një zonë të klientit - këto janë zona të ndryshme, përdorues të ndryshëm punojnë me to, por të dyja kanë radhë të ndryshme. Kur gjithçka fillon të bjerë së bashku, projekti bëhet rrëmujë;

Zgjidhja e saktë është të ndash në pjesë të veçanta logjike, d.m.th. nëse zonat e Shitjeve dhe Klientit përdorin modelin e përdoruesit, atëherë ne krijojmë 2 modele përdoruesi. Ata mund të lexojnë të njëjtat të dhëna, por ato i paraqesin pak më ndryshe. Nëse e prishni sistemin në këtë mënyrë, atëherë gjithçka perceptohet shumë më mirë dhe është shumë më e lehtë t'i shpërndani të gjitha.

Një tjetër gjë e rëndësishme është se pjesët duhet të komunikojnë gjithmonë përmes ndërfaqeve. Pra, në shembullin tonë, nëse Sales ndërvepron me diçka, atëherë ajo nuk shkruan në bazën e të dhënave, nuk përdor një model të përbashkët dhe "bisedon" me fusha të tjera përmes një kontrate specifike.

Po në lidhje me shtresën e domenit?

Shtresa e domenit është e ndarë në disa shërbime, etj. - kjo është e rëndësishme për zhvillimin e një aplikacioni, por për shkallëzimin e dizajnit të tij nuk është shumë e rëndësishme. Në shtresën e domenit është jashtëzakonisht e rëndësishme ta ndash atë nga mjedisi, konteksti në të cilin ekzekutohet, d.m.th. nga kontrolluesi, mjedisi i konsolës etj., në mënyrë që të gjitha modelet të mund të përdoren në çdo kontekst.

Ka 2 libra në lidhje me shtresën e domenit që unë rekomandoj për të gjithë:

• "Dizajni i drejtuar nga domeni: Trajtimi i kompleksitetit në zemrën e softuerit" nga Eric Evans,
• "Zbatimi i dizajnit të drejtuar nga domeni, zbatimi i dizajnit të drejtuar nga domeni."

• rreth BoundedContext - http://martinfowler.com/bliki/BoundedContext.html (ajo që u përmend më lart - nëse dy zonat tuaja duket se kryqëzohen, por ato janë të ndryshme, atëherë ia vlen të dublikoni disa entitete, siç është modeli i përdoruesit);
• rreth DDD në përgjithësi - lidhje me një libër tjetër.

Në arkitekturë, përsëri, ia vlen t'i përmbahemi parimit të ndarjes asgjë, d.m.th. nëse doni të bëni diçka të përbashkët, bëjeni gjithmonë me vetëdije. Është e preferueshme të vendosni logjikën në anën e aplikacionit, por ia vlen të dini se kur të ndaloni. Asnjëherë, për shembull, nuk duhet të krijoni procedura të ruajtura në një DBMS, sepse shkallëzimi i tij është shumë i vështirë. Nëse e transferojmë këtë në anën e aplikacionit, atëherë bëhet më e lehtë - do të krijojmë disa serverë dhe gjithçka do të kryhet atje.

Mos e nënvlerësoni optimizimin e shfletuesit. Siç thashë tashmë, nga 300-600 ms që kërkesat ekzekutohen në server, atyre u shtohen 300-600 ms, të cilat shpenzohen për klientin. Klientit nuk i intereson nëse serveri ynë është i shpejtë, ose nëse faqja funksionon kaq shpejt, kështu që unë ju këshilloj të përdorni Google PageSpeed, etj.

Si zakonisht, abstragimi dhe fragmentimi nuk janë aspak të lira. Nëse e ndajmë shërbimin në shumë mikroshërbime, atëherë nuk do të mund të punojmë më me të sapoardhurit dhe do të duhet t'i paguajmë shumë, shumë ekipit tonë, i cili do të rrëmojë të gjitha këto, do të renditë nëpër të gjitha shtresat, përveç kësaj , shërbimi mund të fillojë të funksionojë më ngadalë. Nëse kjo nuk është e frikshme në gjuhët e përpiluara, atëherë në PHP, të paktën deri në versionin 7, kjo nuk është shumë...

Asnjëherë mos veproni verbërisht, gjithmonë monitoroni dhe analizoni. Verbërisht, pothuajse të gjitha vendimet e paracaktuara janë të gabuara. Mendoni! Mos besoni se ka një plumb argjendi, kontrolloni gjithmonë.

Disa lidhje më të dobishme:

Sistemet, paketat softuerike, sistemet e bazës së të dhënave, ruterat, rrjetet, etj., nëse kërkojnë aftësi për të punuar nën ngarkesë të madhe. Sistemi quhet i shkallëzuar, nëse është në gjendje të rrisë produktivitetin në raport me burimet shtesë. Shkallueshmëria mund të vlerësohet përmes raportit të rritjes së performancës së sistemit me rritjen e burimeve të përdorura. Sa më afër të jetë ky raport me një, aq më mirë. Shkallueshmëria nënkupton gjithashtu aftësinë për të rritur burimet shtesë pa ndryshime strukturore në nyjen qendrore të sistemit.

Në një sistem me shkallëzim të dobët, shtimi i burimeve çon vetëm në një rritje të lehtë të performancës dhe pas një pike të caktuar "pragu", shtimi i burimeve nuk ka ndonjë efekt të dobishëm.

Shkallëzimi vertikal

Rritja e performancës së secilit komponent të sistemit për të përmirësuar performancën e përgjithshme.

Shkallëzimi horizontal

Ndarja e sistemit në komponentë më të vegjël strukturorë dhe shpërndarja e tyre nëpër makina të veçanta fizike (ose grupe të tyre) dhe/ose rritja e numrit të serverëve që kryejnë të njëjtin funksion paralelisht.

Shënime

Shiko gjithashtu

Lidhjet

Fondacioni Wikimedia. 2010.

Shihni se çfarë është "Shkallëzimi" në fjalorë të tjerë:

shkallëzueshmëria- zgjerueshmëria Karakteristika e një aplikacioni që funksionon në platforma të ndryshme dhe ndryshon në madhësi (për shembull, në një kompjuter me Windows dhe në një stacion pune Sun që funksionon Unix). Për harduerin, rritje e parashikueshme në performancën e sistemit me... ...

shkallëzueshmëria- 3.1.43 shkallëzueshmëria: Aftësia për të ofruar funksionalitet lart e poshtë një grupi të porositur platformash aplikacioni që ndryshojnë në shpejtësi dhe burime. Burimi… Fjalor-libër referues i termave të dokumentacionit normativ dhe teknik

Aftësia e softuerit për të ekzekutuar saktë në sisteme të vogla dhe të mëdha me performancë që rritet në proporcion me fuqinë përpunuese të sistemit. Në anglisht: Scalability Shihni gjithashtu: Open System Software Software… Fjalor Financiar

shkallëzueshmëria e sistemit (në SCADA)- shkallëzueshmëria e sistemit [Intent] Shkallueshmëria e sistemit. Kjo do të thotë që projekti i zhvilluar mund të testohet në një kompjuter ose në një rrjet të vogël dhe më pas të zgjerohet sistemi (në përputhje me programin e zhvillimit, buxhetin, etj.) pa... ... Udhëzues teknik i përkthyesit

shkallëzueshmëria (në teknologjinë e informacionit)- Aftësia e një shërbimi IT, procesi, artikulli konfigurimi, etj., për të kryer funksionin e tij të rënë dakord më parë kur ndryshon ngarkesa ose fushëveprimi. [ITIL Glossary of Terms version 1.0, 29 korrik 2011] SQ shkallëzueshmëria Aftësia e një IT... ... Udhëzues teknik i përkthyesit

shkallëzueshmëria (aplikacionet)- zgjerueshmëria e shkallëzimit Karakteristikat e një aplikacioni që funksionon në platforma të ndryshme dhe ndryshon në madhësi (për shembull, në një PC nën Windows dhe në një stacion pune Sun nën Unix). Për harduerin, rritje e parashikueshme në sistem... ... Udhëzues teknik i përkthyesit

shkallëzueshmëria (rrjetet dhe sistemet e komunikimit)- Një kriter për një sistem automatizimi të nënstacionit me kosto efektive, duke marrë parasysh karakteristika të ndryshme funksionale, pajisje të ndryshme elektronike inteligjente, madhësinë e nënstacionit dhe diapazonin e tensionit të nënstacionit. [GOST R 54325 2011... ... Udhëzues teknik i përkthyesit

Gjerësisht i shkallëzuar- - [L.G. Sumenko. Fjalori anglisht-rusisht i teknologjisë së informacionit. M.: Ndërmarrja Shtetërore TsNIIS, 2003.] Temat e teknologjisë së informacionit në përgjithësi EN shkallëzueshmëria terabyte ... Udhëzues teknik i përkthyesit

shkallëzueshmëria horizontale- Rritja e kapacitetit të sistemit duke shtuar nyje në grup. Temat e teknologjisë së informacionit në përgjithësi EN shkallëzueshmëria horizontale ... Udhëzues teknik i përkthyesit

SCALABILITY - shkallëzueshmëri- një nga parimet bazë të ndërtimit të sistemeve të hapura, garanton ruajtjen e investimeve në informacion dhe softuer kur kaloni në një platformë harduerike më të fuqishme... Fjalori i E-Biznesit

libra

• Microsoft SharePoint 2010. Udhëzuesi i plotë, Michael Noel, Colin Spence. Libri eksploron të gjitha veçoritë e reja në SharePoint—nga veçoritë e reja të rrjeteve sociale deri tek kërkimi i përmirësuar—që ju ndihmojnë të përfitoni sa më shumë nga të dyja SharePoint...

9 korrik 2015 ora 09:10

Shkallëzimi horizontal i serverëve të bazës së të dhënave për sistemet OLTP, ose çfarë është në treg

• Administrimi i bazës së të dhënave,
• Optimizimi i serverit

Si rregull, kompanitë e mëdha dhe të mesme kanë sisteme informacioni transaksionale shumë të ngarkuara që janë komponenti më i rëndësishëm i biznesit, ato quhen sisteme OLTP. Ndërsa biznesi rritet, ngarkesa rritet shumë shpejt, kështu që detyra për të rritur produktivitetin e burimeve ekzistuese për serverët e bazës së të dhënave është shumë akute. Shpesh, për të zgjidhur problemin e rritjes së performancës së serverëve të bazës së të dhënave, blihen pajisje më të fuqishme (i ashtuquajturi shkallëzim "vertikal"), por kjo metodë ka një disavantazh shumë domethënës: herët a vonë kompania do të blejë një server të bazës së të dhënave me maksimum. performanca me një çmim të përballueshëm dhe çfarë të bëni më pas? Perspektivat e mëtejshme për biznesin mund të mos jenë aq rozë - në shumë raste po flasim për një përkeqësim të reputacionit të kompanisë, pamundësi për t'i shërbyer klientëve në momentet e rritjes së kërkesës dhe një humbje të konsiderueshme fitimi.

Për të eliminuar situata të tilla dhe për të siguruar funksionalitetin e sistemeve OLTP, shumë kompani marrin rrugën e shkallëzimit "horizontal" të serverëve të bazës së të dhënave. Në ndryshim nga rritja e performancës së serverit kryesor (shkallëzimi "vertikal"), me shkallëzimin "horizontal", serverët kombinohen në një grup (set), dhe ngarkesa në serverët e bazës së të dhënave shpërndahet midis tyre. Kjo qasje është më e avancuar teknologjikisht, pasi përveç avantazheve të dukshme në formën e mundësisë së rritjes së produktivitetit duke shtuar serverë të rinj, zgjidhet problemi i arritjes së tolerancës ndaj gabimeve dhe fatkeqësive.

Shumë kompani IT në Rusi dhe në botë po zhvillojnë zgjidhje të ngjashme më poshtë do të përpiqem të flas për to në mënyrë më të detajuar.

Zgjidhja e parë - Oracle RAC (Cluster i vërtetë i aplikacioneve)- u shfaq në vitin 2001 në versionin 9i për të rritur disponueshmërinë dhe performancën në sistemet shumë të ngarkuara të bazuara në Oracle DBMS. Kjo ju lejon të shpërndani ngarkesën në një bazë të dhënash shumë të ngarkuar midis serverëve të bazës së të dhënave dhe në këtë mënyrë të rritni aftësitë e sistemit OLTP për rritjen e qetë të rrjedhave të informacionit. Për informacion më të detajuar, referojuni dokumentacionit ose librave nga Oracle Press. Prandaj, do të ndalem në disa pika që janë interesante nga pikëpamja e parimit të funksionimit.

Sepse Oracle RAC zbaton arkitekturën Shared-everything (me të gjitha avantazhet dhe disavantazhet e saj të natyrshme), më pas për secilin server në Oracle RAC ekziston cache e tij, e cila përmban të dhënat e pyetjeve SQL të ekzekutuara në të. Ekziston gjithashtu një cache globale e grupeve, e implementuar duke përdorur teknologjinë Cache Fusion, e cila sinkronizohet me memorien e serverit lokal bazuar në të dhëna. Një rol të veçantë në koordinimin e burimeve të grupimeve dhe grumbullimit të cache-it luan struktura e të dhënave Global Resource Directory, e cila regjistron në cilin server, cilat të dhëna dhe për cilat objekte janë relevante; cili është mënyra e mbylljes për objektin në shembull. I gjithë ky informacion ju ndihmon të vendosni se cili server është më i mirë për të dërguar një pyetje SQL nga pikëpamja e performancës, pasi nëse merrni vendimin e gabuar, koha e pyetjes SQL do të rritet për shkak të kohës që duhet për të sinkronizuar të dhënat midis cache-ve.

Një tipar i rëndësishëm i kësaj qasjeje për shpërndarjen e ngarkesës midis serverëve të bazës së të dhënave është nevoja për të marrë parasysh "diversitetin" e trafikut SQL nga sistemi OLTP. Në rastet kur pyetjet SQL marrin të dhëna nga shumë tabela në të njëjtën kohë, dhe shkalla e ndryshimit në këto tabela është e madhe, mund të humbet koha duke sinkronizuar të dhënat e cache-së midis serverëve të ndryshëm në grup (kjo është arsyeja pse një ndërlidhje e shpejtë dhe e besueshme midis serverëve eshte e nevojshme). Kjo, nga ana tjetër, mund të çojë në përgjegjshmëri të degraduar të sistemit OLTP dhe përfitimet e përdorimit të Oracle RAC mund të mohohen plotësisht.

Të mirat:

• Grup aktiv/Aktiv
• Balancimi i ngarkesës
• Shkallëzimi me performancë të rritur por edhe disponueshmëri të rritur
• Rritje pothuajse lineare e performancës kur shtohen nyje të reja në grup
• Aplikim-shkallëzim transparent

Minuset:

• Punon vetëm me Oracle DBMS
• Për funksionimin kërkohet një ndërlidhje me performancë të lartë me vonesë të ulët
• Sistemet e ruajtjes mund të jenë një pikë e vetme dështimi. Për të siguruar një nivel të lartë të tolerancës ndaj gabimeve, RAC duhet të kombinohet me pasqyrimin e gatishmërisë ose të ruajtjes.

Zgjidhja e dytë - Citrix NetScaler– zbaton shkallëzimin horizontal të serverëve të bazës së të dhënave për sistemet OLTP të bazuara në MS SQL Server dhe MySQL ndryshe nga Oracle RAC. Karakteristikat teknike mund të gjenden duke ndjekur lidhjen.

Nëse në Oracle RAC serverët e bazës së të dhënave sinkronizohen automatikisht, atëherë Citrix NetScaler duhet të përdorë teknologji të palëve të treta për sinkronizim: AlwaysOn nga Microsoft, replikimi MySQL. Vetë zgjidhja Citrix NetScaler është një server proxy midis shtresës së aplikacionit (serveri i aplikacionit, serveri në internet) dhe serverëve të bazës së të dhënave, kështu që të gjitha kërkesat SQL për serverin e bazës së të dhënave kalojnë përmes tij.

Sipas specifikimeve, zgjidhja mund të njohë nënshkrimin e pyetjeve SQL (për leximin ose shkrimin e të dhënave) dhe t'i ridrejtojë ato në serverët e nevojshëm (të përcaktuar nga cilësimet) në grup. Vonesa për përpunimin e një pyetjeje SQL nga serveri proxy është minimale, kështu që përgjigja e sistemit OLTP nuk duhet të përkeqësohet pas zbatimit. Pavarësisht nga ky përfitim, aftësia për të ngarkuar pyetjet SQL të bilancit varet gjithashtu nga karakteristikat e trafikut të sistemit OLTP. Në shumë sisteme OLTP, të dhënat e ndryshuara në një transaksion lexohen menjëherë nga pyetësori tjetër SQL për punë të mëtejshme. Duke marrë parasysh veçoritë e një teknologjie të tillë, siç është MS AlwaysOn, të dhënat në serverët shtesë mbeten prapa atij kryesor për ca kohë (në modalitetin sinkron dhe asinkron). Pa marrë parasysh këtë, aplikacioni dhe përdoruesi mund të përfundojnë me një situatë ku të dhënat e shtuara nuk do të merren në pyetjen e ardhshme SQL. Si rregull, teknologjia Citrix NetScaler rekomandohet të përdoret jo në modalitetin automatik, por në modalitetin manual, kështu që fushëveprimi i saj i aplikimit është i kufizuar në pyetje të thjeshta të bazës së të dhënave në aplikacionet në internet.

Teknologjia e tretë - Grupi i të dhënave Softpoint– një zhvillim rus, i cili është i ngjashëm me dy të mëparshmet, por në një sërë mënyrash është më i zbatueshëm për problemet praktike të shkallëzimit "horizontal" të serverëve të bazës së të dhënave për sistemet OLTP. Informacione më të hollësishme rreth produktit mund të gjenden në faqen e internetit të shitësit.

Në pamje të parë, teknologjia është e ngjashme me Citrix NetScaler, pasi është një server proxy midis nivelit të aplikacionit dhe nivelit të bazës së të dhënave, dhe gjithashtu është i integruar ngushtë me teknologjitë e sinkronizimit të bazës së të dhënave (për shembull, MS AlwaysOn), por ndryshe nga Citrix NetScaler monitoron bazën e të dhënave serveri desinkronizohet në grup dhe garanton plotësisht konsistencën e të dhënave në mostra, pavarësisht se ku është ekzekutuar pyetja SQL në serverë. Kjo veçori ju lejon të siguroni balancimin automatik të ngarkesës pa u përshtatur me trafikun e aplikacionit.

Teknologjia gjithashtu siguron sinkronizimin e tabelave të përkohshme midis serverëve në grup, gjë që është shumë e rëndësishme për balancim më të mirë, duke përfshirë pyetjet SQL duke përdorur tabela të përkohshme. Një avantazh i rëndësishëm i përdorimit të Softpoint Data Cluster është mundësia për t'u njohur me shembuj të zbatimeve për