שלום, קוראי הבר! במאמר האחרון דיברנו על אמצעי פשוט להתאוששות מאסון במערכות אחסון AERODISK ENGINE - שכפול. במאמר זה נצלול לנושא מורכב ומעניין יותר – המטרוקלוסטר, כלומר אמצעי להגנה אוטומטית על אסונות לשני מרכזי נתונים, המאפשר למרכזי נתונים לפעול במצב אקטיבי-אקטיבי. אנחנו נגיד לך, נראה לך, נשבור את זה ונתקן את זה.
כרגיל, קודם כל תיאוריה
מטרוקלוסטר הוא אשכול הפרוס על פני מספר אתרים בתוך עיר או אזור. המילה "אשכול" רומזת לנו בבירור שהמתחם הוא אוטומטי, כלומר, החלפת צמתי אשכולות במקרה של כשלים מתרחשת באופן אוטומטי.
כאן טמון ההבדל העיקרי בין מטרוקלוסטר לשכפול רגיל. אוטומציה של פעולות. כלומר, במקרה של תקלות מסוימות (כשל ב-Data Center, ערוצים שבורים וכדומה), מערכת האחסון תבצע באופן עצמאי את הפעולות הנדרשות על מנת לשמור על זמינות הנתונים. בעת שימוש בעותקים רגילים, פעולות אלו מבוצעות באופן ידני באופן מלא או חלקי על ידי המנהל.
מה זה עושה?
המטרה העיקרית שלקוחות רודפים אחריה בעת שימוש ביישומי מטרוקלוסטר מסוימים היא למזער RTO (Recovery Time Objective). כלומר, למזער את זמן ההתאוששות של שירותי IT לאחר תקלה. אם אתה משתמש בשכפול רגיל, זמן ההתאוששות תמיד יהיה ארוך יותר מזמן ההתאוששות עם מטרוקלוסטר. למה? פשוט מאוד. המנהל חייב להיות ליד שולחנו ולעבור רפליקציה באופן ידני, והמטרוקלוסטר עושה זאת באופן אוטומטי.
אם אין לך מנהל תורן מסור שלא ישן, לא אוכל, לא מעשן או חולה וצופה במצב מערכת האחסון 24 שעות ביממה, אז אין דרך להבטיח שהמנהל יעשה זאת. להיות זמין להחלפה ידנית במהלך תקלה.
בהתאם לכך, RTO בהיעדר מטרוקלוסטר או מנהל אלמותי ברמה ה-99 של שירות התורן המנהל יהיה שווה לסכום זמן ההחלפה של כל המערכות ולפרק הזמן המקסימלי שאחריו מובטח למנהל העבודה להתחיל לעבוד עם מערכות אחסון ומערכות נלוות.
לפיכך, אנו מגיעים למסקנה המתבקשת שיש להשתמש במטרוקלוסטר אם הדרישה ל-RTO היא דקות, לא שעות או ימים. כלומר, כאשר במקרה של תקלה חמורה ביותר במרכז הנתונים, על מחלקת ה-IT לספק לעסק זמן. לשחזר גישה לשירותי IT תוך דקות, או אפילו שניות.
איך זה עובד?
ברמה התחתונה, המטרוקלסטר משתמש במנגנון לשכפול נתונים סינכרוני, אותו תיארנו במאמר הקודם (ראה. ). מכיוון שהשכפול הוא סינכרוני, הדרישות עבורו מתאימות, או ליתר דיוק:
- סיב אופטי כפיזיקה, 10 גיגה-ביט Ethernet (או יותר);
- המרחק בין מרכזי הנתונים אינו עולה על 40 קילומטרים;
- עיכוב ערוץ אופטי בין מרכזי נתונים (בין מערכות אחסון) הוא עד 5 מילישניות (אופטימלי 2).
כל הדרישות הללו הינן מייעצות במהותן, כלומר, המטרוקלסטר יפעל גם אם לא יעמדו בדרישות אלו, אך עלינו להבין כי ההשלכות של אי עמידה בדרישות אלו שוות להאטה בפעולת שתי מערכות האחסון ב. מטרוקלסטר.
אז, העתק סינכרוני משמש להעברת נתונים בין מערכות אחסון, ואיך העתקים עוברים אוטומטית, והכי חשוב, איך להימנע מפיצול מוח? לשם כך, ברמה גבוהה יותר, נעשה שימוש בגורם נוסף - בורר.
כיצד פועל בורר ומהי תפקידו?
הבורר הוא מכונה וירטואלית קטנה או אשכול חומרה שיש להפעיל באתר שלישי (למשל במשרד) ולספק גישה למערכת האחסון באמצעות ICMP ו-SSH. לאחר ההשקה, הבורר צריך להגדיר את ה-IP, ולאחר מכן מצד האחסון לציין את הכתובת שלו, בתוספת הכתובות של בקרים מרוחקים המשתתפים במטרוקלסטר. לאחר מכן, השופט מוכן לעבודה.
הבורר עוקב כל הזמן אחר כל מערכות האחסון במטרוקלסטר ואם מערכת אחסון מסוימת אינה זמינה, לאחר אישור חוסר הזמינות מחבר אחר באשכול (אחת ממערכות האחסון ה"חיות"), הוא מחליט להפעיל את הליך החלפת כללי שכפול. ומיפוי.
נקודה מאוד חשובה. על הבורר להתמקם תמיד באתר שונה מאלה בו ממוקמות מערכות האחסון, כלומר לא במרכז נתונים 1, בו מותקנת מערכת אחסון 1, ולא במרכז נתונים 2, בו מותקנת מערכת אחסון 2.
למה? כי רק כך יכול בורר, בעזרת אחת ממערכות האחסון ששרדו, לקבוע באופן חד משמעי ומדויק את נפילת כל אחד משני האתרים בהם מותקנות מערכות האחסון. כל שיטות אחרות להצבת בורר עלולה לגרום לפיצול מוח.
כעת נצלול לפרטי עבודתו של הבורר.
הבורר מפעיל מספר שירותים שמסקרים כל הזמן את כל בקרי האחסון. אם תוצאת הסקר שונה מהקודמת (זמינה/לא זמינה), אז היא נרשמת במסד נתונים קטן, שעובד גם על הבורר.
נתבונן ביתר פירוט בהיגיון עבודתו של הבורר.
שלב 1: קבע חוסר זמינות. אירוע כשל במערכת אחסון הוא היעדר פינג משני הבקרים של אותה מערכת אחסון בתוך 5 שניות.
שלב 2. התחל את הליך ההחלפה. לאחר שהבורר הבין שאחת ממערכות האחסון אינה זמינה, הוא שולח בקשה למערכת האחסון "חי" על מנת לוודא שמערכת האחסון "מתה" באמת מתה.
לאחר קבלת פקודה כזו מהבורר, מערכת האחסון השנייה (חיה) בודקת בנוסף את זמינות מערכת האחסון הראשונה שנפלה, ואם היא לא קיימת, שולחת אישור לפוסק על ניחושו. מערכת האחסון אכן לא זמינה.
לאחר קבלת אישור כזה, הפוסק מפעיל הליך מרחוק להחלפת שכפול והעלאת מיפוי על אותם העתקים שהיו פעילים (ראשוניים) במערכת האחסון שנפלה, ושולח פקודה למערכת האחסון השנייה לשנות את העתקים הללו משניים לראשי ו להעלות מיפוי. ובכן, מערכת האחסון השנייה, בהתאם, מבצעת את ההליכים הללו, ולאחר מכן מספקת גישה ל-LUNs האבודים מעצמה.
מדוע יש צורך באימות נוסף? למניין. כלומר, רוב מכלל המספר האי-זוגי (3) של חברי האשכול חייב לאשר את נפילת אחד מצמתי האשכול. רק אז החלטה זו תהיה נכונה בהחלט. זה הכרחי כדי למנוע החלפה שגויה ובהתאם, מפוצל מוח.
שלב זמן 2 לוקח בערך 5 - 10 שניות, לפיכך, בהתחשב בזמן הדרוש לקביעת חוסר זמינות (5 שניות), תוך 10 - 15 שניות לאחר התאונה, LUNs ממערכת האחסון שנפלו יהיו זמינים אוטומטית לעבודה עם ה-live מערכת אחסון.
ברור שכדי למנוע אובדן קשרים עם מארחים, צריך גם לדאוג להגדיר נכון פסקי זמן על המארחים. הזמן הקצוב המומלץ הוא לפחות 30 שניות. זה ימנע מהמארח לנתק את החיבור למערכת האחסון במהלך מיתוג עומס במקרה של אסון ויכול להבטיח שאין הפרעות קלט/פלט.
רגע, מסתבר שאם הכל כל כך טוב עם המטרוקלוסטר, למה צריך שכפול קבוע בכלל?
במציאות, הכל לא כל כך פשוט.
בואו נבחן את היתרונות והחסרונות של המטרוקלסטר
אז הבנו שהיתרונות הברורים של המטרוקלוסטר בהשוואה לשכפול קונבנציונלי הם:
- אוטומציה מלאה, המבטיחה זמן התאוששות מינימלי במקרה של אסון;
- זה הכל :-).
ועכשיו, תשומת לב, החסרונות:
- עלות פתרון. למרות שה- Metrocluster במערכות Aerodisk אינו דורש רישוי נוסף (משתמשים באותו רישיון כמו עבור העתק), אך עלות הפתרון עדיין תהיה גבוהה אף יותר מאשר שימוש בשכפול סינכרוני. יהיה עליך ליישם את כל הדרישות עבור העתק סינכרוני, בתוספת הדרישות למטרוקלסטר הקשורות למעבר נוסף ולאתר נוסף (ראה תכנון מטרוקלסטר);
- מורכבות הפתרון. המטרוקלוסטר מורכב הרבה יותר מהעתק רגיל, ודורש הרבה יותר תשומת לב ומאמץ לתכנון, תצורה ותיעוד.
בסופו של דבר. Metrocluster הוא בהחלט פתרון מאוד מתקדם וטוב מבחינה טכנולוגית כאשר אתה באמת צריך לספק RTO בשניות או דקות. אבל אם אין משימה כזו, ו-RTO בשעות זה בסדר לעסקים, אז אין טעם לירות דרורים מתותח. השכפול הרגיל של עובד-איכר מספיק, שכן אשכול מטרו יגרום לעלויות נוספות ולסיבוך של תשתית ה-IT.
תכנון מטרוקלוסטר
סעיף זה אינו מתיימר להיות מדריך מקיף לתכנון מטרו-אשכולות, אלא רק מציג את הכיוונים העיקריים שיש לעבד אם תחליט לבנות מערכת כזו. לכן, כאשר ממשיכים להטמיע מטרוקלוסטר, הקפידו לערב את יצרן מערכת האחסון (כלומר אותנו) ומערכות קשורות אחרות להתייעצות.
פלטפורמות
כאמור לעיל, מטרוקלסטר דורש לפחות שלושה אתרים. שני מרכזי נתונים שבהם יפעלו מערכות אחסון ומערכות נלוות, וכן אתר שלישי בו יעבוד הבורר.
המרחק המומלץ בין מרכזי נתונים הוא לא יותר מ-40 קילומטרים. מרחק גדול יותר עלול לגרום לעיכובים נוספים, שבמקרה של מטרוקלסטר הם מאוד לא רצויים. נזכיר לכם שהעיכובים צריכים להיות עד 5 אלפיות שניות, אם כי מומלץ לשמור אותם בתוך 2.
מומלץ לבדוק עיכובים גם בתהליך התכנון. כל ספק בוגר יותר או פחות שמספק סיבים אופטיים בין מרכזי נתונים יכול לארגן בדיקת איכות די מהר.
לגבי עיכובים בפני הבורר (כלומר, בין האתר השלישי לשני הראשונים), סף ההשהיה המומלץ הוא עד 200 אלפיות שניות, כלומר, מתאים חיבור VPN תאגידי רגיל דרך האינטרנט.
מיתוג ורשת
שלא כמו סכימת השכפול, שבה מספיק לחבר מערכות אחסון מאתרים שונים, סכימת metrocluster דורשת חיבור מארח עם שתי מערכות האחסון באתרים שונים. כדי להבהיר יותר מה ההבדל, שתי הסכמות מוצגות להלן.
כפי שניתן לראות מהתרשים, מארחי אתר 1 שלנו מסתכלים גם על מערכת אחסון 1 וגם על מערכת אחסון 2. כמו כן, להיפך, מארחי אתר 2 מסתכלים גם על מערכת אחסון 2 וגם על מערכת אחסון 1. כלומר, כל מארח רואה את שתי מערכות האחסון. זהו תנאי מוקדם להפעלת המטרוקלסטר.
כמובן, אין צורך לחבר כל מארח עם כבל אופטי למרכז נתונים אחר; שום יציאות או כבלים לא יספיקו. כל החיבורים הללו חייבים להתבצע באמצעות מתגי Ethernet 10G+ או FibreChannel 8G+ (FC מיועד רק לחיבור מארחים ומערכות אחסון עבור IO, ערוץ השכפול זמין כעת רק באמצעות IP (Ethernet 10G+).
עכשיו כמה מילים על טופולוגיית הרשת. נקודה חשובה היא התצורה הנכונה של רשתות משנה. יש צורך להגדיר מיד מספר רשתות משנה עבור סוגי התעבורה הבאים:
- רשת המשנה לשכפול שעליה הנתונים יסונכרנו בין מערכות האחסון. יכול להיות שיש כמה מהם, במקרה הזה זה לא משנה, הכל תלוי בטופולוגיית הרשת הנוכחית (כבר מיושמת). אם יש שניים מהם, אז ברור שיש להגדיר ניתוב ביניהם;
- רשתות משנה של אחסון שדרכן המארחים יגשו למשאבי אחסון (אם זה iSCSI). צריכה להיות תת-רשת אחת כזו בכל מרכז נתונים;
- שליטה בתתי רשתות, כלומר שלוש רשתות משנה הניתנות לניתוב בשלושה אתרים מהם מנוהלות מערכות אחסון, ושם נמצא גם הבורר.
אנחנו לא מתייחסים לרשתות משנה לגישה למשאבי מארח כאן, מכיוון שהן תלויות מאוד במשימות.
הפרדת תעבורה שונה לרשתות משנה שונות היא חשובה ביותר (חשוב במיוחד להפריד את העתק מה-I/O), כי אם תערבבו את כל התעבורה לרשת משנה "עבה", אזי התעבורה הזו תהיה בלתי אפשרית לניהול, וב בתנאים של שני מרכזי נתונים זה עדיין יכול לגרום לאפשרויות שונות של התנגשות רשת. לא נעמיק בנושא זה במסגרת מאמר זה, שכן ניתן לקרוא על תכנון רשת הנמתחת בין מרכזי נתונים על משאבי יצרני ציוד הרשת, שם זה מתואר בפירוט רב.
תצורת בורר
על הבורר לספק גישה לכל ממשקי הניהול של מערכת האחסון באמצעות פרוטוקולי ICMP ו-SSH. כדאי גם לחשוב על בטיחות הכשל של הבורר. יש כאן ניואנס.
מעבר לכשל בבורר רצוי מאוד, אך אינו חובה. מה קורה אם השופט מתרסק בזמן הלא נכון?
- פעולת המטרוקלסטר במצב רגיל לא תשתנה, כי ל-arbtir אין שום השפעה על פעולת המטרוקלסטר במצב רגיל (המשימה שלו היא להחליף את העומס בין מרכזי הנתונים בזמן)
- יתרה מכך, אם הבורר מסיבה זו או אחרת נופל ו"ישן" דרך תאונה במרכז הנתונים, אז לא יקרה מעבר, כי לא יהיה מי שייתן את פקודות המיתוג הדרושות ויארגן מניין. במקרה זה, המטרוקלוסטר יהפוך לתכנית רגילה עם שכפול, אשר תצטרך לעבור ידנית במהלך אסון, אשר ישפיע על ה-RTO.
מה נובע מכך? אם אתה באמת צריך להבטיח מינימום RTO, אתה צריך לוודא שהבורר עמיד בפני תקלות. ישנן שתי אפשרויות לכך:
- הפעל מכונה וירטואלית עם בורר ב-hypervisor סובלני לתקלות, למרבה המזל כל ההיפרוויזורים המבוגרים תומכים בסובלנות תקלות;
- אם באתר השלישי (במשרד קונבנציונלי) אתה עצלן מכדי להתקין אשכול רגיל ואין אשכול hypervozor קיים, אז סיפקנו גרסת חומרה של הבורר, המיוצרת בקופסת 2U שבה שניים רגילים שרתי x-86 עובדים ואשר יכולים לשרוד כשל מקומי.
אנו ממליצים בחום להבטיח את סבילות התקלות של הבורר, למרות העובדה שה- Metrocluster אינו זקוק לו במצב רגיל. אבל כפי שמראים גם התיאוריה וגם הפרקטיקה, אם אתה בונה תשתית אמינה באמת חסינת אסונות, אז עדיף לשחק בזה בטוח. עדיף להגן על עצמך ועל העסק שלך מפני "חוק הרשעות", כלומר מפני כשל של הבורר וגם של אחד האתרים שבהם נמצאת מערכת האחסון.
ארכיטקטורת פתרונות
בהתחשב בדרישות לעיל, אנו מקבלים את ארכיטקטורת הפתרון הכללית הבאה.
LUNs צריכים להיות מופצים באופן שווה על פני שני אתרים כדי למנוע עומס יתר חמור. יחד עם זאת, בעת שינוי גודל בשני מרכזי הנתונים, עליך לכלול לא רק נפח כפול (שדרוש לאחסון נתונים בו-זמנית בשתי מערכות אחסון), אלא גם ביצועים כפולים ב-IOPS ו-MB/s על מנת למנוע פגיעה באפליקציה אירוע של כשל באחד ממרכזי הנתונים ov.
בנפרד, נציין כי עם הגישה הנכונה לגודל (כלומר, בתנאי שסיפקנו את הגבולות העליונים הנכונים של IOPS ו-MB/s, כמו גם את משאבי המעבד וה-RAM הדרושים), אם אחת ממערכות האחסון ב- אשכול מטרו נכשל, לא תהיה ירידה רצינית בביצועים בתנאים עבודה זמנית על מערכת אחסון אחת.
זה מוסבר על ידי העובדה שכאשר שני אתרים פועלים בו זמנית, שכפול סינכרוני "אוכל" מחצית מביצועי הכתיבה, שכן כל עסקה חייבת להיכתב לשתי מערכות אחסון (בדומה ל-RAID-1/10). לכן, אם אחת ממערכות האחסון נכשלת, השפעת השכפול באופן זמני (עד שמערכת האחסון הכושלת תתאושש) נעלמת, ואנו מקבלים עלייה פי שניים בביצועי הכתיבה. לאחר הפעלה מחדש של ה-LUN של מערכת האחסון הכושלת במערכת האחסון העובדת, העלייה הכפולה הזו נעלמת עקב העובדה שעומס מופיע מה-LUN של מערכת האחסון האחרת, ואנו חוזרים לאותה רמת ביצועים שהייתה לנו לפני "נפילה", אבל רק במסגרת אתר אחד.
בעזרת גודל מוכשר, אתה יכול להבטיח תנאים שבהם המשתמשים לא ירגישו בכלל כשל של מערכת אחסון שלמה. אבל אנחנו חוזרים שוב, זה מצריך גודל זהיר מאוד, שעבורו, אגב, אתה יכול לפנות אלינו בחינם :-).
הקמת מטרוקלסטר
הגדרת מטרוקלוסטר דומה מאוד להגדרת שכפול רגיל, שתיארנו ב . לכן, בואו נתמקד רק בהבדלים. הקמנו ספסל במעבדה על בסיס הארכיטקטורה שלמעלה, רק בגרסה מינימלית: שתי מערכות אחסון המחוברות באמצעות 10G Ethernet, שני מתגי 10G ומארח אחד שמסתכל דרך המתגים בשתי מערכות האחסון עם יציאות 10G. הבורר פועל על מכונה וירטואלית.
בעת הגדרת כתובות IP וירטואליות (VIP) עבור עותק, עליך לבחור את סוג ה-VIP - עבור metrocluster.
יצרנו שני קישורי שכפול עבור שני LUNs והפצנו אותם על פני שתי מערכות אחסון: LUN TEST Primary על מערכת אחסון 1 (קישור METRO), LUN TEST2 Primary עבור מערכת אחסון 2 (קישור METRO2).
עבורם, הגדרנו שני יעדים זהים (במקרה שלנו iSCSI, אבל גם FC נתמך, הלוגיקה של ההגדרה זהה).
מערכת אחסון 1:
מערכת אחסון 2:
עבור חיבורי שכפול, בוצעו מיפויים בכל מערכת אחסון.
מערכת אחסון 1:
מערכת אחסון 2:
הגדרנו multipath והצגנו אותו למארח.
הקמת בורר
אתה לא צריך לעשות שום דבר מיוחד עם הבורר עצמו; אתה רק צריך להפעיל אותו באתר השלישי, לתת לו IP ולהגדיר גישה אליו באמצעות ICMP ו-SSH. ההגדרה עצמה מתבצעת ממערכות האחסון עצמן. במקרה זה, מספיק להגדיר את הבורר פעם אחת בכל אחד מבקרי האחסון במטרוקלסטר; הגדרות אלה יופצו לכל הבקרים באופן אוטומטי.
בסעיף שכפול מרחוק>> Metrocluster (בכל בקר)>> כפתור "הגדר".
אנו מכניסים את ה-IP של הבורר, כמו גם את ממשקי הבקרה של שני בקרי אחסון מרוחקים.
לאחר מכן, עליך להפעיל את כל השירותים (לחצן "הפעל מחדש הכל"). אם יוגדר מחדש בעתיד, יש להפעיל מחדש את השירותים כדי שההגדרות ייכנסו לתוקף.
אנו בודקים שכל השירותים פועלים.
זה משלים את הגדרת המטרוקלסטר.
מבחן התרסקות
מבחן הריסוק במקרה שלנו יהיה די פשוט ומהיר, שכן פונקציונליות השכפול (החלפה, עקביות וכו') נדונה ב . לכן, כדי לבדוק את מהימנות המטרוקלסטר, די לנו לבדוק את האוטומציה של זיהוי כשלים, מיתוג והיעדר הפסדי הקלטה (עצירות I/O).
לשם כך, אנו מחקים כשל מוחלט של אחת ממערכות האחסון על ידי כיבוי פיזי של שני הבקרים שלה, לאחר שתחילה התחלנו להעתיק קובץ גדול ל-LUN, אותו יש להפעיל במערכת האחסון השנייה.
השבת מערכת אחסון אחת. במערכת האחסון השנייה אנו רואים התראות והודעות ביומנים על כך שהחיבור עם המערכת השכנה אבד. אם מוגדרות הודעות באמצעות ניטור SMTP או SNMP, המנהלן יקבל הודעות מתאימות.
בדיוק 10 שניות לאחר מכן (נראה בשתי צילומי המסך), חיבור השכפול של METRO (זה שהיה Primary במערכת האחסון הכושלת) הפך אוטומטית ל- Primary במערכת האחסון העובדת. באמצעות המיפוי הקיים, LUN TEST נשאר זמין למארח, ההקלטה ירדה מעט (בתוך 10 האחוזים המובטחים), אך לא נקטעה.
המבחן הסתיים בהצלחה.
לסיכום
ההטמעה הנוכחית של המטרוקלוסטר במערכות האחסון מסדרת AERODISK Engine N מאפשרת פתרון מלא של בעיות שבהן יש צורך לבטל או למזער את זמני השבתה עבור שירותי IT ולהבטיח את פעולתם 24/7/365 עם עלויות עבודה מינימליות.
אפשר לומר, כמובן, שכל זה הוא תיאוריה, תנאי מעבדה אידיאליים וכן הלאה... אבל יש לנו מספר פרויקטים מיושמים שבהם יישמנו פונקציונליות של חוסן אסון, והמערכות עובדות בצורה מושלמת. אחד הלקוחות המוכרים למדי שלנו, המשתמש רק בשתי מערכות אחסון בתצורה חסינת אסונות, כבר הסכים לפרסם מידע על הפרויקט, אז בחלק הבא נדבר על היישום הקרבי.
תודה, אנו מצפים לדיון פורה.
מקור: www.habr.com