pegasus-plan - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

pegasus-plan – führt Pegasus aus, um den ausführbaren Workflow zu generieren

ZUSAMMENFASSUNG

Pegasus-Plan [-v] [-q] [-V] [-h]
[-Dprop=Wert...]] [-b Präfix]
[--conf propsfile]
[-c Cachedatei[,Cachedatei...]] [--Aufräumen Aufräumarbeiten Strategie ]
[-C Stil[,Stil...]]
[--dir dir]
[--Macht] [--force-replan]
[--inherited-rc-files] [-j Präfix]
[-n][-I Eingabeverzeichnis][-O Ausgabeverzeichnis] [-o site]
[-s site1[,site2...]]
[--staging-site s1=ss1[,s2=ss2[..]]
[--randomdir[=dirname]]
[--relative-dir dir]
[--relative-submit-dir dir]
-d daxfile

BESCHREIBUNG

Die Pegasus-Plan Der Befehl nimmt den DAX als Eingabe auf und generiert einen ausführbaren Workflow
normalerweise in Form von Kondor Dateien einreichen, die an eine übermittelt werden können Ausführung Website für
Ausführung.

Im Rahmen der Generierung eines ausführbaren Workflows muss der Planer Folgendes ermitteln:

frustrierten
Der Pegasus Workflow Planner stellt sicher, dass alle für die Ausführung erforderlichen Daten vorliegen
Der ausführbare Workflow wird durch Hinzufügen von Übertragungsknoten an die Ausführungsstelle übertragen
an geeigneten Stellen im DAG. Dies geschieht durch die Suche nach einem geeigneten Replik
Katalog um die Speicherorte der Eingabedateien für die verschiedenen Jobs zu bestimmen. Von
Standardmäßig wird ein dateibasierter Replikatkatalog verwendet.

Der Pegasus Workflow Planner versucht auch, den Workflow zu reduzieren, sofern nicht anders angegeben
ansonsten. Dies geschieht durch das Löschen der Jobs, deren Ausgabedateien gefunden wurden
an einer Stelle im Replikatkatalog. Derzeit werden keine Kostenmetriken verwendet. Jedoch
Bevorzugt wird ein Ort, der der Hinrichtungsstätte entspricht

Der Planer kann auch Knoten hinzufügen, um alle materialisierten Dateien an eine Ausgabe zu übertragen
Website. Der Speicherort auf der Ausgabe-Site wird durch Nachschlagen im Site-Katalog bestimmt
Datei, deren Pfad aus der übernommen wird pegasus.catalog.site.file Resorts
Wert.

ausführbare Dateien
Der Planer sucht in einem Transformationskatalog nach den Speicherorten der ausführbaren Dateien
auf den im ausführbaren Workflow verwiesen wird. Benutzer können INSTALLED oder STAGEABLE angeben
ausführbare Dateien im Katalog. Stagingfähige ausführbare Dateien können von Pegasus zum Staging verwendet werden
ausführbare Dateien auf Ressourcen, auf denen sie nicht vorinstalliert sind.

RESSOURCEN
Das Layout der Websites, auf denen Pegasus Jobs eines Workflows planen kann, wird beschrieben
im Site-Katalog. Der Planer sucht im Standortkatalog nach einem Standort
in welchen Verzeichnissen ein Job ausgeführt werden kann, welche Server für das Ein- und Auslagern verwendet werden sollen
Daten und welche Jobmanager (falls zutreffend) für die Übermittlung von Jobs verwendet werden können.

Die Speicherorte für Daten und ausführbare Dateien können jetzt in DAX-Dateien angegeben werden, die dem DAX-Schema entsprechen
Version 3.2 oder höher.

OPTIONAL

Jede Option wird mit ihren langen Optionssynonym(en) angezeigt.

-DEigenschaft=Wert
Die -D Option ermöglicht es einem erfahrenen Benutzer, bestimmte Eigenschaften zu überschreiben, die
beeinflussen die Programmausführung, darunter den Standardspeicherort des Benutzers
properties-Datei und den PEGASUS-Home-Speicherort. Man kann mehrere CLI-Eigenschaften einstellen, indem man
diese Option mehrmals geben. Die -D Option(en) muss die erste Option auf dem . sein
Befehlszeile. Eine CLI-Eigenschaft hat Vorrang vor der Eigenschaftendateieigenschaft des
gleicher Schlüssel.

-d Datei, --dax Datei
Der DAX ist die XML-Eingabedatei, die einen abstrakten Workflow beschreibt. Dies ist eine Pflicht
Option, die genutzt werden muss.

-b Präfix, --Basisname Präfix
Das Basisnamenspräfix, das beim Erstellen von Workflow-Dateien wie Dagman verwendet werden soll
Datei (.dag-Datei) und andere Workflow-spezifische Dateien, die von Condor erstellt werden. Normalerweise
Dieses Präfix wird aus dem Namensattribut übernommen, das im Stammelement des Dax angegeben ist
Dateien.

-c Datei[,Datei,...], --Zwischenspeicher Datei[,Datei,...]
Eine durch Kommas getrennte Liste von Pfaden zu Replikat-Cachedateien, die die Ergebnisse überschreiben
der Replikatkatalog für eine bestimmte LFN.

Jeder Eintrag in der Cache-Datei beschreibt eine LFN, die entsprechende PFN und die
zugehörigen Attribute. Das Poolattribut sollte für jeden Eintrag angegeben werden.

LFN_1 PFN_1 pool=[Site-Handle 1]
LFN_2 PFN_2 pool=[Site-Handle 2]
...
LFN_N PFN_N [Site-Handle N]

Um die Cache-Dateien als zusätzliche Replikatkataloge zu behandeln, legen Sie die Eigenschaft fest
pegasus.catalog.replica.cache.asrc zu wahr. Dadurch ergibt sich die Zuordnung im Cache
Dateien, die mit den Zuordnungen im Replikatkatalog zusammengeführt werden sollen. Also für eine bestimmte
LFN stehen sowohl die Einträge in der Cache-Datei als auch im Replikatkatalog für die Reproduktion zur Verfügung
Auswahl.

-C Stil[,Stil,...], - Cluster Stil[,Stil,...]
Durch Kommas getrennte Liste von Clustering-Stilen, die auf den Workflow angewendet werden sollen. Diese Art von
Der Vorgang führt zu einer Gruppierung von n Rechenjobs zu größeren Jobs, um die Remote-Ressourcen zu reduzieren
Planungsaufwand. Sie können eine Liste rekursiver Clustering-Techniken angeben
Wenden Sie sie auf den Workflow an. Auf diese Weise können Sie beispielsweise einige Jobs in einem Cluster zusammenfassen
Workflow mit horizontalem Clustering und verwenden Sie dann Label-basiertes Clustering für den
Zwischenworkflow für vertikales Clustering.

Die geclusterten Jobs können am Remote-Standort entweder nacheinander oder mithilfe von MPI ausgeführt werden.
Dies kann durch Festlegen der Eigenschaft angegeben werden pegasus.job.aggregator. Die Immobilie kann
kann durch die Zuordnung des PEGASUS-Profilschlüssels überschrieben werden Kollaps entweder mit dem
Transformation im Transformationskatalog oder die Ausführungsstelle in der Site
Katalog. Der angegebene Wert (für die Eigenschaft oder das Profil) ist der logische Name von
die Transformation, die für Clustering-Jobs verwendet werden soll. Beachten Sie, dass Clustering dies tun wird
passieren nur, wenn die entsprechenden Transformationen in der Transformation katalogisiert sind
Katalog.

PEGASUS wird mit einer ausführbaren Clustering-Datei geliefert Pegasus-Cluster das findet man im
$PEGASUS_HOME/bin Verzeichnis. Es führt die Jobs im Cluster-Job nacheinander auf dem aus
gleichen Knoten am entfernten Standort.

Darüber hinaus ist auch ein MPI-basiertes Clustering-Tool namens „pegasus-mpi-cluster“ verfügbar
verteilt und kann im bin-Verzeichnis gefunden werden. Pegasus-MPI-Cluster kann auch sein
Wird im SharedFS-Setup verwendet und muss mit dem MPI der Remote-Site kompiliert werden
Installieren. Verzeichnis. Der Wrapper wird auf jedem MPI-Knoten ausgeführt, wobei der erste der ist
Meister und der Rest als Arbeiter.

Standardmäßig Pegasus-Cluster wird für Clustering-Jobs verwendet, sofern es nicht in der überschrieben wird
Eigenschaften oder durch den Pegasus-Profilschlüssel Kollaps.

Die folgenden Arten von Clustering-Stilen werden derzeit unterstützt:

· horizontal ist der Clustering-Stil, bei dem sich Arbeitsplätze auf derselben Ebene befinden
zu größeren Aufgaben zusammengefasst. Eine Ebene des Workflows wird als die größte definiert
Abstand eines Knotens vom Stamm des Workflows. Clustering findet nur bei Jobs statt
vom gleichen Typ, dh sie beziehen sich auf die gleiche logische Transformation im
Transformationskatalog.

Horizontales Clustering kann in einem von zwei Modi betrieben werden. A. Basierend auf der Anzahl der Jobs.

Die Granularität des Clusterings kann durch die Zuordnung von PEGASUS angegeben werden
Profilschlüssel Cluster.Größe oder den PEGASUS-Profilschlüssel Cluster.num an. Nach der Installation können Sie HEIC-Dateien mit der
Transformation.

Die Cluster.Größe Der Schlüssel gibt an, wie viele Jobs in einem größeren Cluster zusammengefasst werden müssen
geclusterter Job. Der Schlüssel „clusters.num“ gibt an, wie viele geclusterte Jobs vorhanden sein sollen
für eine bestimmte Ebene an einem bestimmten Ausführungsort erstellt. Wenn beide Schlüssel vorhanden sind
Wenn für eine bestimmte Transformation ein Wert angegeben ist, wird der Schlüsselwert „clusters.num“ verwendet
um die Clustering-Granularität zu bestimmen.

1. Laufzeitbasiert.

Um Jobs nach Laufzeiten zu gruppieren, muss der Benutzer eine und zwei Eigenschaften festlegen
Profilschlüssel. Die Eigenschaft pegasus.clusterer.preference muss auf eingestellt sein
Wert Laufzeit. Darüber hinaus muss der Benutzer zwei Pegasus-Profile angeben. A.
Clusters.maxruntime, das die maximale Dauer angibt, für die die
Der geclusterte Job soll ausgeführt werden. B. job.runtime, das die Dauer angibt
für den der Job ausgeführt wird, dem der Profilschlüssel zugeordnet ist. Im Idealfall,
Clusters.maxruntime sollte im Transformationskatalog und in job.runtime festgelegt werden
sollte für jeden Auftrag individuell eingestellt werden.

· Etikette ist der Clustering-Stil, mit dem Sie die Jobs in Ihrem Workflow kennzeichnen können.
Die Jobs mit derselben Ebene werden in denselben geclusterten Job eingefügt. Dies ermöglicht Ihnen
Fassen Sie Jobs über Ebenen hinweg oder auf eine Weise zusammen, die für Sie am besten geeignet ist
Anwendung.

Um den Workflow zu kennzeichnen, müssen Sie PEGASUS-Profile mit den Jobs in verknüpfen
DAX. Der Profilschlüssel, der zum Beschriften des Workflows verwendet werden soll, kann über die Eigenschaft festgelegt werden
pegasus.clusterer.label.key. Die Standardeinstellung lautet „Beschriftung“, d. h., wenn Sie einen PEGASUS haben
Profilschlüsselbezeichnung mit Jobs, die Jobs mit demselben Wert für das Pegasus-Profil
Die Schlüsselbezeichnung wird in denselben geclusterten Job verschoben.

--Aufräumen Aufräumarbeiten Strategie
Die Bereinigungsstrategie, die für Workflows verwendet werden soll. Pegasus kann Bereinigungsjobs hinzufügen
ausführbarer Workflow, der Dateien und Verzeichnisse während des Workflows entfernen kann
Ausführung.

Die folgenden Arten von Bereinigungsstrategien werden derzeit unterstützt:

· keine Deaktiviert die Bereinigung vollständig. Der Planer fügt keine Bereinigungsjobs hinzu
ausführbaren Workflow überhaupt.

· Blatt Der Planer fügt pro Staging-Site einen Blattbereinigungsknoten hinzu, der die entfernt
Verzeichnis, das durch den Job „Verzeichnis erstellen“ im Workflow erstellt wurde.

· an Ort und Stelle Der Planer fügt zusätzlich zu den Blattbereinigungsknoten auch Bereinigungsknoten pro hinzu
Ebene des Workflows, die während der Ausführung nicht mehr benötigte Dateien entfernt. Für
Beispielsweise entfernt ein hinzugefügter Bereinigungsknoten Eingabedateien für eine bestimmte Berechnung
Auftrag, nachdem der Auftrag erfolgreich abgeschlossen wurde.

--conf Profil
Der Pfad zur Eigenschaftendatei, die den Eigenschaftenplaner enthält, muss while verwendet werden
Planung des Arbeitsablaufs.

--dir dir
Das Basisverzeichnis, in dem normalerweise die Ausgabe des Pegasus Workflow Planner erfolgen soll
Condor übermittelt Dateien, die generiert werden sollen. Pegasus erstellt dabei eine Verzeichnisstruktur
Basisverzeichnis auf der Grundlage des Benutzernamens, der VO-Gruppe und der Bezeichnung des Workflows im
DAX.

Standardmäßig ist das Basisverzeichnis das Verzeichnis, von dem aus das ausgeführt wird Pegasus-Plan
Befehl.

-f, --Macht
Dadurch wird die Reduktionsphase umgangen, in der die abstrakte DAG auf Basis reduziert wird
der Speicherorte der vom Replikatkatalog zurückgegebenen Ausgabedateien. Das ist
analog zu a um Stilgenerierung des ausführbaren Workflows.

--force-replan
Wenn bei hierarchischen Workflows ein DAX-Auftrag fehlschlägt, wird bei jedem Auftrag die Wiederherstellung standardmäßig wiederholt
DAG des zugehörigen Workflows wird übermittelt. Diese Option veranlasst Pegasus, das neu zu planen
Stattdessen wird im Fehlerfall ein DAX-Job ausgeführt.

-g, --Gruppe
Die VO-Gruppe, zu der der Benutzer gehört.

-h, --help
Zeigt alle Optionen zum Pegasus-Plan Befehl.

--inherited-rc-files Datei[,Datei,...]
Eine durch Kommas getrennte Liste von Pfaden zu Replikatdateien. Die darin genannten Standorte verfügen über eine
haben eine niedrigere Priorität als die Speicherorte in der DAX-Datei. Diese Option wird normalerweise verwendet
intern für hierarchische Arbeitsabläufe, wobei die in der genannten Dateispeicherorte verwendet werden
übergeordneter (umfassender) Workflow DAX, der an die (entsprechenden) Unterworkflows übergeben wird
DAX-Jobs.

-I, --input-dir
Ein Pfad zum Eingabeverzeichnis, in dem sich die Eingabedateien befinden. Dadurch wird intern a geladen
Verzeichnisbasiertes Replikatkatalog-Backend, das eine Verzeichnisliste erstellt
Erstellen Sie die LFN→PFN-Zuordnungen für die Dateien im Eingabeverzeichnis. Sie können angeben
Zusätzliche Eigenschaften entweder auf der Befehlszeile oder in der Eigenschaftendatei, um die zu steuern
Site-Attribut und URL-Präfix, die den Zuordnungen zugeordnet sind.

pegasus.catalog.replica.directory.site gibt das Poolattribut an, mit dem verknüpft werden soll
die Zuordnungen. Standardmäßig ist lokal

pegasus.catalog.replica.directory.url.prefix gibt das zu verwendende URL-Präfix an
Aufbau des PFN. Standardmäßig ist file://

-j Präfix, --job-präfix Präfix
Das Job-Präfix, das zum Erstellen der Dateinamen für die Job-Übermittlungsdateien angewendet werden soll.

-n, --nocleanup
Diese Option ist veraltet. Verwenden Sie stattdessen --cleanup none.

-o site, --output-site site
Die Ausgabesite, an die die Ausgabedateien des DAX übertragen werden.

Standardmäßig ist der materialisiert frustrierten verbleibt im Arbeitsverzeichnis auf dem Ausführung
Website, auf der es erstellt wurde. Nur diese Ausgabedateien werden an eine Ausgabesite übertragen
für welches Übertragungsattribut im DAX auf true gesetzt ist.

-O Möglichkeiten für das Ausgangssignal: Verzeichnis, --output-dir Möglichkeiten für das Ausgangssignal: Verzeichnis
Das Ausgabeverzeichnis, in das die Ausgabedateien des DAX übertragen werden.

Wenn -o angegeben wird, ist das Speicherverzeichnis der Site, die als Ausgabesite angegeben ist
aktualisiert, um das übergebene Verzeichnis zu sein. Wenn keine Ausgabesite angegeben ist, dann diese Option
Setzt die Ausgabesite intern auf lokal, wobei das Speicherverzeichnis auf aktualisiert wird
Verzeichnis übergeben.

-q, --ruhig
Verringert die Protokollierungsstufe.

-r[dirname], --randomdir[=dirname]
Pegasus Worfklow Planner fügt dem ausführbaren Workflow Jobs zum Erstellen von Verzeichnissen hinzu
Erstellen Sie ein Verzeichnis, in dem alle Jobs für diesen Workflow auf einer bestimmten Site ausgeführt werden.
Das erstellte Verzeichnis befindet sich im Arbeitsverzeichnis (im Site-Katalog mit angegeben).
jede Seite).

