מידע על פריסות כחול-ירוק ב-Cloud SQL

במאמר הזה מוסבר על פריסות כחול-ירוק (blue-green deployment) ב-Cloud SQL, שמאפשרות לבצע עדכונים במסד הנתונים, כמו שדרוגים של גרסאות ראשיות ושינויים בחומרה, תוך צמצום זמן ההשבתה.

כוונות פריסה ותרחישי שימוש

אפשר ליצור פריסת כחול-ירוק (blue-green deployment) עם כוונה לבצע שדרוג של הגרסה הראשית או בלי כוונה כזו:

  • יצירה עם כוונה (שדרוג גרסה ראשית): שדרוג מנוע מסד הנתונים לגרסה ראשית חדשה יותר. במהלך יצירת הפריסה, Cloud SQL מפעיל את API של בדיקה מוקדמת לשדרוג גרסה ראשית כדי לוודא שיש תאימות לפני שממשיכים בתהליך העבודה של השדרוג.
  • יצירה ללא כוונה (שינויים בהגדרות או בחומרה): שינויים בשלבים בגרסה הנוכחית של מסד הנתונים. תרחישי שימוש כוללים שינוי סוגי מכונות (התאמה לעומס של CPU/RAM), בדיקת דגלים לניהול מסד נתונים או הערכת שינויים באחסון בלי לשדרג את גרסת המנוע.

איך פריסות כחול-ירוק פועלות

פריסות כחול-ירוק (blue-green deployment) ב-Cloud SQL מספקות תהליך עבודה אוטומטי שמאפשר להכין שינויים בסביבה משנית זמנית לפני שמעבירים את התנועה הפעילה.

במהלך פריסת כחול-ירוק (blue-green deployment),‏ Cloud SQL יוצר סביבת Staging נפרדת (ירוקה) שמשקפת את סביבת הייצור הקיימת (כחולה). השירות שומר על שכפול לוגי רציף מכחול לירוק. אתם יכולים לבדוק ביסודיות את התאימות והביצועים של האפליקציה בסביבה הירוקה בלי להשפיע על תנועת הנתונים בסביבת הייצור. כשמוכנים, מפעילים מעבר מהיר שמשייך לסביבה הירוקה סטטוס של קריאה וכתיבה בייצור עם השבתה מינימלית של האפליקציה (בדרך כלל תוך שניות).

רכיבים של פריסת כחול-ירוק

פריסת כחול-ירוק (blue-green deployment) מורכבת מהרכיבים הבאים:

  • סביבה כחולה (מקור): סביבת הייצור הקיימת שלכם שמשרתת באופן פעיל תנועה של אפליקציות. היא מורכבת ממופע המקור לקריאה ולכתיבה ומכל ההגדרות שמשויכות אליו.
  • סביבה ירוקה (יעד): סביבת ביניים זמנית ומבודדת שנוצרה על ידי Cloud SQL כשיבוט של הסביבה הכחולה. הסביבה הירוקה כוללת את השינויים שביקשתם (למשל, גרסה חדשה יותר של מסד נתונים) ונשארת מסונכרנת עם הסביבה הכחולה באמצעות שכפול רציף. ‫Cloud SQL נותן באופן אוטומטי שם למופע הירוק של סביבת הבדיקה באמצעות התבנית BLUE_INSTANCE_NAME-green-UNIQUE_ID (כאשר BLUE_INSTANCE_NAME מקוצר ל-48 תווים לכל היותר ו-UNIQUE_ID הוא מזהה הקסדצימלי באורך 8 תווים).

  • מעבר: התהליך המתוכנן שמתחיל על ידי המשתמש, שבו הסביבה הירוקה הופכת למופע החדש של סביבת הייצור לקריאה ולכתיבה. במהלך המעבר, Cloud SQL מחליף את נקודות הקצה של החיבור, כך שהאפליקציות מתחברות לסביבה הירוקה עם נפילה קצרה בחיבור (בדרך כלל בשניות). השעות השקטות הצפויות במהלך המעבר משתנות בהתאם למהדורת Cloud SQL:

    • מהדורת Cloud SQL Enterprise Plus: זמן ההשבתה של המעבר הוא בדרך כלל פחות משנייה.
    • מהדורת Cloud SQL Enterprise: זמן ההשבתה של המעבר הוא בדרך כלל פחות מ-60 שניות, בהתאם לעומס העבודה ולזמן האחזור של השכפול.

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

  • מחיקה: תהליך ההסרה של משאב הפריסה כחול-ירוק. התנהגות המחיקה משתנה בהתאם לשאלה אם בוצע מעבר:

    • לפני המעבר: מחיקת הפריסה מסירה את מופע ההכנה הירוק ואת משאב הפריסה. המופע הכחול של סביבת הייצור לא מושפע וממשיך להציג תעבורה.
    • אחרי המעבר: מחיקת הפריסה מסירה את המטא-נתונים של הפריסה. כברירת מחדל, גם המופע שהומר (ירוק) וגם המופע הכחול נשמרים. אפשר למחוק את המופע הכחול כדי למנוע חיובים שוטפים.

