Distribuované koncepty architektury, které jsem se naučil při budování velkého platebního systému. Keith Matsudeira: Škálovatelná webová architektura a distribuované systémy

n1.doc

11. Architektura distribuovaných systémů

Cíle
Účelem této kapitoly je prostudovat architekturu distribuovaných softwarových systémů. Po přečtení této kapitoly byste měli:

• 
  znát hlavní výhody a nevýhody distribuovaných systémů;
• 
  rozumět různým přístupům používaným při vývoji architektur klient/server;
• 
  porozumět rozdílům mezi architekturou klient/server a architekturou distribuovaných objektů;
• 
  znát koncept zprostředkovatele objektových požadavků a principy implementované ve standardech CORBA.

V současné době jsou distribuovány téměř všechny velké softwarové systémy. Distribuovaný systém je systém, ve kterém je zpracování informací soustředěno na více než jeden systém počítač ale distribuovány na více počítačích. Při navrhování distribuovaných systémů, které mají mnoho společného s návrhem jakéhokoli jiného softwaru, je stále třeba brát v úvahu řadu specifických vlastností. Některé z nich již byly zmíněny v úvodu kapitoly 10 při diskuzi o architektuře klient/server a podrobněji se o nich pojednává zde.

Vzhledem k tomu, že distribuované systémy jsou v dnešní době tak rozšířené, musí vývojáři softwaru znát jejich konstrukční funkce. Donedávna byly všechny velké systémy většinou centralizované, které běžely na jednom hlavním počítači (mainframe) s připojenými terminály. Terminály prakticky nezpracovávaly informace - všechny výpočty byly prováděny na hlavním stroji. Vývojáři takových systémů nemuseli myslet na problémy distribuovaného počítání.

Všechny moderní softwarové systémy lze rozdělit do tří velkých tříd.
1. Systémy aplikačního softwaru navržené pro provoz pouze na jednom osobním počítači nebo pracovní stanici. Tyto zahrnují textové procesory, tabulky, grafické systémy atd.

2. Vestavěné systémy navržené pro provoz na jediném procesoru nebo na integrované skupině procesorů. Patří sem řídicí systémy pro domácí spotřebiče, různé spotřebiče atd.

3. Distribuované systémy, ve kterých software běží na volně integrované skupině paralelních procesorů propojených sítí. Patří sem ATM systémy vlastněné bankou, publikační systémy, softwarové systémy pro kolektivní použití atd.
V současnosti jsou mezi uvedenými třídami softwarových systémů jasné hranice, které se budou v budoucnu stále více stírat. Postupem času, když vysokorychlostní bezdrátová síť budou široce dostupné, bude možné dynamicky integrovat zařízení například s vestavěnými softwarovými systémy elektronické organizéry s obecnějšími systémy.

Kniha zdůrazňuje šest klíčových charakteristik distribuovaných systémů.
1. Sdílení zdrojů. Distribuované systémy umožňují sdílení hardwarových a softwarových prostředků, jako jsou pevné disky, tiskárny, soubory, kompilátory a podobně, propojené prostřednictvím sítě. Sdílení zdrojů je samozřejmě možné i ve víceuživatelských systémech, ale v tomto případě by za poskytování zdrojů a jejich správu měl odpovídat centrální počítač.

2. otevřenost. Jedná se o možnost rozšířit systém přidáním nových zdrojů. Distribuované systémy jsou otevřené systémy, ke kterému je připojen hardware a software od různých výrobců.

3. Rovnoběžnost. V distribuovaných systémech může současně běžet více procesů různé počítače online. Tyto procesy se mohou (ale nemusí) vzájemně ovlivňovat, když jsou spuštěny.

4. Škálovatelnost. V zásadě jsou všechny distribuované systémy škálovatelné: aby systém vyhovoval novým požadavkům, lze jej škálovat přidáním nových výpočetních zdrojů. Ale v praxi může být růst omezen na síť, která spojuje jednotlivé počítače v systému. Pokud připojíte mnoho nových počítačů, šířka pásma sítě nemusí být dostatečná.

5. Odolnost proti chybám. Přítomnost více počítačů a možnost duplikace informací znamená, že distribuované systémy jsou odolné vůči určitému hardwaru a softwarové chyby(viz kapitola 18). Většina distribuovaných systémů obvykle dokáže zachovat alespoň částečnou funkčnost v případě chyby. K úplnému selhání systému dochází pouze v případě síťových chyb.

6. Průhlednost. Tato vlastnost znamená, že uživatelé mají plnou hodnotu transparentní přístup ke zdrojům a zároveň jsou před nimi skryty informace o rozložení zdrojů v systému. V mnoha případech však specifické znalosti o organizaci systému pomáhají uživateli lépe využívat zdroje.
Distribuované systémy mají samozřejmě řadu nevýhod.

Složitost. Distribuované systémy jsou složitější než centralizované. Mnohem obtížnější je obecně porozumět a vyhodnotit vlastnosti distribuovaných systémů a také tyto systémy otestovat. Například zde výkon systému nezávisí na rychlosti jednoho procesoru, ale na šířce pásma sítě a rychlosti různých procesorů. Přesunutím zdrojů z jedné části systému do druhé může být výkon systému drasticky ovlivněn.

Bezpečnost. Obvykle je systém přístupný z několika různé stroje, lze zprávy v síti zobrazit nebo zachytit. Proto je mnohem obtížnější udržet bezpečnost v distribuovaném systému.

ovladatelnost. Systém se může skládat z různých typů počítačů, na kterých mohou být nainstalovány různé verze operačních systémů. Chyby na jednom počítači se mohou rozšířit na další počítače s nepředvídatelnými následky. Proto je potřeba mnohem více úsilí pro správu a udržování systému v provozuschopném stavu.

Nepředvídatelnost. Jak všichni uživatelé webu vědí, reakce distribuovaných systémů na určité události je nepředvídatelná a závisí na plně naložen systém, jeho organizace a zatížení sítě. Vzhledem k tomu, že se všechny tyto parametry mohou neustále měnit, může se čas potřebný k dokončení uživatelského požadavku v té či oné době výrazně lišit.
Při diskuzi o výhodách a nevýhodách distribuovaných systémů kniha identifikuje řadu kritických problémů návrhu takových systémů (tabulka 11.1). Tato kapitola se zaměřuje na architekturu distribuovaného softwaru, jak se domnívám při vývoji softwarových produktů tento okamžik je nejvýznamnější. Pokud vás zajímají jiná témata, podívejte se do specializovaných knih o distribuovaných systémech.
Tabulka 11.1. Problémy navrhování distribuovaných systémů

Úkolem vývojářů distribuovaných systémů je navrhnout software nebo hardware tak, aby poskytoval všechny potřebné vlastnosti distribuovaného systému. A to vyžaduje znát výhody a nevýhody různých architektur distribuovaných systémů. Existují dva příbuzné typy architektur distribuovaných systémů.
1. Architektura klient/server. V tomto modelu může být systém reprezentován jako soubor služeb poskytované servery klientům. V takových systémech se servery a klienti navzájem výrazně liší.

2. Architektura distribuovaných objektů. V tomto případě neexistují žádné rozdíly mezi servery a klienty a systém lze považovat za sadu vzájemně se ovlivňujících objektů, na jejichž umístění ve skutečnosti nezáleží. Mezi poskytovatelem služeb a jejich uživateli není žádný rozdíl.
V distribuovaném systému mohou být implementovány různé systémové komponenty různé jazyky programování a provoz na různých typech procesorů. Datové modely, reprezentace informací a interakční protokoly – to vše nemusí být nutně stejného typu v distribuovaném systému. Distribuované systémy proto vyžadují software, který dokáže spravovat tyto heterogenní části a zaručit interakci a výměnu dat mezi nimi. Middleware patří do této třídy softwaru. Je jakoby uprostřed mezi různými částmi distribuovaných součástí systému.

Tento článek popisuje různé typy middlewaru, které mohou podporovat distribuované výpočty. Takový software je zpravidla sestaven z hotových komponent a nevyžaduje speciální úpravy od vývojářů. Mezi příklady middlewaru patří programy pro správu databází, transakční manažery, převodníky dat, komunikační inspektoři atd. Dále v této kapitole bude struktura distribuovaných systémů popsána jako třída middlewaru.

Distribuované systémy jsou obvykle vyvíjeny pomocí objektově orientovaného přístupu. Tyto systémy jsou vytvořeny z volně integrovaných částí, z nichž každá může přímo interagovat jak s uživatelem, tak s ostatními částmi systému. Tyto části by měly reagovat na nezávislé události, kdykoli je to možné. Softwarové objekty postavené na těchto principech jsou přirozenou součástí distribuovaných systémů. Pokud ještě nejste obeznámeni s pojmem objekty, doporučuji si nejprve přečíst kapitolu 12 a poté se k této kapitole znovu vrátit.

11.1. Víceprocesorová architektura

