HCI-Server: Funktionsweise und Aufbau einfach erklärt

Wenn ein Kunde anruft und mitten im Satz stöhnt, weil er „schon wieder ein neues Speicherarray einplanen muss, während die VM-Hosts noch nicht mal ausgelastet sind", dann ist das in neun von zehn Fällen der Moment, in dem wir über hyperkonvergente Infrastrukturen sprechen. Die Funktionsweise und Vorteile einer solchen HCI-Architektur lassen sich am besten an genau solchen Support-Tickets erklären, weil dort sofort sichtbar wird, wo klassische Drei-Schichten-Setups an ihre Grenzen stoßen. In diesem Artikel nehme ich Sie mit durch den Aufbau eines HCI-Clusters, zeige, welche Komponenten wirklich zwingend nötig sind, und erkläre, welche Stolperfallen mir in der Praxis immer wieder begegnen.

Was eine hyperkonvergente Infrastruktur von klassischen Setups unterscheidet

In einer konventionellen IT-Landschaft stehen drei Welten nebeneinander: Rechenleistung in Form von Servern, Speicher in einem separaten SAN oder NAS, und ein Netzwerk-Layer mit eigenen Switches, VLANs und Routing-Logiken. Jede dieser Welten hat ihr eigenes Management, eigene Lizenzmodelle und eigene Spezialisten. Genau das ist der Punkt, an dem viele Kunden anrufen: weil die Komplexität irgendwann nicht mehr beherrschbar ist und einzelne Silos gegeneinander arbeiten.

Eine hyperkonvergente Infrastruktur – kurz HCI – bricht diese Trennung konsequent auf. Rechenleistung, Speicher und Netzwerkfunktionen werden in einem softwaredefinierten System auf Standard-x86-Servern zusammengeführt und über eine einzige Schnittstelle zentral verwaltet. Das bedeutet für die Praxis: Wo früher drei Administrationswerkzeuge, drei Verträge und drei Wartungsfenster koordiniert werden mussten, gibt es jetzt ein Cluster, eine Konsole und ein konsistentes Lifecycle-Management. Gerade in mittelständischen Rechenzentren, in denen ein einzelner Administrator für 80 VMs und 40 Terabyte Speicher verantwortlich ist, macht das einen spürbaren Unterschied im Alltag.

HCI ist kein neues Hardwareprodukt, sondern eine Architekturentscheidung: Speicher wandert aus dem SAN zurück in die Server und wird von Software verwaltet.

Die drei Säulen im HCI-Stack: Hypervisor, SDS und SDN

Damit eine hyperkonvergente Infrastruktur tatsächlich funktioniert, müssen drei softwaredefinierte Schichten sauber zusammenspielen. Wenn nur eine davon fehlt oder unzureichend dimensioniert ist, bricht das Konzept früher oder später ein – das erleben wir im Support regelmäßig, wenn Kunden mit „HCI-Edition" beworbene Server kaufen, aber nur einen Hypervisor installieren.

Die erste Säule ist der Hypervisor. Er stellt die virtualisierten Rechenressourcen bereit, auf denen die VMs und Container laufen. Hier kommen in der Regel VMware vSphere, Microsoft Hyper-V oder zunehmend auch KVM-basierte Lösungen zum Einsatz. Der Hypervisor entscheidet, wie viele vCPUs und wie viel Arbeitsspeicher eine Arbeitslast bekommt, und kümmert sich um die Live-Migration laufender VMs zwischen den Nodes.

Die zweite Säule ist der softwaredefinierte Speicher, das sogenannte SDS (Software-Defined Storage). Er ist das Herzstück der HCI-Architektur, denn er pooled die lokalen Festplatten und SSDs aller Nodes zu einem gemeinsamen Datenspeicher. Jeder Node trägt einen Teil seiner Kapazität zum Cluster bei, und das SDS verteilt die Daten intelligent über alle Knoten. Fällt ein Node aus, bleiben die VMs erreichbar, weil das SDS die Daten redundant vorhält und die Replikate automatisch weiter bedient.

