אבני בניין של תוכנית התאוששות מאסון (DR)

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

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

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

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

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

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

מחשוב ואחסון

בטבלה הבאה מופיע סיכום של התכונות בשירותי האחסון והמחשוב של Google Cloud , שמשמשים כאבני בניין להתאוששות מאסון:

מוצר	תכונה
Compute Engine	משאבי מחשוב ניתנים להרחבה סוגי מכונות מוגדרים מראש ומותאמים אישית זמני אתחול מהירים תמונות מצב תבניות של הגדרות מכונה קבוצות של מופעי מכונה מנוהלים הזמנות דיסקים לאחסון מתמיד תחזוקה שקופה מיגרציה פעילה
Cloud Storage	מאגר אובייקטים עמיד במיוחד יתירות בין אזורים סוגי אחסון (storage classes) ניהול מחזור החיים של אובייקטים העברת נתונים ממקורות אחרים הצפנה במנוחה כברירת מחדל מחיקה עם אפשרות שחזור
Google Kubernetes Engine (GKE)	סביבה מנוהלת לפריסה ולהתאמה לעומס (scaling) של אפליקציות בקונטיינרים תיקון אוטומטי של צמתים בדיקות פעילות ובדיקות מוכנות נפחי אחסון מתמידים אשכולות אזוריים ואשכולות עם כמה אזורים רישות מרובה אשכולות

במאמר Architecting disaster recovery for cloud infrastructure outages: product reference אפשר לקרוא מידע נוסף על האופן שבו התכונות והעיצוב של המוצרים האלה ושל מוצרים אחרים שלGoogle Cloud יכולים להשפיע על אסטרטגיית ההתאוששות מאסון שלכם.

Compute Engine

‫Compute Engine מספק מכונות וירטואליות (VM). הוא המשאב העיקרי של Google Cloud. בנוסף להגדרת מכונות Compute Engine, להפעלתן ולמעקב אחריהן, בדרך כלל משתמשים במגוון תכונות קשורות כדי ליישם תוכנית DR.

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

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

תבניות של הגדרות מכונה

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

מידע נוסף זמין במקורות המידע הבאים:

• מידע על תבניות של מכונות וירטואליות
• תבניות דטרמיניסטיות של מכונות

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

קבוצות של מופעי מכונה מנוהלים

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

הזמנות

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

דיסקים לאחסון מתמיד ותמונות מצב

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

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

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

תחזוקה שקופה

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

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

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

כלי לייבוא דיסקים וירטואליים

הכלי ייבוא דיסק וירטואלי מאפשר לייבא פורמטים של קבצים, כולל VMDK,‏ VHD ו-RAW, כדי ליצור מכונות וירטואליות חדשות ב-Compute Engine. באמצעות הכלי הזה, אתם יכולים ליצור מכונות וירטואליות ב-Compute Engine עם אותה הגדרה כמו המכונות הווירטואליות המקומיות שלכם. הגישה הזו מתאימה למקרים שבהם אי אפשר להגדיר תמונות של Compute Engine מקובצי ההפעלה של תוכנה שכבר מותקנת בתמונות.

גיבויים אוטומטיים

אפשר להשתמש בתגים כדי להפוך את הגיבויים של מכונות Compute Engine לאוטומטיים. לדוגמה, אתם יכולים ליצור תבנית של תוכנית גיבוי באמצעות שירות Backup and DR, ולהחיל את התבנית באופן אוטומטי על המכונות של Compute Engine.

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

Cloud Storage

‫Cloud Storage הוא מאגר אובייקטים שמתאים במיוחד לאחסון קובצי גיבוי. הוא מספק סוגי אחסון (storage class) שונים שמתאימים לתרחישי שימוש ספציפיים, כמו שמוצג בדיאגרמה הבאה.

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

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

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

Storage Transfer Service מאפשר לייבא נתונים מ-Amazon S3, מ-Azure Blob Storage או ממקורות נתונים מקומיים אל Cloud Storage. בתרחישי DR, אפשר להשתמש ב-Storage Transfer Service כדי:

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

Filestore

מופעי Filestore הם שרתי קבצים מנוהלים מסוג NFS לשימוש עם אפליקציות שפועלות במופעים של Compute Engine או באשכולות GKE.

רמות השירות Filestore Basic ו-Zonal הן משאבים אזוריים ולא תומכות בשכפול בין אזורים, בעוד שמופעים ברמת השירות Filestore Enterprise הם משאבים אזוריים. כדי לשפר את העמידות של סביבת Filestore, מומלץ להשתמש במופעים ברמת Enterprise.

Google Kubernetes Engine

‫GKE היא סביבה מנוהלת ומוכנה לייצור לפריסת אפליקציות בקונטיינרים. ‫GKE מאפשר לכם לתזמן מערכות HA, וכולל את התכונות הבאות:

• תיקון אוטומטי של צמתים. אם צומת נכשל בבדיקות תקינות רצופות במשך תקופה ממושכת (כ-10 דקות), ‏ GKE מתחיל תהליך תיקון של הצומת הזה.
• בדיקות פעילות ובדיקות מוכנות. אפשר לציין בדיקת פעילות, שמודיעה ל-GKE באופן תקופתי שה-Pod פועל. אם ה-Pod נכשל בבקשה לבדיקת תקינות (probe), אפשר להפעיל אותו מחדש.
• אשכולות אזוריים ואשכולות עם כמה אזורים. אפשר לפרוס משאבי Kubernetes בכמה אזורים בתוך אזור מסוים.
• Multi-cluster Gateway מאפשר להגדיר משאבים משותפים לאיזון עומסים בכמה אשכולות GKE באזורים שונים.
• גיבוי ל-GKE מאפשר לכם לגבות ולשחזר עומסי עבודה באשכולות GKE.

