‫AlloyDB Omni באמצעות סקירה כללית של כלי התיזמור RPM

בוחרים גרסת תיעוד:

‫AlloyDB Omni מספק פלטפורמת תזמור לפריסה ולניהול של AlloyDB Omni בסביבות שאינן Kubernetes – לדוגמה, ב-Red Hat Enterprise Linux (RHEL) ובמערכות תואמות שמשתמשות בחבילות של Red Hat Package Manager (RPM). אפשרות הפריסה של מתזמן ה-RPM מרחיבה את הגמישות והאוטומציה שדומות לענן לתשתית מקומית ולתשתית של מכונות וירטואליות (VM).

באמצעות AlloyDB Omni עם כלי התזמור של RPM, ארגונים יכולים להתקין, להגדיר ולנהל מכונות של AlloyDB Omni באמצעות חבילות RPM רגילות. הגישה הזו מתאימה לארגונים שהשקיעו הרבה בתשתית של מכונות וירטואליות, ושיש להם שיטות תפעוליות מבוססות שמבוססות על כלים אוטומטיים, כמו Ansible. אפשרות הפריסה של מתזמן RPM פועלת ישירות במכונות וירטואליות של Linux או בשרתי Bare Metal, בלי צורך בשכבת קונטיינרים כמו Docker או במערכת תזמון כמו Kubernetes.

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

תרחישים לדוגמה

אפשרות הפריסה של כלי התזמור של RPM תומכת בתרחישי השימוש הבאים:

תרחיש לדוגמה תיאור
ארגונים עם תשתית של מכונות וירטואליות מתאים לחברות שבהן Kubernetes הוא לא הסטנדרט, או לסביבות בקונטיינרים עם יחסי תלות של אפליקציות שמעדיפות פריסות רגילות של מכונות וירטואליות או של Bare Metal.
פעולות פשוטות יותר אוטומציה של פריסת מסד הנתונים, ההגדרה וניהול מחזור החיים באמצעות כלים מוכרים, כמו Ansible.
זמינות גבוהה (HA) ותוכנית התאוששות מאסון (DR) הגדרת אשכולות AlloyDB Omni גמישים עם מנגנוני יתירות כשל ושחזור אוטומטיים.
סביבות היברידיות מבטיח פעולות עקביות במסד הנתונים במרכזי נתונים מקומיים ובמכונות וירטואליות בענן.
שילוב מערכות מדור קודם משתלב עם אפליקציות ומערכות קיימות שמיועדות לסביבות ללא קונטיינרים.

יתרונות

היתרונות של פריסת תזמור RPM כוללים:

  • פריסה מהירה: אוטומציה של כל מחזור החיים, מהקצאה ועד אימות, שמקצרת משמעותית את הזמן ומפחיתה את המורכבות של הגדרת אשכולות AlloyDB Omni.
  • שילוב חלק: שילוב מקורי עם ניהול חבילות סטנדרטי של Linux‏ (RPM) ומסגרות אוטומציה פופולריות, כמו Ansible, שמאפשר לצוותים להשתמש במיומנויות קיימות ובשילובי כלים.
  • חוויית משתמש עקבית: חוויית המשתמש וקבוצת התכונות לניהול ולתפעול דומות לאלה של מפעיל Kubernetes של AlloyDB Omni, מה שמאפשר עקביות במודלים שונים של פריסה.
  • זמינות גבוהה (HA) והתאוששות מאסון (DR) ברמה שמתאימה לארגונים: תמיכה בהגדרות אישיות גמישות של זמינות גבוהה והתאוששות מאסון, כדי לענות על הצרכים של המשכיות עסקית.
  • אבטחה חזקה: מאפשרת ליישם אסטרטגיות אבטחה מרובות, כולל ניהול משתמשים, אבטחת רשת עם אישורים (SSL) ושילוב עם מערכות, למשל Microsoft Active Directory.
  • ניהול מרוכז: משתמש בשירות AlloyDB Omni כדי לספק מישור בקרה מאוחד לניהול AlloyDB Omni במכונות וירטואליות.
  • ניטור וביקורת: מאפשר שילוב עם שרתי רישום חיצוניים ביומן – לדוגמה, Elastic Stack – באמצעות rsyslog לניהול, מעקב וביקורת של יומנים מרכזיים.
  • הגנה על נתונים: כולל תכונות לגיבוי פשוט, הגדרות שחזור ואסטרטגיות.
  • מאגר חיבורים: תמיכה בפריסה של PgBouncer כדי לשפר את החיבורים למסד הנתונים ואת הביצועים.
  • ניהול צי: מאפשר לנהל כמה אשכולות של AlloyDB Omni בקנה מידה נרחב.

