זמינות גבוהה בשרתים וירטואליים: מדריך מלא

אינפורמטק דיגיטל » Recursos » זמינות גבוהה בשרתים וירטואליים: מדריך מלא

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

כשאנחנו מתערבבים וירטואליזציהאשכולות, אחסון והתאוששות מאסוןטכנולוגיות רבות צצו (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, רפליקות וכו'), ולא תמיד ברור באיזו לבחור או כיצד לשלב את כולן. מאמר זה מספק סקירה מעמיקה של האפשרויות והגישות העיקריות: החל מאשכולות מסורתיים עם אחסון משותף ועד פתרונות מודרניים המבוססים על שכפול בזמן אמת בין צמתים, כולל דוגמאות ספציפיות עם ארכיטקטורות Red Hat, Microsoft Hyper-V, QNAP ו-HA-DAS.

מושגים בסיסיים של זמינות גבוהה בסביבות וירטואליות

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

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

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

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

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

זמינות גבוהה בפלטפורמות Red Hat Enterprise Linux ו-KVM/Xen

המערכת האקולוגית של רד האט מציעה מספר אפשרויות עבור הגן על מכונות וירטואליות באמצעות אשכולות ותוספים של זמינות גבוההבגרסאות כמו Red Hat Enterprise Linux 5 ו-6, נתמכים שילובים שונים של היפר-ויזורים ותוספות אשכול.

תומכי RHEL 5 שתי פלטפורמות וירטואליזציה: Xen (מ-RHEL 5.0) ו-KVM (מ-RHEL 5.4)תוסף אשכול RHEL 5 Advanced Platform (AP) מאפשר לך לנהל מכונות וירטואליות מסוג Xen ו-KVM כמשאבי אשכול, כך שתשתית הזמינות הגבוהה של המארח תשלוט בהפעלה, כיבוי וגיבוי בעת כשל של מכונות וירטואליות בין צמתים.

עם RHEL 6, התמיכה בווירטואליזציה פשוטה יותר: רק KVM נתמך כ-hypervisorעם זאת, תוסף RHEL 6 High Availability עדיין מאפשר להתייחס למכונות וירטואליות של KVM כמשאבי אשכול המנוהלים על ידי תשתית ה-HA של המארח. מנהל משאבי האשכול (rgmanager בגרסאות קלאסיות) אחראי על ניטור הצמתים והעברת אורחים בין שרתים פיזיים כאשר מתגלה כשל.

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

היבט מעניין אחד הוא שמנקודת מבטו של האשכול, מערכת ההפעלה האורחת של המכונה הווירטואלית לא משנה כל כךכל מערכת הפעלה אורחת תואמת Xen או KVM ב-RHEL יכולה להיחשב כמכונה וירטואלית בעלת זמינות גבוהה: גרסאות שונות של RHEL (3, 4, 5 וכו') ומהדורות שונות של Microsoft Windows, כל עוד הן נתמכות על ידי ההיפר-ויזור. זה מספק גמישות ניכרת בעת אבטחת סביבות מעורבות.

עם זאת, רד האט עצמה ממליצה על זהירות בבחירה בין שימוש תוסף RHEL High Availability או פלטפורמות וירטואליזציה שלמות יותר כגון Red Hat Enterprise Virtualization (RHEV) לספק זמינות גבוהה (HA) למכונות וירטואליות. שניהם מציעים פונקציונליות של זמינות גבוהה, אך מקרי השימוש שונים ויש לקחת בחשבון את גודל הסביבה ואת מודל ההפעלה.

מתי להשתמש ב-RHEL HA לעומת RHEV לזמינות גבוהה

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

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

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

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

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

זמינות גבוהה ב-Hyper-V: אשכולות, עותקים משוכפלים והעברה חיה

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

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

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

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

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

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

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

רפליקה של Hyper-V והעברה חיה "לא שיתפו דבר"

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

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

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

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

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

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

השילוב של טכנולוגיות אלו (אשכולות של גיבוי בעת כשל, CSV, הגירה חיה עם או בלי אחסון משותף, ושכפול Hyper-V) מספק מגוון רחב של אפשרויות עבור תכנון אסטרטגיות המשכיות עסקית וסבילות לתקלות מותאמים לתקציבים שונים ולרמות ביקוש שונות.

פתרונות זמינות גבוהה עם HA-DAS ו-Windows Server

מעבר לסביבות עם SAN גדולות, ישנן ארכיטקטורות שנועדו עבור זמינות גבוהה במערכות אחסון המחוברות ישירות לשרתים (HA-DAS)פתרונות אלה מנצלים את Windows Server (למשל, 2012) ובקרי RAID/HBA מתקדמים כדי לספק אשכולות בעלי זמינות גבוהה ללא צורך בהגדרת iSCSI SAN או FC מסורתיים.

בגישה זו, נעשה שימוש באמצעים הבאים: שני צמתי אשכול HA עם אחסון JBOD משותף (מארז דיסק "סתם חבורה של דיסקים" ללא אינטליגנציה משלו). ה-JBOD מתחבר לשני השרתים באמצעות בקרי Host RAID HBA יתירים, כך שכל צומת רואה את אותה קבוצת דיסקים ויכול לגשת לאותו RAID בו זמנית.

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

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

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

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

פתרונות HA-DAS מסוג זה מיועדים לשימושים שונים: וירטואליזציה של שרתי Hyper-V, Windows VDI, אחסון SAN/NAS, מסדי נתונים טרנזקציונליים (OLTP)מחסן נתונים ושירותי אינטרנט בעלי זמינות גבוההכל זה מושג על ידי מינוף שלדת אחסון משותפת אחת, שני צמתים מיותרים ולוגיקת אשכולות של Windows.

זמינות גבוהה במיוחד עבור מערכי NAS של QNAP ו-Virtualization Station 4

בתחום ה-NAS, יצרנים כמו QNAP פיתחו פונקציונליות מתקדמות עבור כדי להשיג זמינות גבוהה הן של אחסון והן של מכונות וירטואליות המאוחסנות בציוד שלךבפרט, הם משלבים את מערכת ההפעלה QuTS hero (מבוססת על ZFS) עם Virtualization Station 4 כדי להציע שכפול בזמן אמת ומעבר לגיבוי בין שני התקני NAS.

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

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

תכונה זו זמינה רק ב NAS של QNAP עם מעבדי x86 שמריצים את QuTS hero ויש להם את הגרסה המתאימה של Virtualization Station 4. השימוש בטכנולוגיית ZFS ו-SnapSync חיוני, מכיוון שהיא אחראית על סנכרון נתוני המכונה הווירטואלית בין שני התקני ה-NAS בזמן אמת, ומבטיחה שהמכונה הווירטואלית המשוכפלת תמיד מעודכנת.

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

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

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

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

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

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

דרישות ומגבלות של זמינות גבוהה ב-QNAP

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

לגבי התוכנה, יש צורך גרסת h5.3 ומעלה של QuTS hero ועם Virtualization Station 4.1 או גרסה מתקדמת יותר. רק גרסאות אלו כוללות פונקציונליות של VM HA מבוססת SnapSync. תכונה זו אינה זמינה בהתקני NAS עם QTS "קלאסי" או גרסאות קודמות של Virtualization Station.

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

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

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

ההבדל בין זמינות גבוהה לבין שכפול/DR פשוט במכונות וירטואליות

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

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

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

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

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

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

מגוון הפתרונות הזה - אשכולות RHEL ו-Hyper-V, ארכיטקטורות HA-DAS נטולות SAN, זמינות גבוהה ייעודית ב-QNAP NAS עם Virtualization Station, ושכפול מתקדם של מכונות וירטואליות - מדגים שכיום ניתן לתכנן... סביבות וירטואליות עמידות לתקלות במיוחד המותאמות לגדלים ולתקציבים שונים של חברותהבנת ההבדלים בין כל גישה, המגבלות שלהן (כגון המספר המרבי של צמתים או הצורך באחסון משותף) והדרישות הטכניות שלהן היא המפתח לבחירת השילוב הנכון ולשמירה על שירותים קריטיים פועלים כמעט ללא הפרעה.