pegasus-mpi-cluster - מקוון בענן

תָכְנִית:

שֵׁם

pegasus-mpi-cluster - כלי להפעלת זרימות עבודה חישוביות המתבטאות כ-DAGs
(גרפים אציקליים מכוונים) על אשכולות חישוביים באמצעות MPI.

תַקצִיר

Pegasus-mpi-cluster [אפשרויות] workflow.dag

תיאור

Pegasus-mpi-cluster הוא כלי המשמש להפעלת HTC (High Throughput Computing) מדעי
זרימות עבודה במערכות המיועדות עבור HPC (מחשוב גבוה בביצועים). למערכות HPC רבות יש
ארכיטקטורות מותאמות אישית המותאמות ליישומים מקבילים ומקושרים הדוקים. אלה
למערכות יש בדרך כלל רשתות אקזוטיות עם זמן אחזור נמוך המיועדות למעבר קצר
הודעות במהירות רבה בין צמתי מחשוב. רבות מהרשתות הללו הן כל כך גבוהות
אופטימיזציה לכך שצמתי המחשוב אפילו לא תומכים בערימת TCP/IP. זה עושה את זה
בלתי אפשרי להפעיל יישומי HTC באמצעות תוכנה שתוכננה עבור סחורה
אשכולות, כגון קונדור.

Pegasus-mpi-cluster פותחה כדי לאפשר יישומי HTC מחוברים באופן רופף כגון
זרימות עבודה מדעיות כדי לנצל את היתרונות של מערכות HPC. על מנת לעקוף את הרשת
נושאים שפורטו לעיל, Pegasus-mpi-cluster משתמש ב-MPI (ממשק העברת הודעות), א
API נפוץ לכתיבת יישומי SPMD (Single Process, Multiple Data) מקבילים.
לרוב מערכות HPC יש מימוש MPI שעובד בכל רשת אקזוטית
ארכיטקטורה שהמערכת משתמשת בה.

An Pegasus-mpi-cluster העבודה מורכבת מתהליך אב יחיד (תהליך זה הוא בדרגה 0 אינץ'
בשפה MPI) וכמה תהליכי עבודה. תהליך המאסטר מנהל את זרימת העבודה ו
מקצה משימות זרימת עבודה לעובדים לביצוע. העובדים מבצעים את המשימות וחוזרים
התוצאות למאסטר. כל פלט שנכתב ל-stdout או stderr על ידי המשימות נקלט
(ראה מְשִׁימָה STDIUM).

Pegasus-mpi-cluster יישומים מבוטאים כ-DAGs (גרפים אציקליים מכוונים) (ראה DAG
קבצים). כל צומת בגרף מייצג משימה, והקצוות מייצגים תלות
בין המשימות המגבילות את סדר ביצוע המשימות. כל משימה היא א
תוכנית ומערכת של פרמטרים שצריך להפעיל (כלומר פקודה וכמה אופציונליים
טיעונים). התלות מייצגות בדרך כלל תלות בזרימת נתונים ב-
יישום, שבו קבצי הפלט המיוצרים על ידי משימה אחת נחוצים כקלט עבור אחרת.

אם מתרחשת שגיאה בעת ביצוע DAG שגורמת לזרימת העבודה להפסיק, היא יכולה להיות
הופעל מחדש באמצעות קובץ הצלה, המתעד את התקדמות זרימת העבודה (ראה הצלה
קבצים). זה מאפשר Pegasus-mpi-cluster כדי להפעיל את זרימת העבודה במקום שבו היא נעצרה.

Pegasus-mpi-cluster תוכנן לעבוד ככלי עצמאי או כהשלמה ל
מערכת ניהול זרימת העבודה של פגסוס (WMS). למידע נוסף על שימוש ב-PMC עם
פגסוס ראה את הסעיף על PMC ו PEGASUS.

Pegasus-mpi-cluster מאפשר להפעיל יישומים המבוטאים כ-DAG במקביל על a
מספר גדול של צמתי מחשוב. הוא תוכנן להיות פשוט, קל משקל וחזק.

אפשרויות

-h, - עזרה
הדפס הודעת עזרה

-V, --גִרְסָה
מידע על גרסת הדפסה

-v, --מִלוּלִי
הגבר את רמת הרישום. הוספת מרובים -v מעלה את הרמה יותר. ברירת המחדל
רמת יומן היא מידע. (ראה יומן)

-q, --שֶׁקֶט
הפחת את מילולי הרישום. הוספת מרובים -q מוריד את הרמה יותר. ברירת המחדל
רמת יומן היא מידע. (ראה יומן)

-s, --דילוג-הצלה
התעלם מקובץ ההצלה עבור workflow.dag אם הוא קיים. ציין זאת Pegasus-mpi-cluster
עדיין תיצור קובץ הצלה חדש עבור ההרצה הנוכחית. התנהגות ברירת המחדל היא ל
השתמש בקובץ ההצלה אם נמצא אחד. (לִרְאוֹת הצלה קבצים)

-o נתיב, --stdout נתיב
נתיב לקובץ עבור סטדout משימה. (לִרְאוֹת מְשִׁימָה STDIUM ו --לכל משימה)

-e נתיב, --סטדרר נתיב
נתיב לקובץ עבור המשימה stderr. (לִרְאוֹת מְשִׁימָה STDIUM ו --לכל משימה)

-m M, --מקס-כישלונות M
הפסק להגיש משימות חדשות לאחר מכן M משימות נכשלו. פַּעַם M הושג,
Pegasus-mpi-cluster יסיים להפעיל את כל המשימות שהחלו, אך לא
להתחיל עוד משימות. אפשרות זו משמשת כדי למנוע Pegasus-mpi-cluster החל מ-
המשך הפעלת זרימת עבודה שסובלת משגיאה שיטתית, כגון א
חסר נתיב בינארי או נתיב לא חוקי. ברירת המחדל עבור M הוא 0, כלומר בלתי מוגבל
כשלים מותרים.

