מידרוג אוטומטי מנוהל

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

כיצד עובד קנה מידה אוטומטי מנוהל

כשמפעילים את התכונה 'שינוי גודל אוטומטי מנוהל', Spanner משנה את גודל המופע באופן אוטומטי. אפשר להפעיל את התכונה 'שינוי גודל אוטומטי מנוהל' במופע Spanner או במחיצת המופע (בתצוגה מקדימה). התכונה 'שינוי גודל אוטומטי מנוהל' מגיבה לשינויים בעומס העבודה או בנפח האחסון שנדרש למופע, כשהעומס גדל או קטן. מדרג אוטומטי מנוהל או מגדיל את הקנה מידה, ומוסיף קיבולת מחשוב למופע, או שהוא מקטין את הקנה מידה, ומסיר את קיבולת המחשוב מהמופע.

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

המדרג האוטומטי המנוהל על ידי Spanner קובע כמה קיבולת חישוב נדרשת, בהתבסס על הדברים הבאים:

  • יעד ניצול מעבד בעדיפות גבוהה
  • יעד ניצול כולל של המעבד
  • יעד לניצול נפח האחסון
  • מגבלה מינימלית
  • מגבלה מקסימלית

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

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

אם מנהל קנה המידה האוטומטי מגדיל את קנה המידה של מופע עד למגבלה המקסימלית שלו, אבל עומס העבודה עדיין גורם לניצול גבוה יותר של CPU מאשר יעד, יכול להיות שזמן האחזור של בקשות עומס העבודה יהיה גבוה יותר או שהבקשות ייכשלו. אם מופעלת הגדלה של נפח האחסון של מופע עד למקסימום קיבולת החישוב שלו, אבל עומס העבודה דורש נפח אחסון גדול יותר מהמגבלה המקסימלית, בקשות כתיבה עלולות להיכשל. כדי לבדוק אם הושג היעד המקסימלי, אפשר לעיין ביומני האירועים של מערכת המידרוג האוטומטי המנוהל במסוף Google Cloud בדף System insights. למידע נוסף, ראה מגבלות אחסון.

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

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

תמחור

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

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

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

אפשר להגביל את העלות המקסימלית של מופע Spanner על ידי הגדרת המגבלה של מספר הצמתים או יחידות העיבוד לרמה שרוצים להוציא.

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

מגבלות

ההגבלות הבאות חלות כשמפעילים או משנים את התכונה של שינוי גודל אוטומטי מנוהל במופע או במחיצת מופע:

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

פרמטרים של קנה מידה אוטומטי מנוהל

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

