Verwenden von Clustern für technisches Rechnen in großem Maßstab in der Cloud

Diese Lösung bietet Anleitungen für die Durchführung von technischem Rechnen in großem Maßstab in der Google Cloud. Viele technische Computing-Apps erforderngroße Anzahl einzelner Rechenknoten, die zu einem Cluster verbunden sind und die Berechnung und den Datenzugriff über die Knoten hinweg koordinieren.

Die Konzepte und Technologien, die dem Cluster-Computing zugrunde liegen, haben sich in den letzten Jahrzehnten entwickelt und sind mittlerweile ausgereift und Mainstream. Die Migration des Softwarestacks in die Google Cloud kann einige Probleme verursachen, bietet jedoch auch eine Reihe von Möglichkeiten, um die Kosten zu senken und bestehende Engpässe in den heutigen Hochleistungsrechnerumgebungen zu verringern. Dieser Leitfaden bietet einen Überblick über die Technologien, die Herausforderungen und die aktuellen Lösungen für die Ausführung von Computerclustern in der Google Cloud.

Cluster Computing aggregiert und koordiniert eine Sammlung von Maschinen, die zusammenarbeiten, um eine Aufgabe zu lösen. Cluster haben typischerweise einen einzelnen Kopfknoten (manchmal auch als Masterknoten bezeichnet), eine bestimmte Anzahl von Rechenknoten und möglicherweise einige andere Spezialknoten. Der Kopfknoten ist das Gehirn des Systems und istverantwortlich für:

• Registrieren von Compute Nodes im System.
• Überwachung der Knoten.
• Jobs bestimmten Knoten zuweisen.

Benutzer senden Jobs, die aus vielen Aufgaben bestehen, wobei eine Aufgabe die Hauptarbeitseinheit ist. Einige Jobs haben einen komplexen Satz von Aufgabenabhängigkeiten, sodass bestimmte Aufgaben vor anderen ausgeführt werden müssen. und einige Aufgaben erfordern möglicherweise bestimmte Knotenkonfigurationen in Bezug auf Speicher, CPUs oder andere bestimmte Hardware, auf der ausgeführt werden soll. Tasks sind ausführbare Dateien, die Eingabedaten aus dem Speicher lesen, die Daten verarbeiten, um ein Ergebnis zu erzeugen, und dann die Endergebnisse zurück in den Speicher schreiben.

Es gibt zwei Haupttypen von Cluster-Computing-Workloads:

• High-Performance Computing (HPC) — Eine Art von Computing, die Manyworker-Knoten verwendet, eng gekoppelt ist und gleichzeitig ausgeführt wird, um atask zu erreichen. Diese Maschinen benötigen normalerweise eine geringe Netzwerklatenz, um effektiv kommunizieren zu können. Beispiele für Anwendungen in diesem Bereich sind Wettermodellierung, Computational Fluid Dynamics (CFD), Spannungsmodellierung im Ingenieurwesen und Elektronikdesign.

• High-Throughput Computing (HTC) – Eine Art von Computing, bei der Apps mehrere Aufgaben haben, die unabhängig voneinander verarbeitet werden, ohne dass die einzelnen Rechenknoten kommunizieren müssen. Manchmal werden diese Workloads als peinlich parallele oder Batch-Workloads bezeichnet. Typische Beispiele sind Medien-Rendering, Transcodierung, Genomik, andparticle-physics-Event-Simulation und Verarbeitung. Wenn Sie viele einzelne Dateien verarbeiten müssen, ist dies wahrscheinlich eine enorme Arbeitslast.

Cluster-Computing-Software-Stack

Ein Cluster-Computing-Software-Stack besteht aus:

• Systemverwaltungssoftware, die Cluster bereitstellt und erstellt.
• Scheduler, die die Auftragsausführung orchestrieren.
• Endbenutzer-Apps.

In den folgenden Abschnitten werden Systemverwaltungssoftware und Scheduler behandelt.

Systemverwaltungssoftware