ארכיטקטורה

ב-AlloyDB Omni מוגדרת היררכיה של רכיבים שמאפשרת גמישות. הגמישות הזו עוזרת למקסם את זמינות הנתונים ולשפר את הביצועים ואת קצב העיבוד של השאילתות. הגישה הזו מאפשרת לכם לעקוב אחרי פריסת AlloyDB Omni ולשנות את קנה המידה והגודל שלה בהתאם לעומסי העבודה.

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

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

Resilient HA

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

בתרשים הבא מוצגת ארכיטקטורת הפריסה של זמינות גבוהה וגמישות בסביבת Bare Metal או VM:

ארכיטקטורת פריסה של HA גמיש ב-AlloyDB Omni.

איור 1. ארכיטקטורת פריסה של זמינות גבוהה וגמישות ב-AlloyDB Omni

HA מדרגי

בארכיטקטורת HA שניתנת להתאמה לעומס, פורסים צומת ראשי פעיל וצמתים במצב המתנה באזורים נפרדים, בשילוב עם צמתים ייעודיים של מאזן העומסים HAProxy. הצמתים האלה של מאזן העומסים חושפים את נקודות הקצה לקריאה-כתיבה ולקריאה בלבד, ומנתבים את תנועת הלקוחות.

בתרשים הבא מוצגת הטקסונומיה של פריסת HA עם יכולת התאמה לעומס (scaling) של AlloyDB Omni בסביבת Bare Metal או VM:

ארכיטקטורת פריסה של מכונה וירטואלית עם זמינות גבוהה וסקיילביליות ב-AlloyDB Omni.

איור 2. ארכיטקטורת פריסה של מכונה וירטואלית עם זמינות גבוהה וסקלאביליות ב-AlloyDB Omni

רכיבים

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

רכיב תיאור
כלי תזמור התזמור ב-AlloyDB Omni מספק ממשקים של שורת הפקודה ו-Ansible, שעוזרים לפרוס ולנהל אשכול אחד או יותר של AlloyDB Omni בסביבה מבוזרת.
alloydbomni הליבה של AlloyDB Omni כוללת את PostgreSQL ותכונות של טייס אוטומטי לשיפור הביצועים והיכולות לתמיכה בעומסי עבודה מודרניים, למשל עיבוד אנליטי אונליין (OLAP) ו-AI גנרטיבי.
alloydbomni_monitor רכיב המעקב ב-AlloyDB Omni מאפשר לאסוף מדדים מ-AlloyDB Omni.
‫alloydbomni_ui (אופציונלי) ממשק המשתמש באינטרנט של AlloyDB Omni הוא מסוף אינטרנט בניהול עצמי שמספק מרכזי בקרה של ניראות למכונות של אשכולות, תרשימי טלמטריה של המערכת, גדלים של מסדי נתונים, דגלים לניהול מסד נתונים פעילים, נתונים סטטיסטיים של מנועים מבוססי-עמודות ותובנות לגבי שאילתות.
etcd ‫etcd מספק מערכת הגדרות מבוזרת שבה תוכנה לניהול אשכולות משתמשת כדי לאחסן את ההגדרות ואת פרטי המצב של PostgreSQL.
תוכנה לניהול אשכולות מישור הבקרה המרכזי מתזמר את הפעולות ברמת האשכול. הפעולות האלה כוללות אתחול של האשכול, ניהול של זמינות גבוהה, טיפול ביתירות כשל, תיאום שדרוגים וחשיפת ממשקים לכלי אוטומציה, למשל Ansible וכלי שורת הפקודה alloydbctl.
Node manager סוכן שפועל בכל צומת באשכול AlloyDB Omni. הוא מקיים אינטראקציה עם תוכנה לניהול אשכולות כדי לבצע משימות בצומת, למשל, התקנה והגדרה של AlloyDB Omni, ניהול מחזור החיים של שירות מסד הנתונים (התחלה ועצירה), מעקב אחרי תקינות הצומת ואיסוף יומנים ומדדים.
HAProxy ‫HAProxy פועל כמאזן עומסים בפריסות של AlloyDB Omni. הוא חושף את נקודות הקצה (endpoints) לקריאה-כתיבה ולקריאה בלבד. הוא פועל עם התוכנה לניהול אשכולות כדי להפנות את התנועה לצמתים הפעילים המתאימים.
keepalived הכלי keepalived יכול לספק זמינות גבוהה לצמתים המשתתפים, למשל HAProxy, באמצעות כתובת IP וירטואלית צפה.
PgBouncer ‫PgBouncer הוא מאגר חיבורים קל למסדי נתונים של PostgreSQL.
pgBackRest ‫pgBackRest הוא כלי בקוד פתוח לגיבוי ולשחזור, שמיועד ל-PostgreSQL.

