Arhitektuurne projekteerimine on seotud otsustusstrateegia valiku ja süsteemi modulariseerimisega. Lahendusstrateegia on mõeldud süsteemi kliendi- ja serveriosade ehitamisega seotud probleemide lahendamiseks ning kliendi ja serveri "liimimiseks" on vaja vahevara. Peamiste ehitusplokkide (moodulite) otsustamine sõltub vaid osaliselt valitud lahendusstrateegiast.

Klient ja server on loogilised mõisted. Klient on arvutusprotsess, mis esitab serveriprotsessile päringuid. Server on arvutuslik protsess, mis teenindab serveri päringuid. Tavaliselt töötavad kliendi- ja serveriprotsessid erinevates masinates, kuid samas masinas on võimalik juurutada ka klient/server-süsteem.

Tüüpilise stsenaariumi korral vastutab kliendiprotsess kasutaja ekraanil teabe kuvamise ja kasutaja algatatud sündmuste käsitlemise eest. Serveriprotsess on mis tahes arvutisõlm, millel on andmebaas, kust klientprotsess saab andmeid pärida.

Kliendi/serveri arhitektuuri saab laiendada, et see esindaks suvalist hajutatud süsteemi. Iga andmebaasiga arvutisõlm võib mõnes äritegevuses täita kliendi rolli ja mõnes muus toimingus serveri rolli. Selliste sõlmede ühendamine sidevõrgu kaudu loob hajutatud töötlemissüsteemi arhitektuuri, nagu on näidatud joonisel fig. 5.

Riis. 5 Hajutatud töötlemissüsteemi arhitektuur

Hajutatud töötlemissüsteemis pääseb klient juurde mis tahes arvule serveritele. Samas saab kliendile lubada korraga juurdepääsu ainult ühele serverile. See tähendab, et see ei pruugi olla võimeline kombineerima kahe või enama andmebaasiserveri andmeid ühes päringus. Võimaluse korral toetab arhitektuur hajutatud andmebaasisüsteemi.

Kolmetasandiline arhitektuur

Nagu kliendiprotsess ja serveriprotsess, on ka rakendusprotsess loogiline kontseptsioon, mida võib, kuid ei pruugi toetada selleks otstarbeks mõeldud riistvara. Rakendusloogika võib ühtviisi hästi töötada nii kliendi- kui ka serverisõlmes, s.t. saab manustada kliendi- või serveriprotsessi ja rakendada DLL-ina (Dynamic Link Library), API-na (Application Programming Interface), RPC-kõnedena (Remote Procedure Calls) jne.

Kui rakenduse loogika on koostatud koos kliendiga, siis räägitakse paksust kliendi arhitektuurist ("klient steroididel"). Kui see on koostatud serveriga, siis räägitakse õhukesest kliendi arhitektuurist ("klient" "nahk ja luud"). Võimalikud on ka vahepealsed arhitektuurid, milles rakendusloogika koostatakse osaliselt koos kliendiga ja osaliselt serveriga. Rakendusloogikat saab kasutada ka arvutussõlmede eraldamiseks, nagu on näidatud joonisel 1. 6.

Riis. 6 Kolmetasandiline arhitektuur

See on kolmetasandiline arhitektuur selle puhtaimal kujul. Selle parimad omadused hõlmavad suurt paindlikkust, laiendatavust, kasutaja sõltumatust, saadavust ja madalaid uuendamiskulusid. Kuid sellisel arhitektuuril võib olla kõrge algkulu ja lisaks võib sellel esineda mõningaid jõudlusprobleeme.

• Tõlge

Liitusin Uberiga kaks aastat tagasi mobiiliarendajana, kellel oli taustaarenduskogemus. Siin arendasin rakenduses maksefunktsioone ja kirjutasin selle käigus rakenduse enda ümber. Pärast seda siirdusin arendusjuhtkonda ja juhtisin meeskonda ise. Tänu sellele sain taustaprogrammi palju lähemalt tundma õppida, kuna minu meeskond vastutab paljude meie makseid võimaldavate taustasüsteemide eest.

Enne Uberis töötamist ei olnud mul hajutatud süsteemidega kogemusi. Sain traditsioonilise arvutiteaduse hariduse, mille järel töötasin tosin aastat täisstacki arenduses. Seega, kuigi ma võiksin joonistada erinevaid diagramme ja rääkida kompromissidest ( kompromissid) süsteemides ei saanud ma selleks ajaks piisavalt hästi aru ja ei tajunud jaotuse mõisteid - nagu näiteks järjepidevus ( järjepidevus), saadavus ( kättesaadavus) või idempotentsus ( idempotentsus).

Selles postituses käsitlen mõnda kontseptsiooni, mida mul oli vaja õppida ja ellu viia Uberi täna kasutatava suuremahulise, väga kättesaadava hajutatud maksesüsteemi loomisel. Tegemist on kuni mitme tuhande päringu sekundis koormusega süsteemiga, milles kriitiline maksefunktsionaalsus peab korrektselt töötama ka juhtudel, kui teatud süsteemiosad lakkavad töötamast.

Kas see on täielik nimekiri? Suure tõenäosusega ei. Samas, kui ma ise oleksin neid mõisteid varem tundma õppinud, oleks see mu elu palju lihtsamaks teinud.

