מדריך להכנת תוכנית התאוששות מאסון (DR)

Last reviewed 2024-07-05 UTC

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

הסדרה מורכבת מהחלקים הבאים:

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

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

יסודות התכנון של DR

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

  • ‫A יעד משך ההתאוששות (RTO), שהוא משך הזמן המקסימלי המקובל שבו האפליקציה יכולה להיות במצב אופליין. הערך הזה מוגדר בדרך כלל כחלק מהסכם רמת שירות (SLA) רחב יותר.
  • יעד להתאוששות מאסון (RPO), שהוא משך הזמן המקסימלי המקובל שבמהלכו יכול להיות שאפליקציה תאבד נתונים בגלל אירוע משמעותי. המדד הזה משתנה בהתאם לדרכים שבהן נעשה שימוש בנתונים. לדוגמה, נתוני משתמשים שמשתנים לעיתים קרובות יכולים להיות עם RPO של כמה דקות בלבד. לעומת זאת, נתונים פחות קריטיים שמשתנים לעיתים רחוקות יכולים להיות עם RPO של כמה שעות. (המדד הזה מתאר רק את משך הזמן, ולא מתייחס לכמות או לאיכות הנתונים שאבדו).

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

תרשים שמראה שזמן התאוששות קצר (RTO) או נקודת שחזור קרובה (RPO) מתאימים לעלות גבוהה.

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

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

מידע נוסף על SLO ו-SLA זמין בספר Site Reliability Engineering של Google.

יכול להיות שאתם מתכננים ארכיטקטורה לזמינות גבוהה (HA). זמינות גבוהה (HA) לא חופפת לחלוטין להתאוששות מאסון (DR), אבל לעיתים קרובות צריך לקחת אותה בחשבון כשחושבים על ערכי RTO ו-RPO. זמינות גבוהה עוזרת להבטיח רמה מוסכמת של ביצועים תפעוליים, בדרך כלל זמן פעולה, לתקופה ארוכה מהרגיל. כשמריצים עומסי עבודה של ייצור ב-Google Cloud, יכול להיות שמשתמשים במערכת שמפוזרת באופן גלובלי, כך שאם משהו משתבש באזור מסוים, האפליקציה ממשיכה לספק שירות גם אם היא זמינה פחות. בעצם, האפליקציה הזו מפעילה את תוכנית ה-DR שלה.

למה Google Cloud?

‫Google Cloud יכול לצמצם באופן משמעותי את העלויות שקשורות ל-RTO ול-RPO, בהשוואה לעמידה בדרישות של RTO ו-RPO בפריסה מקומית. לדוגמה, בתכנון DR צריך להתייחס למספר דרישות, כולל:

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

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

‫Google Cloud מציע כמה תכונות שרלוונטיות לתכנון DR, כולל:

  • רשת גלובלית. ל-Google יש אחת מרשתות המחשבים הגדולות והמתקדמות בעולם. הרשת של Google בשדרה מרכזית מושתתת על רישות מתקדם המוגדר על ידי תוכנה ומספקת שירותי שמירה במטמון קצה לביצועים מהירים, עקביים וניתנים להתאמה.
  • יתירות. כשיש כמה נקודות נוכחות (PoP) ברחבי העולם, יש יתירות חזקה. הנתונים שלכם משוכפלים אוטומטית במכשירי אחסון בכמה מיקומים.
  • יכולת הרחבה. Google Cloud מתוכנן להתרחב כמו מוצרים אחרים של Google (לדוגמה, חיפוש ו-Gmail), גם כשחווים עלייה חדה בתנועה. שירותים מנוהלים כמו Cloud Run,‏ Compute Engine ו-Firestore מספקים לכם התאמה אוטומטית לעומס שמאפשרת לאפליקציה שלכם לגדול ולהצטמצם לפי הצורך.
  • אבטחה. מודל האבטחה של Google מבוסס על עשרות שנים של ניסיון בעזרה ללקוחות לשמור על בטיחות באפליקציות של Google כמו Gmail ו-Google Workspace. בנוסף, צוותי הנדסת אמינות האתרים ב-Google עוזרים להבטיח זמינות גבוהה ולמנוע ניצול לרעה של משאבי הפלטפורמה.
  • עמידה בדרישות. ‫Google עוברת באופן קבוע ביקורות עצמאיות של צד שלישי כדי לוודא ש- Google Cloud עומדת בתקנות ובשיטות המומלצות בנושא אבטחה, פרטיות ותאימות. Google Cloud עומדת בתקנים כמו ISO 27001,‏ SOC 2/3 ו-PCI DSS 3.0.

תבניות DR

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

הדרך שבה תתמודדו עם תקר תלויה במידת ההכנה שלכם:

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

יצירת תוכנית מפורטת להתאוששות מאסון

בקטע הזה מפורטות המלצות ליצירת תוכנית DR.

תכנון בהתאם ליעדי ההתאוששות

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

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

תכנון שחזור מקצה לקצה

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

הגדרת משימות ספציפיות

כשמגיע הזמן להפעיל את תוכנית ההתאוששות מאסון, אתם לא רוצים להיתקע בניסיון לנחש מה המשמעות של כל שלב. כל משימה בתוכנית ה-DR צריכה לכלול פקודה או פעולה קונקרטית אחת או יותר, שלא משתמעת לשתי פנים. לדוגמה, "Run the restore script" (הפעלת סקריפט השחזור) היא הוראה כללית מדי. לעומת זאת, הפקודה 'Open a shell and run /home/example/restore.sh' (פתיחת מעטפת והרצת /home/example/restore.sh) היא מדויקת וקונקרטית.

הטמעה של אמצעי בקרה

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

הכנת התוכנה

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

לוודא שאפשר להתקין את התוכנה

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

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