פרמטר תיאור
יעד ניצול מעבד בעדיפות גבוהה אחוז מקיבולת המעבד של המופע לשימוש עבור משימות בעלות עדיפות גבוהה. הערך צריך להיות בין 10% ל-90%. כאשר ניצול המעבד בעל עדיפות גבוהה של מופע חורג מהיעד שהגדרת, Spanner מוסיף מיד קיבולת מחשוב למופע. אם ניצול המעבד נמוך משמעותית מהיעד, Spanner מסיר קיבולת חישוב. למידע נוסף, ראה קביעת יעד ניצול CPU בעל עדיפות גבוהה.
יעד כולל לניצול יחידת העיבוד המרכזית (CPU) אחוז מקיבולת המעבד הכוללת של המופע לשימוש במשימות בעדיפות גבוהה, בינונית ונמוכה. הערך צריך להיות בין 10% ל-90%. כשהשימוש הכולל במעבד של מופע חורג מהיעד שהגדרתם,‏ Spanner מוסיף מיד קיבולת חישוב למופע. אם סך השימוש במעבד נמוך משמעותית מהיעד, מערכת Spanner מסירה את קיבולת החישוב. למידע נוסף, ראה קביעת יעד ניצול המעבד הכולל.
יעד לניצול נפח האחסון אחוז האחסון בצומת שניתן להשתמש בו לפני ש-Spanner גדל. היעד הזה מבטיח שתמיד תהיה לכם מספיק קיבולת חישוב כדי להתמודד עם תנודות בכמות הנתונים שאתם מאחסנים. ערך זה חייב להיות בין 10% ל-99%. מידע נוסף זמין במאמר בנושא קביעת יעד לניצול נפח האחסון.
מגבלה מינימלית כמות קיבולת החישוב הנמוכה ביותר שאליה Spanner מוריד את המופע. הערך המינימלי לא יכול להיות נמוך מ-10% מהערך שהגדרתם לתקרה המקסימלית. לדוגמה, אם המגבלה המקסימלית היא 40 צמתים, המגבלה המינימלית חייבת להיות לפחות 4 צמתים. הדרישה של 10% היא גבול קשה. למידע נוסף, ראו קביעת מגבלת המינימום.
המגבלה המקסימלית הכמות הכי גבוהה של קיבולת מחשוב ש-Spanner יכול להגדיל את המופע עד אליה. בצמתים, הערך הזה צריך להיות גדול מ-1 (או מ-1,000 יחידות עיבוד) ושווה למספר המינימלי של צמתים או יחידות עיבוד, או גדול ממנו. הערך לא יכול להיות יותר מפי 10 מהמספר שבחרת עבור כמות קיבולת החישוב המינימלית. הדרישה הזו של 10 פעמים היא מגבלה קשיחה. מידע נוסף מופיע במאמר בנושא קביעת המגבלה המקסימלית.
השבתת קנה מידה נמוך יותר מונעים מהכלי לשינוי גודל אוטומטי לצמצם את מספר הצמתים או יחידות העיבוד. כאשר מוגדר ל-True, כל התנהגויות הורדת קנה המידה מושבתות, כולל הורדת קנה המידה של המופע ומחיצת המופע. אפשר להגדיר את האפשרות הזו רק באמצעות Google Cloud CLI. מידע נוסף זמין במאמר דגלי פרמטרים ומגבלות ב-Google Cloud CLI.

קבע את תצורת מקדם השינוי האוטומטי המנוהל

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

קביעת יעד ניצול המעבד (CPU) בעדיפות גבוהה

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

כשניצול המעבד קרוב ל-100% או מעל 100%, יכול להיות שהביצועים ייפגעו. אם עומס העבודה שלך רגיש להשהייה או לביצועים, שקול להתאים אישית את יעד המעבד הכולל לערך נמוך יותר. שימו לב שפעולה כזו עלולה להוביל לעלויות גבוהות יותר.

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

ניתן גם להגדיר יעדים הן עבור ניצול כולל והן עבור ניצול CPU בעדיפות גבוהה. מידע נוסף זמין במאמר קביעת יעדי ניצול המעבד.

קביעת יעד כולל לניצול המעבד

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

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

אם הגדרתם את יעד השימוש הכולל ב-CPU ואתם עדיין רואים חביון גבוה באופן לא מקובל, כדאי להקטין את יעד השימוש הכולל ב-CPU.

כדי לייעל את תפוקת הכתיבה ויצירת האינדקסים, אנו ממליצים על יעד CPU כולל של 70% עבור מופעים אזוריים ו-50% עבור מופעים מרובי אזורים. זה עובד היטב גם במהלך כשל, אם לא נבחר יעד בעל עדיפות גבוהה. עם זאת, יעדים אלה עשויים לגרור עלויות גבוהות יותר. אם העלות מהווה דאגה, אנו ממליצים על יעד מעבד כולל של 85%. זה מספק תקורה לספיגת קפיצות חדות מבלי להפעיל השהיה הנגרמת מרוויה של משאבים (ניצול של 100%).