Alustame siis SLA-de, järjepidevuse, andmete vastupidavuse, sõnumite püsivuse, idempotentsuse ja mõne muu teemaga, mida mul oli vaja uues töökohas õppida.

SLA

Suurtes süsteemides, mis töötlevad miljoneid sündmusi päevas, lähevad mõned asjad kindlasti valesti. Seetõttu on enne süsteemi planeerimisse sukeldumist kõige olulisem otsustada, mida "terve" süsteem meie jaoks tähendab. "Tervise" aste peaks olema midagi sellist Tegelikult saab mõõta. Levinud viis süsteemi "tervise" mõõtmiseks on SLA ( teenusetaseme lepingud). Siin on mõned levinumad SLA-d, millega olen praktikas kokku puutunud.

• Kättesaadavus: protsent ajast, mil teenus töötab. Kuigi on kiusatus saavutada 100% kättesaadavus, võib selle tulemuse saavutamine olla tõesti keeruline ja väga kulukas. Isegi suured ja kriitilised süsteemid, nagu VISA kaardivõrk, Gmail või Interneti-teenuse pakkujad, ei ole 100% kättesaadavad – aastatega kogunevad need seisakutesse kulunud sekundid, minutid või tunnid. Paljude süsteemide puhul loetakse kõrgeks saadavuseks neli üheksat (99,99% ehk umbes 50 minutit seisakuid aastas). Sellele tasemele jõudmiseks tuleb palju higistada.
• Täpsus: kas andmete kadumine või ebatäpsus on vastuvõetav? Kui jah, siis milline protsent on vastuvõetav? Maksesüsteemi puhul, millega ma töötasin, pidi see arv olema 100%, kuna andmeid ei olnud võimalik kaotada.
• Ribalaius/võimsus (võimsus): millist koormust peaks süsteem taluma? Seda mõõdikut väljendatakse tavaliselt taotlustes sekundis.
• Latentsus: kui kaua peaks süsteem reageerima? Kui kaua tuleks 95% ja 99% päringutest kätte toimetada? Sellistes süsteemides on tavaliselt paljud päringud "müra", nii et p95 ja p99 viivitused on reaalses maailmas praktilisemad.

Miks on suure maksesüsteemi loomisel SLA-sid vaja? Loome uue süsteemi olemasoleva asemele. Veendumaks, et teeme asju õigesti ja meie uus süsteem on eelkäijast "parem", kasutasime SLA-d, et määratleda oma ootused sellele. Juurdepääsetavus oli üks olulisemaid nõudeid. Kui meil oli eesmärk meeles, pidime nende eesmärkide saavutamiseks lahendama arhitektuuri kompromissid.

Horisontaalne ja vertikaalne skaleerimine

Kui meie vastloodud süsteemi kasutav äri kasvab, siis koormus sellele ainult suureneb. Ühel hetkel ei suuda olemasolev käitis edaspidise koormuse kasvuga toime tulla ja me peame tõstma kandevõimet. Kaks levinumat skaleerimisstrateegiat on vertikaalne või horisontaalne skaleerimine.

Horisontaalne skaleerimine tähendab rohkemate masinate (või sõlmede) lisamist süsteemi, et suurendada läbilaskevõimet ( mahutavus). Horisontaalne skaleerimine on kõige populaarsem viis hajutatud süsteemide skaleerimiseks.

Vertikaalne skaleerimine on sisuliselt "osta suurem/tugevam masin" – (virtuaalne) masin, millel on rohkem südamikke, parem töötlemisvõimsus ja rohkem mälu. Hajutatud süsteemide puhul on suurendamine tavaliselt vähem populaarne, kuna see võib olla kulukam kui horisontaalne suurendamine. Mõned tuntud suured saidid, nagu Stack Overflow, on aga edukalt vertikaalselt skaleeritud, et see koormus vastaks.

Miks on skaleerimisstrateegial mõtet, kui ehitate suurt maksesüsteemi? Otsustasime varakult, et ehitame horisontaalselt skaleeruva süsteemi. Kuigi vertikaalne skaleerimine on mõnel juhul vastuvõetav, oli meie maksesüsteem selleks hetkeks juba saavutanud oma prognoositud koormuse ja olime pessimistlikud eelduse suhtes, et üks ülikallis suurarvuti suudab selle koormusega toime tulla täna, rääkimata tulevikust. Peale selle olid meie meeskonnas mõned inimesed, kes töötasid suurte makseteenuse pakkujate heaks ja kellel oli halbu kogemusi vertikaalselt skaleerida isegi kõige võimsamates masinates, mida neil aastatel raha eest osta sai.

Järjepidevus

Mis tahes süsteemide kättesaadavus on oluline. Hajutatud süsteemid ehitatakse sageli masinatest, mille individuaalne saadavus on madalam kui kogu süsteemi saadavus. Olgu meie eesmärgiks ehitada süsteem 99,999% käideldusega (seisakuaeg on ligikaudu 5 minutit aastas). Kasutame masinaid/sõlmesid, mille käideldavus on keskmiselt 99,9% (seisakuaeg ca 8 tundi/aastas). Otsene viis meile vajaliku kättesaadavuse indikaatori saavutamiseks on lisada klastrisse veel mõned sellised masinad/sõlmed. Isegi kui mõned sõlmed on "maas", on teised jätkuvalt töös ja süsteemi üldine saadavus on kõrgem kui selle üksikute komponentide saadavus.

