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

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

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

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ů využívajících existující sítě a kanály. Například není neobvyklé, že existují univerzitní distribuované systémy, které se skládají z lokálních sítí různých oddělení propojených vysokorychlostními kanály. V globálních systémech mohou být různé stanice propojeny veřejnými sítěmi, jako jsou síťové služby nabízené komerčními telekomunikačními operátory, 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 bude mít neustále k dispozici.

Když přejdeme k problémům škálování, které jsou vlastní heterogenním systémům, a vezmeme-li v úvahu potřebu 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 se s tímto problémem vyrovnávají. Aby se vývojáři aplikací nemuseli starat o hardware, který používají, distribuované systémy poskytují softwarový obal, který chrání aplikace před tím, co se děje na hardwaru (to znamená, že poskytují transparentnost).

Nejranější a nejzákladnější distribuovaná architektura je architektura klient-server, ve které jedna strana (klient) zahájí komunikaci 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ěď od serveru. server. Model klient-server lze použít jako základ pro popis různých interakcí. Uvažujme interakci komponent softwaru, který tvoří distribuovaný systém.

Rýže. 2.8. Logické aplikační úrovně

Uvažujme typickou aplikaci, kterou 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 (AL) a datový přístup (DA), práce 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í aplikační doménu a aplikační logická vrstva implementuje všechny algoritmy související s aplikační doménou.

