כיצד ניתן למנוע את ה"אסון" הבא עם Azure Site Recovery

מעוניין לשתף?

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

מהו Azure Site Recovery?

זהו שירות ענן מנוהל של Microsoft Azure המאפשר התאוששות מאסון (Disaster Recover) עבור ארכיטקטורות ענן או ארכיטקטורות היברידיות. השירות מאפשר לשכפל בקלות כל מכונה ווירטואלית, כולל מערכות פיזיות On-prem בענן (בדרך כלל ב-Region אחר). בעת אסון או השבתה מתוכננת או לא מתוכננת, המערכת מבצעת Failover תוך שחזור מהיר של כל הנתונים בתהליך מובנה, מוכח ומסודר שמבטיח המשכיות עסקית רציפה.

פתרון Azure Site Recovery מאפשר לבצע המשכיות עסקית במספר תרחישים שונים:

  • Hyper-V to Azure – המשכיות עסקית לסביבת Hyper-V המקומית בAzure.
  • Hyper-V to Hyper-V – המשכיות עסקית מסביבת Hyper-V מקומית וסביבת Hyper-V משנית.
  • VMware/Physical to Azure – המשכיות עסקית לסביבת VMware או שרתים פיזיים.
  • VMware/Physical to VMware – המשכיות עסקית מסביבת VMware לסביבת VMware משנית.
  • Azure to Azure – המשכיות עסקית לשרתי IaaS ב-Azure מ-Region אחד ל-Region אחר.

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

ההגדרה והניהול של ההמשכיות העסקית מבוצעים במסגרת ה- Azure Management Portal. אין צורך בניהול של patchים או של תחזוקת שרתים, הכל מנוהל במסגרת השירות. באמצעות השימוש בשירות ASR ניתן להנות מRTO (Recovery Time Objective) וRPO (Recovery Point Objective) נמוכים במיוחד.

כיצד מקימים פרוייקט המשכיות עסקית?

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

  • שלב התכנון – זהו שלב קריטי המשלב הביטים טכניים ועסקיים גם יחד. כך למשל, בשלב זה בוחנים את הצרכים מבחינת RPO ו- RTO, נפחי האחסון הנדרשים, רוחבי הפס של הרשת וכו'.
  • הקמת הסביבות והגדרתן – לאחר שלב התכנון מגיע שלב ההטמעה. במסגרת זו מגדירים את הסביבות ואת תהליך הרפליקציה. תהליך זה כולל הגדרת סביבת הDR בענן, הגדרת הרשת, האחסון ומדיניות הרפליקציה.
  • רפליקציה ראשונית – תהליך הרפליקציה הראשוני לוקח זמן ממשוך מכיוון שהוא כולל את כל (או רוב) המידע ולא רק את הדלתא\השינויים. זהו תהליך רגיש, לכן יש לתכננו באופן מוקפד ומבעוד מועד כך שלא יפריע למהלך התקין של הארגון.
  • בדיקת ההתאוששות (Failover) – בשלב זה ניתן לבדוק את תהליך ההתאוששות מאסון. ASR מאפשר לבצע בדיקה שכזאת על ידי כך שמדמים מצב שבו צריך לבצע Failover וכך לבחון את מוכנות הסביבות והמערכות.
  • ניטור הרפליקציה ופתרון בעיות – כחלק מתהליך ה-DR מאוד חשוב לנטר את הרפליקציות ולבדוק שיעדי ה- RPO נשמרים. מעבר לאספקת התראות על Jobים שונים, ASR גם כולל Event Log Source משלו המשמש לבצע תהליך פתרון בעיות עבור בעיות שונות ברפליקציה.
  • ביצוע מיגרציה – באמצעות יכולת המיגרציה של ASR ניתן לבצע מיגרציה והמערכת באופן אוטומטי דואגת לכך שה- workload יעבור מיגרציה במלואו, תהליך הרפליקציה יפסק, והחיוב עבור המכונה שממנה בוצעה המיגרציה יפסק.

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

כתבות נוספות שיעניינו אותך

מרץ 7, 2019   •

EXPERDA TEAM

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

אפריל 15, 2019   •

EXPERDA TEAM

While the SQL Server 2016 integrated the R programming, SQL Server 2017 allows you to execute both the R and Python script within the database server.