בדף הזה מוסבר איך הארכיטקטורה של Memorystore for Valkey מספקת ותומכת בזמינות גבוהה (HA). בנוסף, מוסבר איך לשפר את הביצועים והיציבות של המכונה באמצעות הגדרות HA מומלצות.
זמינות גבוהה
Memorystore for Valkey מבוסס על ארכיטקטורה עם זמינות גבוהה, שבה הלקוחות ניגשים ישירות לצומתי Memorystore for Valkey מנוהלים. כדי לעשות את זה, הלקוחות מתחברים לנקודות קצה (endpoints) נפרדות, כמו שמתואר במאמר התחברות למכונה של Memorystore for Valkey.
התחברות ישירה למאגרים מספקת את היתרונות הבאים:
חיבור ישיר מונע צעדים (hops) מיותרים, וכך מקצר את זמן הטעינה הלוך ושוב (זמן האחזור של הלקוח) בין הלקוח לצומת של Memorystore for Valkey.
במצב Cluster Mode Enabled, חיבור ישיר מונע נקודת כשל בודדת כי כל פיסת מידע מתוכננת להיכשל באופן עצמאי. לדוגמה, אם תנועה מכמה לקוחות מעמיסה על משבצת (חלק ממרחב המפתחות), כשל בפיצול מגביל את ההשפעה על הפיצול שאחראי על הצגת המשבצת.
הגדרות מומלצות
מומלץ ליצור מכונות עם זמינות גבוהה בכמה אזורים, ולא מכונות באזור אחד, כי הן מספקות אמינות גבוהה יותר. עם זאת, אם אתם בוחרים להקצות מכונה בלי רפליקות, מומלץ לבחור מכונה באזור יחיד. מידע נוסף זמין במאמר מתי להשתמש במכונה באזור יחיד.
כדי להפעיל זמינות גבוהה במכונה, צריך להקצות לפחות רפליקה אחת לכל שאד. אפשר לעשות את זה כשיוצרים את המכונה, או להגדיל את מספר הרפליקות לרפליקה אחת לפחות לכל שאד. הרפליקות מספקות מעבר אוטומטי לגיבוי בעת כשל במהלך תחזוקה מתוכננת וכשל בלתי צפוי של שארינג.
מומלץ להגדיר את הלקוח בהתאם להנחיות שבמאמר שיטות מומלצות ללקוחות. אם תשתמשו בשיטות המומלצות, הלקוח שלכם יוכל לטפל בפריטים הבאים במכונה באופן אוטומטי וללא זמן השבתה:
- התפקיד (מעבר אוטומטי לגיבוי במקרה של כשל)
- נקודת הקצה (החלפת צומת)
- שינויים בהקצאת משבצות שקשורים להפעלת מצב אשכול (הרחבה וצמצום אופקיים בהתאם לעומס של הצרכן)
עותקים
מכונה של Memorystore for Valkey עם זמינות גבוהה היא משאב אזורי. כדי להגן מפני הפסקות חשמל באזור, ב-Memorystore for Valkey המכונות הווירטואליות הראשיות והרפליקות של המקטעים מפוזרות בכמה אזורים. ב-Memorystore for Valkey אפשר להשתמש במכונות עם 0 עד 5 רפליקות לכל פיסת מידע.
אתם יכולים להשתמש ברפליקות כדי להגדיל את קצב הקריאה, אבל יכול להיות שהנתונים לא יהיו עדכניים.
- מצב אשכול מופעל: משתמשים בפקודה
READONLYכדי ליצור חיבור שמאפשר ללקוח לקרוא מרפליקות. - מצב אשכול מושבת: מתחברים לנקודת הקצה של הקורא כדי להתחבר לכל אחת מהרפליקות הזמינות.
דוגמאות למכונות עם מצב אשכול מופעל
התרשימים הבאים ממחישים דוגמאות למכונות שמופעל בהן מצב אשכול:
דוגמה למכונה עם שלושה פיצולים ואפס רפליקות לכל פיצול

דוגמה למכונה עם שלושה פיצולים ורפליקה אחת לכל פיצול

דוגמה למכונה עם שלושה שאדים וכמה רפליקות לכל שאד

דוגמאות למכונות עם מצב אשכול מושבת
התרשים הבא ממחיש דוגמה למכונות שבהן מצב אשכול מושבת:
דוגמה למכונה עם כמה רפליקות