-t T, --מנסה T
נסה להפעיל כל משימה T פעמים לפני סימון המשימה ככשלה. שימו לב שה- T
ניסיונות אינם נחשבים ככישלונות למטרות ה -m אוֹפְּצִיָה. משימה היא רק
נחשב ככשל אם הוא נוסה T פעמים והכל T ניסיונות מביאים לאפס
קוד יציאה. הערך של T חייב להיות לפחות 1. ברירת המחדל היא 1.

-n, --נולוק
אל תנעל את DAGFILE. כברירת מחדל, Pegasus-mpi-cluster ינסה לרכוש א
נעילה בלעדית על DAGFILE כדי למנוע מעבודות MPI מרובות להפעיל את אותו DAG ב
אותו זמן. אם אפשרות זו צוינה, המנעול לא יירכש.

-r, --לְהַצִיל נתיב
נתיב ליומן הצלה. אם הקובץ קיים, ו -s לא צוין, אז היומן יהיה
משמש לשחזור מצב זרימת העבודה. הקובץ נחתך לאחר קריאתו ו
יומן הצלה חדש נוצר במקומו. ברירת המחדל היא להוסיף .לְהַצִיל ל-DAG
שם קובץ. (לִרְאוֹת הצלה קבצים)

---host-script נתיב
נתיב לסקריפט או קובץ הפעלה להפעלה על כל מארח ייחודי Pegasus-mpi-cluster
פועל הלאה. ניתן להגדיר נתיב זה גם באמצעות סביבת PMC_HOST_SCRIPT
מִשְׁתַנֶה. (לִרְאוֹת HOST סקריפטים)

--מארח-זיכרון גודל
כמות הזיכרון הזמינה בכל מארח ב-MB. ברירת המחדל היא לקבוע את הסכום
של זיכרון RAM פיזי באופן אוטומטי. ניתן להגדיר ערך זה גם באמצעות PMC_HOST_MEMORY
משתנה הסביבה. (לִרְאוֹת מבוסס משאבים תזמון)

--מארח-מעבד מעבד
מספר המעבדים הזמינים בכל מארח. ברירת המחדל היא לקבוע את מספר המעבד
ליבות באופן אוטומטי. ניתן להגדיר ערך זה גם באמצעות סביבת PMC_HOST_CPUS
מִשְׁתַנֶה. (לִרְאוֹת מבוסס משאבים תזמון)

--הגבלות-קפדניות
זה מאפשר מגבלות קפדניות על שימוש בזיכרון עבור משימות. כאשר אפשרות זו מצוינת, ו
משימה מנסה להקצות יותר זיכרון ממה שהתבקש ב-DAG, הזיכרון
פעולת ההקצאה תיכשל.

--max-wall-time דקות
זה המספר המרבי של דקות Pegasus-mpi-cluster יאפשר את זרימת העבודה
לרוץ. מתי הזמן הזה יפוג Pegasus-mpi-cluster יבטל את זרימת העבודה ויתמזג
כל קבצי stdout/stderr של העובדים. הערך הוא בדקות, וה-
ברירת המחדל היא זמן קיר בלתי מוגבל. אפשרות זו נוספה כך שהפלט של זרימת עבודה
יתועד גם אם זרימת העבודה חורג מזמן הקיר המרבי של עבודת האצווה שלו. זֶה
ניתן להגדיר ערך גם באמצעות משתנה הסביבה PMC_MAX_WALL_TIME.

--לכל משימה
זה גורם ל-PMC ליצור קובץ .out.XXX ו-.err.XXX עבור כל משימה במקום
משימת כתיבה stdout/stderr to --stdout ו --סטדרר. שם הקבצים הם
"TASKNAME.out.XXX" ו-"TASKNAME.err.XXX", כאשר "TASKNAME" הוא שם המשימה
מה-DAG ו-"XXX" הוא מספר רצף שמוגדל בכל פעם שהמשימה היא
ניסו. אפשרות זו עוקפת את הערכים עבור --stdout ו --סטדרר. הטיעון הזה הוא
בשימוש על ידי Pegasus כאשר זרימות עבודה מתוכננות במצב PMC בלבד כדי להקל על איתור באגים
ומעקב.

---jobstate-log
אפשרות זו גורמת ל-PMC ליצור קובץ jobstate.log עבור זרימת העבודה. הקובץ הוא
בשם "jobstate.log" והוא ממוקם באותה ספרייה שבה נמצא קובץ ה-DAG
ממוקם. אם הקובץ כבר קיים, אז PMC מוסיף שורות חדשות לקובץ הקיים.
אפשרות זו משמשת את פגסוס כאשר זרימות עבודה מתוכננות במצב PMC בלבד ל
להקל על הניטור.

--monitor-hack
אפשרות זו גורמת ל-PMC ליצור קובץ .dagman.out עבור זרימת העבודה. הקובץ הזה
מחקה את התוכן של קובץ .dagman.out שנוצר על ידי Condor DAGMan. הנקודה של
אפשרות זו היא לגרום לניטור לחשוב שהוא מתמודד עם DAGMan כך
זה יפיק את האירועים המתאימים לאכלוס מסד הנתונים של STAMPEDE
מטרות ניטור. הקובץ נקרא "DAG.dagman.out" כאשר "DAG" הוא הנתיב ל-
קובץ PMC DAG.

--no-resource-log
אל תיצור א workflow.dag.resource קובץ עבור זרימת העבודה.

--אין-שינה-ב-rev
אל תשתמש בסקר עם sleep() כדי ליישם קבלת הודעות. (לִרְאוֹת ידוע נושאים: CPU
נוֹהָג)

--maxfds
הגדר את המספר המרבי של מתארי קבצים שיכולים להישאר פתוחים על ידי המאסטר עבור I/O
העברה. כברירת מחדל, ערך זה מוגדר אוטומטית על סמך הערך של
getrlimit(RLIMIT_NOFILE). הערך חייב להיות לפחות 1, ולא יכול להיות יותר מ
RLIMIT_NOFILE.

