המעבר לעננים

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

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

האם המעבר לאופיס 365 תגרום ל-Corporates השונים בארץ לעבור לגמרי לענן? לעניות דעתי – לא כל כך מהר. בשביל Mail, השהיה (Latency) של 100 מילישניות לערך אינה כזה עניין גדול, לא מרגישים את זה, אך כשמדובר ב-RDP או פרוטוקולים אחרים כמו HTTP ואחרים – העניין הופך לבעייתי ובכלל בארץ, בניגוד לסטארטאפים שמתחילים מהדקה הראשונה עבודה על ענן, ה-Corporates מאוד שמרנים ויקח זמן עד שהם יעברו לענן. גוגל, אמזון ומיקרוסופט מודעות בהחלט לעניין, ומיקרוסופט לדוגמא מכינה את ה-Azure Stack – הנה לך אדוני המנמ"ר/CTO "מיני Azure" שכולו יושב ב-Data Center שלך. כל ה-DATA שלך יושב בחווה שלכם ושום דבר לא זז החוצה אם לא תרצה, ואם תרצה – תוכל לחבר את ה-Stack הזה בקלות ל-Azure הענן. גם אמזון התכוננו לרגע הזה והם חתמו עם VMWare על פרויקט חדש שנקרא VMWare Cloud on AWS שנותן לך גם פתרון שמשלב את ה-Data Center שלך עם AWS כך שתוכל להתרחב מה-DC שלך החוצה ל-AWS (והפוך). גם לגוגל יש פתרון שהוא בפיתוח ובשלב זה אין עליו מידע פתוח.

המעבר לענן, לעניות דעתי, לא יהיה שאלה של "אם" אלא "מתי". אני לא צופה שבשנה הקרובה חטיבות ה-Hosting בסלקום/בזק בינלאומי/אורנג'/טריפל C יודיעו בקרוב שהן עוברות להפסדים כי הלקוחות העיפו את השרתים מהן (לזה יקח זמן רב, אם בכלל) – אבל המחשבה והדיבור על מעבר של לפחות חלק מהתשתית לענן ציבורי תעלה שוב ושוב בכל "צומת" שהחברה תצטרך להשקיע סכומים נכבדים ב-IT: רכישת רשיונות למערכות הפעלה, מעבר לסטורג' גדול אחר, הקמת ענן פרטי (כמו OpenStack) וכו'. כמובן שיהיו גם מקרים רבים שגם בעוד 10 שנים השרתים יהיו פה ב-DC בגלל רגולציה במקרים שונים.

ובכל זאת, חברות רבות "מסתקרנות" לגבי מעבר לענן. הסיפורים של כל מיני סטארטאפים איך הם נותנים שרות למליוני אנשים ומשלמים רק כמה אלפי דולרים בודדים בחודש לספק הענן גורם לסקרנות ולרצון להתנסות, המחירים בסנטים גם קורצים לחברה שמסתקרנת רצון לטבול אצבעות, ואז הן הולכות למחשבונים של ספקי הענן ואחרי מספר חישובים הן נרתעות. סתם דוגמא: באמזון, שרת Windows יחיד עם 8 ליבות ו-32 ג'יגה זכרון עם דיסק (EBS) של 200 ג'יגה יעלה לחברה $733 בחודש וזה כמובן לא כולל תעבורה החוצה וגם התמיכה של אמזון היא ברמת הבסיס. זול – זה לא. (אגב, גם בגוגל וגם במיקרוסופט המחיר יהיה פחות או יותר זהה) – אז הרעיון לנסות מעבר כלשהו נכנס בחזרה למגירה.