Die dritte Säule ist das softwaredefinierte Netzwerk, das SDN (Software-Defined Networking). Es übernimmt die Aufgaben klassischer Switches: VLANs, Lastverteilung, Mikrosegmentierung und teilweise auch das Routing zwischen virtuellen Maschinen. Damit lässt sich Netzwerktopologie komplett in Software abbilden, ohne dass jeder VM-Host einzeln konfiguriert werden muss. Das bedeutet für die Praxis, dass neue Netzwerksegmente in Minuten statt in Tagen bereitstehen, weil kein physisches Patchen mehr nötig ist.

Nodes als Fundament: Warum drei Knoten die Untergrenze sind

Wer einen HCI-Cluster plant, stellt schnell fest, dass die Mindestanzahl der physischen Server-Knoten – der Nodes – nicht verhandelbar ist. In Standard-Enterprise-Setups sind drei Nodes das absolute Minimum, und das hat einen sehr konkreten technischen Hintergrund: das Quorum. Jede Clusterentscheidung, ob bei einem Failover, einer Replikation oder einer Schreiboperation, erfordert eine Mehrheit unter den Knoten. Bei zwei Nodes gibt es im Split-Brain-Fall – wenn beide Knoten gleichzeitig ausfallen oder die Netzwerkverbindung zwischen ihnen reißt – keine klare Mehrheit mehr, und das Cluster kann sich nicht entscheiden, welche Datenkopie als konsistent gelten soll.

Mit drei Nodes ist das Problem gelöst: Zwei Knoten bilden eine Mehrheit, der dritte dient als Tie-Breaker. Selbst wenn ein Node komplett ausfällt, bleiben die übrigen zwei in der Lage, das Cluster konsistent weiterzuführen. In Edge- oder ROBO-Umgebungen – also kleinen Außenstellen – arbeiten manche Hersteller mit Zwei-Node-Konfigurationen plus einem externen Witness-Dienst, der die Schiedsrichterfunktion übernimmt. Das funktioniert, ist aber architektonisch komplexer und sollte nur gewählt werden, wenn wirklich keine dritte Maschine vor Ort untergebracht werden kann.

Die Skalierung erfolgt horizontal, also durch das Hinzufügen weiterer Nodes. Jeder neue Knoten bringt Rechenleistung, Arbeitsspeicher und Speicherkapazität mit, und das Cluster wächst linear. In Microsofts Azure Stack HCI sind je nach Edition bis zu 16 Knoten pro Cluster möglich, andere Hersteller erlauben deutlich mehr. Was die maximale Anzahl angeht, hängt sie stark vom jeweiligen Software-Stack ab – eine universelle Obergrenze gibt es nicht, weshalb ich hier keine pauschale Zahl nennen möchte.

Ein Punkt, der in der Praxis oft unter den Tisch fällt: die Platzierung der Knoten innerhalb der physischen Infrastruktur. HCI-Systeme bieten Fault Domains, also logische Gruppierungen von Nodes, die einem gemeinsamen Ausfallrisiko unterliegen – etwa einer gemeinsamen Stromversorgung, einem gemeinsamen Rack oder einem Switch-Stack. Wer drei Nodes in einem einzigen Rack mit nur einer USV betreibt, kann formal drei Knoten vorweisen, de facto aber nur eine Fehlertoleranz. Die Storage-Policy rechnet zwar Replication Factors sauber durch, aber gegen einen Stromausfall auf Rack-Ebene hilft auch der beste Software-Stack nichts. Deshalb gehört zur Knotenplanung immer auch die Frage: Welche Nodes teilen sich welche Infrastruktur, und wie verteile ich die Fault Domains so, dass ein einzelner Ausfall nicht alle Replikate gleichzeitig trifft?

Rechenleistung richtig dimensionieren: Overhead und Auslastung im Blick

