Príklad architektúry D2000

V dnešnom blogu by som chcel uviesť viacero možných architektúr pri nasadzovaní aplikačného servera Ipesoft D2000.

Vzhľadom ku flexibilite a možnosti spúšťania jednotlivých procesov D2000 na vzdialených počítačoch bude zoznam určite neúplný – ale budem sa snažiť popísať najčastejšie sa vyskytujúce konfigurácie.

Začnem od najjednoduchšej. Všetky procesy (jadro systému [Kernel], komunikačný proces [Kom], archivačný process [Archiv] a ďalšie [Event], [Calc], [DbManager], ...) sú spustené na jedinom počítači. Na tomto počítači je aj databázový server (konfiguračná, monitorovacia, archívna databáza). Ak sa používa aplikačná databáza, môže byť tiež lokálna. Systém nemá žiadnu redundanciu.

Dnes už väčšina aplikácií vyžaduje redundanciu (samostatný blog), ktorá dokáže zabezpečiť bezvýpadkovosť nielen ak sa vyskytne problém s D2000, ale predovšetkým pri aplikácii aktualizácií (firmware, OS, databázy, D2000), čo je dnes už samozrejmou súčasťou starostlivosti o aplikačné servery. Zjednodušene platí, že v redundantnom systéme aktívny komponent pracuje (zberá dáta, spúšťa skripty) a pasívny (alebo pasívne, keďže D2000 podporuje aj redundanciu viacerých serverov) nerobí nič. Je to ale hrubé zjednodušenie, lebo napríklad výpočtový proces ([Calc]) počíta aj keď je pasívny. Všetky hodnoty sa z aktívneho procesu Kernel distribuujú na pasívny/pasívne procesy Kernel (a odtiaľ na pripojené procesy, ktoré ich potrebujú).

Špeciálnym prípadom je proces Archiv, ktorý sa v redundantných systémoch konfiguruje podobne ako užívateľské procesy ([Hi],[Cnf]), aby sa pripájal k aktívnemu Kernelu (pomocou štartovacích parametrov /RD alebo /RF), pričom viaceré archívne procesy sú spustené ako inštancie (napr. inštancia 1 a 2 procesu SELF.ARC). Takto je možné dosiahnuť redundanciu procesu Archiv a prípadne prepínať aktívnu/pasívnu inštanciu podľa potreby, bez nutnosti prepínania redundancie aplikačného servera. Čím sa líši aktívna a pasívna inštancia archívu? Obidve archivujú dáta rovnakých archívnych objektov (každá do vlastnej databázy), ale aktívna inštancia poskytuje dáta užívateľom, prípadne skriptom, ktoré ich potrebujú.

Obrázok 2 - Redundantný D2000 systém s dvoma nodmi.

V minulosti sa pre väčšie aplikácie používala architektúra s dedikovanými archívnymi servermi. Pri dnešných možnostiach hardvéru už nie je problém použiť virtuálne servery s dostatočným množstvom CPU, pamäte a diskového priestoru, aby dokázali prevádzkovať D2000 procesy spolu s archívom aj archívnou databázou (štandardne na platforme PostgreSQL).

D2000 sa niekedy používa aj v trojnásobnej redundancii. Väčšinou ide o konfiguráciu redundancia + disaster recovery, keď dva servery sú na hlavnej lokalite a tretí je na záložnej lokalite. Toto má zmysel, pokiaľ je predmetom riadenia geograficky distribuovaná sústava (napr. niekoľko závodov na výrobu elektrickej energie alebo tranzitný plynovod), prípadne sa jedná o MES systém s vysokou dostupnosťou. Aj v tomto prípade platia všetky fakty uvedené pri redundantnom systéme s dvoma nodmi, akurát proces Archiv bude existovať v troch inštanciách.

Obrázok 3 - Redundantný D2000 systém s troma nodmi.

Je možné vytvoriť aj viacnodovú redundanciu, ale v praxi 3 nody stačia. Štvornodovú redundanciu som videl u zákazníka iba krátkodobo – počas migrácie dvojnodovej redundancie na nové dva nody (dokonca umiestnené v inej sieti). A u iného zákazníka bežala takmer pol roka dokonca šesťnodová redundancia – ako už tušíte, tiež sa jednalo o migráciu, tentokrát trojnodového systému na nové servery – a opäť, dokonca aj do iných sietí.

