ארכיטקטורת עזר של מסד נתונים של Oracle בניהול עצמי

ארכיטקטורת העזר הזו מספקת מסגרת מושגית לפריסה ולהפעלה של מסדי נתונים של Oracle בניהול עצמי ב-Google Distributed Cloud‏ (GDC) עם בידוד פיזי (air-gapped). הפתרון הזה מאפשר לכם לשמור על עומסי עבודה (workloads) קריטיים של מסדי נתונים באמצעות Oracle Database Operator for Kubernetes הרשמי באשכולות רגילים.

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

תכונות ויכולות

הפתרון מספק כמה רכיבים פונקציונליים מרכזיים לניהול מסד נתונים:

  • ניהול אוטומטי של מחזור החיים: אפשר להשתמש ב-Oracle Database Operator כדי להפוך לאוטומטי את ההקצאה, השכפול, התיקון וההגדרה של מסדי נתונים של מופע יחיד (SIDB).
  • זמינות גבוהה: תמיכה משולבת ב-Oracle Data Guard כדי לספק שכפול סינכרוני או אסינכרוני ויכולות מעבר אוטומטי לגיבוי. יש תמיכה בזמינות גבוהה בתחום אחד.
  • שילוב של אחסון קבוע: אפשר להשתמש בצורה חלקה בסוגי האחסון הקיימים של GDC standard-rwo לקובצי מסד נתונים כדי להבטיח עמידות של הנתונים.
  • ניהול מאובטח של קובצי אימג': תמיכה בשיקוף של קובצי אימג' של קונטיינרים של Oracle מ-Oracle Container Registry למרשמי Harbor מקומיים, כולל סריקה משולבת של נקודות חולשה.
  • ניראות מאוחדת: מנגנונים מובנים לייצוא מדדי מסד נתונים ל-Prometheus ולהעברת יומני התראות באמצעות דפוסי sidecar.
  • רשת גמישה: תמיכה במאזני עומסים פנימיים וחיצוניים ברמה 4 כדי לחשוף נקודות קצה של מסדי נתונים בצורה מאובטחת.

עקרונות אדריכליים

  • גישה בניהול עצמי: מספקת את מסגרת הארכיטקטורה לפריסה ולניהול של עומסי עבודה של Oracle.
  • פעולות מבוססות-ענן: שימוש בתבנית אופרטור לניהול עומסי עבודה עם שמירת מצב, כדי להבטיח עקביות בסביבות שונות.
  • עמידות שמתחשבת במסד הנתונים: מתן עדיפות לשכפול ברמת מסד הנתונים (Data Guard) על פני שכפול ברמת התשתית כדי להבטיח עקביות לוגית ושחזור מהיר יותר.
  • עיצוב שמתמקד באבטחה: עומד בדרישות של מערכות מבודדות באמצעות שימוש במאגרי מידע מקומיים, סריקת תמונות חובה ומדיניות רשת מפורשת לכל התנועה במסד הנתונים.

ארכיטקטורה

הארכיטקטורה ממחישה את הקשר בין אשכול התקנים של GDC, האופרטור של Oracle Database, משאבי ה-SIDB והתשתית התומכת כמו Harbor.

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

מושגים וטכנולוגיות

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

תשתית ופלטפורמה

  • אשכול סטנדרטי של GDC: סביבת המחשוב הראשית שבה נמצאים Oracle Operator ותאי מסד הנתונים.
  • ‫Harbor Registry: מקור מידע מקומי ומאובטח לכל תמונות הקונטיינרים. הוא מספק סריקה אוטומטית כדי לוודא שאין בתמונות נקודות חולשה ידועות.
  • אחסון קבוע: סוגי האחסון standard-rwo של GDC מספקים את האחסון הבסיסי של בלוקים שנדרש לקובצי נתונים של Oracle, ליומני פעולות חוזרות ולקובצי בקרה באמצעות PersistentVolumeClaim.

שירותים ולוגיקה

  • ‫Oracle Database Operator: הגורם האחראי על מעקב אחרי משאבים מותאמים אישית כמו SingleInstanceDatabase ו-DataguardBroker. הוא מתרגם אותם לאובייקטים רגילים של Kubernetes, כולל StatefulSets לקבוצות Pod של מסדי נתונים ושירותים לרשת.
  • מסד נתונים של מופע יחיד (SIDB): פריסה מבוססת-קונטיינר שמשתמשת בארכיטקטורת ריבוי הדיירים של Oracle‏ (CDB/PDB). אפשר לפרוס כמה מופעי SIDB נפרדים או לאחד עומסי עבודה על ידי יצירת כמה מסדי נתונים ניתנים להרכבה (PDB) בתוך SIDB יחיד.
  • ‫Data Guard Broker: מתזמר מעברי תפקידים בין מופעים ראשיים למופעי המתנה. הוא מנהל את תוויות התפקידים במסד הנתונים, למשל database.oracle.com/role: primary, שמשמשות את שירותי Kubernetes כדי לנתב את תעבורת הנתונים בצורה נכונה אחרי יתירות כשל.
  • מאזן עומסים ברמה 4: מספק כתובות IP יציבות לקישוריות למסד הנתונים.