איך מעבר לגיבוי בעת כשל משפיע על האפליקציה
כש-Memorystore for Valkey מקדם רפליקה למכונה הראשית, הוא מבטל את החיבורים הקיימים לנקודת הקצה הראשית של המכונה. במהלך אירועים אוטומטיים של תיקונים ותחזוקה, המכונה לא זמינה למשך 30 שניות בממוצע.
אחרי שהמכונה הופכת לזמינה, Memorystore for Valkey משתמש באותה מחרוזת חיבור או כתובת IP כדי להפנות אוטומטית את האפליקציה למכונה הראשית החדשה. אין צורך לעדכן את האפליקציה.
במהלך יתירות כשל, אם יש חיבורים לנקודת הקצה לקריאה, Memorystore for Valkey מנתק את החיבורים לרפליקה שהוא מקדם למכונה הראשית. עם זאת, Memorystore for Valkey לא מנתק את החיבורים לרפליקות האחרות. אחרי שהמעבר לתצורת יתירות כשל מסתיים והרפליקה החדשה זמינה, Memorystore for Valkey מפנה את החיבורים לרפליקה החדשה.
יתירות כשל אוטומטית
מעבר אוטומטי לגיבוי בעת כשל בתוך פיסת מידע יכול להתרחש בגלל תחזוקה או כשל בלתי צפוי בצומת הראשי. במהלך מעבר לגיבוי בעת כשל, רפליקה מקודמת להיות הראשית. אפשר להגדיר רפליקות באופן מפורש. בנוסף, השירות יכול להקצות באופן זמני רפליקות נוספות במהלך תחזוקה פנימית כדי למנוע זמני השבתה.
מעבר אוטומטי לגיבוי במקרה של כשל מונע אובדן נתונים במהלך עדכוני תחזוקה. למידע נוסף על התנהגות של יתירות כשל אוטומטית במהלך תחזוקה, ראו התנהגות של יתירות כשל אוטומטית במהלך תחזוקה.
משך הזמן של יתירות כשל ותיקון צומת
באירועים לא מתוכננים, כמו קריסה של תהליך בצומת הראשי או כשל בחומרה, מעבר אוטומטי למצב של יתירות כשל יכול להימשך כמה עשרות שניות. בזמן הזה המערכת מזהה את הכשל ובוחרת רפליקה שתהיה המכונה הראשית החדשה.
תיקון הצומת יכול להימשך כמה דקות עד שהשירות יחליף את הצומת שנכשל. זה נכון לגבי כל הצמתים הראשיים והצמתים של הרפליקות. במכונות שאין להן זמינות גבוהה (לא הוקצו רפליקות), תיקון של צומת ראשי שנכשל גם לוקח כמה דקות.
התנהגות הלקוח במהלך מעבר לא מתוכנן לגיבוי בעת כשל
סביר להניח שהחיבורים של הלקוחות יאופסו, בהתאם לאופי התקלה. אחרי השחזור האוטומטי, אפשר לנסות שוב להתחבר באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי להימנע מעומס יתר על הצמתים הראשיים וצומתי הרפליקה.
לקוחות שמשתמשים ברפליקות לקצב העברת נתונים בקריאה עשויים לחוות ירידה זמנית בקיבולת עד שהצומת שנכשל יוחלף באופן אוטומטי.
כתיבות שאבדו
במהלך מעבר לגיבוי בעת כשל שנובע מכשל בלתי צפוי, יכול להיות שפעולות כתיבה שאושרו יאבדו בגלל האופי האסינכרוני של פרוטוקול הרפליקציה של Valkey.
אפליקציות לקוח יכולות להשתמש בפקודה Valkey WAIT כדי לשפר את אבטחת הנתונים בעולם האמיתי.
ההשפעה על מרחב המפתחות של הפסקה זמנית בפעילות של אזור אחד
בקטע הזה מוסבר איך הפסקה זמנית בשירות באזור אחד משפיעה על מכונה של Memorystore for Valkey.
מכונות בכמה אזורים
מכונות HA: אם יש הפסקה זמנית בשירות באזור מסוים, כל מרחב המפתחות זמין לקריאה ולכתיבה, אבל מכיוון שחלק מהעותקים לקריאה בלבד לא זמינים, קיבולת הקריאה מצטמצמת. אנחנו ממליצים מאוד להקצות קיבולת יתר לאשכול, כדי שלמכונה תהיה מספיק קיבולת קריאה במקרה הנדיר של הפסקת שירות באזור אחד. כשההפסקה מסתיימת, הרפליקות באזור המושפע משוחזרות וקיבולת הקריאה של האשכול חוזרת לערך שהוגדר. מידע נוסף מופיע במאמר תבניות לאפליקציות אמינות שניתנות להרחבה.
מכונות ללא זמינות גבוהה (ללא רפליקות): אם יש הפסקה זמנית בשירות באזור מסוים, החלק של מרחב המפתחות שהוקצה באזור המושפע עובר ניקוי נתונים, ואי אפשר לכתוב או לקרוא ממנו למשך ההפסקה הזמנית בשירות. כשההפסקה מסתיימת, המכונות הראשיות באזור המושפע משוחזרות והקיבולת של האשכול חוזרת לערך שהוגדר.
מכונות באזור אחד
- גם במכונות HA וגם במכונות שאינן HA: אם יש הפסקה זמנית בשירות באזור שבו המכונה מוקצית, האשכול לא זמין והנתונים נמחקים. אם יש הפסקה זמנית בשירות באזור אחר, האשכול ממשיך לשרת בקשות קריאה וכתיבה.
שיטות מומלצות
בקטע הזה מתוארות שיטות מומלצות לזמינות גבוהה ולרפליקות.
הוספת רפליקה
כדי להוסיף רפליקה, צריך תמונת מצב של RDB. תמונות מצב של RDB משתמשות בפיצול תהליכים ובמנגנון copy-on-write כדי ליצור תמונת מצב של נתוני הצומת. בהתאם לדפוס הכתיבה לצמתים, הזיכרון שבו הצמתים משתמשים גדל ככל שמועתקים דפים שהכתיבה נוגעת בהם. הזיכרון שבשימוש יכול להיות עד פי שניים מגודל הנתונים בצומת.
כדי לוודא שלצמתים יש מספיק זיכרון להשלמת קובץ ה-snapshot, צריך להשאיר או להגדיר את maxmemory ב-80% מקיבולת הצומת, כך ש-20% יישמרו לתקורה. התקורה הזו של הזיכרון, בנוסף למעקב אחרי קובצי ה-snapshot, עוזרת לכם לנהל את עומס העבודה כדי ליצור קובצי snapshot בצורה תקינה. בנוסף, כשמוסיפים רפליקות, צריך להפחית את תנועת הכתיבה ככל האפשר. מידע נוסף זמין במאמר מעקב אחרי השימוש בזיכרון של מכונה.