Sie können Clustering-Software entweder direkt auf der Bare-Metal-Hardware wie bei lokalen Clustern oder in virtualisierten Umgebungen wie bei Cloudenvironments ausführen. Die manuelle Orchestrierung mehrerer Knoten in einem Cluster ist zeitaufwändig und fehleranfällig. Sie können eine spezielle Cluster-Management-Software verwenden, um mehrere Knoten und Ressourcen auf wiederholbare und deterministische Weise bereitzustellen und zu konfigurieren.

Die Open-Source-Elasticluster-Software der Universität Zürich bietet einen cloud-nativen Ansatz für das Clustermanagement mit Unterstützung für die Bereitstellung von Knoten mithilfe der Computer-Engine und die Konfiguration von Knoten mithilfe einer Reihe von Ansibleplaybooks. ElastiCluster stellt die Knoten bereit und installiert einen Basissoftwarestack, einschließlich NFS für die Dateibereitstellung, NIS-Benutzerkontenverwaltung und einen Taskplaner für die Ausführung von Benutzeranwendungen. ElastiCluster unterstützt eine Vielzahl von Schedulern, und Sie können es sofort verwenden oder an die Bedürfnisse kleiner bis mittlerer Teams anpassen.

Wenn Sie andere Konfigurationsmanagementsysteme zur Verwaltung Ihrer HPC-Cluster verwenden, z. B. Chef, Puppet oder Terraform, können Sie diese Investitionen bei der Migration zu Google Cloud mithilfe der verfügbaren Tools und Plugins nutzen.

Google Cloud bietet native Dienste für die Bereitstellung und Bereitstellungmulti-Node-Softwaresysteme. Mit Cloud Deployment Manager können Sie eine Reihe von Cloud-Ressourcen bereitstellen, darunter Compute Engine, von Compute Enginemanaged Instance Groups und Cloud Storage. Das HTCONDOR-Lernprogramm zeigt Ihnen, wie Sie Cloud Deployment Manager und verwaltete Instanzgruppen verwenden, um einen Cluster bereitzustellen und zu konfigurieren.

Job schedulers

Nachdem der Cluster betriebsbereit ist, wird die Software, die die Aufgabenausführung und Knotenzuweisung verwaltet, als Job Scheduler (manchmal auch als Workloadmanager oder Warteschlangenmanager bezeichnet) bezeichnet. Oft kommt ein Cluster-Manager mit abuilt-in Job-Scheduler. Job Scheduler bieten eine Vielzahl von Funktionen, um Jobs und Aufgaben zu verwalten, z:

• Unterstützung für Jobprioritäten über Benutzer und Gruppen hinweg, wodurch eine richtlinienbasierte Jobplanung bereitgestellt werden kann.
• Unterstützung für fehlgeschlagene Aufgaben, indem Aufgaben in die Warteschlange gestellt und neu geplant werden.
• Berücksichtigung von Aufgabenabhängigkeiten und Ressourcenbedarf für die Aufgabenverteilung.
• Skalierung der Clustergröße in Abhängigkeit von der Anzahl der Jobs in der Warteschlange.

Es gibt eine Vielzahl beliebter kommerzieller und Open-Source-Workload-Manager.Beispiele hierfür sind Htcondor von der University of Wisconsin, Slurm von SchedMD, Univa Grid Engine und LSF Symphony von IBM. Jeder hat seine Stärken.

HTCondor basiert auf einer Shared-Nothing-Philosophie und wird über gemeinsam genutzte Ressourcen hinweg verwendet, um Aufträge opportunistisch auf ansonsten leerlaufenden Ressourcen zu planen. Es bietet eine eigene Datenbewegung und erfordert daher keine Sharedfile-Systeme. Infolgedessen skaliert HTCondor auf Hunderttausende von Kernen und kann in mehreren Zonen und Regionen verwendet werden. HTCondor wurde für hybride Workloads verwendet, bei denen die Arbeit zwischen lokalen und Cloud-basierten Systemen geteilt oder aufgeteilt wird. Wie der Name schon sagt, konzentriert es sich jedoch auf Jobs mit hohem Durchsatz und nicht auf eng gekoppelte parallele Jobs.

