bazat pe mediul de calcul reconfigurabil multi-conducte L-Net

Una dintre sarcinile urgente din domeniul sistemelor de control este dezvoltarea de software pentru sisteme distribuite de control tolerante la defecte. Soluțiile existente astăzi în acest domeniu sunt proprietare, ca urmare, costisitoare și nu întotdeauna eficiente.

Aceste soluții nu prevăd utilizarea eficientă a resurselor bazelor redundante, tehnice și software, ceea ce afectează negativ atât toleranța la erori, cât și scalabilitatea acestor soluții. Dacă arhitectura rețelei este încălcată, nu există nicio posibilitate de reconfigurare dinamică atât a proceselor de procesare a informațiilor, cât și a transmiterii fluxurilor de date (atât de control, cât și de informații). Utilizarea microcontrolerelor specifice, utilizarea DCS / SCADA complică dezvoltarea și suportul sistemelor, extinderea funcționalității acestora.

Arhitectura sistemului de control distribuit

Arhitectura tipică generalizată a unui sistem de control distribuit (DCS) include trei niveluri legate ierarhic: nivelul operatorului, nivelul de control și nivelul I / O (vezi Fig. 1).

Sarcina principală a nivelului operatorului este de a furniza o interfață om-mașină (HMI) pentru a asigura configurarea și controlul funcționării întregului sistem. Nivelul de control este responsabil pentru primirea și prelucrarea datelor de la senzori, transmiterea datelor la nivelul operatorului și dezvoltarea acțiunilor de control asupra dispozitivelor de acționare. Nivelul I / O reprezintă senzori și actuatori conectați direct la obiectul controlat.

Sarcina software-ului, în cadrul arhitecturii generalizate a DCS, este de a asigura funcționarea nivelului operatorului și conexiunea acestuia cu nivelul de control al sistemului. În consecință, nivelul fundamental în proiectarea software-ului și rezolvarea problemelor de interacțiune cu hardware este cel al operatorului. Software-ul ar trebui să profite la maximum de resursele hardware disponibile ale sistemului, fiind în același timp cât mai independent de arhitectura internă a hardware-ului.

Hardware oferă resurse de calcul, memorie și suporturi de comunicație între nodurile dintr-un sistem. La proiectarea arhitecturii generale a sistemului, nodurile specifice nivelului I / O care vor fi conectate la acesta într-o implementare specifică nu sunt luate în considerare; prin urmare, nivelul operatorului și nivelul de control sunt luate în considerare în arhitectura generală. Hardware-ul trebuie să fie răspândit, să respecte standardele moderne și să aibă toate proprietățile și capacitățile necesare implementării arhitecturii.

Cerințe DCS

Cerințele pentru DCS se aplică nu numai sistemului în ansamblu, ci și componentelor sale hardware și software separat, deoarece abordările specifice pentru îndeplinirea acestor cerințe pentru aceste componente pot fi fundamental diferite. DCS ar trebui să fie, în primul rând, tolerant la erori. Cea mai simplă metodă de creștere a toleranței la defecțiuni este redundanța (duplicarea) unităților funcționale sau a agregatului lor. A doua proprietate importantă este scalabilitatea. Scalabilitatea se bazează pe implementarea unor algoritmi speciali în software și capacitatea hardware de a înlocui și adăuga noi noduri sau părțile componente ale acestora. În același timp, sistemul ar trebui să rămână simplu pentru funcționarea sa, dezvoltarea de noi noduri sau module și modificarea arhitecturii sale.

Prezentare generală a arhitecturilor DCS

Pentru revizuirea arhitecturilor DCS, Siemens SIMATIC PCS 7 DCS a fost selectat ca unul dintre cele mai solicitate de pe piață și RTS S3 ca DCS implementat pe baza QNX RTOS.

Siemens SIMATIC PCS 7

Arhitectura sistemului are toate proprietățile unei arhitecturi DCS generice. Stațiile operator sunt computere bazate pe arhitectura procesorului x86 cu sistem de operare Windows și pachetul Siemens WinCC, care oferă un HMI. Există servere cu baze de date. Stațiile operatorilor, stațiile de inginerie și serverele sunt conectate printr-o rețea locală bazată pe Ethernet. Nivelul operatorului este legat de planul de control al rețelei redundante Industrial Ethernet. La nivel de control există controlere logice programabile (PLC) cu posibilitatea redundanței datorită dublării funcționalității. Este posibil să vă conectați la sisteme și rețele externe și să organizați accesul la distanță la sistem.

RTS S3

Această arhitectură constă în mod similar din straturile structurii generalizate a DCS. Stațiile operatorului se bazează pe aceeași platformă hardware ca în SIMATIC DCS, dar pot fi operate atât în ​​sistemele de operare Windows, cât și în Linux. Stațiile de inginerie sunt combinate cu stațiile de operator. Sistemul oferă un mediu de dezvoltare a aplicațiilor unificat. Ethernet conectează nodurile din stratul operator și nivelul operatorului însuși cu planul de control utilizând stiva de protocol TCP / IP. La nivel de control există computere industriale care rulează sistemul QNX OS cu propria bază de date și posibilitatea redundanței prin duplicarea funcționalității nodului.

Dezavantaje ale sistemelor descrise

Sistemele descrise mai sus utilizează o platformă hardware / software diferită pentru nivelul operatorului și planul de control. În cadrul nivelului operator, poate fi utilizată o singură arhitectură de procesor și este necesară o stație specială de inginerie pentru a configura și dezvolta nivelul de control. Aceste DCS oferă doar redundanță hardware cu duplicarea funcționalității nodului redundant ca o modalitate de a crește toleranța la erori, care este o utilizare irațională a hardware-ului redundant.

Caracteristici și caracteristici funcționale ale sistemului L-Net

La dezvoltarea sistemului L-Net, sarcina a fost crearea unui sistem de control care să aibă următoarele caracteristici:

• Reconfigurare dinamică cu recuperare completă cu pierderi minime în caz de eșec al gazdei sau întreruperea topologiei rețelei.
• Distribuirea eficientă a sarcinilor între nodurile de rețea eficiente disponibile.
• Duplicarea canalelor de comunicare între noduri cu reconfigurare dinamică a fluxurilor de transmisie de date.
• Ușurința de utilizare și scalabilitatea sistemului.
• Portabilitatea și performanța sistemului pe orice platformă hardware concepută pentru sisteme de control al clădirilor și sisteme încorporate.

Pentru a construi un sistem cu caracteristicile de mai sus, este necesar un sistem de operare, destinat în primul rând pentru crearea de sisteme de control și sisteme încorporate. Analiza sistemelor de operare existente a arătat că cel mai potrivit sistem de operare este QNX 6 (Neutrino), care are alocare de resurse foarte eficientă și capacități de rețea. Capabilitățile largi de rețea sunt furnizate de protocolul de rețea Qnet. Rezolvă problema fiabilității și echilibrării dinamice a sarcinii canalelor de comunicații, dar nu rezolvă problema toleranței la erori a sistemului în ansamblu. Ca rezultat, a fost dezvoltat un sistem inovator de control bazat pe un mediu de calcul reconfigurabil distribuit multi-conducte. Sistemul dezvoltat are o arhitectură peer-to-peer care include trei blocuri logice: un bloc de intrare-ieșire, un bloc de comutare general și un bloc de mediu de calcul reconfigurabil (RCS) (vezi Fig. 2).

Principalele avantaje ale acestei arhitecturi sunt:

• Tipul de la egal la egal
• Descentralizare
• Scalabilitate
• Distributie spatiala

Caracteristicile funcționale ale acestei arhitecturi:

• Prelucrarea datelor prin conducte
• Redundanță hardware
• Distribuția încărcăturii
• Reconfigurare din mers

La primul nivel al arhitecturii există o unitate de intrare-ieșire (I / O), care include: noduri de intrare-ieșire, un comutator de noduri de intrare-ieșire, o interfață de intrare-ieșire, senzori și actuatori. Unitatea este responsabilă pentru mecanismele de bază pentru generarea acțiunilor de control pe baza datelor de la senzorii locali și a datelor primite de la alte niveluri ale sistemului de control. Sarcinile atribuite sunt distribuite între nodurile I / O sănătoase pe baza performanței relative curente sau manual de către operator. Senzorii și actuatorii sunt conectați printr-un autobuz la toate nodurile I / O din bloc, ceea ce permite oricărui nod să interogheze orice senzor sau să genereze un efect asupra oricărui actuator. Comutatorul nodului I / O asigură comunicarea între toate nodurile I / O pentru a face schimb de date între ele și alte niveluri ale arhitecturii sistemului pentru a obține date de control și informații. Cu capacitățile hardware adecvate, nodurile comunică între ele și cu noduri și comutatoare la alte niveluri ale sistemului direct, ceea ce reduce timpul de răspuns în rețea. Comunicarea directă între noduri și o anumită sarcină de noduri în modul curent de funcționare a unității I / O permite organizarea calculelor conductelor în unitate, care sunt necesare pentru funcționarea acestei unități fără a recurge la puterea de calcul externă a sistemului de control ( DCS), care face posibilă utilizarea eficientă a resurselor gratuite furnizate pentru nodurile de redundanță ale unității I / O în momentul eșecului.

Blocul comutatoarelor de uz general, situat la al doilea nivel al arhitecturii, organizează linii de comunicație între blocurile de intrare-ieșire și sistemele DCS și externe. Fiecare comutator poate interconecta diverse legături și comutatoare în întregul sistem de control. Numărul de linii de comunicație este determinat de capacitățile hardware ale nodurilor și comutatoarelor incluse în blocuri. Deoarece rețeaua Qnet vă permite să distribuiți dinamic fluxurile de date, scalarea acestui bloc se realizează prin simpla conectare a dispozitivelor noi și nu necesită configurare, iar dacă unul dintre comutatoare eșuează, transferul de date între noduri nu va fi întrerupt dacă alt comutator oferă o conexiune similară între noduri sau acestea sunt direct legate. În același timp, este necesar să aveți grijă de lățimea de bandă de rețea suficientă necesară pentru a face backup unui switch eșuat.

Blocul de rețea de calcul reconfigurabil (RCN), situat la al treilea nivel al arhitecturii, oferă un sistem de gestionare a puterii de calcul ridicat pentru rezolvarea problemelor complexe de procesare a informațiilor, luarea deciziilor, recunoaștere etc. Blocul este responsabil pentru inițializarea întregului sistem de control: verificarea operabilității comutatoarelor și a nodurilor, integritatea rețelei, construirea graficelor de rețea ale întregului sistem, setarea parametrilor de pornire pentru funcționarea blocurilor de intrare-ieșire. Nodurile acestui bloc asigură arhivarea atât a propriilor date, cât și a datelor din blocurile I / O. Fiecare nod al acestui bloc poate juca rolul unei mașini a operatorului proiectat să monitorizeze funcționarea sistemului și să facă ajustări la programele de lucru ale acestui nod și ale tuturor nodurilor sistemului și să efectueze reconfigurarea la cerere.

Distribuția încărcăturii

Una dintre principalele sarcini ale sistemului L-Net este distribuirea sarcinii de calcul pe nodurile de rețea. Soluția la această problemă se bazează pe construirea conductelor de calcul. Pentru a construi o conductă de calcul, preliminar este construit un grafic de sarcini - o schemă pentru schimbul de fluxuri de date de la o sursă la un receptor. Senzorii acționează ca o sursă, iar actuatorii acționează ca un destinatar. Conducta de calcul în sine este o mapare a graficului sarcinii (vezi Fig. 3) pe graficul rețelei de calculatoare (vezi Fig. 4), luând în considerare cerințele sarcinii la resursele de calcul ale sistemului și starea sa actuală.

