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

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

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

סקירה כללית

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

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

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

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

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

כדי לבדוק את הסטטוס של זמינות גבוהה באשכול מסד נתונים, בודקים את הסטטוס שלו 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. הערך המינימלי הוא 4 והערך המקסימלי הוא 86400 (שווה ל-24 שעות).

  • ‫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