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

Last reviewed 2024-08-05 UTC

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

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

מבוא

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

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

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

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

סביבת הייצור היא מקומית

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

גיבוי ושחזור נתונים

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

פתרון 1: גיבוי ל-Cloud Storage באמצעות משימה מתוזמנת

התבנית הזו משתמשת באבני הבניין הבאות של DR:

  • Cloud Storage

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

gcloud storage cp -r SOURCE_DIRECTORY gs://BUCKET_NAME

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

בשלבים הבאים מוסבר איך להטמיע תהליך גיבוי ושחזור באמצעות הפקודה gcloud storage.

  1. מתקינים את gcloud CLI במחשב המקומי שבו משתמשים כדי להעלות את קובצי הנתונים.
  2. יוצרים קטגוריה כיעד לגיבוי הנתונים.
  3. יוצרים חשבון שירות.
  4. יוצרים מדיניות IAM כדי להגביל את הגישה לקטגוריה ולאובייקטים שבה. כוללים את חשבון השירות שנוצר במיוחד למטרה הזו. פרטים על הרשאות גישה ל-Cloud Storage מופיעים במאמר הרשאות IAM ל-gcloud storage.
  5. משתמשים בהתחזות לחשבון שירות כדי לספק למשתמש המקומי Google Cloud(או לחשבון השירות) גישה להתחזות לחשבון השירות שיצרתם קודם. אפשרות אחרת היא ליצור משתמש חדש במיוחד למטרה הזו.
  6. בודקים שאפשר להעלות ולהוריד קבצים בדלי היעד.
  7. מגדירים לסקריפט לוח זמנים להעלאת הגיבויים באמצעות כלים כמו Linux crontab ותזמון המשימות של Windows.
  8. מגדירים תהליך שחזור שמשתמש בפקודה gcloud storage כדי לשחזר את הנתונים לסביבת השחזור של DR ב- Google Cloud.

אפשר גם להשתמש בפקודה gcloud storage rsync כדי לבצע סנכרון מצטבר בזמן אמת בין הנתונים שלכם לבין קטגוריה של Cloud Storage.

לדוגמה, הפקודה gcloud storage rsync הבאה מעתיקה את כל הקבצים או האובייקטים שחסרים או שהנתונים שלהם השתנו, כדי שהתוכן בקטגוריה של Cloud Storage יהיה זהה לתוכן בספריית קובצי המקור. אם נפח הנתונים שהשתנה בין סשנים רצופים של גיבוי קטן יחסית לנפח הכולל של נתוני המקור, שימוש ב-gcloud storage rsync יכול להיות יעיל יותר משימוש בפקודה gcloud storage cp. באמצעות gcloud storage rsync, אפשר להטמיע לוח זמנים של גיבוי בתדירות גבוהה יותר ולהשיג RPO נמוך יותר.

gcloud storage rsync -r SOURCE_DIRECTORY gs:// BUCKET_NAME

מידע נוסף זמין במאמר בנושא הפקודה gcloud storage להעברות קטנות יותר של נתונים מקומיים.

פתרון 2: גיבוי ל-Cloud Storage באמצעות שירות ההעברה לנתונים מקומיים

התבנית הזו משתמשת באבני הבניין הבאות של DR:

  • Cloud Storage
  • שירות להעברת נתונים מקומיים

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

הוראות להעברת נפחים גדולים של נתונים ממיקומים מקומיים ל-Cloud Storage זמינות במאמר העברה או גיבוי של נתונים מאחסון מקומי.

פתרון 3: גיבוי ל-Cloud Storage באמצעות פתרון שער של שותף

התבנית הזו משתמשת באבני הבניין הבאות של DR:

  • Cloud Interconnect
  • אחסון מדורג ב-Cloud Storage

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

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

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

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

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

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

מידע נוסף על פתרונות של שותפים זמין במאמר מציאת Google Cloud השותף המתאים.

גיבוי ושחזור של מסד נתונים

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

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

