Distribuovaný AIS sa stal každodennou realitou. Mnoho podnikových AIS používa distribuované databázy. Boli vypracované metódy distribúcie údajov a riadenia distribuovaných údajov, architektonické prístupy zaisťujúce škálovateľnosť systémov, implementácia princípov viacvrstvovej architektúry klient-server a architektúra strednej vrstvy.

Mobilné architektúry sa začínajú uplatňovať v praxi. To platí pre databázové systémy aj webové aplikácie.

Oživuje sa prístup k budovaniu distribuovaných systémov založený na architektúre peer-to-peer, v ktorom na rozdiel od architektúry klient-server, ktorá dnes v distribuovaných systémoch dominuje, nie sú úlohy interagujúcich strán v sieti fixné. Sú priradené v závislosti od situácie v sieti a od zaťaženia jej uzlov.

V súvislosti s intenzívnym rozvojom komunikačných technológií sa mobilný AIS aktívne rozvíja. Boli vyvinuté technické prostriedky a softvér na ich vytvorenie. To viedlo k vývoju mobilných databázových systémov. Mnoho výskumných tímov vykonáva výskum špecifických vlastností týchto systémov a vytvára ich rôzne prototypy. Technológie Java sa stali dôležitým nástrojom pre vývoj mobilného softvéru.

Bol vytvorený štandard WAP (Wireless Application Protocol), ktorý už niektoré modely mobilných telefónov podporujú. Na základe WAP a XML vyvinul W3C značkovací jazyk pre bezdrôtovú komunikáciu WML (Wireless Markup Language).

Pri vývoji AIS bola väčšia pozornosť venovaná metadátam. Tu sa vykonávajú kroky v dvoch smeroch - štandardizácia prezentácie metadát a zabezpečenie ich podpory v systéme.

AIS používa rôzne spôsoby a prostriedky na prezentáciu metadát (rôzne druhy archívov metadát). Nedostatok zjednotenia v tejto oblasti výrazne komplikuje riešenie problémov mobility aplikácií, opätovného použitia a integrácie informačných zdrojov a informačných technológií, ako aj reinžinieringu AIS.

Na prekonanie týchto ťažkostí sa aktívne pokračuje vo vývoji štandardov metadát zameraných na rôzne informačné technológie. V tejto oblasti už existuje množstvo medzinárodných, národných a priemyselných noriem, ktoré definujú prezentáciu metadát a výmenu metadát v AIS. Niektoré z nich už získali status de facto štandardov. Tu sa obmedzíme na uvedenie iba tých najvýznamnejších z nich.

Pravdepodobne prvým de facto štandardom tejto kategórie bol jazyk popisu údajov CODASYL pre sieťové databázy. Medzi neskoršie štandardy patria: štandard dotazovacieho jazyka SQL pre relačné databázy, obsahujúci definíciu takzvanej informačnej schémy - súbor reprezentácií schém relačnej databázy; štandardná súčasť objektovej databázy ODMG, ktorá popisuje rozhrania archívu archívov objektových schém; medzinárodný štandard IRDS (Information Resource Dictionary Systems), ktorý popisuje systémy na vytváranie a udržiavanie adresárov informačných zdrojov organizácie.

Ďalej je potrebné spomenúť štandard CWM (Common Warehouse Metamodel) na reprezentáciu metadát dátového skladu vyvinutý konzorciom OMG na základe predtým vytvoreného štandardu OIM (Open Information Model) konzorcia MDC (Meta Data Coalition).

Nový technologický platforma XML pre web obsahuje aj štandardy prezentácie metadát. Podpora metadát je jednou z najdôležitejších inovácií webu, ktorá radikálne mení technológiu správy jej informačných zdrojov. Aj keď bola podpora metadát pôvodne vyžadovaná v databázových technológiách, metadáta neboli podporované na webe prvej generácie.

Štandardy webových metadát zahrnujú podmnožinu jazyka XML používaného na opis logickej štruktúry určitého typu dokumentu XML. Tento popis sa nazýva DTD (Definícia typu dokumentu). Platforma XML navyše obsahuje štandard XML Schema, ktorý ponúka pokročilejšie funkcie na popis dokumentov XML. Štandard Resource Definition Framework (RDF) definuje jednoduchý znalostný reprezentačný jazyk na opis obsahu dokumentov XML. Nakoniec vyvíjaný štandard OWL (Ontology Web Language) definuje formálny jazyk popisu ontológie pre sémantický web.

Konzorcium OMG vyvinulo štandard UML (Unified Modeling Language), ktorý poskytuje metadáta pre nástroje CASE na analýzu a návrh vizuálnych objektov. Tento jazyk je podporovaný v mnohých softvérových produktoch CASE. OMG tiež vytvoril štandard XML Metadata Interchange (XMI) na výmenu metadát medzi nástrojmi CASE pomocou UML.

Je potrebné spomenúť aj štandard Dublin Core (DC), súbor prvkov metadát na opis obsahu dokumentov rôzneho charakteru. Tento štandard si rýchlo získal popularitu a našiel najmä široké využitie vo webovom prostredí (pozri časť 3.3).

Práce na vývoji existujúcich a vytváraní nových štandardov na prezentáciu metadát pre AIS pokračujú. Podrobnejšie informácie o príslušných normách nájdete v encyklopédii.

V predchádzajúcej kapitole sme sa pozreli na úzko prepojené viacprocesorové systémy so zdieľanou pamäťou, zdieľanými dátovými štruktúrami jadra a zdieľanou oblasťou, z ktorej sa vyvolávajú procesy. Na účely zdieľania zdrojov je však často žiaduce prideliť procesory spôsobom, ktorý je nezávislý od operačného prostredia a prevádzkových podmienok. Predpokladajme napríklad, že užívateľ osobného počítača potrebuje prístup k súborom umiestneným na väčšom počítači, ale zároveň si zachová kontrolu nad osobným počítačom. Aj keď niektoré programy, ako napríklad uucp, podporujú prenos sieťových súborov a ďalšie sieťové funkcie, ich použitie nebude používateľovi skryté, pretože si je vedomý toho, že sieť používa. Okrem toho je potrebné poznamenať, že programy ako textové editory nefungujú s odstránenými súbormi, ako s bežnými. Používatelia by mali mať štandardný súbor funkcií systému UNIX a okrem potenciálneho úzkeho miesta vo výkonnosti by nemali pociťovať prekročenie hraníc počítača. Napríklad práca systémových funkcií otvorených a čítaných so súbormi na vzdialených počítačoch by sa nemala líšiť od ich práce so súbormi patriacimi do miestnych systémov.

Architektúra distribuovaného systému je znázornená na obrázku 13.1. Každý počítač zobrazený na obrázku je samostatná jednotka pozostávajúca z CPU, pamäte a periférnych zariadení. Model sa nerozbije, aj keď počítač nemá lokálny súborový systém: na komunikáciu s inými počítačmi musí mať periférne zariadenia a všetky súbory, ktoré k nemu patria, môžu byť umiestnené na inom počítači. Fyzická pamäť dostupná pre každý počítač je nezávislá na procesoch spustených na iných počítačoch. V tomto ohľade sa distribuované systémy líšia od tesne spojených viacprocesorových systémov diskutovaných v predchádzajúcej kapitole. Preto jadro systému na každom stroji funguje nezávisle od vonkajších prevádzkových podmienok distribuovaného prostredia.

Obrázok 13.1. Systémový model distribuovanej architektúry

Distribuované systémy, dobre popísané v literatúre, tradične spadajú do nasledujúcich kategórií:

Periférne systémy, čo sú skupiny počítačov, ktoré majú výraznú zhodu a sú spojené s jedným (zvyčajne väčším) strojom. Periférne procesory zdieľajú svoju záťaž s centrálnym procesorom a presmerujú naň všetky hovory do operačného systému. Cieľom periférneho systému je zvýšiť celkový výkon siete a poskytnúť schopnosť priradiť procesor k jednému procesu v operačnom prostredí UNIX. Systém sa spustí ako samostatný modul; Na rozdiel od iných modelov distribuovaných systémov nemajú periférne systémy skutočnú autonómiu, s výnimkou prípadov spojených s procesným dispečingom a alokáciou lokálnej pamäte.

Distribuované systémy ako „Newcastle“, ktoré umožňujú vzdialenú komunikáciu pomocou názvov vzdialených súborov v knižnici (názov je prevzatý z článku „Pripojenie Newcastle“ - pozri). Vymazané súbory majú kusovník (rozlišovací názov), ktorý vo vyhľadávacej ceste obsahuje špeciálne znaky alebo voliteľný komponent názvu, ktorý predchádza koreňu systému súborov. Implementácia tejto metódy nezahŕňa zmeny v jadre systému, a preto je jednoduchšia ako ostatné metódy diskutované v tejto kapitole, ale menej flexibilná.

Distribuované systémy sú úplne transparentné a štandardné rozlišujúce názvy postačujú na odkaz na súbory umiestnené na iných počítačoch; je na jadre, aby tieto súbory rozpoznalo ako odstránené. Cesty na vyhľadávanie súborov uvedené v ich zložených názvoch prekračujú hranice zariadenia v bodoch pripojenia, bez ohľadu na to, koľko takýchto bodov sa vytvorí, keď sú systémy súborov namontované na diskoch.

V tejto kapitole sa pozrieme na architektúru každého modelu; všetky poskytnuté informácie nevychádzajú z výsledkov konkrétneho vývoja, ale z informácií publikovaných v rôznych technických článkoch. To predpokladá, že moduly protokolov a ovládače zariadení sú zodpovedné za adresovanie, smerovanie, riadenie toku a detekciu a opravu chýb - inými slovami, že každý model je nezávislý na používanej sieti. Príklady použitia systémových funkcií uvedené v nasledujúcej časti pre periférne systémy fungujú podobným spôsobom pre systémy ako Newcastle a pre úplne transparentné systémy, o ktorých budeme diskutovať neskôr; preto ich raz podrobne zvážime a v častiach venovaných iným typom systémov sa zameriame hlavne na vlastnosti, ktoré tieto modely odlišujú od všetkých ostatných.

13.1 PERIFERÁLNE PROCESORY

Architektúra periférneho systému je znázornená na obrázku 13.2. Cieľom tejto konfigurácie je zlepšiť celkový výkon siete realokáciou bežiacich procesov medzi CPU a periférnymi procesormi. Každý z periférnych procesorov nemá k dispozícii žiadne iné lokálne periférne zariadenia okrem tých, ktoré potrebuje na komunikáciu s centrálnou procesorovou jednotkou. Centrálny procesor má k dispozícii súborový systém a všetky zariadenia. Predpokladajme, že všetky užívateľské procesy sú vykonávané na periférnom procesore a nepohybujú sa medzi periférnymi procesormi; po prenesení do procesora na ňom zostanú až do dokončenia. Periférny procesor obsahuje odľahčenú verziu operačného systému určenú na spracovanie miestnych hovorov do systému, správu prerušenia, alokáciu pamäte, prácu so sieťovými protokolmi a ovládač zariadenia pre komunikáciu s centrálnym procesorom.

Keď je systém inicializovaný na centrálnom procesore, jadro načíta lokálny operačný systém na každý z periférnych procesorov prostredníctvom komunikačných liniek. Každý proces bežiaci na periférii je spojený so satelitným procesom patriacim centrálnemu procesoru (pozri); keď proces spustený na periférnom procesore volá systémovú funkciu, ktorá vyžaduje iba služby centrálneho procesora, periférny proces komunikuje so svojim satelitom a požiadavka je odoslaná na spracovanie do centrálneho procesora. Satelitný proces vykonáva funkciu systému a výsledky posiela späť do periférneho procesora. Vzťah medzi periférnym procesom a jeho spoločníkom je podobný vzťahu klient-server, o ktorom sme podrobne diskutovali v kapitole 11: periférny proces funguje ako klient svojho spoločníka, ktorý podporuje funkcie práce so súborovým systémom. V tomto prípade má proces vzdialeného servera iba jedného klienta. V časti 13.4 sa pozrieme na procesy servera s viacerými klientmi.

