התאוששות מאסון בענן - פתרון הגנה על העסק בזמן אסון

התאוששות מאסון

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

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

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

החברה מציעה שני שירותים מרכזיים בתחום:

שירות התאוששות מאסון מבוסס גיבוי

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

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

שירות התאוששות מאסון אוניברסלי

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

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

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

מדוע לבחור בשירות התאוששות מאסון של אופק טכנולוגיות?

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

חישוב עלויות ההשבתה של העסק שלך:

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

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

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

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

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

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

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

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

עלויות זמן ההשבתה תלויות ב:

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

גורמים הקשורים למוניטין ולנאמנות הלקוחות כוללים:

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

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

קצת היסטוריה על התחום:

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

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

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

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

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

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

גיבוי לענן או התאוששות מאסון?

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

עד היום, לקוחות היו צריכים לבחור בין שתי פתרונות:

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

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

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

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

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

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

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

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

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

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

יישום הפתרון אורך בדרך כלל ימים בודדים ולאחר מכן הלקוח מוגן באופן מלא בפתרון גיבוי מקיף כולל התאוששות מאסון לסביבת המחשוב שלו.

הבדלים בין המשכיות עסקית להתאוששות מאסון

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

מהי זמינות גבוהה (HA)?

זמינות גבוהה היא שילוב של מנגנונים המאפשרים זמן פעילות של יישומים וגישה לנתונים. תפיסה זו וטכנולוגיות ה- HA הבסיסיות הן שמאפשרות לארגונים לשמור על רמות SLA של uptime כגון "ארבע תשיעיות" וכו '. זמינות גבוהה של מנגנונים וטכנולוגיות מטפלות בהפסקות שגרתיות שעלולות להיות תוצאה של כשל בחומרה, כשל ברשת, עומס - הפסקות ביצע, או כישלון יישום אחר. אירועי זמינות גבוהה עשויים לכלול את הפריטים הבאים:

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

דוגמאות לטכנולוגיות הזמינות הגבוהה כוללות:

ל- VMware יש "זמינות גבוהה" מובנית בתוך אשכול VMware ESXi המשתמש בשרת vCenter. אם המארח נכשל, ה- VM יופעל מחדש על מחשב מארח בריא.
מערכת מבוססת אשכולות Hyper-V מספקת זמינות גבוהה בעזרת מינוף של הטכנולוגיה הבסיסית של אשכול Windows על מנת זמינות גבוהה דומה למכונות וירטואליות.
שירות Windows Clustering מספק זמינות גבוהה עבור יישומים ושירותים כגון Microsoft SQL Server, שרתי קבצים ושאר השירותים.
מאגרי עומס רשת מספקים יכולות יתירות וניהול עומסים המאפשרות העמסת עומסים על פני צמתים שונים וכן מתן יתירות
זמינות גבוהה בסיסית אחרת בהנדסה עשויה להיות כרוכה במתגי רשת מרובים ולכן יש נתיבים כפולים לנתונים. אספקת כוח מבוססת UPS מספקת זמינות גבוהה מבחינת החשמל. גנרטורים יכולים לספק זמינות גבוהה כאשר יש הפסקת חשמל.

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

מהי התאוששות מאסון (DR)?

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

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

דוגמאות לטכנולוגיות התאוששות מאסון כוללים:

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

למה אתה צריך זמינות גבוהה (HA) והתאוששות מאסון (DR)?

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

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

כיצד לבדוק פתרון התאוששות מאסון בענן

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

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

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

1. כשל מתוכנן ללא אובדן נתונים

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

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

2. כשל לא מתוכנן עם אובדן נתונים

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

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

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

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

3. חזרה לאתר המקומי ללא אובדן נתונים.

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

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

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