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

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

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

סקירה כללית

כדי להפעיל זמינות גבוהה באשכול מסד הנתונים, צריך להגדיר את AlloyDB Omni Kubernetes operator ליצירת עותקים משוכפלים של מסד הנתונים הראשי. אופרטור 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. אם הסטטוס של HAReady הוא True, אז הזמינות הגבוהה מופעלת ועובדת באשכול. אם הערך הוא False, המשמעות היא שההגדרה מופעלת אבל לא מוכנה כי היא בתהליך של הגדרה.

כדי לבדוק את הסטטוס של HAReady באמצעות שורת הפקודה kubectl, מריצים את הפקודה הבאה:

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

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

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

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

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

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

  • הזמן בין בדיקות התקינות (ברירת המחדל היא 30 שניות)

  • מספר בדיקות התקינות הרצופות שנכשלו (ברירת המחדל היא 3)

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

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

אופרטור 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 מפעיל מעבר אוטומטי לגיבוי.

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

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

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

  • ‫HEALTHCHECK_PERIOD: ערך של מספר שלם שמציין את מספר השניות להמתנה בין כל בדיקת תקינות. ערך ברירת המחדל הוא 30. הערך המינימלי הוא 1 והערך המקסימלי הוא 86400 (שווה ליום).

  • ‫AUTOFAILOVER_TRIGGER_THRESHOLD: ערך של מספר שלם שמייצג את מספר הכשלים הרצופים בבדיקת תקינות לפני הפעלת מעבר לגיבוי. ערך ברירת המחדל הוא 3. הערך המינימלי הוא 0. אין ערך מקסימלי. אם השדה הזה מוגדר לערך 0, המערכת תשתמש בערך ברירת המחדל 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) או פעילויות מתוכננות אחרות שדורשות החלפה בין תפקידי מסד הנתונים הראשי והרפליקה המשנית למקרה חירום.

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

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

    kubectl get instances.alloydbomni.internal.dbadmin.goog

תיקון אוטומטי של מכונה במצב המתנה

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

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

השבתת התיקון האוטומטי של המופע

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

כדי להשבית את התיקונים האוטומטיים:

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

    spec:
  availability:
    enableAutoHeal: false

שינוי הגדרות ההפעלה של התיקון האוטומטי

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

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

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

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

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

  • ‫AUTOHEAL_TRIGGER_THRESHOLD: ערך של מספר שלם שמייצג את מספר הכשלים הרצופים בבדיקת תקינות לפני הפעלת תיקון. ערך ברירת המחדל הוא 5. הערך המינימלי הוא 2 בגלל שגיאות זמניות חד-פעמיות אפשריות בבדיקות תקינות של מצב המתנה.

פתרון בעיות בתיקון מופעים

אם אתם משתמשים במספר גדול של אשכולות מסדי נתונים באשכול Kubernetes יחיד, או אם יש לכם אשכולות מסדי נתונים עם הקצאת יתר של משאבים, יכול להיות שהתיקון האוטומטי יגרום לחוסר זמינות של האופרטור AlloyDB Omni או של אשכולות מסדי הנתונים. אם מופיעה שגיאה שמתחילה ב-HealthCheckProber: health check for instance failed והשגיאה מתייחסת לזמן קצוב לתפוגה או לבעיה בהתחברות, נסו את הפתרונות המומלצים הבאים:

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

  • HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

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

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

  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