von Redaktion IT-A…
Lesezeit
2 Minuten
Latenzen minimieren bei der Cloudmigration
Wer Workloads in die Cloud verschieben will, spielt vorher die effiziente Cloudnutzung durch. Das schließt den Ansatz "Compute in der Cloud, Daten lokal" wegen hoher Latenz meist aus. Das übliche Kopieren der Datensätze zum Cloudprovider dauert jedoch, wenn die WAN-Leitung nicht üppig bemessen ist. Sollen zudem andere Applikationen auf die Daten zugreifen, kommen NAS-Dienste ins Spiel, für die die Hyperscaler eher wenig bieten. Doch wie der Fachbeitrag zeigt, gibt es hier durchaus Alternativen.
Alles muss in die Cloud. Zu dieser Lesart verführt der Hype um Cloud Computing, aber das ist nicht zielführend. Eine Unternehmen legt eine solide Entscheidungsgrundlage, indem sie alle ihre Workloads kategorisiert. Buchhaltungssystem, Office, Kalender, E-Mail, Fachanwendungen und vieles mehr summieren sich schnell zu hunderten Workloads, die bei großen Unternehmen rasch die Tausendergrenze überschreiten. Danach wird geprüft, welche Applikationen bei einem Cloudbetrieb tatsächlich einen Geschäftsvorteil bringen und compliant sind. Nun stellt sich die Frage für den Workload: Alles in die Cloud?
Ein Workload wird nicht getrennt, oder?
Ein Workload besteht aus mehreren Komponenten, die aber eine Einheit bilden, und sollte deshalb nicht auseinandergerissen werden. Denn die nötige Kommunikation zwischen Teilen eines Workloads, die einerseits im Rechenzentrum und andererseits der Cloud laufen, erhöht die Latenz. Wer demnach einen Workload trennt, muss sich darüber im Klaren sein. Was also rechtfertigt beispielsweise das Rechnen in der Cloud und das Datenhalten On-Premises?
Ein Unternehmen könnte auf diese Weise etwa wiederkehrende Spitzen an Rechenkapazitäten, die die normale Last um das Fünf- bis Hundertfache übersteigen, aus der Cloud decken. Das sogenannte Cloud Bursting funktioniert mit Anwendungen, die weder auf einer komplexen Infrastruktur laufen, noch auf Interaktionen mit anderen Applikationen und Systemen angewiesen sind. Fällt ein Workload in diese Kategorie, sollte vor dem Trennen eine genaue Datenbetrachtung erfolgen.
Hadoop-Cluster rechnen mit Kopien
Diese Aufgabe stellt sich Versicherungen, die ihren Quartalsabschluss machen, genauso wie Onlineshops im Weihnachtsgeschäft oder Stromanbietern. Ein Energieversorger kalkuliert beispielsweise einmal im Quartal neu, um seine Preise zu optimieren. Die Berechnungen würden mit einem Hadoop-Cluster von 100 Knoten in der Cloud eine Woche dauern. Im eigenen Rechenzentrum hält der Stromanbieter 20 Knoten für ein Hadoop-Cluster vor, die sonst alle Berechnungen bestens abdecken. Die Daten liegen lokal, eine hohe Latenz und geringe Bandbreite verlangsamen das Rechnen, trotz der vielen Knoten in der Cloud. Die Firma kopiert deswegen unter anderem die Daten zum Wetter, von den Windrädern und Verbrauchern ins Speichersystem oder zu Speicherdiensten in der Cloud.
Zum Beispiel wird zu S3 von AWS kopiert. Dort erwartet EMR (Elastic MapReduce), der Hadoop-Dienst von AWS, die Daten. Diese Eingangsdaten sind üblicherweise sehr groß. Deshalb entscheidet sich der Versorger dazu, Datensätze sukzessive zu kopieren, sobald diese vorliegen. Bei vollständigen Eingangsdaten rechnet der Hadoop-Cluster los. Dabei wäre es sinnvoll zu überlegen, anstelle von 100 besser gleich 1000 Knoten zu buchen. Denn 1000 Knoten brauchen nur ein Zehntel der Zeit und kosten dasselbe. Der Ergebnisdatensatz wird danach entweder in der Cloud abgelegt, zurück ins Firmenrechenzentrum kopiert oder zurückgeschrieben.
ln/Oliver Krause, Cloud Solution Architect bei NetApp
Ein Workload wird nicht getrennt, oder?
Ein Workload besteht aus mehreren Komponenten, die aber eine Einheit bilden, und sollte deshalb nicht auseinandergerissen werden. Denn die nötige Kommunikation zwischen Teilen eines Workloads, die einerseits im Rechenzentrum und andererseits der Cloud laufen, erhöht die Latenz. Wer demnach einen Workload trennt, muss sich darüber im Klaren sein. Was also rechtfertigt beispielsweise das Rechnen in der Cloud und das Datenhalten On-Premises?
Ein Unternehmen könnte auf diese Weise etwa wiederkehrende Spitzen an Rechenkapazitäten, die die normale Last um das Fünf- bis Hundertfache übersteigen, aus der Cloud decken. Das sogenannte Cloud Bursting funktioniert mit Anwendungen, die weder auf einer komplexen Infrastruktur laufen, noch auf Interaktionen mit anderen Applikationen und Systemen angewiesen sind. Fällt ein Workload in diese Kategorie, sollte vor dem Trennen eine genaue Datenbetrachtung erfolgen.
Hadoop-Cluster rechnen mit Kopien
Diese Aufgabe stellt sich Versicherungen, die ihren Quartalsabschluss machen, genauso wie Onlineshops im Weihnachtsgeschäft oder Stromanbietern. Ein Energieversorger kalkuliert beispielsweise einmal im Quartal neu, um seine Preise zu optimieren. Die Berechnungen würden mit einem Hadoop-Cluster von 100 Knoten in der Cloud eine Woche dauern. Im eigenen Rechenzentrum hält der Stromanbieter 20 Knoten für ein Hadoop-Cluster vor, die sonst alle Berechnungen bestens abdecken. Die Daten liegen lokal, eine hohe Latenz und geringe Bandbreite verlangsamen das Rechnen, trotz der vielen Knoten in der Cloud. Die Firma kopiert deswegen unter anderem die Daten zum Wetter, von den Windrädern und Verbrauchern ins Speichersystem oder zu Speicherdiensten in der Cloud.
Zum Beispiel wird zu S3 von AWS kopiert. Dort erwartet EMR (Elastic MapReduce), der Hadoop-Dienst von AWS, die Daten. Diese Eingangsdaten sind üblicherweise sehr groß. Deshalb entscheidet sich der Versorger dazu, Datensätze sukzessive zu kopieren, sobald diese vorliegen. Bei vollständigen Eingangsdaten rechnet der Hadoop-Cluster los. Dabei wäre es sinnvoll zu überlegen, anstelle von 100 besser gleich 1000 Knoten zu buchen. Denn 1000 Knoten brauchen nur ein Zehntel der Zeit und kosten dasselbe. Der Ergebnisdatensatz wird danach entweder in der Cloud abgelegt, zurück ins Firmenrechenzentrum kopiert oder zurückgeschrieben.
Zum Kopieren der Daten von On-Premises in die Cloud können Unternehmen zu Open-Source-Tools greifen. Allerdings werden freie Werkzeuge umso langsamer, je größer die Datenmenge ist. Denn sie kopieren sequenziell, also ein File beziehungsweise einen Datensatz nach dem anderen. Beim Kopieren über WAN kommt noch hinzu, dass die Leitung nicht voll wird. Das Erstellen einer Kopie bei einer 1-GByte-Leitung mit einer Latenz von 30 Millisekunden dauert ewig. Die Lösung sind Dienste, die das Kopieren hochgradig parallelisieren, indem sie zwischen NAS und einem Objektspeicher wie S3 hin und her kopieren. In dem Fall ergibt Datensatzgröße geteilt durch Bandbreite ungefähr die Zeit, um die Daten zu kopieren. Die Rechnung geht beispielsweise mit NetApp Cloud Sync auf, da der Dienst die skizzierte Anforderung erfüllt.
| Seite 1 von 2 | Nächste Seite >> |
ln/Oliver Krause, Cloud Solution Architect bei NetApp