Soluția este de a utiliza un serviciu care oferă destinatarului informații complete despre hardware-ul curent, starea acestuia și sursele de date disponibile, care efectuează lucrări cu grafice și sarcini de rețea. Ca rezultat, performanța crește datorită canalizării calculelor și este organizată utilizarea rațională a tuturor resurselor de calcul disponibile pentru sistem.

toleranță la erori

Principala problemă a funcționării unui astfel de sistem este o întrerupere completă a conductelor de calcul în cazul unei defecțiuni a oricărui nod al acestui transportor sau în încălcarea transferului de date între ele. Mijloacele de bază ale protocolului Qnet realizează restaurarea conexiunilor între noduri în cazul încălcării parțiale a acestora din cauza liniilor de rezervă furnizate de arhitectură. Sistemul L-Net rezolvă problema restabilirii operabilității în cazul unei eșecuri complete a gazdei sistemului de calcul prin reconfigurarea dinamică a conductei de calcul, adică folosind resurse de lucru pentru a înlocui blocul rău. Sistemul oferă trei scenarii de recuperare (reconfigurare) care diferă în ceea ce privește timpul de răspuns la eșec, timpul de recuperare și resursele hardware utilizate: la eșec, cu pregătire pasivă și pregătire activă.

• Reconfigurare la eșec- după detectarea unei defecțiuni, se efectuează căutarea hardware-ului disponibil și includerea acestuia în graficul activităților.
• Reconfigurare cu disponibilitate pasivă- hardware-ul redundant este determinat în prealabil, se începe un proces care asigură implementarea vârfului graficului de sarcini pe un nod, conexiunile sunt stabilite, dar procesul nu procesează date decât dacă nodul principal eșuează.
• Reconfigurare cu disponibilitate activă- partea de sus a graficului de sarcini este implementată pe mai multe noduri, care efectuează prelucrarea datelor în paralel și transmit rezultatul.

Ca rezultat, sistemul oferă o disponibilitate flexibilă pentru eșecuri atât la nivel de software, cât și hardware, capacitatea de a schimba configurația nodurilor fără a întrerupe munca și pierde performanța indiferent de implementarea rețelei, a conductei de calcul și a nodului.

Concluzie

Sistemul L-Net dezvoltat, spre deosebire de analogii existenți, presupune utilizarea unei game largi de caracteristici hardware ale nodurilor DCS cu compatibilitatea lor completă cu software-ul. Când nodurile funcționează sub controlul unui sistem de operare (QNX Neutrino), este posibil să le construiți pe diferite arhitecturi de procesor (x86, ARM, MIPS etc.) cu o varietate de interfețe și dispozitive periferice. Implementarea nodurilor este posibilă sub formă de desktop, PC-uri industriale, PC-uri purtabile și computere cu o singură placă. Toate componentele complexului software al DCS dezvoltat pot fi lansate pe oricare dintre nodurile sale cu sistemul de operare QNX, în timp ce rămâne posibilă utilizarea nodurilor cu un sistem de operare diferit. Această abordare permite fiecărui nod să fie utilizat pentru a rezolva atât sarcini la nivel de operator, cât și la nivel de control. În consecință, există un sistem flexibil de interacțiune între colegii fără o ierarhie rigidă a nivelurilor inerente arhitecturii DCS generalizate și sisteme care utilizează această arhitectură ca bază. Rețeaua de la egal la egal simplifică procesele de implementare, operare, scalare și depanare a unui sistem.

Pentru a realiza potențialul de calcul al hardware-ului redundant în sistemul dezvoltat, sunt propuși algoritmi pentru configurare dinamică și reconfigurare bazate pe protocolul de rețea Qnet și software-ul de rețea L-Net. Algoritmul de configurare dinamică se bazează pe distribuirea sarcinii de calcul pe toate nodurile prin pipelining și paralelizarea sarcinilor și echilibrarea dinamică a sarcinii pe canalele de transmisie de date între noduri. Algoritmul de reconfigurare a sistemului presupune prezența a trei scenarii pentru restabilirea operabilității în caz de eșec, în funcție de hardware-ul disponibil, prioritățile și sarcinile atribuite sistemului: la eșec, cu disponibilitate pasivă (alocarea resurselor) și cu disponibilitate activă (utilizarea resurselor) . Configurarea dinamică și algoritmii de reconfigurare îmbunătățesc performanța și fiabilitatea utilizând rezervele hardware din sistem.

Un avantaj important al sistemului este transparența maximă a tehnologiilor hardware și software utilizate în acesta, ceea ce face posibilă simplificarea serioasă a suportului tehnic al sistemului și dezvoltarea de noi module pentru acesta.

Concluzie

Soluțiile arhitecturale dezvoltate permit îmbunătățirea unor astfel de indicatori ai sistemelor de control distribuite precum fiabilitatea, performanța, costul, scalabilitatea și simplitatea datorită posibilității de a utiliza o gamă largă de hardware, a implementării algoritmilor de configurare dinamică și a utilizării raționale a resurselor sistemului.

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: Bazele aplicației. - SPb: BHV-Petersburg, 2005.
5. Krten R. Introducere în QNX Neutrino. Un ghid pentru dezvoltarea aplicațiilor în timp real. - SPb: BHV-Petersburg, 2011.

Cuvinte cheie: sistem de control distribuit, suport informațional pentru sistemele de control, sisteme distribuite reconfigurabile.

Arhitectura unui sistem de control distribuit bazat pe mediul de calcul reconfigurabil multi-conducte L-Net

Sergey Yu. Potomskiy, profesor asistent al Universității Naționale de Cercetare „Școala Superioară de Economie”.

Nikita A. Poloyko, student în anul V al Universității Naționale de Cercetare „Școala Superioară de Economie”. Asistent de studiu. Programator. Domeniul de instruire: „Control și informatică în sistemele tehnice”.

Abstract. Articolul este dedicat unui sistem de control distribuit bazat pe un mediu de calcul reconfigurabil multi-conducte. Arhitectura sistemului este dată. De asemenea, sunt prezentate și caracteristicile de bază și proprietățile funcționale ale sistemului. Articolul prezintă o justificare pentru alegerea sistemului de operare. Avantajele de bază ale sistemului în comparație cu dezvoltările similare existente sunt prezentate în articol.

Cuvinte cheie: sistem de control distribuit, suport software pentru sistem, reconfigurabil distribuit.

În contact cu

Sisteme multicomputer eterogene

Cel mai mare număr de sisteme distribuite existente în prezent sunt construite în conformitate cu schema sistemelor multicomputer eterogene. Aceasta înseamnă că computerele care fac parte din acest sistem pot fi extrem de diverse, de exemplu, în ceea ce privește tipul de procesor, dimensiunea memoriei și performanța I / O. În practică, rolul unora dintre aceste computere poate fi jucat de sisteme paralele de înaltă performanță, de exemplu, multiprocesor sau sisteme multicomputer omogene.

Rețeaua care le conectează poate fi, de asemenea, foarte eterogenă.

Un exemplu de eterogenitate este crearea de sisteme multicomputer mari care utilizează rețele și canale existente. Așadar, de exemplu, nu este neobișnuit existența sistemelor distribuite universitare, constând din rețele locale de diferite facultăți, interconectate prin canale de mare viteză. În sistemele globale, diferitele stații pot fi la rândul lor conectate prin rețele publice, cum ar fi serviciile de rețea oferite de operatorii de telecomunicații comerciale, cum ar fi SMDS sau Releu cadru.

Spre deosebire de sistemele discutate în paragrafele anterioare, multe sisteme multicomputer eterogene pe scară largă necesită o abordare globală. Aceasta înseamnă că o aplicație nu poate presupune că anumite performanțe sau anumite servicii îi vor fi disponibile tot timpul.

Trecând la problemele de scalare inerente sistemelor eterogene și luând în considerare necesitatea unei abordări globale inerente majorității dintre acestea, observăm că crearea de aplicații pentru sisteme multicomputer eterogene necesită software specializat. Această problemă este tratată de sistemele distribuite. Astfel, dezvoltatorii de aplicații nu trebuie să se îngrijoreze de hardware-ul pe care îl folosesc, sistemele distribuite oferă un shell software care protejează aplicațiile de ceea ce se întâmplă în hardware (adică oferă transparență).

Cea mai veche și fundamentală arhitectură distribuită este client-server, în care una dintre părți (clientul) inițiază schimbul de date prin trimiterea unei cereri către cealaltă parte (serverul). Serverul procesează solicitarea și, dacă este necesar, trimite un răspuns către client (Fig. 2.7).

Orez. 2.7. Model de interacțiune client-server

Interacțiunea în cadrul modelului client-server poate fi fie sincronă, atunci când clientul așteaptă ca serverul să-și proceseze solicitarea, fie asincronă, în care clientul trimite o cerere către server și își continuă execuția fără a aștepta serverul. raspuns. Modelul client și server poate fi folosit ca bază pentru descrierea diferitelor interacțiuni. Luați în considerare interacțiunea componentelor software-ului care formează un sistem distribuit.

Orez. 2.8. Nivele logice ale aplicației

Luați în considerare o anumită aplicație tipică, care, în conformitate cu conceptele moderne, poate fi împărțită în următoarele niveluri logice (Fig.2.8): interfața cu utilizatorul (UI), logica aplicației (LP) și accesul la date (DD), lucrul cu o bază de date (DB) ... Utilizatorul sistemului interacționează cu acesta prin interfața cu utilizatorul, baza de date stochează date care descriu domeniul aplicației, iar stratul logic al aplicației implementează toți algoritmii legați de domeniu.

Deoarece, în practică, diferiți utilizatori ai sistemului sunt de obicei interesați să acceseze aceleași date, cea mai simplă separare a funcțiilor unui astfel de sistem între mai multe computere va fi împărțirea straturilor logice ale aplicației între o parte a serverului aplicației responsabil pentru accesarea datelor și a părților client situate pe mai multe computere.implementarea interfeței cu utilizatorul. Logica aplicației poate fi atribuită serverului, clienților sau partajată între ei (Figura 2.9).

Orez. 2.9. Arhitectură pe două niveluri

Arhitectura aplicațiilor construite pe acest principiu se numește client-server sau cu două legături... În practică, astfel de sisteme nu sunt adesea clasificate ca distribuite, dar formal pot fi considerate cei mai simpli reprezentanți ai sistemelor distribuite.

Dezvoltarea arhitecturii client-server este arhitectura pe trei niveluri, în care interfața cu utilizatorul, logica aplicației și accesul la date sunt separate în componente independente ale sistemului care pot rula pe computere independente (Figura 2.10).

Orez. 2.10. Arhitectură pe trei niveluri

Solicitarea utilizatorului în astfel de sisteme este procesată secvențial de partea client a sistemului, de serverul logic al aplicației și de serverul bazei de date. Cu toate acestea, un sistem distribuit este de obicei înțeles ca un sistem cu o arhitectură mai complexă decât una cu trei niveluri.

Orez. 2.11. Sistem distribuit cu amănuntul

În ceea ce privește aplicațiile pentru automatizarea activităților întreprinderii, sistemele distribuite sunt denumite de obicei sisteme cu logica aplicației distribuite între mai multe componente ale sistemului, fiecare dintre acestea putând fi executată pe un computer separat. De exemplu, implementarea logicii de aplicare a unui sistem de vânzare cu amănuntul trebuie să utilizeze interogări către logica de aplicare a terților, cum ar fi furnizorii de bunuri, sistemele de plăți electronice sau băncile care acordă împrumuturi de consum (Figura 2.11).

Un alt exemplu de sistem distribuit sunt rețelele schimb direct de date între clienți (rețele peer-to-peer)... Dacă exemplul anterior a avut o arhitectură „copac”, atunci rețelele de schimb direct sunt organizate într-un mod mai complex, Figura 2.12. Astfel de sisteme sunt în prezent, probabil, unul dintre cele mai mari sisteme distribuite existente, reunind milioane de computere.

