temelji se na rekonfigurabilnom računalnom okruženju s više cjevovoda L-Net

Jedan od hitnih zadataka na području upravljačkih sustava je razvoj softvera za distribuirane upravljačke sustave otporne na greške. Rješenja koja postoje na ovom području danas vlasnička su, stoga su skupa i nisu uvijek učinkovita.

Ova rješenja ne omogućuju učinkovito korištenje resursa suvišnih baza, tehničkog i softverskog, što negativno utječe i na toleranciju grešaka i na skalabilnost takvih rješenja. Ako je narušena mrežna arhitektura, ne postoji mogućnost dinamičke rekonfiguracije procesa obrade informacija i prijenosa tokova podataka (i upravljačkih i informacijskih). Korištenje posebnih mikrokontrolera, uporaba DCS / SCADA komplicira razvoj i podršku sustavima, proširenje njihove funkcionalnosti.

Arhitektura distribuiranog upravljačkog sustava

Opća tipična arhitektura distribuiranog upravljačkog sustava (DCS) uključuje tri hijerarhijski povezane razine: razinu operatora, razinu upravljanja i razinu U / I (vidi sliku 1).

Glavni zadatak razine operatera je osigurati sučelje čovjek-stroj (HMI) kako bi se osigurala konfiguracija i kontrola rada cijelog sustava. Kontrolna razina odgovorna je za primanje i obradu podataka sa senzora, prijenos podataka na razinu operatora i generiranje kontrolnih radnji na aktuatorima. I / O razina predstavlja senzore i aktuatore izravno spojene na upravljački objekt.

Zadaća softvera, u okviru generalizirane arhitekture DCS -a, je osigurati funkcioniranje razine operatora i njegovu povezanost s upravljačkom razinom sustava. Slijedom toga, temeljna razina u dizajnu softvera i rješavanju pitanja njegove interakcije s hardverom je ona operatora. Softver bi trebao maksimalno iskoristiti dostupne hardverske resurse sustava, a pritom biti što neovisniji o unutarnjoj arhitekturi hardvera.

Hardver pruža računalne resurse, memoriju i komunikacijske medije između čvorova u sustavu. Prilikom projektiranja opće arhitekture sustava, posebni čvorovi I / O razine koji će biti povezani s njim u određenoj izvedbi ne uzimaju se u obzir, pa se razina operatora i razina upravljanja razmatraju u generaliziranoj arhitekturi. Hardver mora biti široko rasprostranjen, u skladu sa suvremenim standardima i imati sva svojstva i sposobnosti potrebne za implementaciju arhitekture.

DCS zahtjevi

Zahtjevi za DCS ne odnose se samo na sustav u cjelini, već i na njegove hardverske i softverske komponente zasebno, budući da se posebni pristupi ispunjavanju ovih zahtjeva za ove komponente mogu bitno razlikovati. DCS bi trebao biti, prije svega, otporan na greške. Najjednostavniji način povećanja tolerancije grešaka je redundancija (dupliciranje) funkcionalnih jedinica ili njihovog agregata. Drugo važno svojstvo je skalabilnost. Skalabilnost se temelji na implementaciji posebnih algoritama u softveru i hardverskoj sposobnosti zamjene i dodavanja novih čvorova ili njihovih sastavnih dijelova. Istodobno, sustav bi trebao ostati jednostavan za rad, razvoj novih čvorova ili modula i izmjenu svoje arhitekture.

Pregled arhitektura DCS -a

Za pregled DCS arhitekture, Siemens SIMATIC PCS 7 DCS odabran je kao jedan od najtraženijih na tržištu, a RTS S3 kao DCS implementiran na temelju QNX RTOS -a.

Siemens SIMATIC PCS 7

Arhitektura sustava ima sva svojstva generičke DCS arhitekture. Operatorske stanice su računala temeljena na arhitekturi x86 procesora sa Windows OS -om i Siemens WinCC paketom koji pruža HMI. Postoje poslužitelji s bazama podataka. Operatorske stanice, inženjerske stanice i poslužitelji povezani su lokalnom mrežom zasnovanom na Ethernetu. Razina operatora povezana je s upravljačkom ravninom redundantne industrijske Ethernet mreže. Na razini upravljanja nalaze se programabilni logički kontroleri (PLC) s mogućnošću redundancije zbog dupliciranja funkcionalnosti. Moguće je povezivanje s vanjskim sustavima i mrežama te organiziranje daljinskog pristupa sustavu.

RTS S3

Ova se arhitektura na sličan način sastoji od slojeva generalizirane strukture DCS -a. Operatorske stanice temelje se na istoj hardverskoj platformi kao i u SIMATIC DCS -u, ali mogu raditi pod Windows i Linux operativnim sustavima. Inženjerske postaje kombinirane su sa stanicama operatora. Sustav pruža jedinstveno okruženje za razvoj aplikacija. Ethernet povezuje čvorove unutar nositeljskog sloja i samu razinu operatora s upravljačkom ravninom pomoću stoga TCP / IP protokola. Na kontrolnoj razini postoje industrijska računala koja izvode QNX OS sa vlastitom bazom podataka i mogućnošću redundancije dupliciranjem funkcionalnosti čvora.

Nedostaci opisanih sustava

Gore opisani sustavi koriste različitu hardversku / softversku platformu za razinu operatora i upravljačku ravninu. Unutar razine operatora može se koristiti samo jedna arhitektura procesora, a za konfiguriranje i razvoj razine upravljanja potrebna je posebna inženjerska stanica. Ovi DCS -ovi nude samo hardversku redundanciju s dupliranjem funkcionalnosti redundantnog čvora kao način za povećanje tolerancije grešaka, što je neracionalna upotreba redundantnog hardvera.

Karakteristike i funkcionalne značajke L-Net sustava

Prilikom razvoja L-Net sustava, zadatak je bio stvoriti upravljački sustav koji bi imao sljedeće karakteristike:

• Dinamička rekonfiguracija s potpunim oporavkom uz minimalne gubitke u slučaju kvara hosta ili poremećaja topologije mreže.
• Učinkovita raspodjela zadataka među dostupnim učinkovitim mrežnim čvorovima.
• Umnožavanje komunikacijskih kanala između čvorova s ​​dinamičkom rekonfiguracijom tokova prijenosa podataka.
• Jednostavnost korištenja i skalabilnost sustava.
• Prijenosnost i performanse sustava na bilo kojoj hardverskoj platformi dizajniranoj za izgradnju upravljačkih sustava i ugrađenih sustava.

Za izgradnju sustava s gore navedenim karakteristikama potreban je operacijski sustav koji je prvenstveno namijenjen stvaranju upravljačkih sustava i ugrađenih sustava. Analiza postojećih operacijskih sustava pokazala je da je najprikladniji operacijski sustav QNX 6 (Neutrino) koji ima vrlo učinkovitu raspodjelu resursa i mogućnosti mreže. Široke mogućnosti umrežavanja pružaju mrežni protokol Qnet. Rješava problem pouzdanosti i dinamičkog uravnoteženja opterećenja komunikacijskih kanala, ali ne rješava problem tolerancije grešaka sustava u cjelini. Kao rezultat toga, razvijen je inovativni sustav upravljanja temeljen na distribuiranom rekonfigurabilnom računalnom okruženju s više cjevovoda. Razvijeni sustav ima peer-to-peer arhitekturu koja uključuje tri logička bloka: ulazno-izlazni blok, prekidački blok opće namjene i blok rekonfigurabilnog računalnog okruženja (RCS) (vidi sliku 2).

Glavne prednosti ove arhitekture su:

• Vrsta peer-to-peer
• Decentralizacija
• Skalabilnost
• Prostorna raspodjela

Funkcionalne značajke ove arhitekture:

• Obrada podataka cjevovoda
• Višak hardvera
• Raspodjela opterećenja
• Rekonfiguracija u hodu

Na prvoj razini arhitekture nalazi se jedinica ulaz-izlaz (I / O), koja uključuje: ulazno-izlazne čvorove, prekidač ulazno-izlaznih čvorova, ulazno-izlazno sučelje, senzore i aktuatore. Jedinica je odgovorna za osnovne mehanizme za generiranje kontrolnih radnji na temelju podataka s lokalnih senzora i podataka primljenih s drugih razina upravljačkog sustava. Dodijeljene zadatke distribuira među zdravim I / O čvorovima na temelju njihovih trenutnih relativnih performansi ili ručno od strane operatora. Senzori i aktuatori povezani su sabirnicom na sve U / I čvorove u bloku, što omogućuje bilo kojem čvoru ispitivanje bilo kojeg senzora ili stvaranje učinka na bilo koji pogon. Prekidač I / O čvora omogućuje komunikaciju između svih I / O čvorova radi razmjene podataka između njih i drugih razina arhitekture sustava radi dobivanja upravljačkih i informacijskih podataka. Uz odgovarajuće hardverske mogućnosti, čvorovi međusobno komuniciraju, s čvorovima i prekidačima na drugim razinama sustava izravno, što smanjuje vrijeme odziva u mreži. Izravna komunikacija između čvorova i određenog opterećenja čvorova u trenutnom načinu rada U / I jedinice omogućuje organiziranje proračuna cjevovoda u jedinici, koji su potrebni za rad ove jedinice bez pribjegavanja vanjskoj računalnoj snazi ​​upravljačkog sustava ( DCS), što omogućuje učinkovito korištenje besplatnih resursa predviđenih za redundantne čvorove U / I jedinice u trenutku kvara.

Blok prekidača opće namjene, koji se nalazi na drugoj razini arhitekture, organizira komunikacijske linije između ulazno-izlaznih blokova i DCS-a i vanjskih sustava. Svaki prekidač može međusobno povezati različite veze i prekidače u cijelom upravljačkom sustavu. Broj komunikacijskih linija određen je hardverskim mogućnostima čvorova i sklopki uključenih u blokove. Budući da vam mreža Qnet omogućuje dinamičku distribuciju protoka podataka, skaliranje ovog bloka provodi se jednostavnim povezivanjem novih uređaja i ne zahtijeva konfiguraciju, a ako jedan od prekidača ne uspije, prijenos podataka između čvorova neće se prekinuti ako drugi prekidač pruža sličnu vezu između čvorova ili su oni izravno povezani. Istodobno, potrebno je pobrinuti se za dovoljnu propusnost mreže potrebnu za sigurnosno kopiranje neuspjele sklopke.

Blok rekonfigurabilne računalne mreže (RCN), koji se nalazi na trećoj razini arhitekture, pruža sustav upravljanja visokom računalnom snagom za rješavanje složenih problema obrade informacija, odlučivanja, prepoznavanja itd. Blok je odgovoran za inicijalizaciju cijelog upravljačkog sustava: provjeru operativnosti sklopki i čvorova, integritet mreže, izgradnju mrežnih grafikona cijelog sustava, postavljanje početnih parametara za rad ulazno-izlaznih blokova. Čvorovi ovog bloka omogućuju arhiviranje vlastitih podataka i podataka iz I / O blokova. Svaki čvor ovog bloka može igrati ulogu stroja rukovatelja dizajniranog za nadzor rada sustava i prilagođavanje programa rada i ovog čvora i svih čvorova sustava, te izvršavanje rekonfiguracije na zahtjev.

Raspodjela opterećenja

Jedan od glavnih zadataka L-Net sustava je raspodjela računalnog opterećenja na čvorovima mreže. Rješenje ovog problema temelji se na izgradnji računskih cjevovoda. Za izgradnju proračunskog cjevovoda prethodno se izrađuje graf zadataka - shema za razmjenu tokova podataka od izvora do primatelja. Senzori djeluju kao izvor, a aktuatori kao primatelji. Računski cjevovod predstavlja preslikavanje grafa zadatka (vidi sliku 3) u grafikon računalne mreže (vidi sliku 4), uzimajući u obzir zahtjeve zadatka prema računalnim resursima sustava i njegovo trenutno stanje.

