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

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

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

הגדרת מפרט של זמינות גבוהה

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

DBCluster:
  metadata:
    ...
  spec:
    ...
    readOnlyPort: READ_ONLY_PORT
    availability:
      numberOfStandbys: NUMBER_OF_STANDBYS
      enableStandbyAsReadReplica: true
      enableAutoFailover: true
      enableAutoHeal: true
      replayReplicationSlotsOnStandbys: true
      healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
      autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD
      autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

מחליפים את המשתנים הבאים:

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

  • (אופציונלי) READ_ONLY_PORT: היציאה במאזן העומסים או כתובת ה-IP הווירטואלית שמשמשת לנקודת הקצה של הגיבוי לקריאה בלבד. ערך ברירת המחדל הוא 5433 (היציאה הראשית ועוד 1).

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

  • (אופציונלי) AUTOFAILOVER_TRIGGER_THRESHOLD: מספר הפעמים שבהן בדיקת התקינות יכולה להיכשל לפני שמתבצעת העברה אוטומטית לשרת גיבוי. ערך ברירת המחדל הוא 3. הערך המינימלי הוא 0, אבל אם הערך מוגדר כ-0, ‏ AlloyDB Omni משתמש בערך ברירת המחדל.

    מעבר גיבוי אוטומטי מתרחש אם בדיקת תקינות נכשלת AUTOFAILOVER_TRIGGER_THRESHOLD פעמים או למשך HEALTHCHECK_PERIOD * AUTOFAILOVER_TRIGGER_THRESHOLD שניות (90 שניות כברירת מחדל).

  • (אופציונלי) AUTOHEAL_TRIGGER_THRESHOLD: מספר הפעמים שבהן בדיקת תקינות יכולה להיכשל לפני שהתיקון האוטומטי מתחיל. ערך ברירת המחדל הוא 5. הערך המינימלי הוא 0, אבל אם הערך מוגדר כ-0, ‏ AlloyDB Omni משתמש בערך ברירת המחדל.

    מתבצעת התאוששות אוטומטית אם בדיקת תקינות נכשלת AUTOHEAL_TRIGGER_THRESHOLD פעמים או למשך HEALTHCHECK_PERIOD * AUTOHEAL_TRIGGER_THRESHOLD שניות.

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

כשמגדירים את enableStandbyAsReadReplica: true, מאזן העומסים (כתובת ה-IP הווירטואלית של HAProxy ו-Keepalived) חושף באופן אוטומטי נקודת קצה ייעודית לקריאה בלבד, בנוסף לנקודת הקצה הראשית לקריאה ולכתיבה.

‫HAProxy מעביר תנועה בין מערכות גיבוי פעילות באופן הבא:

  • מריץ בדיקות תקינות בכל הצמתים במצב המתנה באמצעות GET /isstandby.
  • מפיץ שאילתות קריאה בין מצבי המתנה פעילים באמצעות איזון עומסים leastconn.
  • עדכון אוטומטי של הניתוב במקרה של מעבר לגיבוי ללא ניתוק של חיבורי הלקוח לטופולוגיית הגיבוי החדשה.

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

alloydbctl

alloydbctl get -d "DEPLOYMENT_SPEC" -t DBCluster -n DBCLUSTER_NAME

מחליפים את המשתנים הבאים:

Ansible

  1. תצור פלייבוק של Ansible לתפקיד google.alloydbomni_orchestrator.status. לדוגמה, status.yaml:

    - name: STATUS_PLAYBOOK_NAME
      hosts: localhost
      vars:
        ansible_user: ANSIBLE_USER
        ansible_ssh_private_key_file: ANSIBLE_SSH_PRIVATE_KEY_FILE
      roles:
      - role: google.alloydbomni_orchestrator.status
    

    מחליפים את המשתנים הבאים:

    • ‫STATUS_PLAYBOOK_NAME: השם של קובץ ה-playbook של Ansible. לדוגמה, My cluster status.

    • ‫ANSIBLE_USER: משתמש במערכת ההפעלה שמשמש את Ansible כדי להתחבר לצמתים של AlloyDB Omni.

    • ‫ANSIBLE_SSH_PRIVATE_KEY_FILE: המפתח הפרטי שמשמש את Ansible לחיבור לצמתים של AlloyDB Omni באמצעות SSH.

  2. מריצים את הפלייבוק:

    ansible-playbook status.yaml -i "DEPLOYMENT_SPEC" -e resource_type=DBCluster \
      -e resource_name=DBCLUSTER_NAME

    מחליפים את המשתנים הבאים:

