קטגוריה: לינוקס

טיפים לפרויקטים למערכות משובצות

אם יש תחום שהשתנה מאוד בשנים האחרונות, הרי זהו תחום המערכות המשובצות (Embedded). בשנות ה-90 ועד ועד לעשור האחרון, בתחום זה שלטו מערכות קניינות (היי VXWorks!) והמעבדים היו יחסית די חלשים. לינוקס נכנס לתחום בשנות ה-2000 עם כל מיני פתרונות, חלקן קוד פתוח לחלוטין, חלקן מעורבות בחלקים עם קוד סגור והדברים החלו להשתנות באופן רציני במיוחד ב-5 שנים האחרונות.

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

נתחיל עם המעבדים: אם יש משהו אחד שאני רואה בחברות רבות בשימוש – זה לוחות מבוססים I.MX של NXP (לשעבר Freescale זכרונה לברכה). מעבד זה הוא מעבד כלל לא רע והוא מעולה בפתרונות לוידאו, אך כיום ישנם לא מעט פתרונות מחברות מתחרות שונות שלא רק נותנות את מה ש-I.MX (כולל דור אחרון) נותנים, הם נותנים גם ביצועים יותר טובים וגם מחיר יותר טוב (תלוי כמובן בכמות המוזמנת). מעבדים של סמסונג, קוואלקום, Rockchip, Texas Instruments, Amologic ואחרות מציעות מעבדי ARM שונים בין אם מדובר ב-32 או 64 ביט, עם תמיכה לציודים שונים, כולל התקנים חדשים (כמו פתרונות Wifi בסטנדרטים האחרונים).

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

כיום לעומת זאת, התחרות מ-ט-ו-ר-פ-ת! ה-Raspberry Pi יצא במחיר מגוחך של 35$ והמתחרים הגיבו בהתאם, וכיום אפשר להשיג לוחות עם מעבדים ברמות שונות בפחות מ-150$ (בקצה הגבוה) ללוח שכולל את המעבד, זכרון, כניסות ויציאות ועוד. אף אחד לא האמין שנגיע לסיטואציה הזו.

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

אבל כיום ישנה דרך אחרת שכדאי לתת את הדעת עליה: אם אתם מכינים את המוצר שלכם, סביר להניח שניסיתם אותו בסביבת לינוקס על PC בשלב ה-PoC, וזה מעולה, אבל במקום להתחיל לעבוד על Yocto, אני ממליץ ללכת בדרך אחרת: לרוב המעבדים המודרניים (מבוססי ARM) יש היום גירסת לינוקס כמו אובונטו שקומפלה לאותו מעבד (אם אין, אפשר לבנות עבורכם. צרו קשר). קחו את ה-IMAGE הזה, התקינו אותו על כרטיס מיקרו SD (לפחות Class 10 או U1) והריצו את הלינוקס הזה על הלוח ואז התקינו את מוצרכם על אותו אובונטו שרץ על ה-ARM. זה יתן לכם מושג כללי איך המוצר שלכם רץ על מערכת משובצת. יכול להיות שזה יהיה קצת יותר איטי מבניה מצומצמת (עם Yocto ועל השאר תיכף ארחיב) – אבל זה יכול לתת לכם מושג אם זה רץ ואיך, ולמפתחים זה יכול לעשות את החיים יותר קלים אם הם אינם מכירים לינוקס לעומק בצורה מעולה – כי זה נראה בדיוק כמו דסקטופ לינוקס.

אחרי שהמוצר שלכם רץ על אובונטו מבוסס ARM – יגיע הזמן להתחיל לבנות את ה-IMAGE שאותו תתקינו על ה-eMMC שנמצא על הלוח. כאן מומלץ בשלב ראשון אם אתם עדיין משתמשים ב-LTIB – לצאת לגמרי מהכלי הזה (שוב, הוא מת). אם אתם משתמשים ב-Yocto לבנות Image (עם או בלי ה-BSP של היצרן) הגיע הזמן גם לבדוק חלק נוסף שנקרא Open Embedded – כיום שתיהם משולבים והיתרון הגדול של OE הוא כמות נוספת (ולעיתים נחוצה) של "מתכונים" המאפשרים הוספת חבילות חדשות בעת יצירת ה-Image, שלא לדבר על היתרון הגדול של הכלי smart שנמצא ב-Yocto שמאפשר לכם לבנות עדכונים חלקיים (הן כ-RPM או APT או IPK או OPKG) כך שכשמוצאים חור אבטחה באחת מהחבילות, סקריפט פשוט בתוך המערכת המשובצת שאתם בונים יכול להוריד מהשרתים שלכם עדכון חבילה ספציפית ושימוש ב-smart יכול להתקין את החבילה – וכך אין צורך להוציא IMAGE שלם בגלל חור אבטחה.

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

