אחסון בלוקים למכונות וירטואליות: התאמה, הגדרה וניטור

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

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

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

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

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

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

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

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

מצבי חיבור דיסקים: השוואת אפשרויות

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

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

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

כיצד אנו מתאימים ומגדירים אחסון בלוקים לעומס

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

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

  1. אוספים פרופיל עומס — אוספים סטטיסטיקה מההיפרוויזורים וממערכות האורח לאורך מחזור עבודה, ולא ליום אחד: היכן הזרימה יציבה, היכן יש פרצים קצרים, איזה כרך נסוג ראשון.
  2. מתאימים אחסון — משווים את הפרופיל לסוג הכרך ולרמת היתירות, פוסלים אפשרויות שמתאימות פורמלית בנפח אך לא יעמדו בשיאים.
  3. מתכננים תכנית כרכים — חלוקה לפי ייעוד, מערכת קבצים, פרמטרי עיגון, גיבויים וסדר יצירתם, כדי שלא יהיה צורך לעצור את הכרך.
  4. מגדירים ומחברים — מפעילים גישה מרובת נתיבים, קובעים מטמון ותור בהתאם לאופי העומס, בודקים שלאחר אתחול הצומת הכרכים נאספים אוטומטית.
  5. בודקים כשל — לפי הסדר מנתקים את הנתיב לאחסון, את הצומת, מחצית מהערוצים ורושמים כמה נמשך המיתוג והאם כתיבה הולכת לאיבוד.
  6. מקימים ניטור — התראות לפי השהיה, תפוסה, שחיקה ושגיאות קלט/פלט, כדי שההידרדרות תיראה לפני שהמשתמש יבחין בה.
  7. מוסרים נוהלים — תכנית פריסה, נהלים להרחבת כרך, שחזור והחלפת דיסק, סדר פעולות בעת תקלה — כמסמך שלפיו עובדת המשמרת התורנית.

מה הלקוח מקבל לידיו: תכניות, מדיניות, נהלים

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

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

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

מקרה בוחן: כיצד הסרנו ירידות ביצועי קלט/פלט באשכול וירטואליזציה

היכן איבדו קלט/פלט

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

בהתחלה הכול היה יציב, אך עם גידול מספר המכונות הופיעו ירידות קצרות: השהיית הקלט/פלט זינקה פי עשרות במהלך העתקת הלילה, הגירת צמתים ובנייה מחדש של מערכים. שיעור הפעולות שארוכות מסף היעד עלה מ-1–2% ל-15%, ומכונות בודדות נכנסו להמתנה לדיסק למשך דקות.

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

מה שינו וכיצד מדדו

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

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

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

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

במה שונה אחסון בלוקים מאחסון קבצים ומאחסון אובייקטים?

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

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

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

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

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

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

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

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

מה יקרה לכרך בעת אובדן צומת?

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

כיצד מתבצעת הגירה ללא השבתה?

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

האם ניתן לחבר אחסון קיים?

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

האם הצפנת כרכים תאט את העבודה?

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

נדון במשימה: נתאים מצב אחסון לעומס שלכם

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

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

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