--שמור על זיקה
כברירת מחדל, PMC מנסה לאפס את זיקת המעבד והזיכרון. זאת כדי להבטיח זאת
כל המעבדים והזיכרון הזמינים יכולים לשמש משימות PMC במערכות שאינן
מוגדר כהלכה. דגל זה אומר ל-PMC לשמור על הגדרות הזיקה שעברו בירושה
ההורה שלו. שים לב שניתן לנקות את מדיניות הזיכרון רק אם הידור של PMC
ליבנומה. זיקה למעבד נמחקת באמצעות sched_setaffinity (), ומדיניות הזיכרון היא
ניקה עם set_mempolicy().

DAG קבצים

Pegasus-mpi-cluster זרימות עבודה מתבטאות באמצעות פורמט פשוט מבוסס טקסט דומה ל
זה בשימוש קונדור DAGMan. יש רק שני סוגי רשומות מותרים בקובץ DAG: מְשִׁימָה
ו EDGE. מתעלמים מכל השורות הריקות ב-DAG (השורות עם כל התווים הלבנים),
כמו כל השורות שמתחילות ב-# (שים לב ש-# יכול להופיע רק בתחילת שורה,
לא באמצע).

הפורמט של א מְשִׁימָה השיא הוא:

מזהה "TASK" [אפשרויות...] בר הפעלה [טיעונים...]

איפה id הוא מזהה המשימה, אפשרויות היא רשימה של אפשרויות משימות, הפעלה הוא הנתיב
לקובץ ההפעלה או לסקריפט להפעלה, ו ויכוחים ... היא רשימה מופרדת ברווחים של
טיעונים להעביר למשימה. דוגמה היא:

משימה t01 -m 10 -c 2 /bin/program -a -b

דוגמה זו מציינת משימה t01 שדורש 10 MB זיכרון ו-2 מעבדים כדי לפעול
/bin/program עם הוויכוחים -a ו -b. אפשרויות המשימות הזמינות הן:

-m M, --בקשה-זיכרון M
כמות הזיכרון הנדרשת למשימה ב-MB. ברירת המחדל היא 0, כלומר זיכרון
אינו נחשב למשימה זו. ניתן להגדיר אפשרות זו עבור עבודה ב-DAX על ידי
ציון פרופיל pegasus::pmc_request_memory. (לִרְאוֹת מבוסס משאבים תזמון)

-c N, --request-cpus N
מספר המעבדים הנדרשים במשימה. ברירת המחדל היא 1, מה שמרמז שה
מספר החריצים במארח צריך להיות קטן או שווה למספר המעבדים הפיזיים
כדי להשתמש בכל החריצים. ניתן להגדיר אפשרות זו עבור עבודה ב-DAX על ידי
ציון פרופיל pegasus::pmc_request_cpus. (לִרְאוֹת מבוסס משאבים תזמון)

-t T, --מנסה T
מספר הפעמים לניסיון לבצע את המשימה לפני שנכשל לצמיתות. זה
מקבילה ברמת המשימה של --מנסה אפשרות שורת פקודה.

-p P, --עדיפות P
עדיפות המשימה. P צריך להיות מספר שלם. לערכים גדולים יותר יש עדיפות גבוהה יותר.
ברירת המחדל היא 0. העדיפויות הן פשוט רמזים ואינן קפדניות - אם משימה לא יכולה להיות
מותאם למשבצת זמינה (למשל עקב זמינות משאבים), אך בעדיפות נמוכה יותר
המשימה יכולה, ואז המשימה תידחה והמשימה בעדיפות נמוכה יותר תבוצע.
ניתן להגדיר אפשרות זו עבור עבודה ב-DAX על ידי ציון ה-pegasus::pmc_priority
פּרוֹפִיל.

-f VAR=קובץ, --pipe-forward VAR=קובץ
העבר I/O לקובץ קובץ שימוש בצינורות כדי לתקשר עם המשימה. הסביבה
משתנה VAR יוגדר לערך של מתאר קובץ עבור צינור שאליו
המשימה יכולה לכתוב כדי להכניס נתונים קובץ. לדוגמה, אם משימה מציינת: -f
FOO=/tmp/foo ואז משתנה הסביבה FOO עבור המשימה יוגדר למספר
(למשל 3) המייצג את הקובץ /tmp/foo. על מנת לפרט טיעון זה בא
Pegasus DAX אתה צריך להגדיר את פרופיל pegasus::pmc_arguments (שים לב שהערך של
pmc_arguments חייב להכיל את החלק "-f" של הארגומנט, כך שערך חוקי יהיה:
-f A=/tmp/a ). (לִרְאוֹת I / O
העברה)

-F SRC=DEST, --העבר קבצים SRC=DEST
העבר I/O לקובץ DEST מהקובץ SRC. כאשר המשימה מסתיימת, העובד
יקרא את הנתונים מ SRC ושלח אותו למאסטר שם זה ייכתב ל-
פילה DEST. לאחר SRC נקרא זה נמחק. על מנת לפרט טיעון זה בא
Pegasus DAX אתה צריך להגדיר את פרופיל pegasus::pmc_arguments. (לִרְאוֹת I / O העברה)

הפורמט של an EDGE השיא הוא:

ילד הורה "EDGE".

איפה הורה הוא המזהה של משימת האב, ו ילד הוא המזהה של משימת הילד. א
דוגמה EDGE השיא הוא:

EDGE t01 t02

זרימת עבודה פשוטה בצורת יהלום תיראה כך:

# יהלום.יום
משימה א /bin/echo "אני"
משימה ב /bin/echo "אני ב'"
משימה ג /bin/echo "אני C"
משימה ד /bin/echo "אני D"

EDGE AB
EDGE AC
EDGE BD
CD של EDGE

הצלה קבצים

סוגים רבים ושונים של שגיאות יכולים להתרחש בעת הפעלת DAG. אחת או יותר מהמשימות עשויות
נכשל, משימת ה-MPI עלולה להיגמר מזמן הקיר, Pegasus-mpi-cluster עלול לשבש (אנחנו מקווים
לא), המערכת עלולה לקרוס וכו' על מנת להבטיח שה-DAG לא צריך להיות
הופעל מחדש מההתחלה לאחר שגיאה, Pegasus-mpi-cluster יוצר קובץ הצלה
עבור כל זרימת עבודה.