Nejjednodušším distribuovaným systémem je víceprocesorový systém. Skládá se z mnoha různých procesů, které mohou (ale nemusí) běžet na různých procesorech. Tento modelčasto používané ve velkých systémech reálného času. Jak se dozvíte v kapitole 13, tyto systémy shromažďují informace, rozhodují se na jejich základě a posílají signály agentovi, který mění systémové prostředí. V zásadě lze všechny procesy související se sběrem informací, rozhodováním a řízením výkonného mechanismu provádět na jediném procesoru pod kontrolou plánovače úloh. Použití více procesorů zlepšuje výkon a odolnost systému. Rozdělení procesů mezi procesory může být potlačeno (je vlastní kritickým systémům) nebo může být řízeno správcem procesů.

Na Obr. 11.1 ukazuje příklad tohoto typu systému. Jedná se o zjednodušený model systému řízení dopravy. Skupina distribuovaných senzorů shromažďuje informace o množství průtoku. Shromážděné údaje jsou zpracovávány na místě před odesláním do dispečinku. Na základě obdržených informací se operátoři rozhodují a řídí semafory. V tomto příkladu existují samostatné logické procesy pro správu senzorů, řídicí místnosti a semaforů. Může se jednat jak o jednotlivé procesy, tak o skupinu procesů. V našem příkladu běží na různých procesorech.

Rýže. 11.1. Multiprocesorový systém řízení dopravy
Softwarové systémy, na kterých běží více procesů současně, nemusí být nutně distribuovány. Pokud je v systému více než jeden procesor, není složité implementovat distribuci procesů. Při tvorbě víceprocesorových softwarových systémů však není nutné vycházet pouze z distribuovaných systémů. Návrh těchto typů systémů se v podstatě řídí stejným přístupem jako návrh systémů pracujících v reálném čase popsaný v kapitole 13.

11.2. Architektura klient/server

Kapitola 10 se již zabývala konceptem klient/server. V architektuře klient/server je softwarová aplikace modelována jako sada služeb poskytovaných servery a sada klientů využívajících tyto služby. Klienti si musí být vědomi dostupných (existujících) serverů, i když si nemusí být vědomi existence jiných klientů. Jak je patrné z Obr. Na obrázku 11.2, což je schéma distribuované architektury klient/server, klienti a servery představují různé procesy.


Rýže. 11.2. Systém klient/server
Systém nemusí mít vztah jedna ku jedné mezi procesy a procesory. Na Obr. Obrázek 11.3 ukazuje fyzickou architekturu systému, který se skládá ze šesti klientských strojů a dvou serverů. Spouštějí klientské a serverové procesy znázorněné na obr. 11.2. Obecně, když mluvím o klientech a serverech, mám na mysli spíše logické procesy než fyzické stroje na kterých tyto procesy běží.

Architektura systému klient/server by měla odrážet logickou strukturu vyvíjené softwarové aplikace. Na Obr. 11.4 nabízí další pohled na softwarovou aplikaci strukturovanou do tří úrovní. Prezentační vrstva poskytuje uživatelům informace a interakci s nimi. Runtime aplikace implementuje logiku aplikace. Vrstva správy dat provádí všechny databázové operace. V centralizovaných systémech neexistuje jasné oddělení mezi těmito úrovněmi. Při návrhu distribuovaných systémů je však nutné tyto vrstvy oddělit, aby bylo možné každou vrstvu umístit na různé počítače.

Nejjednodušší architektura klient/server je dvouvrstvá, ve které se aplikace skládá ze serveru (nebo mnoha identických serverů) a skupiny klientů. Existují dva druhy takové architektury (obr. 11.5).
1. Modelka tenký klient. V tomto modelu se veškerá práce s aplikací a správa dat provádí na serveru. Na klientském počítači běží pouze software prezentační vrstvy.

2. model tlustého klienta. V tomto modelu server pouze spravuje data. Na klientském stroji je realizován provoz aplikace a interakce s uživatelem systému.


Rýže. 11.3. Počítače v síti klient/server

Rýže. 11.4. Softwarové aplikační vrstvy
Tenký klient s dvouvrstvou architekturou je nejjednodušší způsob migrace stávajících centralizovaných systémů (viz Kapitola 26) na architekturu klient/server. Uživatelské rozhraní se v těchto systémech „přesune“ na osobní počítač a samotná softwarová aplikace plní funkce serveru, tzn. spouští všechny aplikační procesy a spravuje data. Model tenkého klienta lze také implementovat tam, kde klienti nejsou běžnými síťovými zařízeními osobní počítače nebo pracovní stanice. Síťová zařízení provozují internetový prohlížeč a uživatelské rozhraní implementované v systému.


Rýže. 11.5. Modely tenkých a tlustých klientů
Hlavní nevýhodou modelu tenkého klienta je vysoká zátěž serveru a sítě. Všechny výpočty se provádějí na serveru a to může vést k významným síťový provoz mezi klientem a serverem. Moderní počítače mají dostatek výpočetního výkonu, ten se ale v modelu tenkého klienta banky prakticky nepoužívá.

Naproti tomu model tlustého klienta využívá výpočetní výkon místních strojů: na klientském počítači je umístěna vrstva pro provádění aplikací i vrstva prezentace. Server je zde v podstatě transakční server, který spravuje všechny databázové transakce. Příkladem tohoto typu architektury mohou být systémy bankomatů, kde je bankomatem klient a server je centrální počítač, který spravuje databázi zákaznických účtů.

Na Obr. zobrazeno 11.6 síťový systém bankomaty. Všimněte si, že bankomaty nejsou připojeny k zúčtovací databázi přímo, ale prostřednictvím teleprocessingového monitoru. Tento monitor je prostředníkem, který komunikuje se vzdálenými klienty a organizuje požadavky klientů do sekvence transakcí pro práci s databází. Použití sekvenčních transakcí, když dojde k selhání, umožňuje systému obnovit se bez ztráty dat.


Rýže. 11.6. Systém klient/server pro síť ATM
Vzhledem k tomu, že provádění softwarové aplikace je organizováno efektivněji v modelu tlustého klienta než v modelu tenkého klienta, je obtížnější takový systém spravovat. Zde jsou funkce aplikace distribuovány na mnoha různých strojích. Nutnost výměny aplikace vede k její reinstalaci na všech klientských počítačích, což je drahé, pokud jsou v systému stovky klientů.

Příchod jazyka Java a apletů ke stažení umožnil vývoj modelů klient/server, které jsou někde mezi modely tenkých a tlustých klientů. Část programů, které tvoří aplikaci, lze stáhnout na klientský počítač jako Java applety a tím snižovat zatížení serveru. Uživatelské rozhraní je vytvořeno pomocí webového prohlížeče, který spouští Java applety. Nicméně, webové prohlížeče od různých dodavatelů a dokonce různé verze Webové prohlížeče od stejného výrobce nefungují vždy stejně. Starší prohlížeče na starších počítačích nemusí vždy spustit Java applety. Proto by se tento přístup měl používat pouze tehdy, když jste si jisti, že všichni uživatelé systému mají nainstalované prohlížeče kompatibilní s Java.

Ve dvouvrstvém modelu klient/server je významným problémem umístění tří logických vrstev na dvou počítačových systémech – prezentace, spouštění aplikací a správa dat. Proto má tento model často buď problémy se škálovatelností a výkonem, pokud je zvolen model tenkého klienta, nebo problémy se správou systému, pokud je použit model tlustého klienta. Aby se předešlo těmto problémům, je třeba zvolit alternativní přístup – třívrstvý model architektury klient/server (obrázek 11.7). V této architektuře odpovídají samostatné procesy vrstvám prezentace, spouštění aplikací a správy dat.


Rýže. 11.7. Třívrstvá architektura klient/server
Softwarová architektura, postavená na třívrstvém modelu klient/server, nevyžaduje tři počítačové systémy. Na stejném počítači serveru můžete spustit spouštění aplikací i správu dat jako samostatné logické servery. Pokud zároveň vzrostou systémové požadavky, bude relativně snadné oddělit spouštění aplikací a správu dat a provozovat je na různých procesorech.

Bankovní systém využívající internetové služby lze implementovat pomocí třívrstvé architektury klient/server. Účtovací databáze (obvykle umístěná na hostitelském počítači) poskytuje služby správy dat, webový server podporuje aplikační služby, jako jsou zařízení pro převod peněz, generování zpráv, placení faktur atd. Klientem je počítač uživatele s internetovým prohlížečem. Jak je znázorněno na Obr. 11.8 je tento systém škálovatelný, protože je relativně snadné přidávat nové webové servery s rostoucím počtem klientů.

Použití třívrstvé architektury v tomto příkladu optimalizovalo přenos dat mezi webovým serverem a databázovým serverem. Interakce mezi těmito systémy nemusí být založena na internetových standardech, ale lze použít rychlejší nízkoúrovňové komunikační protokoly. Informace z databáze jsou obvykle zpracovávány účinným middlewarem, který podporuje databázové dotazy v daném jazyce strukturované dotazy SQL.