הארכיטקטורה הזו מאפשרת להריץ ולהפעיל את AlloyDB Omni ביעילות בסביבת ה-VM הקיימת של Linux, ולשלב את AlloyDB Omni עם שיטות העבודה המוכרות.

דרישות מערכת

דרישות המערכת של מחסנית הפריסה של AlloyDB Omni כוללות קבוצה של מכונות וירטואליות שהוגדרו מראש להפעלת רכיבים שונים. לכל מכונה וירטואלית של AlloyDB Omni צריך להיות דיסק נתונים מצורף שמוגדר עם מערכת הקבצים ext4/xfs. גודל הדיסק משוער לפי גודל הנתונים. מאפייני הביצועים של האחסון משפיעים על הביצועים של AlloyDB Omni. בטבלה הבאה מפורטות הגדרות המינימום וההגדרות המומלצות של המעבד (CPU) והזיכרון למכונות הווירטואליות.

סוג המכונה הווירטואלית דרישות מינימליות לחומרה ולמערכת ההפעלה (OS) חומרה ומערכת הפעלה מומלצות
צומת בקרה
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64 2 vCPUs עם תמיכה ב-AVX2
  • ‫RAM: ‏2GB
  • דיסק: 10GB
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64‏ 8 vCPU עם תמיכה ב-AVX2
  • ‫RAM: ‏8GB
  • דיסק: 20GB או יותר
צמתים של מאזן עומסים
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64 2 vCPUs עם תמיכה ב-AVX2
  • ‫RAM: ‏2GB
  • דיסק: 10GB
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64‏ 16 vCPU עם תמיכה ב-AVX2
  • ‫RAM: ‏8GB
  • דיסק: 20GB או יותר
‫AlloyDB Omni (עצמאי)
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64 2 vCPUs עם תמיכה ב-AVX2
  • ‫RAM: ‏16GB
  • דיסק: 20GB
  • דיסק נתונים: פי 2 מגודל הנתונים
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64‏ 64 vCPUs עם תמיכה ב-AVX2
  • ‫RAM: ‏8GB לכל vCPU ל-AlloyDB Omni
  • דיסק: 20GB
  • דיסק נתונים: פי 2 מגודל הנתונים
‫AlloyDB Omni (עם זמינות גבוהה)
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64 4 vCPUs עם תמיכה ב-AVX2
  • ‫RAM: ‏20GB
  • דיסק: 10GB
  • דיסק נתונים: פי 2 מגודל הנתונים
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64‏ 64 vCPUs עם תמיכה ב-AVX2
  • זיכרון RAM: ‏8GB או יותר לכל vCPU ל-AlloyDB Omni
  • דיסק: 20GB
  • דיסק נתונים: פי 2 מגודל הנתונים
צומת של מאגר הגיבויים
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64 2 vCPUs עם תמיכה ב-AVX2
  • ‫RAM: ‏2GB
  • דיסק: 10GB
  • דיסק גיבוי: מספר הימים כפול גודל הנתונים
  • מערכת הפעלה: RHEL9
  • מעבד (CPU): ‏x86-64‏ 8 vCPU עם תמיכה ב-AVX2
  • ‫RAM: ‏8GB
  • דיסק: 20GB
  • דיסק גיבוי: מספר הימים כפול גודל הנתונים

ארכיטקטורת עזר לפריסת HA

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

הרכיב של תוכנה לניהול אשכולות בסטאק התוכנות מבצע את הגדרת האשכול, עוקב אחרי תקינות השרת של AlloyDB Omni ומנהל את יתירות הכשל האוטומטית על ידי בחירת המכונה הראשית החדשה בעזרת מערכת הגדרות מבוזרת כמו etcd. ארגונים משתמשים ב-RPO וב-Recovery Time Objective‏ (RTO) כמדדים העיקריים לזמינות. הגדרות הארכיטקטורה של HA מציעות RPO ו-RTO קרובים לאפס במקרה של כשל ברמת האזור. אתם יכולים גם להגדיר גיבויים ומכונות אופציונליות של מאגר קריאה עם רפליקציה אסינכרונית, כדי להעביר עומסי עבודה לקריאה בלבד.