Slurm und Univa Grid Engine bieten eine traditionellere HPC-Cluster-Umgebung, die sowohl parallele Anwendungen mit hohem Durchsatz als auch mit hoher Leistung unterstützt. Sie gehen beide von einem gemeinsamen Dateisystem über die Knoten aus, wodurch die Daten nicht mehr verschoben werden müssen. Beide bieten eine komfortable und vertraute Benutzerumgebung für die Entwicklung von Apps, da es sich häufig um dieselben Tools handelt, die vor Ort verwendet werden.Diese herkömmlichen Job-Scheduler sind für kleine bis mittelgroße Cluster ausreichend, aber mit zunehmender Clustergröße wird die Auslastung des Dateiservers zum Flaschenhals für die Leistung. Parallele und verteilte Dateisysteme (siehe nächster Abschnitt)können bei diesem Problem in großem Maßstab helfen. Wenn kein Dateizugriff mit niedriger Latenz erforderlich ist, können Sie alternativ den Cloud-Speicher nutzen, der mithilfe der API oder über gcsfuse parallelen Objektzugriff bereitstelltposix-Kompatibilität ist erforderlich.

Schließlich enthält Google Cloud einen einfachen Dienst zum Planen von AD HOC-basierten Aufgaben in Compute Engine für Workloads mit hohem Durchsatz: theCloud Life SciencesPipelines API.Für diesen Dienst müssen Sie den Auftrag in Aufgaben zerlegen, Abhängigkeiten zwischen Aufgaben verwalten und den Aufgabenlebenszyklus verwalten. Das Open-Source-Projekt Dsub bietet ein Befehlszeilentool zum Starten von Batch-Jobs und unterstützt die Cloud Life Sciences Pipelines API.

Storage

Die meisten HPC-Anwendungen benötigen 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 kann die Anwendungs-E / A jedoch zu einem Leistungsengpass werden.Scale-Out und parallele Dateisysteme wie Elastifile (erworben von Google), Lustre oder Quobyte helfen bei der Skalierung auf große Cluster (oder sogar e / A-lastige kleinere Cluster).

Wenn kein Dateizugriff mit niedriger Latenz erforderlich ist, können Sie alternativ den Cloud-Speicher nutzen, der mithilfe der API parallelen Objektzugriff bereitstellt, oder übergcsfuse, wo POSIX-Kompatibilität erforderlich ist.

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

Es gibt viele Gründe, Compute-Cluster in der Cloud auszuführen:

• Zeit bis zur Lösung. Der Start eines Clusters in Produktionsqualität in der Cloud dauert nur wenige Minuten, von einem kleinen 10-Knoten-Cluster mit Hunderten von verfügbaren Kernen bis hin zu großen Clustern mit hunderttausend oder mehr Kernen. Im Gegensatz dazu kann der Aufbau neuer Cluster vor Ort Monate dauern, bis sie betriebsbereit sind. Selbst wenn lokale Cluster verfügbar sind, weisen sie in der Regel eine hohe Auslastung und lange Warteschlangenwartezeiten — manchmal Stunden oder Tage — auf, bevor die Ausführung von Aufträgen geplant wird. Stattdessen können Sie Ihre eigenen Cluster in der Cloud erstellen, sie für Ihre Workloads verwenden und die Cluster beenden, wenn die Analyse abgeschlossen ist.

• Niedrigere Gesamtbetriebskosten. Google Cloud reduziert nicht nur die Zeit bis zur Lösung, sondern kann auch die Gesamtkosten pro Ausführung senken, indem es bezugsfertige VMs, Rabatte für die langfristige Nutzung und dynamische Skalierung nutzt. Sie können Knoten hinzufügen, wenn Jobs in der Warteschlange stehen, und sie entfernen, wenn sie nicht benötigt werden.

