Ilgaamžė informacinė sistema būtinai reikalauja mastelio (~ dydžio keitimo), tai yra, tam tikro augimo neperrašant visko programos kodas ir visos įrangos pakeitimas.
Sistema gali būti keičiama trimis kryptimis: 1) dydis ( papildomų vartotojų, ištekliai), 2) mastas geografine prasme, 3) administravimas (daugelyje administraciškai nepriklausomų organizacijų).
Kitaip tariant, mastelio keitimas apima keletą augimo tipų: vartotojų skaičių tinkle, duomenų bazės dydį, operacijų sudėtingumą, naujų programų atsiradimą.
Vartotojų skaičius tinkle. Jei jis padvigubės, greičiausiai tinklo ir duomenų bazės apkrova padvigubės.
Duomenų bazės dydis. Duomenų bazei padidėjus iki dešimčių ir šimtų gigabaitų, atsarginės kopijos kūrimo, atkūrimo ir atsisiuntimo operacijos taps kliūtimi.
Sandorio sudėtingumas. Programų kūrėjai daro jas vis „protingesnes“, todėl vartotojams lengviau dirbti ir analizuoti duomenis. Tačiau tuo pačiu metu duomenų ryšių skaičius didėja eksponentiškai, dėl to, pirma, padidėja rašymo sudėtingumas, todėl padidėja klaidų tikimybė. Ir, antra, atliekant tokią operaciją, sistemai reikia apdoroti didelį duomenų kiekį, o tai gali būti praktiškai neįmanoma esant tam tikrai procesoriaus galiai, RAM kiekiui ir pan. Tam, savo ruožtu, reikia parašyti specialius algoritmus, skirtus duomenų iškrovimui, kaupimui talpykloje ir kt.
Naujų programų atsiradimas. Vartotojai pradeda naudotis kompiuteriu naujose srityse, o tai padidina esamų serverių apkrovą. Be to, būtina organizuoti programų integravimą.
Išplečiamose sistemose gali būti naudojamas vienas (arba abu!) galios mastelio keitimo principas skaičiavimo sistema: daugiaprocesis, klasterinė technologija.
Keičiamos sistemos išsprendžia aukščiau nurodytas centralizavimo problemas, padidindamos tinklo, serverių, duomenų bazių ir taikomųjų programų dydį ir galią tiesiog pridėdamos aparatinę įrangą. Keičiami IC suteikia augimo kelius, kai galia didėja neperprogramuojant programų arba bent jau jų visiškai neperprogramuojant.
Stovintis mastelio keitimo kelyje
Centralizuotos paslaugos
Centralizuoti duomenys
Centralizuoti algoritmai.
Centralizuota paslauga daro prielaidą, kad tam tikra paslauga (programa) yra tik viename kompiuteryje. Jei iš skirtingų klientų į šią paslaugą skambina ne dažnai ir ne vienu metu, tai yra visiškai priimtinas sprendimas. Priešingu atveju tokia paslauga taps sistemos kliūtimi. Kad centralizuota paslauga keltų mažiau problemų, būtina naudotis didelės spartos ryšio linijomis, o kompiuteris, kuriame yra ši paslauga, turi būti pakankamai greitas, turėti RAM ir pakankamai buferių. Neabejotinas tokios paslaugos privalumas – ją lengviau atnaujinti. Jei paslauga yra procesas, kurio veikimui reikia daug skaičiavimo išteklių, gali būti daug ekonomiškiau užtikrinti, kad tie ištekliai būtų pasiekiami tik viename kompiuteryje, o ne keliuose klientuose. Tačiau, kita vertus, dažnai, kai centralizuota paslauga žlunga, visa sistema praranda savo funkcionalumą.
Centralizuotos paslaugos pavyzdys galėtų būti vartotojų, įeinančių į tinklą, teisių ir galių nustatymo procesas. Tikriausiai pastebėjote, kad kai daugelis vartotojų ryte vienu metu prisijungia prie tinklo, tai atrodo laikina. A Aš vėluoju. Jei prisijungiate prie tinklo vidury dienos, tai įvyksta greitai. Jei domeno valdiklis sugenda, išliks tik galimybė dirbti su vietiniu kompiuteriu.
Keičiamoje sistemoje siūloma naudoti decentralizuotas paslaugas. Tai galima pasiekti dviem būdais: arba atkartojant (nukopijuojant) paslaugą į kelis kompiuterius arba (jei įmanoma) padalinant paslaugą į atskiras užduotis ir paskirstant atitinkamus fragmentus skirtinguose kompiuteriuose. Pavyzdys: pakankamai didelis vietinis tinklas Rekomenduojama, kad DHCP serveris (dalyvaujantis nuomojantis IP adresus), tarptinklinio ryšio profilių saugykla būtų ne domeno valdiklyje, o atskiras kompiuteris(žinoma, įjungtas tinkamu laiku).
Dažnai centralizuota paslauga yra susijusi su centralizuotais duomenimis. Centralizuotus duomenis dažnai lengviau apsaugoti (lengviau tvarkyti atsarginė kopija). Tačiau tokių duomenų kiekis gali būti toks didelis, kad jokios pagrįstos skaičiavimo galios neužtenka. Centralizuotose saugyklose reikalingų duomenų paieška dažnai tampa sunkesnė. Viena vertus, didėjant saugyklai, paieškos laikas ilgėja. Kita vertus, centralizuotos saugyklos atveju funkcijų – paieškos parametrų – rinkinys auga, nes su duomenimis dirba daug žmonių. skirtingos užduotys. Dėl centralizuotų duomenų labai svarbu tai padaryti archyvinės kopijos siekiant sumažinti galimų nuostolių sugedus centralizuotai saugyklai. Centralizuotų duomenų pavyzdys yra duomenų bazės serveris (MY SQL, MS SQL ir kt.).
Mastelio keitimo sistema turi veikti su decentralizuotais duomenimis. Geras pavyzdys– DNS paslauga, atitinkanti simbolinį tinklo išteklių pavadinimą su jo IP adresu. DNS serverio medžio architektūra leidžia padalyti informaciją į fragmentus, kurių kiekvieną palaiko vienas serveris. Tarp serverių užmegztas ryšys ir apibrėžtas jų sąveikos protokolas. Šio ryšio suteikimas kainuoja naudojant decentralizuotą saugyklą. Decentralizuotas saugojimas turi keletą įdomių savybių: nevienodą prieigos prie informacijos laiką. Siekdami išlyginti šiuos skirtumus, tai yra, kad pagreitintų bent pakartotinę prieigą prie nuotolinių duomenų, DNS serveriai naudoja informacijos kaupimą talpykloje. Tačiau atminkite, kad talpyklos kaupimas sukelia duomenų nenuoseklumo problemą. Problemos, kylančios dėl duomenų decentralizavimo, iš kurių pagrindinė yra duomenų nenuoseklumas skirtingi kompiuteriai, pažiūrėsime šiek tiek vėliau. Pažvelkime į 13 nuoseklumo modelių.
Centralizuotas algoritmas taip pat yra blogas paskirstytai sistemai. Algoritmas gali būti laikomas centralizuotu, jei jį užbaigti, ty priimti sprendimą, reikia visa informacija, gautas iš tiesioginių šaltinių. Prisiminkime kurse studijuotus maršruto parinkimo algoritmus " Informaciniai tinklai“ Apsvarstykime „kanalo būsenos protokolą“ kaip centralizuoto algoritmo pavyzdį. Šis algoritmas daro prielaidą, kad lentelės maršrutizatorius palaiko ryšį su kiekvienu maršrutizatoriumi. Tai veda prie didžiulio perduotų paslaugų paketų skaičiaus. Šis algoritmas reikalauja maršrutizatoriaus išteklių ir tinklo, nors jis yra silpnai jautrus maršrutizatoriaus dingimui. „Atstumo vektoriaus protokolo“ algoritmas nepriklauso centralizuotiems algoritmams, nes Norėdami priimti sprendimą (sukurti maršruto parinkimo lentelę), maršrutizatoriui tereikia susisiekti su savo kaimynais. Šis algoritmas užima daug mažiau tinklo, bet gali priimti neteisingą sprendimą, kai maršrutizatorius dingsta (atstumo iki begalybės didinimo problema)
Technologijos, naudojamos kuriant keičiamo dydžio sistemas: ryšio delsos slėpimas, paskirstymas, replikacija.
Skirtojo laiko slėpimas dažnai įgyvendinamas naudojant asinchroninį ryšį, kai procesas, kuris paprašė nuotolinės paslaugos, atlieka tam tikrą darbą (nepriklausomai nuo laukiamo atsakymo), kol gaunamas atsakymas. Tam, kad tai būtų įgyvendinta, yra organizuojama kelių gijų programa, kurios viena iš gijų (gijų), esant užklausai, yra blokuojama ir laukia atsakymo, tai yra, veikia sinchroniškai su nuotoline paslauga, o likusios gijos veikia asinchroniškai, tai yra, tęsia vykdymą. Tačiau ne visada įmanoma surengti asinchroninį vykdymą, pavyzdžiui, kada interaktyvus darbas vartotojas su nuotoline duomenų baze. Tokiu atveju rekomenduojama organizuoti bent dalinį duomenų patikrinimą kliento pusėje naudojant scenarijus, taip sumažinant skambučių į nuotolinę duomenų bazę skaičių ir taip sutrumpinant kliento laukimo laiką.
Antra svarbi technologija mastelio keitimas – paskirstymas. Mes jau minėjome paskirstytą DNS paslaugą. Svarbus duomenų paskirstymo aspektas yra įvardijimas. Problema ta, kad vardai turi būti unikalūs, o tai reiškia, kad vardų erdvės turi būti vienaip ar kitaip organizuotos. Kaip ir failams, kiekvienas interneto objektas turi turėti unikalų pilnas vardas, įskaitant vardus DNS serveriai nuo objekto iki DSN šaknies.
Ir galiausiai, trečioji technologija yra replikacija. Naudojant replikaciją, visi arba dalis bendrinamų duomenų nukopijuojami į kelis kompiuterius. Dėl to duomenys gali būti priartinti prie vartotojo, taip sumažinant prieigos laiką ir sumažinant saugyklą palaikančių kompiuterių apkrovą. Tokio sprendimo kaina – būtinybė užtikrinti duomenų nuoseklumą. Reikia atskirti replikaciją ir talpyklą. Replikacija vyksta duomenų serverio (savininko) iniciatyva, o talpyklos kaupimas – kliento (vartotojo) iniciatyva.
Jei kalbame apie talpyklą, tada klientas (pvz. Internet Explorer) privalo savarankiškai stebėti duomenų tinkamumą. Tam naudojami mechanizmai: a) užklausos atnaujinti duomenis po tam tikro laiko, b) užklausos dėl aktualumo (pastovumo serveryje). Pirmuoju atveju gali būti perduodami nepakitę duomenys, o tai be reikalo apkrauna tinklą. O antruoju klientas pirmiausia išsiaiškina, ar duomenys pasikeitė, ir tik pasikeitus išsiunčia prašymą perduoti duomenis. Akivaizdu, kad jei duomenys keičiasi retai, tada geriau naudoti antrąjį metodą, kitaip - pirmąjį. Dabar keli žodžiai apie nuoseklumą. Dėl to, kad paskirstytoje sistemoje gali būti skirtingų klientų, kuriems skirtingiems duomenims reikia skirtingo „šviežumo“, skirtingi duomenys turi skirtingą atnaujinimo laiką ir kitas charakteristikas, o duomenų perdavimas yra brangus malonumas, tada skirtingų atvejų Reikės įvairių metodų nuoseklumui užtikrinti.
Mastelio keitimas informacinė sistema– tiek horizontaliai, tiek vertikaliai – yra vienas iš labiausiai svarbius veiksnius, į kurį turėtumėte atkreipti dėmesį renkantis bet kurios organizacijos veiklos automatizavimo priemonę. Jei pasirinkto sprendimo nepavyks padidinti arba kiekvienas verslo augimo etapas sukels sunkumų jį išlaikyti ir plėtoti programinės įrangos produktas, tuomet net neturėtumėte pradėti jo naudoti. LETOGRAF EDMS sukūrėme atsižvelgdami į aukštus mastelio keitimo reikalavimus.
Horizontalaus arba vertikalaus mastelio poreikis atsiranda kuriant įmonių didelės apkrovos IT sistemas, kuriose dirba tūkstančiai ar net dešimtys tūkstančių vartotojų. Tačiau ne visos EDMS gali palaikyti daugelio vartotojų veikimą vienu metu. Tik tuo atveju, jei EDMS architektūriniame lygmenyje turi galimybę padidinti vartotojų skaičių neprarandant našumo – tik šiuo atveju mastelio keitimas bus sėkmingas. Mūsų sukurta LETOGRAF sistema buvo sukurta taip, kad būtų idealiai keičiama tiek horizontaliai, tiek vertikaliai. Tai pasiekiama naudojant pačios sistemos architektūrą ir programos kodą, kurį sukūrėme, ir naudojant InterSystems Caché DBVS, kurios pagrindu yra sukurta mūsų EDMS, funkcionalumą.
Caché DBMS yra moderni duomenų bazių valdymo sistema ir aplinka, skirta greitam programų kūrimui. Ši DBVS yra pagrįsta technologija, kuri užtikrina našumą ir didelio našumo, mastelio keitimas ir patikimumas. Tuo pačiu metu sistemos techninės įrangos reikalavimai išlieka gana kuklūs.
Caché DBVS palaiko aukštą našumą net dirbant su didžiuliu duomenų kiekiu ir daugybe serverių paskirstytose sistemose. Šiuo atveju duomenys pasiekiami per objektus, didelio našumo SQL užklausas ir tiesiogiai apdorojant daugiamates duomenų struktūras.
Vertikalus mastelio keitimas
Vertikalus mastelio keitimas apima serverio galios ir su jo galimybių didinimą disko posistemis. LETOGRAF palaiko modernią procesoriaus architektūrą, kuri leidžia apdoroti didelius duomenų kiekius keliose gijose. Tuo pačiu metu patys duomenys EDMS yra sutvarkyti taip, kad juos būtų galima lengvai paskirstyti saugojimo sistemoje. skirtingi diskai. Šis metodas leidžia tolygiai paskirstyti duomenų saugykloje esančią apkrovą ir sumažinti ją nuskaitant duomenis tiesiai iš duomenų bazės, o tai reiškia, kad sistemos našumo sumažėjimo galima išvengti net tada, kai vienu metu dirba daug vartotojų.
Dar platformos kūrimo etape supratome, kad vertikalus mastelio keitimas yra viena iš pagrindinių sistemos galimybių, kurios poreikis laikui bėgant tik didės. Sistemą sukūrėme taip, kad kiekvieno vartotojo darbo procesai buvo atskirti į atskirus sistemos procesai, kurios nesutampa dėl to, kad duomenų bazės veiksmingai dalijasi prieiga prie informacijos. Tuo pačiu metu LETOGRAF EDMS yra sumažintas duomenų užraktų skaičius ir nėra kliūčių nei skaitant duomenis, nei juos rašant.
EDMS LETOGRAF architektūra leidžia paskirstyti duomenis keliuose fiziniuose ar virtualiuose serveriuose. Dėl šio paskirstymo kiekvienas vartotojas veikia izoliuotame procese, o reikalingi duomenys efektyviai talpinami naudojant Caché DBVS technologijas. Duomenų užrakinimo laikas yra minimalus: visos operacijos susistemintos taip, kad duomenys į išskirtinės prieigos režimą būtų perkelti tik labai trumpam laikui. Tuo pačiu metu net tokie labai apkrauti duomenys, kalbant apie prieigų į diską skaičių, tokie kaip žurnalai, indeksai, objektų duomenys, srautai, vartotojo veiksmų žurnalai, yra paskirstomi taip, kad vidutinė posistemio apkrova išliktų vienoda ir nesukelia vėlavimų. Šis metodas leidžia efektyviai vertikaliai padidinti sistemos mastelį, paskirstant apkrovą tarp serverių ar virtualių diskų.
Horizontalus mastelio keitimas
Horizontalus mastelio keitimas – tai vartotojų seansų paskirstymas per skirtingus serverius (tolygus programų serverių įkėlimas ir galimybė prijungti papildomus taikomųjų programų serverius), taip pat duomenų paskirstymas tarp skirtingų duomenų bazių serverių, kas užtikrina aukštą sistemos našumą, nesumažinant atsparumo gedimams. Horizontaliam mastelio keitimui LETOGRAF sistema suteikia daugybę galimybių.
Visų pirma, tai yra apkrovos mastelio keitimas dėl Enterprise Cache Protocol (ECP, paskirstytos talpyklos protokolo), protokolo, naudojamo InterSystems Caché DBVS. ECP pranašumas yra novatoriškas požiūris į duomenų kaupimą talpykloje. Viduje šio protokolo vartotojų procesai, kurie veikia DBVS taikomųjų programų serveriuose (arba ECP klientuose) ir aptarnauja užklausas, gauna prieigą prie vietinės neseniai naudotų duomenų talpyklos. Ir tik tuo atveju, jei šių duomenų nepakanka, ECP klientas pasiekia duomenų bazę. Tai atliekama naudojant ECP protokolą automatinis valdymas Talpykla: dažniausiai pasiekiami duomenys saugomi talpykloje, o dažnai atnaujinami duomenys periodiškai kartojami, užtikrinant duomenų vientisumą ir teisingumą visuose ECP klientuose. Šiuo atveju vidinis InterSystems Caché algoritmas daro prielaidą, kad duomenų bazės yra sinchronizuojamos tarp ECP kliento ir ECP serverio.
Tiesą sakant, Caché DBVS technologijų naudojimas leidžia lengvai ir greitai padidinti apkrovą tarp taikomųjų programų serverių, taip užtikrinant didelio vartotojų skaičiaus prisijungimą prie vieno duomenų bazės serverio naudojant ECP protokolą.
Kadangi konkretaus vartotojo prašoma informacija gali būti naudojama keliems ECP klientams, būtina trumpam blokuoti duomenis, greitai atlikti operacijas neatliekant vidinių skaičiavimų. Ir mes tai sėkmingai įgyvendinome. Ši technologija leidžia efektyviai išplėsti sistemos mastelį, kai naudojame vieną duomenų bazės serverį ir kelis serverius, kuriuose veikia vartotojo procesai. Caché DBVS technologinė savybė yra ta, kad ji palaiko operacijų teisingumą viename ECP serveryje, nepriklausomai nuo prie jo prijungtų ECP klientų skaičiaus. Tuo atveju, kai turime vieną ECP serverį ir daug ECP klientų, ši problema puikiai išspręsta, nes visos operacijos vyksta viename duomenų bazės serveryje.
Patirtis rodo, kad net ir labai apkrautose sistemose visada galima aiškiai padalyti duomenis tarp duomenų bazių serverių pagal tam tikras charakteristikas. Pavyzdžiui, jei į valdą yra sujungtos kelios organizacijos, vargu ar vieno struktūrinio padalinio naudotojai kada nors reikalaus duomenų, susijusių su kitu padaliniu. Tai leidžia algoritmo lygmeniu atskirti ir saugoti tokius duomenis skirtinguose duomenų bazių serveriuose, taip padidinant horizontalaus mastelio keitimo galimybę.
EDMS LETOGRAF diegia dalijimosi mechanizmą, kurio dėka mes sistemos nustatymų lygyje (nenaudojant programavimo) leidžiame aprašyti pačių duomenų paskirstymo per skirtingus duomenų bazių serverius taisykles ir principus. Nepaisant to, kad duomenų bazės struktūros požiūriu kiekviename serveryje saugoma informacija yra vienoda, pati informacija iš esmės skiriasi priklausomai nuo organizacijos ar bet kokių kitų konkrečiai užduočiai reikšmingų savybių. Naudojant sharding technologiją, galima pasiekti, kad 95-99% atvejų vartotojai dirbs tik su savo „duomenų dalimi“ ir nereikės per seansą prieiti prie skirtingų duomenų bazių serverių.
LETOGRAF EDMS mastelio keitimo galimybes taip pat įtakoja tai, kad duomenys gali būti tvarkomi skirtingai. Pavyzdžiui, dokumentus galima keisti (net ir tuos, kurie buvo sukurti prieš keletą metų), tačiau įrašai gali būti įtraukti tik į vartotojo veiklos žurnalą (negalima ištrinti ar pakeisti nei vieno įrašo). LETOGRAF EDMS naudojami mechanizmai leidžia dar labiau padidinti sistemos našumą ir pagerinti mastelį, išlaikant tokius žurnalus atskiruose duomenų bazių serveriuose – tiek vieno serverio, tiek kelių serverių konfigūracijų atveju. Šiuo metodu siekiama sumažinti pagrindinių duomenų bazių serverių apkrovą.
Panaši situacija susiklosto ir su turiniu (EDMS „informaciniu turiniu“). Kadangi LETOGRAF sistema veikia su dideliu turinio kiekiu – terabaitais duomenų, milijonais failų ir dokumentų – pagrįstai galima manyti, kad į sistemą patenkantis turinys jokiomis aplinkybėmis neturėtų būti pažeistas. Todėl taip pat perkeliame failų saugyklą į atskirus duomenų bazių serverius ir taip suteikiame papildomą horizontalų mastelį.
Priekinės dalies programinė įranga
LETOGRAF EDMS kaip priekinę dalį naudoja Apache ir HAProxy. HAProxy yra atsakinga už apkrovos balansavimą tarp Apache žiniatinklio serverių. HAProxy, kaip parodė sistemos patirtis, įsitvirtino kaip efektyviausias sprendimas, galintis užtikrinti didelį vartotojų skaičių ir būtiną gedimų tolerancijos kontrolę.
Kai vartotojas atidaro naršyklę ir prisijungia prie sistemos, HAProxy „paskirsto“ ją vienam iš taikomųjų programų serverių. Be to, visos užklausos, gautos iš šio vartotojo, bus siunčiamos į tą patį programų serverį tuo pačiu procesu.
Išbandėme įvairias sistemas ir bandymai parodė, kad HAProxy yra efektyviausias apkrovos balansavimo įrankis, užtikrinantis tolygų vartotojų pasiskirstymą laisvuose programų serverių lizduose. HAProxy turi visus reikalingus mechanizmus, kad būtų galima sekti kiekvieno taikomųjų programų serverio būseną ir neplatinti naujas eismasį programų serverį, kuris dėl kokios nors priežasties sugedo. Be to, HAProxy papildomai suteikia daugybę galimybių, susijusių su statinių (nekeičiamų vartotojo darbo metu) duomenų kaupimu talpykloje – pavyzdžiui, stilių, piktogramų ir pan. – tai leidžia tvarkyti sąsają.
Projekto įgyvendinimo pavyzdys
LETOGRAF architektūra leidžia pasiekti reikšmingų rezultatų mažinant reakcijos laiką ir didinant sistemos našumą. Vykdant vieną iš mūsų projektų, EDMS saugoma 23,5 TB duomenų. Iš jų 14,7 TB (63 %) yra srautai (prie kortelių pridedami failai), 3,5 TB (15 %) yra ataskaitų formos, pvz., ataskaitų lentelės, kurios generuojamos asinchroniniu režimu ir gali būti paleidžiamos pagal tvarkaraštį ir vartotojo užklausą ir pateikti suvestinę lentelę, kurioje bet kokie duomenys gali būti detalizuoti iki objekto. Dar 1,6 TB (7 proc.) yra vartotojo operacijų žurnalas, o likusi dalis (16 proc.) – kortelių duomenys ir indeksai.
Šioje sistemoje dirba daugiau nei 11 tūkstančių vartotojų, iš jų 2 tūkstančiai dirba vienu metu, o piko dienomis EDMS vienu metu dirbančių darbuotojų skaičius viršija 3 tūkst.. Žurnalo įrašų skaičius jau viršijo 5,5 mlrd., o registracijos kortelių skaičius pasiekė beveik pusę milijardo.
Šiame projekte kaip duomenų bazės serveris yra įdiegtas dviejų grupių klasteris fiziniai serveriai su trimis DBVS instaliacijomis, taip pat atsarginiu serveriu. Dešimt taikomųjų programų serverių (ir viena atsarginė kopija) apdoroja vartotojo sesijas ir teikia asinchronines ataskaitas. 2 HAProxy serveriai veikia kaip balansai. Iškilus problemoms su vienu iš serverių, jo IP adresas automatiškai perkeliamas į kitą serverį. Taip pat yra failų indeksavimo serveris ir atpažinimo serveris (suteikiantis nuskaitytų popierinių dokumentų teksto atpažinimą dedant į sistemą elektroninius vaizdus).
Santrauka
EDMS LETOGRAF suteikia daugybę skirtingų mastelio keitimo mechanizmų. Siūlome tam tikrą pyragą, kuris yra paremtas serveriu (fiziniu arba virtualiu), kuriame įdiegta operacinė sistema. Viršuje yra InterSystems Caché DBVS, kurios viduje yra platformos kodas. Ir jau virš jo yra LETOGRAF sistemos nustatymai, kurių dėka EDMS yra pilnai sukonfigūruotas. Ir toks pyragas dedamas ant kiekvieno serverio. Dėl pasirinktų konfigūracijų serveriai yra tam tikru būdu sujungti vienas su kitu. Ir paskutinis sluoksnis yra HAProxy, kuris paskirsto vartotojų užklausas tarp serverių. Ši architektūra leidžia mums palaikyti mastelio keitimą ir pateikti visus būtinus stebėjimo mechanizmus. Dėl to galutiniai vartotojai gauna greitai veikiančią EDMS, o IT specialistai – vieningą sistemą, kurią lengva valdyti ir prižiūrėti, be daugybės komponentų, kurie, esant labai apkrautoms programoms, turi būti nuolat stebimi ir administruojami. . Be to, atsižvelgiant į kintančius organizacijos poreikius, LETOGRAF EDMS gali būti lengvai perkonfigūruojamas pridedant naujų serverių ar disko galimybių.
Ši medžiaga yra privatus Club.CNews bendruomenės nario įrašas.
CNews redaktoriai neatsako už jo turinį.
Iki 2012 m. pabaigos daugiau nei 50 % programų, veikiančių x86 platformoje, buvo virtualizuotos. Tačiau tik 20 % verslui svarbių programų yra virtualizuotos.
Ar taip yra todėl, kad IT skyriai nepasitiki virtualizacijos platformomis? Ar jie mano, kad virtualizacijos platformos nėra pakankamai stabilios, kad palaikytų itin svarbias programas?
Per pastaruosius 10 metų VMware įrodė, kad virtualizavimas yra realybė, ir iš tikrųjų virtualizuotos programos dažnai yra stabilesnės, kai jos veikia VMware valdomoje infrastruktūroje.
Taigi, jei pasitikėjimas ar stabilumas nėra problema, kokia yra priežastis, kodėl IT skyriai dar nevirtualizavo likusių programų?
Sumažinti mastelį
Mastelio sumažinimas arba horizontalus mastelio keitimas – naujų išteklių įtraukimas į infrastruktūrą, pavyzdžiui, serverių klasteryje.
Kainos ir toliau mažėja, o našumas ir toliau didėja, pigūs (plačiai vartojami) serveriai idealus sprendimas horizontaliam mastelio keitimui ir gali būti surinkti į dideles grupes, kad būtų galima sutelkti skaičiavimo išteklius.
Pastaruosius septynerius metus VMware infrastruktūros architektai meldžiasi už horizontalų mastelį. Kai kurie gali ginčytis dėl šio konkretaus požiūrio, tačiau jis taip pat turi savų niuansų ir viskas priklauso nuo verslo reikalavimų. Horizontaliojo mastelio keitimo pranašumas yra tas, kad prekių serveriai yra pigūs, o jei serveris sugenda, tai paveikia nedidelį skaičių VM. Minusas – didesnės vSphere licencijų sąnaudos, dideli reikalavimai duomenų centro erdvei ir dažniausiai tokie prekiniai serveriai neturi didelių skaičiavimo resursų.
Proporcingai didinti
Vertikalus mastelio keitimas yra skaičiavimo išteklių pridėjimas prie jau naudojamo serverio. Paprastai tai yra procesoriai arba RAM.
Paprastai tokie serveriai yra gana galingi – palaiko 4 procesorius ir 512 GB atminties. Be to, yra sistemų su 8 procesoriais ir 1TB atmintimi, o kai kuriems pasiseka pamatyti net 16 procesorių serverius su 4TB atmintimi. Ir ne, tai nėra pagrindiniai kompiuteriai ar kažkas panašaus, tai serveriai, pagrįsti klasikine x86 architektūra.
Perėjimas prie antrosios virtualizacijos bangos, kuri suteikia lankstumo, kurį ši technologija suteikia verslui svarbioms programoms, daro didžiulį spaudimą šiandien naudojamai VMware infrastruktūrai dėl šių problemų:
- Nepakankamos mastelio keitimo galimybės. Intensyviai skaičiuojami darbo krūviai yra iššūkis dėl riboto resursų kiekio naudojant pigius prekių serverius.
- Nepakankamas patikimumas. Prekių įranga ar techninė įranga, naudojanti tokius komponentus, gali būti mažiau patikima. Patikimumo problemą galima išspręsti naudojant funkcijas, kurias aptarsiu kituose straipsniuose.
- Didėjantis valdymo sudėtingumas ir didėjančios veiklos sąnaudos. Paprasčiau valdyti 100 serverių, o ne 1000 ir dėl to 10 serverių lengviau valdyti nei 100. Tas pats pasakytina ir apie eksploatacines išlaidas – 10 serverių išlaikymas yra daug pigesnis nei 100.
Išleidus vSphere 5, vienai VM prieinamų išteklių skaičius išaugo 4 kartus.
Ir išleidus vSphere 5.1, siaubingos VM gali tapti dar siaubingesnės.
Kad vSphere 5.1 galėtų paleisti monstrišką VM, planuotojas turi turėti ir suplanuoti gijas, kad jos veiktų 64 fiziniuose procesoriuose. Nėra daug serverių, galinčių palaikyti tiek branduolių, o serverių, palaikančių 16 lizdų ir 160 branduolių, yra dar mažiau.
Serverio vertikalus mastelio keitimas yra dviejų tipų: beklijinis ir klijuojamas. Šie žodžiai į rusų kalbą verčiami taip: atitinkamai be integruojančių technologijų ir su integruojančiomis technologijomis.
Be klijų architektūra
Ši architektūra sukūrė Intel ir pristatė Intel Xeon E7.
Ryšiui tarp I/O įrenginių, tinklo sąsajos o procesoriai naudoja specialiai sukurtą QPI magistralę.
Serveriuose su 4 procesoriais jie visi yra tiesiogiai sujungti vienas su kitu per šią magistralę. „Glueless“ procesorius naudoja vieną iš kanalų procesoriaus prijungimui prie I/O sąsajų, o kitus tris – prie gretimų procesorių.
8 procesorių serveryje kiekvienas procesorius yra tiesiogiai prijungtas prie trijų gretimų, o per kitą procesorių – su kitais keturiais.
Šios architektūros pranašumai:
- Serverio gamintojui nereikia specialaus tobulinimo ar specializacijos
- Bet kuris serverių gamintojas gali pagaminti 8 procesorių serverius
- Sumažėja 4 ir 8 procesorių serverių kaina
- Bendros nuosavybės išlaidos didėja, kai padidinate mastelį
- Architektūra apribota iki 8 procesorių serverių
- Sunku išlaikyti talpyklos vientisumą, nes didėja lizdai
- Netiesinis produktyvumo augimas
- Kainos ir našumo santykis krenta
- Neoptimalus našumas naudojant dideles VM
- Iki 65% magistralės pralaidumo išleidžiama kalbantiesiems QPI protokolo transliacijoms
Pagrindinės programos, kurių veikimas nukenčia dėl QPI protokolo trūkumų, yra Java programos, didelės duomenų bazės ir delsai jautrios programos.
Vertikalaus mastelio keitimo rezultatas turi būti toks, kad nebūtų kliūties, kitaip architektūra netenka prasmės. Taigi produktyvumo didėjimo tiesiškumas turi atitikti išteklių papildymų tiesiškumą.
Klijuota architektūra
Norėdami išspręsti aukščiau aprašytas problemas, techninės įrangos kūrėjai sukūrė klijuotą architektūrą. Ši architektūra naudoja išorinį mazgo valdiklį QPI salelių – procesorių grupių – sujungimui organizuoti.
„Intel QPI“ siūlo specialų keičiamo dydžio sprendimą – išorinius mazgų valdiklius (arba XNC), praktinis įgyvendinimas kurį sukūrė trečiųjų šalių OEM įmonės. Išorinis mazgo valdiklis, naudojamas pradedant Intel Xeon E7-4800, su įmontuotu atminties valdikliu, taip pat apima Cache Coherent Non-Uniform Memory Access (ccNUMA) sistemą, kurios užduotis yra stebėti duomenų tinkamumą. kiekvienoje procesoriaus laikinosios atminties eilutėje.
Vėlavimai tarp procesoriaus ir atminties ccNUMA priklauso nuo dviejų komponentų vietos vienas kito atžvilgiu, todėl XNC valdikliai tampa svarbiu serverio komponentu ir labai nedaugelis serverių gamintojų gali sukurti serverius, kurių mastelis būtų didesnis.
Vieningos informacinės sistemos paprastai yra įdiegtos atskirame asmeniniame kompiuteryje (tinklas nenaudojamas). Tokioje sistemoje gali būti kelios paprastos programos, sujungtos bendru informacijos fondu, ir ji skirta darbui vienam vartotojui arba vartotojų grupei, besidalijančiai vienu darbo vieta. Tokios aplikacijos kuriamos naudojant vadinamuosius darbalaukis, arba vietinis, duomenų bazių valdymo sistemos (DBVS). Tarp vietinių DBVS žinomiausios yra Clarion, Clipper, FoxPro, Paradox, dBase ir Microsoft Access.
Grupinės informacinės sistemos yra orientuoti į kolektyvinį darbo grupės narių naudojimąsi informacija ir dažniausiai yra kuriami vietinio kompiuterių tinklo pagrindu. Kuriant tokias programas, duomenų bazių serveriai (dar vadinami SQL serveriais) naudojami darbo grupėms. Yra gana daug įvairių SQL serverių, tiek komercinių, tiek laisvai platinamų. Tarp jų žinomiausi duomenų bazių serveriai yra „Oracle“, „DB2“, „Microsoft“. SQL serveris, InterBase, Sybase, Informix.
Įmonės informacinės sistemos yra sistemų, skirtų darbo grupėms, kūrimas, jie yra orientuoti didelės įmonės ir gali palaikyti geografiškai išsklaidytus mazgus ar tinklus. Iš esmės jie turi kelių lygių hierarchinę struktūrą. Tokioms sistemoms būdinga kliento-serverio architektūra su serverių specializacija arba kelių lygių architektūra. Kuriant tokias sistemas galima naudoti tuos pačius duomenų bazių serverius, kaip ir kuriant grupines informacines sistemas. Tačiau didelėse informacinėse sistemose plačiausiai naudojami serveriai yra Oracle, DB2 ir Microsoft SQL Server. Grupės ir įmonių sistemoms ženkliai padidinami patikimo veikimo ir duomenų saugumo reikalavimai. Šios savybės suteikiamos išlaikant duomenų, nuorodų ir operacijų duomenų bazių serveriuose vientisumą.
Centralizuota arba paskirstyta duomenų bazė.
Dizaino elementaiŽiniatinklis- šiuo metu orientuotos sistemos
Scrum yra principų rinkinys, kuriuo remiantis grindžiamas kūrimo procesas, leidžiantis per griežtai nustatytą trumpą laiką ( sprintai nuo 2 iki 4 savaičių) galutiniam vartotojui suteikti veikiančią programinę įrangą su naujomis funkcijomis, kurios turi didžiausią prioritetą. Programinės įrangos galimybės, skirtos diegti kitame sprinte, nustatomos sprinto pradžioje planavimo etape ir negali keistis per visą jo trukmę. Tuo pačiu griežtai fiksuota trumpa sprinto trukmė suteikia kūrimo procesui nuspėjamumo ir lankstumo.
ORM yra programavimo technologija, susiejanti duomenų bazes su objektinių programavimo kalbų sąvokomis ir sukurianti „virtualiųjų objektų duomenų bazę“.
Problema: Objektinio programavimo metu programos objektai reiškia objektus realiame pasaulyje. Problemos esmė – tokius objektus paversti tokia forma, kurioje jie galėtų būti saugomi failuose ar duomenų bazėse ir kurią vėliau būtų galima lengvai atkurti, išsaugant objektų savybes ir ryšius tarp jų. Šie objektai vadinami „saugomais“ objektais. atkakliai). Istoriškai buvo keli šios problemos sprendimo būdai.
Modelis-vaizdas-valdiklis- programinės įrangos architektūra, kurioje taikomosios programos duomenų modelis, vartotojo sąsaja ir valdymo logika yra atskirti į tris atskirus komponentus, kad vieno komponento modifikavimas turėtų minimalų poveikį kitiems komponentams.
Mastelio keitimas - įrenginio galimybė padidinti savo
galimybės
didinant funkcinių blokų skaičių,
atlieka vienas ir
tos pačios užduotys.
Glossary.ru
Paprastai žmonės pradeda galvoti apie mastelio keitimą
serveris negali susidoroti su jam priskirtu darbu. Su kuo jis tiksliai ne?
susidoroti? Bet kurio žiniatinklio serverio veikimas iš esmės priklauso nuo pagrindų
Kompiuterių veikla yra duomenų apdorojimas. Atsakymas į HTTP (ar bet kurią kitą) užklausą
apima tam tikrų operacijų su kai kuriais duomenimis atlikimą. Atitinkamai,
turime du pagrindinius subjektus – duomenis (būdingus jų apimtimi) ir
skaičiavimai (pasižymi sudėtingumu). Serveris gali nesugebėti su juo susidoroti
dirbti dėl didelio duomenų kiekio (gali fiziškai netilpti
serveris) arba dėl didelės skaičiavimo apkrovos. Kalba čia yra
žinoma, apie bendrą apkrovą – vienos užklausos apdorojimas gali būti sudėtingas
yra mažas, tačiau didelis jų skaičius gali užgožti serverį.
Mes daugiausia kalbėsime apie mastelio keitimą naudodami pavyzdį
tipiškas augantis interneto projektas, tačiau tinka ir čia aprašyti principai
kitos taikymo sritys. Pirmiausia pažvelgsime į projekto architektūrą ir paprastą
paskirstyti jo komponentus keliuose serveriuose, o tada apie tai pakalbėsime
skaičiavimo ir duomenų mastelio keitimas.
Tipiška svetainės architektūra
Įprastos svetainės gyvenimas prasideda nuo labai paprastos architektūros
- tai vienas žiniatinklio serveris (dažniausiai „Apache“ atlieka savo vaidmenį),
kuri tvarko visus HTTP užklausų aptarnavimo darbus,
gavo iš lankytojų. Tada jis suteikia klientams vadinamąją „statiką“.
serverio diske yra failų, kurių nereikia apdoroti: nuotraukos (gif,
jpg, png), stiliaus lapus (css), kliento scenarijus (js, swf). Tas pats serveris
atsako į užklausas, kurios reikalauja skaičiavimų – dažniausiai formuojasi
html puslapių, nors kartais vaizdai ir kiti dokumentai sukuriami skrendant.
Dažniausiai atsakymus į tokius prašymus generuoja scenarijai, parašyti PHP,
perl ar kitomis kalbomis.
Tokios paprastos darbo schemos trūkumas yra tas, kad skiriasi
užklausų pobūdis (failų įkėlimas iš disko ir scenarijų skaičiavimas)
apdorojamas to paties žiniatinklio serverio. Reikalingos skaičiavimo užklausos
serverio atmintyje saugokite daug informacijos (scenarijų kalbos vertėjas,
patys scenarijai, duomenys, su kuriais jie dirba) ir gali užimti daug
skaičiavimo ištekliai. Priešingai, norint išleisti statinius duomenis, reikia nedaug išteklių
procesorius, bet gali užtrukti ilgai, jei klientas turi mažai
ryšio greitis. Vidinis Apache serverio dizainas daro prielaidą, kad kiekvienas
ryšys tvarkomas atskiru procesu. Tai patogu paleisti scenarijus,
tačiau nėra optimalus apdorojimui paprastos užklausos. Pasirodo, kad sunkus (nuo
scenarijai ir kiti duomenys) „Apache“ procesai daug laiko praleidžia laukdami (pirmiausia gavus
užklausą, tada siunčiant atsakymą), eikvojama serverio atmintis.
Šios problemos sprendimas yra paskirstyti apdorojimo darbus
prašymai tarp dviejų skirtingos programos- t.y. skirstymas į frontend ir
backend Lengvas frontend serveris atlieka statinio turinio ir likusios dalies aptarnavimo užduotis
užklausos nukreipiamos (proxy) į užpakalinę programą, kurioje atliekamas formavimas
puslapių. Lėtųjų klientų laukimu taip pat rūpinasi frontend, o jei ir naudoja
multipleksavimas (kai vienas procesas aptarnauja kelis klientus - taigi
dirbti, pavyzdžiui, nginx arba lighttpd), tada laukti praktiškai nieko
išlaidas.
Tarp kitų svetainės komponentų reikėtų pažymėti duomenų bazę
kuriame paprastai saugomi pagrindiniai sistemos duomenys – populiariausi čia yra
nemokamos DBVS MySQL ir PostgreSQL. Saugykla dažnai skiriama atskirai
dvejetainiai failai, kuriuose yra paveikslėlių (pavyzdžiui, straipsnių iliustracijos
svetainę, avatarus ir naudotojų nuotraukas) ar kitus failus.
Taigi, mes gavome architektūros schemą, kurią sudaro
keli komponentai.
Paprastai svetainės gyvavimo pradžioje visi architektūros komponentai
yra tame pačiame serveryje. Jei jis nustos susidoroti su apkrova, tada
Yra paprastas sprendimas – lengviausia atskiriamas dalis perkelti į kitą
serveris. Paprasčiausias būdas pradėti nuo duomenų bazės – perkelti ją į atskirą serverį ir
pakeisti prieigos duomenis scenarijuose. Beje, šiuo metu mes susiduriame su
tinkamo kodo architektūros svarba. Jei dirbate su duomenų baze
pateikta atskiras modulis, bendras visai svetainei – tada pataisykite parametrus
jungtys bus lengvos.
Taip pat aiškūs būdai, kaip toliau atskirti komponentus – pavyzdžiui, galite perkelti sąsają į atskirą serverį. Bet dažniausiai frontend
reikalauja nedaug sistemos išteklių ir šiame etape jo pašalinimas neduos reikšmingų rezultatų
produktyvumo padidėjimas. Dažniausiai svetainę riboja našumas.
scenarijai – atsakymo generavimas (html puslapis) užtrunka per ilgai.
Todėl kitas žingsnis paprastai yra vidinio serverio mastelio keitimas.
Skaičiavimo paskirstymas
Tipiška situacija augančiai svetainei – duomenų bazė jau yra
perkeltas į atskirą mašiną, padalijimas į frontend ir backend baigtas,
tačiau srautas ir toliau didėja, o užpakalinė programa neturi laiko apdoroti
prašymus. Tai reiškia, kad turime paskirstyti skaičiavimus keliems
serveriai. Tai padaryti paprasta – tiesiog nusipirkite antrą serverį ir įdiekite jį
Jame yra programų ir scenarijų, reikalingų užpakalinei programai veikti.
Po to turite įsitikinti, kad vartotojų užklausos yra paskirstytos
(subalansuotas) tarp gaunamų serverių. APIE įvairiais būdais balansavimas
bus aptarta toliau, tačiau šiuo metu pažymime, kad tai paprastai atlieka priekinė dalis,
kuris sukonfigūruotas taip, kad tolygiai paskirstytų užklausas tarp
serveriai.
Svarbu, kad visi vidiniai serveriai veiktų tinkamai
atsakyti į prašymus. Tam paprastai reikia dirbti su kiekvienu iš jų
tą patį naujausių duomenų rinkinį. Jei visą informaciją saugosime viename
duomenų bazę, tada pati DBVS pateiks dalijimasis ir duomenų nuoseklumą.
Jei kai kurie duomenys saugomi vietoje serveryje (pavyzdžiui, php sesijos
klientas), tuomet turėtumėte pagalvoti apie jų perkėlimą į bendrą saugyklą ar daugiau
sudėtingas užklausų paskirstymo algoritmas.
Ne tik darbas gali būti paskirstytas keliuose serveriuose
scenarijus, bet ir duomenų bazės atliekamus skaičiavimus. Jei DBVS atlieka daug
sudėtingų užklausų, užimančių serverio procesoriaus laiką, galite sukurti keletą
duomenų bazės kopijos skirtinguose serveriuose. Tai iškelia sinchronizavimo problemą
duomenys, kai keičiasi, ir čia taikomi keli metodai.
- Sinchronizavimas taikymo lygiu. Šiuo atveju mūsų
scenarijai savarankiškai rašo pakeitimus visose duomenų bazės kopijose (ir patys neša
atsakomybę už duomenų teisingumą). Nėra geriausias variantas nes jis
reikalauja kruopštaus įgyvendinimo ir yra labai atsparus klaidoms. - Replikacija- tai yra automatinis replikavimas
viename serveryje padaryti pakeitimai turi įtakos visiems kitiems serveriams. Paprastai kai
Naudojant replikaciją, pakeitimai visada įrašomi į tą patį serverį – jis vadinamas master, o likusios kopijos vadinamos vergais. Dauguma DBVS turi
integruoti arba išoriniai replikacijos organizavimo įrankiai. Išskirti
sinchroninis replikavimas – tokiu atveju lauks prašymas pakeisti duomenis
kol duomenys bus nukopijuoti į visus serverius, ir tik tada jis bus sėkmingai užbaigtas – ir asinchroniškai – tokiu atveju pakeitimai nukopijuojami į pagalbinius serverius iš
vėluoja, bet rašymo užklausa baigiama greičiau. - Multi-master replikacija. Šis požiūris yra panašus
ankstesnįjį, bet čia galime keisti duomenis neprisijungę
vienam konkrečiam serveriui, bet į bet kurią duomenų bazės kopiją. Tuo pačiu metu keičiasi
sinchroniškai arba asinchroniškai bus perkelti į kitas kopijas. Kartais ši schema vadinama
terminas „duomenų bazių klasteris“.
Yra įvairių variantų, kaip paskirstyti sistemą tarp serverių.
Pavyzdžiui, mes galime turėti vieną duomenų bazės serverį ir keletą užpakalinių sistemų (labai
tipinė schema), arba atvirkščiai – viena backend ir kelios duomenų bazės. O kas, jei padidintume mastelį
tiek vidinį serverį, tiek duomenų bazę, tada galite sujungti pagrindinę programą ir duomenų bazės kopiją
vienas automobilis. Bet kokiu atveju, kai tik turėsime kelias kopijas
bet kuriame serveryje, kyla klausimas, kaip teisingai paskirstyti tarp jų
apkrova.
Balansavimo metodai
Sukurkime kelis serverius (bet kokiam tikslui – http, duomenų bazei ir pan.), kurių kiekvienas gali apdoroti užklausas. Prieš
susiduriame su užduotimi, kaip paskirstyti darbus tarp jų, kaip išsiaiškinti kokius
serveris atsiųsti užklausą? Yra du pagrindiniai užklausų platinimo būdai.
- Balansavimo vienetas. Tokiu atveju klientas siunčia užklausą vienam
jam žinomą fiksuotą serverį ir jis jau peradresuoja užklausą į vieną iš
veikiančius serverius. Tipiškas pavyzdys yra svetainė su viena sąsaja ir keliomis
backend serveriai, kuriems užklausos perduodamos tarpiniu serveriu. Tačiau „klientas“ gali
būti mūsų sistemoje – pavyzdžiui, scenarijus gali išsiųsti užklausą
į duomenų bazės tarpinį serverį, kuris perduos užklausą vienam iš DBVS serverių.
Pats balansavimo mazgas gali veikti tiek atskirame serveryje, tiek viename
iš veikiančių serverių.Šio požiūrio pranašumai yra
kad klientui nereikia nieko žinoti apie vidinę sistemos struktūrą – apie kiekį
serverių, apie jų adresus ir funkcijas – tik
balansuotojas Tačiau trūkumas yra tas, kad balansavimo vienetas yra vienas
sistemos gedimo taškas - jei ji sugenda, bus visa sistema
neveikiantis. Be to, esant didelei apkrovai, balansyras gali tiesiog sustoti
susidoroti su savo darbu, todėl šis metodas ne visada taikomas. - Kliento pusės balansavimas. Jei norime išvengti
vienas gedimo taškas, yra alternatyvus variantas – patikėti serverio pasirinkimą
pačiam klientui. Tokiu atveju klientas turi žinoti apie vidinę mūsų struktūrą
sistemos, kad būtų galima teisingai pasirinkti, su kuriuo serveriu susisiekti.
Neabejotinas pranašumas yra gedimo taško nebuvimas - jei vienas iš
serveriuose klientas galės susisiekti su kitais. Tačiau kaina už tai yra
sudėtingesnė kliento logika ir mažesnis balansavimo lankstumas.
Žinoma, yra ir šių metodų derinių. Pavyzdžiui,
yra pagrįstas toks gerai žinomas apkrovos paskirstymo metodas, kaip DNS balansavimas
kad nustatant svetainės IP adresą klientui suteikiamas
vieno iš kelių identiškų serverių adresas. Taigi DNS veikia kaip a
balansavimo mazgo, iš kurio klientas gauna „paskirstymą“, vaidmuo. Tačiau
pati DNS serverių struktūra reiškia, kad nėra gedimo vietos dėl
dubliavimas - tai yra, dviejų metodų pranašumai yra sujungti. Žinoma, šis
Balansavimo metodas turi ir trūkumų – pavyzdžiui, tokią sistemą sunku dinamiškai
atstatyti.
Darbas su svetaine paprastai neapsiriboja vienu prašymu.
Todėl projektuojant svarbu suprasti, ar galima atlikti nuoseklias užklausas
klientas turi būti tinkamai apdorotas skirtinguose serveriuose, arba klientas turi būti tinkamai apdorotas
susieta su vienu serveriu dirbant su svetaine. Tai ypač svarbu, jei
svetainėje saugoma laikina informacija apie vartotojo seansą (š
Tokiu atveju galimas ir nemokamas platinimas – bet tuomet būtina saugoti
seansų (visiems serveriams bendra saugykla). „Pririšti“ lankytoją
galite nurodyti konkretų serverį pagal jo IP adresą (tačiau jis gali keistis),
arba slapuku (kuriame iš anksto įrašytas serverio identifikatorius), arba net
tiesiog nukreipiant jį į norimą domeną.
Kita vertus, kompiuterių serveriai gali neturėti lygių teisių.
Kai kuriais atvejais pravartu elgtis priešingai, skirti atskirą serverį
apdoroti vieno tipo užklausas ir gauti vertikalų padalijimą
funkcijas. Tada klientas arba balansavimo mazgas pasirinks serverį
priklausomai nuo gauto prašymo tipo. Šis požiūris leidžia mums atsiskirti
svarbūs (arba atvirkščiai, ne kritiški, o sunkūs) kitų prašymai.
Duomenų paskirstymas
Mes išmokome paskirstyti skaičiavimus, todėl didelis
lankomumas mums nėra problema. Tačiau duomenų apimtys ir toliau auga,
juos saugoti ir apdoroti darosi vis sunkiau – tai reiškia, kad laikas kurti
paskirstyta duomenų saugykla. Tokiu atveju nebeturėsime vieno ar
keli serveriai, kuriuose yra visa duomenų bazės kopija. Vietoj to, duomenys
bus paskirstytas skirtinguose serveriuose. Kokios platinimo schemos galimos?
- Vertikalus pasiskirstymas(vertikalus skaidymas) – paprasčiausiu atveju
reiškia atskirų duomenų bazės lentelių perkėlimą į kitą serverį. At
Tokiu atveju turėsime pakeisti scenarijus, kad galėtume pasiekti skirtingus serverius
skirtingus duomenis. Limite kiekvieną lentelę galime saugoti atskirame serveryje
(nors praktiškai tai vargu ar bus naudinga). Akivaizdu, kad su šiuo
paskirstymas, prarandame galimybę atlikti SQL užklausas, kurios sujungia duomenis iš
dvi lentelės skirtinguose serveriuose. Jei reikia, galite įgyvendinti
logikos sujungimas programoje, tačiau ji nebus tokia efektyvi kaip DBVS.
Todėl, skaidydami duomenų bazę, turite išanalizuoti ryšius tarp lentelių,
paskirstyti kuo savarankiškesnes lenteles.Sudėtingesnis atvejis
vertikalus bazinis pasiskirstymas yra vienos lentelės išskaidymas, kai dalis
kai kurie jo stulpeliai patenka į vieną serverį, o kai kurie iš jų patenka į kitą. Ši technika
yra mažiau paplitęs, bet gali būti naudojamas, pavyzdžiui, atskirti mažas
ir dažnai atnaujinami duomenys iš didelio kiekio retai naudojamų duomenų. - Horizontalus paskirstymas(horizontalus skaidymas) – susideda iš
paskirstyti duomenis iš vienos lentelės keliuose serveriuose. Tiesą sakant, toliau
kiekvienas serveris sukuria vienodos struktūros lentelę ir saugo
tam tikra duomenų dalis. Duomenis serveriuose galite paskirstyti įvairiais būdais
kriterijai: pagal diapazoną (įrašai su id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, likusi dalis – į serverį B) arba pagal tam tikro lauko maišos reikšmę
įrašų. Horizontalus duomenų skaidymas leidžia saugoti neribotą kiekį
tačiau įrašų skaičius apsunkina pasirinkimą. Veiksmingiausias būdas pasirinkti
įrašus tik tada, kai žinoma, kuriame serveryje jie saugomi.
Norėdami pasirinkti tinkamą duomenų paskirstymo schemą, turite
atidžiai išanalizuoti duomenų bazės struktūrą. Esamos lentelės (ir galbūt
atskiri laukai) gali būti klasifikuojami pagal prieigos prie įrašų dažnumą, pagal dažnumą
atnaujinimai ir ryšiai (reikia pasirinkti iš kelių
lentelės).
Kaip minėta aukščiau, be duomenų bazės, svetainei dažnai reikia
dvejetainių failų saugykla. Paskirstytos failų saugojimo sistemos
(iš tikrųjų failų sistemos) galima suskirstyti į dvi klases.
- Darbas lygiu Operacinė sistema
. Be to, už
programomis, darbas su failais tokioje sistemoje niekuo nesiskiria nuo įprasto darbo su
failus. Keitimąsi informacija tarp serverių tvarko operacinė sistema.
Kaip tokių pavyzdžių failų sistemos galime pacituoti tai, kas jau seniai žinoma
NFS šeima arba mažiau žinoma, bet daugiau moderni sistema Blizgesys. - Įgyvendinta taikymo lygiu platinami
saugyklos reiškia, kad apsikeitimo informacija darbą atlieka pats
taikymas. Paprastai įdedamos darbo su saugykla funkcijos
atskira biblioteka. Vienas iš ryškiausių tokios saugyklos pavyzdžių yra MogileFS, sukurtas pagal
„LiveJournal“ kūrėjai. Kitas dažnas pavyzdys yra naudojimas
WebDAV protokolas ir jį palaikanti saugykla.
Pažymėtina, kad duomenų paskirstymas lemia ne tik
saugojimo, bet iš dalies ir apkrovos paskirstymo klausimas – kiekviename
Serveryje yra mažiau įrašų, todėl jie apdorojami greičiau.
Skaičiavimų ir duomenų paskirstymo metodų derinys leidžia kurti
potencialiai neribotai keičiamo dydžio architektūra, galinti dirbti su
bet koks duomenų kiekis ir bet kokia apkrova.
išvadas
Apibendrindami tai, kas pasakyta, suformuluosime išvadas trumpų tezių forma.
- Du pagrindiniai (ir susiję) mastelio keitimo iššūkiai yra skaičiavimo paskirstymas ir duomenų paskirstymas
- Įprasta svetainės architektūra apima vaidmenų atskyrimą ir
apima frontend, backend, duomenų bazę ir kartais failų saugyklą - Mažiems duomenų kiekiams ir didelėms apkrovoms naudokite
duomenų bazės atspindėjimas – sinchroninis arba asinchroninis replikavimas - Dideliems duomenų kiekiams būtina paskirstyti duomenų bazę – išskaidyti
jį vertikaliai arba horizontaliai - Dvejetainiai failai saugomi paskirstytose failų sistemose
(įdiegta OS lygiu arba programoje) - Balansavimas (užklausų paskirstymas) gali būti vienodas arba
padalintas pagal funkcionalumą; su balansavimo mazgu arba kliento pusėje - Tinkamas metodų derinys leis atlaikyti bet kokią apkrovą;)
Nuorodos
Galite tęsti šios temos studijas įdomiose svetainėse ir tinklaraščiuose anglų kalba.
