מידע על תחזוקה

בדף הזה מוסבר איך מתבצעת תחזוקה של אשכולות ב-Memorystore for Redis Cluster. הוא גם מספק מידע והמלצות להגדרות שאפליקציות הלקוח צריכות להכיר כדי לנצל את העובדה שתחזוקה של Memorystore for Redis Cluster לא גורמת להשבתה. ההמלצות האלה רלוונטיות גם לאשכולות זמינים במיוחד וגם לאשכולות ללא עותקים משוכפלים. עם זאת, אנחנו ממליצים מאוד על הגדרת זמינות גבוהה לכל תרחישי השימוש בסביבת ייצור.

‫Memorystore for Redis Cluster מעדכן את האשכולות באופן שוטף כדי לוודא שהשירות אמין, יעיל, מאובטח ועדכני. העדכונים האלה נקראים תחזוקה. התחזוקה מנוהלת באופן מלא על ידי השירות ומתוכננת כך שלא תהיה השפעה על זמן ההשבתה.

בדרך כלל עבודות התחזוקה נכללות בקטגוריות הבאות:

  • תכונות של Memorystore. כדי להפעיל חלק מהתכונות, נדרש עדכון תחזוקה של Memorystore.
  • תיקוני אבטחה למערכת ההפעלה. אנחנו עוקבים כל הזמן אחרי נקודות חולשה חדשות באבטחה שמזוהות במערכת ההפעלה. כשאנחנו מזהים איומים חדשים, אנחנו מתקנים את מערכת ההפעלה כדי להגן עליכם מפני סיכונים חדשים.
  • תיקונים למסדי נתונים. התחזוקה יכולה לכלול עדכון של Redis כדי לשפר את מאפייני האבטחה, הביצועים והאמינות של אשכולות מעבר למה ש-Redis מספק.

הגדרת אפליקציית הלקוח

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

  1. כדי לוודא שכל תחזוקה מתוזמנת לא תשפיע על אפליקציית הלקוח, צריך להשתמש בלקוח של אשכול Redis של OSS ולהגדיר אותו בהתאם להנחיות שבמאמר שיטות מומלצות לשימוש בלקוח Redis. ההגדרות המומלצות של הלקוח יכולות למנוע איפוסים של חיבורים באמצעות רענונים תקופתיים של הטופולוגיה בתוך השורה ורוטציות של חיבורים ברקע.
  2. בודקים את אפליקציית הלקוח באמצעות סדרה של פעולות עדכון (כמו הגדלה או הקטנה של הקיבולת, שינויים במספר העותקים) בזמן שמריצים עומס עבודה מייצג בצמתים הראשיים ובצמתים של העותקים, ועוקבים אחרי ההשפעה על הלקוח. העדכונים האלה בודקים את הלוגיקה של רענון הטופולוגיה בתוך השורה בלקוחות, את ההשפעה של סנכרון מלא, את גילוי הצמתים החדשים ואת היכולת להסיר צמתים קיימים. הבדיקה עוזרת לוודא שהלקוח מוגדר בצורה נכונה כדי למנוע השפעה שלילית על האפליקציה.

תחזוקה מתוזמנת

ב-Memorystore for Redis Cluster נעשה שימוש באסטרטגיית מחזור חיים של פריסה הדרגתית ויצירה לפני השמדה, כדי למנוע השפעה של השבתה שנגרמת כתוצאה מתחזוקה. אפשר לבצע תחזוקה ללא השבתה באמצעות היכולות של פרוטוקול Redis להפניית בקשות, בשילוב עם המנגנונים הבאים של Memorystore:

  1. מעבר גיבוי לשחזור מתואם ללא אובדן נתונים.
  2. הסרת צומת בצורה חלקה כדי לאפשר ללקוחות להתעדכן בטופולוגיה של האשכול בלי להשפיע על הזמינות.
  3. נקודות הקצה של Private Service Connect באשכול לא מושפעות מתחזוקה. מידע נוסף על נקודות הקצה האלה זמין במאמר נקודות קצה של אשכול.

התנהגות השירות שמתוארת בקטעים הבאים חלה רק על תחזוקה מתוזמנת. מידע על ההשפעה של אירועים לא מתוכננים כמו כשלים בחומרה זמין במאמר התנהגות הלקוח במהלך יתירות כשל לא מתוכננת.

אסטרטגיית פריסה הדרגתית

