Server Clus­te­ring: Ein­füh­rung in Cloud Server Cluster

Ein Server-Cluster ist ein Node-Verbund mehrerer un­ab­hän­gi­ger Server (Nodes), die nach außen als ein einziges System auftreten. Ziel ist es, durch Redundanz die Hoch­ver­füg­bar­keit (High Avai­la­bi­li­ty) zu steigern, durch Last­ver­tei­lung (Load Balancing) die Per­for­mance zu op­ti­mie­ren oder komplexe Re­chen­auf­ga­ben (HPC) zu be­wäl­ti­gen.

Server-Cluster bestehen heute nicht mehr nur aus phy­si­scher Hardware in einem Re­chen­zen­trum. In modernen Um­ge­bun­gen umfassen sie auch virtuelle Maschinen und con­tai­ne­ri­sier­te Workloads. Besonders deutlich wird das bei Ku­ber­netes: Hier bilden Control Plane und Worker Nodes den Ku­ber­netes Cluster, während An­wen­dun­gen in Ku­ber­netes Pods aus­ge­führt werden. Clus­te­ring ist damit keine reine Hardware-Frage mehr, sondern ein Ar­chi­tek­tur­prin­zip für Ver­füg­bar­keit, Ska­lier­bar­keit und den zu­ver­läs­si­gen Betrieb ver­teil­ter Systeme.

Warum einen Server-Cluster verwenden?

Server-Cluster werden in der Praxis vor allem dann ein­ge­setzt, wenn eine Single-Server-Lösung an tech­ni­sche oder be­trieb­li­che Grenzen stößt. Das betrifft ins­be­son­de­re Hoch­ver­füg­bar­keit, Last­ver­tei­lung und Sca­la­bi­li­ty. Während vertikale Ska­lie­rung die Res­sour­cen eines be­stehen­den Systems erhöht, erweitert ho­ri­zon­ta­le Ska­lie­rung die Kapazität durch zu­sätz­li­che Pods oder Nodes. Für die ho­ri­zon­ta­le Ska­lie­rung steht in Ku­ber­netes der Ho­ri­zon­tal Pod Au­t­o­s­ca­ler nativ zur Verfügung. Das Hoch- und Her­un­ter­ska­lie­ren der Node-Anzahl (Cluster Au­t­o­s­ca­ler bzw. Karpenter) und die vertikale Anpassung einzelner Pods (Vertical Pod Au­t­o­s­ca­ler) werden über separate, zu­sätz­lich zu in­stal­lie­ren­de Kom­po­nen­ten rea­li­siert.

Typische Vorteile eines Clusters sind deshalb:

• höhere Aus­fall­si­cher­heit durch Failover
• bessere Last­ver­tei­lung bei stei­gen­den Zu­griffs­zah­len
• fle­xi­ble­res Pro­vi­sio­ning zu­sätz­li­cher Res­sour­cen
• war­tungs­freund­li­che­re Ar­chi­tek­tu­ren mit Rolling Updates oder kon­trol­lier­ter Um­schal­tung
• bessere Eignung für verteilte, con­tai­ne­ri­sier­te oder re­chen­in­ten­si­ve Workloads.

Wie funk­tio­niert ein Server-Cluster?

Ein Server-Cluster besteht aus mehreren Nodes, die über Netzwerk und Cluster-Software ko­or­di­niert werden. Damit der Verbund stabil arbeitet, über­wa­chen sich die Nodes ge­gen­sei­tig über Heartbeat-Ver­bin­dun­gen. Fällt ein Node aus oder antwortet nicht mehr, kann der Cluster einen Failover auslösen und Dienste auf andere Nodes ver­schie­ben oder neu starten. Zentral für diese Ent­schei­dung ist das Quorum. Es stellt sicher, dass bei einem Teil­aus­fall nicht zwei Cluster-Hälften gleich­zei­tig glauben, aktiv zu sein.

Beim Storage hat sich das Bild in den letzten Jahren deutlich verändert. Klas­si­sche Cluster arbeiten häufig mit gemeinsam genutztem SAN- oder NAS-Speicher. In modernen Um­ge­bun­gen kommen daneben soft­ware­de­fi­nier­te Spei­cher­lö­sun­gen zum Einsatz, die Storage-Funk­tio­nen stärker von der zugrunde liegenden Hardware ent­kop­peln. Für per­for­man­te fabric-basierte An­bin­dun­gen ist zudem NVMe-over-Fabrics relevant. Die Spe­zi­fi­ka­ti­on definiert drei Trans­por­te: RDMA, TCP und Fibre Channel. RDMA wird über Ethernet (RoCE/iWARP) oder In­fi­ni­Band über­tra­gen, TCP über Ethernet, während Fibre Channel ein eigenes Transport- und Fabric-Modell (FC-NVMe) darstellt.