מחזור החיים של הפריסה והמצבים שלה

פריסת כחול-ירוק עוברת דרך ארבעה שלבים נפרדים במחזור החיים:

  1. יצירה והעברה (PROVISIONING): כשמבקשים פריסה כחול-ירוק, Cloud SQL מקצה מופע יעד ירוק זמני שמשכפל את סביבת הייצור הכחולה. במקרה של שדרוג גרסה מרכזי, Cloud SQL מפעיל גם את API של בדיקה מוקדמת של שדרוג גרסה מרכזי כדי לאמת את התאימות של מסד הנתונים לפני שממשיכים בתהליך השדרוג. ‫Cloud SQL מחיל את השדרוג המבוקש או את שינוי ההגדרה על סביבת הייצור (ירוקה) ומתחיל שכפול לוגי רציף מהסביבה הכחולה לירוקה.
  2. אימות של סביבת הבדיקה (SWITCHOVER_READY או SWITCHOVER_NOT_READY): כשהשכפול הראשוני מסתיים, הפריסה עוברת למצב SWITCHOVER_READY (או SWITCHOVER_NOT_READY אם השכפול נכשל או אם מתרחשות שגיאות). הגרסה הכחולה ממשיכה לטפל בתעבורת נתונים של סביבת ייצור פעילה. מתחברים ל-green כדי להריץ בדיקות אימות, לוודא שהאפליקציה תואמת ולבדוק את ביצועי השאילתות.
  3. הפעלת מעבר (SWITCHOVER_IN_PROGRESS או SWITCHOVER_COMPLETED): כשמפעילים מעבר, Cloud SQL מריץ בדיקות בטיחות מקדימות, מחליף את נקודות הקצה של החיבור, מגדיר את המופע הירוק כמופע פעיל לקריאה ולכתיבה בסביבת הייצור (SWITCHOVER_COMPLETED) ומעביר את המופע הכחול למופע עצמאי לקריאה ולכתיבה. פעולות קריאה וכתיבה פעילות מנותבות באופן בלעדי למופע הירוק, והשכפול הלוגי מהכחול לירוק מופסק. מידע נוסף זמין במאמר בנושא ביצוע מעבר בין פריסות כחולות וירוקות.

  4. מחיקה (DELETING): כשמסיימים את הבדיקה או אחרי שמאמתים את פעולות הייצור, מוחקים את משאב הפריסה. התנהגות המחיקה משתנה בהתאם למצב הפריסה:

    • לפני המעבר (ביטול): אם מחליטים לא להמשיך בהטמעה או אם מתעוררות בעיות באימות, מחיקת ההטמעה מסירה את מופע ההכנה הירוק ומוחקת את מטא-נתוני ההטמעה. מופע הייצור המקורי הכחול לא משתנה וממשיך להעביר תנועה ללא הפרעה.
    • אחרי המעבר (ניקוי): אחרי שהמעבר מסתיים ואתם מאמתים את הפעולות במופע החדש של הסביבה הפעילה, מחיקת הפריסה מסירה את המטא-נתונים של הפריסה. כברירת מחדל, גם מופע הייצור החדש (ירוק) וגם המופע הכחול נשמרים כמופעים עצמאיים לקריאה ולכתיבה. אפשר לציין את האפשרות --delete-old-source כדי למחוק באופן סופי את המופע הכחול ולהפסיק את החיובים עליו.

    מידע נוסף זמין במאמר בנושא מחיקת פריסת כחול-ירוק (blue-green deployment).

