מנוע AERODISK: עמידות בפני אסון. חלק 1

שלום, קוראי הבר! הנושא של מאמר זה יהיה הטמעת כלי התאוששות מאסון במערכות אחסון AERODISK Engine. בתחילה, רצינו לכתוב במאמר אחד על שני הכלים: רפליקציה ומטרוקלוסטר, אך, למרבה הצער, התברר שהמאמר ארוך מדי, אז חילקנו את המאמר לשני חלקים. בואו נעבור מפשוט למורכב. במאמר זה נגדיר ונבדוק שכפול סינכרוני - נפיל דאטה סנטר אחד, וגם נשבור את ערוץ התקשורת בין הדאטה סנטרים ונראה מה קורה.

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

קצת תיאוריה

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

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

היתרונות של שיטה זו:

• הנתונים תמיד זהים בכל מערכות האחסון

חסרונות:

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

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

יתרונות של שכפול אסינכרוני:

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

חסרונות:

• הנתונים במרכזי נתונים שונים אינם תמיד זהים

לפיכך, בחירת מצב השכפול תלויה ביעדים העסקיים. אם זה קריטי עבורך שמרכז הנתונים לגיבוי מכיל בדיוק את אותם נתונים כמו מרכז הנתונים הראשי (כלומר, דרישה עסקית ל-RPO = 0), אז תצטרך להוציא את המזומן ולהשלים עם המגבלות של סינכרוני הֶעתֵק מְדוּיָק. ואם העיכוב במצב הנתונים מקובל או שפשוט אין כסף, אז אתה בהחלט צריך להשתמש בשיטה האסינכרונית.

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

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

אין כאן תשובה ברורה, אז הנה הטיעונים בעד ונגד:

טיעונים לשכפול אחסון:

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

טיעונים נגד שכפול אחסון:

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

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

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

סיימתי עם התיאוריה, עכשיו תרגול

אנו נגדיר את התצורה של העתק במעבדה שלנו. בתנאי מעבדה, חיקוי שני מרכזי נתונים (למעשה, שני מתלים סמוכים שנראו בבניינים שונים). המעמד מורכב משתי מערכות אחסון Engine N2, המחוברות זו לזו באמצעות כבלים אופטיים. שרת פיזי המריץ את Windows Server 2016 מחובר לשתי מערכות האחסון באמצעות 10Gb Ethernet. המעמד די פשוט, אבל זה לא משנה את המהות.

סכמטית זה נראה כך:

באופן הגיוני, שכפול מאורגן באופן הבא:

עכשיו בואו נסתכל על פונקציונליות השכפול שיש לנו כעת.
שני מצבים נתמכים: אסינכרוני וסינכרוני. זה הגיוני שהמצב הסינכרוני מוגבל על ידי מרחק וערוץ תקשורת. בפרט, מצב סינכרוני דורש שימוש בסיבים כמו פיזיקה ו-10 Gigabit Ethernet (או יותר).

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

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

נכון לעכשיו, מערכת האחסון AERODISK ENGINE תומכת בשכפול עבור התקני בלוק (LUNs) באמצעות פרוטוקול Ethernet (על נחושת או אופטי). עבור פרויקטים בהם נדרשת שכפול דרך מארג SAN על גבי Fibre Channel, אנו מוסיפים כרגע פתרון מתאים, אך הוא עדיין לא מוכן, אז במקרה שלנו, רק Ethernet.

שכפול יכול לעבוד בין כל מערכות אחסון מסדרת ENGINE (N1, N2, N4) ממערכות זוטרות ועד ישנות יותר ולהיפך.

הפונקציונליות של שני מצבי השכפול זהה לחלוטין. להלן פרטים נוספים על מה שזמין:

• שכפול "אחד לאחד" או "אחד לאחד", כלומר, הגרסה הקלאסית עם שני מרכזי נתונים, הראשי והגיבוי
• שכפול הוא "אחד לרבים" או "אחד לרבים", כלומר. ניתן לשכפל LUN אחד למספר מערכות אחסון בו-זמנית
• הפעל, השבת ו"הפוך" שכפול, בהתאמה, כדי להפעיל, להשבית או לשנות את כיוון השכפול
• שכפול זמין עבור בריכות RDG (Raid Distributed Group) ו-DDP (Dynamic Disk Pool). עם זאת, ניתן לשכפל LUNs של מאגר RDG רק ל-RDG אחר. אותו דבר עם DDP.

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

הגדרת שכפול

תהליך ההתקנה די פשוט ומורכב משלושה שלבים.

1. הגדרת רשת
2. הגדרת אחסון
3. הגדרת כללים (חיבורים) ומיפוי

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

הגדרת משאבי רשת

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

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

תהליך יצירת VIP עבור העתק אינו שונה בהרבה מיצירת VIP עבור I/O (NFS, SMB, iSCSI). במקרה זה, אנו יוצרים VIP רגיל (ללא VLAN), אך הקפידו לציין שהוא מיועד לשכפול (ללא מצביע זה לא נוכל להוסיף VIP לכלל בשלב הבא).