Järjepidevus on väga kättesaadavate süsteemide võtmeküsimus. Süsteem on järjepidev, kui kõik sõlmed näevad ja tagastavad samaaegselt samu andmeid. Erinevalt meie eelmisest mudelist, kui lisasime suurema kättesaadavuse saavutamiseks rohkem sõlmi, pole süsteemi järjepidevuse tagamine sugugi tühine. Veendumaks, et iga sõlm sisaldab sama teavet, peavad nad saatma üksteisele sõnumeid, et olla pidevalt sünkroonis. Samas ei pruugita nende üksteisele saadetavaid sõnumeid kohale toimetada – need võivad kaduma minna ja osa sõlmedest võib olla kättesaamatud.

Järjepidevus on kontseptsioon, mille mõistmiseks kulus mul kõige rohkem aega, enne kui ma sellest aru sain ja hindasin. Järjepidevust on mitut tüüpi, kõige laialdasemalt kasutatav hajutatud süsteemides on tugev järjepidevus ( tugev konsistents), nõrk konsistents ( nõrk konsistents) ja lõplik konsistents ( lõplik järjepidevus). Sellest artiklist saate lugeda kasulikku praktilist analüüsi iga mudeli eeliste ja puuduste kohta. Üldiselt, mida nõrgem on nõutav järjepidevuse tase, seda kiiremini saab süsteem töötada, kuid seda tõenäolisem on, et see ei tagasta kõige värskemat andmekogumit.

Miks peaks suure maksesüsteemi ehitamisel arvestama järjepidevusega? Süsteemis olevad andmed peavad olema järjepidevad. Aga kui järjekindel? Mõne süsteemi osa jaoks sobivad ainult väga järjepidevad andmed. Näiteks peame väga järjepidevalt salvestama teavet makse algatamise kohta. Süsteemi muude osade puhul, mis pole nii olulised, võib järjepidevust lõpuks pidada mõistlikuks kompromissiks.

Hiljutiste tehingute loendi väljund illustreerib seda hästi: neid saab rakendada, kasutades lõpuks järjepidevust ( lõplik järjepidevus) - ehk viimane tehing võib mõnes süsteemi osas ilmuda alles mõni aeg hiljem, kuid tänu sellele tagastab loendipäring tulemuse väiksema viivitusega või nõuab täitmiseks vähem ressursse.

Andmete vastupidavus

Vastupidavus tähendab, et kui andmed on edukalt andmelattu lisatud, on need edaspidi meile kättesaadavad. See kehtib isegi siis, kui süsteemi sõlmed lähevad võrguühenduseta, ebaõnnestuvad või sõlmede andmed on rikutud.

Erinevatel hajutatud andmebaasidel on erinev andmete vastupidavuse tase. Mõned neist toetavad andmete vastupidavus masina/sõlme tasemel, teised teevad seda klastri tasemel ja mõned ei paku seda funktsiooni üldse. Vastupidavuse suurendamiseks kasutatakse tavaliselt mõnda replikatsiooni vormi – kui andmeid salvestatakse mitme sõlme vahel ja üks sõlmedest kaob, on andmed endiselt saadaval. , selgitades, miks hajutatud süsteemide vastupidavuse saavutamine võib olla tõsine väljakutse.

Miks on andmete vastupidavus maksesüsteemi loomisel oluline? Kui andmed on kriitilised (nt maksed), ei saa me paljudes meie süsteemi osades nende kaotamist lubada. Meie loodud hajutatud andmesalved pidid toetama klastritasemel andmete vastupidavust – nii et isegi eksemplaride kokkujooksmisel säiliksid lõpetatud tehingud. Tänapäeval toetavad enamik hajutatud salvestusteenuseid – nagu Cassandra, MongoDB, HDFS või Dynamodb – kõik vastupidavust erinevatel tasanditel ja neid saab konfigureerida klastri tasemel vastupidavuse tagamiseks.

Sõnumi püsivus ja vastupidavus

Hajutatud süsteemide sõlmed teostavad arvutusi, salvestavad andmeid ja saadavad üksteisele sõnumeid. Sõnumite saatmise põhiomadus on see, kui usaldusväärselt need sõnumid kohale jõuavad. Kriitiliste süsteemide puhul on sageli nõue, et ükski sõnum ei läheks kaduma.

Hajussüsteemide puhul sõnumside ( sõnumite saatmine) tehakse tavaliselt mõne hajutatud sõnumiteenuse abil – RabbitMQ, Kafka või mõni muu. Need sõnumimaaklerid saavad toetada (või on konfigureeritud toetama) sõnumiedastuskindluse eri tasemeid.

Sõnumi püsivus tähendab, et kui sõnumit töötlev sõlm ebaõnnestub, on sõnum ka pärast probleemi lahendamist töötlemiseks saadaval. Sõnumi vastupidavust kasutatakse tavaliselt sõnumijärjekorra tasemel. Kui järjekord (või sõlm) läheb püsiva sõnumijärjekorra korral sõnumi saatmisel võrguühenduseta, saab see sõnumi siiski vastu, kui see uuesti võrku tuleb. Hea üksikasjalik artikkel selle teema kohta on saadaval lingil.