Standardmäßig dupliziert Pegasus die relative Verzeichnisstruktur auf dem Submit-Host
der entfernte Standort. Der Benutzer kann diese Option ohne Argumente angeben, um einen Zufall zu erstellen
Zeitstempelbasierter Name für das Ausführungsverzeichnis, das vom Erstellungsverzeichnis erstellt wird
Arbeitsplätze. Der Benutzer kann das optionale Argument für diese Option angeben, um das anzugeben
Basisname des Verzeichnisses, das erstellt werden soll.

Die Jobs zum Erstellen von Verzeichnissen beziehen sich auf die dirmanager ausführbare Datei, die im Lieferumfang enthalten ist
PEGASUS-Worker-Paket. Der Transformationskatalog wird nach der Transformation durchsucht
namens pegasus::dirmanager für alle entfernten Standorte, an denen der Workflow stattgefunden hat
geplant. Pegasus kann einen Standardpfad für die ausführbare Dirmanager-Datei erstellen, wenn
PEGASUS_HOME Die Umgebungsvariable ist den Sites im Site-Katalog zugeordnet als
ein Umgebungsprofil.

--relative-dir dir
Das Verzeichnis relativ zum Basisverzeichnis, in dem sich der ausführbare Workflow befinden soll
generiert und ausgeführt. Dies überschreibt die Standardverzeichnisstruktur von Pegasus
erstellt basierend auf Benutzername, VO-Gruppe und dem DAX-Label.