Ein Aspekt, der in Vertriebspräsentationen gern unter den Tisch fällt, ist der systembedingte Ressourcen-Overhead einer HCI-Umgebung. Wer die gleiche Hardware in einer klassischen Drei-Schichten-Architektur betreibt, hat mehr nutzbare Ressourcen als in einem HCI-Cluster – das ist eine einfache mathematische Realität. Der Hypervisor selbst beansprucht etwa fünf Prozent der CPU-Leistung pro Node, der virtuelle Storage-Controller kommt zusätzlich auf rund zehn Prozent CPU- und RAM-Last. Diese Werte variieren je nach Hersteller und Workload, liegen aber erfahrungsgemäß in dieser Größenordnung.

Das bedeutet für die Praxis, dass die tatsächlich für VMs verfügbare Rechenleistung spürbar unter der Bruttoleistung der Hardware liegt. Wer einen Node mit zwei 24-Kern-Prozessoren kauft, bekommt nicht 48 Kerne für VMs, sondern real eher 38 bis 40 – der Rest geht an Hypervisor, Storage-Controller und Systemdienste. Diese Lücke muss beim Sizing einkalkuliert werden, sonst läuft das Cluster früher als erwartet in eine Engpasssituation.

Neben dem Overhead ist die empfohlene maximale Auslastung ein weiterer Faktor. Als Faustregel aus dem Support hat sich bewährt, einen Node dauerhaft nicht über 60 bis 70 Prozent auszulasten. Der Grund ist einfach: Bei einem Ausfall muss ein verbleibender Knoten die Last des ausgefallenen übernehmen, und dafür braucht es freie Kapazität. Wer ein Cluster dauerhaft am Anschlag betreibt, riskiert, dass beim Failover eines Nodes die verbleibenden Knoten überlastet werden und selbst in Performance-Probleme rutschen. N+1-Failover-Kapazität und Wachstumspuffer sollten immer eingeplant werden, gerade wenn neue Anwendungen oder Abteilungen hinzukommen.

Datensicherheit ohne RAID-Controller: Storage Policies im Detail

In klassischen Server-Setups kümmert sich der RAID-Controller um Redundanz: RAID 5, RAID 6 oder RAID 10 sind die typischen Konfigurationsmuster. Bei HCI entfällt diese hardwarebasierte Logik. Stattdessen übernehmen softwaredefinierte Speicherrichtlinien, die sogenannten Storage Policies, die Absicherung der Daten. Das ist mehr als nur eine andere Schreibweise desselben Konzepts – es ist ein grundlegend anderer Ansatz.

Die einfachste Form ist der Replikationsfaktor (Replication Factor, RF). RF2 bedeutet, dass jede geschriebene Datei zweimal im Cluster vorhanden ist – einmal als Original auf dem schreibenden Knoten und einmal als Replikat auf einem zweiten Knoten. Bei RF3 entstehen drei Kopien, also das Original auf Node 1 plus zwei zusätzliche Replikate auf zwei weiteren Knoten, sodass insgesamt drei Kopien vorgehalten werden. Bei RF2 darf ein Node ausfallen, ohne dass Daten verloren gehen – schon RF2 genügt für die meisten Produktivworkloads. RF3 wird für kritische Daten gewählt, bei denen selbst der Ausfall eines zweiten Knotens überlebt werden muss. In Clustern mit drei oder vier Nodes ist RF2 der Standard, weil die Kosten für dreifache Speicherung erst ab einer gewissen Clustergröße wirtschaftlich sinnvoll werden.

Die zweite Variante ist Erasure Coding, eine rechnerische Redundanz, die Speicherplatz effizienter nutzt als reine Replikation. Ähnlich wie bei RAID 5 oder RAID 6 werden Paritätsinformationen über mehrere Nodes verteilt, sodass der Ausfall einzelner Knoten kompensiert werden kann, ohne dass jede Datei vollständig dupliziert wird. Das spart Kapazität und wird deshalb häufig für Archivdaten oder Backup-Workloads genutzt, während produktive VMs eher mit Replikation laufen, weil die Performance dort wichtiger ist als die Platzeffizienz. Erasure Coding kostet allerdings CPU-Zeit, weil jede Schreiboperation die Paritätsberechnung anstößt – bei datenintensiven Workloads mit vielen kleinen Schreibvorgängen kann das zum versteckten Engpass werden, den man erst im Betrieb bemerkt.

