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