ניהול יתירות כשל

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

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

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

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

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

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

המסוף

  1. במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.

    פתיחת רשימת המכונות

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

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

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

  4. לוחצים על Save. מופיעה תיבת דו-שיח לאישור.

  5. קוראים בעיון את האזהרות בתיבת הדו-שיח לאישור, פועלים לפי ההוראות בתיבת הדו-שיח ולוחצים על Continue.

gcloud

  1. אם אתם לא יודעים מהו מזהה המכונה, תוכלו להשתמש בפקודה bigtable instances list כדי להציג רשימה של המכונות בפרויקט: 

    gcloud bigtable instances list

  2. אם אתם לא יודעים מהם מזהי האשכולות של המכונה, תוכלו להשתמש בפקודה bigtable clusters list כדי להציג את רשימת האשכולות במכונה: 

    gcloud bigtable clusters list --instances=INSTANCE_ID

    מחליפים את INSTANCE_ID במזהה הקבוע של המכונה.

  3. אם אתם לא יודעים מה המזהה של פרופיל האפליקציה, אתם יכולים להשתמש בפקודה bigtable app-profiles list כדי להציג רשימה של פרופילי האפליקציות של המכונה: 

    gcloud bigtable app-profiles list --instance=INSTANCE_ID

    מחליפים את INSTANCE_ID במזהה הקבוע של המכונה.

  4. משתמשים בפקודה bigtable app-profiles update כדי לשנות את האשכול שבו משתמש פרופיל האפליקציה:

    gcloud bigtable app-profiles update APP_PROFILE_ID \
    --instance=INSTANCE_ID \
    --route-to=CLUSTER_ID

    מזינים את הפרטים הבאים:

    • APP_PROFILE_ID: המזהה הקבוע של פרופיל האפליקציה.
    • INSTANCE_ID: המזהה הקבוע של המכונה
    • ‫CLUSTER_ID: מזהה האשכול שאליו צריך לנתב את כל הבקשות. הדגל הזה מפעיל ניתוב לאשכול יחיד.

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

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

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

ביצוע מעבר אוטומטי לגיבוי במקרה של כשל

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

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

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

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

איך עוקבים אחרי מכונה של Bigtable