Nicht jeder Cluster benötigt dabei Shared Storage. Gerade verteilte Da­ten­platt­for­men und manche Da­ten­bank­clus­ter arbeiten als Shared-Nothing-Ar­chi­tek­tur: Jeder Node verwaltet eigene Res­sour­cen, während Re­pli­ka­ti­on oder Par­ti­tio­nie­rung für Ver­füg­bar­keit und Ska­lie­rung sorgen.

Server-Cluster-Typen im Überblick

High-Avai­la­bi­li­ty-Cluster / Failover-Cluster

Ein High-Avai­la­bi­li­ty-Cluster (HA) bzw. Failover-Cluster verfolgt in erster Linie das Ziel, Dienste trotz Node-Ausfall verfügbar zu halten. Die Cluster-Software überwacht die Ge­sund­heit der Nodes und der be­reit­ge­stell­ten Rollen. Sobald ein Fehler erkannt wird, werden Rollen neu gestartet oder auf einen anderen Node ver­scho­ben. Das ist vor allem für Da­ten­ban­ken, virtuelle Maschinen oder andere ge­schäfts­kri­ti­sche Dienste relevant.

In diesem Zu­sam­men­hang ist auch die Un­ter­schei­dung zwischen Active/Active und Active/Passive wichtig. Bei Active/Active ver­ar­bei­ten mehrere Nodes gleich­zei­tig pro­duk­ti­ve Last. Bei Active/Passive übernimmt min­des­tens ein Standby-Node erst dann Aufgaben, wenn ein aktiver Knoten ausfällt. Active/Active nutzt vor­han­de­ne Res­sour­cen ef­fi­zi­en­ter, Active/Passive ist in vielen Szenarien einfacher und be­re­chen­ba­rer.

Load-Balancing-Cluster

Load-Balancing-Cluster verteilen ein­ge­hen­de Ver­bin­dun­gen oder Anfragen auf mehrere Instanzen eines Dienstes. So lassen sich Engpässe vermeiden und Spit­zen­las­ten besser abfangen. Klas­si­sche Vertreter sind Software-Load-Balancer wie NGINX oder HAProxy. In Container-Um­ge­bun­gen wird dieses Prinzip um Ku­ber­netes-Services, Ingress Con­trol­ler und die Gateway API erweitert. Ingress kann HTTP- und HTTPS-Zugriffe auf Services im Cluster routen und übernimmt dabei unter anderem Load Balancing und TLS-Ter­mi­nie­rung.

Für kom­ple­xe­re Traffic-Steuerung reicht klas­si­sches Load Balancing oft nicht mehr aus. Service-Meshes wie Istio ergänzen die Cluster-In­fra­struk­tur um feinere Routing-Regeln, Retries, Timeouts, Circuit Breaker sowie Canary- und A/B-Rollouts. Damit wird Load Balancing von einer reinen Ver­tei­lungs­funk­ti­on zu einem Teil des gesamten Traffic-Ma­nage­ments im Cluster.

High-Per­for­mance-Computing-Cluster

HPC-Cluster bündeln Re­chen­leis­tung für Workloads, die ein einzelner Server nicht effizient be­wäl­ti­gen kann. Dazu zählen Si­mu­la­tio­nen, wis­sen­schaft­li­che Be­rech­nun­gen, Rendering, Machine Learning sowie das Training und die Inferenz von Large Language Models (LLMs). In solchen Um­ge­bun­gen verwaltet ein Scheduler wie Slurm die ver­füg­ba­ren Compute Nodes und weist Jobs kon­trol­liert Res­sour­cen zu.

Für diese Workloads sind heute vor allem GPU-Cluster relevant. Je stärker Training oder Inferenz über mehrere Nodes verteilt werden, desto wichtiger werden hoher Da­ten­durch­satz und geringe Latency zwischen den Systemen. Deshalb kommt in solchen Clustern häufig In­fi­ni­Band-Net­wor­king zum Einsatz, um die Kom­mu­ni­ka­ti­on zwischen den Nodes zu be­schleu­ni­gen und Netz­wer­k­eng­päs­se zu re­du­zie­ren.

Container-Or­ches­trie­rung: Clus­te­ring 2.0

Moderne Clus­te­ring-Konzepte sind eng mit Container-Or­ches­trie­rung verbunden. Ku­ber­netes au­to­ma­ti­siert De­ploy­ment, Ska­lie­rung und Ver­wal­tung con­tai­ne­ri­sier­ter An­wen­dun­gen. Die Control Plane verwaltet die Worker Nodes und die Pods im Cluster; in Pro­duk­ti­ons­um­ge­bun­gen läuft sie ty­pi­scher­wei­se über mehrere Systeme, um Feh­ler­to­le­ranz und Hoch­ver­füg­bar­keit zu erhöhen.