Obrázok 13.2. Konfigurácia periférneho systému

Obrázok 13.3. Formáty správ

Keď periférny proces volá systémovú funkciu, ktorú je možné spracovať lokálne, jadro nemusí odoslať požiadavku na satelitný proces. Takže napríklad na získanie ďalšej pamäte môže proces volať funkciu sbrk na lokálne spustenie. Ak sú však služby centrálneho procesora požadované napríklad na otvorenie súboru, jadro zakóduje informácie o parametroch odovzdaných volanej funkcii a podmienkach vykonania procesu do správy odoslanej do satelitného procesu (obrázok 13.3). Správa obsahuje znak, z ktorého vyplýva, že systémovú funkciu v mene klienta vykonáva satelitný proces, parametre odovzdané funkcii a údaje o prostredí vykonávania procesu (napríklad identifikačné kódy používateľa a skupiny), ktoré sú rôzne pre rôzne funkcie. Zostávajúca časť správy sú údaje s premennou dĺžkou (napríklad zložený názov súboru alebo údaje, ktoré sa majú zapisovať pomocou funkcie zápisu).

Satelitný proces čaká na požiadavky z periférneho procesu; keď je prijatá požiadavka, dekóduje správu, určí typ systémovej funkcie, vykoná ju a prevedie výsledky na odpoveď odoslanú do periférneho procesu. Odozva okrem výsledkov vykonania systémovej funkcie obsahuje chybové hlásenie (ak existuje), číslo signálu a dátové pole s premenlivou dĺžkou, ktoré obsahuje napríklad informácie načítané zo súboru. Periférny proces je pozastavený, kým nie je prijatá odpoveď, po jej prijatí dešifruje a odošle výsledky užívateľovi. Toto je všeobecná schéma na spracovanie hovorov do operačného systému; teraz prejdeme k podrobnejšiemu zváženiu jednotlivých funkcií.

Aby ste vysvetlili, ako periférny systém funguje, zvážte niekoľko funkcií: getppid, open, write, fork, exit a signal. Funkcia getppid je veľmi jednoduchá, pretože sa zaoberá jednoduchými formulármi požiadaviek a odpovedí, ktoré sa vymieňajú medzi periférnym zariadením a procesorom. Jadro na periférnom procesore generuje správu so znamienkom, z ktorého vyplýva, že požadovanou funkciou je funkcia getppid, a odošle požiadavku centrálnemu procesoru. Satelitný proces na centrálnom procesore číta správu z periférneho procesora, dešifruje typ funkcie systému, vykoná ho a získa identifikátor jeho rodiča. Potom vygeneruje odpoveď a odošle ju do prebiehajúceho periférneho procesu na druhom konci komunikačnej linky. Keď periférny procesor dostane odpoveď, postúpi ju procesu, ktorý sa nazýva systémová funkcia getppid. Ak periférny proces ukladá údaje (napríklad ID procesu rodiča) do lokálnej pamäte, nebude musieť so svojim spoločníkom vôbec komunikovať.

Ak sa zavolá funkcia otvoreného systému, periférny proces pošle svojmu spoločníkovi príslušnú správu, ktorá obsahuje názov súboru a ďalšie parametre. Ak je úspešný, sprievodný proces alokuje index a vstupný bod do tabuľky súborov, alokuje záznam v tabuľke deskriptorov užívateľského súboru v jeho priestore a vráti deskriptor súboru do periférneho procesu. Celý tento čas, na druhom konci komunikačnej linky, periférny proces čaká na odpoveď. Nemá k dispozícii žiadne štruktúry, ktoré by uchovávali informácie o otváranom súbore; popisovač vrátený otvorením je ukazovateľ na záznam v tabuľke deskriptora používateľského súboru, ktorý vlastní sprievodný proces. Výsledky vykonania funkcie sú znázornené na obrázku 13.4.

Obrázok 13.4. Volanie otvorenej funkcie z periférneho procesu

Ak sa zavolá zápis systémovej funkcie, periférny procesor vygeneruje správu pozostávajúcu zo znaku funkcie zápisu, deskriptora súboru a množstva údajov, ktoré sa má zapísať. Potom z priestoru periférneho procesu skopíruje údaje do satelitného procesu prostredníctvom komunikačnej linky. Satelitný proces dešifruje prijatú správu, načíta údaje z komunikačnej linky a zapíše ich do príslušného súboru (deskriptor obsiahnutý v správe sa použije ako ukazovateľ na jeho register a záznam, o ktorom sa v tabuľke súborov používa. ); všetky tieto akcie sa vykonávajú na centrálnom procesore. Na konci práce satelitný proces odošle periférnemu procesu správu, ktorá potvrdí prijatie správy a obsahuje počet dátových bajtov, ktoré boli úspešne skopírované do súboru. Operácia čítania je podobná; satelit informuje periférny proces o počte skutočne načítaných bajtov (v prípade čítania údajov z terminálu alebo z kanála sa toto číslo nie vždy zhoduje s množstvom uvedeným v požiadavke). Na vykonanie oboch týchto funkcií môže byť potrebné odoslať viac informačných správ cez sieť, ktoré sú určené množstvom odoslaných dát a veľkosťou sieťových paketov.

Jedinou funkciou, ktorú je potrebné pri behu na CPU zmeniť, je funkcia vidlicového systému. Keď proces vykonáva túto funkciu na CPU, jadro preň vyberie periférny procesor a odošle správu špeciálnemu procesu - serveru, ktorý ho informuje, že začne vykladať aktuálny proces. Za predpokladu, že server požiadavku prijal, jadro použije fork na vytvorenie nového periférneho procesu a alokáciou vstupu do tabuľky procesov a priestoru adries. Centrálny procesor uvoľní kópiu procesu, ktorý volal funkciu fork, do periférneho procesora, prepíše novo pridelený adresný priestor, vytvorí miestny satelit na komunikáciu s novým periférnym procesom a odošle periférii správu na inicializáciu počítadla programu. pre nový proces. Satelitný proces (na CPU) je potomkom procesu, ktorý sa nazýva fork; periférny proces je technicky potomkom serverového procesu, ale logicky je potomkom procesu, ktorý sa nazýva funkcia fork. Proces servera nemá žiadne logické spojenie s dieťaťom, keď sa fork dokončí; jedinou úlohou servera je pomôcť vyložiť dieťa. Vzhľadom na silné prepojenie medzi systémovými komponentmi (periférne procesory nemajú autonómiu) majú periférny proces a satelitný proces rovnaký identifikačný kód. Vzťah medzi procesmi je znázornený na obrázku 13.5: súvislá čiara ukazuje vzťah rodič-dieťa a bodkovaná čiara ukazuje vzťah medzi rovesníkmi.

Obrázok 13.5. Vykonávanie funkcie vidlice na CPU

Keď proces vykoná funkciu vidlice na periférnom procesore, vyšle správu svojmu satelitu na CPU, ktorý potom vykoná celú sekvenciu akcií opísaných vyššie. Družica vyberie nový periférny procesor a urobí potrebné prípravy na uvoľnenie obrazu starého procesu: vyšle požiadavku rodičovskému periférnemu procesu na prečítanie jeho obrazu, v reakcii na ktorú sa na druhom konci začína prenos požadovaných údajov. komunikačného kanála. Satelit číta prenášaný obraz a prepíše ho na periférneho potomka. Keď je vykladanie obrazu dokončené, satelitný proces sa rozbehne, vytvorí svoje dieťa na CPU a odovzdá hodnotu programového počítadla periférnemu dieťaťu, aby tento vedel, kde začať spustenie. Očividne by bolo lepšie, keby bolo dieťa sprievodného procesu priradené periférnemu dieťaťu ako rodičovi, ale v našom prípade sú vygenerované procesy schopné bežať na iných periférnych procesoroch, nielen na tých, na ktorých sú vytvorené. Vzťah medzi procesmi na konci funkcie vidlice je znázornený na obrázku 13.6. Keď periférny proces skončí svoju prácu, odošle zodpovedajúcu správu satelitnému procesu a tým sa tiež skončí. Sprievodný proces nemôže inicializovať vypnutie.

Obrázok 13.6. Vykonávanie funkcie vidlice na periférnom procesore

V multiprocesorových aj uniprocesorových systémoch musí proces reagovať na signály rovnakým spôsobom: proces buď dokončí vykonanie systémovej funkcie pred kontrolou signálov, alebo naopak po prijatí signálu okamžite opustí pozastavený stav a náhle preruší prácu systémovej funkcie, ak je to v súlade s prioritou. s ktorou bol pozastavený. Pretože satelitný proces vykonáva systémové funkcie v mene periférneho procesu, musí reagovať na signály v koordinácii s ním. Ak v jednoprocesorovom systéme signál spôsobí, že proces preruší funkciu, sprievodný proces vo viacprocesorovom systéme by sa mal správať rovnako. To isté sa dá povedať o prípade, keď signál vyzve proces, aby ukončil svoju prácu pomocou funkcie výstupu: periférny proces sa ukončí a odošle zodpovedajúcu správu satelitnému procesu, ktorý sa samozrejme tiež skončí.

Keď periférny proces zavolá funkciu signálneho systému, uloží aktuálne informácie do miestnych tabuliek a pošle na svoj satelit správu, ktorá ho informuje, či má byť špecifikovaný signál prijatý alebo ignorovaný. Nie je dôležité, aby satelitný proces zachytával signál alebo predvolenú akciu. Reakcia procesu na signál závisí od troch faktorov (obrázok 13.7): či signál príde, keď proces vykonáva funkciu systému, či sa pomocou signalizačnej funkcie indikuje ignorovanie signálu, či sa signál vyskytuje na rovnaký periférny procesor alebo na inom. Prejdeme k zváženiu rôznych možností.

algoritmus sighandle / * algoritmus spracovania signálu * /

ak (aktuálny proces je niečím spoločníkom alebo má prototyp)

ak (signál je ignorovaný)

ak (signál prišiel počas vykonávania systémovej funkcie)

umiestnite signál pred satelitný proces;

poslať signálnu správu periférnemu procesu;