בהתאם לעומס העבודה ולדרישות הניתוב, אתם יכולים לפרוס את AlloyDB Omni באמצעות ארכיטקטורת זמינות גבוהה גמישה, שפועלת בלי צמתים ייעודיים של מאזן עומסים, או באמצעות ארכיטקטורת זמינות גבוהה שניתנת להתאמה, שכוללת צמתים ייעודיים של מאזן עומסים:

Resilient HA

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

  • ניתוב IP וירטואלי: השירות keepalived פועל ישירות בצומתי מסד הנתונים ומנהל כתובת IP וירטואלית צפה שמצביעה על הצומת הראשי הפעיל. ההגדרה הזו חושפת את נקודת הקצה לקריאה ולכתיבה ישירות בצומת הפעיל. אפליקציות לקוח מתחברות למסד הנתונים באמצעות כתובת ה-IP הווירטואלית. אם מתרחש מעבר לגיבוי בעת כשל וצומת המתנה מקודם לצומת ראשי, השירות keepalived מעביר באופן אוטומטי את כתובת ה-IP הווירטואלית לצומת הראשי הפעיל החדש.
  • מאגר חיבורים: אם אתם משתמשים ב-PgBouncer למאגר חיבורים, הוא פועל ישירות בצומתי מסד הנתונים.

HA מדרגי

בארכיטקטורת HA עם יכולת התאמה לעומס, נוספים לאשכול מסד הנתונים צמתים ייעודיים של מאזן עומסים (קבוצת load_balancer_nodes):

  • איזון עומסים של HAProxy: צומתי מאזן העומסים הייעודיים מריצים את HAProxy, שחושף נקודות קצה לקריאה וכתיבה ונקודות קצה לקריאה בלבד. ‫HAProxy פועל עם תוכנה לניהול אשכולות כדי לעקוב אחרי מצבי הצמתים, לנתב שאילתות קריאה-כתיבה לצומת הראשי הפעיל ולהפיץ שאילתות לקריאה בלבד בין צמתים תקינים במצב המתנה או מכונות אופציונליות של מאגר קריאה. אם מתרחש יתירות כשל, HAProxy מעביר באופן אוטומטי את תעבורת נתונים של קריאה וכתיבה לצומת הפעיל החדש.
  • זמינות גבוהה של מאזן העומסים: השירות keepalived פועל בצמתים של מאזן העומסים ומנהל כתובת IP וירטואלית צפה (floating) ביניהם. הלקוחות מתחברים למאזן העומסים של HAProxy באמצעות כתובת ה-IP הווירטואלית הזו כדי לבצע פעולות במסד הנתונים. אם שירות HAProxy הפעיל או צומת מאזן העומסים נכשלים, שירות keepalived מעביר את כתובת ה-IP הווירטואלית לצומת אחר של מאזן העומסים.
  • מאגר חיבורים: אם אתם משתמשים ב-PgBouncer למאגר חיבורים, הוא פועל בצמתים הייעודיים של מאזן העומסים לצד HAProxy ו-keepalived.

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

ארכיטקטורת פריסה של AlloyDB Omni HA.

איור 3. ארכיטקטורת פריסה של HA

כלי תזמור של RPM

‫AlloyDB Omni עם מתזמר RPM מספק פלטפורמת אוטומציה ומישור בקרה להתקנה, להגדרה ולניהול של אשכולות מסדי נתונים של AlloyDB Omni בקבוצה של מכונות וירטואליות או שרתי Bare Metal. זה כולל הגדרות שונות של ארכיטקטורה, למשל זמינות גבוהה (HA) עצמאית, גמישה וניתנת להתאמה.

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