כברירת מחדל, Spanner מתעדף תעבורה הפונה למשתמש על ידי ויסות פעולות רקע עתירות משאבים (כגון יצירת אינדקס). כדי להאיץ את פעולות הרקע האלה, אפשר להגדיר יעד נמוך יותר לשימוש הכולל במעבד (לדוגמה, ‎<=60%‎). האות הזה גורם למערכת להקצאת משאבים באופן אוטומטי להקצות משאבי מחשוב נוספים, וכך להגדיל את התפוקה של משימות המערכת. עם זאת, הדבר עלול להגדיל את העלויות. אם ברצונך להגדיל באופן זמני את התפוקה ליצירת אינדקס, תוכל להגדיר יעדי CPU כוללים נמוכים יותר עד להשלמת יצירת האינדקס.

ניתן גם להגדיר יעדים הן עבור ניצול כולל והן עבור ניצול CPU בעדיפות גבוהה. למידע נוסף, ראה קביעת שני יעדי ניצול המעבד.

קבע את שני יעדי ניצול המעבד

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

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

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

באופן כללי, אנחנו ממליצים על יעדי ניצול המעבד הבאים למעבר גיבוי אמין:

סוג המכונה יעד כולל לניצול יחידת העיבוד המרכזית (CPU) יעד ניצול מעבד (CPU) בעדיפות גבוהה
מופע אזורי 70% ‪65%
מופע רב-אזורי 50% 45%

בהתאם לעומס העבודה, אנחנו ממליצים גם על יעדים ספציפיים יותר לניצול המעבד:

סוג עומס העבודה יעדי מעבד מומלצים השפעות
עומס עבודה (workload) שרגיש לתפוקה וכולל הרבה פעולות כתיבה יעד ניצול מעבד כולל: 70% תפוקה גבוהה יותר על חשבון זמן האחזור
עומס עבודה רגיש להשהייה וכבד קריאה יעד ניצול מעבד כולל: 80%

יעד ניצול CPU בעדיפות גבוהה: 65% (אזורי) או 45% (רב-אזורי)		 זמן אחזור צפוי בזנב בעלות גבוהה יותר
תעדוף עומסי עבודה לפי יחס עלות-תועלת יעד ניצול המעבד הכולל: 85%

יעד ניצול המעבד בעדיפות גבוהה: 65% (אזורי) או 45% (אזורי)		 עלות וביצועים סבירים עם אפשרות לעיכוב ביצירת האינדקס

קביעת יעד לניצול נפח האחסון

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

קביעת המגבלה המקסימלית

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

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

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

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

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

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

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

איך קובעים את הגבול התחתון

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

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

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

למידע נוסף על ערכים מקובלים, ראה פרמטרים מנוהלים של קנה מידה אוטומטי.

במקרים רבים כדאי להגדיר את הערך המינימלי ליותר מאחד. כדאי לבחור מספר גבוה יותר או להגדיל את המגבלה המינימלית במקרים הבאים:

  • אתם צופים אירוע שיא של הרחבת עומס בעתיד הקרוב, שבו צפויה עלייה זמנית בנפח התנועה, ואתם רוצים לוודא שיש לכם מספיק קיבולת חישובית.
  • האפליקציה שלך שולחת תנועה עם עליות חדות. כשמוסיפים קיבולת מחשוב חדשה, Spanner מבצע איזון מחדש באופן אוטומטי כדי להשתמש בצמתים או ביחידות העיבוד החדשים. התהליך הזה יכול להימשך כמה דקות, ולכן כדאי לבחור ערך מינימלי גבוה יותר. כך המופע שלכם יוכל להתמודד עם העליות בצורה חלקה.
  • אתם מגדילים את קיבולת החישוב המקסימלית. הערך המינימלי חייב להיות תמיד 10% או יותר מיעד קיבולת החישוב המקסימלית. לדוגמה, אם הגדרתם את המספר המקסימלי של הצמתים ל-30, אתם צריכים להגדיר את המספר המינימלי של הצמתים ל-3 לפחות.

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

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

