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

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

אבל רגע…

קלסטרים עובדים עם משאב משותף שזהו מערך האחסון המרכזי. מה יהיה אם יקרה משהו למערך האחסון המרכזי שכשמו כן הוא – מרכזי. לב לבה של מערך המחשוב בארגון? אז נכון שהיום רוב מערכי האחסון הם (כמעט) ללא נקודת כשל פנימית אחת. שני קונטרולרים, מערך דיסקים ב Raid עם Hot Spare וכן הלאה. ומה קורה אם כל מערך האחסון נהיה תקול כגון כשל במספר דיסקים במקביל, כשל באספקת החשמל (לשני ספקי המתח). מה שקורה במצב שכזה הוא שאנחנו בסמטוכה רצינית ורצוי שנתקשר לאשה להודיע שהלילה לא נגיע הביתה וגם תירוץ טוב למנכ”ל החברה לא יזיק. במקרה הטוב יש לנו סביבת DR או כול פתרון אחר שאפשר להרים, אבל אנחנו ממילא כבר נכנסנו להשבתה כללית.

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

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

אבל מה זה קלסטר ברמת האחסון? מה זה Storage Network Raid ?Storage Network Raid הוא קלסטר של האחסון לכל דבר ועניין. לפחות שתי יחידות אחסון זהות שהמידע משוכפל ביניהן ועם מנגנון FailOver ואפילו Quorum. קלסטר שיכול להתפרס באותו חדר מחשב בין כמה ארונות, בין בניינים וכו’. ישנן תוכנות מצויינות בשוק עבור ביצוע קלסטר של מערכות אחסון. וישנה אפשרות לבצע זאת בעזרת מערך האחסון בלבד. היום בחרתי להתמקד במערכת Hp StoreVirtual, אשר בנויה על מנגנון Hp LeftHand.

HP StoreVirtual זה SAN Storage בתצורה של Scale Out. בכל צירוף של יחידת אחסון אני מוסיף כוח מעבד, רוחב פס של iscsi ומגדיל את ה cache. לא משרשר מגירות דיסקים לאותו מעבד. כל הרישויים האפשריים כלולים בפנים (nice…)

העיקרון הוא מאוד פשוט. שתי יחידות אחסון זהות (או יותר) אשר מחוברות לשרתים. המידע שנרשם ביחידה אחת, ירשם גם בשניה. ה Acknowledge לשרת הרושם יגיע מהיחידה האחרונה שהמידע נרשם בה. ישמו לב, לא מדובר ברפליקציה של הLUN אלא ה Block עצמו. התקשורת בין שתי יחידות האחסון ובין השרתים לאחסון מבוצע ע”ג iSCSI. ומחייב קו מקסימום 2ms latency. התוצאה שמתקבלת היא אפשרות לכשל של עד 50% מיחידות האחסון והמערכות ימשיכו לתפקד כרגיל. בפועל מאחורי הקלעים, במקרה של כשל, ה Path עובר מיחידת האחסון הכושלת אל יחידת האחסון השניה המתפקדת (אפשר לדמות את זה כפי שקורה ב mpio במקרה של נתק בכרטיס הרשת). מי שאחראי לניהול התקין זה מנגנון ה Fail Over Manager.

מבט על ה LUN והמידע הנרשם המועתק בין ארבעה יחידות אחסון ב Network Raid 10:

ש

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

מבט על Multi Site Cluster של ארבעה יחידות אחסון וכיצד מיוצגים בו השרתים, יחידות האחסון וכיצד המידע מתחלק:

ד

בתצורה הנ”ל, אפילו אם יפול ארון שלם עם כל השרתים ויחידות האחסון, עדיין המערכות יוכלו לתפקד רגיל – גם מתחנו את הקלסטר של השרתים בין הארונות. כמובן שבמידה ומותחים את הקלסטר הוירטואלי יש לייצג בשתי המקומות את כל התקשורת כגון lan, vmotion והשרתים יבצעו FailOver ללא קשר ליחידות האחסון.
ישנן אפשרויות לשחק עם הגדרות השרתים ולשייך אותם לוגית לאותו ה site שהם ממוקמים בו – Multi Site. במצב כזה יהיה גורם שלישי – Fail Over Manager, בנוסף לתפקודו כquorum, הוא יהיה אחראי לדאוג שכל שרת מדבר עם יחידת האחסון שנמצאת באותו ה site שלו. במידה ותהיה נפילה, הוא יבצע ניתוב של תקשורת iscsi למערכות האחסון באתר השני. אפשר תצורת single site בה השרתים לא ישויכו לאתר ספציפי ויהיה כמעיין ענן iscsi. בתצורה זו נגדיר חלק מיחידת האחסון כמנהלי failover – אם תרצו ממש כמו Node Majority במיקרוסופט

חשוב מאוד להדגיש, היכולת של StoreVirtual Network Raid מבדלת את עצמה מפתרונות אחרים בכך שהFailOver שקוף לחלוטין וזה מאפשר נפילה של יחידה או שתים באותו אתר ולא יהיה צורך לעבוד על האתר המרוחק (תלוי כמובן בסך מספר היחידות), כפי שקיים במערכות של שרשור מגירות דיסקים לבקר. זוכרים? Scale Out!
למערכת הזו קיים פתרון יפה מאוד עבור DR בעלות נמוכה ושימור השקעה במערכות אחסון הישנות שברשותנו. בעזרת StoreVirtual VSA כפי שמוסבר *כאן* נבצע רפליקציה של ה Snapshot לאתר שלישי. חשוב להבין שיש עלות של כפילות יחידות האחסון ומצריך אותה קונפיגורציה של דיסקים בין כל יחידות האחסון. איך אפשר להביא את הפתרון הזה לשוק הקטן או למי שאין תקציב למספר רב של יחידות אחסון? HP הוציאה פתרון של סטוראג’ מבוסס תוכנה (StoreVirtual VSA) המאפשר לבנות מערכת אחסון SAN על שרת עם דיסקים פנימיים. הסבר מלא נמצא *כאן* .