פריסות תחזוקה של Memorystore for Redis Cluster מתבצעות בהיקף הולך וגדל, ובקצב שמאפשר זיהוי כשל מוקדם מספיק כדי לצמצם את ההשפעה ולבסס את יציבות המערכת. זמני ההרצה (הזמן שבו העדכון מוחל ונבדק לפני שהוא נחשב להצלחה והמערכת ממשיכה) משולבים בכל צי האשכולות של Memorystore בקנה מידה של השירות. בנוסף, זמני ההמתנה משולבים באשכול בכל האזורים באזור (מספר דומיינים של תקלות) כדי לצמצם את היקף ההשפעה, אם יש כזה.

במקרה של אשכול שהוגדר לזמינות גבוהה, מתעדכן לכל היותר תחום/אזור אחד של תקלות בכל זמן נתון, כדי לוודא שלרסיס של האשכול, כולל העותק הראשי והעותקים המשוכפלים, יש זמינות גבוהה לאורך כל העדכון. בנוסף, רק כמה צמתי Redis מתעדכנים בכל זמן נתון. העדכונים מתבצעים באמצעות מנגנון מחזור חיים של יצירה לפני השמדה, כדי למקסם את היציבות של האשכול. האסטרטגיה הזו מועילה במיוחד כשמעדכנים אשכול עם הרבה רסיסים. החלת העדכונים רק על חלק קטן ממרחב המפתחות הכולל של המשתמשים בכל זמן נתון ממקסמת את זמינות הנתונים.

אסטרטגיית מחזור חיים מסוג Create-before-destroy

ל-Redis cluster יש כמה shards. לכל שארד יש צומת ראשי אחד ואפס או יותר צמתים משוכפלים. ב-Memorystore נעשה שימוש בתהליך הבא כדי לעדכן צומת Redis ראשי או צומת שכפול קיים בכל רסיס:

  1. ב-Memorystore for Redis Cluster, קודם כל נוספת רפליקה חדשה לגמרי עם עדכון התוכנה האחרון לשארד. ‫Memorystore יוצר צומת חדש לגמרי, במקום לעדכן צומת קיים, כדי להבטיח שהקיבולת שהוקצתה תישמר במקרה של כשל לא צפוי באתחול.
  2. אם צומת בתוך הרסיס שצריך לעדכן הוא צומת ראשי, הוא מומר קודם לשכפול לפני ההסרה באמצעות מעבר גיבוי (failover) מתואם.
  3. בשלב הבא, Memorystore מסיר את העותק המשוכפל שמשתמש בתוכנה מהגרסה הקודמת.
  4. התהליך חוזר על עצמו לכל צומת באשכול.

האסטרטגיה של יצירה לפני השמדה עוזרת לשמור על הקיבולת שהוקצתה לאשכול, בהשוואה לפריסה מתגלגלת טיפוסית שמתעדכנת במקום, אבל גורמת להפסקת זמינות (ולפעמים לאובדן נתונים) באפליקציית הלקוח. לרסיסים ללא עותקים משוכפלים, Memorystore for Redis Cluster עדיין מקצה עותק משוכפל חדש, מתאם את המעבר לגיבוי בשעת כשל ומחליף את הצומת הראשי הקיים של הרסיס.

שלב 1: מוסיפים עותק משוכפל של Redis

השלב הראשון במנגנון create-before-destroy הוא להוסיף צומת משוכפל עם התוכנה העדכנית באמצעות מנגנון ה-OSS Redis של סנכרון מלא, כדי להעתיק את הנתונים מהצומת הראשי לצומת המשוכפל. הפעולה הזו מתבצעת על ידי יצירת עותק של תהליך צאצא ושימוש בשכפול ללא דיסק כדי לאתחל את העותק. ‫Memorystore for Redis Cluster תומך בשכפול ללא דיסק. אלא אם מפעילים התמדה, ב-Memorystore for Redis Cluster לא נעשה שימוש בדיסקים במהלך השכפול.

כדי להפיק את המרב מארכיטקטורת ההרחבה האופקית של האשכול, מומלץ להקצות מספר גבוה יותר של רסיסים כדי לצמצם את גודל מרחב המפתחות בתוך הצומת. מערך נתונים קטן יותר לכל צומת עוזר לצמצם את ההשפעה של זמן האחזור של הפיצול של פעולת סנכרון מלאה. היא גם מאיצה את העתקת הנתונים בין הצמתים.

שלב 2: מעבר גיבוי אוטומטי מתואם של השרת הראשי