פתרון 1: גיבוי ושחזור באמצעות שרת שחזור ב- Google Cloud

  1. יוצרים גיבוי של מסד הנתונים באמצעות מנגנוני הגיבוי המובנים של מערכת ניהול מסד הנתונים.
  2. חיבור הרשת המקומית לרשת Google Cloud .
  3. יוצרים קטגוריה של Cloud Storage כיעד לגיבוי הנתונים.
  4. מעתיקים את קובצי הגיבוי ל-Cloud Storage באמצעות gcloud storagegcloud CLI או פתרון של שותף (ראו שלבים שמוסברים קודם בקטע בנושא גיבוי ושחזור נתונים). פרטים נוספים זמינים במאמר מעבר אל Google Cloud: העברת מערכי נתונים גדולים.
  5. מעתיקים את יומני העסקאות לאתר השחזור ב- Google Cloud. גיבוי של יומני העסקאות עוזר לשמור על ערכי RPO נמוכים.

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

  1. יוצרים קובץ אימג' בהתאמה אישית של שרת מסד הנתונים ב- Google Cloud. לשרת מסד הנתונים צריך להיות אותו הגדרות בקובץ האימג' כמו לשרת מסד הנתונים המקומי.
  2. מטמיעים תהליך להעתקת קובצי הגיבוי וקובצי יומן הטרנזקציות המקומיים ל-Cloud Storage. פתרון 1 כולל דוגמה להטמעה.
  3. מפעילים מכונה בגודל מינימלי מהתמונה המותאמת אישית ומצרפים את כל הדיסקים הקשיחים שנדרשים.
  4. מגדירים את הדגל של מחיקה אוטומטית לערך false עבור הדיסקים הקבועים.
  5. מחילים את קובץ הגיבוי האחרון שהועתק קודם ל-Cloud Storage, בהתאם להוראות ממערכת מסד הנתונים לשחזור קובצי גיבוי.
  6. מחילים את קבוצת הקבצים האחרונה של יומני הטרנזקציות שהועתקו ל-Cloud Storage.
  7. מחליפים את המכונה המינימלית במכונה גדולה יותר שיכולה לקבל תנועה של נתוני ייצור.
  8. מעבירים את הלקוחות לנקודה במסד הנתונים המשוחזר ב- Google Cloud.

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

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

פתרון 2: שכפול לשרת המתנה ב- Google Cloud

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

  1. חיבור הרשת המקומית לרשת Google Cloud .
  2. יוצרים קובץ אימג' בהתאמה אישית של שרת מסד הנתונים ב- Google Cloud. ההגדרה של שרת מסד הנתונים בקובץ האימג' צריכה להיות זהה להגדרה של שרת מסד הנתונים המקומי.
  3. מפעילים מכונה מקובץ האימג' בהתאמה אישית ומצרפים את כל דיסקי האחסון המתמיד (persistent disk) שצריך.
  4. מגדירים את הדגל של מחיקה אוטומטית לערך false עבור הדיסקים הקבועים.
  5. מגדירים שכפול בין שרת מסד הנתונים המקומי לבין שרת מסד הנתונים של היעד ב- Google Cloud בהתאם להוראות שספציפיות לתוכנת מסד הנתונים.
  6. בפעולה רגילה, הלקוחות מוגדרים להצביע על שרת מסד הנתונים במקום.

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

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

סביבת הייצור היא Google Cloud

בתרחיש הזה, גם סביבת הייצור וגם סביבת ההתאוששות מאסון (DR) פועלות ב- Google Cloud.

גיבוי ושחזור נתונים

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

התבנית הזו משתמשת באבני הבניין הבאות של DR:

  • סוגי אחסון (storage class) ב-Cloud Storage עם רמות שונות של גישה (Nearline,‏ Coldline ו-Archive)

דיאגרמה קונספטואלית המציגה תמונה שבה העלות יורדת ככל שהנתונים מועברים מדיסקים קבועים ל-Nearline ול-Coldline.

סוגי האחסון Nearline,‏ Coldline ו-Archive Storage מיועדים לאחסון נתונים שניגשים אליהם לעיתים רחוקות, ולכן יש עלויות נוספות שקשורות לאחזור נתונים או מטא-נתונים שאוחסנו בסוגים האלה, וגם משך אחסון מינימלי שעליו אתם מחויבים.

גיבוי ושחזור של מסד נתונים

