תכנון ההתקנה של AlloyDB Omni

בוחרים גרסה של מאמרי העזרה:

במאמר הזה מוסבר איך להתכונן להרצת AlloyDB Omni בסביבת Linux.

סקירה כללית על AlloyDB Omni

גודל וקיבולת

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

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

כדי לקבוע את הגודל של סביבת AlloyDB Omni, צריך לבצע את השלבים הבאים:

  1. מגדירים את עומס העבודה.

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

    • קצב העסקאות: קובעים את מספר העסקאות הצפוי לשנייה (TPS), כולל קריאות, כתיבות, עדכונים ומחיקות.

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

    • דרישות ביצועים: הגדירו את זמני התגובה הקבילים לסוגים שונים של שאילתות ופעולות.

  2. מוודאים שהחומרה תומכת בדרישות הגודל.

    • מעבד: מערכות עם כמה ליבות מעבד משפרות את הביצועים של AlloyDB Omni, והמערכת מתרחבת באופן לינארי בהתאם לעומס העבודה. עם זאת, בדרך כלל PostgreSQL בקוד פתוח לא מפיק תועלת מיותר מ-16 מעבדי vCPU. חשוב להביא בחשבון את הדברים הבאים:

      • מספר ליבות המעבד בהתאם למידת הניצול של המעבד ולצרכי החישוב.
      • כל שיפור שנובע משינוי בדור המעבד או בפלטפורמה.

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

    • אחסון

      • סוג: בהתאם לצרכים שלכם, אתם יכולים לבחור בין אחסון NVMe מקומי לביצועים, לבין אחסון SAN למדרגיות ולשיתוף נתונים.

      • קיבולת: צריך לוודא שיש מספיק נפח אחסון לנתונים, לאינדקסים, ל-Write-Ahead Log ‏ (WAL), לגיבויים ולצמיחה עתידית.

      • ‫IOPS: מעריכים את פעולות הקלט/פלט לשנייה (IOPS) הנדרשות על סמך דפוסי הקריאה והכתיבה של עומס העבודה. כשמריצים את AlloyDB Omni בענן ציבורי, כדאי לבדוק את מאפייני הביצועים של סוג האחסון כדי להבין אם צריך להגדיל את נפח האחסון כדי לעמוד ביעד IOPS ספציפי.

דרישות מוקדמות להפעלת AlloyDB Omni

לפני שמפעילים את AlloyDB Omni, חשוב לוודא שאתם עומדים בדרישות החומרה והתוכנה הבאות.

דרישות חומרה

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

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

דרישות תוכנה

מערכת הפעלה או פלטפורמה תוכנה מינימלית
Linux1
  • אחת ממערכות ההפעלה הבאות:
    • RHEL 9
    • Rocky Linux 9
  • חבילה של policycoreutils-python-utils
  1. ‫AlloyDB Omni מניח שהחבילה policycoreutils-python-utils מותקנת לפני התקנת חבילת ה-RPM של AlloyDB Omni. כך AlloyDB Omni יכול להגדיר את מדיניות SELinux שמאפשרת לשירות מסד הנתונים של AlloyDB Omni לפעול.

סוגי האחסון הנתמכים

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

אחסון מקומי ב-NVMe או ב-SAN

לשני סוגי האחסון, אחסון מקומי ב-Non-Volatile Memory Express‏ (NVMe) ואחסון ברשת אזור אחסון (SAN), יש יתרונות משלהם. הפתרון המתאים תלוי בדרישות הספציפיות של עומס העבודה, בתקציב ובצרכים העתידיים שלכם בנוגע ליכולת ההתאמה לעומס.

כדי לבחור את אפשרות האחסון הכי מתאימה, כדאי להביא בחשבון את הדברים הבאים:

  • כדי לתת עדיפות לביצועים מוחלטים, בחרו ב-NVMe מקומי.
  • אם אתם צריכים נפח אחסון משותף בקנה מידה גדול, בחרו ב-SAN.
  • אם אתם צריכים לאזן בין ביצועים לבין שיתוף, כדאי לשקול שימוש ב-SAN עם NVMe over Fabrics כדי לקבל גישה מהירה יותר.

אחסון NVMe מקומי

‫NVMe הוא פרוטוקול עם ביצועים גבוהים שמיועד לכונני SSD. לאפליקציות שצריכות גישה מהירה לנתונים, אחסון NVMe מקומי מציע את היתרונות הבאים:

  • כונני NVMe SSD מתחברים ישירות לאפיק Peripheral Component Interconnect express‏ (PCIe) כדי לספק מהירויות קריאה וכתיבה גבוהות.
  • אחסון NVMe מקומי מספק את זמן האחזור הקצר ביותר.
  • אחסון NVMe מקומי מספק את התפוקה הגבוהה ביותר.

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

אחסון SAN

רשת SAN היא רשת אחסון ייעודית שמחברת כמה שרתים למאגר משותף של התקני אחסון, בדרך כלל כונני SSD או אחסון NVMe מרכזי. למרות ש-SAN לא מהיר כמו NVMe מקומי, רשתות SAN מודרניות, במיוחד אלה שמשתמשות ב-NVMe over Fabrics, עדיין מספקות ביצועים מצוינים לרוב עומסי העבודה הארגוניים.

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

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