Cluster für umfassendes technisches Computing in der Cloud verwenden

Diese Lösung bietet eine Anleitung für umfassendes technisches Computing in Google Cloud. Viele technische Computing-Anwendungen erfordern eine große Anzahl von einzelnen Compute-Knoten, die zu einem Cluster miteinander verbunden sind und sowohl die Berechnung als auch den Datenzugriff über die Knoten koordinieren.

Die Konzepte und Technologien, die dem Cluster-Computing zugrunde liegen, haben sich in den letzten Jahrzehnten weiterentwickelt und sind mittlerweile ausgereift und alltäglich. Die Migration des Softwarepakets zu Google Cloud kann einige Schwierigkeiten beinhalten, bietet aber auch eine Reihe von Möglichkeiten, Kosten zu senken und bestehende Engpässe in Hochleistungs-Computing-Umgebungen von heute zu beheben. Dieser Leitfaden liefert einen Überblick über die Technologien, die Herausforderungen und die aktuellen Lösungen für den Betrieb von Computing-Clustern in Google Cloud.

Cluster-Computing aggregiert und koordiniert eine Sammlung von Maschinen, damit diese gemeinsam an der Lösung einer Aufgabe arbeiten. Cluster haben in der Regel einen einzelnen Hauptknoten (manchmal auch als Master-Knoten bezeichnet), eine Reihe von Compute-Knoten und möglicherweise einige andere Spezialknoten. Der Hauptknoten ist das Gehirn des Systems und verantwortlich für:

  • Die Registrierung von Compute-Knoten im System.
  • Die Überwachung der Knoten.
  • Die Zuordnung von Jobs zu bestimmten Knoten.
Diagramm: Cluster aus einem Hauptknoten und einer Reihe von Compute-Knoten
Abbildung 1: Ein Cluster besteht aus einem Hauptknoten und einer Reihe von Compute-Knoten. Die Nutzer interagieren mit dem Hauptknoten, der anschließend die Arbeit an die Compute-Knoten weiterleitet und koordiniert.

Die Nutzer senden Jobs, die aus vielen Aufgaben bestehen, wobei eine Aufgabe die Basisarbeitseinheit darstellt. Einige Anwendungen erfordern, dass alle Aufgaben in einem Job gleichzeitig ausgeführt werden, und lassen Aufgaben miteinander kommunizieren, um einen parallelen Algorithmus zu implementieren. Einige Jobs haben komplexe Aufgabenabhängigkeiten, sodass bestimmte Aufgaben vor anderen ausgeführt werden müssen. Außerdem können einzelne Aufgaben bestimmte Knotenkonfigurationen hinsichtlich Arbeitsspeicher, CPUs oder sonstiger besonderer Hardware erfordern, auf der sie ausgeführt werden sollen. Aufgaben sind ausführbare Dateien, die Eingabedaten aus dem Speicher lesen, die Daten zu einem Ergebnis verarbeiten und die endgültigen Ergebnisse anschließend wieder in den Speicher schreiben.

Es gibt zwei Haupttypen von Cluster-Computing-Arbeitslasten:

  • Hochleistungs-Computing (High-Performance Computing, HPC): ein Computing, das viele eng miteinander gekoppelte und gleichzeitig ausgeführte Worker-Knoten für die Erledigung einer Aufgabe verwendet. Diese Maschinen benötigen gewöhnlich eine niedrige Netzwerklatenz für eine effektive Kommunikation. Beispielanwendungen in diesem Bereich sind Wettermodelle, Verfahren der numerischen Strömungsmechanik (Computational Fluid Dynamics, CFD) sowie Belastungsmodelle im Ingenieurwesen und Elektronikdesign.

  • Computing mit hohem Durchsatz (High Throughput Computing, HTC): eine Art von Computing, bei der Anwendungen mehrere Aufgaben haben, die unabhängig voneinander verarbeitet werden, ohne dass die einzelnen Compute-Knoten miteinander kommunizieren müssen. Manchmal werden diese Arbeitslasten auch als Embarrassingly-Parallel- oder als Batcharbeitslasten bezeichnet. Typische Beispiele sind Medienrendering, Transcodierung, Genomik sowie die Simulation und Verarbeitung von Ereignissen in der Teilchenphysik. Wenn Sie viele einzelne Dateien verarbeiten müssen, handelt es sich wahrscheinlich um eine HTC-Arbeitslast.