כשמשתמשים במסד נתונים בניהול עצמי (לדוגמה, אם התקנתם MySQL,‏ PostgreSQL או SQL Server במופע של Compute Engine), חלות אותן דאגות תפעוליות כמו בניהול מסדי נתונים של ייצור מקומיים, אבל כבר לא צריך לנהל את התשתית הבסיסית.

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

למידע נוסף על שימוש ב-Backup and DR לתרחישים של מסדי נתונים בניהול עצמי ב- Google Cloud, אפשר לעיין במקורות הבאים:

Google Cloud

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

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

שחזור שרת מסד נתונים בלי לסנכרן את המצב

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

התבנית הזו משתמשת באבני הבניין הבאות של DR:

  • Compute Engine
  • קבוצות של מופעי מכונה מנוהלים
  • Cloud Load Balancing (איזון עומסים פנימי)

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

תרשים ארכיטקטוני שמציג תמונה של אחסון מתמיד (persistent disk) שצולמה מאחסון מתמיד באזור אחד

בשלבים הבאים מוסבר איך להגדיר את התרחיש הזה:

  1. יצירת רשת VPC.

  2. כדי ליצור אימג' בהתאמה אישית שמוגדר עם שרת מסד הנתונים:

    1. מגדירים את השרת כך שקובצי מסד הנתונים וקובצי היומן ייכתבו לדיסק מתמיד סטנדרטי שמצורף לשרת.
    2. יוצרים קובץ snapshot מדיסק האחסון המתמיד המצורף.
    3. מגדירים סקריפט לטעינה בזמן ההפעלה ליצירת דיסק אחסון מתמיד (persistent disk) מקובץ ה-snapshot ולטעינת הדיסק.
    4. יוצרים תמונה מותאמת אישית של דיסק האתחול.

  3. יוצרים תבנית של הגדרות מכונה שמשתמשת בתמונה.

  4. באמצעות תבנית של הגדרות מכונה, מגדירים קבוצת מופעי מכונה מנוהלים עם גודל יעד של 1.

  5. הגדרת בדיקות תקינות באמצעות מדדים של Cloud Monitoring.

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

  7. מגדירים משימה מתוזמנת ליצירת קובצי snapshot רגילים של דיסק האחסון המתמיד.

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

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

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

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

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

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

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

הווריאציה שתבחרו תהיה תלויה בתקציב, ב-RTO וב-RPO.

שחזור מתוך נתונים פגומים חלקיים במסדי נתונים גדולים מאוד

שכפול אסינכרוני של Persistent Disk מאפשר שכפול של אחסון בלוקים עם RPO נמוך ו-RTO נמוך עבור DR פעיל-סביל בין אזורים. אפשרות האחסון הזו מאפשרת לכם לנהל שכפול של עומסי עבודה ב-Compute Engine ברמת התשתית, ולא ברמת עומס העבודה.

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

יש כמה אסטרטגיות שיכולות לעזור לכם:

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

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

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

שירותים מנוהלים של מסדי נתונים ב- Google Cloud

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

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

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

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

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

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

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

  • אם הנזק מתגלה תוך 7 ימים, אפשר להריץ שאילתה על הטבלה לנקודת זמן בעבר כדי לשחזר את הטבלה לפני הנזק באמצעות snapshot decorators.
  • מייצאים את הנתונים מ-BigQuery ויוצרים טבלה חדשה שמכילה את הנתונים המיוצאים, אבל לא את הנתונים הפגומים.
  • לאחסן את הנתונים בטבלאות שונות לתקופות זמן ספציפיות. השיטה הזו מאפשרת לשחזר רק קבוצת משנה של נתונים לטבלה חדשה, ולא את כל קבוצת הנתונים.
  • ליצור עותקים של מערך הנתונים בפרקי זמן ספציפיים. אפשר להשתמש בעותקים האלה אם התרחש אירוע של השחתת נתונים שלא ניתן לתעד באמצעות שאילתה לנקודת זמן מסוימת (לדוגמה, אם האירוע התרחש לפני יותר מ-7 ימים). אפשר גם להעתיק מערך נתונים מאזור אחד לאזור אחר כדי להבטיח את זמינות הנתונים במקרה של כשלים באזור.
  • אחסון הנתונים המקוריים ב-Cloud Storage, שמאפשר ליצור טבלה חדשה ולטעון מחדש את הנתונים שלא נפגמו. משם תוכלו לשנות את ההגדרות של האפליקציות כך שיפנו לטבלה החדשה.

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

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

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

