Below video explain download and installation process of Systegrate DiodeLink Console™.

Below video shows how to setup SMB feature in Systegrate DiodeLink Console™

DiodeLink Console 1.0 – New Release

A practical way to move industrial and operational data from OT to IT through a hardware-enforced one-way path—without turning every integration project into a custom engineering effort.

For many industrial teams, the real challenge is not collecting data. It is moving that data safely out of protected environments and into reporting, analytics, monitoring, historian, or enterprise systems. Systegrate DiodeLink Console 1.0 addresses exactly that problem. It combines one-way transfer enforced by a physical data diode with a clear administration model for streams, certificates, file exchange, and service operations.

In practice, the platform runs as a pair of services: a Sender on the OT side and a Receiver on the IT side. The Sender reads data from local sources, the diode allows traffic to travel in one direction only, and the Receiver reconstructs or republishes the data for downstream consumers. That model allows teams to keep segmentation strong while still making operational data usable.

How it works in one glance

Figure 1. DiodeLink Console operates as a Sender/Receiver pair around a hardware data diode, carrying data from OT to IT without a reverse channel.

The operating model is intentionally straightforward. Each node has a diode-side interface and a separate data or management interface. Administrators create a stream once per use case, use the same stream ID on both nodes, start the stream, and then verify status, metrics, and logs. The command-line interface, diodecmd, is the control surface for stream lifecycle, optional features, certificate handling, and license operations.

What stands out in DiodeLink Console 1.0

Hardware-enforced directionality

Traffic flows from Sender to Receiver only. The user manuals consistently position the diode link as the only path between OT and IT zones.

Seven replication stream types

UDP, Files, MQTT, SNMP, Modbus, OPC UA, and CIP cover the most common operational data exchange patterns.

Built-in file access options

SFTP, SMB, and NFS features let teams present replicated files in forms that Linux and Windows operators already understand.

Built-in MQTT broker option

The MQTT feature can enable a Mosquitto-based broker, create the default replication stream, and secure client access with TLS or mutual TLS.

Security administration included

Certificate import, trust-store maintenance, client certificate generation, and CRL handling are part of the standard administration model.

Operational visibility

Stream status, live metrics, logs, export/import, and table or JSON output help administrators standardize operations and troubleshooting.

Replication streams: the real value of the platform

DiodeLink Console is not just a transport tunnel. Its value comes from how it turns different OT data patterns into repeatable, one-way replication services. Instead of forcing every source to behave the same way, it provides protocol-specific stream models.

Stream type	How it works	Typical result on the IT side
UDP	The Sender listens for packets and forwards them through the diode. The Receiver forwards them to a configured destination. Unicast, multicast, and broadcast patterns are supported.	A downstream application receives the same packet flow on the expected host, group, or target network.
Files	The platform watches a managed directory tree, applies include/exclude masks and retry logic, and moves files through the one-way path.	Replicated files become available to IT-side users or processes, optionally exposed through SFTP, SMB, or NFS.
MQTT	The Sender subscribes to a source broker topic, transfers messages one-way, and the Receiver publishes them to a destination broker. QoS and authenticated TLS setups are supported.	IT-side clients can consume mirrored MQTT topics locally or through the built-in broker.
SNMP	The Sender reads SNMP data and trap events from a source agent. The Receiver feeds a mirror agent on the IT side.	Monitoring tools can query an IT-side SNMP endpoint instead of reaching back into OT.
Modbus	The Sender polls selected registers, coils, inputs, or ranges from OT devices. The Receiver exposes the replicated state through Modbus TCP or RTU.	SCADA, MES, or historians can read a local Modbus replica as if it were a nearby device.
OPC UA	The Sender performs discovery and sends ordered frames for metadata, values, and diagnostics. The Receiver rebuilds a read-only virtual OPC UA server.	IT-side OPC UA clients can browse and read a structured replica without direct OT connectivity.
CIP / EtherNet/IP	The Sender captures cyclic implicit I/O from OT-side PLCs. The Receiver acts as a local edge server for IT-side PLC clients, with plain or secure TLS/DTLS modes.	Replicated cyclic I/O reaches IT-side PLC consumers while keeping OT isolation intact.

Why these stream models matter

Each stream solves a different integration problem:

• UDP fits telemetry, syslog-style messages, PLC broadcasts, and lightweight sensor traffic.
• Files fit document exchange, batch data export, reports, recipes, and hand-off workflows between teams or systems.
• MQTT fits event-driven OT/IIoT data and broker-based integration patterns.
• SNMP fits network or device monitoring when the IT side needs visibility without direct device access.
• Modbus fits classic industrial register replication for SCADA and historian use cases.
• OPC UA fits structured, browsable industrial information models and diagnostics.
• CIP fits cyclic industrial controller data flows used in EtherNet/IP environments.

That breadth is important. Many organizations do not have just one data pattern in OT. They have several, and they need a platform that can standardize how those patterns cross a one-way boundary.