Protože v praxi mají různí uživatelé systému obvykle zájem o přístup ke stejným datům, nejjednodušším způsobem, jak distribuovat funkce takového systému mezi několik počítačů, by bylo oddělit logické úrovně aplikace mezi jednu serverovou část aplikace, která je odpovědná pro přístup k datům a klientským částem umístěným na několika počítačích implementujících uživatelské rozhraní. Aplikační logiku lze přiřadit serveru, klientům nebo mezi ně rozdělit (obrázek 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é, 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. Obvykle je však distribuovaný systém chápán jako systém se složitější architekturou než třívrstvý.

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

Ve vztahu k podnikovým automatizačním aplikacím se distribuované systémy obvykle nazývají 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 systému maloobchodního prodeje musí 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 přímé výměnné sítě organizovány složitějším způsobem, obr. 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

Principy tvorby podnikového systému zpracování informací

Historie vývoje výpočetní techniky (a tedy i softwaru) začala samostatnými, autonomními systémy. Vědci a inženýři byli zaměstnáni vytvářením prvních počítačů a většinou si lámali hlavu nad tím, jak zajistit, aby tyto shluky elektronek fungovaly. Tento stav však netrval dlouho – myšlenka na spojení výpočetního výkonu byla zcela zřejmá a byla ve vzduchu, prosycená hučením kovových skříní prvních ENIAKů a Marků. Koneckonců, myšlenka spojit úsilí dvou nebo více počítačů k řešení složitých úkolů, které přesahují možnosti každého z nich jednotlivě, leží na povrchu.

Rýže. 1. Distribuované výpočetní schéma

Praktickou realizaci myšlenky propojování počítačů do clusterů a sítí však brzdil nedostatek technických řešení a především potřeba vytvářet standardy a interakční protokoly. Jak víte, první počítače se objevily na konci čtyřicátých let dvacátého století a první počítačová síť ARPANet, která spojovala několik počítačů ve Spojených státech, se objevila až v roce 1966, téměř o dvacet let později. Taková kombinace výpočetních schopností samozřejmě velmi matně připomínala moderní distribuovanou architekturu, ale přesto to byl první krok správným směrem.

Vznik lokálních sítí nakonec vedl k rozvoji nové oblasti vývoje softwaru - vytváření distribuovaných aplikací. Museli jsme to udělat, jak se říká, od nuly, ale naštěstí o takové aplikace okamžitě projevily zájem velké společnosti, jejichž obchodní struktura taková řešení vyžadovala. Právě ve fázi tvorby podnikových distribuovaných aplikací se formovaly základní požadavky a vyvíjely základní architektury takových systémů, které se používají dodnes.

Postupně se sálové počítače a terminály vyvíjely směrem k architektuře klient-server, což byla v podstatě první verze distribuované architektury, tedy dvouvrstvého distribuovaného systému. Ostatně právě v aplikacích klient-server byla část výpočetních operací a obchodní logiky přenesena na stranu klienta, což se ve skutečnosti stalo vrcholem, vizitkou tohoto přístupu.

Během tohoto období se ukázalo, že hlavní výhody distribuovaných aplikací jsou:

· dobrá škálovatelnost – v případě potřeby lze snadno zvýšit výpočetní výkon distribuované aplikace bez změny její struktury;

· schopnost řídit zátěž - střední úrovně distribuované aplikace umožňují řídit toky uživatelských požadavků a přesměrovávat je ke zpracování na méně zatížené servery;

· globálnost – distribuovaná struktura umožňuje sledovat prostorové rozložení obchodních procesů a vytvářet klientské zakázky v nejvhodnějších bodech.

Jak čas plynul, malé ostrůvky univerzit, vládních a podnikových sítí se rozšiřovaly a spojovaly do regionálních a národních systémů. A pak se na scéně objevil hlavní hráč – internet.

Panegyrika o World Wide Web se již dlouho stala běžnou součástí publikací o počítačových tématech. Internet skutečně sehrál klíčovou roli ve vývoji distribuovaných počítačů a učinil z této spíše specializované oblasti vývoje softwaru střed zájmu armády profesionálních programátorů. Dnes výrazně rozšiřuje možnosti distribuovaných aplikací, umožňuje připojovat vzdálené uživatele a zpřístupňuje funkce aplikací všude.

Toto je historie problému. Nyní se podívejme, co jsou distribuované aplikace.

Distribuované výpočetní paradigma

Představte si poměrně velký výrobní podnik, obchodní společnost nebo společnost poskytující služby. Všechny jejich divize již mají vlastní databáze a specifický software. Centrální kancelář nějakým způsobem shromažďuje informace o aktuální činnosti těchto útvarů a poskytuje manažerům informace, na základě kterých činí manažerská rozhodnutí.

Pojďme dále a předpokládejme, že organizace, o které uvažujeme, se úspěšně rozvíjí, otevírá pobočky a vyvíjí nové typy produktů nebo služeb. Progresivně smýšlející manažeři se navíc na posledním setkání rozhodli zorganizovat síť vzdálených pracovišť, ze kterých by klienti dostávali informace o plnění svých zakázek.

V popsané situaci může být vedoucího IT oddělení jen líto, pokud se předem nepostaral o vybudování obecného systému řízení podnikových toků, protože bez něj bude velmi obtížné zajistit efektivní rozvoj organizace. . Kromě toho se nelze obejít bez podnikového systému zpracování informací, navrženého s ohledem na rostoucí zatížení a navíc odpovídajícímu hlavním obchodním tokům, protože všechna oddělení musí plnit nejen své úkoly, ale v případě potřeby také zpracovávat požadavky od jiných oddělení a dokonce (pro projektového manažera noční můra!) zákazníků.

Jsme tedy připraveni formulovat základní požadavky na moderní podnikové aplikace, diktované organizací samotného výrobního procesu.

Prostorové oddělení. Divize organizace jsou rozptýleny po prostoru a často mají špatně sjednocený software.

Konstrukční soulad. Software musí adekvátně odrážet informační strukturu podniku – odpovídat hlavním datovým tokům.

Zaměřte se na externí informace. Moderní podniky jsou nuceny věnovat zvýšenou pozornost práci se zákazníky. Podnikový software proto musí umět pracovat s novým typem uživatelů a jejich požadavky. Takoví uživatelé mají samozřejmě omezená práva a mají přístup k přesně definovanému typu dat.

Všechny uvedené požadavky na software podnikové úrovně splňují distribuované systémy - schéma rozdělení výpočtu je na Obr. 1.

Distribuované aplikace samozřejmě nejsou prosty nedostatků. Za prvé, jejich provoz je nákladný a za druhé, vytváření takových aplikací je pracný a složitý proces a náklady na chybu ve fázi návrhu jsou velmi vysoké. Vývoj distribuovaných aplikací se však úspěšně rozvíjí - koneckonců, hra stojí za svíčku, protože takový software pomáhá zvyšovat efektivitu organizace.

Paradigma distribuovaného počítání tedy předpokládá přítomnost několika center (serverů) pro ukládání a zpracování informací, implementaci různých funkcí a distribuci v prostoru. Kromě požadavků od systémových klientů musí tato centra plnit i vzájemné požadavky, protože v některých případech může být k vyřešení prvního úkolu nutné společné úsilí několika serverů. Pro správu složitých dotazů a fungování systému jako celku je zapotřebí specializovaný software pro správu. A nakonec celý systém musí být „ponořen“ do nějakého transportního média, které zajišťuje interakci jeho částí.

Distribuované výpočetní systémy mají takové obecné vlastnosti, jako jsou:

· ovladatelnost – znamená schopnost systému efektivně řídit jeho součásti. Toho je dosaženo použitím řídicího softwaru;

· výkon – zajištěný schopností přerozdělit zátěž na systémové servery pomocí softwaru pro správu;

· škálovatelnost – pokud je nutné fyzicky zvýšit produktivitu, distribuovaný systém může snadno integrovat nové výpočetní zdroje do svého transportního prostředí;

· rozšiřitelnost - do distribuovaných aplikací lze přidávat nové komponenty (serverový software) s novými funkcemi.

Přístup k datům v distribuovaných aplikacích je možný z klientského softwaru a další distribuované systémy mohou být organizovány na různých úrovních – od klientského softwaru a transportních protokolů až po ochranu databázových serverů.

Rýže. 2. Hlavní úrovně architektury distribuovaných aplikací

Uvedené vlastnosti distribuovaných systémů jsou dostatečným důvodem k tomu, abychom se smířili se složitostí jejich vývoje a vysokými náklady na údržbu.

Distribuovaná aplikační architektura

Podívejme se na architekturu distribuované aplikace, která jí umožňuje provádět složité a rozmanité funkce. Různé zdroje poskytují různé možnosti pro vytváření distribuovaných aplikací. A všichni mají právo na existenci, protože takové aplikace řeší širokou škálu problémů v mnoha tematických oblastech a nezadržitelný vývoj vývojových nástrojů a technologií tlačí k neustálému zlepšování.

Přesto existuje nejobecnější architektura distribuované aplikace, podle které je rozdělena do několika logických vrstev, úrovní zpracování dat. Aplikace, jak víte, jsou navrženy tak, aby zpracovávaly informace, a zde můžeme zdůraznit tři z jejich hlavních funkcí:

· prezentace dat (uživatelská úroveň). Zde si uživatelé aplikace mohou prohlédnout potřebná data, odeslat žádost o provedení, zadat nová data do systému nebo je upravit;

· zpracování dat (střední úroveň, middleware). Na této úrovni se koncentruje obchodní logika aplikace, řídí se datové toky a organizuje se interakce částí aplikace. Právě koncentrace všech funkcí zpracování a řízení dat na jedné úrovni je považována za hlavní výhodu distribuovaných aplikací;

· úložiště dat (datová vrstva). Toto je úroveň databázového serveru. Jsou zde umístěny samotné servery, databáze, nástroje pro přístup k datům a různé pomocné nástroje.

Tato architektura se často nazývá třívrstvá nebo třívrstvá. A velmi často na těchto „třích pilířích“ vzniká struktura vyvíjené aplikace. Vždy je třeba poznamenat, že každou úroveň lze dále rozdělit na několik podúrovní. Uživatelskou úroveň lze například rozdělit na samotné uživatelské rozhraní a pravidla pro ověřování a zpracování vstupních dat.

Samozřejmě, pokud vezmeme v úvahu možnost rozdělení do podúrovní, pak se do tříúrovňové architektury vejde jakákoli distribuovaná aplikace. Zde však nelze nevzít v úvahu ještě jednu charakteristickou vlastnost, která je distribuovaným aplikacím vlastní – správu dat. Důležitost této funkce je zřejmá, protože je velmi obtížné vytvořit skutečně běžící distribuovanou aplikaci (se všemi klientskými stanicemi, middleware, databázovými servery atd.), která by nezvládala své požadavky a odpovědi. Distribuovaná aplikace tedy musí mít ještě jednu logickou úroveň – úroveň správy dat.

Rýže. 3. Distribuce obchodní logiky mezi úrovněmi distribuované aplikace

Proto je vhodné rozdělit meziúroveň na dvě nezávislé úrovně: úroveň zpracování dat (jelikož je nutné vzít v úvahu důležitou výhodu, kterou to dává - koncentraci obchodních pravidel pro zpracování dat) a úroveň správy dat. Ten zajišťuje kontrolu nad prováděním požadavků, zpracovává datové toky a organizuje interakci částí systému.

Lze tedy rozlišit čtyři hlavní úrovně distribuované architektury (viz obr. 2):

· prezentace dat (uživatelská úroveň);

· pravidla obchodní logiky (úroveň zpracování dat);

· správa dat (úroveň správy dat);

· ukládání dat (úroveň ukládání dat).

Tři ze čtyř úrovní, s výjimkou první, se přímo podílejí na zpracování dat a úroveň prezentace dat umožňuje jejich vizualizaci a úpravu. Pomocí této vrstvy uživatelé přijímají data z vrstvy zpracování dat, která naopak získává informace z úložiště a provádí všechny potřebné transformace dat. Po zadání nových informací nebo úpravě stávajících informací proudí data opačným směrem: z uživatelského rozhraní přes vrstvu obchodních pravidel do skladu.

Další vrstva - správa dat - stojí stranou hlavního toku dat, ale zajišťuje hladké fungování celého systému správou požadavků a odpovědí a interakcí částí aplikace.

Samostatně je nutné zvážit možnost prohlížení dat v režimu pouze pro čtení. V tomto případě se vrstva zpracování dat nepoužívá v celkovém schématu přenosu dat, protože není třeba provádět žádné změny. A samotný tok informací je jednosměrný – od úložiště až po úroveň prezentace dat.

Fyzická struktura distribuovaných aplikací

Nyní se pojďme věnovat fyzickým vrstvám distribuovaných aplikací. Topologie distribuovaného systému zahrnuje rozdělení na několik databázových serverů, serverů pro zpracování dat a sadu lokálních a vzdálených klientů. Všechny mohou být umístěny kdekoli: ve stejné budově nebo na jiném kontinentu. V každém případě musí být části distribuovaného systému propojeny spolehlivými a bezpečnými komunikačními linkami. Co se týče rychlosti přenosu dat, ta do značné míry závisí na důležitosti propojení obou částí systému z hlediska zpracování a přenosu dat a v menší míře na jejich vzdálenosti.

Distribuce obchodní logiky napříč úrovněmi distribuované aplikace

Je čas přejít k podrobnému popisu úrovní distribuovaného systému, ale nejprve si řekněme pár slov o rozložení funkčnosti aplikace napříč úrovněmi. Obchodní logiku lze implementovat na kterékoli z úrovní třívrstvé architektury.

Databázové servery mohou nejen ukládat data do databází, ale také obsahovat část obchodní logiky aplikace v uložených procedurách, triggerech atd.

Klientské aplikace mohou také implementovat pravidla pro zpracování dat. Pokud je soubor pravidel minimální a sestává především z postupů kontroly správnosti zadávání dat, jedná se o „tenkého“ klienta. Na druhé straně tlustý klient obsahuje velkou část funkčnosti aplikace.

Úroveň zpracování dat je vlastně určena k implementaci obchodní logiky aplikace a jsou zde soustředěna všechna základní pravidla pro zpracování dat.

V obecném případě je tedy funkčnost aplikace „rozprostřena“ po celé aplikaci. Celá rozmanitost distribuce obchodní logiky napříč aplikačními úrovněmi může být reprezentována jako hladká křivka ukazující podíl pravidel zpracování dat soustředěných na konkrétním místě. Křivky na Obr. 3 jsou kvalitativní povahy, ale přesto nám umožňují vidět, jak mohou změny ve struktuře aplikace ovlivnit distribuci pravidel.

A praxe tento závěr potvrzuje. Koneckonců, vždy existuje několik pravidel, která je třeba implementovat speciálně do uložených procedur databázového serveru a velmi často je vhodné přenést některé počáteční operace s daty na stranu klienta - alespoň proto, aby se zabránilo zpracování nesprávných dotazů.

Vrstva prezentace dat

Úroveň prezentace dat je jediná dostupná pro koncového uživatele. Tato úroveň modeluje klientské pracovní stanice distribuované aplikace a odpovídající software. Možnosti klientské pracovní stanice jsou primárně určeny možnostmi operačního systému. V závislosti na typu uživatelského rozhraní je klientský software rozdělen do dvou skupin: klienti, kteří používají funkce grafického uživatelského rozhraní (například Windows) a weboví klienti. V každém případě však musí klientská aplikace poskytovat následující funkce:

· získávání dat;

· prezentace dat pro prohlížení uživatelem;

· editace dat;

· kontrola správnosti zadaných údajů;

· uložení provedených změn;

· Zpracování výjimek a zobrazování informací o chybách uživateli.

Je žádoucí soustředit všechna obchodní pravidla na úroveň zpracování dat, ale v praxi to není vždy možné. Poté hovoří o dvou typech klientského softwaru. „Tenký“ klient obsahuje minimální sadu obchodních pravidel, zatímco „tlustý“ klient implementuje významnou část aplikační logiky. V prvním případě se distribuovaná aplikace mnohem snadněji ladí, modernizuje a rozšiřuje, ve druhém lze minimalizovat náklady na vytvoření a údržbu vrstvy správy dat, protože některé operace lze provádět na straně klienta a pouze data; přenos padá na middleware.

Vrstva zpracování dat

Vrstva zpracování dat kombinuje části, které implementují obchodní logiku aplikace a působí jako prostředník mezi vrstvou prezentace dat a vrstvou ukládání dat. Veškerá data jím procházejí a procházejí v něm změnami kvůli řešenému problému (viz obr. 2). Funkce této úrovně zahrnují následující:

· zpracování datových toků v souladu s obchodními pravidly;

· interakce s prezentační vrstvou dat za účelem přijímání požadavků a vracení odpovědí;

· interakce s vrstvou úložiště dat pro přenos požadavků a přijímání odpovědí.

Nejčastěji je vrstva zpracování dat identifikována s middlewarem distribuované aplikace. Tato situace plně platí pro „ideální“ systém a pouze částečně pro reálné aplikace (viz obr. 3). Pokud jde o posledně jmenované, middleware pro ně obsahuje velký podíl pravidel pro zpracování dat, ale některá z nich jsou implementována na serverech SQL ve formě uložených procedur nebo triggerů a některá jsou součástí klientského softwaru.

Toto „rozostření“ obchodní logiky je oprávněné, protože nám umožňuje zjednodušit některé postupy zpracování dat. Vezměme si klasický příklad vystavení příkazu. Může obsahovat pouze názvy těch produktů, které jsou skladem. Při přidávání určité položky do objednávky a určování jejího množství je tedy nutné odečíst odpovídající číslo ze zůstatku této položky na skladě. Je zřejmé, že je nejlepší implementovat tuto logiku pomocí databázového serveru – uložené procedury nebo triggeru.

Vrstva správy dat

Vrstva správy dat je potřebná k zajištění toho, aby aplikace zůstala jedním celkem, byla stabilní a spolehlivá a měla schopnost modernizace a škálování. Zajišťuje provádění systémových úloh bez něj, části aplikace (databázové servery, aplikační servery, middleware, klienti) nebudou moci vzájemně interagovat a spojení přerušená při zvýšení zátěže nelze obnovit.

Kromě toho lze na vrstvě správy dat implementovat různé služby aplikačního systému. Vždy jsou totiž pro celou aplikaci společné funkce, které jsou nezbytné pro chod všech úrovní aplikace, nelze je tedy umístit na žádnou z dalších úrovní.

Například služba jednotného času poskytuje všem částem aplikace systémová časová razítka, která je udržují v synchronizaci. Představte si, že distribuovaná aplikace má server, který klientům posílá úkoly s konkrétním termínem pro jejich dokončení. Pokud je termín zmeškán, musí být úkol zaregistrován s vypočítanou dobou zpoždění. Pokud jsou klientské stanice umístěny ve stejné budově jako server nebo v sousední ulici, není problém, algoritmus účtování je jednoduchý. Co když se ale klienti nacházejí v jiných časových pásmech – v jiných zemích nebo dokonce v zámoří? V tomto případě musí být server schopen vypočítat rozdíly na základě časových pásem při odesílání úloh a přijímání odpovědí a klienti budou muset do sestav přidávat servisní informace o místním čase a časovém pásmu. Pokud distribuovaná aplikace obsahuje jednorázovou službu, pak tento problém jednoduše neexistuje.

Kromě služby jednotného času může vrstva správy dat obsahovat služby pro ukládání obecných informací (informace o aplikaci jako celku), generování obecných sestav atd.

Mezi funkce vrstvy správy dat tedy patří:

· správa částí distribuované aplikace;

· řízení spojení a komunikačních kanálů mezi částmi aplikace;

· řízení datových toků mezi klienty a servery a mezi servery;

· řízení zátěže;

· implementace služeb aplikačního systému.

Je třeba poznamenat, že vrstva správy dat je často vytvářena na základě hotových řešení dodávaných na softwarový trh různými výrobci. Pokud si vývojáři pro svou aplikaci zvolili architekturu CORBA, pak zahrnuje zprostředkovatele objektových požadavků (ORB), pokud je platformou Windows, mají k dispozici řadu nástrojů: technologii COM+ (vývoj Microsoft Transaction Server, technologie MTS ), technologie zpracování front zpráv MSMQ, technologie Microsoft BizTalk atd.

Úroveň ukládání dat

Vrstva úložiště dat kombinuje SQL servery a databáze používané aplikací. Poskytuje řešení pro následující úkoly:

· ukládání dat do databáze a jejich udržování v provozuschopném stavu;

· zpracování požadavků na úrovni zpracování dat a vracení výsledků;

· implementace části obchodní logiky distribuované aplikace;

· správa distribuovaných databází pomocí administrativních nástrojů databázových serverů.

Kromě samozřejmých funkcí – ukládání dat a zpracování dotazů, může úroveň obsahovat část obchodní logiky aplikace v uložených procedurách, triggerech, omezeních atd. A samotná struktura databáze aplikace (tabulky a jejich pole, indexy, cizí klíče, atd.) ) dochází k implementaci datové struktury, se kterou distribuovaná aplikace pracuje, a implementaci některých pravidel obchodní logiky. Například použití cizího klíče v databázové tabulce vyžaduje vytvoření odpovídajícího omezení pro manipulaci s daty, protože záznamy v hlavní tabulce nelze smazat, pokud existují odpovídající záznamy propojené cizím klíčem tabulky.