Rješenje je korištenje usluge koja primatelju pruža sveobuhvatne informacije o trenutnom hardveru, njegovom stanju i dostupnim izvorima podataka, koja obavlja rad s mrežnim grafikonima i zadacima. Kao rezultat toga, performanse se povećavaju zbog konsolidiranja izračuna i organizira se racionalno korištenje svih računalnih resursa koji su na raspolaganju sustavu.

tolerancija kvarova

Glavni problem funkcioniranja takvog sustava je potpuni prekid proračunskih cjevovoda u slučaju kvara bilo kojeg čvora ovog transportera ili kršenja prijenosa podataka između njih. Osnovna sredstva protokola Qnet postižu obnavljanje veza između čvorova u slučaju njihovog djelomičnog narušavanja zbog rezervnih linija koje osigurava arhitektura. Sustav L-Net rješava problem vraćanja operativnosti u slučaju potpunog kvara hosta računalnog sustava dinamičkom rekonfiguracijom računalnog cjevovoda, t.j. korištenje radnih resursa za zamjenu lošeg bloka. Sustav nudi tri scenarija oporavka (rekonfiguracije) koji se razlikuju u vremenu odziva na kvar, vremenu oporavka i upotrijebljenim hardverskim resursima: nakon kvara, s pasivnom spremnošću i aktivnom spremnošću.

• Rekonfiguracija nakon kvara- nakon što se otkrije kvar, traži se raspoloživi hardver i uključuje ga u grafikon zadataka.
• Rekonfiguracija s pasivnom spremnošću- unaprijed se utvrđuje suvišni hardver, pokreće se proces koji osigurava provedbu vrha grafa zadataka na čvoru, uspostavljaju se veze, ali proces ne obrađuje podatke osim ako glavni čvor ne uspije.
• Rekonfiguracija s aktivnom spremnošću- vrh grafikona zadatka implementiran je na nekoliko čvorova, koji paralelno izvode obradu podataka i prenose rezultat.

Kao rezultat toga, sustav pruža fleksibilnu spremnost za kvarove na softverskoj i hardverskoj razini, mogućnost promjene konfiguracije čvorova bez prekida rada i gubitka performansi bez obzira na implementaciju mreže, proračunskog cjevovoda i čvora.

Zaključak

Razvijeni sustav L-Net, za razliku od postojećih analoga, pretpostavlja korištenje širokog raspona hardverskih karakteristika DCS čvorova s ​​njihovom potpunom kompatibilnošću sa softverom. Kada čvorovi rade pod kontrolom jednog operacijskog sustava (QNX Neutrino), moguće ih je izgraditi na različitim procesorskim arhitekturama (x86, ARM, MIPS itd.) S različitim sučeljima i perifernim uređajima. Implementacija čvorova moguća je u obliku stolnih računala, industrijskih računala, prijenosnih računala i računala s jednom pločom. Sve komponente softverskog kompleksa razvijenog DCS -a mogu se pokrenuti na bilo kojem od njegovih čvorova s ​​QNX OS -om, dok je i dalje moguće koristiti čvorove s različitim operativnim sustavom. Ovaj pristup omogućuje da se svaki čvor koristi za rješavanje zadataka na razini operatora i na razini upravljanja. Slijedom toga, postoji fleksibilan sustav interakcije među kolegama bez krute hijerarhije razina svojstvene generaliziranoj DCS arhitekturi i sustavima koji tu arhitekturu koriste kao bazu. Peer-to-peer mreža pojednostavljuje procese postavljanja, rada, skaliranja i ispravljanja pogrešaka u sustavu.

Kako bi se ostvario računski potencijal redundantnog hardvera u razvijenom sustavu, predloženi su algoritmi dinamičke konfiguracije i rekonfiguracije na temelju mrežnog protokola Qnet i mrežnog softvera L-Net. Algoritam dinamičke konfiguracije temelji se na raspodjeli računarskog opterećenja na svim čvorovima postavljanjem i paraleliziranjem zadataka te dinamičkim uravnoteženjem opterećenja kanala za prijenos podataka između čvorova. Algoritam rekonfiguracije sustava pretpostavlja prisutnost tri scenarija za vraćanje operativnosti u slučaju kvara, ovisno o raspoloživom hardveru, prioritetima i zadacima dodijeljenim sustavu: nakon kvara, s pasivnom spremnošću (raspodjela resursa) i s aktivnom spremnošću (upotreba resursa) . Algoritmi dinamičke konfiguracije i rekonfiguracije poboljšavaju performanse i pouzdanost korištenjem hardverskih rezervi u sustavu.

Važna prednost sustava je maksimalna transparentnost i hardverske i softverske tehnologije koja se u njemu koristi, što omogućuje ozbiljno pojednostavljenje tehničke podrške sustava i razvoj novih modula za njega.

Zaključak

Razvijena arhitektonska rješenja omogućuju poboljšanje takvih pokazatelja distribuiranih upravljačkih sustava kao što su pouzdanost, performanse, cijena, skalabilnost i jednostavnost zbog mogućnosti korištenja širokog raspona hardvera, implementacije algoritama dinamičke konfiguracije i racionalnog korištenja resursa sustava.

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Zyl S. QNX Momentics: Osnove primjene. - SPb: BHV-Petersburg, 2005 (zbornik).
5. Krten R. Uvod u QNX Neutrino. Vodič za razvoj aplikacija u stvarnom vremenu. - SPb: BHV-Petersburg, 2011 (zbornik).

Ključne riječi: distribuirani upravljački sustav, informacijska podrška za upravljačke sustave, distribuirani rekonfigurabilni sustavi.

Arhitektura distribuiranog upravljačkog sustava temeljenog na rekonfigurabilnom višecijevnom računalnom okruženju L-Net

Sergej Yu. Potomskiy, docent Nacionalnog istraživačkog sveučilišta "Viša ekonomska škola".

Nikita A. Poloyko, student pete godine Nacionalnog istraživačkog sveučilišta "Viša ekonomska škola". Asistent na studiju. Programer. Područje izobrazbe: "Upravljanje i informatika u tehničkim sustavima".

Sažetak.Članak je posvećen distribuiranom upravljačkom sustavu koji se temelji na rekonfigurabilnom računalnom okruženju s više cjevovoda. Navedena je arhitektura sustava. Također su date osnovne karakteristike i funkcionalna svojstva sustava. Članak predstavlja obrazloženje za izbor operacijskog sustava. U članku su prikazane osnovne prednosti sustava u usporedbi s postojećim sličnim razvojima.

Ključne riječi: distribuirani sustav upravljanja, programska podrška sustava, distribuirano rekonfigurabilno.

U kontaktu s

Heterogeni multikompjuterski sustavi

Najveći broj trenutno postojećih distribuiranih sustava izgrađen je prema shemi heterogenih višeračunalnih sustava. To znači da računala koja su dio ovog sustava mogu biti vrlo različita, na primjer, po vrsti procesora, veličini memorije i performansama I / O. U praksi, ulogu nekih od ovih računala mogu odigrati paralelni sustavi visokih performansi, na primjer, višeprocesorski ili homogeni višeračunalni sustavi.

Mreža koja ih povezuje također može biti vrlo heterogena.

Primjer heterogenosti je stvaranje velikih višeračunalnih sustava pomoću postojećih mreža i kanala. Tako, na primjer, nije neobično postojanje sveučilišno distribuiranih sustava, koji se sastoje od lokalnih mreža različitih fakulteta, međusobno povezanih kanalima velike brzine. U globalnim sustavima različite postaje mogu biti povezane javnim mrežama, poput mrežnih usluga koje nude komercijalni telekomunikacijski operateri, kao što su SMDS ili Relej okvira.

Za razliku od sustava o kojima smo govorili u prethodnim odlomcima, mnogi heterogeni multikompjuterski sustavi velikih razmjera zahtijevaju globalni pristup. To znači da aplikacija ne može pretpostaviti da će joj određene performanse ili određene usluge biti dostupne cijelo vrijeme.

Prelazeći na pitanja skaliranja svojstvena heterogenim sustavima i uzimajući u obzir potrebu za globalnim pristupom koji je svojstven većini njih, napominjemo da je za izradu aplikacija za heterogene multikompjuterske sustave potreban specijalizirani softver. Ovaj problem rješavaju distribuirani sustavi. Kako programeri aplikacija ne bi morali brinuti o hardveru koji koriste, distribuirani sustavi pružaju softversku ljusku koja štiti aplikacije od onoga što se događa u hardveru (odnosno, pruža transparentnost).

Najstarija i najosnovnija distribuirana arhitektura je klijent-poslužitelj u kojoj jedna od strana (klijent) započinje razmjenu podataka slanjem zahtjeva drugoj strani (poslužitelju). Poslužitelj obrađuje zahtjev i po potrebi šalje odgovor klijentu (slika 2.7).

Riža. 2.7. Model interakcije klijent-poslužitelj

Interakcija u okviru modela klijent-poslužitelj može biti sinkrona, kada klijent čeka da poslužitelj obradi njegov zahtjev, ili asinkrona, u kojoj klijent šalje zahtjev poslužitelju i nastavlja njegovo izvršavanje bez čekanja da poslužitelj odgovor. Model klijenta i poslužitelja može se koristiti kao osnova za opisivanje različitih interakcija. Razmotrite interakciju komponenti softvera koje tvore distribuirani sustav.

Riža. 2.8. Razine logike aplikacije

Razmotrimo određenu tipičnu aplikaciju koja se, u skladu sa suvremenim konceptima, može podijeliti na sljedeće logičke razine (slika 2.8): korisničko sučelje (UI), logika aplikacije (LP) i pristup podacima (DD), rad s bazom podataka (DB) ... Korisnik sustava s njim komunicira putem korisničkog sučelja, baza podataka pohranjuje podatke koji opisuju domenu aplikacije, a aplikacijski logički sloj implementira sve algoritme vezane za domenu.

Budući da su u praksi različiti korisnici sustava obično zainteresirani za pristup istim podacima, najjednostavnije razdvajanje funkcija takvog sustava između nekoliko računala bit će razdvajanje logičkih slojeva aplikacije između jednog poslužiteljskog dijela aplikacije odgovoran za pristup podacima i dijelovima klijenta koji se nalaze na nekoliko računala.provedbu korisničkog sučelja. Aplikacijska logika može se dodijeliti poslužitelju, klijentima ili podijeliti između njih (slika 2.9).

Riža. 2.9. Dvoslojna arhitektura

Arhitektura aplikacija izgrađena na ovom principu naziva se klijent-poslužitelj ili dvolančan... U praksi se takvi sustavi često ne klasificiraju kao distribuirani, ali formalno se mogu smatrati najjednostavnijim predstavnicima distribuiranih sustava.

Razvoj arhitekture klijent-poslužitelj je troslojna arhitektura, u kojem su korisničko sučelje, logika aplikacije i pristup podacima odvojeni u neovisne komponente sustava koje mogu raditi na neovisnim računalima (slika 2.10).

Riža. 2.10. Arhitektura na tri nivoa

Korisnički zahtjev u takvim sustavima sekvencijalno obrađuje klijentski dio sustava, aplikacijski logički poslužitelj i poslužitelj baze podataka. Međutim, distribuirani sustav obično se shvaća kao sustav složenije arhitekture od troslojnog.

Riža. 2.11. Distribuirani maloprodajni sustav

S obzirom na aplikacije za automatiziranje aktivnosti poduzeća, distribuirani sustavi obično se nazivaju sustavi s aplikacijskom logikom raspoređenom na nekoliko komponenti sustava, od kojih se svaka može izvesti na zasebnom računalu. Na primjer, implementacija logike primjene sustava maloprodaje mora koristiti upite prema aplikacijskoj logici trećih strana, poput dobavljača robe, sustava za elektroničko plaćanje ili banaka koje daju potrošačke kredite (slika 2.11).