else ( / * periférny proces * /

/ * či bol počas vykonávania systémovej funkcie prijatý signál alebo nie * /

poslať signál do satelitného procesu;

algoritmus Satellite_end_of_syscall / * ukončenie systémovej funkcie vyvolanej periférnym procesom * /

vstupné informácie: chýba

výstupné informácie: žiadne

ak (počas vykonávania systémovej funkcie došlo k prerušeniu)

odoslať správu o prerušení, signál do periférneho procesu;

inak / * výkon systémovej funkcie nebol prerušený * /

poslať odpoveď: povoliť vlajku indikujúcu príchod signálu;

Obrázok 13.7. Spracovanie signálu v periférnom systéme

Predpokladajme, že periférny proces pozastavil svoju prácu, zatiaľ čo satelitný proces v jeho mene plní funkciu systému. Ak sa signál vyskytne inde, satelitný proces ho detekuje skôr ako periférny proces. Sú možné tri prípady.

1. Ak satelitný proces počas čakania na nejakú udalosť neprešiel do pozastaveného stavu, z ktorého by sa po prijatí signálu ukončil, vykoná funkciu systému do konca, pošle výsledky vykonania do periférneho procesu a zobrazí aký signál dostal.

2. Ak je procesu prikázané ignorovať tento typ signálu, satelit pokračuje v sledovaní algoritmu vykonávania systémových funkcií bez opustenia pozastaveného stavu pomocou longjmp. V odpovedi odoslanej na periférny proces nebude žiadna správa o prijatí signálu.

3. Ak satelitný proces po prijatí signálu preruší výkon systémovej funkcie (pomocou longjmp), informuje o tom periférny proces a oznámi mu číslo signálu.

Periférny proces hľadá v prijatej odpovedi informácie o prijatí signálov a prípadne signály spracuje pred opustením systémovej funkcie. Správanie procesu vo viacprocesorovom systéme teda presne zodpovedá jeho správaniu v uniprocesorovom systéme: buď sa ukončí bez opustenia režimu jadra, alebo zavolá vlastnú funkciu spracovania signálu, alebo ignoruje signál a úspešne dokončí funkciu systému.

Obrázok 13.8. Prerušenie počas vykonávania systémovej funkcie

Predpokladajme napríklad, že periférny proces volá funkciu čítania z terminálu pripojeného k centrálnemu procesoru a pozastaví jeho prácu, kým funkciu vykonáva satelitný proces (obrázok 13.8). Ak užívateľ stlačí kláves break, jadro CPU vyšle signál do satelitného procesu. Ak bol satelit v pozastavenom stave a čakal na časť údajov z terminálu, okamžite tento stav ukončil a ukončil funkciu čítania. Družica vo svojej odpovedi na požiadavku periférneho procesu nahlási chybový kód a číslo signálu zodpovedajúce prerušeniu. Periférny proces analyzuje odpoveď a keďže správa hovorí, že prišlo prerušenie, pošle signál sebe. Pred opustením funkcie čítania periférne jadro kontroluje signalizáciu, detekuje signál prerušenia zo satelitného procesu a spracováva ho ako obvykle. Ak v dôsledku príjmu signálu prerušenia periférny proces ukončí svoju prácu pomocou funkcie výstupu, táto funkcia sa postará o zabitie satelitného procesu. Ak periférny proces zachytí signály prerušenia, zavolá užívateľom definovanú funkciu spracovania signálov a po ukončení funkcie čítania vráti užívateľovi chybový kód. Na druhej strane, ak satelit vykonáva funkciu štatistického systému v mene periférneho procesu, jeho prijatie nepreruší po prijatí signálu (funkcia stat zaručene ukončí akúkoľvek pauzu, pretože má obmedzený čas čakania na zdroje. ). Družica dokončí vykonanie funkcie a vráti číslo signálu do periférneho procesu. Periférny proces vysiela signál do seba a prijíma ho pri výstupe zo systémovej funkcie.

Ak sa počas vykonávania systémovej funkcie vyskytne signál na periférnom procesore, periférny proces bude v tme, či sa čoskoro vráti k riadeniu zo satelitného procesu, alebo sa tento prechod do pozastaveného stavu na neurčito. Periférny proces vyšle na satelit špeciálnu správu, ktorá ho informuje o výskyte signálu. Jadro na CPU správu dešifruje a vyšle signál na satelit, ktorého reakcia na príjem signálu je popísaná v predchádzajúcich odsekoch (abnormálne ukončenie vykonávania funkcie alebo jej dokončenie). Periférny proces nemôže odoslať správu na satelit priamo, pretože satelit je zaneprázdnený vykonávaním systémovej funkcie a nečíta údaje z komunikačnej linky.

Pokiaľ ide o prečítaný príklad, treba poznamenať, že periférny proces netuší, či jeho spoločník čaká na vstup z terminálu alebo vykonáva iné akcie. Periférny proces vysiela signál na satelit: ak je satelit v pozastavenom stave s prioritou prerušiteľnosti, okamžite opustí tento stav a ukončí funkciu systému; inak je funkcia úspešne dokončená.

Nakoniec zvážte prípad príchodu signálu v čase, ktorý nesúvisí s vykonávaním funkcie systému. Ak signál pochádza z iného procesora, satelit ho najskôr prijme a odošle signálnu správu do periférneho procesu, bez ohľadu na to, či sa signál týka periférneho procesu alebo nie. Periférne jadro dešifruje správu a pošle signál procesu, ktorý naň reaguje obvyklým spôsobom. Ak signál pochádza z periférneho procesora, proces vykoná štandardné akcie bez toho, aby sa uchýlil k službám svojho satelitu.

Keď periférny proces pošle signál iným periférnym procesom, zakóduje správu o ukončení hovoru a odošle ju do satelitného procesu, ktorý lokálne vykoná volanú funkciu. Ak sa niektoré z procesov, pre ktoré je signál určený, nachádzajú na iných periférnych procesoroch, ich satelity signál prijmú (a reagujú naň, ako je popísané vyššie).

13.2 KOMUNIKÁCIA NEWCASTLE

V predchádzajúcej časti sme uvažovali o type tesne prepojeného systému, ktorý sa vyznačuje odosielaním všetkých hovorov funkciám subsystému správy súborov, ktoré vznikajú na periférnom procesore, do vzdialeného (centrálneho) procesora. Teraz sa zameriame na menej úzko prepojené systémy, ktoré pozostávajú zo zariadení, ktoré majú prístup k súborom na iných počítačoch. Napríklad v sieti osobných počítačov a pracovných staníc majú používatelia často prístup k súborom umiestneným na veľkom počítači. V ďalších dvoch častiach sa pozrieme na také systémové konfigurácie, v ktorých sú všetky systémové funkcie vykonávané v lokálnych subsystémoch, ale zároveň je možné pristupovať k súborom (prostredníctvom funkcií subsystému správy súborov) umiestnených na iných počítačoch.

Tieto systémy používajú na identifikáciu odstránených súborov jednu z nasledujúcich dvoch ciest. V niektorých systémoch je do zloženého názvu súboru pridaný špeciálny znak: komponent názvu, ktorý predchádza tomuto znaku, identifikuje počítač, zvyšok názvu je súbor na tomto počítači. Takže napríklad rozlišovací názov

"sftig! / fs1 / mjb / rje"

identifikuje súbor " / fs1 / mjb / rje" na stroji "sftig". Táto schéma identifikácie súborov dodržiava konvenciu uucp na prenos súborov medzi systémami UNIX. V inej schéme sú odstránené súbory identifikované pridaním špeciálnej predpony k názvu, napríklad:

/../sftig/fs1/mjb/rje

kde „/../“ je predpona označujúca, že súbor je vymazaný; druhá zložka názvu súboru je názov vzdialeného počítača. Táto schéma používa známu syntax názvu súboru UNIX, takže na rozdiel od prvej schémy sa užívateľské programy nemusia prispôsobovať používaniu mien s neobvyklou konštrukciou (pozri).

Obrázok 13.9. Formulácia požiadaviek na súborový server (procesor)

Zvyšok tejto časti sa budeme venovať modelu systému používajúceho odkaz Newcastle, v ktorom jadro nejde o rozpoznávanie odstránených súborov; táto funkcia je úplne priradená podprogramom zo štandardnej knižnice C, ktoré v tomto prípade zohrávajú úlohu systémového rozhrania. Tieto podprogramy analyzujú prvú zložku názvu súboru, ktorá v oboch opísaných identifikačných metódach obsahuje znak odľahlosti súboru. Toto je odklon od rutiny, v ktorej rutiny knižnice neanalyzujú názvy súborov. Obrázok 13.9 ukazuje, ako sú formulované požiadavky na súborový server. Ak je súbor lokálny, jadro lokálneho systému spracuje požiadavku normálne. Zvážte opačný prípad:

otvorený ("/../ sftig / fs1 / mjb / rje / súbor", O_RDONLY);

Otvorený podprogram z knižnice C analyzuje prvé dve zložky názvu súboru a vie, že má vyhľadať súbor na vzdialenom počítači „sftig“. Aby mala informácia o tom, či mal proces predtým spojenie s daným počítačom, podprogram spustí špeciálnu štruktúru, v ktorej si túto skutočnosť zapamätá, a v prípade zápornej odpovede nadviaže spojenie so súborovým serverom spusteným na vzdialený stroj. Keď proces formuluje svoju prvú požiadavku na vzdialené spracovanie, vzdialený server potvrdí požiadavku, v prípade potreby sa zaznamená do polí identifikačných kódov používateľa a skupiny a vytvorí satelitný proces, ktorý bude konať v mene klientskeho procesu.

Na splnenie požiadaviek klienta musí mať satelit na vzdialenom počítači rovnaké oprávnenia na súbory ako klient. Inými slovami, užívateľ "mjb" musí mať rovnaké prístupové práva k vzdialeným aj lokálnym súborom. Nanešťastie je možné, že sa identifikačný kód klienta "mjb" môže zhodovať s identifikačným kódom iného klienta na vzdialenom počítači. Správcovia systému na počítačoch spustených v sieti by teda mali buď zabezpečiť, aby bol každému používateľovi priradený identifikačný kód, ktorý je jedinečný pre celú sieť, alebo vykonať konverziu kódu v čase žiadosti o sieťovú službu. Ak to neurobíte, sprievodný proces bude mať práva iného klienta na vzdialenom počítači.

Chúlostivejším problémom je získanie práv superužívateľov v súvislosti s prácou so vzdialenými súbormi. Na jednej strane by klient superužívateľa nemal mať na vzdialený systém rovnaké práva, aby nedošlo k zavádzaniu ovládacích prvkov zabezpečenia vzdialeného systému. Na druhej strane niektoré programy, ak im nie sú udelené práva superužívateľov, jednoducho nebudú môcť fungovať. Príkladom takéhoto programu je program mkdir (pozri kapitolu 7), ktorý vytvorí nový adresár. Vzdialený systém nedovolí klientovi vytvoriť nový adresár, pretože práva superužívateľov na vymazanie neplatia. Problém vytvárania vzdialených adresárov slúži ako vážny dôvod na revíziu funkcie systému mkdir v smere rozšírenia jeho schopností v automatickom vytváraní všetkých spojení potrebných pre používateľa. Stále je však bežným problémom, že programy setuid (ako napríklad program mkdir) získavajú práva superužívateľov nad vzdialenými súbormi. Asi najlepším riešením tohto problému by bolo nastaviť dodatočné charakteristiky pre súbory, ktoré opisujú prístup k nim vzdialeným superužívateľom; bohužiaľ, to by vyžadovalo zmeny v štruktúre indexu disku (pokiaľ ide o pridávanie nových polí) a v existujúcich systémoch by to spôsobilo príliš veľa neporiadku.

Ak je otvorený podprogram úspešný, miestna knižnica o tom zanechá zodpovedajúcu poznámku v štruktúre prístupnej pre užívateľa, ktorá obsahuje adresu sieťového uzla, ID procesu spoločníka, deskriptor súboru a ďalšie podobné informácie. Rutiny knižnice na čítanie a zápis určujú na základe deskriptora súboru, či je súbor vymazaný, a ak áno, pošlú správu na satelit. Klientský proces interaguje so svojim spoločníkom vo všetkých prípadoch prístupu k funkciám systému, ktoré vyžadujú služby vzdialeného počítača. Ak proces pristupuje k dvom súborom umiestneným na rovnakom vzdialenom počítači, použije jeden satelit, ale ak sú súbory umiestnené na rôznych počítačoch, už sa použijú dva satelity: jeden na každom počítači. Dva satelity sa používajú aj vtedy, keď dva procesy pristupujú k súboru na vzdialenom počítači. Vyvolaním systémovej funkcie prostredníctvom satelitu proces vygeneruje správu, ktorá obsahuje číslo funkcie, názov vyhľadávacej cesty a ďalšie potrebné informácie, podobné tej, ktorá je zahrnutá v štruktúre správ v systéme s periférnymi procesormi.

Mechanizmus vykonávania operácií na aktuálnom adresári je zložitejší. Keď proces vyberie vzdialený adresár ako aktuálny, rutina knižnice odošle na satelit správu, ktorá zmení aktuálny adresár, a rutina si zapamätá, že adresár je vymazaný. Vo všetkých prípadoch, keď názov cesty vyhľadávania začína znakom iným ako lomka (/), podprogram odošle názov na vzdialený počítač, kam ho satelitný proces nasmeruje z aktuálneho adresára. Ak je aktuálny adresár lokálny, rutina jednoducho pošle názov vyhľadávacej cesty jadru lokálneho systému. Funkcia chroot systému vo vzdialenom adresári je podobná, ale pre lokálne jadro zostáva bez povšimnutia; striktne povedané, proces môže túto operáciu ignorovať, pretože jej vykonanie zaznamenáva iba knižnica.

Keď proces volá vidlicu, príslušná rutina knižnice odošle správy každému satelitu. Procesy satelitov sa rozvetvujú a odosielajú svoje podradené ID rodičovskému klientovi. V klientskom procese je spustená funkcia systému vidlice, ktorá prenáša kontrolu na dieťa, ktoré sa mu narodí; miestne dieťa vedie dialóg so vzdialeným satelitným dieťaťom, ktorého adresy sú uložené v knižničnej rutine. Táto interpretácia funkcie vidlice uľahčuje satelitným procesom ovládanie otvorených súborov a aktuálnych adresárov. Keď proces pracujúci so vzdialenými súbormi skončí (volaním funkcie ukončenia), podprogram odošle správy všetkým svojim vzdialeným satelitom, aby urobili to isté pri prijatí správy. V cvičeniach sú prediskutované určité aspekty implementácie funkcií systému exec a exit.

Výhodou odkazu Newcastle je, že prístup procesu k vzdialeným súborom sa stáva transparentným (pre používateľa neviditeľným) bez toho, aby bolo potrebné vykonávať akékoľvek zmeny v jadre systému. Tento vývoj má však niekoľko nevýhod. Po prvé, počas jeho implementácie je možný pokles výkonu systému. Vďaka použitiu rozšírenej knižnice C sa veľkosť pamäte používanej každým procesom zvyšuje, aj keď proces nemá prístup k vzdialeným súborom; knižnica duplikuje funkcie jadra a vyžaduje si viac pamäte pre seba. Zvýšenie veľkosti procesov predlžuje dobu spustenia a môže spôsobiť väčšiu hádku o pamäťové zdroje, čo vytvára podmienky pre častejšie vykladanie a stránkovanie úloh. Miestne požiadavky sa budú vykonávať pomalšie kvôli predĺženiu trvania každého hovoru do jadra a taktiež sa dá spomaliť spracovanie vzdialených požiadaviek, čím sa zvýšia náklady na ich odoslanie cez sieť. Dodatočné spracovanie vzdialených požiadaviek na užívateľskej úrovni zvyšuje počet operácií kontextového prepínania, vykladania a výmeny. Nakoniec, aby bolo možné získať prístup k vzdialeným súborom, je potrebné programy znova skompilovať pomocou nových knižníc; staré programy a dodané objektové moduly bez neho nebudú môcť pracovať so vzdialenými súbormi. Všetky tieto nevýhody v systéme popísanom v nasledujúcej časti chýbajú.

13.3 „TRANSPARENTNÉ“ DISTRIBUOVANÉ SYSTÉMY SÚBOROV

Pojem „transparentné priradenie“ znamená, že používatelia na jednom počítači majú prístup k súborom na inom počítači bez toho, aby si uvedomili, že prekračujú hranice počítača, rovnako ako na svojom počítači, keď sa presúvajú z jedného systému súborov do druhého, prechádzajú bodmi pripojenia. Názvy, ktorými sa procesy odvolávajú na súbory umiestnené na vzdialených počítačoch, sú podobné názvom miestnych súborov: v nich nie sú žiadne charakteristické znaky. V konfigurácii zobrazenej na obrázku 13.10 je adresár „/ usr/ src“ patriaci stroju B „namontovaný“ do adresára „/ usr/ src“ patriaceho k počítaču A. rovnaký zdrojový kód systému, ktorý sa tradične nachádza v priečinku „/ adresár usr / src ". Používatelia spustení na počítači A majú prístup k súborom umiestneným na počítači B pomocou bežnej syntaxe zápisu názvov súborov (napríklad: „/usr/src/cmd/login.c“) a samotné jadro rozhodne, či je súbor vzdialený alebo lokálny . Používatelia spustení na počítači B majú prístup k svojim miestnym súborom (nevedia, že používatelia počítača A majú prístup k rovnakým súborom), ale zase nemajú prístup k súborom umiestneným na počítači A. Samozrejme sú možné aj ďalšie možnosti v najmä tie, v ktorých sú všetky vzdialené systémy namontované v koreňovom adresári lokálneho systému, aby mali používatelia prístup ku všetkým súborom vo všetkých systémoch.

Obrázok 13.10. Systémy súborov po vzdialenom pripojení

Podobnosti medzi pripojením lokálnych súborových systémov a povolením prístupu k vzdialeným súborovým systémom si vyžiadali prispôsobenie funkcie pripojenia vzdialeným súborovým systémom. V tomto prípade má jadro k dispozícii tabuľku pripojenia rozšíreného formátu. Vykonaním funkcie pripojenia jadro zorganizuje sieťové pripojenie so vzdialeným počítačom a do tabuľky pripojenia uloží informácie charakterizujúce toto pripojenie.

Zaujímavý problém súvisí s názvami ciest, ktoré obsahujú „..“. Ak proces vytvára aktuálny adresár zo vzdialeného súborového systému, potom použitie znakov „..“ v názve pravdepodobne vráti proces do lokálneho súborového systému, a nie k súborom nad aktuálnym adresárom. Vrátime sa znova k obrázku 13.10 a všimnite si, že keď proces patriaci stroju A, ktorý predtým vybral aktuálny adresár " / usr / src / cmd" umiestnený vo vzdialenom súborovom systéme, vykoná príkaz

aktuálny adresár bude koreňový adresár patriaci stroju A, nie stroju B. Algoritmus namei spustený v jadre vzdialeného systému po prijatí postupnosti znakov „..“ skontroluje, či je proces volania agentom proces klienta, a ak áno, nastaví, či klient považuje aktuálny pracovný adresár za koreň vzdialeného systému súborov.

Komunikácia so vzdialeným počítačom má jednu z dvoch foriem: volanie na diaľku alebo volanie funkcie vzdialeného systému. V prvom formulári každá procedúra jadra zaoberajúca sa indexmi kontroluje, či index ukazuje na vzdialený súbor, a ak áno, odošle požiadavku vzdialenému počítaču na vykonanie špecifikovanej operácie. Táto schéma prirodzene zapadá do abstraktnej štruktúry podpory súborových systémov rôznych typov, popísanej v záverečnej časti kapitoly 5. Prístup k vzdialenému súboru teda môže iniciovať prenos niekoľkých správ po sieti, ktorých počet je určený počtom implikovaných operácií so súborom, so zodpovedajúcim predĺžením času odozvy na požiadavku, pričom sa zohľadní čakací čas prijatý v sieti. Každá sada vzdialených operácií obsahuje aspoň akcie na uzamknutie indexu, počítanie referencií atď. Aby sa model vylepšil, boli navrhnuté rôzne optimalizačné riešenia súvisiace so spojením niekoľkých operácií do jedného dotazu (správy) a uložením najdôležitejších údajov do vyrovnávacej pamäte (cm. ).

Obrázok 13.11. Otvorenie vzdialeného súboru

Zvážte postup, ktorý otvorí vzdialený súbor "/usr/src/cmd/login.c", kde "src" je bod pripojenia. Analyzovaním názvu súboru (pomocou schémy namei-iget) jadro zistí, že súbor je odstránený, a odošle požiadavku na hostiteľský počítač, aby získal uzamknutý index. Po prijatí požadovanej odpovede lokálne jadro vytvorí kópiu indexu v pamäti zodpovedajúcej vzdialenému súboru. Potom jadro skontroluje potrebné prístupové práva k súboru (napríklad na čítanie) odoslaním ďalšej správy na vzdialený počítač. Otvorený algoritmus pokračuje v plnom súlade s plánom uvedeným v kapitole 5 a podľa potreby odosiela správy na vzdialený počítač, kým nie je algoritmus dokončený a index sa neuvoľní. Vzťah medzi dátovými štruktúrami jadra po dokončení otvoreného algoritmu je znázornený na obrázku 13.11.

Ak klient zavolá funkciu systému čítania, jadro klienta uzamkne lokálny index, vydá zámok na vzdialený index, požiadavku na čítanie, skopíruje údaje do lokálnej pamäte, vydá požiadavku na uvoľnenie vzdialeného indexu a uvoľní lokálny index. . Táto schéma je v súlade so sémantikou existujúceho jadra jednoprocesora, ale frekvencia používania siete (viacnásobné volanie každej funkcie systému) znižuje výkon celého systému. Na zníženie toku správ v sieti je však možné kombinovať viacero operácií do jednej požiadavky. V príklade s funkciou čítania môže klient odoslať serveru jednu všeobecnú požiadavku na „čítanie“ a samotný server sa rozhodne, že chytí a uvoľní index, keď je spustený. Zníženie sieťového prenosu je možné dosiahnuť aj použitím vzdialených vyrovnávacích pamätí (ako sme už diskutovali vyššie), je však potrebné dbať na to, aby funkcie systémových súborov používajúce tieto vyrovnávacie pamäte boli vykonávané správne.

V druhej forme komunikácie so vzdialeným počítačom (volanie funkcie vzdialeného systému) lokálne jadro zistí, že systémová funkcia súvisí so vzdialeným súborom, a pošle parametre špecifikované vo svojom hovore do vzdialeného systému, ktorý vykoná funkciu a vráti výsledky klientovi. Klientský počítač prijme výsledky vykonania funkcie a ukončí stav hovoru. Väčšinu systémových funkcií je možné vykonávať pomocou iba jednej sieťovej požiadavky a prijatia odpovede po primeranom čase, nie všetky funkcie však do tohto modelu zapadajú. Takže napríklad po prijatí určitých signálov jadro vytvorí súbor pre proces s názvom „jadro“ (kapitola 7). Vytvorenie tohto súboru nie je spojené s konkrétnou systémovou funkciou, ale končí vykonaním niekoľkých operácií, ako je vytvorenie súboru, kontrola povolení a vykonanie série zápisov.

V prípade funkcie otvoreného systému obsahuje požiadavka na spustenie funkcie odoslaná na vzdialený počítač časť názvu súboru, ktorá zostala po vylúčení komponentov názvu cesty vyhľadávania, ktoré odlišujú vzdialený súbor, a tiež rôzne vlajky. V predchádzajúcom príklade otvorenia súboru „/usr/src/cmd/login.c“ jadro odošle na vzdialený počítač názov „cmd/login.c“. Správa obsahuje aj poverenia, ako sú identifikačné kódy používateľov a skupín, ktoré sú potrebné na overenie povolení súborov na vzdialenom počítači. Ak je zo vzdialeného počítača prijatá odpoveď indikujúca úspešnú otvorenú funkciu, lokálne jadro stiahne bezplatný index do pamäte lokálneho počítača a označí ho ako register vzdialených súborov, uloží informácie o vzdialenom počítači a vzdialenom indexe a rutinne alokuje nový záznam v tabuľke súborov. V porovnaní so skutočným indexom na vzdialenom počítači je index vo vlastníctve lokálneho počítača formálny a neporušuje konfiguráciu modelu, ktorá je v zásade rovnaká ako konfigurácia používaná pri volaní vzdialenej procedúry (obrázok 13.11). Ak funkcia volaná procesom pristupuje k vzdialenému súboru pomocou svojho deskriptora, miestne jadro z (miestneho) indexu vie, že súbor je vzdialený, formuluje požiadavku, ktorá obsahuje volanú funkciu, a odošle ju na vzdialený počítač. Žiadosť obsahuje ukazovateľ na vzdialený index, pomocou ktorého môže satelitný proces identifikovať samotný vzdialený súbor.

Po prijatí výsledku vykonania akejkoľvek systémovej funkcie sa jadro môže uchýliť k službám špeciálneho programu na jeho spracovanie (po dokončení ktorého jadro skončí s touto funkciou), pretože lokálne spracovanie výsledkov sa používa v systéme s jedným procesorom. nie je vždy vhodný pre systém s niekoľkými procesormi. V dôsledku toho sú možné zmeny v sémantike systémových algoritmov zamerané na poskytnutie podpory pri vykonávaní funkcií vzdialeného systému. V sieti však súčasne cirkuluje minimálny tok správ, čo zaisťuje minimálny čas odozvy systému na prichádzajúce požiadavky.

13.4 DISTRIBUOVANÝ MODEL BEZ PRENOSOVÝCH PROCESOV

Použitie prenosových procesov (satelitných procesov) v transparentnom distribuovanom systéme uľahčuje sledovanie odstránených súborov, ale tabuľka procesov vzdialeného systému je preťažená satelitnými procesmi, ktoré sú väčšinu času nečinné. V iných schémach sa na spracovanie vzdialených požiadaviek používajú špeciálne serverové procesy (pozri a). Vzdialený systém má množinu (oblasť) serverových procesov, ktoré z času na čas priradí na spracovanie prichádzajúcich vzdialených požiadaviek. Po spracovaní požiadavky sa proces servera vráti do oblasti a vstúpi do stavu pripraveného na spracovanie ďalších požiadaviek. Server nezachováva užívateľský kontext medzi dvoma hovormi, pretože môže spracovávať požiadavky z niekoľkých procesov naraz. Preto každá správa pochádzajúca z klientskeho procesu musí obsahovať informácie o jeho prostredí vykonávania, a to: identifikačné kódy používateľa, aktuálny adresár, signály atď.

Keď proces otvorí vzdialený súbor, vzdialené jadro priradí index ďalším odkazom na súbor. Miestny počítač má vlastnú tabuľku deskriptorov súborov, tabuľku súborov a indexovú tabuľku s pravidelnou sadou záznamov, pričom záznam v indexovej tabuľke identifikuje vzdialený počítač a vzdialený index. V prípadoch, keď systémová funkcia (napríklad čítanie) používa deskriptor súborov, jadro odošle správu smerujúcu na predtým priradený vzdialený index a prenesie informácie súvisiace s procesom: identifikačný kód používateľa, maximálna veľkosť súboru atď., Stroj má Serverový proces, ktorý má k dispozícii, má interakcia s klientom vyššie opísanú formu, spojenie medzi klientom a serverom sa však vytvorí iba na dobu fungovania systému.

Používanie serverov namiesto satelitných procesov môže sťažiť správu dátovej prevádzky, signálov a vzdialených zariadení. Veľký počet požiadaviek na vzdialený počítač pri absencii dostatočného počtu serverov by mal byť zaradený do poradia. To vyžaduje protokol vyššej vrstvy, ako je protokol používaný v hlavnej sieti. V satelitnom modeli je naopak presýtenie eliminované, pretože všetky požiadavky klientov sú spracovávané synchrónne. Klient môže mať vybavenú maximálne jednu žiadosť.

Spracovanie signálov, ktoré prerušujú výkon systémovej funkcie, je tiež komplikované pri použití serverov, pretože vzdialený počítač musí vyhľadať príslušný server, ktorý slúži na výkon funkcie. Je dokonca možné, že kvôli zaneprázdnenosti všetkých serverov je požiadavka na funkciu systému v stave čakania na spracovanie. Podmienky pre vznik konkurencie tiež vznikajú, keď server vráti výsledok systémovej funkcie volajúcemu procesu a odpoveď servera zahŕňa odoslanie zodpovedajúcej signalizačnej správy prostredníctvom siete. Každá správa musí byť označená, aby ju vzdialený systém mohol rozpoznať a v prípade potreby ukončiť procesy servera. Pri použití satelitov sa automaticky identifikuje proces, ktorý zvláda splnenie požiadavky klienta, a v prípade príchodu signálu nie je ťažké skontrolovať, či je požiadavka dokončená alebo nie.

Nakoniec, ak systémová funkcia volaná klientom spôsobí, že sa server pozastaví na neurčito (napríklad pri čítaní údajov zo vzdialeného terminálu), server nemôže spracovať ďalšie požiadavky na uvoľnenie oblasti serverov. Ak k vzdialeným zariadeniam pristupuje niekoľko procesov naraz a počet serverov je zhora obmedzený, existuje celkom hmatateľné úzke miesto. Pri satelitoch sa to nestane, pretože ku každému klientskemu procesu je priradený satelit. Ďalší problém s používaním serverov pre vzdialené zariadenia bude popísaný v cvičení 13.14.

Napriek výhodám, ktoré používanie satelitných procesov poskytuje, je potreba voľných záznamov do procesnej tabuľky v praxi taká akútna, že vo väčšine prípadov sa služby serverových procesov stále používajú na spracovanie vzdialených požiadaviek.

Obrázok 13.12. Koncepčný diagram interakcie so vzdialenými súbormi na úrovni jadra

13.5 ZÁVERY

V tejto kapitole sme uvažovali o troch schémach práce so súbormi umiestnenými na vzdialených počítačoch, pričom vzdialené systémy súborov považujeme za rozšírenie lokálneho. Architektonické rozdiely medzi týmito rozloženiami sú znázornené na obrázku 13.12. Všetky sa zase líšia od viacprocesorových systémov popísaných v predchádzajúcej kapitole v tom, že procesory tu nezdieľajú fyzickú pamäť. Systém periférnych procesorov pozostáva z úzko prepojenej sady procesorov, ktoré zdieľajú súborové prostriedky centrálneho procesora. Pripojenie typu Newcastle poskytuje skrytý („transparentný“) prístup k vzdialeným súborom, nie však pomocou jadra operačného systému, ale pomocou špeciálnej knižnice C. Z tohto dôvodu musia byť všetky programy, ktoré majú v úmysle použiť tento typ odkazu, prekompilované, čo je vo všeobecnosti vážnou nevýhodou tejto schémy. Odľahlosť súboru je indikovaná pomocou špeciálnej postupnosti znakov opisujúcich stroj, na ktorom sa súbor nachádza, a to je ďalší faktor obmedzujúci prenos programov.

V transparentných distribuovaných systémoch sa na prístup k vzdialeným súborom používa modifikácia funkcie pripojenia systému. Indexy v lokálnom systéme sú označené ako vzdialené súbory a lokálne jadro pošle vzdialenému systému správu s popisom požadovanej funkcie systému, jeho parametrov a vzdialeného indexu. Komunikácia v „transparentnom“ distribuovanom systéme je podporovaná v dvoch formách: vo forme volania na vzdialenú procedúru (na vzdialený počítač sa odošle správa obsahujúca zoznam operácií spojených s indexom) a vo forme volania na funkciu vzdialeného systému (správa popisuje požadovanú funkciu). Záverečná časť kapitoly pojednáva o problémoch spojených so spracovaním vzdialených požiadaviek pomocou satelitných procesov a serverov.

13.6 CVIČENIA

*1. Popíšte implementáciu funkcie výstupného systému v systéme s periférnymi procesormi. Aký je rozdiel medzi týmto prípadom a tým, keď sa proces ukončí po prijatí nezachyteného signálu? Ako by malo jadro ukladať obsah pamäte?

2. Procesy nemôžu ignorovať signály SIGKILL; Vysvetlite, čo sa stane v periférnom systéme, keď proces dostane taký signál.

* 3. Popíšte implementáciu funkcie systému exec v systéme s periférnymi procesormi.

*4. Ako by mal centrálny procesor rozdeľovať procesy medzi periférne procesory, aby vyrovnal celkové zaťaženie?

*5. Čo sa stane, ak periférny procesor nemá dostatok pamäte na prispôsobenie sa všetkým procesom, ktoré sú do neho načítané? Ako by sa malo vykonávať vykladanie a výmena procesov v sieti?

6. Zvážte systém, v ktorom sa odosielajú požiadavky na vzdialený súborový server, ak sa v názve súboru nachádza špeciálna predpona. Nech proces zavolá execl ("/../ sftig / bin / sh", "sh", 0); Spustiteľný súbor je na vzdialenom počítači, ale musí byť spustený v lokálnom systéme. Vysvetlite, ako je vzdialený modul migrovaný do lokálneho systému.

7. Ak správca potrebuje pridať nové počítače do existujúceho systému s pripojením, akým je Newcastle, ako je možné o tom najlepšie informovať moduly knižnice C?

*osem. Počas vykonávania funkcie exec jadro prepíše adresný priestor procesu vrátane knižničných tabuliek používaných odkazom Newcastle na sledovanie odkazov na vzdialené súbory. Po spustení funkcie si musí proces zachovať schopnosť prístupu k týmto súborom pomocou svojich starých deskriptorov. Popíšte implementáciu tohto bodu.

*deväť. Ako je uvedené v časti 13.2, volanie funkcie výstupného systému v systémoch s pripojením Newcastle má za následok odoslanie správy do sprievodného procesu, ktorý prinúti tento proces ukončiť. To sa deje na úrovni knižničných rutín. Čo sa stane, keď lokálny proces dostane signál, ktorý mu hovorí, aby ukončil režim jadra?

*desať. V systéme s odkazom na Newcastle, kde sú vzdialené súbory identifikované predponou názvu so špeciálnou predponou, ako môže užívateľ, ktorý ako komponent názvu súboru zadá „..“ (nadradený adresár), prejsť bodom vzdialeného pripojenia?

11. Z kapitoly 7 vieme, že rôzne signály spôsobujú, že proces uloží obsah pamäte do aktuálneho adresára. Čo by sa malo stať, ak je aktuálny adresár zo vzdialeného systému súborov? Akú odpoveď by ste dali, ak systém používa vzťah ako Newcastle?

*12. Aké sú dôsledky pre miestne procesy, ak sú zo systému odstránené všetky satelitné alebo serverové procesy?

*13. Zvážte, ako implementovať algoritmus prepojenia do transparentného distribuovaného systému, ktorého parametrami môžu byť dva názvy vzdialených súborov, ako aj algoritmus exec spojený s vykonaním niekoľkých interných operácií čítania. Uvažujte o dvoch formách komunikácie: vzdialené volanie procedúr a volanie funkcií vzdialeného systému.

*štrnásť. Pri prístupe k zariadeniu môže proces servera vstúpiť do stavu pozastavenia, z ktorého ho vyberie ovládač zariadenia. Prirodzene, ak je počet serverov obmedzený, systém už nebude schopný uspokojiť požiadavky miestneho počítača. Vymyslite spoľahlivú schému, pomocou ktorej nie sú všetky procesy servera pozastavené pri čakaní na dokončenie V / V súvisiacich so zariadením. Funkcia systému sa nezastaví, pokiaľ sú všetky servery zaneprázdnené.

Obrázok 13.13. Konfigurácia terminálového servera

*15. Keď sa používateľ prihlási do systému, disciplína na koncovej linke uloží informáciu, že terminál je operátorský terminál vedúci skupinu procesov. Z tohto dôvodu, keď používateľ stlačí kláves „break“ na klávesnici terminálu, všetky procesy v skupine dostanú signál prerušenia. Zvážte konfiguráciu systému, v ktorej sú všetky terminály fyzicky prepojené s jedným počítačom, ale registrácia používateľa je logicky implementovaná na iných počítačoch (obrázok 13.13). V každom prípade systém vytvorí rýchly proces pre vzdialený terminál. Ak sú požiadavky na vzdialený systém spracovávané sadou serverových procesov, všimnite si, že keď sa spustí otvorená procedúra, server prestane čakať na pripojenie. Po dokončení funkcie otvorenia sa server vráti do oblasti serverov a preruší jeho pripojenie k terminálu. Ako je signál prerušenia odoslaný stlačením klávesu „break“ na adresy procesov zahrnutých v tej istej skupine?

*16. Zdieľanie pamäte je funkcia, ktorá je súčasťou miestnych počítačov. Z logického hľadiska je možné alokovanie spoločnej oblasti fyzickej pamäte (lokálnej alebo vzdialenej) vykonať pre procesy patriace rôznym počítačom. Popíšte implementáciu tohto bodu.

* 17. Proces stránkovania a algoritmy stránkovania uvedené v kapitole 9 predpokladajú použitie lokálneho pagera. Aké zmeny by sa mali vykonať v týchto algoritmoch, aby boli schopné podporovať zariadenia na vzdialené vykladanie?

*osemnásť. Predpokladajme, že na vzdialenom počítači (alebo v sieti) dôjde k smrteľnému zlyhaniu a protokol lokálnej sieťovej vrstvy túto skutočnosť zaznamená. Vytvorte schému obnovy pre miestny systém, ktorý odosiela požiadavky na vzdialený server. Okrem toho vytvorte schému obnovy pre serverový systém, ktorý stratil kontakt s klientmi.

*19. Keď proces pristupuje k vzdialenému súboru, je možné, že proces pri hľadaní súboru prejde niekoľkými počítačmi. Vezmite si napríklad názov „ / usr / src / uts / 3b2 / os“, kde „ / usr“ je adresár patriaci stroju A, „ / usr / src“ je bod pripojenia koreňa počítača B, „ / usr / src / uts / 3b2 "je bod pripojenia koreňa počítača C. Prechádzanie viacerými počítačmi do konečného cieľa sa nazýva" multihop ". Ak však existuje priame sieťové spojenie medzi strojmi A a C, odosielanie údajov prostredníctvom zariadenia B by bolo neefektívne. Popíšte vlastnosti implementácie „multishoppingu“ v systéme s pripojením Newcastle a v „transparentnom“ distribuovanom systéme.

V súčasnej dobe majú všetky IS vyvinuté na komerčné účely distribuovanú architektúru, čo znamená použitie globálnych a / alebo lokálnych sietí.

Historicky bola architektúra súborových serverov prvou, ktorá sa rozšírila, pretože jej logika je jednoduchá a je najľahšie preniesť do takej architektúry už používané IS. Potom sa transformovala na architektúru server-klient, ktorú je možné interpretovať ako jej logické pokračovanie. Moderné systémy používané v globálnej sieti INTERNET sa týkajú hlavne architektúry distribuovaných objektov (pozri obr. III‑15 )

IS si môžeme predstaviť, že sa skladá z nasledujúcich komponentov (obr. III-16)

III.03.2. a Aplikácie na súborovom serveri.

Ide o historicky prvú distribuovanú architektúru (obr. III-17). Je organizovaný veľmi jednoducho: server obsahuje iba údaje a všetko ostatné patrí klientskemu počítaču. Pretože lokálne siete sú dosť lacné a vzhľadom na to, že s takouto architektúrou je aplikačný softvér autonómny, takáto architektúra sa dnes často používa. Môžeme povedať, že ide o variant architektúry klient-server, v ktorom sú na serveri umiestnené iba dátové súbory. Rôzne osobné počítače interagujú iba prostredníctvom spoločného úložiska údajov, preto sa programy napísané pre jeden počítač najľahšie prispôsobia takejto architektúre.

Klady:

Výhody architektúry súborového servera:

Jednoduchosť organizácie;

Nie je v rozpore s požiadavkami potrebnými na zachovanie integrity a spoľahlivosti databázy.

Preťaženie siete;

Nepredvídateľná odpoveď na požiadavku.

Tieto nevýhody sú vysvetlené skutočnosťou, že každá požiadavka na databázu vedie k prenosu značného množstva informácií cez sieť. Ak napríklad chcete vybrať jeden alebo niekoľko riadkov z tabuliek, celá tabuľka sa stiahne do klientskeho počítača a DBMS už tam vyberie. Významná sieťová prevádzka je spojená najmä s organizáciou vzdialeného prístupu k databáze.

III.03.2. b Aplikácie klient-server.

V tomto prípade dochádza k rozdeleniu zodpovednosti medzi server a klienta. Podľa toho, ako sú oddelené, rozlišujte tučný a tenký klient.

V modeli tenkého klienta sa všetka práca s aplikáciami a správa údajov vykonáva na serveri. Užívateľské rozhranie v týchto systémoch „migruje“ do osobného počítača a samotná softvérová aplikácia plní funkcie servera, t.j. spúšťa všetky aplikačné procesy a spravuje údaje. Model tenkého klienta je možné implementovať aj tam, kde sú klientmi počítače alebo pracovné stanice. Na sieťových zariadeniach je spustený internetový prehliadač a používateľské rozhranie implementované v systéme.

Hlavná chyba modely tenkých klientov - vysoké zaťaženie servera a siete. Všetky výpočty sa vykonávajú na serveri, čo môže viesť k významnej sieťovej prevádzke medzi klientom a serverom. V moderných počítačoch je dostatok výpočtového výkonu, ale v modeli / tenkom klientovi banky sa prakticky nepoužíva

Naproti tomu hrubý klientský model využíva výpočtový výkon lokálnych počítačov: samotná aplikácia je umiestnená na klientskom počítači. Príkladom tohto typu architektúry sú bankomatové systémy, v ktorých je bankomat klient a server je centrálny počítač obsluhujúci databázu zákazníckych účtov.

III.03.2. c Dvoj a trojvrstvová architektúra klient-server.

Všetky vyššie uvedené architektúry sú dvojstupňové. Rozlišujú medzi úrovňou klienta a servera. Stručne povedané, IC pozostáva z troch logických úrovní:

· Užívateľská úroveň;

Úroveň aplikácie:

· Dátová vrstva.

Preto v dvojúrovňovom modeli, kde sú zahrnuté iba dve úrovne, existujú problémy so škálovateľnosťou a výkonom, ak je zvolený model tenkého klienta, alebo problémy so správou systému, ak je zvolený model hrubého klienta. Týmto problémom sa dá vyhnúť, ak použijeme model pozostávajúci z troch úrovní, kde dve z nich sú servery (obr. III-21).

Dátový server

V skutočnosti môžu byť aplikačný server a dátový server umiestnené na tom istom počítači, ale nemôžu navzájom vykonávať funkcie. Na trojúrovňovom modeli je dobré, že logicky oddeľuje výkon aplikácie a správu údajov.

Tabuľka III-5 Aplikácia rôznych typov architektúr

Architektúra	Aplikácia
Dvojúrovňový tenký klient	1 Staršie systémy, v ktorých nie je vhodné oddeľovať výkon aplikácií a správu údajov. 2 Vypočítajte náročné aplikácie s malou správou údajov. 3 Aplikácie s veľkým objemom údajov, ale malým počtom výpočtov.
Dvojúrovňový hrubý klient	1 Aplikácie, kde používateľ vyžaduje intenzívne spracovanie údajov, tj. Vizualizáciu údajov. 2 Aplikácie s relatívne konštantnou sadou užívateľských funkcií aplikované na dobre spravované systémové prostredie.
Trojúrovňový server-klient	1 Veľké aplikácie s bunkami a tisíckami klientov 2 Aplikácie, v ktorých sa údaje aj metódy spracovania často menia. 3 Aplikácie, ktoré integrujú údaje z viacerých zdrojov.

Tento model je vhodný pre mnoho typov aplikácií, ale obmedzuje vývojárov IS, ktorí sa musia rozhodnúť, kde budú poskytovať služby, poskytovať podporu škálovateľnosti a vyvíjať nástroje na spájanie nových zákazníkov.

III.03.2. d Architektúra distribuovaných objektov.

Obecnejší prístup poskytuje architektúra distribuovaných objektov, ktorej hlavnými komponentmi sú objekty. Prostredníctvom svojich rozhraní poskytujú súbor služieb. Ostatné objekty odosielajú požiadavky bez rozdielu medzi klientom a serverom. Objekty môžu byť umiestnené na rôznych počítačoch v sieti a interagovať prostredníctvom middlewaru, podobne ako systémová zbernica, ktorá vám umožňuje pripojiť rôzne zariadenia a udržiavať komunikáciu medzi hardvérovými zariadeniami.

…

Správca ovládačov ODBC

Vodič 1

Vodič K.

DB 1

DB K

Práca s SQL

…

Architektúra ODBC obsahuje komponenty:

1. Aplikácia (napr. IS). Vykonáva úlohy: požaduje pripojenie k zdroju údajov, odosiela dopyty SQL do zdroja údajov, popisuje úložnú oblasť a formát pre dotazy SQL, spracováva chyby a upozorňuje na ne používateľa, potvrdzuje alebo vracia transakcie, požaduje pripojenie k dátový zdroj.

2. Správca zariadení. Načíta ovládače na požiadanie aplikácií, ponúka jediné rozhranie pre všetky aplikácie a administrátorské rozhranie ODBC je rovnaké a bez ohľadu na to, s akým DBMS bude aplikácia interagovať. Microsoft Driver Driver je dynamicky načítateľná knižnica DLL.

3. Ovládač závisí od systému DBMS. Ovládač ODBC je dynamická knižnica (DLL), ktorá implementuje funkcie ODBC a interaguje so zdrojom údajov. Ovládač je program, ktorý spracuje požiadavku na funkciu špecifickú pre DBMS (môže upravovať požiadavky v súlade s DBMS) a vráti výsledok aplikácii. Každý DBMS, ktorý podporuje technológiu ODBC, musí vývojárom aplikácií poskytnúť ovládač pre tento DBMS.

4. Zdroj údajov obsahuje kontrolné informácie určené používateľom, informácie o zdroji údajov a slúži na prístup k určitému systému DBMS. V tomto prípade sa používajú prostriedky operačného systému a sieťovej platformy.

Dynamický model

Tento model predpokladá mnoho aspektov, ktoré sú v jazyku UML reprezentované pomocou najmenej 5 diagramov, pozri s. 2,04,2- 2,04,5.

Zvážte aspekt riadenia. Model riadenia dopĺňa štrukturálne modely.

Bez ohľadu na to, ako je popísaná štruktúra systému, pozostáva zo súboru štruktúrnych jednotiek (funkcií alebo predmetov). Aby fungovali ako celok, musia byť spravované a v statických diagramoch nie sú žiadne kontrolné informácie. Riadiace modely navrhujú tok riadenia medzi systémami.

V softvérových systémoch existujú dva hlavné typy riadenia.

1. Centralizované riadenie.

2. Správa podľa udalostí.

Centralizovaná správa môže byť:

· Hierarchické- na základe princípu „návratnosti hovoru“ (takto vzdelávacie programy najčastejšie fungujú)

· Dispečerský model ktorý sa používa pre paralelné systémy.

V. modely dispečerov predpokladá sa, že jednou zo súčastí systému je dispečer. Riadi spúšťanie a vypínanie systémov a koordináciu zvyšku systému. Procesy môžu bežať navzájom paralelne. Proces je program, subsystém alebo procedúra, ktorá je práve spustená. Tento model je možné použiť aj v sekvenčných systémoch, kde riadiaci program volá jednotlivé subsystémy v závislosti od niektorých stavových premenných (prostredníctvom operátora prípad).

Manažment udalostí predpokladá absenciu akéhokoľvek podprogramu zodpovedného za riadenie. Ovládanie sa vykonáva pomocou externých udalostí: stlačením tlačidla myši, stlačením klávesnice, zmenou hodnôt snímača, zmenou hodnôt časovača atď. Každá externá udalosť je zakódovaná a umiestnená vo fronte udalostí. Ak je poskytnutá reakcia na udalosť vo fronte, zavolá sa postup (podprogram), ktorý vykoná reakciu na túto udalosť. Udalosti, na ktoré systém reaguje, sa môžu vyskytnúť buď v iných subsystémoch, alebo vo vonkajšom prostredí systému.

Príkladom takejto správy je organizácia aplikácií vo Windows.

Všetky vyššie popísané štrukturálne modely je možné implementovať pomocou centralizovanej správy alebo správy založenej na udalostiach.

Používateľské rozhranie

Pri vývoji modelu rozhrania by ste mali vziať do úvahy nielen úlohy navrhnutého softvéru, ale aj vlastnosti mozgu súvisiace s vnímaním informácií.

III.03.4. Psychofyzické vlastnosti osoby súvisiace s vnímaním a spracovaním informácií.

Časť mozgu, ktorú možno konvenčne nazvať procesorom vnímania, neustále, bez účasti vedomia, spracováva prichádzajúce informácie, porovnáva ich s minulou skúsenosťou a ukladá ich.

Keď vizuálny obraz upúta našu pozornosť, informácie, ktoré nás zaujímajú, sa dostanú do krátkodobej pamäte. Ak našu pozornosť nepriťahovali, informácie v úložisku zmiznú a nahradia ich nasledujúce časti.

V každom okamihu môže byť zameranie pozornosti fixované v jednom bode, takže ak je potrebné súčasne sledovať niekoľko situácií, zameranie sa pohybuje od jedného sledovaného objektu k druhému. Pozornosť je zároveň rozptýlená a niektoré detaily môžu byť prehliadané. Je tiež dôležité, že vnímanie je do značnej miery založené na motivácii.

Pri zmene rámca je mozog na chvíľu zablokovaný: zvládne nový obraz a zvýrazní najpodstatnejšie detaily. To znamená, že ak potrebujete rýchlu odpoveď od používateľa, nemali by ste obrázky náhle meniť.

Krátkodobá pamäť je prekážkou v systéme spracovania informácií o osobe. Jeho kapacita je 7 ± 2 neprepojené objekty. Nenárokované informácie sú v ňom uložené maximálne 30 sekúnd. Aby sme nezabudli na žiadne pre nás dôležité informácie, zvyčajne si ich zopakujeme a aktualizujeme informácie v krátkodobej pamäti. Pri navrhovaní rozhraní teda majte na pamäti, že drvivej väčšine je napríklad ťažké zapamätať si a zadávať čísla obsahujúce viac ako päť číslic na inej obrazovke.

Napriek tomu, že kapacita a doba úložiska dlhodobej pamäte je neobmedzená, prístup k informáciám nie je jednoduchý. Mechanizmus získavania informácií z dlhodobej pamäte má asociatívny charakter. Aby sa zlepšilo zapamätanie informácií, sú viazané na údaje, ktoré už pamäť ukladá, a uľahčuje ich získanie. Pretože prístup k dlhodobej pamäti je ťažký, odporúča sa neočakávať, že si používateľ informácie zapamätá, ale že ich rozpozná.

III.03.4. b Základné kritériá pre vyhodnocovanie rozhraní

Početné prieskumy a prieskumy popredných firiem zaoberajúcich sa vývojom softvéru ukázali, že používatelia oceňujú rozhranie:

1) jednoduchosť učenia sa a zapamätávania - konkrétne odhadnite čas zvládnutia a dobu uchovávania informácií a pamäte;

