Redundanzkonzepte für große Rechenzentren Redundanz neu denken - wenn 2N und Hexagonalsystem an Grenzen stoßen

Anbieter zum Thema

dc-ce RZ-Beratung Berlin, Frankfurt, Erding

DAXTEN GmbH

Data Center Group GmbH

EPS Rechenzentrum Infrastruktur GmbH

Mit steigender Rechenzentrumsleistung wird eine vollständige 2N-Auslegung immer aufwendiger. Hyperscaler verlagern Redundanz deshalb teilweise näher an die IT und denken in kleineren Fehlerdomänen.

Die Planungsgrundsätze für Rechenzentren in Europa werden unter anderem durch die anerkannten Regeln der Technik EN 50600 und verschiedenen Zertifizierer mit eigenen Regelwerken wie zum Beispiel TSI oder Uptime geprägt. Für hochverfügbare Rechenzentren kommen dabei häufig klassische Redundanzkonzepte wie 2N oder Formen der verteilten Redundanz zum Beispiel 6N/5 zum Einsatz.

Load Groups und Monitoring

Hochverfügbarkeit im Rechenzentrum mit verteilter Redundanz aus Betreibersicht

Mit zunehmender Größe der Rechenzentren stoßen diese Ansätze jedoch an praktische und wirtschaftliche Grenzen. Hyperscaler mit Leistungen von 100 Megawatt (MW) IT und mehr können aus wirtschaftlichen und technischen Gründen eine vollständige Verdoppelung nicht beliebig skalieren.

Ein vereinfachtes Rechenbeispiel verdeutlicht die Größenordnung:

Nimmt man für Transformator, Netzersatzanlage und Schaltanlage eine Versorgungseinheit mit etwa 3 MW Leistung an, sind für 100 MW IT-Leistung bereits mehr als 30 aktive Einheiten erforderlich. Werden Kühlung und weitere Infrastruktur berücksichtigt, kann die Anzahl – abhängig vom Gesamtkonzept – in Richtung 50 aktive Versorgungseinheiten steigen. Bei einer vollständigen 2N-Struktur verdoppelt sich diese Infrastruktur auf 100 Einheiten.

Ähnlich verhält es sich bei den USV (Unterbrechungsfreie-Stromversorgung). Bei angenommenen 3 MW je USV-Einheit wären für 100 MW IT-Leistung bereits rund 34 USV-Einheiten erforderlich. Bei 2N steigt die Anzahl auf fast 70 Einheiten. Mit USV für Infrastruktur sind das bei 2N 80 Einheiten und mehr.

Der Investitionsbedarf und Flächenbedarf einer durchgängigen 2N-Redundanz wird bei diesen Dimensionen gewaltig.

Hyperscaler betrachten Redundanz anders

Aus den Veröffentlichungen der Hyperscaler gibt es Hinweise zu angepassten Redundanzkonzepten. Bereits vor der KI-Welle erläuterte Peter DeSantis 2020 für AWS, dass klassische 2N-Konzepte den hohen Verfügbarkeitsanforderungen von AWS entsprechen und auch von AWS angewendet wurden, AWS die Redundanz jedoch weiterentwickelt und umfassender betrachtet. DeSantis führt aus, dass die zunehmende Komplexität von einzelnen Komponenten zum Beispiel unterbrechungsfreie Stromversorgung (USV), Automatic Transfer Switch (ATS) selbst Auswirkungen auf die Verfügbarkeit haben kann, weil die Fehleranfälligkeit mit der Komplexität steigt. AWS verweist darauf, dass Software, die nicht von AWS selbst erstellt bzw. kontrolliert wird, in der Regel zusätzliche Komplexität verursacht.

Die Betrachtung geht damit über die klassische elektrische Redundanz hinaus. Auch die Architektur der Cloud-Anwendungen, die Verteilung über mehrere Availability Zones (geografische Cluster) und Rechenzentren sowie die Größe der jeweiligen Fehlerdomäne werden Teil der Verfügbarkeitsstrategie. AWS beschreibt Fehlerisolierung ausdrücklich als die Aufteilung eines Systems in kleinere Subsysteme, deren Fehler möglichst unabhängig voneinander bleiben.

2N oder lieber N+1?

Hochverfügbarkeit mit verteilter Redundanz aus Investorensicht

Interessant ist auch ein weiterer Gedanke aus den AWS-Veröffentlichungen: Mehr Redundanz führt nicht unbegrenzt zu einem sinnvollen Gewinn an Verfügbarkeit. Zusätzliche Reserveeinheiten bringen ab einem bestimmten Punkt nur noch wenig zusätzlichen Verfügbarkeitsgewinn, während Kosten und Komplexität weiter steigen.

Das unterscheidet sich deutlich von einer Betrachtung, bei der die Verfügbarkeit hauptsächlich aus der Redundanz der technischen Infrastruktur abgeleitet wird.

Die Fehlerdomäne wird wichtiger

Die Strategie der Hyperscaler lässt sich allerdings nicht aus einem einzelnen veröffentlichten Versorgungsschema ableiten. Die öffentlich verfügbaren Informationen bleiben insgesamt grob und geben nur wenige Einzelheiten preis.

Erkennbar ist aber ein Grundgedanke:

Nicht nur die Redundanz einer Komponente ist entscheidend, sondern auch der Auswirkungsbereich eines Fehlers – bei AWS als "Blast Radius" oder auch Fehlerdomäne bezeichnet.

Ein Ausfall, der nur einen abgegrenzten Teil der IT betrifft, beispielsweise ein Rack, kann durch die Softwarearchitektur beherrscht werden. Fehler, die eine Versorgungseinheit eines größeren Rechenzentrumsbereichs betreffen, müssen dagegen durch Reservesysteme abgesichert werden. Störungen, die ein vollständiges Rechenzentrum betreffen, können durch die Verteilung der Anwendungen auf weitere Rechenzentren beziehungsweise Availability Zones berücksichtigt werden. Damit bekommt auch die Architektur der IT Einfluss auf das Design der Stromversorgung.

Abstimmung ist Pflicht

Verteilte Redundanz im Rechenzentrum aus Planersicht

Die USV wandert näher an die IT

Ein interessanter Ansatz ist die Verlagerung der unterbrechungsfreien Energieversorgung bis an den Server beziehungsweise in das Rack. AWS beschrieb bereits 2020 USV-Systeme innerhalb der einzelnen Racks. Im offiziellen AWS-Liveblog zur Infrastructure Keynote wird ausdrücklich auf „Mini-UPSes in individual DC racks“ verwiesen. AWS stellt der Mini-UPS die konventionelle zentrale Megawatt-USV mit ihrem hohen Gewicht und eigenen Infrastrukturbedarf gegenüber.

Data Center Frontier veröffentlichte dazu unmittelbar nach der re:Invent 2020 eine ausführliche Darstellung. Dort wird beschrieben, dass AWS kleine Batteriepacks und speziell entwickelte Stromversorgungen in jedes Rack integriert und dadurch die Funktion der zentralen USV auf die Rack-Ebene verlagert. Diese verteilte Architektur reduziert durch eine entfalle Wandlung die Energieverluste in der Stromversorgungskette deutlich. Gleichzeitig verkleinert sich die Fehlerdomäne: Ein Fehler der USV-Funktion betrifft nicht mehr einen ganzen Data Hall, sondern im Wesentlichen das jeweilige Rack.

Power the Future

Für jedes Rechenzentrum die passende Untenbrechungsfreie Stromversorgung

Ein vergleichbarer Grundgedanke findet sich heute auch in den Open-Compute-Architekturen, an denen Microsoft, Google, Meta, mitarbeitet: Bei Open Rack V3 erfolgt die AC/DC-Wandlung in einem Power Shelf. Mehrere Gleichrichter versorgen einen gemeinsamen DC-Bus im Rack. Die ORv3-Architektur arbeitet mit einem 48-V-DC-Bus; dazu sind eigene BBU-Shelves und BBU-Module (BBU: Backup Battery Units) veröffentlicht . Bei diesem Projekt sind die aktiven Module des Power Shelves, Gleichrichter und BBU, in 4 aus 5 Redundanz ausgeführt.

Die konkrete technische Umsetzung und auch die verwendete Spannung sind dabei nicht das Entscheidende.

Wichtig ist das Prinzip:

AC/DC-Wandlung, DC-Verteilung und kurzzeitige Energiespeicherung rücken näher an die IT.

Bei Ausfall der AC-Versorgung übernimmt die Battery Backup Unit für eine begrenzte Zeit die Versorgung des DC-Busses.

Gegenüber einer klassischen zentralen Online-USV können damit Funktionen anders verteilt und der Auswirkungsberich des Fehlers (Fehlerdomäne) verkleinert werden.

800 VDC ist die neue Basis für Hyperscale-KI-Fabriken

Gleichstrom bei minus 200 Grad im Rechenzentrum

Stromversorgung und Anwendungsdesign wachsen zusammen

An dieser Stelle wird das Design der Cloud-Anwendung relevant. Hyperscaler können aufgrund der großen Anzahl von Servern, auf denen ein Dienst verteilt wird, Fehler bereits auf der Anwendungsebene berücksichtigen. Klassische Verfügbarkeitsbetrachtungen der technischen Gebäudeausrüstung behandeln die Anwendungsebene nur eingeschränkt.

Das Rack kann dadurch zu einer bewusst abgegrenzten elektrischen Fehlerdomäne werden. Das bedeutet nicht, dass der Ausfall eines Racks grundsätzlich unkritisch ist. Die IT-Architektur muss einen solchen Fehler auch tatsächlich beherrschen können.

Ist das gegeben, kann die Versorgung vor dieser Fehlerdomäne nach anderen Redundanzphilosophien aufgebaut werden. Die BBU im Rack übernimmt die kurzfristige, unterbrechungsfreie Versorgung der IT. Die vorgelagerte elektrische Infrastruktur muss eine alternative Energieversorgung damit nicht zwingend unterbrechungsfrei bereitstellen.

Sie muss die alternative Versorgung vielmehr innerhalb der definierten Autonomiezeit der BBU wieder herstellen.

Genau diese Trennung von lokaler Kurzzeitüberbrückung und vorgelagerter Redundanz eröffnet neue Möglichkeiten für Redundanzkonzepte.

Eine davon ist die Blockredundanz beziehungsweise das Catcher-System. Darum geht es im zweiten Beitrag.

2N oder lieber N+1?

Hochverfügbarkeit mit verteilter Redundanz aus Investorensicht

Hinweise und weiterführende Literatur

• Amazon Web Services (2020): AWS re:Invent 2020 – Infrastructure Keynote with Peter DeSantis. AWS. Online verfügbar.

• Miller, Rich (2020): AWS Designs In-Rack Micro UPS Units for a More Efficient Cloud. Data Center Frontier, 11.12.2020. Online verfügbar.

• Amazon Web Services (AWS): Availability and Beyond: Understanding and Improving the Resilience of Distributed Systems on AWS. AWS Whitepaper. Online verfügbar.

• Open Compute Project (OCP): Open Rack V3 – Power Shelf Specification. Open Compute Project. Online verfügbar

• TÜV NORD: EN 50600 – Rechenzentren: Zertifizierung der Verfügbarkeit und Sicherheit. TÜV NORD. Online verfügbar.

(ID:50968093)