מצבי משאבי פריסה

כשבודקים פריסה מסוג blue-green, השדה state מציין את הסטטוס הנוכחי של מחזור החיים שלה:

  • ‫PROVISIONING: הפריסה נוצרת. לשדרוגים של גרסאות ראשיות, Cloud SQL מריץ את ה-API של בדיקת ההתאמה כדי לוודא שהגרסה החדשה תואמת לפני שהוא ממשיך. ‫Cloud SQL מקצה את הסביבה הירוקה, מחיל את השדרוגים המבוקשים ומגדיר שכפול לוגי רציף.
  • ‫SWITCHOVER_READY: הסביבה הירוקה הוקצתה, השכפול הלוגי מכחול לירוק תקין והפריסה מוכנה למעבר.
  • ‫SWITCHOVER_NOT_READY: הפריסה הוקצתה, אבל אי אפשר להתחיל את המעבר. המצב הזה קורה אם השכפול הלוגי נכשל או נעצר, אם השכפול הראשוני לא הושלם או אם בצומת המזווג התגלתה שגיאה.
  • ‫SWITCHOVER_IN_PROGRESS: פעולת מעבר פעילה. ‫Cloud SQL מחליף את נקודות הקצה של החיבור וממיר את המכונה הירוקה למכונת קריאה וכתיבה פעילה בסביבת הייצור.
  • ‫SWITCHOVER_COMPLETED: פעולת המעבר הושלמה בהצלחה. המכונה הירוקה היא עכשיו מכונת קריאה וכתיבה פעילה של הייצור, והמכונה הכחולה נשמרת כמכונת קריאה וכתיבה עצמאית.
  • ‫DELETING: הפריסה נמחקת. אם מוחקים לפני המעבר, Cloud SQL מסיר את מכונת ה-staging הירוקה ומוחק את המטא-נתונים של הפריסה. אם מוחקים אחרי המעבר, Cloud SQL מסיר את המטא-נתונים של הפריסה, ויכול גם למחוק את המכונה הכחולה אם מציינים את הדגל --delete-old-source.
  • ‫STATE_UNSPECIFIED: מצב הפריסה לא ידוע.

מצבים ומוכנות למעבר

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

  • תקינות השכפול וההשהיה: אם השכפול הלוגי בין הכחול לירוק נכשל, מושהה או לא תקין, סטטוס הפריסה משתנה ל-SWITCHOVER_NOT_READY. הפריסה state והפלט של התיאור לא מדווחים על השהיית שכפול, ו-Cloud SQL לא מעריך את השהיית השכפול כבדיקה מוקדמת כשנקבע סטטוס הפריסה. עם זאת, פעולת המעבר נכשלת אם השהיית השכפול גבוהה מדי כשמתחילים את המעבר. כדי להבטיח שהמעבר יתבצע בצורה חלקה, חשוב לוודא שזמן ההשהיה של השכפול הוא מינימלי לפני שמתחילים את המעבר. אפשר לעקוב אחרי השהיית השכפול ב-Cloud Monitoring (על ידי בדיקת מדדים כמו replica_lag ברשימת המדדים של Cloud SQL) או ישירות במכונה הירוקה. מידע נוסף זמין במאמר בנושא מעקב אחרי השהיית רפליקציה.
  • סטטוס הצומת המזווג: בקטע deploymentMappings, כל צומת מזווג מדווח על מצב הצומת שלו (למשל PROVISIONED, UPGRADED, UPGRADE_FAILED, SWITCHOVER_IN_PROGRESS, SWITCHOVER_SUCCEEDED או SWITCHOVER_FAILED). אם בצומת מזווג מתרחשת שגיאה (UPGRADE_FAILED או SWITCHOVER_FAILED), מצב הפריסה הכולל משתנה ל-SWITCHOVER_NOT_READY. אם המעבר נכשל, הניתוב נשאר במופע הכחול ללא אובדן נתונים.
  • פתרון בעיות שקשורות למוכנות למעבר: אם הפריסה מדווחת על SWITCHOVER_NOT_READY, בודקים את השדה errorDetail כדי לאבחן שגיאות בשכפול או בצומת. לפני שמתחילים את המעבר, מוודאים שפיגור השכפול הוא מינימלי, ומוודאים שפעולות DDL פעילות של אצווה או טרנזקציות כתיבה ארוכות במכונה הכחולה הושלמו.