2) rýchlosť dosahovania výsledkov pri používaní systému, ktorá je určená počtom príkazov a nastavení zadaných alebo vybratých myšou;

3) subjektívna spokojnosť s prevádzkou systému (jednoduchosť použitia, únava atď.).

Navyše pre profesionálnych používateľov, ktorí neustále pracujú s rovnakým balíkom, je druhé a tretie kritérium rýchlo na prvom mieste a pre neprofesionálnych používateľov, ktorí pravidelne pracujú so softvérom a vykonávajú relatívne jednoduché úlohy - prvý a tretí.

Z tohto hľadiska majú dnes rozhrania s bezplatnou navigáciou najlepšie vlastnosti pre profesionálnych používateľov a rozhrania s priamou manipuláciou pre neprofesionálnych používateľov. Dlho sa pozorovalo, že pri kopírovaní súborov, pričom všetky ostatné veci sú rovnaké, väčšina profesionálov používa škrupiny ako Far, zatiaľ čo neprofesionáli používajú Windows „drag and drop“.

III.03.4. c Typy používateľských rozhraní

Rozlišujú sa nasledujúce typy používateľských rozhraní:

Primitívne

Bezplatná navigácia

Priama manipulácia.

Rozhranie je primitívne

Primitívne nazýva sa rozhranie, ktoré organizuje interakciu s používateľom a používa sa v konzolovom režime. Jedinou odchýlkou ​​od sekvenčného procesu, ktorý údaje poskytujú, je opakovanie viacerých súborov údajov.