Cluster-Computing-Softwarepaket

Ein Cluster-Computing-Softwarepaket besteht aus:

  • Software zur Systemverwaltung, die Cluster bereitstellt und erstellt.
  • Planern, die die Ausführung von Jobs orchestrieren.
  • Endnutzeranwendungen.

Die folgenden Abschnitte gehen näher auf die Software zur Systemverwaltung und die Planer ein.

Software zur Systemverwaltung

Sie können Clustering-Software entweder direkt auf der Bare-metal-Hardware, wie bei lokalen Clustern, oder in virtualisierten Umgebungen ausführen, wie bei Cloud-Umgebungen. Das manuelle Orchestrieren mehrerer Knoten in einem Cluster ist zeitaufwendig und fehleranfällig. Sie können spezifische Software für die Clusterverwaltung verwenden, um mehrere Knoten und Ressourcen gemeinsam bereitzustellen und zu konfigurieren, wiederholbar und zufallsunabhängig.

Die Open-Source-Software ElastiCluster der Universität Zürich bietet einen cloudnativen Ansatz für die Clusterverwaltung mit Compute Engine, mit Unterstützung für die Bereitstellung von Knoten, und die Konfiguration von Knoten mithilfe einer Reihe von Ansible-Playbooks. ElastiCluster stellt die Knoten bereit und installiert einen Basis-Softwarestack, einschließlich NFS zur Dateibereitstellung, NIS-Nutzerkontenverwaltung und eines Jobplaners für die Ausführung von Nutzeranwendungen. ElastiCluster unterstützt eine Vielzahl von Planern. Sie können die vorkonfigurierte Version verwenden oder diese anpassen, um den Anforderungen von kleinen bis mittelgroßen Teams gerecht zu werden.

Wenn Sie Ihre HPC-Cluster mit anderen Konfigurationsverwaltungssystemen wie Chef, Puppet oder Terraform verwalten, können Sie diese Investitionen bei der Migration zu Google Cloud mithilfe der verfügbaren Tools und Plug-ins nutzen.

Google Cloud bietet native Dienste für die Bereitstellung und den Einsatz von Softwaresystemen mit mehreren Knoten. Mit Cloud Deployment Manager können Sie verschiedene Cloud-Ressourcen bereitstellen, z. B. Compute Engine, von Compute Engine verwaltete Instanzgruppen und Cloud Storage. Die HTCondor-Anleitung zeigt Ihnen, wie Sie Cloud Deployment Manager und verwaltete Instanzgruppen verwenden, um einen Cluster bereitzustellen und zu konfigurieren.

Jobplaner

Sobald der Cluster einsatzbereit ist, wird die Software, die die Aufgabenausführung und die Knotenzuweisung verwaltet, als Jobplaner (gelegentlich auch als Arbeitslastmanager oder als Warteschlangenmanager) bezeichnet. Häufig verfügt ein Cluster-Manager über einen integrierten Jobplaner. Jobplaner bieten eine Vielzahl von Fähigkeiten, um Jobs und Aufgaben zu verwalten, wie zum Beispiel:

  • Die nutzer- und gruppenübergreifende Unterstützung von Jobprioritäten für eine richtlinienbasierte Jobplanung.
  • Die Unterstützung für fehlgeschlagene Aufgaben, die in die Warteschlange gesetzt oder neu geplant werden.
  • Die Berücksichtigung von Aufgabenabhängigkeiten und Ressourcenanforderungen für die Aufgabenzuteilung.
  • Die Skalierung der Clustergröße abhängig von der Anzahl von Jobs in der Warteschlange.

Es gibt eine Vielzahl von beliebten kommerziellen und Open-Source-Arbeitslastmanagern. Beispiele: HTCondor von der University of Wisconsin, Slurm-GCP von SchedMD, Altair Grid Engine und IBM Spectrum LSF. Jede dieser Lösungen hat ihre Stärken.

