אשכול של שני צמתים - השטן נמצא בפרטים

היי הבר! אני מציג לתשומת לבך את התרגום של המאמר "שני צמתים - השטן נמצא בפרטים" מאת אנדרו ביקהוף.

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

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

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

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

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

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

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

לכן, כדי למנוע שחיתות נתונים כתוצאה מכשל בצומת בודד - אנחנו מסתמכים על משהו שנקרא "דיסוציאציה" (סִיוּף).

עקרון הדיסוציאציה

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

ישנן שתי קטגוריות של שיטות דיסוציאציה, שאקרא להן ישר и עקיף, אבל אפשר לקרוא להם באותה מידה פָּעִיל и פַּסִיבִי. שיטות ישירות כוללות פעולות מצד עמיתים שורדים, כגון אינטראקציה עם מכשיר IPMI (Intelligent Platform Management Interface) או iLO (מנגנון לניהול שרתים בהיעדר גישה פיזית אליהם), בעוד ששיטות עקיפות מסתמכות על התקן הכושל. צומת לזהות איכשהו שהוא במצב לא בריא (או לפחות למנוע מחברים אחרים להתאושש) ולאותת כלב שמירה על חומרה על הצורך לנתק את הצומת הכושל.

הקוורום עוזר בעת שימוש בשיטות ישירות ועקיפות כאחד.

דיסוציאציה ישירה

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

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

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

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

למרבה הצער, תכונות ההפעלה של מכשירי IPMI ו-iLo נחשבות לעתים רחוקות בזמן רכישת הציוד.

דיסוציאציה עקיפה

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

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

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

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

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

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

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

מִניָן

הקוורום נשמע נהדר, נכון?

החיסרון היחיד הוא שכדי שיהיה אותו באשכול עם N איברים, אתה צריך שיהיה לך חיבור בין N/2+1 מהצמתים שלך שנותר. מה שלא אפשרי באשכול שני צמתים לאחר שצומת אחד נכשל.

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

ביצוע עבודה של אשכול דו-צמתים

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

אפשרות 1 - שיטת דיסוציאציה כפולה

התקן iLO או IPMI של צומת מייצג נקודת כשל מכיוון שאם הוא נכשל, ניצולים לא יכולים להשתמש בו כדי להביא את הצומת למצב בטוח. באשכול של 3 צמתים או יותר, אנו יכולים להפחית זאת על ידי חישוב מניין ושימוש בכלי שמירה של חומרה (מנגנון ניתוק עקיף, כפי שנדון קודם לכן). במקרה של שני צמתים, עלינו להשתמש במקום זאת ביחידות חלוקת כוח ברשת (PDUs).

לאחר כשל, השורד מנסה תחילה ליצור קשר עם התקן הניתוק הראשי (משובץ iLO או IPMI). אם זה מצליח, ההתאוששות נמשכת כרגיל. רק אם התקן iLO/IPMI נכשל, יש גישה ל-PDU; אם הגישה מצליחה, השחזור יכול להמשיך.

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

כאן אתם עשויים לשאול - האם ה-PDU הוא נקודת כשל בודדת? שהתשובה לכך היא, כמובן.

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

אפשרות 2 - הוספת בורר

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

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

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

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

ההבדל המעשי בין בורר לצומת שלישי הוא שבורר דורש הרבה פחות משאבים כדי לפעול ויכול לשרת יותר מאשכול אחד.

אפשרות 3 - גורם אנושי

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

אפשרות בונוס

הזכרתי שאתה יכול להוסיף צומת שלישי?

שני מתלים

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

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

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

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

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

שני מרכזי נתונים

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

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

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

מקור: www.habr.com