בניית מכונות VM בעולם החדש

תחום הקונטיינרים קיבל בשנים האחרונות דחיפה רצינית תודות לפתרונות כמו Docker, OpenShift, Kubernetes ומערכות רבות נוספות, ואחד הדברים הראשונים שכל מי שנכנס לעולם הקונטיינרים לומד הוא שקונטיינרים זה דבר זמני – אתה מפעיל, מכבה, וכל התוכן שבקונטיינר עצמו – נעלם, ולכן משתמשים בפונקציות כמו Volume (במערכות כמו Kubernetes יש לנו את PV/PVC) כדי למפות משאב חיצוני (כמו תיקייה במכונה) אל קונטיינר ושם יאוחסן המידע, כך שגם אם הקונטיינר נמחק, ה-DATA נשאר.

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

הדבר שאני מדבר עליו – חלוקה.

נניח ואנחנו צריכים VM שיתן לנו שרות מסוים. נניח SQL, שרת Web, שרת GIT, ועוד ועוד, כל דבר שנותן לנו שרות. ברוב המקרים שאני ראיתי – מקימים VM, מתקינים עליו את מערכת ההפעלה הרצויה ואת האפליקציה שתתן לנו את השרות הרצוי. היכן יאוכסן ה-DATA שאותו אפליקציה תנגיש? בתוך ה-VM. אחרי הכל – תמיד אפשר להגדיל דיסקים וירטואליים, זכרון וכו’.

אבל הבעיה הכי גדולה במכונות VM כאלו שבונים – קשורה לשחזור נתונים. נניח שהקמנו שרת Gitlab או שרת שליSQL או שרת SQL וכל הזמן זורמים אליו נתונים חדשים ועדכוני נתונים. לפתע מכונת ה-VM מפסיקה לפעול או שיש תקלה שיקח זמן לתקן אותה. מכיוון שזו מכונת VM, בדרך כלל אפשר פשוט לשחזר אותה מגיבוי (או אם בוצע snapshot לאחרונה).

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

איך נמנעים? די פשוט: מתחילים להשתמש בשרותי ה-Network File שקיימים, דוגמאות:

• אם אנחנו מרימים שליSQL או SQL של מיקרוסופט על לינוקס, אפשר למפות את התיקיות DATA שהשרות נזקק להן – למפות ל-NFS Share (אם אתם מריצים SQL של מיקרוסופט על לינוקס עם NFS, ודאו כי מדובר ב-NFS 4.2 וה-mount צריך לכלול את הפרמטר nolock)
• אם אתם מרימים שרת אפליקציית GIT או שרת WEB – אפשר למפות ל-NFS את התיקיה שה-DATA עצמו (כמו קבצי php,html, גרפיקה וככו’) יאוחסן. כל מה שצריך זה פשוט ליצור בסטורג’ את ה-NFS Share ולבצע mount שיוגדר בקובץ fstab.
• ב-Windows נשתמש באותן שיטות, רק עם SMB במקום NFS.

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

אני מניח שיהיו לא מעט מתנגדים לשיטה (במיוחד מנהלי סטורג’ שפתאום מגיעים אליהם עם דרישות ליצור עוד ועוד NFS/CIFS Share) אך זו השיטה שבין כה תצטרכו להשתמש בה עם קונטיינרים בעתיד, ובסופו של יום – שיטה זו חוסכת זמן רב אם מכונה שנותנת שרות למשתמשים רבים נופלת באמצע היום ואין הרבה זמן לבדוק ולטפל בבעיה (במיוחד אם אין ידע מספק בחברה על התקלה ואיך לטפל בה), וזו בדיוק הסיבה שאני ממליץ לחברות ועסקים “להמיר” מכונות VM לעבוד בשיטה כזו ולחסוך זמן התאוששות. אגב, אחד המקומות שבהם גם תוכלו להשתמש בשיטה כזו היא בעננים ציבוריים (באמזון זהו שרות EFS שמספק NFS לכל ה-Instances שלך לדוגמא).

לסיכום: מכונות VM לא צריכות להיות “מפלצות VM” עם דיסקים בגדלים של מאות ג’יגה עד טרהבייטים. בדרך כלל אין צורך ש-VM מבוסס לינוקס לדוגמא יהיה בגודל של יותר מ-10-20 ג’יגהבייט. אם ה-VM נותן שרותים, אני ממליץ פשוט לאחסן את הנתונים לשרותים דרך NFS/CIFS, כך גם תקבלו מהירות read/write יותר גבוהה (דיסקים וירטואליים עדיין יותר איטיים בהשוואה ל-NFS “טבעי”, אגב), וגם כשתצטרכו לשחזר מ-snapshot או גיבוי, לא תצטרכו לדאוג לגבי עניין האם ה-DATA החשוב מעודכן.