הרווח הגדול של ספקי הענן הגדולים מגיע מהשכרת שרתים ובמיוחד מהליבות (cores). הם מוכרים כל ליבה במחיר מוערך של 30-50$ לחודש וגם הזכרון אינו זול (בערך 10-20$ לחודש, תלוי בקונפיגורציה, מערכת הפעלה, סוג תקשורת וכו'). מדוע? כי כמות הליבות שניתנת למכירה בשרת אינה כה גדולה. שרת עם 16 ליבות אפשר למכור לדוגמא ל-20 לקוחות שכל אחד מקבל ליבה, אבל לא ל-30 לקוחות – כי הלקוחות רוצים ביצועים (בניגוד לספקי VPS שדוחפים עשרות לקוחות על מכונה עם 8 ליבות). ספקי הענן יכולים לרכוש שרתים עם 8 מעבדים כשכל אחד מהם כולל 16 ליבות לדוגמא, אבל העלות של שרת כזה גבוהה מדי בשבילם ולכן ברוב המקרים אם תבדקו מה המעבד שנמצא במכונה שלקחתם מספק הענן, תמצאו שהמכונה מכילה מעבדים כמו Xeon E5 26XX (כלומר מקסימום 2 מעבדים ועד 8 ליבות פר מעבד, ברוב הזמן זה יהיה דגם של 4 ליבות). יש לספקי הענן גם מכונות עם מספר מעבדים וליבות גדולים, אך המחיר – גבוה בהרבה מהמחיר שציינתי.

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

אז איך לדוגמא חברת X תוכל להתנסות בענן ציבורי מבלי לשרוף אלפי דולרים בחודש על PoC?

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

אחרי שפתחנו חשבון אצל ספק הענן, נצטרך לבחור מה הפרויקט שאנחנו הולכים להעביר ואלו VM הולכים לעשות מעבר, והכי חשוב – כמה ג'יגהבייט/טרהבייט אתם הולכים להעביר לספק ענן. אם מדובר לדוגמא בג'יגהבייטים בודדים או עשרות בודדות של ג'יגהבייט, אפשר להעלות את קבצי ה-VM דרך האינטנט, אך אם מדובר בעשרות או מאות ג'יגהבייט או יותר – כדאי להשתמש בשרותי ה-import/export Disk של ספק הענן, כלומר תצטרכו להכין דיסק קשיח (או פתרון אחר בהתאם לספק הענן) ולשלוח אותו לפי הוראות ספק הענן. המחיר – דווקא די זול, בסביבות ה-80$ ועוד 2.50 דולר פר שעת עבודה להעלאת הנתונים (אמזון לדוגמא).

לאחר שהנתונים יועלו לספק הענן, נצטרך להתחיל לבנות את התשתית המאובטחת שלנו מבחינת כתובות IP פנימיות, Subnet, Internet Gateway וכו' וכו' ולהחיל אותם על ה-VM שלנו שבענן (אצל חלק מהספקים יש צורך בהקמת ה-VM מהגיבוי שהעלתם/שלחתם, אצל חלק זה אוטומטי). אחרי שיש לנו את ה-VM למעלה, יכול להיות שנצטרך לשנות כתובות IP בהתאם לתשתית שהגדרנו. המטרה הסופית היא שבסוף כל ה-VM ששלחתם יעלו ותהיה לכם תקשורת אליהם בדיוק כמו שיש אצלכם ב-DC (אם כי ישנם שינויים שתצטרכו לעשות, כמו לא לתת כתובת IP חיצונית לכל שרת אלא לעבוד בצורה מסודרת מול Gateway או עם Bastion אם אתם עובדים עם מכונות לינוקס). הכל עובד? מצוין. בשלב זה תתחילו לעבוד עם המערכת כמו שהיא בימים או שבועות הקרובים. קיבלתם קרדיט, זה לא עולה לכם שקל, נצלו את זה 🙂

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

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

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

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

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

ולמי שמעוניין לעבור את התהליך או לקבל יעוץ – אשמח לסייע 🙂

על CI/CD ועל Jenkins

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

נתחיל בהסתכלות על המצב ה"קלאסי" של פיתוח, אצל חברות שמפתחות תוכנה המשווקת לציבור. בחברת הפיתוח יושבים כמה מפתחים וכל אחד (או קבוצה) אחראים לפיתוח חלק כלשהו. GUI, לוגיקה, ועוד ועוד. כל קבוצה (או יחידים) מפתחים בנפרד ובסוף יום (או כמה פעמים ביום) כל אחד מעלה את הקוד שלו למערכת SCM (ר"ת Source Code Management) ואחת לזמן מה מגיע החלק הקשה – איחוד הקוד של כל האינדיבידואלים או הקבוצות השונות לקוד אחיד למה שיהיה בהמשך גירסה חדשה של התוכנה. באיחוד כזה מתרחשים הרבה קונפליקטים מבחינת קוד – אחד שבר (בטעות) קוד ישן, השני הגדיר דברים בצורה שונה והקוד שלו בעייתי לאיחוד, ויש עוד שלל בעיות באיחוד קוד (שלא לדבר על ההערות שנזרקות…) שנכתב לאורך תקופה ללא איחוד. אלו כמובן בעיות שיש להן פתרון (במיוחד עם GIT..) ולכן עולה השאלה "בשביל מה אנחנו צריכים CI/CD אם אנחנו לא סטארט-אפ?"

ל-CI/CD (ר"ת של Continuous Integration ו-Continuous Deployment בהתאמה) יש (די בצדק) שם שמתאים לפיתוח בדרכים של ASD (ר"ת Agile Software Development) או בשם יותר ידוע – XP (ר"ת Extreme Programming), מה שדי מרתיע חברות פיתוח "קלאסיות" מאימוץ CI/CD, אבל יש יתרונות גדולים ל-CI/CD:

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

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

נכיר בקצרה את Jenkins. מערכת Jenkins נוצרה ב-2005 ע"י מפתח שעבד ב-Sun ו-Sun שחררה את הקוד לקהילה והמוצר עבר שינויים שונים במהלך חייו והיה נקרא Hudson. ב-2011 חברת אורקל (שרכשה את SUN) הצליחה להסתכסך עם קהילת המפתחים בקוד פתוח ולפיכך המפתחים החליטו לקחת את הקוד ולפצל (Fork) את המוצר ולתת לו שם חדש: Jenkins.

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

אחרי שהקמנו מערכת Jenkins, אנחנו מתחילים להשתמש בה והעבודה ב-CI/CD מתחילה עם המפתחים. אחרי שהמפתחים דחפו את השינויים מגיע תור ה-CI Server או במקרה שלנו – Jenkins לעשות את העבודה. ניצור JOB שבו בעצם אנחנו מגדירים ל-Jenkins מה לעשות. מהיכן לקחת את הקוד, מה לקמפל, ומה לעשות עם הקבצים (כמו לדוגמא האם להעביר אותם בדיקת סגנון קוד עם SonarQube לדוגמא) להעלות אותם ל-Artifactory, לשרת אחר וכו'.

מבחינת המפתחים, כשעובדים ב-Continuous Integration כל מפתח כותב את הקוד שלו, מוריד את הקוד של האחרים מה-SCM, משנה את הקוד שלו בהתאם על מנת לאחד אותו עם השאר, מריץ קוד בדיקות (Unite Testing), ולאחר שהקוד עבר בהצלחה בדיקות מקומיות, הוא מבצע Push ל-SCM. את התהליך עושים מספר פעמים ביום בכל פעם שכותבים חלק, לדוגמא – כותבים פונקציה חדשה, משפרים משהו קיים, מתקנים באגים וכו'. משם Jenkins ימשיך את תהליך ה-CI אם נגדיר לו מתי (אם לבדוק את ה-SCM אם מישהו ביצע commit לדוגמא, או לפי שעון).

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

מכאן אנו עוברים לחלק של ה-CD או ה-Continuous Deployment: קימפול והכנת קבצים בינאריים וחבילות זה טוב – אבל צריך לעשות עם זה משהו…

ב-Jenkins יש לנו "צינורות" (Pipelines) ועם הפונקציונאליות הזו אנחנו נגדיר ל-Jenkins מה אנחנו הולכים לעשות עם הקבצים הבינאריים. אנחנו יכולים לדוגמא להגדיר בצינורות לזרוק את הקבצים הבינאריים בשרת טסטים, להריץ טסטים שונים (Unit tests, Selenium ועשרות סוגים שונים של בדיקות, תלוי בקוד, פלטפורמה וכו'). לאחר שהקבצים עברו בהצלחה בחינה, אנחנו יכולים להורות בצינור לבצע Deploy של החבילות בשרת "מראה" של פרודקשן להתקין את החבילות ולהריץ בדיקות שונות נוספות. לאחר שגם כאן הבחינות עוברות, אפשר להורות בצינור להטמיע את החבילות החדשות בשרתי הפרודקשן באופן אוטומטי או לפי הוראה של המפתחים/מנהלים.

כך נראית החלוקה בין CI ל-CD

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

בסופו של יום, לקוחות דורשים מיצרניות התוכנה והשירותים דברים רבים והם מעוניינים במענה מהיר ואם הם לא מקבלים, הם לא מתביישים להתחיל לבדוק את הפתרונות של המתחרים (תשאלו את Pay pal) ואף לעבור למתחרים, מה שעלול לגרום הפסדים כספיים. עבודה ב-CI/CD יכולה לעזור בקיצוץ הזמנים באופן ניכר.

מה לגבי מתחרים ל-Jenkins? ישנם לא מעט מתחרים ל-Jenkins בשוק (הנה לדוגמא טבלת השוואה קצרה בין ל-Jenkins ו-2 פתרונות אחרים מובילים, החלק של Open Source לא כל כך עדכני לגבי המתחרים), אך הבעיה הראשונה של רובם שהם פתרונות SAAS, כלומר שהמערכת אינה נמצאת אצלך בשרתים אלא אצל חברה אחרת ואתם משלמים לה. זה יכול להיות פתרון טוב אם הקוד כולו מהרגע הראשון הוא קוד פתוח, אולם מצד שני – אני לא מכיר הרבה חברות שיש להן קוד סגור שמעוניינות לבצע Build אצל חברות זרות. יחד עם זאת, כמובן – יש ויש.

מבחינת תאימות פלטפורמות – Jenkins הוא קוד פתוח מ-א' ועד ת' והוא רץ יפה מאוד על Windows (לא צריכים Windows Server), מק וכמובן לינוקס. הוא תומך בכל שפה, ויש לו יותר מ-1200 תוספים שונים שכוללים תמיכה בכל SCM, בכל קומפיילר, אותנטיקציה, אחסון וכו'. יחד עם זאת, כדאי לקחת בחשבון שלא כדאי "לערבב" – אם לדוגמא הקוד שלכם כתוב ב- #C, הקימו את Jenkins על Windows, אך אם אתם כותבים בשפות אחרות שרצות על לינוקס, עדיף להרים את ה-Jenkins על לינוקס הואיל ותחזוקת האבטחה הרבה יותר קלה.

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

[stextbox id="info" caption="הערת מפרסם"]הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.[/stextbox]

כשרוכשים SSD לשרתים

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

אחת הבעיות שיש כיום היא שלרבים אין כל כך מושג מה זה אומר SSD. כולם כמובן יודעים שדיסק קשיח מכני הוא דיסק המורכב ממספר פלטות, ראשים מגנטיים, ובקר בתוך הדיסק עם זכרון מטמון קטן (בין 16 ל-256 מגהבייט, תלוי בדיסק ולאיזה שוק הוא משוייך כמובן). כולם יודעים שכשזה מגיע לשרתים – אתה צריך בקר RAID טוב, חלקם ירכשו בקר עם סוללת גיבוי וזכרון מטמון נוסף – והעיקר כשרוכשים דיסקים מכניים – חשובה מהירות הסיבוב (10,15K RPM), חשוב סוג החיבור (SAS, SATA) ועוד כמה פרמטרים קטנים כמו PMP, Dual Connection וכו'.

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

מאמר זה יתן מספר מושגים לגבי תכנון ורכישה של דיסקים SSD. בכדי להתחיל אני ממליץ לקרוא את המאמר הזה באתר של Seagate. המאמר הזה מסביר איך מאוחסנים הנתונים, מה זה "איסוף זבל" (Garbage Collection), מה זה Over Provision (בקיצור: OP) ומה היתרונות. המאמר קצת ישן וחלקו לא עדכני לגבי הטכנולוגיות כיום, אבל הוא מצליח להעביר את המידע בצורה קלה ולפיכך הוא מומלץ לקריאה ע"י כל איש IT/איש סיסטם ללא קשר למערכת ההפעלה.

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

תכנון ראשוני

כשאנחנו רוצים לקנות שרת עם דיסקים מכניים, ההחלטה על כמות הדיסקים היא די קלה. אנחנו מחליטים איזו תצורת RAID נשתמש (1,10,5,50 וכו') וכמות המקום הרצויה לפי חישוב ה-RAID. אחרי שאנו יודעים על כמות המקום שאנו רוצים, אנחנו בוחרים בהתאם לתקציב את גודל הדיסקים, מהירות, סוג חיבור, בקר RAID יעודי בחלק מהמקרים וכו'. מכאן אנחנו ממשיכים בבחירת חלקים אחרים (מעבדים, זכרון, תקשורת, גודל שרת מבחינ U וכו')

כשזה מגיע ל-SSD, התהליך הוא שונה לחלוטין.

הדבר הראשון שאנחנו צריכים לדעת זה מה השרת עומד להריץ וגם מהו יחס הכתיבה/קריאה. לא חשוב אם אתה צריך 2 טרה מקום או 50 טרה מקום – זה הנתון הכי חשוב. מדוע? מכיוון שישנם 3 סוגי SSD בכל הקשור לעומס העבודה.

Read Intensive

ב-Read Intensive מדובר על כך שהשרת יותר יקרא מידע מה-SSD מאשר יכתוב ביחס של 70% קריאה, 30% כתיבה. לדוגמא: אם יש לנו שרת SQL מפלצתי שמכונות אחרות מחוברות אליו ורוב הזמן קוראות ממנו מידע ופה ושם גם כותבות מדי פעם רשומות – אנחנו נבחר SSD שהוא Read Intensive (רוב דגמי ה-SSD בשוק שיותר זולים הם Read Intensive)

Mixed Intensive

כשיש לנו שרת שמבצע כתיבה וקריאה (ביחס של 50% קריאה 50% כתיבה) אנחנו נבחר SSD שהוא Mixed Intensive. דיסקים כאלו מתאימים למצבים שבהם אנו לא רק קוראים הרבה, אנחנו גם כותבים הרבה. לדוגמא: אם יש לך מכונת ESXi עם דיסקים SSD מקומיים ואתה בכל יום מוחק כמה VM ויוצר VM חדשים (Full Clone או מ-אפס) אז דיסקים כאלו יתאימו לסיטואציה הזו.

Write Intensive

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

כמות המקום שאנחנו צריכים

כפי שציינתי לעיל, בדיסקים מכניים כמות הדיסקים שנצטרך לרכוש תלויה לפי חישוב ה-RAID ולפי חישוב הדיסקים. נניח שבדיסקים מכניים אנחנו צריכים RAID 5 ו-10 טרהבייט מקום, אנחנו נרכוש 6 דיסקים שכל אחד מהם הוא 2 טרה או 11 דיסקים של 1 טרה (פחות או יותר, דיסקים SAS מגיעים בגדלים ש"קופצים" ב-300 ג'יגה, אז אנחנו בעצם נרכוש 12 דיסקים של 900 ג'יגה שיתנו לנו ברוטו של 9.9 טרה).

גם כאן, ב-SSD החישוב שונה. כשיצרן מצהיר על גודל דיסק SSD לדוגמא בגודל 1.2 טרהבייט, הדיסק בעצם בגודלו האמיתי הוא 1.4 (בערך) טרהבייט, רק שהיצרן שומר מקום ל-Over Provisioning (אזור בדיסק שבו אנחנו לא נשתמש אך הבקר הפנימי ב-SSD כן ישתמש לצרכיו), אולם יש יצרנים שמציינים את הגודל כ"ברוטו", כלומר דיסק SSD של 500 ג'יגהבייט אולם הכמות כוללת את ה-OP.

כלל האצבע שאני ממליץ הוא "לחתוך" מהדיסק בערך כ-10-20% כך שמתוך 1 טרהבייט, ישארו למערכת 800-900 ג'יגהבייט. כך אנחנו נמשיך לקבל לאורך זמן ביצועים טובים מה-SSD. במבט ראשון זה נראה כמו "מכה" (בכל זאת, אם קנית 10 דיסקים של 1 טרהבייט, אז "זרקת" 2 טרהבייט וזה עוד לפני חישובי RAID!), אבל ה"מכה" הזו משתלמת לאורך זמן.

נקודה חשובה נוספת (שגם לא ממש תהיה קלה לעיכול): לא למקסם את המקום בדיסק, הווה אומר – אם אנחנו מגיעים ל-60-70% ניצול של המקום הפנוי, הגיע הזמן לעשות דיון ברכישת דיסקים נוספים. ככל שתגיעו למספרים גבוהים יותר (80% ומעלה) הביצועים ירדו.

כמות כתיבה יומית

דיסקים SSD אינם כמו דיסקים מכניים שאפשר לכתוב עליהם חופשי כמה שרוצים. הבקר שב-SSD לא רץ כל שניה לכתוב את קובץ ה-10K שכתבתם כרגע. הקובץ ישב בזכרון (DRAM) של ה-SSD ובפעילות הכתיבה הגדולה הבאה הוא יכתב, כך שבקר ה-SSD עושה את הכל כדי לחסוך בפעולות הכתיבה. לעיתים הוא דוחס מידע, ולעיתים הוא עושה פעולות אחרות (תלוי בבקר SSD). לפיכך, אחד הפרמטרים החשובים שאנחנו צריכים לדעת הוא כמה בהערכה גסה אנחנו הולכים לכתוב על הדיסק ביום. האם אנחנו הולכים לזרוק על דיסק 500 ג'יגהבייט כ-300-400 ג'יגהבייט ליום? או שאנחנו אולי נכתוב כמה עשרות ג'יגהבייט מקסימום ליום? המושג נקרא DWPD והוא ר"ת של Disk Write Per Day, והוא מציין במספרים כמה פעמים אתה יכול לכתוב על כל הדיסק ביום. דיסקים SSD פשוטים נותנים לדוגמא משהו כמו 0.3. שימו לב: אם אתם "חונקים" מדי יום את הדיסק בכתיבות, אתם עלולים לגרום לאחריות שלכם להסתיים הרבה יותר מוקדם ולכן חשוב לבדוק את הנושא כשבוחרים דיסקים SSD.

SAS? SATA? NVME?

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

אני מניח שחלק מהקוראים כרגע כבר אומרים לעצמם "בשום מצב לא SATA". אין לו Queue לפקודות SCSI, ויש הרבה דברים של-SAS יש ושלא קיימים בפרוטוקול SATA וזה נכון אבל אם תסכלו בקטלוגים של SSD ל-Enterprise תמצאו שחלק נכבד מהדיסקים הוא בחיבור SATA (במהירות של .. 6 ג'יגהביט). מדוע? מכיוון שאותו "תור" וריבוי ערוצים שנמצא ב-SAS מתאים לדיסקים מכניים שבהם כמות ה-IOPS שאנחנו מקבלים היא מקסימום תלת ספרתית מאוד נמוכה (סביב ה-120-150 IOPS) וריבוי ערוצים מעלה את זה ל-300 IOPS ויותר – אבל עדיין תלת ספרית, אך דיסק SSD בחיבור ה-SATA הפשוט נותן IOPS של 5 ספרות, כלומר מה שלא מקבלים בריבוי ערוצים, מקבלים במהירות.

דיסקים מבוססי NVME הם בעצם כרטיסים שמתחברים בחיבור מיוחד שנקרא U.2 (לשעבר SFF-8639) ל-PCIe בלוח האם, כלומר אלו דיסקים עצמאיים (תיכף נגיע לזה) שאין בינם לבין SSD אחרים מבוססי חיבור NVME – שום דבר. נסו לדמיין שאתם מכניסים 2 כרטיסים גרפיים ללא SLI. אותו דבר.

מה שמביא אותנו ל….

RAID

כשזה מגיע לדיסקים SSD מבוססי SATA, הסיפור פשוט. מחברים ל-RAID שבלוח האם או לכרטיס בקר יעודי (שימו לב להגדרות Cache בבקר, בחלק מהמקרים עם דיסקים SSD SATA שונים יתכן ותצטרכו לבטל את ה-Cache). מגדירים את הדיסקים לפני כן ל-OP שאנחנו קובעים (אני ממליץ לחשוף את הדיסקים כ-JBOD ב-RAID, להעלות לינוקס מ-CD או כרטיס SD ולעשות זאת עם פקודת hdparm ורק אז לבנות בבקר RAID את ה-RAID שאתם רוצים תוך כדי שמוודאים שהבקר "רואה" את הדיסק בניכוי ה-OP שהגדרתם) ומתחילים התקנה של המערכת שאתם רוצים.

הנה טיפ קטן: לא להגדיר דיסקים SSD כ-RAID-5,6,50,60 אלא אם אתם רוצים נחיתה מאסיבית בביצועים. היצרנים ממליצים RAID-0, RAID 1 או מקסימום RAID-10 (לעשירים מביניכם).

כשזה מגיע ל-NVME לעומת זאת תצפה לכם הפתעה. אין RAID. גם אם ממש תרצו, אין RAID בחומרה (למען האמת יהיה בקרוב, חברת AVAGO מוציאה צ'יפ לזה אבל גם אז אל תצפו לביצועים משהו, דיסקים SSD בחיבור NVME יודעים לחנוק DMI בקלילות). מדוע אין? כי אלו SSD שיכולים "לחנוק" את ה-DMI בקלילות. SSD מבוסס NVME מעביר בממוצע כ-2 ג'יגהבייט בשניה (אם תתנו לו סיבה) וה-DMI 3.0 שקיים בשרתים מודרניים יכול מקסימום להעביר 3.93 ג'יגהבייט בשניה, כלומר מספיק 2 דיסקים SSD בחיבור NVME "לחנוק" את השרת.

אז מה עושים עם השרידות? חושבים קצת אחרת. בדיסק SSD בחיבור NVME ל-Enterprise יש שרידות הרבה יותר גבוהה בהשוואה לדיסקים מכניים. "סקטורים" פגומים? הבקר ידע להעביר לבד את הנתונים לאזור תקין. יש Fragment? הבקר ידע להעביר בזמנו החופשי את הנתונים ולסדר אותם (במסגרת ה-Garbage Collection). הפסקת חשמל? יש "סופר קבלים" על ה-SSD ששומרים את המידע על ה-DRAM עד שהחשמל חוזר. בקיצור (ואני אומר את זה מנסיון) – יקח לכם המון המון מאמץ להרוס SSD מבוסס NVME שמיועד ל-Enterprise. בגלל זה האחריות עליהם היא ל-5 ולחלקם 10 שנים.

נקודה חשובה נוספת: הפופולריות של NVME עברה "מתחת לרדאר" של יצרני שרתים. (הח"מ סיים לפני מספר ימים שיחות עם נציגי חברת SuperMicro כדי שיוציאו כרטיס PCIe עם PLX כך שניתן יהיה לחבר 4 דיסקים SSD עם NVME למכונת PC. בשרתים זה יותר מסובך כי ה-Backplane לא "יודע" מה זה חיבור U.2) ולכן רובם מאפשרים גם במכונות החדשים מספר קטן של כונני SSD בחיבור NVME. ב-DELL ו-HP כמדומני המקסימום הוא 4 דיסקים והשאר SAS מכני או SATA מכני או SSD. לכן אם אתם רוצים מכונה שתהיה "מפוצצת" ב-SSD בחיבור NVME, צרו קשר עם חברת SuperMicro לדוגמא.

לכן, אם אתם מתכננים לדוגמא להרים ESXi עם NVMe, תשכחו מ-RAID. (מה לעשות, ESXi לא תומך אפילו ב-RAID תוכנה, לא חשוב כמה תנסו). או שתשתמשו בדיסקים SSD בחיבור SATA או שתבנו Datastores שונים על כל NVMe ומשם תרפלקו לכם עם Veeam או כל תוכנה אחרת VM חשובים.

חסכון

(הנה מילה ששומעים הרבה ב-IT ומצווים לכך … ותמיד אפשר לשמוע על איזה מנהל שהחליט לקנות מפלצת שהניצול שלה יהיה 10% ממה שהיא יכולה לנפק)

הבדל המחירים בין SSD לצרכן לבין SSD ל-Enterprise הוא הבדל שנע בין 50-300%. עם SSD שהוא NVME בחיבור PCIe אתם בקלות מגיעים לאלפי דולרים עד עשרות אלפי דולרים וכמובן שהדיסקים האלו נותנים ביצועים מהממים – IOPS של 6-7 ספרות, אבל מה לעשות שברוב המקרים תגישו הצעת מחיר כזו והמנהל יתהה לגבי בריאותכם הנפשית.

ה"סוד" הגדול וההבדלים לדוגמא ב-SSD בין גירסת הצרכן לגירסת ה-Enterprise נעוץ במספר דברים:

  • גירסת ה-Enterprise כוללת "סופר קבלים" לשמירת הנתונים שעדיין לא נכתבו – בעת נפילת מתח
  • בגירסת ה-Enterprise – השבבים שעליהם נשמרים המידע הם בתצורת MLC (למי שלא ידע, SLC כבר מת) או eMLC.
  • בגירסת ה-Enterprise – הבקר הוא הרבה יותר חכם
  • בגירסת ה-Enterprise – הם מוצעים גם בחיבור SATA וגם כ-NVME (כאשר יש תהום של ביצועים בין ה-2)
  • בגירסת ה-Enterprise – האחריות היא בין 5 ל-10 שנים.

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

  • כדאי ללכת על שבבים שהם 3D NAND (כמו של סמסונג או טושיבה) כל עוד מדובר על MLC. ליצרן זה חוסך שבבים והמחיר יורד. אם מדובר על מכונה שרוב הזמן יקראו ממנה, אפשר גם לבחור SSD שיהיה מבוסס על צ'יפים שהם TLC אך כדאי לזכור – במקרים כאלו הכתיבה תהיה איטית (יחסית).
  • אם יש UPS – אז נוכל לוותר על ה"סופר קבלים"
  • אפשר להסתפק גם ב-1-3 שנים של אחריות במקרים מסויימים.
  • חיבור SATA מספיק

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

העתיד

כשזה מגיע להתפתחות טכנולוגיית ה-SSD, אפשר לאמר שהיא מתפתחת בקצב מהיר. אינטל וחברת מיקרון עובדות על XPoint – טכנולוגיה שתתן ביצועים פי כמה וכמה מהירים מכל SSD שקיים כיום. סמסונג עובדת גם על פתרון שתחשוף אותו בסוף השנה או בתחילת השנה הבאה (עקב NDA אינני יכול לפרט), וגם טושיבה, WD/Sandisk עובדות על טכנולוגיות אחרות לשמירה/קריאת נתונים הרבה יותר מהירות מכל שבב FLASH NAND שקיים כיום. כל החברות במקביל עובדות על טכנולוגיות תלת מימד (3D) עם מספר דו ותלת ספרתי של שכבות על מנת להוציא SSD עם הרבה יותר מקום (סמסונג הוציאה לאחרונה דיסק של 15 טרהבייט במחיר "עגול" של … $10000).

אחת הטכנולוגיות החדשות שבקרוב "תסתער" על השוק (במיוחד שוק הוירטואליזציה, קונטיינרים ועוד) היא טכנולוגיית ה-MVMEoF (כלומר NVME Over Fabrics). כיום, כשאנחנו רוצים לייצא חלק מהדיסקים לשרתים, אנחנו עושים זאת בעזרת טכנולוגיות כמו NFS, SMB או iSCSI אך איננו מקבלים את כל המהירות ש-SSD בחיבור NVME מקבלים. עם NVMEoF המהירות שנגיע לנתונים תימדד בננו שניות, כאילו הדיסק יושב פיזית במכונה (כמובן שלשם כך יהיה צורך בהחלפת תשתיות – 40 ג'יגה Ethernet כמינימום, כרטיסי רשת שמבצעים Offload ל-TCP כמו של מלאנוקס ואחרים) ויש עוד כמה דברים בצינור.

עוד תחום נוסף מעניין הם דיסקים SSD חדשים ש"ישתפו פעולה" עם מערכת ההפעלה ויתנו למערכת ההפעלה בעצם לנהל את הדיסק ובכך להעביר את רוב הלוגיקה של הבקר – למערכת ההפעלה. הפרויקט נקרא Open Channel SSD והמימוש שלו נמצא בקרנל 4.4 בלינוקס (עדיין לא ב-Windows). עדיין אין כוננים כאלו אך כל היצרנים משתתפים בפרויקט.

לסיכום

דיסקים SSD הם ההווה ועתיד. זה כמובן לא אומר שדיסקים מכניים הולכים למות (רחוק מכך, הם מצטיינים בגדלים ובמחירים זולים יותר מ-SSD, כרגע לפחות) אבל מצד שני טכנולוגיית ה-SSD עברה את סף ה"נסיון" והיא יציבה יותר מדיסקים מכניים, שלא לדבר על כך שמבחינת מהירות כתיבה וקריאת נתונים – היא עוקפת כל דיסק מכני גם בחיבור SAS. ה-SSD גרם לטכנולוגיה חדשה כבר למות (SATA Express) וטכנולוגיית ה-NVME מחברת את ה-SSD (דרך U.2 או ככרטיס PCIe או בחיבור M.2 – פוסט על M.2 יופיע בקרוב) ישירות ללוח אם תוך עקיפת צורך בבקר כלשהו או בצורך "מנהל" כלשהו – ה-SSD מבוסס NVME עושה הכל, (רק כדאי לוודא שה-BIOS/UEFI תומך ב-NVME) – והיא נותנת ביצועים שנמדדים בג'יגהבייטים תוך מתן עשרות אלפי IOPS.

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

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

כמה מילים על Thin Client ל-Citrix

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

ל-2 סוגי הפתרונות הנ"ל יש יתרון בכך שקל יחסית לנהל אותן, הן מבחינת הגדרות מערכת, והן מבחינת נעילה וכו', אולם ישנן כמה נקודות שכדאי לתת עליהן את הדעת:

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

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

כיום ישנו גם פתרון שהוא יותר זול.

למי שלא מכיר – זהו ה-Raspberry Pi-3 (מודל B). זהו מחשב בגודל קטן מאוד עם כמות זכרון של 1 ג'יגהבייט והוא מריץ מערכת Linux ויש לו גם Client מלא ל-Citrix עם כל הפונקציות פעילות. הוא יכול לשמש בעקרון כ-Thin Client מאוד זול ולהתאים לחברות…

… בערך …

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

תכירו את Viewsonic SC-T25: זהו המוצר של חברת Viewsonic ובתוכו יש בדיוק את אותו Raspberry Pi-3 Model B, אך כאן מדובר למוצר שמיועד לחברות. יש לו מערכת הפעלה לינוקסאית הכוללת ניהול מרכזי והמכשיר תומך בכל הפונקציות של Citrix. המכשיר ישווק בקרוב במחיר הכרות של 89$ לקופסא (בחו"ל).

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

דוגמא אחרת שחשובה לאבטחה וקשה לבצע בקופסאות סגורות אחרות: רוב הקופסאות מגיעות עם 4 כניסות USB אבל המשתמש מנצל רק 2 (מקלדת, עכבר) או 3 (כרטיס חכם או מתאם USB->Serial). נשארה כניסה אחת או יותר פתוחה ואנו רוצים לנעול על מנת שהמשתש לא יכניס ציוד לא מורשה. בעזרת סקריפט פשוט (דוגמא: כאן) אפשר לכבות את הכניסות האלו כך שגם אם יוכנס ציוד, המערכת לא "תראה" אותו ולא ניתן יהיה להפעיל אותו, וניתן להוסיף עוד 1001 דברים שירוצו על הקופסא או מחוץ לקופסא כדי להרחיב את השימוש בהתאם לצרכי החברה. (אגב, בקרוב ל-Pi תהיה תמיכת PXE כך שלא יהיה צורך לעדכן שום דבר בקופסא. מכבים, מדליקים, הקופסא מוכנה לשימוש).

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

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

[stextbox id="info" caption="הבהרה"]לי אין קשר ל-Viewsonic או ליבואן ופוסט זה נכתב מהאספקטים של לינוקס, אבטחה וניהול יותר קל של Citrix Clients.[/stextbox]

כמה מילים על ניטור

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

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

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

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

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

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

עד כה דיברתי על 2 סוגי ניטור:

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

יש עוד סוג של ניטור שיכול לעזור לחברות שיוצרות המון קבצי לוגים (החל מחומות אש, IPS/IDS, אפליקציות שונות, בנקאות וכו'). במקרים כאלו, אפליקציות כמו שציינתי לעיל לא יסייעו. מישהו נניח חדר למערכת. דרך איזה פורט הוא נכנס? מה כתובת ה-IP שלו? מה הוא עשה? במה הוא השתמש? אלו פרטים שכל מערכת בטחון תדע. אם יש באג באפליקציה, מה הפלט שמופיע בלוג? איך ננתח את כל הלוגים מעשרות שרתי Web ושרתי אפליקציה?

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

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

מערכות משובצות: ללכת באופן מסודר

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

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

מנסיוני בתחום – כדאי לעשות את הדברים בצורה אחרת לגמרי. נכון, לפעמים יש אילוצי זמן, Time to market וכו', אבל אם ניקח את ההשקעה הכספית בהבאת יועץ חיצוני או מתכנת חיצוני (ב-2 המקרים זה לא זול) בשביל שינסה לעשות משהו שקשה עד בלתי אפשרי לעשות – נראה שבסופו של דבר היה עדיף מלכתחילה לשנות את הדרך ולהתחיל .. הפוך

הדבר הראשון שיש למצוא הוא "מה צריך כח?". לדוגמא – אם הקופסא תשמש כנתב, אז רכיבי הרשת צריכים יחס מיוחד ואסור לסמוך על מה שיצרן ה-SoC נותן בצ'יפ. צריכים לטפל בתעבורה של 1 ג'יגהביט לדוגמא? כדאי וצריך לצייד את הלוח בצ'יפ רשת יעודי (עם שאר החלקים). דוגמא אחרת: צריכים ראיה ממוחשבת שתדע למצוא עצמים במהירות פריימים גבוה? אז אתם צריכים GPU חזק שמגיע ברוב המקרים יחד עם CPU חזק (כדאי לשים לב: במקרים כמו של מעבדי אינטל, לדוגמא סידרת Atom X3/X5/X7 – אתם תקבלו מעבד בהחלט חזק בהשוואה למעבדי ARM בינוניים, אבל בכל מה שקשור ל-GPU, כל מעבד ARM בינוני עם Mali 500 ומעלה עוקף אותו). עוד דוגמא היא עניין המצלמות: מצלמות סיניות פשוטות לא יעשו את העבודה, ומצלמות שמוציאות YUV (ושאר פורמטים קרובים) רק יקטינו את כמות הפריימים שתוכלו לעבד עם תוכנות ראיה ממוחשבת.

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

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

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

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

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

[stextbox id="info" caption="גילוי נאות"]כותב שורות אלו נותן שרותי אינטגרציה למערכות משובצות[/stextbox]

על Ransomware והתגוננות מפניהם

עדכון 1: כשהכופרה מעיפה את VSS (בסוף הפוסט)

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

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

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

  1. פריצה חמורה אירעה בשרתי צד ג' שנותנים שרותי פרסום לאתרים גדולים ודרך פירצה זו הופצו סקריפטים שרצים בדפדפן שמחפשים כל סוג פריצה שקיים לדפדפנים שונים, ל-Flash, ל-Java ו-JS ושאר דרכים – כדי להוריד אוטומטית Ransomware למשתמש וכדי לגרום לו להריץ אותו. כל מה שהמשתמש היה צריך לעשות זה פשוט לגלוש לאתרים הגדולים (כמו New York Times, BBC, AOL, MSN ועוד) והסקריפט שהיה נטען לדפדפן המשתמש היה כבר רץ ומחפש פירצה.
  2. עד כה רוב תוכנות ה-Ransomware היו משתמשות במפתח פרטי קבוע שהיה חלק מחבילת ה-Ransomware, ולאחר זמן מה יצרני האנטיוירוס ידעו לזהות את המפתח ולהציע ללקוחותיהם דרך לחילוץ הקבצים מבלי לשלם כופר. לאחרונה הדבר שונה ובחלק מתוכנות ה-Ransomware המפתח הפרטי נוצר כל פעם מחדש ומועלה מיד לשרת של התוקף ונמחק מהמחשב, כך שלא ניתן אם הותקן Ransomware כזה לחלץ את הקבצים משום שמדובר במפתח 256 ביט שכיום עדיין אף אחד לא פיצח (אולי ה-NSA הצליחו אבל הם לא מפרסמים כלום בנידון כמובן), כך שמחשב פרטי או מחשב בעסק שחוטף Ransomware כזה, הדרך היחידה לחלץ את המידע – היא לשלם את הכופר לתוקף..

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

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

ניתן לעומת זאת להשתמש בשיטה ותיקה שמיקרוסופט המציאה ממזמן (והורידה חלק מהפונקציונאליות בחלונות 8/8.1 אך החזירה ב-10) והיא ה-Volume Shadow Copy (בקיצור: VSS). בשיטה זו המערכת שומרת Snapshot על כל הקבצים המקומיים (לא ב-XP, שם יש שמירה על קבצי מערכת, לא על תכנים כמו מסמכים וכו')

במידה ובמחשבים מותקנים דיסקים קשיחים, ניתן ליצור Partition נוסף שעליו ישבו ה-snapshots (כדאי לעיין במאמר הזה כדי לבצע את הדברים) או שניתן לבצע Snapshot למערכת NAS (על כך בהמשך) וכך ניתן גם לשחזר קבצים את Snapshot של ה-Volume (עוד פרטים כיצד לבצע mount ל-snapshots ולחלץ מידע – ניתן לקרוא כאן).

אם התכנים נשמרים ב-SAN או NAS, כדאי להפעיל את תכונת ה-Snapshot ב-Storage עצמו (חפשו Volume shadow או VSS) ואז את השחזור ניתן לבצע ישירות מתחנת המשתמש (או ב-Storage, לפי הצרכים). יש לוודא ששרות ה-VSS נראה בתחנת המשתמש (בתחנות מבוססות חלונות 7 ובגרסאות חלונות 8 PRO וכו' אפשר להשתמש בכלי כמו Shadow Explorer לשם כך).

שרתי לינוקס שמשרתים תחנות Windows דרך SAMBA: אם הנכם משתמשים ב-LVM אז תוכלו לבצע Snapshots ולשקף אותם דרך smb.conf בשרת כך שניתן יהיה לשחזר קבצים. ניתן לראות איך לבצע זאת כאן. אם הינכם משתמשים בשרותי ZFS על לינוקס/BSD או סולאריס, אין שום בעיה להשתמש ב-Snapshots שמיוצרים ע"י ZFS ל-SAMBA ואפשר לקחת סקריפט מוכן עם הוראות בקישור כאן.

לסיכום: נזקי כופרה יכולים ליצור כאב ראש לא קטן, במיוחד שאין גיבוי עדכני, אז כמובן שצריך לוודא שגיבויים מבוצעים תדיר (ונבדקים תדיר – הדבר האחרון שאתם צריכים זה גיבוי לא קריא בעת חרום). מומלץ לבדוק ולהשתמש בשרות VSS. נכון, השרות די מוגבל (לא ניתן לבצע את גיבוי ה-VSS לרשת) אבל הוא יכול לשמש כפתרון זול על מנת למגר נזק מכופרות. אם אתם מציעים למשתמשים אחסון תוכן בכונני רשת, ודאו כי ל-storage יש snapshots שניתן לגשת אליהם דרך אפשרות ה-Restore to Previous Versions (אם אין, אפשר לתת למשתמשים Shadow Explorer או לכתוב סקריפט ב-PS שיאפשר שחזור).

כשהכופרה מעיפה את ה-VSS: כפי שציין הגולש גיא אדרי בפורום, רוב הכופרות עוצרות את שרות ה-VSS ומוחקות גיבויים (בהנחה וביטלתם את ה-UAC). במקרים כאלו מאוד מומלץ לחשוב לעבור לכונני רשת שיאחסנו את התכנים (לא את האפליקציות וכמובן לא את ה-SWAP). במידה ואין תקציב לסטורג' לדבר כזה, ניתן לבנות סטורג' זול שיארח כונני רשת (יש לדאוג ל-2 כונני SSD ב-RAID-1 שישמשו כ-Cache קריאה/כתיבה ל-RAID פנימי שיורכבי מדיסקים SATA או NL-SAS). אותו שרת יכול להריץ שרות SAMBA, להתחבר ל-AD ועל השרת הזה ניתן ליצור כונני רשת ולבצע Snapshots לכונני הרשת עם LVM או עם ZFS. במקרה התקפה של כופרה, היא לא יכולה למחוק את ה-Snapshots של כונני הרשת, ניתן גם לבצע Snapshots בתדירות גבוהה (עם ZFS בלינוקס או סולאריס או BSD אפשר גם כל 10-15 דקות וניתן להשאיר כמות גדולה של Snapshots מבלי לחשוש לבעיות ביצועים), כך שבסופו של דבר אם כופרה תוקפת, אפשר לשחזר את המחשב מ-IMAGE, למפות את כונן הרשת, ולשחזר מה-snapshot את כל התוכן אל ה-share של כונן הרשת.

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

אם יש תחום שהשתנה מאוד בשנים האחרונות, הרי זהו תחום המערכות המשובצות (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 – לחצו להגדלה)

מי משתמש בטריק הזה? חברה אחת שאולי שמעתם עליה בשם .. אמזון, שמציעה שרותי דסקטופ תחת השם 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 כל הזמן.

 

Exit mobile version