• Unterstützung für die Zusammenarbeit. In vielen Situationen wird die Datenanalyse in Zusammenarbeit mit verschiedenen Personen in mehreren Organisationen entwickelt. Google Cloud bietet auf Projektebeneidentitäts- und Zugriffsverwaltungstools für den kontrollierten Zugriff auf Daten und Analysetools. Autorisierte Benutzer können auf dieselben Apps, Daten und Cluster zugreifen, um sicherzustellen, dass sich alle auf derselben Seite befinden, ohne Daten kopieren, Versionen verwalten oder Cluster-Konfigurationen synchronisieren zu müssen.

• Aufgabenspezifische Ressourcen. Da die Kosten eines Auftrags nur von den gesamten Kernstunden und nicht von der Anzahl der Instanzen abhängen, ermöglicht die Ausführung von Clustern in der Cloud jedem Team oder jeder Gruppe, über einen eigenen dedizierten Cluster zu verfügen. Dieser Ansatz kann einen weiteren wichtigen Schmerzpunkt bei der Entwicklung von Richtlinien für die Verwendung mehrerer Gruppen lindern. Anschließend können Sie jeden dedizierten Cloud-Cluster anpassen, um ihn für die Ziel-App abzustimmen. Lokale Cluster bestehen in der Regel aus einer einheitlichen Ressource, die von den verschiedenen Gruppen und Apps gemeinsam genutzt wird. In einer solchen Umgebung sind Richtlinien für die gemeinsame Nutzung in den Gruppen in der Regel komplex einzurichten und zu verwalten.

• Integration. Bevor sie große Rechenaufträge ausführen können, Forscher tunsignifikante Arbeit, um die Datensätze vorzubereiten. Nach dem Wechsel in die Cloud können diese Forscher die in der Cloud verfügbaren Big Data-Tools nutzen. Die Outputs der Rechensysteme müssen ebenfalls analysiert werden. Tools wie BigQuery und Datalab können erhebliche Vorteile gegenüber den in lokalen Systemen verfügbaren bieten.

Architektonische Überlegungen

Während die bisher beschriebenen Vorteile überzeugend sind, gibt es dennoch einige technische Herausforderungen, die Migrationsprojekte oft behindern.

• Datenbewegung. Die Datasets, die von den Computenodes eines Clusters verarbeitet werden, müssen in der Regel vor der Ausführung der Jobs in der Cloud bereitgestellt werden.Die Verwaltung der Datenbewegung kann je nach Datenvolumen und Verwaltung komplex sein. Tools wie Avere können helfen, indem sie eine Cloud-Caching-Ebene bereitstellen, die Daten bei Bedarf automatisch verschiebt, aber für viele Apps müssen die Datensätze manuell bereitgestellt werden.

• Datenzugriff. Viele HPC-Anwendungen erfordern gemeinsamen Zugriff auf einen Satz offiles und Verzeichnisse. Wie dieser Zugriff bereitgestellt wird, kann erhebliche Auswirkungen habenapp-Leistung. Sie können freigegebene Daten nutzen, die im Cloud-Speicher, auf NFS-Servern wie Filestore oder mithilfe paralleler Dateisysteme gespeichert sind, wie im Abschnitt Storage beschrieben.

• Sicherheit. Bei sensiblen Daten müssen Sie sicherstellen, dass der Zugriff immer autorisiert ist und die Daten im Ruhezustand und bei der Übertragung angemessen verschlüsselt werden. Während Cloud-Speicher Daten im Ruhezustand und während der Übertragung verschlüsselt, können Sie eine zusätzliche Steuerungsebene anwenden und Schlüssel entweder im Cloud-Schlüsselverwaltungsdienst oder selbst verwalten. Die Schlüssel müssen vor der Ausführung des Jobs auf den computenodes abgerufen oder installiert werden.