--relative-submit-dir dir
Das Verzeichnis relativ zum Basisverzeichnis, in dem sich der ausführbare Workflow befinden soll
generiert. Dies überschreibt die Standardverzeichnisstruktur, die Pegasus basierend erstellt
auf Benutzername, VO-Gruppe und das DAX-Label. Durch Angabe --relative-dir und
--relative-submit-dir Sie können unterschiedliche relative Ausführungsverzeichnisse auf dem haben
Remote-Site und anderes relatives Übermittlungsverzeichnis auf dem Übermittlungshost.

-s site[,site,...], --sites site[,site,...]
Eine durch Kommas getrennte Liste von Ausführungsstandorten, auf denen der Workflow ausgeführt werden soll.
Für jede Site sollte im Site-Katalog ein Eintrag vorhanden sein, der verwendet wird. Laufen
Geben Sie auf dem Submit-Host den Ausführungsort als an aus einer regionalen.

Falls diese Option nicht angegeben ist, werden alle Sites im Site-Katalog ausgewählt
als Kandidaten für die Ausführung des Workflows.

--staging-site s1=ss1[,s2=ss2[..]]
Eine durch Kommas getrennte Liste von Schlüssel=Wert-Paaren, wobei der Schlüssel der Ausführungsort und ist
value ist die Staging-Site für diese Ausführungssite.

