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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי למזער את היעד להתאוששות מאסון (RTO), כדאי לפרוס מכשירים לגיבוי ולשחזור באזורים שבהם נמצאת עומס העבודה של סביבת הייצור ובאזור DR. כך אפשר לוודא שסביבת 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 משותף בתוך הרשת שלכם. כל התנועה ממסוף הניהול של האפליקציה עוברת דרך ה-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.

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