Většina databázových serverů podporuje různé administrativní procedury, včetně správy distribuovaných databází. Patří mezi ně replikace dat, vzdálená archivace, nástroje pro přístup ke vzdáleným databázím atd. Možnost využití těchto nástrojů je třeba vzít v úvahu při vývoji struktury vlastní distribuované aplikace.

Připojení k databázím SQL serveru se provádí především pomocí klientského softwaru serveru. Navíc lze dodatečně využít různé technologie pro přístup k datům, například ADO (ActiveX Data Objects) nebo ADO.NET. Při návrhu systému je ale nutné vzít v úvahu, že funkčně zprostředkující technologie přístupu k datům nepatří do vrstvy ukládání dat.

Rozšíření základní úrovně

Výše uvedené úrovně architektury distribuovaných aplikací jsou základní. Tvoří strukturu vytvářené aplikace jako celek, ale zároveň přirozeně nemohou zajistit implementaci jakékoli aplikace - tematické oblasti a úkoly jsou příliš rozsáhlé a různorodé. Pro takové případy lze architekturu distribuované aplikace rozšířit o další vrstvy, které jsou navrženy tak, aby odrážely vlastnosti vytvářené aplikace.

Mimo jiné jsou zde dvě nejpoužívanější rozšíření základních úrovní.

Vrstva obchodního rozhraní se nachází mezi vrstvou uživatelského rozhraní a vrstvou zpracování dat. Skrývá detaily struktury a implementace obchodních pravidel vrstvy zpracování dat před klientskými aplikacemi a zajišťuje, že programový kód klientských aplikací je abstrahován od implementačních prvků aplikační logiky.

Výsledkem je, že vývojáři klientských aplikací používají určitou sadu nezbytných funkcí - analog aplikačního programovacího rozhraní (API). To umožňuje, aby byl klientský software nezávislý na implementaci vrstvy zpracování dat.

Při provádění velkých změn v systému se to samozřejmě neobejde bez globálních změn, ale úroveň obchodního rozhraní vám to umožňuje, pokud to není nezbytně nutné.

Vrstva pro přístup k datům se nachází mezi vrstvou ukládání dat a vrstvou zpracování dat. Umožňuje vytvořit strukturu aplikace nezávislou na konkrétní technologii ukládání dat. V takových případech softwarové objekty na úrovni zpracování dat přenášejí požadavky a přijímají odpovědi pomocí zvolené technologie přístupu k datům.

Při implementaci aplikací na platformě Windows se nejčastěji používá technologie ADO pro přístup k datům, protože poskytuje univerzální způsob přístupu k široké škále datových zdrojů – od SQL serverů po tabulky. Pro aplikace na platformě .NET se používá technologie ADO.NET.

Open source software se stal základním stavebním kamenem při vytváření některých z největších světových webových stránek. S růstem těchto webových stránek se objevily osvědčené postupy a pokyny pro jejich architekturu. Tato kapitola si klade za cíl pokrýt některé z klíčových problémů, které je třeba vzít v úvahu při navrhování velkých webových stránek, a také některé základní komponenty používané k dosažení těchto cílů.

Tato kapitola se zaměřuje na analýzu webových systémů, i když některé materiály mohou být extrapolovány na jiné distribuované systémy.

1.1 Principy budování distribuovaných webových systémů

Co přesně znamená vytvořit a spravovat škálovatelný web nebo aplikaci? Na primitivní úrovni je to prostě připojení uživatelů ke vzdáleným zdrojům přes internet. A zdroje nebo přístup k těmto zdrojům, které jsou distribuovány na mnoha serverech a jsou odkazem, který zajišťuje škálovatelnost webu.

Jako většina věcí v životě může čas strávený předem plánováním sestavení webové služby pomoci později; Pochopení některých úvah a kompromisů za velkými weby může přinést chytřejší rozhodnutí při vytváření menších webů. Níže jsou uvedeny některé klíčové principy, které ovlivňují návrh rozsáhlých webových systémů:

• Dostupnost: Dostupnost webových stránek je zásadní pro pověst a funkčnost mnoha společností. U některých větších online prodejců může být nedostupnost byť jen několik minut za následek ztrátu příjmů v tisících nebo milionech dolarů. Vývoj jejich systémů tak, aby byly vždy dostupné a odolné vůči selhání, je tedy základním obchodním i technologickým požadavkem. Vysoká dostupnost v distribuovaných systémech vyžaduje pečlivé zvážení redundance pro klíčové komponenty, rychlé zotavení z dílčích selhání systému a hladké omezování schopností, když nastanou problémy.
• Výkon: Výkonnost webových stránek se stala důležitou metrikou pro většinu webových stránek. Rychlost webu ovlivňuje uživatelskou zkušenost a spokojenost, stejně jako hodnocení ve vyhledávačích – faktor, který přímo ovlivňuje udržení publika a příjmy. Ve výsledku je klíčové vytvořit systém, který je optimalizován pro rychlé reakce a nízkou latenci.
• Spolehlivost: systém musí být spolehlivý, aby daný požadavek na data konzistentně vracel specifikovaná data. V případě změny nebo aktualizace údajů by měl stejný požadavek vrátit nové údaje. Uživatelé potřebují vědět, že pokud je něco zaznamenáno nebo uloženo v systému, mohou si být jisti, že to zůstane na místě pro pozdější vyhledání.
• Škálovatelnost: Pokud jde o jakýkoli velký distribuovaný systém, velikost je pouze jedna položka na seznamu, kterou je třeba vzít v úvahu. Neméně důležité jsou snahy o zvýšení propustnosti pro zvládnutí velkých objemů zátěže, což se obvykle označuje jako škálovatelnost systému. Škálovatelnost může odkazovat na různé parametry systému: množství dodatečného provozu, který dokáže zpracovat, jak snadné je přidat úložnou kapacitu nebo kolik dalších transakcí lze zpracovat.
• ovladatelnost: Dalším důležitým faktorem je navržení systému, který se snadno ovládá. Spravovatelnost systému se rovná škálovatelnosti operací „údržby“ a „aktualizace“ Pro zajištění spravovatelnosti je nutné vzít v úvahu snadnost diagnostiky a pochopení vznikajících problémů, snadnost aktualizace nebo úpravy a snadnost použití systému. (To znamená, že funguje podle očekávání bez selhání nebo výjimek?)
• Cena: Cena je důležitým faktorem. To může samozřejmě zahrnovat náklady na hardware a software, ale je také důležité zvážit další aspekty potřebné k nasazení a údržbě systému. Musí být zajištěno množství vývojářského času potřebného k sestavení systému, množství provozního úsilí potřebného k uvedení systému do provozu a dokonce i odpovídající úroveň školení. Náklady představují celkové náklady na vlastnictví.