תכנון פריסה רציפה לשחזור

ערכת הכלים של פריסה רציפה (CD) היא רכיב חיוני כשפורסים את האפליקציות. כחלק מתוכנית השחזור, צריך לקחת בחשבון איפה בסביבה המשוחזרת יפרסו את הארטיפקטים. תכננו איפה אתם רוצים לארח את סביבת ה-CD ואת הארטיפקטים – הם צריכים להיות זמינים ופעילים במקרה של אסון.

הטמעה של אמצעי בקרה לצורכי אבטחה ותאימות

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

הגדרת אבטחה זהה בסביבות DR וייצור

חשוב לוודא שהבקרות ברשת מספקות את אותה הפרדה וחסימה שקיימות בסביבת הייצור של המקור. למדו כיצד להגדיר VPC משותף וחומות אש כדי לאפשר לכם ליצור בקרה מרכזית על הרישות והאבטחה של ה-Deployment שלכם, להגדיר רשתות משנה ולשלוט בתעבורה הנכנסת והיוצאת. הסבר על השימוש בחשבונות שירות כדי להחיל הרשאות מינימליות על אפליקציות שניגשות לממשקי API של Google Cloud . חשוב להשתמש בחשבונות שירות כחלק מכללי חומת האש.

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

  • אם סביבת הייצור שלכם היא Google Cloud, קל לשכפל את מדיניות IAM בסביבת ה-DR. אתם יכולים להשתמש בכלים של תשתית כקוד (IaC), כמו Terraform, כדי לפרוס את מדיניות IAM בסביבת הייצור. לאחר מכן משתמשים באותם כלים כדי לקשר את המדיניות למשאבים המתאימים בסביבת ה-DR, כחלק מהתהליך של הקמת סביבת ה-DR.

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

  • צריך להגדיר מדיניות IAM כדי להעניק הרשאות מתאימות למוצרים. לדוגמה, יכול להיות שתרצו להגביל את הגישה לקטגוריות ספציפיות ב-Cloud Storage.

  • אם סביבת הייצור שלכם נמצאת אצל ספק אחר של שירותי ענן, צריך למפות את ההרשאות במדיניות IAM של הספק האחר למדיניות IAM. Google Cloud

אימות האבטחה של ה-DR

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

מוודאים שהמשתמשים יכולים לגשת לסביבת ה-DR

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

כדי לנהל באופן מרכזי את הגישה של אדמינים למכונות וירטואליות (VM) שמופעלות, צריך להפעיל את התכונה OS Login בפרויקטים שמהווים את סביבת ה-DR. Google Cloud

הדרכה למשתמשים

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

מוודאים שסביבת ה-DR עומדת בדרישות התאימות

מוודאים שהגישה לסביבת ה-DR מוגבלת רק לאנשים שצריכים גישה. חשוב לוודא שנתונים של פרטים אישיים מזהים (PII) צונזרו והוצפנו. אם אתם מבצעים בדיקות חדירה רגילות בסביבת הייצור, אתם צריכים לכלול את סביבת ה-DR כחלק מההיקף הזה ולבצע בדיקות רגילות על ידי הקמת סביבת DR.

חשוב לוודא שבזמן שסביבת ה-DR פועלת, כל היומנים שנאספים ממנה מועברים לארכיון היומנים של סביבת הייצור. באופן דומה, חשוב לוודא שתוכלו לייצא את יומני הביקורת שנאספים דרך Cloud Logging לארכיון של sink היומן הראשי כחלק מסביבת ה-DR. שימוש במתקני יעד הייצוא. לגבי יומני אפליקציות, צריך ליצור שיקוף של סביבת הרישום ביומן והמעקב המקומית. אם סביבת הייצור שלכם היא ספק ענן אחר, צריך למפות את שירותי הרישום והמעקב של הספק הזה לשירותים המקבילים של Google Cloud . צריך להגדיר תהליך לפורמט של קלט בסביבת הייצור.

התייחסות לנתונים ששוחזרו כמו לנתוני ייצור

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

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

איך מוודאים שתוכנית ה-DR פועלת

לוודא שאם מתרחש אסון, תוכנית ה-DR פועלת כמצופה.

שמירה על יותר מנתיב אחד לשחזור נתונים

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

בודקים את התוכנית באופן קבוע

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

  • אוטומציה של הקצאת משאבים לתשתית. אפשר להשתמש בכלים מסוג תשתית כקוד (IaC) כמו Terraform כדי לבצע אוטומציה של הקצאת משאבים בתשתית שלכם ב- Google Cloud. אם סביבת הייצור שלכם פועלת במקום, ודאו שיש לכם תהליך ניטור שיכול להתחיל את תהליך התאוששות מאסון כשהוא מזהה כשל, ושיוכל להפעיל את פעולות השחזור המתאימות.
  • מעקב אחרי הסביבות באמצעות Google Cloud Observability. ל-Google Cloud יש כלים מצוינים לרישום ביומן ולמעקב שאפשר לגשת אליהם באמצעות קריאות API, וכך להפוך את הפריסה של תרחישי שחזור לאוטומטית על ידי תגובה למדדים. כשמתכננים בדיקות, חשוב לוודא שיש לכם מערכת מתאימה למעקב ולהתראות, שיכולה להפעיל פעולות שחזור מתאימות.

  • מבצעים את הבדיקה שצוינה קודם:

    • בודקים שההרשאות וגישת המשתמש פועלות בסביבת ה-DR כמו בסביבת הייצור.
    • ביצוע בדיקות חדירה בסביבת ה-DR.
    • מבצעים בדיקה שבה נתיב הגישה הרגיל אל Google Cloud לא פועל.

מה השלב הבא?

שותפים ביצירת התוכן

מחברים: