Scale-Out or Scale-Up
Die Begriffe Scale-out und Scale-Up sind seit Jahren, gerade im Storagebereich, in aller Munde. Viele wissen aber gar nicht, dass sie schon seit Jahren bereits eine Scale-Out Infrastruktur betreiben. Und zwar ihre Virtualisierungsumgebung. Die skaliert nämlich in die Breite! Benötige man mehr Rechenleistung, so fügt man einfach weitere Server hinzu. Zusätzlich zur Rechenleistung bekommt man dann auch mehr Arbeitsspeicher, und zusätzliche Netzwerkanschlüsse, was wiederrum mehr Bandbreite für die Virtuellen Maschinen bedeutet. Und warum funktioniert das? Weil eine Abstraktion stattfindet. Zwischen der Hardware (CPU, Arbeitsspeicher, …) der Server und der Virtuellen Maschinen.
Der nächste Schritt ist es nun, selbiges mit Storage zu machen. Traditionelle Storage Systeme sind starr. Es handelt sich hier oft um Scale-Up Systeme, die eine gewisse Rechenleistung und eine gewisse Speicherkapazität verfügen. Wird mehr Speicherplatz oder Performance benötigt, müssen Disken ausgetauscht oder hinzugefügt werden, Storage Prozessoren durch stärkere ersetzt werden, Cache oder Flashspeicher hinzugefügt werden. Würde es aber die Möglichkeit geben, dass die Speicherkapazität und die Performance des darunterliegenden Storage mit der Anzahl der Server, und somit auch mit der Anzahl der VMs mitwächst, dann erspart man sich das ewige Nachbessern auf dem Storagesystem. Zum Glück gibt es solche Lösungen schon, man nennt sie „Hyper-converged infrastructure“.
Hyper-converged Infrastructure
Bei einer Hyper-converged infrastructure wird also das Storagesystem mit meinen Servern verschmolzen. Jeder Server virtualisiert somit nicht nur die Hardware, sondern es findet auch eine Virtualisierung der lokalen Hard Disk Drives statt. Die Disken aller Server werden zu einem oder mehreren virtuellen Storage Pools vereint. In welcher Form die Daten dann redundant gehalten werden, ist je nach Lösung unterschiedlich. Fakt ist jedoch, dass eine Replikation der Daten zwischen den einzelnen Servern stattfinden muss, da es sonst, bei Ausfall eines Servers, zum Stillstand des Storage Pools kommen würde. Die Replikation der Daten hat jedoch zur Folge, dass jeder I/O einer Virtuellen Maschine (Front-End I/O) einen I/O im Storage Back-End (Back-End I/O) verursacht. Bei Datenverteilung auf mehrere Server, um den Ausfall mehrere Server zu überstehen, verändert sich das Verhältnis natürlich zwischen Front-End I/O und Back-End I/Os auf 1:2, 1:3, 1:4, usw. Möchte man dazu noch heute gängige Technologien wie Deduplication und Compression verwenden, erhöht sich der Aufwand um den Storage Pools zu managen. Das beeinflusst einerseits die CPU Auslastung der Server und andererseits die Performance des Storage.
Optimierung durch Simplivity
Simplivity versucht hier einen anderen Weg. Diese innovative Hyper-converged Infrastructur sieht ebenfalls Datenreplikation zwischen den Servern vor. Jedoch wird die Datenreplikation, die In-Line Deduplikation und die In-Line Compression mit einer eigens entwickelten Hardwarekarte, der OmniStack Accelerator Card, unterstützt. Diese übernimmt einerseits Tätigkeiten, die ansonsten die CPU durchführen müsste, und andererseits optimiert sie die Daten bevor sie geschrieben werden. Durch die Optimierung der Front-End I/Os, werden nur mehr die Back-End I/Os geschrieben, die auch wirklich benötigt werden. Simplivity geht hier der Strategie „The best IO is the one you don’t have to do” nach. Was soviel bedeutet, wie „warum soll man auch einen Back-End I/O schreiben, wenn die Daten bereits auf den Disken liegen“.
Die Funktionen eines Global Unified Management, welches die Konfiguration direkt aus dem vSphere Client ermöglicht, und die Möglichkeit Snapshots und eine asynchrone Datenreplikation für Disaster Recovery durchzuführen, runden diese Lösung in ihrer Funktion noch weiter ab. Eine Infrastruktur von Simplivity ersetzt somit nicht nur die Shared Storage für die Server, sondern auch Backup Software, Backup-to-Disk Device, Disaster Recovery Software, und deren einzelnen Managementsysteme.
Zusätzlicher Blog Beitrag Simplivity und Hyper-converged Infrastructure:
http://opennetworks.at/die-antwort-auf-hyperconverged-infrastructure/