V některých případech lze třívrstvý model klient/server převést na vícevrstvý přidáním dalších serverů do systému. Vrstvené systémy lze také použít tam, kde aplikace potřebují mít přístup k informacím umístěným v různých databázích. V tomto případě je federovaný server umístěn mezi serverem, na kterém je spuštěna aplikace, a databázovými servery. Federovaný server shromažďuje distribuovaná data a předkládá je aplikaci, jako by byla ve stejné databázi.


Rýže. 11.8. Použití architektury distribuovaného bankovnictvíInternet-služby
Návrháři architektur klient/server musí při výběru té nejvhodnější zvážit řadu faktorů. V tabulce. 11.2 uvádí různá použití architektury klient/server.
Tabulka 11.2. aplikace odlišné typy architektury klient/server

11.3. Architektura distribuovaných objektů

V modelu klient/server distribuovaného systému existují rozdíly mezi klienty a servery. Klient požaduje služby pouze od serveru, hq ne od jiných klientů; servery mohou fungovat jako klienti a požadovat služby od jiných serverů, ale ne od klientů; klienti si musí být vědomi služeb poskytovaných určitými servery a toho, jak tyto servery interagují. Tento model je skvělý pro mnoho typů aplikací, ale zároveň omezuje vývojáře systémů, kteří se musí rozhodovat, kde budou poskytovat služby. Musí také poskytovat podporu pro škálovatelnost a vyvíjet prostředky pro zahrnutí klientů na distribuované servery.

Obecnějším přístupem používaným v návrhu distribuovaného systému je rozmazání rozdílu mezi klientem a serverem a návrh architektury systému jako architektury distribuovaného objektu. V této architektuře (obrázek 11.9) jsou hlavními součástmi systému objekty, které prostřednictvím svých rozhraní poskytují sadu služeb. Jiné objekty vyvolávají tyto služby bez rozlišení mezi klientem (uživatelem služby) a serverem (poskytovatelem služby).


Rýže. 11.9. Architektura distribuovaných objektů
Objekty mohou být umístěny na různých počítačích v síti a interagovat prostřednictvím middlewaru. Analogicky se systémovou sběrnicí, která umožňuje připojení různá zařízení a podporují komunikaci mezi hardwarem, middleware lze považovat za softwarovou sběrnici. Poskytuje sadu služeb, které umožňují objektům vzájemně interagovat, přidávat je nebo odebírat ze systému. Middleware se nazývá broker objektových požadavků. Jeho úkolem je poskytovat rozhraní mezi objekty. Zprostředkovatelé požadavků na objekty jsou popsáni v části 11.4.

Hlavní výhody modelu distribuované objektové architektury jsou uvedeny níže.
Vývojáři systému mohou být pomalí při rozhodování o tom, kde a jak budou služby poskytovány. Objekty poskytující služby mohou běžet kdekoli (uzel) v síti. Proto se rozdíl mezi modely tlustého a tenkého klienta stává irelevantním, protože pro spuštění aplikace není nutné předem plánovat umístění objektů.

Architektura systému je zcela otevřená, což umožňuje v případě potřeby přidávat do systému nové zdroje. Další část poznamenává, že standardy softwarových sběrnic se neustále vyvíjejí, aby umožnily objektům napsaným v různých programovacích jazycích vzájemně se ovlivňovat a poskytovat si služby.

Flexibilita a škálovatelnost systému. Pro zvládnutí zatížení systému můžete vytvořit instance systému se stejnými službami, které budou poskytovat různé objekty nebo různé instance (kopie) objektů. Když se zatížení zvýší, mohou být do systému přidány nové objekty, aniž by byla přerušena práce ostatních objektů v systému.

Systém je možné dynamicky rekonfigurovat pomocí objektů migrujících v síti na vyžádání. Objekty poskytující služby mohou migrovat na stejný procesor jako objekty požadující služby, čímž se zlepšuje výkon systému.
Architekturu distribuovaných objektů lze v procesu návrhu systému použít dvěma způsoby.
1. Ve formě logického modelu, který umožňuje vývojářům strukturovat a plánovat systém. V tomto případě je funkčnost aplikace popsána pouze termíny a kombinacemi služeb. Poté jsou vyvíjeny způsoby poskytování služeb pomocí více distribuovaných objektů. Na této úrovni se zpravidla navrhují velkomodulové objekty, které poskytují služby odrážející specifika konkrétní aplikační oblasti. Například v účetním programu maloobchodní můžete zahrnout objekty, které by sledovaly stav zásob, sledovaly interakce se zákazníky, klasifikovaly zboží atd.

2. Jako flexibilní přístup k implementaci systémů klient/server. V tomto případě logický model systems je model klient/server, ve kterém jsou klienti a servery implementováni jako distribuované objekty, které interagují prostřednictvím softwarové sběrnice. S tímto přístupem je snadné nahradit systém např. dvouúrovňovým víceúrovňovým. V tomto případě nelze server ani klienta implementovat do jednoho objektu, ale mohou se skládat z mnoha malých objektů, z nichž každý poskytuje určitou službu.
Příkladem systému, který je vhodný pro distribuovanou objektovou architekturu, je systém pro zpracování dat uložených v různých databázích (obr. 11.10). V tomto příkladu lze libovolnou databázi považovat za objekt s rozhraním, které poskytuje přístup k datům pouze pro čtení. Každý z objektů integrátoru se zabývá určitými typy závislostí dat shromažďováním informací z databází, aby se pokusil tyto závislosti sledovat.

Objekty vizualizéru interagují s objekty integrátoru a prezentují data v grafické podobě nebo generují zprávy o analyzovaných datech. Způsoby, jak prezentovat grafické informace, jsou popsány v kapitole 15.


Rýže. 11.10. Architektura systému distribuovaného zpracování dat
Pro tento typ aplikace je architektura distribuovaných objektů vhodnější než architektura klient/server ze tří důvodů.
1. V těchto systémech (na rozdíl např. od systému ATM) neexistuje jediný poskytovatel služeb, na který by byly soustředěny všechny služby správy dat.

2. Můžete zvýšit počet dostupných databází bez přerušení systému, protože každá databáze je pouze objekt. Tyto objekty podporují zjednodušené rozhraní, které řídí přístup k datům. Dostupné databáze lze umístit na různé stroje.

3. Přidáním nových objektů integrátoru můžete sledovat nové typy závislostí mezi daty.
Hlavní nevýhodou distribuovaných objektových architektur je, že je obtížnější je navrhnout než systémy klient/server. Ukazuje se, že systémy klient/server poskytují přirozenější přístup k budování distribuovaných systémů. Odráží vztah mezi lidmi, ve kterém někteří lidé využívají služeb jiných lidí, kteří se specializují na poskytování konkrétních služeb. Je mnohem obtížnější vyvinout systém v souladu s architekturou distribuovaných objektů, protože softwarový průmysl dosud nenashromáždil dostatečné zkušenosti s návrhem a vývojem objektů velkého rozsahu.

11.4. CORBA

Jak bylo uvedeno v předchozí části, implementace architektury distribuovaných objektů vyžaduje middleware (zprostředkovatele požadavků na objekty), který organizuje interakci mezi distribuovanými objekty. Zde mohou nastat určité problémy, protože objekty v systému mohou být implementovány v různých programovacích jazycích, mohou být spouštěny různé platformy a jejich jména by neměla znát všechny ostatní objekty v systému. Middleware proto musí udělat hodně práce, aby udržoval neustálou komunikaci mezi objekty.

V v současné době Existují dva hlavní standardy middlewaru pro podporu distribuovaných objektů.
1. CORBA (Common Object Request Broker Architecture - architektura poptávkových brokerů pro společné objekty). Jedná se o sadu middlewarových standardů vyvinutých OMG (Object Management Group). OMG je konsorcium výrobců softwaru a hardwaru, včetně společností jako Sun, Hewlett-Packard a IBM. Standardy CORBA definují běžný na stroji nezávislý přístup k výpočtu distribuovaných objektů. od různých výrobců bylo vyvinuto mnoho implementací tohoto standardu. Standardy CORBA jsou podporovány provozem Unixový systém a operační systémy od společnosti Microsoft.

2. DCOM (Distributed Component Object Model - objektový model distribuovaných komponent). DCOM je standard vyvinutý a implementovaný společností Microsoft a integrovaný do jejích operačních systémů. Tento model distribuovaného počítání je méně univerzální než CORBA a nabízí omezenější možnosti pro síťové interakce. DCOM je v současnosti omezen na operační systémy Microsoft.
Zde jsem se rozhodl věnovat pozornost technologii CORBA, protože je univerzálnější. Navíc se domnívám, že je pravděpodobné, že CORBA, DCOM a další technologie, jako je RMI (Remote Method Invocation - vzdálené volání metody, technologie pro budování distribuovaných aplikací v jazyce Java), se budou postupně sbližovat a to konvergence bude založena na standardech CORBA. Proto není potřeba další standard. Rozdílné standardy budou pouze brzdou dalšího rozvoje.

