כלקוחות AlloyDB Omni, אתם אחראים להגדיר ולהפעיל את AlloyDB Omni כדי לוודא שעומסי העבודה שלכם יפיקו את הערך המרבי מהשירות.
| שכבה | באחריות Google | באחריות הלקוח | |
|---|---|---|---|
| חומרה ומארח | תשתית פיזית | לציין את דרישות המינימום ואת הדרישות המומלצות (אם רלוונטי) | הקצאת שרתים פיזיים, מכונות וירטואליות או מכשירי קצה כמו חשמל, קירור וחומרה. |
| מערכת ההפעלה (OS) של המארח | לציין את דרישות המינימום ואת הדרישות המומלצות (אם רלוונטי) | ניהול ליבת Linux, החלת תיקוני אבטחה של מערכת ההפעלה והקשחת צומתי המארח. | |
| Kubernetes | ניהול אשכולות | לציין את דרישות המינימום ואת הדרישות המומלצות (אם רלוונטי) | ניהול האשכול על בסיס יומי – כולל שדרוגים – בהתאם לשיטות המומלצות בתחום. |
| אחסון (CSI/PV) | מציינים את דרישות המינימום והדרישות המומלצות (אם רלוונטי) | הקצאת מחלקת האחסון וניהול המכשירים שעומדים בבסיס שלה. ל-AlloyDB Omni נדרש התקן בלוקים, לכן חשוב לבחור מחלקה של התקן בלוקים. | |
| רשתות (CNI) | לציין את דרישות המינימום ואת הדרישות המומלצות (אם רלוונטי) | הקצאה וניהול של שכבת הרשת – לדוגמה, רשתות של פודים, בקרי כניסה, מאזני עומסים וכללי חומת אש בין צמתים. | |
| בקרת גישה מבוססת-תפקידים (RBAC) | מציינים את חשבונות השירות, התפקידים וקישורי התפקידים שנדרשים לאופרטור של AlloyDB Omni Kubernetes. | מחילים את הכללים האלה של בקרת גישה מבוססת-תפקידים (RBAC) על האשכול, ומוודאים שהם תואמים למדיניות האבטחה הפנימית. כדי לגשת למשאבים של AlloyDB Omni, צריך ליצור תפקידי RBAC נוספים וקישורי תפקידים. | |
| ניהול סודות | קריאת סודות סטנדרטיים של Kubernetes כדי להקצות משאבים, כמו משתמש postgres ראשוני. |
ליצור, לאבטח ולשנות את הסודות של Kubernetes באשכול. | |
| ניהול אישורים | להסתמך על סודות סטנדרטיים של Kubernetes ועל cert-manager
לשילוב אישורים. |
התקנה, הגדרה וניהול של מחזור החיים של cert-manager. |
|
| תוכנת אופרטור | פיתוח והשקה | לפתח את הלוגיקה של אופרטור AlloyDB Omni ואת ה-CRD, ולפרסם קובצי אימג' של קונטיינרים, תרשימי Helm וחבילות OLM. | אין. הלקוחות יכולים להשתמש בארטיפקטים שמאוחסנים ב-Artifact Registry לפריסות שלהם. |
| התקנה ומחזור חיים | צריך לספק תיעוד וארטיפקטים של שדרוג. | ||
| המנוע של מסד הנתונים | קובץ בינארי של מסד נתונים | מספקים את קובצי האימג' של קונטיינר AlloyDB עם אופטימיזציות קנייניות כמו מנוע מבוסס-עמודות והאצת AI. | אין. |
| תיקון | הפצת תיקוני אבטחה ועדכוני גרסאות ראשיות ומשניות למנוע. לספק הוראות שדרוג. | כדאי לתזמן שדרוגים בהקדם האפשרי, בהתאם לרמת הקריטיות של כל גרסה. | |
| ניהול משתמשים |
|
|
|
| ניהול נתונים | גיבויים | מספקים את ה-CRD של `BackupPlan` ו-`Backup` ואת הלוגיקה לניהול הגיבויים, שמנוהלים באמצעות pgBackrest עם שילוב תואם ל-S3. |
מגדירים את לוחות הזמנים של הגיבוי ואת תקופת השמירה, ומקצים את קטגוריית האחסון המקומית, S3 או Cloud Storage. |
| זמינות גבוהה (HA) | לספק את הלוגיקה של יתירות כשל אוטומטית ומנגנוני תיקון. | צריך להקצות מספיק צמתים ואזורים כדי לספק יעד המתנה לתמיכה במעבר לגיבוי. | |
| הצפנה (במנוחה) | אין. | כדאי לנהל את ההצפנה בשכבת האחסון כדי לוודא שהיא עונה על הדרישות שלכם. | |
| הצפנה (בזמן ההעברה) | לספק mTLS לרכיבי מפעיל פנימיים ולהגדיר TLS בצד השרת לחיבורים בין המשתמש למסד הנתונים. | להתחבר למסד הנתונים באמצעות לקוחות TLS מאובטחים ולנהל את תשתית האישורים הבסיסית. | |
| ניראות (observability) | מדדים | חשיפת מדדים של מסד נתונים פנימי באמצעות נקודת קצה שתואמת ל-Prometheus. | פורסים ומנהלים את כלי הגירוד באמצעות Prometheus, Open Telemetry או פתרונות תואמים אחרים ומערך האחסון שלהם. לפקח על התקינות הכוללת של המערכת. |
| רישום ביומן | לכתוב יומני ביקורת ו-PostgreSQL לקבצים בדיסק במאגר, וגם לבצע רוטציה שלהם. | פריסת כלי איסוף יומנים – לדוגמה, Fluentd ו-Fluent Bit – כדי לשלוח יומנים לבק-אנד של אחסון (כמו Splunk או ELK). חשוב לוודא שחולצו אוספי היומנים כדי לשמור את היומנים למשך חודש אחד לפחות, כפי שמומלץ. | |
| המחשה | לספק מדדים לדוגמה ולוחות בקרה של יומנים כדי לעקוב אחרי עומסי עבודה רגילים. | פורסים את כלי ההמחשה (למשל Grafana) ועוקבים אחרי התקינות שלו. ליצור מרכזי בקרה ולשלב אותם במשימות התפעוליות היומיומיות. | |
| שליחת התראות | ללא | לנהל את צינור עיבוד הנתונים של ההתראות – לדוגמה, שילוב עם PagerDuty. | |
| תמיכה | פתרון בעיות | מתן תמיכה בבאגים בתוכנה ובשגיאות במנוע. כדי לקבל את התמיכה הזו, צריך מינוי לרישיון. | מתן תמיכה ראשונית באמצעות מסמכים ומאגר ידע. לנפות באגים שקשורים לתשתית. |