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

בוחרים גרסת תיעוד:

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

סקירה כללית

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

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