נקודות הקצה מדווחות בקטע status.primary.endpoints:

    - Read-Write: VIRTUAL_IP:5432
    - Read-Only: VIRTUAL_IP:5433

החלת מפרט DBCluster

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

alloydbctl

alloydbctl apply -d "DEPLOYMENT_SPEC" -r "DBCLUSTER_SPECIFICATION"

מחליפים את המשתנים הבאים:

Ansible

ansible-playbook DBCLUSTER_PLAYBOOK -i "DEPLOYMENT_SPEC" \
      -e resource_spec="DBCLUSTER_SPECIFICATION"

מחליפים את המשתנים הבאים:

  • ‫RESTORE_PLAYBOOK: הנתיב ל-playbook שיצרתם עבור ה-CRD של DBCluster.

  • ‫DEPLOYMENT_SPEC: הנתיב למפרט הפריסה שיצרתם בקטע התקנת רכיבי AlloyDB Omni.

  • ‫DBCLUSTER_SPECIFICATION: הנתיב למפרט DBCluster שיצרתם בקטע יצירת אשכול.

מעבר לגיבוי למכונה במצב המתנה

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

במהלך מעבר בין שרתים מתבצעות הפעולות הבאות:

  1. כלי התזמור של AlloyDB Omni מעביר את השרת הראשי למצב אופליין.

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

  3. כלי התזמור של AlloyDB Omni ממיר את השרת הראשי לשרת המתנה.

  4. ‫AlloyDB Omni מפעיל את מצב ההמתנה שהומר לאחרונה.

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

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

  1. מוודאים שהמכונות הראשיות והמכונות במצב המתנה תקינות.

  2. מוודאים שהזמינות הגבוהה status.phase היא Ready.

    alloydbctl

    alloydbctl get -d "DEPLOYMENT_SPEC" -t DBCluster -n DBCLUSTER_SPECIFICATION -o yaml

    מחליפים את המשתנים הבאים:

    Ansible

    ansible-playbook status.yaml -i DEPLOYMENT_SPEC -e resource_type=DBCluster \
      -e resource_name=DBCLUSTER_SPECIFICATION

    מחליפים את המשתנים הבאים:

  3. יוצרים מפרט Switchover בפורמט הבא:

    Switchover:
      metadata:
        name: SWITCHOVER_NAME
      spec:
        dbClusterRef: DBCLUSTER_NAME
        newPrimary: NEW_PRIMARY_NAME
    

    מחליפים את המשתנים הבאים:

    • ‫SWITCHOVER_NAME: השם של מפרט Switchover. לדוגמה: my-switchover-1. השם הזה צריך להיות ייחודי בכל פעם שמבצעים מעבר לגיבוי.

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

    • (אופציונלי) NEW_PRIMARY_NAME: הוא מכונה במצב המתנה שהופכת למופע הראשי החדש. כדי למפות את שם המופע למארח, אפשר לעיין בשדה instanceList בסטטוס של DBCluster שאליו יש הפניה.

  4. אם אתם משתמשים ב-Ansible, אתם צריכים ליצור קובץ playbook עבור Switchoverהמפרט.

    - name: SWITCHOVER_PLAYBOOK_NAME
      hosts: localhost
      vars:
        ansible_user: ANSIBLE_USER
        ansible_ssh_private_key_file: ANSIBLE_SSH_PRIVATE_KEY_FILE
      roles:
      - role: google.alloydbomni_orchestrator.switchover
    

    מחליפים את המשתנים הבאים:

    • ‫SWITCHOVER_PLAYBOOK_NAME: השם של קובץ ה-playbook של Ansible. לדוגמה, My Switchover.

    • ‫ANSIBLE_USER: משתמש במערכת ההפעלה שמשמש את Ansible כדי להתחבר לצמתים של AlloyDB Omni.

    • ‫ANSIBLE_SSH_PRIVATE_KEY_FILE: המפתח הפרטי שמשמש את Ansible לחיבור לצמתים של AlloyDB Omni באמצעות SSH.

  5. מחילים את המפרט של Switchover.

    alloydbctl

    alloydbctl apply -d "DEPLOYMENT_SPEC" -r "SWITCHOVER_SPECIFICATION"

    מחליפים את המשתנים הבאים:

    • ‫DEPLOYMENT_SPEC: הנתיב למפרט הפריסה שיצרתם בקטע התקנת רכיבי AlloyDB Omni.

    • ‫SWITCHOVER_SPECIFICATION: הנתיב למפרט Switchover שיצרתם בשלב שלוש.

    Ansible

    ansible-playbook SWITCHOVER_PLAYBOOK -i "DEPLOYMENT_SPEC" \
      -e resource_spec="SWITCHOVER_SPECIFICATION"

    מחליפים את המשתנים הבאים:

    • ‫SWITCHOVER_PLAYBOOK: הנתיב ל-playbook שיצרתם עבור ה-CRD שלכם בSwitchoverשלב 4.

    • ‫DEPLOYMENT_SPEC: הנתיב למפרט הפריסה שיצרתם בקטע התקנת רכיבי AlloyDB Omni.

    • ‫SWITCHOVER_SPECIFICATION: הנתיב למפרט Switchover שיצרתם בשלב שלוש.