דגלים של פרמטרים ומגבלות ב-Google Cloud CLI

כשמשתמשים ב-Google Cloud CLI כדי להגדיר את שינוי הגודל האוטומטי המנוהל, יש כמה דגלים שחובה להגדיר. ישנם דגלים אופציונליים שבהם ניתן להשתמש כדי לציין אם ברצונך להשתמש בצמתים או ביחידות עיבוד. למידע נוסף על יצירת מופע חדש או מחיצה חדשה של מופע באמצעות שינוי גודל אוטומטי מנוהל, או על הפעלת שינוי גודל אוטומטי מנוהל במופע קיים או במחיצה קיימת של מופע, אפשר לעיין במדריכים הבאים:

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

  • autoscaling-high-priority-cpu-percent
  • autoscaling-total-cpu-percent
  • autoscaling-storage-percent

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

אם תבחר להשתמש בצמתים, עליך להשתמש גם בשני הדגלים הבאים בעת הפעלת מקדם השינוי האוטומטי המנוהל:

  • autoscaling-min-nodes
  • autoscaling-max-nodes

אם בוחרים להשתמש ביחידות עיבוד, צריך להשתמש גם בשני הדגלים הבאים כשמפעילים את קנה המידה האוטומטי המנוהל:

  • autoscaling-min-processing-units
  • autoscaling-max-processing-units

אפשר להשתמש בדגל הבוליאני --disable-downscaling כדי למנוע מהמערכת האוטומטית לשינוי גודל האשכול להקטין את מספר הצמתים או יחידות העיבוד. כשמגדירים את הדגל הזה לערך true, הגדלת קנה המידה ממשיכה לפעול כרגיל כדי לעמוד בביקוש המוגבר. כדי להפעיל את הקטנת הרזולוציה אחרי השבתה, משתמשים ב--no-disable-downscaling flag.

המגבלות הבאות חלות כשמוסיפים את הכלי לשינוי גודל קבוצת המופעים המנוהלת למופע קיים באמצעות Google Cloud CLI:

  • אי אפשר להשתמש בדגל --nodes עם הדגלים --autoscaling-min-nodes או --autoscaling-max-nodes כי השימוש בדגל --nodes מגדיר מספר ספציפי של צמתים ולא טווח של צמתים שניתן להרחבה. באופן דומה, אי אפשר להשתמש בדגל --processing-units עם הדגלים autoscaling-min-processing-units או autoscaling-max-processing-units, כי השימוש בדגל --processing-units מגדיר מספר ספציפי של יחידות עיבוד ולא טווח של יחידות עיבוד.
  • אי אפשר לערבב את הדגלים עבור צמתים ויחידות עיבוד יחד. לדוגמה, אי אפשר להשתמש ב---autoscaling-max-nodes עם autoscaling-min-processing-units.

שיפור ההגדרות

חשוב לעקוב אחרי השימוש בקיבולת החישוב ולשנות את ההגדרות לפי הצורך, במיוחד אחרי שמפעילים לראשונה את התכונה 'שינוי גודל אוטומטי מנוהל'. מומלץ להשתמש בדף System insights במסוף Google Cloud .

התאמה אוטומטית לעומס (autoscaling) אסימטרית לקריאה בלבד

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

  • מגבלת קיבולת חישוב מינימלית
  • מגבלה על קיבולת מחשוב מקסימלית
  • יעד ניצול מעבד בעדיפות גבוהה
  • יעד ניצול כולל של המעבד
  • השבתה של סה"כ המעבד
  • השבתת עדיפות גבוהה של יחידת העיבוד המרכזית (CPU)

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

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

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

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

חששות לגבי כשל

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

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

למשל, נבחן את התרחיש הבא:

  • עותק משוכפל A מוגדר עם יעדי CPU בעלי עדיפות גבוהה וגם עם יעדי CPU כוללים.
  • עותק משוכפל B מוגדר עם יעד CPU בעל עדיפות גבוהה בלבד.

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

