במאמר זה, ברצוני לדבר על התכונות של כל מערכי Flash AccelStor העובדים עם אחת מפלטפורמות הווירטואליזציה הפופולריות ביותר - VMware vSphere. במיוחד, התמקד באותם פרמטרים שיעזרו לך לקבל את האפקט המרבי משימוש בכלי כה רב עוצמה כמו All Flash.
AccelStor NeoSapphire™ כל מערכי הפלאש הם או התקני צומת המבוססים על כונני SSD עם גישה שונה מהותית ליישום הרעיון של אחסון נתונים וארגון הגישה אליו באמצעות טכנולוגיה קניינית במקום אלגוריתמי ה-RAID הפופולריים מאוד. המערכים מספקים גישה חסימה למארחים דרך ממשקי Fibre Channel או iSCSI. למען ההגינות, אנו מציינים שלדגמים עם ממשק ISCSI יש גם גישה לקבצים כבונוס נחמד. אבל במאמר זה נתמקד בשימוש בפרוטוקולי בלוק בתור הפרודוקטיבי ביותר עבור All Flash.
ניתן לחלק את כל תהליך הפריסה והתצורה שלאחר מכן של פעולה משותפת של מערך AccelStor ומערכת הווירטואליזציה VMware vSphere למספר שלבים:
- יישום טופולוגיית חיבור ותצורה של רשת SAN;
- הגדרת מערך כל פלאש;
- הגדרת מארחי ESXi;
- הגדרת מכונות וירטואליות.
AccelStor NeoSapphire™ מערכי Fibre Channel ומערכי iSCSI שימשו כחומרה לדוגמה. תוכנת הבסיס היא VMware vSphere 6.7U1.
לפני פריסת המערכות המתוארות במאמר זה, מומלץ מאוד לקרוא את התיעוד מ-VMware לגבי בעיות ביצועים ( ) והגדרות iSCSI ()
טופולוגיית חיבור ותצורת רשת SAN
המרכיבים העיקריים של רשת SAN הם HBAs במארחי ESXi, מתגי SAN וצמתי מערך. טופולוגיה טיפוסית לרשת כזו תיראה כך:
המונח Switch כאן מתייחס הן למתג פיזי נפרד או לסט מתגים (Fabric), והן למכשיר המשותף בין שירותים שונים (VSAN במקרה של Fibre Channel ו-VLAN במקרה של iSCSI). שימוש בשני מתגים/בדים עצמאיים יבטל נקודת כשל אפשרית.
חיבור ישיר של מארחים למערך, למרות שנתמך, מאוד לא מומלץ. הביצועים של כל מערכי הפלאש גבוהים למדי. ולשם מהירות מקסימלית, יש להשתמש בכל היציאות של המערך. לכן, נוכחות של מתג אחד לפחות בין המארחים לבין NeoSapphire™ היא חובה.
הנוכחות של שתי יציאות ב-HBA המארח היא גם דרישה חובה כדי להשיג ביצועים מקסימליים ולהבטיח סובלנות לתקלות.
בעת שימוש בממשק Fibre Channel, יש להגדיר אזורי אזורים כדי למנוע התנגשויות אפשריות בין יוזמים ומטרות. אזורים בנויים על העיקרון של "יציאת יוזם אחת - יציאת מערך אחת או יותר."
אם אתה משתמש בחיבור דרך iSCSI במקרה של שימוש במתג משותף עם שירותים אחרים, אז הכרחי לבודד תעבורת iSCSI בתוך VLAN נפרד. כמו כן, מומלץ מאוד לאפשר תמיכה ב-Jumbo Frames (MTU = 9000) כדי להגדיל את גודל המנות ברשת ובכך להפחית את כמות המידע התקורה במהלך השידור. עם זאת, כדאי לזכור שלפעולה נכונה יש צורך לשנות את פרמטר ה-MTU בכל רכיבי הרשת לאורך שרשרת "יוזם-מתג-יעד".
הגדרת מערך All Flash
המערך מועבר ללקוחות עם קבוצות שכבר נוצרו . לכן, אין צורך לבצע פעולות כדי לשלב כוננים למבנה אחד. אתה רק צריך ליצור נפחים בגודל ובכמות הנדרשים.
מטעמי נוחות, קיימת פונקציונליות ליצירת אצווה של מספר כרכים בגודל נתון בו-זמנית. כברירת מחדל, נוצרים נפחים דקים, מכיוון שהדבר מאפשר שימוש יעיל יותר בשטח האחסון הזמין (כולל תמיכה ב- Space Reclamation). מבחינת ביצועים, ההבדל בין נפחים "דקים" ל"עבים" אינו עולה על 1%. עם זאת, אם אתה רוצה "לסחוט את כל המיץ" מתוך מערך, אתה תמיד יכול להמיר כל נפח "דק" ל"עבה". אבל צריך לזכור שניתוח כזה הוא בלתי הפיך.
לאחר מכן, נותר "לפרסם" את אמצעי האחסון שנוצרו ולהגדיר זכויות גישה אליהם מהמארחים באמצעות ACLs (כתובות IP עבור iSCSI ו-WWPN עבור FC) והפרדה פיזית על ידי יציאות מערך. עבור דגמי iSCSI זה נעשה על ידי יצירת Target.
עבור דגמי FC, הפרסום מתרחש באמצעות יצירת LUN עבור כל יציאה של המערך.
כדי להאיץ את תהליך ההגדרה, ניתן לשלב מארחים לקבוצות. יתרה מכך, אם המארח משתמש ב-FC HBA מרובה יציאות (מה שבפועל קורה לרוב), אז המערכת קובעת אוטומטית שהיציאות של HBA כזה שייכות למארח בודד הודות ל-WWPNs הנבדלים באחד. יצירת אצווה של Target/LUN נתמכת גם עבור שני הממשקים.
הערה חשובה בעת שימוש בממשק iSCSI היא ליצור מספר יעדים עבור אמצעי אחסון בו-זמנית כדי להגביר את הביצועים, מכיוון שלא ניתן לשנות את התור על היעד ולמעשה יהווה צוואר בקבוק.
הגדרת מארחי ESXi
בצד המארח של ESXi, תצורה בסיסית מבוצעת על פי תרחיש צפוי לחלוטין. הליך עבור חיבור iSCSI:
- הוסף מתאם iSCSI תוכנה (לא נדרש אם הוא כבר נוסף, או אם אתה משתמש במתאם iSCSI חומרה);
- יצירת vSwitch שדרכו תעבור תעבורת iSCSI, והוספת קישור מעלה פיזי ו-VMkernel אליו;
- הוספת כתובות מערך ל- Dynamic Discovery;
- יצירת מאגר נתונים
כמה הערות חשובות:
- במקרה הכללי, כמובן, אתה יכול להשתמש ב-vSwitch קיים, אבל במקרה של vSwitch נפרד, ניהול הגדרות המארח יהיה הרבה יותר קל.
- יש צורך להפריד בין תעבורת Management ו-iSCSI לקישורים פיזיים ו/או רשתות VLAN נפרדות כדי למנוע בעיות ביצועים.
- כתובות ה-IP של ה-VMkernel והיציאות המתאימות של מערך All Flash חייבות להיות בתוך אותה רשת משנה, שוב עקב בעיות ביצועים.
- כדי להבטיח סובלנות לתקלות בהתאם לכללי VMware, vSwitch חייב להיות בעל לפחות שני קישורים פיזיים
- אם נעשה שימוש במסגרות ג'מבו, עליך לשנות את ה-MTU של vSwitch ו-VMkernel
- זה יהיה שימושי להזכיר לך שעל פי המלצות VMware עבור מתאמים פיזיים שישמשו לעבודה עם תעבורת iSCSI, יש צורך להגדיר Teaming ו-Failover. בפרט, כל VMkernel חייב לעבוד דרך קישור מעלה אחד בלבד, יש להעביר את הקישור השני למצב שאינו בשימוש. כדי לסבול תקלות, עליך להוסיף שני VMkernels, שכל אחד מהם יפעל דרך ה-uplink שלו.
מתאם VMkernel (vmk#)
מתאם רשת פיזית (vmnic#)
vmk1 (Storage01)
מתאמים פעילים
vmnic2
מתאמים שאינם בשימוש
vmnic3
vmk2 (Storage02)
מתאמים פעילים
vmnic3
מתאמים שאינם בשימוש
vmnic2
אין צורך בצעדים מקדימים כדי להתחבר באמצעות Fibre Channel. אתה יכול ליצור מיד מאגר נתונים.
לאחר יצירת מאגר הנתונים, עליך לוודא שמדיניות ה-Round Robin עבור נתיבים אל היעד/LUN משמשת כבעלת הביצועים ביותר.
כברירת מחדל, הגדרות VMware מספקות שימוש במדיניות זו בהתאם לתכנית: 1000 בקשות דרך הנתיב הראשון, 1000 הבקשות הבאות דרך הנתיב השני וכו'. אינטראקציה כזו בין המארח למערך שני הבקרים תהיה לא מאוזנת. לכן, אנו ממליצים להגדיר את מדיניות Round Robin = 1 פרמטר דרך Esxcli/PowerCLI.
פרמטרים
עבור Esccli:
- רשימת LUNs זמינים
רשימת התקני esxcli אחסון nmp
- העתק את שם המכשיר
- שנה את מדיניות הסיבוב רובין
esxcli storage nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
רוב היישומים המודרניים נועדו להחליף חבילות נתונים גדולות על מנת למקסם את ניצול רוחב הפס ולהפחית את עומס המעבד. לכן, ESXi כברירת מחדל מנפיקה בקשות קלט/פלט להתקן האחסון בנתחים של עד 32767KB. עם זאת, עבור תרחישים מסוימים, החלפת נתחים קטנים יותר תהיה פרודוקטיבית יותר. עבור מערכי AccelStor, אלו הם התרחישים הבאים:
- המכונה הוירטואלית משתמשת ב-UEFI במקום ב-BIOS מדור קודם
- משתמש ב-vSphere Replication
עבור תרחישים כאלה, מומלץ לשנות את הערך של הפרמטר Disk.DiskMaxIOSize ל-4096.
עבור חיבורי iSCSI, מומלץ לשנות את הפרמטר Login Timeout ל-30 (ברירת מחדל 5) כדי להגביר את יציבות החיבור ולהשבית את DelayedAck delay לאישורים של מנות שהועברו. שתי האפשרויות נמצאות ב-vSphere Client: מארח → הגדר → אחסון → מתאמי אחסון → אפשרויות מתקדמות עבור מתאם iSCSI
נקודה עדינה למדי היא מספר הכרכים המשמשים עבור מאגר הנתונים. ברור שלמען נוחות הניהול יש רצון ליצור נפח אחד גדול לכל נפח המערך. עם זאת, לנוכחותם של מספר כרכים ובהתאם, למאגר הנתונים יש השפעה מועילה על הביצועים הכוללים (עוד על תורים בהמשך). לכן, אנו ממליצים ליצור לפחות שני כרכים.
עד לאחרונה יחסית, VMware המליצה להגביל את מספר המכונות הווירטואליות בחנות נתונים אחת, שוב על מנת להשיג את הביצועים הגבוהים ביותר האפשריים. עם זאת, כעת, במיוחד עם התפשטות ה-VDI, הבעיה הזו כבר לא כל כך חריפה. אבל זה לא מבטל את הכלל רב השנים - להפיץ מכונות וירטואליות הדורשות IO אינטנסיבי על פני מאגרי נתונים שונים. כדי לקבוע את המספר האופטימלי של מכונות וירטואליות לכל כרך, אין דבר טוב יותר בתוך התשתית שלו.
הגדרת מכונות וירטואליות
אין דרישות מיוחדות בעת הגדרת מכונות וירטואליות, או ליתר דיוק, הן די רגילות:
- שימוש בגרסת ה-VM הגבוהה ביותר האפשרית (תאימות)
- זה יותר להקפיד להגדיר את גודל ה-RAM בעת הצבת מכונות וירטואליות בצפיפות, למשל, ב-VDI (שכן כברירת מחדל, בעת האתחול, נוצר קובץ עמוד בגודל התואם ל-RAM, אשר צורך קיבולת שימושית ומשפיע על הביצוע האחרון)
- השתמש בגרסאות המתאמים הפרודוקטיביות ביותר מבחינת IO: רשת מסוג VMXNET 3 ו-SCSI מסוג PVSCSI
- השתמש ב-Thick Provision Eager Zeroed מסוג דיסק לביצועים מקסימליים וב-Thin Provisioning לניצול מקסימלי של שטח האחסון
- במידת האפשר, הגבל את הפעולה של מכונות קריטיות שאינן קלט/פלט באמצעות הגבלת דיסק וירטואלי
- הקפד להתקין את VMware Tools
הערות על תורים
Queue (או Outstanding I/Os) הוא מספר בקשות הקלט/פלט (פקודות SCSI) הממתינות לעיבוד בכל זמן נתון עבור התקן/אפליקציה ספציפיים. במקרה של הצפת תור, מונפקות שגיאות QFULL, מה שבסופו של דבר מביא להגדלת פרמטר ההשהיה. כאשר משתמשים במערכות אחסון בדיסק (ציר), באופן תיאורטי, ככל שהתור גבוה יותר, כך הביצועים שלהם גבוהים יותר. עם זאת, אל תשתמש בו לרעה, מכיוון שקל להיתקל ב-QFULL. במקרה של מערכות All Flash, מצד אחד, הכל קצת יותר פשוט: אחרי הכל, למערך יש חבילות נמוכות בסדרי גודל ולכן, לרוב, אין צורך לווסת בנפרד את גודל התורים. אבל מצד שני, בתרחישי שימוש מסוימים (הטיה חזקה בדרישות IO למכונות וירטואליות ספציפיות, בדיקות לביצועים מקסימליים וכו') יש צורך, אם לא לשנות את הפרמטרים של התורים, אז לפחות להבין אילו אינדיקטורים ניתן להשיג, והעיקר באילו דרכים.
במערך AccelStor All Flash עצמו אין מגבלות ביחס לנפחים או ליציאות I/O. במידת הצורך, אפילו אמצעי אחסון בודד יכול לקבל את כל המשאבים של המערך. המגבלה היחידה על התור היא עבור יעדי iSCSI. זו הסיבה שהצורך ליצור מספר (באופן אידיאלי עד 8 חלקים) מטרות עבור כל נפח כדי להתגבר על מגבלה זו צוין למעלה. נחזור גם על כך שמערכים של AccelStor הם פתרונות פרודוקטיביים מאוד. לכן, עליך להשתמש בכל יציאות הממשק של המערכת כדי להשיג מהירות מקסימלית.
בצד המארח של ESXi, המצב שונה לחלוטין. המארח עצמו מיישם את הנוהג של גישה שווה למשאבים לכל המשתתפים. לכן, ישנם תורי IO נפרדים עבור מערכת ההפעלה האורחת ו-HBA. תורים למערכת ההפעלה האורחת משולבים מתורים למתאם ה-SCSI הווירטואלי ולדיסק הווירטואלי:
התור ל-HBA תלוי בסוג/ספק הספציפי:
הביצועים הסופיים של המכונה הוירטואלית ייקבעו לפי מגבלת עומק התורים הנמוכה ביותר מבין רכיבי המארח.
הודות לערכים אלו, אנו יכולים להעריך את מדדי הביצועים שאנו יכולים לקבל בתצורה מסוימת. לדוגמה, אנו רוצים לדעת את הביצועים התיאורטיים של מכונה וירטואלית (ללא כריכת בלוק) עם חביון של 0.5ms. אז ה-IOPS שלו = (1,000/איחור) * I/Os יוצאים מהכלל (מגבלת עומק תור)
דוגמאות
דוגמא 1
- מתאם FC Emulex HBA
- VM אחד לכל מאגר נתונים
- מתאם SCSI Paravirtual של VMware
כאן מגבלת עומק התור נקבעת על ידי Emulex HBA. לכן IOPS = (1000/0.5)*32 = 64K
דוגמא 2
- מתאם תוכנה iSCSI של VMware
- VM אחד לכל מאגר נתונים
- מתאם SCSI Paravirtual של VMware
כאן מגבלת עומק התורים כבר נקבעת על ידי מתאם SCSI Paravirtual. לכן IOPS = (1000/0.5)*64 = 128K
דגמים מובילים של כל מערכי Flash AccelStor (לדוגמה, ) מסוגלים לספק ביצועי כתיבה של 700K IOPS בבלוק 4K. עם גודל בלוק כזה, די ברור שמכונה וירטואלית אחת אינה מסוגלת לטעון מערך כזה. כדי לעשות זאת, תזדקק ל-11 (לדוגמה 1) או 6 (לדוגמה 2) מכונות וירטואליות.
כתוצאה מכך, עם תצורה נכונה של כל הרכיבים המתוארים של מרכז נתונים וירטואלי, אתה יכול לקבל תוצאות מרשימות מאוד מבחינת ביצועים.
4K אקראי, 70% קריאה/30% כתיבה
למעשה, העולם האמיתי הוא הרבה יותר מורכב ממה שניתן לתאר אותו בנוסחה פשוטה. מארח אחד מארח תמיד מספר מכונות וירטואליות עם תצורות ודרישות IO שונות. ועיבוד I/O מטופל על ידי המעבד המארח, שהכוח שלו אינו אינסופי. אז, כדי לנצל את מלוא הפוטנציאל של אותו הדבר במציאות, תצטרך שלושה מארחים. בנוסף, אפליקציות הפועלות בתוך מכונות וירטואליות מבצעות התאמות משלהן. לכן, עבור גודל מדויק אנו מציעים כל מערכי הפלאש בתוך התשתית של הלקוח על משימות שוטפות אמיתיות.
מקור: www.habr.com