התאמה אוטומטית לעומס (Automatic scaling)
בדף הזה מוסבר איך פועלת ההתאמה האוטומטית לעומס. לפני שאתם קוראים את הדף הזה, כדאי שתכירו את הסקירה הכללית של Bigtable ואת המכונות, האשכולות והצמתים.
ב-Bigtable, מכונות הן קונטיינרים של אשכולות, שהם משאבים ספציפיים למיקום שמטפלים בבקשות. בכל אשכול יש צומת אחד או יותר, שהם משאבי מחשוב שמשמשים לניהול הנתונים. כשיוצרים אשכול במכונה, בוחרים באפשרות הקצאת צמתים ידנית או באפשרות התאמה לעומס (autoscaling).
כשמקצים צמתים באופן ידני, מספר הצמתים באשכול נשאר קבוע עד שמשנים אותו. כשהתאמה אוטומטית לעומס מופעלת, Bigtable עוקב אחרי האשכול באופן רציף ומתאים באופן אוטומטי את מספר הצמתים באשכול לפי הצורך. התאמה אוטומטית לעומס פועלת גם באשכולות HDD וגם באשכולות SSD, בכל האזורים של Bigtable.
אפשר להגדיר התאמה אוטומטית לעומס במסוף Google Cloud , באמצעות gcloud או באמצעות ספריית הלקוח של Cloud Bigtable ל-Java.
מתי כדאי להשתמש בהתאמה לעומס (autoscaling)
ברוב המקרים, מומלץ להפעיל התאמה אוטומטית לעומס. היתרונות של התאמה אוטומטית לעומס כוללים:
- עלויות – התאמה אוטומטית לעומס יכולה לעזור לכם לבצע אופטימיזציה של העלויות, כי Bigtable מפחית את מספר הצמתים באשכול בכל פעם שאפשר. כך תוכלו להימנע מהקצאת יתר.
- ביצועים – התאמה אוטומטית לעומס מאפשרת ל-Bigtable להוסיף באופן אוטומטי צמתים לאשכול כשעומס העבודה משתנה או כשיש עלייה בדרישות לאחסון נתונים. כך אפשר לשמור על יעדי הביצועים של עומסי העבודה, כי לאשכול יש מספיק צמתים כדי לעמוד בדרישות של ניצול המעבד (CPU) והאחסון.
- אוטומציה – התאמה אוטומטית לעומס מפחיתה את מורכבות הניהול. אתם לא צריכים לעקוב אחרי גודל האשכול ולשנות אותו באופן ידני, או לכתוב אפליקציה שתבצע את המשימות האלה, כי שירות Bigtable מטפל בהן בשבילכם.
יכול להיות שהתאמה אוטומטית לעומס לא תעבוד טוב בסוגי עומסי העבודה הבאים, כי למרות ש-Bigtable מוסיף צמתים במהירות כשתעבורת הנתונים גדלה, יכול לקחת זמן לאזן את הצמתים הנוספים.
- תנועה מתפרצת
- עומסי עבודה פתאומיים באצווה
אם העליות החדות בשימוש צפויות או מתוזמנות באופן קבוע, אתם יכולים להשתמש בהתאמה אוטומטית לעומס ולשנות את ההגדרות לפני הפרצים המתוכננים. פרטים נוספים זמינים במאמר עיכוב בזמן איזון מחדש של צמתים.
שכבת זיכרון והתאמה לעומס (autoscaling)
אשכולות בתוך מכונות של מהדורת Enterprise Plus יכולים להשתמש בשכבה בזיכרון. רמת הזיכרון הפנימי של Bigtable משתמשת בהתאמה אנכית מנוהלת לחלוטין של קצב הנתונים, שמאפשרת לאשכולות להגיב כמעט באופן מיידי לעליות חדות בתנועה של קריאת נקודות. התאמה אנכית לעומס משנה אוטומטית כל צומת בהתאם לדרישות של עומס העבודה, ומשתלבת עם התאמה אוטומטית לעומס ב-Bigtable. מידע נוסף על מגבלות ההתאמה לעומס (scaling) האנכית ועל קיבולת ה-throughput של שכבת ה-in-memory זמין במאמר הסבר על הביצועים.
כשהקיבולת של שכבת הזיכרון הפנימי מגיעה למגבלה, Bigtable משנה באופן אוטומטי את קנה המידה של האשכול בצורה אופקית בהתאם להגדרות של ההתאמה האוטומטית לעומס.
איך פועלת התאמה אוטומטית לעומס (autoscaling)
התאמה אוטומטית לעומס היא תהליך של שינוי קנה המידה או הגודל של אשכול באופן אוטומטי, על ידי הוספה או הסרה של צמתים. כשמפעילים התאמה אוטומטית לעומס, Bigtable מתאים באופן אוטומטי את גודל האשכול. כשיש תנודות בעומס העבודה או בצורכי האחסון של האשכול, Bigtable מרחיב אנכית בהתאם לעומס את האשכול ומוסיף לו צמתים, או מצמצם אנכית בהתאם לעומס את האשכול ומסיר ממנו צמתים.
ההתאמה האוטומטית לעומס ב-Bigtable קובעת את מספר הצמתים הנדרש על סמך המאפיינים הבאים:
- יעד ניצול המעבד (CPU)
- יעד ניצול נפח האחסון
- מספר הצמתים המינימלי
- מספר הצמתים המקסימלי
כל מאפיין התאמה לעומס יוצר מספר מומלץ של צמתים, ו-Bigtable משתמש באופן אוטומטי במספר הגבוה ביותר. לדוגמה, אם האשכול צריך 10 צמתים כדי לעמוד ביעד של ניצול נפח האחסון, אבל 12 צמתים כדי לעמוד ביעד של ניצול ה-CPU, Bigtable ישנה את קנה המידה של האשכול ל-12 צמתים.
ככל שמספר הצמתים משתנה, Bigtable מבצע אופטימיזציה של האחסון באופן רציף, ומאזן מחדש את הנתונים בין הצמתים כדי לוודא שהתנועה מתפזרת באופן שווה ושאף צומת לא עמוס מדי.
אחרי הגדלת האשכול, Bigtable מאזן מחדש באופן אוטומטי את הצמתים באשכול כדי להגיע לביצועים אופטימליים. כל הבקשות ממשיכות להגיע לאשכול בזמן שהסילומיות והאיזון מחדש מתבצעים. מידע נוסף זמין בקטע מגבלות התאמה לעומס (scaling).
אם אשכול הוגדל למספר המקסימלי של צמתים והיעד של ניצול המעבד חורג, יכול להיות שלבקשות יהיה זמן אחזור ארוך או שהן ייכשלו. אם אשכול הוגדל למספר המקסימלי של צמתים והייתה חריגה ממגבלת ניצול האחסון, בקשות הכתיבה ייכשלו. פרטים נוספים על מגבלות האחסון זמינים במאמר אחסון לכל צומת.
כשמוסיפים צומת לאשכול קטן, כמו אשכול עם צומת אחד, יכול להיות שתבחינו בעלייה זמנית בזמן האחזור בזמן שהאשכול מאזן את עצמו מחדש. הסיבה לכך היא שהצומת הנוסף מכפיל באופן יחסי את גודל האשכול. באופן דומה, אם גודל האשכול יורד משני צמתים לצומת אחד, יכול להיות שתהיה השהיה מסוימת.
כשמצמצמים את האשכול, הצמתים מוסרים בקצב איטי יותר מאשר כשמרחיבים אותו, כדי למנוע השפעה על זמן האחזור. פרטים נוספים זמינים במאמר בנושא מגבלות התאמה לעומס (scaling).
פרמטרים של התאמה אוטומטית לעומס (Automatic scaling)
כשיוצרים או עורכים אשכול ובוחרים בהתאמה אוטומטית לעומס, מגדירים את הערכים של יעד ניצול ה-CPU, מספר הצמתים המינימלי ומספר הצמתים המקסימלי. אתם יכולים להגדיר את יעד ניצול האחסון או להשאיר אותו בברירת המחדל, שהיא 50% (2.5TB ל-SSD ו-8TB ל-HDD).
| פרמטר | תיאור |
|---|---|
| יעד ניצול המעבד (CPU) |
אחוז מקיבולת המעבד (CPU) של האשכול. הערך יכול להיות בין 10% ל-80%. כשהשימוש ב-CPU באשכול חורג מהיעד שהגדרתם, Bigtable מוסיף מיד צמתים לאשכול. כשהניצול של המעבד נמוך משמעותית מהיעד, Bigtable מסיר צמתים. מידע נוסף זמין במאמר הגדרת היעד של ניצול המעבד (CPU). |
| מספר הצמתים המינימלי |
מספר הצמתים המינימלי שאליו 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) במסמך הזה. |
הגדרת התאמה לעומס (autoscaling)
בקטע הזה מוסבר איך לבחור את הפרמטרים של ההתאמה האוטומטית לעומס. אחרי שמגדירים את הערכים הראשוניים, עוקבים אחרי האשכול ומשנים את המספרים לפי הצורך.
הגדרת יעד לניצול ה-CPU
הגדירו את יעד ניצול המעבד (CPU) בהתאם לעומס העבודה הייחודי שלכם. היעד האופטימלי לאשכול תלוי בדרישות של עומס העבודה לגבי זמן האחזור וקצב הנתונים. מידע נוסף זמין במאמר תכנון הקיבולת של Bigtable.
באופן כללי, אם אתם מבחינים בזמן אחזור גבוה באופן בלתי קביל, כדאי להוריד את יעד ניצול המעבד (CPU).
הגדרת יעד לניצול נפח האחסון
אם האפליקציה שלכם רגישה לזמן אחזור, אתם צריכים לשמור על ניצול אחסון נמוך מ-60%. אם האפליקציה לא רגישה לזמן אחזור, אפשר לבחור יעד ניצול אחסון של 70% או יותר. מידע נוסף זמין במאמר תכנון הקיבולת של Bigtable.
במקרה של התאמה אוטומטית לעומס, ניצול האחסון מבוטא במספר הבייטים של האחסון הדחוס לכל צומת בדיסק, ולא באחוזים. יעד ניצול נפח האחסון מוגדר לכל צומת, אבל חל על כל האשכול. מגבלות הקיבולת לצמתים הן 5TB לכל צומת לאחסון SSD ו-16TB לכל צומת לאחסון HDD.
בטבלה הבאה מוצגים יעדי נפח האחסון לפי אחוזי היעד של ניצול נפח האחסון. במסוף Google Cloud הערך הוא ב-TB לכל צומת, וב-CLI של gcloud, ב-API ובספריות הלקוח של Cloud Bigtable הערך הוא מספר שלם ב-GiB לכל צומת.
| אחוז | 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)
אחסון מדורג (גרסת טרום-השקה (Preview)) לא משפיע על ההתאמה האוטומטית לעומס (automatic scaling) של SSD, שמתוארת בקטע הגדרת היעד לניצול נפח האחסון במסמך הזה. כשמפעילים גישה לא תכופה כחלק משכבות האחסון, ההתאמה האוטומטית לעומס גם מוודאת שהנפח המשולב של ה-SSD ושל האחסון לגישה לא תכופה לא חורג ממגבלת האחסון לכל צומת, בהתאם למהדורה. כשהמגבלה מגיעה, Bigtable משתנה באופן אוטומטי.
- מהדורת Enterprise: המגבלה היא 32TB לכל צומת.
- מהדורת Enterprise Plus: המגבלה היא 32TB לכל צומת או 64TB לכל צומת.
לדוגמה, באשכול SSD, אם מגדירים יעד של ניצול נפח אחסון של 2.5TB (50%) לכל צומת, והשימוש בגישה לא תכופה גבוה מספיק כדי להגדיל את נפח האחסון הנדרש עם אחסון מדורג מעבר למגבלה, Bigtable מוסיף צמתים. זה קורה גם אם השימוש ב-SSD נשאר בטווח של יעד ה-50%.
הטבלה הבאה עוזרת להבין איך ההתאמה האוטומטית לעומס ממליצה על מספר הצמתים על סמך השימוש ב-SSD והשימוש בגישה לא תכופה:
| תרחיש | יעד ניצול נפח האחסון | אחוז הניצול | שימוש ב-SSD | שימוש בגישה לא תכופה | אחסון משולב של SSD וגישה לא תכופה | מספר הצמתים המומלץ |
|---|---|---|---|---|---|---|
| השימוש ב-SSD נמצא בטווח היעד ואין שימוש בגישה לא תכופה. | 5TB | 100% | פחות מ-5TB | 0 TB | פחות מ-5TB | 1 |
| השימוש ב-SSD חורג ממגבלת האחסון לכל צומת. | 5TB | 100% | 6 TB | 0 TB | 6 TB | 2 |
| השימוש ב-SSD ובגישה לא תכופה נמצאים במסגרת מגבלת האחסון השכבתי. | 5TB | 100% | 5TB | 27 TB | 32 TB | 1 |
| נפח האחסון הנדרש חורג ממגבלת האחסון של הרמה. | 5TB | 100% | 5TB | 28TB | 33 TB | 2 |
| השימוש ב-SSD כמעט חורג מיעד השימוש ב-SSD, ואין שימוש בגישה לא תכופה. | 3 TB | 60% | 3 TB | 0 TB | 3 TB | 1 |
| השימוש ב-SSD כמעט חורג מיעד השימוש ב-SSD, והשימוש באחסון מדורג כמעט חורג ממגבלת האחסון המדורג. | 3 TB | 60% | 3 TB | 29TB | 32 TB | 1 |
| השימוש ב-SSD חורג מיעד האחסון ב-SSD, ואין שימוש בגישה לא תכופה. | 2.5TB | 50% | 4TB | 0 TB | 4TB | 2 |
| השימוש חורג ממגבלת האחסון של הרמה. | 2.5TB | 50% | 2TB | 31TB | 33 TB | 2 |
מידע נוסף על אחסון מדורג זמין במאמר סקירה כללית על אחסון מדורג.
קביעת המספר המקסימלי של צמתים
הערך שתבחרו כמספר המקסימלי של צמתים צריך להיות מספר הצמתים שהאשכול צריך כדי לטפל בעומס העבודה הכבד ביותר, גם אם אתם לא מצפים להגיע לנפח הזה רוב הזמן. Bigtable אף פעם לא מגדיל את מספר הצמתים מעבר למה שצריך. אפשר גם לחשוב על המספר הזה כמספר הצמתים המקסימלי שאתם מוכנים לשלם עליו. לפרטים על הערכים המקובלים, ראו פרמטרים של התאמה לעומס (autoscaling).
המספר המקסימלי צריך לאפשר גם את יעד ניצול המעבד (CPU) שהגדרתם וגם את יעד ניצול האחסון שהוגדר על ידי Bigtable.
אם אתם משנים אשכול מהקצאה ידנית להתאמה אוטומטית לעומס, חפשו את המספר הגבוה ביותר של צמתים שהיו באשכול בחודש האחרון בערך. המספר המקסימלי של ההתאמה האוטומטית לעומס צריך להיות לפחות המספר הזה.
אם אתם מפעילים התאמה אוטומטית לעומס באשכול חדש במכונה קיימת, השתמשו במדדים מאשכולות אחרים במכונה כנקודת ייחוס.
אם יש לכם עומס עבודה חדש ואתם לא בטוחים איך הוא יגדל, אתם יכולים להעריך את מספר הצמתים שאתם צריכים כדי לעמוד ביעד המובנה של ניצול האחסון, ואז לשנות את המספר בהמשך.
אם הפעלתם אחסון מדורג, אתם צריכים להביא בחשבון את מגבלת האחסון של 32TB לכל צומת (Enterprise) או 64TB (Enterprise Plus). גם אם השימוש ב-SSD נמוך, נפח גדול של נתונים בשכבת הגישה בתדירות נמוכה יכול להפעיל התאמה לעומס של הצומת.
כדי להגיע למספר הזה, מעריכים את כמות הנתונים שמתכננים לאחסן באשכול, ואז מחלקים את המספר הזה ביעד ניצול האחסון של סוג האחסון שבו משתמשים.
לדוגמה, אם אתם מאחסנים 10TB באשכול SSD, אתם יכולים לחלק 10TB ב-2.5TB, שהוא יעד ניצול האחסון שמוגדר כברירת מחדל לאשכולות SSD שמשתמשים בהתאמה אוטומטית לעומס. התוצאה היא 4, כלומר 4 הוא מספר הצמתים שיכולים לטפל בכמות הנתונים הזו, והמספר המקסימלי צריך להיות גבוה יותר.
בדוגמאות הבאות, שבהן נעשה שימוש באותה נוסחה, מוצג מספר הצמתים שאתם עשויים להזדקק להם עבור כמה נפחי אחסון לדוגמה:
| אחסון SSD לכל אשכול | המספר המקסימלי הקטן ביותר של צמתים |
|---|---|
| 25TB | 10 |
| 35 TB | 14 |
| 50 TB | 20 |
אחרי שהאשכול פועל עם התאמה אוטומטית לעומס, עוקבים אחרי האשכול ומוודאים שהערך שנבחר למספר המקסימלי של הצמתים הוא לפחות בגובה של recommended number of nodes for CPU target ושל recommended number of nodes for storage target.
קביעת המספר המינימלי של הצמתים
אפשר להגדיר את המינימום לערך נמוך כמו 1 כדי לוודא ש-Bigtable יוכל לצמצם את הגודל למינימום האפשרי, וכך לחסוך בעלויות. האשכול אף פעם לא קטן מדי, כי Bigtable מונע באופן אוטומטי את הירידה של מספר הצמתים מתחת למינימום שנדרש כדי לשמור על יעדי הניצול של המעבד (CPU) והאחסון. בקטע פרמטרים של התאמה לעומס (Autoscaling) מפורטים הערכים שאפשר להזין.
עם זאת, בהרבה מקרים תרצו להגדיר ערך גבוה יותר. כדאי לבחור מספר גבוה יותר או להגדיל את מספר הצמתים המינימלי במצבים הבאים:
- יש לכם אירוע שיא של הרחבת העומס, שבו אתם צופים עלייה זמנית בתנועה, ואתם רוצים לוודא שיש לכם מספיק קיבולת.
- האפליקציה שולחת תנועה עם קפיצות חדות. כשמוסיפים צמתים חדשים, Bigtable מאזן מחדש באופן אוטומטי את הצמתים החדשים. התהליך הזה יכול להימשך כמה דקות, ולכן בדרך כלל עדיף לנקוט גישה שמרנית ולבחור מינימום גבוה יותר, כדי שהאשכול יוכל להתמודד עם העליות החדות בצורה חלקה.
- אתם מגדילים את המספר המקסימלי של הצמתים. המספר המינימלי חייב להיות תמיד 10% או פחות מהמספר המקסימלי של הצמתים. לדוגמה, אם מגדירים את הערך המקסימלי ל-30, צריך להגדיר את הערך המינימלי ל-3 לפחות.
אם מגדילים את הערך של מספר הצמתים המינימלי באשכול, Bigtable מנסה מיד לשנות את קנה המידה של האשכול למינימום החדש. האילוצים הרגילים חלים, אבל אם באזור מסוים אין צמתים, לא יוקצו צמתים נוספים כדי לעמוד במינימום שהוגדר. Bigtable ממשיך לנסות להוסיף צמתים ויוצר רשומה ביומן הביקורת לכל ניסיון שנכשל, עד שהוא מצליח לשנות את קנה המידה של האשכול למספר המינימלי החדש של הצמתים. במצב כזה, Bigtable לא משנה את הערך שהוגדר. כתוצאה מכך, יכול להיות שמספר הצמתים באשכול יהיה נמוך מהמינימום עד להשלמת ההתאמה לעומס.
שפרו את ההגדרות
אחרי שמפעילים את ההתאמה האוטומטית לעומס, חשוב לעקוב אחרי ההתנהגות שלה ולשנות את ההגדרות לפי הצורך. אפשר להשתמש במדדי המעקב כדי לבדוק את הדברים הבאים:
- מספר הצמתים המומלץ: שימו לב למדדים
recommended_node_count_for_cpuו-recommended_node_count_for_storage. המדדים האלה מציינים את המספר האידיאלי של צמתים, בהתאם ליעדי הניצול של המעבד (CPU) והאחסון, בהתאמה. - מספר הצמתים שהוקצו: השוו בין מספר הצמתים המומלץ למספר הצמתים שהוקצו בפועל. אם באשכול שלכם נעשה שימוש עקבי ביותר צמתים מהמומלץ, כדאי לשקול להפחית את מספר הצמתים המינימלי כדי להוזיל את העלויות.
- מספר הצמתים המקסימלי: ודאו שמספר הצמתים המקסימלי גבוה מספיק כדי לאפשר לאשכול להתרחב בהתאם לדרישה. אם אתם רואים שהאשכול מגיע לעיתים קרובות למספר הצמתים המקסימלי, הגדילו אותו כדי לספק קיבולת גדולה יותר.
אפשר גם לשנות את יעד ניצול המעבד (CPU) כדי לשפר את הביצועים. אם אתם מבחינים בבעיות של זמן אחזור, יכול להיות שתצטרכו להקטין את יעד ניצול המעבד (CPU) כדי לוודא שהאשכול יגדיל את קנה המידה בצורה אגרסיבית יותר כשהביקוש יעלה. לעומת זאת, אם לאשכול שלכם יש באופן עקבי הקצאת יתר והזמן האחזור סביר, אתם יכולים לשקול להגדיל את יעד המעבד (CPU).
חשבון לרפליקציה
במכונה שמשתמשת ברפליקציה, הגדרות ההתאמה האוטומטית לעומס והפעילות של כל אשכול לא תלויות באשכולות האחרים במכונה. צריך להגדיר את מצב ההתאמה לעומס לכל אשכול במכונה.
באופן כללי, במכונות משוכפלות צריך להפעיל התאמה אוטומטית לעומס בכל אשכול במכונה. הגדרת ההתאמה האוטומטית לעומס תהיה בדרך כלל זהה לכל אשכול במכונה, אבל יכולה להיות שונה בהתאם לדרישות של תרחיש השימוש, עומס העבודה והביצועים של כל אשכול.
מכיוון שאשכולות במכונה משוכפלת מבצעים עבודה נוספת לניהול השכפול, כדאי לבחור עבורם מספר מקסימלי גבוה יותר של צמתים מאשר למכונה עם אשכול יחיד. מידע נוסף זמין במאמר רפליקציה וביצועים.
בקרת גישה
כדי להגדיר התאמה אוטומטית לעומס, אתם צריכים להיות ישות מורשית בתפקיד עם ההרשאות create ו-update באשכול ובמכונה שאתם מגדירים.
מעקב
ב-Bigtable יש כמה מדדים שעוזרים להבין איך פועלת ההתאמה האוטומטית לעומס (scaling) ב-Bigtable, כשהיא מגדילה ומקטינה את קנה המידה כדי לעמוד בדרישות של עומסי העבודה. המדדים גם יכולים לעזור לכם להעריך אם ההגדרות שלכם אופטימליות לעמידה בדרישות של עומס העבודה והעלות של העסק. לדוגמה, אם אתם רואים שמספר הצמתים באשכול קרוב לעיתים קרובות למספר המקסימלי של צמתים, כדאי לשקול להגדיל את המספר המקסימלי. איך עוקבים אחרי המשאבים של Bigtable?
המדדים הבאים מוצגים בתרשימים בדף הסקירה הכללית של האשכול במסוף Google Cloud . אפשר גם לראות את המדדים האלה באמצעות Cloud Monitoring.
bigtable.googleapis.com/cluster/autoscaling/min_node_countbigtable.googleapis.com/cluster/autoscaling/max_node_countbigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_cpubigtable.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:
עוברים אל Logs Explorer:
בוחרים את הפרויקט המתאים ב- Google Cloud .
בשדה Query, מזינים את הטקסט הבא:
resource.type="audited_resource" resource.labels.service="bigtableadmin.googleapis.com" resource.labels.method="AutoscaleCluster"לוחצים על Run query.
בחלונית Query results מוצגים היומנים מהשעה האחרונה.
מידע נוסף על צפייה ביומנים זמין במאמר Cloud Logging.