Was im Support immer wieder zu Verwirrung führt: HCI ersetzt nicht das Backup. Die Replikation schützt vor Hardwareausfällen, nicht vor versehentlichem Löschen, Ransomware oder logischer Korruption. Wer eine VM im Cluster löscht, ist sie auch in der Replikation los. Snapshots und klassische Backup-Strategien bleiben Pflicht, unabhängig davon, wie robust das Storage-Policy-Setup ist. Diese Lektion haben viele Kunden schmerzhaft lernen müssen, weshalb ich sie hier ausdrücklich erwähne.

Netzwerkbandbreite: Warum 10 GbE das Minimum ist

Ein HCI-Cluster lebt vom Datenaustausch zwischen den Nodes. Wenn VM A auf Node 1 eine Datei schreibt, hält das SDS unter einer RF2-Policy genau eine zusätzliche Kopie dieser Datei auf einem zweiten Knoten vor – etwa auf Node 2. Das Original auf Node 1 und das Replikat auf Node 2 ergeben die zwei Kopien, die RF2 definiert. Bei einer RF3-Policy entstehen zwei zusätzliche Replikate, sodass die Datei auf Node 1, Node 2 und Node 3 gleichzeitig liegt und das Cluster auch dann konsistent bleibt, wenn zwei Knoten gleichzeitig ausfallen. Diese Ost-West-Datenströme – also der Traffic innerhalb des Clusters – sind deutlich intensiver als bei klassischen Setups, in denen die VMs ihre Daten direkt vom SAN ziehen. Ohne ausreichend dimensioniertes Backend-Netzwerk wird das Cluster zum Engpass.

Als Untergrenze gelten 10 GbE pro Node. Das reicht für viele Alltagsworkloads, stößt aber bei datenintensiven Anwendungen wie Datenbanken, VDI oder Video-Streaming schnell an Grenzen. Für anspruchsvolle Setups empfehle ich 25 GbE oder mehr, gerade wenn das Cluster wächst und der Replikationsverkehr proportional zunimmt. Auch die Wahl der Schnittstellen spielt eine Rolle: Dedizierte Storage-Netzwerke, die ausschließlich für den Cluster-Interconnect genutzt werden, sind sinnvoll, um Produktiv-Traffic vom Replikations- und Migrationstraffic zu trennen. In produktiven Setups sehe ich häufig LACP-Bündelung, also zwei oder mehr physische Links, die zu einem logischen Bond zusammengefasst werden – ein einzelnes 25-GbE-Kabel ist gut, zwei gebondete 25-GbE-Kabel sind im Fehlerfall überlegen und nehmen dem Cluster die Angst vor einem einzelnen Kabelbruch.

Ein häufiger Fehler in der Praxis: Die Storage-Netzwerk-Ports werden an Standard-Switches mit geringer Backplane-Kapazität betrieben. Wenn drei Nodes mit 25 GbE an einen Switch mit 48 Ports hängen, aber der Switch intern nur 100 Gbit/s Uplink-Kapazität hat, bricht der Durchsatz unter Last ein. Hier lohnt es sich, in Switches mit ausreichender Backplane und in eine saubere Segmentierung zu investieren, sonst wird das vermeintlich performante Cluster zum schleichenden Problemfall. Auch die Trennung von Management-Traffic, VM-Migration und Replikation über eigene VLANs gehört zum Pflichtprogramm – ein Cluster, in dem alles über ein einziges VLAN läuft, ist bei der ersten Diagnose kaum noch zu durchschauen, weil Storage-, vMotion- und Admin-Frames sich gegenseitig die Bandbreite streitig machen.