• Latenz zwischen Knoten. Bei eng gekoppelten HPC-Apps ist die Leistung möglicherweise empfindlich gegenüber der Latenz zwischen Knoten im Cluster.Da Google Cloud Knoten mit einer Größe von bis zu 64 Kernen bereitstellt, können Sie parallele 64-Wege-Jobs ausführen, ohne Knoten zu durchlaufen. In den meisten Fällen funktionieren Jobs mit etwa 1000 Kernen oder weniger auf nicht spezialisierter Netzwerkhardware recht gut.

• Softwarelizenzverwaltung. Viele kommerzielle Anwendungen erfordern alicense Server, manchmal auch als Schlüsselserver bekannt. Einige Apps verfügen über einen integrierten oder empfohlenen Lizenzserver, andere sind möglicherweise mit vorhandenen Lizenzserverangeboten kompatibel. Einige Job-Scheduler können bei der Lizenzverwaltung helfen und verhindern, dass Jobs ausgeführt werden, bis eine Lizenz verfügbar ist.

Empfohlene Architekturen und Best Practices

Technical Computing bietet viele Werkzeuge und Ansätze für verschiedene Umgebungen. Bei so vielen Optionen fällt es Ihnen möglicherweise schwer, loszulegen.Unabhängig von der Wahl der Clusterverwaltungssoftware und des Schedulers gibt es eine Reihe von Best Practices, die Sie bei der Ausführung in Google Cloud befolgen können.

• Nutzen Sie nach Möglichkeit präemptive VMs. Preemptible VMs sind genau wieregular VMs auf Compute Engine, aber preislich bis zu 80% weniger thanregular VMs, mit dem Vorbehalt, dass sie mit wenig Ankündigung zurückgefordert werden können.Bei Workloads mit hohem Durchsatz erkennen Ihre Jobplaner den Verlust des Knotens, behandeln ihn als Knotenfehler und planen alle auf diesem Knoten ausgeführten Aufgaben auf einer anderen Ressource neu. Während jede Arbeit an diesen verlorenen Knoten verloren gehen kann, ist die Wahrscheinlichkeit eines Knotenverlusts gering genug, dass der niedrigere Preis die Chance wert ist. Die erwartete Verlustrate beträgt 5% bis 15%. PreemptibleVMs sind auf maximal 24 Stunden Nutzung beschränkt, bevor sie zurückgefordert werden.
• Nutzen Sie die Kosten und die Bandbreite des Cloud-Speichers, anstatt Ihr eigenes paralleles Dateisystem zu betreiben. Cloud-Speicher bietetstarke Konsistenz und skalierbare parallele Leistung bei niedrigen Gesamtkosten.Während die First-Byte-Latenz bei etwa 100 ms hoch ist, sind Apps, die Cloud-Speicher nutzen können, anstatt einen parallelen Dateiserver auf der Computer-Engine auszuführen, kostengünstiger. Die verfügbare Bandbreite zwischen Cloud-Speicher und den Rechenknoten reicht für manyapps aus, einige Kunden haben eine anhaltende Gesamtbandbreite von über 23 GB / s gemeldet.
• Erstellen Sie einen Single-App- oder Single-Group-Cluster. Herkömmliche Cluster werden über mehrere Benutzer, Gruppen und Apps verteilt, was zu langen Warteschlangenzeiten für Jobs und ineffizienter Ressourcennutzung durch Apps führen kann. Erwägen Sie in Google Cloud, mehrere Cluster für jede Gruppe oder jedes Projekt zu erstellen und Cluster zu verwenden, die für bestimmte Apps optimiert sind, die darauf ausgeführt werden. Unabhängig davon, ob Sie einen Cluster für zwei Stunden oder zwei Cluster für jeweils eine Stunde ausführen, sind die Gesamtkosten gleich.

Während jede Implementierung einzigartig ist, enthalten die folgenden Abschnitte einige allgemeine Empfehlungen für drei häufige Fälle.

Unabhängige Forscher, die ihre Daten verarbeiten möchten

Einzelne Forscher versuchen in der Regel, ihre App über ihre Daten hinweg auszuführen und so schnell wie möglich fertig zu stellen. Sie mögen Experten in ihrer Anwendung sein, aber sie möchten keine Experten in der Clusterverwaltung oder -verwaltung sein.

