הגדרת וירטואליזציית קונטיינרים LXC/LXD מקצה לקצה

היכן נשבר קונטיינר LXC ואיך מזהים זאת לפני התקלה

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

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

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

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

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

מה נותנת וירטואליזציית קונטיינרים מנוהלת על שרתים

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

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

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

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

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

השוואת מצבי בידוד: LXC, מכונות וירטואליות, ארגזי חול

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

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

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

סדר ההטמעה: מביקורת התשתית ועד מסירה לתפעול

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

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

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

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

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

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

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

מקרה בוחן: איך סילקנו את הבלגן של השרתים וקיצרנו את זמן ההשבתה

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

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

מה שינו

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

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

מה קיבלנו

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

מה עושים אם חלק מהשירותים כבר חיים במכונות וירטואליות?

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

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

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

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

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

ספקות טכניים לפני המעבר לקונטיינרים

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

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

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

מי ואיך מקבל גישה פנימה?

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

האם המערכת תשרוד כשל של צומת אחד?

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

נדון במשימה ונחזור עם הערכה ותוכנית הטמעה

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

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

בעקבות הדיון במשימה תקבלו:

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

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