Rozhranie ponuky.

Na rozdiel od primitívneho rozhrania umožňuje užívateľovi vybrať operáciu zo špeciálneho zoznamu zobrazeného programom. Tieto rozhrania zahŕňajú implementáciu mnohých scenárov práce, ktorých postupnosť akcií určuje používateľ. Organizácia ponúk podobná stromom naznačuje, že nájsť položku vo viac ako dvojúrovňových ponukách je náročné.

AggreGate je jednou z prvých platforiem IoT na svete, ktorá skutočne podporuje distribuovanú architektúru. To poskytuje neobmedzenú škálovateľnosť na vyváženie a oddelenie všetkých operácií servera AggreGate na rôznych úrovniach. Takáto architektúra môže byť základom pre súčasné výzvy i budúce potreby.

Na rozdiel od záložného klastra sú servery AggreGate v distribuovanej architektúre úplne nezávislé. Každý server má svoju vlastnú databázu, lokálne používateľské účty a súvisiace povolenia.

Distribuovaná architektúra AggreGate je mimoriadne flexibilná. Technicky je založený na vytváraní peer-to-peer spojení medzi servermi a pripájaní častí jedného dátového modelu niektorých serverov („dodávateľov“) k iným („spotrebiteľom“).

Ciele distribuovaných operácií