עוד כלי שכדאי להכיר (ולהפתעתי עוד לא פגשתי חברות שמשתמשות בו) זה Docker לבניית Images. מדוע? כשמריצים Yocto, אין אפשרות להריץ מספר סשנים של Bakebit. לעומת זאת, עם טכנולוגיית קונטיינרים כמו Docker אפשר בהחלט להקים כמה קונטיינרים ולהריץ בכל אחד מהם Bakebit, זה יכול מאוד לסייע אם מקמפלים קוד לכמה מעבדים או לכמה מטרות (Targets) שונות. יתרון נוסף של Docker זה שהכל רץ במהירות טבעית ויש אפשרות מובנית לשיתוף תיקיות (כמו תיקיית Cache ל-Yocto. אגב, טיפ קטן לאלו שצריכים לעבוד המון עם Yocto – להריץ bitbake world בפעם הראשונה, עדיף לעשות זאת בסופ"ש או בלילה לפני שיוצאים – וכך יהיה לכם Cache שיעזור "לאפות" דברים יותר מהר).

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

אין לי ספק שאנשי פיתוח אלגוריתמים ודרייברים הם אנשים חכמים ומוכשרים, אבל במקרים רבים אין להם את הידע שצריך "מסביב". כך לדוגמא, אם יש צורך בכך שהמערכת תציע ממשק Web, ישנם כמה פתרונות. לפעמים יש צורך להציג גרפיקה, ויש הבדל ענקי בין להוסיף Xorg ל-Image או להסתפק ב-Frame Buffer, וישנן עוד מאות דוגמאות שאיש לינוקס רציני יכול להמליץ להוסיף/להחליף במקום פתרון ברירת מחדל (שאחר כך יכול להתגלות כחור אבטחה ענק או כחבילה שלא מתוחזקת ע"י המפתח שלה כבר שנים). לכן, המלצתי היא דווקא במקרים של פרוייקטים משובצים לפצל את המשרה ל-2. תנו למפתח לעשות את עבודתו המקצועית ותנו לאיש הלינוקס לבנות את השאר, בדיוק כמו שתיקחו גרפיקאי ומעצב UX לעצב לכם את הממשק Web ולא תסמכו על המתכנת שיעצב לכם את הממשק.

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

עבודה כ-Devops

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

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

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

שני הדברים שהכי קובעים בקבלת מועמד לעבודה הם ידע ונסיון. כשאדם לומד מ-ספר או קורס, יהיה עדיין חסר לו בין 50-90% מהידע שחברה צריכה. כך לדוגמא מבחינת Troubleshooting – רוב הקורסים בקושי נוגעים בנושא (וברוב עבודות הסיסטם הזמן שנשרף הוא על תקלות, בין אם זה AD שעושה צרות, SQL שעובד לאט, תקשורת איטית, תקלות ב-1001 שרותים ואפליקציות וכו' – ובלינוקס זה יכול להיות תקלות של ביצועי שרותים, שרת שלא עולה, הרשאות לא נכונות, Segfault של אפליקציות ועוד המון המון סוגי תקלות). בקורסים אולי מלמדים אותך איך להקים מערכות ושירותים – אבל בקושי נוגעים ב-Troubleshooting, ולכן חשוב לבדוק כמה שנות נסיון אמיתיות יש למועמד.

בתחום הסיסטם תמיד כדאי שיהיה לך נסיון בשפת סקריפטים כלשהי. בעולם המיקרוסופט כדאי מאוד שיהיה לך נסיון ב-Powershell וגם ב-Batch. בלינוקס – כדאי מאוד שיהיה לך נסיון לפחות ב-BASH ועדיף גם נסיון ב-Python או PHP, כלומר ידע ונסיון בשפת סקריפטים – חובה. ידע בשפת תכנות אחרות – זה פלוס.

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

כמה רחבה? בניגוד לאיש סיסטם, איש Devops הוא בעצם ה"מכתיב" בכל התחומים שקשורים החל משרתים ועד לפיתוח. כך לדוגמא אם איש סיסטם הכיר Puppet לאוטומציה, איש Devops טוב יצטרך להכיר גם Chef וגם Ansible. הוא לא חייב להכיר אותם עד רמת הבורג, אבל צריך שיהיה לו ידע בהרמה לדוגמא של 2 שרתים, "חיבור" למערכת אוטומציה והתקנת שרות כלשהו, לדוגמא. עניין אחר הוא בשינוי מתודת פיתוח אפליקציות של החברה (במיוחד של חברות שנותנות שרותי SaaS לדוגמא) – בעבר חברות היו מפתחות גירסה 1 ואחר כך היו מתחילים לעבוד על גירסה 1.1 או 2. כיום חברות רבות עוברות לשיטה שבה הפיתוח הוא מתמשך ו"נזרק" מיד לפרודקשן לאחר שהוא מתקמפל ועובר סט בדיקות אוטומטי (מה שנקרא CI או Continuous Integration) ובשביל זה קיימים כלים כמו Jenkins. מי שצריך להרים מערכת CI, לכתוב לה סקריפטים, לכתוב בדיקות וכו' – הוא איש ה-Devops.

עדכון: להלן כמה דברים שאנשי Devops כותבים לגבי הנושא:

יבגני זיסלס כותב: "בוא נתחיל מזה שדבאופס, כפי שהגו האנשים שהכניסו לנו את המושג, זה בכלל לא קשור לכלי כזה או אחר. וזה גם לא ״בן אדם״, ז״א אין דבר כזה ״מהנדס דבאופס״ או ״צוות דבאופס״. אבל כמו כשציינתי, ככה מסתכלים על זה האנשים שהגו את המושג. היום יש גם את כל החברות והציידי ראשים והמחפשי עבודה שכמובן רואים את זה אחרת לגמרי, אבל אני קופץ קדימה מדי.
דבאופס לפי ההגדרה הראשונית, זה עניין של תרבות חברה. וכל הכנסים והפרסומים שמבטיחים שדבאופס יתן כל מני אחוזים ענקיים בשיפור העסק, כל זה מסתמך על השוואה של חברות שיש בהן תרבות דבאופס, לבין אלו שאין. אני מזמין אותך לקרוא את סקר ה-״דבאופס״ שחברת פאפטלאבס הכינו ב-2015 ו-2014, וכאשר אתה קורא את התוצאות שים לב שמדובר בתרבות, לא כלים.
אבל בוא נחזור אל מחפש העבודה הממוצע שחושב לעשות תיקון קריירה ולקרוא לעצמו ״דבאופס״. תתחיל בזה שכנראה הוא, והחברה שרוצה לגייס אותו, לא יועץ או פרילנסר. לכן לא באמת יש סיבה למישהו שעובד בחברה שעושה שימוש בשף, שיהיה לו ידע בסיסי בדברים אחרים. וכמובן גם חברה שמחפשת אנשים עם ידע בשף, לא צריכה את אלה שלא מכירים אותו.
עניין הנסיון הוא באמת משחק תפקיד די גדול אצל מישהו כזה שקורא לעצמו ״דבאופס״, אחרי הכל הכלים שאותו אדם טוען לדעת לא טריוויאליים, ולרוב לא היו בשימוש בעבר בשום מקצוע אחר (לא סיסטם ולא מתכנת ולא הלפדסק ולא בדיקות). אז יש כלי חדש, צריך תווית חדשה, ולמזלנו בדיוק הגיע ה״דבאופס״ הזה, אז למה לא. אבל נסיון בשימוש בכלי הוא שום דבר ליד נסיון בהבנה של מערכות, ויותר חשוב, בהבנה של מערכות של אנשים.
אתה בטח מכיר ארגונים שבהם הפוליטיקה שולטת, אז דמיין בן אדם בארגון כזה שיודע להשיג דברים שהוא רוצה שיקרו כאילו אין שום פוליטיקה … זה מיומנות, גם כאן יש אנשים עם נסיון בזה וכאלה בלי נסיון, וגם זה דוגמא לכלי, לא פחות חשוב משף או ג'נקינס.
קיצור, העליתי כמה נקודות, אבל המאמר בא לחזק בדיוק את הדברים שאנשים בעולם ה״דבאופס״ מנסים להעלים." (יבגני גם ממליץ לקרוא את ה-Agile Manifesto וגם את הקישור הבא)

עמוס שפירא כותב: "…בכלל מזה "איש DevOps"? הרי DevOps זה צורת מבט על כל תהליך הפיתוח (Dev) והרצת שרתים (Ops) כשלבים מאד קשורים אחד לשני, לעומת המודלים הקודמים שבהם אנשי הפיתוח לא יודעים כלום ולא מעניין אותם איך הקוד שלהם רץ בשטח והתפקיד שלהם נגמר כשהם " זורקים את הקוד מעבר לגדר" ("chuck over the fence").
מבחינת אנשי סיסטם (ואני לא בטוח כמה זה קשור ספציפית ל-Devops), איש סיסטם עדכני צריך להבין את החלק שלו בכל התהליך מהגדרת המוצר וכתיבת התוכנה (ששם הוא יכול לתרום בהסבר מראש מה הוא צריך כדי לעשות את החלק שלו) וכן לממש "infrastructure as code", אוטומציה של תהליכים, תמיכה בשרשרת הבניה והבדיקות של התוכנה וכו'." (למעוניינים, ישנו שרשור של אנשי Devops המתייחסים לפוסט זה ואנשי Devops מסבירים מה הוא המקצוע)

איש ה-Devops ברמת המאקרו צריך להכיר המון טכנולוגיות חדשות ועדיף שיהיה לו מבחינת שפות ידע ב-Python, JAVA ואם אפשר – גם RUBY (ולאחרונה מה שנהיה פופולרי – שפת Go של גוגל), אך כאן זה לא נעצר – איש Devops חייב להמשיך להכיר טכנולוגיות חדשות בזמן  העבודה או מחוץ לעבודה. מכיר קונטיינרים? אם לא – תכיר. אתה צריך להרים מכונות VM בצורה אוטומטית? תכיר את Vagrant והרשימה ארוכה ומתארכת כמעט כל יום או כל שבוע. כך לדוגמא בעבר אם היה לך נסיון ב-RDBMS כלשהו (החל מ-MySQL או SQL server של מיקרוסופט או Oracle DB) – כיום חברות רבות מחפשות ידע בשרותי DB שמבוססים NoSQL (כמו MongoDB ואחרים).

ואחד הנושאים הכי חשובים שאיש Devops צריך להכיר ברמה מעולה – הם העננים הציבוריים. פחות ESXI/Xen ויותר אמזון AWS, מיקרוסופט Azure, או גוגל Cloud Computing. כל אחד מהעננים הציבוריים מציע עשרות (ובמקרה של אמזון מאות) שרותים שונים ורוב מוחלט של חברות שמציעים שרותים באינטרנט – מארחות בענן ואותם שרותים שמציעים העננים הציבוריים נגישים דרך API או SDK (ומי ש"בונה" על ממשק GUI של ספק הענן – שיקח בחשבון שבמקרים רבים ה-GUI מספק פונקציונאליות פחותה מה-API) ובשביל להשתמש ב-API או SDK – יש צורך בידע בשפות כמו Python או JAVA ובמקרים מסויימים Javascript וידע ב-JSON לדוגמא.

לסיכום: המקצוע של איש Devops שונה מתפקיד של איש System. הוא כולל את התפקיד של איש סיסטם ולוקח אותו כמה צעדים (די הרבה, למען האמת) קדימה. איש Devops להישאר במצב של לימוד X והלימודים הבאים שלו יהיו שנה הבאה אם בכלל. הוא חייב להשקיע המון בלימודים של דברים חדשים. אלו שהתרגלו לעולם של מיקרוסופט יצטרכו לבצע לעצמם הסבה ללינוקס (מה לעשות, אמזון שולטת בשוק הענן הציבורי), הכרת VI (או emacs, לא nano), הכרת רשת על לינוקס, שרותים, סקריפטים ועוד ועוד.

ולאלו שמתעניינים במיוחד בשורה התחתונה של "כמה מקבלים" – באופן עקרוני, איש Devops מקבל יותר מאיש סיסטם, אבל שוב – תלוי כמה נסיון יש. אפשר להגיע ל-30K+ אם יש לך נסיון עשיר ב-Devops, Linux ונסיון טוב עם שרותי ענן של אמזון לדוגמא.

(גילוי נאות: כותב שרות אלו מציע שרותי Devops כפרילאנסר)

על רשיון VDA ועל פתרונות עוקפים

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

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

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

פתרון 1
הפתרון הראשון הוא שימוש במערכת הפעלה של מיקרוסופט המיועדת לשרתים, ו"הפיכתה" למערכת דסקטופ. אפשר לבצע זאת הן על מערכת 2008/2008R2 והן על 2012/2012R2 בגרסאות Standard. מיקרוסופט עצמה מאשרת כי למערכת ש"הומרה" לדסקטופ, אין צורך רשיון VDA (אבל מצד שני גם לא תוכלו להשתמש במערכת הזו למשתמשים רבים אלא אך ורק מכונה פר משתמש). הנה מה שמיקרוסופט כותבת (מתוך ה-FAQ לגבי VDI – לחצו להגדלה)

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

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

הרבה, הרבה מאוד חברות לא אוהבות רעיון ה-VDA. תחשבו על זה לרגע – הדסקטופים שלכם והלאפטופים – בכולם יש Windows ששולם פעם אחת בלבד, וגם הרשיונות למערכות Windows 2012/2012R2/2008 שולמו באופן חד פעמי, ואילו VDA מצריך תשלום כל שנה, ולכן החברות הללו שהיו מעוניינות לחשוב על פתרון VDI פנו הן ל-Citrix והן ל-VMWare למצוא פתרונות חלופיים.

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

ה-VDI שיופעל עבור המשתמש הוא לינוקס לכל דבר ועניין, בין אם זו הפצת RHEL או Centos (גירסאות 6.6 ומעלה) או אובונטו 12 (שאר ההפצות לא נתמכות באופן רשמי אבל מנסיון – אין שום בעיה להשתמש בהן, כולל סביבות כמו KDE, XFCE ואחרות). ההטמעה בלינוקס (במקרה ומדובר ב-Horizon View של VMware, ב-Citrix זה שונה) כוללת התקנת VMWare Tools (ואני ממליץ לא להתקין את החבילה ש-VMWare נותנת אלא את Open VM Tools שזו גירסת הקוד הפתוח שהיא הרבה יותר יציבה, מעודכנת, וגם המהנדסים של VMWare משתתפים בפרויקט והחבילה כלולה בתוך ה-REPO ברירת המחדל של ההפצה), התקנת JRE (כן, ב-VMWare עדיין חושבים שלהריץ JAVA על דסקטופ זה דבר חכם…) ואת ה-View Agent והגדרות נוספות שונות שאיש הלינוקס יצטרך להוסיף. אגב, את עניין הרפליקציה של המכונות (בין אם Linked Clones או Full Clones יש צורך לבצע עם סקריפט שכתוב ב.. Power Shell. לך תבין מדוע..)

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

בשיטה זו – אתם משלמים 0 פר VDI למיקרוסופט (שוב, למעט רשיונות שאתם צריכים לשלם על Published Apps)

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

 

כמה דברים על VDI – תוספות

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

ראשית – השוק בישראל בכל הקשור ל-VDI: ברוב המקרים, השוק בישראל נחלק ל-2: אלו שמשתמשים (ומיישמים) את הפתרון של Ctrix (חלק מקופות החולים לדוגמא), ואלו שמשתמשים בפתרון של מיקרוסופט (רוב חברות הסלולר, בנקים). ל-2 הפתרונות יש חפיפה (פחות או יותר) מבחינת פונקציות כאשר ל-Citrix יש יתרונות כמו:

  • תמיכה הרבה יותר גדולה ב-Clients מסוגים שונים (מטלפון סלולרי ועד כרומבוק, כולל הפצות לינוקס שונות, אנדרואיד, iOS וכו')
  • תמיכה בדסקטופים שאינם מיקרוסופט (דסקטופ מבוסס לינוקס)
  • מוצרים משלימים מהחברה עצמה שנותנים בעצם פתרון יותר "בוגר" כפתרון VDI
  • לא חשוב מה פתרון הוירטואליזציה שתשתמש – בין אם זה Hyper-V, XenServer או ESXi (ואפילו KVM) – ל-Citrix זה לא ממש משנה (אם כי תמיכה רשמית תקבל רק לשלישיה שציינתי לעיל)

מבחינת הפתרון של מיקרוסופט, הפתרון שלהם מתבסס על כך שתריץ את הכל אך ורק תחת הכלים שלהם. וירטואליזציה? Hyper-V. אפליקציות ודסקטופים? תחת שרות RDS בלבד. פרוטוקול תצוגה? RDP בלבד, כך שאם אתם חברה שכבר בין כה מריצים את כל הוירטואליזציה שלכם רק ב-Hyper-V, מעבר לפתרון VDI יהיה קל יותר לכם אם תשתמשו בפתרון VDI של מיקרוסופט (כמובן שתצטרכו תשתית הרבה יותר רצינית מבחינת דיסקים, מכונות ל-compute ועוד – אבל את זה תצטרכו בכל פתרון VDI), כך שהפתרון של מיקרוסופט יותר קל למימוש ללא צורך ברכישת אפליקציות נוספות וכך מיקרוסופט יוצרת "נעילה" אצל הלקוחות והיציאה מה"נעילה" הזו אינה קלה. (אם כי קשה גם לצאת מהפתרונות של המתחרים).

גם לפתרון של VMWare יש יתרונות לא רעים כלל וכלל. יש לך כבר שרתים שמריצים RDS? מצוין, תתקין עליהם Agent של VMWare View והמשתמשים שלך יוכלו להתחבר ישירות לכל האפליקציות שביצעת להן Publish, או למכונות דסקטופ וירטואליות קיימות (אם כי את המכונות דסקטופ הוירטואליות מומלץ לך להקים מחדש עם ה-View). בפתרון של VMWare הקמת מכונות וירטואליות יכולה להתבצע במגוון אפשרויות, החל בהקמת מספר מכונות וירטואליות סטטיות שמשתמשים מתחברים אליהן בצורה קבועה, ועד מצב שהמערכת משתמשת ב-Golden Image שאליו היא מחברת דיסקים זמניים ובכך היא תקים VM חדש בכל פעם שמשתמש עוזב (וישנן אופציות נוספות כמובן) תוך שניות ספורות. גם תהליך העדכון למכונות הוא קל מאוד ותהליך הלימוד של View לא יקח יותר מיומיים (כל עוד יש למנהל פתרון הוירטואליזציה ידע ברמה של VCP). אם יש לחברה סניפים, פתרון ה-PCoIP נותן פתרון יעיל ודינמי (בהשוואה ל-RDP) שיודע להתמודד יפה עם רוחב פס משתנה, עם הצפנה מובנית בפרוטוקול עצמו (גם RDP תומך בהצפנה, PCoIP מוגדר עם הצפנה כברירת מחדל), אין צורך ב-Wan Optimizer (אפשר לקרוא עוד על כך ואפשרויות נוספות כאן), ומבחינת כמות השרתים הנוספת שצריך כדי להקים ולנהל את ה-View עצמו (לא כולל ה-VM של הדסקטופ) – הכמות היא קטנה (יחסית, יחסית).

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

  • מבחינת מחיר (שוב, אינני מדבר על מחירי ברזל מבחינת compute ו-storage – את זה תצטרכו לרכוש בכל פתרון שתבחרו) – הפתרון של מיקרוסופט הוא הכי זול (תצטרכו CAL פר משתמש או ציוד). סביר להניח שתצטרכו לשלם על רשיון מערכת הפעלה לדסקטופ (רשיון ה-OEM לא יעזור למיטב ידיעתי, אבל את הרשיון הזה תצטרכו לשלם בכל פתרון VDI.
  • מבחינת קלות תפעול והקמה, הפתרון של מיקרוסופט קל למימוש, אך גם הפתרון של View קל למימוש ואם אתם כבר משתמשים ב-ESXi, אז תוכלו לבקש ממי שמוכר לכם את הרשיונות מחיר מיוחד (עם האיום של לעבור לשכנים ממול 🙂 ) ובכל מקרה אם תרצו לרכוש את הפתרון של VMWare אל תרכשו את הרשיונות בחנות של VMWare, מנסיון – המחיר יכול להיות נמוך בהרבה מהמחיר המוצג באתר (3000 יורו ל-10 משתמשים בגירסת ה-Enterprise).
  • אם אתם מקום שמשתמש ב-Clients שונים (או חושבים להכניס Clients נוספים חוץ מעמדות PC שיהיו "טיפשות") – אז מומלץ להסתכל על הפתרונות של VMWare ושל Citrix. נכון, הרוב תומך היום ב-RDP, אבל המתחרים למיקרוסופט משקיעים הרבה יותר ב-Clients ממיקרוסופט עצמה, במיוחד בתמיכה בציודים כמו Zero Client או כרומבוקים (פוסט על כרומבוקים בחברות יופיע כאן בקרוב).
  • אם אתם רוצים להעביר סביבות לינוקס ל-VDI (יעיל במיוחד לפיתוח, תוכנות CAD וכו') – גירסה 6 של View והגירסה הקרובה של Citrix תומכות בכך, הפתרון של מיקרוסופט לא תומך בכך.
  • אם אתם רוצים להעביר/להקים מכונות VM שמריצות תלת מימד/עריכת וידאו ל-VDI, הפתרון של Citrix ושל VMWare יתאימו לכך (יהיה צורך ב-GRiD של nVidia לשם כך). הפתרון של מיקרוסופט לא תומך בכך (זה יתמך בגירסה הבאה).
  • אם יש לכם סניפים מרוחקים שמחוברים ב-DSL או בפתרון תקשורת אחרת, פתרון PCoIP יכול להוות יתרון הואיל ואין צורך בפתרונות WAN Optimization.
  • נקודה חשובה: ראיתי את העניין הזה בקופות חולים, בחברות אשראי, בחברות ביטוח, בבנקים וכו' – אם אתם נותנים פתרון VDI, תעיפו את ה-PC והטמיעו Thin Client. מחשב PC צורך יותר חשמל מ-Thin Cliernt במיוחד כשמדובר במאות מחשבי PC בבניין. פתרון Thin Client מבוסס ARM צורך פחות מעשירית ממה ש-PC צריך מבחינת חשמל, ואין צורך בהחלפת מאווררים.
  • אם אתם חושבים על מעבר ל-VDI, כדאי לשקול פתרון מבוסס Hyper Converged, כך שלא תצטרכו להשקיע עוד מאות אלפי דולרים על Storage חדש. ישנם מספר פתרונות כאלו (כתבתי על כך כאן), וכל עוד אינכם "נעולים" אך ורק על Hyper-V, תוכלו להרים 2-3 שרתים כאלו ולראות איך זה עובד מבחינת מחיר וביצועים. אגב, VSAN 6 של VMWare יצא לאחרונה, והתמיכה שלו ב-Flash הרבה יותר טובה (עכשיו הוא תומך ב-Flash לא רק כ-Cache).

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

עוד קצת על KVM

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

לכן בפוסט זה אני אדבר על KVM מחוץ ל-Scope של Open Stack.

הדבר הראשון שחשוב להבין לגבי KVM הוא שבניגוד לפתרונות וירטואליזציה אחרים, KVM אינו פתרון רק עבור X86/X86-64. טכנית, KVM מבוסס על אפליקציה שנקראת QEMU (שאגב, ממשיכה להיות מפותחת וגרסאות חדשות יוצאות תדיר, רק לפני 10 ימים יצאה גירסת RC3 לגירסה 2.3). היחוד של QEMU הוא שאפליקציה מאפשרת לך להריץ מערכות שונות על מעבדים שונים. הדוגמא הכי פשוטה וידועה היא הרצה של מערכת מבוססת ARM על PC (כפי שהיא קיימת באנדרואיד SDK), אבל אתה יכול להריץ גם מערכת Solaris של 64 ביט על אמולציה של מעבד Sparc (במקרה זה Niagra T1) על ה-PC שלך. אתה יכול להריץ גם מערכות שונות של MIPS (שוב, על ה-PC שלך דרך QEMU), ואפשר גם להריץ אפילו מערכת S390s עם Debian לדוגמא. גמישות היא הצד החזק של QEMU.

KVM הוא בעצם "תוסף" ל-QEMU. טכנית, KVM עצמו לא "מכיר" דיסקים, רשת, בקרים וכו', את זה ה-KVM מקבל מ-QEMU. אם נדמה את זה לחומרה, KVM נותן את החלק של ה"מעבד", QEMU את החומרה והשרותים שצריכים כדי להריץ מערכת. ישנם גם חלקים אחרים שיושבים "באמצע" ומאפשרים למערכת לרוץ עם גישת Native, כך שהביצועים עצמם יהיו כמו בהרצת מערכת הפעלה על "ברזל" אמיתי. (כמו VirtIO שנותן שרותי פארא-וירטואליזציה).

הדוגמא הכי פשוטה היא שימוש במעבדים שאינם X86-64, כמו ARM. בזמן הקרוב יצאו שרתים שמבוססים לא על מעבדי Xeon אלא על מעבדים של חברות שונות המבוססים ARM. אחת הפונקציות שחברות רבות רוצות הן וירטואליזציה על אותו מעבד ARM כדי להריץ מערכות הפעלה שונות (נכון, טכנולוגיית קונטיינרים קיימת גם ל-ARM אבל לפעמים יש צורך להריץ מערכת הפעלה עם Kernel שונה), במקרים כאלו ישנה גירסת KVM ל-ARM שרצה על ה"ברזל" ואיתה מריצים מערכות הפעלה אחרות שמבוססות ARM. גם למעבדי MIPS יש KVM.

מהצד היותר "גבוה" יש גירסת KVM למערכות הענקיות של IBM מסידרת System Z (ה-Main Frame), ושוב, גם כאן, ה-KVM נותן לך אפשרות להריץ מערכות לינוקס שונות כאשר כל אחת מהן עצמאית לחלוטין עם Kernel וספריות משלה.

אחד הדברים שאנשים רבים לא מודעים לכך, הוא ש-KVM אינו מתחרה ישירות בפתרונות וירטואליזציה מתחרות כמו vSphere או Hyper-V כפתרון מלא. KVM יכול לרוץ מתוך סקריפט Shell פשוט, וכל עוד יש איזה Image לעשות ממנו Boot (או PXE) וכרטיס רשת (אפשר להשתמש ב-Bridge) בצורה יפה, ללא צורך בניהול כלשהו. אם אתה לעומת זאת מחפש להריץ מספר מערכות KVM על שרת, אז כדאי להשתמש בשרות משלים שמבוסס על ספריה בשם libvirt עם אפליקציות כמו Virt-Manager ועם ספריה כמו libguestfs שמאפשרת לך לבצע פעולות שונות למכונה הוירטואלית ול"דיסק" שלה. ישנן עוד עשרות פתרונות פתוחים או סגורים לניהול מערכות KVM, אך KVM עצמו אינו תלוי בהן, כלומר KVM הוא רק כלי, ולא הפתרון כולו.

הנה נקודה שאולי תעניין אנשים שמתעניינים בהרצה של אפליקציות כבדות כמו פוטושופ, עריכת וידאו או הרצת משחקים: כשזה מגיע לוירטואליזציה ודימוי (Emulate) של כרטיס מסך, הפתרון של KVM הוא פתרון די גרוע בהשוואה לפתרונות כמו VirtualBox או VMWare Workstation או Hyper-V. יחד עם זאת, היתרון הגדול של KVM הוא האפשרות למפות כרטיס גרפי רציני ישירות ל-VM (זה קיים גם בפתרונות וירטואליזציה אחרים, אולם ב-ESXi לדוגמא המערכת לא מאפשרת להשתמש בכרטיסים גרפיים ביתיים למיפוי ל-VM אלא אך ורק את הכרטיסים הגרפיים היקרים), כך שאם לדוגמא יש לך 2 מסכים גדולים שאתה רוצה להריץ עליהם מעת לעת עריכה גרפית או משחק ב-2 מסכים, אתה יכול לחבר מסך שלישי זול לחיבור ה-On-board בלוח האם, ולמפות את הכרטיס הגרפי היותר יקר עם 2 המסכים שמחוברים אליו אל ה-VM. מבחינת ביצועים, ההפרש נמדד באחוזים בודדים בלבד, כך שתוכל להנות מביצועים מעולים, ולאחר שתסיים עם ה-VM, תוכל להמשיך ולהשתמש במסכים לעבודה עם הלינוקס (שימו לב, בשיטה זו ה-VM רץ רק כמסך מלא או מסכים מלאים, לא כ-Window). את אותו טריק, אגב, ניתן לבצע גם עם 2 מסכים בלבד כל עוד מסך אחד מחובר לעיבוד הגרפי שקיים בלוח האם והשני לכרטיס הגרפי העצמאי.

אינני ממליץ לחברות להסתכל על KVM כפתרון חלופי (במובן של Drop-In) למערכות כמו vSphere או Hyper-V. פתרון מבוסס KVM יכול להתאים למוסדות גדולים אם הם משתמשים ב-KVM יחד עם מערכת כמו Open Stack, או שיש להם אנשי לינוקס שיכתבו את הסקריפטים/קוד שידעו להתממשק ל-libvirt ושאר ספריות. KVM יכול בהחלט להריץ מערכות לינוקס ו-Windows Server בלי שום בעיה, אולם אם משווים את זה לפתרונות כמו vSphere, ישנם חלקים רבים מהפצת הלינוקס שאתה משתמש שתצטרך להטמיע אותם כדי לקבל פתרון קרוב וזו לא עבודה שאנשים עם נסיון מועט בלינוקס ידעו לבצע אותה. אם אתם רוצים להטמיע KVM בארגון שלכם, מומלץ להתחיל עם משהו פשוט (וזה לוקח זמן) ורק לאחר שאתם מרוצים, אפשר להתחיל לחשוב על הטמעה של יותר ויותר חלקים (וכן, אפשר להמיר די בקלות מכונות VM מבוססות ESXi ל-KVM. מכונות מבוססות Hyper-V – קצת יותר מסובך). אם אתם רוצים להטמיע פתרון מבוסס KVM ויותר מסחרי מרד-האט, אתם יכולים להסתכל על RHEV (ובגירסת קוד פתוח – oVirt). אם אתם בעניין של Hyper Converge, אז מומלץ להסתכל על הפתרון של חברת Scale Computing.

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

לסיכום: KVM הוא רק כלי. כלי טוב ועוצמתי להרצת VM, אך זהו כלי שצריך להשקיע לא מעט כדי ללמוד אותו ולהתנסות איתו ובתמורה אתה יכול לקבל ביצועים ששווים למה שמקבלים עם ESXi. מכיוון שמדובר רק בכלי ולא בסביבה שלמה, מומלץ להשקיע (למעוניינים) להסתכל על הספריות בקישורים לעיל כדי להיכנס לעולם ה-KVM.

הכנת VM מבוסס לינוקס לשימוש אצל ספקי ענן

חברות רבות משתמשות כיום בשרותיהן של ספקי ענן (אמזון, גוגל, Azure, Rack Space, Digital-Ocean ועוד) ובמקרים רבים אנשים מקימים לעצמם את השרתים בשיטה הקלאסית: בוחרים מערכת הפעלה מהתפריט שהספק מציע (או משתמשים ב-Image שהספק מציע), ולאחר מכן הם מבצעים כניסת SSH, ומשם הם ממשיכים להתקין חבילות, לבצע הגדרות, להעלות סקריפטים, להוסיף משתמשים וכו' וכו'.

שיטה זו היא שיטה מעולה – אם כל מה שיש לך זה שרת יחיד או כמות Fixed של שרתי VM. אחרי הכל, חברות רבות מעדיפות להקים מספר קבוע של X שרתים ועם זה הם יתמודדו, יגדירו Flow וכו'.

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

הבעיה בהקמת שרת נוסף היא הזמן שלוקח לשרת כזה "לקום". הבלוג של חברת Flycops נותן דוגמא מצוינת לכך. במקרה שלהם, כל שרת חדש שהיה מוקם במסגרת ה-Scale Up לקח לו לא פחות מ-6 דקות עד שהוא היה מסוגל לקבל גולשים. זה אולי נשמע זמן קצר, אבל אלו 6 דקות שאתם כחברה תפסידו גולשים שמגיעים מכל מיני מקומות שונים (גוגל, בלוגים, אתרים שמפנים אליכם, לינקים מאימיילים וכו') וחבל.

לכן, במקרים של Scale Up שהמערכת שתשתמשו תרים עוד ועוד שרתים בהתאם לקריטריונים של עומס – כדאי לתכנן מראש Image שתבנו שהוא יעלה, שימשוך הגדרות מסויימות ושיהיה זמין לקבל גולשים.

איך עושים זאת? די פשוט:

  • בשלב ראשון נשתמש במערכת וירטואליזציה שיש לנו מקומית. זה יכול להיות ESXi, זה יכול להיות VMWare לדסקטופ, זה יכול להיות VirtualBox או יכול להיות (ומה שהח"מ משתמש) KVM.
  • נקים Guest חדש ונשתמש ב-ISO של הפצת הלינוקס המועדפת עלינו. מבחינת גודל דיסק, לא מומלץ "להשתולל" (במיוחד לאלו שאינם יכולים להקים מכונה עם Thin Provisioning) – ברוב המקרים 8-10 ג'יגה אמורים להספיק בהחלט. מבחינת Partitions, כל אחד יכול להחליט באיזה שיטה ללכת, עם או בלי LVM. אני ממליץ לבצע Partition יחיד (flat) שהכל ישב שם. חשוב: מבחינת חבילות לא מומלץ להתקין GUI גרפי, זה סתם יתפוס מקום ומשאבים.
  • לאחר שסיימנו עם ההתקנה נפעיל את המכונה הוירטואלית, נתחבר אליה (ב-SSH) ונוודא שיש לה חיבור לאינטרנט.
  • בשלב הבא אנחנו צריכים להתקין את האפליקציות שאנחנו צריכים שיהיו ב-VM. אני ממליץ לבחור באחת מהפתרונות הבאים:
    • יש את Packer (שכתובה ב-Go – תודה לעמוס על התיקון) שאיתה אפשר לבנות את כל ההתקנה שאתם צריכים על ה-VM. היא מתאימה מאוד לחובבי JSON.
    • יש את Cloud-Init שכתבו קנוניקל ורד-האט "אימצה" בשמחה. היתרון שלו שהוא הרבה יותר ידידותי לאנשי סיסטם שלא מעוניינים להתעסק יותר מדי "בקרביים". עם Cloud-init מגדירים מה המשתמשים שיהיו, מה החבילות שצריך, וב-reboot הבא המערכת כבר תעשה את הכל לבד.
      שימו לב: את Cloud-init יש להתקין בתוך ה-VM. מכיוון שהוא נמצא ב-REPO של EPEL, יש לבצע yum install epel-release (לא צריך את ה-URL עם הגירסה האחרונה אם אתם משתמשים ב-CentOS, זה אוטומטי), ולאחר מכן yum install cloud-init.
    • אפשרי לעבוד עם Puppet – כל עוד אתה יודע לעבוד ללא Puppet Master.
    • חשוב מאוד – בצעו update לאחר שהתקנתם את מה שרציתם. המכונות שיבוססו על ה-image הזה ישרתו אנשים מבחוץ ולא נעים לחטוף פריצה רק בגלל ששכחנו לעדכן את כל ה-DEB/RPM.

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

  • כבו את המכונה הוירטואלית וגשו למחיצה שבה היא נמצאת.
  • התקינו את חבילת libguestfs בהתאם להפצת לינוקס שאתם משתמשים בה (מחוץ ל-VM)
  • מכיוון שיכול להיות שהמכונה כוללת דברים שאין לנו צורך בהם (מפתחות שונים שהשתמשנו כדי להעתיק ממקומות אחרים, תעודות SSL, קבצי מטמון וכו') נשתמש בפקודה virt-sysprep כדי לנקות את ה-Image. הריצו את הפקודה virt-sysprep -a image.vmdk (כאשר image.vmdk זהו שם ה-image של ה-VM שלכם). פעולת ה-virt-sysprep תנקה את כל מה שלא צריך וגם תמחק את כל ה-MAC Address שיש לכרטיסי רשת.

לפני שאנחנו מעלים את ה-image לענן, חשוב לבדוק שאתם מגדירים partitions ודברים נוספים (kernel modules, הגדרות שונות) לפי מה שהספק ענן שלכם מבקש, וכל ספק עם השטיקים שלו.

אם אתם משתמשים ב-Ravello (כדי לבצע testing, PoC):
אנחנו צריכים להקטין את ה-image לגודל קטן (מכיוון שהתקנות יוצרות קבצים זמניים שנמחקים, ה-image בעקרון אינו קטן בצורה אוטומטית). לשם כך נשתמש בפקודה virt-sparsify (שוב, לשים לב שהמכונת VM כבויה) בפורמט הבא:
virt-sparsify image.qcow2 final.qcow2
(שוב, image.qcow2 הוא שם המכונה שלכם כרגע, final.qcow2 זה השם image לאחר ההקטנה).

אם אתם משתמשים ב-Google Compute Engine
במקרה זה מומלץ לעקוב אחר ההוראות כאן כיצד להעלות את ה-image ומה מומלץ שיהיה בו.

אם אתם משתמשים בשרות של אמזון
במקרה של שרות באמזון, לצערי בשלב זה הם אינם מקבלים קבצי qcow2 ולכן תצטרכו להמיר את ה-image שלכם ל-VMDK (ההוראות הן כמו הקישור לעיל, רק שבמקום O qcow2- תצטרכו לכתוב
O vmdk- ).

כעת נוכל להשתמש ב-image שהעלינו כ-Template. מומלץ לשמור את ה-image היכן שהוא ולעדכן אותו אחת לתקופה ולהעלות אותו שוב (לאחר שעבר virt-sysprep) לענן ולהשתמש ב-image החדש כ-template.

בעניין Hyper Converged

מי שקורא חדשות טכנולוגיה המיועדות ל-IT/CTO/CIO בוודאי שמע בשנתיים-שלוש האחרונות את המושג Hyper Converged (או HC בקיצור), מושג שיותר ויותר חברות משתמשות בו כדי להציע משהו חדש למנהלי ה-IT.

על מנת להבין את עניין ה-HC, כדאי שנראה מה יש ברוב החברות כיום:

כשזה מגיע לוירטואליזציה (ואין זה משנה איזה פתרון Hypervisor אתם משתמשים), בד"כ יש מספר שרתים שהם ה-Host, והם מחוברים ל-Storage כלשהו ומשתמשים בשרותים כמו NFS או iSCSI (או SMB במקרה של Hyper-V) כדי לאחסן קבצים של המערכות הוירטואליות. במקרים מסויימים משתמשים בדיסקים שנמצאים מקומית בשרת עצמו כשמדובר על שרת (Host) שמריץ מערכות וירטואליות עצמאיות או במקרים שאין Storage גדול רציני.

כשאנחנו מעוניינים ליצור אשכול לצרכים שונים (High Availability, Fault Tolerance וכו'), אנו צריכים 2 שרתים (במינימום) שהם זהים מבחינת החומרה ו-Storage חיצוני שיהיה מחובר ל-2 השרתים, ואנו מגדירים דרך הפאנל של הויראטואליזציה (כמו vCenter או VSA/VCSA) את 2 השרתים כאשכול. יש כמובן "ערימה" של דברים להגדיר כמו סוג האשכול, הגדרות אחסון, כתובות, קבוצות פורטים וכו' – אבל זה בעקרון Cluster.

בשיטת ה-HC הדברים שונים לחלוטין: בשיטה זו אין לנו צורך יותר ב-Storage חיצוני. במקום זה השרתים יהיו עם דיסקים מסוגים שונים (SSD, דיסקים מכניים מבוססי SAS/NL-SAS/SATA) וכל השרתים יהיו מחוברים באשכול למתג של 10 ג'יגהביט (מינימום, כאשר כל הכניסות במתג הם 10 ג'יגהביט). על השרתים מותקנת מערכת וירטואליזציה (בד"כ vSphere אך גם KVM נתמך בחלק מהמקרים) ובנוסף מותקן VM מיוחד בכל שרת פיזי שמתחבר ישירות לדיסקים והוא מנהל אותם (ולא ה-vSphere). בשיטה זו הנתונים נכתבים לכל הדיסקים בכל השרתים והמערכות הוירטואליות רצות על השרתים כאשר האחסון הוא על הדיסקים המקומיים וכש-VM "עובר דירה", חלק מהנתונים עובר מהדיסקים המכניים (האיטיים ויתר) ל-SSD וכך ניתנת לנו האפשרות לבצע Live Migration או כל פעולת High Availability אחרת שנרצה (HA, FT וכו'). במצב כזה (וברוב מערכות ה-HC) אנחנו יכולים לסבול מצב ששרת פיזי אחד נופל מבלי שאף מערכת וירטואלית תיפול.

ישנן מספר חברות שמוכרות מוצרי HC, נתמקד בשלישיה המובילה: Nutanix, Simplivity ו-EVO:Rail.

ל-Nutanix יש פתרונות מ-2 סוגים: הפתרון המבוסס תוכנה (אתה מתקין על השרת שלך) או פתרון חומרה (אתה קונה את השרת מהם), כאשר בפתרון שלהם חייבים לפחות 3 שרתים. ההתקנה עצמה היא קלה (לוקח בערך רבע שעה) ויש לך ממשק GUI נחמד ובנוסף יש לך CLI (שהוא בעצם לינוקס עם אובונטו, ככלל – כל המערכת היא בעצם סקריפטים של לינוקס + מודולים קנייניים שלהם) ויש גם ממשק RESTful API למפתחים. המערכת קלה (יחסית) ללימוד, אך היא אינה מחליפה את הצורך ב-vCenter/VSA אם אתה משתמש בפתרון מבוסס VMWare. ניתן במקום vSphere להשתמש בוירטואליזציה הפתוחה KVM אם כי בשלב זה הם עדיין לא מאפשרים להריץ מכונות VM מבוססות Windows (וגם ה-KVM שיש להם די ישן למען האמת, מגירסת CentOS 6.5).

הפתרון השני הוא של Simplivity וגם הוא מאפשר לך לבצע Cluster אך עם טוויסט מעניין: אתה יכול להוסיף את הענן של אמזון כ"חווה" (DC) משלך ואתה יכול להעביר מכונות הלוך ושוב בין DC שונים, ובנוסף יש לך את הדברים שאתה רגיל אליהם מעולם ה-Storage כמו DeDup, Replication, Snapshots וכו' כאשר הדגש הוא בעצם לא "לחנוק" לך את רוחב הפס בין השרתים שיושבים אצלך בבניין לבין ה-DC האחרים. בניגוד לפתרונות המתחרים, הכמות המינימלית שאתה צריך זה שרת אחד.

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

למי שמעוניין להיכנס יותר לעומק ולקרוא על ההתקנה, השימוש, מה נתמך במה, אני ממליץ לקרוא את המאמר המעולה של בריאן סור על הפתרונות הנ"ל.

אז מה? להתחיל לארגן מכרז למכור את ה-Storage הגדול שלכם? ממש לא.

תחום ה-HC כרגע "שורץ" בפתרונות מחברות צעירות וחברות סטארט-אפ. Nutanix כרגע מובילה את שוק ה-HC עם שיווק מאוד אגרסיבי, אבל הפתרונות שלהם גם מאוד יקרים. כמה יקרים? 6 ספרות במונחים ישראלים ואם תרצה משהו יותר רציני כמו ארון שלם – 7 ספרות. החברות הגדולות המייצרות מוצרי Storage כבר לוטשות עיניים לעבר החברות הקטנות וסביר להניח שנשמע בקרוב על כמה רכישות, ומכיוון שתחום ה-IT הוא תחום שמרני, מומלץ לא לסגור עסקאות עתה אלא להמתין.

תחום ה-HC נותן פתרונות שיכולים מצד אחד לחסוך הרבה עבודה (תקים פעם אחת, תוסיף ניטור משלך ועדכונים מעת לעת – ואתה מסודר. תיאורתית לפחות), אבל מי שוותיק בתחום הזה יכול להיזכר בתקופות קודמות בהן גם חברות מכרו ל-IT מוצרים שנתנו "HC" בתחומים אחרים (זוכרים Self Healing?) וכעבור מספר שנים אותן קופסאות ישבו בחוות השרתים ו… צברו אבק. פתרונות ה-Storage שיש לנו כיום מלכתחילה לא תוכננו לאחסון דיסקים של VM והפתרונות שיש הם (בלי שאף אחד יודה בצורה רשמית) הם "hacks" רציניים (פתרון כמו iSCSI היה בכלל מדובר להתחברות ל-initiator יחיד, בינו ל-LUN שמוגדר ב-Storage, והשינויים ב-VMFS ש-VMWare עשו איפשרו לו להתחבר ל-2 שרתים במקביל, ו-NFS היה צריך גם שינויים ברמת ה-Storage בקוד על מנת לאפשר לו לעבוד טוב מול Hypervisor). פתרון טוב, לעניות דעתי, הוא פתרון Cluster אך מופרד ועדיף פתרון שמקובל על רובם או כולם: פתרון שיתן לנו לייצא מ-Cluster שמיועד ל-Storage איזה Block Device, אבל שיהיה בצורה טבעית ניתן לשיתוף בין Clients שונים לדוגמא, פתרון שאם אני מחבר אותו למערכת וירטואליזציה, שאינו צריך להמתין ל-Acknowledge שהתוכן נכתב לפני שהוא מאפשר למכונה הוירטואלית להמשיך לעבוד כרגיל.  אלו פתרונות שעדיין לא קיימים כיום בצורה יציבה ומלאה (הכי קרוב שידוע לי שקיים – זה Ceph). בעיה נוספת שקיימת עם פתרונות ה-HC הוא עניין הבטחון לגבי העתיד – מה תעשה אם אותה חברה שרכשת ממנה קופסאות מחר תיעלם או שיתגלעו ביניכם חילוקי דעות לגבי מחירי חידוש תמיכה?

ב-The Register הופיע לאחרונה מאמר של טרוור פוט על כך ש-VMWare "מפחדת" מחברות כמו Nutanix שתסחוף את השוק לכיוונה ומכיוון שב-Nutanix הוירטואליזציה היא (כמעט) אינה פתרון רק של VMWare, אז VMWare יכולים להפסיד את השוק וחברות אחרות מתחרות ל-Nutanix יכולות להעתיק את אותה שיטה ושוב – VMWare תהיה בצרות. מבחינתו, כמנהל IT הוא יוכל לעבור בין פתרון אחד לאחר בקלות. זו דעתו כמובן, אך מנסיון שלי כאחד שהקים כמה פתרונות שמבוססים הן על VMWare והן על פתרונות וירטואליזציה אחרים, אני יכול לאמר כי מעבר בין פתרון וירטואליזציה אחד לפתרון אחר אינו קל כלל וכלל ובמקרים רבים התוצאות והתהליך יגרמו אי נוחות למנהל ה-IT, ועוד לא התחלתי לדבר על מעבר מפתרון שיש NetApp (לדוגמא) לכל פתרון אחר, שגם הוא, איך נאמר בעדינות – הדרך אינה סוגה בשושנים.

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

על אחסון וגדילה

כשמדברים על אחסון (כ-Storage), רובנו נתייחס למכונה הגדולה שנמצאת בחברה, ה-Storage הזה שברוב מוחלט של המקרים הוא קופסא של יצרן כלשהו. זה יכול להיות של NetApp, של EMC, של IBM, של HP ושלל חברות גדולות וקטנות, כל חברה בד"כ תקנה לפני הצרכים או לפי ההמלצות, ואצל רובן תהיה "קופסא" אחת כזו שאליה משורשרים "מגשים" של דיסקים. זה יכול להיות דיסקים מכניים מבוססי SAS, דיסקים שהם SSD, דיסקים שהם NL-SAS או אפילו במקרים מסויימים – SATA.

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

מה קורה כשכמות המקום הפנוי היא קטנה? בד"כ מוסיפים עוד "מגש" (במקרים מסויימים זה נקרא גם JBOD) והדיסקים שיהיו בפנים יכולים להיות מסוגים שונים, בהתאם לתקציב ולביצועים שמעוניינים לקבל. הגישה הזו נקראת Scale Up.

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

בנוסף – ישנם 2 בעיות רציניות:

הבעיה הראשונה נקראת SPOF (או Single Point Of Failure): הגדרות שגויות, מעבד שמתקלגל, זכרון שנדפק, בקר שהפסיק לעבוד בצורה תקינה – והפתרון אחסון שלך יתן ביצועים גרועים או שבמקרה הגרוע – יפסיק לעבוד. נכון, יש SLA שסביר להניח שרכשתם ובו טכנאי של החברה המייצרת/יבואן הפתרון יתחבר אליכם מרחוק או יגיע אליכם תוך זמן קצר, אך עדיין, גם אם הוא יתקן את התקלה, תצטרך ברוב המקרים להפעיל את כל המכונות הוירטואליות מחדש, לוודא שכל השרותים למעלה, לוודא שהגדרות שביצעו אנשי ה-IT באמת נשמרו ולא צריכים להגדיר מחדש כדי ששרותים יעלו ובקיצור – כמעט שום תקלה שקשורה לתיקון האחסון אינה מסתיימת בדקות ספורות אלא יותר בשעות.

אם תשאל את יבואן האחסון לפתרון, הוא ישמח להציע לך פתרון של "אשכול" (Cluster): בפתרון כזה אתם רוכשים עוד פתרון אחסון זהה (אם כי אפשר בחלק מהמקרים להסתפק בדיסקים יותר איטיים ו-SSD שישמש כמטמון, תלוי ביצרן, תלוי בדגם) ואז מבחינה תיאורתית אם האחסון הראשי נופל – האחסון השני נכנס לפעולה (מה שנקרא Active/Passive Cluster) ואפשר "לטפל" לדגמים יותר גבוהים שמאפשרים לך בעצם לפצל את העומס בערך למחצית, כאשר 2 האחסונים עובדים ביחד וכל ביט שנכתב – נכתב ב-2 האחסונים. פתרון זה נקרא Active/Active Cluster ובמקרה כזה אם אחד האחסונים נופל, השני ימשיך לעבוד כרגיל וברגע שהאחסון התקול יטופל ויעלה, יהיה סינכרון בין האחסונים. הבעיה הכי גדולה בפתרון כזה – הוא המחיר, והוא מאוד גבוה.

הבעיה השניה שהיא יותר מהותית באותם אחסונים כמו NetApp ואחרים – היא "קניינות" של הפתרון, כלומר שהכל סגור מבחינת ה"ברזל", הדיסקים והמערכות שעובדות בתוכו. אם מחר יפנה אליך לדוגמא יבואן דיסקים ויציע לך מבצע-משוגע של דיסקים מבוססי SAS גדולים במחיר של 3 ותקבל 4 (לדוגמא) – לא תוכל להכניס את הדיסקים הללו לאחסונים הנ"ל. ישנו קוד מיוחד שבודק את הדיסק שהכנסת ל"מגש" וברגע שהוא מוצא שהדיסק אינו מאותו יצרן/סוג מסויים שיצרן האחסון עובד איתו – המערכת פשוט לא תהיה מוכנה להכניס את הדיסקים החדשים שקנית לשימוש. אתה גם לא יכול להכניס JBOD שאינם של אותו יצרן אחסון לשימוש עם פתרון האחסון. בקיצור – הכל צריך לעבור דרך השיווק של יצרן פתרון האחסון שיש לך, והוא כמובן נוקב במחירים הרבה יותר גבוהים ממה שאתה יכול לקנות בשוק החופשי. (אם כי אסייג שבחלק מהפתרון לקצה היותר נמוך, במיוחד פתרונות NAS – אין בעיה להכניס דיסק של כל יצרן, אבל הבעיות של פתרונות כאלו הם עדיין ה-Scaling).

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

מ-Scale Up נעבור למושג שמוכר יותר בתחום ה-High Performance Computing ותחום הענן – זהו תחום ה-Scale Out בפתרונות אחסון.

סביר להניח שלקוראי פוסט זה יש חשבון אחד או יותר אצל אחד מספקי פתרון ענן כלשהו, בין אם זה אמזון , או Google Compute Platform או Azure של מיקרוסופט – ונגזרותיהם: לאמזון יש את S3, לגוגל יש את ה-Google Drive, למיקרוסופט יש את OneDrive ויש גם פתרונות אחרים כמו DropBox ואחרים.

המכנה המשותף לכל אותם פתרונות אחסון קבצים בענן – זה מערכות האחסון שלהם. אף אחד מספקי הענן לא משתמש ב-NetApp או EMC והם לא משתמשים בדיסקים SAS במהירות 15K RPM כדי לאחסן את הקבצים שאתה מעלה (אינני מדבר על אחסון של מכונות וירטואליות או EBS – לזה נגיע בהמשך). במה הם משתמשים? בדיסקים הכי פשוטים שיש (כן, גם דיסקים איטיים). מהי מערכת האחסון שלהם? לכל אחד מספקי הענן יש פתרון In House משלו שהמתכנתים שלו כתבו או השתמשו בפתרון קוד פתוח אחר (אף אחד מהספקים לא מפרט) וברוב המקרים זה רץ על לינוקס. הם כמובן משתמשים בדיסקים של SSD כחלק מהפתרון, ואת השרידות הם מבצעים בכך שהם כותבים את אותו הקובץ למספר מקומות אחרים באותו Data Center. מכיוון שמדובר בפתרון שמכיל מאות אלפי (ויותר) דיסקים קשיחים – הפתרון מבחינה טכנית אצלהם שונה לחלוטין ממה שיש ב-Corporate. אין RAID ברמה כלשהי, ואין מעבדים קניינים מיוחדים בתוך שרתי האחסון (שאליו מחוברים כמות רצינית של JBOD). כך מצד אחד הם חוסכים בהשקעה ומצד שני הם יכולים לתת רמת שרידות מעולה. אחרי הכל, במחיר של דיסק אחד ל-Enterprise אפשר לקנות 3 דיסקים הרבה יותר גדולים מבוססי SATA פשוטים.

כשזה מגיע לאחסון מכונות וירטואליות או אחסון שיותר מוכר כ-Raw Storage – לדוגמא EBS, PD, Drives – בהתאם לספק ענן, גם כאן ספקי הענן לא "רצים" לקנות את פתרונות ה-Enterprise והם מעדיפים פתרונות SSD שהם זולים, גם אם חיי המוצר יהיו קצרים, והספקים משתמשים בכל טריק אפשרי כדי לתת למכונות שלך בענן ביצועים גבוהים (יחסית), אבל שוב -אין שימוש בפתרונות אחסון קנייניים מבחוץ כמו של EMC ואחרים. זה פשוט לא שווה להם פיננסית, במיוחד בתחרות האכזרית כיום שכל ספק חותך בעשרות אחוזים את המחיר והשאר "נגררים" אחריו בחיתוכי מחיר לאחר מספר ימים.

הפתרונות שתיארתי מבחינת ספקי הענן – הם נכללים בקטגוריות ה-Scale Out, כלומר הפתרונות לא מבוססים על שרת אחסון יחיד ואולי עוד Mirror, אלא הם מתחילים ב-3 שרתים ומעלה כאשר העומס מחולק בין השרתים. במקרה של ספקי הענן מדובר כמובן בהרבה יותר מ-3, ומכיוון שהכל נכתב בכמה וכמה עותקים, גם אם יפלו שרתים שמחזיקים מאות דיסקים, אתה לא תרגיש בכלום, כי אתה תקבל את השרות משרתי אחסון שכנים שיושבים באותו Data Center.

פתרונות ה-Scale Out Storage החלו את דרכם בפרוייקטים שמבוססים HPC. בפרוייקטים כאלו יש צורך באחסון כמויות עצומות (פטהבייטים ומעלה) וכל פתרון כזה אם היה מבוסס על פתרון של NetApp או EMC היה גוזל הרבה יותר מדי משאבים כספיים לפרויקט ומכיוון שנוצר צורך בפתרון שהולך וגודל ומצריך המון דיסקים ושרידות מאוד גבוהה – נוצרו פתרונות אחסון מבוססי קוד פתוח שיכולים גם לתת פתרון לפרוייקטים מבוססי HPC וגם יכולים לגדול מיידית ולשרת אלפי ועשרות אלפי מכונות וירטואליות, אחסון קבצים ועוד.

בפוסט הבא אתאר כיצד פתרון Scale Out יכול להתאים ל-Enterprise/Corporate, מהם ה"מועמדים", יתרונות וחסרונות ובמיוחד – על Ceph.

עתיד אמצעי אחסון ב-Enterprise

[stextbox id="info" caption="הערה"]מאמר זה מדבר על הדיסקים/כוננים המשמשים לאחסון ולא על פתרונות כמו NAS/SAN וכו'.[/stextbox]

מבחינת דיסקים/כוננים קשיחים, אנחנו נמצאים בתקופה מאוד מעניינת. ב-15 שנים האחרונות היו שינויים בתחום זה, אך לא שינויים כה מהותיים. רוב החברות בעשור האחרון השתמשו בכונני SAS (ולפני כן SCSI לגרסאותיו) בשרתים, וההתקדמות בכל הקשור לתחום הכוננים המגנטיים – היתה מועטה. היתה קפיצת מהירות סיבוב לדקה מ-10K ל-15K, היו הכפלות כמות אחסון (144G ל-300G ברוטו, 300 ל-600 ומשם ל-900) ופה ושם ראינו גם "נגיעות" של יצרניות הדיסקים בהטמעת פתרון Cache קטן כלשהו בדיסקים.

מבחינת כוננים מבוססי טכנולוגיית Flash, ראינו התפתחות ממצב של "1 ביט בתא" (SLC) ל-2 ביטים ויותר בתא (MLC) (היתה גם קפיצה ל-TLC – של 3 ביטים בתא, אולם הם היו מיועדים לשימוש ביתי/דסקטופ) וגם קומבינציות שיותר מתאימות ל-Corporate כמו eMLC, ואפשר לקרוא על כך בקצרה כאן.

אחד הדברים שחברות רצו בכל הקשור לדיסקים מגנטיים – היו גדלים יותר רציניים. זה נחמד שיש גדלים כמו 150 או 300 ג'יגה, אבל במחשב שלך יושב לו בנחת דיסק של 2-4 טרהבייט. הוא בהחלט לא מתאים ל-Enterprise והיצרניות החלו לקבל שאלות לגבי דיסקים גדולים ב-Enterprise. מכיוון שאי אפשר להכניס פלטות כמו שיש דיסקים של דסקטופ ל-Enterprise SAS ולהאיץ את מהירות הסביבוב ל-15K, הגו היצרניות סטנדרט חדש שנקרא Nearline Storage SAS ובקיצור: NL-SAS.

מהו NL-SAS? אלו דיסקים SATA שמיוצרים בטכנולוגיה שונה במעט מטכנולוגיית הדיסקים לדסקטופ, אך הבקר שיש לאותו דיסק הוא בקר SAS, כך שדברים כמו Command Queue, ערוץ תעבורה כפול ועוד יתרונות שיש ל-SAS – קיימים לדיסקים הללו, אך האמינות שלהם אינה כמו האמינות של דיסקים SAS "אמיתיים" (תוכלו לקרוא על כך יותר כאן). אז נכון, יש פחות אמינות מבחינת שגיאות כתיבה וטיפול בהן בהשוואה ל-SAS, ואין מהירות של 15K סיבובים לשניה (יש דיסקים SATA עם מהירות 10K, אגב, והם יקרים), אבל מצד שני – יש הרבה יותר שטח אחסון בדיסק.

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

טכנולוגיות ה-SSD הלכו והתפתחו יותר ויותר. מהירות ה-SAS (של 6 ג'יגהביט בשניה) נהפכה לצוואר בקבוק ואז הגיעה טכנולוגיית ה-SAS במהירות 12 ג'יגהביט. אם היינו חיים בעולם של דיסקים מגנטיים בלבד, הסטנדרט הזה היה נשאר למספר שנים, אך הסטנדרט הנ"ל לא מחזיק מעמד והיצרנים החלו לפנות לפתרון אחר: ערוץ ה-PCIe X4 (ברוב המקרים הכרטיס הוא בחיבור פיזי של PCIe X8 שהוא יותר סטנדרטי) והכונן כפי שהכרנו אותו הפך לכרטיס PCIe ומכיוון שהחיבור ב-PCIe הוא הרבה יותר מהיר מ-SAS (עם Latency מאוד נמוך), מהירות הכתיבה והקריאה זינקה בפראות למהירויות בג'יגהבייטים, אך אז צצה בעיה אחרת: כמה כרטיסים אתה יכול להכניס בשרת 1U? אולי 2 במקרה הטוב, ואולי 3-4 בשרתי 2U.

NVM_Express_logoהיה צריך פתרון אחר והוא הגיע. הפתרון הוא NVME. טכנולוגיית ה-NVMe בעצם "מורידה" את הפתרון מהצורך ב-Slot פיזי של PCIe ומעבירה אותו בחיבור חוטי על בקר MVNe שיושב בכונן עצמו.

Samsung-XS1715-1.6GB-NVMe-SSD-Connectorכך נראה חיבור NVMe (בתמונה מימין) בכונן של סמסונג בדגם XS1715. כפי שאתם יכולים לראות, מדובר בחיבור שונה לחלוטין מ-SAS או SATA. זהו חיבור בסטנדרט חדש שנקרא SFF-8639 (הוא דומה מאוד לחיבור SFF-8482). היתרונות של חיבור כזה הוא שהוא תואם אחורה ל-SAS ול-SATA והוא משתמש בכל הפינים ה"מיותרים" למימוש חיבור PCIe. (כמובן שיש צורך בכך שלוח האם ידע לתמוך בחיבור SFF-8639). חיבור זה, בשלב זה, יודע לתמוך רק בכונני SSD בתצורה של 2.5 אינטש בעובי 15 מ"מ.

הבה נסתכל על המפרט של ה-XS1715. זהו כונן שמתחרה בדגמים ל-Enterprise כמו של אינטל P3700 או כונן אחר של חברת Micron. להלן הטבלה:

SamsungXS1715-Specs

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

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

סמסונג היתה הראשונה להציג כונן עם נתונים מטורפים כאלו, אך המתחרים לא נמצאים מאחור. אינטל תכריז כבר בקרוב על סידרה P3800 (השמועות מדברות כבר על סידרה P4XXX עם שינויים רציניים וכפי הנראה שגם אינטל תרד מגירסת הכרטיסים) שתתן את אותם ביצועים כמו של סמסונג. סאנדיסק ומיקרון גם יוציאו מוצרים עם IOPS פחות או יותר באותה רמה במחצית השניה של השנה ובינתיים מדברים על כך שלקראת סוף השנה נתחיל לראות כוננים בטכנולוגיית NVMe עם IOPS של 7 ספרות. כל הכוננים הנ"ל מגיעים עם כמות אחסון החל מ-300 ג'יגהבייט ועד 3.2 טרהבייט, וזה עוד לפני שאותן חברות מתחילות להכניס את טכנולוגיית יצור צ'יפים בתלת מימד (שכבה על שכבה, סמסונג משווקת כיום לדוגמא את ה-Pro 850 שמיועד לשימוש Semi Enterprise/Workstation ב-32 שכבות, [גירסא הבאה תהיה כבר לפי השמועות – 128 שכבות] מה שיתן גם ביצועים יותר טובים מכונני SSD מבוססים SLC, וגם אין צורך בליטוגרפיה כה נמוכה – מה שסמסונג משתמשת זה 40 ננומטר)

כך שהמירוץ – בעיצומו, ועוד לא דיברנו על פתרון יותר מדהים – פתרונות SSD שיושבים על .. תושבות הזכרון בשרת. (שוב – Latency הרבה יותר נמוך מ-NVMe של משהו כמו 2-3 ננו-שניות).

אז לאן אנחנו מתקדמים בעצם? לפיצול.

מבחינת עלויות/אחסון – כוננים מגנטיים מבוססי SAS במהירות 10-15K סיבובים לשניה יופסקו להיות מיוצרים במהלך השנים הקרובות (לא השנה או השנה הבאה כמובן) מכיוון שלטכנולוגיה הזו אין ממש המשך. אפשר להאריך לה את החיים באופן מלאכותי בכך שהיצרנים יטמיעו Cache יותר גדול, אך בעידן שחברות רוצות שטחי אחסון יותר ויותר גדולים, ה-NL-SAS וגם כונני SATA יתפסו יותר מקום כשמדובר על אחסון שלא מצריך IOPS מטורף (לוגים, ארכיבאות, גיבויים, וידאו בזרימה). כיום המחיר להרים Cluster לצורך אחסון יורד כל הזמן וישנן מספר מערכות בקוד פתוח (וגם קנייניות כמובן) המאפשרות לך לקבל ביצועים טובים במחיר די זול תוך שילוב כונני SSD להאצת גישה, מהם תוכל לייצא החוצה iSCSI או NFS או SMB לשימושי החברה.

מבחינת עלויות/ביצועים (כן, IOPS) התחרות עושה את שלה ולחברות/יצרני Storage יש מגוון אפשרויות חדשות לבנות מערכות שנותנות IOPS גבוה בהתאם לתקציב של הלקוח, החל מ-SAS, המשך ב-NVMe ועד ULLtraDimm, ורובן יאפשרו ללקוח לשלב מודולים שונים כך שאפשר תמיד לגדול ולקבל IOPS יותר גבוה. שילוב טכנולוגיית התלת מימד ביצור רכיבי Flash מוזילה משמעותית את עלות היצור וכמות הצ'יפים שיש צורך בכונן SSD כזה, ואני משער שכבר ב-3 השנים הקרובות נתחיל לראות תחרות רצינית שתתן גם לחברות הקטנות פתרונות IOPS מכובדים.

טכנולוגיה אינה דת

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

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

ישנם דברים שיכולים מאוד להתאים לאיש IT מקצועי עם שנים רבות של נסיון שפשוט לא יכולים להתאים למשתמשים רבים. אני יכול לתת דוגמא פשוטה: אני כותב את הפוסט הזה עם מחשב ASUS ChromeBox שמריץ את ChromeOS שרוב הזמן אני עובד עליו. מדוע? כי אני מקבל את החוויה של שימוש בכרום תוך 6 שניות מהפעלת המכשיר, אין לי חשש מבעיה של תקלת אחסון (הכל בענן או ברשת) ואין שום דבר שיכול לגרום למכונה הקטנה הזו "להיתקע". אם אני צריך דברים יותר מורכבים, אז אני משתמש ב-Crouton באותה מכונה ואז יש לי בנוסף ל-ChromeOS אובונטו או Debian ובלחיצה על צירוף מקשים יש לי Shell כדי לעשות דברים פשוטים או מורכבים ואני אפילו יכול להריץ אפליקציות Android על ה-ChromeBox הזה ללא צורך במכשיר סלולרי או טאבלט.

האם אני ממליץ את הקונפיגורציה הזו לאנשי IT? אם הם הטיפוסים שאוהבים "לחטט" ו"לשחק" עם דברים – אז כן, בהחלט. האם אני ממליץ להעביר תחנות של מזכירות ומשתמשים קלים אחרים ל-ChromeBox? לא, כי אין עדיין ב-ChromeOS שום תמיכה פנימית ל-Active Directory, לניהול מרוכז עם כלי System Center של מיקרוסופט (שחברות רבות משתמשות בו), אין עדיין מספיק כלים שיכולים להחליף או לתת חוויית שימוש דומה בכלים שיש בעולם של מיקרוסופט למשתמש הסופי. היכן כן אמליץ להטמיע אותו למשתמשי קצה? באותן חברות קטנות שהחליטו להשתמש בשרותי Google Apps (או מה שנקרא היום Google for Work) ושכל העבודה מתבצעת דרך דפדפן. עלויות התחזוקה שם הן מאוד קטנות וגם אם מתקלקלת קופסא כלשהי, שום מידע לא הולך לאיבוד.

דוגמא אחרת היא בתחום הוירטואליזציה. התחום הזה נחלק בין 2 חברות גדולות (VMWare, מיקרוסופט) ויש גם את המתחרים כמו Xen, אורקל (VM Server). בעולם חברות רבות החלו במעבר מוירטואליזציות שרצות מקומית על השרתים של החברה לשרותי ענן כמו Amazon, Azure וגם ל-Google Cloud. בישראל, לעומת זאת, המעבר לשרותים הנ"ל עדיין איטי וחלק גדול מהחברות לא חושבות לעבור (אם כי כן להשתמש בשרותים אחרים כמו אחסון, DNS וכו')

אם אנחנו מדברים על וירטואליזציה, ושוב – אנשי ה-IT שאוהבים "לשחק", אני ממליץ להם על הכרות עם KVM. זו וירטואליזציה בקוד פתוח שנותנת ביצועים כמו ESXI. למי שמצפה ל-GUI כמו שיש עם vCenter (או VCSA/VSA) או כמו כלים של מיקרוסופט – יתאכזב. ה-GUI שיש מהרגע הראשון הוא מאוד פשוט. KVM נבנה יותר לכיוון אנשים שאוהבים Command Line ומכיוון שהוא נכתב כך, ישנם עשרות כלים, חלקם חינמיים וחלקם בתשלום – שמאפשרים לך ניהול של שרתים פיזיים שמריצים KVM. אפשרות שתעניין אתכם אולי זה להריץ את oVirt (המנהל הרשמי להרצת מכונות KVM, זה יותר מזכיר את ה-vCenter). אפשרות נוספת בבית שלכם (אם יש לכם כרטיס nVidia במחשב וגם כרטיס onboard) היא להריץ Windows עם משחקים בביצועים של בערך 95-99% בהשוואה ל-Native. הנה הדגמה:

אגב, ספריה טובה שאני ממליץ עליה (לאלו שכותבים ב-Python, PHP וכו') היא ספריית libvirt. בעזרת ספריה זו אתם יכולים להתחבר גם ל-ESXi, גם ל-Hyper-V, גם ל-Xen, ל-VirtualBox ועוד כמה מערכות וירטואליזציה ולהריץ עליהם אפליקציות שאתם תכתבו, כך שאם יש לכם סביבה מעורבת, ספריה זו יכולה לעזור לכם לכתוב כלים לנהל, לדגום ביתר קלות.

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