Ďalšou možnosťou je vysunutie vybraných procesov do demlitarizovanej zóny – t.j. na server, ktorý je v sieti s nižšou úrovňou bezpečnosti, ktorá je od D2000 siete oddelená firewallom. Príklady použitia:

• DbManager proces pristupujúci k externým databázam.

• Event proces sťahujúci a spracovávajúci dáta z webu alebo od externých partnerov.

• Kom proces zverejňujúci dáta vočí externým systémom.

• SAS proces (Security Access Server), cez ktorý sa pripájajú externí D2000 klienti.

• OPC a OPC UA server, ku ktorým sa pripájajú externí OPC a OPC UA klienti .

V prípade takýchto klientov je možné nakonfigurovať tzv. reverzné pripojenie, keď sa proces Kernel pripája na definovaný TCP port a IP adresu (namiesto toho, aby sa klientský proces pripájal na Kernel). Toto zabezpečí, že v prípade napadnutia servera v DMZ nebude odtiaľ možné útočiť na D2000 server.

Obrázok 4 – Neredundantný systém s vysunutím vybraných procesov do DMZ.

Obrázok 4 ukazuje neredundantný systém, ale analogicky používame redundantné architektúry s DMZ. Aj servery a procesy v demilitarizovanej zóne môžu byť redundantné – DbManager, Event, Kom nakonfigurované ako inštančné (podobne ako procesy Archiv), SASy OPC a OPC UA servery ako neinštančné (s tým, že všetky sú aktívne). Klienti (užívateľské procesy ako HI) sa pripájajú s parametrom /RF k redundancii definovanej ako IP adresy serverov, na ktorých bežia SAS procesy. A podobne, v konfigurácii OPC a OPC UA klientov je možné zadať všetky IP adresy, na ktorých sú spustené OPC a OPC UA servery.

Podobný prípad (ale významovo opačný), ktorý sa používa v praxi, je vzdialený komunikačný proces, ktorý je umiestnený naopak v sieti s vyššou úrovňou bezpečnosti ako D2000 (spravidla sa jedná o technologickú sieť). V tomto prípade sa pochopiteľne reverzné pripojenie nepoužíva, keďže dotyčný Kom proces je v bezpečnejšej sieti a preto je logické, že sa pripája do menej bezpečnej siete. Opäť platí poznámka, že D2000 systém môže byť aj redundantný.

Ďalším dôvodom pre vysunutie Kom procesu do technologickej siete je možnosť použitia technológie KOM Archívu. Jedná sa o schopnosť Kom procesu lokálne ukladať hodnoty meraných bodov získané z komunikácie, pokiaľ dôjde ku strate spojenia na D2000 Kernel, a poslať ich po obnovení spojenia. Takto je možné eliminovať výpadky dát spôsobené problémami v sieti.

A posledným dôvodom môže byť OPC komunikácia. Pr inej je bezpečnejšie a jednoduchšie na konfiguráciu firewallov umiestniť Kom proces priamo na počítač s OPC serverom a povoliť prístup Kom procesu na jediný TCP port (3119) počítača, na ktorom je spustený Kernel, ako otvárať všetky porty potrebné pre vzdialené Windows komunikáciu, či inštalovať a konfigurovať treťostranný softvér ako OPC Tunneler.

Obrázok 5 - Neredundantný systém s vysunutím komunikačného procesu do technologickej siete

Tento rok sme migrovali existujúci SCADA systém, pričom sa menila aj jeho architektúra. Z logistických dôvodov boli presunuté redundantné aplikačné servery do dvoch geograficky distribuovaných serverovní, pričom komunikačné procesy zostali v technologickej sieti na dvoch redundantných komunikačných počítačoch (jednalo sa o priemyselné PC s pasívnym chladením, umiestnené na DIN lištu). V systéme existovalo niekoľko komunikačných procesov, ktoré boli nakonfigurované ako inštancie 1 a 2, ktoré sa pripájajú k aktívnemu D2000 serveru, ako ukazuje nasledovný obrázok:

Obrázok 6 - Redundantný systém s vysunutím redundantných komunikačných procesov do technologickej siete.