Orez. 2.12. Sistem de schimb direct de date între clienți

(Materialul site-ului http://se.math.spbu.ru)

Introducere.

În prezent, sunt distribuite practic toate sistemele software mari. Sistem distribuit- un sistem în care prelucrarea informațiilor este concentrată nu pe un singur computer, ci este distribuită între mai multe computere. La proiectarea sistemelor distribuite, care are multe în comun cu proiectarea software-ului în general, mai sunt încă câteva elemente de luat în considerare.

Există șase caracteristici principale ale sistemelor distribuite.

1. Partajarea resurselor. Sistemele distribuite permit partajarea atât a resurselor hardware (hard diskuri, imprimante), cât și a celor software (fișiere, compilatoare).
2. Deschidere.Este capacitatea de a extinde sistemul prin adăugarea de resurse noi.
3. Paralelism.În sistemele distribuite, mai multe procese pot rula simultan pe diferite computere din rețea. Aceste procese pot interacționa în timp ce rulează.
4. Scalabilitate . Sub scalabilitate se înțelege posibilitatea adăugării de proprietăți și metode noi.
5. Toleranță la erori. Prezența mai multor computere permite duplicarea informațiilor și rezistența la unele erori hardware și software. Sistemele distribuite pot accepta funcționalități parțiale în caz de eroare. O defecțiune completă a sistemului apare numai cu erori de rețea.
6. Transparenţă.Utilizatorilor li se oferă acces complet la resursele din sistem, în timp ce informațiile despre distribuția resurselor în întregul sistem le sunt ascunse.

Sistemele distribuite au, de asemenea, o serie de dezavantaje.

1. Complexitate... Este mult mai dificil să înțelegeți și să evaluați proprietățile sistemelor distribuite în general și sunt mai dificil de proiectat, testat și întreținut. De asemenea, performanța sistemului depinde de viteza rețelei și nu de procesoarele individuale. Realocarea resurselor poate modifica semnificativ viteza sistemului.
2. Siguranță... De obicei, sistemul poate fi accesat de la mai multe mașini diferite, mesajele din rețea pot fi vizualizate și interceptate. Prin urmare, într-un sistem distribuit, este mult mai dificil să se mențină securitatea.
3. Controlabilitate... Sistemul poate consta din diferite tipuri de computere pe care pot fi instalate diferite versiuni ale sistemelor de operare. Erorile de pe o mașină se pot răspândi la alte mașini într-un mod imprevizibil.
4. Imprevizibilitatea ... Reacția sistemelor distribuite la unele evenimente este imprevizibilă și depinde de încărcarea completă a sistemului, de organizarea acestuia și de încărcarea rețelei. Deoarece acești parametri se pot modifica constant, prin urmare, timpul de răspuns la cerere poate diferi semnificativ de momentul respectiv.

Din aceste neajunsuri, puteți vedea că atunci când proiectați sisteme distribuite, există o serie de probleme pe care dezvoltatorii trebuie să le ia în considerare.

1. Identificarea resurselor ... Resursele din sistemele distribuite sunt situate pe diferite computere, astfel încât sistemul de denumire a resurselor ar trebui gândit astfel încât utilizatorii să poată accesa cu ușurință și să se refere la resursele de care au nevoie. Un exemplu este sistemul URL (Uniform Resource Locator), care definește numele paginilor web.
2. Comunicare... Operabilitatea universală a internetului și implementarea eficientă a protocoalelor TCP / IP în Internet pentru majoritatea sistemelor distribuite sunt exemple ale celui mai eficient mod de organizare a comunicării între computere. Cu toate acestea, în unele cazuri în care sunt necesare performanțe speciale sau fiabilitate, este posibil să se utilizeze instrumente specializate.
3. Calitatea serviciului de sistem ... Acest parametru reflectă performanța, sănătatea și fiabilitatea. O serie de factori afectează calitatea serviciului: distribuția proceselor, resurselor, hardware-ului și adaptabilitatea sistemului.
4. Arhitectura software ... Arhitectura software descrie distribuția funcțiilor sistemului între componentele sistemului, precum și distribuția acestor componente între procesoare. Dacă trebuie să mențineți un serviciu de sistem de înaltă calitate, alegerea arhitecturii potrivite este esențială.

Provocarea pentru proiectanții de sisteme distribuite este de a proiecta software și hardware pentru a furniza toate caracteristicile necesare unui sistem distribuit. Acest lucru necesită cunoașterea avantajelor și dezavantajelor diferitelor arhitecturi de sisteme distribuite. Există trei tipuri de arhitecturi de sistem distribuite.

1. Arhitectura client / server ... În acest model, sistemul poate fi gândit ca un set de servicii furnizate de servere clienților. În astfel de sisteme, serverele și clienții diferă semnificativ unul de celălalt.
2. Arhitectură pe trei niveluri ... În acest model, serverul nu furnizează servicii clienților direct, ci prin intermediul serverului de logică de afaceri.

Despre primele două modele s-au spus deja de mai multe ori, să ne oprim asupra celui de-al treilea mai detaliat.

1. Arhitectura obiectelor distribuite ... În acest caz, nu există diferențe între servere și clienți, iar sistemul poate fi gândit ca un set de obiecte care interacționează, a căror locație nu contează cu adevărat. Nu există nicio distincție între furnizorul de servicii și utilizatorii acestora.

Această arhitectură este folosită pe scară largă astăzi și este, de asemenea, numită arhitectura serviciilor web. Un serviciu web este o aplicație accesibilă pe Internet și care oferă unele servicii, a căror formă este independentă de furnizor (deoarece se utilizează formatul universal de date - XML) și platforma de operare. În prezent, există trei tehnologii diferite care susțin conceptul de sisteme de obiecte distribuite. Acestea sunt tehnologiile EJB, CORBA și DCOM.

În primul rând, câteva cuvinte despre ceea ce este XML în general. XML este un format de date generic utilizat pentru furnizarea de servicii Web. Serviciile web se bazează pe standarde și protocoale deschise: SOAP, UDDI și WSDL.

1. Săpun ( Protocolul de acces la obiecte simple, dezvoltat de W3C, definește un format pentru solicitările către serviciile web. Mesajele dintre un serviciu Web și utilizatorul acestuia sunt ambalate în așa-numitele plicuri SOAP (uneori numite și plicuri XML). Mesajul în sine poate conține fie o cerere de efectuare a unei acțiuni, fie un răspuns - rezultatul acestei acțiuni.
2. WSDL (Limbajul de descriere a serviciului web).Interfața serviciului web este descrisă în documentele WSDL (iar WSDL este un subset de XML). Înainte de a implementa un serviciu, dezvoltatorul își compune descrierea în limbajul WSDL, specifică adresa serviciului web, protocoalele acceptate, o listă a operațiunilor permise și formatele de solicitare și răspuns.
3. UDDI (descriere universală, descoperire și integrare) - Protocol de căutare servicii web Internet ( http://www.uddi.org/). Este un registru de afaceri în care furnizorii de servicii Web înregistrează servicii și dezvoltatorii găsesc serviciile pe care trebuie să le includă în aplicațiile lor.

Din discuție, poate părea că serviciile web sunt cea mai bună și necontestată soluție, iar singura întrebare este în alegerea instrumentelor de dezvoltare. Cu toate acestea, nu este. Există o alternativă la serviciile web, Semantic Web, despre care creatorul WWW Tim Berners-Lee a vorbit acum cinci ani.

Dacă scopul serviciilor web este de a facilita comunicarea între aplicații, atunci Semantic Web este conceput pentru a rezolva o problemă mult mai complexă - folosind mecanisme de metadate pentru a crește eficiența valorii informațiilor care pot fi găsite pe Web. Acest lucru se poate face prin abandonarea abordării orientate spre documente în favoarea celei orientate spre obiecte.

Bibliografie

1. SomervilleI. Inginerie software.
2. Dranitsa A. Java vs. .NET. - „Computerra”, # 516.
3. Resurse Internet.

În capitolul anterior, am analizat sistemele multiprocesor strâns cuplate cu memorie partajată, structuri de date partajate ale nucleului și un pool partajat din care sunt invocate procesele. Cu toate acestea, de multe ori este de dorit să se aloce procesoare în așa fel încât să fie autonome de mediul de operare și de condițiile de operare în scopul partajării resurselor. Să presupunem, de exemplu, că un utilizator al unui computer personal trebuie să acceseze fișiere situate pe o mașină mai mare, dar, în același timp, să păstreze controlul asupra computerului personal. Deși unele programe, cum ar fi uucp, acceptă transferul de fișiere în rețea și alte funcții de rețea, utilizarea lor nu va fi ascunsă de utilizator, deoarece utilizatorul este conștient că folosește rețeaua. În plus, trebuie remarcat faptul că programele precum editorii de text nu funcționează cu fișierele șterse, ca și în cazul celor obișnuite. Utilizatorii ar trebui să aibă setul standard de funcții de sistem UNIX și, în afară de potențialul blocaj de performanță, nu ar trebui să simtă trecerea granițelor mașinii. Deci, de exemplu, activitatea funcțiilor de sistem deschise și citite cu fișiere pe mașini la distanță nu ar trebui să difere de activitatea lor cu fișierele aparținând sistemelor locale.

Arhitectura sistemului distribuit este prezentată în Figura 13.1. Fiecare computer prezentat în figură este o unitate autonomă formată dintr-un procesor, memorie și periferice. Modelul nu se rupe chiar dacă computerul nu are un sistem de fișiere local: trebuie să aibă dispozitive periferice pentru a comunica cu alte mașini și toate fișierele care îi aparțin pot fi localizate pe alt computer. Memoria fizică disponibilă pentru fiecare mașină este independentă de procesele care rulează pe alte mașini. În acest sens, sistemele distribuite diferă de sistemele multiprocesor strâns cuplate discutate în capitolul anterior. În consecință, nucleul sistemului de pe fiecare mașină funcționează independent de condițiile de funcționare externe ale mediului distribuit.

Figura 13.1. Model de sistem de arhitectură distribuită

Sistemele distribuite, bine descrise în literatură, se încadrează în mod tradițional în următoarele categorii:

Sisteme periferice, care sunt grupuri de mașini care au o comunitate puternică și sunt asociate cu o mașină (de obicei mai mare). Procesoarele periferice își împărtășesc încărcarea cu procesorul central și îi redirecționează toate apelurile către sistemul de operare. Scopul unui sistem periferic este de a crește performanța generală a rețelei și de a oferi posibilitatea de a aloca un procesor unui singur proces într-un mediu de operare UNIX. Sistemul pornește ca un modul separat; Spre deosebire de alte modele de sisteme distribuite, sistemele periferice nu au autonomie reală, cu excepția cazurilor legate de dispecerizarea proceselor și alocarea memoriei locale.

Sisteme distribuite precum „Newcastle”, care permit comunicarea la distanță prin numele fișierelor la distanță din bibliotecă (numele este preluat din articolul „Conexiunea Newcastle” - vezi). Fișierele șterse au un BOM (nume distinctiv) care, în calea de căutare, conține caractere speciale sau o componentă de nume opțională care precede rădăcina sistemului de fișiere. Implementarea acestei metode nu implică modificări ale nucleului sistemului și, prin urmare, este mai simplă decât celelalte metode discutate în acest capitol, dar mai puțin flexibilă.

Sistemele distribuite sunt complet transparente, în care numele distincte standard sunt suficiente pentru a accesa fișierele localizate pe alte mașini; depinde de nucleu să recunoască aceste fișiere ca șterse. Căile de căutare a fișierelor specificate în numele lor compuse traversează limitele mașinii în punctele de montare, indiferent de câte astfel de puncte sunt formate atunci când sistemele de fișiere sunt montate pe discuri.

În acest capitol, vom analiza arhitectura fiecărui model; toate informațiile furnizate nu se bazează pe rezultatele unor evoluții specifice, ci pe informații publicate în diverse articole tehnice. Aceasta presupune că modulele de protocol și driverele de dispozitiv sunt responsabile pentru adresare, rutare, controlul fluxului și detectarea și corectarea erorilor - cu alte cuvinte, că fiecare model este independent de rețeaua utilizată. Exemplele de utilizare a funcțiilor de sistem prezentate în secțiunea următoare pentru sisteme periferice funcționează în mod similar pentru sisteme precum Newcastle și pentru sisteme complet transparente, care vor fi discutate mai târziu; prin urmare, le vom lua în considerare în detaliu o dată, iar în secțiunile dedicate altor tipuri de sisteme, ne vom concentra în principal pe caracteristicile care disting aceste modele de toate celelalte.

13.1 PROCESOARE PERIFERICE

Arhitectura sistemului periferic este prezentată în Figura 13.2. Scopul acestei configurații este de a îmbunătăți performanța generală a rețelei prin realocarea proceselor care rulează între procesor și procesoarele periferice. Fiecare dintre procesoarele periferice nu are la dispoziție alte dispozitive periferice locale în afară de cele de care are nevoie pentru a comunica cu unitatea centrală de procesare. Sistemul de fișiere și toate dispozitivele sunt la dispoziția procesorului central. Să presupunem că toate procesele utilizatorilor sunt executate pe procesorul periferic și nu se deplasează între procesoarele periferice; odată transferate la procesor, acestea rămân pe acesta până la finalizare. Procesorul periferic conține o versiune ușoară a sistemului de operare concepută pentru a gestiona apelurile locale către sistem, gestionarea întreruperilor, alocarea memoriei, lucrul cu protocoale de rețea și cu un driver de dispozitiv pentru comunicarea cu procesorul central.

Când sistemul este inițializat pe procesorul central, nucleul încarcă sistemul de operare local pe fiecare dintre procesoarele periferice prin intermediul liniilor de comunicație. Orice proces care rulează la periferie este asociat cu un proces prin satelit aparținând procesorului central (vezi); atunci când un proces care rulează pe un procesor periferic apelează o funcție de sistem care necesită numai serviciile procesorului central, procesul periferic comunică cu satelitul său și solicitarea este trimisă procesorului central pentru procesare. Procesul prin satelit îndeplinește o funcție de sistem și trimite rezultatele înapoi la procesorul periferic. Relația dintre un proces periferic și satelitul său este similară cu relația client-server pe care am discutat-o ​​în detaliu în capitolul 11: procesul periferic acționează ca un client al satelitului său, care susține funcțiile de lucru cu sistemul de fișiere. În acest caz, procesul serverului la distanță are un singur client. În secțiunea 13.4 vom analiza procesele serverului cu mai mulți clienți.

Figura 13.2. Configurarea sistemului periferic

Figura 13.3. Formate de mesaje

Când un proces periferic apelează o funcție de sistem care poate fi procesată local, nucleul nu trebuie să trimită o cerere procesului prin satelit. De exemplu, pentru a obține memorie suplimentară, un proces poate apela funcția sbrk pentru execuție locală. Cu toate acestea, dacă serviciile procesorului central sunt necesare, de exemplu, pentru a deschide un fișier, nucleul codifică informații despre parametrii trecuți funcției apelate și condițiile de execuție a procesului într-un mesaj trimis procesului satelit (Figura 13.3). Mesajul include un semn din care rezultă că funcția sistemului este realizată de procesul prin satelit în numele clientului, parametrii trecuți funcției și date despre mediul de execuție a procesului (de exemplu, codurile de identificare ale utilizatorului și ale grupului), care sunt diferite pentru diferite funcții. Restul mesajului este de date cu lungime variabilă (de exemplu, un nume de fișier compus sau date care trebuie scrise cu funcția de scriere).

Procesul prin satelit așteaptă cererile din procesul periferic; când se primește o cerere, aceasta decodează mesajul, determină tipul funcției de sistem, o execută și convertește rezultatele într-un răspuns trimis procesului periferic. Răspunsul, pe lângă rezultatele execuției funcției sistemului, include mesajul de eroare (dacă există), numărul semnalului și o matrice de date cu lungime variabilă care conține, de exemplu, informații citite dintr-un fișier. Procesul periferic este suspendat până când se primește un răspuns, după ce îl primește, decriptează și transmite rezultatele către utilizator. Aceasta este schema generală pentru gestionarea apelurilor către sistemul de operare; acum să trecem la o analiză mai detaliată a funcțiilor individuale.

Pentru a explica modul în care funcționează sistemul periferic, luați în considerare o serie de funcții: getppid, open, write, fork, exit și signal. Funcția getppid este destul de simplă, deoarece se ocupă de formulare simple de solicitare și răspuns care sunt schimbate între periferic și CPU. Nucleul procesorului periferic generează un mesaj care are un semn, din care rezultă că funcția solicitată este funcția getppid și trimite cererea către procesorul central. Procesul prin satelit al procesorului central citește mesajul de la procesorul periferic, decriptează tipul funcției de sistem, îl execută și obține identificatorul părintelui său. Apoi generează un răspuns și îl transmite unui proces periferic în așteptare la celălalt capăt al liniei de comunicație. Când procesorul periferic primește un răspuns, îl transmite procesului care a numit funcția de sistem getppid. Dacă procesul periferic stochează date (cum ar fi ID-ul procesului părintelui) în memoria locală, nu trebuie să comunice deloc cu însoțitorul său.

Dacă funcția de sistem deschis este apelată, procesul periferic trimite un mesaj adecvat însoțitorului său, care include numele fișierului și alți parametri. Dacă are succes, procesul însoțitor alocă un index și un punct de intrare tabelului de fișiere, alocă o intrare în tabelul descriptorului de fișiere utilizator în spațiul său și returnează descriptorul fișierului la procesul periferic. În tot acest timp, la celălalt capăt al liniei de comunicație, procesul periferic așteaptă un răspuns. El nu are la dispoziție structuri care să stocheze informații despre fișierul deschis; mânerul returnat de open este un pointer către o intrare în tabelul descriptor de fișiere utilizator deținut de procesul însoțitor. Rezultatele executării funcției sunt prezentate în Figura 13.4.

Figura 13.4. Apelarea funcției deschise dintr-un proces periferic

Dacă se efectuează un apel către scrierea funcției de sistem, procesorul periferic generează un mesaj constând dintr-un semn al funcției de scriere, un descriptor de fișier și cantitatea de date care trebuie scrise. Apoi, din spațiul procesului periferic, copiază datele în procesul satelit prin linia de comunicație. Procesul prin satelit decriptează mesajul primit, citește datele de pe linia de comunicație și le scrie în fișierul corespunzător (descriptorul conținut în mesaj este utilizat ca un pointer la indexul căruia și la înregistrarea despre care în tabelul de fișiere este utilizat ); toate aceste acțiuni sunt efectuate pe procesorul central. La sfârșitul lucrării, procesul prin satelit trimite către procesul periferic un mesaj care confirmă primirea mesajului și conține numărul de octeți de date care au fost copiați cu succes în fișier. Operația de citire este similară; satelitul informează procesul periferic despre numărul de octeți efectiv citiți (în cazul citirii datelor de la un terminal sau de la un canal, acest număr nu coincide întotdeauna cu suma specificată în cerere). Pentru a efectua una sau alta funcție, poate fi necesar să trimiteți mesaje de informații prin rețea de mai multe ori, care este determinată de cantitatea de date trimise și de dimensiunea pachetelor de rețea.

Singura funcție care trebuie modificată în timpul rulării pe CPU este funcția de sistem furcă. Când un proces execută această funcție pe CPU, nucleul selectează un procesor periferic pentru acesta și trimite un mesaj către un proces special - serverul, informându-l pe acesta din urmă că va începe să descarce procesul curent. Presupunând că serverul a acceptat solicitarea, nucleul folosește furculița pentru a crea un nou proces periferic, alocând o intrare în tabelul de proces și un spațiu de adrese. Procesorul central descarcă o copie a procesului care a apelat funcția fork la procesorul periferic, suprascriind spațiul de adresă nou alocat, generează un satelit local pentru a comunica cu noul proces periferic și trimite un mesaj la periferic pentru a inițializa contorul programului pentru noul proces. Procesul prin satelit (pe CPU) este un descendent al procesului numit furcă; un proces periferic este tehnic un descendent al procesului server, dar logic este un descendent al procesului care a numit funcția fork. Procesul serverului nu are nicio conexiune logică cu copilul la finalizarea furcii; singurul serviciu al serverului este de a ajuta la descărcarea copilului. Datorită cuplării puternice dintre componentele sistemului (procesoarele periferice nu au autonomie), procesul periferic și procesul prin satelit au același cod de identificare. Relația dintre procese este prezentată în Figura 13.5: linia continuă arată relația părinte-copil, iar linia punctată arată relația dintre colegi.

Figura 13.5. Executarea funcției fork pe CPU

Atunci când un proces execută funcția fork pe procesorul periferic, acesta trimite un mesaj către satelitul său de pe CPU, care apoi execută întreaga secvență de acțiuni descrisă mai sus. Satelitul selectează un nou procesor periferic și face pregătirile necesare pentru descărcarea imaginii vechiului proces: trimite procesului periferic părinte o cerere de citire a imaginii sale, ca răspuns la care transferul datelor solicitate începe la celălalt capăt al canalul de comunicare. Satelitul citește imaginea transmisă și o suprascrie descendentului periferic. Când descărcarea imaginii este terminată, procesul de satelit se bifurcă, creându-și copilul pe CPU și transmite valoarea contorului programului către copilul periferic, astfel încât acesta din urmă să știe de unde să înceapă execuția. Evident, ar fi mai bine dacă copilul procesului însoțitor ar fi atribuit copilului periferic ca părinte, dar în cazul nostru, procesele generate pot rula pe alte procesoare periferice, nu doar pe cel pe care sunt create. Relația dintre procese la sfârșitul funcției fork este prezentată în Figura 13.6. Când procesul periferic își termină activitatea, trimite un mesaj corespunzător procesului prin satelit și, de asemenea, acesta se termină. Un proces însoțitor nu poate iniția o oprire.

Figura 13.6. Executarea unei funcții fork pe un procesor periferic

Atât în ​​sistemele multiprocesor, cât și în cele uniprocesor, procesul trebuie să răspundă semnalelor în același mod: procesul fie finalizează executarea funcției sistemului înainte de a verifica semnalele, fie, dimpotrivă, la primirea semnalului, iese imediat din starea suspendată și întrerupe brusc funcția de sistem, dacă acest lucru este în concordanță cu prioritatea cu care a fost suspendat. Deoarece procesul prin satelit îndeplinește funcții de sistem în numele procesului periferic, acesta trebuie să răspundă la semnale în coordonare cu acesta din urmă. Dacă, pe un sistem uniprocesor, un semnal determină un proces să anuleze funcția, procesul însoțitor pe un sistem multiprocesor ar trebui să se comporte în același mod. Același lucru se poate spune despre cazul în care semnalul solicită procesului să își încheie activitatea folosind funcția de ieșire: procesul periferic se termină și trimite mesajul corespunzător procesului prin satelit, care, desigur, se termină și.

Când un proces periferic apelează funcția sistemului de semnal, acesta stochează informațiile curente în tabelele locale și trimite un mesaj către satelitul său prin care îl informează dacă semnalul specificat trebuie primit sau ignorat. Procesul prin satelit nu face nicio diferență dacă se interceptează semnalul sau acțiunea implicită. Reacția unui proces la un semnal depinde de trei factori (Figura 13.7): dacă un semnal ajunge în timp ce procesul execută o funcție de sistem, dacă se face o indicație folosind funcția de semnal pentru a ignora semnalul, dacă semnalul apare pe același procesor periferic sau pe altul. Să trecem la luarea în considerare a diferitelor posibilități.

algoritm sighandle / * algoritm de procesare a semnalului * /

dacă (procesul actual este însoțitorul cuiva sau are un prototip)

dacă (semnalul este ignorat)

if (semnalul a venit în timpul executării unei funcții de sistem)

puneți un semnal în fața procesului satelit;

trimite un mesaj de semnal către un proces periferic;

else (/ * proces periferic * /

/ * dacă a fost primit un semnal în timpul executării unei funcții de sistem sau nu * /

trimite un semnal către procesul de satelit;

algoritm satellite_end_of_syscall / * terminarea unei funcții de sistem numită de un proces periferic * /

informații de intrare: absente

informații de ieșire: niciuna

if (a fost primită o întrerupere în timpul executării unei funcții de sistem)

trimite mesaj de întrerupere, semnal la procesul periferic;

else / * executarea funcției de sistem nu a fost întreruptă * /

trimite un răspuns: activați steagul care indică sosirea semnalului;

Figura 13.7. Procesarea semnalului în sistemul periferic

Să presupunem că un proces periferic și-a suspendat activitatea în timp ce procesul prin satelit îndeplinește o funcție de sistem în numele său. Dacă semnalul apare în altă parte, procesul prin satelit îl detectează mai devreme decât procesul periferic. Sunt posibile trei cazuri.

1. Dacă, în așteptarea unui eveniment, procesul prin satelit nu a intrat în starea suspendată, din care ar ieși la primirea unui semnal, îndeplinește funcția de sistem până la capăt, trimite rezultatele execuției la procesul periferic și arată ce semnal a primit.

2. Dacă procesul este instruit să ignore acest tip de semnal, satelitul continuă să urmeze algoritmul de execuție a funcției sistemului, fără a părăsi starea suspendată cu longjmp. În răspunsul trimis procesului periferic, nu va exista niciun mesaj primit de semnal.

3. Dacă, la primirea unui semnal, procesul prin satelit întrerupe executarea funcției sistemului (prin longjmp), acesta informează procesul periferic despre acest lucru și îl informează despre numărul semnalului.

Procesul periferic caută în răspunsul primit informații despre primirea semnalelor și, dacă există, procesează semnalele înainte de a ieși din funcția de sistem. Astfel, comportamentul unui proces într-un sistem multiprocesor corespunde exact comportamentului său într-un sistem uniprocesor: fie iese fără a ieși din modul kernel, fie apelează o funcție personalizată de procesare a semnalului, fie ignoră semnalul și finalizează cu succes funcția sistemului.

Figura 13.8. Întrerupeți în timpul executării unei funcții de sistem

Să presupunem, de exemplu, că un proces periferic apelează o funcție de citire de la un terminal conectat la un procesor central și își întrerupe activitatea în timp ce procesul prin satelit îndeplinește funcția (Figura 13.8). Dacă utilizatorul apasă tasta de întrerupere, nucleul procesorului trimite un semnal către procesul de satelit. Dacă satelitul se afla într-o stare suspendată, așteptând o parte din date de la terminal, acesta iese imediat din această stare și încetează funcția de citire. În răspunsul său la o solicitare a unui proces periferic, satelitul raportează codul de eroare și numărul de semnal corespunzător întreruperii. Procesul periferic analizează răspunsul și, din moment ce mesajul spune că a sosit o întrerupere, trimite semnalul către sine. Înainte de a ieși din funcția de citire, nucleul periferic verifică semnalizarea, detectează un semnal de întrerupere din procesul satelit și îl procesează ca de obicei. Dacă, ca urmare a primirii unui semnal de întrerupere, procesul periferic își termină activitatea folosind funcția de ieșire, această funcție se ocupă de uciderea procesului prin satelit. Dacă procesul periferic interceptează semnale de întrerupere, apelează funcția de gestionare a semnalului definită de utilizator și returnează utilizatorului un cod de eroare la ieșirea din funcția de citire. Pe de altă parte, dacă satelitul execută funcția de sistem stat în numele procesului periferic, nu își va întrerupe execuția atunci când primește un semnal (funcția stat este garantată pentru a ieși din orice pauză, deoarece are un timp de așteptare limitat al resurselor ). Satelitul finalizează executarea funcției și returnează numărul semnalului la procesul periferic. Procesul periferic trimite un semnal către sine și îl primește la ieșirea din funcția de sistem.

Dacă apare un semnal pe procesorul periferic în timpul executării unei funcții de sistem, procesul periferic va fi în întuneric dacă va reveni în curând la controlul procesului prin satelit sau acesta din urmă va intra într-o stare suspendată la nesfârșit. Procesul periferic trimite un mesaj special către satelit prin care îl informează despre apariția unui semnal. Nucleul procesorului decriptează mesajul și trimite un semnal către satelit, a cărui reacție la primirea semnalului este descrisă în paragrafele anterioare (încetarea anormală a execuției funcției sau finalizarea acesteia). Procesul periferic nu poate trimite un mesaj către satelit direct, deoarece satelitul este ocupat îndeplinind o funcție de sistem și nu citește date de pe linia de comunicație.

Referindu-ne la exemplul citit, trebuie remarcat faptul că procesul periferic nu are idee dacă însoțitorul său așteaptă intrarea de la terminal sau efectuează alte acțiuni. Procesul periferic trimite un mesaj de semnal către satelit: dacă satelitul este într-o stare suspendată cu o prioritate întreruptă, acesta iese imediat din această stare și încetează funcția de sistem; în caz contrar, funcția este finalizată cu succes.

În cele din urmă, luați în considerare cazul unui semnal care ajunge într-un moment care nu are legătură cu executarea unei funcții de sistem. Dacă un semnal a provenit de la un alt procesor, satelitul îl primește mai întâi și trimite un mesaj de semnal către procesul periferic, indiferent dacă semnalul privește sau nu procesul periferic. Miezul periferic decriptează mesajul și trimite un semnal către proces, care reacționează la acesta în mod obișnuit. Dacă semnalul a apărut pe procesorul periferic, procesul efectuează acțiuni standard fără a recurge la serviciile satelitului său.

Când un proces periferic trimite un semnal către alte procese periferice, acesta codifică un mesaj de apel de ucidere și îl trimite către procesul prin satelit, care execută funcția apelată local. Dacă unele dintre procesele pentru care este destinat semnalul se află pe alte procesoare periferice, sateliții lor vor primi semnalul (și vor reacționa la acesta așa cum este descris mai sus).

13.2 COMUNICAREA NEWCASTLE

În secțiunea anterioară, am considerat un tip de sistem strâns cuplat, care se caracterizează prin trimiterea tuturor apelurilor către funcțiile subsistemului de gestionare a fișierelor care apar pe procesorul periferic către un procesor la distanță (central). Trecem acum la luarea în considerare a sistemelor mai puțin strâns cuplate, care constau din mașini care accesează fișiere de pe alte mașini. Într-o rețea de computere personale și stații de lucru, de exemplu, utilizatorii accesează adesea fișiere situate pe o mașină mare. În următoarele două secțiuni, vom analiza configurațiile sistemului în care toate funcțiile sistemului sunt efectuate în subsistemele locale, dar în același timp este posibil să accesați fișiere (prin funcțiile subsistemului de gestionare a fișierelor) situate pe alte mașini.

Aceste sisteme utilizează una dintre următoarele două căi pentru a identifica fișierele șterse. Pe unele sisteme, un nume special este adăugat la numele de fișier compus: componenta de nume care precede acest caracter identifică mașina, restul numelui este fișierul de pe mașina respectivă. Deci, de exemplu, numele distins

„sftig! / fs1 / mjb / rje”

identifică fișierul „/ fs1 / mjb / rje” pe „sftig” al mașinii. Această schemă de identificare a fișierelor urmează convenția uucp pentru transferul de fișiere între sistemele UNIX. Într-o altă schemă, fișierele șterse sunt identificate prin adăugarea unui prefix special la nume, de exemplu:

/../sftig/fs1/mjb/rje

unde „/../” este un prefix care indică ștergerea fișierului; a doua componentă a numelui fișierului este numele mașinii la distanță. Această schemă folosește sintaxa familiară a numelui de fișier UNIX, astfel încât spre deosebire de prima schemă, programele utilizatorilor nu trebuie să se adapteze la utilizarea de nume cu o construcție neobișnuită (vezi).

Figura 13.9. Formularea cererilor către serverul de fișiere (procesor)

Restul acestei secțiuni îl vom dedica unui model de sistem care utilizează o legătură Newcastle, în care nucleul nu este preocupat de recunoașterea fișierelor șterse; această funcție este complet alocată subrutinelor din biblioteca standard C, care în acest caz joacă rolul interfeței de sistem. Aceste rutine analizează prima componentă a numelui fișierului, care în ambele metode de identificare descrise conține un semn al îndepărtării fișierului. Aceasta este o abatere de la rutină în care rutinele bibliotecii nu analizează numele fișierelor. Figura 13.9 arată cum sunt formulate cererile către un server de fișiere. Dacă fișierul este local, nucleul de sistem local procesează cererea în mod normal. Luați în considerare cazul opus:

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

Subrutina deschisă din biblioteca C analizează primele două componente ale numelui fișierului și știe să caute fișierul pe mașina la distanță „sftig”. Pentru a avea informații despre dacă procesul a avut anterior o conexiune cu o anumită mașină, subrutina începe o structură specială în care își amintește acest fapt și, în cazul unui răspuns negativ, stabilește o conexiune cu serverul de fișiere care rulează pe mașina la distanță. Când procesul formulează prima cerere de procesare la distanță, serverul la distanță confirmă solicitarea, dacă este necesar, înregistrează în câmpurile codurilor de identificare ale utilizatorului și ale grupului și creează un proces prin satelit care va acționa în numele procesului client.

Pentru a îndeplini cererile clientului, satelitul trebuie să aibă aceleași permisiuni de fișiere pe computerul de la distanță ca și clientul. Cu alte cuvinte, utilizatorul „mjb” trebuie să aibă aceleași drepturi de acces atât la fișierele la distanță, cât și la cele locale. Din păcate, este posibil ca codul de identificare a clientului „mjb” să coincidă cu codul de identificare al altui client de pe aparatul de la distanță. Astfel, administratorii de sistem de pe mașinile care rulează pe o rețea ar trebui fie să se asigure că fiecărui utilizator i se atribuie un cod de identificare unic pentru întreaga rețea, fie să efectueze conversia codului în momentul unei cereri de servicii de rețea. Dacă acest lucru nu se face, procesul însoțitor va avea drepturile unui alt client pe aparatul la distanță.

O problemă mai delicată este obținerea drepturilor de superutilizator în legătură cu lucrul cu fișiere la distanță. Pe de o parte, clientul superutilizator nu ar trebui să aibă aceleași drepturi asupra sistemului la distanță pentru a nu induce în eroare controalele de securitate ale sistemului la distanță. Pe de altă parte, unele dintre programe, dacă nu li se acordă drepturi de superutilizare, pur și simplu nu vor putea funcționa. Un exemplu de astfel de program este programul mkdir (vezi Capitolul 7), care creează un nou director. Sistemul la distanță nu ar permite clientului să creeze un director nou, deoarece drepturile de superutilizare nu sunt în vigoare la ștergere. Problema creării directoarelor la distanță servește ca un motiv serios pentru revizuirea funcției sistemului mkdir în direcția extinderii capacităților sale în stabilirea automată a tuturor conexiunilor de care are nevoie utilizatorul. Cu toate acestea, este încă o problemă obișnuită faptul că programele setuid (cum ar fi programul mkdir) câștigă drepturi de superutilizator asupra fișierelor șterse. Poate că cea mai bună soluție la această problemă ar fi setarea caracteristicilor suplimentare pentru fișierele care descriu accesul la acestea de către superutilizatori la distanță; din păcate, acest lucru ar necesita modificări ale structurii indexului discului (în ceea ce privește adăugarea de câmpuri noi) și ar crea prea multă mizerie în sistemele existente.

Dacă subrutina deschisă reușește, biblioteca locală lasă o notă corespunzătoare despre aceasta în structura accesibilă utilizatorului care conține adresa nodului de rețea, ID-ul procesului companionului, descriptorul fișierului și alte informații similare. Rutinele bibliotecii citite și scrise determină, pe baza descriptorului fișierului, dacă fișierul este șters și, în caz afirmativ, trimite un mesaj către satelit. Procesul clientului interacționează cu partenerul său în toate cazurile de accesare a funcțiilor sistemului care necesită serviciile unei mașini la distanță. Dacă un proces accesează două fișiere situate pe aceeași mașină la distanță, utilizează un satelit, dar dacă fișierele sunt localizate pe mașini diferite, sunt deja utilizați doi sateliți: unul pe fiecare mașină. De asemenea, doi sateliți sunt utilizați atunci când două procese accesează un fișier pe o mașină la distanță. Prin invocarea funcției de sistem prin satelit, procesul generează un mesaj care include numărul funcției, numele căii de căutare și alte informații necesare, similar cu cel inclus în structura mesajului din sistem cu procesoare periferice.

Mecanismul pentru efectuarea operațiunilor pe directorul curent este mai complex. Când procesul selectează un director la distanță ca cel curent, rutina bibliotecii trimite un mesaj către satelit, care schimbă directorul curent, iar rutina își amintește că directorul este șters. În toate cazurile în care numele căii de căutare începe cu un caracter diferit de o bară directă (/), subrutina trimite numele către computerul de la distanță, unde procesul însoțitor îl direcționează din directorul curent. Dacă directorul curent este local, rutina pur și simplu transmite numele căii de căutare către nucleul de sistem local. Funcția chroot de sistem dintr-un director la distanță este similară, dar trece neobservată pentru kernel-ul local; strict vorbind, procesul poate ignora această operațiune, deoarece doar biblioteca înregistrează execuția sa.

Când un proces apelează furcă, rutina de bibliotecă adecvată trimite mesaje către fiecare satelit. Procesele prin satelit se ramifică și își trimit id-urile copilului către clientul părinte. Procesul client rulează funcția de sistem furcă, care transferă controlul către copilul pe care îl generează; copilul local este în dialog cu copilul satelit la distanță ale cărui adrese sunt stocate de rutina bibliotecii. Această interpretare a funcției de furcă facilitează procesele prin satelit să controleze fișierele deschise și directoarele curente. Când procesul de lucru cu fișiere la distanță iese (apelând funcția de ieșire), subrutina trimite mesaje către toți sateliții săi la distanță, astfel încât aceștia să facă același lucru atunci când primesc mesajul. Anumite aspecte ale implementării funcțiilor sistemului de executare și ieșire sunt discutate în exerciții.

Avantajul unei legături Newcastle este că accesul unui proces la fișierele la distanță devine „transparent” (invizibil pentru utilizator) și nu sunt necesare modificări ale kernel-ului sistemului. Cu toate acestea, această dezvoltare are o serie de dezavantaje. În primul rând, în timpul implementării sale, este posibilă o scădere a performanței sistemului. Datorită utilizării bibliotecii extinse C, dimensiunea memoriei utilizate de fiecare proces crește, chiar dacă procesul nu accesează fișiere la distanță; biblioteca dublează funcțiile nucleului și necesită mai mult spațiu de memorie pentru sine. Creșterea dimensiunii proceselor prelungește perioada de pornire și poate crea mai multă dispută pentru resursele de memorie, creând condiții pentru descărcarea și paginarea mai frecvente a sarcinilor. Solicitările locale se vor executa mai lent din cauza creșterii duratei fiecărui apel către nucleu, iar procesarea solicitărilor la distanță poate fi, de asemenea, încetinită, costul trimiterii acestora prin rețea crește. Prelucrarea suplimentară a cererilor la distanță la nivel de utilizator crește numărul de comutatoare de context, operațiuni de descărcare și swap. În cele din urmă, pentru a accesa fișiere la distanță, programele trebuie recompilate folosind noile biblioteci; programele vechi și modulele de obiecte livrate nu vor putea funcționa fără fișiere la distanță. Toate aceste dezavantaje sunt absente din sistemul descris în secțiunea următoare.

13.3 SISTEME DE FIȘIERE DISTRIBUITE „TRANSPARENTE”

Termenul „alocare transparentă” înseamnă că utilizatorii de pe o mașină pot accesa fișiere pe o altă mașină fără să-și dea seama că depășesc limitele mașinii, la fel cum fac pe mașina lor atunci când se deplasează de la un sistem de fișiere la altul prin punctele de montare. Numele prin care procesele se referă la fișiere localizate pe mașini la distanță sunt similare cu numele fișierelor locale: nu există caractere distinctive în ele. În configurația prezentată în Figura 13.10, directorul "/ usr / src" aparținând mașinii B este "montat" în directorul "/ usr / src" aparținând mașinii A. același cod sursă de sistem, care se găsește în mod tradițional în "/ directorul usr / src ". Utilizatorii care rulează pe mașina A pot accesa fișierele localizate pe mașina B utilizând sintaxa familiară de scriere a numelor fișierelor (de exemplu: "/usr/src/cmd/login.c"), iar nucleul în sine decide dacă fișierul este la distanță sau local . Utilizatorii care rulează pe mașina B au acces la fișierele lor locale (nu știu că utilizatorii mașinii A pot accesa aceleași fișiere), dar, la rândul lor, nu au acces la fișierele localizate pe mașina A. Desigur, alte opțiuni sunt posibile, în în special, cele în care toate sistemele la distanță sunt montate la rădăcina sistemului local, astfel încât utilizatorii să aibă acces la toate fișierele de pe toate sistemele.

Figura 13.10. Sisteme de fișiere după montare la distanță

Asemănările dintre montarea sistemelor de fișiere locale și permiterea accesului la sistemele de fișiere la distanță au determinat adaptarea funcției de montare la sistemele de fișiere la distanță. În acest caz, nucleul are la dispoziție o masă de montare cu format extins. Prin executarea funcției de montare, nucleul organizează o conexiune de rețea cu o mașină la distanță și stochează informații care caracterizează această conexiune în tabelul de montare.

O problemă interesantă are legătură cu numele căilor care includ „..”. Dacă un proces creează directorul curent dintr-un sistem de fișiere la distanță, atunci folosirea caracterelor „..” din nume va returna procesul în sistemul de fișiere local, mai degrabă decât să acceseze fișierele de deasupra directorului curent. Revenind din nou la Figura 13.10, rețineți că atunci când un proces aparținând mașinii A, după ce ați selectat anterior directorul curent "/ usr / src / cmd" situat în sistemul de fișiere la distanță, va executa comanda

directorul curent va fi directorul rădăcină aparținând mașinii A, nu mașinii B. Algoritmul namei care rulează în nucleul sistemului la distanță, după ce a primit secvența de caractere „..”, verifică dacă procesul de apelare este un agent al procesul clientului și, dacă da, setează, dacă clientul tratează directorul de lucru curent ca rădăcina sistemului de fișiere la distanță.

Comunicarea cu un aparat la distanță ia una din cele două forme: un apel la procedură la distanță sau un apel la funcția sistemului la distanță. În prima formă, fiecare procedură de kernel care se ocupă de indexuri verifică dacă indexul indică un fișier la distanță și, în caz afirmativ, trimite o cerere la mașina la distanță pentru a efectua operația specificată. Această schemă se încadrează în mod natural în structura abstractă a suportului pentru sisteme de fișiere de diferite tipuri, descrisă în partea finală a Capitolului 5. Astfel, accesul la un fișier la distanță poate iniția transferul mai multor mesaje prin rețea, al căror număr este determinat prin numărul de operațiuni implicite din fișier, cu o creștere corespunzătoare a timpului de răspuns la cerere, luând în considerare timpul de așteptare acceptat în rețea. Fiecare set de operații la distanță include cel puțin acțiuni pentru blocarea indexului, numărarea referințelor etc. Pentru a îmbunătăți modelul, au fost propuse diferite soluții de optimizare legate de combinarea mai multor operațiuni într-o singură interogare (mesaj) și tamponarea celor mai importante date (cm. ).

Figura 13.11. Deschiderea unui fișier la distanță

Luați în considerare un proces care deschide un fișier la distanță „/usr/src/cmd/login.c”, unde „src” este punctul de montare. Analizând numele fișierului (folosind schema namei-iget), nucleul detectează că fișierul este șters și trimite o cerere la mașina gazdă pentru a obține indexul blocat. După ce a primit răspunsul dorit, nucleul local creează o copie a indexului în memorie corespunzătoare fișierului la distanță. Apoi, nucleul verifică drepturile de acces necesare la fișier (de citit, de exemplu), trimițând un alt mesaj la mașina de la distanță. Algoritmul deschis continuă în deplină conformitate cu planul prezentat în capitolul 5, trimitând mesaje către aparatul de la distanță, după cum este necesar, până când algoritmul este complet și indexul este eliberat. Relația dintre structurile de date ale nucleului la finalizarea algoritmului deschis este prezentată în Figura 13.11.

Dacă clientul apelează funcția de sistem de citire, nucleul client blochează indexul local, emite o blocare pe indexul de la distanță, o cerere de citire, copiază datele în memoria locală, emite o cerere de eliberare a indexului de la distanță și eliberează indexul local . Această schemă este în concordanță cu semantica kernel-ului uniprocesor existent, dar frecvența utilizării rețelei (apeluri multiple către fiecare funcție de sistem) reduce performanța întregului sistem. Cu toate acestea, pentru a reduce fluxul de mesaje în rețea, mai multe operațiuni pot fi combinate într-o singură cerere. În exemplul cu funcția de citire, clientul poate trimite serverului o cerere generală de „citire”, iar serverul însuși decide să preia și să elibereze indexul atunci când este executat. Reducerea traficului de rețea poate fi realizată și prin utilizarea bufferelor de la distanță (așa cum am discutat mai sus), dar trebuie să aveți grijă să vă asigurați că funcțiile fișierului de sistem care utilizează aceste buffere sunt executate corect.

În a doua formă de comunicare cu o mașină la distanță (un apel către o funcție de sistem la distanță), nucleul local detectează că funcția de sistem este legată de un fișier la distanță și trimite parametrii specificați în apelul său către sistemul la distanță, care execută funcția și returnează rezultatele clientului. Aparatul client primește rezultatele executării funcției și iese din starea apelului. Majoritatea funcțiilor sistemului pot fi realizate utilizând o singură cerere de rețea și primind un răspuns după un timp rezonabil, dar nu toate funcțiile se încadrează în acest model. De exemplu, la primirea anumitor semnale, nucleul creează un fișier pentru procesul numit „nucleu” (Capitolul 7). Crearea acestui fișier nu este asociată cu o anumită funcție de sistem, dar ajunge să efectueze mai multe operații, cum ar fi crearea unui fișier, verificarea permisiunilor și efectuarea unei serii de scrieri.

În cazul funcției de sistem deschis, solicitarea de a executa funcția trimisă la mașina la distanță include partea din numele fișierului rămasă după excluderea componentelor numelui căii de căutare care disting fișierul la distanță, precum și diferite semnalizatoare. În exemplul anterior de deschidere a fișierului „/usr/src/cmd/login.c”, nucleul trimite numele „cmd / login.c” către computerul de la distanță. Mesajul include, de asemenea, acreditări, cum ar fi codurile de identificare a utilizatorului și a grupului, care sunt necesare pentru a verifica permisiunile de fișiere pe o mașină la distanță. Dacă se primește un răspuns de la mașina la distanță care indică o funcție deschisă cu succes, nucleul local preia un index gratuit în memoria mașinii locale și îl marchează ca index de fișier la distanță, stochează informații despre mașina la distanță și indexul la distanță și alocă în mod obișnuit o nouă intrare în tabelul de fișiere. În comparație cu indicele real de pe aparatul de la distanță, indicele deținut de aparatul local este formal și nu încalcă configurația modelului, care este, în linii mari, aceeași cu configurația utilizată la apelarea procedurii de la distanță (Figura 13.11). Dacă o funcție apelată de un proces accesează un fișier la distanță prin descriptorul său, nucleul local știe din indexul (local) că fișierul este la distanță, formulează o cerere care include funcția apelată și îl trimite la mașina la distanță. Solicitarea conține un indicator către indexul la distanță prin care procesul prin satelit poate identifica fișierul la distanță în sine.

După ce a primit rezultatul executării oricărei funcții de sistem, nucleul poate recurge la serviciile unui program special pentru al procesa (la finalizarea căruia nucleul va termina de lucrat cu funcția), deoarece procesarea locală a rezultatelor utilizate într-un sistem uniprocesor nu este întotdeauna potrivit pentru un sistem cu mai multe procesoare. Ca urmare, sunt posibile schimbări în semantica algoritmilor de sistem, care vizează furnizarea de suport pentru executarea funcțiilor de sistem la distanță. Totuși, în același timp, un flux minim de mesaje circulă în rețea, asigurând timpul minim de răspuns al sistemului la solicitările primite.

13.4 MODEL DISTRIBUIT FĂRĂ PROCESE DE TRANSFER

Utilizarea proceselor de transfer (procese prin satelit) într-un sistem distribuit transparent facilitează urmărirea fișierelor șterse, dar tabelul de procese al sistemului la distanță este supraîncărcat cu procese prin satelit care sunt inactive de cele mai multe ori. În alte scheme, procesele speciale de server sunt utilizate pentru a procesa cererile de la distanță (vezi și). Sistemul la distanță are un set (pool) de procese de server pe care le atribuie din când în când pentru procesarea solicitărilor de la distanță primite. După procesarea cererii, procesul serverului revine la pool și intră într-o stare gata să proceseze alte cereri. Serverul nu păstrează contextul utilizatorului între două apeluri, deoarece poate procesa cereri de la mai multe procese simultan. Prin urmare, fiecare mesaj care ajunge dintr-un proces client trebuie să includă informații despre mediul său de execuție, și anume: coduri de identificare a utilizatorului, directorul curent, semnale etc.

Când un proces deschide un fișier la distanță, nucleul de la distanță atribuie un index pentru legăturile ulterioare către fișier. Mașina locală menține un tabel descriptor de fișiere personalizat, un tabel de fișiere și un tabel index cu un set regulat de înregistrări, cu o intrare de tabel index care identifică mașina la distanță și indexul la distanță. În cazurile în care o funcție de sistem (de exemplu, citită) folosește un descriptor de fișier, nucleul trimite un mesaj care indică indexul la distanță atribuit anterior și transferă informații legate de proces: codul de identificare a utilizatorului, dimensiunea maximă a fișierului, etc. proces de server la dispoziția sa, interacțiunea cu clientul ia forma descrisă anterior, cu toate acestea, conexiunea dintre client și server este stabilită numai pe durata funcției de sistem.

Utilizarea serverelor în locul proceselor prin satelit poate face mai dificilă gestionarea traficului de date, a semnalelor și a dispozitivelor la distanță. Un număr mare de solicitări către o mașină la distanță ar trebui să fie în așteptare în absența unui număr suficient de servere. Acest lucru necesită un protocol de nivel mai înalt decât cel utilizat în rețeaua principală. Pe modelul satelit, pe de altă parte, suprasaturarea este eliminată deoarece toate cererile clientului sunt procesate sincron. Un client poate avea cel mult o cerere în așteptare.

Procesarea semnalelor care întrerupe executarea unei funcții de sistem este, de asemenea, complicată atunci când se utilizează servere, deoarece aparatul la distanță trebuie să caute serverul adecvat care servește la executarea funcției. Este chiar posibil ca, din cauza ocupării tuturor serverelor, să fie procesată o cerere pentru o funcție de sistem. Condițiile pentru apariția concurenței apar și atunci când serverul returnează rezultatul funcției de sistem procesului de apelare și răspunsul serverului include trimiterea unui mesaj de semnalizare corespunzător prin rețea. Fiecare mesaj trebuie marcat astfel încât sistemul la distanță să îl poată recunoaște și, dacă este necesar, să termine procesele serverului. Atunci când se utilizează sateliți, procesul care gestionează îndeplinirea cererii clientului este identificat automat și, în cazul în care ajunge un semnal, nu este dificil să verificați dacă cererea a fost procesată sau nu.

În cele din urmă, dacă o funcție de sistem apelată de client face ca serverul să se întrerupă la nesfârșit (de exemplu, când citește date de la un terminal la distanță), serverul nu poate procesa alte cereri pentru a elibera grupul de servere. Dacă mai multe procese accesează dispozitive la distanță simultan și dacă numărul de servere este limitat de sus, există un blocaj destul de tangibil. Acest lucru nu se întâmplă cu sateliții, deoarece un satelit este alocat fiecărui proces client. O altă problemă cu utilizarea serverelor pentru dispozitive la distanță va fi tratată în Exercițiul 13.14.

În ciuda avantajelor pe care le oferă utilizarea proceselor prin satelit, nevoia de intrări gratuite în tabelul de procese în practică devine atât de acută încât, în majoritatea cazurilor, serviciile proceselor server sunt încă utilizate pentru a procesa cererile de la distanță.

Figura 13.12. Diagrama conceptuală a interacțiunii cu fișierele la distanță la nivel de nucleu

13.5 CONCLUZII

În acest capitol, am examinat trei scheme pentru lucrul cu fișiere situate pe mașini la distanță, tratând sistemele de fișiere la distanță ca o extensie a celei locale. Diferențele arhitecturale dintre aceste planuri sunt prezentate în Figura 13.12. Toate, la rândul lor, diferă de sistemele multiprocesor descrise în capitolul anterior prin faptul că aici procesoarele nu împart memoria fizică. Un sistem de procesor periferic constă dintr-un set de procesoare strâns cuplat care partajează resursele de fișiere ale procesorului central. Conexiunea de tip Newcastle oferă acces ascuns („transparent”) la fișiere la distanță, dar nu prin intermediul nucleului sistemului de operare, ci prin utilizarea unei biblioteci speciale C. Din acest motiv, toate programele care intenționează să utilizeze acest tip de legătură trebuie recompilate, ceea ce, în general, reprezintă un dezavantaj serios al acestei scheme. Depărtarea unui fișier este indicată folosind o secvență specială de caractere care descrie mașina pe care se află fișierul, iar acesta este un alt factor care limitează portabilitatea programelor.

În sistemele distribuite transparente, o modificare a funcției sistemului de montare este utilizată pentru a accesa fișierele la distanță. Indexurile de pe sistemul local sunt marcate ca fișiere la distanță, iar nucleul local trimite un mesaj către sistemul de la distanță descriind funcția de sistem solicitată, parametrii săi și indexul de la distanță. Comunicarea într-un sistem distribuit „transparent” este acceptată în două forme: sub forma unui apel către o procedură la distanță (un mesaj este trimis la mașina la distanță care conține o listă de operațiuni asociate indexului) și sub forma unui apel către o funcție de sistem la distanță (mesajul descrie funcția solicitată). Partea finală a capitolului discută aspecte legate de procesarea cererilor la distanță folosind procese și servere prin satelit.

13.6 EXERCIȚII

*unu. Descrieți implementarea funcției sistemului de ieșire într-un sistem cu procesoare periferice. Care este diferența dintre acest caz și când procesul se încheie la primirea unui semnal neprins? Cum ar trebui ca nucleul să arunce conținutul memoriei?

2. Procesele nu pot ignora semnalele SIGKILL; Explicați ce se întâmplă în sistemul periferic atunci când procesul primește un astfel de semnal.

* 3. Descrieți implementarea funcției de sistem exec pe un sistem cu procesoare periferice.

* 4. Cum ar trebui procesorul central să distribuie procesele între procesoarele periferice pentru a echilibra sarcina generală?

*cinci. Ce se întâmplă dacă procesorul periferic nu are suficientă memorie pentru a găzdui toate procesele descărcate pe acesta? Cum ar trebui să se facă descărcarea și schimbarea proceselor în rețea?

6. Luați în considerare un sistem în care sunt trimise solicitări către un server de fișiere la distanță dacă se găsește un prefix special în numele fișierului. Lăsați procesul să apeleze execl ("/../ sftig / bin / sh", "sh", 0); Executabilul se află pe o mașină la distanță, dar trebuie să ruleze pe sistemul local. Explicați modul în care modulul de la distanță este migrat la sistemul local.

7. Dacă administratorul trebuie să adauge mașini noi la un sistem existent cu o conexiune precum Newcastle, cum este cel mai bun mod de a informa modulele bibliotecii C despre acest lucru?

*opt. În timpul executării funcției exec, nucleul suprascrie spațiul de adrese al procesului, inclusiv tabelele bibliotecii utilizate de link-ul Newcastle pentru a urmări linkurile către fișiere la distanță. După executarea funcției, procesul trebuie să păstreze capacitatea de a accesa aceste fișiere prin vechii lor descriptori. Descrieți implementarea acestui punct.

*nouă. Așa cum se arată în secțiunea 13.2, apelarea funcției sistemului de ieșire pe sistemele cu o conexiune Newcastle are ca rezultat trimiterea unui mesaj către procesul însoțitor, obligându-l pe acesta din urmă să se termine. Acest lucru se face la nivelul rutinelor bibliotecii. Ce se întâmplă atunci când un proces local primește un semnal care îi spune să iasă în modul kernel?

* 10. Într-un sistem cu o legătură Newcastle, unde fișierele la distanță sunt identificate prin prefixarea numelui cu un prefix special, cum poate un utilizator, specificând „..” (director părinte) ca componentă a numelui de fișier, să traverseze punctul de montare la distanță?

11. Știm din capitolul 7 că diferite semnale determină un proces să arunce conținutul memoriei în directorul curent. Ce ar trebui să se întâmple dacă directorul curent provine din sistemul de fișiere la distanță? Ce răspuns ați da dacă sistemul folosește o relație precum Newcastle?

* 12. Care sunt implicațiile pentru procesele locale dacă toate procesele prin satelit sau server sunt eliminate din sistem?

* 13. Luați în considerare cum să implementați algoritmul de legătură într-un sistem distribuit transparent, parametrii căruia pot fi două nume de fișiere la distanță, precum și algoritmul exec, asociat cu efectuarea mai multor operații de citire interne. Luați în considerare două forme de comunicare: un apel de procedură la distanță și un apel de funcție de sistem la distanță.

*paisprezece. La accesarea dispozitivului, procesul serverului poate intra în starea suspendată, din care va fi scos de către driverul dispozitivului. Bineînțeles, dacă numărul de servere este limitat, sistemul nu va mai putea satisface cererile mașinii locale. Vino cu o schemă fiabilă prin care nu toate procesele serverului sunt suspendate în așteptarea finalizării I / O legate de dispozitiv. Funcția de sistem nu va opri executarea în timp ce toate serverele sunt ocupate.

Figura 13.13. Configurare Terminal Server

*cincisprezece. Când un utilizator se conectează la sistem, disciplina liniei de terminal stochează informațiile că terminalul este un terminal de operator care conduce un grup de procese. Din acest motiv, atunci când utilizatorul apasă tasta „pauză” de pe tastatura terminalului, toate procesele din grup primesc semnalul de întrerupere. Luați în considerare o configurație a sistemului în care toate terminalele sunt conectate fizic la o singură mașină, dar înregistrarea utilizatorului este implementată logic pe alte mașini (Figura 13.13). În fiecare caz, sistemul creează un proces getty pentru terminalul de la distanță. Dacă solicitările către un sistem la distanță sunt procesate de un set de procese de server, rețineți că atunci când se execută procedura de deschidere, serverul încetează să aștepte o conexiune. Când funcția de deschidere se finalizează, serverul se întoarce la grupul de servere, întrerupându-și conexiunea la terminal. Cum se trimite semnalul de întrerupere prin apăsarea tastei „pauză” către adresele proceselor incluse în același grup?

*şaisprezece. Partajarea memoriei este o caracteristică inerentă mașinilor locale. Din punct de vedere logic, alocarea unei zone comune de memorie fizică (locală sau la distanță) poate fi efectuată pentru procesele aparținând diferitelor mașini. Descrieți implementarea acestui punct.

* 17. Procesul de paginare și algoritmii de paginare discutați în capitolul 9 presupun utilizarea unui pager local. Ce modificări ar trebui aduse acestor algoritmi pentru a putea suporta dispozitive de descărcare la distanță?

* 18. Să presupunem că mașina la distanță (sau rețeaua) sa prăbușit și că protocolul de strat de rețea local a înregistrat acest fapt. Elaborați o schemă de recuperare pentru un sistem local care face cereri către un server la distanță. În plus, dezvoltați o schemă de recuperare pentru un sistem server care a pierdut contactul cu clienții.

*nouăsprezece. Când un proces accesează un fișier la distanță, este posibil ca procesul să traverseze mai multe mașini în căutarea fișierului. Luați numele "/ usr / src / uts / 3b2 / os" ca exemplu, unde "/ usr" este directorul aparținând mașinii A, "/ usr / src" este punctul de montare al rădăcinii mașinii B " / usr / src / uts / 3b2 "este punctul de montare al rădăcinii mașinii C. Mersul prin mai multe mașini până la destinația sa finală se numește multihop. Cu toate acestea, dacă există o conexiune directă de rețea între mașinile A și C, trimiterea datelor prin mașina B ar fi ineficientă. Descrieți caracteristicile implementării „multishopping” într-un sistem cu conexiune Newcastle și într-un sistem distribuit „transparent”.

În prezent, sunt distribuite practic toate sistemele software mari. Un sistem distribuit este un sistem în care procesarea informațiilor este concentrată nu pe un singur computer, ci este distribuită între mai multe computere. Atunci când proiectați sisteme distribuite, care are multe în comun cu proiectarea oricărui alt software, există încă o serie de caracteristici specifice de luat în considerare. Unele dintre acestea au fost deja menționate în introducerea la capitolul 10 când am analizat arhitectura client / server și sunt discutate mai detaliat aici.

Deoarece sistemele distribuite sunt răspândite în prezent, dezvoltatorii de software ar trebui să fie familiarizați cu specificul designului lor. Până de curând, toate sistemele mari erau în mare parte centralizate, rulând pe un singur computer gazdă (mainframe) cu terminale atașate la acesta. Terminalele practic nu au procesat informații - toate calculele au fost efectuate pe mașina gazdă. Dezvoltatorii unor astfel de sisteme nu au fost nevoiți să se gândească la problemele informatice distribuite.

Toate sistemele software moderne pot fi împărțite în trei clase mari.

1. Sisteme software de aplicații proiectate să funcționeze numai pe un singur computer personal sau stație de lucru. Acestea includ procesoare de text, foi de calcul, sisteme grafice etc.

2. Sisteme încorporate concepute pentru a rula pe un singur procesor sau pe un grup integrat de procesoare. Acestea includ sisteme de control pentru aparate de uz casnic, diverse aparate etc.

3. Sisteme distribuite în care software-ul rulează pe un grup ușor integrat de procesoare paralele care sunt conectate printr-o rețea. Acestea includ sistemele ATM deținute de o bancă, sistemele de publicare, sistemele software partajate etc.

În prezent, există limite clare între clasele listate de sisteme software, care vor fi din ce în ce mai neclare în viitor. În timp, pe măsură ce rețelele fără fir de mare viteză devin disponibile pe scară largă, va fi posibilă integrarea dinamică a dispozitivelor cu sisteme software încorporate, cum ar fi organizatoarele electronice cu sisteme mai generale.

Au fost identificate șase caracteristici principale ale sistemelor distribuite.

1. Partajarea resurselor. Sistemele distribuite permit partajarea resurselor hardware și software, cum ar fi hard disk-uri, imprimante, fișiere, compilatoare și altele asemenea, care sunt conectate printr-o rețea. Este evident că partajarea resurselor este posibilă și în sistemele cu mai mulți utilizatori, dar în acest caz, computerul central trebuie să fie responsabil pentru furnizarea resurselor și gestionarea acestora.

2. Deschidere. Aceasta este capacitatea de a extinde sistemul prin adăugarea de resurse noi. Sistemele distribuite sunt sisteme deschise care conectează hardware și software de la diferiți producători.

3. Paralelism.În sistemele distribuite, mai multe procese pot rula simultan pe diferite computere din rețea. Aceste procese pot (dar nu trebuie) să interacționeze între ele în timp ce rulează.

4. Scalabilitate.În principiu, toate sistemele distribuite sunt scalabile: pentru a îndeplini noi cerințe, sistemul poate fi extins prin adăugarea de noi resurse de calcul. Dar, în practică, acumularea poate fi limitată la rețeaua care conectează computerele individuale din sistem. Dacă sunt conectate multe mașini noi, este posibil ca lățimea de bandă a rețelei să nu fie suficientă.

5. Toleranță la erori. Prezența mai multor computere și capacitatea de a copia informații înseamnă că sistemele distribuite sunt rezistente la anumite erori hardware și software. Majoritatea sistemelor distribuite, în caz de eroare, pot suporta, de obicei, funcționalități cel puțin parțiale. O defecțiune completă a sistemului are loc numai în caz de erori de rețea.

6. Transparenţă. Această proprietate înseamnă că utilizatorilor li se oferă acces complet transparent la resurse și, în același timp, le sunt ascunse informații despre distribuția resurselor în sistem. Cu toate acestea, în multe cazuri, cunoștințele specifice despre organizarea sistemului ajută utilizatorul să utilizeze mai bine resursele.

Desigur, sistemele distribuite au o serie de dezavantaje.

Complexitate. Sistemele distribuite sunt mai complexe decât cele centralizate. Este mult mai dificil să înțelegeți și să evaluați proprietățile sistemelor distribuite în general și, de asemenea, să testați aceste sisteme. De exemplu, aici performanța sistemului nu depinde de viteza unui procesor, ci de lățimea de bandă a rețelei și viteza diferitelor procesoare. Mutarea resurselor dintr-o parte a sistemului în alta poate afecta drastic performanța sistemului.

Siguranță. De obicei, sistemul poate fi accesat de la mai multe mașini diferite, mesajele din rețea pot fi vizualizate sau interceptate. Prin urmare, într-un sistem distribuit, este mult mai dificil să se mențină securitatea.

Controlabilitate. Sistemul poate consta din computere de diferite tipuri, pe care pot fi instalate diferite versiuni ale sistemelor de operare. Erorile de pe o mașină se pot răspândi la alte mașini cu consecințe imprevizibile. Prin urmare, este necesar un efort mult mai mare pentru a gestiona și menține sistemul în stare de funcționare.

Imprevizibilitatea. După cum știu toți utilizatorii Web, răspunsul sistemelor distribuite la anumite evenimente este imprevizibil și depinde de încărcarea completă a sistemului, de organizarea acestuia și de încărcarea rețelei. Deoarece toți acești parametri pot fi în continuă schimbare, timpul petrecut pentru executarea cererii utilizatorului la un moment dat poate varia semnificativ.

Când se discută despre avantajele și dezavantajele sistemelor distribuite, sunt identificate o serie de probleme critice de proiectare pentru astfel de sisteme (Tabelul 9.1).

Tabelul 9.1. Probleme de proiectare a sistemelor distribuite

Problemă de proiectare	Descriere
Identificarea resurselor	Resursele dintr-un sistem distribuit sunt localizate pe diferite computere, astfel încât sistemul de denumire a resurselor ar trebui gândit astfel încât utilizatorii să poată accesa cu ușurință și să se refere la resursele de care au nevoie. Un exemplu este sistemul Uniform Resource Locator (URL), care definește adresele paginilor web. Fără un sistem de identificare ușor perceput și universal, majoritatea resurselor vor fi inaccesibile utilizatorilor sistemului.
Comunicații	Operabilitatea universală a internetului și implementarea eficientă a protocoalelor TCP / IP în Internet pentru majoritatea sistemelor distribuite sunt exemple ale celui mai eficient mod de organizare a comunicării între computere. Cu toate acestea, acolo unde sunt impuse cerințe speciale pentru performanță, fiabilitate etc., pot fi utilizate metode alternative de comunicare a sistemului.
Calitatea serviciului de sistem	Calitatea serviciilor oferite de sistem reflectă performanța, operabilitatea și fiabilitatea acestuia. Calitatea serviciului este influențată de o serie de factori: distribuția proceselor sistemului, alocarea resurselor, hardware-ul sistemului și al rețelei și adaptabilitatea sistemului.
Arhitectura software	Arhitectura software descrie distribuția funcțiilor sistemului între componentele sistemului, precum și distribuția acestor componente între procesoare. Dacă trebuie să mențineți un serviciu de sistem de înaltă calitate, alegerea arhitecturii potrivite se dovedește a fi un factor decisiv.

Provocarea pentru proiectanții de sisteme distribuite este de a proiecta software sau hardware pentru a furniza toate caracteristicile necesare unui sistem distribuit. Acest lucru necesită cunoașterea avantajelor și dezavantajelor diferitelor arhitecturi de sisteme distribuite. Două tipuri conexe de arhitecturi de sistem distribuite se remarcă aici.

1. Arhitectura client / server.În acest model, sistemul poate fi gândit ca un set de servicii furnizate de servere clienților. În astfel de sisteme, serverele și clienții diferă semnificativ unul de celălalt.

2. Arhitectura obiectelor distribuite.În acest caz, nu există diferențe între servere și clienți, iar sistemul poate fi gândit ca un set de obiecte care interacționează, a căror locație nu contează cu adevărat. Nu există nicio distincție între furnizorul de servicii și utilizatorii acestora.

Într-un sistem distribuit, diferite componente ale sistemului pot fi implementate în diferite limbaje de programare și pot rula pe diferite tipuri de procesoare. Modelele de date, prezentarea informațiilor și protocoalele de comunicare nu sunt neapărat toate de același tip într-un sistem distribuit. În consecință, sistemele distribuite necesită software care să poată gestiona aceste părți eterogene și să garanteze interacțiunea și schimbul de date între ele. Middleware se referă tocmai la această clasă de software. Se află, așa cum ar fi, în mijlocul între diferite părți ale componentelor distribuite ale sistemului.

Sistemele distribuite sunt de obicei proiectate cu o abordare orientată obiect. Aceste sisteme sunt create din piese slab integrate, fiecare dintre ele putând interacționa direct atât cu utilizatorul, cât și cu alte părți ale sistemului. Aceste părți ar trebui, ori de câte ori este posibil, să răspundă la evenimente independente. Obiectele software bazate pe aceste principii sunt componente naturale ale sistemelor distribuite. Dacă nu sunteți deja familiarizați cu conceptul de obiecte.