Bei der Ausführung auf einem gemeinsam genutzten Dateisystem wird die Staging-Site automatisch aktiviert
vom Planer als Ausführungsort zugeordnet. Wenn nur ein Wert angegeben ist, dann
Dies wird als Bereitstellungsort für alle Hinrichtungsorte angesehen. z.B --staging-site
Lokal bedeutet, dass der Planer die lokale Site als Staging-Site für alle Jobs verwendet
im Arbeitsablauf.

-s, --einreichen
Sendet das generierte ausführbar Arbeitsablauf. mit automatisierten pegasus-lauf Skript in
Verzeichnis $PEGASUS_HOME/bin. Standardmäßig generiert der Pegasus Workflow Planner nur
Der Condor reicht Dateien ein und reicht sie nicht ein.

-v, - ausführlich
Erhöht die Ausführlichkeit von Nachrichten über das Geschehen. Standardmäßig sind alle FATAL,
ERROR-, CONSOLE- und WARN-Meldungen werden protokolliert. Die Protokollierungshierarchie ist wie folgt:

1. TÖDLICH

2. FEHLER

3. KONSOLE

4. WARNUNG

5. INFORMATIONEN

6. KONFIG

7. DEBUG

8. SPUR

Um beispielsweise zusätzlich die Meldungen INFO, CONFIG und DEBUG anzuzeigen, legen Sie fest -vvv.

