Dotaz: Výběr ze dvou serverů a zamaskování za jednu adresu

[BouHou]

Ahoj,řeším následující problém s komunikací mezi PLC. Mám dva komunikační CPU, které se chovají jako server (dostávají pomocí protokolu MODBUS dotazy a na ty odpovídají). Oba servery (CPU) jsou v redundantní konfiguraci. Tzn. že v obou je úplně stejný program, jenom má každý jinou IP adresu. Problém je, že v jednom okamžiku je aktivní vždy jenom jeden server. Ten druhý neodpovídá.

Potřeboval bych oba servery zamaskovat pod jednu adresu (což by pomocí routeru s NATem nebyl problém), ale lze nějak udělat, aby se vytvořilo spojení vždy na aktivní server (to by se přepínalo, když by do určitého času nedostal od serveru odpověď).

Potřebuji, aby se to navenek tvářilo, že se připojuji na jedno zařízení bez ohledu na to, které CPU zrovna běží. Nějaké napády nebo i tipy na HW, který by to dokázal?

Odpovědi

[NN]

Problém je, že v jednom okamžiku je aktivní vždy jenom jeden server.

Muzes to rozvest? Jak se pozna, ktery je aktivni? Obycejne ICMP to asi nebude..

[BouHou]

Nemám teď sice HW u sebe (abych to mohl na 100% otestovat), ale ICMP podle mě fungovat bude.

[NN]

Nerikam, ze to fungovat nebude, ale ten redundantni HW se musi nejak domluvit mezi sebou => bude existovat presna moznost jak zjistit, ktery je aktivni. ICMP je v tomto smeru dost nespolehlive, co kdyz zrovna po kontrole dojde ke zmene roli?

Na reseni takovych situaci existuji GLBP protokoly(HSRP,VRRP,NHRP etc..).

[BouHou]

Všem moc díky za jejich nápady. Musím promyslet a pozjišťovat co všechno se dá na PLC-CPU (serverech) a na clientovi nastavit.

Jenom pro shrnutí:
• Zařízení je druhém konci světa bez možnosti remote connection - je to rafinerie a jakékoliv připojení zvenčí je pro ně nepřípustné. Takže mám trošku svázané ruce a nemám možnost testování dopředu. Vše si musím promyslet a nachystat doma, abych to potom na jednu návštěvu na místě dokázal rozchodit.
• Nejlepší by bylo použít nějaký ze zmíněných protokolů mezi servery, aby si navzájem vyjednali IP adresu, ale spíš to vypadá, že to nepůjde použít.
• Zatím to vypadá na řešení s routerem a NATem, kdy by přepínal spojení podle toho, který server je aktivní.
• Na řešení, že si client bude zkoušet postupně oba servery jsem dopředu spoléhal, ale momentálně se ukazuje, že to asi nebude možné.
• Řešení s relé mi nepřijde dobré, protože tím sice přepojím fyzické spojení, ale nezměním IP adresu, která je nastavená u připojení na clientovi.
• Další řešení, které mě napadlo je kompletně předělat komunikaci ze client->server na server<-client. Tzn. prohodit role client-server. CPU by byli oba clienti a komunikovali by s druhým zařízením (nynější client, který není redundantní), ale to by bylo poněkud pracné.

[Josef Kufner]

Řešení s relé mi nepřijde dobré, protože tím sice přepojím fyzické spojení, ale nezměním IP adresu, která je nastavená u připojení na clientovi.

Aby relé mělo smysl, musejí mít oba servery stejnou IP adresu. Nicméně pokud to je rafinerie na konci světa, tak se na relé vykašli, neboť to nebude otestované a snadno nahraditelné. Raději omez vše, co se může podělat, i za cenu složitějšího klienta. Co takhle aby se klient připojil na oba servery současně a pak používal ten zdravější?

[BouHou]

S tím musím souhlasit, nic netestované ani nic co by nebylo snadno nahraditelné. Stejné IP adresy nemůžou být, to je dáno HW a systém neumožnuje konfigurovat dvě zařízení se stejnou IP.

[Petr Šobáň]

Jsem myslel že se potřebuješ připojit zvnějšku a proto to musí mít jednu IP, ale když je to uzavřený systém tak mě nenapadá proč by jsi to měl maskovat za jednu IP?

Normálně ať klient kontroluje obě adresy a která bude reagovat tak ty data budu vypisovat ukládat a i můžu zobrazovat který je funkční.....

Klidně můžeš komunikovat s obouma naráz ne čemu by to vadilo......

A nebo máš pouze nějaký automat co umí komunikovat pouze s jednou IP?

[BouHou]

No pro mě je ten client "blackbox" na zákazníkově straně a nevím jaké má nebo nemá možnosti. Proto jsem zvažoval vše zamaskovat pod jednu adresu,aby se můj systém vůdči němu tvářil jako "standardní" systém a on jenom provedl "standardní" konfiguraci.

[Petr Šobáň]

Jednoduše pořídit router do kterého se dá dát alternativní fw LEDE (OpenWRT) a napsat si skript.

