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

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

איך פועל מידרוג אוטומטי מנוהל

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

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

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

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

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

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

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

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

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

תמחור

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

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

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

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

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

מגבלות

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

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

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

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

פרמטר תיאור
יעד ניצול מעבד (CPU) בעדיפות גבוהה אחוז מקיבולת ה-CPU של המופע לשימוש במשימות בעדיפות גבוהה. הערך צריך להיות בין 10% ל-90%. אם ניצול המעבד של מכונה בעדיפות גבוהה חורג מהיעד שהגדרתם, Spanner מוסיף באופן מיידי קיבולת חישוב למכונה. אם השימוש במעבד נמוך משמעותית מהיעד, Spanner מסיר קיבולת חישוב. מידע נוסף זמין במאמר בנושא קביעת יעד גבוה לניצול מעבד.
יעד כולל לניצול המעבד אחוז מקיבולת המעבד הכוללת של המופע לשימוש במשימות בעדיפות גבוהה, בינונית ונמוכה. הערך צריך להיות בין 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) עבור הגדרות אזוריות, בשני אזורים ובמספר אזורים של מכונות, אפשר לעיין במאמר התראות על שימוש גבוה במעבד (CPU).

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

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

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

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

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

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

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

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

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

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

הגדרת יעדי ניצול המעבד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • יש לכם אירוע שיא של הרחבת עומס שעומד להתרחש, ואתם צופים עלייה זמנית בנפח התנועה. אתם רוצים לוודא שיש לכם מספיק קיבולת חישובית.
  • האפליקציה שלך שולחת תנועה עם עליות חדות. כשמוסיפים קיבולת מחשוב חדשה, 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) בעדיפות גבוהה
  • יעד כולל לניצול המעבד
  • השבתה של סה"כ המעבד
  • השבתת עדיפות גבוהה של יחידת העיבוד המרכזית (CPU)

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

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

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

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

בעיות שקשורות למעבר לגיבוי

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

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

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

  • העתק A מוגדר עם יעדי מעבד (CPU) גם בעדיפות גבוהה וגם בסך הכול.
  • עותק משוכפל ב' מוגדר רק עם יעד CPU בעדיפות גבוהה.

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

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

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

בקרת גישה

כדי להגדיר את הכלי המנוהל לשינוי גודל אוטומטי, אתם צריכים להיות ישות (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.

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

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

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