Tipps für Cloud Storage: Private und Public Clouds verbinden
Public und Private Clouds haben sich durchgesetzt. Doch die Art und Weise, wie sie zusammenarbeiten können, hängt von vielen Faktoren ab. Wir erklären vier Anwendungsfälle.
Public und Private Clouds sind für die meisten Unternehmen nicht länger eine Entweder-Oder-Option. Stattdessen werden heute hybride Clouds als die beste Cloud-Praxis angesehen. Unternehmen wünschen sich außerdem Flexibilität bei der Wahl, welche Public Cloud sie einsetzen wollen, sowie die Fähigkeit, sich beziehungsweise ihre Daten zwischen verschiedenen Clouds bewegen zu können. Private und Public Clouds miteinander zu verbinden, bleibt jedoch eine Herausforderung.
Latenzen, Bandbreite und die Performance in der jeweiligen Cloud sind bestimmende Faktoren dafür, welche Daten in die Cloud gebracht werden und wie der Zugang zu ihnen organisiert wird. Anstatt sich auf die Suche nach der perfekten Cloud-Anwendung zu begeben, die alle Anforderungen eines Unternehmens erfüllen kann, sollten IT-Professionals mehr nach Lösungen für bestimmte Anwendungsfälle von Cloud Storage suchen.
Im Folgenden geht es um die vier effektivsten Strategien, mit denen sich eine lokale Infrastruktur und Private Clouds mit einer oder mehreren Public Clouds in besonders verbreiteten Anwendungsfällen von Cloud Storage verbinden lassen. Diese Anwendungsfälle umfassen Cloud Bursting, die Cloud als primäres Compute- und Storage-System, die Cloud als einen Backup- und Disaster-Recovery-Zielort sowie die Cloud als Datenarchivierung.
Cloud Bursting
Die meisten Unternehmen errichten ihre Rechenzentren sowohl bei den Storage- als auch den Computing-Anforderungen für die größten Krisenszenarien, wenn extreme Anforderungen an ihre Ressourcen auftreten. Zwischen diesen Spitzenbelastungen wird die Mehrzahl der Ressourcen nicht in Anspruch genommen. Wenn genug Workloads hinzugefūgt wurden oder wenn die bestehenden bis zu den Grenzen der Möglichkeiten des Rechenzentrums skalieren, beantragen die Unternehmen in der Regel zusätzliche Investitionen in diese Ressourcen.
Das Ziel von Cloud Bursting besteht darin, diesen kostspieligen Zyklus zu unterbrechen, bei dem man ununterbrochen einen Schritt vor dem nächsten Wachstumsschub bleiben muss, um eine Katastrophe schon im Ansatz zu vermeiden. Cloud Bursting bezeichnet insgesamt ein Deployment-Modell, in dem Anwendungen in einer Private Cloud ausgeführt werden und bei steigendem Bedarf nach mehr Rechenkapazität Public-Cloud-Ressourcen nutzen können. Der Vorteil eines solchen hybriden Cloud-Deployments ist die höhere Flexibilität und Skalierbarkeit, während für die Public-Cloud-Ressourcen nur bei der tatsächlichen Nutzung bezahlt wird.
Mit einer durchdachten Cloud-Bursting-Strategie können Unternehmen ihr Rechenzentrum auf den Normalfall anstelle einer Spitzenauslastung ausrichten. Wenn der Bedarf einmal die aktuellen Ressourcen des Rechenzentrums überschreitet, können sie bestimmte Anwendungen oder Workloads in die Cloud verlegen.
Die Qualität der Verbindung für Anwendungsfälle von Cloud Bursting hängt großenteils von der Sorgfalt der Planung im Vorfeld und der Einschätzung des Unternehmens ab, wie wichtig es ist, Workloads in die Cloud zu verschieben. Mit dem richtigen Ausmaß an Vorplanung – die natürlich eine relative Angelegenheit und kein einfacher Standard ist –, sollte eine normale Internetverbindung für Unternehmen ausreichen.
Vorausschauende Planung erfordert Replikation von Daten in die Cloud, bevor es zu einer Lastspitze kommt. Die Replikation muss fortlaufend durchgeführt werden, so dass die Kopie in der Cloud nie mehr als ein paar Minuten entfernt von der synchronen Kopie On-Premises ist – also so zeitnah, wie es nur geht.
Dieser aktuelle Ansatz hat auch Bedeutung für eventuell anstehende Disaster-Recovery-Maßnahmen, da geschäftskritische Anwendungen bevorzugt in die Cloud aufgenommen werden. Der Nachteil davon, bestimmte Anwendungen bevorzugt bei der Aufnahme in die Cloud zu behandeln, liegt darin, dass die Storage-Ressourcen der Cloud beständig in Anspruch genommen werden, was auch die Kosten der Cloud erhöht.
Wenn es ein Unternehmen wünscht, Workloads in die Cloud dynamischer zu übernehmen, muss es in viel schnellere Verbindungen investieren. Ein flexiblerer Ansatz versteift sich nicht auf die Inanspruchnahme zusätzlicher Cloud-Ressourcen, sondern geht mehr von jeweils aktuellen Situationen aus, wenn weitere Verlagerungen von Workloads in die Cloud anfallen – was natürlich auch bestimmte Reserven voraussetzt. Es gibt auch Anwendungen, die Daten leichter verschieben können, als es mit den typischen Werkzeugen für File Transfers möglich ist.
Die Cloud als primärer Speicher
Möglicherweise besteht der interessanteste Anwendungsfall von Cloud Storage – aber auch der mit den meisten Risiken – darin, die Cloud als primären Speicher- oder primären Compute-Standort zu benutzen. Um die Cloud für primäres Storage einzusetzen, muss man alle Latenzprobleme lösen. Anders als bei Cloud-Backup und -Recovery, wo die Verbindungsproblematik mehr eine Frage der Bandbreite ist, ist primäres Storage in der Regel mehr transaktional ausgerichtet, was die Latenzen zum entscheidenden Problem macht.
Ein hauptsächlicher Einsatzgrund für die Cloud als primären Speicher findet sich bei Network Attached Storage (NAS). Hersteller auf diesem Gebiet konzentrieren sich darauf, ein Cloud-basiertes File System zu erzeugen, das automatisch eine Kopie der besonders aktiven Daten auf einer lokalen Appliance oder einem Edge-Gerät anlegt. Wenn ein Anwender On-Premises diese Daten modifiziert oder verändert, wird die Cloud-Kopie auf den neuesten Stand gebracht. Wenn der Anwender eine Datei öffnet, die sich nicht auf dem lokalen Edge-Gerät befindet, wird sie anschließend aus der Cloud zurückgeholt. In den meisten Fällen fällt die dazu benötigte Zeit kaum auf, außer es handelt sich um eine große Datei.
Unternehmen können diese Edge-Appliances leicht in alle ihre Rechenzentren und externen Büros integrieren, da alle Storage-Systeme sich effektiv an einem Ort befinden – in der Cloud. Ein paar Hersteller auf diesem Gebiet haben auch globale File-Locking-Fähigkeiten hinzugefügt: Wenn eine Datei an einem bestimmten Ort benutzt wird, sehen Anwender an allen Orten einen Read-Only-Hinweis, wenn sie auf die gleiche Datei zugreifen wollen.
Einige dieser Systeme unterstützen auch den Multi-Cloud-Einsatz. Wenn ein Volume erzeugt wird, kann es der Administrator mit einem bestimmten Cloud-Account verbinden. Das Bewegen von Daten zwischen verschiedenen Providern erfordert, dass eine Kopie von einem Volume zu einem anderen verschoben wird – dies bedeutet dann, dass alle Daten durch die lokale Appliance zurückgeroutet werden.
Die Cloud-Instanzen von primärem Block Storage bringen mehr Probleme mit sich als File Storage. Erstens verhalten sich Anwendungen nicht so geduldig wie Anwender, die auf Files warten. Anwendungen schalten sich ab oder es kommt sogar zu einem Absturz, wenn Daten nicht schnell genug erreichbar sind. In der Vergangenheit bestand der einzige Weg zu einer gewissen Anwendungsstabilität darin, die lokale Anwendung groß genug zu machen, so dass die Gefahr sehr klein war, Daten könnten nicht auf ihr vorhanden sein. Das Problem besteht aber darin, dass diese Methode kein Geld einspart.
Es gibt mehrere Methoden, dieses Problem zu lösen. Zum Beispiel verfügen viele Cloud-Provider nun über Optionen zur direkten Verbindung, bei denen ein standardmäßiges Storage-System von Unternehmen direkt verbunden ist mit Compute-Ressourcen in der Cloud.
Die Hersteller arbeiten mit Hosting-Providern zusammen, die sich in der Nähe von Public-Cloud-Providern befinden, so dass eine Highspeed-Verbindung möglich ist. Bei diesem Szenario handelt es sich darum, dass ein Unternehmen die Cloud vor allem wegen ihrer Compute-Ressourcen und ein mehr traditionelles Storage-System für das Speichern der Daten verwendet. Man kann auch Backup-Anwendungen für dieses traditionelle Speichersystem einsetzen und dann diese Backups in einem Cloud-Speicher ablegen. Weil die Verbindung so nahe und so schnell ist, lassen sich diese Backups relativ zügig durchführen.
Multi-Clouds erleichtern Datentransporte
Es gibt verschiedene Einrichtungen für Managed Hosting, die über direkten Zugang zu mehreren Public-Cloud-Providern verfügen. Diese Firmen befinden sich physisch und geographisch so nahe an den Rechenzentren der Public-Cloud-Provider, dass deren Computing-Ressourcen mit solch geringen Latenzen auf Storage zugreifen können, wie sie in diesen Fällen innerhalb des Rechenzentrums des Providers anzutreffen sind. Da die Daten hier praktisch „stationär“ sind, sind keine Migrationsprozesse erforderlich. Wenn das Unternehmen einen anderen Provider wegen dessen leistungsfähigerer oder billigerer Rechenfunktionalitäten einsetzen will, dann können die IT-Aufgaben leicht zwischen verschiedenen Providern verschoben werden.
Eine andere Option besteht darin, Daten in einem sekundären Tier abzulegen, bevor sie in der Cloud gespeichert werden. Mit diesen Multi-Tier-Angeboten können Unternehmen relativ kleine Flash-basierte Zwischenspeicher lokal für aktive Daten einrichten, die für einen geographisch nahen sekundären Provider als Tier dienen, um „warme“ Daten zu speichern. Sobald die Daten sehr „kalt“ sind, werden sie ausschließlich in der Cloud gespeichert.
Das Resultat ist ein On-Premises-Zwischenspeicher, der in seiner Größe der Kapazität der täglich aktiven Daten entspricht, während „warme“ Daten nur ein paar Millisekunden entfernt sind und so nicht die Ausführung von Anwendungen behindern. Alle Daten werden zur Cloud repliziert, wenn sie erzeugt oder verändert werden, aber die Replikation verläuft asynchron, so dass sie nicht die produktive Performance tangiert. Diese Cloud-Kopie fungiert als eine Disaster-Recovery-Kopie. Das bedeutet auch, dass Daten nicht noch einmal kopiert werden müssen, wenn sie aus den ersten und sekundären Tiers herausfallen. Sie werden ganz einfach aus diesen Tiers gelöscht, da sie sich bereits in dem Cloud-Tier befinden.
Die Storage-Strategie für Multi-Tier Primary Cloud unterstützt in der Regel mehrere Clouds, aber da Daten irgendwann auch einmal in einer einzigen Cloud als zentrales Repository gespeichert sein können, bleibt das Verschieben zwischen Providern der gleiche Prozess wie bei jeder anderen Migrationsaufgabe. Die lokale Appliance-Strategie kann sich auf mehrere Clouds erstrecken, aber aller Wahrscheinlichkeit nach müssen alle Daten im Gegensatz dazu zurück auf ein On-Premises-System migriert werden, bevor sie zu dem neuen Provider gesendet werden.
Cloud-Backup und -Recovery
Der populärste und oft erste Einsatzzweck für die Verbindung einer lokalen Infrastruktur und Public Clouds besteht im Backup und Recovery von Daten. Wegen Technologien wie Komprimierung, Deduplizierung und inkrementellen Backups auf Block-Niveau muss die Verbindung zwischen einem lokalen Backup-System und einer Public-Cloud-Speicherinstanz nicht besonders schnell sein. Eine elementare Verbindung für Geschäftszwecke reicht in der Regel aus.
In Sachen lokaler Backup-Speicher hat jeder Hersteller sein eigenes Verfahren. Traditionelle Backup-Hersteller sehen On-Premises-Speicher oft als die primäre Backup-Kopie und die Cloud-Kopie nur als Mittel für Disaster-Recovery-Zwecke. Die Cloud wird als ein Ersatz für Tape angesehen. Andere, modernere Backup-Angebote betrachten Public-Cloud-Storage als eine Methode mit einem eigenen Wert. Ein lokales Gerät dient als Zwischenspeicher (Cache) oder Tier, und ältere Backups werden je nach Zugangszeiten automatisch zu einem Public-Cloud-Tier verschoben. Der Vorteil der Cache-Tier-Methode besteht darin, dass die On-Premises-Investition relativ klein ausfällt und selten erneuert oder erweitert werden muss.
Während Komprimierung, Deduplizierung und inkrementelle Backups auf Block-Niveau die erforderliche Bandbreite für den Backup-Prozess gesenkt haben, wandten sich die Backup-Hersteller erst vor kurzem Restores zu, indem sie auf die Vorteile von Disaster Recovery as a Service setzten. DRaaS ermöglicht die Wiederherstellung von Anwendungen als eine virtuelle Maschine in der Cloud und eliminiert vorübergehend das Problem einer schnellen Verbindung zurück zum lokalen Rechenzentrum. Im Katastrophenfall befindet sich der komplette Prozess der Verschiebung von Daten innerhalb des Cloud-Rechenzentrums und kommt ohne eine Internetverbindung aus. Abhängig davon, wie die Software Cloud-Ressourcen benutzt, können die Anwendungen innerhalb von vier Stunden wieder ihren Betrieb aufnehmen, nachdem eine Katastrophe offiziell erklärt worden ist.
Wenn die IT-Abteilung entscheidet, die Anwendung zurück ins lokale Rechenzentrum zu verschieben, wird die Internetbandbreite zu einem Problem werden, außer der Cloud Provider verfügt über die Fähigkeit, Daten in großen Mengen zu verschicken. Während manche DRaaS-Tools Daten im Hintergrund zurück ins lokale Rechenzentrum replizieren können, wird dieser Prozess bei einer Verbindung mit niedriger Bandbreite Tage, wenn nicht Wochen dauern – und eine Stange Geld kosten. Leider sind Technologien wie Deduplizierung und Block-Level inkrementelles Backup nicht hilfreich, wenn es um die Recovery-Geschwindigkeit geht.
Was stellt man mit den Backup-Daten an, wenn sie in der Cloud angekommen sind?
In vielen Fällen wird es einem Unternehmen ausreichen, wenn die Backup-Daten in der Cloud nur dann verwendet werden, wenn eine Recovery-Anfrage auftaucht. Doch in anderen Fällen wird man mehr mit den Daten machen und dazu Computing-Ressourcen der Cloud nutzen wollen. Weil DRaaS zum Beispiel sowieso Computing-Ressourcen und nicht nur Cloud Storage benutzt, wird es für ein Unternehmen nahe liegen, die Cloud-Kopie seiner Daten für Tests, Entwicklung oder Durchführung von Reports und Analytics zu verwenden.
Das Problem dabei ist, dass die meisten Backup-Anwendungen Daten in einem proprietären Format speichern, das nicht direkt von Computing-Ressourcen der Cloud gelesen werden kann. Dies bedeutet, dass die IT-Abteilung zuerst die Daten wieder in ihrem natürlichen Format herstellen muss. Wenn Zeit und Aufwand für diese Wiederherstellung zu unproduktiv sind, sollte man sich nach einer Backup-Anwendung umsehen, die Daten in ihrem natürlichen Format speichert.
Alte Daten archivieren
Ein Archiv in der Cloud ist eigentlich der beste Anwendungsfall, da es in der Regel keine Änderungen an der Netzwerkbandbreite erfordert und da es einen deutlichen Return on Investment (ROI) liefert. Archivierungsprodukte analysieren produktive Speicherdaten im Rechenzentrum, die in einem festgelegten Zeitraum nicht mehr genutzt worden sind – in der Regel mehr als ein Jahr. Diese Dateien werden dann zu einem sekundären Speichergerät verschoben, das auf einer Terabyte-Basis geringere Kosten verursacht.
Das Problem mit traditionellen Archivierungsangeboten besteht darin, dass sie eine deutliche zusätzliche Investition in ein sekundäres Speichersystem erfordern – in der Regel 50 Terabyte oder mehr. Die meisten Unternehmen werden anfangs keine 50 Terabyte Kapazität für Archivierung zur Verfügung haben. Und selbst wenn sie sie besitzen, werden sie dabei kaum an Archivierung denken. Cloud-Archivierung löst dieses Problem, indem Daten nach und nach je nach Bedarf auf einer Gigabyte-Basis archiviert werden.
Der schrittweise Ansatz ermöglicht den Einsatz von Netzwerken mit eher bescheidener Bandbreite. Per Definition wird auf Archive selten zugegriffen, so dass bei diesem Szenario die Netzwerkbandbreite nicht die gleiche Rolle spielt wie bei anderen Anwendungsfällen von Cloud Storage.
Ein Problembereich sind die Metadaten. In den meisten Speicher-I/O-Prozessen spielen Metadaten eine Rolle. Will ein Anwender zum Beispiel eine Liste eines in der Cloud archivierten Verzeichnisses erstellen, dann müssen alle diese Metadaten über eine Breitbandverbindung gesendet werden, was Zeit kostet. Um das Metadaten-Problem zu vermeiden, speichern einige Hersteller die Metadaten lokal und in der Cloud, so dass Queries auf die lokale Kopie der Metadaten zugreifen und die Anwender eine sofortige Antwort erhalten.
Die meisten Angebote für Cloud-Archive können Daten zu mehreren Clouds senden und einige können sogar mehrere Clouds gleichzeitig unterstützen. Das Problem beim Wechseln zwischen verschiedenen Providern besteht in den Kosten und der Zeit, um Daten von einem Cloud-Ort zu einem anderen zu bewegen, was besonders im Fall von Archiven die Migration einer großen Menge an Informationen bedeutet. Das gleiche Problem tritt auf, wenn ein Unternehmen ein Archiv wieder aus der Cloud herausholen und seine Daten lokal speichern will, weil die Mietkosten in der Cloud teurer sind als der Kaufpreis eines On-Premises-Objekt-Speichers. Vorher in der Cloud gespeicherte Archivdaten zurück in das eigene Rechenzentrum zu transferieren, dauert seine Zeit und ist wegen der Netzwerk- und Ausstiegsgebühren teuer.
Die eigene private Cloud mit der Public Cloud zu verbinden, ist einfacher denn jemals zuvor. Es gibt eine Reihe von Anwendungsfällen für Cloud Storage, bei denen lokale und Public-Speichersysteme gut zusammenarbeiten. Es gibt andere Fälle, in denen die Public Cloud ein geeigneter Ersatz sein könnte. Unternehmen müssen einen Plan entwickeln und Schritt für Schritt umsetzen, wenn möglich in Etappen. Es ist sinnvoll, sich auf bestimmte Anwendungsfälle zu konzentrieren und sich dann anderen zuzuwenden, wenn sich Erfolg und Durchführbarkeit mit der Cloud durchsetzen.