תכנון ההתקנה

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

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

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

גודל וקיבולת

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

מומלץ להתחיל עם פריסה באמצעות משאבי 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 למדרגיות ושיתוף נתונים.

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

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

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

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

דרישות חומרה

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

דרישות תוכנה

מערכת הפעלה או פלטפורמה תוכנה מינימלית תוכנות מומלצות
Linux1
  • אחת ממערכות ההפעלה הבאות:
    • ‫Ubuntu 22.04 ואילך
    • ‫Debian 11
    • RHEL 8.10
  • ליבת Linux בגרסה 4.18 ומעלה
  • ‫Cgroups v1 או v2 מופעלים
  • ‫Docker Engine 20.10+‎ או Podman 4.2.0+‎
  • אחת ממערכות ההפעלה הבאות:
    • ‫Ubuntu 22.04 ואילך
    • ‫Debian 11 או 12
    • RHEL 9
  • גרסה 6.1 ומעלה של ליבת Linux, או כל גרסה של ליבת Linux שקודמת לגרסה 5.3 וכוללת תמיכה בהנחיות MADV_COLLAPSE ו-MADV_POPULATE_WRITE
  • האפשרות Cgroupsv2 מופעלת
  • ‫Docker Engine מגרסה 25.0.0 ואילך או Podman מגרסה 5.0.0 ואילך
macOS
  • ‫Docker Desktop 4.20 ואילך
  • ‫Docker Desktop 4.30 ואילך
  1. ‫AlloyDB Omni מניח שאם SELinux קיים, הוא מוגדר במארח כך שהוא מאפשר להפעיל את הקונטיינר, כולל גישה למערכת הקבצים (או ש-SELinux מוגדר כ-permissive).

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

‫AlloyDB Omni תומך במערכות קבצים בנפחי אחסון בלוקים במכונות מסד נתונים. במערכות פיתוח או ניסיון קטנות יותר, משתמשים במערכת הקבצים המקומית של המארח שבו פועל הקונטיינר. לעומסי עבודה ארגוניים, השתמשו באחסון ששמור למכונות של 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 לשרת אחר במרכז הנתונים, וכך לאפשר שחזור מהיר יותר.

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