בדף הזה מתוארות המפרטים של האשכולות והצמתים במופעים של Memorystore for Redis Cluster. הוראות ליצירת מכונה זמינות במאמר יצירת מכונות.
בחירת סוג הצומת
כל הרסיסים באשכול משתמשים באותו סוג צומת שתבחרו. סוג הצומת הכי טוב לאשכול תלוי בדרישות שלכם לגבי מחיר, ביצועים וקיבולת של מרחב המפתחות.
סוג הצומת redis-shared-core-nano מיועד לעומסי עבודה קטנים. סוג הצומת הזה מספק ביצועים משתנים ואין לו הסכם רמת שירות (SLA), ולכן הוא לא מתאים לעומסי עבודה של ייצור.
סוג הצומת redis-standard-small מאפשר הקצאה של אשכולות קטנים, והגדלה של האשכול במרווחים קטנים יותר בעלויות נמוכות יותר בהשוואה לסוגי צמתים אחרים. redis-standard-small מציע גם את היתרון של חלוקת מרחב המפתחות בין יותר צמתים עם מספר כולל גבוה יותר של מעבדים וירטואליים. האפשרות הזו מציעה שיפור בביצועים ביחס למחיר בהשוואה ל-redis-highmem-medium, כל עוד קיבולת מרחב המפתחות הכוללת של הצמתים הקטנים מספיקה לצרכי הנתונים שלכם.
אם יש לכם עומסי עבודה שדורשים קצב גבוה יותר של כוח עיבוד ביחס לזיכרון, כדאי לבחור את סוג הצומת redis-highcpu-medium. אם אתם צריכים קיבולת גדולה יותר מזו ש-redis-highmem-medium מספק, מומלץ לבחור את סוגי הצמתים redis-standard-large, redis-highmem-xlarge או redis-highmem-2xlarge. כשמוסיפים מעבדים וירטואליים לצמתים גדולים יותר ויותר (הרחבת היקף השימוש), יכול להיות שהביצועים של Redis לא יגדלו באופן לינארי. במקום זאת, כדי לשפר את הביצועים של המחיר, מומלץ להרחיב את הקיבולת על ידי הוספת צמתים נוספים לאשכול.
הגדרת סוג הצומת
הקיבולת והמאפיינים של הצומת תלויים בסוג הצומת שתבחרו:
קיבולת של מרחב מפתחות ותקורה שמורה
| סוג הצומת | קיבולת ברירת המחדל של מרחב מפתחות שניתן לכתיבה | הקיבולת הכוללת של הצומת |
|---|---|---|
| redis-shared-core-nano | 1.12GB | 1.4GB |
| redis-standard-small | 5.2GB | 6.5GB |
| redis-highmem-medium | 10.4GB | 13GB |
| redis-highcpu-medium | 10.4GB | 13GB |
| redis-standard-large | 20.8GB | 26GB |
| redis-highmem-xlarge | 46.4GB | 58GB |
| redis-highmem-2xlarge | 88GB | 110GB |
מערכת Memorystore שומרת באופן אוטומטי חלק מהקיבולת של המופע כדי למנוע שגיאות של חוסר בזיכרון (OOM). כך מובטחת חוויה חלקה של קריאה וכתיבה של מפתחות. מגבלות הזיכרון ופרטי האחסון הם כדלקמן:
התאמה אישית של האחסון: אנחנו ממליצים להשתמש בהגדרות ברירת המחדל, אבל יש לכם אפשרות לשנות את כמות האחסון השמור באמצעות ההגדרה
maxmemory. מידע עלmaxmemoryזמין במאמר הגדרות נתמכות של מופעים.כמה נפח אחסון מקבלים? צריך לעיין בעמודה קיבולת ברירת המחדל של מרחב מפתחות שניתן לכתיבה בטבלה הקודמת. כאן מוצג נפח האחסון שזמין למפתחות שלכם כברירת מחדל.
מיצוי נפח האחסון אם רוצים להשתמש בנפח האחסון המקסימלי האפשרי, בעמודה total node capacity מוצגת מגבלת האחסון כשמגדירים את
maxmemoryconfig ל-100%. עם זאת, לא מומלץ לבחורmaxmemoryערך גבוה יותר מהגדרת ברירת המחדל.לסוג הצומת
redis-shared-core-nanoיש מגבלה קשיחה של 1.12GB, ואי אפשר לשנות אותה באמצעות ההגדרהmaxmemory.
מאפייני הצומת
ככל שתבחרו יותר מעבדים וירטואליים (vCPU) לאשכול, כך הביצועים יהיו טובים יותר. אם באשכול מופעלים עומסי עבודה שדורשים הרבה משאבים, כדאי לבחור סוג צומת עם vCPU גבוה יותר (לדוגמה, redis-highmem-xlarge). אם באשכול מופעלות משימות שדורשות פחות משאבים, כדאי לבחור סוג צומת עם vCPU נמוך יותר (לדוגמה, redis-highmem-medium).
שינוי הגודל של מכונה
במסגרת יצירת מכונת Memorystore for Redis Cluster, בוחרים סוג צומת למכונה ומציינים את מספר הרסיסים של המכונה. אחרי שיוצרים את המופע, יכול להיות שיהיה צורך לשנות את גודל המופע בדרכים הבאות, בהתאם לשינויים בקיבולת הנדרשת:
- משנים את מספר הרסיסים של המופע. הפעולה הזו נקראת הגדלה אופקית.
כדי להגדיל את הקיבולת של מופע באופן אופקי, מבצעים אחת מהפעולות הבאות:
- מוסיפים שרדים למופע. הפעולה הזו מרחיבה את המופע out.
- מסירים את הרסיסים מהמופע. זוהי הרחבה אנכית של המכונה (scale up).
- משנים את סוג הצומת של המופע. הפעולה הזו נקראת שינוי גודל אנכי. כדי לשנות את הגודל של מופע באופן אנכי, צריך לשנות את סוג הצומת של המופע לאחד מסוגי הצמתים הבאים:
- מעבר לסוג צומת גדול יותר. זהו תהליך של הגדלת המופע.
- מעבר לסוג צומת קטן יותר. זוהי הפחתה של המופע.
מפרט האשכול
בקטע הזה מוצגים הקיבולת המינימלית והמקסימלית של האשכול, בהתאם לצורה של האשכול, לסוג הצומת ולמספר העותקים.
קיבולת מינימלית שאפשר לכתוב אליה
הקיבולת לכתיבה היא נפח האחסון שזמין לכתיבת מפתחות. הוא שווה לגודל של צומת מופע אחד. לכן, בהתאם לסוג הצומת, הקיבולת המינימלית שאפשר לכתוב אליה היא בין 1.4GB ל-110GB. התפוסה המינימלית לכתיבה לא מושפעת ממספר העותקים המשוכפלים שתבחרו.
קיבולת מקסימלית לכתיבה
| סוג הצומת וגודל הצומת | קיבולת מקסימלית בהתאם לצורת האשכול של 250 צמתים ראשיים ו-0 עותקים משוכפלים לכל צומת | הקיבולת המקסימלית בהתאם לצורת האשכול של 125 צמתים ראשיים ועותק אחד לכל צומת | קיבולת מקסימלית בהתחשב בצורת האשכול של 83 צמתים ראשיים ו-2 עותקים משוכפלים לכל צומת | קיבולת מקסימלית בהתחשב בצורת האשכול של 62 צמתים ראשיים ו-3 עותקים משוכפלים לכל צומת | הקיבולת המקסימלית של צורת האשכול היא 50 צמתים ראשיים ו-4 רפליקות לכל צומת | קיבולת מקסימלית בהתחשב בצורת האשכול של 41 צמתים ראשיים ו-5 עותקים משוכפלים לכל צומת |
|---|---|---|---|---|---|---|
| redis-ליבת מעבד משותפת-nano – 1.4GB | 350GB | 175GB | 116.2GB | 86.8GB | 70GB | 57.4GB |
| redis-standard-small – 6.5GB | 1,625GB | 812.5GB | 539.5GB | 403GB | 325GB | 266.5GB |
| redis-highmem-medium – 13 GB | 3,250GB | 1,625GB | 1,079GB | 806GB | 650GB | 533GB |
| redis-highcpu-medium – 13GB | 3,250GB | 1,625GB | 1,079GB | 806GB | 650GB | 533GB |
| redis-standard-large – 26GB | 6,500GB | 3,250GB | 2,158GB | 1,612GB | 1,300GB | 1,066GB |
| redis-highmem-xlarge – 58GB | 14,500GB | 7,250GB | 4,814GB | 3,596GB | 2,900GB | 2,378GB |
| redis-highmem-2xlarge – 110GB | 27,500GB | 13,750GB | 9,130GB | 6,820GB | 5,500GB | 4,510GB |
ביצועים
השימוש בכלי ההשוואה של OSS memtier באזור us-central1 הניב 120,000 עד 130,000 פעולות בשנייה לכל צומת עם 2 vCPU (redis-standard-small ו-redis-highmem-medium) עם זמן אחזור של מיקרו-שניות וגודל נתונים של 1KiB.
מומלץ לבצע השוואה משלכם באמצעות עומסי עבודה אמיתיים או עומסי עבודה סינתטיים שדומים לתנועת הנתונים בסביבת הייצור. בנוסף, מומלץ להגדיר את גודל האשכולות עם מרווח ביטחון (או "מרווח עליון") לעומסי עבודה גבוהים או לתנועה לא צפויה. מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש ב-Memorystore for Redis Cluster.
נקודות קצה של אשכולות
בקטע הזה מוסבר על שתי נקודות הקצה שיש לכל מופע.
נקודת קצה של גילוי
לכל מופע יש נקודת קצה לגילוי שאליה מתחבר הלקוח. הוא שילוב של כתובת IP ומספר יציאה. הוראות לאיתור נקודת הקצה של הגילוי באשכול זמינות במאמר הצגת נקודת הקצה של הגילוי באשכול.
הלקוח שלכם משתמש בו גם לחיפוש צמתים. הלקוח משתמש בנקודת הקצה של Discovery כדי לאחזר את טופולוגיית האשכול של המופע שלכם, כדי להפעיל את לקוחות האשכול של OSS Redis ולעדכן אותם במצב יציב. טופולוגיית האשכול שמתקבלת מספקת נקודות קצה של צומתי Redis (שילובים של כתובת IP ויציאה) שצריך לשמור במטמון בזיכרון על ידי לקוח אשכול Redis. הלקוח שלכם יטפל בעדכונים ובהפניות האוטומטיות בלי שיהיה צורך בשינוי נוסף באפליקציה. מידע על התנהגות של גילוי לקוחות ושיטות מומלצות זמין במאמר גילוי לקוחות.
נקודת הקצה של הגילוי זמינה מאוד כי היא מגובה על ידי כמה צמתי Redis בכמה אזורים כדי להציג את טופולוגיית האשכול. טופולוגיית ההצגה דרך נקודת הקצה היא חזקה גם כשמדובר בכשלים בצומת הקצה העורפי או בעדכוני צומת.
נקודת הקצה (endpoint) של Discovery מתנהגת באופן הבא:
נקודת הקצה של הגילוי באשכול נשארת ללא שינוי לאורך מחזור החיים של מופע האשכול, גם במהלך תחזוקה או פעולות אחרות שאתם מבצעים, כמו שינוי גודל או שינוי מספר העותקים.
נקודות הקצה של צומת Redis יכולות להשתנות, ואפשר לעשות בהן שימוש חוזר כשמוסיפים צמתים ומסירים אותם לאורך זמן. מומלץ להשתמש בלקוח של אשכול Redis שיכול לטפל בשינויים האלה באופן אוטומטי באמצעות רענון של הטופולוגיה והפניות אוטומטיות. דוגמאות ללקוחות של אשכול Redis אפשר למצוא בדוגמאות קוד של ספריות לקוח. באפליקציה שלכם לא צריכים להיות יחסי תלות או הנחות שלפיהן נקודות הקצה של הצומת יישארו ללא שינוי עבור אשכול נתון.
נקודת קצה של נתונים
בנוסף לנקודת הקצה של הגילוי, לכל אשכול יש נקודת קצה של נתונים. נקודת הקצה הזו שמורה לשימוש של Memorystore for Redis Cluster כדי לחבר את הלקוח לצמתים באשכול. לכן, אל תתחברו לנקודת הקצה הזו ישירות.