Der ent­schei­den­de Un­ter­schied zu klas­si­schen Server-Clustern liegt in der Abs­trak­ti­ons­ebe­ne. Nicht mehr einzelne physische Server stehen im Vor­der­grund, sondern de­kla­ra­tiv be­schrie­be­ne Workloads. Pods werden je nach ver­füg­ba­ren Res­sour­cen auf Nodes geplant, re­pli­ziert und bei Bedarf neu gestartet. Dadurch wird Clus­te­ring stärker soft­ware­ge­steu­ert und weniger an einzelne Hardware gebunden.

Cloud-Native vs. On-Premise Clus­te­ring

Cloud-Native- und On-Premise-Cluster verfolgen ähnliche Grund­prin­zi­pi­en, un­ter­schei­den sich aber deutlich im Be­triebs­mo­dell. In Cloud-Native-Um­ge­bun­gen sind ho­ri­zon­ta­le Ska­lie­rung, au­to­ma­ti­sches Pro­vi­sio­ning und Load-Balancing-Funk­tio­nen oft enger in die Plattform in­te­griert. Ku­ber­netes kennt dafür sowohl Pod-Au­t­o­s­ca­ling als auch Node-Au­t­o­s­ca­ling.

On-Premise-Cluster bieten dafür meist mehr direkte Kontrolle über Hardware, Netz­werk­to­po­lo­gie und Storage, erfordern aber in der Regel mehr Ei­gen­auf­wand bei Planung, Pro­vi­sio­ning, Redundanz, Betrieb und Wartung. In der Praxis ist Clus­te­ring on premises daher oft komplexer um­zu­set­zen, während Cloud-Native-Modelle viele Me­cha­nis­men bereits auf Platt­form­ebe­ne stan­dar­di­sie­ren.

Check­lis­te: Wann ist ein Cluster sinnvoll?

Ein Cluster ist besonders sinnvoll, wenn

• Aus­fall­zei­ten ge­schäfts­kri­tisch sind,
• Last­spit­zen re­gel­mä­ßig auftreten,
• An­wen­dun­gen ho­ri­zon­tal skaliert werden sollen,
• verteilte Workloads wie Container-Platt­for­men, Da­ten­platt­for­men oder GPU-Jobs betrieben werden.

Für kleine, stabile An­wen­dun­gen mit klar kal­ku­lier­ba­rer Last kann ein einzelner Server dagegen wirt­schaft­li­cher und einfacher zu betreiben sein.

FAQ: Häufige Fragen zu Clus­te­ring

Was ist ein Quorum im Cluster?

Das Quorum ist die Mehr­heits­re­gel eines Clusters. Es legt fest, ob noch genügend gültige Stimmen vorhanden sind, also Stimmen von Cluster-Knoten und ge­ge­be­nen­falls eines Witness, die für die Mehr­heits­ent­schei­dung des Clusters zählen. Damit ver­hin­dert es Split-Brain-Si­tua­tio­nen. His­to­risch wurde dafür oft von einer Quorum-Disk ge­spro­chen; heute sind je nach Plattform auch Disk Witness, File Share Witness, Cloud Witness oder externe Quorum Devices üblich.

Ist Ku­ber­netes dasselbe wie ein klas­si­scher Failover-Cluster?

Ku­ber­netes ist eine Or­ches­trie­rungs­platt­form für con­tai­ne­ri­sier­te Workloads und arbeitet mit Control Plane, Worker Nodes und Pods. Klas­si­sche Failover-Cluster fo­kus­sie­ren sich stärker auf die Hoch­ver­füg­bar­keit einzelner Rollen oder Dienste. In der Praxis über­schnei­den sich beide Welten, verfolgen aber un­ter­schied­li­che Be­triebs­mo­del­le.

Benötigt ein moderner Cluster immer Shared Storage?

Nein. Zwar gibt es weiterhin Shared-Storage-Modelle, aber moderne Cluster arbeiten je nach Workload auch mit soft­ware­de­fi­nier­tem Storage, re­pli­zier­ten Daten oder Shared-Nothing-Ar­chi­tek­tu­ren. Welche Variante sinnvoll ist, hängt vor allem von Anwendung, La­tenz­an­for­de­run­gen und Kon­sis­tenz­mo­dell ab.

Was ist der Un­ter­schied zwischen Active/Active und Active/Passive?

Bei Active/Active arbeiten mehrere Nodes gleich­zei­tig produktiv und teilen sich die Last. Bei Active/Passive steht min­des­tens ein Node im Be­reit­schafts­mo­dus und übernimmt erst beim Ausfall eines aktiven Knotens. Active/Active erhöht die Res­sour­cen­aus­las­tung, Active/Passive ver­ein­facht oft das Failover-Design.