בדף הזה מתוארים המפרטים של האשכולות והצמתים במכונות של 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. כשמוסיפים vCPU לצמתים גדולים יותר ויותר (הגדלת קנה מידה), יכול להיות שביצועי 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זמין במאמר תצורות נתמכות של מכונות.כמה נפח אחסון מקבלים? צריך לעיין בעמודה Default writable keyspace capacity (קיבולת ברירת המחדל של מרחב מפתחות שניתן לכתיבה) בטבלה הקודמת. כאן מוצג כמה נפח אחסון זמין למפתחות שלכם כברירת מחדל.
מיצוי נפח האחסון אם רוצים למצות את נפח האחסון, בעמודה 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, בוחרים סוג צומת למכונה ומציינים את מספר הרסיסים של המכונה. אחרי שיוצרים את המופע, וככל שהצרכים של הקיבולת של המופע משתנים, יכול להיות שיהיה צורך לשנות את גודל המופע בדרכים הבאות:
- שינוי מספר הרסיסים של המופע. הפעולה הזו נקראת הרחבה אופקית.
כדי להגדיל את הקיבולת של מופע באופן אופקי, מבצעים אחת מהפעולות הבאות:
- מוסיפים שרדים למכונה. זה נקרא הרחבה אופקית של המכונה.
- מסירים את הרסיסים מהמופע. זו הרחבה אופקית של המכונה.
- משנים את סוג הצומת של המופע. הפעולה הזו נקראת שינוי גודל אנכי. כדי לשנות את הגודל של מופע באופן אנכי, צריך לשנות את סוג הצומת של המופע לאחד מסוגי הצמתים הבאים:
- מעבר לסוג צומת גדול יותר. הפעולה הזו מרחיבה את המופע למעלה.
- שינוי לסוג צומת קטן יותר. זוהי הפחתה של המופע.
מפרט האשכול
בקטע הזה מוצגים הקיבולת המינימלית והמקסימלית של האשכול, בהתאם לצורה של האשכול, לסוג הצומת ולמספר העותקים.
קיבולת מינימלית לכתיבה
קיבולת הכתיבה היא כמות האחסון שזמינה לכתיבת מפתחות. היא שווה לגודל של צומת מופע אחד. לכן, בהתאם לסוג הצומת, קיבולת הכתיבה המינימלית היא בין 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 ומספר יציאה. הוראות לאיתור נקודת הקצה של הגילוי באשכול זמינות במאמר הצגת נקודת הקצה של הגילוי באשכול.
הלקוח שלכם משתמש בו גם לגילוי צמתים. הלקוח משתמש בנקודת הקצה של הגילוי כדי לאחזר את טופולוגיית האשכול של המופע שלכם, כדי להפעיל את לקוחות האשכול של OSS Redis ולעדכן אותם במצב יציב. טופולוגיית האשכול שמתקבלת מספקת נקודות קצה של צמתים של Redis (שילובי IP ופורט) שניתן לשמור במטמון בזיכרון על ידי לקוח האשכול של Redis. לאחר מכן, הלקוח שלכם מטפל בעדכונים ובהפניות אוטומטית, בלי שיידרש שינוי נוסף באפליקציה. למידע על התנהגות הגילוי של הלקוח ועל שיטות מומלצות, אפשר לעיין במאמר בנושא גילוי לקוחות.
נקודת הקצה של הגילוי זמינה מאוד כי היא מגובה על ידי כמה צמתי Redis בכמה אזורים כדי לספק את טופולוגיית האשכול. אספקת הטופולוגיה דרך נקודת הקצה היא חזקה גם כשמתמודדים עם כשלים בצומת העורפי או עם עדכוני צמתים.
נקודת הקצה של Discovery מתנהגת באופן הבא:
נקודת הקצה של הגילוי באשכול לא משתנה לאורך מחזור החיים של מופע האשכול, גם במהלך תחזוקה או פעולות אחרות שאתם מבצעים, כמו הגדלה או הקטנה של מספר העותקים.
נקודות הקצה של צומתי Redis יכולות להשתנות ולהיות בשימוש חוזר, ככל שמוסיפים צמתים ומסירים אותם לאורך זמן. מומלץ להשתמש בלקוח של אשכול Redis שיכול לטפל בשינויים האלה באופן אוטומטי באמצעות רענון של הטופולוגיה והפניות אוטומטיות. דוגמאות ללקוחות של אשכול Redis אפשר למצוא בדוגמאות קוד של ספריות לקוח. באפליקציה שלכם לא צריכות להיות תלויות או הנחות שנקודות הקצה של הצמתים יישארו ללא שינוי עבור אשכול נתון.
נקודת קצה של נתונים
בנוסף לנקודת הקצה של הגילוי, לכל אשכול יש נקודת קצה של נתונים. נקודת הקצה הזו שמורה לשימוש של Memorystore for Redis Cluster כדי לחבר את הלקוח לצמתים באשכול. לכן, אל תתחברו לנקודת הקצה הזו ישירות.