HTCondor ist nach einer Shared-nothing-Philosophie aufgebaut und wird über gemeinsam genutzte Ressourcen verwendet, um Jobs auf ansonsten ungenutzten Ressourcen opportunistisch zu planen. Es ermöglicht seine eigene Datenbewegung und benötigt daher keine gemeinsam genutzten Dateisysteme. Entsprechend kann HTCondor auf mehrere Hunderttausend Kerne skaliert und in mehreren Zonen und Regionen verwendet werden. HTCondor wird für Hybridarbeitslasten verwendet, bei denen die Arbeit gemeinsam bewältigt oder zwischen lokalen und cloudbasierten Systemen aufgeteilt wird. Wie der Name schon sagt, liegt der Schwerpunkt dieser Lösung jedoch auf Jobs mit hohem Durchsatz und nicht auf eng gekoppelten, parallelen Jobs.

Slurm und Altair Grid Engine bieten eine traditionellere HPC-Clusterumgebung, die sowohl Anwendungen mit hohem Durchsatz als auch parallele Hochleistungsanwendungen unterstützt. Sie nutzen beide ein knotenübergreifendes gemeinsames Dateisystem, weshalb keine Daten verschoben werden müssen. Außerdem bieten beide eine bequeme und vertraute Nutzerumgebung für die Entwicklung von Anwendungen, da sie häufig schon als lokale Tools eingesetzt werden. Diese traditionellen Jobplaner sind ausreichend für kleine bis mittelgroße Cluster. Da die Clustergröße jedoch zunimmt, wird die Arbeitslast auf dem Dateiserver zum Leistungsengpass. Bei großen Datenmengen können parallele und verteilte Dateisysteme (siehe nächster Abschnitt) bei diesem Problem Abhilfe schaffen. Wenn kein Dateizugriff mit niedriger Latenz erforderlich ist, können Sie alternativ auch Cloud Storage nutzen, das parallelen Objektzugriff über die API oder über gcsfuse bietet, wobei POSIX-Kompatibilität erforderlich ist.

Schließlich enthält Google Cloud einen einfachen Dienst zum Planen einer Docker-basierten Aufgabe in Compute Engine für Arbeitslasten mit hohem Durchsatz: die Cloud Life Sciences Pipelines API. Für diesen Dienst müssen Sie den Job in Aufgaben zerlegen, Abhängigkeiten über Aufgaben hinweg verwalten und den Aufgabenlebenszyklus steuern. Das Open-Source-Projekt dsub bietet ein Befehlszeilentool zum Starten von Batchjobs und unterstützt die Cloud Life Sciences Pipelines API.

Speicher

Die meisten HPC-Anwendungen erfordern eine Dateispeicherlösung, die die POSIX API unterstützt. Für kleinere Cluster bietet FileStore einen von Google verwalteten NFS-basierten Dateispeicherdienst. Bei größeren Clustern können die E/A-Anforderungen einer Anwendung jedoch zu einem Leistungsengpass werden. Skalierbare und parallele Dateisysteme wie Filestore High Scale, Lustre oder Quobyte – zur Skalierung auf große Cluster (bzw. auch auf kleinere Cluster mit hohen E/A-Anforderungen).

Wenn kein Dateizugriff mit niedriger Latenz erforderlich ist, können Sie alternativ auch Cloud Storage verwenden, das parallelen Objektzugriff über die API oder über gcsfuse bietet, wenn POSIX-Kompatibilität ist erforderlich.

Möglichkeiten für Cluster-Computing in der Cloud