Buď bude pingat na IP těch serverů, nebo jinak zjištovat kdo je aktivní a podle toho přepíše port forward na příslušný PC.

Případně mikrotik tam se dají taky spouštět nějaké skripty, ale v tomto se nevyznám.....

[BouHou]

No to by asi mohlo fungovat. Jenom místo pingů bych musel dávat requesty na MODBUS zprávu. Můžeš prosím doporučit nějaký robustní HW, na kterém by se to dalo rozběhat? Ideálně něco "průmyslového", aby se to dalo dát do rozváděče na DIN lištu.

[alkoholik]

Muzes na tech serverech rozjet VRRP? Dal bys jim jednu adresu navic o kterou by se dohadovaly. Normalne se na to pouziva keepalived.

[BouHou]

Bohužel VRRP se tam rozjet nedá.

[j]

Nevim teda co mas za aplikaci a jaky mas moznosti, ale ... zcela standardni chovani pokud jednomu dns zaznamu pridelis dve (nebo vic) adres je to, ze klient postupne zkousi vsechny. Jakou veme prvni pak vetsinou nemuzes ovlivnit, protoze i dns to vraci (umyslne) v ruznym poradi.

Tzn standardni klient by nepouzival IP ale DNS jmeno, a to jmeno by mu vratilo ty dve (nebo vic) ruznych adres, a komunikaci by zahajil s tou, ktera by mu odpovedela. Tedy klidne s tou, co odpovi nejdriv(zahajit muze na vsechny) - podobne se umej chovat browsery ve vztahu ipv4/v6, ale je to v tomto pripade v rozporu s rfc (prednost ma dostat v6, ne treba jen o par ms rychlejsi v4).

[NN]

komunikaci by zahajil s tou, ktera by mu odpovedela.

Pri statickem DNS zaznamu to snad vrati zaznam vzdy bez ohledu na stav zarizeni. Jak to resi vypadek?

[Ovrscout]

Asi je to jasné a možná že to ve vaší situaci ani jinak udělat nejde - V tom případě se za hloupé poznámky omlouvám :)

Ale projistotu:

• Vřazením routru který to bude takhle směrovat se vytvoří nový "Single point of failure", pokud ho tedy nějakým způsobem také nezdvojíte
• Takovéhle přesměrování platí jen pro nově vytvořená spojení. A pokud se client zkusí navázat nové spojení dříve než se to na routeru přesměruje, může se, podle toho jak se trefí, natahovat čas než se spojení podaří či zahodí. Záleží ale jak jde nakonfigurovat ten klient a jaké jsou požadavky na rychlost.

Nejlepší je to asi vyřešit přímo na tom klientu, pokud to jde, ale víc asi neporadím.

P.S. Nápad "j" na použití DNS se mi líbí, tam alespoň většinou lze zadat i záložní dns server. Záleží ale co a jak ten konkrétní klient podporuje.

[jeniceek]

Asi by se dalo použít HAProxy.

[Josef Kufner]

V zásadě to můžeš řešit na klientovi, nebo na serverech, nebo na routeru před servery.

Pokud to budeš řešit na klientovi, dáš mu seznam adres a on se zkusí připojit na všechny (postupně či najednou, to už je jedno).

Pokud to budeš řešit na serverech, dáš všem stejnou IP adresu a po jiném komunikačním kanále zajistíš, že aktivní bude jen jeden.

Pokud to budeš řešit na routeru před servery, uděláš prostý NAT dle potřeby a necháš ho automaticky přenastavovat. Takto se obvykle řeší load-balancing, jen ty routery jsou občas zdvojené, pro případ, že by jeden upadl.

Alternativa k routeru je prosté relé, které fyzicky přepojí kabel, a nějaká triviální logika na jeho přepínání připojená na GPIO piny (pokud jsou).

[Petr Šobáň]

Vidíš relé mě nenapadlo a stačí to připojit na nějaký zdroj toho PC a pokud bude zapnuté tak kabel připojen k němu pokud bude vypnuté tak kabel k záložnímu....

A nebo na nějaký pin a přepínat pomocí SW.

[Josef Kufner]

K tomu relé by to chtělo nějaký monostabilní klopný obvod, který by bylo potřeba pravidelně tahat za nohu, aby držel relé sepnuté. Je totiž potřeba řešit nejen zapnutí počítače, ale i to, že něco smysluplného dělá (watchdog). Pak je také vhodné, aby ten druhý počítač mohl odpojit ten první, pokud zjistí, že přestal fungovat.

Asi bych vzal ATtiny441, připojil přes sériové porty servery (ATtiny441 má dva) a přihodil pár relé. Program by byl vcelku jednoduchý – pár primitivních textových příkazů na odpojení/připojení/… a ovládalo by se to prostým echo X >/dev/ttyS0.

[R]

Tieto routery, rele a podobne nezmysly budu single point of failure. Najprv by som si teda polozil otazku: budu spolahlivejsie ako samotny server?

[BouHou]

To by neměl být problém, protože tato komunikace s clientem je jenom dohledový systém. Veškeré kritické řízení, kvůli kterému jsou tam redundantní CPU, probíhá po jiné - redundantní - komunikaci.