הכל אודות Fault domains ,Update domains ו- Availability set

אהלן, אהלן!
הפעם נדבר על…
Fault domain ,Update domain ו- Availability set.
אחד היתרונות הבולטים בשימוש בענן הציבורי (Public Cloud) ואחת הסיבות העיקריות לבחירה בענן הציבורי כסביבת האירוח של המערכות, היא העלות הנמוכה יחסית של השירות בתמורה לקבלת שרידות וזמינות גבוה מאוד. המושגים שציינתי שייכים לעולם השרידות והזמינות ב-Azure.
במאמר הפעם נסביר מהם כל אחד מהמושגים הנ"ל וכיצד הם מאפשרים לכם לייצר זמינות ושרידות למערכות שלכם שמתארחות ב-Azure.
היכנסו לפוסט ויאללה מתחילים…

בסוף אחד המאמרים הראשונים שכתבתי, הסברתי ממש על קצה המזלג מה זה Fault Domain ומה זה Update domains.
למי שלא זוכר מוזמן לחזור אחורה ולקרוא –Windows Azure data centers

ועכשיו להסברים הרבה יותר מפורטים ומורחבים.

מה זה Fault Domain ?
Fault Domain זו קבוצה של שרתים וירטואלים המתארחים על תשתית פיזית שיש לה נקודת כשל משותפת.
כשאני אומר נקודת כשל משותפת, אני מתכוון לכך שאותם שרתים מקבלים חשמל מאותו המקור, שאותם שרתים מקושרים לאותו ציוד תקשורת פיזי, כמו לדוגמא Switch משותף. שאותם שרתים…רצים על אותו שרת פיזי. שאותם שרתים…מקבלים מיזוג מאותה מערכת קירור וכו' וכו' …

בחוות השרתים של Azure (ואני שוב מזמין אתכם לחזור לפוסט Windows Azure data centers) השרתים מסודרים בתוך מכולות (Containers) כן, כן, ממש כאלו מכולות כמו שיש על המשאיות שמובילות סחורה.
כל מכולה כזו יש לה אספקת חשמל משותפת, ציוד תקשורת משותף מערכת קירור משותפת וכו' …
מיקרוסופט מגדירים כל מכולה כזו כ- Fault Domain.
בכל אחת מחוות השרתים של מיקרוסופט יש כמה וכמה מכולות שכאלו.
על מנת שהשירות שלכם ישרוד כשל בחשמל, כשל במערכת קירור, כשל בציוד תקשורת וכו'…
עליכם לדאוג שהשירות שלכם ירוץ ע"ג שתי שרתים וירטואלים לפחות ושכל שרת יתארח ב- Fault Domain נפרד.
ההפרדה הזו בעצם יוצרת שרידות ע"י כך שאתם מבטלים את התלות של השירות שלכם בנקודת כשל אחת.

כיצד מגדירים שרתים שיתארחו ב- Fault Domains שונים אתם שואלים ?
על כך נדבר בהמשך המאמר ואז הכל יהיה מובן.

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

מה זה Update domain ?
Update domain היא קבוצה לוגית שמאגדת בתוכה שרתים וירטואלים.
כאשר מיקרוסופט מבצעת עבודה יזומה על שרתים ברמת התוכנה היא מבצעת את העבודה בחלקים.
מה זה אומר בחלקים ? כל פעם העבודה מתבצעת על קבוצת שרתים/Update domain שונה.
אף פעם העדכון לא מתבצע על מס' Update domains במקביל.
על מנת להימנע מהשבתה של השירות שלכם בזמן עבודה יזומה של מיקרוסופט, עליכם לדאוג שהשירות שלכם ירוץ ע"ג שתי שרתים וירטואלים לפחות ושכל שרת ישויך ל- Update domain שונה.
החלוקה של השירות שלכם לשתי שרתים וירטואלים שכל אחד משוייך ל- Update domain שונה מאפשרת לשירות שלכם להישאר זמין במקרה ומיקרוסופט מבצעים עבודה שגורמת לשרת להיות לא זמין.
הסיבה שהשירות שלכם יישאר זמין היא מכיוון שבאותו הזמן ששרת אחד לא יהיה זמין, השרת השני ימשיך לתפקד, להיות זמין ולספק שירות.