Každý z těchto principů poskytuje základ pro rozhodování při návrhu distribuované webové architektury. Mohou však být i ve vzájemném konfliktu, protože dosažení cílů jednoho jde na úkor zanedbávání druhého. Jednoduchý příklad: volba jednoduchého přidání několika serverů jako řešení výkonu (škálovatelnosti) může zvýšit náklady na správu (musíte provozovat další server) a nákupy serverů.

Při vývoji jakékoli webové aplikace je důležité vzít v úvahu tyto klíčové principy, i když to má potvrdit, že projekt může obětovat jeden nebo více z nich.

1.2 Základy

Při zvažování architektury systému je třeba vyřešit několik problémů, například které komponenty se vyplatí používat, jak do sebe zapadají a jaké kompromisy lze udělat. Investování peněz do škálování bez jasné potřeby není chytré obchodní rozhodnutí. Určitá předvídavost při plánování však může v budoucnu ušetřit značný čas a zdroje.

Tato část se zaměřuje na některé základní faktory, které jsou kritické pro téměř všechny velké webové aplikace: Služby,
nadbytek, segmentace, A řešení poruch. Každý z těchto faktorů zahrnuje volby a kompromisy, zejména v kontextu zásad popsaných v předchozí části. Pro upřesnění uveďme příklad.

Příklad: Aplikace pro hostování obrázků

Pravděpodobně jste již někdy zveřejnili obrázky online. Pro velké weby, které ukládají a doručují mnoho obrázků, existují problémy s vytvořením nákladově efektivní, vysoce spolehlivé architektury, která má nízké latence odezvy (rychlé načítání).

Představte si systém, kde mají uživatelé možnost nahrávat své obrázky na centrální server a kde lze obrázky vyžadovat prostřednictvím odkazu na web nebo rozhraní API, podobně jako Flickr nebo Picasa. Pro zjednodušení popisu předpokládejme, že tato aplikace má dva hlavní úkoly: schopnost nahrávat (zapisovat) obrázky na server a vyžadovat obrázky. Efektivní načítání je samozřejmě důležitým kritériem, ale prioritou bude rychlé doručení na žádost uživatelů (například obrázky mohou být požadovány pro zobrazení na webové stránce nebo jinou aplikací). Tato funkce je podobná té, kterou může poskytnout webový server nebo okrajový server CDN (Content Delivery Network). Server CDN obvykle ukládá datové objekty na více místech, čímž je přibližuje geograficky/fyzicky blíže uživatelům, což vede ke zlepšení výkonu.

Další důležité aspekty systému:

• Počet uložených obrázků může být neomezený, takže z tohoto hlediska je třeba zvážit škálovatelnost úložiště.
• Stahování/požadavky obrázků by mělo mít nízkou latenci.
• Pokud uživatel nahraje obrázek na server, jeho data musí vždy zůstat nedotčená a přístupná.
• Systém musí být snadno udržovatelný (spravovatelný).
• Vzhledem k tomu, že hostování obrázků negeneruje velké zisky, systém musí být nákladově efektivní.

Dalším potenciálním problémem tohoto návrhu je, že webový server, jako je Apache nebo lighttpd, má obvykle horní limit počtu současných připojení, který je schopen obsluhovat (výchozí hodnota je přibližně 500, ale může být mnohem vyšší) a s vysokým provozem. , nahrávky mohou tento limit rychle vyčerpat. Vzhledem k tomu, že čtení může být asynchronní nebo může využívat jiné optimalizace výkonu, jako je komprese gzip nebo chunking, může webový server přepínat čtení zdrojů rychleji a přepínat mezi klienty a přitom obsluhovat mnohem více požadavků, než je maximální počet připojení (s Apache a s maximálním počtem připojení nastaveno na 500, je docela možné obsloužit několik tisíc požadavků na čtení za sekundu). Záznamy na druhou stranu mají tendenci udržovat připojení otevřené po celou dobu stahování. Přenos souboru o velikosti 1 MB na server tedy může ve většině domácích sítí trvat déle než 1 sekundu, takže webový server je schopen zpracovat pouze 500 těchto záznamů současně.

Obrázek 1.2: Oddělení čtení/zápisu

Předvídání tohoto potenciálního problému naznačuje potřebu oddělit čtení a zápis obrázků do nezávislých služeb, jak je znázorněno v . To nám umožní nejen škálovat každou z nich jednotlivě (protože je pravděpodobné, že vždy budeme provádět více čtení než zápisů), ale také si být vědomi toho, co se děje v každé službě. Konečně rozliší problémy, které mohou v budoucnu nastat, a usnadní tak diagnostiku a vyhodnocení problému pomalého přístupu ke čtení.

Výhodou tohoto přístupu je, že jsme schopni řešit problémy nezávisle na sobě – aniž bychom se museli starat o nahrávání a načítání nových snímků ve stejném kontextu. Obě tyto služby stále používají globální korpus obrázků, ale pomocí technik specifických pro službu jsou schopny optimalizovat svůj vlastní výkon (například řazením požadavků do fronty nebo ukládáním oblíbených obrázků do mezipaměti – více o tom později). Z hlediska služeb i nákladů lze každou službu škálovat nezávisle podle potřeby. A to je pozitivní věc, protože jejich kombinování a míchání by mohlo neúmyslně ovlivnit jejich výkon, jako ve scénáři popsaném výše.

Výše uvedený model bude samozřejmě fungovat optimálně, pokud existují dva různé koncové body (ve skutečnosti je to velmi podobné několika implementacím poskytovatelů cloudových úložišť a sítí pro doručování obsahu). Existuje mnoho způsobů, jak takové problémy vyřešit, a v každém případě lze najít kompromis.

Flickr například řeší tento problém čtení a zápisu rozdělením uživatelů mezi různé moduly tak, že každý modul může sloužit pouze omezenému počtu konkrétních uživatelů, a jak se počet uživatelů zvyšuje, do clusteru se přidávají další moduly (viz prezentace škálování na Flickru ,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). V prvním příkladu je snazší škálovat hardware na základě skutečného využití (počet čtení a zápisů v celém systému), zatímco Flickr se škáluje na základě uživatelské základny (to však předpokládá stejné využití napříč uživateli, takže kapacita nutno naplánovat podle zásob). V minulosti by nedostupnost nebo problém s některou ze služeb narušila funkčnost celého systému (například nikdo nemohl zapisovat soubory), nedostupnost jednoho z modulů Flickru by se pak dotkla pouze uživatelů s ním spojených. V prvním příkladu je snazší provádět operace na celém souboru dat – například aktualizovat záznamovou službu tak, aby zahrnovala nová metadata, nebo prohledávat všechna metadata obrázků – zatímco s architekturou Flickr musel být každý modul aktualizován nebo prohledán ( nebo musela být vytvořena vyhledávací služba pro třídění metadat, která jsou k tomuto účelu skutečně určena).

Pokud jde o tyto systémy, neexistuje žádný všelék, ale vždy byste měli vycházet ze zásad popsaných na začátku této kapitoly: určit potřeby systému (zatížení čtení nebo zápisu nebo obojí, úroveň paralelismu, dotazy na datové sady, rozsahy, řazení, atd.), provádět srovnávací srovnávací testy různých alternativ, porozumět podmínkám potenciálního selhání systému a vypracovat komplexní plán, pokud dojde k selhání.

Nadbytek

Aby mohla webová architektura elegantně zvládnout selhání, musí mít redundanci ve svých službách a datech. Pokud je například na jednom serveru uložena pouze jedna kopie souboru, ztráta tohoto serveru bude znamenat ztrátu souboru. Je nepravděpodobné, že by to byla pozitivní situace a obvykle se tomu lze vyhnout vytvořením více kopií nebo záloh.

Stejný princip platí pro služby. Proti selhání jednoho uzlu se můžete chránit tím, že poskytnete nedílnou součást funkčnosti aplikace, abyste zajistili, že více kopií nebo verzí může běžet současně.

Vytvoření redundance v systému vám umožní zbavit se slabých míst a poskytnout záložní nebo redundantní funkcionalitu v případě nouze. Pokud například v produkci běží dvě instance stejné služby a jedna z nich zcela nebo částečně selže, systém může selhání překonat přechod na pracovní kopii.
Přepínání může probíhat automaticky nebo může vyžadovat ruční zásah.

.

Další klíčovou úlohou redundance služby je vytvořit architektura, která neumožňuje sdílení zdrojů. S touto architekturou je každý uzel schopen fungovat samostatně a navíc v nepřítomnosti centrálního „mozku“, který by spravoval stavy nebo koordinoval akce ostatních uzlů. Podporuje škálovatelnost, protože přidávání nových uzlů nevyžaduje zvláštní podmínky nebo znalosti. A co je nejdůležitější, tyto systémy nemají žádný kritický bod selhání, díky čemuž jsou mnohem odolnější vůči selhání.

.

Například v naší aplikaci obrazového serveru by všechny obrázky měly redundantní kopie někde v jiném hardwaru (ideálně v jiné geografické lokalitě v případě katastrofy, jako je zemětřesení nebo požár v datovém centru), a služby by přístup k obrázkům bude nadbytečný, protože všechny budou potenciálně sloužit požadavkům. (Cm. .)
Při pohledu do budoucna jsou load balancery skvělým způsobem, jak to umožnit, ale o tom níže.

Obrázek 1.3: Redundantní aplikace pro hostování obrázků

Segmentace

