הגישה הזו מועילה למשתמשים כי היא מספקת את התכונות המתקדמות של AlloyDB Omni – למשל, מהירות גבוהה פי שניים בעומסי עבודה (workloads) עם טרנזקציות ומהירות גבוהה פי 100 בשאילתות ניתוח נתונים בהשוואה ל-PostgreSQL רגיל – תוך שימוש ב-Kubernetes לניהול אוטומטי, להרחבת קנה מידה ולניידות בסביבות שונות כמו מרכזי נתונים או עננים פרטיים.
משתמשים באפשרות הפריסה של כלי לניהול קונטיינרים כשצריך מסד נתונים של PostgreSQL עם ביצועים גבוהים ויכולת התאמה לעומס, אבל אי אפשר להשתמש בשירות ענן מנוהל במלואו בגלל דרישות רגולטוריות או ריבונות נתונים, או כשצריך לפעול בסביבות לא מקוונות. אפשרות הפריסה של כלי לתזמור קונטיינרים מתאימה גם למודרניזציה של מסדי נתונים מדור קודם בלי להתחייב להעברה מלאה לענן, ועדיין ליהנות משיטות הפעלה מבוססות-ענן.
אפשר גם ליצור אשכולות עם הצפנת נתונים שקופה (TDE), שמאפשרת לכם לאבטח את כל הנתונים במצב מנוחה באשכולות AlloyDB Omni בלי לשנות את קוד האפליקציה. אם מפעילים את התכונה הזו, כל הנתונים הקריטיים במצב מנוחה מוצפנים באופן אוטומטי לפני שהם נכתבים בדיסק. כך תוכלו לעמוד בדרישות התאימות ולהגן על מידע רגיש.
תרחישים לדוגמה
בוחרים באפשרות הפריסה של כלי לתזמור קונטיינרים כשצריך אחת או יותר מהיכולות הבאות:
- הקצאת הרשאות אוטומטית וניהול מחזור חיים מבוסס-API.
- זמינות גבוהה (HA) שניתנת להגדרה כדי לכוונן את מנגנוני המעבר לגיבוי (failover).
- תמיכה ב-Sidecar לשילוב סוכני גיבוי או ניטור של Enterprise.
- מאגרי קריאה משתנים להתאמת נפח הפעולות לקריאה בלבד.
- איזון עומסים באמצעות איגום חיבורים בצד השרת (PgBouncer).
- תמיכה בפלטפורמה וזמינות ב-Marketplace של Google Distributed Cloud ו-OpenShift.
- תוכנית התאוששות מאסון (DR) בין אזורים כדי ליצור מסדי נתונים במצב המתנה באשכולות, במרכזי נתונים ובאזורים מרוחקים.
איך זה עובד
AlloyDB Omni משתמש ב-Kubernetes באמצעות אופרטור ייעודי של AlloyDB Omni Kubernetes כדי להפוך לאוטומטי את הפריסה והניהול של מכונות AlloyDB Omni באשכול Kubernetes.
הסבר על אפשרות הפריסה של כלי תזמור קונטיינרים:
- פריסת אופרטור: האופרטור AlloyDB Omni מותקן באשכול Kubernetes (שיכול להיות ב- Google Cloud(GKE), ב-AWS (EKS), ב-Azure (AKS), ב-OpenShift או בפריסה מקומית).
- משאבים בהתאמה אישית: האופרטור של AlloyDB Omni מגדיר הגדרות של משאבים בהתאמה אישית (CRD) ב-Kubernetes, בעיקר
DBCluster. משתמשים יוצרים משאבים מותאמים אישית שלDBClusterומנהלים אותם באמצעות כלים סטנדרטיים של Kubernetes, כמוkubectl., כדי ליצור אינטראקציה עם AlloyDB Omni. ניהול מחזור חיים: האופרטור של AlloyDB Omni מחפש את המשאבים המותאמים אישית האלה ומבצע אוטומציה של המשימות המורכבות שקשורות לניהול מחזור החיים של מופע מסד נתונים של AlloyDB Omni.
מחזור החיים הזה כולל את השלבים הבאים:
- הקצאת משאבים: הגדרת מופע מסד הנתונים על סמך המפרט של
DBCluster. - זמינות גבוהה: הגדרה וניהול של מנגנוני מעבר לגיבוי (failover) כדי להבטיח את הזמינות של מסד הנתונים.
- התאוששות מאסון: הפעלת תכונות כמו DR באזורים שונים עם מסדי נתונים במצב המתנה.
- גיבויים: ניהול תהליכי גיבוי.
- עדכונים: טיפול בתחזוקה עם זמן השבתה קצר ועדכוני גרסה.
- אבטחה: שילוב תכונות כמו Active Directory לאימות.
- הקצאת משאבים: הגדרת מופע מסד הנתונים על סמך המפרט של
אוטומציה: באמצעות האופרטור AlloyDB Omni, אתם מקבלים ניהול מחזור חיים מבוסס-API עבור AlloyDB Omni, מה שמפשט את הפעולות ומאפשר לכם לנהל את מופעי מסד הנתונים באופן הצהרתי, בהתאם לאפליקציות אחרות של Kubernetes.
האופרטור AlloyDB Omni זמין דרך חבילות שונות, כולל תרשימי Helm וחבילות OLM ל-Kubernetes ול-OpenShift. למידע נוסף, ראו אפשרויות ההורדה וההתקנה הזמינות של AlloyDB Omni.
המאמרים הבאים
- הרשמה ל-AlloyDB Omni
- בוחרים אפשרות להורדה או להתקנה של AlloyDB ל-PostgreSQL.
- בחירת גרסאות תואמות של אופרטור Kubernetes ושל אשכול מסד נתונים.
- בוחרים ארכיטקטורת הפניה לזמינות של AlloyDB Omni.
- התקנה של AlloyDB Omni ב-Kubernetes.