אתם ודאי שואלים בשלב זה כיצד ניתן לקבוע שהשרתים יהיו משוייכים ל- Update domains שונים על מנת לשמור על שרידות ?
מיד מגיעים לדבר על הנושא.

מה זה Availability set ?
Availability set זו מעין קבוצה שמשייכים אליה שרתים והיא זו שדואגת שהשרתים המשוייכים לאותו ה- Availability set תתבצע בניהם הפרדה ל- Fault Domains ו-Update domains שונים.
כך למעשה אתם יוצרים את השרידות עבור השרתים שלכם.
למשתמש אין את היכולת לקבוע עבור כל שרת לאיזה Fault Domain ו- Update domain השרת יהיה משוייך.
מי שקובע עבור המשתמש כל שרת לאיזה Fault Domain ו- Update domain הוא יהיה משוייך זה ה- Availability set שעושה זאת באופן אוטומטי.
המשתמש רק צריך לדאוג לשייך את השרתים שלו ל-Availability sets.
על מנת שבאמת תוכל להתקיים שרידות ותהיה הפרדה של השירות בין שתי Fault Domains שונים ובין שתי Update domains שונים בכל Availability set חייבים להיות מינימום שתי שרתים שמריצים את אותו השירות.

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

אנסה לחדד קצת יותר, מערך=Cloud service.
זוכרים את המאמר Microsoft Azure cloud service ? שם כתבתי,

כעת נעשה סיכום ביניים קצר כדי להגדיר במשפט אחד מה זה Microsoft Azure cloud service ? Microsoft Azure cloud service הוא שירות שמכיל בתוכו שרתים וירטואליים (Instances\VMs) המריצים כולם את אותו אתר/אפליקציה/שירות כאילו כל השרתים היו יחידה אחת.

במילים אחרות כל השרתים שמשוייכים לאותו ה-Cloud service צריך להגדיר אותם באותו ה-Availability set כך שעבור כל Cloud service יהיה Availability set שמכיל את השרתים של Cloud service ספציפי.
הביטו בתמונה הבאה היא נועדה להמחיש את כל מה שנכתב במאמר הזה.

קרדיט לתמונה – מיקרוסופט.

 רגע לפני סיום משהו נוסף,
החלוקה של השרתים ל- Fault Domains מחולקת תמיד לעד שתי Fault Domains.
FD1 ו-FD2.
לצורך הדוגמא נניח ויש לכם מערך של ארבעה שרתים שמריצים את אותו השירות.
שייכתם את ארבעת השרתים לאותו ה-Availability set.
ה-Availability set יחלק את השרתים באופן הבא:
שתי שרתים ישייך ל- FD1 ושתי שרתים אחרים ישייך ל-FD2.
(למי שבטעות לא הבין, FD זה קיצור של Fault Domain)

מה לגבי חלוקה ל-Update domains ?
שם החלוקה מתבצעת ליותר קבוצות של Update domain, עד ארבעה קבוצות. UD1, UD2, UD3, UD4.
שוב לצורך הדוגמא נניח ויש לכם מערך של ארבעה שרתים שמריצים את אותו השירות.
שייכתם את ארבעת השרתים לאותו ה-Availability set.
ה-Availability set יחלק את השרתים באופן הבא:
שרת אחד בכל UD.
שרת ראשון ישייך ל-UD1
שרת שני ישייך ל-UD2
שרת שלישי ישייך ל-UD3
שרת רביעי ישייך ל-UD4
וכך הלאה בצורה מחזורית. (ושוב אם מישהו בטעות לא הבין UD זה קיצור של Update domain).

רק כדי שבטוח תבינו אתן עוד דוגמא אחת.
אם היו שמונה שרתים במערך החלוקה הייתה כזו:
ארבע שרתים בכל Fault Domain
ושתי שרתים בכל Update domain

מקווה שהדברים מובנים.
הקפידו לבצע את השיוכים של השרתים ל-Availability set בצורה נכונה על מנת לנצל את יתרון השרידות ש-Azure מספק לכם.

במאמרים מתקדמים יותר אציג צעד אחר צעד כיצד ליצור Availability set ,כיצד לשייך שרת וירטואלי ל-Availability set, כיצד להעביר שרת וירטואלי מ-Availability set אחד לאחר ומה ההשלכות לכך.

שאלות הארות/הערות בתחתית הפוסט.