איך HPE SimpliVity 380 עבור VDI יעבוד: מבחני עומס קשים

הלקוח רצה VDI. באמת הסתכלתי על השילוב של SimpliVity + VDI Citrix Virtual Desktop. לכל המפעילים, עובדי משרדי העיר וכדומה. ישנם חמשת אלפים משתמשים בגל ההגירה הראשון בלבד, ולכן הם התעקשו על בדיקת עומס. VDI יכול להתחיל להאט, הוא יכול לשכב ברוגע - וזה לא תמיד קורה בגלל בעיות בערוץ. קנינו חבילת בדיקה מאוד חזקה במיוחד עבור VDI והעמסנו את התשתית עד שהיא הייתה כבדה מדי על הדיסקים והמעבד.

אז, נצטרך בקבוק פלסטיק ותוכנת LoginVSI עבור בדיקות VDI מתוחכמות. יש לנו את זה עם רישיונות ל-300 משתמשים. אחר כך לקחנו את חומרת HPE SimpliVity 380 בחבילה המתאימה למשימה של צפיפות משתמשים מקסימלית לשרת, חתכנו מכונות וירטואליות עם מנוי יתר טוב, התקנו עליהן תוכנת משרד ב-Win10 והתחלנו בבדיקות.

בואו נלך!

מערכת

שני צמתים (שרתים) של HPE SimpliVity 380 Gen10. בכל אחד:

• 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
• זיכרון RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
• בקר דיסק ראשי: HPE Smart Array P816i-a SR Gen10.
• כוננים קשיחים: 9 x 1.92 TB SATA 6Gb/s SSD (בתצורת RAID6 7+2, כלומר זהו דגם Medium במונחי HPE SimpliVity).
• כרטיסי רשת: 4 x 1Gb Eth (נתוני משתמש), 2 x 10Gb Eth (SimpliVity ו-vMotion backend).
• כרטיסי FPGA מובנים מיוחדים בכל צומת למניעת כפילויות/דחיסה.

הצמתים מחוברים זה לזה באמצעות חיבור Ethernet של 10Gb ישירות ללא מתג חיצוני, המשמש כ-SimpliVity backend ולהעברת נתוני מחשב וירטואלי באמצעות NFS. נתוני מכונות וירטואליות באשכול משתקפים תמיד בין שני צמתים.

הצמתים משולבים לתוך אשכול Vmware vSphere המנוהל על ידי vCenter.

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


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

לכל מכונה וירטואלית יש 2vCPU ו-4GB RAM:

התוכנה הבאה הדרושה לבדיקה הותקנה במכונות הוירטואליות:

• Windows 10 (64 סיביות), גרסה 1809.
• Adobe Reader XI.
• סוכן משלוח וירטואלי של Citrix 1811.1.
• Doro PDF 1.82.
• עדכון Java 7 13.
• Microsoft Office Professional Plus 2016.

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

איזון ואחסון נתונים מתרחשים ברמת אחסון התוכנה של SimpliVity עצמה.

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

בדיקה

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


הבדיקה בוצעה בשלושה מצבים:

מצב בנצ'מרק - מקרי עומס 300 עובדי ידע ו-300 עובדי אחסון.

מצב סטנדרטי - מארז עומס 300 עובדי כוח.

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

מבחני Knowledge and Power Workers מדמים את עומס העבודה האמיתי של משתמשים העובדים על תחנות עבודה וירטואליות.

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

במהלך הבדיקה, משתמשים נכנסים לתחנות עבודה למשך 48 דקות בקצב של כמשתמש אחד כל 10 שניות.

ממצאים

התוצאה העיקרית של בדיקת LoginVSI היא מדד VSImax, אשר מורכב מזמן הביצוע של משימות שונות שהושק על ידי המשתמש. לדוגמא: זמן פתיחת קובץ ב-Notepad, זמן לדחיסת קובץ ב-7-Zip וכו'.

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

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

להלן המדדים העיקריים:

מדדים

פעולות שננקטו

מְפוֹרָט описание

רכיבים טעונים

נ.ש.ל.ד.

זמן פתיחת טקסט
קובץ במשקל 1 KB

פנקס רשימות נפתח ו
פותח מסמך אקראי בגודל 1 KB המועתק מהמאגר
משאבים

מעבד ו-I/O

NFO

זמן פתיחת דיאלוג
חלונות בפנקס רשימות

פתיחת קובץ VSI-Notepad [Ctrl+O]

מעבד, זיכרון RAM ו-I/O

 

ZHC*

הגיע הזמן ליצור קובץ Zip דחוס מאוד

דחיסה מקומית
הועתק מקובץ pst אקראי בנפח 5MB
מאגר משאבים

מעבד ו-I/O

ZLC*

הגיע הזמן ליצור קובץ Zip דחוס בצורה חלשה

דחיסה מקומית
הועתק מקובץ pst אקראי בנפח 5MB
מאגר משאבים

I / O

 

CPU

חישוב גדול
מערך נתונים אקראי

יצירת מערך גדול
נתונים אקראיים שישמשו בטיימר הקלט/פלט (טיימר קלט/פלט)

CPU

כאשר מתבצעת בדיקה, מחושב תחילה המדד הבסיסי של VSIbase, אשר מראה את המהירות שבה מבוצעות עבודות ללא עומס על המערכת. על סמך זה נקבע VSImax Threshold, השווה ל-VSIbase + 1ms.

