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

הנה כמה שיקולים חשובים שמשפיעים על פריסת מכשירי הגיבוי והשחזור של Backup and DR:

  • מהן הדרישות של הארגון שלכם לגבי יעד זמן ההתאוששות (RTO)? ה-RTO הוא משך הזמן המקסימלי שבו אתם יכולים להרשות לעצמכם להיות בלי הנתונים. לדוגמה, אם ה-RTO הוא 4 שעות,אתם צריכים להיות מסוגלים לגשת לנתונים תוך 4 שעות מרגע הכשל.

  • האם אתם צריכים לרכז את ניהול הגיבויים? אתם צריכים להחליט אם אתם רוצים לנהל את הגיבויים באופן מרוכז או לא.

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

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

עומסי העבודה נמצאים באזור אחד

אסטרטגיית הגיבוי הטובה ביותר באזור מסוים תלויה בצרכים שלכם.

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

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

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

אם אתם צריכים גם Backup and DR

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

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

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

עומסי העבודה נמצאים בכמה אזורים

אסטרטגיית הגיבוי הטובה ביותר בין אזורים תלויה בצרכים שלכם.

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

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

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

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

אם אתם צריכים גם Backup and DR

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

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

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

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

הטופולוגיה המומלצת של הרשת ל-Backup and DR

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

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

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

שיטות מומלצות לשימוש ב-VPC משותף

מומלץ לפעול לפי השיטות הבאות:

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

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

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

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

    • גישה פרטית ל-Google: מומלץ להפעיל גישה פרטית ל-Google בכל תת-רשת שבה מתקינים מכשיר גיבוי/שחזור. כך אפשר לוודא שמכשיר הגיבוי/השחזור יכול לתקשר עם ממשקי API, כמו Compute Engine,‏ Cloud Storage ו-Cloud Logging, שחשובים לפעולת המעקב וההתראות. כדי לפשט ולשפר את החיבורים לממשקי API של Google Cloud , כדאי להגדיר את פענוח ה-DNS של private.googleapis.com, כפי שמתואר בקטע סיכום של אפשרויות ההגדרה. כדי להגדיר גישה פרטית ל-Google, מגדירים את כללי חומת האש ממכשירי הגיבוי/השחזור כך שיאפשרו חיבורים לטווח ה-CIDR‏ 199.36.153.8/30 ביציאת TCP‏ 443.

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