Standardy CORBA definuje skupina OMG, která sdružuje více než 500 společností podporujících objektově orientovaný vývoj. Úlohou OMG je vytvářet standardy pro objektově orientovaný vývoj, nikoli poskytovat konkrétní implementace těchto standardů. Tyto normy jsou volně dostupné na webových stránkách OMG. Skupina se nezabývá pouze standardy CORBA, ale definuje také širokou škálu dalších standardů, včetně modelovacího jazyka UML.

Zastoupení distribuovaných aplikací v rámci CORBA je znázorněno na Obr. 11.11. Toto je zjednodušený diagram architektury správy objektů převzatý z článku. Očekává se, že distribuovaná aplikace se bude skládat z následujících komponent.
1. Aplikační objekty, které jsou vytvořeny a vyvinuty pro tento softwarový produkt.

2. Standardní objekty, které jsou definovány OMG pro konkrétní úkoly. V době psaní této knihy se mnoho lidí zabývalo vývojem objektových standardů pro finance, pojišťovnictví, elektronický obchod, zdravotnictví a další.

3. Základní služby CORBA podporující základní distribuované výpočetní služby, jako jsou adresáře, správa zabezpečení atd.

4. Horizontální nástroje CORBA, jako jsou uživatelská rozhraní, nástroje pro správu systému atd. Horizontálními prostředky, které jsou společné pro mnoho aplikací.


Rýže. 11.11. Struktura aplikace založené na distribuovaných standardechCORBA
Standardy CORBA popisují čtyři hlavní prvky.
1. Objektový model, ve kterém objekt CORBA zapouzdřuje stavy prostřednictvím jasného popisu v jazyce IDL (Interface Definition Language).

2. Object Request Broker (ORB), který spravuje požadavky na objektové služby. ORB přiděluje objekty, které poskytují služby, připravuje je na příjem požadavků, předává požadavek službě a vrací výsledky objektu, který požadavek podal.

3. Kolekce objektových služeb, které jsou základními službami a jsou potřebné v mnoha distribuovaných aplikacích. Příkladem jsou adresářové služby, transakční služby a dočasné služby údržby objektů.

4. Agregát společné komponenty postavena nad základními službami. Mohou být jak vertikální, odrážející specifika konkrétní oblasti, tak horizontální univerzální komponenty používané v mnoha softwarových aplikací. Tyto komponenty jsou popsány v kapitole 14.
V modelu CORBA objekt zapouzdřuje atributy a služby jako běžný objekt. Objekty CORBA však musí stále obsahovat definici různých rozhraní, která popisují globální atributy a objektové operace. Objektová rozhraní CORBA jsou definována ve standardu univerzální jazyk popisy rozhraní IDL. Pokud jeden objekt požaduje služby poskytované jinými objekty, přistupuje k těmto službám prostřednictvím rozhraní IDL. Objekty CORBA mají jedinečný identifikátor nazývaný Interoperable Object Reference (IOR). Když jedna entita odešle požadavky na službu poskytovanou jinou entitou, použije se identifikátor IOR.

Zprostředkovatel požadavků na objekty zná objekty, které požadují služby, a jejich rozhraní. Organizuje interakci mezi objekty. O umístění jiných objektů, stejně jako o jejich realizaci, nemusí spolupracující objekty nic vědět. Protože rozhraní IDL odděluje objekty od zprostředkovatele, implementaci objektů lze změnit, aniž by to ovlivnilo ostatní součásti systému.

Na Obr. Obrázek 11-12 ukazuje, jak objekty ol a o2 komunikují prostřednictvím zprostředkovatele požadavku na objekt. Volající (ol) je spojen s IDL stub, který definuje rozhraní objektu, který poskytuje službu. Konstruktor objektu ol při požadavku na službu vloží volání do útržku jeho implementace objektu. IDL je rozšíření C++, takže pokud programujete v C++, C nebo Java, přístup k útržku je snadný. Překlad popisu rozhraní objektu do IDL je také možný pro jiné jazyky, jako je Ada nebo COBOL. Ale v těchto případech je nutná vhodná instrumentální podpora.

Rýže. 11.12. Objektová komunikace prostřednictvím Object Request Broker
Objekt, který poskytuje službu, je spojen s kostrou IDL, která váže rozhraní k implementaci služby. Jinými slovy, když je služba volána přes rozhraní, rámec IDL překládá volání do služby bez ohledu na to, jaký jazyk byl použit při implementaci. Po dokončení metody nebo postupu kostra převede výsledky do IDL, aby byly k dispozici volajícímu. Pokud objekt současně poskytuje služby jiným objektům nebo využívá služby, které jsou poskytovány jinde, potřebuje jak IDL kostru, tak IDL stub. Ten je nezbytný pro všechny používané objekty.

Zprostředkovatel požadavků na objekt se obvykle neimplementuje jako samostatné procesy, ale jako rámec (viz kapitola 14), který je spojen s implementací objektu. Proto v distribuovaném systému musí mít každý počítač, na kterém jsou spuštěny objekty, svého vlastního zprostředkovatele požadavků na objekt, který zpracovává všechna volání místních objektů. Pokud je však podán požadavek na službu, která je poskytována vzdálenou entitou, je vyžadována interakce mezi zprostředkovateli.

Tato situace je znázorněna na Obr. 11.13. V tomto příkladu, pokud objekt ol nebo o2 odesílá požadavky na služby poskytované objekty o3 nebo o4, je nutná interakce zprostředkovatelů spojených s těmito objekty. Standardy CORBA podporují komunikaci broker-to-broker, což umožňuje makléřům přístup k popisům rozhraní IDL, a nabízejí standard OMG Generic Inter-ORB Protocol (GIOP) pro komunikaci s makléři. Tento protokol definuje standardní zprávy, které si makléři mohou vyměňovat při volání vzdálených objektů a předávání informací. V kombinaci s nízkoúrovňovým internetovým protokolem TCP/IP umožňuje tento protokol makléřům komunikovat přes internet.

První varianty CORBA byly vyvinuty již v 80. letech 20. století. Rané verze CORBA byla jen o podpoře distribuovaných objektů. Postupem času se však standardy vyvíjely, staly se pokročilejšími. Podobně jako mechanismy pro komunikaci distribuovaných objektů nyní standardy CORBA některé definují standardní služby, který lze použít k podpoře objektově orientovaných aplikací.


Rýže. 11.13. Interakce mezi brokery žádosti o objekt
Služby CORBA jsou nástroje, které jsou potřebné v mnoha distribuovaných systémech. Tyto standardy definují přibližně 15 běžných služeb (služeb). Tady jsou některé z nich.
1. Pojmenovací služba, která umožňuje objektům najít jiné objekty v síti a odkazovat na ně. Jmenná služba je adresářová služba, která přiřazuje názvy objektům. Objekty mohou tuto službu použít k vyhledání IOR jiných objektů podle potřeby.

2. Registrační služba, která umožňuje objektům registrovat jiné objekty poté, co nastanou určité události. Pomocí této služby lze objekty registrovat podle jejich účasti na konkrétní akci a kdy daná událost již došlo, služba jej automaticky zaregistruje.

3. Transakční služba, která podporuje elementární transakce a vrácení zpět v případě chyb nebo selhání. Tato služba je zařízení odolné proti chybám (viz kapitola 18), které poskytuje obnovu v případě chyb během operace aktualizace. Pokud akce k aktualizaci objektu způsobí chyby nebo selhání systému, daný objekt vždy se můžete vrátit do stavu, ve kterém byl před zahájením aktualizace.
Předpokládá se, že standardy CORBA by měly obsahovat definice rozhraní pro širokou škálu komponent, které lze použít při vytváření distribuovaných aplikací. Tyto komponenty mohou být vertikální nebo horizontální. Vertikální komponenty jsou navrženy speciálně pro konkrétní aplikace. Jak již bylo uvedeno, na vývoji definic těchto složek se podílelo mnoho odborníků z různých oblastí činnosti. Horizontální komponenty jsou obecné, jako jsou komponenty uživatelského rozhraní.

V době psaní této knihy již byly specifikace součástí vyvinuty, ale ještě nebyly dohodnuty. Z mého pohledu je to pravděpodobně místo, kde jsou standardy CORBA nejslabší, a může trvat několik let, než se dostanete do bodu, kdy jsou k dispozici specifikace i implementace komponent.
KLÍČOVÉ KONCEPTY
Všechny velké systémy v různé míře jsou distribuovány, ve kterých softwarové komponenty jsou vykonávány na skupině procesorů integrovaných do sítě.

Distribuované systémy mají následující vlastnosti: využití zdrojů, otevřenost, souběžnost, škálovatelnost, tolerance chyb a průhlednost.

Systémy klient/server jsou distribuovány. Takové systémy jsou modelovány jako sada služeb poskytovaných serverem klientským procesům.