Hlavné ciele distribuovanej architektúry sú:

• Škálovateľnosť... Servery nižšej úrovne môžu byť veľmi zaťažené, zbierajú údaje a spravujú veľký počet zariadení takmer v reálnom čase. V praxi je však počet zariadení, na ktorých je možné spravovať jeden server, obmedzený na niekoľko tisíc. Pri škálovaní systému na správu veľkého počtu zariadení je rozumné nastaviť viac serverov a kombinovať ich v distribuovanej inštalácii.
• Rozdelenie výkonu... Každý server v distribuovanej inštalácii rieši iný problém. Servery na správu siete kontrolujú dostupnosť a výkonnosť sieťovej infraštruktúry, zatiaľ čo servery na riadenie prístupu spracúvajú požiadavky od ovládačov dverí a turniketov. Riadiace operácie, ako je generovanie správ a ich distribúcia poštou, je možné vykonávať na centrálnom serveri.
• Ochrana pred vniknutím... Sekundárne servery sond môžu byť inštalované na vzdialených miestach a pripojené k centrálnemu serveru. Operátori systému sa pripájajú iba k centrálnemu serveru, čím sa eliminuje potreba konfigurovať VPN a presmerovanie portov na tieto servery.
• Centralizácia... Sekundárne servery môžu pracovať v plne automatickom režime, pričom ich konfigurácia a monitorovanie sa vykonáva prostredníctvom hlavného servera nainštalovaného v centrálnej riadiacej miestnosti.