-V, --Version
Zeigt die aktuelle Versionsnummer des Pegasus Workflow Management Systems an.

RÜCKKEHR Mehrwert

Wenn der Pegasus Workflow Planner erfolgreich einen ausführbaren Workflow generieren kann,
Der Exitcode ist 0. Alle Laufzeitfehler führen zu einem Exitcode von 1. Dies ist normalerweise der Fall
Dies ist der Fall, wenn Sie Ihre Kataloge usw. falsch konfiguriert haben. Im Falle eines Fehlers
Beim Laden einer bestimmten Modulimplementierung zur Laufzeit lautet der Exitcode 2. Dies
Dies liegt normalerweise daran, dass Factory-Methoden beim Laden eines Moduls fehlschlagen. Im Falle eines anderen
Wenn während der Ausführung des Befehls ein Fehler auftritt, ist der Exitcode 1. In den meisten Fällen ist
Die protokollierte Fehlermeldung sollte einen klaren Hinweis darauf geben, wo etwas schief gelaufen ist.

STEUERN PEGASUS-PLAN SPEICHER VERBRAUCH

pegasus-plan wird versuchen, die Speichergrenzen automatisch anhand von Faktoren wie der Gesamtzahl zu ermitteln
Systemspeicher und potenzielle Speichergrenzen (ulimits). Die automatischen Grenzwerte können sein
überschrieben, indem zuvor die Umgebungsvariablen JAVA_HEAPMIN und JAVA_HEAPMAX festgelegt wurden
Aufruf von Pegasus-Plan. Die Werte sind in Megabyte angegeben. Als Faustregel gilt: JAVA_HEAPMIN kann
auf die Hälfte des Wertes von JAVA_HEAPMAX gesetzt werden.

