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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת יעד לניצול נפח האחסון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המגבלות הבאות חלות כשמוסיפים את המידרוג האוטומטי המנוהל למופע קיים באמצעות 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)
השבתת עדיפות גבוהה של המעבד

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

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

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

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

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

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

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

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

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

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

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

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

בקרת גישה

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

מעקב

‫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.

במסוף Google Cloud , פותחים את Spanner:

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

בחלונית 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:

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

כניסה לדף Logs Explorer
בוחרים את הפרויקט המתאים Google Cloud .

בשדה 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"

לוחצים על Run query.

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

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