סמנכ"ל מהיר באחסון Unity: איך זה עובד

היום נדבר על טכנולוגיה מעניינת המיושמת במערכות אחסון Unity/Unity XT - FAST VP. אם זו הפעם הראשונה שאתה שומע על Unity, אז אתה יכול לבדוק את מאפייני המערכת באמצעות הקישור בסוף המאמר. עבדתי על FAST VP בצוות הפרויקט של Dell EMC במשך יותר משנה. היום אני רוצה לדבר על הטכנולוגיה הזו ביתר פירוט ולחשוף כמה פרטים על היישום שלה. כמובן, רק כאלו שמותר להיחשף. אם אתה מעוניין בבעיות של אחסון נתונים יעיל או פשוט לא הבנת את התיעוד במלואו, מאמר זה בהחלט יהיה שימושי ומעניין.

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

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

FAST VP ראשי תיבות של Fully Automated Storage Tiering for Virtual Pool. קצת קשה? אין בעיה, נבין את זה עכשיו. שכבות היא דרך לארגן את אחסון הנתונים שבה ישנן מספר רמות (שכבות) שבהן הנתונים הללו מאוחסנים. לכל אחד יש מאפיינים משלו. הכי חשוב: ביצועים, נפח ומחיר אחסון יחידת מידע. כמובן שיש קשר ביניהם.

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

עכשיו בואו נסתכל על התכונות של הטמעת שכבות אחסון ב-Unity. ל-Unity יש 3 רמות, או שכבה:

• ביצועים קיצוניים (SSD)
• ביצועים (SAS HDD 10k/15k RPM)
• קיבולת (NL-SAS HDD 7200 RPM)

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

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

למה אני צריך Tiering?

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

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

• דורש זמן ותשומת לב של המנהל;
• לא תמיד ניתן "למשוך מחדש" משאבי אחסון כדי שיתאימו לתנאים משתנים;
• יתרון חשוב נעלם: גישה אחידה למשאבים הממוקמים ברמות אחסון שונות.

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

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

בעיות נפתרו על ידי סמנכ"ל FAST

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

• הפצת נתונים על סוגים שונים של דיסקים, רמות
• הפצת נתונים בין דיסקים מאותו סוג
• הפצת נתונים בעת הרחבת המאגר

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

כיצד סמנכ"ל FAST מקצה נתונים למאגר. פוליטיקאים

כדי לשלוט במיקום הנתונים במאגר עם FAST VP מופעל, המדיניות הבאה קיימת:

• הרמה הכי זמינה
• דרג אוטומטי
• התחל גבוה ואז רמה אוטומטית (ברירת מחדל)
• השכבה הנמוכה ביותר הזמינה

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

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

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

קריטריונים שבהם משתמש Fast VP בעבודתו

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

לפונקציית חישוב הטמפרטורה יש את המאפיינים הבאים:

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

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

אבל בואו נחזור למשימות. אז אנחנו יכולים להתחיל לנתח מה נעשה כדי לפתור בעיות של FAST VP.

א. הפצת נתונים על פני סוגי דיסקים שונים, רמות

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

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

ב. חלוקת נתונים בין דיסקים מאותו סוג

זכור, בהתחלה כתבתי את אמצעי האחסון מ אחד או יותר רמות משולבות לבריכה אחת? במקרה של רמה אחת, ל-FAST VP יש גם עבודה לעשות. כדי להגיע לביצועים מקסימליים בכל רמה, רצוי לפזר נתונים באופן שווה בין דיסקים. זה יאפשר לך (בתיאוריה) לקבל את הכמות המקסימלית של IOPS. נתונים בתוך קבוצת RAID יכולים להיחשב מופצים באופן שווה בין דיסקים, אך זה לא תמיד המקרה בין קבוצות RAID. במקרה של חוסר איזון, FAST VP יעביר נתונים בין קבוצות RAID ביחס לנפח ול"ביצועים מותנים" שלהן (במונחים מספריים). לשם הבהירות, אראה תוכנית איזון מחדש בין שלוש קבוצות RAID:

ב. חלוקת נתונים בעת הרחבת המאגר

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

פילוס שחיקה של SSD

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

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

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

כמה עצות

1. אל תזניח את קריאת התיעוד. ישנן שיטות עבודה מומלצות, והן עובדות די טוב. אם אתה עוקב אחריהם, אז, ככלל, לא מתעוררות בעיות רציניות. שאר העצות בעצם חוזרות או משלימות אותן.
2. אם הגדרת והפעלת את FAST VP, עדיף להשאיר אותו מופעל. תן לו להפיץ את הנתונים בזמן המוקצב לו ולאט לאט מפעם בשנה ולהשפיע בצורה רצינית על ביצוע משימות אחרות. במקרים כאלה, הפצת הנתונים מחדש עשויה להימשך זמן רב.
3. היזהר בבחירת חלון רילוקיישן. למרות שזה ברור, נסו לבחור זמן עם הכי פחות עומס על Unity והקצו פרק זמן מספיק.
4. תכנן להרחיב את מערכת האחסון שלך, עשה זאת בזמן. זוהי המלצה כללית שחשובה גם עבור FAST VP. אם כמות השטח הפנוי קטנה מאוד, תנועת הנתונים תאט או תהפוך לבלתי אפשרית. במיוחד אם הזנחת את נקודה 2.
5. כאשר מרחיבים מאגר עם FAST VP מופעל, לא כדאי להתחיל עם הדיסקים האיטיים ביותר. כלומר, או שנוסיף את כל קבוצות ה-RAID המתוכננות בבת אחת, או נוסיף קודם את הדיסקים המהירים ביותר. במקרה זה, הפצה מחדש של נתונים לדיסקים "מהירים" חדשים תגביר את המהירות הכוללת של הבריכה. אחרת, התחלה עם דיסקים "איטיים" עלולה להוביל למצב מאוד לא נעים. ראשית, הנתונים יועברו לדיסקים חדשים ואיטיים יחסית, ולאחר מכן, כאשר יתווספו מהירים יותר, בכיוון ההפוך. יש כאן ניואנסים הקשורים לפוליסות שונות של FAST VP, אבל באופן כללי, מצב דומה אפשרי.

אם אתה מסתכל על מוצר זה, אתה יכול לנסות את Unity בחינם על ידי הורדת מכשיר וירטואלי Unity VSA.

בסוף החומר, אני חולק כמה קישורים שימושיים:

• עמוד מערכת אחסון Unity
• Dell EMC Unity: FAST VP Theory of Operation - תיאור קצר של הפונקציה
• תיאור מלא ומפורט יותר, פורמט pdf
• מהדורת Unity VSA/Cloud

מסקנה

הייתי רוצה לכתוב על הרבה, אבל אני מבין שלא כל הפרטים יעניינו את הקורא. לדוגמה, אתה יכול לדבר בפירוט רב יותר על הקריטריונים שלפיהם FAST VP מקבל החלטות לגבי העברת נתונים, על תהליכי ניתוח סטטיסטיקות I/O. כמו כן, נושא האינטראקציה עם בריכות דינמיות, וזה ראוי למאמר נפרד. אתה יכול אפילו לפנטז על פיתוח הטכנולוגיה הזו. אני מקווה שזה לא היה משעמם ולא שיעממתי אותך. נתראה שוב!

מקור: www.habr.com