ניהול זמינות גבוהה ב-Kubernetes

בחירת גרסה של מאמר העזרה:

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

סקירה כללית

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

הפעלת זמינות גבוהה

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

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

כדי להפעיל זמינות גבוהה:

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

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

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

  2. מחילים מחדש את המניפסט.

השבתת זמינות גבוהה

כדי להשבית את הזמינות הגבוהה:

  1. מגדירים את numberOfStandbys ל-0 במניפסט של האשכול:

    spec:
  availability:
    numberOfStandbys: 0

  2. מחילים מחדש את המניפסט.

אימות של HA באשכול מסד נתונים

כדי לראות את סטטוס הזמינות הגבוהה הנוכחי של אשכול מסד נתונים, בודקים את HAReadyהתנאי של הסטטוס של האשכול. אם הערך הזה status מוגדר כ-True, אז HA מוגדר ועובד באשכול מסדי הנתונים.

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

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים.

  • ‫NAMESPACE: מרחב השמות של אשכול מסד הנתונים.

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

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

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

האופרטור AlloyDB Omni תומך במעבר אוטומטי וידני ליתירות כשל. מעבר אוטומטי ליתירות כשל מופעל כברירת מחדל.

המעבר לגיבוי מתבצע בסדר הבא:

  1. האופרטור של AlloyDB Omni מעביר את מופע מסד הנתונים הראשי למצב אופליין.

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

  3. האופרטור AlloyDB Omni מוחק את מופע מסד הנתונים הראשי הקודם.

  4. האופרטור AlloyDB Omni יוצר רפליקה חדשה במצב המתנה.

השבתת מעבר אוטומטי לגיבוי

כברירת מחדל, מעבר אוטומטי לגיבוי (failover) מופעל באשכולות של מסדי נתונים.

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

  1. מגדירים את enableAutoFailover ל-false במניפסט של האשכול:

    spec:
  availability:
    enableAutoFailover: false

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

אתם יכולים להשתמש בהגדרות כדי לשנות את המעבר האוטומטי לגיבוי לכל אשכול מסדי נתונים.

האופרטור של AlloyDB Omni מבצע בדיקות תקינות רגילות כל 30 שניות. אם מופעל סף ההפעלה של מעבר אוטומטי לגיבוי (failover) במופע, האופרטור של AlloyDB Omni מפעיל מעבר אוטומטי לגיבוי.

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

```yaml
spec:
  availability:
    autoFailoverTriggerThreshold: TRIGGER_THRESHOLD
```

מחליפים את מה שכתוב בשדות הבאים:

  • ‫TRIGGER_THRESHOLD: ערך של מספר שלם שמייצג את מספר הכשלים הרצופים בבדיקת תקינות לפני הפעלת מעבר לגיבוי. ערך ברירת המחדל הוא 3.

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

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

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫FAILOVER_NAME: שם המשאב, לדוגמה failover-1.

  • ‫NAMESPACE: מרחב השמות של משאב המעבר לגיבוי, שצריך להיות זהה למרחב השמות של אשכול מסד הנתונים שאליו הוא מתייחס.

  • ‫DB_CLUSTER_NAME: השם של אשכול מסדי הנתונים שרוצים לבצע לו מעבר לגיבוי.

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

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫FAILOVER_NAME: השם שהקציתם למשאב המעבר לגיבוי בעת היצירה שלו.

  • ‫NAMESPACE: מרחב השמות של אשכול מסד הנתונים.

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

מעבר למופע במצב המתנה

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

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

האופרטור AlloyDB Omni תומך במעבר ידני.

המעבר גורם לרצף האירועים הבא:

  1. האופרטור של AlloyDB Omni מעביר את מופע מסד הנתונים הראשי למצב אופליין.

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

  3. האופרטור של AlloyDB Omni מעביר את מופע מסד הנתונים הראשי הקודם לרפליקה במצב המתנה.

ביצוע מעבר לגיבוי (failover)

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

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

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     newPrimary: STANDBY_REPLICA_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SWITCHOVER_NAME: שם למשאב המעבר הזה, לדוגמה, switchover-1.

  • ‫DB_CLUSTER_NAME: השם של מופע מסד הנתונים הראשי שאליו מתייחסת פעולת המעבר.

  • ‫STANDBY_REPLICA_NAME: השם של מופע מסד הנתונים שרוצים להגדיר כראשי חדש.

    כדי לזהות את השם של העותק המשוכפל במצב המתנה, מריצים את הפקודה הבאה: posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

שימוש בעותק המתנה כמכונה לקריאה בלבד

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

  1. משנים את המניפסט של אשכול מסד הנתונים כדי להגדיר את הפרמטר enableStandbyAsReadReplica לערך true.

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. מחילים מחדש את המניפסט.

  3. מוודאים שנקודת הקצה לקריאה בלבד מדווחת בשדה status של האובייקט DBCluster:

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

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

      Status:
  [...]
  Primary:
    [...]
    Endpoints:
      Name: Read-Write
      Value: 10.128.0.81:5432
      Name: Read-Only
      Value: 10.128.0.82:5432