מגבלות

לפני שמשתמשים בפריסות כחול-ירוק (blue-green deployment), חשוב לעיין במגבלות הבאות:

  • מנועים וגרסאות נתמכים: מכונות של Cloud SQL ל-MySQL בגרסה MySQL 5.7 ואילך נתמכות להכנת הגדרות (יצירה ללא כוונה). שדרוג לגרסה ראשית גרסאות יעד (יצירה עם כוונה) נתמכות מ-MySQL 8.0 עד 8.4. אין תמיכה ב-MySQL 8.0.18 לפריסות כחול-ירוק.
  • מנועי מסד נתונים שלא נתמכים: לא ניתן להשתמש ב-Cloud SQL ל-PostgreSQL וב-Cloud SQL ל-SQL Server.
  • מופעים עם רפליקות לקריאה בלבד: פריסות כחול-ירוק לא תומכות במופעים עם רפליקות לקריאה בלבד.
  • הגדרות רשת לא נתמכות: פריסות כחול-ירוק (blue-green deployment) לא תומכות בהגדרות של Private Service Connect לחיבורים יוצאים.
  • אימות קבוצות ב-IAM: פריסות כחול-ירוק (blue-green deployment) לא תואמות לאימות קבוצות ב-IAM ב-MySQL ויכולות לגרום לכשלים במעבר.
  • דרישה לגבי ארכיטקטורת הרשת: מכונות Cloud SQL חייבות להשתמש בארכיטקטורת הרשת החדשה. אין תמיכה במופעים שמשתמשים בארכיטקטורת הרשת הישנה.
  • דרישה לרישום ביומן בינארי: במופעי MySQL צריכים להיות גיבויים אוטומטיים ורישום ביומן בינארי מופעלים כדי לתמוך בשכפול לוגי רציף לסביבה הירוקה.
  • דרישה לגבי גרסת תחזוקה: לפני שיוצרים פריסה כחול-ירוק, צריך לוודא שמופעלת במופע המקור הכחול גרסת התחזוקה העדכנית ביותר. כדי לבדוק או לעדכן את גרסת התחזוקה של המופע, אפשר לעיין במאמר בנושא ביצוע תחזוקה בשירות עצמי.
  • זמינות משאבים: הקצאת מכונות וירטואליות במהלך תהליכי עבודה של פריסת כחול-ירוק (blue-green deployment) – כולל יצירת מכונת ה-staging הירוקה ויצירת המכונה הכחולה אחרי המעבר – עשויה להיות מושפעת ממגבלות של משאבי מחשוב באזור או באזור הזמינות שנבחרו.
  • השבתות לא מתוכננות ויתירות כשל: מעבר בפריסת כחול-ירוק הוא פעולה מתוכננת בלבד שדורשת מופע מקור כחול RUNNING תקין. המופע הירוק של סביבת הבדיקה פועל כרפליקה לקריאה מיוחדת. בדומה לרפליקות לקריאה רגילות, אי אפשר להשתמש במופע הירוק כיעד להעברה אוטומטית במקרה של הפסקת פעילות לא מתוכננת של מופע המקור. כדי להגדיר שחזור אוטומטי של הפסקות פעילות, צריך להגדיר את המכונה לזמינות גבוהה או להשתמש ברפליקה לשחזור מאסון (DR).

חיוב ומחירים

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

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

  • לפני המעבר: אם מבטלים את הפריסה, צריך למחוק אותה כדי להסיר את מופע ההכנה הירוק ולהפסיק את החיובים עליו.
  • אחרי המעבר: מוחקים את הפריסה ומציינים את האפשרות --delete-old-source כדי למחוק באופן סופי את המופע הכחול אחרי שמאמתים את מופע הייצור החדש. אם לא תמחקו את המופע הכחול, תמשיכו לשלם על שני המופעים.

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