ה-VIP חייב להיות באותה רשת משנה של יציאות ה-IP שביניהן הוא צף.

אנו חוזרים על ההגדרות הללו במערכת אחסון מרחוק, עם IP שונה, כמובן.
VIP ממערכות אחסון שונות יכולים להיות בתתי רשתות שונות, העיקר שיש ניתוב ביניהם. במקרה שלנו, דוגמה זו מוצגת בדיוק (192.168.3.XX ו-192.168.2.XX)

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

הגדרת אחסון

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

במאגר R02 שנוצר בעבר, עליך ליצור LUN. בואו ניצור אותו ונקרא לו LUN1.

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

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

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

הגדרת כללי שכפול או קישורי שכפול

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

ההגדרה מתבצעת בתפריט "שכפול מרחוק".

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

בשדה "מערכות מרוחקות" אנו מוסיפים את מערכת האחסון שלנו2. כדי להוסיף, עליך להשתמש במערכות אחסון IP לניהול (MGR) ובשם ה-LUN המרוחק שלתוכו נבצע שכפול (במקרה שלנו, LUN1R). יש צורך בכתובות IP של בקרה רק בשלב הוספת חיבור; תעבורת שכפול לא תועבר דרכם; ה-VIP שהוגדר קודם לכן ישמש לשם כך.

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

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

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

מערכת אחסון 1. מיד לאחר היצירה החל הסנכרון.

מערכת אחסון 2. אנו רואים את אותו כלל, אבל הסנכרון כבר הסתיים.

LUN1 במערכת אחסון 1 נמצא בתפקיד ראשי, כלומר, הוא פעיל. LUN1R במערכת אחסון 2 היא בתפקיד של Secondary, כלומר, היא במצב המתנה למקרה שמערכת אחסון 1 נכשלת.
כעת אנו יכולים לחבר את ה-LUN שלנו למארח.

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

ההבדל היחיד הוא שאנו יוצרים מיפוי בתפריט "מיפוי שכפול".

הגדרנו מיפוי ונתנו את ה-LUN למארח. המארח ראה את ה-LUN.

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

זהו, ההתקנה הושלמה. מבחנים יבואו בהמשך.

בדיקה

נבדוק שלושה תרחישים עיקריים.

1. החלפת תפקידים רגילה משני > ראשי. יש צורך בהחלפת תפקידים קבועה במקרה, למשל, נצטרך לבצע כמה פעולות מניעה במרכז הנתונים הראשי ובזמן זה, על מנת שהנתונים יהיו זמינים, אנו מעבירים את העומס למרכז הנתונים הגיבוי.
2. החלפת תפקידי חירום משני > ראשי (כשל במרכז הנתונים). זהו התרחיש העיקרי שעבורו קיימת שכפול, שיכול לעזור לשרוד כשל מוחלט במרכז הנתונים מבלי לעצור את החברה לתקופה ממושכת.
3. התמוטטות ערוצי תקשורת בין מרכזי נתונים. בדיקת התנהגות נכונה של שתי מערכות אחסון בתנאים שבהם מסיבה כלשהי ערוץ התקשורת בין מרכזי הנתונים אינו זמין (למשל, חופר חפר במקום הלא נכון ושבר את האופטיקה האפלה).

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

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

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

החלפת תפקידים קבועה

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

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

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

לאחר מכן באחת ממערכות האחסון (זה לא משנה, בראש או בגיבוי) בתפריט "שכפול מרחוק", בחר את החיבור REPL1 שלנו ולחץ על "שנה תפקיד".

לאחר מספר שניות, LUN1R (מערכת אחסון גיבוי) הופך לראשי.

אנו ממפים את LUN1R עם מערכת אחסון2.

לאחר מכן, כונן ה-E: שלנו מחובר אוטומטית למארח, רק שהפעם הוא "הגיע" מ-LUN1R.

ליתר ביטחון, נשווה את סכומי הגיבוב.

זהה. מבחן עבר.

כישלון. כשל במרכז הנתונים

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

בוא נראה מה קורה במערכת אחסון 1 (הגיבוי כרגע).

אנו רואים שה-LUN הראשי (LUN1R) אינו זמין. הודעת שגיאה הופיעה ביומנים, בלוח המידע, וגם בכלל השכפול עצמו. לפיכך, נתונים מהמארח אינם זמינים כעת.

שנה את התפקיד של LUN1 לראשי.

אני עושה מיפוי למארח.

ודא שכונן E מופיע במארח.

אנחנו בודקים את ה-hash.

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

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

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

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

כשל בערוצי תקשורת בין מרכזי נתונים

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

על Primary אנחנו רואים שאין קשר עם Secondary.

ב-Seconary אנחנו רואים שאין קשר ל-primary.

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

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

לאחר זמן מה, הסנכרון הושלם.

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

ממצאים

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

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

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

אנא כתבו הערות, נשמח לקבל ביקורת נכונה ועצות מעשיות.

עד הפעם הבאה.

מקור: www.habr.com