Flexible statt statische Server
Je nach Geschmack
Eine Composable Infrastructure bietet viele Vorteile: Ziele sind eine höhere Flexibilität in der IT-Infrastruktur, Kostenoptimierung bei der Beschaffung, bessere Auslastung im Betrieb und ein standardisiertes und automatisierbares Management.
Viele IT-Abteilungen stehen traditionell vor der einen entscheidenden Frage: Wie kann eine Systemarchitektur aussehen, die günstig alle aktuellen Anforderungen an die Hardware, Software und das Management abdeckt, effizient im Betrieb und darüber hinaus flexibel und agil genug ist, schnell auf neue Kundenanforderungen zu reagieren? Eine Antwort scheint mit neuen Architekturkonzepten wie Intels Rack-Scale-Design oder der Composable Infrastructur (CI) des Gen-Z-Konsortiums gefunden, die diese Herausforderungen angehen.
Auch bei der Virtualisierung und später konvergenten sowie hyperkonvergenten Systemen ging es um dieselben Themen: eine flexiblere und potenziell effizientere IT. Alle Ansätze abstrahieren einzelne Komponenten wie CPU, RAM, Massenspeicher und I/O und stellen sie anschließend neu zusammen. So erhält der Nutzer einen individuellen virtuellen Server speziell für seine Anwendungen. Über entsprechende Management-APIs lässt sich dieser Prozess auf Wunsch automatisieren.
Diese Flexibilität der Hardware geht aber nicht über den Server hinaus. Hat man ihm zum Beispiel zu viel CPU-Leistung, Hauptspeicher, I/O-Karten oder Storage spendiert, bleiben viele Ressourcen nicht nur ungenutzt, sie verursachen außerdem weitere Kosten. Solche großen Server kann der Administrator zwar mit der Virtualisierung oder Hardwarepartitionierung auch in kleinere Einheiten aufteilen, doch die Beschaffungskosten steigen mit der Anzahl der CPU-Sockel exponentiell. Ein zu mager bestückter Rechner genügt hingegen noch nicht einmal den heutigen Bedürfnissen der Anwendungen und Nutzer. Es ist also eine Balance zwischen notwendiger Flexibilität sowie Beschaffungs- und Betriebskosten gefragt.
Noch flexibler als klassische VMs
Die Herausforderungen der herkömmlichen Virtualisierung gehen das Rack-Scale-Design und das Gen-Z-Konsortium mit der Composable Infrastructure an. Der Unterschied der Konzepte besteht eher im Wie der Umsetzung, weniger im zu erreichenden Ziel. Allen gemein ist eine disaggregierte Hardware, die man als Pool unterschiedlicher Ressourcen wie CPU, Speicher, Storage und Netzwerk handhabt. Aus ihnen stellt der Administrator maßgeschneiderte, anwendungsorientierte Server zusammen.
Statt vorhandene Hardware in neue virtuelle Server aufzuteilen, entsteht dabei ein neuer Hardwareverbund aus den einzelnen Ressourcen des Pools. Auf einem solchen Server laufen Betriebssystem und Applikationen ohne Modifikationen wie auf seinem klassischen Pendant. Er lässt sich anschließend falls gewünscht wieder in kleinere, virtuelle Server aufteilen.
Eine Composable Infrastructure ist konzeptuell nicht ressourcenlimitiert im Vergleich zum High-End-Server mit seiner maximalen Anzahl von Prozessoren, Speicher oder I/O-Slots. Das liegt daran, dass der Ressourcenpool mit dem Bedarf wachsen kann. Ebenso kann der Systemverwalter einzelne Komponenten gegen neuere austauschen. Letzteres ist wichtig, da die Weiterentwicklung der einzelnen Hardwareressourcen (CPU, Memory, Storage, Accelerators etc.) in der Regel nicht parallel, sondern unabhängig voneinander verläuft.
Ein limitierender Faktor
Technische Grenzen setzt dem Konzept das Netzwerk beziehungsweise der Interconnect als verbindendes Element der Komponenten. Latenz, Bandbreite und Protokolle des Netzwerks und Interconnects spielen deshalb eine wesentliche Rolle bei der Skalierung. Hier sind monolithische Rechner mit ihren größtenteils proprietären Interconnects einem offenen Konzept, das auch über mehrere Racks skalieren soll, überlegen. Das liegt daran, dass Erstere für eine kurze Latenz und hohe Bandbreite, allerdings mit limitierter Reichweite, optimiert sind.
Die Weiterentwicklungen der Standardnetzwerke in den letzten Jahren haben allerdings Latenz, Bandbreite und Protokolle deutlich verbessert, sodass manche Hersteller einen disaggregierten, Pool-basierten Server, angefangen bei I/O und Storage, bereits umsetzen. Schnelle Remote-Memory-Zugriffe sind hier die Königsklasse, benötigen aber noch weitere Verbesserungen.
Konzeptionell kann man sich das so vorstellen, dass eine CI die servertypischen internen Interconnects wie QPI/UPI, Infinity Fabric, CCIX, OpenCapi, DDR4 oder PCIe von Punkt-zu-Punkt-Verbindungen in Netzwerk-Fabrics mit Switches überführt. Durch Letztere lassen sich je nach Bedarf Verbindungen zu einzelnen oder mehreren Ressourcen schalten. Auch die Reichweite erhöht die CI auf diese Weise. Zudem kann der Administrator so einzelne Ressourcen erweitern oder erneuern, ohne bestehende Hardwareverbünde abschalten zu müssen.
Folglich spielt das Netzwerk-Fabric eine zentrale Rolle. Hier würde ein Technologiewechsel alle Ressourcen betreffen und ergibt deshalb ausschließlich dann Sinn, wenn man ganze Blöcke nebst zugehörigen Komponenten neu beschaffen muss.