קטגוריה: וירטואליזציה

העתיד: דיסקים, Storage ו-NVME-OF

כשזה מגיע לעולם הטכנולוגיות של דיסקים קשיחים, אפשר לאמר שהטכנולוגיה קפצה אחורה ואז זינקה קדימה. תשאלו כל מנהל IT לגבי רכישות דיסקים – כשזה היה קשור לדיסקים מכניים, ברוב מוחלט של המקרים התנאי הראשון לדיסקים היה שהם יעבדו ב-SAS. מה לגבי דיסקים SATA? זה רק למקרים שאין צורך במהירות, שמדובר על שרתים קטנים, אולי NAS קטן לאיזה פרויקט או מחלקה, דברים כאלו.

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

התשובה: במקרים של דיסקים מכניים – בהחלט. במקרים של SSD – זה יוצא ההיפך. קחו דיסק SSD בחיבור SATA ותקבלו לדוגמא מהירות קריאה של 550 מגהבייט לשניה. לזה, שום SAS לא הגיע עם דיסקים מכניים (אלא אם מכניסים את ה-Cache של הבקר אבל זה יפה במבחנים, לא לעבודה במציאות) וכך עולם הדיסקים חזר "אחורה" ל-SATA ופורמט ה-SAS די "מת" למרות מאמצים מצד יצרני בקרים ושרתים להוציא (מאוחר מדי, LSI היו הראשונים להוציא מוצרים ב-2013) את SAS-12G, וכך המצב בשנתיים האחרונות בשוק הוא שדיסקים SSD קיימים בגירסאות SATA בלבד – אבל הדיסקים עצמם מכילים את כל תכונות ה-Enterprise כמו תיקון תקלות אוטומטי, שמירת מידע עצמאית בעת הפסקת חשמל, שרידות גבוהה בעבודות כבדות ועוד.

דיסקים SSD מבוססים SATA מאפשרים לחברות להמשיך לעבוד כאילו הם עובדים עם דיסקים מכניים או דיסקים SSD ישנים, ורבים נוטים עדיין לעשות את הטעות לעבוד כ-RAID-5,50,60 כשהם שוכחים 2 דברים מאוד חשובים:

ה-RAID-5 וה"אחים" שלו 50,60 ביצעו 2 דברים חשובים: נתנו ביצועים גבוהים הנובעים מעבודה עם ריבוי דיסקים וחלוקת העבודה בין הדיסקים, ושרידות יותר גבוהה מכיוון שאם הולך דיסק אחד או 2 (בהתאם לשלב ה-RAID) – המערכת היתה ניתנת לשיקום לאחר החלפת הדיסקים. עם SSD לעומת זאת (גירסת Enterprise!) הביצועים שהדיסקים האלו מוציאים די "חונקים" כל כרטיס רשת. תחשבו על כך: 2 דיסקים SSD ב-RAID-0 מוציאים מהירות תיאורתית של 1100 מגהבייט לשניה (בקריאה). נתרגם זאת לג'יגהביט ונקבל .. 8 ג'יגהביט, כלומר כרטיס רשת של 10 ג'יגהביט יהיה תפוס ב-80% בזמן שהוא משדר את ה-DATA מצמד הדיסקים, ושוב – אני מדבר על 2 דיסקים בלבד. אז מה בעצם נותן בקר דיסקים? ביצועים? יש כבר לדיסקים, לא צריך גם Cache. שרידות? ב-SSD ל-Enterprise יש יכולות הרבה יותר מרשימות של שרידות פנימית מאשר כמעט כל בקר RAID בשוק. ובכל זאת, חברות ממשיכות לעבוד כך. מדוע? אני חושב שזה עניין של הרגל.