Miks on suurte maksesüsteemide ehitamisel oluline sõnumite ohutus ja vastupidavus? Meile tuli sõnumeid, mille kaotamist me ei saanud endale lubada – näiteks teade, et inimene algatas reisi eest tasumise. See tähendas, et kasutatav sõnumsidesüsteem pidi olema kadudeta: iga sõnum tuli üks kord kohale toimetada. Siiski luuakse süsteem, mis edastab iga sõnumi sileüks kord kui vähemaltüks kord - need on ülesanded, mis erinevad oluliselt oma raskusastmelt. Otsustasime rakendada sõnumsidesüsteemi, mis edastab vähemalt korra, ja valisime sõnumisiini ( sõnumibuss), mille peale otsustasime selle ehitada (valisime Kafka kasuks, luues kadudeta klastri, mis oli meie puhul vajalik).

Idempotentsus

Hajutatud süsteemide puhul võib kõik valesti minna – ühendused võivad keset katkeda või päringud võivad aeguda. Kliendid kordavad neid taotlusi sageli. Idempotentne süsteem tagab, et olenemata sellest, mis juhtub ja kui mitu korda konkreetset päringut täidetakse, toimub selle päringu tegelik täitmine ainult üks kord. Hea näide on makse tegemine. Kui klient koostab maksetaotluse, on päring edukas, kuid kui klient aegub, saab klient sama päringut korrata. Idempotentse süsteemi puhul ei võeta makse sooritajalt kahekordset tasu; kuid mitte-idemponeti süsteemi puhul on see täiesti võimalik nähtus.

Idempotentsete hajutatud süsteemide kujundamine nõuab teatud tüüpi hajutatud lukustusstrateegiat. Siin tulevad mängu mõisted, millest me varem rääkisime. Oletame, et kavatseme rakendada idempotentsust optimistliku lukustamise abil, et vältida samaaegseid värskendusi. Selleks, et saaksime kasutada optimistlikku lukustamist, peab süsteem olema tugevalt järjepidev – et saaksime käitamise ajal kontrollida, kas mõni muu toiming on mõnda versioonimist kasutades alanud.

Idempotentsuse saavutamiseks on palju viise ja iga konkreetne valik sõltub süsteemi piirangutest ja sooritatava toimingu tüübist. Idempotentsete lähenemisviiside kujundamine on arendajale väärt väljakutse – vaadake lihtsalt Ben Nadeli postitusi, kus ta räägib erinevatest strateegiatest, mida ta on kasutanud, mis hõlmavad nii hajutatud lukke kui ka piiranguid ( piirangud) Andmebaas. Kui kujundate hajutatud süsteemi, võib idempotentsus kergesti olla üks osadest, millest olete tähelepanuta jätnud. Oleme oma praktikas kohanud juhtumeid, kus minu meeskond "põles läbi", et nad ei olnud veendunud mõne võtmeoperatsiooni õige idempotentsuse olemasolus.

Miks on idempotentsus suure maksesüsteemi ehitamisel oluline? Kõige tähtsam: vältida topelttasusid ja topelt tagasimakseid. Arvestades, et meie sõnumsidesüsteemil on "vähemalt üks kord ilma kadudeta" edastamine, peame eeldama, et kõiki sõnumeid saab edastada mitu korda ja süsteemid peavad tagama idempotentsuse. Oleme otsustanud seda käsitleda versioonide loomise ja optimistliku lukustamise abil, kus meie süsteemid rakendavad idempotentset käitumist, kasutades andmeallikana tugevalt ühtset poodi.

Jagamine ja kvoorum

Hajutatud süsteemid peavad sageli salvestama palju rohkem andmeid, kui üks sõlm suudab endale lubada. Kuidas siis salvestada andmekogum õigele arvule masinatele? Kõige populaarsem tehnika selleks on killustamine. Andmed jaotatakse horisontaalselt, kasutades partitsioonile määratud räsi. Kuigi paljud hajutatud andmebaasid rakendavad tänapäeval killustumist kapoti all, on see iseenesest huvitav teema ja tasub uurida – eriti uuesti killustamine. Foursquare'il oli 2010. aastal 17-tunnine seisak, mis oli tingitud servade purunemise juhtumist, misjärel ettevõte jagas , heites valgust probleemi juurtele.

Paljudel hajutatud süsteemidel on andmed või arvutused, mida kopeeritakse mitme sõlme vahel. Toimingute järjepidevuse tagamiseks on määratletud hääletusviis, mille puhul selleks, et toiming loetaks edukaks, on vajalik, et teatud arv sõlme saaks sama tulemuse. Seda protsessi nimetatakse kvoorumiks.

Miks on Uberis suure maksesüsteemi ülesehitamisel kvoorumi ja jagamise mõte? Mõlemad mõisted on lihtsad ja neid kasutatakse peaaegu kõikjal. Kohtusin nendega, kui me Cassandras replikatsiooni seadistasime. Cassandra (ja teised hajutatud süsteemid) kasutavad kvoorumit ja kohalikku kvoorumit ( kohalik kvoorum), et tagada klastritevaheline järjepidevus.

Näitleja mudel

Tuttav sõnavara, mida kasutame programmeerimistavade kirjeldamiseks – näiteks muutujad, liidesed, meetodite väljakutsed – viitab ühe masinaga süsteemidele. Kui räägime hajutatud süsteemidest, peame kasutama muid lähenemisviise. Levinud viis selliste süsteemide kirjeldamiseks on tegutseja mudel, milles näeme koodi suhtluse mõttes. See mudel on populaarne tänu sellele, et see langeb kokku mõttemudeliga, kuidas me kujutame ette näiteks inimeste suhtlemist organisatsioonis. Teine, mitte vähem populaarne viis hajutatud süsteemide kirjeldamiseks on CSP, interakteeruv järjestikune protsess.