Distribúcia rolí servera

V tomto jednoduchom scenári sú dva servery kombinované do distribuovanej infraštruktúry. Prevádzkovatelia systému sú neustále pripojení k monitorovaciemu serveru a vykonávajú svoje každodenné povinnosti. Vedenie spoločnosti sa pripojí k serveru prehľadov a analytiky, keď potrebuje získať kúsok údajov. Bez ohľadu na množstvo údajov a zaťaženie servera táto operácia neovplyvní prácu operátorov.

Cloudová platforma IoT vo veľkom

Poskytovatelia telekomunikačných a cloudových služieb ponúkajú služby IoT v modeloch IaaS / PaaS / SaaS. V týchto prípadoch hovoríme o miliónoch zariadení, ktoré vlastnia tisíce používateľov. Udržiavanie takej obrovskej infraštruktúry vyžaduje stovky serverov AggreGate, z ktorých väčšinu možno rozdeliť do dvoch skupín:

• Servery, ktoré uchovávajú register používateľov a ich zariadení, presmerovávajú pripojenia operátorov a zariadení na servery nižšej úrovne, ako aj agregujú údaje pre následnú analýzu informácií za účasti serverov nižšej úrovne
• Servery, ktoré monitorujú a spravujú zariadenia, ako aj prijímajú, ukladajú a spracúvajú údaje

Servery na správu používateľov a zariadení sú zodpovedné aj za interakciu so systémom cloudovej správy, ktorý je zodpovedný za nasadenie a monitorovanie nových serverov úložiska a analýzy.

Servery na ukladanie a spracovanie údajov používajú zdroje (alarmy, modely, pracovné toky, dashboardy atď.) Prijaté zo serverov šablón, ktoré zase ukladajú kmeňové kópie týchto zdrojov.

Vrstvená IoT infraštruktúra

Vďaka distribuovanej infraštruktúre AggreGate môže akékoľvek riešenie zahŕňať mnoho serverov rôznych úrovní. Niektoré z nich môžu pracovať na bránach IoT, zhromažďovať údaje, iné - ukladať a spracovávať informácie a ostatné - vykonávať agregáciu na vysokej úrovni a distribuované výpočty.

Terénne zariadenia, ako sú senzory a akčné členy, je možné pripojiť k serverom priamo, prostredníctvom agentov, prostredníctvom brán alebo ich kombináciou.

Inteligentné riadenie mesta

Toto je príklad vrstvenej architektúry na báze AggreGate pre komplexnú automatizáciu veľkej skupiny budov:

• Úroveň 1: fyzické zariadenie (sieťové smerovače, regulátory, priemyselné zariadenia atď.)
• Úroveň 2: servery pre správu (servery na monitorovanie siete, servery na riadenie prístupu, servery na automatizáciu budov a ďalšie)
• Úroveň 3: vybudovanie stredísk riadenia serverov (jeden server na budovu, ktorý zbiera informácie zo všetkých serverov druhej úrovne)
• Úroveň 4: servery mestskej časti (konečný cieľ eskalácie upozornení nižšej úrovne, monitorovanie v reálnom čase, integrácia so systémami Service Desk)
• Úroveň 5: servery ústredia (kontrola okresných serverov, zber a syntéza správ, oznámenia)

Ktorýkoľvek z vyššie uvedených serverov môže byť klastrom s podporou prevodu pri zlyhaní viacerých uzlov.

Viacsegmentová správa siete

AggreGate Network Manager je postavený na platforme AggreGate a je typickým prípadom použitia pre distribuovanú architektúru. Veľké segmentované siete spoločností a telekomunikačných operátorov nie je možné monitorovať z jedného centra z dôvodu obmedzení smerovania, bezpečnostných politík alebo obmedzení šírky pásma prepojení na segmenty vzdialených sietí.