Takýto dizajn je odolný voči súčasnému výpadku jedného aplikačného servera a jedného komunikačného servera. Navyše, inštancie 1 a 2 viacerých komunikačných procesov (na obrázku KomA, KomB, KomC) je možné prepínať nezávisle, takže aktívne inštancie môžu byť rozložené na oboch serveroch ServerKom1 a ServerKom2, čím je možné rozložiť aj záťaž na oba komunikačné servery.

Jedna komunikácia smerom “hore”, na MES systém, ostala priamo na aplikačnom serveri – takže aj tam bol spustený komunikačný proces.

Samozrejme, všetky vyššie uvedené dizajny sú modelové. V praxi sa dizajn prispôsobuje potrebám konkrétneho zákazníka. Takže je možné mať napríklad 2-nodovú aplikáciu s redundantným SAS serverom v demilitarizovanej zóne, s piatimi komunikačnými servermi (neredundantnými) umiestnenými v technologických sieťach a ďalším komunikačným procesom na dedikovanom serveri, ktorý slúži na komunikáciu s externým partnerom.

Ako navrhujeme server pre aplikačnú databázu?

Aplikačnou databázou myslím obecnú SQL databázu, ktorá je používaná vo väčších a zložitejších SCADA systémoch a prakticky vo všetkých MES a EMS systémoch. Štruktúru má v rukách aplikačný programátor, na prístup do tejto databázy sa používa proces DbManager. Súčasťou tejto databázy môže byť aj EDA databáza - viac info v samostatnom blogu o typoch databáz.

V najskromnejšom prípade sa môže aplikačná databáza nachádzať priamo na serveri s aplikáciou, ale zvyčajne má vlastný dedikovaný server. Môže to byť Windows alebo Linux, dnes sú kvôli spoľahlivosti a výkonu preferované Linuxové riešenia.

Obrázok 7 - Neredundantný databázový server.

Pokiaľ chceme zredundantniť databázu, štandardne používame 2-nodový Linuxový cluster (Corosync/Pacemaker), v ktorom sú dáta zrkadlené na oboch nodoch (pomocou DRBD) a databázový server beží na jednom z nodov. Klienti pristupujú cez virtuálnu IP adresu, ktorá je v clustri tiež zdieľaná (takže obidva servery musia byť na tom istom segmente siete). Toto riešenie je použiteľné, ak sú oba servery na jednej lokalite (takže latencia siete medzi nimi je minimálna). Viac informácií o tejto architektúre a jej monitorovaní je v samostatnom blogu.

Obrázok 8 - Redundantný databázový cluster.

Pokiaľ sú servery na dvoch rôznych lokalitách, používame master-slave replikáciu (spravidla asynchrónnu, aby výpadok záložnej lokality nezastavil produkciu). V tomto prípade je vyžadované ručné prepínanie medzi master a slave databázovými servermi. Keď sa teda redundancia D2000 prepína medzi lokalitami, je nutné ručne prekonfigurovať databázové servery.

Obrázok 9 - Redundantné databázové servery s master-slave replikáciou.

Pokiaľ máme 3-nodovú architektúru D2000 (dva nody na hlavnej lokalite, jeden na záložnej), tak obvykle rovnakú úrovňou redundancie používame aj pre aplikačnú databázu. Na hlavnej lokalite vytvoríme databázový cluster, ktorý je asynchrónne replikovaný na záložnú lokalitu:

Obrázok 10 - Redundantný databázový cluster s master-slave replikáciou.

Záver

V tomto blogu som chcel demonštrovať niektoré základné a často v praxi používané architektúry systémov postavených na aplikačnom serveri Ipesoft D2000. V skutočnosti sa aj architektúra systémov v čase vyvíja – často je systém postavený ako neredundantný a postupne, ako rastie a zväčšuje sa, narastá aj jeho význam a užívatelia začnú rozmýšľať o zredundantnení (redundantné archívy, aplikačné servery, databázy ...).

Dobrou správou je, že pri takýchto úpravách spravidla nie je nutné zasahovať do logiky aplikácie – snáď iba rozšíriť diagnostiku a vizualizovať architektúru systému v schémach, aby bolo možné monitorovať aj funkčnosť aktuálne pasívnych prvky redundancie.

1.6.2026, Ing. Peter Humaj, www.ipesoft.com

‍