אלמנטים בסיסיים של פלטפורמת הווירטואליזציה של Flash (FVP), חלק 2. שימוש בפלטפורמה או מערכת קבצים משלך | א-מערכות

אלמנטים בסיסיים של פלטפורמת הווירטואליזציה של Flash (FVP), חלק 2. שימוש בפלטפורמה או מערכת קבצים משלך

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

�דוע לא VMFS?
מערכות קבצים מספקות תכונות שאינן חובה ולעתים אף מתנגשות עם הדרישות של הפלטפורמה המעבדת קלט / פלט פעיל במכשירי פלאש. אחת הבעיות הגדולות ביותר בשימוש במערכת קבצים הדומה ל- VMFS במכשיר פלאש היא שהיא מותאמת למערכות אחסון של SAN ולדגמי ניהול הנתונים שלהן; סטיאם כתב מאמר על כך עבור ACM בזמן שעבד ב- VMware. לרוע המזל, זה הופך את מערכת הקבצים לכלי לא הולם למשימות FVP.

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

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

פעולות הבזק ברמה נמוכה
להלן דוגמה כיצד הכתיבה למכשירי פלאש שונה מהותית מהקלטות בכוננים קשיחים. פלאש לא יכול להחליף נתונים קיימים. ניתן לכתוב נתונים בזיכרון הבזק רק בעמוד ריק. תכונה של זיכרון פלאש היא שהקלטה יכולה להתבצע על ידי דפים, ומחיקה יכולה להיעשות רק בלוקים. ��הו עמוד ומה חסימה? פלאש מאחסן נתונים בתאים; תאים משולבים לדפים (4 KB); העמודים מקובצים לבלוקים. מרבית היצרנים משלבים 128 עמודים לגוש אחד. אם ברצונך למחוק את הדף, עליך למחוק את החסימה כולה. יש לשמור את כל הנתונים הדרושים מדפים אחרים במקום אחר. ידוע כי למכשירי פלאש יש מספר מוגבל של מחזורי כתיבה ומוח.

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

ניהול ללבוש
שימו לב, לשם הפשטות החלטתי להציג 9 עמודים בגוש אחד במקום 128 עמודים בכל בלוק.

נתחיל בתהליך ניהול הבלאי. בדוגמה זו, היישום כבר יצר את הנתונים והקליט אותם בעמודים A, B ו- C בגוש 1 (שלב 1). מגיעים נתונים חדשים (שלב 2) שנכתבים לדפים D, E ו- F. היישום מעדכן את הנתונים הקודמים (AC) ובמקום להשתמש בעמודים הקודמים, מכשיר הפלאש ממשיך להשתמש בעמודים החדשים. נתונים חדשים אלה מכונים A-1, B-1 ו- C-1. הפצת רשומות בצורה שווה ככל האפשר נקראת "ניהול בלאי." עמודים ישנים מסומנים כעת כפג תוקפם.

  עמודים ישנים מסומנים כעת כפג תוקפם

אוסף זבל וכניסה מרובה
בדוגמה זו, גוש א 'מלא, מה קורה אם נגמר לו השטח הזמין למשתמש להקלטה ומגיעים נתונים חדשים?

אוסף זבל וכניסה מרובה   בדוגמה זו, גוש א 'מלא, מה קורה אם נגמר לו השטח הזמין למשתמש להקלטה ומגיעים נתונים חדשים

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

איסוף האשפה בסדר, אך הכניסה המרובה המתרחשת במהלך פעולתו גורמת נזק משמעותי למכשירי הפלאש. על מנת להקליט 3 עמודים, על מכשיר הפלאש לקרוא 6 עמודים ולכתוב את 6 העמודים במקום אחר לפני שהוא יכול לכתוב נתונים חדשים. ואל תשכחו ממעגל המחיקה. ��ניח תרחיש בו הדיסק מלא, לאן נעביר (באופן זמני) את הנתונים לפני רישום נתונים חדשים? בתרשים שלי הוספתי את בלוק B לאפשרות זו. על מנת לעשות זאת במצב אמיתי (בעת השימוש במערכת הקבצים) עליכם להקצות שטח עודף ששמור על ידי הבזק של הבקר.

על מנת לעשות זאת במצב אמיתי (בעת השימוש במערכת הקבצים) עליכם להקצות שטח עודף ששמור על ידי הבזק של הבקר

עודף שטח
ניתן לשמור קיבולת פלאש לתהליכים המנוהלים על ידי בקר הבזק. זה יכול להיעשות הן על ידי יצרן מכשיר הפלאש והן על ידי המשתמש. לדוגמה, כשאתה קונה מאיץ PCIe של פלאש 160 GB, למעשה אתה מקבל כרטיס של 192 ג'יגה-בייט. 160 ג'יגה-בתים זמינים למשתמש ו -32 ג'יגה-בתים שמורים בנוסף לפעולות ברמת הבזק ברמת הבזק, כגון איסוף אשפה, תיקון שגיאות וקושחת בקר. כשאתה רוכש כונן SSD שאינו תעשייתי, בדרך כלל אתה מקבל מעט שטח עודף שמור. כשאתה מעצב התקן פלאש זה במערכת קבצים כלשהי, עליך להיות מודע לתכונות אלה, ואפשר להזמין מקום נוסף מחוץ לקיבולת הזמינה. אין כרגע המלצות קנה מידה סטנדרטיות, כך שעליך לעשות בחירות על סמך החוויה שלך. במקרה הגרוע ביותר, תמצא את עצמך עם דיסק מקוטע וה- SSD יצטרך להעביר נתונים כל הזמן כדי לכתוב חדשים. דמיין את הילדים משחקים תגית, רק דפוס התנועה קצת יותר מסובך.

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

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

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

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

אני מצטט את מנהל המוצר Bala שלנו: "האלגנטיות של המוצר, לדעתי, היא שהוא מבצע משימות בסיסיות, ולא דורש מהמשתמש פעולות חדשות או חריגות."

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

מאמר מקורי .

מאז 2016 פרש ה- FVP מהמכירה.

?דוע לא VMFS?
?הו עמוד ומה חסימה?
?ניח תרחיש בו הדיסק מלא, לאן נעביר (באופן זמני) את הנתונים לפני רישום נתונים חדשים?