V systému klient/server je uživatelské rozhraní na straně klienta a správa dat je vždy udržována na sdíleném serveru. Aplikační funkce mohou být implementovány na klientském počítači nebo na serveru.

V architektuře distribuovaných objektů neexistuje žádný rozdíl mezi klienty a servery. Objekty poskytují základní služby, které mohou volat jiné objekty. Stejný přístup lze použít při implementaci systémů klient/server.

Distribuované objektové systémy musí mít middleware navržený tak, aby zpracovával interakce mezi objekty a přidával nebo odebíral objekty ze systému. Koncepčně lze middleware chápat jako softwarovou sběrnici, ke které jsou připojeny objekty.

Standardy CORBA jsou souborem standardů pro middleware, který podporuje architekturu distribuovaných objektů. Patří mezi ně objektový model, zprostředkovatel požadavků na objekt a definice sdílených služeb. V současné době existuje několik implementací standardů CORBA.
Cvičení
11.1. Vysvětlete, proč jsou distribuované systémy vždy škálovatelnější než centralizované. Jaký je pravděpodobný limit škálovatelnosti softwarového systému?

11.2. Jaký je hlavní rozdíl mezi modely tlustého a tenkého klienta při vývoji klient/server? Vysvětlete, proč použití Javy jako implementačního jazyka vyhlazuje rozdíly mezi těmito modely?

11.3. Na základě aplikačního modelu znázorněného na obr. Na obrázku 11.4 zvažte potenciální problémy, které mohou nastat při převodu sálového systému zdravotní péče z 80. let na systém klient/server.

11.4. Distribuované systémy založené na modelu klient/server se vyvíjejí od 80. let 20. století, ale teprve nedávno byly implementovány systémy založené na distribuovaných objektech. Uveďte tři důvody, proč se tak stalo.

11.5. Vysvětlete, proč používání distribuovaných objektů ve spojení s zprostředkovatelem požadavků na objekty usnadňuje implementaci škálovatelných systémů klient/server. Svou odpověď ilustrujte příkladem.

11.6. Jak se IDL používá k podpoře komunikace mezi objekty implementovanými v různých programovacích jazycích? Vysvětlete, proč tento přístup může způsobit problémy s výkonem, pokud existují drastické rozdíly mezi jazyky použitými k implementaci objektů.

11.7. Jaké základní vybavení by měl zprostředkovatel žádosti o objekt poskytovat?

11.8. Lze prokázat, že vývoj norem CORBA pro horizontální a vertikální komponenty omezuje konkurenci. Pokud jsou již vytvořeny a přizpůsobeny, brání to menším společnostem ve vývoji lepších komponent. Diskutujte o roli standardizace při udržování nebo omezování konkurence na softwarovém trhu.