Drugi primjer distribuiranog sustava su mreže izravna razmjena podataka između klijenata (peer-to-peer mreže)... Ako je prethodni primjer imao "stablo" arhitekturu, tada su mreže izravne razmjene organizirane na složeniji način, slika 2.12. Takvi sustavi trenutno su vjerojatno jedan od najvećih postojećih distribuiranih sustava koji ujedinjuje milijune računala.

Riža. 2.12. Sustav izravne razmjene podataka između klijenata

(Materijal web stranice http://se.math.spbu.ru)

Uvod.

Danas se distribuiraju gotovo svi veliki softverski sustavi. Distribuirani sustav- sustav u kojemu obrada informacija nije koncentrirana na jednom računalu, već je raspoređena među nekoliko računala. Prilikom projektiranja distribuiranih sustava, koji ima puno zajedničkog s dizajnom softvera općenito, još uvijek treba uzeti u obzir neke specifičnosti.

Postoji šest glavnih karakteristika distribuiranih sustava.

1. Dijeljenje resursa. Distribuirani sustavi omogućuju dijeljenje i hardverskih (tvrdih diskova, pisača) i softverskih (datoteka, prevoditelja) resursa.
2. Otvorenost.To je mogućnost proširenja sustava dodavanjem novih resursa.
3. Paralelizam.U distribuiranim sustavima više procesa može istodobno raditi na različitim računalima u mreži. Ti procesi mogu međusobno djelovati tijekom izvođenja.
4. Skalabilnost . Pod, ispod skalabilnost razumije se mogućnost dodavanja novih svojstava i metoda.
5. Tolerancija kvarova. Prisutnost više računala omogućuje dupliciranje informacija i otpornost na neke hardverske i softverske pogreške. Distribuirani sustavi mogu podržati djelomičnu funkcionalnost u slučaju pogreške. Potpuni kvar sustava događa se samo s mrežnim pogreškama.
6. Transparentnost.Korisnicima je omogućen potpuni pristup resursima u sustavu, dok su im u isto vrijeme skriveni podaci o raspodjeli resursa u cijelom sustavu.

Distribuirani sustavi također imaju niz nedostataka.

1. Složenost... Mnogo je teže razumjeti i ocijeniti svojstva distribuiranih sustava općenito, teže ih je projektirati, testirati i održavati. Također, performanse sustava ovise o brzini mreže, a ne o pojedinim procesorima. Preraspodjela resursa može značajno promijeniti brzinu rada sustava.
2. Sigurnost... Obično se sustavu može pristupiti s više različitih strojeva, poruke na mreži se mogu pregledavati i presresti. Stoga je u distribuiranom sustavu mnogo teže održavati sigurnost.
3. Kontrolabilnost... Sustav se može sastojati od različitih vrsta računala na koja se mogu instalirati različite verzije operativnih sustava. Pogreške na jednom stroju mogu se proširiti na druge strojeve na nepredvidljiv način.
4. Nepredvidivo ... Reakcija distribuiranih sustava na neke događaje je nepredvidiva i ovisi o punom opterećenju sustava, njegovoj organizaciji i opterećenju mreže. Budući da se ti parametri mogu stalno mijenjati, stoga se vrijeme odgovora na zahtjev može značajno razlikovati od vremena.

Iz ovih nedostataka možete vidjeti da pri projektiranju distribuiranih sustava postoji niz problema koje programeri moraju uzeti u obzir.

1. Identifikacija resursa ... Resursi u distribuiranim sustavima nalaze se na različitim računalima, pa treba razmisliti o sustavu imenovanja resursa kako bi korisnici mogli lako pristupiti resursima koji su im potrebni. Primjer je sustav URL (Uniform Resource Locator) koji definira nazive web stranica.
2. Komunikacija... Univerzalna operabilnost Interneta i učinkovita implementacija TCP / IP protokola na Internetu za većinu distribuiranih sustava primjeri su najučinkovitijeg načina organizacije komunikacije između računala. Međutim, u nekim slučajevima gdje su potrebne posebne performanse ili pouzdanost, moguće je koristiti specijalizirane alate.
3. Kvaliteta usluga sustava ... Ovaj parametar odražava performanse, zdravlje i pouzdanost. Na kvalitetu usluge utječu brojni čimbenici: raspodjela procesa, resursa, hardvera i prilagodljivost sustava.
4. Arhitektura softvera ... Softverska arhitektura opisuje raspodjelu funkcija sustava među komponentama sustava, kao i raspodjelu tih komponenti među procesorima. Ako trebate održavati visokokvalitetnu uslugu sustava, odabir prave arhitekture je kritičan.

Izazov za dizajnere distribuiranih sustava je projektiranje softvera i hardvera koji će pružiti sve potrebne karakteristike distribuiranog sustava. To zahtijeva poznavanje prednosti i nedostataka različitih arhitektura distribuiranih sustava. Postoje tri vrste arhitektura distribuiranih sustava.

1. Arhitektura klijent / poslužitelj ... U ovom modelu sustav se može zamisliti kao skup usluga koje poslužitelji pružaju klijentima. U takvim se sustavima poslužitelji i klijenti međusobno značajno razlikuju.
2. Arhitektura na tri nivoa ... U ovom modelu poslužitelj ne pruža usluge klijentima izravno, već putem poslužitelja poslovne logike.

O prva dva modela već je rečeno više puta, zadržimo se na trećem detaljnije.

1. Arhitektura distribuiranih objekata ... U tom slučaju nema razlika između poslužitelja i klijenata, a sustav se može zamisliti kao skup međusobno povezanih objekata čija lokacija zapravo nije važna. Ne postoji razlika između davatelja usluga i njegovih korisnika.

Ova se arhitektura danas široko koristi i naziva se i arhitektura web usluga. Web usluga je aplikacija koja je dostupna putem Interneta i pruža neke usluge čiji je oblik neovisan o davatelju usluga (budući da se koristi univerzalni format podataka - XML) i platformi za rad. Trenutno postoje tri različite tehnologije koje podržavaju koncept distribuiranih objektnih sustava. To su EJB, CORBA i DCOM tehnologije.

Prvo, nekoliko riječi o tome što je XML općenito. XML je generički format podataka koji se koristi za pružanje web usluga. Web usluge temelje se na otvorenim standardima i protokolima: SOAP, UDDI i WSDL.

1. SAPUN ( Protokol za jednostavan pristup objektima, koji je razvio W3C, definira format zahtjeva za web usluge. Poruke između web usluge i njezinog korisnika pakirane su u takozvane SOAP omotnice (ponekad se nazivaju i XML omotnice). Sama poruka može sadržavati ili zahtjev za izvršenje radnje, ili odgovor - rezultat ove radnje.
2. WSDL (jezik opisa web usluge).Sučelje web usluge opisano je u dokumentima WSDL (a WSDL je podskup XML -a). Prije implementacije usluge, programer sastavlja njen opis na WSDL jeziku, navodi adresu web usluge, podržane protokole, popis dopuštenih operacija te formate zahtjeva i odgovora.
3. UDDI (Univerzalni opis, otkriće i integracija) - Protokol pretraživanja internetskih web usluga ( http://www.uddi.org/). To je poslovni registar u kojemu davatelji internetskih usluga registriraju usluge, a programeri pronalaze usluge koje trebaju uključiti u svoje aplikacije.

Iz izvješća se može činiti da su web usluge najbolje i neosporno rješenje, a jedino je pitanje izbor razvojnih alata. Međutim, nije. Postoji alternativa web uslugama, semantički web, o kojem je tvorac WWW-a Tim Berners-Lee govorio prije pet godina.

Ako je cilj web usluga olakšavanje komunikacije između aplikacija, tada je semantički web osmišljen kako bi riješio mnogo složeniji problem - korištenjem mehanizama metapodataka za povećanje učinkovitosti vrijednosti informacija koje se mogu pronaći na webu. To se može učiniti napuštanjem pristupa orijentiranog na dokumente u korist objektno orijentiranog.

Bibliografija

1. SomervilleI. Softversko inženjerstvo.
2. Dranitsa A. Java vs.NET. - "Computerra", # 516.
3. Internet resursi.

U prethodnom smo poglavlju pogledali čvrsto povezane višeprocesorske sustave sa zajedničkom memorijom, dijeljenim jezgrovitim strukturama podataka i zajedničkim spremištem iz kojeg se pozivaju procesi. Često je, međutim, poželjno dodijeliti procesore na takav način da su neovisni o radnom okruženju i radnim uvjetima u svrhu dijeljenja resursa. Pretpostavimo, na primjer, da korisnik osobnog računala mora pristupiti datotekama koje se nalaze na većem stroju, ali u isto vrijeme zadržati kontrolu nad osobnim računalom. Iako neki programi, poput uucp -a, podržavaju prijenos mrežnih datoteka i druge mrežne funkcije, njihova uporaba neće biti skrivena od korisnika, budući da je korisnik svjestan da koristi mrežu. Osim toga, valja napomenuti da programi poput uređivača teksta ne rade s izbrisanim datotekama, kao s običnim. Korisnici bi trebali imati standardni skup funkcija sustava UNIX i, osim potencijalnog uskog grla performansi, ne bi trebali osjetiti prelazak granica stroja. Tako se, na primjer, rad sistemskih funkcija otvorenih i čitljivih s datotekama na udaljenim strojevima ne bi trebao razlikovati od njihovog rada s datotekama koje pripadaju lokalnim sustavima.

Arhitektura distribuiranog sustava prikazana je na slici 13.1. Svako računalo prikazano na slici je samostalna jedinica koja se sastoji od CPU-a, memorije i perifernih uređaja. Model se ne lomi iako računalo nema lokalni datotečni sustav: mora imati periferne uređaje za komunikaciju s drugim strojevima, a sve datoteke koje mu pripadaju mogu se nalaziti na drugom računalu. Fizička memorija dostupna svakom stroju neovisna je o procesima koji se izvode na drugim strojevima. U tom pogledu, distribuirani sustavi razlikuju se od čvrsto povezanih višeprocesorskih sustava o kojima je bilo riječi u prethodnom poglavlju. Sukladno tome, jezgra sustava na svakom stroju funkcionira neovisno o vanjskim radnim uvjetima distribuiranog okruženja.

Slika 13.1. Model sustava distribuirane arhitekture

Distribuirani sustavi, dobro opisani u literaturi, tradicionalno spadaju u sljedeće kategorije:

Periferni sustavi, koji su skupine strojeva koji imaju izrazito zajedničko svojstvo i povezani su s jednim (obično većim) strojem. Periferni procesori dijele svoje opterećenje sa središnjim procesorom i prosljeđuju mu sve pozive operacijskom sustavu. Cilj perifernog sustava je povećati ukupne performanse mreže i omogućiti mogućnost dodjeljivanja procesora jednom procesu u UNIX operativnom okruženju. Sustav se pokreće kao zasebni modul; Za razliku od drugih modela distribuiranih sustava, periferni sustavi nemaju stvarnu autonomiju, osim u slučajevima koji se odnose na dispečiranje procesa i dodjelu lokalne memorije.

Distribuirani sustavi poput "Newcastlea", koji omogućuju daljinsku komunikaciju prema nazivima udaljenih datoteka u knjižnici (naziv je preuzet iz članka "The Newcastle Connection" - vidi). Izbrisane datoteke imaju BOM (istaknuti naziv) koji na putu pretraživanja sadrži posebne znakove ili izbornu komponentu imena koja prethodi korijenu datotečnog sustava. Implementacija ove metode ne uključuje promjene u jezgri sustava, pa je jednostavnija od ostalih metoda o kojima se govori u ovom poglavlju, ali manje fleksibilna.

Distribuirani sustavi potpuno su transparentni, u kojima su standardni ugledni nazivi dovoljni za pristup datotekama koje se nalaze na drugim strojevima; na kernelu je da prepozna te datoteke kao izbrisane. Putevi pretraživanja datoteka navedeni u njihovim složenim nazivima prelaze granice stroja na točkama montiranja, bez obzira na to koliko se takvih točaka formira kada se datotečni sustavi montiraju na diskove.

U ovom poglavlju ćemo pogledati arhitekturu svakog modela; sve pružene informacije ne temelje se na rezultatima određenog razvoja, već na informacijama objavljenim u raznim tehničkim člancima. To pretpostavlja da su protokolarni moduli i upravljački programi uređaja odgovorni za adresiranje, usmjeravanje, kontrolu protoka, otkrivanje i ispravljanje grešaka, drugim riječima, da je svaki model neovisan o mreži koja se koristi. Primjeri korištenja funkcija sustava prikazani u sljedećem odjeljku za periferne sustave djeluju na sličan način za sustave poput Newcastlea i za potpuno transparentne sustave, o čemu će biti riječi kasnije; stoga ćemo ih jednom detaljno razmotriti, a u odjeljcima posvećenim drugim vrstama sustava usredotočit ćemo se uglavnom na značajke koje te modele razlikuju od svih ostalih.

13.1 PERIFERNI PROCESORI

Arhitektura perifernog sustava prikazana je na slici 13.2. Cilj ove konfiguracije je poboljšati ukupne performanse mreže premještanjem pokrenutih procesa između CPU -a i perifernih procesora. Svaki od perifernih procesora nema na raspolaganju druge lokalne periferne uređaje osim onih koji su mu potrebni za komunikaciju sa središnjom procesorskom jedinicom. Sustav datoteka i svi uređaji stoje na raspolaganju središnjem procesoru. Pretpostavimo da se svi korisnički procesi izvode na perifernom procesoru i da se ne kreću između perifernih procesora; jednom prebačeni u procesor, ostaju na njemu do završetka. Periferni procesor sadrži laganu verziju operacijskog sustava dizajniranu za rukovanje lokalnim pozivima prema sustavu, upravljanje prekidima, dodjelu memorije, rad s mrežnim protokolima i upravljačkim programom za komunikaciju sa središnjim procesorom.

Kad se sustav inicijalizira na središnjem procesoru, jezgra učitava lokalni operacijski sustav na svaki od perifernih procesora putem komunikacijskih linija. Svaki proces koji se izvodi na periferiji povezan je sa satelitskim procesom koji pripada središnjem procesoru (vidi); kada proces koji radi na perifernom procesoru poziva funkciju sustava koja zahtijeva usluge samo središnjeg procesora, periferni proces komunicira sa svojim satelitom i zahtjev se šalje središnjem procesoru na obradu. Satelitski proces obavlja funkciju sustava i šalje rezultate natrag perifernom procesoru. Odnos između perifernog procesa i njegovog satelita sličan je odnosu klijent-poslužitelj o kojem smo detaljno govorili u 11. poglavlju: periferni proces djeluje kao klijent svog satelita, koji podržava funkcije rada s datotečnim sustavom. U tom slučaju proces udaljenog poslužitelja ima samo jednog klijenta. U odjeljku 13.4 pogledat ćemo poslužiteljske procese s više klijenata.

Slika 13.2. Konfiguracija perifernog sustava

Slika 13.3. Formati poruka

Kad periferni proces pozove sistemsku funkciju koja se može lokalno obraditi, kernel ne mora slati zahtjev satelitskom procesu. Tako, na primjer, kako bi dobio dodatnu memoriju, proces može pozvati funkciju sbrk za lokalno izvršavanje. Međutim, ako su usluge središnjeg procesora potrebne, na primjer, za otvaranje datoteke, jezgro kodira informacije o parametrima proslijeđenim pozvanoj funkciji i uvjetima izvođenja procesa u poruku poslanu satelitskom procesu (slika 13.3). Poruka uključuje znak iz kojeg proizlazi da funkciju sustava obavlja satelitski proces u ime klijenta, parametri proslijeđeni funkciji i podaci o okruženju izvođenja procesa (na primjer, identifikacijski kodovi korisnika i grupe), koji su različiti za različite funkcije. Ostatak poruke su podaci promjenjive duljine (na primjer, naziv složene datoteke ili podaci koji se zapisuju s funkcijom pisanja).

Satelitski proces čeka zahtjeve iz perifernog procesa; kada se primi zahtjev, on dekodira poruku, određuje tip funkcije sustava, izvršava je i pretvara rezultate u odgovor poslan perifernom procesu. Odgovor, osim rezultata izvršenja funkcije sustava, uključuje poruku o pogrešci (ako postoji), broj signala i niz podataka promjenjive duljine koji sadrži, na primjer, podatke pročitane iz datoteke. Periferni proces obustavlja se dok se ne primi odgovor, nakon što ga primi, dešifrira i prenosi rezultate korisniku. Ovo je opća shema za rukovanje pozivima operacijskom sustavu; prijeđimo sada na detaljnije razmatranje pojedinih funkcija.

Da biste objasnili kako funkcionira periferni sustav, razmotrite brojne funkcije: getppid, open, write, fork, exit i signal. Funkcija getppid prilično je jednostavna jer se bavi jednostavnim obrascima zahtjeva i odgovora koji se razmjenjuju između periferije i CPU -a. Jezgra na perifernom procesoru generira poruku koja ima znak, iz čega proizlazi da je tražena funkcija funkcija getppid, te šalje zahtjev središnjem procesoru. Satelitski proces na središnjem procesoru čita poruku s perifernog procesora, dešifrira vrstu funkcije sustava, izvršava je i dobiva identifikator svog roditelja. Zatim generira odgovor i prosljeđuje ga perifernom procesu na čekanju na drugom kraju komunikacijske linije. Kad periferni procesor primi odgovor, prosljeđuje ga procesu koji je nazvao funkciju sustava getppid. Ako periferni proces pohranjuje podatke (kao što je ID procesa roditelja) u lokalnu memoriju, uopće ne mora komunicirati sa svojim pratiteljem.

Ako se pozove funkcija otvorenog sustava, periferni proces šalje odgovarajuću poruku svom pratiocu, koja uključuje naziv datoteke i druge parametre. Ako je uspješan, popratni proces dodjeljuje indeks i ulaznu točku tablici datoteka, dodjeljuje unos u tablici deskriptora korisničke datoteke u svom prostoru i vraća deskriptor datoteke u periferni proces. Cijelo to vrijeme, na drugom kraju komunikacijske linije, periferni proces čeka odgovor. On nema na raspolaganju nikakve strukture koje bi pohranile podatke o datoteci koja se otvara; ručka koju vraća open pokazivač je na unos u tablici deskriptora korisničke datoteke u vlasništvu popratnog procesa. Rezultati izvršavanja funkcije prikazani su na slici 13.4.

Slika 13.4. Pozivanje otvorene funkcije iz perifernog procesa

Ako se pozove pisanje sistemske funkcije, periferni procesor generira poruku koja se sastoji od predznaka funkcije pisanja, deskriptora datoteke i količine podataka za upisivanje. Zatim iz prostora perifernog procesa kopira podatke u satelitski proces putem komunikacijske linije. Satelitski proces dešifrira primljenu poruku, čita podatke s komunikacijske linije i zapisuje ih u odgovarajuću datoteku (deskriptor koji se nalazi u poruci koristi se kao pokazivač na čiji se indeks i zapis o kojem se u tablici datoteka koristi ); sve se te radnje izvode na središnjem procesoru. Na kraju rada, satelitski proces šalje perifernom procesu poruku koja potvrđuje primanje poruke i sadrži broj bajtova podataka koji su uspješno kopirani u datoteku. Operacija čitanja je slična; satelit obavještava periferni proces o broju stvarno pročitanih bajtova (u slučaju čitanja podataka s terminala ili s kanala, taj se iznos ne podudara uvijek s iznosom navedenim u zahtjevu). Za obavljanje jedne ili druge funkcije možda će biti potrebno više puta slati informacijske poruke preko mreže, što je određeno količinom poslanih podataka i veličinom mrežnih paketa.

Jedina funkcija koju je potrebno promijeniti tijekom rada na CPU -u je funkcija sustava vilica. Kad proces izvrši ovu funkciju na CPU -u, jezgra za njega odabire periferni procesor i šalje poruku posebnom procesu - poslužitelju, obavještavajući potonjeg da će započeti istovar trenutnog procesa. Pod pretpostavkom da je poslužitelj prihvatio zahtjev, jezgra koristi vilicu za stvaranje novog perifernog procesa, dodjeljujući unos tablice procesa i adresni prostor. Središnji procesor ispisuje kopiju procesa koji je pozvao funkciju rašlje na periferni procesor, prepisujući novo dodijeljeni adresni prostor, iznjedri lokalni satelit za komunikaciju s novim perifernim procesom i šalje poruku periferiji da pokrene programski brojač za novi proces. Satelitski proces (na CPU -u) potomak je procesa koji je nazvao fork; periferni proces tehnički je potomak poslužiteljskog procesa, ali logično je potomak procesa koji je pozvao funkciju fork. Poslužiteljski proces nema logičku vezu s djetetom kad se vilica dovrši; jedini posao poslužitelja je pomoći u rasterećenju djeteta. Zbog snažne sprege između komponenti sustava (periferni procesori nemaju autonomiju), periferni proces i satelitski proces imaju isti identifikacijski kod. Odnos između procesa prikazan je na slici 13.5: neprekinuta linija prikazuje odnos roditelj-dijete, a točkasta linija prikazuje odnos među vršnjacima.

Slika 13.5. Izvršavanje funkcije vilice na CPU -u

Kada proces izvršava funkciju vilice na perifernom procesoru, šalje poruku svom satelitu na CPU -u, koji zatim izvršava cijeli niz gore opisanih radnji. Satelit odabire novi periferni procesor i vrši potrebne pripreme za istovar slike starog procesa: šalje roditeljskom perifernom procesu zahtjev za čitanje njegove slike, u odgovoru na koji prijenos traženih podataka počinje na drugom kraju komunikacijski kanal. Satelit čita prenesenu sliku i prepisuje je perifernom potomku. Kad je iskrcavanje slike završeno, satelit se račva, stvarajući svoje dijete na CPU -u, i prosljeđuje vrijednost brojača programa perifernom djetetu tako da potonji zna odakle započeti izvršavanje. Očito bi bilo bolje da je dijete pratećeg procesa dodijeljeno perifernom djetetu kao roditelj, ali u našem slučaju generirani procesi mogu se izvoditi na drugim perifernim procesorima, a ne samo na onom na kojem su stvoreni. Odnos između procesa na kraju funkcije vilice prikazan je na slici 13.6. Kad periferni proces završi svoj rad, šalje odgovarajuću poruku satelitskom procesu, što također završava. Popratni postupak ne može pokrenuti gašenje.

Slika 13.6. Izvođenje funkcije vilice na perifernom procesoru

I u višeprocesorskim i u jednoprocesorskim sustavima proces mora reagirati na signale na isti način: proces ili dovršava izvršavanje funkcije sustava prije provjere signala, ili, naprotiv, po primitku signala, odmah izlazi iz suspendiranog stanja i naglo prekida rad funkcije sustava, ako je to u skladu s prioritetom s kojim je suspendiran. Budući da satelitski proces obavlja funkcije sustava u ime perifernog procesa, mora reagirati na signale u koordinaciji s potonjim. Ako u jednoprocesorskom sustavu signal uzrokuje da proces prekine funkciju, popratni proces u višeprocesorskom sustavu trebao bi se ponašati na isti način. Isto se može reći i za slučaj kada signal potiče proces da prekine svoj rad pomoću izlazne funkcije: periferni proces završava i šalje odgovarajuću poruku satelitskom procesu, koji, naravno, također završava.

Kad periferni proces pozove funkciju signalnog sustava, on pohranjuje trenutne informacije u lokalne tablice i šalje poruku svom satelitu u kojem ga obavještava treba li navedeni signal primiti ili zanemariti. Za satelitski proces nema razlike hoće li presresti signal ili zadanu radnju. Reakcija procesa na signal ovisi o tri čimbenika (slika 13.7): hoće li se signal primiti dok proces izvršava funkciju sustava, radi li se indikacija pomoću signalne funkcije za zanemarivanje signala, javlja li se signal na istom perifernom procesoru ili na nekom drugom. Prijeđimo na razmatranje različitih mogućnosti.

algoritam sighandle / * algoritam za obradu signala * /

if (trenutni proces je nečiji pratilac ili ima prototip)

ako (signal se zanemaruje)

if (signal je došao tijekom izvršavanja funkcije sustava)

staviti signal ispred satelitskog procesa;

poslati signalnu poruku perifernom procesu;

else ( / * periferni proces * /

/ * je li signal primljen tijekom izvršavanja funkcije sustava ili ne * /

poslati signal satelitskom procesu;

algoritam satellite_end_of_syscall / * prekid funkcije sustava koja se naziva perifernim procesom * /

ulazni podaci: odsutan

izlazne informacije: nema

if (prekid je primljen tijekom izvršavanja funkcije sustava)

poslati poruku o prekidu, signal perifernom procesu;

else / * izvršavanje funkcije sustava nije prekinuto * /

poslati odgovor: omogućiti zastavicu koja označava dolazak signala;

Slika 13.7. Obrada signala u perifernom sustavu

Pretpostavimo da je periferni proces obustavio svoj rad dok satelitski proces u njegovo ime obavlja funkciju sustava. Ako se signal pojavi na drugom mjestu, satelitski proces ga otkriva ranije od perifernog procesa. Moguća su tri slučaja.

1. Ako, dok čeka neki događaj, satelitski proces nije ušao u suspendirano stanje, iz kojeg bi izašao po primitku signala, izvršava funkciju sustava do kraja, šalje rezultate izvršenja perifernom procesu i prikazuje koji je signal primio.

2. Ako proces dobije instrukciju da zanemari ovu vrstu signala, satelit nastavlja slijediti algoritam izvođenja funkcije sustava bez napuštanja suspendiranog stanja longjmpom. U odgovoru poslanom perifernom procesu neće biti primljene poruke.

3. Ako pri primanju signala satelitski proces prekine izvršavanje funkcije sustava (longjmp -om), o tome obavještava periferni proces i obavještava ga o broju signala.

Periferni proces traži informacije o primanju signala u primljenom odgovoru i, ako ih ima, obrađuje signale prije izlaska iz funkcije sustava. Dakle, ponašanje procesa u višeprocesorskom sustavu točno odgovara njegovom ponašanju u jednoprocesorskom sustavu: ili izlazi bez izlaska iz načina rada jezgre, ili poziva prilagođenu funkciju obrade signala, ili zanemaruje signal i uspješno dovršava funkciju sustava.

Slika 13.8. Prekid tijekom izvođenja funkcije sustava

Pretpostavimo, na primjer, da periferni proces poziva funkciju čitanja s terminala spojenog na središnji procesor i pauzira svoj rad dok satelitski proces obavlja tu funkciju (slika 13.8). Ako korisnik pritisne tipku break, jezgra CPU -a šalje signal satelitskom procesu. Ako je satelit bio u suspendiranom stanju i čekao dio podataka s terminala, odmah izlazi iz tog stanja i prekida funkciju čitanja. U odgovoru na zahtjev perifernog procesa, satelit izvještava o šifri greške i broju signala koji odgovaraju prekidu. Periferni proces analizira odgovor i, budući da poruka kaže da je stigao prekid, šalje signal sebi. Prije izlaska iz funkcije čitanja, periferna jezgra provjerava ima li signalizacije, detektira signal prekida iz satelitskog procesa i obrađuje ga kao i obično. Ako, kao rezultat prijema signala prekida, periferni proces prekine svoj rad pomoću izlazne funkcije, ova funkcija brine se o ubijanju satelitskog procesa. Ako periferni proces presreće signale prekida, poziva korisnički definiranu funkciju upravljanja signalom i vraća korisniku kod pogreške pri izlasku iz funkcije čitanja. S druge strane, ako satelit izvršava funkciju stat sustava u ime perifernog procesa, neće prekinuti njegovo izvršavanje kada primi signal (funkcija stat će zajamčeno izaći iz svake stanke, jer ima ograničeno vrijeme čekanja resursa ). Satelit dovršava izvršavanje funkcije i vraća broj signala perifernom procesu. Periferni proces šalje signal sebi i prima ga na izlazu iz funkcije sustava.

Ako se signal pojavi na perifernom procesoru tijekom izvršavanja funkcije sustava, periferni proces bit će u mraku hoće li se uskoro vratiti u kontrolu iz satelitskog procesa ili će potonji preći u suspendirano stanje na neodređeno vrijeme. Periferni proces šalje posebnu poruku satelitu koji ga obavještava o pojavi signala. Jezgra na CPU -u dešifrira poruku i šalje signal satelitu čija je reakcija na primanje signala opisana u prethodnim odlomcima (nenormalan prekid izvršenja funkcije ili njezin završetak). Periferni proces ne može poslati poruku satelitu izravno jer je satelit zauzet obavljanjem funkcije sustava i ne čita podatke s komunikacijske linije.

Pozivajući se na pročitani primjer, valja napomenuti da periferni proces nema pojma čeka li njegov pratitelj na ulaz s terminala ili izvodi druge radnje. Periferni proces šalje signalnu poruku satelitu: ako je satelit u suspendiranom stanju s prioritetom prekida, on odmah izlazi iz tog stanja i prekida funkciju sustava; u suprotnom, funkcija je uspješno dovršena.

Na kraju, razmotrimo slučaj dolaska signala u vrijeme koje nije povezano s izvršavanjem funkcije sustava. Ako signal potiče iz drugog procesora, satelit ga prvo prima i šalje signalnu poruku perifernom procesu, bez obzira odnosi li se signal na periferni proces ili ne. Periferna jezgra dešifrira poruku i šalje signal procesu, koji na njega reagira na uobičajen način. Ako signal potiče iz perifernog procesora, proces izvodi standardne radnje bez pribjegavanja uslugama svog satelita.

Kada periferni proces šalje signal drugim perifernim procesima, on kodira poruku o pozivu na uboj i šalje je satelitskom procesu, koji lokalno izvršava pozvanu funkciju. Ako se neki od procesa za koje je signal namijenjen nalaze na drugim perifernim procesorima, njihovi sateliti će primiti signal (i reagirati na njega kako je gore opisano).

13.2 KOMUNIKACIJA NOVIH ZAMAKA

U prethodnom smo odjeljku razmatrali vrstu čvrsto povezanog sustava, koji se odlikuje slanjem svih poziva funkcijama podsustava za upravljanje datotekama koji se pojavljuju na perifernom procesoru udaljenom (središnjem) procesoru. Sada se okrećemo razmatranju sustava sa slabijom vezom, koji se sastoje od strojeva koji pozivaju datoteke na drugim strojevima. Na primjer, u mreži osobnih računala i radnih stanica korisnici često pristupaju datotekama koje se nalaze na velikom računalu. U sljedeća dva odjeljka pogledat ćemo konfiguracije sustava u kojima se sve funkcije sustava izvode u lokalnim podsustavima, ali je istodobno moguć pristup datotekama (putem funkcija podsustava za upravljanje datotekama) koje se nalaze na drugim strojevima.

Ovi sustavi koriste jedan od sljedeća dva puta za identifikaciju izbrisanih datoteka. Na nekim sustavima složenom imenu datoteke dodaje se poseban znak: komponenta imena koja prethodi ovom znaku identificira stroj, ostatak naziva je datoteka na tom stroju. Tako, na primjer, istaknuto ime

"sftig! / fs1 / mjb / rje"

identificira datoteku " / fs1 / mjb / rje" na stroju "sftig". Ova shema identifikacije datoteka slijedi uucp konvenciju za prijenos datoteka između UNIX sustava. U drugoj shemi, izbrisane se datoteke identificiraju dodavanjem posebnog prefiksa imenu, na primjer:

/../sftig/fs1/mjb/rje

gdje je "/../" prefiks koji označava da je datoteka izbrisana; druga komponenta naziva datoteke je naziv udaljenog računala. Ova shema koristi poznatu sintaksu naziva UNIX datoteke, pa se za razliku od prve sheme, korisnički programi ne moraju prilagođavati korištenju imena s neobičnom konstrukcijom (vidi).

Slika 13.9. Oblikovanje zahtjeva do poslužitelja datoteka (procesora)

Ostatak ovog odjeljka posvetit ćemo modelu sustava koji koristi vezu Newcastle, u kojemu se kernel ne bavi prepoznavanjem izbrisanih datoteka; ova je funkcija u potpunosti dodijeljena potprogramima iz standardne C knjižnice, koje u ovom slučaju igraju ulogu sučelja sustava. Ove podrutine analiziraju prvu komponentu naziva datoteke koja u obje opisane metode identifikacije sadrži znak udaljenosti datoteke. Ovo je odstupanje od rutine u kojoj knjižnične rutine ne analiziraju imena datoteka. Slika 13.9 prikazuje kako su formulirani zahtjevi prema datotečnom poslužitelju. Ako je datoteka lokalna, jezgra lokalnog sustava normalno obrađuje zahtjev. Razmotrimo suprotan slučaj:

open ("/../ sftig / fs1 / mjb / rje / file", O_RDONLY);

Otvorena potprogram iz C knjižnice analizira prve dvije komponente naziva datoteke i zna tražiti datoteku na udaljenom stroju "sftig". Kako bi imali informacije o tome je li proces prethodno imao vezu s danim strojem, potprogram pokreće posebnu strukturu u kojoj pamti tu činjenicu, a u slučaju negativnog odgovora uspostavlja vezu s poslužiteljem datoteka koji radi na udaljeni stroj. Kad proces formulira svoj prvi zahtjev za daljinsku obradu, udaljeni poslužitelj potvrđuje zahtjev, ako je potrebno, bilježi u polja identifikacijskih kodova korisnika i grupe i stvara satelitski proces koji će djelovati u ime procesa klijenta.

Da bi ispunio zahtjeve klijenta, satelit mora imati iste dozvole za datoteke na udaljenom računalu kao i klijent. Drugim riječima, korisnik "mjb" mora imati ista prava pristupa i udaljenim i lokalnim datotekama. Nažalost, moguće je da se identifikacijski kod klijenta "mjb" može podudarati s identifikacijskim kodom drugog klijenta na udaljenom računalu. Stoga bi administratori sustava na strojevima koji rade na mreži trebali osigurati da se svakom korisniku dodijeli identifikacijski kod koji je jedinstven za cijelu mrežu, ili izvršiti pretvorbu koda u vrijeme zahtjeva mrežne usluge. Ako se to ne učini, popratni proces imat će prava drugog klijenta na udaljenom računalu.

Delikatnije pitanje je dobivanje prava superkorisnika u vezi s radom s udaljenim datotekama. S jedne strane, klijent superkorisnika ne bi trebao imati ista prava nad udaljenim sustavom kako ne bi doveo u zabludu sigurnosne kontrole udaljenog sustava. S druge strane, neki od programa, ako im se ne odobre prava superkorisnika, jednostavno neće moći raditi. Primjer takvog programa je program mkdir (vidi Poglavlje 7), koji stvara novi direktorij. Udaljeni sustav ne bi dopustio klijentu da stvori novi direktorij jer prava superusera ne djeluju na brisanje. Problem stvaranja udaljenih direktorija služi kao ozbiljan razlog za reviziju funkcije sustava mkdir u smjeru proširenja njegovih mogućnosti u automatskom uspostavljanju svih veza potrebnih korisniku. Međutim, i dalje je čest problem da setuid programi (poput programa mkdir) stječu prava superkorisnika nad izbrisanim datotekama. Možda bi najbolje rješenje ovog problema bilo postavljanje dodatnih karakteristika za datoteke koje opisuju pristup udaljenim superkorisnicima; nažalost, to bi zahtijevalo promjene u strukturi indeksa diska (u smislu dodavanja novih polja) i stvaralo bi previše nereda u postojećim sustavima.

Ako otvorena podrutina uspije, lokalna knjižnica ostavlja odgovarajuću napomenu o tome u strukturi pristupačnoj koja sadrži adresu mrežnog čvora, ID procesa popratnika, deskriptor datoteke i druge slične podatke. Rutine knjižnice čitanje i pisanje određuju, na temelju deskriptora, je li datoteka izbrisana, a ako je tako, šalju poruku satelitu. Klijentski proces komunicira sa svojim pratiteljem u svim slučajevima pristupa funkcijama sustava koji zahtijevaju usluge udaljenog stroja. Ako proces pristupa dvije datoteke smještene na istom udaljenom računalu, koristi jedan satelit, ali ako se datoteke nalaze na različitim strojevima, već se koriste dva satelita: po jedan na svakom stroju. Dva satelita se također koriste kada dva procesa pristupaju datoteci na udaljenom računalu. Pozivanjem funkcije sustava putem satelita proces generira poruku koja uključuje broj funkcije, naziv puta pretraživanja i druge potrebne informacije, slične onima uključenim u strukturu poruka u sustavu s perifernim procesorima.

Mehanizam izvođenja operacija na trenutnom direktoriju je složeniji. Kad proces odabere udaljeni direktorij kao trenutni, rutina knjižnice šalje poruku satelitu, koji mijenja trenutni direktorij, a rutina pamti da je imenik izbrisan. U svim slučajevima gdje naziv staze pretraživanja počinje znakom koji nije kosa crta (/), potprogram šalje ime udaljenom stroju, gdje satelit obrađuje rute iz trenutnog direktorija. Ako je trenutni direktorij lokalni, rutina jednostavno prosljeđuje naziv staze pretraživanja jezgri lokalnog sustava. Sustavna funkcija chroot na udaljenom direktoriju slična je, ali za lokalnu jezgru ostaje nezamijećena; strogo govoreći, proces može zanemariti ovu operaciju, jer samo knjižnica bilježi njezino izvršavanje.

Kada proces poziva fork, odgovarajuća knjižnična rutina šalje poruke svakom satelitu. Procesi satelita granaju se i šalju svoje podređene ID -ove nadređenom klijentu. Klijentski proces pokreće funkciju sustava vilica, koja prenosi kontrolu na dijete koje on stvara; lokalno dijete u dijalogu je s udaljenim satelitskim djetetom čije adrese pohranjuje rutina knjižnice. Ovakvo tumačenje funkcije vilice olakšava satelitskim procesima kontrolu otvorenih datoteka i trenutnih direktorija. Kad proces koji radi s udaljenim datotekama izađe (pozivanjem izlazne funkcije), potprogram šalje poruke svim svojim udaljenim satelitima kako bi i oni učinili isto kad prime poruku. U vježbama se raspravlja o određenim aspektima implementacije funkcija izvršnog i izlaznog sustava.

Prednost veze na Newcastle je u tome što pristup procesa udaljenim datotekama postaje "transparentan" (nevidljiv za korisnika), te nisu potrebne nikakve promjene u jezgri sustava. Međutim, ovaj razvoj ima niz nedostataka. Prije svega, tijekom njegove implementacije moguće je smanjenje performansi sustava. Zbog upotrebe proširene C knjižnice, veličina memorije koju koristi svaki proces povećava se, čak i ako proces ne pristupa udaljenim datotekama; knjižnica duplicira funkcije jezgre i zahtijeva više memorijskog prostora za sebe. Povećanje veličine procesa produljuje razdoblje pokretanja i može stvoriti više sukoba za memorijske resurse, stvarajući uvjete za češće iskrcavanje i straničenje zadataka. Lokalni će se zahtjevi sporije izvršavati zbog povećanja trajanja svakog poziva jezgri, a obrada udaljenih zahtjeva također se može usporiti, povećavaju se troškovi slanja putem mreže. Dodatna obrada udaljenih zahtjeva na korisničkoj razini povećava broj prekidača konteksta, operacija istovara i zamjene. Konačno, kako bi mogli pristupiti udaljenim datotekama, programi se moraju ponovno kompajlirati pomoću novih knjižnica; stari programi i isporučeni objektni moduli bez toga neće moći raditi s udaljenim datotekama. Svi ovi nedostaci nedostaju u sustavu opisanom u sljedećem odjeljku.

13.3 "PROZIRNI" DISTRIBUCIRANI SISTEMI DATOTEKE

Izraz "transparentno dodjeljivanje" znači da korisnici na jednom stroju mogu pristupiti datotekama na drugom stroju, a da nisu svjesni da prelaze granice stroja, baš kao što su na svom računalu kada se kreću iz jednog datotečnog sustava u drugi, prelazeći točke montiranja. Nazivi pod kojima se procesi odnose na datoteke smještene na udaljenim strojevima slični su nazivima lokalnih datoteka: u njima nema karakterističnih znakova. U konfiguraciji prikazanoj na slici 13.10, direktorij "/ usr/ src" koji pripada stroju B "montiran" je u direktorij "/ usr/ src" koji pripada stroju A. isti izvorni kod sustava, koji se tradicionalno nalazi u "/ usr / src "direktorij. Korisnici koji rade na stroju A mogu pristupiti datotekama koje se nalaze na stroju B koristeći uobičajenu sintaksu pisanja naziva datoteka (na primjer: "/usr/src/cmd/login.c"), a jezgra sama odlučuje je li datoteka udaljena ili lokalna . Korisnici koji rade na stroju B imaju pristup svojim lokalnim datotekama (nesvjesni da korisnici stroja A mogu pristupiti istim datotekama), ali zauzvrat nemaju pristup datotekama koje se nalaze na stroju A. Naravno, moguće su i druge opcije, u posebno oni u kojima su svi udaljeni sustavi montirani u korijenu lokalnog sustava, tako da korisnici imaju pristup svim datotekama na svim sustavima.

Slika 13.10. Sustavi datoteka nakon udaljenog montiranja

Sličnosti između postavljanja lokalnih datotečnih sustava i dopuštanja pristupa udaljenim datotečnim sustavima potaknule su prilagodbu funkcije montiranja udaljenim datotečnim sustavima. U ovom slučaju, jezgra ima na raspolaganju tablicu montiranja proširenog formata. Izvođenjem funkcije montiranja, kernel organizira mrežnu vezu s udaljenim strojem i pohranjuje informacije koje karakteriziraju ovu vezu u tablicu montiranja.

Zanimljiv problem odnosi se na nazive staza koji uključuju "..". Ako proces stvara trenutni direktorij s udaljenog datotečnog sustava, tada će upotreba znakova ".." u imenu vjerojatnije vratiti proces u lokalni datotečni sustav, a ne pristupiti datotekama iznad trenutnog direktorija. Vraćajući se opet na sliku 13.10, imajte na umu da će, kada proces koji pripada stroju A, nakon što je prethodno odabrao trenutni direktorij " / usr / src / cmd" koji se nalazi u udaljenom datotečnom sustavu, izvršiti naredbu

trenutni direktorij bit će korijenski direktorij stroja A, a ne stroj B. Namei algoritam koji radi u jezgri udaljenog sustava, nakon što primi niz znakova "..", provjerava je li pozivni proces agent klijenta process, i ako je tako, postavlja, Da li klijent tretira trenutni radni direktorij kao korijen udaljenog datotečnog sustava.

Komunikacija s udaljenim strojem ima jedan od dva oblika: poziv udaljene procedure ili poziv funkcije udaljenog sustava. U prvom obliku, svaki postupak jezgre koji se bavi indeksima provjerava pokazuje li indeks na udaljenu datoteku, i ako je tako, šalje zahtjev udaljenom stroju da izvrši navedenu operaciju. Ova se shema prirodno uklapa u apstraktnu strukturu podrške datotečnih sustava različitih vrsta, opisanih u završnom dijelu Poglavlja 5. Dakle, pristup udaljenoj datoteci može pokrenuti prijenos nekoliko poruka preko mreže, čiji je broj određen prema broju impliciranih operacija u datoteci, s odgovarajućim povećanjem vremena odgovora na zahtjev, uzimajući u obzir vrijeme čekanja prihvaćeno u mreži. Svaki skup udaljenih operacija uključuje barem radnje za zaključavanje indeksa, brojanje referenci itd. Kako bi se poboljšao model, predložena su različita rješenja optimizacije koja se odnose na kombiniranje više operacija u jedan upit (poruku) i međuspremljivanje najvažnijih podataka (cm. ).

Slika 13.11. Otvaranje udaljene datoteke

Razmislite o procesu koji otvara udaljenu datoteku "/usr/src/cmd/login.c", gdje je "src" točka montiranja. Raščlanjivanjem naziva datoteke (korištenjem namei-iget sheme), kernel otkriva da je datoteka izbrisana i šalje zahtjev računalu domaćina da dobije zaključani indeks. Nakon što je primio željeni odgovor, lokalno jezgro stvara kopiju indeksa u memoriji koja odgovara udaljenoj datoteci. Zatim jezgra provjerava potrebna prava pristupa datoteci (na primjer za čitanje) slanjem druge poruke udaljenom računalu. Otvoreni algoritam nastavlja se u potpunosti u skladu s planom navedenim u Poglavlju 5, šaljući poruke prema udaljenom stroju prema potrebi, sve dok algoritam ne bude dovršen i indeks ne bude oslobođen. Odnos između struktura podataka jezgre nakon dovršetka otvorenog algoritma prikazan je na slici 13.11.

Ako klijent pozove funkciju čitanja sustava, jezgra klijenta zaključava lokalni indeks, zaključava udaljeni indeks, zahtjev za čitanje, kopira podatke u lokalnu memoriju, izdaje zahtjev za oslobađanje udaljenog indeksa i oslobađa lokalni indeks . Ova je shema konzistentna sa semantikom postojećeg jezgra jednoprocesorske jedinice, ali učestalost korištenja mreže (više poziva svakoj funkciji sustava) smanjuje performanse cijelog sustava. Međutim, kako bi se smanjio protok poruka na mreži, više se operacija može kombinirati u jedan zahtjev. U primjeru s funkcijom čitanja, klijent može poslužitelju poslati jedan opći zahtjev za "čitanje", a sam poslužitelj odlučuje zgrabiti i otpustiti indeks kada se izvrši. Smanjivanje mrežnog prometa također se može postići korištenjem udaljenih međuspremnika (o čemu smo gore govorili), ali se mora paziti da se funkcije sistemske datoteke pomoću tih međuspremnika pravilno izvode.

U drugom obliku komunikacije s udaljenim strojem (poziv funkciji udaljenog sustava), lokalna jezgra otkriva da je funkcija sustava povezana s udaljenom datotekom i šalje parametre navedene u svom pozivu udaljenom sustavu koji izvršava funkciju i vraća rezultate klijentu. Klijentski stroj prima rezultate izvođenja funkcije i izlazi iz stanja poziva. Većina funkcija sustava može se izvesti pomoću samo jednog mrežnog zahtjeva i primanjem odgovora nakon razumnog vremena, ali ne uklapaju se sve funkcije u ovaj model. Tako, na primjer, nakon primitka određenih signala, jezgra stvara datoteku za proces koji se naziva "jezgra" (Poglavlje 7). Stvaranje ove datoteke nije povezano s određenom funkcijom sustava, već na kraju izvodi nekoliko operacija, poput stvaranja datoteke, provjere dopuštenja i izvođenja niza zapisa.

U slučaju funkcije otvorenog sustava, zahtjev za izvršavanje funkcije poslane na udaljeni stroj uključuje dio naziva datoteke koji je ostao nakon isključivanja komponenti naziva puta pretraživanja koje razlikuju udaljenu datoteku, kao i različite zastavice. U ranijem primjeru otvaranja datoteke "/usr/src/cmd/login.c", kernel šalje naziv "cmd/login.c" udaljenom računalu. Poruka također uključuje vjerodajnice kao što su identifikacijski kodovi korisnika i grupe, koji su potrebni za provjeru dopuštenja datoteka na udaljenom računalu. Ako se s udaljenog stroja primi odgovor koji označava uspješnu funkciju otvaranja, lokalno jezgro dohvaća slobodan indeks u memoriji lokalnog stroja i označava ga kao indeks udaljene datoteke, pohranjuje podatke o udaljenom stroju i udaljenom indeksu te rutinski dodjeljuje novi unos u tablici datoteka. U usporedbi s stvarnim indeksom na udaljenom stroju, indeks u vlasništvu lokalnog stroja je formalan i ne krši konfiguraciju modela, koja je uglavnom ista kao konfiguracija koja se koristi pri pozivanju udaljenog postupka (slika 13.11). Ako funkcija koja je pozvana procesom pristupa udaljenoj datoteci po svom deskriptoru, lokalna jezgra iz (lokalnog) indeksa zna da je datoteka udaljena, formulira zahtjev koji uključuje pozvanu funkciju i šalje je na udaljeni stroj. Zahtjev sadrži pokazivač na udaljeni indeks pomoću kojeg satelitski proces može identificirati samu udaljenu datoteku.

Nakon što je primio rezultat izvršavanja bilo koje sistemske funkcije, kernel može pribjeći uslugama posebnog programa za njegovu obradu (po završetku kojega će jezgro dovršiti rad s funkcijom), jer se lokalna obrada rezultata koristi u jednoprocesorskom sustavu nije uvijek prikladan za sustav s više procesora. Zbog toga su moguće promjene semantike algoritama sustava s ciljem pružanja podrške za izvršavanje funkcija udaljenog sustava. Međutim, u isto vrijeme mrežom cirkulira minimalni protok poruka, osiguravajući minimalno vrijeme odgovora sustava na dolazne zahtjeve.

13.4 DISTRIBUCIRANI MODEL BEZ PROCESA PRIJENOSA

Korištenje procesa prijenosa (satelitski procesi) u transparentnom distribuiranom sustavu olakšava praćenje izbrisanih datoteka, ali je procesna tablica udaljenog sustava preopterećena satelitskim procesima koji većinu vremena ne rade. U drugim shemama za obradu udaljenih zahtjeva koriste se posebni poslužiteljski procesi (vidi i). Udaljeni sustav ima skup (spremište) poslužiteljskih procesa koje s vremena na vrijeme dodjeljuje za obradu dolaznih udaljenih zahtjeva. Nakon obrade zahtjeva, poslužiteljski proces se vraća u spremište i ulazi u stanje spremno za obradu drugih zahtjeva. Poslužitelj ne čuva korisnički kontekst između dva poziva jer može obraditi zahtjeve iz više procesa odjednom. Stoga svaka poruka koja stiže iz klijentskog procesa mora sadržavati podatke o okruženju izvođenja, naime: identifikacijske kodove korisnika, trenutni direktorij, signale itd. Funkcije.

Kad proces otvori udaljenu datoteku, udaljena jezgra dodjeljuje indeks za sljedeće veze na datoteku. Lokalni stroj ima prilagođenu tablicu deskriptora datoteka, tablicu datoteka i indeksnu tablicu s redovitim skupom zapisa, s unosom tablice indeksa koji identificira udaljeni stroj i udaljeni indeks. U slučajevima kada funkcija sustava (na primjer, čitanje) koristi deskriptor datoteke, jezgro šalje poruku koja upućuje na prethodno dodijeljeni udaljeni indeks i prenosi podatke vezane za proces: identifikacijski kod korisnika, najveću veličinu datoteke itd. Stroj ima poslužiteljskog procesa koji mu je na raspolaganju, interakcija s klijentom ima oblik opisan ranije, međutim, veza između klijenta i poslužitelja uspostavlja se samo za vrijeme trajanja funkcije sustava.

Korištenje poslužitelja umjesto satelitskih procesa može otežati upravljanje podatkovnim prometom, signalima i udaljenim uređajima. Veliki broj zahtjeva prema udaljenom računalu trebao bi se staviti u red čekanja u nedostatku dovoljnog broja poslužitelja. To zahtijeva protokol višeg sloja od onog koji se koristi na glavnoj mreži. U satelitskom modelu, pak, prezasićenost je eliminirana jer se svi zahtjevi klijenata obrađuju sinkrono. Klijent može imati najviše jedan zahtjev na čekanju.

Obrada signala koji ometaju izvršavanje funkcije sustava također je komplicirana pri korištenju poslužitelja, budući da udaljeni stroj mora tražiti odgovarajući poslužitelj koji služi izvršavanju funkcije. Čak je moguće da je, zbog zauzetosti svih poslužitelja, zahtjev za sistemskom funkcijom u stanju čekanja za obradu. Uvjeti za pojavu natjecanja također se javljaju kada poslužitelj vrati rezultat funkcije procesa u pozivni proces, a odgovor poslužitelja uključuje slanje odgovarajuće signalne poruke kroz mrežu. Svaka poruka mora biti označena tako da je udaljeni sustav može prepoznati i po potrebi prekinuti poslužiteljske procese. Prilikom korištenja satelita automatski se identificira proces koji obrađuje ispunjenje zahtjeva klijenta, a u slučaju dolaska signala nije teško provjeriti je li zahtjev dovršen ili nije.

Konačno, ako sistemska funkcija koju pozove klijent uzrokuje da poslužitelj pauzira na neodređeno vrijeme (na primjer, pri čitanju podataka s udaljenog terminala), poslužitelj ne može obraditi druge zahtjeve za oslobađanje spremišta poslužitelja. Ako više procesa pristupa udaljenim uređajima odjednom i ako je broj poslužitelja ograničen odozgo, postoji prilično opipljivo usko grlo. To se ne događa sa satelitima, budući da je satelit dodijeljen svakom procesu klijenta. Drugi problem s korištenjem poslužitelja za udaljene uređaje bit će obrađen u vježbi 13.14.

Unatoč prednostima koje pruža upotreba satelitskih procesa, potreba za besplatnim unosom u tablicu procesa u praksi postaje toliko akutna da se u većini slučajeva usluge poslužiteljskih procesa još uvijek koriste za obradu udaljenih zahtjeva.

Slika 13.12. Konceptualni dijagram interakcije s udaljenim datotekama na razini jezgre

13.5 ZAKLJUČCI

U ovom smo poglavlju razmotrili tri sheme za rad s datotekama koje se nalaze na udaljenim strojevima, tretirajući udaljene datotečne sustave kao proširenje lokalnog. Arhitektonske razlike između ovih rasporeda prikazane su na slici 13.12. Svi se oni, pak, razlikuju od višeprocesorskih sustava opisanih u prethodnom poglavlju po tome što ovdje procesori ne dijele fizičku memoriju. Periferni procesorski sustav sastoji se od čvrsto povezanog skupa procesora koji dijele datotečne resurse središnjeg procesora. Veza tipa Newcastle pruža skriven ("transparentan") pristup udaljenim datotekama, ali ne pomoću jezgre operacijskog sustava, već korištenjem posebne C knjižnice. Iz tog razloga, svi programi koji namjeravaju koristiti ovu vrstu veze moraju se ponovno kompajlirati, što je općenito ozbiljan nedostatak ove sheme. Udaljenost datoteke označena je posebnim nizom znakova koji opisuju stroj na kojem se datoteka nalazi, a to je još jedan faktor koji ograničava prenosivost programa.

U transparentnim distribuiranim sustavima modifikacija funkcije montiranja sustava koristi se za pristup udaljenim datotekama. Indeksi na lokalnom sustavu označeni su kao udaljene datoteke, a lokalno jezgro šalje poruku udaljenom sustavu opisujući traženu funkciju sustava, njegove parametre i udaljeni indeks. Komunikacija u "transparentnom" distribuiranom sustavu podržana je u dva oblika: u obliku poziva udaljenoj proceduri (poruka se šalje na udaljeni stroj koja sadrži popis operacija povezanih s indeksom) i u obliku poziva na funkciju udaljenog sustava (poruka opisuje traženu funkciju). Završni dio poglavlja razmatra pitanja koja se odnose na obradu udaljenih zahtjeva pomoću satelitskih procesa i poslužitelja.

13.6 VJEŽBE

*jedan. Opišite implementaciju funkcije izlaznog sustava u sustavu s perifernim procesorima. Koja je razlika između ovog slučaja i kada proces završi nakon primitka nehvaćenog signala? Kako bi kernel trebao ispustiti sadržaj memorije?

2. Procesi ne mogu zanemariti SIGKILL signale; Objasnite što se događa u perifernom sustavu kada proces primi takav signal.

* 3. Opišite implementaciju funkcije exec sustava na sustavu s perifernim procesorima.

*4. Kako bi središnji procesor trebao raspodijeliti procese među perifernim procesorima kako bi uravnotežio ukupno opterećenje?

*pet. Što se događa ako periferni procesor nema dovoljno memorije za smještaj svih procesa koji su na njega istovareni? Kako bi trebalo izvršiti istovar i zamjenu procesa u mreži?

6. Razmotrite sustav u kojem se zahtjevi udaljenom poslužitelju datoteka šalju ako se u imenu datoteke pronađe poseban prefiks. Neka proces pozove execl ("/../ sftig / bin / sh", "sh", 0); Izvršna datoteka je na udaljenom računalu, ali mora biti pokrenuta na lokalnom sustavu. Objasnite kako se udaljeni modul migrira na lokalni sustav.

7. Ako administrator treba dodati nove strojeve u postojeći sustav s vezom poput Newcastlea, kako je najbolji način obavijestiti module knjižnice C o tome?

*osam. Tijekom izvršavanja exec funkcije, kernel prepisuje adresni prostor procesa, uključujući tablice knjižnica koje koristi veza Newcastlea za praćenje veza do udaljenih datoteka. Nakon izvršavanja funkcije, proces mora zadržati mogućnost pristupa tim datotekama prema njihovim starim opisima. Opišite provedbu ove točke.

*devet. Kao što je prikazano u odjeljku 13.2, pozivanje funkcije izlaznog sustava na sustavima s Newcastleovom vezom rezultira slanjem poruke popratnom procesu, prisiljavajući potonji da se prekine. To se radi na razini knjižničnih rutina. Što se događa kada lokalni proces primi signal koji mu govori da izađe u načinu rada jezgre?

*10. U sustavu s vezom u Newcastleu, gdje su udaljene datoteke identificirane prefiksom imena s posebnim prefiksom, kako može korisnik, navodeći ".." (nadređeni direktorij) kao komponentu naziva datoteke, preći udaljenu točku montiranja?

11. Iz Poglavlja 7 znamo da različiti signali uzrokuju da proces izbaci sadržaj memorije u trenutni direktorij. Što bi se trebalo dogoditi ako je trenutni direktorij iz udaljenog datotečnog sustava? Koji biste odgovor dali ako sustav koristi odnos poput Newcastlea?

*12. Koje su posljedice za lokalne procese ako se svi satelitski ili poslužiteljski procesi uklone iz sustava?

*13. Razmislite kako implementirati algoritam povezivanja u transparentan distribuirani sustav čiji parametri mogu biti dva naziva udaljenih datoteka, kao i exec algoritam, povezan s izvođenjem nekoliko internih operacija čitanja. Razmotrite dva oblika komunikacije: poziv udaljene procedure i poziv funkcije udaljenog sustava.

*četrnaest. Prilikom pristupa uređaju, poslužiteljski proces može ući u suspendirano stanje, iz kojeg će ga izvaditi upravljački program uređaja. Naravno, ako je broj poslužitelja ograničen, sustav više neće moći zadovoljiti zahtjeve lokalnog računala. Osmislite pouzdanu shemu u kojoj nisu svi poslužiteljski procesi obustavljeni dok se čeka dovršetak ulaza / izlaza vezanih za uređaj. Funkcija sustava neće se prekinuti dok su svi poslužitelji zauzeti.

Slika 13.13. Konfiguracija terminalnog poslužitelja

*petnaest. Kad se korisnik prijavi u sustav, disciplina terminalne linije sprema informacije da je terminal operacijski terminal koji vodi skupinu procesa. Iz tog razloga, kada korisnik pritisne tipku "break" na terminalnoj tipkovnici, svi procesi u grupi primaju signal prekida. Razmotrimo konfiguraciju sustava u kojoj su svi terminali fizički spojeni na jedan stroj, ali se registracija korisnika logički provodi na drugim strojevima (slika 13.13). U svakom slučaju, sustav stvara getty proces za udaljeni terminal. Ako zahtjeve prema udaljenom sustavu obrađuje skup poslužiteljskih procesa, imajte na umu da kada se izvrši otvorena procedura, poslužitelj prestaje čekati vezu. Kad se funkcija otvaranja dovrši, poslužitelj se vraća u spremište poslužitelja, prekidajući svoju vezu s terminalom. Kako se signal prekida šalje pritiskom na tipku "break" na adrese procesa uključenih u istu grupu?

*šesnaest. Dijeljenje memorije značajka je svojstvena lokalnim strojevima. S logičkog gledišta, dodjela zajedničkog područja fizičke memorije (lokalne ili udaljene) može se provesti za procese koji pripadaju različitim strojevima. Opišite provedbu ove točke.

* 17. Paging procesa i algoritmi straničenja koji su razmatrani u 9. poglavlju pretpostavljaju upotrebu lokalnog dojavljivača. Koje bi izmjene trebale biti unesene u ove algoritme kako bi se moglo podržati uređaje za istovar na daljinu?

*18. Pretpostavimo da se na udaljenom stroju (ili na mreži) dogodio fatalni pad, a protokol lokalnog mrežnog sloja bilježi tu činjenicu. Razviti shemu oporavka za lokalni sustav koji šalje zahtjeve udaljenom poslužitelju. Osim toga, razviti shemu oporavka za poslužiteljski sustav koji je izgubio kontakt s klijentima.

*devetnaest. Kada proces pristupi udaljenoj datoteci, moguće je da će preći više strojeva u potrazi za datotekom. Uzmite za primjer naziv " / usr / src / uts / 3b2 / os", gdje je " / usr" direktorij koji pripada stroju A, " / usr / src" je mjesto montiranja korijena stroja B, " / usr / src / uts / 3b2 "je točka montiranja korijena stroja C. Hodanje kroz više strojeva do krajnjeg odredišta naziva se" multihop ". Međutim, ako postoji izravna mrežna veza između strojeva A i C, slanje podataka putem stroja B bilo bi neučinkovito. Opišite značajke implementacije "multishoppinga" u sustavu s Newcastle vezom i u "transparentnom" distribuiranom sustavu.

Danas se distribuiraju gotovo svi veliki softverski sustavi. Distribuirani sustav je sustav u kojemu obrada informacija nije koncentrirana na jednom računalu, već je raspoređena među nekoliko računala. Prilikom projektiranja distribuiranih sustava, koji ima mnogo zajedničkog s dizajnom bilo kojeg drugog softvera, potrebno je uzeti u obzir još niz specifičnih značajki. Neki od njih već su spomenuti u uvodu Poglavlja 10 kada smo pogledali arhitekturu klijent / poslužitelj, a ovdje se detaljnije raspravlja.

Budući da su distribuirani sustavi danas rašireni, programeri softvera trebali bi biti upoznati sa specifičnostima svog dizajna. Do nedavno su svi veliki sustavi bili uglavnom centralizirani, radili su na jednom glavnom računalu (glavnom računalu) s priključenim terminalima. Terminali praktički nisu obrađivali informacije - svi proračuni izvedeni su na računalu domaćinu. Programeri takvih sustava nisu morali razmišljati o problemima distribuiranog računalstva.

Svi moderni softverski sustavi mogu se podijeliti u tri široke klase.

1. Sustavi aplikacijskog softvera dizajnirani za rad samo na jednom osobnom računalu ili radnoj stanici. To uključuje procesore teksta, proračunske tablice, grafičke sustave itd.

2. Ugrađeni sustavi dizajnirani za rad na jednom procesoru ili na integriranoj skupini procesora. To uključuje sustave upravljanja za kućanske aparate, razne aparate itd.

3. Distribuirani sustavi u kojima softver radi na labavo integriranoj skupini paralelnih procesora koji su povezani mrežom. To uključuje bankomate u vlasništvu banke, izdavačke sustave, zajedničke softverske sustave itd.

Trenutno postoje jasne granice između navedenih klasa softverskih sustava, koje će se u budućnosti sve više brisati. S vremenom, kako bežične mreže velike brzine postaju široko dostupne, bit će moguće dinamički integrirati uređaje s ugrađenim softverskim sustavima, poput elektroničkih organizatora s općenitijim sustavima.

Postoji šest glavnih karakteristika distribuiranih sustava.

1. Dijeljenje resursa. Distribuirani sustavi omogućuju dijeljenje hardverskih i softverskih resursa poput tvrdih diskova, pisača, datoteka, kompajlera i slično koji su povezani putem mreže. Očigledno je da je dijeljenje resursa moguće i u sustavima s više korisnika, ali u ovom slučaju središnje računalo mora biti odgovorno za opskrbu resursima i njihovo upravljanje.

2. Otvorenost. Ovo je mogućnost proširenja sustava dodavanjem novih resursa. Distribuirani sustavi su otvoreni sustavi koji povezuju hardver i softver različitih proizvođača.

3. Paralelizam. U distribuiranim sustavima više procesa može istodobno raditi na različitim računalima u mreži. Ti procesi mogu (ali ne moraju) međusobno djelovati tijekom izvođenja.

4. Skalabilnost. U načelu, svi su distribuirani sustavi skalabilni: kako bi se zadovoljili novi zahtjevi, sustav se može proširiti dodavanjem novih računalnih resursa. No, u praksi se nakupljanje može ograničiti na mrežu koja povezuje pojedinačna računala u sustavu. Ako je spojeno mnogo novih strojeva, propusnost mreže možda neće biti dovoljna.

5. Tolerancija kvarova. Prisutnost više računala i mogućnost dupliciranja informacija znači da su distribuirani sustavi otporni na određene hardverske i softverske pogreške. Većina distribuiranih sustava, u slučaju pogreške, obično može podržati barem djelomičnu funkcionalnost. Potpuni kvar sustava događa se samo u slučaju pogrešaka mreže.

6. Transparentnost. Ovo svojstvo znači da se korisnicima daje potpuno transparentan pristup resursima, a istovremeno su im skriveni podaci o raspodjeli resursa u sustavu. Međutim, u mnogim slučajevima posebno znanje o organizaciji sustava pomaže korisniku da bolje iskoristi resurse.

Naravno, distribuirani sustavi imaju niz nedostataka.

Složenost. Distribuirani sustavi složeniji su od centraliziranih. Mnogo je teže razumjeti i ocijeniti svojstva distribuiranih sustava općenito, a također i testirati te sustave. Na primjer, ovdje performanse sustava ne ovise o brzini jednog procesora, već o propusnosti mreže i brzini različitih procesora. Premještanje resursa s jednog dijela sustava na drugi može drastično utjecati na performanse sustava.

Sigurnost. Obično se sustavu može pristupiti s više različitih strojeva, poruke na mreži se mogu pregledavati ili presresti. Stoga je u distribuiranom sustavu mnogo teže održavati sigurnost.

Kontrolabilnost. Sustav se može sastojati od računala različitih tipova, na koja se mogu instalirati različite verzije operativnih sustava. Pogreške na jednom stroju mogu se proširiti na druge strojeve s nepredvidivim posljedicama. Stoga je potrebno mnogo više napora za upravljanje i održavanje sustava u ispravnom stanju.

Nepredvidivo. Kao što su svi korisnici weba svjesni, odgovor distribuiranih sustava na određene događaje je nepredvidiv i ovisi o punom opterećenju sustava, njegovoj organizaciji i opterećenju mreže. Budući da se svi ti parametri mogu stalno mijenjati, vrijeme provedeno na izvršavanju korisničkog zahtjeva u jednom ili drugom trenutku može se značajno razlikovati.

Prilikom rasprave o prednostima i nedostacima distribuiranih sustava identificirani su brojni kritični problemi projektiranja takvih sustava (tablica 9.1).

Tablica 9.1. Problemi projektiranja distribuiranih sustava

Problem dizajna	Opis
Identifikacija resursa	Resursi u distribuiranom sustavu nalaze se na različitim računalima, pa bi trebalo razmisliti o sustavu imenovanja resursa kako bi korisnici mogli lako pristupiti resursima koji su im potrebni. Primjer je sustav Uniform Resource Locator (URL) koji definira adrese web stranica. Bez lako uočljivog i univerzalnog sustava identifikacije, većina resursa bit će nedostupna korisnicima sustava.
Komunikacije	Univerzalna operabilnost Interneta i učinkovita implementacija TCP / IP protokola na Internetu za većinu distribuiranih sustava primjeri su najučinkovitijeg načina organizacije komunikacije između računala. Međutim, tamo gdje se postavljaju posebni zahtjevi za performanse, pouzdanost itd., Mogu se koristiti alternativne metode komunikacije sustava.
Kvaliteta usluga sustava	Kvaliteta usluge koju nudi sustav odražava njegove performanse, operativnost i pouzdanost. Na kvalitetu usluge utječu brojni čimbenici: raspodjela procesa u sustavu, raspodjela resursa, hardver sustava i mreže te prilagodljivost sustava.
Arhitektura softvera	Softverska arhitektura opisuje raspodjelu funkcija sustava među komponentama sustava, kao i raspodjelu tih komponenti po procesorima. Ako trebate održavati visokokvalitetnu uslugu sustava, odabir prave arhitekture bit će odlučujući faktor.

Izazov za dizajnere distribuiranih sustava je dizajnirati softver ili hardver koji će pružiti sve potrebne karakteristike distribuiranog sustava. To zahtijeva poznavanje prednosti i nedostataka različitih arhitektura distribuiranih sustava. Ovdje se ističu dvije povezane vrste arhitektura distribuiranih sustava.

1. Arhitektura klijent / poslužitelj. U ovom modelu sustav se može zamisliti kao skup usluga koje poslužitelji pružaju klijentima. U takvim se sustavima poslužitelji i klijenti međusobno značajno razlikuju.

2. Arhitektura distribuiranih objekata. U tom slučaju nema razlika između poslužitelja i klijenata, a sustav se može zamisliti kao skup međusobno povezanih objekata čija lokacija zapravo nije važna. Ne postoji razlika između davatelja usluga i njegovih korisnika.

U distribuiranom sustavu različite komponente sustava mogu se implementirati u različite programske jezike i izvoditi na različitim vrstama procesora. Modeli podataka, prezentacija informacija i komunikacijski protokoli nisu nužno svi iste vrste u distribuiranom sustavu. Posljedično, distribuirani sustavi zahtijevaju softver koji može upravljati tim heterogenim dijelovima i jamčiti interakciju i razmjenu podataka između njih. Srednji softver odnosi se upravo na ovu klasu softvera. On je, takoreći, na sredini između različitih dijelova distribuiranih komponenti sustava.

Distribuirani sustavi obično su projektirani s objektno orijentiranim pristupom. Ti su sustavi stvoreni od labavo integriranih dijelova, od kojih svaki može izravno komunicirati i s korisnikom i s drugim dijelovima sustava. Ti bi dijelovi trebali, kad god je to moguće, reagirati na neovisne događaje. Softverski objekti temeljeni na tim načelima prirodne su komponente distribuiranih sustava. Ako već niste upoznati s pojmom objekata.