קובץ ההצלה הוא קובץ טקסט פשוט המפרט את כל המשימות בזרימת העבודה
סיימו בהצלחה. קובץ זה מתעדכן בכל פעם שמשימה מסתיימת, ונשטף
מעת לעת כך שאם זרימת העבודה נכשלת והמשתמש מפעיל אותה מחדש, Pegasus-mpi-cluster
יכול לקבוע אילו משימות עדיין צריכות להתבצע. ככזה, קובץ ההצלה הוא סוג של
יומן עסקאות עבור זרימת העבודה.

קובץ ההצלה מכיל אפס רשומות DONE או יותר. הפורמט של רשומות אלה הוא:

"בוצע" *משימה*

איפה משימות הוא המזהה של המשימה שהסתיימה בהצלחה.

כברירת מחדל, קובצי הצלה מקבלים שם DAGNAME.rescue איפה DAGNAME הוא הנתיב לקלט
קובץ DAG. ניתן לשנות את שם הקובץ על ידי ציון ה- -r ויכוח.

PMC ו PEGASUS

שימוש PMC ל פגסוס המשימות אשכולות
PMC יכול לשמש כמעטפת לביצוע עבודות מקובצות בפגסוס. במצב זה
פגסוס מקבץ מספר משימות יחד ומגיש אותן כעבודה אחת מקובצת ל-a
מערכת מרחוק. לאחר מכן PMC מבצעת את המשימות הבודדות באשכול ומחזירה את
תוצאות.

ניתן לציין את PMC כמנהל המשימות עבור משרות מקובצות בפגסוס בשלוש דרכים:

1. גלובלי בקובץ המאפיינים

המשתמש יכול להגדיר מאפיין בקובץ המאפיינים שמוביל לכל האשכולות
עבודות של זרימת העבודה המבוצעות על ידי PMC. בקובץ המאפיינים של Pegasus ציין:

#קובץ נכסי PEGASUS
pegasus.clusterer.job.aggregator=mpiexec

בדוגמה לעיל, כל המשרות המקובצות בכל האתרים המרוחקים יושקו באמצעות
PMC כל עוד ערך הנכס אינו מוחלף בקטלוג האתר.

2. על ידי הגדרת מפתח הפרופיל "job.aggregator" בקטלוג האתר:


...
mpiexec


בדוגמה לעיל, כל העבודות המקובצות ב-siteX יבוצעו באמצעות
PMC כל עוד הערך אינו מוחלף בקטלוג הטרנספורמציה.

3. על ידי הגדרת מפתח הפרופיל "job.aggregator" בקטלוג הטרנספורמציה:

tr B {
site siteX {
pfn "/path/to/mytask"
קשת "x86"
OS "לינוקס"
הקלד "INSTALLED"
פרופיל pegasus "clusters.size" "3"
פרופיל pegasus "job.aggregator" "mpiexec"
}
}

בדוגמה שלמעלה, כל העבודות המקובצות עבור טרנספורמציה B ב-siteX יהיו
מבוצע באמצעות PMC.

בדרך כלל יש צורך להכניס ערך pegasus::mpiexec בקטלוג הטרנספורמציה שלך
המפרט א) את הנתיב ל-PMC באתר המרוחק וב) את פרופילי הגלובוס הרלוונטיים
כגון xcount, host_xcount ו-maxwalltime כדי לשלוט בגודל משימת ה-MPI. הערך הזה
ייראה כך:

tr pegasus::mpiexec {
site siteX {
pfn "/path/to/pegasus-mpi-cluster"
קשת "x86"
OS "לינוקס"
הקלד "INSTALLED"
פרופיל globus "maxwalltime" "240"
פרופיל globus "host_xcount" "1"
פרופיל globus "xcount" "32"
}
}

אם רשומת קטלוג טרנספורמציה זו לא צוינה, פגסוס תנסה ליצור א
נתיב ברירת המחדל על בסיס פרופיל הסביבה PEGASUS_HOME שצוין באתר
קטלוג לאתר המרוחק.

ניתן להשתמש ב-PMC גם עם אשכולות אופקיים וגם מבוססי תווית בפגסוס, אבל אנחנו
ממליצים להשתמש באשכולות מבוססת תווית כך שגרפים משנה שלמים של Pegasus DAX יכולים להיות
מקובצים בעבודת PMC אחת, במקום רק רמה אחת של זרימת העבודה.

פגסוס פרופילים ל PMC
ישנם מספר פרופילי פגסוס הממפים לאפשרויות משימות PMC:

pmc_request_memory
פרופיל זה משמש להגדרת המשימה --request-memory והוא מצויין בדרך כלל
ב-DAX או בקטלוג הטרנספורמציה.

pmc_request_cpus
מפתח זה משמש כדי להגדיר את אפשרות המשימה --request-cpus והוא מצויין בדרך כלל ב-
DAX או קטלוג טרנספורמציה.

pmc_priority
מפתח זה משמש כדי להגדיר את אפשרות המשימה --priority והוא מצויין בדרך כלל ב-
DAX.

פרופילים אלה משמשים את פגסוס בעת יצירת DAG הקלט של PMC כאשר PMC משמש כ-
מנהל משימות למשרות מקובצות בפגסוס.

ניתן לציין את הפרופילים ב-DAX כך:


-a 1 -b 2 -c 3
...
1024
4
10


דוגמה זו מציינת משימת PMC הדורשת 1GB של זיכרון ו-4 ליבות, ויש לה א
עדיפות של 10. זה מייצר משימה ב-PMC DAG שנראית כך:

משימה mytask_ID00000001 -m 1024 -c 4 -p 10 /path/to/mytask -a 1 -b 2 -c 3

שימוש PMC ל מה היא שלם פגסוס DAX
ניתן גם להגדיר את פגסוס להפעיל את כל זרימת העבודה כעבודת PMC אחת. בזה
מצב Pegasus יפיק PMC DAG יחיד עבור זרימת העבודה כולה וכן PBS
סקריפט שניתן להשתמש בו כדי לשלוח את זרימת העבודה.