Näitlejamudel põhineb näitlejatel, kes saadavad üksteisele sõnumeid ja vastavad neile. Iga näitleja saab teha piiratud hulga asju – luua teisi näitlejaid, saata teistele sõnumeid või otsustada, mida järgmise sõnumiga peale hakata. Mõne lihtsa reegliga saame üsna hästi kirjeldada keerulisi hajutatud süsteeme, mis suudavad end pärast näitleja "kukkumist" taastada. Kui te pole selle lähenemisviisiga tuttav, siis soovitan teile seda artiklit

Heterogeensed mitmearvutisüsteemid

Suurim hulk praegu olemasolevaid hajutatud süsteeme on ehitatud heterogeensete mitmearvutisüsteemide skeemi järgi. See tähendab, et sellesse süsteemi kuuluvad arvutid võivad olla äärmiselt mitmekesised, näiteks protsessori tüübi, mälumahu ja I/O-kanali jõudluse poolest. Praktikas võivad mõne sellise arvuti rolli täita suure jõudlusega paralleelsed süsteemid, näiteks mitmeprotsessorilised või homogeensed multiarvutid.

Neid ühendav võrk võib samuti olla väga heterogeenne.

Heterogeensuse näide on suurte mitmearvutisüsteemide loomine olemasolevate võrkude ja kanalite abil. Nii et näiteks ülikoolide hajutatud süsteemide olemasolu, mis koosnevad erinevate teaduskondade kohalikest võrkudest, mis on omavahel ühendatud kiirete kanalitega, pole midagi ebatavalist. Laialasüsteemides saab erinevaid jaamu omakorda ühendada avalike võrkude kaudu, näiteks kommertsvedajate pakutavad võrguteenused, nagu näiteks SMDS või raami relee.

Erinevalt eelmistes lõikudes käsitletud süsteemidest vajavad paljud suuremahulised heterogeensed mitmearvutisüsteemid globaalset lähenemist. See tähendab, et rakendus ei saa eeldada, et teatud jõudlus või teatud teenused on talle alati saadaval.

Pöördudes heterogeensetele süsteemidele omaste skaleerimisprobleemide juurde ja arvestades enamikule neist omase globaalse lähenemise vajadust, märgime, et heterogeensete mitmearvutisüsteemide rakenduste loomine nõuab spetsiaalset tarkvara. Selle probleemiga tegelevad hajutatud süsteemid. Et rakenduste arendajad ei peaks muretsema kasutatava riistvara pärast, pakuvad hajutatud süsteemid kesta, mis kaitseb rakendusi riistvaras toimuva eest (st pakuvad läbipaistvust).

Varaseim ja põhilisem hajutatud arhitektuur on "klient-server", milles üks osapooltest (klient) algatab andmevahetuse, saates päringu teisele poolele (serverile). Server töötleb päringu ja saadab vajadusel vastuse kliendile (joonis 2.7).

Riis. 2.7. Kliendi-serveri interaktsioonimudel

Kliendi-serveri mudelisisene interaktsioon võib olla kas sünkroonne, kui klient ootab, kuni server oma päringu töötlemise lõpetab, või asünkroonne, kus klient saadab päringu serverile ja jätkab selle täitmist serveri vastust ootamata. Kliendi ja serveri mudelit saab võtta aluseks erinevate interaktsioonide kirjeldamisel. Mõelge hajutatud süsteemi moodustava tarkvara komponentide koostoimele.

Riis. 2.8. Rakenduse loogilised kihid

Vaatleme tüüpilist rakendust, mille saab tänapäevaste ideede kohaselt jagada järgmisteks loogilisteks tasemeteks (joonis 2.8): kasutajaliides (UI), rakenduse loogika (LP) ja andmete juurdepääs (DD), töötamine andmebaasiga ( DB) . Süsteemi kasutaja suhtleb sellega läbi kasutajaliidese, andmebaasis on salvestatud rakenduse teemavaldkonda kirjeldavad andmed ning rakenduse loogikakiht realiseerib kõik teemavaldkonnaga seotud algoritmid.

Kuna praktikas on süsteemi erinevad kasutajad tavaliselt huvitatud juurdepääsust samadele andmetele, on sellise süsteemi funktsioonide lihtsaim eraldamine mitme arvuti vahel rakenduse loogiliste tasemete eraldamine vastutava rakenduse ühe serveriosa vahel. juurdepääsuks andmetele ja mitmes arvutis asuvatele kliendiosadele, rakendades kasutajaliidest. Rakendusloogika võib omistada serverile, klientidele või jagada nende vahel (joonis 2.9).

Riis. 2.9. Kahetasandiline arhitektuur

Sellel põhimõttel üles ehitatud rakenduste arhitektuuri nimetatakse klient-serveriks või kahe lüliga. Praktikas selliseid süsteeme sageli hajutatud süsteemide alla ei liigitata, kuid formaalselt võib neid pidada hajussüsteemide lihtsaimateks esindajateks.