Sizing für die Praxis: Best Practices aus dem Support-Alltag

Aus den vielen HCI-Projekten, die ich begleitet habe, sind einige Best Practices herausgekommen, die ich jedem ans Herz lege, der ein solches System plant. Diese Hinweise klingen selbstverständlich, werden aber in der Hektik der Beschaffung erstaunlich oft vergessen.

1. Erst die Workloads, dann die Hardware. Bevor irgendein Server bestellt wird, muss klar sein, welche VMs laufen sollen, wie viel CPU, RAM und Speicher sie benötigen und welche Verfügbarkeitsanforderungen gelten. Ein HCI-Cluster lässt sich zwar nachträglich erweitern, aber eine grobe Fehldimensionierung lässt sich nicht durch das Hinzufügen weiterer Nodes kompensieren, wenn die einzelnen Knoten bereits überlastet sind.

2. Den Ressourcen-Overhead einkalkulieren. Hypervisor und Storage-Controller schlucken real zwischen 15 und 20 Prozent der Bruttoleistung. Wer das ignoriert, kauft zu klein und ärgert sich später über Performanceprobleme, die kein Hardware-Upgrade mehr löst.

3. Dauerhafte Auslastung bei 60 bis 70 Prozent halten. N+1-Failover-Szenarien und Wachstumspuffer müssen eingeplant werden, sonst kippt das Cluster beim ersten Node-Ausfall in eine Kettenreaktion.

4. Storage Policies bewusst wählen. RF2 für die meisten Workloads, RF3 oder Erasure Coding für kritische Daten. Die Wahl sollte nicht dem Standard-Wizard überlassen bleiben, sondern dokumentiert und nachvollziehbar sein – auch damit in zwei Jahren noch klar ist, warum welche Policy auf welcher VM liegt.

5. Netzwerk dediziert und mit Reserven planen. Mindestens 10 GbE pro Node, idealerweise 25 GbE – möglichst als Bond. Die Backplane der Switches muss den Gesamtverkehr aller Ports tragen können, ohne zum Flaschenhals zu werden, und das Storage-Netzwerk gehört strikt vom VM- und Management-Traffic getrennt.

6. Fault Domains sauber setzen. Nodes, die sich eine Stromversorgung, einen Rack-Frame oder einen Switch-Stack teilen, gehören in eine gemeinsame Fault Domain. Wer das ignoriert, hat formal drei Knoten, de facto aber nur einen Single Point of Failure.

7. Backup und Snapshot-Strategie nicht vergessen. HCI-Redundanz ist kein Ersatz für Backup. Snapshots, Offsite-Kopien und eine getestete Recovery-Prozedur bleiben unverzichtbar.

HCI funktioniert dann gut, wenn Architektur, Sizing und Storage-Policies als zusammenhängendes System geplant werden – nicht als drei separate Beschaffungsvorgänge.

Am Ende ist eine hyperkonvergente Infrastruktur kein Allheilmittel, aber für viele mittelständische IT-Umgebungen eine sehr pragmatische Antwort auf eine sehr konkrete Frage: Wie verwalte ich Rechenleistung, Speicher und Netzwerk so, dass es im Alltag funktioniert, ohne dass drei Spezialistenteams jede Änderung begleiten müssen? Wenn das HCI sauber dimensioniert, mit den richtigen Storage Policies versehen und über ein ausreichend dimensioniertes Netzwerk betrieben wird, dann ist die Verwaltungskomplexität tatsächlich geringer als bei einem klassischen Drei-Schichten-Setup. Das ist kein Marketingversprechen, sondern die Erfahrung aus Jahren von Support-Einsätzen, in denen die Anrufe nach der HCI-Migration spürbar weniger wurden. Wer hingegen an der Hardware, am Netzwerk oder an der Storage-Policy spart, wird schnell merken, dass auch eine elegante Architektur an ihren Schnittstellen scheitern kann.