בניגוד לשימוש ב-PMC ככלי אשכול משימות, במצב זה אין עבודות ב-
זרימת עבודה מבוצעת ללא PMC. כל זרימת העבודה, כולל עבודות עזר כגון
יצירת ספריות והעברת קבצים, מנוהלת על ידי PMC. אם Pegasus מוגדר בזה
במצב, אז אין צורך ב-DAGMan ו-Condor.

כדי להפעיל במצב PMC בלבד, הגדר את המאפיין "pegasus.code.generator" ל-"PMC" ב-Pegasus
קובץ מאפיינים:

pegasus.code.generator=PMC

על מנת להגיש את עבודת ה-PBS שהתקבלה, ייתכן שיהיה עליך לבצע שינויים בקובץ ה-.pbs
נוצר על ידי Pegasus כדי לגרום לזה לעבוד עם האשכול שלך. מצב זה הוא ניסיוני ו
לא נעשה שימוש נרחב.

יומן

כברירת מחדל, כל הודעות הרישום מודפסות ל-stderr. אם תגביר את הרישום באמצעות
-v אז אתה עלול להסתיים עם הרבה סטדרר שיועבר מהעובדים ל
אדון.

רמות היומן לפי סדר החומרה הן: FATAL, ERROR, WARN, INFO, DEBUG ו-TRACE.

רמת הרישום המוגדרת כברירת מחדל היא INFO. ניתן להגדיל את רמות הרישום באמצעות -v ו
ירד עם -q.

מְשִׁימָה STDIUM

כברירת מחדל, ה-stdout וה-stderr של המשימות יופנו ל-stdout של המאסטר ו
סטדרר. אתה יכול לשנות את הנתיב של קבצים אלה עם -o ו -e טיעונים. אתה יכול גם
אפשר קבצי stdio לכל משימה באמצעות --לכל משימה טַעֲנָה. שימו לב שאם לכל משימה
לא נעשה שימוש בקבצי stdio, אז ה-stdio של כל העובדים ימוזג לאוט אחד ואחד
קובץ שגיאה על ידי המאסטר בסוף, כך שקלט/פלט מעובדים שונים לא ישוזר,
אבל קלט/פלט מכל עובד יופיע בסדר שנוצר. שימו לב גם ש,
אם העבודה תיכשל מסיבה כלשהי, התפוקות לא ימוזגו, אלא יהיו
קובץ אחד עבור כל עובד בשם DAGFILE.out.X ו-DAGFILE.err.X, כאשר DAGFILE הוא הנתיב
לקלט DAG, ו X היא דרגת העובד.

HOST סקריפטים

סקריפט מארח הוא סקריפט מעטפת או קובץ הפעלה זה Pegasus-mpi-cluster מופעל על כל אחד
מארח ייחודי עליו הוא פועל. ניתן להשתמש בהם כדי להתחיל שירותי עזר, כגון
memcached, שהמשימות בזרימת עבודה דורשות.

סקריפטים מארח מוגדרים באמצעות ---host-script טיעון או ה PMC_HOST_SCRIPT
משתנה הסביבה.

סקריפט המארח מופעל מתי Pegasus-mpi-cluster מתחיל וחייב לצאת עם קוד יציאה
של 0 לפני שניתן לבצע משימות כלשהן. אם זה הסקריפט המארח מחזיר קוד יציאה שאינו אפס,
אז זרימת העבודה תבוטל. לסקריפט המארח ניתנות 60 שניות לבצע כל הגדרה שהיא
נדרש. אם הוא לא יוצא תוך 60 שניות, אות SIGALRM יימסר ל-
תהליך, שאם לא יטופל, יגרום להפסקת התהליך.

כשתהליך העבודה מסתיים, Pegasus-mpi-cluster יספק אות SIGTERM למארח
קבוצת התהליך של התסריט. כל תהליכי צאצא שנותרו פועלים על ידי הסקריפט המארח יקבל
אות זה אלא אם כן הם יצרו קבוצת תהליכים משלהם. אם נשארו תהליכים
כדי לקבל את האות הזה, אז הם יקבלו כמה שניות לצאת, ואז הם יהיו
שלח את SIGKILL. זהו המנגנון שבאמצעותו יכולים להיות תהליכים שהתחילו הסקריפט המארח
הודיעו על סיום זרימת העבודה.

מבוסס משאבים תזמון

למשאבי מחשוב בעלי ביצועים גבוהים יש לרוב יחס נמוך בין זיכרון למעבדים. באותו
זמן, למשימות זרימת עבודה יש ​​לרוב דרישות זיכרון גבוהות. לעתים קרובות, דרישות הזיכרון
של משימת זרימת עבודה עולה על כמות הזיכרון הזמינה לכל מעבד במארח נתון. כ
כתוצאה מכך, ייתכן שיהיה צורך להשבית חלק מהמעבדים כדי לפנות מספיק זיכרון להפעלה
את המשימות. באופן דומה, לקודים רבים יש תמיכה במארחים מרובי ליבות. במקרה כזה זה כן
הכרחי ליעילות כדי להבטיח את מספר הליבות הנדרשות על ידי המשימות הפועלות
על מארח אל תחרוג ממספר הליבות הזמינות באותו מארח.

על מנת להפוך את התהליך הזה ליעיל יותר, Pegasus-mpi-cluster תומך מבוסס משאבים
תזמון. בתזמון מבוסס משאבים המשימות בזרימת העבודה יכולות לציין כמה
זיכרון וכמה מעבדים הם דורשים, ו Pegasus-mpi-cluster יתזמן אותם כך
המשימות הפועלות על מארח נתון אינן עולות על כמות הזיכרון הפיזי והמעבדים
זמין. זה מאפשר Pegasus-mpi-cluster כדי לנצל את כל המעבדים הזמינים
כאשר דרישת הזיכרון של המשימות נמוכה, אך גם להשבית חלק מהמעבדים כאשר המשימות
דרישת הזיכרון גבוהה יותר. זה גם מאפשר זרימות עבודה עם תערובת של ליבה אחת ו
משימות מרובות ליבות לביצוע במאגר הטרוגני.

אם אין מארחים זמינים שיש להם מספיק זיכרון ומעבדים לביצוע אחד מה
משימות בזרימת עבודה, ואז זרימת העבודה מבוטלת.

