Google hat offiziell seinen Fehdehandschuh in den IaaS-Cloud-Computing-Ring geworfen und den Zugang zum Dienst Google Compute Engine (GCE) für die breite Öffentlichkeit freigegeben. Eines der von Google angepriesenen Unterscheidungsmerkmale ist die Leistung seiner Netzwerkinfrastruktur.

Wir haben den Dienst kurz getestet, um die Verbindungsleistung im HPC-Anwendungsbereich zu testen. Insbesondere wollten wir die Latenz zwischen zwei Maschinen in einem MPI-Cluster messen.

Unser Google Compute Engine Test

Für unseren Test haben wir zwei Instanzen hochgefahren, einen OpenMPI-Cluster eingerichtet und dann den osu_latency-Benchmark vom OSU-Mikro-Benchmarks Testsuite zur Messung der Zeit, die zum Ping-Pong-Versand einer 0-Byte-Nachricht zwischen Knoten benötigt wird. Die unten angegebenen Werte sind die Durchschnittswerte der Einweglatenz aus drei Versuchen. Für jeden Versuch wurde ein neues Maschinenpaar gestartet.

*alle Latenzwerte in Mikrosekunden gemessen

Die gemeldeten Latenzwerte sind für alle von uns getesteten Instanztypen in etwa gleich. Die Abweichungen zwischen den Tests sind wahrscheinlich auf Konflikte mit anderen Mandanten auf dem Rechner zurückzuführen. Das Benchmarking von Cloud-Computing-Instanzen ist bekanntermaßen ein kniffliges Problem. Zukünftig werden wir einen umfassenderen Test mit mehr Instanzen und über verschiedene Zeiträume durchführen.

Vergleich der Benchmarks

Zum Vergleich: Beim gleichen Test mit Amazon EC70-Instanzen zeigten wir Latenzen zwischen 90 und 2 Mikrosekunden. Wichtig ist, dass dies kein direkter Vergleich ist: Amazon bietet spezielle Cluster-Compute-Instanztypen sowie Placement Groups an. Letztere ermöglichen eine bessere Bandbreite und geringere Latenzen zwischen Maschinen in derselben Gruppe. Die GCE-Latenzwerte scheinen näher an denen von Edward Walker zu liegen. berichtet für Nicht-Cluster-Compute-Instanzen auf EC2. Es ist wahrscheinlich, dass sich Google zunächst auf die typischere Workload des Hostings von Webdiensten konzentriert und sich später auf die Optimierung seiner Infrastruktur für andere Bereiche wie HPC konzentrieren wird. Derzeit scheint GCE besser für Workloads geeignet zu sein, die eher „peinlich parallel“ sind.
Beachten Sie, dass diese Mikro-Benchmarks nicht unbedingt die Leistung realer Anwendungen abbilden. Wir empfehlen Ihnen, anwendungsspezifische Tests auf Makroebene durchzuführen, um ein realistisches Bild der erwarteten Leistung zu erhalten. Es gibt verschiedene Möglichkeiten, Latenzeinbußen zu minimieren:

• Für bestimmte Klassen von Simulationsproblemen ist es möglicherweise möglich, Modelle in einzelne Teile zu zerlegen, die dann parallel ausgewertet werden können. Mit dem Aufkommen der Public Cloud ist jedoch ein Umdenken erforderlich. Anstatt eines einzelnen Clusters vor Ort können mehrere kleinere Cluster gestartet werden, die die zerlegten Teile gleichzeitig verarbeiten können.
• Nutzen Sie nach Möglichkeit hybride Open MP/MPI-Anwendungen. Die Reduzierung der Kommunikation zwischen Clusterknoten ist ein hervorragender Ansatz, um Latenzkosten vollständig zu vermeiden.

Wir freuen uns auf das anhaltende Wettrüsten der verschiedenen Cloud-Anbieter und erwarten, dass sich die HPC-Leistung weiter verbessern wird. So hat Microsoft kürzlich eine neue HPC-Angebot für Azure das Infiniband-Konnektivität zwischen Instanzen verspricht. Wie in den meisten Fällen ist der Wettbewerb zwischen großen Cloud-Computing-Anbietern für den Endkunden sehr gut. Bei Neu skalierenWir freuen uns über die Möglichkeiten, unseren Kunden weiterhin die bestmögliche Leistung zu bieten.