• DiodeLink Console™ Instalacja

    Poniższe video wyjaśnia proces instalacji oprogramowania Systegrate DiodeLink Console™.

  • Wsparcie dla protokołu SMB

    Poniższe wideo pokazuje w jaki sposób Systegrate DiodeLink Console ™ współpracuje z protokołem SMB.

  • DiodeLink Console 1.0 – Nowa wersja już dostępna!

    Systegrate DiodeLink Console 1.0

    DiodeLink Console 1.0 – Nowa wersja już dostępna!

    Praktyczne rozwiązanie do jednokierunkowego przenoszenia danych z OT do IT przez sprzętowo wymuszoną ścieżkę one-way — bez zamieniania każdego projektu integracyjnego w osobne przedsięwzięcie inżynierskie.

    W wielu zakładach przemysłowych problemem nie jest już samo pozyskanie danych. Prawdziwym wyzwaniem jest ich bezpieczne wyprowadzenie z chronionego środowiska OT do systemów raportowych, analitycznych, monitoringu, historianów czy platform biznesowych. Systegrate DiodeLink Console 1.0 odpowiada właśnie na tę potrzebę. Łączy fizycznie wymuszoną transmisję jednokierunkową przez data diode z przejrzystym modelem administracji strumieniami, certyfikatami, wymianą plików i usługami dodatkowymi.

    W praktyce platforma działa jako para usług: Sender po stronie OT oraz Receiver po stronie IT. Sender odczytuje dane ze źródeł lokalnych, dioda pozwala na ruch tylko w jednym kierunku, a Receiver odtwarza albo publikuje te dane dalej w postaci gotowej do wykorzystania przez odbiorców po stronie IT. Dzięki temu można zachować twardą segmentację sieci, a jednocześnie realnie udostępnić dane operacyjne tam, gdzie są potrzebne.

    Jak to działa — w jednym spojrzeniu

    Źródła OT PLC, brokerzy, pliki, UDP, OPC UA, SNMP Sender odbiera lub subskrybuje Data Diode tylko one-way Receiver odtwarza lub publikuje Odbiorcy IT SCADA, historian, analityka, klienci

    Rysunek 1. DiodeLink Console działa jako para Sender/Receiver wokół sprzętowej data diode, przenosząc dane z OT do IT bez kanału zwrotnego.

    Model operacyjny pozostaje prosty. Każdy węzeł ma interfejs po stronie diody oraz osobny interfejs danych lub zarządzania. Administrator tworzy strumień dla konkretnego przypadku użycia, używa tego samego identyfikatora strumienia po obu stronach, uruchamia go, a następnie weryfikuje status, metryki i logi. Interfejs wiersza poleceń diodecmd służy do zarządzania cyklem życia strumieni, funkcjami opcjonalnymi, certyfikatami oraz licencją.

    Co wyróżnia DiodeLink Console 1.0

    Sprzętowo wymuszony kierunek transmisji

    Ruch odbywa się wyłącznie od Sendera do Receivera. Dokumentacja użytkownika konsekwentnie opisuje łącze data diode jako jedyną ścieżkę między strefą OT i IT.

    Siedem typów strumieni replikacyjnych

    UDP, Files, MQTT, SNMP, Modbus, OPC UA i CIP obejmują najczęstsze wzorce wymiany danych operacyjnych.

    Wbudowane formy dostępu do plików

    Funkcje SFTP, SMB i NFS pozwalają udostępniać zreplikowane pliki w sposób dobrze znany użytkownikom Linux i Windows.

    Opcjonalny wbudowany broker MQTT

    Funkcja MQTT potrafi uruchomić brokera opartego na Mosquitto, utworzyć domyślny strumień replikacji i zabezpieczyć klientów przez TLS lub mutual TLS.

    Bezpieczeństwo w modelu operacyjnym

    Import certyfikatów, utrzymanie trust store, generowanie certyfikatów klienckich i obsługa CRL są częścią standardowej administracji platformą.

    Widoczność i kontrola pracy

    Status strumieni, metryki, logi, eksport/import konfiguracji oraz wyjście tabelaryczne lub JSON pomagają standaryzować utrzymanie i diagnostykę.

    Strumienie replikacji: tu widać realną wartość platformy

    DiodeLink Console nie jest wyłącznie tunelem transportowym. Jej przewaga polega na tym, że różne wzorce danych OT zamienia w powtarzalne, jednokierunkowe usługi replikacyjne. Zamiast zmuszać wszystkie źródła do identycznego działania, platforma oferuje modele strumieni dopasowane do konkretnych protokołów.

    Typ strumienia Jak działa Efekt po stronie IT
    UDP Sender nasłuchuje pakietów i przekazuje je przez diodę. Receiver wysyła je dalej do skonfigurowanego celu. Obsługiwane są tryby unicast, multicast i broadcast. Aplikacja odbiorcza otrzymuje ten sam strumień pakietów na oczekiwanym hoście, grupie lub sieci docelowej.
    Files Platforma obserwuje zarządzane drzewo katalogów, stosuje maski include/exclude i logikę ponowień, a następnie przenosi pliki jednokierunkowo. Zreplikowane pliki stają się dostępne dla użytkowników lub procesów po stronie IT, opcjonalnie przez SFTP, SMB albo NFS.
    MQTT Sender subskrybuje temat na brokerze źródłowym, przesyła wiadomości przez diodę, a Receiver publikuje je na brokerze docelowym. Obsługiwane są QoS oraz uwierzytelnione konfiguracje TLS. Klienci po stronie IT mogą korzystać z lustrzanych tematów MQTT lokalnie lub przez wbudowany broker.
    SNMP Sender pobiera dane SNMP i zdarzenia trap z agenta źródłowego. Receiver zasila agenta lustrzanego po stronie IT. Narzędzia monitorujące odpytują punkt SNMP po stronie IT, bez potrzeby bezpośredniego dostępu do sieci OT.
    Modbus Sender odczytuje wybrane rejestry, cewki, wejścia lub zakresy z urządzeń OT. Receiver udostępnia zreplikowany stan przez Modbus TCP albo RTU. SCADA, MES lub historiany mogą czytać lokalną replikę Modbus tak, jakby była pobliskim urządzeniem.
    OPC UA Sender wykonuje discovery i przesyła uporządkowane ramki metadanych, wartości i diagnostyki. Receiver odbudowuje tylko-do-odczytu wirtualny serwer OPC UA. Klienci OPC UA po stronie IT mogą przeglądać i odczytywać uporządkowaną replikę bez łączności zwrotnej do OT.
    CIP / EtherNet/IP Sender przechwytuje cykliczne implicit I/O z PLC po stronie OT. Receiver działa jako lokalny serwer brzegowy dla klientów PLC po stronie IT, w trybie jawnym lub zabezpieczonym TLS/DTLS. Zreplikowane cykliczne dane sterowników trafiają do odbiorców po stronie IT przy zachowaniu izolacji OT.

    Dlaczego takie modele strumieni mają znaczenie

    Każdy strumień rozwiązuje inny problem integracyjny:

    • UDP sprawdza się dla telemetrii, komunikatów typu syslog, broadcastów PLC i lekkiego ruchu sensorowego.
    • Files pasuje do wymiany dokumentów, wsadów danych, raportów, receptur i procesów przekazywania plików między systemami lub zespołami.
    • MQTT odpowiada za scenariusze event-driven oraz integracje oparte o broker wiadomości.
    • SNMP wspiera monitoring urządzeń i sieci wtedy, gdy strona IT potrzebuje wglądu bez bezpośredniego dostępu do OT.
    • Modbus jest naturalnym wyborem dla klasycznej replikacji rejestrów przemysłowych do SCADA i historianów.
    • OPC UA pasuje do uporządkowanych modeli informacji przemysłowej, odczytu wartości i diagnostyki.
    • CIP odpowiada za cykliczne przepływy danych sterowników w środowiskach EtherNet/IP.

    To istotne, ponieważ w praktyce większość organizacji nie ma jednego wzorca danych w OT, lecz kilka naraz. Potrzebują więc platformy, która ustandaryzuje sposób przenoszenia tych danych przez granicę one-way.

    Bezpieczeństwo i administracja bez dodatkowych narzędzi

    Z dokumentacji użytkownika wyłania się platforma zaprojektowana nie tylko na dzień wdrożenia, ale do codziennej eksploatacji. Administrator może włączać funkcje opcjonalne, tworzyć udziały, wymieniać i odnawiać certyfikaty, zarządzać listami zaufania i unieważnień, generować certyfikaty klienckie do mutual TLS oraz eksportować i importować definicje strumieni. Dla zespołów operacyjnych taka spójność procedur bywa równie ważna jak sama lista obsługiwanych protokołów.

    Warto też zwrócić uwagę na model licencjonowania. Opisana ścieżka obejmuje wbudowaną 180-dniową licencję trial, proces request/import dla licencji docelowej oraz wsparcie dla przypisania do sprzętu, środowiska programowego albo nazwy hosta. To upraszcza planowanie testów, odbiorów i przejścia do produkcji.

    Chcesz sprawdzić platformę we własnym środowisku? To jest bardzo dobry moment, aby to zrobić. Wersję trial można zamówić tutaj: https://systegrate.com/#request-trial. Tylko teraz okres trial wynosi 180 dni.

    Podsumowanie: jakie są możliwości replikacji?

    DiodeLink Console 1.0 umożliwia replikację:

    • ruchu pakietowego przez UDP w scenariuszach unicast, multicast i broadcast,
    • wymiany wsadowej i katalogów odbiorczych przez replikację plików,
    • wiadomości brokerowych przez MQTT,
    • danych monitorujących i trapów przez SNMP,
    • stanu rejestrów przemysłowych przez Modbus,
    • modeli informacji przemysłowej i bieżących wartości przez OPC UA,
    • cyklicznych danych sterowników przez CIP / EtherNet/IP.

    Platforma potrafi także udostępnić zreplikowaną zawartość w przyjaznej formie przez SFTP, SMB, NFS oraz wbudowany broker MQTT, a jednocześnie utrzymać certyfikaty, zaufanie, logowanie i cykl życia strumieni w jednym modelu administracyjnym.

    Dla organizacji budujących bezpieczny most między OT i IT najważniejszy wniosek jest prosty: Systegrate DiodeLink Console 1.0 to nie tylko narzędzie do obsługi data diode. To praktyczna warstwa replikacji, która zamienia jednokierunkowy transfer w użyteczne usługi dla utrzymania ruchu, inżynierii i odbiorców biznesowych.

  • Dwu‑węzłowy klaster HA dla serwerów brzegowych – przegląd podejść i rozwiązań

       W środowiskach brzegowych (edge) często mamy do dyspozycji tylko dwie maszyny w danej lokalizacji: ograniczenia kosztowe, energetyczne, miejsce w szafie, wymagania mobilne albo brak łączności pozwalającej na sensowne dostawienie trzeciego węzła.

       Jednocześnie oczekiwania względem wysokiej dostępności (HA) pozostają podobne jak w centrum danych: automatyczny failover, odporność na awarie sprzętu i/lub oprogramowania, kontrola split‑brain, szybki powrót do pracy.

       Problem polega na tym, że większość popularnych technologii HA (klastry, systemy rozproszone, bazy danych) jest projektowana pod (co najmniej) 3 węzły, aby osiągnąć kworum i bezpiecznie podejmować decyzje w sytuacjach niejednoznacznych (np. przy awarii sieci).

       W tym artykule zbieram praktyczne opcje dla klastra 2‑węzłowego: od klasycznych klastrów zasobów (Pacemaker), przez wirtualizację (Proxmox/Hyper‑V/VMware), po storage oraz bazy danych.

       Skupiam się na tym, co realnie działa, jakie są warunki brzegowe i gdzie czają się pułapki.

    Założenia: dwa węzły (Node A i Node B) w jednej lokalizacji, wymagany automatyczny failover, a aplikacje mogą działać jako usługa systemowa, VM lub kontenery.


    Dlaczego 2 węzły są trudne: split‑brain i kworum

       W klastrze dwuwęzłowym kluczowym problemem jest split‑brain: sytuacja, w której oba węzły uznają, że „ten drugi nie żyje” i jednocześnie próbują przejąć zasoby (IP, wolumen, rolę lidera, zapis do tej samej bazy itp.).

       W klastrach opartych o konsensus (Raft/Paxos) i w wielu produktach enterprise, wymaganie nieparzystej liczby głosów eliminuje część niejednoznaczności.

       Dwa węzły nie potrafią same rozstrzygnąć, „kto ma rację”, gdy komunikacja się urywa.

    Typowe strategie obejścia

    1. Świadek (witness / tie‑breaker / quorum device) – Dodajemy trzeci „głos”, ale nie jako pełny węzeł obliczeniowy. – Świadek może być:
      • małą VM (np. w chmurze),
      • urządzeniem w tej samej sieci (np. NAS),
      • usługą arbitrażu (qdevice),
      • komponentem storage (np. dysk świadek).
    2. Fencing (STONITH) + zasady preferencji – Jeśli węzły tracą kontakt, klaster musi umieć wyłączyć drugi węzeł lub odciąć mu dostęp do zasobów (zasilanie/IPMI, iDRAC/iLO, PDU, BMC, watchdog). – W edge bywa to problematyczne (brak zarządzalnego PDU, różny sprzęt).
    3. Active/Passive zamiast Active/Active – Upraszczamy architekturę: jeden węzeł aktywny, drugi w gotowości. – Często łatwiej o poprawność, kosztem mniejszej elastyczności.
    4. Asymetria / priorytety / „jeden węzeł zawsze wygrywa” – Możliwe, ale ryzykowne, jeśli nie ma twardego mechanizmu odcięcia dostępu do współdzielonych zasobów.

    Wymagania projektowe dla edge (praktyczne)

       Zanim wybierzesz technologię, warto sprecyzować kilka odpowiedzi:

    • Czy aplikacja toleruje chwilową niedostępność (sekundy/minuty)?
    • Czy dane są współdzielone (jeden wolumen), czy replikowane (kopie na obu węzłach)?
    • Czy możliwy jest świadek poza lokalizacją (np. mała instancja w chmurze, VPS)?
    • Czy masz fencing (IPMI/iLO/iDRAC, PDU) lub przynajmniej watchdog?
    • Czy HA dotyczy:
    • usług systemowych,
    • kontenerów,
    • maszyn wirtualnych,
    • storage,
    • bazy danych,
    • czy wszystkiego naraz?

    Podejście 1: klasyczny klaster zasobów (Pacemaker/Corosync)

    Open source: Pacemaker + Corosync (+ SBD/qdevice)

       To jeden z najbardziej dojrzałych i elastycznych stosów HA na Linuksie.

       Najczęstszy wzorzec w 2‑węzłowym układzie to:

    • Corosync jako warstwa komunikacji klastra,
    • Pacemaker jako manager zasobów (IP, usługi, promotable resources),
    • fencing/STONITH oraz/lub SBD (Storage Based Death) lub qdevice jako tie‑breaker.

    Dokumentacja i referencje: – Pacemaker: https://clusterlabs.org/pacemaker/ – Corosync: https://corosync.github.io/corosync/ – 

    Dokumentacja „ClusterLabs”: https://clusterlabs.org/ – SBD (stosowane m.in. przez SUSE): https://github.com/ClusterLabs/sbd – 

    corosync-qdevice (quorum device dla 2 węzłów): https://github.com/corosync/corosync-qdevice

    Zalety

    • Bardzo elastyczne: możesz „opakować” praktycznie dowolną usługę,
    • Działa świetnie w modelu active/passive,
    • W ekosystemie enterprise jest dobrze znane (SUSE, RHEL‑like),

    Wyzwania dla 2 węzłów

    • Musisz świadomie rozwiązać kworum (qdevice) albo zaimplementować fencing,
    • Bez fencingu łatwo o split‑brain, zwłaszcza przy wspólnym storage,

    Komercyjne / enterprise dystrybucje tego podejścia

    • SUSE Linux Enterprise High Availability Extension: https://www.suse.com/products/highavailability/
    • Red Hat High Availability Add‑On: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/high-availability

       W praktyce te rozwiązania nadal opierają się o Pacemaker/Corosync, ale dostajesz narzędzia, wsparcie i „utwardzone” scenariusze.


    Podejście 2: HA na poziomie wirtualizacji (2 hosty + witness)

       Jeśli Twoje aplikacje działają jako VM lub w kontenerze, często najprościej zapewnić HA na warstwie hypervisora.

    Proxmox VE (open source)

       Proxmox bazuje na klastrze corosync i do pełnego kworum standardowo preferuje minimum 3 głosy.

       Dla 2 węzłów typowym podejściem jest QDevice jako świadek.

    • Proxmox VE: https://www.proxmox.com/en/proxmox-virtual-environment/overview
    • Proxmox – dokumentacja klastra/Corosync/QDevice (szukaj: pvecm qdevice): https://pve.proxmox.com/pve-docs/

       Zaleta: zyskujesz HA poprzez start VM na drugim hoście

       Wada: nadal potrzebujesz trzeciego głosu (nawet jako mały świadek).

    VMware vSphere (komercyjne)

       VMware HA/DRS jest popularnym wyborem w data center.

       Często spotyka się konfiguracje 2‑hostowe (z różnymi kompromisami) oraz mechanizmy tie‑break (np. świadek dla storage / vSAN witness w scenariuszach ROBO).

    • vSphere High Availability: https://docs.vmware.com/en/VMware-vSphere/index.html
    • vSAN 2‑Node + Witness (koncepcja): https://core.vmware.com/vsan-2-node-cluster-guide

    Microsoft Hyper‑V Failover Cluster (komercyjne)

       Windows Server Failover Clustering potrafi działać w układach 2‑węzłowych ze świadkiem: File Share Witness lub Cloud Witness.

    • Failover Clustering: https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview
    • Cloud Witness: https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness

    W edge to bywa bardzo praktyczne: „trzeci głos” może być w chmurze i jest lekki.


    Podejście 3: replikacja danych + failover aplikacji (bez wspólnego storage)

       W edge często lepsze jest podejście „każdy ma swoje dyski”, a dane są replikowane.

       Wtedy split‑brain jest nadal groźny (dwa master’y), ale przestajesz mieć pojedynczy współdzielony wolumen, który łatwo uszkodzić.

    DRBD + Pacemaker (open source)

       DRBD replikuje blokowo dane pomiędzy węzłami i typowo pracuje jako active/passive (primary/secondary).

       Często łączy się go z Pacemakerem.

    • DRBD: https://linbit.com/drbd/
    • LINBIT (vendor, model open source + komercyjny): https://linbit.com/

       Dla 2 węzłów DRBD jest sprawdzonym wzorcem, ale trzeba dopilnować:

    • fencingu i/lub mechanizmów zapobiegających dual‑primary,
    • polityki promocji zasobu,
    • testów awarii łącza

    Replikacja na poziomie bazy danych

       Jeśli problem dotyczy głównie bazy danych, czasem lepiej zrobić HA w obrębie DB niż na poziomie całego serwera.

       Przykłady:

    • PostgreSQL: streaming replication + (np.) Patroni (częściej 3+), ale w 2 węzłach zwykle i tak potrzebujesz świadka lub zewnętrznego DCS. 
    • Patroni: https://patroni.readthedocs.io/
    • MySQL / MariaDB: asynchroniczna replikacja, Group Replication (zwykle 3+), Galera (zwykle 3+).
    • MariaDB Galera Cluster: https://mariadb.com/kb/en/galera-cluster/

    Podejście 4: Kubernetes na 2 węzłach (i co z control‑plane?)

       Kubernetes z definicji (etcd) przewiduje nieparzystą liczbę członków quorum.

       Dwuwęzłowy klaster „produkcyjny” jest możliwy, ale wymaga świadomego obejścia:

    • control‑plane może być pojedynczy (co obniża HA),
    • albo dwa control‑plane + zewnętrzny trzeci członek etcd (świadek) / zewnętrzny etcd,
    • albo zarządzany control‑plane poza lokalizacją (czasem nieakceptowalne w edge).

       Referencje: – etcd – quorum: https://etcd.io/docs/ – Kubernetes HA considerations (oficjalne docs): https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/


    Podejście 5: aktywne/aktywne na poziomie aplikacji (bez twardego failover)

       Czasem najlepsza opcja w 2‑węzłowym edge to… nie robić klasycznego klastra.

       Zamiast tego:

    • uruchamiasz aplikację aktywnie na obu węzłach,
    • a ruch rozkładasz przez load balancer lub DNS,
    • dane trzymasz w modelu „eventually consistent” lub z mechanizmem konfliktów.

       To podejście wymaga uwzględnienia na poziomie samej aplikacji, ale potrafi być bardziej odporne na problemy sieciowe, bo nie wymaga „jednego lidera” w każdej sytuacji.


    Dobre praktyki dla 2 węzłów (niezależnie od technologii)

    • Zawsze projektuj scenariusz awarii łącza (network partition), nie tylko awarii węzła
    • Zadbaj o tie‑breaker: qdevice / cloud witness / file witness / witness VM.
    • Jeśli masz wspólny storage, fencing jest obowiązkowy.
    • Automatyzuj testy HA:
      • odcięcie sieci,
      • reset węzła,
      • utrata storage,
      • powrót węzła do klastra.
    • Zbieraj metryki i logi klastra w jednym miejscu (w edge często offline‑friendly).

    Podsumowanie

    Dwuwęzłowy klaster HA jest jak „most wiszący na dwóch punktach” – da się, ale wymaga dodatkowego mechanizmu rozstrzygania (świadek) i/lub twardego odcięcia (fencing).

    Najbardziej praktyczne, powtarzalne wzorce w edge to:

    • 2 węzły + witness (cloud/VM/qdevice) – najczystsze podejście do kworum,
    • Pacemaker/Corosync + fencing/SBD dla usług linuksowych,
    • HA hypervisora dla środowisk opartych o VM,
    • DRBD dla replikacji danych bez współdzielonego storage.

    W 2‑węzłowych klastrach trzeba dodać trzeci element, który pomoże rozstrzygnąć, który węzeł powinien pozostać aktywny, nawet jeśli to będzie człowiek, administrator 🙂

    W kolejnych artykułach postaram się przybliżyć rozwiązanie opracowane przez nasz zespół specjalnie dla serwerów brzegowych

    Rozwiązanie Systegrate HA cluster łączy kilka z powyższych podejść w spójną całość, pozwalając: – trzymać stan w key=value store, – przełączać klaster HA – zapewniać sposoby radzenia sobie w sytuacjach awaryjnych

    Bibliografia i dalsza lektura

    [1] https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview

    [2] https://clusterlabs.org/pacemaker/

    [3] https://etcd.io/docs/

    [4] https://clusterlabs.org/

    [5] https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

    [6] https://clusterlabs.org/pacemaker/doc/

    [7] https://corosync.github.io/corosync/

    [8] https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness

    [9] https://pve.proxmox.com/pve-docs/

    [10] https://github.com/corosync/corosync-qdevice

    [11] https://core.vmware.com/vsan-2-node-cluster-guide

    [12] https://linbit.com/drbd/

    [13] https://patroni.readthedocs.io/

    [14] https://github.com/ClusterLabs/sbd

    [15] https://www.suse.com/products/highavailability/

    [16] https://mariadb.com/kb/en/galera-cluster/

    [17] https://www.cs.cornell.edu/home/rvr/papers/OSDI04.pdf

    [18] https://medium.com/@johanesmistrialdo/simple-2-node-kubernetes-deployment-with-kubeadm-bb9b3385b950

    UWAGA: Powyższy artykuł został opracowany z wykorzystaniem narzędzi AI w celu wsparcia procesu pisania i redakcji treści.