(Materiál z webu http://se.math.spbu.ru)

Úvod.

V současné době jsou distribuovány téměř všechny velké softwarové systémy. distribuovaný systém- systém, ve kterém není zpracování informací soustředěno na jednom počítači, ale je distribuováno mezi více počítačů. Při navrhování distribuovaných systémů, které mají mnoho společného s návrhem softwaru obecně, je stále třeba brát v úvahu některé specifické vlastnosti.

Existuje šest hlavních charakteristik distribuovaných systémů.

1. Sdílení zdrojů. Distribuované systémy umožňují sdílení jak hardwarových (pevné disky, tiskárny), tak softwarových (soubory, kompilátory) zdrojů.
2. otevřenost.Jedná se o možnost rozšířit systém přidáním nových zdrojů.
3. Rovnoběžnost.V distribuovaných systémech může více procesů současně běžet na různých počítačích v síti. Tyto procesy mohou interagovat, když jsou spuštěny.
4. Škálovatelnost . Pod škálovatelnost schopnost přidávat nové vlastnosti a metody se rozumí.
5. Odolnost proti chybám. Mít více počítačů umožňuje duplikaci informací a odolnost vůči některým hardwarovým a softwarovým chybám. Distribuované systémy mohou zachovat částečnou funkčnost v případě chyby. K úplnému selhání systému dochází pouze při chybách sítě.
6. Průhlednost.Uživatelé mají plný přístup ke zdrojům v systému, zároveň jsou před nimi skryty informace o rozložení zdrojů v systému.

Distribuované systémy mají také řadu nevýhod.

1. Složitost. Mnohem obtížnější je obecně porozumět a vyhodnotit vlastnosti distribuovaných systémů, je náročnější je navrhovat, testovat a udržovat. Výkon systému také závisí na rychlosti sítě, nikoli na jednotlivých procesorech. Realokace zdrojů může výrazně změnit rychlost systému.
2. Bezpečnost. Obvykle lze k systému přistupovat z několika různých strojů, zprávy v síti lze prohlížet a zachycovat. Proto je mnohem obtížnější udržet bezpečnost v distribuovaném systému.
3. ovladatelnost. Systém se může skládat z různých typů počítačů, na které lze nainstalovat různé verze operačních systémů. Chyby na jednom počítači se mohou šířit nepředvídatelnými způsoby na další počítače.
4. nepředvídatelnost . Reakce distribuovaných systémů na některé události je nepředvídatelná a závisí na plné zátěži systému, jeho organizaci a zatížení sítě. Protože se tyto parametry mohou neustále měnit, může se doba odezvy na požadavek od času výrazně lišit.

Z těchto nedostatků je vidět, že při návrhu distribuovaných systémů vzniká řada problémů, se kterými musí vývojáři počítat.

1. Identifikace zdroje . Zdroje v distribuovaných systémech jsou umístěny na různých počítačích, takže systém pojmenování zdrojů by měl být navržen tak, aby uživatelé mohli snadno otevřít a odkazovat na zdroje, které potřebují. Příkladem je systém URL (Uniform Resource Locator), který určuje názvy webových stránek.
2. Sdělení. Univerzální provozuschopnost internetu a efektivní implementace protokolů TCP/IP na internetu pro většinu distribuovaných systémů jsou příkladem nejúčinnějšího způsobu komunikace mezi počítači. V některých případech, kdy je vyžadován speciální výkon nebo spolehlivost, lze však použít specializované nástroje.
3. Kvalita servisu systému . Toto nastavení odráží výkon, zdraví a spolehlivost. Kvalitu služby ovlivňuje řada faktorů: rozložení procesů, zdrojů, hardware a adaptabilita systému.
4. Softwarová architektura . Softwarová architektura popisuje distribuci systémových funkcí na systémové komponenty a také distribuci těchto komponent na procesory. Pokud jde o udržení vysoké kvality systémových služeb, je rozhodující výběr správné architektury.

Úkolem vývojářů distribuovaných systémů je navrhnout software a hardware tak, aby poskytoval všechny potřebné vlastnosti distribuovaného systému. A to vyžaduje znát výhody a nevýhody různých architektur distribuovaných systémů. Existují tři typy architektur distribuovaných systémů.

1. Architektura klient/server . V tomto modelu lze systém chápat jako soubor služeb poskytovaných servery klientům. V takových systémech se servery a klienti navzájem výrazně liší.
2. Třívrstvá architektura . V tomto modelu server poskytuje služby klientům nikoli přímo, ale prostřednictvím serveru obchodní logiky.

O prvních dvou modelech bylo řečeno nejednou, zastavme se u třetího.

1. Architektura distribuovaných objektů . V tomto případě neexistují žádné rozdíly mezi servery a klienty a systém lze považovat za sadu vzájemně se ovlivňujících objektů, na jejichž umístění ve skutečnosti nezáleží. Mezi poskytovatelem služeb a jejich uživateli není žádný rozdíl.

Tato architektura je dnes hojně využívána a je také tzv architektury webových služeb. Webová služba je aplikace, která je přístupná přes internet a poskytuje některé služby, jejichž podoba nezávisí na poskytovateli (jelikož se používá univerzální datový formát - XML) a platformě provozu. V daný čas Existují tři různé technologie, které podporují koncept distribuovaného objektové systémy. Jedná se o technologie EJB, CORBA a DCOM.

Nejprve pár slov o tom, co je XML obecně. XML je obecný datový formát, který se používá k poskytování webových služeb. Webové služby jsou založeny na otevřených standardech a protokolech: SOAP, UDDI a WSDL.

1. MÝDLO( Simple Object Access Protocol, vyvinutý organizací W3C, definuje formát pro požadavky na webové služby. Zprávy mezi webovou službou a jejím uživatelem jsou baleny do tzv. SOAP obálek (SOAP obálky, někdy se jim také říká XML obálky). Samotná zpráva může obsahovat buď požadavek na provedení nějaké akce, nebo odpověď – výsledek provedení této akce.
2. WSDL (Web Service Description Language).Rozhraní webové služby je popsáno v dokumentech WSDL (a WSDL je podmnožinou XML). Před nasazením služby vývojář napíše její popis ve WSDL, specifikuje adresu webové služby, podporované protokoly, seznam povolených operací, formáty požadavků a odpovědí.
3. UDDI (Universal Description, Discovery and Integration) - protokol pro vyhledávání webových služeb na internetu ( http://www.uddi.org/). Představuje obchodní rejstřík, kde poskytovatelé webových služeb registrují služby a vývojáři je nacházejí potřebné služby zahrnout do svých aplikací.

Ze zprávy se může zdát, že webové služby jsou nejlepším a nesporným řešením a jedinou otázkou je výběr vývojových nástrojů. Nicméně není. Existuje alternativa k webovým službám, sémantický web, o kterém zakladatel WWW Tim Berners-Lee hovořil před pěti lety.

Pokud je cílem webových služeb usnadnit komunikaci mezi aplikacemi, pak je sémantický web navržen tak, aby řešil mnohem více obtížný problém- pomocí mechanismů metadat ke zvýšení efektivity hodnoty informací, které lze nalézt na webu. Můžete to udělat tak, že opustíte dokumentově orientovaný přístup ve prospěch objektově orientovaného.

Bibliografie

1. SomervilleI. Softwarové inženýrství.
2. Dranica A. Java vs. NET. - "Computerra", #516.
3. Internetové zdroje.

založené na rekonfigurovatelných multi-pipeline computingu Prostředí L-Net

Jedním z naléhavých úkolů v oblasti řídicích systémů je vývoj softwaru pro distribuované řídicí systémy odolné proti poruchám. Řešení, která dnes v této oblasti existují, jsou proprietární, v důsledku toho jsou drahá a ne vždy účinná.

Tato řešení nezajišťují efektivní využití zdrojů redundantních bází, technických a softwarových, což negativně ovlivňuje jak odolnost proti chybám, tak škálovatelnost takových řešení. Pokud dojde k narušení síťové architektury, neexistuje možnost dynamické rekonfigurace jak procesů zpracování informací, tak přenosu datového toku (jak řízení, tak informací). Použití specifických mikrokontrolérů, použití DCS / SCADA komplikuje vývoj a podporu systémů, rozšiřování jejich funkčnosti.

Architektura distribuovaného řídicího systému

Zobecněná typická architektura distribuovaného řídicího systému (DCS) zahrnuje tři hierarchicky propojené úrovně: operátorskou úroveň, řídicí úroveň a vstupně-výstupní úroveň (viz obr. 1) .

Hlavním úkolem operátorské úrovně je poskytnout rozhraní člověk-stroj (HMI), které umožní konfiguraci a ovládání celého systému. Řídicí úroveň je zodpovědná za příjem a zpracování dat ze senzorů, přenos dat na úroveň operátora a generování řídicích akcí pro akční členy. Vstupně-výstupní úroveň představuje senzory a akční členy přímo spojené s řídicím objektem.

Úkolem softwaru je v rámci zobecněné architektury DCS zajistit fungování operátorské úrovně a její propojení s řídící úrovní systému. Základní úrovní při navrhování softwaru a řešení otázek jeho interakce s hardwarem je proto úroveň operátora. Software by měl co nejefektivněji využívat dostupné hardwarové zdroje systému a zároveň být co nejvíce nezávislý na vnitřní hardwarové architektuře.

Hardware poskytuje výpočetní zdroje, paměť a komunikační média mezi uzly v systému. Při návrhu celkové architektury systému se neuvažují konkrétní uzly I/O úrovně, které k němu budou připojeny při jeho konkrétní implementaci, proto se v zobecněné architektuře uvažuje operátorská úroveň a řídící úroveň. Hardware musí být rozšířený, splňovat moderní standardy, mít všechny vlastnosti a schopnosti nezbytné pro implementaci architektury.

Požadavky na DCS

Požadavky DCS se nevztahují pouze na systém jako celek, ale také na jeho hardwarové a softwarové komponenty samostatně, protože konkrétní přístupy ke splnění těchto požadavků na tyto komponenty se mohou zásadně lišit. DCS musí být primárně odolný vůči poruchám. Nejjednodušší metodou zvýšení odolnosti proti chybám je redundance (duplikace) funkčních jednotek nebo jejich kombinace. Druhou důležitou vlastností je škálovatelnost. Škálovatelnost je založena na implementaci speciálních algoritmů v softwaru a hardwarové schopnosti nahrazovat a přidávat nové uzly nebo jejich komponenty. Systém by přitom měl zůstat jednoduchý pro provoz, vývoj nových uzlů či modulů a úpravu architektury.

Přehled architektur DCS

Pro revizi architektur DCS byl vybrán Siemens SIMATIC PCS 7 DCS jako jeden z nejpopulárnějších na trhu a RTS S3 jako DCS implementovaný na bázi QNX RTOS.

Siemens SIMATIC PCS 7

Architektura systému má všechny vlastnosti zobecněné architektury DCS. Počítače založené na architektuře procesoru x86 s OS Windows a balíkem Siemens WinCC poskytujícím HMI fungují jako operátorské stanice. Existují servery s databázemi. Operátorské stanice, inženýrské stanice a servery jsou propojeny lokální sítí na bázi Ethernetu. Operátorská úroveň je propojena s úrovní správy redundantní sítě Industrial Ethernet. Na úrovni ovládání jsou programovatelné logické ovladače(PLC) s možností redundance z důvodu duplicity funkčnosti. Je možné se připojit k externím systémům a sítím a organizovat vzdálený přístup do systému.

RTS S3

Tato architektura se podobně skládá z úrovní zobecněné struktury DCS. Operátorské stanice jsou založeny na stejné hardwarové platformě jako SIMATIC DCS, ale lze je provozovat pod operačními systémy Windows i Linux. Inženýrské stanice jsou kombinovány s operátorskými místnostmi. Systém poskytuje jednotné prostředí pro vývoj aplikací. Síť Ethernet spojuje uzly v rámci nosné vrstvy a samotnou nosnou vrstvu s řídicí rovinou pomocí zásobníku protokolů TCP/IP. Na úrovni řízení jsou průmyslové počítače se systémem QNX OS s vlastní databází a možností redundance duplikací funkčnosti uzlu.

Nevýhody popsaných systémů

Ve výše popsaných systémech se pro úroveň operátora a úroveň řízení používá odlišná hardwarová a softwarová platforma. V rámci operátorské vrstvy lze použít pouze jednu architekturu procesoru a pro nastavení a vývoj řídicí vrstvy je zapotřebí vyhrazená inženýrská stanice. Tyto DCS nabízejí pouze hardwarovou redundanci s duplikací funkčnosti redundantního uzlu jako způsob zvýšení odolnosti proti chybám, což je iracionální použití redundantního hardwaru.

Charakteristika a funkční vlastnosti systému L-Net

Při vývoji systému L-Net bylo úkolem vytvořit řídicí systém, který by měl následující vlastnosti:

• Dynamická rekonfigurace s plnou obnovou s minimální ztrátou v případě selhání hostitele nebo narušení topologie sítě.
• Efektivní rozdělení úkolů mezi dostupné efektivní síťové uzly.
• Duplikace komunikačních kanálů mezi uzly s dynamickou rekonfigurací toků přenosu dat.
• Snadné ovládání a škálování systému.
• Přenositelnost a provozuschopnost systému na jakékoli hardwarové platformě určené pro řídicí systémy budov a vestavěné systémy.

K sestavení systému s výše popsanými charakteristikami je nutný operační systém, který je určen především pro tvorbu řídicích systémů a vestavěných systémů. Analýza existujících operačních systémů ukázala, že nejvhodnější operační systém je operační systém QNX 6 (Neutrino), který má velmi efektivní alokaci zdrojů a síťové možnosti. Široký síťové schopnosti poskytuje síťový protokol Qnet. Řeší problém spolehlivosti a dynamického vyrovnávání zátěže komunikačních kanálů, ale neřeší problém odolnosti systému jako celku. V důsledku toho byl vyvinut inovativní řídicí systém založený na distribuovaném, rekonfigurovatelném, vícepotrubním výpočetním prostředí. Vyvinutý systém má architekturu peer-to-peer, která zahrnuje tři logické bloky: vstupně-výstupní blok, blok přepínačů obecný účel a blok rekonfigurovatelného výpočetního prostředí (RCS) (viz obr. 2).

Hlavní výhody této architektury jsou:

• Typ vrstevníka
• Decentralizace
• Škálovatelnost
• Prostorové rozložení

Funkční vlastnosti této architektury:

• Data Pipelining
• Hardwarová redundance
• Rozložení zatížení
• Rekonfigurace za běhu

Na první úrovni architektury je vstupně-výstupní (I/O) blok, který zahrnuje: I/O uzly, I/O uzelový přepínač, I/O rozhraní, senzory a akční členy. Blok je zodpovědný za základní mechanismy pro generování řídicích akcí na základě dat z lokálních senzorů a dat přijatých z jiných úrovní řídicího systému. Přiřazené úlohy jsou rozděleny mezi zdravé I/O uzly na základě jejich aktuálního relativního výkonu nebo ručně operátorem. Senzory a akční členy jsou připojeny prostřednictvím sběrnice ke všem I/O uzlům v bloku, což umožňuje libovolnému uzlu dotazovat se na jakýkoli senzor nebo generovat dopad na jakýkoli akční člen. Přepínač I/O uzlů zajišťuje komunikaci mezi všemi I/O uzly pro výměnu dat mezi nimi a dalšími úrovněmi systémové architektury za účelem získání řídicích a informačních dat. S vhodnými hardwarovými možnostmi komunikují uzly přímo mezi sebou a s uzly a přepínači na jiných úrovních systému, což zkracuje dobu odezvy v síti. Přímé spojení mezi uzly a určitou pracovní zátěží uzlů v aktuálním režimu provozu I/O bloku umožňuje organizovat v bloku zřetězené výpočty nezbytné pro provoz tohoto bloku bez použití externího výpočetního výkonu řídicího systému ( RSS), což umožňuje efektivně využívat volné zdroje poskytované pro uzly redundantních I/O bloků v době selhání.

Univerzální přepínačový blok, umístěný na druhé úrovni architektury, organizuje komunikační linky mezi I/O bloky a RCS a externími systémy. Každý přepínač může propojovat různé uzly a přepínače v celém řídicím systému. Počet komunikačních linek je určen hardwarovými možnostmi uzlů a přepínačů obsažených v blocích. Protože síť Qnet umožňuje dynamickou distribuci datových toků, provádí se škálování tohoto bloku jednoduché připojení nová zařízení a nevyžaduje konfiguraci, a pokud jeden z přepínačů selže, přenos dat mezi uzly nebude přerušen, pokud druhý přepínač poskytuje podobné spojení mezi uzly nebo jsou přímo připojeny. Zároveň je nutné se postarat o dostatečnou šířku pásma sítě potřebnou pro zálohování neúspěšného switche.

Blok rekonfigurovatelné počítačové sítě (RCN), umístěný na třetí úrovni architektury, poskytuje řídicí systém s vysokým výpočetním výkonem pro řešení složitých problémů zpracování informací, rozhodování, rozpoznávání atd. Blok je zodpovědný za inicializaci celého řídicího systému: kontrolu provozuschopnosti přepínačů a uzlů, integritu sítě, sestavení síťových grafů celého systému, nastavení startovacích parametrů pro provoz I/O bloků. Uzly tohoto bloku umožňují archivaci jak vlastních dat, tak dat z I/O bloků. Každý uzel tohoto bloku může hrát roli operátorského stroje určeného k monitorování provozu systému a provádění úprav pracovních programů jak tohoto uzlu, tak všech uzlů systému a na požádání provádět rekonfiguraci.

Rozložení zatížení

Jedním z hlavních úkolů systému L-Net je rozložení výpočetní zátěže na uzly sítě. Řešení tohoto problému je založeno na konstrukci výpočetních pipelines. Pro sestavení výpočetního potrubí je předběžně sestaven graf úloh – schéma výměny datových toků od zdroje k příjemci. Senzory fungují jako zdroj a akční členy jako přijímač. Vlastní výpočetní potrubí je mapováním grafu úloh (viz obr. 3) na graf počítačové sítě (viz obr. 4) s přihlédnutím k požadavkům úlohy na výpočetní zdroje systému a jeho aktuální stav.

Řešením je využití služby, která poskytuje příjemci komplexní informace o aktuálním hardwaru, jeho stavu a dostupných zdrojích dat, provádí práci se síťovými grafy a úkoly. Výsledkem je zvýšení výkonu díky zřetězení výpočtů a racionálnímu využití všech k dispozici systému výpočetní prostředky.

odolnost proti chybám

Hlavním problémem fungování takového systému je úplné narušení výkonu výpočetních pipeline v případě výpadku některého uzlu tohoto potrubí nebo v případě přerušení přenosu dat mezi nimi. Základní prostředky protokolu Qnet dosahují obnovení vazeb mezi uzly v případě jejich částečného narušení z důvodu záložních linek poskytovaných architekturou. Systém L-Net řeší problém obnovy provozuschopnosti při úplném výpadku hostitele výpočetního systému dynamickou rekonfigurací výpočetního potrubí, tzn. pomocí pracovních prostředků k nahrazení špatného bloku. Systém poskytuje tři scénáře obnovy (rekonfigurace), které se liší dobou odezvy na selhání, dobou obnovy a použitými hardwarovými prostředky: při selhání, s pasivní připraveností, s aktivní připraveností.

• Rekonfigurace při selhání– po zjištění poruchy je vyhledán dostupný hardware a zahrnut do grafu úlohy.
• Rekonfigurace s pasivní připraveností– předem je určen redundantní hardware, je spuštěn proces, který zajišťuje implementaci vrcholu grafu úloh na uzlu, navazují se spojení, ale proces nezpracovává data, pokud nedojde k selhání hlavního uzlu.
• Aktivní rekonfigurace připravenosti– horní část grafu úlohy je implementována na několika uzlech, které provádějí paralelní zpracování dat a přenášejí výsledek.

Díky tomu systém poskytuje flexibilní připravenost na poruchy jak na softwarové, tak hardwarové úrovni, možnost měnit konfiguraci uzlů bez zastavení provozu a ztráty výkonu bez ohledu na implementaci sítě, výpočetního potrubí a uzlu.

Závěr

Vyvinutý systém L-Net na rozdíl od existující analogy zahrnuje použití široké škály hardwarových charakteristik uzlů DCS s jejich plnou softwarovou kompatibilitou. Při provozu uzlů pod kontrolou jednoho operačního systému (QNX Neutrino) je možné je postavit na různých architekturách procesorů (x86, ARM, MIPS atd.) s různými sadami rozhraní a periferií. Implementace uzlů je možná ve formě stolních PC, průmyslových PC, nositelných PC a jednodeskových počítačů. Všechny součásti softwarového komplexu vyvíjeného DCS lze provozovat na kterémkoli z jeho uzlů s OS QNX, přičemž zůstává možnost používat uzly s jiným operačním systémem. Tento přístup umožňuje využít každý uzel k řešení problémů jak na úrovni operátora, tak na úrovni řízení. Proto existuje flexibilní systém interakce mezi partnery bez pevné hierarchie úrovní, která je vlastní zobecněné architektuře DCS a systémům, které tuto architekturu používají jako základní. Síť typu peer-to-peer zjednodušuje proces nasazení, provozu, škálování a ladění systému.

Pro realizaci výpočetního potenciálu redundantního hardwaru ve vyvíjeném systému jsou navrženy dynamické konfigurační a rekonfigurační algoritmy založené na síťovém protokolu Qnet a softwaru. sítě L-Net. Algoritmus dynamické konfigurace je založen na rozložení výpočetní zátěže mezi všechny uzly pomocí zřetězení a paralelizace úloh a dynamického vyrovnávání zátěže na kanálech přenosu dat mezi uzly. Algoritmus rekonfigurace systému předpokládá přítomnost tří scénářů pro obnovení provozuschopnosti v případě selhání v závislosti na dostupném hardwaru, prioritách a úkolech přiřazených systému: při selhání, s pasivní připraveností (alokace zdrojů) a s aktivní připraveností (využití zdrojů). . Algoritmy pro dynamickou konfiguraci a rekonfiguraci umožňují zvýšit výkon a spolehlivost díky hardwarovým rezervám dostupným v systému.

Důležitou výhodou systému je maximální transparentnost hardwarových i softwarových technologií v něm použitých, což umožňuje výrazně zjednodušit technickou údržbu systému a vývoj nových modulů pro něj.

Závěr

Vyvinutá architektonická řešení umožňují zlepšit takové ukazatele distribuovaných řídicích systémů, jako je spolehlivost, výkon, cena, škálovatelnost a jednoduchost díky možnosti použití široké škály hardwaru, implementaci dynamických konfiguračních algoritmů a racionálnímu využití systémových zdrojů.

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: Základy aplikace. - Petrohrad: BHV-Petersburg, 2005.
5. Krten R. Úvod do QNX Neutrino. Průvodce vývojem aplikací v reálném čase. - Petrohrad: BHV-Petersburg, 2011.

Klíčová slova: distribuovaný řídicí systém, Informační podporařídicí systémy, distribuované rekonfigurovatelné systémy.

Architektura distribuovaného řídicího systému založeného na rekonfigurovatelném multi-pipeline výpočetním prostředí L-Net

Sergej Yu. Potomskiy, odborný asistent Národní výzkumné univerzity „Vysoká ekonomická škola“.

Nikita A. Poloyko, student pátého ročníku National Research University "Higher School of Economics". studijní referentka. programátor. Vzdělávací oblast: "Řízení a informatika v technických systémech".

abstraktní.Článek je věnován distribuovanému řídicímu systému založenému na rekonfigurovatelném multi-pipeline výpočetním prostředí. Architektura systému je dána. Rovněž jsou uvedeny základní charakteristiky a funkční vlastnosti systému. Článek představuje zdůvodnění výběru operačního systému. Základní výhody systému ve srovnání se stávajícím podobným vývojem jsou uvedeny v článku.

klíčová slova: distribuovaný řídicí systém, systémová softwarová podpora, distribuovaný rekonfigurovatelný.

V kontaktu s

Heterogenní vícepočítačové systémy

Největší počet v současnosti existujících distribuovaných systémů je postaven podle schématu heterogenních vícepočítačových systémů. To znamená, že počítače, které jsou součástí tohoto systému, mohou být extrémně rozmanité, například pokud jde o typ procesoru, velikost paměti a výkon I/O kanálu. V praxi mohou úlohu některých z těchto počítačů plnit vysoce výkonné paralelní systémy, například víceprocesorové nebo homogenní vícepočítače.

Síť, která je spojuje, může být také vysoce heterogenní.

Příkladem heterogenity je vytváření velkých vícepočítačových systémů pomocí stávající sítě a kanály. Takže například existence univerzitních distribuovaných systémů, skládajících se z lokálních sítí různých fakult, propojených vysokorychlostními kanály, není nic neobvyklého. V globální systémy různé stanice mohou být zase propojeny veřejnými sítěmi, jako jsou síťové služby nabízené komerčními dopravci, jako např SMDS nebo rámové relé.

Na rozdíl od systémů diskutovaných v předchozích odstavcích vyžaduje mnoho rozsáhlých heterogenních vícepočítačových systémů globální přístup. To znamená, že aplikace nemůže předpokládat, že určitý výkon nebo určité služby budou pro ni vždy dostupné.

Pokud jde o problémy škálování, které jsou vlastní heterogenním systémům, a vzhledem k potřebě globálního přístupu, který je vlastní většině z nich, poznamenáváme, že vytváření aplikací pro heterogenní vícepočítačové systémy vyžaduje specializovaný software. Distribuované systémy řeší tento problém. Aby se vývojáři aplikací nemuseli starat o hardware, který používají, distribuované systémy poskytují shell, který chrání aplikace před tím, co se děje v hardwaru (to znamená, že poskytují transparentnost).

Nejranější a nejzákladnější distribuovaná architektura je "klient-server", ve kterém jedna ze stran (klient) iniciuje výměnu dat odesláním požadavku druhé straně (serveru). Server požadavek zpracuje a v případě potřeby odešle klientovi odpověď (obr. 2.7).

Rýže. 2.7. Model interakce klient-server

Interakce v rámci modelu klient-server může být buď synchronní, kdy klient čeká, až server dokončí zpracování svého požadavku, nebo asynchronní, kdy klient odešle požadavek na server a pokračuje v jeho provádění, aniž by čekal na odpověď serveru. Model klienta a serveru lze použít jako základ pro popis různých interakcí. Zvažte interakci komponent softwaru, který tvoří distribuovaný systém.

Rýže. 2.8. Aplikační logické vrstvy

Zvažte některé typická aplikace, které lze v souladu s moderními koncepcemi rozdělit do následujících logických úrovní (obr. 2.8): uživatelské rozhraní (UI), aplikační logika (LP) a přístup k datům (DD), práce s databází (DB). Uživatel systému s ním komunikuje přes uživatelské rozhraní, databáze ukládá popisná data předmětová oblast aplikace a vrstva aplikační logiky implementuje všechny algoritmy související s danou oblastí.

Vzhledem k tomu, že v praxi mají různí uživatelé systému obvykle zájem o přístup ke stejným datům, nejjednodušším oddělením funkcí takového systému mezi několik počítačů bude oddělení logických úrovní aplikace mezi jednu serverovou část odpovědné aplikace. pro přístup k datům a klientským částem umístěným na několika počítačích, implementující uživatelské rozhraní. Aplikační logiku lze přiřadit serveru, klientům nebo mezi ně rozdělit (obr. 2.9).

Rýže. 2.9. Dvouvrstvá architektura

Architektura aplikací postavená na tomto principu se nazývá klient-server resp dvoučlánkový. V praxi takové systémy často nejsou klasifikovány jako distribuované systémy, ale formálně je lze považovat za nejjednodušší zástupce distribuovaných systémů.

Vývoj architektury klient-server je třívrstvá architektura, ve kterém jsou uživatelské rozhraní, aplikační logika a přístup k datům rozděleny do nezávislých komponent systému, které mohou běžet na nezávislých počítačích (obrázek 2.10).

Rýže. 2.10. Třívrstvá architektura

Požadavek uživatele v takových systémech postupně zpracovává klientská část systému, server aplikační logiky a databázový server. Distribuovaným systémem se však obvykle rozumí systémy se složitější architekturou než třívrstvá.

Rýže. 2.11. Distribuovaný maloobchodní systém

Pokud jde o podnikové automatizační aplikace, distribuované systémy jsou obvykle systémy s aplikační logikou rozdělenou mezi několik systémových komponent, z nichž každá může být spuštěna na samostatném počítači. Například implementace aplikační logiky maloobchodního systému by měla využívat požadavky na aplikační logiku třetích stran, jako jsou dodavatelé zboží, elektronické platební systémy nebo banky poskytující spotřebitelské úvěry (obrázek 2.11).

Dalším příkladem distribuovaného systému jsou sítě přímá výměna dat mezi klienty (peer-to-peer sítě). Pokud měl předchozí příklad „stromovou“ architekturu, pak jsou sítě přímé výměny organizovány složitějším způsobem, obrázek 2.12. Takové systémy jsou v současnosti pravděpodobně jedním z největších existujících distribuovaných systémů, který propojuje miliony počítačů.

Rýže. 2.12. Systém přímé výměny dat mezi klienty

Často je při definování distribuovaného systému v popředí rozdělení jeho funkcí mezi více počítačů. S tímto přístupem jakékoli výpočetní systém kde je zpracování dat sdíleno mezi dvěma nebo více počítači. Poněkud úžeji distribuovaný systém lze na základě definice E. Tanenbauma definovat jako soubor nezávislých počítačů propojených komunikačními kanály, které z pohledu uživatele nějakého softwaru vypadají jako jeden celek.

Tento přístup k definování distribuovaného systému má své nevýhody. Například vše, co se v takovém distribuovaném systému používá software by mohl fungovat na jednom počítači, nicméně z pohledu výše uvedené definice již takový systém distribuován nebude. Koncepce distribuovaného systému by proto měla být pravděpodobně založena na analýze softwaru, který takový systém tvoří.

Jako základ pro popis interakce dvou entit uvažujte obecný model interakce klient-server, kdy jedna ze stran (klient) zahájí výměnu dat odesláním požadavku druhé straně (serveru). Server požadavek zpracuje a v případě potřeby odešle klientovi odpověď (obrázek 1.1).

Rýže. 1.1.

Interakce v rámci modelu klient-server může být buď synchronní, kdy klient čeká, až server dokončí zpracování svého požadavku, nebo asynchronní, kdy klient odešle požadavek na server a pokračuje v jeho provádění, aniž by čekal na odpověď serveru. Model klienta a serveru lze použít jako základ pro popis různých interakcí. Pro tento kurz je důležitá interakce komponent softwaru, který tvoří distribuovaný systém.

Zvažte některé typické aplikace, které lze v souladu s moderními myšlenkami rozdělit do následujících logických úrovní (obr. 1.2): uživatelské rozhraní(IP), aplikační logika (LP) a datový přístup (DD) pracující s databází (DB). Uživatel systému s ním komunikuje prostřednictvím uživatelského rozhraní, databáze ukládá data popisující předmět aplikace a aplikační logická vrstva implementuje všechny algoritmy související s aplikací. předmětová oblast.

Vzhledem k tomu, že v praxi mají různí uživatelé systému obvykle zájem o přístup ke stejným datům, nejjednodušším oddělením funkcí takového systému mezi několik počítačů bude oddělení logických úrovní aplikace mezi jednu serverovou část odpovědné aplikace. pro přístup k datům a klientským částem umístěným na několika počítačích, implementující uživatelské rozhraní. Aplikační logiku lze přiřadit serveru, klientům nebo mezi ně rozdělit (obr. 1.3).

Architektura aplikací postavených na tomto principu se nazývá klient-server nebo dvouvrstvá. V praxi takové systémy často nejsou klasifikovány jako distribuované systémy, ale formálně je lze považovat za nejjednodušší zástupce distribuovaných systémů.

Vývoj architektury klient-server je třívrstvá architektura, ve které jsou uživatelské rozhraní, aplikační logika a přístup k datům rozděleny do nezávislých komponent systému, které mohou běžet na nezávislých počítačích (obr. 1.4).

Požadavek uživatele v takových systémech postupně zpracovává klientská část systému, server aplikační logiky a databázový server. Distribuovaným systémem se však obvykle rozumí systémy se složitější architekturou než třívrstvá.