ניהול זמינות גבוהה ב-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. אם הסטטוס של 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 תומך במעבר לגיבוי (failover) אוטומטי וידני. מעבר לגיבוי אוטומטי מופעל כברירת מחדל.

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

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

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

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

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

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

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

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

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

    spec:
  availability:
    enableAutoFailover: false

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

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

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