במסמך הזה מוסברות הודעות שגיאה נפוצות שמופיעות כשיוצרים אשכולות, ומופיעים בו טיפים לפתרון בעיות שקשורות ליצירת אשכולות.
הודעות שגיאה נפוצות שמופיעות כשיוצרים אשכול
למשתמש אין הרשאה לפעול כחשבון שירות
הגורם: לחשבון המשתמש שמנסה ליצור את אשכול Dataproc אין את ההרשאות הנדרשות לשימוש בחשבון השירות שצוין. משתמשי Dataproc צריכים לקבל את ההרשאה
ActAsבחשבון השירות כדי לפרוס משאבי Dataproc. ההרשאה הזו כלולה בתפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) (ראו תפקידים ב-Dataproc).פתרון: מאתרים את המשתמש או חשבון השירות שמנסה ליצור את אשכול Dataproc. מעניקים לחשבון המשתמש את התפקיד 'משתמש בחשבון שירות' (
roles/iam.serviceAccountUser) בחשבון השירות שהאשכול מוגדר להשתמש בו (בדרך כלל חשבון השירות של המכונה הווירטואלית של Dataproc).תם הזמן הקצוב לתפוגה של הפעולה: רק 0 מתוך 2 הצמתים הנדרשים של נתוני המינימום או מנהלי הצמתים פועלים.
הגורם: צומת הבקרה לא יכול ליצור את האשכול כי הוא לא יכול לתקשר עם צמתי העובדים.
פתרון:
- בדיקת אזהרות לגבי כללי חומת האש
- מוודאים שכללי חומת האש הנכונים מוגדרים. מידע נוסף זמין במאמר סקירה כללית של כללי ברירת המחדל של חומת האש ב-Dataproc.
- מבצעים בדיקת קישוריות במסוף Google Cloud כדי לקבוע מה חוסם את התקשורת בין הצמתים של הבקר והעובד.
נדרשת הרשאה
compute.subnetworks.useעבורprojects/{projectId}/regions/{region}/subnetworks/{subnetwork}הגורם: השגיאה הזו יכולה להתרחש כשמנסים להגדיר אשכול Dataproc באמצעות רשת VPC בפרויקט אחר, ולחשבון השירות של סוכן השירות של Dataproc אין את ההרשאות הנדרשות בפרויקט ה-VPC המשותף שמארח את הרשת.
פתרון: פועלים לפי השלבים שמפורטים במאמר בנושא יצירת אשכול שמשתמש ברשת VPC בפרויקט אחר.
באזור
projects/zones/{zone}אין מספיק משאבים זמינים כדי למלא את הבקשה(resource type:compute)הסיבה: לאזור שבו משתמשים כדי ליצור את האשכול אין מספיק משאבים.
פתרון:
- משתמשים בתכונה בחירת תחום אוטומטית (Auto Zone) של Dataproc כדי ליצור את האשכול בכל אחד מהאזורים עם משאבים זמינים.
- יוצרים את האשכול באזור אחר.
שגיאות של חריגה מהמכסה
מכסת CPUS/CPUS_ALL_REGIONS לא מספיקה
מכסת DISKS_TOTAL_GB לא מספיקה
מכסת IN_USE_ADDRESSES לא מספיקההסיבה: הבקשה שלך למעבד, לדיסק או לכתובת IP חורגת מהמכסה הזמינה.
פתרון: שולחים בקשה להגדלת המכסה מGoogle Cloud מסוף.
פעולת האתחול נכשלה
הסיבה: פעולת האתחול שסופקה במהלך יצירת האשכול נכשלה בהתקנה.
פתרון:
- כאן אפשר לקרוא על שיקולים והנחיות לגבי פעולות אתחול.
- בודקים את יומני הפלט. בהודעת השגיאה אמור להופיע קישור ליומנים ב-Cloud Storage.
ההפעלה של הצומת
CLUSTER-NAME-mנכשלה. … See output in:<gs://PATH_TO_STARTUP_SCRIPT_OUTPUT>הסיבה: לא ניתן לאתחל את צומת הבקרה של אשכול Dataproc.
פתרון:
- בודקים את יומני הפלט של סקריפט לטעינה בזמן ההפעלה שמפורטים בהודעת השגיאה (
gs://PATH_TO_STARTUP_SCRIPT_OUTPUT) ומוודאים מה הסיבה לכך שהאתחול של הצומת נכשל. - הסיבות יכולות להיות בעיות בהגדרת הרשת של אשכול Dataproc והתקנה שנכשלה של יחסי תלות בחבילת Python.
- אם הבעיה לא נפתרה אחרי שבדקתם את היומנים של סקריפט ההפעלה, תקנתם בעיות בצד המשתמש וניסיתם שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff), פנו אל התמיכה של Google Cloud.
- בודקים את יומני הפלט של סקריפט לטעינה בזמן ההפעלה שמפורטים בהודעת השגיאה (
יצירת האשכול נכשלה: אין יותר מקום בטווח כתובות ה-IP
הסיבה: מרחב כתובות ה-IP שנדרש להקצאת צמתים של האשכול המבוקש לא זמין.
פתרון:
- ליצור אשכול עם פחות צמתים של עובדים, אבל עם סוג מכונה גדול יותר.
- יוצרים אשכול ברשת משנה או ברשת אחרת.
- כדי לפנות מקום לכתובות IP, צריך לצמצם את השימוש ברשת.
- מחכים עד שיהיה מספיק מרחב כתובות IP ברשת.
הודעת שגיאה בסקריפט ההפעלה: למאגר REPO_NAME אין יותר קובץ Release
הסיבה: מאגר ה-backports של Debian oldstable נמחק.
פתרון:
מוסיפים את הקוד הבא לפני הקוד שמריץ את
apt-getבסקריפט האתחול.oldstable=$(curl -s https://deb.debian.org/debian/dists/oldstable/Release | awk '/^Codename/ {print $2}'); stable=$(curl -s https://deb.debian.org/debian/dists/stable/Release | awk '/^Codename/ {print $2}'); matched_files="$(grep -rsil '\-backports' /etc/apt/sources.list*)" if [[ -n "$matched_files" ]]; then for filename in "$matched_files"; do grep -e "$oldstable-backports" -e "$stable-backports" "$filename" || \ sed -i -e 's/^.*-backports.*$//' "$filename" done fiהזמן הקצוב לתפוגה של ההמתנה לדיווח של מופע
DATAPROC_CLUSTER_VM_NAMEהסתיים או לא ניתן להגיע לרשת:dataproccontrol-REGION.googleapis.comהסיבה: הודעות השגיאה האלה מצביעות על כך שהגדרת הרשת של אשכול Dataproc לא הושלמה: יכול להיות שחסר מסלול לשער האינטרנט שמוגדר כברירת מחדל או כללי חומת אש.
פתרון:
כדי לפתור את הבעיה, אפשר ליצור את בדיקות הקישוריות הבאות:
- יצירת בדיקת קישוריות בין שתי מכונות וירטואליות של אשכול Dataproc. תוצאות הבדיקה הזו יעזרו לכם להבין אם כללי חומת האש של הרשת שלכם לגבי תעבורת נתונים נכנסת או יוצאת חלים על המכונות הווירטואליות של האשכול בצורה נכונה.
- יוצרים בדיקת קישוריות בין מכונה וירטואלית באשכול Dataproc לבין כתובת IP של Dataproc Control API. כדי לקבל את כתובת ה-IP הנוכחית של Dataproc Control API, משתמשים בפקודה הבאה:
dig dataproccontrol-REGION.googleapis.com A
משתמשים באחת מכתובות ה-IPv4 בקטע התשובה של הפלט.
תוצאת בדיקת הקישוריות תעזור לכם להבין אם המסלול אל שער האינטרנט שמוגדר כברירת מחדל וחומת האש שמאפשרת יציאה מוגדרים בצורה נכונה.
על סמך התוצאות של בדיקות הקישוריות:
- מוסיפים נתיב לאינטרנט לרשת ה-VPC של האשכול:
0.0.0.0/0ל-IPv4 ו- ::/0ל-IPv6 עם --next-hop-gateway=default-internet-gateway. - מוסיפים כללים לחומת האש לצורך בקרת גישה.
שגיאה בגלל עדכון
הסיבה: האשכול קיבל משימה שנשלחה לשירות Dataproc, אבל לא הייתה אפשרות להגדיל או להקטין את גודל האשכול באופן ידני או באמצעות התאמה אוטומטית לעומס. גם הגדרת אשכול לא סטנדרטית יכולה לגרום לשגיאה הזו.
פתרון:
איפוס האשכול: פותחים כרטיס תמיכה, כוללים קובץ tar של אבחון ומבקשים לאפס את האשכול למצב RUNNING.
אשכול חדש: יוצרים מחדש את האשכול עם אותה הגדרה. הפתרון הזה יכול להיות מהיר יותר מאיפוס שמתבצע על ידי צוות התמיכה.
טיפים לפתרון בעיות באשכול
בקטע הזה מפורטות הנחיות נוספות לפתרון בעיות נפוצות שיכולות למנוע יצירה של אשכולות Dataproc.
כשקורה כשל בהקצאת משאבים של אשכול Dataproc, לרוב מוצגת הודעת שגיאה כללית או שהסטטוס שמוצג הוא PENDING או PROVISIONING לפני הכשל. כדי לאבחן ולפתור בעיות שגורמות לכשל באשכול, צריך לבדוק את יומני האשכול ולהעריך נקודות כשל נפוצות.
תסמינים נפוצים
אלה תסמינים נפוצים שקשורים לכשלים ביצירת אשכולות:
- סטטוס האשכול נשאר
PENDINGאוPROVISIONINGלמשך תקופה ממושכת. - האשכול עובר למצב
ERROR. - שגיאות כלליות ב-API במהלך יצירת האשכול, כמו
Operation timed out. הודעות שגיאה שמופיעות ביומן או בתגובת ה-API, כמו:
-
RESOURCE_EXHAUSTED: קשורות למכסות של CPU, דיסק או כתובת IP Instance failed to startPermission deniedUnable to connect to service_name.googleapis.comאוCould not reach required Google APIsConnection refusedאוnetwork unreachable- שגיאות שקשורות לכשל בפעולות אתחול, כמו שגיאות בהרצת סקריפט וקובץ שלא נמצא.
-
בדיקת יומני האשכול
שלב חשוב בתהליך אבחון כשלים ביצירת אשכולות הוא בדיקת יומני האשכולות המפורטים שזמינים ב-Cloud Logging.
- נכנסים לדף Logs Explorer: פותחים את Logs Explorer במסוף Google Cloud .
- סינון של אשכולות Dataproc:
- בתפריט הנפתח משאב, בוחרים באפשרות
Cloud Dataproc Cluster. - מזינים את
cluster_nameואתproject_id. אפשר גם לסנן לפיlocation(אזור).
- בתפריט הנפתח משאב, בוחרים באפשרות
- בדיקת רשומות ביומן:
- חפשו הודעות ברמה
ERRORאוWARNINGשמופיעות בסמוך לזמן שבו נכשלה יצירת האשכול. - כדאי לשים לב ליומנים מרכיבי
master-startup,worker-startupו-agentכדי לקבל תובנות לגבי בעיות ברמת מכונת ה-VM או בסוכן Dataproc. - כדי לקבל תובנות לגבי בעיות בזמן האתחול של מכונת ה-VM, מסננים את היומנים לפי
resource.type="gce_instance"ומחפשים הודעות משמות המופעים שמשויכים לצמתי האשכול, כמוCLUSTER_NAME-mאוCLUSTER_NAME-w-0. יומני מסוף סדרתי יכולים לחשוף בעיות בהגדרת הרשת, בעיות בדיסק וכשלים בסקריפטים שמתרחשים בשלב מוקדם במחזור החיים של מכונת ה-VM.
- חפשו הודעות ברמה
סיבות נפוצות לכשל באשכול וטיפים לפתרון בעיות
בקטע הזה מפורטות סיבות נפוצות לכך שיצירת אשכול Dataproc נכשלת, ומופיעים בו טיפים לפתרון בעיות שיעזרו לכם לפתור בעיות שקשורות לאשכולות.
אין מספיק הרשאות IAM
חשבון השירות של המכונה הווירטואלית שבו משתמש אשכול Dataproc צריך לכלול תפקידי IAM מתאימים כדי להקצות מכונות של Compute Engine, לגשת לקטגוריות של Cloud Storage, לכתוב יומנים ולקיים אינטראקציה עם שירותים אחרים של Google Cloud .
- תפקיד Worker נדרש: מוודאים שלחשבון השירות של מכונת ה-VM יש את התפקיד Dataproc Worker (
roles/dataproc.worker). התפקיד הזה כולל את ההרשאות המינימליות שנדרשות ל-Dataproc כדי לנהל משאבי אשכול. - הרשאות גישה לנתונים: אם העבודות קוראות מ-Cloud Storage או מ-BigQuery או כותבות לתוכם, לחשבון השירות צריכים להיות תפקידים שקשורים לכך, כמו
Storage Object Viewer,Storage Object CreatorאוStorage Object Adminל-Cloud Storage, אוBigQuery Data ViewerאוBigQuery Editorל-BigQuery. - הרשאות רישום ביומן: לחשבון השירות צריך להיות תפקיד עם ההרשאות הנדרשות לכתיבת יומנים ב-Cloud Logging, כמו התפקיד
Logging Writer.
טיפים לפתרון בעיות:
זיהוי חשבון השירות: קובעים את חשבון השירות של המכונה הווירטואלית שהאשכול מוגדר להשתמש בו. אם לא מציינים חשבון שירות, ברירת המחדל היא חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.
בודקים את התפקידים ב-IAM: במסוף Google Cloud , עוברים לדף IAM & Admin > IAM, מוצאים את חשבון השירות של מכונת ה-VM באשכול ומוודאים שיש לו את התפקידים הנדרשים לפעולות באשכול. מעניקים את התפקידים החסרים.
חריגה ממכסות משאבים
אשכולות Dataproc צורכים משאבים מ-Compute Engine ומ Google Cloud שירותים אחרים. חריגה מהמכסות של הפרויקט או של האזור עלולה לגרום לכשלים ביצירת אשכולות.
- מכסות Dataproc נפוצות שכדאי לבדוק:
CPUs(אזורי)DISKS_TOTAL_GB(אזורי)-
IN_USE_ADDRESSES(אזוריות לכתובות IP פנימיות, גלובליות לכתובות IP חיצוניות) - מכסות של Dataproc API, כמו
ClusterOperationRequestsPerMinutePerProjectPerRegion
טיפים לפתרון בעיות:
- בדיקת מכסות: נכנסים לדף IAM & Admin > IAM במסוף Google Cloud . מסננים את העמודה 'שירות' לפי הערכים 'Compute Engine API' ו-'Dataproc API'.
- בדיקת השימוש לעומת המגבלה: זיהוי מכסות שהגיעו למגבלות או מתקרבות אליהן.
- במקרה הצורך, מבקשים להגדיל את המכסה.
בעיות בהגדרת הרשת
בעיות בהגדרת הרשת, כמו הגדרה שגויה של רשת VPC, רשת משנה, חומת אש או DNS, הן גורם נפוץ לבעיות ביצירת אשכולות. מופעי האשכול צריכים להיות מסוגלים לתקשר זה עם זה ועם Google APIs.
- רשת VPC ותת-רשת:
- מוודאים שרשת ה-VPC והרשת המשנית של האשכול קיימות ומוגדרות בצורה נכונה.
- מוודאים שלרשת המשנה יש טווח מספיק של כתובות IP זמינות.
- גישה פרטית ל-Google (PGA): אם למכונות הווירטואליות באשכול יש כתובות IP פנימיות והן צריכות להגיע לממשקי Google API עבור Cloud Storage, Cloud Logging ופעולות אחרות, צריך לוודא שגישה פרטית ל-Google מופעלת ברשת המשנה. כברירת מחדל, מכונות וירטואליות (VM) באשכולות Dataproc שנוצרו עם גרסאות של קובצי אימג' מגרסה 2.2 ומעלה מוקצות עם כתובות IP פנימיות בלבד, כשהגישה הפרטית ל-Google מופעלת ברשת המשנה האזורית של האשכול.
- Private Service Connect (PSC): אם אתם משתמשים ב-Private Service Connect כדי לגשת ל-Google APIs, ודאו שנקודות הקצה (endpoints) של Private Service Connect שנדרשות מוגדרות בצורה נכונה עבור Google APIs ש-Dataproc תלוי בהם, כמו
dataproc.googleapis.com,storage.googleapis.com,compute.googleapis.comו-logging.googleapis.com. ערכי ה-DNS של ממשקי ה-API צריכים להתפרש ככתובות IP פרטיות. שימו לב: שימוש ב-Private Service Connect לא מבטל את הצורך בקישור (peering) בין רשתות VPC כדי לתקשר עם רשתות VPC אחרות שמנוהלות על ידי לקוחות. - קישור (peering) בין רשתות VPC שכנות: אם האשכול מתקשר עם משאבים ברשתות VPC אחרות, כמו פרויקטים מארחים של VPC משותף או רשתות VPC אחרות של לקוחות, צריך לוודא שהקישור בין רשתות ה-VPC הוגדר בצורה נכונה ושהנתיבים מופצים.
כללי חומת אש:
- כללי ברירת מחדל: מוודאים שכללי ברירת המחדל של חומת האש, כמו
allow-internalאוallow-ssh, לא מגבילים מדי. כללים מותאמים אישית: אם יש כללים מותאמים אישית לחומת האש, צריך לוודא שהם מאפשרים את נתיבי התקשורת הנדרשים:
- תקשורת פנימית בתוך האשכול (בין צומתי -m לבין צומתי -w).
תעבורה יוצאת ממכונות וירטואליות באשכול אל ממשקי ה-API של Google, באמצעות כתובות IP ציבוריות או שער לאינטרנט, גישה פרטית ל-Google או נקודות קצה של Private Service Connect.
תנועה לכל מקורות הנתונים או השירותים החיצוניים שהעבודות שלכם תלויות בהם.
- כללי ברירת מחדל: מוודאים שכללי ברירת המחדל של חומת האש, כמו
פענוח DNS: מוודאים שמופעים של אשכול יכולים לפתור נכון שמות DNS עבור Google APIs וכל שירות פנימי או חיצוני.
טיפים לפתרון בעיות:
- בדיקת הגדרות הרשת: בודקים את ההגדרות של רשת ה-VPC ושל רשת המשנה שבהן מתבצעת הפריסה של האשכול.
- בדיקת כללי חומת האש: בודקים את כללי חומת האש ברשת ה-VPC או בפרויקט המארח של ה-VPC המשותף.
- בודקים את הקישוריות: מפעילים מכונה וירטואלית זמנית ב-Compute Engine ברשת המשנה של האשכול ומבצעים את השלבים הבאים:
-
pingאוcurlלדומיינים חיצוניים של Google API, כמוstorage.googleapis.com. -
nslookupכדי לוודא שכתובות ה-IP הצפויות מתקבלות מפתרון ה-DNS (גישה פרטית ל-Google או Private Service Connect). - מריצים Google Cloud בדיקות קישוריות כדי לאבחן נתיבים ממכונה וירטואלית לבדיקה לנקודות קצה רלוונטיות.
-
כשלים בפעולות אתחול
פעולות אתחול של Dataproc הן סקריפטים שמופעלים במכונות וירטואליות של אשכולות במהלך יצירת האשכול. שגיאות בסקריפטים האלה יכולות למנוע את הפעלת האשכול.
טיפים לפתרון בעיות:
- בדיקת יומנים של שגיאות בפעולת האתחול: מחפשים ב-Cloud Logging רשומות ביומן שקשורות ל-
init-actionsאו ל-startup-scriptעבור מופעי האשכול. - בודקים את נתיבי הסקריפטים וההרשאות: מוודאים שסקריפטים של פעולות אתחול ממוקמים בצורה נכונה ב-Cloud Storage, ושלחשבון השירות של מכונת ה-VM באשכול יש את התפקיד
Storage Object Viewerשנדרש לקריאת סקריפטים של Cloud Storage. - ניפוי באגים בלוגיקה של הסקריפט: בודקים את הלוגיקה של הסקריפט במכונה וירטואלית נפרדת של Compute Engine שמדמה את סביבת האשכול כדי לזהות שגיאות. מוסיפים לסקריפט רישום מפורט של פעולות.
זמינות של משאבים אזוריים (מלאי חסר)
מדי פעם, סוג מכונה או משאב באזור או בתחום (zone) לא זמינים באופן זמני (מלאי חסר). בדרך כלל, התוצאה היא שגיאות RESOURCE_EXHAUSTED שלא קשורות לבעיות במכסת הפרויקט.
טיפים לפתרון בעיות:
- מנסים להשתמש באזור או באזור משנה אחר: מנסים ליצור את האשכול באזור משנה אחר באותו אזור, או באזור אחר.
- שימוש בבחירת תחום אוטומטית: אפשר להשתמש בתכונה בחירת תחום אוטומטית של Dataproc כדי לבחור באופן אוטומטי אזור עם קיבולת.
- שינוי סוג המכונה: אם אתם משתמשים בסוג מכונה מותאם אישית או מיוחד, נסו להשתמש במכונה לשימוש סטנדרטי (standard) כדי לראות אם זה פותר את הבעיה.
פנייה ל-Cloud Customer Care
אם אתם ממשיכים להיתקל בבעיות שקשורות לכשל באשכול, אתם יכולים לפנות אל Cloud Customer Care. תארו את בעיית הכשל באשכול ואת השלבים שביצעתם כדי לפתור אותה. בנוסף, עליך לספק את הפרטים הבאים:
- נתוני אבחון של אשכול
- פלט מהפקודה הבאה:
gcloud dataproc clusters describe CLUSTER_NAME \ --region=REGION
- היומנים של האשכול שנכשל יוצאו.
שימוש בכלי gcpdiag
gcpdiag
הוא כלי בקוד פתוח. זה לא מוצר נתמך רשמית של Google Cloud .
אפשר להשתמש בgcpdiagכלי כדי לזהות ולפתור Google Cloudבעיות בפרויקט. מידע נוסף זמין בפרויקט gcpdiag ב-GitHub.
הכלי gcpdiag עוזר לכם לגלות בעיות ביצירת אשכול Dataproc באמצעות הבדיקות הבאות:
- שגיאות של חוסר במלאי: בודק את היומנים בכלי Logs Explorer כדי לגלות חוסר במלאי באזורים ובאזורי זמינות.
- מכסה לא מספיקה: בדיקת זמינות המכסה בפרויקט של אשכול Dataproc.
- הגדרת רשת לא מלאה: מבצע בדיקות קישוריות לרשת, כולל בדיקות של כללי חומת האש הנדרשים והגדרות של כתובות IP חיצוניות ופנימיות. אם האשכול נמחק, הכלי
gcpdiagלא יכול לבצע בדיקה של קישוריות הרשת. - הגדרה שגויה של פרויקטים שונים: בדיקה של חשבונות שירות בפרויקטים שונים, ובדיקה של תפקידים נוספים ושל אכיפת מדיניות הארגון.
- תפקידי IAM חסרים ברשת של ענן וירטואלי פרטי (VPC) משותף: אם אשכול Dataproc משתמש ברשת VPC משותפת, המערכת בודקת אם נוספו תפקידים נדרשים של חשבון שירות.
- כשלים בפעולות אתחול: הערכת יומנים בכלי Logs Explorer כדי לגלות כשלים ופסק זמן בסקריפטים של פעולות אתחול.
רשימת השלבים ליצירת אשכול מופיעה במאמר שלבים אפשריים.gcpdiag
מריצים את הפקודה gcpdiag.
אפשר להריץ את הפקודה gcpdiag מ-Cloud Shell במסוףGoogle Cloud או בתוך מאגר Docker.
מסוףGoogle Cloud
- משלימים את הפקודה הבאה ואז מעתיקים אותה.
- פותחים את Google Cloud המסוף ומפעילים את Cloud Shell. פתיחת מסוף Cloud
- מדביקים את הפקודה שהועתקה.
- מריצים את הפקודה
gcpdiag, שמורידה את תמונת ה-Dockergcpdiag, ואז מבצעת בדיקות אבחון. אם יש הוראות לגבי הפלט, פועלים לפיהן כדי לתקן את הבדיקות שנכשלו.
gcpdiag runbook dataproc/cluster-creation \
--parameter project_id=PROJECT_ID \
--parameter cluster_name=CLUSTER_NAME \
--parameter OPTIONAL_FLAGSDocker
אפשר
להריץ את gcpdiag באמצעות wrapper שמתחיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.
- מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית.
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
- מריצים את הפקודה
gcpdiag../gcpdiag runbook dataproc/cluster-creation \ --parameter project_id=PROJECT_ID \ --parameter cluster_name=CLUSTER_NAME \ --parameter OPTIONAL_FLAGS
כאן אפשר לראות את הפרמטרים הזמינים של קובץ ה-runbook הזה.
מחליפים את מה שכתוב בשדות הבאים:
- PROJECT_ID: מזהה הפרויקט שמכיל את המשאב
- CLUSTER_NAME: השם של אשכול Dataproc היעד בפרויקט
- OPTIONAL_PARAMETERS: מוסיפים פרמטר אופציונלי אחד או יותר מהפרמטרים הבאים. חובה לכלול את הפרמטרים האלה אם האשכול נמחק.
-
cluster_uuid: המזהה הייחודי האוניברסלי (UUID) של אשכול Dataproc היעד בפרויקט -
service_account: קלאסטר Dataproc חשבון שירות של מכונה וירטואלית -
subnetwork: נתיב ה-URI המלא של רשת המשנה של אשכול Dataproc -
internal_ip_only: True או False -
cross_project: המזהה של הפרויקט שאליו שייך חשבון השירות של המכונה הווירטואלית, אם אשכול Dataproc משתמש בחשבון שירות של מכונה וירטואלית בפרויקט אחר
-
דגלים שימושיים:
-
--universe-domain: אם רלוונטי, הדומיין של Trusted Partner Sovereign Cloud שמארח את המשאב -
--parameterאו-p: פרמטרים של Runbook
רשימה ותיאור של כל הדגלים של כלי gcpdiag מופיעים בהוראות השימוש ב-gcpdiag.
המאמרים הבאים
- מידע נוסף על כלי המעקב ופתרון הבעיות של Dataproc
- איך מאבחנים אשכולות Dataproc
- אפשר לעיין במסמך שאלות נפוצות בנושא Dataproc .