זכרון
משתמשים יכולים לציין גם את כמות הזיכרון הנדרשת למשימה וגם את כמות הזיכרון
זמין לכל מארח. אם כמות הזיכרון הנדרשת למשימה כלשהי חורגת מהזמין
זיכרון של כל המארחים, אז זרימת העבודה תבוטל. כברירת מחדל, הזיכרון המארח הוא
נקבע באופן אוטומטי, אולם המשתמש יכול לציין --מארח-זיכרון "לשקר" לו
Pegasus-mpi-cluster. כמות הזיכרון הנדרשת עבור כל משימה מצוינת ב-DAG
באמצעות -m/--בקשה-זיכרון טיעון (ראה DAG קבצים).

מעבדים
משתמשים יכולים לציין את מספר המעבדים הנדרשים למשימה, ואת המספר הכולל של מעבדים
זמין בכל מארח. אם מספר המעבדים הנדרשים במשימה חורג מהזמין
מעבדים בכל המארחים, אז זרימת העבודה תבוטל. כברירת מחדל, מספר המעבדים ב-a
המארח נקבע באופן אוטומטי, אך המשתמש יכול לציין --מארח-מעבד להגזים או
תת-מינוי למארח. מספר המעבדים הנדרשים עבור כל משימה מצוין ב-
DAG באמצעות -c/--request-cpus טיעון (ראה DAG קבצים).

I / O העברה

בזרימות עבודה שיש בהן הרבה משימות קטנות, נפוץ ה-I/O שנכתב על ידי המשימות הללו
להיות מאוד קטן. לדוגמה, זרימת עבודה עשויה לכלול 10,000 משימות שכל אחת כותבת כמה KB
של מידע. בדרך כלל כל משימה כותבת לקובץ משלה, וכתוצאה מכך 10,000 קבצים. ה-I/O הזה
דפוס הוא מאוד לא יעיל בהרבה מערכות קבצים מקבילות מכיוון שהוא דורש את הקובץ
מערכת לטיפול במספר רב של פעולות מטא נתונים, שהן צוואר בקבוק ברבים
מערכות קבצים מקבילות.

אחת הדרכים להתמודד עם בעיה זו היא לכתוב את כל 10,000 המשימות לקובץ בודד. ה
הבעיה עם גישה זו היא שהיא מחייבת את המשימות הללו לסנכרן את הגישה אליהן
הקובץ באמצעות מנעולי POSIX או מנגנון אי הכללה הדדי אחר. אחרת, הכותבים
ממשימות שונות עשויות להיות משולבות בסדר שרירותי, וכתוצאה מכך נתונים בלתי שמישים.

על מנת לטפל במקרה השימוש הזה, מיישמת PMC תכונה שאנו קוראים לה "העברת קלט/פלט".
העברת קלט/פלט מאפשרת לכל משימה בעבודת PMC לכתוב נתונים למספר שרירותי של
קבצים משותפים בצורה בטוחה. זה עושה זאת על ידי כך שתהליכי עובד PMC אוספים נתונים
נכתב על ידי המשימה ושלח אותה דרך הרשת המהירה באמצעות הודעות MPI אל
תהליך המאסטר של PMC, שבו הוא נכתב לקובץ הפלט. על ידי תהליך אחד (ה
PMC master process) לכתוב לקובץ את כל ה-I/O ממשימות מקבילות רבות יכול להיות
מסונכרן ונכתב אל הקבצים בצורה בטוחה.

ישנן שתי דרכים שונות להשתמש בהעברת קלט/פלט ב-PMC: צינורות וקבצים. צינורות הם יותר
יעיל, אבל קבצים קלים יותר לשימוש.

I / O העברה באמצעות צינורות
העברת I/O עם צינורות פועלת בכך שתהליכי עובד PMC אוספים נתונים מכל משימה
באמצעות צינורות UNIX. גישה זו יעילה יותר מהגישה מבוססת קבצים, אבל היא
דורש לשנות את הקוד של המשימה כך שהמשימה תכתוב לצינור במקום
קובץ רגיל.

כדי להשתמש בהעברת קלט/פלט, משימת PMC רק צריכה לציין את -f/--pipe-forward
ארגומנט לציון שם הקובץ שאליו יש להעביר נתונים, ואת השם של
משתנה סביבה שדרכו תהליך העבודה של PMC יכול ליידע אותו על הקובץ
מתאר עבור הצינור.

לדוגמה, אם יש משימה "mytask" שצריך להעביר נתונים לשני קבצים:
"myfile.a" ו-"myfile.b", זה ייראה כך:

משימה mytask -f A=/tmp/myfile.a -f B=/tmp/myfile.b /bin/mytask

כאשר תהליך /bin/mytask מתחיל יהיו לו שני משתנים בסביבתו: "A=3"
ו-"B=4", למשל. הערך של משתנים אלה הוא מספר מתאר הקובץ של
קבצים מתאימים. במקרה זה, אם המשימה רוצה לכתוב ל-"/tmp/myfile.a", היא מקבלת
הערך של משתנה הסביבה "A", וקורא לכתוב() על מספר המתאר הזה. ב-C
הקוד לזה נראה כך:

char *A = getenv("A");
int fd = atoi(A);
char *message = "שלום, עולם\n";
כתוב (fd, הודעה, strlen(הוֹדָעָה));

בשפות תכנות מסוימות לא ניתן לכתוב ישירות לקובץ מתאר.
Fortran, למשל, מתייחס לקבצים לפי מספר יחידה במקום להשתמש בתיאורי קבצים. ב
שפות אלה אתה יכול לקשר פונקציות CI/O לתוך הבינארי שלך ולהתקשר אליהם
שגרות שנכתבו בשפה האחרת, או שאתה יכול לפתוח קובץ מיוחד בלינוקס / proc
מערכת קבצים כדי לקבל ידית נוספת לצינור שאליו ברצונך לגשת. עבור האחרונים, הקובץ
אתה צריך לפתוח הוא "/proc/self/fd/NUMBER" כאשר NUMBER הוא מספר מתאר הקובץ שאתה
קיבל ממשתנה הסביבה. עבור הדוגמה שלמעלה, הצינור עבור myfile.a
(משתנה סביבה A) הוא "/proc/self/fd/3".