נטוורקינג והעברת נתונים

בטבלה הבאה מופיע סיכום של התכונות בשירותי הרשת והעברת הנתונים של Google Cloud , שמשמשים כאבני בניין ל-DR:

מוצר	תכונה
Cloud Load Balancing	בדיקות תקינות איזון עומסים גלובלי איזון עומסים אזורי מעבר לגיבוי בענן במספר אזורים איזון עומסים של כמה פרוטוקולים איזון עומסים חיצוני ופנימי
Cloud Service Mesh	מישור בקרה של Service mesh בניהול Google ניתוב מתקדם של בקשות וכללי מדיניות מקיפים לבקרת תנועה
Cloud DNS	ניהול DNS באמצעות תוכנה בקרת גישה ‫Anycast להצגת אזורים מדיניות DNS
Cloud Interconnect	‫Cloud VPN‏ (IPsec VPN) קישור ישיר בין רשתות שכנות (direct peering)

Cloud Load Balancing

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

Cloud Load Balancing מספק כתובת IP אחת מסוג anycast לאפליקציות שלכם. יכול להיות שלאפליקציות שלכם יש מופעים שפועלים באזורים שונים (לדוגמה, באירופה ובארה"ב), ומשתמשי הקצה מופנים לסט המופעים הקרוב ביותר. בנוסף לאיזון עומסים בשירותים שחשופים לאינטרנט, אפשר להגדיר איזון עומסים פנימי בשירותים שמוגדרים מאחורי כתובת IP פרטית של איזון עומסים. אפשר לגשת לכתובת ה-IP הזו רק ממכונות וירטואליות (VM) שהן פנימיות לענן וירטואלי פרטי (VPC).

מידע נוסף זמין במאמר סקירה כללית על איזון עומסים ב-Cloud.

Cloud Service Mesh

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

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

מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

Cloud DNS

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

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

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

Cloud Interconnect

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

ניהול ומעקב

בטבלה הבאה מופיע סיכום של התכונות בשירותי Google Cloud הניהול והמעקב שמשמשים כאבני בניין להתאוששות מאסון:

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

לוח הבקרה של סטטוס שירותי Cloud

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

Cloud Monitoring

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

בעזרת Cloud Monitoring אפשר ליצור בדיקות זמני פעילות עבור נקודות קצה שזמינות לציבור ועבור נקודות קצה ברשתות ה-VPC. לדוגמה, אתם יכולים לעקוב אחרי כתובות URL, מכונות של Compute Engine, גרסאות של Cloud Run ומשאבים של צד שלישי, כמו מכונות של Amazon Elastic Compute Cloud ‏ (EC2).

השירות המנוהל של Google Cloud ל-Prometheus

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

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

אבני בניין של DR בפלטפורמות שונות

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

תשתית כקוד

הגדרת התשתית באמצעות קוד, במקום באמצעות ממשקים גרפיים או סקריפטים, מאפשרת להשתמש בכלי תבניות הצהרתית ולבצע אוטומציה של הקצאה והגדרה של תשתית בפלטפורמות שונות. לדוגמה, אתם יכולים להשתמש ב-Terraform וב-Infrastructure Manager כדי להפעיל את הגדרת התשתית הדקלרטיבית שלכם.

כלי ניהול הגדרות

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

כלים לניהול תזמור

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

אם אתם עובדים עם קונטיינרים, בדרך כלל אתם משתמשים בכלי תזמור. ‫Kubernetes לא רק מנהל קונטיינרים בתוך Google Cloud (באמצעות GKE), אלא גם מספק דרך לתזמר עומסי עבודה מבוססי-קונטיינרים במספר פלטפורמות. Google Cloud, ‫AWS ו-Microsoft Azure מספקים גרסאות מנוהלות של Kubernetes.

כדי להפיץ תעבורה לאשכולות Kubernetes שפועלים בפלטפורמות שונות של Cloud, אפשר להשתמש בשירות DNS שתומך ברשומות משוקללות וכולל בדיקות תקינות.

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

העברת נתונים

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

שירות Backup and DR

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

מידע נוסף זמין במאמר סקירה כללית על שירות Backup and DR.

תבניות ל-DR

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

העברת נתונים אל Google Cloudוממנו

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

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

• איך מתחברים אל Google Cloud?
• מה רוחב הפס בין אתר הלקוח לבין ספק הקישוריות?
• מה רוחב הפס שהספק מספק ישירות ל Google Cloud?
• אילו נתונים נוספים יועברו באמצעות הקישור הזה?

מידע נוסף על העברת נתונים אל Google Cloudזמין במאמר מעבר אל Google Cloud: העברת מערכי נתונים גדולים.

איזון בין הגדרת תמונות לבין מהירות הפריסה

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

שמירה על עקביות של תמונות מכונה בסביבות היברידיות

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

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

אפשרות נוספת היא להשתמש בכלים לניהול תצורה כמו Chef,‏ Puppet,‏ Ansible או Saltstack כדי להגדיר מכונות עם רמת פירוט גבוהה יותר, ליצור תמונות בסיסיות, תמונות עם הגדרה מינימלית או תמונות עם הגדרה מלאה לפי הצורך.

אפשר גם להמיר ולייבא באופן ידני תמונות קיימות כמו Amazon AMI, תמונות Virtualbox ותמונות דיסק RAW ל-Compute Engine.

הטמעה של אחסון מדורג

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

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

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

• Google Cloud מידע נוסף על מיקום גיאוגרפי ואזורים

• כדאי לקרוא מאמרים נוספים בסדרה הזו בנושא התאוששות מאסון:

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

• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.

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

מחברים:

• גרייס מוליסון | Solutions Lead
• Marco Ferrari | Cloud Solutions Architect