Datové sady mohou být tak velké, že je nelze umístit na jeden server. Může se také stát, že výpočetní operace vyžadují příliš mnoho počítačových zdrojů, což snižuje výkon a vyžaduje zvýšený výkon. V každém případě máte dvě možnosti: vertikální nebo horizontální měřítko.

Vertikální škálování zahrnuje přidání více zdrojů na jeden server. U velmi velké datové sady by to tedy znamenalo přidání více (nebo větších) pevných disků, aby se celá datová sada vešla na jeden server. V případě výpočetních operací by to znamenalo přesunout výpočet na větší server s rychlejším CPU nebo větší pamětí. V každém případě se vertikální škálování provádí, aby byl jediný výpočetní systémový zdroj schopný dalšího zpracování dat.

Horizontální škálování na druhé straně zahrnuje přidání více uzlů. V případě velkého souboru dat by to znamenalo přidání druhého serveru pro uložení části celkového objemu dat a pro výpočetní zdroj by to znamenalo rozdělení práce nebo zátěže mezi některé další uzly. Aby bylo možné plně využít potenciál horizontálního škálování, musí být implementováno jako vnitřní princip návrhu systémové architektury. Jinak může být změna a izolace kontextu potřebného pro horizontální měřítko problematická.

Nejběžnější metodou horizontálního škálování je rozdělení služeb do segmentů nebo modulů. Mohou být distribuovány takovým způsobem, že každá logická sada funkcí funguje samostatně. Toho lze dosáhnout geografickými hranicemi nebo jinými kritérii, jako jsou platící a neplatící uživatelé. Výhodou těchto schémat je, že poskytují službu nebo úložiště dat s rozšířenou funkčností.

V našem příkladu obrazového serveru je možné, že jediný souborový server používaný k uložení obrazu by mohl být nahrazen několika souborovými servery, z nichž každý obsahuje svou vlastní jedinečnou sadu obrazů. (Viz.) Tato architektura by umožnila systému zaplnit každý souborový server obrazy a přidávat další servery, jakmile se místo na disku zaplní. Návrh bude vyžadovat schéma pojmenování, které spojuje název souboru obrázku se serverem, který jej obsahuje. Název obrázku lze vygenerovat z konzistentního hašovacího schématu vázaného na servery. Alternativně by každý obrázek mohl mít přírůstkové ID, které by doručovací službě umožnilo při vyžádání obrázku zpracovat pouze rozsah ID přidružených ke každému serveru (jako index).

Obrázek 1.4: Aplikace pro hostování obrázků s redundancí a segmentací

Samozřejmě existují potíže s distribucí dat nebo funkcí napříč mnoha servery. Jednou z klíčových otázek je umístění dat; V distribuovaných systémech platí, že čím blíže jsou data k operaci nebo výpočetnímu bodu, tím lepší je výkon systému. V důsledku toho je distribuce dat mezi více servery potenciálně problematická, protože kdykoli mohou být data potřebná, existuje riziko, že nemusí být dostupná na požadovaném místě, server bude muset provést nákladné získávání potřebných informací přes síť.

Další potenciální problém vzniká ve formě
nedůslednost (nesoulad) Když různé služby čtou a zapisují do sdíleného prostředku, potenciálně do jiné služby nebo úložiště dat, je možné, že dojde k „závodním podmínkám“ – kdy se některá data považují za aktualizovaná na nejnovější stav, ale ve skutečnosti jsou čtena před aktualizací. - v takovém případě jsou údaje nekonzistentní. Například ve scénáři hostování obrázku může dojít k konfliktu, pokud jeden klient odešle požadavek na aktualizaci obrázku psa a změní název „Pes“ na „Gizmo“, zatímco jiný klient obrázek čte. V takové situaci není jasné, jaký titul, „Pes“ nebo „Gizmo“, by získal druhý klient.

.

S segmentací dat jsou samozřejmě spojeny určité překážky, ale segmentace vám umožňuje izolovat každý problém od ostatních: podle dat, podle zatížení, podle vzorců používání atd. do spravovaných bloků. To může pomoci se škálovatelností a spravovatelností, ale stále existuje riziko. Existuje mnoho způsobů, jak snížit riziko a zvládnout selhání; v zájmu stručnosti však nejsou zahrnuty v této kapitole. Pokud chcete více informací o tomto tématu, měli byste se podívat na blogový příspěvek o odolnosti proti chybám a monitorování.

1.3. Stavební bloky pro rychlý a škálovatelný přístup k datům

Když jsme se podívali na některé základní principy vývoje distribuovaných systémů, přejděme nyní ke složitějšímu problému – škálování přístupu k datům.

Nejjednodušší webové aplikace, jako jsou aplikace zásobníku LAMP, jsou podobné obrázku v .

Obrázek 1.5: Jednoduché webové aplikace

Jak aplikace roste, vyvstávají dvě hlavní výzvy: škálování přístupu k aplikačnímu serveru ak databázi. Ve vysoce škálovatelném návrhu aplikací je web nebo aplikační server obvykle minimalizován a často implementuje architekturu sdílení prostředků. Díky tomu je vrstva aplikačního serveru systému horizontálně škálovatelná. V důsledku tohoto návrhu se těžké břemeno přesune dolů na databázový server a podpůrné služby; Tato vrstva je místem, kde do hry vstupují skutečné problémy se škálováním a výkonem.

Zbytek této kapitoly pokrývá některé z nejběžnějších strategií a technik pro zlepšení výkonu a škálovatelnosti těchto typů služeb poskytováním rychlého přístupu k datům.

Obrázek 1.6: Zjednodušená webová aplikace

Většinu systémů lze zjednodušit na obvodový vstup
což je dobré místo, kde začít hledat. Máte-li mnoho dat, můžete s jistotou předpokládat, že k nim chcete mít snadný a rychlý přístup jako bonboniéra v horní zásuvce vašeho stolu. Přestože je toto srovnání příliš zjednodušující, upozorňuje na dva složité problémy: škálovatelnost úložiště dat a rychlý přístup k datům.

Pro účely této části předpokládejme, že máte mnoho terabajtů (TB) dat a umožňujete uživatelům přístup k malým částem těchto dat v náhodném pořadí. (Cm. .)
Podobným úkolem je určit umístění souboru obrázku někde na souborovém serveru ve vzorové aplikaci pro hostování obrázků.

Obrázek 1.7: Přístup ke konkrétním datům

