התאוששות מאסון והמשכיות עסקית על הענן של אמזון
התאוששות מאסון Disaster Recovery – DR והמשכיות עסקית – Business Continuity היו מאז ומעולם נושאים שהעסיקו את מערכי ה-IT והובילו להוצאות גדולות ומשמעותיות על מערכות ואמצעי אחסון שהמתינו למקרה אסון.
בשל מגבלות תקציב ועצלות תחזוקתית, מערכות ההתאוששות מאסון סובלות פעמים רבות מפערים ואי עמידה ביעדי ההתאוששות. ארגונים מתקשים להחזיק את המערכות מעודכנות בצמוד לעדכוני התוכנה של המערכת הראשית, ובתקופות כלכליות קשות, מתקשים במיוחד להפנות תקציבים לתמיכה במערכות ההתאוששות.
הענן של אמזון מציע חלופה מצויינת בכל הנוגע להתאוששות מאסון מאחר והוא מהווה אתר נפרד ומרוחק הכולל אחסון ויכולות עיבוד. היתרון הגדול בשימוש בענן לצורך התאוששות מאסון הוא ביכולת להקטין את ההוצאות השוטפות למינימום תוך שימוש ביתרונות המשמעותיים ביותר של הענן: תשלום רק על המשאבים הנצרכים ויכולת התרחבות (scale) כמעט בלתי מוגבלת בעת הצורך.
תכנון מערכת התאוששות מאסון מחייבת התייחסות לפרק הזמן המקסימאלי הנדרש להגעה לרמת השירות הנדרשת בעת אסון (Recovery Time Objective) וכן לפגיעה המותרת בעדכניות הנתונים (Recovery Point Objective). החלטות בנושאים אלה הן בעלות משמעויות כלכליות ואופרטיביות והן המדריכות את תכנון ותפעול מערכת ההתאוששות.
בהתייחס לנושאים אלה, להלן תיאורם של מספר מימדים חשובים והכרחיים לתכנון ותפעול מערכות התאוששות מאסון, תוך ציון שירותי הענן של אמזון הרלוונטיים לכל מימד.
הענן של אמזון מציע את חבילת שירותי אחסון הנתונים העשירה ביותר הקיימת כיום. החבילה כוללת שירותים מנוהלים לאחסון קבצים ואובייקטים, שירותיי בסיסי נתונים מבוססי RDBMS כגון (MySQL, Oracle, SQL Server), שירותי NoSQL וכן שירותי Block Storage.
בצורה הפשוטה ביותר, ניתן לאחסן את המידע על גבי שירות האחסון Amazon S3, המבטיח durability של מעל 99.99% ומחיר נמוך (בזמן כתיבת שורות אלה המחיר ל GB הוא 5-10 סנט כתלות בכמות הנתונים המאוחסנת).
שירות זה מתאים במיוחד לאחסון קבצים ואובייקטים, ויכול, בנוסף, להוות פתרון טוב וזול לגיבוי בסיסי נתונים שלמים.
בעת הצורך, ניתן להפעיל יחידת עיבוד בענן המריצה בסיס נתונים RDBMS כלשהו ולטעון את הגיבוי מתוך S3 ליחידת העיבוד. במקרה של נתונים הנצרכים כשרת קבצים, ניתן לצרוך את הנתונים ישירות משירות S3.
במידה ודרוש פתרון מהיר יותר לאתחול, ניתן לבחור בין שתי חלופות נוספות. האחת היא יצירה ותחזוקה של Elastic Block Storage (EBS) המכיל ווליומים של דטה אותם ניתן להצמיד ליחידות עיבוד רצות תוך זמן קצר ביותר. האופציה השנייה, והמהירה ביותר, כוללת הפעלת יחידת עיבוד המריצה בסיס נתונים מעודכן, במקביל על גבי הענן של אמזון, כך שבעת הצורך אין כל שיהוי בהכנת בסיס הנתונים לפעולה.
האופציה הכוללת הרצה במקביל של יחידת בסיס נתונים, מוכרת מסביבות לא-ענניות ועל פניה אינה נראית כמו יתרון לסביבת הענן. אולם, גם בסיטואציה זו ניתן למצוא שלל אפשרויות לחסכון תוך שימוש בענן. לדוגמה, שירות Amazon RDS, המאפשר הרצת בסיסי נתונים מבוססי RDBMS, מאפשר לשנות בלחיצת כפתור ותוך דקות ספורות את גודל יחידת העיבוד ובלוק הזכרון המקושר לבסיס הנתונים. ניתן לתכנן מערכת התאוששות המורכבת מיחידת עיבוד מוקטנת, לספיגה ראשונית, ובעת אסון “לחמם” במקביל מערכת עיבוד גדולה יותר אשר תתפוס את מקומה בתוך דקות. באופן שכזה, ניתן לחסוך עלויות שרת בזמן שגרה, ולהקטין עלויות רשיון, על חשבון פגיעה קלה ולזמן קצר בעת ההתאוששות.
באופן דומה, במידה וניתן להפעיל את המערכת למשך זמן קצר תוך שימוש בחלק מהנתונים, ניתן לתכנן מערכת התאוששות המורכבת מ Block Storage מוקטן המכיל את הנתונים הדרושים ביותר ושאר המידע מגובה על שירות S3. בעת אסון “מחממים” במקביל יחידת זכרון מוגדלת וטוענים לתוכה את המידע השלם מתוך S3.
אלו רק שתי דוגמאות, מיני רבות, המציגות את עושר הפתרונות האפשריים תוך שימוש בכלי האחסון של הענן. כל הדרוש הוא הכרת המערכת ויצירתיות ארכיטקטונית.
אחסון הנתונים הוא רק חלק אחד במארג הפתרון הקשור לטיפול במידע בסביבת התאוששות. החלק השני, החשוב לא פחות, הוא העברת הנתונים לסביבת ההתאוששות ושמירתם מעודכנים.
בקצה הטריוויאלי ביותר, ניתן להעביר נתונים באמצעות חיבור אינטרנטי רגיל תוך שימוש בפרוטוקול REST על בסיס HTTP של שירות האחסון S3. פתרון זה מתאים למקרים הפשוטים יותר הדורשים מעבר מידע בכמות קטנה יחסית וקבוצות עדכון מידע קטנות.
ניתן להאיץ את קצב העברת הנתונים ע”י פתיחת ערוץ תקשורת ישיר לשירותי אמזון, Amazon Direct Connect, המאפשר הן האצת זמני העלאת הנתונים והן הקטנת עלויות. במידת הצורך, ניתן לשלב את השירותים הללו עם שירות הרשת המאובטחת, Amazon VPC, המאפשרת להגדיר מקטע בענן כחלק מהרשת הפרטית, כולל הקצאת הכתובות מתוך הרשת הפרטית של הארגון.
עבור צרכי נתונים גדולים במיוחד ניתן להשתמש בשירות המיוחד Amazon Import/Export המאפשר לשלוח אמצעי אחסון פיזיים לסניפי השירות של אמזון, אשר יעלו אותם חינם אין כסף לאחד או יותר משירותי האחסון של אמזון (S3, EBS או שירות הארכיב Amazon Glacier). בשימוש בשירות זה אין כל עלות להעברת נתונים או להעלאתם, למעט עלויות שירותי המשלוח לסניפי אמזון וחזרה.
המפתח לבחירה בשירות זה על גבי קישור ישיר הוא על-פי גודל הנתונים ומהירות החיבור הקיים. לדוגמה, עפ”י מפתח המופיע באתר השירות של Amazon Import/Export, במקרה של חיבור במהירות 100Mbps יש לשקול את השימוש בשירות מגודל מידע של 5TB ויותר.
במקביל לפתרונות שלעיל, אמזון מציעה שירות לגיבוי והעברת נתונים מתוך סביבת הארגון (on-premise) לסביבת הענן בשם Amazon Storage Gateway. השירות כולל התקנה של Virtual Machine במערכות הארגון המחבר בין המידע בארגון לבין שירות S3 של אמזון. המערכת מגבה את הנתונים באופן רציף ומאובטח על גבי הענן של אמזון ושומרת את הנתונים בצורה מוצפנת בתיקיות שהוגדרו לכך. ניתן להגדיר את פעולת המערכת כך שהמידע יועבר באופן רציף לענן וחלקו יישמר מקומי (Cache) או להגדירה כך שכל המידע נשמר מקומית, לצורך גישה מהירה, ואחת לתקופה נשמר גיבוי על גבי הענן.
כמו במקרה אחסון הנתונים, גם בנוגע למרכיב העברת הנתונים ניתן לשלב מספר שירותים במקביל בכדי להגיע לפתרון הדרוש ובכדי להבטיח את עדכון המידע באופן המיטבי.
לדוגמה, את פתיח המידע ניתן להעלות לענן באמצעות שליחת מדיה פיזית עם המידע המלא לשירות Amazon Import/Export. במקביל יוגדר VM לשירות Amazon Storage Gateway עם הגדרות לגיבוי אינקרמנטלי מהנקודה בה נשלח המידע המלא לענן.
עם טעינת המידע הראשוני לענן ע”י אמזון, צירוף המקטעים האינקרמנטלים של הגיבוי יהוו את המידע המלא הנכון לנקודת זמן מסויימת.
את מרכיב המידע הנדרש לזמינות גבוהה במקרה של אסון ניתן לעדכן באופן קבוע באמצעות תקשורת ישירה לשירותי האחסון של אמזון (Direct Connect מעל VPC).
במקרה שבו מערכת ההתאוששות נדרשת להכנס לפעולה באופן מיידי, ניתן לעדכן את בסיסי הנתונים בסביבת ההתאוששות בצמוד לעדכון המידע בסביבה החיה או אף לבצע כתיבה כפולה במקרה בו לא ניתן לסבול עיכוב כלשהו או איבוד מידע כלשהו בכניסת מערכת ההתאוששות לפעולה.
כוח המחשוב הדרוש להפעלת מערכת ההתאוששות דורש תכנון ותחזוקה בדומה לאחסון הנתונים והעברתם.
שרתי בסיס הנתונים, שרתי האינטרנט ושרתי תפעול אחרים הנדרשים לתפעול המערכת יכולים להמתין באופן רדום או, לחילופין, לפעול בשגרה בהמתנה למקרה הצורך.
מגוון האפשרויות לתכנון ותחזוקה של יחידות העיבוד על גבי הענן של אמזון הוא עצום ומאפשר להגיע די בקלות למיצוי עלות-תועלת.
אמזון מציעה שלוש דרכים מרכזיות לתכנון ותפעול יחידות עיבוד: הכנת תבניות מותקנות (Images), שימוש בכלי הגדרת תצורה ושימוש בשירותים מנוהלים.
עבור מערכות סטנדרטיות, כדוגמת בסיסי נתונים ושרתי אינטרנט, מומלץ לבחון את אחד מהשירותים המנוהלים של אמזון. שירות Amazon RDS הוא שירות בסיס נתונים המנוהל ומתופעל ע”י אמזון. השירות מאפשר את הפעלת בסיסי הנתונים המובילים בשוק (MySQL, Oracle, SQLServer) תוך דאגה להתקנת עדכוני תוכנה ואבטחה ותמיכה בגיבויים אוטומטיים. באמצעות השירות ניתן, בלחיצת כפתור, לשנות את יכולות העיבוד והאחסון של שרתי בסיס הנתונים ואף להוסיף Replication Servers לשרתי ה Master.
השירות מאפשר לבחור בין הכלת מחיר רשיון השימוש בבסיס הנתונים במחיר השימוש השעתי לבין שימוש ברשיון הלקוח הקיים.
עבור שרתי האינטרנט, מומלץ לבחון את שירות Amazon Elastic Beanstalk, המציע פלטפורמה לניהול מערך שרתי אינטרנט באופן אלסטי ללא צורך בהתקנה. תפעול השירות קל מאוד וכולל, בעיקר, את טעינת קוד האפליקציה המקומפל (למשל WAR בג’אווה) והגדרת חוקי האלסטיות של המערכת – כלומר, על פי איזו אינדיקציה יש להוסיף או להוריד שרתי אינטרנט. אמזון דואגת לעדכניות השרתים ולתפעול האלסטיות והוספת שרתים במקרה הצורך.
שירות זה הוא דוגמה טובה לכל היתרונות שבענן: מינימום תחזוקה, מינימום עלות עודפת וגמישות (Scalability) בעת הצורך.
במקביל לפתרונות שלעיל, אמזון מציעה שירות לגיבוי והעברת נתונים מתוך סביבת הארגון (on-premise) לסביבת הענן בשם Amazon Storage Gateway. השירות כולל התקנה של Virtual Machine במערכות הארגון המחבר בין המידע בארגון לבין שירות S3 של אמזון. המערכת מגבה את הנתונים באופן רציף ומאובטח על גבי הענן של אמזון ושומרת את הנתונים בצורה מוצפנת בתיקיות שהוגדרו לכך. ניתן להגדיר את פעולת המערכת כך שהמידע יועבר באופן רציף לענן וחלקו יישמר מקומי (Cache) או להגדירה כך שכל המידע נשמר מקומית, לצורך גישה מהירה, ואחת לתקופה נשמר גיבוי על גבי הענן.
במידה ונדרשת התקנה ייחודית ליחידת עיבוד ניתן לבחור בין הכנת תבנית (Amazon Machine Image – AMI) לבין ייבוא של תבנית קיימת לתוך שירות אמזון. במקרה של הכנת תבנית, יש להפעיל יחידת עיבוד Amazon EC2, להתקין עליה את ההתקנות השונות הנדרשות ולחתום אותה כתבנית באמצעות אתר הניהול של אמזון או כלי שורת הפקודה. בעת הצורך, ניתן להפעיל מספר יחידות עיבוד, ככל הנדרש, מתוך התבנית שהוכנה.
במקרה ותבנית שכזו קיימת במערכת או, בעדיפות, נוצרת כחלק מתהליך עדכון התוכנה של המערכת הראשית, ניתן להשתמש בשירות הייבוא של תבניות לתוך המערכת של אמזון כחלק מתהליך בנייה והתקנה של גרסה חדשה על גבי המערכת הראשית של הארגון.
בדומה לנושא עדכניות המידע, השמירה על עדכניות יחידות העיבוד קריטית ביותר. הסכנה בהפעלת מערכת גיבוי והתאוששות תוך שימוש במערכות עיבוד בעלות גרסאות שונות ממקבילותיהן בסביבת המערכת הראשית עשויה להוביל לאסון רב עוד יותר שעלול ליכלול פגיעה חמורה בשירות ובמקרים מסויימים אף פגיעה במידע והנתונים עצמם. המצב עשוי להיות מסוכן עד כדי כך, שבמקרים מסויימים עדיף שלא להשתמש במערכת התאוששות וגיבוי כלל מאשר להפעיל מערכת ישנה ולא מתוחזקת.
על כן, ברור כי תחזוקת מערכת התאוששות מחייבת נהלים ברורים ומסודרים לגבי עדכונה, במקביל למערכת הראשית. עדיף, כמובן, לעשות שימוש בכלים אוטומטיים לניהול התקנות ויצירת תבניות (Images) אשר כחלק מתהליך בנייתה והתקנתה של המערכת הראשית ייעדכנו גם את מערכת הגיבוי.
כלים כגון Puppet ומקבילו הענני-Chef מומלצים מאוד לצורך כך מאחר ומאפשרים הגדרה של התקנות הדרושות ליחידות העיבוד בשפת סקריפט ללא הצורך ביצירת תבניות מוכנות מראש. מוד העבודה המומלץ הוא, כמובן, לפעול הן בסביבה הראשית והן בסביבת ההתאוששות מתוך אותן תשתיות Puppet או Chef וכך להבטיח עדכניות וסנכרון מערכות. אמזון מאפשרת הפעלת סקריפטים של Chef ו Puppet מתוך שירות Amazon CloudFormation, עליו יורחב בהמשך.
מערכות התאוששות על הענן נבדלות זו מזו במידת מוכנותם לפעולה מלאה בשיגרה. ככל שהמערכת מוכנה וזמינה יותר לפעולה בכל עת, כך זמן ההמתנה קטן מרגע הכשל ועד כניסת מערכת ההתאוששות לפעולה. מן הצד השני, ככל שהמערכת מכילה בעת שגרה רכיבים רבים יותר בפעולה כך עולה מורכבות תחזוקת המערכת, וכמובן, עלויות הפעלתה בשגרה.
בקצה הפשוט של פתרונות ההתאוששות נמצאת מערכת “קרה”, המהווה גיבוי של המידע על גבי שירותי האחסון ללא כל יחידת עיבוד בפעולה. בעת הצורך מופעלות יחידות העיבוד הדרושות לפעולת המערכת והמידע נטען מתוך שירותי האחסון ליחידות העיבוד. זהו הפתרון הזול ביותר והפשוט ביותר לתפעול אך גם בעל משמעויות ניכרות בזמן התאוששות וככל הנראה גם בכמות המידע שתאבד.
בקצה המורכב ביותר של פתרונות ההתאוששות נמצאת מערכת מלאה ומתפקדת (full-scale) ולמעשה זהה לחלוטין למערכת הרגילה. היתרון הבולט ביותר של מערכת שכזו הוא בכך שבאפשרותה להכנס לפעולה כמעט ללא שיהוי. עם זאת, מערכת שכזו היא המורכבת ביותר לתחזוקה ולעדכון ובעלת המשמעויות הניכרות ביותר מבחינת עלות בעת שגרה.
על הסקאלה שבין שני הפתרונות שצויינו נמצאות אינסוף אפשרויות לתכנון מערכות התאוששות מוכנות למחצה אשר בעת הצורך מתעוררות לחיים מלאים. מערכת שכזו יכולה, למשל, להכיל את כל המרכיבים באופן מלא אך בצורה מוקטנת (scaled down) ולהתאים לסביבות שאינן יכולות להרשות לעצמן זמן השבתה (down-time) גבוה אך ניתן להפעילן לפרקי זמן קצרים בביצועים נמוכים יותר.
מנגד ניתן להקים מערכת המכילה את המרכיבים הקריטיים בקונפיגורציה מלאה כאשר שאר יחידות העיבוד רדומות ומופעלות בעת הצורך.
הפתרון היצירתי והמתאים ביותר סביר שיהיה קומבינציה של שתי האפשרויות שתוארו, כאשר יחידות העיבוד הקריטיות ובעלות פרק זמן הטעינה הארוך ביותר פועלות כל העת בקונפיגורציה מלאה. יחידות העיבוד הקריטיות פחות, או אלה שניתן להפעילן בביצועים נמוכים יותר, פועלות בצורה מוקטנת ושאר היחידות רדומות ומופעלות בזמן אמת. בעת אסון, היחידות הנדרשות מופעלות והיחידות המוקטנות מוגדלות ע”י הרחבתם הפיזית (vertical scale) או הוספת יחידות נוספות מאותו הסוג (horizontal scale).
ארכיטקטורת מערכת התאוששות, טובה ככל שתהיה, אינה שלמה ללא תוכנית פעולה לעת אסון ובדיקתה.
תוכנית הפעולה צריכה לכלול את כל הפעולות הנדרשות להבאת מערכת ההתאוששות לפעולה מלאה וכן את התנהלות המערכת מרגע האסון ועד חזרה לתפקוד המערכת הראשית.
תוכנית הפעולה תכלול את הפעלת יחידות העיבוד הנדרשות, “חימום” יחידות עיבוד מוגדלות במקביל ליחידות הגיבוי, טעינת הנתונים מאמצעי האחסון לתוך יחידות העיבוד, קביעת הגדרות היחידות השונות והפניית התעבורה לשירות אל שירות ההתאוששות. חשיבות רבה, כמובן, להפעלה מהירה ככל הניתן של מערכת ההתאוששות וכניסתה לפעולה, אך חשיבות רבה אף יותר להפעלת התוכנית על פי סדר הפעולות הנכון והנדרש בכדי להגיע למערכת נכונה ומתפקדת.
על כן מומלץ לעשות שימוש, ככל הניתן, בסקריפטים ומנהלי התקנות אותם ניתן לבדוק מראש ולהכניס לפעולה בלחיצת כפתור.
שימוש ב Amazon CloudFormation, ובעת הצורך שילוב כלי ה API וה Command Line Tools של אמזון, מאפשר ליצור תוכנית פעולה ממוכנת אשר בעת הצורך תפעיל את יחידות העיבוד מתוך התבניות המוכנות או הסקריפטים של Chef ו Puppet ותדאג להגדרות המתאימות.
בדיקת מערכת ההתאוששות היא שלב חשוב מאוד הדורש התייחסות ותכנון מיוחד ולרוב אינו טריוויאלי להשגה. האפשרות המועדפת היא הרצה במקביל של מערכת ההתאוששות והמערכת הראשית. ניתן להשיג זאת, לדוגמה, תוך שימוש ב Route 53 בתור Weighted DNS המפעיל את המערכת הראשית ומערכת ההתאוששות במקביל ומפנה בקשות לכל מערכת על פי משקל מוגדר מראש. במידה ומצב זה אפשרי מבחינת עלויות ועדכניות נתונים, ניתן לבחון בזמן אמת את מערכת ההתאוששות וכן להפסיק את פעילותה בקלות, לתקנה ולהחזירה לבדיקה עד לאישורה הסופי – וכל זאת ע”י שינוי הגדרות ה DNS.
במידה ולא ניתן להפעיל את מערכת ההתאוששות במקביל, יש לבדוק האם ניתן להריץ את מערכת ההתאוששות לפרק זמן מסוים באופן המחקה את פעילות המערכת הראשית ולוודא התנהגות דומה – למשל ע”י קריאת לוגים של המערכת הראשית והרצת קבצי הפקודות על הנתונים בסביבת ההתאוששות כפי שבוצעו במערכת הראשית.
בכל מקרה, יש לוודא בדיקות ידנית ובדיקות אוטומטיות של מערכת ההתאוששות בדומה לבדיקות המערכת הראשית וכחלק מתהליך האישור של עדכונים למערכת הראשית.
מחשבון העלויות של אמזון http://calculator.s3.amazonaws.com/calc5.html מאפשר קבלת מושג ראשוני לגבי עלויות פריסה של מערכות על גבי הענן של אמזון.
המחשבון טעון בצידו הימני בפריסטים מוכנים מראש לתסריטים שונים וביניהם קיימת האופציה “Disaster Recovery and Backup” איתה ניתן להתחיל בבניית עלויות הפריסה של מערכת ההתאוששות.
מערכת התאוששות טובה אינה בהכרח מערכת המחליפה את כל המערכת הראשית בעת אסון. במידת האפשר, מומלץ לתכנן מספר תת-מערכות התאוששות וגיבוי המאפשרות להחליף את פעילותן של מערכות קריטיות בכל עת עם מערכות מקבילות בענן. כך ניתן לתחזק מערכות גיבוי והתאוששות לבסיס הנתונים, לאמצעי האחסון, וליחידות העיבוד, לחברן למערכת הראשית באמצעות VPN ולהכניסן לפעילות בעת הצורך.
מערכת התאוששות אינה רלוונטית רק למערכות רגילות, on-premise, אלא גם למערכות ענן. מערכות הרצות על שירותי ענן פרטיים או ציבוריים אחרים יכולות להשתמש בשירותי הענן של אמזון לצרכי גיבוי והתאוששות ולהתכונן לכשל מערכתי שעשוי לנבוע מפעילות המערכת הראשית או אף מכשל של מערך הענן כולו.
מערכות המותקנות על הענן של אמזון צריכות להיות מתוכננות כך שיעשו שימוש בשירותי השרידות המובנים של אמזון, כגון שימוש ב- Availability Zones המהווים מרכזי מחשוב נפרדים באותו איזור חישובי. דרגת שרידות גבוהה יותר ניתן להשיג תוך שימוש באחד או יותר מתשעת ה-Regions האחרים של אמזון הפרוסים ברחבי העולם כגיבוי והתאוששות במקרה של פגיעה בביצועי ה-Region בו מותקנת המערכת הראשית.
לסיום, אמליץ לקרוא את המאמר Using Amazon Web Services for Disaster Recovery המהווה השראה למאמר זה ומתאר את תפיסת ההמשכיות העסקית והתאוששות מאסון של אמזון.