התאמה אוטומטית לעומס (Automatic scaling)

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

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

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

אפשר להגדיר התאמה אוטומטית לעומס במסוף Google Cloud , באמצעות gcloud או באמצעות ספריית הלקוח של Cloud Bigtable ל-Java.

מתי כדאי להשתמש בהתאמה אוטומטית לעומס

ברוב המקרים מומלץ להפעיל את התכונה 'התאמה אוטומטית לעומס'. היתרונות של שינוי גודל אוטומטי כוללים:

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

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

  • תנועה עם שיאים
  • עומסי עבודה פתאומיים באצווה

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

בזיכרון ובהתאמה אוטומטית לעומס

אפשר להשתמש בשכבת הנתונים בזיכרון באשכולות במופעים של מהדורת Enterprise Plus. רמת השירות של Bigtable בזיכרון משתמשת בהתאמה אנכית לקיבולת העברת הנתונים, שמנוהלת באופן מלא, וכך מאפשרת לאשכולות להגיב כמעט באופן מיידי לעליות חדות בתעבורת הנתונים של קריאות נקודתיות. התאמה אנכית לעומס (vertical scaling) מתאימה כל צומת באופן אוטומטי כדי להתאים לדרישות של עומס העבודה, ומשתלבת עם התאמה אוטומטית לעומס (autoscaling) של Bigtable. מידע נוסף על מגבלות של הרחבה אנכית ועל קיבולת של תפוקת נתונים בזיכרון זמין במאמר הסבר על ביצועים.

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

איך מתבצעת התאמה אוטומטית לעומס

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

התכונה 'שינוי גודל אוטומטי' ב-Bigtable קובעת את מספר הצמתים הנדרש על סמך המאפיינים הבאים:

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

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

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

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

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

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

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

פרמטרים של התאמה אוטומטית לעומס

כשיוצרים או עורכים אשכול ובוחרים באפשרות של התאמה אוטומטית לעומס (automatic scaling), מגדירים את הערכים של יעד ניצול המעבד (CPU), מספר הצמתים המינימלי ומספר הצמתים המקסימלי. אפשר להגדיר את יעד השימוש באחסון או להשאיר אותו כברירת המחדל, שהיא 50% (2.5TB ל-SSD ו-8TB ל-HDD).

פרמטר תיאור
יעד ניצול המעבד (CPU)

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

מספר הצמתים המינימלי

המספר הנמוך ביותר של צמתים שאליהם Bigtable יקטין את גודל האשכול. אם האפשרות 2x node scaling מופעלת (ברירת המחדל ב-Enterprise Plus), הערך חייב להיות מספר זוגי. הערך הזה חייב להיות גדול מאפס, ולא יכול להיות נמוך מ-10% מהערך שקבעתם למספר המקסימלי של הצמתים. לדוגמה, אם המספר המקסימלי של הצמתים הוא 40, המספר המינימלי של הצמתים צריך להיות לפחות 4. דרישת ה-10% היא מגבלה קשיחה. מידע נוסף זמין במאמר בנושא קביעת מספר הצמתים המינימלי.
מספר הצמתים המקסימלי

המספר הכי גבוה של צמתים שאתם רוצים לאפשר את הגדלת הקיבולת של האשכול עד אליו. אם האפשרות 2x node scaling מופעלת (ברירת המחדל ב-Enterprise Plus), הערך חייב להיות מספר זוגי. הערך הזה צריך להיות גדול מאפס ושווה למספר המינימלי של הצמתים או גדול ממנו. הערך לא יכול להיות גדול פי 10 מהמספר שבוחרים כמספר המינימלי של הצמתים. הדרישה של פי 10 היא מגבלה קשיחה. מידע נוסף זמין במאמר בנושא קביעת המספר המקסימלי של הצמתים.
יעד ניצול נפח האחסון

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

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

הגדרת התאמה אוטומטית לעומס

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

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

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

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

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

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

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

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

אחוז SSD HDD
80% ‫4TB או 4,096GiB ‫12.8TB או 13,107GiB
70% ‫3.5TB או 3,584GiB ‫11.2TB או 11,468GiB
60% ‫3TB או 3,072GiB ‫9.6TB או 9,830GiB
50% ‫2.5TB או 2,560GiB ‫8TB או 8,192GiB

אחסון מדורג והתאמה לעומס (autoscaling)

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

  • מהדורת Enterprise: המגבלה היא 32 TB לכל צומת.
  • מהדורת Enterprise Plus: המגבלה היא 32 TB לכל צומת או 64 TB לכל צומת, אם מופעלת הגדלת קיבולת של 2x.