אם אתה משתמש פגסוס-קיקסטארט, וזה כנראה המקרה אם אתה משתמש ב-PMC עבור א
זרימת העבודה של Pegasus, אז יש טריק שאתה יכול לעשות כדי להימנע משינוי הקוד שלך. אתה משתמש
מה היא / proc מערכת הקבצים, כמתואר לעיל, אבל אתה נותן ל-pegasus-kickstart לטפל בנתיב
בְּנִיָה. לדוגמה, אם לאפליקציה שלך יש ארגומנט, -o, המאפשר לך
ציין את קובץ הפלט ואז תוכל לכתוב את המשימה שלך כך:

משימה mytask -f A=/tmp/myfile.a /bin/pegasus-kickstart /bin/mytask -o /proc/self/fd/$A

במקרה זה, pegasus-kickstart יחליף את ה-$A בטיעוני היישום שלך ב-
מספר מתאר הקובץ הרצוי. הקוד שלך יכול לפתוח את הנתיב הזה כרגיל, לכתוב לו, ו
ואז סגור אותו כאילו היה קובץ רגיל.

I / O העברה באמצעות קבצים
העברת קלט/פלט עם קבצים פועלת בכך שמשימות כותבות נתונים בקבצים בדיסק המקומי.
תהליך העבודה של PMC קורא קבצים אלה ומעביר את הנתונים למאסטר היכן שהוא יכול
להיכתב לקובץ הפלט הרצוי. גישה זו עשויה להיות הרבה פחות יעילה מאשר שימוש
צינורות מכיוון שהיא מערבת את מערכת הקבצים, שיש לה יותר תקורה מצינור.

ניתן להפעיל העברת קבצים על ידי מתן ה- -F/--forward file טיעון למשימה.

הנה דוגמה:

TASK mytask -F /tmp/foo.0=/scratch/foo /bin/mytask -o /tmp/foo.0

במקרה זה, תהליך העבודה יצפה למצוא את הקובץ /tmp/foo.0 כאשר mytask יוצא
בְּהַצלָחָה. הוא קורא את הנתונים מאותו קובץ ושולח אותם למאסטר שיש לכתוב אליו
הסוף של /scratch/foo. לאחר קריאת /tmp/foo.0 הוא יימחק על ידי העובד
התהליך.

גישה זו פועלת בצורה הטובה ביותר במערכות שבהן הדיסק המקומי הוא מערכת קבצים RAM כגון Cray
מכונות XT. לחלופין, המשימה יכולה להשתמש / dev / shm על אשכול לינוקס רגיל. אולי זה
גם לעבוד ביעילות יחסית על דיסק מקומי אם המטמון של מערכת הקבצים מסוגל לכך
לספוג את כל הקריאה והכתיבה.

I / O העברה אזהרות
בעת שימוש בהעברת קלט/פלט חשוב לקחת בחשבון כמה אזהרות.

ראשית, אם עבודת ה-PMC נכשלת מסיבה כלשהי (כולל כאשר זרימת העבודה הופסקה עבור
המפר --max-wall-time), אז הקבצים המכילים קלט/פלט מועבר עלולים להיות פגומים. הֵם
יכול לכלול חלקית רשום, כלומר רק חלק מהקלט/פלט ממשימה אחת או יותר היה
כתובים, והם יכולים לכלול לשכפל רשום, כלומר ה-I/O נכתב, אבל ה-
עבודת PMC נכשלה לפני שניתן היה לסמן את המשימה כמוצלחת, וזרימת העבודה הייתה
הופעל מחדש מאוחר יותר. אנחנו לא מתחייבים לגבי התוכן של קבצי הנתונים במקרה זה.
זה תלוי בקוד שקורא את הקבצים כדי א) לזהות וב) להתאושש מבעיות כאלה.
כדי להסיר כפילויות, הרשומות צריכות לכלול מזהה ייחודי, וכדי להסיר
חלקים הרשומות צריכות לכלול סכום ביקורת.

שנית, אתה לא צריך להשתמש בהעברת I/O אם המשימה שלך עומדת לכתוב הרבה נתונים
הקובץ. מכיוון שעובד ה-PMC קורא נתונים מהצינור/קובץ לזיכרון ושולח
זה בהודעת MPI, אם תכתוב יותר מדי, תהליך העבודה יריץ את המערכת
מחוץ לזיכרון. כמו כן, כל הנתונים צריכים להתאים להודעת MPI אחת. בהובלת צינורות
אין הגבלה קשה על הגודל, אבל בהעברת קבצים המגבלה היא 1MB. אנחנו לא
השוואת הביצועים ב-I/O גדול, אבל כנראה שכל דבר גדול מ-1MB בערך
יותר מדי. בכל מקרה, אם הנתונים שלך גדולים מ-1MB, כנראה שהעברת קלט/פלט לא יקרה
ממילא יש יתרון רב בביצועים.

שלישית, ה-I/O לא נכתב לקובץ אם המשימה מחזירה קוד יציאה שאינו אפס. אָנוּ
נניח שאם המשימה נכשלה אתה לא רוצה את הנתונים שהיא הפיקה.

רביעית, הנתונים ממשימות שונות אינם משולבים. כל הנתונים שנכתבו על ידי א
משימה נתונה תופיע ברצף בקובץ הפלט. שים לב שאתה עדיין יכול לקבל
עם זאת, רשומות חלקיות, אם יופיעו נתונים כלשהם ממשימה, הם לעולם לא יחולקו ביניהם
טווחים לא סמוכים בקובץ הפלט. אם יש לך 3 משימות שכותבות: "אני משימה" אתה
יכול לקבל:

אני משימה אני משימה אני משימה

you

אני משימה אני משימה

אבל לא:

אני משימה אני אני אני משימה משימה