PEGASUS IMMOBILIEN

Dies ist keine erschöpfende Liste der verwendeten Eigenschaften. Für die vollständige Beschreibung und Liste
von Eigenschaften beziehen sich auf $PEGASUS_HOME/doc/advanced-properties.pdf

pegasus.selector.site
Gibt an, welche Art von Site-Selektor Sie verwenden möchten. Wenn nicht angegeben, wird die Standardeinstellung verwendet
Wert von Zufällig wird eingesetzt. Weitere unterstützte Modi sind RoundRobin und NonJavaCallout zur Abwicklung, Integrierung, Speicherung und
Aufrufe an einen externen Site-Selektor.

pegasus.catalog.replica
Gibt den Typ des Replikatkatalogs an, der verwendet werden soll.

Wenn nicht angegeben, wird der Wert standardmäßig verwendet RLS.

pegasus.catalog.replica.url
Kontaktzeichenfolge für den Zugriff auf den Replikatkatalog. Im Fall von RLS ist es die RLI-URL.

pegasus.dir.exec
Ein Suffix für das Arbeitsverzeichnis im Site-Katalog, um die aktuelle Arbeitsweise zu bestimmen
Verzeichnis. Wenn relativ, wird der Wert aus dem an das Arbeitsverzeichnis angehängt
site.config-Datei. Wenn absolut, stellt es das Arbeitsverzeichnis dar.

