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

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

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

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

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

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

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

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

ארכיטקטורה

הארכיטקטורה ממחישה את הקשר בין אשכול התקנים של 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 כדי לנתב את תעבורת הנתונים בצורה נכונה אחרי יתירות כשל.
  • מאזן עומסים L4: מספק כתובות IP יציבות לקישוריות למסד הנתונים.

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

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

לתשומת ליבכם

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

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

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

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

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

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

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

אסטרטגיית ניראות של sidecars ליומנים

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

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

הנחות

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

מגבלות

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

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