Wenn Sie Workloads mit hohem Durchsatz ausführen, können Sie die Cloud Life SciencesPipelines-API verwenden.Für die Pipelines-API müssen Sie Ihre App in einen Docker-Container legen und Ihre Eingabedateien in einem Cloud-Speicher-Bucket ablegen. Danach können Sie das Befehlszeilentool gcloud verwenden, um die App gegen alle Dateien im Cloud Storage-Bucket zu starten. Sie können theresults in einem anderen Cloud-Speicher-Bucket platzieren.

Hier ist ein Beispiel für einen Befehl zum Ausführen einer Task, die Samtools verwendet, um eine BAM-Indexdatei aus einer Eingabe-BAM-Datei zu generieren:

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

Wo

• repräsentiert die ID Ihrer App in der Pipelines-API.
• steht für den Namen Ihres Cloud Storage-Buckets.
• repräsentiert den Namen Ihres Verzeichnisses.

Es muss kein Cluster bereitgestellt oder verwaltet werden. Die Aufgaben werden einfach bis zum Abschluss in einer VM ausgeführt, die von der Pipelines-API bereitgestellt und verwaltet wird. Dies ist kosteneffizient, da Compute Engine pro Sekunde der Nutzung abrechnet.

Kleiner bis mittlerer Cluster für ein einzelnes Projekt oder Team

In einem Projekt oder Team haben die Mitglieder möglicherweise Zugriff auf einen Cluster, der von einem zentralen Team für Benutzer in ihrem gesamten Unternehmen ausgeführt wird, oder auf umfangreiche Ressourcen in einem externen HPC-Center. In beiden Fällen werden die Cluster professionell verwaltet und mit Standardwerkzeugen aufgerufen. Benutzer können beispielsweise ssh verwenden, um eine Verbindung zu einem Kopfknoten herzustellen, und Grid Enginesubmit -Skripte verwenden, um Aufträge zur Ausführung zu senden.

Ein Ansatz für ein solches Team besteht darin, mit ElastiCluster eine Clusterumgebung zu definieren, die ihren lokalen Systemen ähnelt. Sie können den Cluster anpassen, indem sie einen Compute Engine-Maschinentyp auswählen, der für ihre App am besten geeignet ist, und die Startskripte anpassen, um die Softwareabhängigkeiten für ihre App zu installieren. Eingabedaten können weiterhin im Cloud-Speicher bereitgestellt werden, und Sie können gcsfuse auf den Rechenknoten installieren, um die Eingabedaten einzuhängen.

Diese Details werden in der ElastiCluster-Konfigurationsdatei aufgezeichnet, und wenn eine Berechnung erforderlich ist, wird ein Cluster beispielsweise mithilfe des Befehlszeilentools aufgerufen:

% elasticluster start astrocluster1

Der Cluster, der in der Konfigurationsdatei als astrocluster1 bezeichnet wird, wird wie angegeben bereitgestellt und konfiguriert. Die Definitionen in einer Konfigurationsdatei sind flexibel und unterstützen verschiedene Knotentypen für Head- und Compute-Knoten, Compute Enginepersistente Festplatten für Scratch-Speicherplatz, Preemptible VMs zur Senkung der Kosten für Highthroughput-Workloads und GPUs für einen beschleunigten Betrieb. Ein Beispiel für eine Basiskonfiguration für einen Slurm-basierten Cluster mit 10 Rechenknoten und 1 Kopfknoten mit virtuellen 32-Core-Maschinen auf Basis von CentOS würde wie folgt aussehen:

 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 Jobs mehr im System ausgeführt werden, können Sie den Cluster stoppen:

% elasticluster stop astrocluster1

Bei größeren Workloads können Sie:

• Passen Sie die Cluster-Maschinentypen an, um die Kosten weiter zu senken.
• Fügen Sie einen externen parallelen Filer hinzu, um die Leistung im Maßstab zu erhöhen.
• Fügen Sie automatische Skalierungsfunktionen hinzu, um zusätzliche Knoten basierend auf der Warteschlangentiefe hinzuzufügen und zu entfernen.

HPC-Center Burst-Kapazität zu bestehenden Clustern hinzufügen

Zentrale HPC-Center verfügen über eine enorme Rechenkapazität, aber da sie von vielen Gruppen im gesamten Unternehmen oder in der Organisation verwendet werden, weisen HPC-Center in der Regel eine konstant hohe Auslastung und lange Wartezeiten auf. Sie werden typischerweise mit Blick auf eine bestimmte Produktionskapazität gekauft, und wenn unvorhergesehene Arbeitslasten in den Mix eingehen, können sie den Fortschritt erheblich verlangsamen.

In diesen Situationen können Sie in die Google Cloud-Umgebung eindringen, indem Sie Compute Nodes vorübergehend zum Cluster hinzufügen. Der Cluster wird zu einem Hybrid, wobei der Head-Knoten und einige Compute-Knoten lokal und andere Computenodes in Google Cloud ausgeführt werden. Wenn die Jobwarteschlangen entleert wurden, können diezusätzliche Knoten können freigegeben werden.

Der Wechsel in die Cloud ist aus mehreren Gründen praktisch:

• Es unterhält eine konsistente Benutzerumgebung für job submission andmanagement. Benutzer wissen nicht, ob zusätzliche Knoten hinzugefügt werden.
• Es ermöglicht IT-Managern, Richtlinien für den Burst zu definieren, um die Kosten zu kontrollieren.

Die größte Herausforderung besteht darin, einen konsistenten Daten- und Dateinamensraum für alle Jobs 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 dieser Situation können Jobs, die auf diese Dateien verweisen, nicht ausgeführt werden.

Wenn die Google Cloud-Knoten mit internen Dateizugriffsberechtigungen konfiguriert sind, werden Jobs ausgeführt, die jedoch möglicherweise nicht auf dieselbe Weise ausgeführt werden und möglicherweise zusätzliche Netzwerkbandbreite und Ausgangsgebühren verursachen. Darüber hinaus können parallele Jobs, die auf lokale und Cloud-Knoten aufgeteilt sind, aufgrund der zusätzlichen Latenz zwischen den verschiedenen Teilen der App möglicherweise nicht gut abschneiden.

Bei Jobs mit hohem Durchsatz umgeht die Verwendung von HTCondor zum Eindringen in Cloud-Ressourcen viele dieser Herausforderungen. HTCondor unterstützt die dynamische Bereitstellung mitglideinwms.Wenn Jobs an die Jobwarteschlange gesendet werden, können sie Knoten auslösen, die bereitgestellt und dem Cluster hinzugefügt werden. Wenn sie hinzugefügt werden, überträgt der Condor-Scheduler die Eingabedateien an den angegebenen Knoten und verwendet diese zusätzlichen Knoten, um die Aufgaben auszuführen und die Warteschlange zu leeren.

Lesen Sie mehr über Cluster Computing-Anwendungsfälle in Google Cloud:

• Google Cloud, HEPCloud und die Natur der Natur
• 220.000 Kerne und Zählen: MIT-Mathematikprofessor bricht Rekord für den größten Compute Engine-Job aller Zeiten

Lesen Sie mehr über:

• Dateiserver auf Compute Engine
• Cloud Deployment Manager-Dokumentation

Erste Schritte mit Ihrem Cluster:

• Stapelverarbeitung mit Compute Engine Autoscaler
• Erstellen eines HTCondor-Clusters mithilfe von Cloud Deployment Manager-Vorlagen

Beispielprojekte auf GitHub:

• dsub beispiel: Einfache Batch-Jobs mit Docker
• ElastiCluster example

• Pipelines API examples

• Probieren Sie andere Google Cloud-Funktionen selbst aus. Schauen Sie sich unsere Tutorials an.