ניתוח ביצועי VM ב-VMware vSphere. חלק 3: אחסון

חלק 1. על CPU
חלק 2. על זיכרון

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

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

קצת תיאוריה

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

• מספר פעולות קלט/פלט (פעולות קלט/פלט בשנייה, IOPS);
• תפוקה;
• עיכוב של פעולות קלט/פלט (Latency).

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

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

התפוקה קשורה למספר פעולות ה-I/O באופן הבא:

תפוקה = IOPS * גודל בלוק, כאשר גודל הבלוק הוא גודל הבלוק.

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

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

חֶבִיוֹן - פרמטר הביצועים המעניין ביותר. זמן השהיית הקלט/פלט עבור מכונה וירטואלית מורכבת מ:

• עיכובים בתוך ה-Hypervisor (KAVG, Average Kernel MilliSec/Read);
• עיכוב מסופק על ידי רשת הנתונים ומערכת האחסון (DAVG, Average Driver MilliSec/Command).

ההשהיה הכוללת הנראית לעין במערכת ההפעלה האורחת (GAVG, Average Guest MilliSec/Command) היא הסכום של KAVG ו-DAVG.

GAVG ו-DAVG נמדדים ו-KAVG מחושב: GAVG–DAVG.

מקור

בואו נסתכל מקרוב על KAVG. במהלך פעולה רגילה, KAVG אמור לשאוף לאפס או לפחות להיות הרבה פחות מ-DAVG. המקרה היחיד שאני מכיר בו KAVG צפוי להיות גבוה הוא מגבלת ה-IOPS בדיסק ה-VM. במקרה זה, כאשר תנסה לחרוג מהמגבלה, KAVG יגדל.

המרכיב המשמעותי ביותר של KAVG הוא QAVG - זמן תור העיבוד בתוך ההיפרוויזר. שאר הרכיבים של KAVG זניחים.

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

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

גודל התור לירח יכול להיות מושפע מהכללת מנגנון SIOC (Storage I/O Control). הוא מספק גישה אחידה לירח מכל השרתים באשכול על ידי שינוי דינמי של התור לירח בשרתים. כלומר, אם אחד המארחים מריץ VM שדורש כמות לא פרופורציונלית של ביצועים (VM שכן רועש), SIOC מקטין את אורך התור לירח במארח זה (DQLEN). פרטים נוספים כאן.

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

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

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

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

מוני ביצועי תת-מערכת הדיסק ב-vCenter נאספים בקטעי Datastore, Disk, Virtual Disk:

בסעיף חנות מידע ישנם מדדים לאחסון דיסקים של vSphere (מאגרי נתונים) שעליהם ממוקמים הדיסקים של ה-VM. כאן תמצאו מונים סטנדרטיים עבור:

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

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

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

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

בתמונה למטה יש גרף של ביצועי דיסק VM, שבו ניתן לראות את מספר ה-IOPS, השהיה וגודל הבלוק. 

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

ESXTOP

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

נתחיל עם מידע על מכונות וירטואליות. מסך "Disk VM" נקרא באמצעות מקש "v":

NVDISK הוא מספר הדיסקים של VM. כדי להציג מידע עבור כל דיסק, הקש "e" והזן את ה-GID של ה-VM המעניין.

המשמעות של שאר הפרמטרים במסך זה ברורה משמותיהם.

מסך שימושי נוסף בעת פתרון בעיות הוא מתאם דיסק. נקרא על ידי מקש "d" (שדות A,B,C,D,E,G נבחרים בתמונה למטה):

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

AQLEN – גודל תור מקסימלי במתאם.

גם במסך זה מופיעים מוני ההשהיה שעליהם דיברתי למעלה: KAVG/cmd, GAVG/cmd, DAVG/cmd, QAVG/cmd.

מסך מכשיר הדיסק, אשר נקרא על ידי לחיצה על מקש "u", מספק מידע על התקני בלוק בודדים - ירחים (שדות A, B, F, G, I נבחרים בתמונה למטה). כאן תוכלו לראות את מצב התור לירחים.

DQLEN - גודל תור עבור מכשיר בלוק.
ACTV - מספר פקודות קלט/פלט בליבת ESXi.
QUED - מספר פקודות קלט/פלט בתור.
%דולר אמריקאי - ACTV / DQLEN × 100%.
לִטעוֹן – (ACTV + QUED) / DQLEN.

אם %USD גבוה, כדאי לשקול להגדיל את התור. ככל שיש יותר פקודות בתור, כך ה-QAVG גבוה יותר ובהתאם, ה-KAVG.

אתה יכול גם לראות במסך התקן דיסק אם VAAI (vStorage API for Array Integration) פועל על מערכת האחסון. לשם כך, בחר בשדות A ו-O.

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

כפי שניתן לראות בתמונה למעלה, VAAI עובד על מערכת אחסון זו: נעשה שימוש פעיל בפרימיטיבים של אפס ו-ATS.

טיפים לייעול העבודה עם תת-מערכת הדיסק ב-ESXi

• שימו לב לגודל הבלוק.
• הגדר את גודל התור האופטימלי ב-HBA.
• אל תשכח להפעיל את SIOC בחנויות נתונים.
• בחר PSP בהתאם להמלצות יצרן מערכת האחסון.
• ודא ש-VAAI פועל.

מאמרים שימושיים בנושא:http://www.yellow-bricks.com/2011/06/23/disk-schednumreqoutstanding-the-story/
http://www.yellow-bricks.com/2009/09/29/whats-that-alua-exactly/
http://www.yellow-bricks.com/2019/03/05/dqlen-changes-what-is-going-on/
https://www.codyhosterman.com/2017/02/understanding-vmware-esxi-queuing-and-the-flasharray/
https://www.codyhosterman.com/2018/03/what-is-the-latency-stat-qavg/
https://kb.vmware.com/s/article/1267
https://kb.vmware.com/s/article/1268
https://kb.vmware.com/s/article/1027901
https://kb.vmware.com/s/article/2069356
https://kb.vmware.com/s/article/2053628
https://kb.vmware.com/s/article/1003469
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/vsphere-esxi-vcenter-server-67-performance-best-practices.pdf

מקור: www.habr.com