Zehn Standorte, jeder mit eigenem Serverraum und eigener KVM-over-IP-Lösung, keine gemeinsame Übersicht. So sieht der Alltag vieler IT-Teams aus. Die Frage ist dabei selten, ob KVM-over-IP eingeführt wird. Wichtiger ist, wie zentral oder wie verteilt die Verwaltung dahinter organisiert ist.
Drei Architekturmuster stehen zur Wahl: eine zentrale Primär-Sekundär-Struktur mit Redundanz, eine rein lokale Verwaltung je Standort und ein Mischmodell mit zentraler Konfiguration und lokalen Gruppen. Wenige Standorte mit stabiler Anbindung fahren zentral besser, viele kleine Standorte mit schwankender Bandbreite brauchen lokale Handlungsfähigkeit.
KVM-over-IP zentral oder verteilt: die Architekturfrage
| Muster | Wie es arbeitet | Stärke | Schwachstelle |
|---|---|---|---|
| Zentral mit Redundanz | Primärserver plus bis zu fünf Sekundärserver | einheitliche Rechteverwaltung, automatische Umschaltung | zentrale Instanz bleibt gemeinsamer Ausfallpunkt |
| Rein lokal je Standort | jeder Standort verwaltet sich selbst | funktioniert auch ohne WAN | jede Änderung mehrfach pflegen |
| Zentrale Konfiguration, lokale Gruppen | Master verwaltet, Gateway reicht Konsolenzugriff lokal durch | wenig WAN-Last, lokale Handlungsfähigkeit | komplexere Ersteinrichtung |
ATEN setzt bei seiner CCKM-Lösung auf eine Primär-Sekundär-Architektur mit bis zu fünf redundanten Sekundär-Servern (ATEN, 2026). Fällt der primäre Server aus, übernimmt automatisch ein sekundärer. Das ist im Kern eine zentrale Architektur mit eingebauter Redundanz, kein rein verteiltes Modell.
Für IT-Betrieb und Rechenzentrumsverantwortliche in Industrie und Handel ist diese Unterscheidung mehr als eine technische Feinheit. Sie entscheidet darüber, wie ein Team auf einen Ausfall reagiert. Bei einer zentralen Architektur greift im Idealfall eine automatische Umschaltung, bei einem verteilten Modell muss jeder Standort im Ernstfall auch ohne Verbindung zur Zentrale funktionsfähig bleiben.
Wie unterschiedlich Hersteller das Problem lösen
Bei sehr großen Flotten zählt vor allem die Skalierbarkeit der Verwaltungsoberfläche. Der Anbieter Kinan gibt für sein System IPK600 an, bis zu 9.999 Knoten über eine einzige Web-Oberfläche verwalten zu können (Kinan, 01/2025). Das zeigt, wie groß der adressierte Markt inzwischen gedacht wird, auch wenn die meisten Betriebe in Industrie und Handel deutlich kleinere Flotten betreiben.
Auf Geräteebene sieht die Rechnung anders aus. Raritans Dominion KX III erlaubt je nach Modell ein bis acht simultane Nutzer für acht bis 64 Server pro Gerät (Raritan, 2026). Das Gerät selbst bildet also nur einen Baustein der Flotte, die eigentliche Verwaltung mehrerer solcher Geräte über Standorte hinweg braucht eine zusätzliche Softwareebene darüber.
Das Modell mit lokalen Gruppen und zentralem Gateway
SynergyCP verfolgt einen dritten Weg. Ein zentraler Master verwaltet die Konfiguration, während an jedem Standort eigene IP-Groups arbeiten und ein BMC-Forwarding-Gateway den eigentlichen Konsolenzugriff durchreicht (SynergyCP, 2026). Der Charme dieses Modells liegt darin, dass der Datenverkehr für die Konsolensitzung selbst lokal bleibt und nur die Steuerungsbefehle über die zentrale Instanz laufen. Für Umgebungen mit vielen kleinen Standorten und begrenzter WAN-Bandbreite ist das oft der praktikablere Ansatz.
Warum Edge-Standorte die Anforderungen verschieben
der befragten Organisationen nutzen bereits Edge Computing, also Rechenkapazität außerhalb des zentralen Rechenzentrums. Jeder dieser Standorte bringt Server mit, die verwaltet werden müssen, oft ohne IT-Personal vor Ort.
Vertiv, 2022
Ein Unternehmen mit fünf Produktionsstandorten bekommt diese Abwägung ganz praktisch zu spüren. Ein reines Vor-Ort-Modell mit eigener Verwaltung je Standort skaliert schlecht, weil jede Änderung an Zugriffsrechten oder Firmware fünfmal einzeln gepflegt werden muss. Eine rein zentrale Lösung ohne lokale Pufferung wiederum leidet, sobald die WAN-Verbindung zu einem Standort schwach oder instabil ist.
Hinzu kommt, dass Edge-Standorte selten identisch ausgestattet sind. Ein Werk hat vielleicht zehn Server, eine Filiale nur zwei, ein Logistikzentrum wieder eine ganz andere Mischung aus Herstellern und Baujahren. Eine Flottenverwaltung muss diese Unterschiede abbilden können, statt allen Standorten dieselbe starre Konfiguration überzustülpen.
Welche Architektur passt zu Ihrer Standortstruktur?Nennen Sie uns Zahl der Standorte, Serverzahl je Standort und die WAN-Anbindung. Wir sagen Ihnen, welches der drei Muster trägt.
Eine Flotte statt einzelner Inseln verwalten
KVM Fleet setzt genau an dieser Abwägung an und bietet eine zentrale Übersicht über alle Server und Standorte, ohne dass jede einzelne Konsolensitzung zwingend über eine zentrale Instanz geleitet werden muss. Für Teams, die von einzelnen, unverbundenen KVM-Insellösungen kommen, ist das oft der erste Schritt zu einer tatsächlich planbaren Flotte. Wie sich dabei auch die Firmware über alle angeschlossenen Server hinweg pflegen lässt, beschreibt der Beitrag zu Firmware-Updates über hunderte Server. Die Grundlagen des Zugriffswegs stehen im Beitrag zum Out-of-Band-Management.
Häufige Fragen
Sollte man KVM-over-IP zentral oder je Standort verwalten?
Das hängt von der Zahl der Standorte, der Qualität der WAN-Anbindung und davon ab, wie kritisch ununterbrochener Zugriff ist. Wenige Standorte mit stabiler Anbindung profitieren meist von einer zentralen Lösung mit einheitlicher Rechteverwaltung. Viele kleine Standorte mit schwankender Bandbreite fahren oft besser mit lokalen Gruppen, die auch bei einer gestörten WAN-Verbindung funktionsfähig bleiben.
Wie viel Bandbreite braucht KVM-over-IP im Flottenbetrieb?
Der Bandbreitenbedarf hängt stark davon ab, ob nur die Steuerung oder auch die volle Bildschirmübertragung über das WAN läuft. Modelle wie das SynergyCP-Gateway halten den eigentlichen Konsolenverkehr lokal und reduzieren dadurch die WAN-Last deutlich gegenüber einer Architektur, bei der jede Sitzung zentral geroutet wird.
Wie bindet man ältere KVM-Geräte in eine neue Flottenverwaltung ein?
Die meisten etablierten Hersteller, darunter ATEN und Raritan, bieten für ihre älteren KVM-over-IP-Geräte weiterhin unterstützte Schnittstellen an. In der Praxis lohnt sich vor der Einführung eine Bestandsaufnahme, welche Modelle im Einsatz sind und welche Protokolle sie unterstützen, bevor eine Flottenlösung ausgewählt wird.
Der nächste Schritt
Bei torck baut das eigene Entwicklungsteam KVM Fleet für genau dieses Problem, verteilte Standorte zentral und trotzdem ausfallsicher zu verwalten. Die Erfahrung stammt aus dem eigenen Betrieb in Maxhütte-Haidhof, Wien und Rabat, wo mehrere Standorte über eine gemeinsame Oberfläche laufen. Mehr zur Software gibt es auf der Produktseite.
German 
English 
French