Es gibt viele Gründe für die Ausführung von Computing-Clustern in der Cloud:

  • Time-to-Solution. Das Ausführen eines Clusters mit Produktionsqualität in der Cloud dauert nur wenige Minuten. Das gilt für einen kleinen 10-Knoten-Cluster mit Hunderten verfügbarer Kerne genauso wie für große Cluster mit 100.000 oder mehr Kernen. Dagegen kann es beim Aufbau neuer lokaler Cluster Monate dauern, bis diese einsatzbereit sind. Auch wenn lokale Cluster zur Verfügung stehen, haben sie in der Regel eine hohe Auslastung und lange Warteschlangenzeiten, sodass Jobs manchmal erst nach Stunden oder Tagen zur Ausführung geplant werden können. Als Alternative können Sie eigene Cluster in der Cloud erstellen, sie für Ihre Arbeitslasten nutzen und beenden, wenn Ihre Analyse abgeschlossen ist.

  • Niedrigere Gesamtbetriebskosten. Google Cloud verringert nicht nur die Zeit bis zur Lösung, sondern bietet auch die Möglichkeit, die Gesamtkosten pro Ausführung durch Spot-VMs, Langzeitnutzungsrabatte und eine dynamische Skalierung zu senken. Sie können Knoten hinzufügen, wenn sich Jobs in der Warteschlange befinden, und sie wieder entfernen, wenn sie nicht benötigt werden.

  • Unterstützung der Zusammenarbeit. In vielen Fällen wird die Compute-Analyse in Zusammenarbeit verschiedener Personen aus mehreren Organisationen erstellt. Google Cloud bietet Tools zur Identitäts- und Zugriffsverwaltung auf Projektebene, mit denen Sie den Zugriff auf Daten- und Analysetools steuern können. Autorisierte Nutzer können so auf die gleichen Anwendungen, Daten und Cluster zugreifen. Damit ist gewährleistet, dass alle auf dem gleichen Stand sind, ohne Daten kopieren, Versionen verwalten oder Clusterkonfigurationen synchronisieren zu müssen.

  • Auf Aufgaben zugeschnittene Ressourcen. Da sich die Kosten für einen Job nur nach der Gesamtzahl der Kernstunden richten und nicht nach der Anzahl der Instanzen, ermöglicht die Ausführung von Clustern in der Cloud jedem Team und jeder Gruppe die Verwendung eines eigenen dedizierten Clusters. Dieser Ansatz bietet Möglichkeiten zur Bewältigung einer weiteren wichtigen Anforderung bei der Entwicklung von Richtlinien für die Nutzung durch mehrere Gruppen. Sie können dann jeden dedizierten Cloud-Cluster anpassen, um ihn für die Zielanwendung anzupassen. Lokale Cluster bestehen häufig aus einer für alles geeigneten Ressource, die von den verschiedenen Gruppen und Anwendungen gemeinsam genutzt wird. In einer solchen Umgebung ist die Ausarbeitung und Pflege von Richtlinien für die gemeinsame Nutzung durch die Gruppen tendenziell schwierig.

  • Integration. Forscher müssen, bevor sie große Computing-Jobs ausführen können, viel Aufwand in die Vorbereitung der Datasets stecken. Nach der Verschiebung in die Cloud stehen Forschern dafür die in der Cloud verfügbaren Big-Data-Tools zur Verfügung. Auch müssen die Ergebnisse der Computing-Systeme analysiert werden. Tools wie BigQuery und Datalab bieten hier potenziell deutliche Vorteile gegenüber lokalen Systemen.

Grafik: Typische lokale Cluster werden gemeinsam von Nutzern und Gruppen genutzt und erfüllen viele unterschiedliche Anwendungsanforderungen.
Abbildung 2: Typische lokale Cluster werden von Nutzern und Gruppen gemeinsam genutzt und erfüllen viele verschiedene Anwendungsanforderungen. Im Gegensatz dazu können Nutzer beim Wechsel zu Google Cloud die Clusterattribute an die Anforderungen der Anwendung anpassen, um die Kosten zu senken und die Leistung zu steigern.

Hinweise zur Architektur

