AntonioDiaz - stock.adobe.com
Warum nicht jedes Rechenzentrum konsolidiert werden sollte
Ein einziges, zentrales Rechenzentrum zu haben, bietet Vorteile. Anwendungsfälle wie IoT, Edge Computing und Cloud stehen jedoch oft einer konsolidierten Infrastruktur entgegen.
Die Konsolidierung von Rechenzentren ist schon länger ein Schlüsselfaktor für das Wachstum und deren umfassende Verwaltung. Die Möglichkeit, Server zu teilen und möglichst voll zu nutzen, hat dazu beigetragen, die explodierenden Kosten für Hardware, Strom, Kühlung und physischen Platz im Rechenzentrum einzudämmen.
Die Vorteile der Konsolidierung liegen also auf der Hand. Aber es gibt einige Umstände, unter denen ein Unternehmen die Konsolidierung überdenken und abwägen sollte, ob nicht doch eine zweite, getrennte Infrastruktur die richtige Lösung sein könnte.
Das Platzieren von Ressourcen und Diensten außerhalb des Hauptrechenzentrums ist angezeigt, wenn Netzwerkbeschränkungen, Größe und Redundanz für das Unternehmen von entscheidender Bedeutung sind. Es ist wichtig, jede Situation und mögliche Vorgehensweisen individuell zu betrachten und sich an den Bedürfnissen des eigenen Unternehmens zu orientieren.
Der Reiz und die Herausforderungen der Konsolidierung
Mit dem Aufkommen der Servervirtualisierung in Verbindung mit Hypervisorsoftware wurden Prozessorbefehlssätze erweitert, um Anwendungen von der zugrundeliegenden Hardware zu abstrahieren.
Das Übersetzen von physischen Computerressourcen in logische Äquivalente ermöglichte es, Workloads effizienter auf vorhandene Ressourcen zu verteilen. Mit der Installation einer Anwendung auf einem Bare-Metal-Computer war das nicht möglich.
Seit der Einführung der Serverkonsolidierung hat sich die Virtualisierung weiterentwickelt, und das Konzept der Konsolidierung hat sich auf andere Ressourcen, einschließlich E/A- (Eingang/Ausgang, Input/Output) und Netzwerkelemente ausgeweitet.
Doch je weniger Ressourcen im Rechenzentrum für die Workloads vorhanden sind, desto öfter stoßen Unternehmen darauf, dass Konsolidierung nicht das Maß aller Dinge sein kann.
So gibt es innerhalb der Server physische Grenzen. Es gibt eine begrenzte Anzahl von Speicher- und CPU-Zyklen, die über die gesamte Infrastruktur hinweg genutzt werden können. Durch Virtualisierung ist es möglich, diese begrenzten Ressourcen bis zu einem gewissen Grad gemeinsam zu nutzen, jedoch nicht ohne das Risiko eines Leistungsabfalls in den virtuellen Maschinen (VMs).
Physikalische Grenzen bestehen außerdem beim Netzwerk. Admins können die verfügbare Bandbreite gemeinsam nutzen, aber die gesamte Netzwerkbandbreite ist begrenzt. Der Austausch von Daten über globale Entfernungen innerhalb akzeptabler Zeitrahmen erfordert eine große Bandbreite und führt Latenz als Problem ein.
Hinzu kommen erhöhte Risiken bei der Betriebssicherheit. Server, Speicher und Netzwerkgeräte fallen irgendwann aus. Die Folgen können lebenswichtige Bereiche der Rechenzentrumsinfrastruktur und alle VMs auf dem System betreffen. Bei herkömmlichen physischen Serverimplementierungen betrifft ein Serverausfall nur die gehostete Anwendung. Bei einem konsolidierten Server mit acht oder zehn virtuellen Maschinen würde sich derselbe Serverausfall auf alle diese VMs auswirken.
Wann Konsolidierung hinderlich ist
Unternehmens- und IT-Führungskräfte können in mehreren wichtigen Anwendungsfällen, bei denen Belastbarkeit, Entfernung, Größe und Isolierung der Infrastruktur wichtige Aspekte sind, ein überzeugendes Argument gegen eine Konsolidierung vorbringen.
Ausfallsicherheit
Redundante Workloads sind eine gängige Praxis, um den Durchsatz zu erhöhen. Anwendung können wichtige Arbeiten unter Verwendung von Load Balancern ausführen, um den Datenverkehr über doppelte Instanzen zu leiten. Obwohl die Anzahl der doppelten Instanzen die Redundanz erhöht, ist es die Wahl der Einsatzorte (physische Server), welche die Ausfallsicherheit der Anwendung gewährleistet.
Wenn es hauptsächlich darum geht, den Workload-Durchsatz zu erhöhen, können sich doppelte Instanzen potenziell auf demselben konsolidierten Server befinden. Dies gilt jedoch im Allgemeinen als suboptimal, da ein Systemfehler diese zusätzlichen Workload-Instanzen zeitgleich stoppen könnte.
Gilt es zeitgleich auf Anwendungselastizität zu achten, sollte ein Unternehmen niemals doppelte VM-Instanzen auf derselben Hardwarekonfiguration verorten. Stattdessen sollte sich jede redundante Workload-Instanz auf einem anderen Server befinden.
Eine unternehmenskritische Anwendung, deren Architektur auf Ausfallsicherheit ausgelegt ist, erfordert mindestens zwei Server, die leicht ausgelastet und so konfiguriert sind, dass sie Affinitäts- und Anti-Affinitäts-Hypervisor-Optionen einsetzen, um sicherzustellen, dass bei Live-Migrationen oder Neustarts nicht versehentlich Instanzen auf derselben Hardware lokalisiert werden.
Ein ähnlicher Konsolidierungsdruck ergibt sich bei Disaster-Recovery-Einrichtungen, bei denen sich eine doppelte Workload-Instanz auf einem zweiten Server an einem zweiten, möglicherweise entfernen Rechenzentrumsstandort oder sogar in der Public Cloud befinden kann.
Edge Computing und Internet of Things
Unternehmen nutzen eine wachsende Menge von Daten aus unterschiedlichen Quellen, um wichtige Geschäftsentscheidungen zu treffen, Forschung zu betreiben und unternehmenskritische Vorgänge zu automatisieren. Doch das Speichern und Verarbeiten von Daten stellen ein einzelnes zentralisiertes Rechenzentrum hinsichtlich Netzwerklatenz, Bandbreite und Zuverlässigkeit vor große Herausforderungen.
Viele Unternehmen wollen zum Beispiel ihre Produktionsanlage überwachen, aber nicht den Server dort unterbringen. Alle Sensordaten aus der Anlage müssen folglich zusammen mit der Ebene von Befehls- und Steuersignalen zur Verwaltung und zum Betrieb der Anlage über ein WAN in das konsolidierte Rechenzentrum gelangen.
Die Netzwerklatenz, die durch große geografische Entfernungen und weitläufige Netzwerkausrüstung entsteht, kann die Echtzeitsteuerung problematisch machen. Gleichzeitig können unvorhergesehene Unterbrechungen der WAN-Verfügbarkeit die zentralisierte Datenerfassung und -steuerung instabil machen.
Ein Einsatz von Rechen- und Speicherressourcen außerhalb des primären Rechenzentrums und in der Nähe des Standorts aus dem und zu dem Daten fließen sollen, kann diesen Prozess vereinfachen; dies wird üblicherweise als Edge-Computing bezeichnet.
Big Data und Skalierung
Ein Rechenzentrum kann durch die Anforderungen von Workloads für die Verarbeitung von Big Data stark belastet werden. Big Data kann die Rechenleistung von Hunderten oder sogar Tausenden von Servern erfordern, um Terabyte – oder sogar Petabyte – gespeicherte Daten für Verarbeitungsaufgaben auszuführen, die diese Server dann unter Umständen nur einige Stunden in Anspruch nehmen.
Es ist sicherlich möglich, Racks mit physischen Servern aufzustellen und eine Flotte von VMs innerhalb des Hauptrechenzentrums aufzustellen, um solche anspruchsvollen Aufgaben zu bewältigen. Die Kosten und die dafür notwendige Infrastruktur zur Unterstützung solcher Servermengen sind für die meisten Unternehmen jedoch kaum erschwinglich.
Anstatt langfristig in ein zentrales Rechenzentrum zu investieren, das auch Big Data verarbeiten kann, wenden sich Unternehmen häufig alternativen Rechen- und Speicherressourcen wie der Public Cloud zu, die nur dann Kosten verursacht, wenn sie benötigt wird (Opex). Die Technologie bietet Skalierung ohne große Investitionskosten.
Private und Hybrid Cloud
Doch nicht nur die Public Cloud ist eine Cloud. Viele Unternehmen sehen die Private Cloud als Antwort auf neue Geschäftsanforderungen. Mit neuen Diensten und Selbstbedienungsfunktionen (Self Service) können Mitarbeitern und Geschäftspartner Anwendungen und Dienste als Teil des regulären Geschäftsmodells des Unternehmens nutzen, anstatt darauf zu warten, dass die IT-Abteilung sie implementiert.
Beim Einführen von Private Cloud oder Hybrid Cloud kommt es zu ähnlichen Problemen wie bei der Verarbeitung von Big Data. Bei den meisten Rechenzentren handelt es sich um Live-Implementierungen, die auf Konsistenz, Regelmäßigkeit und Kontrolle im täglichen Betrieb angewiesen sind.
Es ist eher unwahrscheinlich, dass ein Unternehmen mit einem laufenden Rechenzentrum für die Produktion in die Private Cloud wechseln wird, und noch unwahrscheinlicher ist es, dass ein Unternehmen über die überschüssigen Rechen- und Speicherressourcen verfügt, um eine skalierbare Private Cloud direkt aufzubauen.
Natürlich besteht die Möglichkeit, eine neue Struktur für die Private Cloud zu errichten, oder aber das Unternehmen nimmt einen der vielen externen Privat-Cloud-Dienste neben dem eigenen Rechenzentrum in Anspruch: Alle größeren Public-Cloud-Anbieter haben virtuelle Private-Cloud-Dienste (VPC) im Angebot. Daneben gibt es auch Private Cloud als Service von Drittanbietern wie VMware, Cisco und IBM.
