ענן עמיד בפני אסון: איך זה עובד

היי הבר!

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

מערכת אחסון ענן עמידה בפני אסונות באתר OST.

מה בפנים

מתחת למכסה המנוע, יש לאשכול שרתי Cisco UCS עם היפרוויזר VMware ESXi, שתי מערכות אחסון INFINIDAT InfiniBox F2240, ציוד רשת של Cisco Nexus, כמו גם מתגי Brocade SAN. האשכול מחולק לשני אתרים - OST ו-NORD, כלומר לכל מרכז נתונים יש סט ציוד זהה. למעשה, זה מה שהופך אותו לעמיד בפני אסונות.

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

כמה מילים על מערכות אחסון. בנינו את הגרסה הראשונה של ענן חסין אסונות ב-NetApp. כאן בחרנו ב-INFINIDAT, והנה הסיבה:

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

הנה כמה תמונות מהפריקה:

איך זה עובד?

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

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

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

כך נראה דיאגרמת החיבור באשכול.

הדבר אפשרי בשל העובדה ש-Inter-Switch Link מוגדר בין בדים SAN של שני האתרים: מתג Fabric A OST SAN מחובר למתג Fabric A NORD SAN, ובדומה למתגי Fabric B SAN.

ובכן, כדי שכל המורכבויות הללו של מפעלי SAN יהיו הגיוניות, שכפול Active-Active מוגדר בין שתי מערכות האחסון: מידע נכתב כמעט בו-זמנית למערכות האחסון המקומיות והמרוחקות, RPO = 0. מסתבר שהנתונים המקוריים מאוחסנים במערכת אחסון אחת, והעתק שלו מאוחסן בשני. נתונים משוכפלים ברמת נפחי האחסון, ונתוני ה-VM (הדיסקים שלו, קובץ התצורה, קובץ ההחלפה וכו') מאוחסנים בהם.

המארח של ESXi רואה את אמצעי האחסון הראשי ואת העתק שלו כהתקן דיסק אחד (התקן אחסון). ישנם 24 נתיבים מהמארח של ESXi לכל התקן דיסק:

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

תכנית של אשכול חסין אסונות.

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

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

מה קורה למכונה הוירטואלית של הלקוח אם...

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

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

מכונות וירטואליות פועלות כרגיל.

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

המכונות הוירטואליות ממשיכות לפעול כרגיל.

כל מתגי ה-SAN באחד מהאתרים נכשלים. נניח שאסון כזה קרה באתר OST. במקרה זה, מארחי ESXi באתר זה יאבדו את כל הנתיבים להתקני הדיסק שלהם. מנגנון VMware vSphere HA הסטנדרטי נכנס לפעולה: הוא יפעיל מחדש את כל המכונות הוירטואליות של אתר OST ב-NORD תוך 140 שניות לכל היותר.

מכונות וירטואליות הפועלות על מארחי אתר NORD פועלות כרגיל.

מארח ESXi נכשל באתר אחד. כאן מנגנון vSphere HA עובד שוב: מכונות וירטואליות מהמארח הכושל מופעלות מחדש במארחים אחרים - באותו אתר או מרוחק. זמן ההפעלה מחדש של המחשב הווירטואלי הוא עד דקה אחת.

אם כל המארחים של ESXi באתר OST נכשלים, אין אפשרויות: ה-VMs מופעלים מחדש על אחד אחר. זמן ההפעלה מחדש זהה.

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

מכונות וירטואליות עבדו כרגיל כל הזמן הזה.

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

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

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

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

מקורות:

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

מקור: www.habr.com