אם צומת Redis שצריך לעדכן הוא צומת ראשי,‏ Memorystore קודם מבצע מעבר גיבוי לשעת חירום מתואם לצומת המשוכפל שנוסף לאחרונה, ואז ממשיך בהסרת הצומת. במהלך מעבר הגיבוי האוטומטי המתואם, הלקוח וצמתי Redis פועלים יחד ומשתמשים באסטרטגיות הבאות כדי למנוע השבתה של האפליקציה:

  1. בקשות נכנסות מלקוחות נחסמות באופן זמני בצומת הראשי, כדי לאפשר חלון זמן שבו אפשר לוודא שהעותק הקיים מסונכרן ב-100% עם הצומת הראשי.
  2. העותק המשוכפל משלים את תהליך הבחירה כדי להשתלט על התפקיד הראשי.
  3. הצומת הראשי הקודם, שהוא עכשיו העתק, מבטל את החסימה של הבקשות הקיימות ומפנה אותן לצומת הראשי החדש באמצעות פרוטוקול של אשכול Redis ב-OSS. כל בקשה חדשה שנשלחת לצומת המשוכפל הקודם ממשיכה להיות מופנית לצומת הראשי החדש.
  4. הלקוח שלכם, שמתאים ל-Redis-cluster, מרענן את הטופולוגיה שלו בזיכרון. הוא לומד את הכתובת של נקודת הקצה הראשית החדשה, ולא צריך יותר הפניות אוטומטיות.

בדרך כלל, מעבר גיבוי אוטומטי מתואם צריך להימשך עשרות אלפיות השנייה. עם זאת, הגודל הכולל של האשכול יכול להגדיל את זמן האחזור של המעבר לגיבוי. כך גם לגבי נתונים בתהליך שעדיין לא הועברו לעותקים. גודל האשכול יכול להשפיע על ההתכנסות בצמתים הראשיים, מה שמשפיע על קבלת ההחלטות לגבי בחירת הצומת הראשי החדש.

שלב 3: מסירים את העותק המשוכפל של Redis

השלב האחרון במנגנון create-before-destroy הוא הסרת צומת העותק המשוכפל בתוכנה הקודמת. הסרה פתאומית של צומת תשפיע על אפליקציות לקוח, כי הלקוחות שומרים במטמון את פרטי נקודת הקצה ואת הטופולוגיה של האשכול. ב-Memorystore for Redis Cluster, הסרת עותק משוכפל של Redis מתוכננת כך שתתבצע בצורה חלקה, כדי לאפשר לאפליקציות לקוח לרענן את הטופולוגיה שלהן לפני שמתרחש כיבוי קשיח של הצומת. הטופולוגיה מותאמת אישית כדי לאפשר ללקוחות ללמוד על העותק החדש. בנוסף, הטופולוגיה שוכחת את העותק המשוכפל שיוסר לפני שהוא מוסר.

צומת העותק שבו פועלת הגרסה הקודמת של התוכנה נשמר למשך תקופת ניקוז מסוימת, בדרך כלל כמה דקות, שבמהלכה הוא מתחיל להפנות מחדש את בקשות הקריאה הנכנסות לצומת הראשי של הרסיס שלו. הוא מאפשר ללקוח של האשכול לרענן את הטופולוגיה של האשכול וללמוד על נקודות הקצה החדשות של העותק. אם הלקוח מנסה להגיע לצומת שהוסר אחרי תקופת ההמתנה, הניסיון נכשל, מה שגורם לרענון של טופולוגיית האשכול בלקוח האשכול, כדי שהוא ילמד על שינוי העותק. רענונים חדשים של טופולוגיית האשכול לא מזהים את צומת העותק שיש להסיר.

הגדרות תחזוקה

באמצעות Memorystore, אתם יכולים להתאים אישית את לוחות הזמנים של התחזוקה בהתאם לצרכים של האפליקציה ולמזער את ההפרעות. כדי לעשות את זה, צריך להגדיר חלון זמן לתחזוקה של האשכול.

חלונות התחזוקה מוגדרים לכל אשכול Memorystore, והם מאפשרים את אפשרויות ההגדרה הבאות:

  • היום בשבוע. היום שבו מתבצעת התחזוקה.
  • שעת התחלה. השעה שבה מתחילה התחזוקה.

משך חלון הזמן לתחזוקה הוא שעה אחת. שימו לב: במקרים מסוימים, יכול להיות שהתחזוקה תימשך מעבר לחלון הזמן שבחרתם.

אחרי שמגדירים חלון זמן לתחזוקה לאשכול, מערכת Memorystore for Redis Cluster מתזמנת תחזוקה אוטומטית בעתיד בהתאם להעדפות שהגדרתם לחלונות זמן לתחזוקה.

חלונות זמן לתחזוקה שמוגדרים כברירת מחדל

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

  • חלון זמן באמצע השבוע (שני עד שישי). ‫22:00 עד 6:00

  • חלון הזמנים בסוף השבוע. שישי, 22:00 עד שני, 6:00

דוגמה לתחזוקה

מפתחים שמנהלים שירות של עגלת קניות אצל קמעונאי אחראים לפקח על סביבת ייצור שכוללת אשכול. כדי להבטיח ביצועים אופטימליים במהלך התחזוקה, כדאי לתזמן אותה לזמן שבו העומס על האשכול מינימלי, בדרך כלל בסביבות חצות ביום ראשון.

במקרה כזה, אפשר להגדיר את חלון זמן לתחזוקה של אשכול הייצור כך:

  • היום בשבוע. יום ראשון.
  • שעת התחלה. ‫1:00.

התראות על תחזוקה קרובה

כדי לוודא שתקבלו עדכונים על אירועי תחזוקה באשכול, אתם יכולים להגדיר התראות באימייל לגבי תחזוקה קרובה לפחות שבוע לפני שהיא מתוכננת. הנושא של ההתראות האלה יהיה "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".

בנוסף, תישלח התראה כשהתחזוקה של האשכול תתחיל. שורת הנושא של האימייל תהיה "Maintenance is undergoing for your Cloud Memorystore instance [your-cluster-name]".

בסיום התחזוקה, נשלחת הודעה על סיום. כותרת האימייל היא "Completed Maintenance for your Cloud Memorystore instance [your-cluster-name]".

אם Memorystore יתזמן מחדש את התחזוקה, תקבלו אימייל עם הודעה על ביטול התחזוקה. שורת הנושא של האימייל הזה תהיה "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".

כדי לקבל את ההתראות האלה על תחזוקה, צריך להביע הסכמה. כדי להירשם לקבלת התראות על תחזוקה:

  1. הגדרת חלון זמן לתחזוקה
  2. הפעלת התראות על תחזוקה

כדי לקבל התראות על תחזוקה מ-Memorystore, צריך לוודא שביצעתם את השלבים האלה לפחות שבוע לפני עדכון התחזוקה המתוזמן של האשכול. אם לא תעשו את זה, ל-Memorystore for Redis Cluster לא יהיה מספיק זמן להודיע לכם על התחזוקה הקרובה.

‫Memorystore for Redis Cluster שולח התראות לכתובת האימייל שמשויכת לחשבון שלכם ב-Google. אי אפשר להגדיר כתובת אימייל חלופית בהתאמה אישית (לדוגמה, כתובת אימייל חלופית של צוות). בשלב הזה, אין לנו אפשרות לשלוח התראות לכתובת אימייל אחרת.

אם נרשמים לקבלת התראות על תחזוקה, מקבלים התראות על כל אשכולות Memorystore עם תחזוקה מתוזמנת בפרויקט שצוין. אם נרשמתם כמנויים, תקבלו התראה נפרדת לכל אשכול.

הוראות לאיתור פעולות תחזוקה מתוזמנות מופיעות במאמר איתור פעולות תחזוקה מתוזמנות.

קביעת מועד חדש לתחזוקה

אם חלונות תחזוקה מוגדרים לאשכול שלכם, בחלק הזה מוסבר איך לתזמן מחדש את התחזוקה. לדוגמה, אם שירות חדש אמור להיות מושק במהלך חלון הזמנים הנוכחי לתחזוקה, יכול להיות שתרצו לדחות את חלון הזמנים לתחזוקה עד כמה ימים אחרי ההשקה.

אפשר לתזמן מחדש את התחזוקה תוך 14 יום מהמועד המקורי שנקבע. במסגרת תזמון מחדש של תחזוקה, בוחרים באחת מהאפשרויות הבאות:

  • עדכון עכשיו: במקום לחכות לחלון זמן לתחזוקה המתוזמן, אפשר להחיל את העדכונים על האשכול באופן מיידי.
  • יום ושעה בהתאמה אישית: אפשר לבחור כל שעה בטווח של 14 ימים מתאריך ושעת התחזוקה המקוריים.

כשקובעים מחדש את מועד התחזוקה, חלות ההגבלות הבאות:

  • אם נותרה פחות משעה עד למועד התחזוקה הנוכחי שנקבע, לא תוכלו לשנות את מועד התחזוקה.
  • אם התזמון מחדש יצליח, תישלח הודעת אימייל לאישור הביטול של התחזוקה הקודמת, ותישלח הודעה חדשה על תחזוקה עתידית עם התזמון המעודכן.