Klient-server arhitektuuri arendamine on kolmeastmeline arhitektuur, milles kasutajaliides, rakendusloogika ja juurdepääs andmetele on eraldatud süsteemi sõltumatuteks komponentideks, mis võivad töötada sõltumatutel arvutitel (joonis 2.10).

Riis. 2.10. Kolmetasandiline arhitektuur

Kasutaja päringut töötlevad sellistes süsteemides järjestikku süsteemi klientosa, rakendusloogikaserver ja andmebaasiserver. Tavaliselt mõistetakse hajutatud süsteemi all aga keerukama arhitektuuriga süsteeme kui kolmetasandiline.

Riis. 2.11. Hajutatud jaemüügisüsteem

Ettevõtte automatiseerimisrakenduste puhul on hajutatud süsteemid tavaliselt süsteemid, mille rakendusloogika on jaotatud mitme süsteemikomponendi vahel, millest igaüht saab käivitada eraldi arvutis. Näiteks jaemüügisüsteemi rakendusloogika juurutamisel tuleks kasutada päringuid kolmandate isikute, näiteks kaubatarnijate, elektrooniliste maksesüsteemide või tarbimislaene pakkuvate pankade rakendusloogikale (joonis 2.11).

Teine näide hajutatud süsteemist on võrgud otsene andmevahetus klientide vahel (peer-to-peer võrgud). Kui eelmisel näitel oli "puu" arhitektuur, siis otsevahetusvõrgud on organiseeritud keerulisemalt, joonis 2.12. Sellised süsteemid on praegu tõenäoliselt üks suurimaid hajutatud süsteeme, mis ühendavad miljoneid arvuteid.

Riis. 2.12. Otsene andmevahetussüsteem klientide vahel

Aggregate on üks väheseid asjade Interneti platvorme maailmas, mis toetab tõeliselt hajutatud arhitektuuri. See pakub piiramatut mastaapsust, et tasakaalustada ja eraldada kõik Aggregate'i serveritoimingud erinevatel tasanditel. Selline arhitektuur võib olla aluseks nii praeguste probleemide lahendamisel kui ka tuleviku vajaduste rahuldamisel.

Erinevalt tõrkesiirdeklastrist on hajutatud arhitektuuris AggreGate'i serverid täiesti sõltumatud. Igal serveril on oma andmebaas, kohalikud kasutajakontod ja seotud õigused.

AggreGate'i hajutatud arhitektuur on äärmiselt paindlik. Tehniliselt põhineb see serverite vahel peer-to-peer suhete loomisel ja mõne serveri (tarnijad) ühtse andmemudeli osade manustamisel teistele ("tarbijatele").

Hajusoperatsioonide eesmärgid

Hajutatud arhitektuuri peamised eesmärgid on:

• Skaleeritavus. Madalama astme servereid saab koormata, kogudes andmeid ja hallates suurt hulka seadmeid peaaegu reaalajas. Praktikas piirdub aga ühe serveriga teenindatavate seadmete arv mõne tuhandega. Süsteemi skaleerimisel suure hulga seadmete haldamiseks on mõistlik installida mitu serverit ja ühendada need hajutatud installi osana.
• Koormuse tasakaalustamine. Iga hajutatud installi server lahendab oma probleemi ise. Võrguhaldusserverid kontrollivad võrgu infrastruktuuri saadavust ja jõudlust, juurdepääsukontrolli serverid töötlevad ukse- ja pöördvärava kontrollerite päringuid. Juhtimistoiminguid, nagu aruannete koostamine ja postitamine, saab teha keskserveris.
• Sissetungikaitse. Sekundaarseid sondiservereid saab installida kaugematesse kohtadesse ja ühendada keskserveriga. Süsteemioperaatorid loovad ühenduse ainult keskserveriga ning VPN-i ja pordiedastust nendele serveritele pole vaja seadistada.
• Tsentraliseerimine. Teisesed serverid võivad töötada täisautomaatses režiimis, samas kui nende seadistamine ja jälgimine toimub kesksesse juhtimisruumi paigaldatud põhiserveri kaudu.

Serverirollide jaotus

Selle lihtsa stsenaariumi korral ühendatakse kaks serverit hajutatud infrastruktuuriks. Süsteemihaldurid on pidevalt ühendatud jälgimisserveriga, täites oma igapäevaseid tööülesandeid. Ettevõtte juhtkond loob ühenduse aruandlus- ja analüüsiserveriga, kui tal on vaja andmeid saada. Sõltumata andmemahust ja serveri koormusest ei mõjuta see toiming operaatorite tööd.

Suuremahuline pilve IoT platvorm

Telekommunikatsiooni- ja pilveteenuste pakkujad pakuvad IoT-teenuseid IaaS/PaaS/SaaS mudelites. Nendel juhtudel räägime miljonitest seadmetest, mis kuuluvad tuhandetele kasutajatele. Sellise tohutu infrastruktuuri säilitamiseks on vaja sadu Aggregate'i servereid, millest enamiku saab rühmitada kahte rühma:

• Serverid, mis salvestavad kasutajate ja nende seadmete registrit, suunavad operaatorite ja seadmete ühendused madalama taseme serveritesse, samuti koondavad andmeid hilisemaks teabe analüüsiks madalama taseme serverite osalusel
• Serverid, mis jälgivad ja haldavad seadmeid, samuti võtavad vastu, salvestavad ja töötlevad andmeid