חמישית, נתונים ממשימות שונות מופיעים בסדר שרירותי בקובץ הפלט. זה תלוי
באיזה סדר בוצעו המשימות על ידי PMC, מה שעלול להיות שרירותי אם אין
תלות בין המשימות. הנתונים שנכתבים צריכים להכיל מספיק מידע
שאתה יכול לקבוע איזו משימה הפיקה אותה אם אתה זקוק לכך. PMC לא
הוסף כותרות או טריילרים לנתונים.

שישית, משימה תסומן כמוצלחת רק אם כל הקלט/פלט שלה בוצע בהצלחה
כתוב. אם זרימת העבודה הושלמה בהצלחה, מובטח שהקלט/פלט היה
כתוב.

שביעית, אם המאסטר אינו מסוגל לכתוב לקובץ הפלט מכל סיבה שהיא (למשל
מאסטר מנסה לכתוב את ה-I/O לקובץ היעד, אך הקריאה write() מחזירה an
שגיאה) אז המשימה מסומנת ככשלה גם אם המשימה הפיקה קוד יציאה שאינו אפס. ב
במילים אחרות, אתה עשוי לקבל שיא קיקסטארט שאינו אפס גם כאשר PMC מסמן שהמשימה נכשלה.

שמינית, הצינורות הם לכתיבה בלבד. אם אתה צריך לקרוא ולכתוב נתונים מהקובץ אתה
צריך להשתמש בהעברת קבצים ולא בהעברת צינורות.

תשיעית, כל הקבצים נפתחים על ידי המאסטר במצב הוספה. זאת כדי שאם זרימת העבודה
נכשל ויש להפעיל מחדש, או אם משימה נכשלת ונוסתה מחדש, הנתונים שהיו
שנכתב בעבר אינו אבוד. PMC לעולם לא מקצץ את הקבצים. זו אחת הסיבות
מדוע אתה יכול לקבל רשומות חלקיות ורשומות כפולות בקובץ הפלט.

לבסוף, בהעברת קבצים קובץ הפלט מוסר כאשר המשימה יוצאת. אתה לא יכול
הסתמכו על כך שהקובץ יהיה שם כשהמשימה הבאה תרוץ גם אם תכתוב אותו לקובץ משותף
מערכת.

MISC

משאב שימוש
בתום הפעלת זרימת העבודה, המאסטר ידווח על ניצול המשאב של ה-
עבודה. זה נעשה על ידי חיבור של כל זמני הריצה של כל המשימות שבוצעו (כולל
משימות שנכשלו) וחלוקה בזמן הקיר הכולל של העבודה פעמים N, כאשר N הוא שניהם
המספר הכולל של תהליכים כולל המאסטר, והמספר הכולל של עובדים. שני אלו
ערכי ניצול משאבים מסופקים כדי שמשתמשים יוכלו לקבל מושג כיצד
ביעילות הם עושים שימוש במשאבים שהם הקצו. ניצול משאבים נמוך
ערכים מצביעים על כך שהמשתמש צריך להשתמש בפחות ליבות, ובזמן קיר ארוך יותר, בריצות עתידיות,
בעוד ערכי ניצול משאבים גבוהים מצביעים על כך שהמשתמש יכול להשתמש ליותר ליבות עבור
ריצות עתידיות וקבל זמן קיר קצר יותר.

ידוע סוגיות

מזלג() ו exec ()
על מנת שתהליכי העבודה יתחילו משימות בצומת המחשוב, צמתי החישוב
חייב לתמוך ב מזלג() ו exec () שיחות מערכת. אם מכונת היעד שלך פועלת א
מערכת הפעלה מופשטת בצמתי המחשוב שאינה תומכת בקריאות מערכת אלו, אם כן
Pegasus-mpi-cluster לא יעבוד.

CPU נוֹהָג
יישומי MPI רבים עוברים אופטימיזציה כך שהודעות שולחות ומקבלות אינן עסוקות בהמתנה
(כלומר, הם מסתובבים/מסקרים הודעה שנשלחת או מקבלת במקום לישון). הנימוק הוא
ששינה מוסיפה תקורה, ומכיוון שמערכות HPC רבות משתמשות בשיתוף שטח על ייעודיים
חומרה, אין תהליכים אחרים שמתחרים, אז ספינינג במקום שינה יכול
לייצר ביצועים טובים יותר. בהטמעות אלו תהליכי MPI יפעלו ב-100% CPU
שימוש גם כשהם רק מחכים להודעה. זו בעיה גדולה עבור ריבוי ליבות
משימות ב Pegasus-mpi-cluster כי חריצי סרק צורכים משאבי CPU. כדי לפתור
הבעיה הזו Pegasus-mpi-cluster מעבד שינה לתקופה קצרה בין בדיקה עבור
הודעות ממתינות. זה מקטין את העומס באופן משמעותי, אבל גורם לעיכוב קצר ב
קבלת הודעות. אם אתה משתמש ביישום MPI שישן על הודעה שלח ו
קבל במקום המתנה עסוקה, אז אתה יכול להשבית את השינה על ידי ציון
--אין-שינה-ב-rev אוֹפְּצִיָה. שימו לב שהמאסטר תמיד יישן אם --max-wall-time is
צוין כי אין דרך להפריע לשיחה חוסמת ב-MPI או לתפוגה אחרת
(למשל SIGALRM לא גורם ל-MPI_Recv להחזיר EINTR).

הסביבה וריאציות

משתני הסביבה להלן הם כינויים עבור אפשרויות שורת הפקודה. אם הסביבה
המשתנה קיים, אז הוא משמש כברירת מחדל עבור האפשרות המשויכת. אם שניהם
נוכח, אז נעשה שימוש באפשרות שורת הפקודה.

PMC_HOST_SCRIPT
כינוי עבור ה ---host-script אוֹפְּצִיָה.

PMC_HOST_MEMORY
כינוי עבור ה --מארח-זיכרון אוֹפְּצִיָה.

PMC_HOST_CPUS
כינוי עבור ה --מארח-מעבד אוֹפְּצִיָה.

PMC_MAX_WALL_TIME
כינוי עבור ה --max-wall-time אוֹפְּצִיָה.

השתמש ב-pegasus-mpi-cluster באינטרנט באמצעות שירותי onworks.net