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

בהמשך מפורטים כמה שיקולים חשובים שמשפיעים על אופן הפריסה של מכשירי גיבוי ושחזור של Backup and DR:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • חיבור למסוף הניהול של מכשיר ה-Appliance: מומלץ לחבר את הרשת של ספק השירות ל-VPC משותף ברשת שלכם. כל התנועה ממסוף הניהול של ה-Appliance עוברת דרך ה-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.

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