Security and administration without side tools

The user manuals show a platform designed for operations, not only for deployment day. Administrators can enable optional features, create shares, rotate or replace certificates, manage trust and revocation lists, generate client certificates for mutual TLS, and export or import stream definitions. For teams that need consistent procedures, this matters as much as raw protocol coverage.

Another practical detail is licensing. The documented workflow includes a built-in 180-day trial, request/import steps for full licenses, and support for hardware-bound, software-bound, or hostname-bound assignment models. That makes lab rollout, validation, and production conversion easier to plan.

Ready to explore it in your own environment? Now is a particularly good time to do it. Trial software can be requested here: https://systegrate.com/#request-trial. For a limited time, the trial period is 180 days.

Summary: what replication is possible?

DiodeLink Console 1.0 can replicate:

• packet-based traffic through UDP in unicast, multicast, and broadcast scenarios,
• batch and drop-zone workflows through file replication,
• brokered messages through MQTT,
• monitoring data and traps through SNMP,
• industrial register state through Modbus,
• industrial information models and live values through OPC UA,
• cyclic controller I/O through CIP / EtherNet/IP.

It can also present replicated content in operator-friendly ways through SFTP, SMB, NFS, and a built-in MQTT broker, while keeping certificate, trust, logging, and stream lifecycle tasks under one administration model.

For organizations building a secure OT-to-IT bridge, that is the key takeaway: Systegrate DiodeLink Console 1.0 is not only a management tool for a data diode. It is a practical replication layer that translates one-way transfer into usable services for operations, engineering, and enterprise consumers.

Goal and context

In edge environments, we often only have two machines available in a given location: cost and power constraints, limited rack space, mobility requirements, or the lack of connectivity that would make adding a third node realistic.

At the same time, expectations around high availability (HA) are similar to those in a data center: automatic failover, resilience to hardware and/or software failures, split‑brain control, and fast recovery.

The challenge is that most popular HA technologies (clusters, distributed systems, databases) are designed for (at least) 3 nodes to achieve quorum and make safe decisions in ambiguous situations (for example, during network partitions).

In this article I collect practical options for a two‑node cluster: from classic resource clusters (Pacemaker), through virtualization (Proxmox/Hyper‑V/VMware), to storage and databases.

I focus on what actually works in the field, what the boundary conditions are, and where the traps are.

Assumptions: two nodes (Node A and Node B) in a single location, automatic failover required, and workloads can run as a system service, VM, or containers.

---

Why two nodes are hard: split‑brain and quorum

In a two‑node cluster, the key risk is split‑brain: a situation where both nodes decide “the other one is down” and both try to take over resources at the same time (VIP, volume, leader role, writes to the same database, etc.).

In consensus‑based systems (Raft/Paxos) and many enterprise products, requiring an odd number of votes eliminates part of the ambiguity.

Two nodes cannot, on their own, decide “who is right” when communication breaks.

Common mitigation strategies

1. Witness (tie‑breaker / quorum device) – We add a third “vote”, but not as a full compute node. – A witness can be:

   • a small VM (for example in the cloud),
   • a device in the same network (for example a NAS),
   • an arbitration service (qdevice),
   • a storage component (for example a witness disk).

2. Fencing (STONITH) + preference rules – When nodes lose contact, the cluster must be able to power off the other node or otherwise cut its access to resources (power/IPMI, iDRAC/iLO, PDU, BMC, watchdog). – In edge deployments this can be difficult (no managed PDU, heterogeneous hardware).

3. Active/Passive instead of Active/Active – We simplify the architecture: one node active, the other on standby. – This is often easier to get right, at the cost of reduced flexibility.

4. Asymmetry / priorities / “one node always wins” – Possible, but risky if there is no hard mechanism to remove access to shared resources.

---

Practical edge design questions

Before you pick a technology, it’s helpful to answer a few questions:

• Does the application tolerate brief downtime (seconds/minutes)?
• Are the data shared (single volume) or replicated (copies on both nodes)?
• Can you place a witness outside the site (for example a small cloud instance / VPS)?
• Do you have fencing (IPMI/iLO/iDRAC, PDU) or at least a watchdog?
• Does HA cover:
• system services,
• containers,
• virtual machines,
• storage,
• databases,
• or all of the above?

---

Approach 1: classic resource cluster (Pacemaker/Corosync)

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

This is one of the most mature and flexible HA stacks on Linux.

A common two‑node pattern is:

• Corosync as the cluster communication layer,
• Pacemaker as the resource manager (VIPs, services, promotable resources),
• fencing/STONITH and/or SBD (Storage Based Death) or qdevice as a tie‑breaker.

Documentation and references: – Pacemaker: https://clusterlabs.org/pacemaker/ – Corosync: https://corosync.github.io/corosync/ – “ClusterLabs” docs: https://clusterlabs.org/ – SBD (used for example by SUSE): https://github.com/ClusterLabs/sbd – corosync-qdevice (quorum device for 2 nodes): https://github.com/corosync/corosync-qdevice

Advantages

• Very flexible: you can “wrap” almost any service.
• Works great in an active/passive model.
• Well known in enterprise ecosystems (SUSE, RHEL‑like).

Two‑node challenges

• You must intentionally solve quorum (qdevice) or implement strong fencing.
• Without fencing, split‑brain is easy—especially with shared storage.

Commercial / enterprise distributions of this approach

• 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

In practice these solutions still rely on Pacemaker/Corosync, but you get tooling, support, and hardened scenarios.

---

Approach 2: HA at the virtualization layer (2 hosts + witness)

If your workloads run as VMs, it’s often simplest to provide HA at the hypervisor layer.

Proxmox VE (open source)

Proxmox uses corosync for cluster membership and typically expects at least 3 votes for full quorum.

For 2 nodes, a typical approach is QDevice as a witness.

• Proxmox VE: https://www.proxmox.com/en/proxmox-virtual-environment/overview
• Proxmox cluster/Corosync/QDevice docs (search for pvecm qdevice): https://pve.proxmox.com/pve-docs/

Benefit: you get HA by restarting VMs on the other host.

Drawback: you still need a third vote (even as a small witness).

VMware vSphere (commercial)

VMware HA/DRS is a common choice in data centers.

Two‑host configurations are also used at the edge (with various trade‑offs), plus tie‑break mechanisms (for example witness for storage / vSAN witness in ROBO scenarios).

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

Microsoft Hyper‑V Failover Cluster (commercial)

Windows Server Failover Clustering supports two‑node setups with a witness: File Share Witness or 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

At the edge this is often very practical: the “third vote” can be in the cloud and is lightweight.

---

Approach 3: data replication + application failover (no shared storage)

At the edge, the “each node has its own disks” approach is often better, and data are replicated.

Split‑brain is still dangerous (two primaries), but you no longer have a single shared volume that’s easy to corrupt.

DRBD + Pacemaker (open source)

DRBD replicates block devices between nodes and is typically used as active/passive (primary/secondary).

It is often combined with Pacemaker.

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

For two nodes, DRBD is a proven pattern, but you must take care of:

• fencing and/or mechanisms that prevent dual‑primary,
• resource promotion policy,
• network partition testing.

Database‑level replication

If the main problem is the database, sometimes it’s better to build HA within the DB layer than across the whole server.

Examples (briefly):

• PostgreSQL: streaming replication + (for example) Patroni (more commonly 3+), but with 2 nodes you usually still need a witness or an external DCS.
• Patroni: https://patroni.readthedocs.io/
• MySQL / MariaDB: async replication, Group Replication (usually 3+), Galera (usually 3+).
• MariaDB Galera Cluster: https://mariadb.com/kb/en/galera-cluster/

---

Approach 4: Kubernetes on two nodes (and what about the control plane?)

Kubernetes (etcd) assumes an odd number of quorum members.

A “production” two‑node cluster is possible, but requires conscious trade‑offs:

• control plane can be single‑node (reducing HA),
• or two control‑plane nodes + a third external etcd member (witness) / external etcd,
• or a managed control plane outside the site (sometimes unacceptable for edge).

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

---

Approach 5: active/active at the application level (no hard failover)

Sometimes the best option in a two‑node edge scenario is… not to build a classic cluster.

Instead:

• you run the application actively on both nodes,
• distribute traffic via a load balancer or DNS,
• keep data in an “eventually consistent” model or with conflict resolution.

This approach is harder for applications, but can be more tolerant to network issues, because it doesn’t require “a single leader” in every situation.

---

Good practices for two‑node setups (regardless of technology)

• Always design for network partitions, not just node failures.
• Use a tie‑breaker: qdevice / cloud witness / file share witness / witness VM.
• If you use shared storage, fencing is mandatory.
• Automate HA tests:
• cutting network,
• resetting a node,
• losing storage,
• rejoining the node back to the cluster.
• Collect cluster metrics and logs in one place (edge is often offline‑friendly).

---

Summary

A two‑node HA cluster is like a “bridge suspended on two points”: it can be done, but it needs an additional decision mechanism (witness) and/or a hard cut‑off (fencing).

The most practical, repeatable patterns at the edge are:

• 2 nodes + witness (cloud/VM/qdevice) — the cleanest approach to quorum,
• Pacemaker/Corosync + fencing/SBD for Linux services,
• hypervisor HA for VM‑based environments,
• DRBD for data replication without shared storage.

In two‑node clusters, you need to add a third element that helps decide which node should remain active—even if that third element is a human administrator 🙂

In upcoming articles I’ll try to describe a solution developed by our team specifically for edge servers.

The Systegrate HA cluster solution combines several of the above approaches into a coherent whole, allowing you to: – keep state in a key=value store, – fail over the HA cluster, – provide ways of handling emergency situations.

—

References and further reading

[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

NOTE: This article was prepared with the use of AI tools to support the writing and editing process.