בשנתיים האחרונות נכנסנו לעידן חדש של דיסקים SSD, מה שבהתחלה נקרא PCI SSD והיום פשוט נקרא NVME SSD. לדיסקים הללו לא תמצאו שום RAID כי הדיסק מחובר ישירות לתושבת PCIE X4 (בחיבור שנקרא כיום U.2, חלק מהיצרנים לצערי עדיין משתמשים בחיבור קנייני משלהם, לרווחתם של יצרני הדיסקים והשרתים, לצערם של הלקוחות ש"ננעלים" בכך שלא ניתן להכניס דיסקים יותר טובים מצד ג'). הדיסקים הללו כיחידות עצמאיות נותנות יותר ביצועים מכל מה שתשיג עם SSD ו-RAID, מהירויות של 2-4 ג'יגהבייט לשניה בקריאה ועד 2 ג'יגהבייט בכתיבה עם עשרות עד מאות אלפי IOPS (וכמובן את המילה האחרונה בשרידות, ושוב – שרידות הרבה יותר גבוהה מכל דיסק מכני שאתם מכירים) ושם כבר אין RAID (ואם רוצים RAID 0,1,10 – עושים זאת בתוכנה. הביצועים לא יהיו נמוכים יותר בהשוואה לבקר יעודי, האמינו לי, גם אם תנסו את זה על מעבד i5 פשוט [ניסיתי בעצמי מול בקר יוקרתי של LSI ]).

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

אם נסתכל מבחינת דיסקים, בשנה הנוכחית השוק מנסה להסתגל למצב חדש שבו יש הרבה יותר ביקוש מהיצע. דיסקים NVME SSD של 3-4 טרהבייט, גם אם תנפנף מול היצרן בכרטיס אשראי פלטיניום, תשלום מיידי או ערימת מזומנים – תיאלץ במקרים רבים לחכות וזה כרגע עדיין "מכה" ב-HP, DELL וגם ב-Lenovo. היצרנים נתפסו "במערומיהם" עם דרישות היסטריות לשבבי Flash מצד כל יצרני המחשבים והטלפונים. כולם רוצים שבבי NAND ועכשיו. יצרני השבבים גדלים (חברת TSMC לדוגמא, אחת החברות הגדולות ליצור שבבים – מתכננת בניה של FAB נוסף בסין בדיוק בשביל זה) ושבבי ה-3D NAND החדשים מאפשרים ליצור שבבים עם כמות אחסון יותר גדלה בליטוגרפיה בשיטות יותר "ישנות" כך שניתן פר Waffer ליצור יותר שבבים. שלבים אלו ואחרים יתורגמו לשחרור לחץ בשוק במהלך השנה שנתיים הקרובות.

אבל גם אם הבעיה תיפתר, נמצא את עצמנו בבעיה אחרת: בשביל ביצועים רציניים צריך NVME SSD וגם אם יש לך דיסקים חדשים וגדולים כאלו, איך בדיוק תשתמש בהם? זה לא שיש לך בקר RAID להגדיר Virtual Disk שעל זה אתה מתקין Windows, Linux, vSphere וכו'.. אפשר כמובן להוסיף דיסק קשיח כלשהו (ולהשתמש בבקר הפנימי כדי לבנות RAID-1 מדיסקים פשוטים) כדי להתקין את מערכת ההפעלה וכו', אבל הדבר הבא שהיצרנים ידחפו נקרא NVME-OF (זהירות, לינק לקובץ PDF). זהו הסטנדרט חדש שנבנה ע"י החברות שבנו את סטנדרט NVME, ועם הסטנדרט הזה אנחנו משתמשים בכמה מושגים שבוודאי שמעתם עליהם:

  • ה-AFA (כלומר All Flash Array) – מערכת סטורג' (או שרת) שבנוי כולו מדיסקים NVME SSD.
  • על מה נעביר את הנתונים? זוכרים ROCE? אז הוא חוזר לסיבוב נוסף, ולאלו שאוהבים לשפוך כסף כאילו אין מחר (בנקים, מכוני מחקר יוקרתיים וכו') – Infiniband.
  • ובאיזו שיטה? זוכרים iSCSI? אז נגזור משם את ה-Target ו-Initiator, שיהיה לכם חיים יותר קלים.
  • אבל מה עם כתובות IP וכו'? זה ישאר, רק שהפעם זה "נעקר" מה-OS ומועבר לביצוע ע"י כרטיס הרשת (כלומר TCP Offload).

עכשיו נשלב את הכל ביחד: נבנה שרת מבוסס Dual Xeon עם 128 ג'יגה (עדיף יותר, תלוי בכמות ה-Clients וכו') מבוסס לינוקס עם קרנל 4.8.7 ומעלה, עליו נרים מערכת שתהווה בעצם Target ובה ישבו לא רק הדיסקים אלא גם מספר כרטיסי רשת עם פס רחב (25 ג'יגה ומעלה או Infiniband). הכרטיסים יחוברו למתג תואם ומשם יחוברו לשאר השרתים שאנו מעוניינים. את חלוקת ה-Volumes וכו' נעשה על ה-Linux והמערכת בלינוקס תשדר זאת דרך ה-ROCE כבלוקים (אפשר עם שילוב TCP/IP, אפשר גם בלי אבל אז יתחילו הצרחות ממחלקת ה-IT) וה-Initiator בשרתים יתחבר ל-Target (יהיו גם אפשרויות אותנטיקציה, הצפנה וכו'). שרתים ישנים יוכלו להעלות את ה-Initiator לדוגמא דרך IPXE (או PXE לחובבי טכנולוגיה קלאסית) ומשם ה-OS יעלה ויקבל תמיכה מלאה כאילו מדובר בדיסקים מקומיים.

והביצועים? אם נשווה זאת לדיסקים NVME מקומיים, ההבדל יהיה באחוזים בודדים. מכיוון שכל השיטה מעיפה כל דבר שמוסיף Latency, הביצועים נראים כאילו מדובר בדיסקים מקומיים, רק שאין צורך לבצע תחזוקת דיסקים פר שרת והכל מבוצע ממקום אחד (ומנסיון, התחזוקה לא כזו מורכבת). סתם דוגמא: גם אם שפכתם כסף והפכתם את המערכת תקשורת שלכם ל-100 ג'יגהביט, תקבלו (במספר חיבורים במקביל) קצב של 93 ג'יגהביט בקריאה, ו-40 ג'יגהביט בכתיבה. עכשיו תנסו לדמיין מערכת VDI לאלפי משתמשים ואיך זה יעבוד, וכן – יש Initiators ללינוקס, Windows ול-VMWare כבר כיום.

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

לסיכום: דיברתי כאן על דיסקים SSD, על תקשורת שגבוהה בהרבה מ-10 ג'יגהביט, על NVME-OF (ממש על קצה המזלג). הטכנולוגיה קיימת כבר כיום (חברת Mellanox  כבר דוחפת ומדגימה אותה), אבל שום חברה לא עוברת מהיום למחר לטכנולוגיה חדשה שמצריכה החלפת מתגים וכרטיסי רשת ורכישה רצינית של NVME SSD ושרתים לכך. אלו דברים שלוקחים זמן, לפעמים שנים – אבל זהו הכיוון שהשוק ל-Data Center עובר אליו. חברות סטורג' רבות ישמחו למכור לכם את הפתרון לאחסון מחר בבוקר, אבל לפחות מבחינת TCO ו-ROI (ואם החברה מוכנה לאמץ מעט ראש פתוח) אני ממליץ לחשוב על פתרון בניה עצמית. הוא הרבה יותר קל ממה שרבים נוטים לחשוב (סתם דוגמא: הוא הרבה יותר קל מאשר הקמה וניהול של שרת ZFS) והוא פתרון שיכול להיות Scale Out די בקלות וזול בהרבה אם חושבים להרחיב – מאשר פתרון קנייני.

מוגש כחומר למחשבה 🙂

על דחיית פרוייקטים והמחיר הכרוך בכך

הנה משהו שקרה לי כעצמאי לא פעם ולא פעמיים (למען האמת, הפעם האחרונה זה קרה לי השבוע): חברת XYZ, חברה גדולה וידועה, רצתה לבצע פרויקט מיגרציה משיטות העבודה הקלאסיות שהיא עובדת עם הכלים הישנים – לכלים חדשים, לעבוד ב-Agile עם CI/CD, עם GIT ועוד.

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

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

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

כך לדוגמא, הגירסה הנוכחית של vSphere שקיימת כיום (6.5) ברמה העקרונית היא די זהה לגירסה 5 (יש כמובן שינויים מהותיים "מתחת למכסה" כמו תצורת דרייברים שהשתנתה מהותית החל מגירסה 6), אבל בגירסה 7 דברים יהיו ממש שונים, תהיה תמיכה לקונטיינרים ולעוד דברים, ואז הצעדים לביצוע אותו פרויקט, יכול להיות שיהיו שונים מהותית – אבל ניתן לבצע את הפרויקט, אם כי במחיר שונה.

לעומת זאת ישנם מקרים שהשינויים הם הרבה יותר מהותיים, במיוחד בכל מה שקשור לדברים חדשים כמו קונטיינרים ומיקרו-שרותים (וכן, יש הבדל בין שתיהם), הרעיון לעבור ממשהו יציב כמו VM (או "ברזל") לדבר שנוצר עבור הפעלת משהו מסויים ומת כעבור כמה שניות/דקות הוא דבר שונה מהותית והוא ללא ספק ימשיך להשתנות וישתנה ללא הכר במהלך השנה שנתיים הקרובות, כלומר כל PoC שיבוצע היום – לא יהיה שווה כלום אם העבודה תתבצע עוד שנתיים. סביר להניח שיהיו כלים ומתודות חדשות ויותר יעילות, צורת חשיבה שונה ודרישות אחרות מבחינת תשתית, תכנות וכו' וכו'. כל עניין קונטיינרים, מיקרו-שרותים, CI/CD וכו' מחייב התפתחות מתמדת, בניגוד לעבר שאם ידעת שפת תכנות מסויימת וידע על פלטפורמה מסויימת אז היית "מסודר" לעשור הקרוב לדוגמא.

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

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

לכן, במידה ובוחרים כל דבר שקשור לתשתיות, פלטפורמה, או כלי עבודה שונים, בין אם הם מבוססי קוד פתוח או סגור (ההמלצה שלי תמיד היא לעבוד עם כלי שמבוסס קוד פתוח) – היא לראות האם ב-Road Map של החברה יש שדרוגים ומעבר לטכנולוגיות ומתודות עדכניות. חברה כמו VMWare לדוגמא "פספסה מעט את הרכבת" בכל הקשור לקונטיינרים ו-OpenStack, אבל גירסה 7 שתצא בהמשך תתן יכולות להרצת קונטיינרים ותמשיך לשפר את ה-VMware Integrated OpenStack שלהם. גם חברה כמו Red Hat שהבינה שקונטיינרים הולכים להיות ה"בון טון" זרקה בגירסה 3 את כל הטכנולגיה של ה-Cartridges שלהם לטובת קונטיינרים וכיום הם מפתחים לגירסה הקרובה עבודה מלאה מול שרתי Windows Server 2016 ועושה את החיים הרבה יותר קלים לשימוש בפונקציות מסויימות ע"י אימוץ kompose.io לדוגמא. לעומת זאת, חברה מסויימת מאוד גדולה וידועה (שלא אציין את שמה אך כל איש IT מכיר אותה) מציגה את עצמה כחברה עם שרותי ענן "מתקדמים" וכל מה שמקבלים כשנרשמים – הם תשתיות כאילו אנחנו נמצאים בשנת 2010 (ולסקרנים מביניכם – לא, אינני מדבר על מיקרוסופט..)

לסיכום: מעבר לטכנולוגיות חדשות ומתודות חדשות מחייב שינוי ברמת החשיבה והביצוע לא רק ברמת המפתחים וראשי צוותים, אלא גם במהירות ההחלטה אצל בכירים. כיום השיטה של "עוד שנתיים נקנה פלטפורמת ABC ונשתמש בה" לא ממש עובדת יותר כי אם אותה פלטפורמה מתעדכנת תדיר, פלטפורמת ABC שיש כיום תהיה שונה מאוד בעתיד, ומי יודע אם בעתיד לא יהיה פתרון מתחרה יותר זול עם פונקציונאליות יותר טובה? לכן המלצתי היא להקים PoC ואם מרוצים – להתחיל להקים מערכת חדשה ולאט לאט להעביר אליה אפליקציות ומפתחים מבלי לזרוק את מערכות ה-Legacy (עדיין). הימור על רכישות עתידיות כיום – כבר אינו כה שווה לעניות דעתי.

מעבר לעננים – מבחינה כספית (מאמר עדכון)

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

בקשר לחלק השני של השאלה, התשובה הפשוטה ביותר היא לא. אם אתם משתמשים בסטורג' מסחרי, בוירטואליזציה מסחרית (VMWare, Hyper-V, Oracle VM Server) – עלויות המעבר לא רק שיהיו גבוהות, התשלום החודשי יהיה גבוה בהרבה ממה שאתם משלמים כיום. חישבו על כך: כל שרת וירטואלי עם 2 ליבות ומעלה, 8 ג'יגה זכרון ומעלה – יעלה לכם מאות דולרים בחודש ולא חשוב אצל איזה ספק ענן ציבורי תבחרו – ועוד לא דיברתי על עלות התקשורת החוצה, עלות הדיסק הקשיח הוירטואלי, עלות התקשורת בין ספק הענן למשרדכם וכמובן עלות התקשורת בין השרתים לבין הלקוחות.

כלומר המצב הקלאסי של היום מבחינת תשתית IT אינו מתאים כל כך למעבר לענן. אם אתם כמובן רק רוצים להעביר כמה מכונות VM בשביל אתרים שיווקיים ועוד כמה דברים שיכולים להיות "בחוץ" – אז אני ממליץ לכם לבחור ב-Digital Ocean (הנה קופון של 10$ מתנה להתחלה מבלי להתחייב). עם המכונות ב-Digital Ocean אינכם משלמים עבור תעבורה מעבר לשימוש רגיל (כל מכונה מגיעה עם כמות תעבורה חודשית מכובדת לכל הדעות), אתם יכולים להוסיף דיסק קשיח בגדלים שאתם רוצים, והמכונות די מהירות ויציבות ומה שהכי חשוב – המחיר ידוע לכם מראש, כך שסביר להניח שתוכלו להעביר חלק מהתשתית לשם ללא הפתעות כספיות.

לגבי שאר המכונות, אם רוצים להעביר לענן, הדבר הראשון עוד לפני שבכלל בוחרים ספק אינטרנט, הוא למדוד כמה משאבים האפליקציות באמת צריכות. נניח ויש לכם אפליקציית JAVA או דוט נט והגדרתם VM עם 2 ליבות ו-16 ג'יגהבייט זכרון. השתמשו בכלים הסטטיסטיים של הוירטואליזציה כדי "לחפור" בהיסטריה של אותו VM האם באמת יש שימוש ב-2 ליבות וב-16 ג'יגהבייט זכרון או שאולי מכונה זו לדוגמא יכולה להסתפק בליבה אחת ו-8 ג'יגהבייט זכרון.

דוגמא נוספת: אפליקציות כמו שרתי Web שפותחים עשרות או מאות תתי-תהליכים בהתאם לכמות החיבורים. נניח שבניתם שרת Web גדול שיקבל כמות גדולה של משתמשים כדי להפעיל אפליקציית Web שהם צריכים ויצרתם לכך 2 מכונות עם 8 ליבות וירטואליות ו-32 ג'יגהבייט זכרון בכל אחת מהמכונות. האם פתרון של 4 מכונות קטנות יותר (2 ליבות ו-8 ג'יגה זכרון) כשמאחוריהן עומד Load Balancer יהיה יעיל יותר? מבחינת עבודה בתשתית ענן, 4 מכונות קטנות עולות פחות מ-2 מכונות גדולות. באמזון לדוגמא, 4 מכונות בגודל כפי שתיארתי לעיל יעלו לכם $319 ואילו 2 מכונות גדולות כפי שתיארתי לעיל יעלו לכם $631, כלומר כמעט כפול (לא כולל דיסק, Snapshots, תעבורה וכו'). גם אם נגדיל ל-6 מכונות קטנות, עדיין המחיר יצא יותר זול מ-2 מכונות גדולות.

עוד נקודה קריטית לפני מעבר לענן היא הצורך לשנות את צורת העבודה כך שבעצם האפליקציה שתרוץ תהיה החשובה והשרת והתשתית יהיו פחות חשובים. כך לדוגמא אם יש לנו אפליקציה שצריכה לקבל כמות משתנה של משתמשים שהכמות קטנה בזמנים מסויימים ומאוד גדולה בזמנים אחרים – במקרים כאלו כדאי לחשוב על העברת האפליקציה לקונטיינרים ושימוש בתשתית קונטיינריזציה בענן (ECS באמזון, GKE בגוגל או OpenShift אם אתם רוצים להריץ משלכם משהו שיותר מתאים ל-Enterprise). בעזרת תשתית זו ניתן להוסיף אוטומטית קונטיינרים משוכפלים ומכונות נוספות (שיארחו את הקונטיינרים) וכמות הקונטיינרים והמכונות תרד אוטומטית בהתאם לכמות המשתמשים באותו זמן (כמובן שניתן להגביל את כמות המכונות שיתווספו, אם לדוגמא משהו קורה שיוצר תעבורה מזוייפת, עקב תקלות וכו'). לאלו שלא רוצים קונטיינרים או לא יכולים (קוד שרץ על Windows בלבד שלא בנוי לעבוד על קונטיינר או שהחברה לא רוצה לעבור ל-Windows Server 2016) – אפשר להקים מכונות (Instances) שישוכפלו דרך מתודת AutoScale לפי כמות המשתמשים שמתחברים או לפי כמות המשאבים שנצרכים – כך שקונטיינרים או מכונות (בהתאם לסיטואציה) הן תמיד זהות וה-Data האמיתי מגיע מבחוץ (NFS או אחסון שיתופי אחר לדוגמא).

לגבי תקשורת – כמעט כל חברה שמכבדת את עצמה משתמשת כיום בסוויצ'ים מסוגים ידועים, בין אם זה Cisco, HP ואחרים. בתשתית ענן, אין סוויצ'ים לשרותכם. הכל וירטואלי דרך ה-VPC (ו-VPN אם אתם רוצים להשתמש להתחבר מספק הענן אליכם), כך שישנה עקומת לימוד קלה אך מצד שני – העלויות עצמן זניחות.

ומה לגבי סטורג'? בניגוד לסטורג' שיש אצלכם בחברה, אצל ספקי ענן אין "סטורג'" באותו מובן. ישנו File או Block Storage שאתם קונים למכונות לפי גודל שאתם רוצים, לפי IOPS שאתם מבקשים (בזהירות – בחירה לא נכונה של סוג אחסון תפציץ לכם את החשבון באלפי או עשרות אלפי דולרים!). אם יש לכם אלפי קבצים סטטיים, אפשר להשתמש ב-S3 (יש כזה לא רק לאמזון, אלא גם למיקרוסופט ולגוגל) לאחסן שם את הקבצים וכמובן אפשר לשמור לשם גיבויים, (אם כי S3 אינו File Storage רגיל עם הרשאות שיש ל-NTFS/CIFS, חשוב לזכור). ככלל, בענן מומלץ יותר לבנות לקבוצות שרתים "מיני סטורג'" משותף בינם מאשר לנסות לעשות זאת על Block Storage ענקי – זה גם יצא זול בהרבה.

נקודה נוספת שמתאימה לחברות גדולות שיש בהן תשתית ענן פרטי והן רוצות לשלב חלק מהתשתית בענן ציבורי והתקציב שלהן בנוי כך שמחלקת המחשוב מחייבת מחלקות אחרות – כדאי יהיה לכלול בתקציב מערכת CMP (או Cloud Management Platform). הסיבה לכך היא פשוטה: כשמתחילים להשתמש ב-AutoScale לגדילה דינמית, יהיה קשה לחשב כמות משאבים פר שרת, הואיל וברגע אחד לאפליקציה של מחלקה מסויימת יש 2 שרתים ולאחר שעתיים יש 20 שרתים. מערכת CMP טובה (המלצתי כאן בעבר על CloudForms) תדע לא רק לחשב את הדברים אוטומטית, אלא גם ניתן יהיה לבנות דרכה את כל תהליך הבקשה, אישורים ובניית המכונה ללא צורך בלימוד שפה סגורה או כלים סגורים (שלא בטוח אם מחר זה יהיה קיים.. תראו מה קרה ל-vCloud Air לדוגמא).

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

קוד פתוח מול קוד סגור ו"נעילת" לקוחות

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

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

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

אחד הדברים שאני מעוניין לשמוע מלקוחות פוטנציאליים או מתעניינים לגבי פתרון זה או אחר – הוא שימוש בקוד פתוח בחברה. באיזה כלים או פלטרפורמה הם משתמשים? האם הם מעוניינים להשתמש בקוד הפתוח ובמוצרי קוד פתוח בשאר מוצרים ובתשתית החברה? או שמבחינתם אין בעיה "להינעל" עם פתרון כלשהו שפעיל רק בזמן שמשלמים דמי מנוי חודשיים/שנתיים/דו-שנתיים/תלת-שנתיים וכו'?

הנה דוגמא: לא מעט חברות שנכנסות יותר ויותר בשימוש עננים ציבוריים "מגלים" כשהם משתמשים בלינוקס ומערכות CI/CD את האוטומציה, ותתפלאו – חברות רבות לדוגמא עד היום לא הכניסו שום אוטומציה. יש פלטפורמות אוטומציה רבות ללינוקס כמו Chef, Puppet, SALT ובוודאי עוד כמה – אולם אני ממליץ ספציפית על Ansible מכמה סיבות:

  • הקוד של "המנוע" – פתוח לחלוטין וכתוב ב-Python.
  • אין צורך ב-"שרת" Ansible. כל הפעילות היא Serverless לחלוטין.
  • הכתיבה של ה"תסריטים" (או Playbooks איך שזה נקרא ב-Ansible) היא פשוטה ולוגית. המשתמש יכול תוך שעה שעתיים אחרי שהוא קרא את התיעוד לכתוב דברים בסיסיים שיכולים לרוץ על המכונה שלו ומכונות אחרות, כך שעקומת הלימוד – היא די קטנה.
  • יש לכם שרתי Windows? אולי הגיע הזמן גם ששם תהיה אוטומציה? אז ל-Ansible יש גם מודולים ל-Windows, בין אם מדובר להתקין קבצי MSI, להגדיר IIS, להעתיק קבצים, פעולות דוט NET, ניהול משתמשים וקבוצות ודברים נוספים. העלות לחברה? יקרה מאוד .. אפס שקלים.
  • מחפשים ממשק Web? אתם יכולים לרכוש את Ansible Tower (וביחד עם זאת לקבל תמיכה רשמית מ-רד-האט) או שאתם יכולים להשתמש בממשק וובי אחר (ויותר בסיסי) בקוד פתוח שנקרא Ansible Semaphore.
  • חושבים לעבור לאוטומציה אחרת מסיבה כלשהי? לרוב המתחרים יש כלים אוטומטיים להעביר את ה-Playbooks שכתבתם אל המערכת החדשה (אם כי עדיין לא נתקלתי בחברה שעברה מ-Ansible למערכת אחרת).

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

אותו הדבר גם בכלים לניהול סביבת חיים (Life Cycle) של קונטיינרים וסביבות המורכבות מעננים פרטיים וציבוריים. ניקח לדוגמא את קטגוריית ה-CMP (כלומר Cloud Management Platform). בתחום זה יש מתחרים רבים, החל מ-VMWare עם ה-vRealize לגרסאותיו, RightScale, ועוד. האם פלטפורמות אלו מבצעות את מה שהן מבטיחות? בהחלט! אולם אם תפסיק לשלם את התשלום החודשי או השנתי, תיתקלו באחת מהסיטואציות הבאות:

  • במקרים כמו של RIghtScale – אתה "בן ערובה", כל עוד שתשלם – הכל עובד. הפסקת לשלם, תתחיל לבנות מחדש את כל מה שבנית – על מוצר אחר.
  • במקרים כמו vRealize אם אתה מפסיק לשלם, המערכת לא תתעדכן לשרותים והגדרות חדשות של עננים ציבוריים, OpenStack ואחרים, אין תמיכה ואין עדכונים לגרסאות חדשות.

לעומת זאת, במוצר כמו CloudForms שנותן לך לבצע CMP (כולל כמובן עמידה ברגולציות וכו'), אם לא בא לך לשלם יותר, אתה יכול לייצא ולייבא את ההגדרות, הקבצים והתכנים לגירסת הקוד הפתוח (ManageIQ) בדיוק כמו שאתה יכול לעבור מ-RHEL ל-CentOS מבלי לאבד פונקציונאליות או תאימות. כשזה מגיע לקונטיינרים, אתה יכול לעבור מגירסת OpenShift מסחרית ל-OpenShift Origin שמבוססת על Kubernetes כך שבעצם למעט שרותי תמיכה (שאותם תוכל לקבל מצד ג' בין כה), אינך מפסיד דבר. להיפך: אתה שומר על כל העבודה שהצוות ביצע ואפשר לאחר המרה לגירסת קוד פתוח – להמשיך לעבוד כרגיל.

לסיכום: לא חשוב אם החברה היא סטארט-אפ שממומנת בחסכונות של המייסד או אם מדובר בחטיבות מחשוב של בנק גדול ועתיר תקציבים: ה-ROI, ה-TCO והשימוש החוזר (re-usability) בפלטפורמה ובכלים הם לדעתי הדברים החשובים. ראיתי מספיק מקרים בהם הוצע ללקוחות כלי כלשהו בקוד סגור בעלות נמוכה (כי מדובר בחברה גדולה ומוכרת שרבים מקשיבים לפתרונות שהיא מקימה) ועתה כשצריך לעבור לעננים וקונטיינרים – החברה צריכה להשקיע תקציבים גדולים כדי לעבור לפלטפורמות קוד פתוח. לכן – חשוב מאוד לבדוק גם כלים בקוד פתוח או כלים מבוססי קוד פתוח וגם להשקיע במחשבה איך לא למצוא את עצמכם "נעולים" באותו כלי או באותה פלטפורמה.

שבוע טוב 🙂

על קונטיינרים ואבטחה

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

טכנית, אלו שמכירים יוניקס ולינוקס משנים קודמות, מכירים בוודאי את chroot ובמקרים רבים אנשים נוטים לחשוב שקונטיינרים הם בדיוק כמו להריץ chroot (כלומר ביצוע הקמת file-system ועליו להריץ את פקודת chroot על מנת לתת כביכול "מערכת הפעלה" נוספת), אך למען האמת, docker משתמש בהרבה יותר מזה כדי להריץ קונטיינר שיכול להיות מאובטח (יש צורך בעבודה נוספת על מנת לאבטח, אפשר לקרוא על כך כאן).

העניין הוא – שברוב המקרים בחברה לא יריצו קונטיינר יחיד (ראו פוסט זה שכתבתי לגבי מעבר מ-VM לקונטיינרים ברמת הקונספט). אם יש לדוגמא אפליקציה וובית, ברוב המקרים היא תהיה מחוברת ל-DB שירוץ על קונטיינר אחר, וההרצה בעצם תבוצע ע"י Container Scheduler כמו Mesos, OpenShift, Kubernetes, Docker-Swarm ועוד – הם ירימו את הקונטיינרים וינהלו את הכל.

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

  • אינטל מציעה את Clear Container (בגירסה 2.1.4 ששוחררה לאחרונה). היתרון של Clear Container בהשוואה לקונטיינרים של Docker הוא בכך שכל קונטיינר של Clear Container הוא בעצם מכונה וירטואלית (VM) שבתוכה מותקנת ורצה האפליקציה, משמע – בשביל להריץ Clear Container, תצטרכו להריץ זאת על Bare Metal (כלומר על "ברזלים") בלבד ולא על VM (כן, יש כמובן Nested Virtualization לכל תוכנת וירטואליזציה, אבל אף חברה לא תשתמש בזה באופן רציני בפרודקשן לדוגמא), כך שבעיה ראשונה שאני רואה – היא ששום חברה לא תסכים שמערכת תקים מכונות VM "על הברזל" בלי מערכת שתנהל את אותם VM מבחינת משאבים, ניטור ובכלל – ללא פתרון כמו vCenter שיש מ-VMWare למכונות VM – אף אחד רציני לא יכנס לזה.
    האם הפתרון של אינטל יכול להשתמש ב-Kubernetes? כן אבל זה ממש לא מוכן לפרודקשן.
  • Kubernetes בעקרון נוקט שיטת אבטחה של "הכל סגור". בברירת המחדל, כאשר אתה מקים קונטיינרים או POD, אינך יכול לגלוש אל האפליקציה שרצה בקונטיינרים או ב-POD ועליך "לחשוף" פורטים מסויימים או להשתמש ב"שרות חשיפה" כמו LoadBalancer או NodePort (שמאפשר לפתוח פורטים מסויימים שיתחברו אל ה-Load Balancer החיצוני שלכם) או ClusterIP, אך החסרון ב-Kubernetes הוא שזו מערכת Multi Platform שאינה מכירה בחלק מתכונות אבטחה שה-Kernel והמערכת יכולים לתת (כמו SELinux – גם בגירסה הנוכחית Kubernetes עדיין לא ניתן לעבוד עם זה). Kubernetes מכיר כמובן ב-namespaces ו-cgroups כדבר שנותן אבטחה, אבל לחברות רבות – זה לא מספיק.
  • OpenShift מכיל את Kubernetes ומערכת Openshift בעצם "עוטפת" את Kubernetes ומוסיפה לו בדיוק את הדברים שחברות מחפשות מבחינת אבטחה. כך לדוגמא אין אפשרות להריץ התקנת Openshift על שרתים מבלי להפעיל SELinux ו-NetworkManager כך שמראש המערכת מקימה קונטיינרים ושאר דברים בצורה מאובטחת כברירת מחדל.
  • מה עם Mesos? אני לא מומחה ב-Mesos אבל לפחות לפי כמה שהכרתי אותו, ישנה אבטחה ברמה של הקמת ותקשורת בין קונטיינרים (עם Auth), אבל אינני רואה שם שום דבר שיכול בעצם למנוע מפורץ שנמצא בקונטיינר – "לצאת החוצה", כלומר הכל תלוי בבנייה ידנית שלך לקונפיגורציות של הקונטיינר, שימוש בתכונות אבטחה של ה-Kernel (ראו לינק ראשון בפוסט זה) וכו'. אין SELinux, AppArmor שיכולים למנוע דברים גם אם המשתמש השיג root מקומי בתוך הקונטיינר.
  • לגבי Docker-Swarm: אנשים לא אוהבים שאני אומר את זה, אבל מבחינת אבטחה ב-Docker Swarm, אין ממש הרבה. כן, אתה יכול לבנות רשת מוצפנת (IPSEC), אבל מה זה עוזר אם מישהו נכנס לקונטיינר ויש לו עכשיו גישה לקונטיינר עם ה-DB? זה נחמד שיש הצפנה אבל הפורץ נכנס אחרי שיש הצפנה והרשת בין הקונטיינרים פועלת באופן שקוף (כבר בוצע Authentication). אז נכון, הוא לא יוכל לפתוח כניסות חדשות, אבל הוא בהחלט יכול להשתמש בכניסות קיימות (פורטים) ואולי לא לגרום לנזק לכל המערכת אלא רק לקונטיינרים שאליהם הקונטיינר שהוא נכנס מחובר. בקיצור, לדעתי האישית לגבי Docker-Swarm, הוא נחמד, אבל אין לו מספיק עבודה רצינית על אבטחה.

לסיכום: האם Docker עצמו יכול להיות מאובטח? בהחלט, אם אתה מתכנן להריץ מספר קונטיינרים קטן ללא Scheduler ואתה מוכן לעשות את העבודה הנוספת להגן על הקונטיינרים (הם לא מספיק מאובטחים בברירת מחדל! אם אתה מחפש להריץ קונטיינר עם פורט 80 החוצה, אתה ממש לא חייב להריץ את הקונטיינר כ-root). אם אתה משתמש ב-Kubernetes, אז יש לך Best Practice כיצד להגן על הקונטיינרים/POD וכו' ברמת התקשורת ואותנטיקציה, אבל Kubernetes עדיין לא יודע איך להגן בתוך הקונטיינר נגד פורץ. הפתרון של אינטל הוא נחמד אבל עד שיהיה פתרון לאינטל ברמה שזה רץ על VM או בשילוב עם מערכת Management ל-VM (כמו vcenter ואחרים) אף חברה רצינית לא תיקח זאת.

לכן הפתרון שאני ממליץ עליו כיום מבחינת קלות, נוחות ומה שהכי חשוב – אבטחה, הוא הפתרון של OpenShift Origin (כגירסת קוד פתוח) או OpenShift Enterprise כגירסה מסחרית (גירסת הקוד הפתוח להתקנה על ברזלים/VM מצריכה שימוש באוטומציה כמו Ansible. גירסת הדגמה ניתן להרים על VM יחיד או על הלינוקס שלך בדסקטופ – ראו את הוידאו הבא כיצד לעשות זאת)

על קונטיינרים ו-Appliance

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

אם יש משהו שאני יכול לאמר על Appliances זה שהחיים איתם מבחינת הכנה – אינם קלים. תמיד אפשר כמובן לכתוב איזה updater לדוגמא שיתחבר לכל מיני מאגרי חבילות (REPO) ויוריד את חבילות מערכת ההפעלה ועדכוני התוכנה וחתימות (אם צריך, נניח), אבל מה אתה עושה אם לקוח לא מוכן לחבר את ה-Appliance עקב הוראות בטחוניות באותה חברה/מוסד/ארגון? אתה צריך ליצור מעין "Delta" של החבילות סיסטם + עדכונים ולשלוח לו את זה כדי שהוא יוריד לדיסק און קי, "ילבין" ויתקין את זה.

נחשוב על סיטואציה שמתרחשת אצל כל חברה שמייצרת Appliance (בין כ-VM ובין כקופסא פיזית) – החברה החליטה שבמסגרת הגירסה הבאה של התוכנה, היא מחליפה בדרך גם את הפצת הלינוקס שלה, ולא חשוב אם מדובר בשדרוג לגירסה אחרת מאותה הפצה או במעבר מ-Ubuntu ל-CentOS. המימוש לתהליך הזה די מורכב הואיל ומדובר על דריסה של מערכת קיימת ואם זה נשבר באמצע, ללקוח יהיה Appliance במצב לא שמיש (נקרא גם Brick). מעבר לכך זה גם מאוד תלוי אם המערכת הוקמה עם Volume Management (תתפלאו כמה Appliances אין להם את זה) ושההגדרות והנתונים יושבים על Logical Volume אחד, ה-DB יושב על Logical Volume אחר וכו' וכו'. בלי זה – כתיבת השדרוג הולכת להיות מורכבת ומסובכת (מנסיון…)

וכאן בדיוק קונטיינרים יכולים מאוד לעזור בשילוב LVM (ר"צ של Logical Volume Manager). את ה-Appliance אפשר לבנות בתצורה הבאה לדוגמא (בניכוי כל הדברים הקשורים ל-Volume Groups וכו'):

  • מחיצת boot/ בגודל 1 ג'יגהבייט (זה הסטנדרט המומלץ בסנטוס 7, אגב) ללא LVM
  • LV לוגי שמכיל את ה-OS עצמו בלבד.
  • LV שמכיל את ספריות ה-DB וקבצי קונפיגורציה
  • LV שמכיל קונטיינרים
  • LV לגיבויים
  • LV שמיועד לקבצים זמניים, Cache וכו'
  • LV ספייר (ריק, לשימושים שונים במהלך חיי ה-Appliances כמו פריסת Plugins זמניים, קבצי התקנה זמניים ועוד ועוד)

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

מבחינת קונטיינרים, יהיו במערכת מינימום 2 קונטיינרים (או 3, תלוי בחברה, מה המוצר, מורכבות ועוד):

  • בקונטיינר הראשון תרוץ אפליקציית Web שמטרתה העיקרית היא ניהול ה-appliance עצמו ברמת סיסטם: עדכוני תוכנה, יצירת גיבוי ושחזור, הרצת בדיקות תקשורת, התחברות ל-AD (אם צריך) ו/או למערכות אחרות. לאותו קונטיינר אנחנו נמפה הן את ה-DB והן את תיקיית קבצי הקונפיגורציה כך ששינויים ישמרו, גם אם לקונטיינר יקרה נזק/יפול/ימחק. לקונטיינר הזה המשתמש יגש דרך כתובת ה-IP של ה-appliance אך דרך פורט אחר שאינו 80/443 ומומלץ שיהיו לו יוזרים שונים מהיוזרים שמשתמשים ב-appliance עצמו.
  • בקונטיינר השני תרוץ האפליקציה העיקרית שלנו וגם בקונטיינר זה אנו נמפה את התיקיות קונפיגורציה ואת תיקיית ה-DB. לכאן המשתמש יגיע דרך HTTP או דרך HTTPS לפי העדפותיכם כמובן (אגב, טיפ קטן לחברות שבונות appliances – תנו דרך קלה להכניס תעודות SSL).
  • אופציונאלי: קונטיינר שלישי יריץ את ה-DB וגם אליו נמפה את תיקיית ה-DB. הסיבה שאני ממליץ להפריד את ה-DB לקונטיינר אחר היא שבמקרים רבים ללקוח יש הרבה פעילות וה-Appliance מגיב באיטיות כשהוא בעומס, ולכן כדאי לחשוב על מתן אפשרות הקמת Appliance רק עם ה-DB.

היתרונות בעבודה בדרך זו:

  • יצרן ה-Appliance יכול להשתמש בכל גירסה באיזו הפצת לינוקס שירצה, מבחינת המערכת – זה בסך הכל Image שקונטיינר מריץ. האפליקציה בקונטיינר מתממשקת לתיקיה של ההגדרות וה-DB ויכולה לזהות אם ההגדרות ישנות (או הנתונים ב-DB ישנים) ולשדרגם בהתאם.
  • כשיש עדכון חרום או עדכון רגיל שאיננו החלפת גירסת Major, העדכון שירד יהיה די קטן והוא ירד בצורה מאובטחת מ-repository של היצרן דרך התשתית של docker, המערכת תעדכן את קבצי ה-image, תבנה קונטיינר חדש ותחליף את הקיים בצורה שקופה.
  • כשיש שדרוג לגירסת Major חדשה, קונטיינר אחר נותן חוויית שימוש הרבה יותר אינפורמטיבית ללקוח, הוא יכול לראות מה קורה מבחינת אחוזי הורדה, מה המערכת עושה.
  • עדכוני מערכת ההפעלה הראשית (שאינה נמצאת בקונטיינר) הם בטוחים וגם אם יש תקלה, המקסימום שיהיה צורך זה לעדכן את ה-OS המינימלי. זה לא נוגע בקונטיינרי (ההגדרות יושבות ב-LV אחר).
  • אם הלקוח גודל מחר וצריך DB עם רפליקציות וכו' – השינויים שיש צורך לבצע הם מינוריים.
  • הזמן שלוקח מגילוי תקלה בתוכנה ועד שחרור ללקוחות (לאחר בדיקה) – מתקצר משמעותית. מהרגע שהחברה שחררה עדכון, הלקוח יכול להיכנס לקונטיינר הניהול, ללחוץ על Update מבלי להוריד קבצים.
  • זמן הירידה והעליה של ה-Appliance לאחר שדרוג מתקצר משמעותית.
  • אפשר לפתוח לטובת הלקוחות ערוצים נוספים כמו testing, beta, stable והלקוח יוכל לבחור לעבור, מדובר בסופו של דבר רק בהחלפת קונטיינר (חשוב לזכור: האפליקציה של הלקוח תצטרך להתמודד עם קבצי הקונפיגורציה וה-DB מבחינת שינוי ושדרוגם)
  • הלקוח יוכל לבצע (או שהמערכת תבצע עבורה) גיבוי של הקונפיגורציה וה-DB במהירות (מדובר ב-LV snapshot שהוא חלק בסיסי בלינוקס) ו-rollback במקרה הצורך.

במקרים כמו עבודה של Offline עקב דרישות של ארגונים בטחוניים או אגף אבטחת המידע של החברה, יהיה צורך בשינויים- אבל את זה אני משאיר מחוץ למאמר זה 🙂

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

המעבר מ-VM לקונטיינרים

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

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

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

אם אני מעוניין להציג דברים אחרים, אולי אתר מלא, אני אכנס לתיקיה שמוגדרת בשרת Web כ-DocumentRoot ואעביר לשם את הקבצים ואולי גם אתקין שם MySQL קטן כי האתר שלי מצריך Database. אני אוודא כי כניסות 80 ו-443 פתוחים לעולם. עכשיו הכל עובד, ואני אכנס אחת לתקופה כלשהי כדי לעדכן את התוכנה, ואת מערכת ההפעלה. אם תהיה לי הפסקת חשמל, ברגע שהחשמל יחזור אני אבצע Boot לפתרון הוירטואליזציה ואפעיל מחדש את ה-VM כדי שאנשים יוכלו לגלוש לאתר שלי.

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

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

כך בדיוק עולם הקונטיינרים בנוי.

קונטיינרים מכילים דברים מאוד מינימליים. הם מכילים "שכבות" של File-system ובהן שלד מאוד-בסיסי של הפצת הלינוקס שתהיה בקונטיינר, ועל זה אנחנו בעצם מתקינים את האפליקציה שאנחנו מעוניינים (אפליקציה, לא אפליקציות), ספריות הכרחיות – וזהו. אם לדוגמא אנחנו מקימים קונטיינר עם MySQL, התיקיות במערכת הקבצים שמחזיקות כל קבצי ה-DB לא יהיו בתוך הקונטיינר אלא ישבו על השרת הפיזי או על אחסון שיתופי כמו NFS, OCFS2 ואחרים ויהיו ממופים לקונטיינר. אותו דבר לגבי שרת Web – כל קבצי האתר יהיו מחוץ לקונטיינר וימופו אל הקונטיינר עצמו כך כשהקונטיינר מת, כבה או נמחק – הקבצים הרלוונטיים ישארו מחוצה לו ללא נזק.

כך שאם נחזור לדוגמא לעיל עם האתר, אנחנו בעצם נקים 2 קונטיינרים עם מיפוי לשרת הפיזי או ל-NFS/OCFS עם המידע הרלוונטי. זיכרו: בקונטיינרים – כל דבר שהולך להשתנות, מומלץ שיכתב/יקרא ממערכת מחוץ לקונטיינר, ודברים שהם קבועים – אנחנו נכלול אותם בעת בניית הקונטיינר בכתיבת קובץ DockerFile (שמהווה בעצם "סקריפט" לבניית הקונטיינר שלנו). יותר מכך – כשעובדים עם מספר קונטיינרים לא קטן, מאוד מומלץ להתחיל לעבוד עם מערכות כמו OpenShift, Kubernetes, Rancher ואחרים – ששם כבר ניתן "להזריק" לקונטיינר דברים רגישים כמו סיסמאות, מפתחות SSL – בעת הרצת הקונטיינר.

לכן, העברה של מערכת מ-VM לקונטיינרים בצורה של "1:1" לא רק שלא שווה, היא גם תעשה צרות (במיוחד שמריצים docker run והמערכת מקימה כל פעם מחדש קונטיינר חדש ולאיש צוות שלא מבין בקונטיינרים יש כאב ראש מדוע הקבצים לא נשמרים ומדוע כשהוא מתחבר לקונטיינר והוא מתנתק, הקונטיינר כבה). צריך לבדוק כל VM מה בעצם הוא עושה, מה האפליקציות שצריך ואז לבנות את הקונטיינרים השונים כדי שהדברים ירוצו, יחד עם מציאת פתרון NFS/OCFS2 ואחרים כדי למפות תיקיות לקונטיינר, דאגה ל-Scheduling ועוד.

קונטיינרים הם כלי מצוין במיוחד ל-2 פעולות:

  • בדיקות – מאוד קל להקים קונטיינרים במהלך תהליך CI/CD שיכלול את האפליקציות והספריות. כך אנחנו בעצם נחסוך יצירת קבצי הרצה שאותם נתקין על VM כדי לנסות. ברגע שהמערכת מסיימת לבצע בדיקות Unit testing לדוגמא או תהליכים אחרים – אפשר לקבוע שבסוף היא תקים קונטיינר המבוסס עם קובץ DockerFile (או שתשתמשו ב-Docker Compose שמבוסס פייתון אבל לא מחייב ידע בפייתון), וכך המערכת תקים קונטיינר עם הכל מוכן לשימוש ע"י צוות הפיתוח או צוותים אחרים.
  • שיווק – כמעט כל חברה שבונה היום מוצרים מבוססי Web ללקוח, בין אם זה שרת מייל, ניטור, אבטחה או 1001 דברים – החברות משתמשות ב-IMAGE כדי לשדרג, רק ש-IMG זה לא תמיד פתרון טוב או קליל, במיוחד אם צריכים לשלוח ללקוח שאין לו ל-Appliance חיבור אינטרנט וצריך לעדכן חבילה מסויימת ספציפית (נניח … openssl) ואז צריך לבנות לוגיקה שלמה שהמערכת תבין כל קובץ מהו ולאן הוא הולך ושלא ישבור כלום באמצע.
    עם קונטיינרים לעומת זאת – החיים הרבה יותר קלים. ה-Appliance יכול להכיל מערכת לינוקס מאוד מינימלית (כמו Atomic של רד-האט/סנטוס), והאפליקציה עצמה יכולה לשבת בקונטיינר כאשר כל קבצי ההגדרות וקבצים חשובים יושבים מחוץ לקונטיינר וממופים לקונטיינר. כך, במקרה של שדרוג, הלקוח יוריד קובץ חתום, המערכת תקבל את הקובץ החתום, תבדוק חתימה, ותפרוס אותו ל-file-system המקומי ואז בהרצה של מספר פקודות ניתן לכבות ולהפעיל את הקונטיינר החדש תוך מיפוי התיקיות החשובות – ועכשיו יש ללקוח Appliance מעודכן עם הגירסה החדשה של התוכנה (ובקשר לעדכון ה-VM עצמו או המכונה הפיזית שמריצה את הקונטיינר – אפשר להשתמש ב-ostree)

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

[stextbox id="alert" caption="גילוי נאות"]"חץ ביז" מעניק שרותי הקמה, תמיכה ואינטגרציה לקונטיינרים על לינוקס.[/stextbox]

על OpenStack וחברות שרוצות לאמץ את הטכנולוגיה

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

בעסק, כמו בעסק, אם לקוח רוצה X והוא מוכן לשלם – אז מספקים לו את הפתרון. אין ויכוח על כך.

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

נתחיל באלו שמעוניינים ב-OpenStack רק בגלל מחיר אפסי. כאן, לצערי, אצטרך לאכזב מספר לקוחות פוטנציאלים בגלל סיבה פשוטה: גירסת ה-OpenStack שקיימת באתר הרשמי אינה מתאימה לסביבות פרודקשן בחברות. מדוע? מכיוון שהגרסאות ש-OpenStack (הארגון) משחרר הם גירסאות שיוצאות כל חצי שנה בערך (עיינו בטבלה כאן) והן מתוחזקות בערך עוד כמחצית השנה, עדכונים קריטיים בשנה לאחר מכן ובסופה – End Of Life, כלומר גירסה יכולה להחזיק בחברה אולי שנה-שנתיים וזה לחלוטין לא מקובל אצל חברות שרגילות שמערכת הפעלה מחזיקה מעמד לפחות 4 שנים ומעלה.

גירסה יציבה עם פתרון ל-3 שנים (עם הרחבת תמיכה בתשלום ל-5 שנים) רק אצל יצרני הפצות לינוקס (או חברת Mirantis וחברות אחרות שמוכרות את OpenStack מיצרני הפצות כמו HPE וכו') והן אינן קיימות כגירסה חופשית, כלומר אם חברה גדולה רוצה OpenStack של יצרן הפצה עם תמיכה והכל – יהיה צורך לרכוש רשיונות ל-OpenStack (ולחלקים נוספים שלא אכנס לפירוט עליהם בפוסט זה). חשוב מאוד: לכו עם יצרן הפצה רציני (כמו רד-האט או SuSE). אני פחות ממליץ על OpenStack מהפצה כמו אובונטו הואיל וקנוניקל "דוחפת" בגירסתה דברים שיחודיים לה שאף אחד אינו יודע אם הם יתוחזקו בעתיד וגם שיטת האכסון בגירסת ה-OpenStack שלהם דורשת המון משאבים (שימוש ב-Ceph כאחסון ראשי).

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

לאחר שדיברנו על העניין הכספי והיציבות של OpenStack – נדבר על OpenStack כפתרון למעבר ממערכת אחרת.

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

האם OpenStack תומך בפתרונות שכוללים גם VM וגם קונטיינרים? בהחלט (החל מגירסת Newton), אבל כדאי לקחת בחשבון את הנקודות הבאות:

  • כדי לתזמן קונטיינרים, אינטגרציית רשת יותר טובה עם קונטיינרים, שימוש ב-Kubernetes או Docker Swarm – יש צורך בגירסת ocata שעדיין אינה קיימת כגירסה מסחרית
  • אם אתם משתמשים ב-vSphere ולא אכפת לכם להתנסות את Admiral (ומספר כלים נוספים) מבית VMWare. רשמית – רק ב-vSphere-7 תהיה תמיכה "out of the box" לקונטיינרים, אבל ה-Admiral (שנכתב ע"י המפתחים ב-VMWare יחד עם תרומות קוד מבחוץ) נותן פתרון לא רע.
  • אם אתם רוצים פתרון וירטואליזציה די "רזה" שמיועד בראש ובראשונה לתת פתרונות וירטואליזציה – כדאי לנסות את RHEV של RedHat (בגירסה הקרובה שלו הוא גם יריץ קונטיינרים באופן טבעי) ובגירסה החופשית – oVirt.
  • אם אתם מתעקשים להשתמש בגירסה החופשית של OpenStack – שדרוג מגירסה ישנה לחדשה לא בטוח שיהיה חלק (ראיתי מספיק מקרים שהשדרוג נשבר באמצע והיה צורך בידע בלינוקס וב-Python כדי להתגבר על התקלה).
  • OpenStack מצריך ידע עמוק בלינוקס. אם יש לכם צוות לינוקס עם ידע רציני במערכת הפעלה וב-Python – זה מעולה. אם לא – תתכוננו להחתים פרילאנסר (או עסק) לבנק שעות/ריטיינר.

לסיכום: OpenStack היא מערכת מעולה שיכולה לתת שרותי IAAS, PAAS, SAAS. רוצים להטמיע אצלכם בחברה כפרודקשן לאורך זמן? קנו את הגירסה המסחרית מיצרן הפצת לינוקס. קחו בחשבון שב-8 מתוך 10 מקרים, OpenStack זה פתרון של "להרוג זבוב עם תותח" ואם אין לכם בעיה עם פתרון הוירטואליזציה שלכם כיום ואתם לא מחפשים "לברוח" ממנו בגלל מחיר (תאמינו לי, גירסה מסחרית של OpenStack זה לא דבר זול) – אפשר לתפור גם פתרונות לקונטיינרים במערכת הקיימת שלכם.

[stextbox id="alert" caption="גילוי נאות"]"חץ ביז" מעניק שרותי הקמה, תמיכה ואינטגרציה ל-OpenStack בכל הגרסאות[/stextbox]

כשהאתר דורש יותר ויותר משאבים בפתאומיות

בעלי אתרים רבים מכירים את התופעה: בד"כ גולשים נכנסים לאתר, קוראים, עוברים לעמודים אחרים, אולי נרשמים ומשתתפים בפעילות שמציע האתר ובעקרון – הכל עובד. המערכת מתארחת בין אצל ספק אירוח אתרים שיתופיים (Shared Hosting) או במכונה וירטואלית (VPS).

הבעיה הגדולה מגיעה כשיש כמות גולשים גדולה שמגיעה במכה אחת, בין אם לכמה דקות או לכמה שעות או כמה ימים. תחשבו לדוגמא על חברה שיש לה אתר מסחרי ובשבוע הקרוב מתקיים מבצע של 20-50% הנחה על מגוון מוצרי החברה ואנשים מעוניינים לרכוש. מה עושים לקראת המבצע? זה תלוי, ובד"כ יבחרו באחת (או יותרת) מהאופציות הבאות:

  • הגדלת משאבי המכונה הוירטואלית (יותר זכרון, יותר ליבות)
  • אופטימיזציה של מערכת האתר – טיוב שאלות SQL, בניה יותר טובה של Cache, אולי מעבר ל-NGINX, שינוי PHP לעבודה כ-FPM ועוד ועוד..
  • שכפול והקמת מכונה זהה ומעל המכונות Load Balancer תוך מתן פתרון גם ל-SQL (שיטות Master/Slave, Multi Master ועוד)
  • אם אתם משתמשים בשרותי ענן כמו אמזון ושרותים כמו RDS, אולי תעברו ל-Instances יותר גדולים, אחסון יותר מהיר וכו'.

אם האתר שלכם נמצא בשרותי ענן ציבורי, בד"כ תהיה אופציה נוספת שנקראת Auto Scaling שתאפשר לכם להוסיף מכונות בהתאם לעומס (אתם יכולים לבדוק עומס על ה-CPU, עומס על הרשת, כמות זכרון פנויה וכו') ובד"כ זה פתרון טוב שעובד יפה והרבה חברות משתמשות בו. גם עניין הוספת VM לזה שקיים, ביצוע רפליקציה של SQL והוספת Load Balancer היא אפשרות טובה כשצריכים אותה.

אך לשיטות האלו יש מספר בעיות:

  • אם האתר עצמו מאוחסן ב-NFS או OCFS2 לדוגמא, תקלה בקוד או חדירה ע"י פורץ ושינוי הקוד (כמו במקרים של Defacement) – תשפיע על כל השרתים שלך. כנ"ל בעת שדרוג -אם השדרוג לא מצליח, שום אתר לא באוויר וכולם מקבלים את אותה שגיאה. בנוסף, אתם מייצרים צוואר בקבוק חדש מכיוון שכל פעם שהאתר צריך ולו את הקובץ הכי קטן – הוא צריך לבצע קריאה ל-Storage, ו-NFS לדוגמא פשוט לא מתאים לזה, אתם יוצרים צוואר בקבוק חדש.
  • מחיר – להוסיף עוד VM + Load Balancer זה לא כזה יקר (לעסק שמתפרנס [גם] מהאינטרנט לדוגמא), אבל כשאתה צריך להוסיף עוד 20 מכונות VM העסק מתחיל להיות קצת יקר וזה לא חשוב אם מדובר בספק אירוח ישראלי או בענן ציבורי.
  • תחזית: כמה הולכים להיכנס לאתר? אתה לא יודע. אתה יכול להעריך בהערכה גסה, אבל אתה לא תדע אם יכנסו פחות או יותר ואם אנשים לא עפו מהאתר או לא הצליחו להיכנס בגלל שהשרתים היו עמוסים, בגלל תקלה, ובקיצור – עניין הניחוש הזה קשה כמו לנחש כמה אנשים יגיעו לחתונה..

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

מכונות VM הם פתרון טוב, אבל יש כיום פתרון יותר טוב והוא כמובן קונטיינרים: אפשר להקים קונטיינרים שיריצו את הקוד PHP, קונטיינרים שיתנו את שרות ה-WEB עצמו, קונטיינרים ל-SQL, קונטיינרים ל-Cache וכו'. הקונטיינרים עצמם אינם דורשים משאבים גדולים – מכיוון שהקונטיינר לא צריך את כל מערכת ההפעלה מותקנת בו אלא אך ורק חלק שצריך להריץ אפליקציה ספציפית, אפשר להפעיל קונטיינרים עם כמות זכרון קטנה (נניח 512 מגהבייט זכרון) בהתאם לצרכים. בנוסף, קונטיינרים הם דבר שניתן לשכפל מאוד מהר (בניגוד ל-VM – קונטיינר משוכפל בשניות). כך בעצם ניתן "להמיר" את האתר שלך למספר קונטיינרים שישוכפלו בין מכונות VM (או Instances), תקבל Load Balancer בחינם, והמערכת תדע לגדול ולקטון בהתאם לצרכיך.

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

  • להקים מספר קונטיינרים שיתפזרו בין VM שונים, יאוחדו לקבוצות וכך המערכת תוכל "לדבר" בין החלקים
  • אם יש תקלה בקונטיינר מסוים, אפשר להרוג אותו והמערכת תקים מיד קונטיינר אחר זהה, כך שאם לדוגמא מישהו פרץ לקונטיינר מסוים, הפגיעה היא מקומית (תלוי כמובן בהגדרות היכן נמצאים הקבצים שנפגעו – בקונטיינר או על NFS/OCFS2 וכו'), ניתן להרוג את הקונטיינר ולהמשיך (כדאי כמובן לתקן את הקוד)
  • עם מערכת כמו Kubernetes ניתן לבצע תהליך הטמעה של גירסה חדשה כך שעדיין ישמרו גירסאות ישנות ולעבור לחדשות לפי קצב שיוחלט (לפי גילוי באגים ותיקונם וכו') וכך יחסך מצב של השבתת מערכת רק כי צריך להחליף גירסה.
  • אפשר להשתמש בהפצות לינוקס אחרות (או בקונטיינרים של Windows – אם אתם מריצים WIndows Server 2016) בתוך הקונטיינרים כך שאין זה משנה מה ההפצת לינוקס שמותקנת על ה-VM עצמו.
  • אין צורך בהגדרות זהות פר VM – ישנה מערכת ETCD שדואגת שההגדרות בין ה-Nodes יהיו זהות לחלוטין בין אחת לשניה באופן אוטומטי.
  • יעילות פר VM – הפצות כמו Atomic, CoreOS, RancherOS ואחרות – ניתן להתקין אותן על ה-VM ובכך לחסוך RAM שתפוס בד"כ על ידי הפצת הלינוקס ב-Node עצמו (אחרי התקנת הפצות כפי שציינתי לעיל – הזכרון התפוס נע בין 50-100 מגהבייט בלבד וה-Node גם עושה Boot מאוד מהר) ובאותו זכרון פנוי ניתן להשתמש לטובת הקונטיינרים.
  • על אותה מערכת Kubernetes ניתן גם להעלות קונטיינרים אחרים עם גרסאות שונות של האתר, לא צריך VM חדש לשם כך.
  • ויש עוד יתרונות.

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

אפשר כמובן לעבוד על Kubernetes בלבד (ויש כמובן גם API – שהוא יותר "client") לשפות שונות כמו PHP, Python, דוט.נט ועוד, אולם אם בחברה יש מספר מפתחים לאתר, אני ממליץ להשתמש בכלי כמו OpenShift Origin כדי לבצע את כל הדברים ב-Kubernetes (כולל דברים ש-Kubernetes לא עושה כמו בניית קונטיינרים, עבודה כמשתמשים וקבוצות ועוד) או בכלי אוטומציה אחרים לבצע הן את הדברים דרך Kubernetes והן את ה"מסביב".

מבחינת עבודה עם Kubernetes – המערכת הזו כתובה ופועלת מעולה – כשזה נמצא על ספק ענן ציבורי כמו גוגל או אמזון. אם זה בתשתית של ספק אירוח מקומי, יש צורך לבצע "שמיניות באויר" בכדי להתחבר למכונות הללו מבחוץ כי היא פשוט בנויה לשימוש פנימי כאשר תקשורת מבחוץ מגיעה דרך תשתית ספק הענן. ב-OpenShift לעומת זאת, פתרו זאת עם HA-PROXY ועם ניתוב חכם כך שאין צורך להסתמך על שרות כמו Load Balancing של ספק ענן חכם ואפשר להשתמש בפתרון המובנה.

מבחינה טכנית, לאלו שיש כבר אתרים גדולים, אין היום שום כלי למיטב ידיעתי שיכול לעשות לאתר שלכם המרה ממצב שהוא רץ על Shared Hosting או VPS/VM או Instance למצב קונטיינר. את הדברים יש צורך לבצע ידנית ויכול להיות שיהיה צורך לבצע מספר שינויים קטנים בתהליך העבודה (שימוש ב-GIT, הפרדה בין תהליכים ועוד) וכמובן יש צורך במחשבה ובבניית תהליך כיצד להכניס את OpenShift לעבודה אצלכם (כך שלא מדובר במשהו שמבצעים בכמה שעות או ביום עבודה אחד).

לסיכום: אם יש לכם אתר שמקסימום נכנסים אליו כמה מאות בודדים של מבקרים שרק קוראים מאמרים לדוגמא, מעבר לקונטיינרים לא יסייע לכם יותר מדי. לעומת זאת אם יש לכם אתרים (או אפליקציות Web – היינו הך במקרה זה) שניגשים אליהם אלפים, עשרות אלפים ומעלה – קונטיינריזציה של המערכת תוכל לעזור הרבה הן בעמידה בעומסים, שרידות ועוד. אגב, אם אתם התחלתם להשתמש ב-Windows Server 2016 – גירסת ה-Kubernetes האחרונה תומכת גם בכם. באם אתם רוצים לבצע את כל התהליך באופן יעיל – אני ממליץ להשתמש ב-OpenShift ולא ישירות ב-Kubernetes.

[stextbox id="info" caption="גילוי נאות"]מעבר לקונטיינרים הוא שרות שניתן ע"י חץ ביז[/stextbox]

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

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

כיום – הכל השתנה. המייל שלכם, סביר להניח שיושב אצל ספק ענן כלשהו (כמו מיקרוסופט או גוגל), אולי יש לכם גם תשתית וירטואליזציה בענן, אולי אתם משתמשים גם בכמה שרותי SAAS שונים לאחסן דברים חיצונית או לקבל שרותים חיצוניים מספק כלשהו בתשתיות SAAS/PAAS/IAAS וכו' ובקיצור: יותר ויותר דברים כבר אינם בבעלותכם הפיזית המלאה ואתם בעצם משלמים על שרותים שונים כשמי שמנהל את הברזלים לאותם שרותים – הוא אותו ספק, לא אתם. לכם מעתה יש "תשתיות" שמורכבות מדברים שיש לכם ב-DC המקומי ועוד דברים חיצוניים.

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

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

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

ענן פנימי

יש לכולם כיום תשתיות וירטואליזציה כמו vSphere או Hyper-V ואותן תשתיות עושות את העבודה בצורה לא רעה, אבל לפעמים צריך להתרחב – להוסיף דברים כמו קונטיינרים, ושרותי AAS שונים פנימיים, בין אם זה DB, Storage, imaging ועוד ועוד והפתרונות שהזכרתי בהתחלה לא בנויים לתת את השרותים הללו (אם שמוליק מהפיתוח צריך DB של 2 ג'יגהבייט, עם הפתרונות שהזכרתי בהתחלה תצטרך להקים לו VM או להקצות לו ב-DB הראשי מקום, והקצאה לטסטים לדוגמא ב-DB הראשי זה לא בדיוק רעיון טוב).

בשביל זה יש לדוגמא את OpenStack. מערכת OpenStack בעצם משתמשת בתשתית הוירטואליזציה הקיימת (וגם מאפשרת לנו להתרחב לתשתית וירטואליזציה חדשה נוספת שאינה דורשת תשלום גבוה) כדי להקצות מכונות VM (ובגירסה האחרונה – גם קונטיינרים) ושרותים שונים עבור המחלקות וה"לקוחות" בחברה. מבחינת משאבי תמיכה וטיפול – ככל שמשתמשים יותר ב-OpenStack, המערכות וירטואליזציה הישנות צריכות פחות תחזוקה כי מערכת OpenStack יודעת לפנות לתשתית ולארגן את הדברים (יצירת מכונות, מחיקה, הקצאת משאבים וכו') כך שהוספת Open Stack לא מחייבת הוספת איש נוסף קבוע לשנים הקרובות אלא רק בהתחלה מומלץ לקחת מישהו חיצוני שמקים את התשתית, מדריך את צוות ה-IT ונותן "ברקע"  תמיכה טכנית ופתרונות.

מערכת Open Stack קיימת כקוד פתוח שניתנת להורדה כאן ובנוסף היא קיימת כפרויקט RDO למשתמשי Fedora/CentOS/RedHat. שימו לב, המערכת מאוד מורכבת ואינה מקבלת תמיכה רשמית.

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

קונטיינרים

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

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

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

ישנם פתרונות רבים בקוד פתוח לבצע את הדברים הנ"ל אולם הפתרון הכי פופולרי הוא Kubernetes שמאפשר דרך ה-Shell/CLI לעשות את הדברים הללו וכמובן ניתן להכניס את הכל לסקריפטים. Kubernetes מתאים למי שמכין קונטיינרים בעצמו / משתמש בקונטיינרים שניבנו ע"י אחרים, אולם Kubernetes אינו כולל את כל ה-Life Cycle של קונטיינרים ואינטגרציה עם כלי CI/CD, ממשק משתמש טוב, ניהול משתמשים ופרויקטים ועוד פונקציות רבות ש-Kubernetes אינו כולל.

לפיכך הכלי שאני ממליץ לדברים אלו הוא OpenShift (גירסה מסחרית) או OpenShift Origin (גירסת קוד פתוח) – של רד-האט. כלי נוסף שאני ממליץ עליו הוא Rancher שיתרונו הגדול על פני OpenShift הוא בכך שזו מערכת Multi Platform.

ניהול תשתיות וירטואליזציה

בין אם יש לכם בחברה OpenStack, קונטיינרים, vSphere, Hyper-V, או תשתית בעננים ציבוריים כמו Amazon AWS, Google Cloud Platform או Microsoft Azure – ניהול דברים אלו מצריך כלי ניהול נפרדים (או במקרה של כלי אוטומציה – כתיבת חלקים נפרדים).

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

חשוב לציין – Cloudforms הוא "כלי מתרחב" – כלומר זהו כלי שניתן להרחבה לא רק ע"י תוספים אלא ע"י כתיבה ב-YAML כל מיני פונקציות נוספות שמתאימים לארגון. רבים מנסים להשוות את Cloudforms ל-"vcenter עם תמיכה בתשתיות נוספות", אך השוואה זו מוטעית. Cloudforms יכול להתרחב בצורה משמעותית בהשוואה ל-vcenter/VCSA והוא כולל מערכת שלמה לביצוע Orchestration, Life Cycle, עמידה בסטנדרטים פנימיים ועוד.

תשתית וירטואליזציה מתחרה

מקודם התייחסתי ל-OpenStack שיכול להתאים להקמת ענן פרטי בחברה, אולם לעיתים חברות מחפשות מערכת "פחות מפלצתית", משהו שיותר מזכיר את ה-vSphere או את ה-Hyper-V. הסיבות יכולות להיות קשורות בתקציב קטן או שאין תקציב גדול להרחבת תשתית וירטואליציה ב-R&D, מעבדות וכו'. איך אמר לי לקוח פעם "תבנה לי מטוס בתקציב של רכב סובארו".

כולם מכירים כמובן את VirtualBox, אך כלי זה אינו מתאים לסביבה מעבר לכמה מכונות VM בודדות שרצות על ברזל יחיד. הפתרון הכי טוב שיש בקוד פתוח הוא oVirt (גירסת קוד פתוח) או RHEV (בגירסה המסחרית) של רד-האט. שתי המוצרים מבוססים על פלטפורמת KVM בלינוקס והמוצרים יודעים לא רק להתממשק לסביבות וירטואליזציה אחרות (במידה וצריך), אלא לעשות את כל מה שמצפים מתשתית וירטואליזציה: Live Migration, Cloning, High Availability, Fault Tolerance, Load Balancing ועוד.

סיכום

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