pegasus.catalog.transformation
Gibt den Typ des zu verwendenden Transformationskatalogs an. Man kann entweder eine Datei verwenden
basierten oder einem datenbankbasierten Transformationskatalog. Derzeit ist die Standardeinstellung Text.

pegasus.catalog.transformation.file
Der Speicherort der Datei, die als Transformationskatalog verwendet werden soll.

Wenn nicht angegeben, wird der Standardspeicherort $PEGASUS_HOME/var/tc.data verwendet.

pegasus.catalog.site
Gibt den Typ des zu verwendenden Site-Katalogs an. Man kann entweder eine textbasierte oder eine verwenden
XML-basierter Site-Katalog. Derzeit ist die Standardeinstellung XML3.

pegasus.catalog.site.file
Der Speicherort der Datei, die als Site-Katalog verwendet werden soll. Wenn nicht angegeben, ist der Standardwert
$PEGASUS_HOME/etc/sites.xml wird im Falle des XML-basierten Site-Katalogs verwendet
$PEGASUS_HOME/etc/sites.txt im Falle des textbasierten Site-Katalogs.

pegasus.data.configuration
Diese Eigenschaft richtet Pegasus für die Ausführung in verschiedenen Umgebungen ein. Dies kann eingestellt werden

sharedfs Wenn dies festgelegt ist, wird Pegasus so eingerichtet, dass es Jobs auf dem freigegebenen Server ausführt
Dateisystem auf der Ausführungsseite. Dies setzt voraus, dass der Kopfknoten eines Clusters und
Die Worker-Knoten teilen sich ein Dateisystem. Die Staging-Site ist in diesem Fall dieselbe wie die
Hinrichtungsstätte.

nonsharedfs Wenn dies festgelegt ist, wird Pegasus so eingerichtet, dass Jobs auf einer Ausführungsseite ausgeführt werden
ohne auf ein gemeinsames Dateisystem zwischen dem Hauptknoten und den Arbeitsknoten angewiesen zu sein.

Condorio Wenn dies festgelegt ist, wird Pegasus so eingerichtet, dass Jobs in einem reinen Condor-Pool ausgeführt werden
Die Knoten teilen sich kein Dateisystem. Die Daten werden von dort auf den Rechenknoten bereitgestellt
Senden Sie den Host mit Condor File IO.

pegasus.code.generator
Der zu verwendende Codegenerator. Standardmäßig werden Condor-Übermittlungsdateien für generiert
ausführbarer Workflow. Einstellung auf Schale führt dazu, dass Pegasus ein Shell-Skript generiert
die auf dem Submit-Host ausgeführt werden kann.

Nutzen Sie pegasus-plan online über die Dienste von onworks.net