מאזן עומסים לזמינות גבוהה

מאזן העומסים (HAProxy) משיג זמינות גבוהה על ידי שיוך הצמתים שלו ל-Keepalived ולכתובת IP וירטואלית. ‫Keepalived משתמש בפרוטוקול Virtual Router Redundancy (VRRP) כדי לשלוט ב-IP וירטואלי צף. אפליקציות לקוח של מסד נתונים מתחברות לכתובת ה-IP הווירטואלית הזו במקום לכתובת ה-IP של צומת מסד הנתונים.

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

כדי ליצור בחירה יציבה, Keepalived מקצה עדיפויות VRRP לצמתים של אשכול מסד הנתונים. צומת מאזן העומסים הראשון מקבל את התפקיד הראשי עם עדיפות גבוהה יותר ב-Keepalived – לדוגמה, 110. צמתים עוקבים פועלים כמשניים עם עדיפות נמוכה יותר – לדוגמה, 100.

כדי לוודא שה-IP הווירטואלי מצביע על צומת תקין, Keepalived מריץ בדיקות תקינות רציפות כל שתי שניות. כדי לאמת את המצב של תהליך HAProxy‏ systemd. אם שירות HAProxy בשרת הראשי נכשל, Keepalived מעביר את כתובת ה-IP הווירטואלית לצומת משני תקין.

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

הגדרת מאזן העומסים

כדי להגדיר את כתובת ה-IP הווירטואלית לצמתים של מאזן העומסים, מוסיפים את השדה dbLoadBalancerOptions לשדה primarySpec במפרט DBCluster:

DBCluster:
  spec:
    primarySpec:
      ...
      dbLoadBalancerOptions:
        onprem:
          loadBalancerIP: "VIRTUAL_IP"
          loadBalancerType: "internal"
          loadBalancerInterface: "VIRTUAL_IP_INTERFACE"

מחליפים את המשתנים הבאים:

  • ‫VIRTUAL_IP: כתובת IP סטטית שמשמשת ל-IP וירטואלי צף. אפליקציות לקוח של מסד נתונים משתמשות בכתובת ה-IP שמוגדרת כאן. כדי לוודא ש-Keepalived יכול לשדר בהצלחה בקשות ARP ללא תמורה, כתובת ה-IP הזו צריכה להיות זמינה, לא יכולה להיות כתובת לולאה חוזרת, ובמקרה של פריסה מקומית, היא שייכת לאותה רשת משנה כמו הממשקים של הצומת הראשי.

  • ‫VIRTUAL_IP_INTERFACE: ממשק הרשת שבו מוגדר VIRTUAL_IP. ערך ברירת המחדל הוא eth0.