Distribuovaný monitorovací systém sa teda obvykle skladá z nasledujúcich komponentov:

• Primárny alebo centrálny server, ktorý zbiera informácie zo všetkých sieťových segmentov
• Sekundárne servery alebo sondové servery volebné zariadenia v izolovaných segmentoch
• Špecializovaný servery, ako sú servery na analýzu prevádzky, ktoré denne spracovávajú miliardy udalostí NetFlow

Sekundárne a špecializované servery sú poskytovateľmi informácií na primárnom serveri a časť svojho dátového modelu vystavujú riadiacemu centru. Môže to byť:

• Celý obsah kontextového stromu servera sondy, ktorý umožňuje úplnú kontrolu konfigurácie z centrálneho servera. V tomto prípade sa server sondy jednoducho použije ako server proxy na prekonanie problému so segmentáciou siete.
• Výstrahy generované serverom sondy. V takom prípade môže byť 99% pracovísk vzdialených a operátor centrálneho servera bude okamžite dostávať oznámenia zo sekundárnych serverov.
• Vlastné množiny údajov zo serverov sond, ako sú napríklad informácie o stave kritických zariadení v reálnom čase alebo súhrnné správy. Všetky súvisiace práce budú vykonávané na sekundárnom serveri, čo umožní vyváženie záťaže.

Vysoko výkonný manažment udalostí

Niektoré prípady použitia platformy AggreGate, ako napríklad centralizovaná správa incidentov, vyžadujú prijatie, spracovanie a trvalé uloženie značného počtu udalostí v štruktúrovanom formáte. Niekedy toky môžu dosiahnuť objemy miliónov udalostí za sekundu a prijatých z rôznych zdrojov.

V takýchto prípadoch jeden server AggreGate nezvládne celý tok udalostí. Distribuovaná architektúra pomôže zorganizovať spracovanie udalostí:

• Na objekty generujúce udalosti je nainštalovaných niekoľko miestnych serverov, ktoré tieto udalosti spracovávajú. K jednému spracovateľskému serveru sa môže pripojiť niekoľko zdrojov (sond).
• Dedikovaný úložný server alebo klaster veľkých dátových úložísk s viacerými servermi je viazaný na každý lokálny server spracovania. Počet klastrových uzlov sa môže líšiť v závislosti od rýchlosti generovania udalostí.
• Všetky lokálne úložné servery vykonávajú predbežné filtrovanie, deduplikáciu, koreláciu (pomocou pravidiel platných pre lokálne pripojené sondy), obohacovanie a ukladanie udalostí.
• Lokálne úložné servery sa pripájajú k centrálnemu agregačnému serveru. Agregačný server je zodpovedný za koreláciu dôležitých udalostí v celom systéme.
• Centrálni operátori serverov môžu prehľadávať celú databázu udalostí, pričom úlohy zisťovania živých dát sú distribuované medzi úložné servery. Preto je možné vytvárať centralizované hlásenia a výstrahy na základe databázy pre všetky udalosti.

Digitálny podnik

AggreGate môže fungovať ako koordinačná platforma pre digitálne podnikanie. Každý zo serverov AggreGate môže vykonávať rôzne funkcie, od monitorovania a správy vzdialených objektov až po služby na vysokej úrovni, ako je business intelligence alebo napríklad správa incidentov.

Všetky servery v digitálnom podniku sú navzájom prepojené prostredníctvom distribuovanej infraštruktúry. Servery nižšej úrovne poskytujú prístup k niektorým kontextom jedného dátového modelu k serverom vyššej úrovne, čo vám umožňuje vytvoriť situačné centrum pre celý podnik.

(Materiál stránok http://se.math.spbu.ru)

Úvod.

V dnešnej dobe sú distribuované prakticky všetky veľké softvérové ​​systémy. Distribuovaný systém- systém, v ktorom je spracovanie informácií sústredené nie na jednom počítači, ale je distribuované medzi niekoľko počítačov. Pri návrhu distribuovaných systémov, ktorý má veľa spoločného s návrhom softvéru vo všeobecnosti, je stále potrebné vziať do úvahy niektoré špecifické funkcie.

Existuje šesť hlavných charakteristík distribuovaných systémov.

1. Zdieľanie zdrojov. Distribuované systémy umožňujú zdieľanie zdrojov hardvéru (pevné disky, tlačiarne) aj softvéru (súbory, kompilátory).
2. Otvorenosť.Je to schopnosť rozšíriť systém pridaním nových zdrojov.
3. Paralelnosť.V distribuovaných systémoch môže bežať viac procesov súčasne na rôznych počítačoch v sieti. Tieto procesy môžu interagovať, keď sú spustené.
4. Škálovateľnosť . Pod škálovateľnosť možnosť pridania nových vlastností a metód je pochopená.
5. Odolnosť proti chybám. Prítomnosť viacerých počítačov umožňuje duplikáciu informácií a odolnosť voči niektorým chybám hardvéru a softvéru. Distribuované systémy môžu podporovať čiastočné funkcie v prípade chyby. K úplnému zlyhaniu systému dochádza iba pri chybách siete.
6. Transparentnosť.Používateľom je poskytnutý plný prístup k zdrojom v systéme, pričom sú pred nimi zároveň skryté informácie o distribúcii zdrojov v celom systéme.

Distribuované systémy majú tiež množstvo nevýhod.

1. Zložitosť... Je oveľa ťažšie porozumieť a vyhodnotiť vlastnosti distribuovaných systémov vo všeobecnosti a je ťažšie ich navrhnúť, testovať a udržiavať. Výkon systému tiež závisí od rýchlosti siete, a nie od jednotlivých procesorov. Prerozdelenie zdrojov môže výrazne zmeniť rýchlosť systému.
2. Zabezpečenie... K systému je spravidla možné pristupovať z niekoľkých rôznych počítačov, správy v sieti je možné prezerať a zachytávať. V distribuovanom systéme je preto oveľa ťažšie udržať bezpečnosť.
3. Ovládateľnosť... Systém môže pozostávať z rôznych typov počítačov, na ktoré je možné nainštalovať rôzne verzie operačných systémov. Chyby na jednom počítači sa môžu nepredvídateľným spôsobom rozšíriť na iné počítače.
4. Nepredvídateľnosť ... Reakcia distribuovaných systémov na niektoré udalosti je nepredvídateľná a závisí od úplného zaťaženia systému, jeho organizácie a zaťaženia siete. Pretože sa tieto parametre môžu neustále meniť, čas odozvy na požiadavku sa preto môže výrazne líšiť od času.

Z týchto nedostatkov vidíte, že pri navrhovaní distribuovaných systémov vzniká množstvo problémov, s ktorými musia vývojári počítať.

1. Identifikácia zdroja ... Zdroje v distribuovaných systémoch sú umiestnené na rôznych počítačoch, preto by ste mali premyslieť systém pomenovania zdrojov, aby používatelia mali ľahký prístup k zdrojom, ktoré potrebujú, a odvolávali sa na ne. Príkladom je systém URL (Uniform Resource Locator), ktorý definuje názvy webových stránok.
2. Komunikácia... Univerzálna prevádzkyschopnosť internetu a efektívna implementácia protokolov TCP / IP na internete pre väčšinu distribuovaných systémov sú príkladmi najúčinnejšieho spôsobu organizácie komunikácie medzi počítačmi. V niektorých prípadoch, kde je potrebný špeciálny výkon alebo spoľahlivosť, je však možné použiť špecializované nástroje.
3. Kvalita služby systému ... Tento parameter odráža výkon, zdravie a spoľahlivosť. Kvalitu služby ovplyvňuje niekoľko faktorov: distribúcia procesov, zdrojov, hardvéru a adaptabilita systému.
4. Softvérová architektúra ... Architektúra softvéru popisuje distribúciu systémových funkcií medzi systémové komponenty, ako aj distribúciu týchto komponentov medzi procesory. Ak potrebujete zachovať vysokú kvalitu systémových služieb, je výber správnej architektúry rozhodujúci.

Výzvou pre návrhárov distribuovaných systémov je navrhnúť softvér a hardvér tak, aby poskytoval všetky požadované vlastnosti distribuovaného systému. To si vyžaduje poznanie výhod a nevýhod rôznych architektúr distribuovaných systémov. Existujú tri typy architektúr distribuovaných systémov.

1. Architektúra klient / server ... V tomto modeli je systém možné chápať ako sadu služieb poskytovaných servermi klientom. V takýchto systémoch sa servery a klienti navzájom výrazne líšia.
2. Trojúrovňová architektúra ... V tomto modeli server neposkytuje služby klientom priamo, ale prostredníctvom servera obchodnej logiky.

O prvých dvoch modeloch už bolo povedané viac ako raz, pozrime sa podrobnejšie na tretí.

1. Architektúra distribuovaných objektov ... V tomto prípade nie sú žiadne rozdiely medzi servermi a klientmi a systém je možné chápať ako množinu interagujúcich objektov, na ktorých umiestnení v skutočnosti nezáleží. Medzi poskytovateľom služieb a ich používateľmi nie je žiadny rozdiel.

Táto architektúra je dnes široko používaná a je aj nazývaná architektúra webových služieb. Webová služba je aplikácia, ktorá je prístupná cez internet a poskytuje niektoré služby, ktorých forma je nezávislá na dodávateľovi (pretože sa používa univerzálny formát údajov - XML) a na platforme prevádzky. V súčasnosti existujú tri rôzne technológie, ktoré podporujú koncept systémov distribuovaných objektov. Ide o technológie EJB, CORBA a DCOM.

Najprv pár slov o tom, čo je XML vo všeobecnosti. XML je generický dátový formát používaný na poskytovanie webových služieb. Webové služby sú založené na otvorených štandardoch a protokoloch: SOAP, UDDI a WSDL.

1. SOAP ( Protokol Simple Object Access Protocol, vyvinutý spoločnosťou W3C, definuje formát požiadaviek na webové služby. Správy medzi webovou službou a jej používateľom sú zabalené v takzvaných obálkach SOAP (niekedy sa im hovorí aj XML obálky). Samotná správa môže obsahovať buď požiadavku na vykonanie akcie, alebo odpoveď - výsledok tejto akcie.
2. WSDL (jazyk popisu webovej služby).Rozhranie webovej služby je popísané v dokumentoch WSDL (a WSDL je podmnožinou XML). Pred nasadením služby vývojár zostaví jej popis v jazyku WSDL, uvedie adresu webovej služby, podporované protokoly, zoznam povolených operácií a formáty požiadaviek a odpovedí.
3. UDDI (univerzálny popis, zisťovanie a integrácia) - Protokol vyhľadávania webových webových služieb ( http://www.uddi.org/). Je to obchodný register, v ktorom poskytovatelia webových služieb registrujú služby a vývojári nachádzajú služby, ktoré potrebujú do svojich aplikácií zahrnúť.

Z diskusie sa môže zdať, že webové služby sú najlepším a nesporným riešením a jediná otázka je vo výbere vývojových nástrojov. Nie je to však tak. Existuje alternatíva webových služieb, Sémantický web, o ktorej pred piatimi rokmi hovoril tvorca WWW Tim Berners-Lee.

Ak je cieľom webových služieb uľahčenie komunikácie medzi aplikáciami, potom je sémantický web navrhnutý tak, aby vyriešil oveľa komplexnejší problém - pomocou mechanizmov metadát zvýšenia efektivity hodnoty informácií, ktoré je možné nájsť na webe. To sa dá dosiahnuť opustením prístupu orientovaného na dokumenty v prospech objektovo orientovaného prístupu.

Bibliografia

1. SomervilleI. Softvérové ​​inžinierstvo.
2. Dranitsa A. Java vs. .NET. - „Computerra“, č. 516.
3. Internetové zdroje.