לדוגמה, באשכול SSD, אם מגדירים יעד לניצול נפח האחסון של 2.5TB ‏ (50%) לכל צומת, והשימוש בגישה לא תדירה גבוה מספיק כדי להגדיל את נפח האחסון הנדרש עם אחסון מדורג מעל המגבלה, Bigtable מוסיף צמתים. זה קורה גם אם השימוש ב-SSD נשאר בטווח של 50% מהיעד.

הטבלה הבאה עוזרת להבין איך התאמה אוטומטית לעומס ממליצה על מספר צמתים על סמך השימוש ב-SSD והשימוש בגישה לא תדירה:

תרחיש יעד לניצול נפח האחסון אחוז הניצול שימוש ב-SSD שימוש בגישה לא תכופה שילוב של אחסון SSD ואחסון לגישה לא תדירה מספר הצמתים המומלץ
השימוש ב-SSD נמצא בטווח היעד ואין שימוש בגישה לא תדירה. 5TB 100% פחות מ-5TB 0 TB פחות מ-5TB 1
השימוש ב-SSD חורג ממגבלת האחסון לכל צומת. 5TB 100% ‫6TB 0 TB ‫6TB 2
השימוש ב-SSD והשימוש בגישה לא תדירה הם במסגרת מגבלת האחסון הרב-שכבתי. 5TB 100% 5TB ‫27TB ‫32TB 1
השימוש בנפח האחסון לפי רמות חורג ממגבלת נפח האחסון לפי רמות. 5TB 100% 5TB ‫28TB ‫33TB 2
השימוש ב-SSD כמעט חורג מיעד השימוש ב-SSD, ואין שימוש בגישה לא תדירה. ‫3TB 60% ‫3TB 0 TB ‫3TB 1
השימוש ב-SSD כמעט חורג מיעד השימוש ב-SSD, והשימוש באחסון מדורג כמעט חורג ממגבלת האחסון המדורג. ‫3TB 60% ‫3TB ‫29TB ‫32TB 1
השימוש ב-SSD חורג מיעד האחסון ב-SSD, ואין שימוש בגישה לא תדירה. ‫2.5TB 50% 4TB 0 TB 4TB 2
השימוש בנפח האחסון חורג מהמגבלה של נפח האחסון הארגוני. ‫2.5TB 50% 2TB ‫31TB ‫33TB 2

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

קביעת המספר המקסימלי של צמתים

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

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

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

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

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

אם הפעלתם אחסון מדורג, אתם צריכים לקחת בחשבון את מגבלת האחסון של 32 TB לכל צומת (Enterprise) או 64 TB (Enterprise Plus). גם אם השימוש ב-SSD נמוך, נפח גדול של נתונים ברמת הגישה הלא תדירה יכול להפעיל שינוי גודל של הצומת.

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

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

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

נפח אחסון SSD לכל אשכול המספר המקסימלי הקטן ביותר של צמתים
25TB 10
‫35TB 14
‫50TB 20

אחרי שהאשכול יופעל עם התאמה אוטומטית לעומס, עוקבים אחרי האשכול ומוודאים שהערך שבוחרים למספר המקסימלי של הצמתים גבוה לפחות כמו recommended number of nodes for CPU target ו-recommended number of nodes for storage target.

קביעת המספר המינימלי של צמתים

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

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

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

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

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

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

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

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

חשבון לשכפול

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

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

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

בקרת גישה

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

מעקב

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

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

  • bigtable.googleapis.com/cluster/autoscaling/min_node_count
  • bigtable.googleapis.com/cluster/autoscaling/max_node_count
  • bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_cpu
  • bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_storage
  • רק ב-Enterprise Plus: ‏ bigtable.googleapis.com/memory_layer/request_unit_usage

רישום ביומן

‫Bigtable פולט יומן ביקורת של אירוע מערכת בכל פעם שהוא משנה את גודל האשכול. הרשומה ביומן אמורה להיראות כך:

Grew from 9 to 10 nodes to maintain CPU utilization at 60%.

אפשר לראות את יומני האירועים של המערכת בנושא שינוי גודל אוטומטי בדף הסקירה הכללית של אשכול Bigtable במסוף Google Cloud . אפשר גם לראות אותם באמצעות Logs Explorer:

  1. מנווטים אל Logs Explorer:

    כניסה לדף Logs Explorer

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

  2. בשדה Query, מזינים את הערך הבא:

    resource.type="audited_resource" resource.labels.service="bigtableadmin.googleapis.com"
resource.labels.method="AutoscaleCluster"

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

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

מידע נוסף על צפייה ביומנים זמין במאמר בנושא Cloud Logging.

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