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

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

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

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

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

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

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

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

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

ב-Memorystore for Redis Cluster נעשה שימוש באסטרטגיית מחזור חיים של פריסה הדרגתית ויצירה לפני השמדה, כדי למנוע השפעה של זמן השבתה שנגרם כתוצאה מתחזוקה. כדי להשיג תחזוקה ללא זמן השבתה, נעשה שימוש ביכולות של הפניה אוטומטית של בקשות בפרוטוקול של Redis OSS Cluster בשילוב עם המנגנונים הבאים של 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 מוסיף קודם רפליקה חדשה לגמרי עם עדכון התוכנה האחרון לשארד. המערכת יוצרת צומת חדש לגמרי, במקום לעדכן צומת קיים, כדי להבטיח שהקיבולת שהוקצתה תישמר במקרה של כשל לא צפוי באתחול.
  2. אם צומת בתוך מחיצת Shard שצריך לעדכן הוא צומת ראשי, הוא מומר קודם לרפליקה לפני ההסרה באמצעות יתירות כשל בשיתוף פעולה.
  3. בשלב הבא, Memorystore מסיר את העותק המשוכפל שמשתמש בתוכנה מהגרסה הקודמת.
  4. התהליך חוזר על עצמו לכל צומת באשכול.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • יום בשבוע. ראשון.
  • שעת התחלה: 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, צריך לוודא שביצעתם את השלבים שלמעלה לפחות שבוע לפני עדכון התחזוקה המתוזמן של המופע. אם לא תעשו זאת, למערכת לא יהיה מספיק זמן להודיע לכם על התחזוקה הקרובה.

ההתראות יישלחו לכתובת האימייל שמשויכת לחשבון שלכם ב-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 מסתיים בתוך חלון הזמן, אבל זה לא תמיד קורה.

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

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

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

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