הגברת מהירות פלש דיסק ע”י אמצעים חיצוניים – הקבלת פעילות בתצורת RAID, שיקולי מערכת הקבצים ומערכת ההפעלה.
הצגנו במאמר הקודם משמעויות ואיכויות של מהירות הכתיבה והקריאה ליחדיות זכרון המבוססות על רכיבי פלש, וראינו כי קיימים מספר פרמטרים המשפיעים באופן משמעותי על נתונים אילו. בחלקם פרמטרים קבועים המושפעים מתצורת הפעילות מול הפלש ובחלקם, פרמטרים משתנים התלויים גם במבנה פתרון הפלש-דיסק וגם בזמן העבודה של הפלש.
מעבר לכך השאיפה הבסיסית לעמוד בביצועי מהירות גבוהים יכולה להיפתר ע”י מימוש בחומרה חיצונית. כל תוספת או תצורת פתרון שתגרום להגברת מהירות הכתיבה הינה כשרה כל עוד אינה פוגעת בזמינות הפתרון לכל מערכת שבה נרצה לממשה. נראה כי פתרון ה- RAID עליו אדבר במאמר זה הינו חביב המהנדסים מזה שנים, אך קיימים תנאים במימושו עבור פלש-דיסקים, כגון אי-התלות בחומרת המחשב/המעבד ואי תלות במערכת ההפעלה. כמובן שלא נדלג על הדרישות הבסיסיות כגון – עמידה בתנאי סביבה, צריכת הספק נמוכה, תוספת או אי-פגיעה ביתירות המערכת.
הפתרון הגנרי מבוסס על עיקרון שלRAID 0 (RAID=Redundant Array of Independent Drives ). הרעיון הוא שהמידע מחולק לפרגמנטים (חלקי מידע), שמספרם נקבע לפי מספר הדיסקים במערכת. הפרגמנטים נכתבים בו זמנית לאותו הסקטור על הדיסק המתאים, וכך ניתן לקרוא מידע בצורה מקבילית מכל הדיסקים ולהגיע לרוחב פס גבוה. החיסרון בתצורה שכזו היא שבמקרה שדיסק אחד נפגם שאר המידע בדיסקים שאינם פגומים הופך לחסר משמעות. ניתן לפתור זאת ע”י שימוש בשילוב של טכניקת RAID 1 ובהכפלת מספר הדיסקים – תצורה כזאת נקראת גם RAID 1+0, יכולה לעמוד בפגיעה של מספר דיסקים מבלי לפגוע במידע. (מינימום 4 דיסקים עם אפשרות פגיעה של 2 דיסקים).
מניסיוננו, גודל הבלוק משפיע מאוד על הביצועים בזיכרונות Flash בניגוד לדיסקים המגנטיים. המהירות בתיחולים מסוימים יכולה לרדת עד כדי מחצית המהירות לפלש-דיסק או למהירות של פלש-דיסק בודד בתצורה של RAID 0, ולכן עלינו לתחל בגודל המתאים את בלוק הקריאה / כתיבה. בבדיקות שלנו בלוקים בגודל של 16MByte נתנו את התוצאות הטובות ביותר. (מדיות שונות של פלש יכולות להציע תוצאות טובות עבור גדלי בלוקים שונים ולכם המספר 16MByte אינו מספר קסם). כדאי גם לזכור שכאשר מבצעים בדיקות מהירות יש להעביר כמות גדולה דיה של מידע (כמה מאות MB לפחות בכל מחזור), כיוון שישנם מנגנוני cash במערכת ההפעלה. בזיכרונות הפלש ממומשים buffer-ים של cash גדולים וניתן לקבל תוצאות פנטסטיות אפילו עבור כמות בינונית של מידע. נקודה נוספת היא שבבדיקות שערכנו, בניית Software RAID 0 של Windows עם Flash disks הניבה תוצאה נמוכה בכ 30 % מבנייה של Software RAID 0 במערכת Linux. המענין הוא שפתרון חומרתי של RAID 0 לא תמיד מבטיח את התוצאות הטובות ביותר מבחינת מהירות כיוון שפתרון זה לא תמיד יוצר צורת הפעלה אופטימאלית עבור הפלש-דיסק.
להלן סכמות אופייניות לשיפור מהירויות ואמינות בהתקני זכרון מבוססי פלאש:
פתרון א’ – בניית RAID 0 על גבי מספר דיסקים. לדוגמא אם לכל דיסק מהירות של 40Mbyte/sec אזי עם 4 דיסקים ניתן להגיע למהירות מקסימלית תאורטית של 160MByte/sec. (בפועל נקבל בין Mbyte/sec 130-150.
פתרון ב’ – להשתמש בזיכרונות DDR כ-Ram Disk. נפיצות זיכרונות DDR מביאים לירידה מתמדת במחירם, כיום כמות מקבילה של זיכרון פלאש מהיר זולה יותר מ-DDR. בתצורה זו משמש ה- Ram Disk כבפר אחסון זמני המציע מהירויות גבוהות בהרבה מזכרון הפלש ומגיע בכתיבה/קריאה לסדרי גודל של כמה ג”ב לשניה. בתצורה זו המידע נכתב/נקרא קודם ל- Ram Disk ולאחר מכן מועתק לפלאש דיסק. יש לשם לב שבפתרון זה נקבל מהירויות גדולות מאד של העברת המידע אך אילו יהיו מהירויות Burst ולכן יש לבחור גודל DDR מתאים ע”פ גודל הבלוקים הגדולים ביותר של המידע שלנו. במימוש נכון, ניתן להגיע למהירויות פנטסטיות שכן מהירות של זיכרון DDR2-6400 לדוגמא, מגיע ל 6.4GByte/sec. כ”כ יש לזכור שעלינו לבצע מחזור אחרון של העברה המידע לפלש לפני כיבוי המערכת ונדרש זמן כיבוי והתראה מספיק ארוך על מנת שנספיק לבצע פעילות זו.
פתרון ג’ – פיתרון משולב – לבנות RAID 0 עם הפלש דיסק ו – Ram Disk (המבוסס על DDR2 לדוגמא) . כך גם ניתן להכפיל את מהירות התעבורה תוך שימוש אקטיבי רק בחצי מכמות הדיסקים שבפיתרון הקודם ולחסוך גם בשחיקה של הפלאש דיסק כתוצאה מפעילות כתיבה. אך גם בפיתרון זה לפני כיבוי המערכת, יש להעתיק את המידע שב Ram Disk לפלאש-דיסק גיבוי (מופיע באיור ב-Backup Fragment 2).
פתרון ד’ – קיימים עוד אופני עבודה בתצורות RAID כגון – RAID 2, 3, 4, 5, 6, 10 וכו’. כל תצורות ה-RAID בין 2 ל-5 כוללות יתירות מידע מורחבת, מציגות ביצועים משופרים ביחס לדיסק בודד ועלותם הינה בין 30% ל- 100% תוספת משטחי מידע=תוספת דיסקים. RAID 10 הינו שילוב של RAID 0 ו- RAID 1 ובעצם שילוב של מהירות=Stripping ויתירות מלאה=Mirror. לא נרחיב במאמר זה נושאים אילו.
נזכור כי לא כל ארכיטקטורת מעבד תתמוך בפתרון RAID וגם יצרן פלש-דיסק המצהיר על מהירויות גבוהות של הדיסק מציג בעצם יישום תצורת RAID פנימית בתוך הפלש-דיסק. עלינו לאמת שנוכל ליישם פלש-דיסק זה במערכת שלנו.
שקולים נוספים – מערכת ההפעלה ומערכת הקבצים:
עבודה תחת מערכת קבצים: כל פתרון חייב להביא בחשבון את השפעת מערכת הקבצים על המהירות ואופי זרימת המידע. מערכות קבצים מוכרות: FAT16/32, NTFS, Ext2, Ext3, Ext4, UFS, Reiser4(lzo), JFS ועוד. מבין אילו, הפגינה מערכת הקבצים Reiser4(lzo) מהירות גבוה פי 4 מ-NTFS. מרתק לדעת כי מערכת קבצים זו נצלה כשליש משטח הדיסק על מנת לשמור את אותה כמות מידע (לעומת השטח שנדרש עבור NTFS). (תוכנת הבדיקה: Bonnie++ Version 1.93c). חשוב לדעת כי אין אנו מחוייבים לעבוד תחת מערכת קבצים ונוכחנו כבר בכמה אפליקציות שהציגו פתרון זה עם מהירויות ביצוע משופרות משמעותית לעומת הפתרון שכלל מערכת קבצים.
עבודה ללא מערכת קבצים: איך ? הייתכן ?! ממש כן ! לא יעלה בדעתנו להציג פתרון כזה אלמלא הדיסקים הינם פלש-דיסקים. איך נוכל לאשר פתרון ללא הגנה מידע – אותה הגנה המציעה מערכת הקבצים. כאן לעזרתינו הגדרת היסוד של פלש דיסק: זוהיא מדיה המאופיינת ע”י 100% מידע תקין בכל רגע. כלומר – המדיה = פתרון פלש דיסק מציע בכל רגע נתון 100% נכונות המידע הנכתב/נראה וזאת מעצם צורת יישום הפלשים יחד עם חומרה ואלרגוריתמים מתאימים. קיימות כבר כמה אפליקציות וברובם גם בתחום הצבאי אוויוני המנצלים איכות זו של הפלש-דיסקים ליישום המידע ללא מערכת קבצים. אבל מדוע – נראה בבדיקות כי יישום ללא מערכת קבצים – כתיבת Row Data לפלש-דיסק מציג מהירויות משופרות עד כדי 30% לעומת שימוש במערכת קבצים.
מערכת ההפעלה: אופן הפתרון של מערכת ההפעלה מגדיר, עבור חלק ממערכות ההפעלה, עבודה עם וללא מערכת הקבצים. אם נתעלם לרגע ממערכת הקבצים נראה כי מערכות ההפעלה מציגות פרמטרים של מהירות, זמן-אמת, גודל בלוקים ו-caching בהתייחס לכתיבה/קריאה לדיסק. מערכות הפעלה כדוגמת Windows יכולות להציג מהירויות של מאות מ”ב לשניה ללא כל תלות בתצורת הפתרון החומרתי של המדיה=פלש דיסק. הפרמטרים העיקריים במערכת ההפעלה הם :
• זמן-אמת – אותם מערכות הפעלה המתנהגות בזמן-אמת מפעילות תכונה זו גם בהתייחס לפעילות מול הדיסקים. הכתיבה לדיסק, תגובת מערכת ההפעלה לפסיקת הדרייבר (מול הדיסק) הינה בזמן-אמת=בזמן דיסקרטי. תוצר המהירות הנגזר מפרמטר זה אינו משמעותי במעבר מקבצי מידע גדולים אך משמעותי בתזמון כתיבת המידע לדיסק. מערכת הנדרשת להציג פתרון כולל של מעבר מידע רציף במהירות גבוהה חייבת לעבוד באופן Real-Time עקב מגבלות החוצצים=buffers של הדרייבר ושל ה-RAM/DDR הכללי העומד לרשותה. דוגמה למערכות הפעלה אילו: Linux-RT (קיימום כמה מהדורות), VxWorks, Integrity ועוד. חשוב לציין כי מערכות ההפעלה הפופולריות Linux ו- Windows אינם מערכות הפעלה זמן-אמת.
• גודל בלוקים – פרמטר משמעותי לגבי תוצאת מהירות הכתיבה/קריאה לדיסק. דרייברים של מערכת ההפעלה משתמשים בחוצצים תוכנתיים וחומרתיים המגדירים גודל חוצץ=Buffer מסויים. במידה ונבחר לבצע פעולות כתיבה החורגות ממחזור הפעולה של הדרייבר נפסיד באופטימאליות מהירות הנתונים לדיסק.
• Cache – כמעט ולא ידוע לבוני הפתרונות, אך כמעט בכל מערכת הפעלה קיים “זכרון-מטמון”=Cache שהינו בעצם חוצץ-Buffer נוסף הקולט מידע בדרכו לדיסק. חוצץ זה מטרתו לסנכרן את פעילות הכתיבה (במקרה זה לדיסק) עם שאר פעילויות מערכת ההפעלה, עם החוצץ החומרתי ותיזמון פעילות הדרייבר. במקרה בו נידע את נתוני מטמון זה נוכל לנצלו לצורכנו ולשפר (לא לקלקל) את מהירות המידע לדיסק. פרמטר נוסף שיש להביא בחשבון הינו הבטחת מערכת ההפעלה לסיים פעילות מול הדיסק בזמן נפילת חשמל. מערכת הפעלה השומרת מטלות כאילו בהיקף מידע נכבד, תכשל ברגע קריטי זה וגם אם נפקוד פעילות זו (דוגמת sync בלינקס) לא מובטח לנו כי כל המידע נכתב לפני נפילת החשמל.
כמו שניתן לראות על מנת להגיע לביצועים מיטביים יש צורך הרבה ידע סביב הזיכרון. זיכרון הוא אחד התחומים הקרדינליים והמתוחכמים ביותר בכל מערכת, ולשם השגת ביצועים אופטימליים, כמעט תמיד יש להעזר במומחה לזיכרון FLASH.
במאמרים הבאים נסקור תלויות מערכת ההפעלה והאפליקציה בחומרות הנוספות המלוות את הפתרון. החומרה המלווה את הפתרון אינה רק מעבד=CPU אלא גם ChipSet, בקרי דיסקים, בקרי RAID, אפיקי קישור לבקרים ומרחק פיזי בין המחשב/מעבד לבין מערך הדיסקים. נושא נוסף הקשור לחדשנות הטכנית הינו טכנולוגיות חדשות לרכיבי זכרון בילתי נדיף. רכיבים אילו יציגו בעוד כשנתיים נפחי זכרון אדירים יחד עם מהירויות משופרות משמעותית וצריכת חשמל נמוכה מאד. טכנולוגיות אילו נמצאות כעת בפיתוח וסיליקון ראשון (מעבדתי) כבר קיים.
Asine Ltd, Asine Group – All Rights reserved 2009
