גמישות ויעילות מקסימליות של אשכולות ומשימות
בדף הזה מפורטות שיטות מומלצות ואסטרטגיות תזמון שיעזרו לכם לתכנן אשכולות גמישים של Managed Service for Apache Spark, שימקסמו את זמינות המשאבים באזורי Google Cloud , יצמצמו את העיכובים בהקצאה וינצלו את האופטימיזציות של הביצועים והעלויות.
סקירה כללית על זמינות המשאבים
הרצת משימות באשכולות קשיחים של Managed Service for Apache Spark יוצרת נקודות כשל בודדות, שעלולות להוביל להפרעות במשימות ולכשלים באשכולות ובמשימות בגלל חוסר זמינות מקומית או עיכובים בהקצאה.
הסיכון שהמשאבים לא יהיו זמינים גבוה באשכולות שמוגדרים עם אחד מהדפוסים האנטי-תבניתיים הנוקשים הבאים:
- מיקום קבוע של אזור: קידוד קשיח של אזור אחד באמצעות הדגל או השדה
zone, במקום לאפשר ל-Managed Service for Apache Spark AutoZone למקם באופן דינמי את האשכול באזור האופטימלי. דפוס האנטי הזה מונע מיצירת האשכול להשתמש במשאבי המחשוב שזמינים באזורים סמוכים. - סוג מכונה או דור אחד לכל תפקיד של צומת: הגבלת תפקידי הצמתים לדור או סוג מכונה אחד. התבנית הזו מונעת מהאשכול לחזור לחלופות.
- מעט מדי משפחות מכונות בדירוג העדיפות הגבוה ביותר: הצגת משפחת מכונות אחת או שתיים בלבד בדירוג 0 של מדיניות VM גמישה, גם כשמוגדרים דירוגי חלופות. הדפוס הזה מצמצם את מאגר המשאבים ש-Managed Service for Apache Spark יכול להשתמש בהם, מה שמגדיל את הסיכוי לחזור לדירוגים נמוכים יותר או לעיכובים בהקצאה.
- שינוי קנה מידה אנכי עם פחות מכונות וירטואליות גדולות: שינוי קנה המידה של אשכולות באופן אנכי כדי להסתמך על מספר קטן של צורות גדולות של מכונות וירטואליות. דפוס האנטי הזה מגביל את הגמישות בתזמון.
- יצירת אשכולות בשיטת "הכול או כלום": הקצאה של כל הצמתים העובדים בו-זמנית, במקום להשתמש ביצירת אשכולות חלקית בשילוב עם התאמה אוטומטית לעומס. הדפוס האנטי-תבניתי הזה גורם לכך שיצירת האשכול תיכשל אם אי אפשר להקצות צומת עובד בגלל חוסר זמינות זמנית של משאבים.
- עומס בלוח הזמנים: הפעלת צינורות עיבוד נתונים גדולים של Batch בשעות השיא, מה שמגביר את התחרות על המשאבים באזור.
השגת משאבים היא שיטה שבה מתכננים משימות כך שיהיו גמישות מבחינת החומרה, יתפרסו על פני כמה אזורים ויהיו ניתנות להתאמה לעומס. אם תפרידו את האשכולות מהגדרות קשיחות ותאפשרו חלופות למשפחות של מכונות מרובות, תוכלו להגדיל את שיעורי ההצלחה של היצירה, לצמצם את זמן האחזור של ההפעלה ולעמוד באופן עקבי בהסכמי רמת השירות (SLA).
המלצות לגבי השגת משאבים
כדי לשפר את זמינות המשאבים ואת יציבות המשימות, כדאי לבצע את האופטימיזציות הבאות:
שימוש במכונות וירטואליות גמישות
התכונה מכונה וירטואלית גמישה מאפשרת לציין רשימה מדורגת של סוגי מכונות וירטואליות לצומת הראשי, לצומת העובד הראשי ולצומת העובד המשני. כך אפשר להגדיל את שיעורי ההצלחה של היצירה על ידי הערכה של סוגי ה-VM שמופיעים ברשימה ובחירה אוטומטית של אזורים עם קיבולת זמינה.
המלצות: השתמשו במכונות וירטואליות גמישות עם שינוי הגדרות הדיסק, שמאפשרות לציין סוגי דיסקים שונים, כמו Hyperdisk ו-Persistent Disk, למשפחות שונות של מכונות מועמדות באותה מדיניות אשכול. אתם יכולים גם לשלב משפחות מכונות מדור 2 ומדור 4 במדיניות אחת, כדי להרחיב את המשימות למאגר רחב יותר ולעקוף את מגבלות הקיבולת.
ציינו לפחות שלוש משפחות מכונות שונות בדירוג 0. Managed Service for Apache Spark שולף קודם כל מהרשימה עם העדיפות הגבוהה ביותר (דירוג 0), כך שדירוג 0 רחב נותן ליצירת האשכול את המאגר הגדול ביותר של משאבים מועמדים לפני שהוא חוזר לדירוגים נמוכים יותר. הדרך הכי יעילה להרחיב את המאגר הזה היא לשלב משפחות מדור 4 ומדור 2 בדרגה 0.
לעומסי עבודה למטרות כלליות, למשל משימות שפועלות כרגע במכונות N2 או N2D, השתמשו בדירוגים הבאים:
- דירוג 0: N4, N4D (עם Hyperdisk Balanced), N2, N2D
- דירוג 1: C4, C4D (עם Hyperdisk Balanced), C2D. אפשר להשתמש ב-Local SSD עם C4 ו-C4D, אבל בדרך כלל 8 או 16 ליבות תומכות רק ב-1-2 כונני Local SSD.
- דירוג 2: E2 (ביצועים נמוכים יותר, כדאי להשתמש רק אם צריך)
לדוגמה, במשרות שבהן משתמשים ב-n2d-standard-16, הדירוגים הם:
- דירוג 0:
n4-standard-16,n4d-standard-16,n2-standard-16,n2d-standard-16 - דירוג 1:
c4-standard-16,c4d-standard-16,c2d-standard-16 - דירוג 2:
e2-standard-16
בגלל ש-N4 ו-N4D דורשים Hyperdisk, וב-N2 וב-N2D משתמשים ב-Persistent Disk, צריך להגדיר את דירוג 0 כשתי בחירות של מכונות שחולקות את אותו דירוג אבל משתמשות בערכי diskConfig שונים. לדוגמה, הדגלים הבאים של gcloud dataproc clusters create מגדירים את מדיניות ה-primary worker בדוגמה הקודמת:
gcloud dataproc clusters create CLUSTER_NAME \
--region=REGION \
--zone="" \
--num-workers=NUM_WORKERS \
--worker-instance-selection='{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
--worker-instance-selection='{"machineTypes":["n2-standard-16","n2d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
--worker-instance-selection='{"machineTypes":["c4-standard-16","c4d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
--worker-instance-selection='{"machineTypes":["c2d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}' \
--worker-instance-selection='{"machineTypes":["e2-standard-16"],"rank":2,"diskConfig":{"bootDiskType":"pd-balanced","bootDiskSizeGb":BOOT_DISK_SIZE_GB}}'
כשמשתמשים במכונות וירטואליות גמישות, חשוב להביא בחשבון את הגורמים הבאים:
תמיכה בסוגי דיסקים משולבים: סוגי המכונות Gen3 ו-Gen4 תומכים רק בסוגי הדיסקים של Hyperdisk, ולא תומכים בסוגי הדיסקים של Persistent Disk. כשמשלבים בין Gen2 ל-Gen4, צריך לציין
diskConfigלכל בחירת מכונה ב-instanceFlexibilityPolicy. מידע נוסף זמין במאמר שינוי ברירות המחדל של הדיסק.- משתמשים ב-Hyperdisk Balanced עם ערכי הבסיס של IOPS וקצב העברת הנתונים שצוינו בביצועי ברירת המחדל של Hyperdisk Balanced.
מכסות למשאבים: כשמגדירים מדיניות של מכונות וירטואליות גמישות עם סוגים חלופיים, Compute Engine בודק את המכסות של כל הסוגים והדיסקים האפשריים באזור. מוודאים שבפרויקט יש מספיק מכסות למחשוב ולדיסק לכל הפריטים שהוגדרו.
הנחות ב-Compute Engine: אתם יכולים לנצל הנחות גמישות תמורת התחייבות לשימוש (CUD) כדי להחיל חיסכון שמבוסס על הוצאות בכמה משפחות של מכונות וירטואליות ובכמה אזורים.
תמחור: אתם יכולים להשתמש במחשבון העלויות שלGoogle Cloud כדי להשוות בין העלויות של כל רמה במדיניות.
לדוגמאות של תבניות הגדרה ופריסה, ראו:
שימוש במיקום מודעות אוטומטי
כדי לאפשר ל-Managed Service for Apache Spark לבחור את האזור הכי מתאים להקצאת משאבים, משתמשים במיקום AutoZone. אם אתם משתמשים ברשתות VPC בהתאמה אישית, ודאו שיש מספיק כתובות IP ברשת המשנה בכל האזורים.
שימוש במכונות קטנות יותר
תכננו את המשימות כך שיתרחבו אופקית על פני סוגי מכונות קטנים יותר (4, 8 או 16 ליבות) במקום להתרחב אנכית עם מכונות וירטואליות גדולות יותר. למכונות וירטואליות קטנות יותר יש זמינות גבוהה יותר באזורים, מה שעוזר למנוע עיכובים ביצירה.
- לבדוק ולתכנן מחדש משימות שמשתמשות במכונות מסוגים גדולים לצומתי דרייבר.
- בודקים משימות שמריצות רק צומתי דרייבר בלי צומתי עובד (אשכולות עם צומת יחיד). משימות שפועלות באשכולות עם צומת יחיד לא יכולות להתרחב באופן דינמי, והן מחייבות הפעלה במארח פיזי יחיד.
שימוש בהתאמה לעומס (autoscaling) באשכול
כדי לנהל את הקיבולת של משימות עם משאבים משתנים (עליות חדות), השתמשו בהתאמה אוטומטית לעומס של האשכול עם מספר מקסימלי מספיק של מכונות.
שימוש ביצירת אשכול חלקי עם התאמה אוטומטית לעומס (automatic scaling)
להשתמש ביצירת אשכול חלקי, שמאפשרת לציין מספר מינימלי של primary workers, עם התאמה אוטומטית לעומס (automatic scaling). אם האשכול מתחיל עם פחות עובדים מהנדרש, ההתאמה האוטומטית לעומס יכולה להוסיף עוד עובדים באופן דינמי ברגע שהמשאבים יהיו זמינים.
תזמון משימות בשעות השפל
תזמנו משימות בשעות שאינן שעות השיא, כמו באמצע היום ובסופי שבוע. כדי למנוע עומס, כדאי לתזמן את המשימות לשעות לא שגרתיות, למשל 10:07 במקום 10:00.
המאמרים הבאים
- איך נותנים עדיפות לסוגי VM באמצעות מכונות וירטואליות גמישות
- איך מגדירים את AutoZone
- איך יוצרים אשכול חלקי
- איך מגדירים כללי התאמה לעומס (autoscaling)
- מידע נוסף על הנחות תמורת התחייבות לשימוש