Tipps zum Verbessern der Infrastruktur-Performance
Der Bedarf hoher Performance für Apps erfordert oft eine Reduzierung der Latenzzeiten, indem entweder die Daten näher an die Compute-Ressource gebracht wird oder umgekehrt.
Zeit ist überall das Wichtigste. Zeit ist eine nicht erneuerbare Ressource, die sich nur vorwärts bewegt. Einmal genutzt (oder verbracht), kann sie nicht mehr zurückgenommen oder zurückgespult werden. Zeit ist das Konstrukt, das Ereignisse und Momente trennt. Im IT-Betrieb gibt es nie genug davon. Niemand hat je gesagt, dass er weniger Zeit braucht. Es gibt immer wieder Druck, mit jeder Sekunde mehr zu tun.
Nehmen wir das Beispiel des High-Performance-Computing (HPC), auch bekannt als Supercomputing, und das ständige Streben, die Anzahl der Floating-Point Operations pro Sekunde (FLOPS) zu erhöhen. Gemessen heute in den Dutzenden bis Hunderten von petaFLOPS, ist das nächste Ziel exaFLOPS, tausend Mal schneller.
Dieselben rasanten Anforderungen sind auch im Storage deutlich zu erkennen. Die Leistung der Speicherinfrastruktur wird in IOPS und Durchsatz pro Sekunde gemessen – von Megabyte bis Gigabyte pro Sekunde bis hin zu Terabyte pro Sekunde.
Es ist dieser permanente Bedarf an mehr Infrastrukturleistung pro Sekunde, der zu der Frage führt: Macht es mehr Sinn, die Daten oder die Compute-Ressource zu verschieben?
Nur keine Überraschungen
Die allgemeine Meinung besagt, dass es sinnvoller ist, Compute näher an die Daten zu bringen, und in den meisten Anwendungsfällen ist es das auch. Es ist im Allgemeinen einfacher und schneller, da die ausführbare Datei viel weniger Daten enthält, die in einem Netzwerk oder einer Verbindung bewegt werden müssen, als Eingabedaten. Die Datenbewegung erfordert Netzwerkbandbreite, Zeit und in den meisten Situationen die richtigen manuellen Handgriffe. Allein der Personalbedarf treibt viele IT-Manager an, den Compute näher an die Daten zu bringen.
Ein ausgezeichnetes Beispiel dafür ist die Hadoop-Architektur. Der Hadoop JobTracker ist in der Lage, einzelne Aufgaben auf den Rechenknoten zu verteilen, auf dem sich die benötigten Daten befinden. Wenn dieser spezielle Rechenknoten für einen Auftrag nicht verfügbar ist, versucht er, diesen Auftrag auf einem Rechenknoten innerhalb desselben Racks zu planen. Wenn auch dieser nicht verfügbar ist, wird der Auftrag an anderer Stelle im Rechnerverbund eingeplant. Der Hadoop JobTracker Planungsalgorithmus braucht zu viel Zeit, um Eingabedaten in den Rechenknoten zu verschieben. Das Verschieben von Daten erhöht die Latenzzeit des Auftrags und erhöht die Reaktionszeit.
Das Hadoop-Beispiel ist nur ein Szenario, wo das Näherbringen des Compute an die Daten wirklich sinnvoll ist. Ein weiteres Beispiel ist, wenn die Bandbreite zwischen dem Compute und den Daten unzureichend ist. Es gibt jedoch noch andere Umstände, unter denen das Verschieben der Compute-Ressource so kostspielig oder komplex ist, dass sie nicht durchführbar ist. Und es gibt Szenarien, bei denen das Verschieben der Daten (an den Compute) aufgrund von Workflows, Zusammenarbeit, Sicherheit oder Infrastruktur sinnvoller ist.
Lassen Sie uns jedes dieser Szenarien aufschlüsseln und klären, wann es sinnvoller ist, die Daten oder die Compute-Ressource zu verschieben.
Compute an die Daten rücken
Wie der Hadoop JobTracker zeigt, ist es in der Regel einfacher und schneller, den Compute und nicht die Daten zu verschieben. Die Leistung der Infrastruktur ist oft schneller, wenn die Compute-Ressource näher an den Daten liegt. Dies ergibt sich direkt aus der kürzeren Entfernung. Die Entfernung entspricht der Latenzzeit. Latenzzeiten reduzieren die Performance der Infrastruktur und sind direkt an die Lichtgeschwindigkeit gebunden. Lichtgeschwindigkeit und Entfernung werden weiterhin ein Latenzproblem sein, bis die Wurmloch-Technologie erfunden ist, was nicht in baldiger Zukunft geschehen wird. Die Reduzierung von Distanz und Latenz verbessert die Performance pro Sekunde, wenn die Latenz die Leistung pro Zeitengpass (Bottleneck) ist. Wenn der Engpass die CPU, Memory, die Softwareineffizienz oder die Speicherinfrastruktur ist, werden die Verbesserungen jedoch begrenzt sein.
Einsatzszenarien, wenn Compute näher an die Daten gebracht werden
Zahlreiche Transaktionen mit geringer Latenz
Cloud-Verarbeitung von Daten, die in der Cloud gespeichert sind
HPC parallele Dateisysteme
In-Memory relationale SQL-Datenbanken
Hoch-performante Storage-Umgebungen
Anwendungen, die am meisten davon profitieren, wenn sie den Rechenvorgang und die Daten näher zusammenrücken, sind wahrscheinlich latenzempfindlich. Transaktionsanwendungen mit großem Volumen, wie zum Beispiel der Hochfrequenzhandel, sind ideal, da in diesem Raum Mikrosekunden (µs) Millionen von Dollar entsprechen. Andere großvolumige transaktionale Anwendungen, die auf diese Weise profitieren, sind HPC, Online-Transaktionsabwicklung, E-Commerce und Online Gaming. Alle diese Anwendungen sehen Vorteile in der Reduzierung der Latenzzeit, indem sie Compute näher an die Daten heranführen.
Der Wert der Verschiebung des Computes an die Daten wird deutlich, wenn eine große Datenmenge über ein WAN bewegt werden muss. Ein gutes Beispiel ist, wenn Sie zum Beispiel ein Petabyte an Daten in einem Cloud-Repository haben, die über eine Netzwerkverbindung an einen anderen Standort verschoben werden müssen. So funktionieren Hardware-Sicherheitsmodule, auch bekannt als Appliances und Cloud-Speicher-Gateways. Daten, die über diese Appliances in die Cloud verschoben wurden, müssen wieder in den ursprünglichen Speicher verbracht werden, damit man sie lesen, verarbeiten oder ändern kann.
Bei einer Bandbreite von 1 GByte/s und der theoretischen Leistung von 125 MBps wird es ziemlich lange dauern, bis man an diese Daten gelangt. TCP/IP wird nicht die theoretische mögliche Performance liefern. Selbst wenn das theoretische Optimum erreichbar wäre, würde es mindestens 93 Tage dauern, bis ein Petabyte Daten ans Ziel gebracht wird. Das wahrscheinlichere Szenario ist, dass der Durchsatz bei etwa 30 Prozent der Nennleistung liegt, was dann etwa 309 Tage oder mehr als 10 Monate für die Datenbewegung bedeuten würde. Selbst bei WAN-Optimierern wird der Zeitaufwand irgendwo dazwischen liegen und immer noch zu lange dauern.
Das Näherbringen des Compute an die Daten in diesem Szenario nimmt deutlich weniger Zeit in Anspruch. Dies ist der Prozess, bei dem eine Recheninstanz mit der Anwendung in der Cloud verbunden wird, um die in der Cloud gespeicherten Daten zu verarbeiten. Nach Abschluss der Verarbeitung wird die Instanz außer Betrieb genommen, um nicht dafür bezahlen zu müssen, obwohl man sie nicht mehr nutzt. Die Verarbeitung der Daten erfolgt viel früher, als wenn man die Daten vor Ort in den Hadoop JobTracker transferiert. Es spart auch enorme Kosten für Cloud-Speichergebühren.
Eine weitere Anwendung, die davon profitiert, dass die Compute näher an den Daten sitzt, sind parallele I/Os, die in vielen HPC-Ökosystemen verwendet werden. Hier verarbeitet ein HPC große Datenmengen parallel über ein paralleles Dateisystem wie Lustre, Panasas, Quobyte, IBM Spectrum Scale (ehemals GPFS) und WekaIO. Um die Latenzanforderungen des parallelen Dateisystems zu erfüllen, müssen in der Regel Daten in den internen Speicher jedes HPC-Serverknotens abgelegt werden, um die Latenzzeit zu verkürzen. Non-Volatile Memory over Fabrics (NVMe-oF) und Remote Direct Memory Access (RDMA) verändern diese Anforderung etwas, indem sie die Netzwerklatenz reduzieren und bis zu einem gewissen Grad die Auswirkungen von Entfernungslatenzen minimieren.
Allerdings reduziert es beides, wenn man Compute relativ nah an den gespeicherten Daten hält. Die gleichen Prinzipien, die von Hadoop JobTracker so effizient eingesetzt werden, werden auch von HPC-Jobplanern wie Slurm Workload Manager verwendet. Slurm ist ein Open-Source-Tool und plant jeden Auftrag auf dem Knoten oder den Knoten mit den verfügbaren Ressourcen, die den Daten am nächsten sind, um die beste Leistung zu erzielen. Der neue gemeinsame Rack-Scale Flash-Speicher vereinfacht dies mit nur einem Minimum an zusätzlichen NVMe-oF-Latenzen im Bereich von 5 µs bis 10 µs.
Mehrere relationale SQL-Datenbanken, wie Oracle Database und SAP HANA, haben Versionen, die alle Daten mittels In-Memory verarbeiten. Hier werden sowohl die geringere Latenzzeit und höhere Leistung des DRAM als auch die geringere Latenzzeit genutzt, da er extrem nahe am Compute liegt, um eine deutlich verbesserte Datenbankleistung zu erzielen. Die hohen Kosten limitieren es jedoch auf die anspruchsvollsten I/O-Leistungsanwendungen.
Wenn man den Compute näher an die Daten heranbringt, kann dies auch zu erheblichen Leistungssteigerungen der Infrastruktur für einige Hochleistungsspeicherarchitekturen führen. Speichersoftware-Dienste sind in der Regel CPU- und speicherintensiv. Durch die Annäherung der Rechnerinstanz an die Daten können viele Prozesse vom Storage-Controller entfernt werden, so dass dieser für Lese-/Schreibvorgänge zur Verfügung stehen. Dieses SSD-Nearline-Controller-Co-processing entlastet die CPU des Storage-Controllers von redundanten, leistungsschwachen Aufgaben. Das verbessert jedoch nicht immer die Speicherleistung, kann die Kosten erhöhen und die Leistung beeinträchtigen.
Die Daten näher an die Compute-Ressource bringen
Das Verschieben der Daten an den Compute bedeutet in der Regel, dass die Leistung der Infrastruktur nicht im Vordergrund steht. Die häufigsten Gründe, dies zu tun, sind wahrscheinlich Kosten, Sicherheit, Komfort und Einfachheit.
Ein Einsatzgebiet ist die Collaboration. Es ist hier fast unmöglich, Compute-Ressourcen näher an die Daten zu bringen, wenn die Mitarbeiter verschiedenen Organisationen, Unternehmen und geografischen Gebieten angehören und unterschiedliche Anwendungen verwenden. Nur wenige Unternehmen werden es Außenstehenden gestatten, auf ihre Systeme hinter ihren Sicherheits-Tools zuzugreifen, um nicht genehmigte Anwendungen zu implementieren. Daher zwingen Collaboration-Workflows in heterogenen Unternehmen in der Regel dazu, dass die Daten an Compute herangebracht werden. Es gibt viele Collaboration-Anwendungen wie Box, Atlassian Confluence, Dropbox, Google Drive, Atlassian Jira und Microsoft OneDrive, die alle die Daten an den Compute leiten.
Der Wert der Verschiebung des Computes an die Daten wird deutlich, wenn eine große Datenmenge über ein WAN bewegt werden muss.
Cloud Bursting, das verwendet wird, um die Elastizität des Cloud-Compute zu nutzen, wenn lokale Ressourcen nicht verfügbar sind, ist ein weiterer Anwendungsfall, bei dem Daten an den Compute verschoben werden müssen. In diesem Szenario werden Daten kopiert und an die Cloud gesendet, wo eine Cloud-Compute-Instanz mit der Anwendung erstellt wird, die diese Daten verarbeitet. Die Ergebnisse werden dann wieder vor Ort migriert, die Cloud-Datenkopie wird gelöscht und die Cloud-Instanz angeschaltet. Dies ist ein kostengünstiger Anwendungsfall, wenn der lokale Compute aufgrund unerwarteter, temporärer oder saisonaler Nachfrage vorübergehend unzureichend ist.
Die Analytik ist ein bereits beschriebenes Szenario, bei dem Compute an die Daten rückt. Trotzdem kann es auch hierbei sinnvoll sein, die Daten an den Compute zu transferieren. Analytics Engines müssen Daten lesen, um sie zu analysieren. Dazu müssen Daten, die in den meisten Fällen benötigt werden, zur effektiven Analyse in die Analyse-Engine verschoben werden.
Spark ist die Analyse-Engine für Hadoop, bei der die Daten auf mehreren Hadoop-Knoten des verteilten Dateisystems (HDFS) liegen müssen, um die beste Leistung zu erzielen. Und obwohl es Datei- und Objektspeichersysteme gibt, die Datei- oder Objektdaten als HDFS erscheinen lassen können, bieten sie nicht immer eine ausreichende Leistung, was bedeutet, dass Daten auf den Hadoop-Speicher verschoben werden müssen. Bei NoSQL-Datenbanken wie Apache Cassandra, Couchbase, DataStax, Apache HBase, MemcacheDB, MongoDB, Neo4J, SAP OrientDB und Redis müssen die Daten ebenfalls an die jeweilige Datenbank gesendet werden.
Die Aggregation ist ein weiteres Szenario für die Übertragung der Daten an den Compute, ein Beispiel hier ist das IoT. Tausende bis Millionen bis Milliarden von Geräten erzeugen Daten, die für Echtzeitanalysen und langfristige Batch-Erkennungen aggregiert werden. Künstliche Intelligenz für den IT-Betrieb (AIOps) ist ein Beispiel für diese Maschinen-Datenaggregation und Echtzeit-Analytik. AIOps-Produkte kommen von vielen Anbietern, wie BMC Software, Correlsense, Corvil, Hewlett Packard Enterprise, IBM, ITRS Group, Moogsoft, SAP, Splunk und StrongBox Data Solutions.
Verteilte Multinode-Speichersysteme sind ebenso ein Anwendungsfall, bei dem die Daten zur Rechnerinstanz transferiert werden. Mehrere verteilte Speichersysteme sorgen für die Load Balance und verschieben gespeicherte Daten über die verschiedenen Speicherknoten, um sicherzustellen, dass die Leistung optimiert wird.
Was ist die bessere Wahl?
Ob nun der Compute zu den Daten oder die Daten zum Compute kommt, um Performance und Zeitersparnis zu erhöhen, hängt von der Anwendung ab. Es gibt keine absolute Wahrheit, und in mehreren Fällen gelten beide für verschiedene Aspekte des Anwendungsfalles. Die Antwort nach der besten Option besteht letztlich darin, die Anforderungen der Anwendung an Leistung, Funktionalität, Kosten, Sicherheit, Zweckmäßigkeit und Benutzerfreundlichkeit auszugleichen.