Obwohl die bisher beschriebenen Vorteile überzeugend sind, gibt es doch einige technische Herausforderungen, die Migrationsprojekte häufig behindern.

  • Datenverschiebung. Die Datasets, die von den Compute-Knoten eines Clusters verarbeitet werden, müssen in der Regel vor der Ausführung der Jobs in der Cloud vorbereitet werden. Die Ausführung der Datenverschiebung kann sich je nach Datenmenge und Art der Verwaltung als komplex erweisen.

  • Datenzugriff. Viele HPC-Anwendungen erfordern einen gemeinsamen Zugriff auf eine Reihe von Dateien und Verzeichnissen. Die Art und Weise, wie dieser Zugriff ermöglicht wird, hat potenziell einen erheblichen Einfluss auf die Anwendungsleistung. Sie können freigegebene Daten nutzen, die in Cloud Storage, auf NFS-Servern wie FileStore oder in parallelen Dateisystemen gespeichert sind, wie im Abschnitt Speicher beschrieben.

  • Sicherheit. Bei vertraulichen Daten müssen Sie darauf achten, dass der Zugriff immer autorisiert ist und die Daten bei Inaktivität sowie während der Übertragung ausreichend verschlüsselt sind. Cloud Storage bietet eine solche Verschlüsselung. Sie können aber auch eine zusätzliche Kontrollebene nutzen und Schlüssel entweder im Cloud Key Management Service oder selbstständig verwalten. Die Schlüssel müssen vor der Ausführung des Jobs abgerufen oder auf den Compute-Knoten installiert werden.

  • Knotenübergreifende Latenz. Bei eng gekoppelten HPC-Anwendungen kann die Leistung stark von der knotenübergreifenden Latenz zwischen den einzelnen Knoten im Cluster abhängig sein. Da Google Cloud Knoten mit bis zu 64 Kernen bereitstellt, können Sie 64 Jobs parallel ausführen, ohne den Knoten wechseln zu müssen. In den meisten Fällen lassen sich Jobs mit rund 1.000 Kernen oder weniger auf nicht spezialisierter Netzwerkhardware gut ausführen.

  • Verwaltung von Softwarelizenzen. Viele kommerzielle Anwendungen erfordern einen Lizenzserver, der oft auch als Schlüsselserver bezeichnet wird. Einige Anwendungen enthalten einen integrierten oder empfohlenen Lizenzserver, während andere für vorhandene Angebote von Lizenzservern geeignet sind. Einige Jobplaner bieten eine Unterstützung bei der Lizenzverwaltung, da sie die Ausführung von Jobs verhindern, bis eine Lizenz zur Verfügung steht.

Das technische Computing bietet viele Tools und Ansätze für verschiedene Umstände. Bei so vielen Optionen können sich die ersten Schritte als schwierig erweisen. Unabhängig von der Wahl der Clusterverwaltungssoftware und des Planers gibt es bei der Ausführung in Google Cloud eine Reihe von Best Practices.

  • Nutzen Sie nach Möglichkeit Spot-VMs. Spot-VMs sind identisch mit normalen VMs in Compute Engine, kosten jedoch bis zu 80 % weniger. Allerdings können sie kurzfristig abberufen werden. Bei Arbeitslasten mit hohem Durchsatz erkennen dabei Ihre Jobplaner den Verlust des Knotens und behandeln ihn als Knotenfehler. Anschließend werden alle Aufgaben, die auf diesem Knoten ausgeführt werden, auf einer anderen Ressource neu geplant. Auch wenn die Arbeit auf diesen Knoten verloren gehen kann, ist die Wahrscheinlichkeit eines Knotenverlusts doch so gering, dass der niedrigere Preis das Risiko lohnt. Die erwartete Verlustquote beträgt 5 % bis 15 %. Spot-VMs sind auf eine Nutzungsdauer von maximal 24 Stunden begrenzt, bevor sie abberufen werden.
  • Nutzen Sie die Kosten und die Bandbreite von Cloud Storage, statt Ihr eigenes paralleles Dateisystem zu betreiben. Cloud Storage bietet eine hohe Konsistenz und eine skalierbare Parallelleistung bei geringen Gesamtkosten. Obwohl die Latenz für das erste Byte mit etwa 100 ms hoch ist, sind Anwendungen, die Cloud Storage nutzen können, kostengünstiger als ein paralleler Dateiserver in Compute Engine. Die verfügbare Bandbreite zwischen Cloud Storage und den Compute-Knoten reicht für viele Anwendungen aus. Einige Kunden haben von einer anhaltenden Gesamtbandbreite von über 23 GB/s berichtet.
  • Erstellen Sie einen Cluster für jede Anwendung oder Gruppe. Traditionelle Cluster werden von mehreren Nutzern, Gruppen und Anwendungen gemeinsam genutzt, was zu langen Warteschlangenzeiten für Jobs und zu einer ineffizienten Nutzung von Ressourcen durch Anwendungen führen kann. Erstellen Sie in Google Cloud mehrere Cluster für jede Gruppe oder jedes Projekt und verwenden Sie Cluster, die für bestimmte Anwendungen optimiert sind, die darauf ausgeführt werden. Ob Sie einen Cluster für zwei Stunden oder zwei Cluster für jeweils eine Stunde ausführen, macht für die Gesamtkosten keinen Unterschied. Mit dem zweiten Ansatz können Sie jedoch die Warteschlangenzeiten verringern und die Anwendungsleistung steigern.