Kasutaja- ja seadmehaldusserverid vastutavad ka pilvehaldussüsteemiga suhtlemise eest, mis juurutab ja jälgib uusi salvestus- ja analüüsiservereid.

Andmete salvestamise ja töötlemise serverid kasutavad malliserveritelt saadud ressursse (häireid, mudeleid, töövooge, armatuurlaudu jne), mis omakorda salvestavad nende ressursside põhikoopiaid.

Kihiline IoT infrastruktuur

Tänu Aggregate'i hajutatud infrastruktuurile võib iga lahendus sisaldada palju erineva tasemega servereid. Mõned neist saavad töötada IoT lüüsides, kogudes andmeid, teised saavad teavet salvestada ja töödelda ning ülejäänud saavad teostada kõrgetasemelist koondamist ja hajutatud andmetöötlust.

Väliseadmeid, nagu andurid ja täiturmehhanismid, saab ühendada serveritega otse, agentide, lüüside või mõlema kombinatsiooni kaudu.

tark linnajuhtimine

See on näide koondväraval põhinevast kihilisest arhitektuurist suure hulga hoonete automatiseerimiseks:

• 1. tase: füüsilised seadmed (võrguruuterid, kontrollerid, tööstusseadmed jne)
• 2. tase: haldusserverid (võrgu jälgimise serverid, juurdepääsukontrolli serverid, hooneautomaatika serverid ja teised)
• 3. tase: serverite juhtimiskeskuste ehitamine (üks server hoone kohta, mis kogub teavet kõikidelt teise taseme serveritelt)
• 4. tase: linnapiirkonna serverid (lõppsihtkoht madalama taseme hoiatuste eskaleerimiseks, reaalajas jälgimine, integreerimine Service Desk süsteemidega)
• 5. tase: peakontori serverid (piirkonnaserverite juhtimine, aruannete kogumine ja koostamine, hoiatused)

Kõik ülaltoodud serverid võivad olla mitme sõlmega tõrkesiirdeklastrid.

Mitmesegmendiline võrguhaldus

Aggregate Network Manager on üles ehitatud AggreGate platvormile ja on hajutatud arhitektuuri tüüpiline kasutusjuht. Ettevõtete ja suuri segmenteeritud võrke ei saa juhtida ühest keskusest marsruutimise piirangute, turbepoliitika või sidekanalite ribalaiuse piirangute tõttu kaugvõrgu segmentidega.

Seega koosneb hajutatud seiresüsteem tavaliselt järgmistest komponentidest:

• Esmane või keskne server, mis kogub teavet kõigist võrgu segmentidest
• Teisene serverid või prooviserverid mis küsivad seadmeid isoleeritud segmentides
• Spetsialiseerunud serverid, nagu liiklusanalüüsi serverid, mis töötlevad miljardeid NetFlow sündmusi päevas

Teisesed ja spetsialiseeritud serverid on põhiserveri teabepakkujad, pakkudes osa oma andmemudelist juhtimiskeskusele. See võib olla:

• Kogu prooviserveri kontekstipuu sisu, mis võimaldab konfiguratsiooni täielikku juhtimist keskserverist. Sel juhul kasutatakse prooviserverit võrgu segmenteerimise probleemi lahendamiseks lihtsalt puhverserverina.
• Sondiserveri genereeritud hoiatused. Sel juhul saab 99% töökohtadest olla kaugjuhtimisega ning keskserveri operaator saab koheselt teatised teisestelt serveritelt.
• Kohandatud andmestikud prooviserveritest, nt reaalajas teave kriitiliste seadmete oleku kohta või koondatud aruanded. Kõik sellega seotud tööd tehakse teiseses serveris, mis võimaldab koormust jaotada.

Suure jõudlusega sündmuste juhtimine

Mõned AggreGate'i platvormi kasutusjuhud (nt tsentraliseeritud intsidentide haldamine) nõuavad märkimisväärse hulga sündmuste vastuvõtmist, töötlemist ja püsivalt struktureeritud vormingus salvestamist. Mõnikord võivad vood ulatuda miljonite sündmusteni sekundis, pealegi saab need erinevatest allikatest.

Sellistel juhtudel ei suuda üks Aggregate'i server kogu sündmuste vooga hakkama saada. Hajutatud arhitektuur aitab korraldada sündmuste töötlemist:

• Sündmusi genereerivatele objektidele on installitud mitu kohalikku serverit, mis neid sündmusi töötlevad. Ühe töötlemisserveriga saab ühenduse luua mitu allikat (sondi).
• Spetsiaalne salvestusserver või mitme serveriga suur andmesalvestusklaster on seotud iga kohaliku töötlemisserveriga. Klastri sõlmede arv võib varieeruda sõltuvalt sündmuste genereerimise kiirusest.
• Kõik kohalikud salvestusserverid teostavad eelfiltreerimist, dubleerimist, korrelatsiooni (kasutades kohapeal ühendatud proovivõtturitele kehtivaid reegleid), rikastamist ja sündmuste salvestamist.
• Kohalikud salvestusserverid loovad ühenduse keskse koondamisserveriga. Koondamisserver vastutab oluliste sündmuste korrelatsiooni eest kogu süsteemis.
• Keskserveri operaatorid saavad vaadata kogu sündmuste andmebaasi, ajakohaste andmete leidmise ülesanne on aga jaotatud salvestusserverite vahel. Seega on kõigi sündmuste andmebaasi põhjal võimalik luua tsentraliseeritud aruandlust ja hoiatusi.

