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

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

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

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

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

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

עקרונות ארכיטקטוניים

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

ארכיטקטורה

הארכיטקטורה ממחישה את הקשר בין אשכול GDC רגיל, Oracle Database Operator, משאבי SIDB והתשתית התומכת כמו Harbor.

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

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

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

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

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

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

  • ‫Oracle Database Operator: הבקר שאחראי על מעקב אחרי משאבים בהתאמה אישית כמו SingleInstanceDatabase ו-DataguardBroker. הוא מתאים אותם לאובייקטים רגילים של Kubernetes, כולל StatefulSets לפודים של מסדי נתונים ושירותים לרשתות.
  • ‫Single Instance Database (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 ו-tolerations כדי להקצות צמתים ספציפיים לעומסי עבודה של מסדי נתונים.
    • הביצועים תלויים מאוד באחסון הבסיסי, ומומלץ להשתמש ב-standard-rwo עם IOPS גבוה.
  • ניהול משאבים ורישוי:
    • הפתרון הזה פועל לפי מודל "החברה מביאה את הרישיון שלה" (BYOL).
    • כדי להשתמש בתכונות מתקדמות כמו Transparent Data Encryption‏ (TDE), ‏ Advanced Compression ו-Active Data Guard (מצב המתנה לקריאה בלבד), צריך רישיונות ספציפיים ל-Enterprise Edition.
    • אפשר להשתמש במהדורת Oracle Database Free לפיתוח ולבדיקה.
  • זמינות ואמינות:
    • כדי להשיג זמינות גבוהה, משתמשים בהגדרות של Data Guard באזור יחיד, שבהן המכונות הראשיות והמכונות במצב המתנה נמצאות באותו מרחב שמות.
    • שימוש בשירות עם בורר לתווית התפקיד primary מבטיח הפניה חלקה של הלקוח במהלך יתירות כשל, בלי שינויים בצד הלקוח.
    • כדי להגן על הנתונים, הפתרון משתמש ב-RMAN לגיבויים בקטגוריה שתואמת ל-S3.
  • ניהול תפעולי:
    • למרות שהאופרטור מפשט את הפריסה, פעולות יומיומיות כמו כוונון ושחזורים מורכבים עדיין דורשות מומחיות בניהול מסדי נתונים.
    • מומלץ להשתמש בקונטיינר משני (sidecar) כדי להעביר יומני מעקב ויומני ביקורת מפורטים שלא נשלחים אל stdout.

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

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

‫Data Guard לעומת רפליקציה ברמת האחסון

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

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

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

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

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

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

הנחות

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

מגבלות

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

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