Obwohl jede Implementierung einzigartig ist, erhalten Sie in den folgenden Abschnitten einige allgemeine Empfehlungen für drei übliche Fälle.

Unabhängiger Forscher, der seine Daten verarbeiten möchte

Einzelne Forscher versuchen in der Regel, ihre Anwendung datenübergreifend auszuführen und so schnell wie möglich fertig zu werden. Sie sind zwar Experten für ihre Anwendung, möchten jedoch keine Experten im Bereich der Clusterverwaltung oder des Clustermanagements sein.

Wenn Sie Arbeitslasten mit hohem Durchsatz ausführen, können Sie die Cloud Life Sciences Pipelines API verwenden. Für die Pipelines API müssen Sie Ihre Anwendung in einem Docker-Container ablegen und Ihre Eingabedateien in einem Cloud Storage-Bucket speichern. Anschließend können Sie die Anwendung mit der Google Cloud CLI für jede Datei im Cloud Storage-Bucket starten. Die Ergebnisse können Sie in einem weiteren Cloud Storage-Bucket ablegen.

Hier sehen Sie einen Beispielbefehl zur Ausführung einer Aufgabe, bei der SAMtools verwendet wird, um eine BAM-Indexdatei aus einer BAM-Eingabedatei zu erzeugen:

gcloud alpha genomics pipelines run --pipeline_id [PIPELINE_ID] \
--logging gs://[YOUR_BUCKET/YOUR_DIRECTORY]/logs \
--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \
--outputs outputFile=gs://[YOUR_BUCKET]/[YOUR_DIRECTORY]/output/NA12878_chr22.bam.bai

Dabei gilt:

  • [PIPELINE_ID] steht für die Anwendungs-ID in der Pipelines API.
  • [YOUR_BUCKET] steht für den Namen des Cloud Storage-Buckets.
  • [YOUR_DIRECTORY] steht für den Namen des Verzeichnisses.

Es gibt keinen Cluster, der bereitgestellt oder verwaltet werden muss. Die Aufgaben werden einfach bis zum Abschluss in einer VM ausgeführt, die von der Pipelines API bereitgestellt und verwaltet wird. Dies ist eine kostengünstige Lösung, da Compute Engine die Nutzung sekundengenau abrechnet.

Kleine bis mittelgroße Cluster für ein einzelnes Projekt oder Team

Die Mitglieder innerhalb eines Projekts oder Teams können Zugriff auf einen Cluster haben, der von einem zentralen Team für Nutzer im gesamten Unternehmen betrieben wird, oder auf umfassende Ressourcen in einem externen HPC-Center. In beiden Fällen werden die Cluster professionell verwaltet, und der Zugriff erfolgt über Standardtools. Beispielsweise können Nutzer ssh verwenden, um eine Verbindung zu einem Hauptknoten herzustellen, und submit-Skripts von Grid Engine, um Jobs zur Ausführung zu senden.

Ein Ansatz für ein solches Team ist die Nutzung von ElastiCluster, um eine Clusterumgebung zu definieren, die den lokalen Systemen ähnelt. Sie können den Cluster anpassen, indem Sie einen Compute Engine-Maschinentyp auswählen, der für ihre Anwendung am besten geeignet ist. Passen Sie dann die Startskripts an, um die Softwareabhängigkeiten für ihre Anwendung zu installieren. Eingabedaten können weiterhin in Cloud Storage vorbereitet werden. Für die Bereitstellung der Eingabedaten kann auf den Compute-Knoten gcsfuse installiert werden.

Diese Details werden in der ElastiCluster-Konfigurationsdatei aufgezeichnet. Wenn eine Berechnung erforderlich ist, wird ein Cluster mit dem Befehlszeilentool aufgerufen. Beispiel:

% elasticluster start astrocluster1

Der in der Konfigurationsdatei als astrocluster1 bezeichnete Cluster wird wie angegeben bereitgestellt und konfiguriert. Die Definitionen in einer Konfigurationsdatei sind flexibel und unterstützen verschiedene Knotentypen für Haupt- und Compute-Knoten, nichtflüchtigen Speicher für Compute Engine als temporären Speicherbereich, Spot-VMs zur Verringerung der Kosten für Arbeitslasten mit hohem Durchsatz und GPUs für einen beschleunigten Vorgang. Eine Basiskonfiguration für einen Slurm-basierten Cluster mit zehn Compute-Knoten und einem Hauptknoten mit virtuellen 32-Kern-Maschinen auf Grundlage von CentOS würde so aussehen:

[cluster/astrocluster1]
 cloud=google
 login=google
 setup=ansible-slurm
 security_group=default
 image_id=centos-7-v20170327
 flavor=n1-standard-32
 frontend_nodes=1
 compute_nodes=10
 ssh_to=frontend
 boot_disk_size=50
 

Wenn schließlich keine weiteren Jobs im System ausgeführt werden, können Sie den Cluster beenden:

% elasticluster stop astrocluster1

Bei größeren Arbeitslasten können Sie Folgendes tun:

  • Versuchen, die Cluster-Maschinentypen anzupassen, um die Kosten weiter zu senken.
  • Einen externen parallelen Filter hinzufügen, um die Leistung in großem Umfang zu steigern
  • Funktionen zur automatischen Skalierung hinzufügen, mit denen weitere Knoten basierend auf der Größe der Warteschlange hinzugefügt oder entfernt werden können

HPC-Center, das vorhandenen Clustern Burst-Kapazität verleiht

Zentrale HPC-Center haben enorme Compute-Kapazitäten. Da sie jedoch von vielen Gruppen im Unternehmen oder in der Organisation verwendet werden, neigen HPC-Center zu einer beständig hohen Auslastung und zu langen Warteschlangenzeiten. Sie werden in der Regel mit einer bestimmten angestrebten Produktionskapazität gekauft. Unvorhergesehene Arbeitslasten können den Fortschritt jedoch deutlich verlangsamen.

In diesen Situationen können Sie Burst-Kapazität in der Google Cloud-Umgebung nutzen, indem Sie dem Cluster vorübergehend Compute-Knoten hinzufügen. Der Cluster wird zu einem Hybrid, wobei der Hauptknoten und einige Compute-Knoten lokal und andere Compute-Knoten in Google Cloud ausgeführt werden. Nachdem die Jobwarteschlangen abgearbeitet worden sind, können die zusätzlichen Knoten freigegeben werden.

Das Bursting in die Cloud ist aus zwei Gründen praktisch:

  • Es garantiert eine konsistente Nutzerumgebung für die Übermittlung und die Verwaltung von Jobs. Für die Nutzer macht es dabei keinen spürbaren Unterschied, ob zusätzliche Knoten hinzugefügt werden.
  • IT-Manager können zur Kostenkontrolle Richtlinien für das Bursting definieren.

Die größte Herausforderung besteht darin, einen konsistenten Daten- und Datei-Namespace für Nutzerjobs auf den lokalen und Google Cloud-Knoten bereitzustellen. Die Google Cloud-Knoten haben möglicherweise keinen Zugriff auf dieselben internen Dateisysteme wie die lokalen Knoten. In diesem Fall werden Jobs, die auf diese Dateien verweisen, nicht ausgeführt.

Wenn die Google Cloud-Knoten mit internen Dateizugriffsberechtigungen konfiguriert sind, werden Jobs zwar ausgeführt, funktionieren aber möglicherweise nicht auf die gleiche Weise und können zusätzliche Netzwerkbandbreite und Gebühren für ausgehenden Traffic verursachen. Darüber hinaus werden auch parallele Jobs, die auf lokale und Cloud-Knoten verteilt sind, aufgrund der zusätzlichen Latenz zwischen den verschiedenen Teilen der Anwendung nicht richtig ausgeführt.

Bei Jobs mit hohem Durchsatz können viele dieser Probleme durch das Bursting mit HTCondor in Cloud-Ressourcen umgangen werden. HTCondor unterstützt die dynamische Bereitstellung mit GlideInWMS. Wenn Jobs an eine Jobwarteschlange gesendet werden, können daraufhin Knoten bereitgestellt und dem Cluster hinzugefügt werden. Wenn sie hinzugefügt werden, überträgt der Condor-Planer die Eingabedateien an den designierten Knoten und verwendet diese zusätzlichen Knoten, um die Aufgaben auszuführen und die Warteschlange abzuarbeiten.

Weitere Informationen

Anwendungsfälle im Bereich Cluster-Computing in Google Cloud:

Weitere Informationen:

Erste Schritte mit Ihrem Cluster:

Beispielprojekte auf GitHub: