Wie können Rechenzentren gestrandete Kapazität erkennen, die durch Engpässe bei Strom, Kühlung, Netzwerk oder Storage verursacht wird?

Rechenzentren können gestrandete Kapazität erkennen, indem sie die nominell freie Kapazität mit der Kapazität vergleichen, die für ein definiertes Workload- oder Geräteprofil tatsächlich einsetzbar ist. Fehlt U-Platz, Strom, Kühlung, Netzwerk, Storage oder eine andere benötigte Ressource, ist die scheinbar freie Ressource gestrandet.

Das Kapazitätsmodell der Quelle macht diese Unterscheidung explizit: Verfügbarer Platz, verbleibender Strom oder Kühlkapazität allein beweisen noch nicht, dass ein neues Deployment unterstützt werden kann. Kapazität wird erst dann nutzbar, wenn alle erforderlichen Bedingungen gleichzeitig erfüllt sind.

Was ist gestrandete Kapazität?

Gestrandete Kapazität ist eine Ressource, die zwar existiert, sich aber nicht in ein nutzbares Deployment umsetzen lässt, weil eine andere Abhängigkeit sie blockiert.

Das einfachste Beispiel ist ein Rack mit freien U-Positionen, aber unzureichendem Strom.

Der Platz existiert.

Das Rack kann den geplanten Server trotzdem nicht aufnehmen.

Dieselbe Logik gilt für andere Bereiche.

Ein Rack kann Strom, aber unzureichende Kühlung haben.

Ein Compute-Cluster kann freie Beschleuniger, aber keine geeignete Netzwerktopologie haben.

Storage kann freie Terabyte, aber unzureichenden Durchsatz für die geplante Trainings-Workload haben.

Eine Facility kann Platz für einen weiteren Cluster haben, aber keinen verbleibenden Spielraum bei den Stromkreisen.

Deshalb fordert der Leitfaden der Quelle zur KI-Kapazitätsplanung, nominale Kapazität von einsetzbarer Kapazität zu trennen.

Warum ist gestrandete Kapazität schwer zu erkennen?

Gestrandete Kapazität ist schwer zu erkennen, weil Infrastrukturteams jede Ressource oft getrennt melden.

Facility-Management meldet die verbleibende elektrische Kapazität.

DCIM meldet freien Rack-Platz.

Das Netzwerkteam meldet verfügbare Ports.

Storage meldet freie Kapazität.

Compute meldet freie GPUs.

Jedes Dashboard kann gesund aussehen.

Das Deployment schlägt trotzdem fehl.

Die fehlende Ebene ist das Deployment-Profil, das die Anforderungen miteinander verknüpft.

Ein bestimmter KI-Cluster benötigt eine bestimmte Kombination aus:

Rack-Platz
Strom
Kühlung
Netzwerk-Fabric
Storage-Durchsatz
Beschleunigertyp
Topologie
Redundanz
Management-Richtlinie

Kapazität muss anhand dieses Profils bewertet werden.

Eine allgemeine Aussage wie "20 Prozent Kapazität verbleiben" ist zu vage, um eine konkrete Deployment-Entscheidung zu stützen.

Wie berechnen Sie einsetzbare Kapazität?

Berechnen Sie die einsetzbare Kapazität für ein definiertes Server-, Rack- oder Workload-Profil.

Berechnen Sie für jede benötigte Ressource, wie viele Einheiten der aktuelle Spielraum unterstützen kann.

Beispiel:

U-Platz unterstützt 12 weitere Server.

Strom unterstützt 7.

Kühlung unterstützt 9.

Netzwerk-Ports unterstützen 6.

Storage-Durchsatz unterstützt 8.

Die einsetzbare Kapazität beträgt 6 Server, weil das Netzwerk die erste Einschränkung ist.

Das ist eine betriebliche Erweiterung der expliziten Schwachstellen-Regel der Quelle für Strom, Kühlung und Spielraum bei den Stromkreisen.

Derselbe Kapazitätsplanungsleitfaden der Quelle stellt zudem fest, dass Netzwerk- und Storage-Beschränkungen gestrandete Kapazität verursachen können, sodass dasselbe Vergleichsprinzip über den gesamten Deployment-Pfad hinweg gilt.

Welche gestrandete Kapazität kann durch Strom verursacht werden?

Strom-bedingte gestrandete Kapazität entsteht, wenn physischer Platz oder Compute-Ressourcen existieren, der elektrische Pfad aber keine zusätzliche Last mehr unterstützen kann.

Mögliche Einschränkungen sind:

Rack-Stromlimit
PDU-Kapazität
Spielraum des Stromkreises
Einschränkung bei A- oder B-Zuleitung
USV-Kapazität
Reservierte Redundanzmarge
Hohe Lastspitzen

Das Rack-Planungsmaterial der Quelle betont, die tatsächliche Serverleistung zu messen, statt sich nur auf historische Annahmen zu verlassen.

Das ist wichtig, weil ein Rack für eine Servergeneration geplant sein kann und später Geräte mit einem anderen Leistungsprofil erhält.

Nutzen Sie aktuellen Strombedarf, historische Spitzenwerte, geplante Last und erforderliche Reserve.

Berechnen Sie dann, wie viele zusätzliche Einheiten der elektrische Pfad unterstützen kann.

Welche gestrandete Kapazität kann durch Kühlung verursacht werden?

Kühlungsbedingte gestrandete Kapazität entsteht, wenn Platz und Strom verfügbar sind, der thermische Pfad die zusätzliche Wärme aber nicht sicher abführen kann.

Bei Luftkühlung kann die Einschränkung die lokale Rack- oder Zonenkapazität sein.

Bei Flüssigkeitskühlung kann es der Spielraum der CDU oder eines Zweigs sein.

Das Flüssigkeitskühlungsdesign der Quelle macht die Zweigbeziehung genau aus diesem Grund sichtbar.

Ist ein Zweig bereits nahe an seinem geplanten Limit, kann es auf Racks in diesem Zweig gestrandeten U-Platz geben.

Das Rack wirkt physisch leer.

Der Kühlpfad verhindert das Deployment.

Deshalb müssen Kühlungs- und Rack-Datensätze miteinander verknüpft sein.

Für die Flüssigkeitsseite behandelt was in einer CDU, einem Flüssigkeitskühlkreislauf und einem Verteilzweig überwacht werden sollte die Telemetrie, die zur Identifikation dieser Einschränkungen benötigt wird.

Welche gestrandete Kapazität kann durch Netzwerkgrenzen verursacht werden?

Netzwerkbedingte gestrandete Kapazität entsteht, wenn Compute- und Facility-Ressourcen verfügbar sind, die benötigte Konnektivität aber fehlt.

Der Kapazitätsplanungsleitfaden der Quelle nennt Netzwerk-Ports explizit als Deployment-Einschränkung.

Das Problem geht über die reine Portanzahl hinaus.

Eine Workload kann benötigen:

Management-Konnektivität
Produktionsnetzwerk
Storage-Netzwerk
Hochgeschwindigkeits-Trainingsnetzwerk
Eine bestimmte Topologie oder Failure Domain

Ein Rechenzentrum kann 20 freie Ethernet-Ports haben, die die Fabric-Anforderung der Workload nicht erfüllen.

Diese Ports sind für dieses Deployment keine nutzbare Kapazität.

Das Kapazitätssystem benötigt deshalb ein Netzwerkprofil, keine bloße Zahl.

Für KI-Training wird die Beziehung zwischen Netzwerk und Compute-Leistung behandelt in wie sich RDMA, RoCE, InfiniBand, Paketverlust und Storage-Performance auf das KI-Training auswirken.

Welche gestrandete Kapazität kann durch Storage verursacht werden?

Storage-bedingte gestrandete Kapazität entsteht, wenn Compute-Ressourcen frei sind, der Storage-Pfad die benötigte Kapazität oder Performance aber nicht liefern kann.

Das KI-Infrastrukturmodell der Quelle behandelt Storage als Teil der Produktionskette und überwacht Kapazität und Performance neben Compute und Netzwerk.

Ein Storage-Pool kann freie Kapazität, aber unzureichende Performance für eine weitere Workload haben.

Das bedeutet, "20 TB frei" beweist nicht, dass ein weiterer Trainingsjob unterstützt werden kann.

Das Kapazitätsprofil kann benötigen:

Storage-Kapazität
Lesedurchsatz
Schreibdurchsatz
IOPS
Latenzanforderung
Checkpoint-Anforderung
Pfadverfügbarkeit

Die genauen Felder hängen von der Workload ab.

Entscheidend ist, dass Storage als Workload-Abhängigkeit bewertet werden muss, nicht nur als verfügbare Terabyte.

Kann GPU-Kapazität selbst gestrandet sein?

Ja. Beschleunigerkapazität kann durch Ressourcenform und Topologie gestrandet sein, selbst wenn die Gesamtzahl freier Karten hoch erscheint.

Angenommen, acht GPUs sind über acht separate Knoten verteilt frei.

Ein Job benötigt acht GPUs innerhalb einer Topologie, die die aktuell freien Ressourcen nicht erfüllen.

Der Cluster meldet acht freie Karten.

Der Job kann trotzdem nicht starten.

Ein weiteres Beispiel ist Arbeitsspeicher.

Mehrere GPUs mit geringerem Speicher können verfügbar sein, während das Modell eine größere Speicherklasse benötigt.

Das ist Ressourcenfragmentierung.

Das KI-Betriebsmaterial der Quelle nennt Ressourcenfragmentierung als einen Grund, warum die nominale Kapazität schrumpft.

Der Scheduler sollte deshalb sowohl die gesamten freien Ressourcen als auch die einsetzbaren Ressourcen für jede Workload-Klasse anzeigen.

Wie sollte gestrandete Kapazität klassifiziert werden?

Klassifizieren Sie gestrandete Kapazität nach der blockierenden Einschränkung.

Nützliche Kategorien sind:

Platz gestrandet
Strom gestrandet
Kühlung gestrandet
Netzwerk gestrandet
Storage gestrandet
Compute-Form gestrandet
Topologie gestrandet
Reservierte Kapazität
Richtlinien- oder Kontingent-gestrandet

Diese Klassifizierung macht die Zahl nutzbar.

Ein Gesamtprozentsatz gestrandeter Kapazität sagt Ihnen, dass es Verschwendung gibt.

Eine Aufschlüsselung nach Ursache sagt Ihnen, was zu beheben ist.

Wenn 40 Prozent der gestrandeten Kapazität netzwerkbedingt sind, löst der Kauf weiterer Racks das Problem nicht.

Wenn Strom die Haupteinschränkung ist, helfen zusätzliche Netzwerk-Ports nicht.

Kapazitätsplanung sollte Investitionen auf den tatsächlichen Engpass lenken.

Wie sollte ein Rechenzentrum den Engpass automatisch erkennen?

Erstellen Sie ein Kapazitätsmodell, das jede Ressourcendimension kontinuierlich aktualisiert und mit definierten Deployment-Profilen vergleicht.

Das Modell benötigt aktuelle Daten aus:

Rack- und U-Positions-Datensätzen
Stromüberwachung
Kühlungsüberwachung
Netzwerkbestand
Storage-Überwachung
Compute-Bestand
Reservierungen
Workload-Anforderungen

Berechnen Sie für jedes Rack, jeden Cluster oder jede Zone den verbleibenden Spielraum je Dimension.

Melden Sie dann das Minimum.

Dieses Minimum ist die aktive harte Einschränkung für das gewählte Profil.

Der Kapazitätsleitfaden der Quelle fordert genau diese Art von mehrdimensionaler Kapazitätssicht und Validierung vor dem Einbau ins Rack.

Was ist ein Deployment-Profil?

Ein Deployment-Profil beschreibt alles, was eine geplante Einheit benötigt.

Für einen Server kann das umfassen:

U-Höhe
Erwarteten Strombedarf
Spitzenlast
Gewicht
Kühlungsart
Benötigte Netzwerk-Ports
Storage-Konnektivität
Management-Port
Redundanzanforderung

Für einen GPU-Cluster kann das zusätzlich umfassen:

Anzahl und Typ der Beschleuniger
Rack-Verteilung
Trainings-Fabric
Storage-Durchsatz
Topologie-Regeln
Kühlzweig-Anforderung

Das Kapazitätssystem nutzt das Profil, um rohen Spielraum in eine einsetzbare Einheitenzahl zu übersetzen.

Ohne Profil kann die Plattform Ressourcen zeigen, aber nicht beantworten, ob das nächste Deployment passt.

Wie sollte reservierte Kapazität behandelt werden?

Reservierte Kapazität sollte nicht als generell einsetzbar gezählt werden.

Der Planungsleitfaden der Quelle unterscheidet explizit zwischen reservierter und einsetzbarer Kapazität.

Ein Projekt kann reservieren:

U-Positionen
Elektrischen Spielraum
Kühlkapazität
Netzwerk-Ports
Storage-Kapazität
GPU-Ressourcen

Sind diese Reservierungen nicht sichtbar, kann dieselbe Kapazität doppelt zugesagt werden.

Gleichzeitig können lange ungenutzte Reservierungen scheinbar gestrandete Kapazität erzeugen.

Das sollte getrennt von physischen Einschränkungen ausgewiesen werden.

Eine reservierte Ressource ist möglicherweise absichtlich nicht verfügbar.

Eine physisch gestrandete Ressource kann nicht genutzt werden, bis ein Engpass beseitigt ist.

Das sind unterschiedliche Managementprobleme.

Wie lässt sich gestrandete Kapazität visualisieren?

Nutzen Sie eine Ansicht, die nominell freie Kapazität mit einsetzbarer Kapazität vergleicht.

Zum Beispiel:

Freie U-Positionen: 120
Von Strom unterstützte Einheiten: 70
Von Kühlung unterstützte Einheiten: 84
Von Netzwerk unterstützte Einheiten: 62
Von Storage unterstützte Einheiten: 75
Einsetzbare Einheiten: 62

Zeigen Sie dann:

Primärer Engpass: Netzwerk
Sekundärer Engpass: Strom
Geschätzte freigesetzte Kapazität bei Netzwerkausbau: 8 Einheiten, bevor Strom zur Einschränkung wird

Das ist nützlicher als fünf separate Auslastungsdiagramme.

Der Operator sieht die nächste Einschränkung, bevor Geld ausgegeben wird.

Wie sollte künftige gestrandete Kapazität prognostiziert werden?

Prognostizieren Sie den Zeitpunkt, an dem jede Einschränkung unter mehreren Nachfrageszenarien limitierend wird.

Der Planungsleitfaden der Quelle empfiehlt Basis-, erwartete und stärkere Wachstumsszenarien statt einer einzelnen deterministischen Prognose.

Erfassen Sie für jede Einschränkung:

Aktuellen Spielraum
Wachstumsrate
Geplante Reservierungen
Ausbauprojekt
Vorlaufzeit des Projekts
Prognostizierte Erschöpfung
Letztmöglichen Entscheidungstermin

Angenommen, die Netzwerkkapazität erreicht in sechs Monaten ihr Limit, der Ausbau der Fabric dauert aber neun Monate.

Die Entscheidung ist bereits verspätet.

Die Prognose sollte sich deshalb auf die Vorlaufzeit für Entscheidungen konzentrieren, nicht nur auf das Datum, an dem eine Ressource null erreicht.

Wie sollten Produktionsdaten das Kapazitätsmodell verbessern?

Vergleichen Sie geplante Annahmen mit dem tatsächlichen Betrieb nach dem Deployment.

Wurde ein Server mit einem bestimmten Leistungsprofil geplant, läuft aber durchgehend niedriger, aktualisieren Sie das Geräteprofil mit Vorsicht.

Ist die Spitzenlast höher als erwartet, passen Sie künftige Platzierungen an.

Hat ein Flüssigkeitskühlungszweig weniger praktischen Spielraum, als das technische Modell annahm, aktualisieren Sie die Deployment-Regeln.

Sinkt die Storage-Performance, wenn eine bestimmte Anzahl von Trainingsjobs gleichzeitig läuft, bilden Sie diese Einschränkung im Workload-Profil ab.

Die Planungsschleife der Quelle speist Betriebsergebnisse explizit in Geräteprofile, Racking-Regeln und Kapazitätsvorhersage zurück.

So wird das Modell im Laufe der Zeit genauer.

Was sollte ein Dashboard für gestrandete Kapazität beantworten?

Es sollte vier Fragen beantworten.

Wie viel nominale Kapazität existiert?

Wie viel ist tatsächlich einsetzbar?

Was verursacht den Unterschied?

Welche Maßnahme würde die meiste nutzbare Kapazität freisetzen?

Ein gutes Dashboard zeigt den Engpass nach Rack, Zone, Cluster und Workload-Profil.

Es sollte auch zeigen, welche geplanten Projekte Kapazität verbrauchen oder freisetzen werden.

Ein Plattformbeispiel, das diese Kapazitätsdimensionen verknüpft, ist Sensaka.

Wenn ich dem Management Kapazität melden würde, würde ich vermeiden zu sagen: "Wir haben noch 30 Prozent freie Kapazität." Ich würde sagen: "Für den nächsten geplanten GPU-Knotentyp können wir 62 weitere Einheiten einsetzen; das Netzwerk ist die erste Engpassgrenze, danach wird Strom limitierend." Das ist der Unterschied zwischen Infrastruktur-Inventar und umsetzbarer Kapazitätsplanung.