הוראות לשינוי המועד של עבודות התחזוקה מופיעות במאמר שינוי המועד של עבודות התחזוקה.

שאלות נפוצות

בקטע הזה מפורטות תשובות לשאלות נפוצות בנושא תחזוקה של Memorystore for Redis Cluster.

איך יודעים מתי מתוכננת תחזוקה לאשכול?

כדי לדעת מתי מתוכננת תחזוקה לאשכול שלכם, מומלץ להירשם לקבלת התראות ולהגדיר חלון זמן לתחזוקה. אפשר גם לבדוק את האשכול באופן ידני כדי לראות אם הפרמטר maintenanceSchedule מופיע בתשובה.

מתי תקבלו התראה מ-Memorystore for Redis Cluster על תחזוקה קרובה?

אם נרשמתם לקבלת התראות על תחזוקה והגדרתם חלון זמן לתחזוקה, תקבלו מ-Memorystore for Redis Cluster התראה באימייל לפחות שבוע לפני אירוע תחזוקה.

כמה זמן אפשר לדחות את התחזוקה?

אחרי שתקבעו מועד לתחזוקה של האשכול, תוכלו להתחיל את העדכון של האשכול באופן מיידי או לדחות את העדכון עד שבועיים מהתאריך והשעה המקוריים שנקבעו לתחזוקה.

לדוגמה, אם קבעתם תחזוקה ל-11 באוקטובר בשעה 23:15, תוכלו לדחות את התחזוקה עד 25 באוקטובר בשעה 23:15. אם לא תבצעו שום פעולה, התחזוקה תתבצע בתאריך ובשעה שנקבעו.

מידע נוסף זמין במאמר בנושא שינוי מועד התחזוקה.

אילו שיטות מומלצות יאפשרו לכם לעדכן את התחזוקה בצורה חלקה?

כדי להבטיח חוויית עדכון חלקה, מומלץ לבצע את הפעולות הבאות:

  1. פועלים לפי ההוראות להגדרת אפליקציית הלקוח.
  2. מגדירים את חלון זמן לתחזוקה ליום ולשעה שבהם יש תעבורת נתונים מינימלית באשכול (לדוגמה, ימי ראשון בחצות).
  3. הפעלת התראות על תחזוקה לכן, מערכת Memorystore for Redis Cluster שולחת לכם התראה באימייל לפחות שבעה ימים לפני שמתבצע עדכון תחזוקה באשכול.
  4. אם אין לכם שעה שבה השימוש באפליקציה נמוך או לא קיים, אז תשתמשו בברירת המחדל של השירות להשקות הדרגתיות. ברירת המחדל הזו כוללת שיטות מומלצות לעדכוני תחזוקה. מידע נוסף זמין במאמר בנושא תחזוקה מתוזמנת.

מתי מומלץ להחיל עדכון תחזוקה באופן מיידי?

אתם יכולים להחיל עדכון תחזוקה באופן מיידי על אשכול בדיקה כדי לראות איך העדכון משפיע על האפליקציה. אתם יכולים לבדוק את ההשפעה של העדכון הזה. אם יש בעיות בעדכון, אפשר לדחות את התחזוקה באשכולות הייצור עד לפתרון הבעיות.

אם התאריך והשעה הנוכחיים מתאימים לעדכון של האשכול, ואתם צופים עומס גבוה על האשכול בעתיד, אתם יכולים להריץ את עדכון התחזוקה באופן מיידי.

האם עדכוני תחזוקה תמיד מסתיימים בתוך חלון הזמן לתחזוקה?

‫Memorystore for Redis Cluster מתחיל עדכון תחזוקה בתוך חלון התחזוקה שאתם מציינים. בדרך כלל, העדכון של Memorystore for Redis Cluster מסתיים בתוך חלון הזמן, אבל זה לא תמיד קורה.

האם אפשר להשבית את התחזוקה או לתזמן תחזוקה באשכולות מסוימים קודם?

אי אפשר לבטל את התחזוקה או לשלוט בסדר התחזוקה של האשכולות. אבל אחרי שתקבלו את ההתראה הראשונית על התחזוקה, תוכלו לתזמן מחדש את התחזוקה ולדחות אותה עד שבועיים.

המאמרים הבאים

  • כאן תוכלו לראות את ההרשאות שאתם צריכים כדי לנהל את חלונות התחזוקה של האשכול.