To je obzvláště obtížné, protože načítání terabajtů dat do paměti může být velmi drahé a má přímý dopad na vstup a výstup disku. Rychlost čtení z disku je několikanásobně nižší než rychlost čtení z RAM - lze říci, že přístup k paměti je rychlý jako Chuck Norris, zatímco přístup na disk je pomalejší než fronta na klinice. Tento rozdíl v rychlosti je zvláště patrný u velkých souborů dat; V nezpracovaných číslech je přístup do paměti 6krát rychlejší než čtení z disku u sekvenčního čtení a 100 000krát rychlejší u náhodného čtení (viz Pathologies of Big Data, http://queue.acm.org/detail. cfm?id=1563874). ). Navíc i s jedinečnými identifikátory může být řešení problému s nalezením malého kousku dat stejně obtížné, jako pokusit se vybrat poslední bonbón plněný čokoládou z krabice stovek dalších bonbónů, aniž byste se podívali.

Naštěstí existuje mnoho přístupů, které lze použít ke zjednodušení, přičemž čtyři nejdůležitější přístupy jsou použití mezipaměti, proxy, indexů a vyvažovačů zatížení. Zbytek této části pojednává o tom, jak lze každý z těchto konceptů použít k mnohem rychlejšímu přístupu k datům.

Mezipaměti

Ukládání do mezipaměti těží z charakteristiky základního principu: nedávno požadovaná data budou pravděpodobně znovu potřeba. Mezipaměti se používají téměř na všech úrovních výpočetní techniky: hardware, operační systémy, webové prohlížeče, webové aplikace a další. Mezipaměť je jako krátkodobá paměť: má omezenou velikost, ale je rychlejší než původní zdroj dat a obsahuje položky, ke kterým se nedávno přistupovalo. Mezipaměti mohou existovat na všech úrovních architektury, ale často se nacházejí na úrovni nejblíže frontendu, kde jsou implementovány tak, aby rychle vracely data bez významného zatížení backendu.

Jak tedy lze mezipaměť použít k urychlení přístupu k datům v našem vzorovém rozhraní API? V tomto případě existuje několik vhodných umístění keší. Jednou z možných možností umístění je výběr uzlů na úrovni dotazu, jak je znázorněno na
.

Obrázek 1.8: Umístění mezipaměti na uzlu na úrovni dotazu

Umístění mezipaměti přímo na uzel na úrovni požadavku umožňuje místní ukládání dat odpovědí. Pokaždé, když je učiněn požadavek na službu, uzel rychle vrátí místní data uložená v mezipaměti, pokud existují. Pokud není v mezipaměti, uzel požadavku si vyžádá data z disku. Mezipaměť na jednom uzlu na úrovni dotazu může být také umístěna buď v paměti (což je velmi rychlé) nebo na místním disku uzlu (rychlejší než pokus o přístup k síťovému úložišti).

Obrázek 1.9: Systémy mezipaměti

Co se stane, když rozložíte ukládání do mezipaměti mezi mnoho uzlů? Jak vidíte, pokud vrstva dotazu obsahuje mnoho uzlů, pak je pravděpodobné, že každý uzel bude mít svou vlastní mezipaměť. Pokud však váš nástroj pro vyrovnávání zatížení náhodně rozděluje požadavky mezi uzly, pak stejný požadavek poputuje do různých uzlů, čímž se zvýší počet chyb v mezipaměti. Dva způsoby, jak překonat tuto překážku, jsou globální a distribuované cache.

Globální mezipaměť

Význam globální mezipaměti je jasný již z názvu: všechny uzly sdílejí jeden jediný mezipaměť. V tomto případě přidáte server nebo úložiště souborů nějakého druhu, které je rychlejší než vaše původní úložiště a které bude dostupné všem uzlům na úrovni požadavků. Každý z uzlů požadavku se dotazuje na mezipaměť stejným způsobem, jako by byla místní. Tento typ schématu ukládání do mezipaměti může způsobit určité problémy, protože jedna mezipaměť může být velmi snadno přetížena, pokud se zvýší počet klientů a požadavků. Zároveň je toto schéma velmi efektivní v určitých architekturách (zejména těch, které jsou spojeny se specializovaným hardwarem, díky kterému je tato globální mezipaměť velmi rychlá, nebo která má pevnou sadu dat, která se musí ukládat do mezipaměti).

Na obrázcích jsou dvě standardní formy globálních keší. Ukázaná situace je taková, že když odpověď uložená v mezipaměti není nalezena v mezipaměti, mezipaměť sama přebírá odpovědnost za získání chybějící části dat ze základního úložiště. Ilustrováno je odpovědnost uzlů požadavku načíst všechna data, která nejsou nalezena v mezipaměti.

Obrázek 1.10: Globální cache, kde cache zodpovídá za načítání

Obrázek 1.11: Globální mezipaměť, kde jsou za získávání odpovědné uzly požadavků

Většina aplikací, které využívají globální mezipaměti, má tendenci používat první typ, kde mezipaměť sama spravuje nahrazování a načítání dat, aby zabránila klientům zahlcovat požadavky na stejná data. Existují však případy, kdy druhá implementace dává větší smysl. Pokud se například mezipaměť používá pro velmi velké soubory, nízká četnost přístupů mezipaměti způsobí, že se mezipaměť vyrovnávací paměti přetíží neúspěšnými přístupy do mezipaměti; v této situaci pomáhá mít velké procento z celkové datové sady (nebo horké datové sady) v mezipaměti. Dalším příkladem je architektura, kde jsou soubory uložené v mezipaměti statické a neměly by být mazány. (Může k tomu dojít kvůli základním charakteristikám výkonu, pokud jde o takovou latenci dat – možná musí být určité části dat velmi rychlé pro velké datové sady – kde aplikační logika rozumí strategii výměny nebo aktivním bodům lépe než mezipaměť.)

Distribuovaná mezipaměť

Tyto indexy jsou často uloženy v paměti nebo někde velmi lokálně vzhledem k příchozímu požadavku klienta. Berkeley DB (BDB) a stromové datové struktury, které se obvykle používají k ukládání dat v uspořádaných seznamech, jsou ideální pro indexovaný přístup.

Často existuje mnoho vrstev indexů, které fungují jako mapa, přesouvají vás z jednoho místa na druhé a tak dále, dokud nezískáte potřebná data. (Cm. )

Obrázek 1.17: Víceúrovňové indexy

Indexy lze také použít k vytvoření více dalších pohledů na stejná data. Pro velké soubory dat je to skvělý způsob, jak definovat různé filtry a zobrazení, aniž byste museli vytvářet mnoho dalších kopií dat.

Řekněme například, že výše zmíněný systém pro hostování obrázků skutečně hostí obrázky stránek knihy a služba umožňuje klientům dotazovat se na text v těchto obrázcích a vyhledávat veškerý textový obsah na dané téma stejným způsobem, jaký vám umožňují vyhledávače. pro vyhledávání obsahu HTML. V tomto případě všechny tyto obrázky knih používají k ukládání souborů tolik serverů a najít jedinou stránku, kterou by uživatel mohl prezentovat, může být docela obtížné. Zpočátku by měly být snadno dostupné reverzní indexy pro dotazování na libovolná slova a sady slov; pak je tu úkol přejít na přesnou stránku a umístění v této knize a získat správný obrázek pro výsledky vyhledávání. Takže v tomto případě by se obrácený rejstřík namapoval na umístění (jako je kniha B) a pak by B mohlo obsahovat rejstřík se všemi slovy, umístěními a počtem výskytů v každé části.

Invertovaný rejstřík, který by Index1 mohl zobrazit ve výše uvedeném diagramu, by vypadal asi takto: Každé slovo nebo sada slov slouží jako rejstřík pro knihy, které je obsahují.

Mezilehlý index bude vypadat podobně, ale bude obsahovat pouze slova, umístění a informace pro knihu B. Tato vrstvená architektura umožňuje každému indexu zabírat méně místa, než kdyby byly všechny tyto informace uloženy v jednom velkém invertovaném indexu.

A to je klíčový bod ve velkých systémech, protože i když jsou komprimované, mohou být tyto indexy poměrně velké a drahé na skladování. Předpokládejme, že v tomto systému máme mnoho knih z celého světa – 100 000 000 (viz blogový příspěvek „Inside Google Books“) – a že každá kniha má pouze 10 stránek (pro zjednodušení výpočtů) s 250 slovy na stránku: máme celkem 250 miliard slov. Pokud vezmeme průměrný počet znaků ve slově na 5 a zakódujeme každý znak 8 bity (nebo 1 bajtem, i když některé znaky ve skutečnosti zabírají 2 bajty), čímž utratíme 5 bajtů na slovo, pak index obsahující každý slovo pouze jednou by vyžadovalo více než 1 terabajt úložiště. Můžete tedy vidět, že indexy, které obsahují také další informace, jako jsou sady slov, umístění dat a počty použití, mohou velmi rychle narůstat.

Vytváření takových přechodných indexů a prezentace dat v menších částech usnadňuje řešení problému velkých dat. Data lze distribuovat na více serverů a zároveň být rychle dostupná. Indexy jsou základním kamenem vyhledávání informací a základem pro dnešní moderní vyhledávače. Samozřejmě, že tato část pouze poškrábe povrch tématu indexování a bylo provedeno mnoho výzkumů, jak indexy zmenšit, zrychlit, obsahovat více informací (např. relevance) a snadno je aktualizovat. (Existují určité problémy se správou konkurenčních podmínek a také s počtem aktualizací potřebných k přidání nových dat nebo změně existujících dat, zejména pokud jde o relevanci nebo bodování).

Umět rychle a snadno najít svá data je důležitá a indexy jsou tím nejjednodušším a nejúčinnějším nástrojem k dosažení tohoto cíle.

Load Balancery

A konečně další kritickou součástí každého distribuovaného systému je load balancer. Nástroje pro vyrovnávání zátěže jsou základní součástí jakékoli architektury, protože jejich úlohou je rozdělovat zátěž mezi uzly odpovědné za obsluhu požadavků. To umožňuje více uzlům transparentně obsluhovat stejnou funkci v systému. (Viz.) Jejich hlavním účelem je zpracovat mnoho současných připojení a směrovat tato připojení k jednomu z požadovaných uzlů, což umožňuje systému škálovat pouhým přidáním uzlů, aby obsluhoval více požadavků.

Obrázek 1.18: Load Balancer

Existuje mnoho různých algoritmů pro obsluhu požadavků, včetně náhodného výběru uzlů, kruhového vyhodnocení nebo dokonce výběru uzlů na základě určitých kritérií, jako je využití CPU nebo RAM. Load balancery mohou být implementovány jako hardwarová zařízení nebo software. Mezi nástroji pro vyrovnávání zatížení open source softwaru je nejpoužívanější HAProxy.

V distribuovaném systému jsou load balancery často umístěny na „přední hraně“ systému, takže všechny příchozí požadavky procházejí přímo jimi. Je velmi pravděpodobné, že ve složitém distribuovaném systému bude muset požadavek projít několika balancéry, jak je znázorněno na
.

Obrázek 1.19: Vícenásobné load balancery

Podobně jako servery proxy mohou některé nástroje pro vyrovnávání zatížení také směrovat požadavky odlišně v závislosti na typu požadavku. Jsou také známé jako reverzní proxy.

Správa dat specifických pro konkrétní uživatelskou relaci je jednou z výzev při používání nástrojů pro vyrovnávání zatížení. Na webu elektronického obchodu, kdy máte pouze jednoho zákazníka, je velmi snadné umožnit uživatelům vkládat položky do košíku a ukládat obsah mezi návštěvami (to je důležité, protože pravděpodobnost prodeje položky se výrazně zvyšuje, pokud uživatel vrátí na stránku, produkt je stále v košíku). Pokud je však uživatel při první návštěvě přesměrován na jeden web a při další návštěvě na jiný web, může dojít k nesrovnalostem, protože nový web nemusí znát obsah nákupního košíku daného uživatele. (Nerozčilovalo by vás, kdybyste si do košíku vložili balíček Mountain Dew a ten tam nebyl, když jste se vrátili?) Jedním z řešení by mohlo být udělat relace „přilepené“, aby byl uživatel vždy přesměrován na totéž uzel. Využití některých funkcí spolehlivosti, jako je automatické převzetí služeb při selhání, však bude výrazně obtížné. V tomto případě bude uživatelův košík vždy obsahovat obsah, ale pokud se jeho lepivý uzel stane nepřístupným, bude zapotřebí speciální přístup a předpoklad o obsahu košíku již nebude pravdivý (i když doufejme, že tento předpoklad nebude zabudován do Aplikace). Tento problém lze samozřejmě vyřešit pomocí jiných strategií a nástrojů, jako jsou ty popsané v této kapitole, jako jsou služby a mnoho dalších (jako jsou mezipaměti prohlížeče, soubory cookie a přepisování URL).

Pokud má systém jen několik uzlů, pak budou techniky jako DNS karusel pravděpodobně praktičtější než load balancery, které mohou být drahé a přidat do systému zbytečnou vrstvu složitosti. Ve velkých systémech samozřejmě existují nejrůznější algoritmy plánování a vyvažování zátěže, včetně něčeho tak jednoduchého, jako je randomizace nebo karusel, až po složitější mechanismy, které berou v úvahu výkonnostní charakteristiky vzoru používání systému. Všechny tyto algoritmy umožňují distribuci provozu a požadavků a mohou poskytovat užitečné nástroje spolehlivosti, jako je automatická odolnost proti chybám nebo automatické odstranění selhávajícího uzlu (například když přestane reagovat na požadavky). Tyto pokročilé funkce však mohou ztěžovat diagnostiku problémů. Například v situacích vysokého zatížení odstraní nástroje pro vyrovnávání zatížení uzly, které mohou běžet pomalu nebo jim vypršel časový limit (kvůli velkému množství požadavků), což jen zhorší situaci pro ostatní uzly. V těchto případech je důležité rozsáhlé monitorování, protože i když se zdá, že celkový provoz a zatížení systému klesají (protože uzly obsluhují méně požadavků), jednotlivé uzly mohou být nataženy na své limity.

Load balancery představují snadný způsob, jak zvýšit kapacitu systému. Stejně jako ostatní techniky popsané v tomto článku hraje zásadní roli v architektuře distribuovaného systému. Zátěžové balancéry také poskytují kritickou funkci kontroly stavu uzlů. Pokud v důsledku takové kontroly některý uzel nereaguje nebo je přetížen, může být odstraněn z fondu zpracování požadavků a díky redundanci vašeho systému bude zátěž přerozdělena mezi zbývající pracovní uzly. .

Fronty

Dosud jsme se podívali na mnoho způsobů, jak rychle číst data. Zároveň další důležitou součástí škálování datové vrstvy je efektivní správa záznamů. Když jsou systémy jednoduché a mají minimální zatížení zpracování a malé databáze, může být zápis předvídatelně rychlý. Ve složitějších systémech však může tento proces trvat neomezeně dlouho. Například data musí být zapsána na více míst na různých serverech nebo indexech nebo může být systém jednoduše pod vysokým zatížením. V případech, kdy zápis, nebo dokonce jakákoliv úloha, trvá dlouho, vyžaduje dosažení výkonu a dostupnosti zabudování asynchronie do systému. Běžným způsobem, jak toho dosáhnout, je uspořádat frontu požadavků.

Obrázek 1.20: Synchronní požadavek

Představte si systém, ve kterém každý klient požaduje úlohu vzdálené služby. Každý z těchto klientů odešle svůj požadavek na server, který provede úkoly co nejrychleji a vrátí jejich výsledky odpovídajícím klientům. V malých systémech, kde jediný server (nebo logická služba) může obsluhovat příchozí klienty tak rychle, jak dorazí, by takové situace měly fungovat dobře. Když však server obdrží více požadavků, než může zpracovat, je každý klient nucen čekat na dokončení zpracování požadavků ostatních klientů, než se vygeneruje odpověď na jeho vlastní požadavek. Toto je příklad synchronního požadavku znázorněného v .

Tento typ synchronního chování může výrazně snížit výkon klienta; Ve skutečnosti je klient v nečinnosti nucen čekat, dokud neobdrží odpověď na požadavek. Přidání dalších serverů pro zvládnutí zatížení systému ve skutečnosti problém nevyřeší; I při efektivním vyvažování zátěže je extrémně obtížné zajistit rovnoměrné a spravedlivé rozložení zátěže potřebné k maximalizaci produktivity klienta. Pokud je navíc server pro zpracování tohoto požadavku nedostupný (nebo došlo k jeho zhroucení), přestane fungovat i klient k němu připojený. Efektivní řešení tohoto problému vyžaduje abstrakci mezi požadavkem klienta a skutečnou prací vykonanou k jeho obsluze.

Obrázek 1.21: Použití front ke správě požadavků

Vstupní fronty. Fronta funguje velmi jednoduše: přijde úkol, dostane se do fronty a „pracovníci“ přijmou další úkol, jakmile mají příležitost ho zpracovat. (Viz.) Tyto úlohy mohou být jednoduché databázové položky nebo něco tak složitého, jako je generování náhledu dokumentu. Když klient odešle požadavky na úkoly do fronty, již nemusí čekat na výsledky provedení; místo toho žádosti potřebují pouze potvrzení, že byly řádně přijaty. Toto potvrzení může později sloužit jako reference na výsledky práce, když si je klient vyžádá.

Fronty umožňují klientům pracovat asynchronním způsobem a poskytují strategickou abstrakci klientského požadavku a odpovědi. Na druhou stranu v synchronním systému neexistuje rozdíl mezi požadavkem a odpovědí, a proto je nelze spravovat samostatně. V asynchronním systému klient odešle úkol, služba odpoví zprávou potvrzující, že úkol byl přijat, a klient pak může pravidelně kontrolovat stav úkolu a výsledek si vyžádá až po jeho dokončení. Zatímco klient zadává asynchronní požadavek, může vykonávat jinou práci a dokonce zadávat asynchronní požadavky z jiných služeb. Ten je příkladem toho, jak fungují fronty a zprávy v distribuovaných systémech.

Fronty také poskytují určitou ochranu proti přerušení a selhání služby. Je například docela snadné vytvořit velmi odolnou frontu, která může opakovat požadavky na služby, které selhaly kvůli momentálním selháním serveru. Je vhodnější použít frontu k vynucení záruk kvality služeb, spíše než vystavit klienty dočasným přerušením služeb, což vyžaduje složité a často nekonzistentní zpracování chyb na straně klienta.

Fronty jsou základním principem řízení distribuovaného přenosu mezi různými částmi jakéhokoli rozsáhlého distribuovaného systému a existuje mnoho způsobů, jak je implementovat. Existuje poměrně málo implementací front s otevřeným zdrojovým kódem, jako je RabbitMQ.
ActiveMQ
BeanstalkD, ale někteří využívají i služby jako Add Tags

Distribuované automatizované informační systémy se dnes staly každodenní realitou. Řada podnikových automatizovaných informačních systémů využívá distribuované databáze. Byly vyvinuty metody pro distribuci dat a distribuovanou správu dat, architektonické přístupy zajišťující škálovatelnost systému, implementace principů vícevrstvé architektury klient-server i architektury střední vrstvy.

Mobilní architektury se začínají uvádět do praxe. To platí jak pro databázové systémy, tak pro webové aplikace.

Oživuje se přístup k budování distribuovaných systémů založený na architektuře peer-to-peer (Peer-to-Peer), ve které, na rozdíl od architektury klient-server, která dnes v distribuovaných systémech dominuje, role interagujících stran v síti nejsou pevné. Přidělují se v závislosti na situaci v síti a zatížení jejích uzlů.

Vzhledem k intenzivnímu rozvoji komunikačních technologií se mobilní AIS aktivně rozvíjejí. Byl vyvinut hardware a software pro jejich tvorbu. Díky tomu se začaly vyvíjet mobilní databázové systémy. Mnoho vědeckých týmů provádí výzkum specifických vlastností takových systémů a vytváří jejich různé prototypy. Technologie Java se staly důležitým nástrojem pro vývoj mobilního softwaru.

Byl vytvořen standard pro protokol WAP (Wireless Application Protocol), který již podporují některé modely mobilních telefonů. Na základě WAP a XML vyvinulo konsorcium W3C značkovací jazyk pro bezdrátovou komunikaci WML (Wireless Markup Language).

Při vývoji AIS byla věnována větší pozornost metadatům. Probíhají zde kroky ve dvou směrech – standardizace prezentace metadat a zajištění jejich podpory v systému.

AIS využívá různé metody a prostředky prezentace metadat (různé typy úložišť metadat). Absence unifikace v této oblasti výrazně komplikuje řešení problémů aplikační mobility, opětovného použití a integrace informačních zdrojů a informačních technologií a také reengineeringu AIS.

K překonání těchto potíží se aktivně vyvíjejí standardy metadat zaměřené na různé informační technologie. V této oblasti již existuje řada mezinárodních, národních a průmyslových standardů, které definují prezentaci metadat a výměnu metadat v AIS. Některé z nich již získaly status de facto standardů. Zde se omezíme na zmínku pouze těch nejvýznamnějších z nich.

Pravděpodobně prvním de facto standardem v této kategorii byl jazyk pro popis dat CODASYL pro databáze síťové struktury. Mezi novější standardy patří: standard dotazovacího jazyka SQL pro relační databáze, který obsahuje definici tzv. informačního schématu - souboru reprezentací schémat relačních databází; komponenta standardu objektové databáze ODMG, která popisuje rozhraní úložiště schémat objektů; mezinárodní standard IRDS (Information Resource Dictionary Systems), který popisuje systémy pro vytváření a údržbu adresářů organizačních informačních zdrojů.

Dále bychom měli zmínit standard CWM (Common Warehouse Metamodel) vyvinutý konsorciem OMG pro reprezentaci metadat datového skladu, založený na standardu OIM (Open Information Model) dříve vytvořeném pro širší účely konsorciem MDC (Meta Data Coalition).

Nová technologická platforma XML pro web také zahrnuje standardy pro reprezentaci metadat. Podpora metadat je jednou z nejdůležitějších inovací webu, která radikálně mění technologii správy jeho informačních zdrojů. Zatímco databázové technologie zpočátku vyžadovaly podporu pro metadata, první generace webu metadata nepodporovala.

Standardy webových metadat jsou podmnožinou jazyka XML používaného k popisu logické struktury určitého typu dokumentu XML. Tento popis se nazývá DTD (Document Type Definition). Platforma XML navíc obsahuje standard XML Schema, který nabízí pokročilejší možnosti pro popis dokumentů XML. Standard RDF (Resource Definition Framework) definuje jednoduchý jazyk reprezentace znalostí pro popis obsahu dokumentů XML. Konečně vyvíjející se standard OWL (Ontology Web Language) definuje formální jazyk popisu ontologie určený pro sémantický web.

Jazykový standard UML (Unified Modeling Language), který poskytuje metadatovou reprezentaci nástrojů CASE pro analýzu a návrh vizuálních objektů, vyvinulo konsorcium OMG. Tento jazyk je podporován v mnoha softwarových produktech CASE. Konsorcium OMG také vytvořilo standard XMI (XML Metadata Interchange) pro výměnu metadat mezi nástroji CASE pomocí jazyka UML.

Za zmínku zde stojí i standard Dublin Core (DC) - soubor prvků metadat pro popis obsahu dokumentů různé povahy. Tento standard si rychle získal oblibu a našel široké uplatnění zejména ve webovém prostředí (viz část 3.3).

Pokračují práce na vývoji stávajících a vytváření nových standardů pro prezentaci metadat pro AIS. Podrobnější informace o předmětných normách naleznete v encyklopedii.

založené na rekonfigurovatelném multi-pipeline výpočetním prostředí L-Net

Jedním z aktuálních problémů 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í a v důsledku toho drahá a ne vždy účinná.

Tato řešení nezajišťují efektivní využití záložních databázových zdrojů, technických a softwarových, což negativně ovlivňuje jak odolnost proti chybám, tak škálovatelnost takových řešení. V případě narušení síťové architektury není možnost dynamické rekonfigurace jak procesů zpracování informací, tak přenosu datových toků (jak řídicích, tak informačních). Použití specifických mikrokontrolérů a použití DCS/SCADA komplikuje vývoj a podporu systémů a 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 související úrovně: úroveň operátora, úroveň řízení a úroveň vstupů/výstupů (viz obr. 1).

Hlavním úkolem operátorské úrovně je poskytnout rozhraní člověk-stroj (HMI) pro konfiguraci a řízení fungová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 vývoj řídicích akcí na akčních členech. Vstupně-výstupní úroveň představuje senzory a akční členy přímo připojené k řídicímu objektu.

Úkolem softwaru je v rámci zobecněné architektury DCS zajistit fungování operátorské úrovně a její propojení s úrovní řízení systému. V důsledku toho je základní úrovní při navrhování softwaru a řešení otázek jeho interakce s hardwarem úroveň operátora. Software musí 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 navrhování obecné architektury systému se neberou v úvahu specifické uzly na úrovni I/O, které k němu budou připojeny v konkrétní implementaci, obecná architektura proto bere v úvahu úroveň operátora a úroveň řízení. Hardware musí být rozšířený, splňovat moderní standardy a mít všechny vlastnosti a schopnosti nezbytné k implementaci architektury.

Požadavky na DCS

Požadavky na 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 především 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 přitom musí zůstat jednoduchý pro jeho obsluhu, vývoj nových jednotek či modulů a úpravu jeho architektury.

Přehled architektur DCS

Abychom provedli revizi architektur DCS, vybrali jsme Siemens SIMATIC PCS 7 DCS jako jednu z nejpopulárnějších na trhu a RTS S3 jako DCS implementovanou na bázi QNX RTOS.

Siemens SIMATIC PCS 7

Architektura systému má všechny vlastnosti zobecněné architektury DCS. Operátorské stanice jsou počítače založené na architektuře procesoru x86 s OS Windows a balíkem Siemens WinCC, který poskytuje HMI. Existují servery s databázemi. Operátorské stanice, inženýrské stanice a servery jsou propojeny lokální sítí založenou na Ethernetu. Operátorská vrstva je spojena s vrstvou správy redundantní sítě průmyslového Ethernetu. Na úrovni řízení jsou programovatelné logické automaty (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 k 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 mohou být řízeny OS Windows nebo Linux. Inženýrské stanice jsou kombinovány s operátorskými stanicemi. Systém poskytuje jednotné prostředí pro vývoj aplikací. Síť Ethernet spojuje uzly v rámci operátorské vrstvy a samotnou operátorskou vrstvu s řídicí vrstvou pomocí zásobníku protokolů TCP/IP. Na úrovni řízení jsou průmyslové počítače s operačním systémem QNX 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žívají různé hardwarové a softwarové platformy. V rámci operátorské úrovně lze použít pouze jednu architekturu procesoru a pro konfiguraci a vývoj řídicí úrovně je zapotřebí speciální inženýrská stanice. Tyto DCS nabízejí jako způsob zvýšení odolnosti proti chybám pouze hardwarovou redundanci s duplikací funkčnosti redundantního uzlu, 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 funkčnosti s minimálními ztrátami 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í datových toků.
• 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 potřebujete operační systém 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ším operačním systémem je QNX 6 (Neutrino), který má velmi efektivní distribuci zdrojů a síťové možnosti. Rozsáhlé síťové možnosti 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 univerzálního přepínače a blok rekonfigurovatelného výpočetního prostředí (RCE) (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:

• Zpracování potrubí
• Hardwarová redundance
• Rozložení zatížení
• Rekonfigurace za běhu

Na první úrovni architektury je vstupní/výstupní (I/O) blok, který zahrnuje: vstupně/výstupní uzly, přepínač vstupních/výstupních uzlů, vstupně/výstupní 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řidělené úlohy jsou distribuovány 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 přes sběrnici ke všem I/O uzlům v bloku, což umožňuje libovolnému uzlu dotazovat se na libovolný senzor nebo působit na jakýkoli akční člen. Přepínač I/O uzlů zajišťuje komunikaci mezi všemi I/O uzly za účelem výměny dat mezi nimi a dalšími úrovněmi systémové architektury pro příjem ří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á komunikace mezi uzly a určitá pracovní zátěž uzlů v aktuálním provozním režimu I/O bloku umožňuje organizovat v bloku pipeline výpočty nezbytné pro provoz tohoto bloku bez použití externího výpočetního výkonu řídicího systému (RCS), který umožňuje efektivně využít volné zdroje poskytnuté pro redundantní uzly I/O bloku v době selhání.

Blok univerzálních přepínačů, 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é spoje 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. Vzhledem k tomu, že síť Qnet umožňuje dynamickou distribuci toků přenosu dat, škálování tohoto bloku se provádí pouhým připojením nových 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 jiný přepínač zajistí podobnou komunikaci mezi uzly nebo s nimi přímo souvisí. V tomto případě je nutné se postarat o dostatečnou šířku pásma sítě nezbytnou 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 vysoce výkonný systém řízení spotřeby pro řešení složitých problémů zpracování informací, rozhodování, rozpoznávání atd. Blok má na starosti 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 činnost I/O bloků. Uzly tohoto bloku zajišťují archivaci jak vlastních dat, tak dat z I/O bloků. Každý uzel tohoto bloku může hrát roli stroje operátora, který je navržen tak, aby monitoroval provoz systému a prováděl úpravy provozních programů jak tohoto uzlu, tak všech uzlů systému, přičemž na požádání provádí 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 síťové uzly. Řešení tohoto problému je založeno na konstrukci výpočetních pipelines. Pro sestavení výpočetního potrubí je nejprve sestaven graf úkolů – schéma pro výměnu 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) do grafu počítačové sítě (viz obr. 4) s ohledem na požadavky ú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, práci se síťovými a úkolovými grafy. V důsledku toho se zvyšuje výkon díky zřetězení výpočtů a je organizováno racionální využití všech výpočetních zdrojů, které má systém k dispozici.

odolnost proti chybám

Hlavním problémem fungování takového systému je úplné narušení výpočetních potrubí, pokud některý uzel tohoto potrubí selže nebo dojde k přerušení přenosu dat mezi nimi. Základní prostředky protokolu Qnet dosahují obnovení spojení mezi uzly při jejich částečném narušení vlivem záložních linek poskytovaných architekturou. Systém L-Net řeší problém obnovy funkčnosti v případě úplného 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 se vyhledá dostupný hardware a jeho zařazení do grafu úlohy.
• Rekonfigurace s pasivní dostupností– 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.
• Rekonfigurace s aktivní dostupností– vrchol grafu úlohy je implementován na několika uzlech, které paralelně provádějí zpracování dat a přenášejí výsledek.

Díky tomu má systém flexibilní připravenost na výpadky jak na softwarové, tak hardwarové úrovni, možnost měnit konfiguraci uzlů bez zastavení práce a ztráty výkonu, přičemž je nezávislý na implementaci sítě, výpočetního potrubí a uzlu .

Závěr

Vyvinutý systém L-Net na rozdíl od stávajících analogů zahrnuje využití široké škály hardwarových charakteristik uzlů DCS s jejich plnou softwarovou kompatibilitou. Když uzly pracují pod stejným operačním systémem (QNX Neutrino), je možné je postavit na různých architekturách procesorů (x86, ARM, MIPS atd.) s rozmanitou sadou rozhraní a periferních zařízení. Implementace uzlů je možná ve formě stolních, průmyslových PC, nositelných PC a jednodeskových počítačů. Všechny součásti softwarového komplexu vyvíjeného DCS lze spouštět 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 použití každého uzlu k řešení problémů jak na úrovni operátora, tak na úrovni řízení. V důsledku toho existuje flexibilní systém interakce mezi rovnocennými uzly bez pevné hierarchie úrovní, která je vlastní zobecněné architektuře DCS a systémům využívajícím tuto architekturu jako základ. Síť peer-to-peer zjednodušuje procesy 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 síťovém softwaru 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ů). Dynamické konfigurační a rekonfigurační algoritmy zlepšují výkon a spolehlivost využitím existujících hardwarových rezerv v systému.

Nezanedbatelnou výhodou systému je maximální transparentnost v něm použitých hardwarových i softwarových technologií, což umožňuje výrazně zjednodušit technickou podporu 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ích systémů, 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í referent. Programátor. Obor: „Ří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ý.