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

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

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

סקירה כללית של AlloyDB Omni זמינה במאמר AlloyDB Omni overview.

גודל וקיבולת

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

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

התאמת הגודל של סביבת AlloyDB Omni כוללת את השלבים הבאים:

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

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

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

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

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

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

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

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

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

    • אחסון

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

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

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

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

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

דרישות חומרה

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

צומת חומרה מינימלית חומרה מומלצת
AlloyDB Omni
  • מעבד (CPU):‏ x86-64‏ 2 vCPU עם תמיכה ב-AVX2
  • ‫RAM: ‏ 16GB
  • דיסק: ‎10GB
  • דיסק נתונים1: פי 2 מנפח הנתונים
  • מעבד: x86-64 עם 64 מעבדים וירטואליים (vCPU) ותמיכה ב-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 תומך במערכות קבצים בנפחי אחסון בלוקים במכונות מסד נתונים. במערכות פיתוח או ניסיון קטנות יותר, משתמשים במערכת הקבצים המקומית של המארח שבו פועל הקונטיינר. עבור עומסי עבודה ארגוניים, צריך להשתמש באחסון ששמור למופעי AlloyDB Omni. בהתאם לדרישות שנקבעו על ידי עומס העבודה של מסד הנתונים, מגדירים את מכשירי האחסון בהגדרת סינגלטון עם מכשיר דיסק אחד לכל קונטיינר, או בהגדרה מאוחדת שבה כמה קונטיינרים קוראים וכותבים מאותו מכשיר דיסק.

אחסון מקומי מסוג NVMe או SAN

גם אחסון מקומי ב-Non-Volatile Memory Express‏ (NVMe) וגם אחסון ב-Storage Area Network‏ (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 לשרת אחר במרכז הנתונים, וכך לאפשר שחזור מהיר יותר.