הטמעת מטמון SSD במערכת האחסון QSAN XCubeSAN

טכנולוגיות לשיפור ביצועים המבוססות על שימוש בכונני SSD ובשימוש נרחב במערכות אחסון הומצאו זה מכבר. קודם כל, זה השימוש ב-SSD כשטח אחסון, שהוא 100% יעיל, אבל יקר. לכן, נעשה שימוש בטכנולוגיות מעייפות ושמירה במטמון, כאשר כונני SSD משמשים רק עבור הנתונים הפופולריים ביותר ("חמים"). שכבה טובה לתרחישים של שימוש ארוך טווח (ימים-שבועות) בנתונים "חמים". מטמון, להיפך, מיועד לשימוש לטווח קצר (דקות-שעות). שתי האפשרויות הללו מיושמות במערכת האחסון QSAN XCubeSAN. במאמר זה נבחן את היישום של האלגוריתם השני - שמירה במטמון SSD.

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

אינדיקציות לשימוש במטמון SSD לקריאה:

• הדומיננטיות של פעולות קריאה על פני פעולות כתיבה (אופייניות לרוב לבסיסי נתונים ויישומי אינטרנט);
• נוכחות של צוואר בקבוק בצורה של ביצועים של מערך הכוננים הקשיחים;
• כמות הנתונים הנדרשים קטנה מגודל מטמון ה-SSD.

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

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

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

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

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

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

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

• גודל בלוק (גודל בלוק מטמון) – 1/2/4 MB
• מספר הבקשות לקריאת בלוק כך שיועתק למטמון (סף אוכלוסין בקריאה) – 1..4
• מספר בקשות לכתיבת בלוק כך שיועתק למטמון (Pulate-on-Write Threshold) – 0..4

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

בהתחשב בעקרון הפעולה של מטמון ה-SSD, אנו יכולים להדגיש את הפעולות העיקריות כאשר עובדים איתו:

• קריאת נתונים כאשר הם לא נמצאים במטמון;
• קרא נתונים כאשר הם נמצאים במטמון;
• כתיבת נתונים בעת שימוש במטמון קריאה;
• כתיבת נתונים בעת שימוש במטמון קריאה + כתיבה.

קריאת נתונים כאשר הם לא נמצאים במטמון

1. בקשה מהמארח מגיעה לבקר;
2. מכיוון שהמבוקשים אינם נמצאים במטמון ה-SSD, הם נקראים מהכוננים הקשיחים;
3. נתוני הקריאה נשלחים למארח. במקביל, מתבצעת בדיקה כדי לראות אם הבלוקים הללו "חמים";
4. אם כן, אז הם מועתקים למטמון ה-SSD לשימוש נוסף.

קרא נתונים כאשר הם נמצאים במטמון

1. בקשה מהמארח מגיעה לבקר;
2. מכיוון שהנתונים המבוקשים נמצאים במטמון ה-SSD, הם נקראים משם;
3. נתוני הקריאה נשלחים למארח.

כתיבת נתונים בעת שימוש במטמון קריאה

1. בקשת כתיבה מהמארח מגיעה לבקר;
2. נתונים נכתבים לכוננים קשיחים;
3. תגובה המציינת הקלטה מוצלחת מוחזרת למארח;
4. במקביל, נבדק האם הבלוק "חם" (מושווה את הפרמטר Populate-on-Write Threshold). אם כן, הוא מועתק למטמון ה-SSD לשימוש מאוחר יותר.

כתיבת נתונים בעת שימוש במטמון קריאה+כתיבה

1. בקשת כתיבה מהמארח מגיעה לבקר;
2. הנתונים נכתבים למטמון ה-SSD;
3. תגובה המציינת הקלטה מוצלחת מוחזרת למארח;
4. נתונים ממטמון ה-SSD נכתבים לכוננים קשיחים ברקע;

צ'ק בפעולה

עמדת מבחן

2 שרתים (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) מחוברים על ידי שתי יציאות דרך Fibre Channel 16G ישירות למערכת האחסון XCubeSAN XS5224D (16GB RAM/בקר).

השתמשנו ב-16 x Seagate Constellation ES, ST500NM0001, 500GB, SAS 6Gb/s, בשילוב RAID5 (15+1), עבור מערך הנתונים ו-8 x HGST Ultrastar SSD800MH.B, HUSMH8010BSS200, 100GB/SAS קבצים כ-12GB, SAS

נוצרו 2 כרכים: אחד לכל שרת.

בדיקה 1. מטמון SSD לקריאה בלבד מ-1-8 כונני SSD

מטמון SSD

• סוג קלט/פלט: התאמה אישית
• גודל בלוק מטמון: 4MB
• סף אוכלוסין בקריאה: 1
• סף אוכלוסין בכתיבה: 0

דפוס I/O

• כלי: IOmeter V1.1.0
• עובדים: 1
• מצטיינים (עומק תור): 128
• מפרטי גישה: 4KB, 100% קריאה, 100% אקראי

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

בדוק 2. מטמון SSD במצב קריאה + כתיבה עם 2-8 SSDs

מטמון SSD

• סוג קלט/פלט: התאמה אישית
• גודל בלוק מטמון: 4MB
• סף אוכלוסין בקריאה: 1
• סף אוכלוסין בכתיבה: 1

דפוס I/O

• כלי: IOmeter V1.1.0
• עובדים: 1
• מצטיינים (עומק תור): 128
• מפרטי גישה: 4KB, 100% כתיבה, 100% אקראי

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

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

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

מבחן 3. אמולציית מסד נתונים

מטמון SSD

• סוג קלט/פלט: מסד נתונים
• גודל בלוק מטמון: 1MB
• סף אוכלוסין בקריאה: 2
• סף אוכלוסין בכתיבה: 1

דפוס I/O

• כלי: IOmeter V1.1.0
• עובדים: 1
• מצטיינים (עומק תור): 128
• מפרטי גישה: 8KB, 67% קריאה, 100% אקראי

פסק דין

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

מקור: www.habr.com