אם הפעלתם תחזוקה מתוכננת עם השבתה כמעט אפסית ב-Cloud SQL, תוכלו להעריך את ההשפעה של אירועי תחזוקה על המכונות שלכם על ידי סימולציה של אירועי תחזוקה מתוכננת עם השבתה כמעט אפסית ב-Cloud SQL ל-MySQL וב-Cloud SQL ל-PostgreSQL.

ב-Cloud SQL Enterprise Plus edition, אפשר להשתמש בadvanced disaster recovery (DR) כדי לפשט את תהליכי השחזור והחזרה לגיבוי, בלי לאבד נתונים אחרי ביצוע מעבר לגיבוי בעקבות כשל חוצה אזורים.

‫Spanner. אפשר להשתמש בתבניות של Dataflow כדי לבצע ייצוא מלא של מסד הנתונים לקבוצה של קובצי Avro בקטגוריה של Cloud Storage, ולהשתמש בתבנית אחרת כדי לייבא מחדש את הקבצים שיוצאו למסד נתונים חדש של Spanner.

כדי לבצע גיבויים מבוקרים יותר, אפשר להשתמש במחבר Dataflow כדי לכתוב קוד לקריאה ולכתיבה של נתונים ב-Spanner בצינור עיבוד נתונים של Dataflow. לדוגמה, אפשר להשתמש במחבר כדי להעתיק נתונים מ-Spanner אל Cloud Storage כגיבוי. המהירות שבה אפשר לקרוא נתונים מ-Spanner (או לכתוב אותם בחזרה) תלויה במספר הצמתים שהוגדרו. השינוי הזה משפיע ישירות על ערכי ה-RTO.

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

בגיבויים מנוהלים, Spanner Backup and Restore מאפשר ליצור גיבויים עקביים שאפשר לשמור עד שנה. ערך ה-RTO נמוך יותר בהשוואה לייצוא, כי פעולת השחזור מציבה את הגיבוי ישירות בלי להעתיק את הנתונים.

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

‫point-in-time-recovery (PITR) ב-Spanner מאפשרת לכם לשחזר נתונים מנקודה ספציפית בזמן בעבר. לדוגמה, אם מפעיל כותב נתונים בטעות או אם פריסת אפליקציה משחיתה את מסד הנתונים, בעזרת PITR אפשר לשחזר את הנתונים מנקודת זמן בעבר, עד למקסימום של 7 ימים.

‫Managed Airflow. אתם יכולים להשתמש ב-Managed Airflow (גרסה מנוהלת של Apache Airflow) כדי לתזמן גיבויים קבועים של כמהGoogle Cloud מסדי נתונים. אתם יכולים ליצור גרף אציקלי מכוון (DAG) להפעלה לפי לוח זמנים (לדוגמה, מדי יום) כדי להעתיק את הנתונים לפרויקט, למערך נתונים או לטבלה אחרים (בהתאם לפתרון שבו נעשה שימוש), או כדי לייצא את הנתונים ל-Cloud Storage.

אפשר לייצא או להעתיק נתונים באמצעות אופרטורים שונים של Cloud Platform.

לדוגמה, אתם יכולים ליצור DAG כדי לבצע את הפעולות הבאות:

סביבת הייצור היא ענן אחר

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

גיבוי ושחזור נתונים

העברת נתונים בין מאגרי אובייקטים היא תרחיש שימוש נפוץ לתרחישי DR. ‫Storage Transfer Service תואם ל-Amazon S3 והוא הדרך המומלצת להעברת אובייקטים מ-Amazon S3 ל-Cloud Storage.

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

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

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

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

  • מעקב והתראות. ‫Storage Transfer Service מספק התראות Pub/Sub על מגוון אירועים. מומלץ להירשם לקבלת ההתראות האלה כדי לטפל בכשלים לא צפויים או בשינויים בזמני השלמת העבודות.

גיבוי ושחזור של מסד נתונים

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

מה השלב הבא?