אפשרות הפריסה של מתזמר RPM היא הממשק המרוחק לתקשורת עם שירות תוכנה לניהול אשכולות של AlloyDB Omni. התזמור פועל בצומת ייעודי שנקרא צומת בקרה. מהצומת הזה אפשר לנהל אשכול אחד או יותר מרחוק, דרך ערוץ מאובטח. כדי להתאים לסביבה שלכם, יש כמה כלים לתזמור ב-AlloyDB Omni. בוחרים את כלי הניהול שמתאים לצורכי האוטומציה שלכם.

  • ‫AlloyDB Omni orchestrator CLI (זמין כ-RPM): מומלץ לסביבות שמשתמשות בסקריפטים של מעטפת כדי להפוך את הפריסה והניהול של האשכולות לאוטומטיים.
  • ‫Ansible לניהול RPM (זמין כאוסף Ansible): מומלץ לסביבות שמשתמשות באוטומציה מובנית שמבוססת על Ansible, ומוכנות להרחיב אותה באמצעות קריאות לתפקידי Ansible נוספים. יש דוגמאות לפלייבוקים של Ansible שמאפשרים שילוב פשוט עם פלייבוקים קיימים של Ansible.

התזמור ב-AlloyDB Omni מאפשר לבצע את הפעולות הבאות שקשורות לאשכול AlloyDB Omni. התזמור שמבוסס על Ansible מספק תפקידי Ansible לכל אחת מהפעולות האלה. שורת הפקודה מספקת קבוצה של פקודות שמופעלות באמצעות הנחיה של מעטפת או סקריפטים של מעטפת.

  • ‫Installation: התקנת רכיבי אשכול שונים בצמתים המתאימים.
  • ‫Bootstrap: מגדירים ומפעילים את כל הרכיבים בהתאם למפרטים שלהם.
  • ‫Update: עדכון משאבים לגרסאות חדשות יותר או להגדרות מעודכנות.
  • ‫Status: קבלת הסטטוס של כל הרכיבים או השירותים באשכול.
  • ‫Delete: מחיקת משאבי אשכול.

התזמורנים מקבלים קבוצה של מפרטים כקלט בפורמט YAML.

  • מפרט פריסה: זהה לפורמט של Ansible Inventory שמגדיר את הטופולוגיה של אשכול המכונות הווירטואליות. הוא מכיל קבוצות שונות של מכונות וירטואליות, למשל אלה שמופיעות בהמשך, יחד עם ההגדרות שלהן.
    • ‫primary_instance_nodes: צמתים שמיועדים לשרתי מסדי נתונים של AlloyDB Omni.
    • ‫cluster_manager_nodes: אופציונלי. צמתים שמריצים שרתי תוכנה לניהול אשכולות של AlloyDB Omni. אם אין צמתים ייעודיים לניהול אשכולות, אפשר לפרוס את תוכנה לניהול אשכולות ב-primary_instance_nodes.
    • ‫etcd_nodes: תוכנה לניהול אשכולות מאחסנת מטא-נתונים ב-etcd. אם לא צוין אחרת, etcd יכול לפעול באותם צמתים כמו צמתי תוכנה לניהול אשכולות.
    • ‫load_balancer_nodes: אופציונלי. צמתים נוספים שמיועדים למאזן עומסים שמבוסס על HAProxy בפריסת HA שניתנת להתאמה לעומס. אם לא מציינים את הפרמטר, keepalived ו-PgBouncer פועלים ישירות בצמתים בקבוצה primary_instance_nodes בפריסת HA גמישה.
  • מפרט המשאבים: אשכול מורכב ממשאב אחד או יותר שצריך לפרוס ולנהל, למשל אשכולות של מסדי נתונים ומאגרי חיבורים. מפרט המשאבים הוא בפורמט YAML ומתאר את המשאבים שצריך לפרוס באשכול.

מגבלות

  • אפשרות הפריסה של RPM orchestrator תומכת רק באפשרויות הבאות:
    • ‫AlloyDB Omni PostgreSQL 18
    • חבילות תוכנה שתואמות ל-RHEL בגרסה 9
    • פלטפורמת Intel x86 64-bit
  • אין תמיכה בשדרוגים של גרסאות ראשיות.
  • ההוראות להגדרת תוכנית התאוששות מאסון (DR) ומאגר מכונות לקריאה בלבד לא נכללות במאמר הזה.
  • המעקב אחרי AlloyDB Omni לא תומך בחיבורי SSL. אתם צריכים לפרוס את שרתי לוח הבקרה למעקב באותה רשת פרטית שבה נמצאים הצמתים של AlloyDB Omni.
  • ‫AlloyDB Omni תומך ב-SELinux גם במצב permissive וגם במצב אכיפה. צריך להגדיר את מצב SELinux שבחרתם לפני שאתחול האשכול. אי אפשר לעבור למצב אכיפה אחרי ההפעלה.

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