מסקנות לגבי ביצועי המערכת מתקבלות על סמך שני מדדים: VSIbase, הקובע את מהירות המערכת, ו-VSImax threshold, הקובע את מספר המשתמשים המקסימלי שהמערכת יכולה להתמודד איתם ללא ירידה משמעותית.

מדד 300 עובדי ידע

עובדי ידע הם משתמשים המעמיסים באופן קבוע זיכרון, מעבד ו-IO עם פסגות קטנות שונות. התוכנה מחקה את עומס העבודה של משתמשי משרד תובעניים, כאילו הם כל הזמן מחטטים במשהו (PDF, Java, חבילת משרד, צפייה בתמונות, 7-Zip). כאשר אתה מוסיף משתמשים מאפס ל-300, ההשהיה עבור כל אחד גדלה בהדרגה.

נתונים סטטיסטיים של VSImax:

VSIbase = 986ms, סף VSI לא הושג.

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:


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

מסקנה: 300 משתמשי ידע עובדים על האשכול הנוכחי ללא כל בעיות ואינם מפריעים זה לזה, ומגיעים למנוי יתר של pCPU/vCPU של 1 עד 6. העיכובים הכוללים גדלים באופן שווה ככל שהעומס גדל, אך הגבול שנקבע לא הושג.

מדד 300 עובדי אחסון

אלו משתמשים שכל הזמן כותבים וקוראים ביחס של 30 ל-70 בהתאמה. בדיקה זו בוצעה יותר למען הניסוי. נתונים סטטיסטיים של VSImax:


VSIbase = 1673, סף VSI הגיע ל-240 משתמשים.

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:

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

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

300 עובדי כוח

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


VSIbase = 970, סף VSI לא הושג.

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:


במהלך הבדיקה, סף עומס המעבד הושג באחד מצמתי המערכת, אך לא הייתה לכך השפעה משמעותית על פעולתו:

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

בדיקות סדירות לא הספיקו ללקוח, והלכנו רחוק יותר: הגדלנו את מאפייני ה-VM (מספר vCPUs כדי להעריך את הגידול במנוי היתר ובגודל הדיסק) והוספנו עומס נוסף.

בעת ביצוע בדיקות נוספות, נעשה שימוש בתצורת הדוכן הבאה:
300 שולחנות עבודה וירטואליים נפרסו בתצורת 4vCPU, 4GB RAM, 80GB HDD.

תצורה של אחת ממכונות הבדיקה:


המכונות פרוסים באפשרות ייעודי - העתקה מלאה:

מדד 300 עובדי ידע עם מנוי יתר 12

נתונים סטטיסטיים של VSImax:


VSIbase = 921 ms, סף VSI לא הושג.

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:


התוצאות שהתקבלו דומות לבדיקת תצורת ה-VM הקודמת.

300 עובדי כוח עם 12 מנויי יתר

נתונים סטטיסטיים של VSImax:


VSIbase = 933, סף VSI לא הושג.

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:


במהלך בדיקה זו, הושג גם סף העומס של המעבד, אך לא הייתה לכך השפעה משמעותית על הביצועים:

התוצאות שהתקבלו דומות לבדיקת התצורה הקודמת.

מה קורה אם אתה מפעיל את העומס במשך 10 שעות?

עכשיו בואו נראה אם ​​יהיה "אפקט צבירה" ונבצע בדיקות במשך 10 שעות ברציפות.

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

רף 300 עובדי ידע + 10 שעות

בנוסף, נבדק מקרה עומס של 300 עובדי ידע, ואחריו עבודת משתמשים במשך 10 שעות.

נתונים סטטיסטיים של VSImax:


VSIbase = 919 ms, סף VSI לא הושג.

נתונים סטטיסטיים מפורטים של VSImax:


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

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:


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

בדיקה נוספת בתוספת עומס סינטטי

הלקוח ביקש להוסיף עומס פרוע לדיסק. לשם כך, נוספה משימה למערכת האחסון בכל אחד מהמכונות הוירטואליות של המשתמש להפעיל עומס סינטטי על הדיסק כאשר המשתמש נכנס למערכת. העומס סופק על ידי כלי השירות fio, המאפשר לך להגביל את העומס על הדיסק במספר IOPS. בכל מכונה הושקה משימה להפעלת עומס נוסף בסך 22 IOPS 70%/30% קריאה/כתיבה אקראית.

רף 300 עובדי ידע + 22 IOPS למשתמש

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

עומס מעבד מארח:




במקביל, העיכובים במערכת האחסון גם גברו באופן טבעי:


היעדר כוח מחשוב הפך קריטי בסביבות 240 משתמשים:


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

230 benchmark עובדי משרד + 22 IOPS למשתמש

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

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

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

נתונים סטטיסטיים של VSImax:


VSIbase = 918 ms, סף VSI לא הושג.

נתונים סטטיסטיים מפורטים של VSImax:


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

סטטיסטיקות עומס מעבד:




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

סטטיסטיקות עומס של מערכת אחסון מניטור SimpliVity:


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

העומס על מערכת האחסון במהלך הבדיקה עמד על כ-6 IOPS ביחס של 500/60 (40 IOPS קריאה, 3 IOPS כתיבה), שהם כ-900 IOPS לתחנת עבודה.

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

סך הכל

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

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

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

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

הפדרציה

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

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

מקור: www.habr.com