בדף הזה מוסבר איך הארכיטקטורה של Memorystore for Redis Cluster מספקת ותומכת בזמינות גבוהה (HA). בדף הזה מוסבר גם איך לשפר את הביצועים והיציבות של האשכול באמצעות הגדרות HA מומלצות.
מידע נוסף על שיקולים ספציפיים לאזור זמין במאמר מיקום גיאוגרפי ואזורים.
זמינות גבוהה
Memorystore for Redis Cluster מבוסס על ארכיטקטורה עם זמינות גבוהה, שבה הלקוחות ניגשים ישירות למכונות וירטואליות מנוהלות של Memorystore for Redis Cluster. הלקוחות שלכם עושים את זה על ידי התחברות לכתובות רשת של רסיסים בודדים, כמו שמתואר במאמר התחברות למופע של Memorystore for Redis Cluster.
לחיבור ישיר ל-shards יש את היתרונות הבאים:
חיבור ישיר מונע נקודת כשל בודדת, כי כל שארד מתוכנן להיכשל באופן עצמאי. לדוגמה, אם תנועה מכמה לקוחות מעמיסה יתר על המשבצת (חלק ממרחב המפתחות), כשל של רסיס מגביל את ההשפעה לרסיס שאחראי על הצגת המשבצת.
חיבור ישיר מאפשר להימנע מניתובים ביניים, וכך מצמצם את זמן הלוך ושוב (השהיית הלקוח) בין הלקוח לבין המכונה הווירטואלית של Redis.
הגדרות מומלצות
מומלץ ליצור מופעים מרובי-אזורים עם זמינות גבוהה במקום מופעים של אזור יחיד, כי הם מספקים אמינות טובה יותר. עם זאת, אם בוחרים להקצות מופע ללא רפליקות, מומלץ לבחור מופע של אזור יחיד. מידע נוסף זמין במאמר מתי כדאי להשתמש באשכול עם אזור אחד.
כדי להפעיל זמינות גבוהה למופע, צריך להקצות לפחות עותק אחד לכל רסיס. אפשר לעשות את זה כשיוצרים את המופע, או להגדיל את מספר העותקים כך שיהיה לפחות עותק אחד לכל שארד. הרפליקות מספקות מעבר אוטומטי לגיבוי במהלך תחזוקה מתוכננת וכשל לא צפוי של שארד.
מומלץ להגדיר את הלקוח בהתאם להנחיות שבמאמר שיטות מומלצות ללקוח Redis. שימוש בשיטות מומלצות מאפשר ללקוח OSS Redis לטפל באופן אוטומטי וחלק בתפקיד (מעבר אוטומטי לגיבוי) ובשינויים בהקצאת משבצות (החלפת צומת, הגדלה או הקטנה של מספר הצרכנים) עבור האשכול, ללא השבתה.
עותקים
מכונה של Memorystore for Redis Cluster עם זמינות גבוהה היא משאב אזורי. המשמעות היא שהמכונות הווירטואליות הראשיות והמשוכפלות של הרסיסים מפוזרות על פני אזורים רבים כדי להגן מפני הפסקת חשמל אזורית. Memorystore for Redis Cluster תומך במכונות עם 0 עד 5 רפליקות לכל shard.
אפשר להשתמש בעותקים כדי להגדיל את קצב העברת הנתונים לקריאה על ידי שינוי קנה המידה של הקריאות.
כדי לעשות את זה, צריך להשתמש בפקודה READONLY כדי ליצור חיבור שיאפשר ללקוח לקרוא מהרפליקות. לפרטים נוספים על קריאה משכפולים, אפשר לעיין במאמר Scale with Redis Cluster.
דוגמה לאשכול עם 0 עותקים משוכפלים לכל רסיס
דוגמה לאשכול עם עותק אחד לכל רסיס
דוגמה לאשכול עם כמה עותקים משוכפלים לכל רסיס
מעבר אוטומטי לגיבוי (failover)
מעבר אוטומטי לגיבוי בתוך שארד יכול לקרות בגלל תחזוקה או כשל בלתי צפוי של הצומת הראשי. במהלך מעבר לגיבוי, העותק הופך לעותק הראשי. אפשר להגדיר רפליקות באופן מפורש. בנוסף, השירות יכול להקצות באופן זמני רפליקות נוספות במהלך תחזוקה פנימית כדי למנוע השבתה.
מעבר אוטומטי לגיבוי מונע אובדן נתונים במהלך עדכוני תחזוקה. מידע נוסף על התנהגות המעבר האוטומטי לגיבוי בזמן תחזוקה זמין במאמר התנהגות המעבר האוטומטי לגיבוי בזמן תחזוקה.
משך הזמן של מעבר לשירות גיבוי ותיקון הצומת
מעבר גיבוי אוטומטי יכול להימשך עשרות שניות במקרה של אירועים לא מתוכננים, כמו קריסת תהליך של צומת ראשי או כשל בחומרה. במהלך הזמן הזה המערכת מזהה את הכשל ובוחרת בעותק משוכפל להיות הראשי החדש.
תיקון הצומת יכול להימשך כמה דקות עד שהשירות יחליף את הצומת שנכשל. הדבר נכון לגבי כל הצמתים הראשיים והמשוכפלים. במקרים שבהם אין זמינות גבוהה (לא הוקצו רפליקות), תיקון של צומת ראשי שנכשל גם לוקח זמן של כמה דקות.
התנהגות הלקוח במהלך מעבר גיבוי אוטומטי לא מתוכנן
סביר להניח שהחיבורים של הלקוחות יאופסו בהתאם לאופי הכשל. אחרי שחזור אוטומטי, אפשר לנסות שוב להתחבר באמצעות השהיה מעריכית לפני ניסיון חוזר כדי להימנע מעומס יתר על הצמתים הראשיים וצמתי העותק.
לקוחות שמשתמשים בעותקים משוכפלים כדי להגדיל את קצב העברת הנתונים לקריאה עשויים לחוות ירידה זמנית בקיבולת עד שהצומת שנכשל יוחלף באופן אוטומטי.
כתיבות שאבדו
במהלך מעבר לגיבוי בעקבות כשל לא צפוי, יכול להיות שפעולות כתיבה שאושרו יאבדו בגלל האופי האסינכרוני של פרוטוקול השכפול של Redis.
אפליקציות לקוח יכולות להשתמש בפקודה WAIT של Redis כדי לשפר את בטיחות הנתונים בעולם האמיתי. זהו ניסיון להשגת התוצאה הטובה ביותר, אבל יש לכך מחיר כפי שמוסבר במסמכי התיעוד של פקודת Redis WAIT.
ההשפעה על מרחב המפתחות של הפסקת חשמל באזור אחד
בקטע הזה מוסבר איך הפסקת חשמל באזור יחיד משפיעה על מופע של Memorystore for Redis Cluster.
מופעים בכמה אזורים
מופעי HA: אם יש הפסקת חשמל באזור מסוים, כל מרחב המפתחות זמין לקריאה ולכתיבה, אבל מכיוון שחלק מהרפליקות לקריאה לא זמינות, קיבולת הקריאה מופחתת. מומלץ מאוד להקצות יותר מדי קיבולת לאשכול כדי שלמופע תהיה מספיק קיבולת קריאה, במקרה הנדיר של הפסקת חשמל באזור יחיד. אחרי שההשבתה מסתיימת, העותקים המשוכפלים באזור המושפע משוחזרים, וקיבולת הקריאה של האשכול חוזרת לערך שהוגדר. מידע נוסף מופיע במאמר תבניות לאפליקציות עמידות שניתנות להרחבה.
מופעים ללא זמינות גבוהה (ללא עותקים): אם יש הפסקת חשמל באזור מסוים, חלק ממרחב המפתחות שהוקצה באזור המושפע עובר ניקוי נתונים, ולא ניתן לבצע בו פעולות כתיבה או קריאה למשך ההפסקה. אחרי שההפסקה מסתיימת, השרתים הראשיים באזור המושפע משוחזרים והקיבולת של האשכול חוזרת לערך שהוגדר.
מופעים של אזור יחיד
- גם מקרים של זמינות גבוהה וגם מקרים של זמינות לא גבוהה: אם יש הפסקת חשמל באזור שבו מוקצה המופע, האשכול לא זמין והנתונים נמחקים. אם יש הפסקת חשמל באזור אחר, האשכול ממשיך להציג בקשות קריאה וכתיבה. אחרי שההפסקה מסתיימת, הקיבולת המוגדרת של האשכול משוחזרת.
שיטות מומלצות
בקטע הזה מתוארות שיטות מומלצות לזמינות גבוהה ולשכפולים.
הוספת עותק
כדי להוסיף רפליקה צריך ליצור תמונת מצב של RDB. תמונות מצב של RDB משתמשות בפיצול תהליכים ובמנגנון 'העתקה בעת כתיבה' כדי ליצור תמונת מצב של נתוני הצומת. בהתאם לדפוס הכתיבה לצמתים, הזיכרון שבו נעשה שימוש בצמתים גדל כשהדפים שהכתיבה נוגעת בהם מועתקים. הזיכרון שבשימוש יכול להיות עד פי שניים מגודל הנתונים בצומת.
כדי לוודא שלצמתים יש מספיק זיכרון כדי להשלים את התמונה, צריך להגדיר את maxmemory ל-80% מהקיבולת של הצומת, כך ש-20% יהיו שמורים לתקורה. התקורה הזו של הזיכרון, בנוסף לתמונות המצב של המעקב, עוזרת לכם לנהל את עומס העבודה כדי ליצור תמונות מצב מוצלחות. בנוסף, כשמוסיפים רפליקות, כדאי להקטין את נפח תנועת הכתיבה ככל האפשר. מידע נוסף זמין במאמר בנושא מעקב אחרי אשכול עם עומס כתיבה גבוה.