זרימת נתונים וממשקים

  • ‫SQL*Net (יציאה 1521): הפרוטוקול העיקרי לקישוריות של אפליקציות.
  • כלי לייצוא נתונים של ניראות: חושף נקודת קצה (endpoint) של /metrics ל-Prometheus.
  • יומני התראות: יומני התראות רגילים של מסד נתונים נשלחים אל stdout לאיסוף על ידי סוכן הרישום ביומן של GDC.
  • ערוצי RMAN: משמשים משאבי CronJob להזרמת גיבויים לאחסון אובייקטים שתואם ל-S3.

לתשומת ליבכם

  • מדרגיות וביצועים:
    • צריך להגדיר את גודל הצמתים של העובדים עם 8 מעבדי CPU וירטואליים ו-32GiB RAM לפחות עבור עומסי עבודה של ייצור.
    • השימוש ב-nodeSelector או ב-taints and tolerations הוא שיטה מומלצת להקצאת צמתים ספציפיים לעומסי עבודה של מסדי נתונים.
    • הביצועים תלויים במידה רבה באחסון הבסיסי. מומלץ להשתמש ב-standard-rwo עם IOPS גבוה.
  • ניהול משאבים ורישוי:
    • הפתרון הזה מבוסס על מודל של החברה מביאה את הרישיון שלה (BYOL).
    • תכונות מתקדמות כמו Transparent Data Encryption‏ (TDE), דחיסה מתקדמת ו-Active Data Guard (המתנה לקריאה בלבד) דורשות רישיונות ספציפיים של מהדורת Enterprise.
    • אפשר להשתמש במהדורה החינמית של Oracle Database לפיתוח ולבדיקות.
  • זמינות ומהימנות:
    • זמינות גבוהה מושגת באמצעות הגדרות של Data Guard באזור יחיד, שבהן מופעים ראשיים וממתינים נמצאים באותו מרחב שמות.
    • שימוש בשירות עם בורר לתווית התפקיד primary מבטיח הפניה חלקה של הלקוח במהלך מעבר לגיבוי ללא שינויים בצד הלקוח.
    • כדי להגן על הנתונים, הפתרון משתמש ב-RMAN לגיבויים בדלי תואם ל-S3.
  • ניהול תפעולי:
    • האופרטור מפשט את הפריסה, אבל כדי לבצע פעולות יומיומיות כמו כוונון ושחזורים מורכבים, עדיין צריך מומחיות בניהול מסדי נתונים.
    • מומלץ להשתמש ב-sidecar container כדי להעביר יומני מעקב וביקורת מפורטים שלא נשלחים אל stdout.

החלטה בנוגע לעיצוב

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

‫Data Guard לעומת שכפול ברמת האחסון

‫Data Guard הוא מנגנון הזמינות הגבוהה כי הוא מודע למסד הנתונים. הגישה הזו מגנה מפני השחתה לוגית ומבטיחה אפס אובדן נתונים במצב זמינות מקסימלית, על ידי אימות בלוקים לפני שהם נכתבים למצב המתנה. השימוש בשיטה הזו דורש רישוי נוסף למהדורת Enterprise, והיא כרוכה ביותר תקורה של הגדרות בהשוואה לצילומי מצב של נפחים, אבל היא מספקת את העקביות הנדרשת לעומסי עבודה קריטיים.

ניהול שירותים למאזני עומסים

כברירת מחדל, הגדרת הפרמטר loadBalancer: true במפרט SingleInstanceDatabase יוצרת באופן אוטומטי שירות איזון עומסים חיצוני. במאזן עומסים פנימי, צריך ליצור באופן ידני משאב שירות נפרד כדי לכלול את ההערה networking.gke.io/load-balancer-type: "Internal" הנדרשת. הגישה הידנית הזו מספקת שליטה הצהרתית בהערות ובתיוגים שאולי לא נחשפים על ידי שירות ברירת המחדל שמנוהל על ידי האופרטור.

אסטרטגיית יכולת הצפייה של קבצי sidecar ליומנים

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

הנחות ומגבלות

הנחות

  • בסביבה יש מופע Harbor שהוגדר מראש וזמין לאירוח תמונות.
  • התוסף Cert-manager מותקן מראש באשכול הרגיל כדי לטפל באישורים של ה-webhook של האופרטור.
  • מאגר אובייקטים שתואם ל-S3 זמין ליעדי גיבוי של RMAN.

מגבלות

  • זמינות גבוהה (HA) באזור יחיד: הגדרות של זמינות גבוהה נתמכות באזור יחיד.
  • ללא Oracle RAC: הפתרון לא כולל תמיכה ב-Real Application Clusters ‏ (RAC), אלא מתמקד ב-Single Instance וב-Data Guard.
  • רק אשכולות רגילים: הפתרון מאומת לאשכולות רגילים של GDC ולא נתמך באשכולות משתמשים משותפים.

המאמרים הבאים