Digitaalne ettevõte

AggreGate võib toimida digitaalse ettevõtte koordineeriva platvormina. Kõik Aggregate'i serverid võivad täita erinevaid funktsioone, alates kaugobjektide jälgimisest ja haldamisest kuni kõrgetasemeliste teenusteni, nagu äriteave või näiteks juhtumite haldamine.

Kõik digitaalse ettevõtte serverid on omavahel ühendatud hajutatud infrastruktuuri kaudu. Madalama taseme serverid võimaldavad juurdepääsu ühe andmemudeli osadele kontekstidele kõrgema taseme serveritele, võimaldades teil luua kogu ettevõtte jaoks olukorrakeskuse.

Tuntud arvutiteadlase E. Tanenbaumi sõnul puudub hajutatud süsteemi üldtunnustatud ja samas range definitsioon. Mõned arukad väidavad, et levitatud on selline arvutussüsteem, milles arvuti rike, mille olemasolu kasutajad varem isegi ei kahtlustanud, viib kogu nende töö seiskumiseni. Märkimisväärne osa hajutatud arvutisüsteemidest vastab kahjuks sellele määratlusele, kuid formaalselt viitab see ainult süsteemidele, millel on unikaalne haavatavus ( üksainus ebaõnnestumise punkt).

Sageli on hajutatud süsteemi defineerimisel esikohal selle funktsioonide jaotus mitme arvuti vahel. Selle lähenemise korral on mis tahes arvutussüsteem kus andmetöötlus on jagatud kahe või enama arvuti vahel. Lähtudes E. Tanenbaumi definitsioonist, võib mõnevõrra kitsamalt hajutatud süsteemi defineerida sidekanalitega ühendatud iseseisvate arvutite kogumina, mis mõne tarkvara kasutaja seisukohalt näevad välja ühtse tervikuna.

Sellel hajutatud süsteemi määratlemise lähenemisviisil on oma puudused. Näiteks kõik, mida sellises hajutatud süsteemis kasutatakse tarkvara võiks töötada ühes arvutis, kuid ülaltoodud definitsiooni seisukohalt sellist süsteemi enam ei levitata. Seetõttu peaks hajutatud süsteemi kontseptsioon põhinema ilmselt sellise süsteemi moodustava tarkvara analüüsil.

Kahe olemi interaktsiooni kirjeldamise aluseks võtame üldise kliendi-serveri interaktsiooni mudeli, kus üks osapooltest (klient) algatab andmevahetuse, saates päringu teisele poolele (serverile). Server töötleb päringu ja vajadusel saadab kliendile vastuse (joonis 1.1).

Riis. 1.1.

Kliendi-serveri mudelisisene interaktsioon võib olla kas sünkroonne, kui klient ootab, kuni server oma päringu töötlemise lõpetab, või asünkroonne, kus klient saadab päringu serverile ja jätkab selle täitmist serveri vastust ootamata. Kliendi ja serveri mudelit saab võtta aluseks erinevate interaktsioonide kirjeldamisel. Selle kursuse puhul on oluline hajutatud süsteemi moodustava tarkvara komponentide koostoime.

Riis. 1.2.

Mõelge mõnele tüüpilisele rakendusele, mille saab tänapäevaste ideede kohaselt jagada järgmisteks loogilisteks tasemeteks (joonis 1.2): kasutajaliides(IP), rakendusloogika (LP) ja andmejuurdepääs (DD), mis töötavad andmebaasiga (DB). Süsteemi kasutaja suhtleb sellega kasutajaliidese kaudu, andmebaasis on salvestatud rakenduse teemavaldkonda kirjeldavad andmed ning rakenduse loogikakiht rakendab kõiki süsteemiga seotud algoritme. ainevaldkond.

Kuna praktikas on süsteemi erinevad kasutajad tavaliselt huvitatud juurdepääsust samadele andmetele, on sellise süsteemi funktsioonide lihtsaim eraldamine mitme arvuti vahel rakenduse loogiliste tasemete eraldamine vastutava rakenduse ühe serveriosa vahel. juurdepääsuks andmetele ja mitmes arvutis asuvatele kliendiosadele, rakendades kasutajaliidest. Rakendusloogika võib omistada serverile, klientidele või jagada nende vahel (joonis 1.3).

Riis. 1.3.

Selle põhimõtte järgi ehitatud rakenduste arhitektuuri nimetatakse klient-serveriks ehk kahetasandiliseks. Praktikas selliseid süsteeme sageli hajutatud süsteemide alla ei liigitata, kuid formaalselt võib neid pidada hajussüsteemide lihtsaimateks esindajateks.

Klient-server arhitektuuri arendus on kolmetasandiline arhitektuur, milles kasutajaliides, rakendusloogika ja juurdepääs andmetele on eraldatud iseseisvateks süsteemi komponentideks, mis võivad töötada sõltumatutel arvutitel (joonis 1.4).

Riis. 1.4.

Kasutaja päringut töötlevad sellistes süsteemides järjestikku süsteemi klientosa, rakendusloogikaserver ja andmebaasiserver. Tavaliselt mõistetakse hajutatud süsteemi all aga keerukama arhitektuuriga süsteeme kui kolmetasandiline.