מכרזים

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

ב-10 למרץ 2021, התחלנו לקרוא בחדשות על שריפה אשר השמידה חוות שרתים של אחד מספקי הענן המובילים באירופה, ספק בשם OVHCloud.

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

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

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

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

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

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

במידה ונרצה להוסיף שרידות לשירותי המחשוב, עלינו לפרוס את השרתים במספר availability zones (מספר data centers), מאחורי רכיב load-balancer, על-מנת לוודא שהם נשארים זמינים בכל תרחיש (קריסת data center, מתקפת DDoS, כמות גדולה מאוד של לקוחות מחוברים בו-זמנית ועוד)

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

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

פתרון התאוששות מאסון בתצורת Active-Active

במידה והמטרה העסקית שלנו היה לבנות שכפול של תשתיות ה-IT שלנו בענן, ולוודא זמינות 24×7, עלינו לבחון מספר נושאים:

היבטי מחשוב (Compute)
עלינו לפרוס שרתים וירטואליים (או Containers) ב-availability zones שונים

בסיסי נתונים
עלינו להקים cluster של בסיס נתונים מנוהל, כאשר כל node ב-cluster יותקן ב-availability zone שונה

שירותי אחסון
עלינו להשתמש בשירות אחסון מנוהל (Object storage, block storage, שירות שיתוף קבצים מנוהל וכו'), במקום להקים ולתחזק שרתי קבצים בעצמנו

 

לבניית פתרון התאוששות מאסון בתצורת Active-Active יש יתרונות וחסרונות:

יתרונות:

– השירותים בענן זמינים 24×7

– השפעה מינימלית על הלקוחות שלנו

חסרונות:

– העלות של הקמה ותחזוקת סביבת בתצורת Active-Active עשויה להיות גבוהה מהסיכון של אובדן הזמינות במקרה אסון

– עלינו לקחת בחשבון היבטים של סנכרון מידע בין האתרים

– עלינו לתחזק בצורה שוטפת את שני האתרים, לרמת עדכונים תוכנה/אבטחה

פתרון התאוששות מאסון בתצורת Active/Standby

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

הקמת סביבות ומעבר ידני בין אתרים (Manual fail-over)

היבטי מחשוב (Compute)
עלינו לייצר image של השרתים הווירטואליים (או של ה-Containers) ולסנכרן את ה-images לכלל האתרים. בעת אסון, עלינו לפרוס ידנית את השרתים מה-image שהכנו מראש

בסיסי נתונים
עלינו להתקין cluster של בסיסי נתונים בתצורת fail-over (או להשתמש בעותק לקריאה – Read Replica)

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

הקמת סביבות ומעבר אוטומטי בין אתרים (Automatic fail-over)

היבטי מחשוב (Compute)
עלינו להשתמש ב-Infrastructure as a Code (דוגמת HashiCorp Terraform, AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager וכו') על-מנת להקים בצורה אוטומטית סביבות production שלמות, תוך שימוש בשפות קוד

בסיסי נתונים
עלינו להקים בסיסי נתונים באמצעות Infrastructure as a Code (התקנה, הגדרה, שחזור נתונים וכו')

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

 

לבניית פתרון התאוששות מאסון בתצורת Active/Standby יש יתרונות וחסרונות:

יתרונות:

– פריסה בקלות של מספר רב של סביבות מחשוב, בתוך דקות ספורות

– עלויות נמוכות בשל העובדה שאנו משלמים אך ורק על משאבי מחשוב שאנו משתמשים בפועל

חסרונות:

– זמן לימוד ארוך יחסית לשימוש בשפות סקריפטים

– עלינו לקחת בחשבון היבטים של סנכרון מידע בין האתרים

– עלינו לתחזק בצורה שוטפת את שני האתרים, לרמת עדכונים תוכנה/אבטחה

סיכום

פתרון התאוששות מאסון, אינו חף מטעויות.

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

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

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

מקורות מידע נוספים

OVHcloud data centers engulfed in flames
https://www.zdnet.com/article/ovhcloud-data-centers-engulfed-in-flames/

Blaze destroys servers at Europe's largest cloud services firm
https://www.reuters.com/article/idUSKBN2B20NU

Millions of websites offline after fire at French cloud services firm
https://news-yahoo-com.cdn.ampproject.org/c/s/news.yahoo.com/amphtml/fire-breaks-ovh-building-strasbourg-074135784.html