כדי למנוע בעיות, מומלץ:

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

בקרת גישה

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

מעקב

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

המדדים הבאים מוצגים בתרשימים בדף System insights במסוף Google Cloud . אפשר גם לראות את המדדים האלה באמצעות Cloud Monitoring.

  • spanner.googleapis.com/instance/autoscaling/min_node_count
  • spanner.googleapis.com/instance/autoscaling/max_node_count
  • spanner.googleapis.com/instance/autoscaling/min_processing_units
  • spanner.googleapis.com/instance/autoscaling/max_processing_units
  • spanner.googleapis.com/instance/autoscaling/high_priority_cpu_target_utilization
  • spanner.googleapis.com/instance/autoscaling/total_cpu_target_utilization
  • spanner.googleapis.com/instance/autoscaling/storage_target_utilization

רישום ביומן

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

הצג יומני רישום בדף תובנות המערכת

אפשר לראות את יומני האירועים של מערכת שינוי הגודל האוטומטי המנוהלת במסוףGoogle Cloud בדף System insights.

  1. בקונסולה Google Cloud , פתחו את Spanner:

    עבור אל Spanner

  2. בחר את המופע או מחיצת המופע המותאמים לקנה מידה אוטומטי.

  3. בתפריט הניווט, לוחצים על תובנות לגבי המערכת.

  4. בדף תובנות המערכת, נווטו אל המדד קיבולת מחשוב.

  5. לוחצים על הצגת יומנים כדי לפתוח את חלונית היומנים.

    בחלונית Compute capacity logs מוצגים היומנים של השעה האחרונה.

    אם הפעלתם שינוי גודל אוטומטי אסימטרי לקריאה בלבד במופע, סיכום היומן יכלול תיאור ומיקום של כל שינוי בקיבולת החישוב של כל רפליקה. לדוגמה, Increased from 1 to 2 nodes in us-central1 to maintain high priority CPU utilization at 80%. אם אתם לא משתמשים בהתאמת גודל אוטומטית אסימטרית, פרטי המיקום לא מופיעים בסיכום היומן. לדוגמה, Increased from 9 to 10 nodes to maintain high priority CPU utilization at 65%. אפשר גם לראות מתי מספר הצמתים גדל כדי לשמור על יעד השימוש הכולל במעבד.

הצג יומני רישום באמצעות Logs Explorer

אפשר גם לראות את היומנים באמצעות Logs Explorer:

  1. במסוף Google Cloud , פותחים את Logs Explorer:

    כניסה לדף Logs Explorer

  2. בוחרים את הפרויקט המתאים Google Cloud .

  3. בשדה Query, מזינים את הטקסט הבא:

     protoPayload.methodName="AutoscaleInstance"

    כדי לצמצם עוד יותר את החיפוש ביומנים, אפשר להוסיף את השאילתה הבאה:

    resource.type="spanner_instance"
resource.labels.instance_id=INSTANCE_ID
resource.labels.project_id=PROJECT_ID
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event"
protoPayload.methodName="AutoscaleInstance"

    כדי להציג יומני רישום עבור שאילתות הפועלות במחיצת מופע שאינה ברירת מחדל, הזן:

    resource.type="spanner_instance"
resource.labels.instance_id=INSTANCE_ID
resource.labels.project_id=PROJECT_ID
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event"
protoPayload.methodName="AutoscaleInstancePartition"

  4. לוחצים על Run query.

חלונית תוצאות שאילתה מציגה את היומנים של השעה האחרונה.

מידע נוסף על צפייה ביומנים זמין במאמר בנושא Cloud Logging. אתם יכולים להגדיר התראות שמבוססות על יומנים בדף Logs explorer ב- Google Cloud או באמצעות Cloud Monitoring API.

המאמרים הבאים