האם תוכניות DR באחסון ישראלי שוות את הכסף?

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

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

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

מכיוון שיש ערימות של פלטפורמות ופתרונות DR שעובדות ומסנכרנות נתונים בדרכים שונות, אתאר את התהליך באופן כללי: אחרי שרכשנו את הציוד, ומתוך הנחה שהחברה משתמשת בוירטואליזציה, אנחנו נתקין את מערכת הוירטואליזציה הבסיסית (ESXI) בשרתים ולאחר שמכונות הסטורג' יסתנכרנו, נחבר דרך ה-vCenter את הסטורג' לשרתים, נגדיר את המתגים, כתובות IP ועוד ועוד. אחרי שמסיימים את הכל, התוכנה שמבצעת את עבודת הרפליקציה בין הסטורג' בחברה לחווה – ממשיכה לעבוד 24/7 וברוב הזמן היא מרפלקת לכיוון אחד (כי בצד של החווה אף אחד ברוב הזמן לא עובד על השרתים, עד למצב חרום או "תרגיל"). ברוב המקרים כשתהיה נפילה, פתרון תוכנת ה-DR ידע לשנות את הפרמטרים הנחוצים על מנת לאפשר עבודה מול החווה של בזק.

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

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

מבחינת מחיר – אכן, עננים ציבוריים אינם דבר זול, אך בניגוד לתוכנות DR רבות, ב-AWS עם שימוש פלטפורמה כמו CloudEndure, אתה יכול לבחור אלו מכונות להעביר לענן בפקודה (או בקליק פשוט) וכל עוד יש בחברה ידע בשימוש AWS לדוגמא, כל תהליך ה-DR יקח מספר שעות (תלוי ברוחב הפס שיש לחברה). עלות השרות היא 99$ למכונה + עלות המכונה (Instance) עצמו כפי שניתן לראות כאן. וכאן ניתן לראות הדגמה של גיור מספר מערכות לענן של אמזון עם CloudEndure.

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

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

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

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

לסיכום: ענן ציבורי צריך לעניות דעתי להיחשב כאופציה נוספת לפני שמחליטים על תוכנית DR, איזה DRaaS וכו'. המחירים יקרים – כשמשלמים לפי שעה (אם לדוגמא משלמים מראש ל-3 שנים, יש עד 75% הנחה פר VM באמזון, לדוגמא). אין צורך לרכוש ציוד נוסף ותלוי בתהליך ה-DR שבחרתם, הוא יכול להתבצע תוך זמן קצר או כפרויקט. יכול להיות שההצעות מספקים מקומיים יהיו יותר זולים, אולי כדאי לחשב את הדברים מראש כתשלום ל-3 שנים ואז להשוות (שימו לב: כל ספקי הענן, ברוב המקרים, ישמחו לתת לכם אלפי עד עשרות אלפי דולר כקרדיטים לשנה הראשונה, כך שזה יכול בהחלט להשפיע על מחיר וההחלטה). אל תקשיבו לאלו שישר פוסלים הצעות של עננים ציבוריים, עדיף שיהיו בידכם המספרים המדוייקים והמעודכנים – ואז תוכלו להחליט.

(גילוי נאות: "חץ ביז" מציע את שרותי ה-DR לעננים ציבוריים)

כמה מילים על WSL 2

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

מיקרוסופט בשנים האחרונות ביצעה כמה שינויים על מנת לכלול תאימות למערכות אחרות. כך לדוגמא ה-command prompt הישן קיבל מתיחת פנים הן ב-Power Shell ומאוחר יותר גם בתאימות להצגת טרמינלים מרחוק (בחיבור SSH או Telnet). זה לא היה מושלם – אבל זה היה צעד חשוב, במיוחד כשמיקרוסופט החלו לשלב גם SSH Client בתוך Windows 10 לגרסאותיו השונות.

בכנס Build האחרון מיקרוסופט הציגה את ה-Windows Terminal שלה – שיפור משמעותי לעומת ה-CMD הישן והקונסולה של PowerShell. הפעם יש טאבים, תמיכה ב-Emoji, קאסטומיזציה ועוד ועוד. בקצרה זה נראה כך:

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

מכאן נעבור לנושא הפוסט: WSL 2.

למי שאינו מכיר, WSL (ראשי תיבות Windows Subsystem for Linux) זו מערכת שמיקרוסופט פיתחה שמשתלבת עם ה-NT Kernel (כן, Windows 10 מבוסס על NT, כמו רוב גרסאות ה-Windows בשנות ה-2000). המערכת הזו משמשת כ"מתרגם" מה-API של ה-Linux Kernel (גירסה 4.4 של ה-Linux Kernel) ל-NT API. בנוסף, המערכת גם דאגה להרשאות מיוחדות של קבצים ותיקיות כך שלא היה צורך ליצור Partition של לינוקס מצד אחד, ומצד שני קבצים בינאריים של לינוקס לא יכלו לרוץ על Windows שלא מותקנת בה WSL. כל הקונסטרוקציה הזו נועדה לתת מספר דברים:

  • לאפשר לבנות הפצות לינוקס ידועות שירוצו ישירות עם ה-WSL ללא צורך במערכת לינוקס ב-VM
  • לאפשר להריץ אפליקציות לינוקס בהתאם להעדפות שלכם.
  • אין צורך בלשלב קוד GPL כמו ה-Kernel לתוך המערכת.

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

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

התוצאה: WSL 2.

השינוי המהותי עם WSL 2 שהפעם יש מעין "מיני VM" קטן שעושה Boot ומטעין גירסה מאוד מקוצרת של ה-Kernel, אך ללא ה-1001 דרייברים שמגיעים עם ה-Linux Kernel וכל הדרייברים הנחוצים שלינוקס צריך – הוא מקבל אותם דרך דרייברים Paravirtualized (קצת מזכיר את ה-VMWare Tools שמתקינים). כך, מצד אחד ה-Kernel רץ בצורה מבודדת כ-VM קטנטן, ומצד שני מיקרוסופט לא צריכה להסתבך עם ה-GPL: הם ישחררו את שינויי הקוד שהם צריכים לשחרר ואין נגיעה ישירה לקוד של Windows.

בשיטה הזו, ה-WSL 2 מקבל מספר דברים:

  • אפשרות להשתמש בגירסת Kernel מודרנית (אני מאמין שמיקרוסופט תוציא מסמך איך לקמפל קרנלים משלך לשימוש ב-WSL 2)
  • אפשר להשתמש בדברים כמו cgroups, להריץ קונטיינרים (docker, cri-o וכו')
  • כל גישת ה-File/Directory תעבור דרך דרייבר שמיקרוסופט תשחרר ש"ידבר" עם NTFS, ומיקרוסופט טוענים כי בדיקות שלהם מראות כי הביצועים משתפרים פי 20 בהשוואה ל-WSL 1.
  • יותר אפליקציות יוכלו לרוץ.

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

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

על VDI ולקוחות שונים

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

בתחום ה-VDI, יש 3 פתרונות ש"שולטים" בשוק: Horizon של VMWare, ה"סלט" של Citrix (כמו Xen Desktop יחד עם כלים אחרים) וכמובן הפתרון של מיקרוסופט. בכל הפתרונות ניתן או "לפרסם" אפליקציות כך שיצוצו כחלונות נפרדים המציגים אפליקציה בלבד או שניתן להקים מכונות וירטואליות ועליהן "להלביש" פרופילים, ויש כמובן את שיטת ה"ערימות" – הקמה של מספר מכונות VM שמשוייכות קבוע למשתמש פר VM.

בהינתן החומרה הנכונה וההגדרות הנכונות, כל הפתרונות יכולים לתת תוצאות מעולות בכל מה שקשור ל-VDI, החל מרמת הפקידה שמשתמשת באופיס ודפדפן וכלה במשתמשים שצריכים להריץ אפליקציות תלת מימד. כולם תומכים בהאצת GPU (למעט מיקרוסופט שירדה מ-RemoteFX ב-Windows Server 2016 והולכת להוציא משהו בקרוב שיקרא GPU-P לצרכים של גרפיקה למשתמש מרוחק).

כל החברות הגדולות במשק משתמשות כבר בפתרון VDI או "מעין VDI". לכו לכל נציגות סלולרית בקניון ואתם תוכלו לראות במסכים של המוכרים חיבור RDP לחוות השרתים של אותה חברת סלולר. על המחשב המקומי לא רץ כמעט כלום (אגב, בלא מעט מקרים אותן חברות גדולות מוותרות על רכישת Thin Client יעודי מכיוון שזה יותר זול להן לרכוש PC בקצה המאוד נמוך עם Windows). רוב המשרדים הממשלתיים, חברת החשמל וכו' משתמשים ב-Citrix לצרכי VDI. חברות גדולות אחרות שלא ממש משתמשות ב-VDI הן חברות השיווק הגדולות (שופרסל, רמי לוי וכו') בקופות הרושמות (כולל הקופות החדשות לשרות עצמי) – שם עדיין יש PC עם דיסק קשיח שמטעין שורת אפליקציות לאחר שה-Windows עולה. אחד הדברים שגיליתי לאחרונה זה שכשבמשרד ממשלתי (נניח רשות המסים) אם ה-Thin Client שלהם (שמשום מה מטעין Windows 10 בזמן Boot, כך שאני לא בדיוק יודע למה הם צריכים Thin Client) לא מצליח להתחבר ל-Store Front של Citrix וזה קורה לכולם באותו סניף – אז הם פשוט מפסיקים לקבל לקוחות ובאותו יום אין עבודה. ברשת שיווק שמרוויחה כסף מכל לקוח, סיטואציה כזו היא הסיוט הכי שחור להנהלה, ולכן לא נראה לי שבעתיד הקרוב הם יעברו למשהו כמו VDI.

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

מדוע שהם בעצם ירכשו? בגלל ש-PC יכול להתקלקל? כיום אפשר ב-500-700$ להשיג PC פשוט בקצה הנמוך (כולל זכרון ו-SSD במקום דיסק מכני), וכל מה שנותר לעשות זאת להעביר את ה-DATA (כולל OS) ממערכת ישנה לחדשה ואולי להתקין דרייברים. בגלל גיבויים? אפשר לקנות NAS קטן, להתקין תוכנה כמו Macrium Reflect שתגבה את כל המכונות לאותו NAS. העלות של כל העניין ממש שולית.

היכן עסקים קטנים כן ירצו להקשיב ליתרונות VDI ולהטמעתם? רק כשהדברים הבאים ימולאו:

  • מחיר – זול. הפתרונות של Citrix ו-VMWare עפים ישר מהחלון. של מיקרוסופט – אולי.
  • שקט – תתפלאו בכמה משרדים אין ממש בידוד למחסן שאפשר להכניס שם שרת 1U או 2U, ובמשרד די שקט, רעש כזה בולט (יש לי כמה כאלו פה בבית, מנסיון!)
  • שרות ותחזוקה ל-3-5 שנים, בלי זה אין על מה לדבר.
  • עלות חד פעמית – לא רשיונות בתשלום חודשי. (ביי ביי nVidia ו-Grid!)
  • שרות ותמיכה מקומיים ובעברית.

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

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

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

כמה מילים על Microsoft SQL 2017 ללינוקס

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

אתחיל במידע כללי: מדוע מיקרוסופט בעצם שחררה את שרת ה-SQL שלה ללינוקס? התשובה די פשוטה: להתחרות מול אורקל ולהציע לחברות שמריצות לינוקס בפרודקשן בגלל היציבות – את שרת ה-SQL שלהם. בדרך להציע זאת ללקוחות, מיקרוסופט פתחה לעצמה פתח להציע דברים אחרים ללקוחות עם Linux עם פרויקט Draw bridge וזאת מבלי לשנות שום קבצים באפליקציה שלהם ומבלי לשבור תאימות, כך שהכלים של SQL ב-Windows יוכלו להתחבר לשרת לינוקס ולעשות את אותה עבודה. כלל, מבחינה טכנית, כשאתם מורידים SQL Server של מיקרוסופט ללינוקס, אתם מקבלים את האפליקציה + ספריות וגם קבצים בינאריים של .. Windows 8 (אפשר לקרוא על כך ולשחק עם זה, למעוניינים. פרטים כאן).

נעבור לאספקט הטכני: שרת SQL של מיקרוסופט ללינוקס נראה בדיוק כמו כל אפליקציה אחרת ללינוקס. כשרוצים להתקין לדוגמא על שרת CentOS או RHEL או SLE של SuSE – מורידים קובץ אחד של REPO ומשתמשים ב-YUM להתקין (או zypper במקרה של SuSE) (לצערי מיקרוסופט לא כל כך עקבו אחרי תקן ה-LSB ללינוקס והקבצים ימצאו ב-var/opt/mssql/ בשעה שהסטנדרט מדבר על opt/). הנה וידאו על התקנה של SQL על CentOS 7 כולל שימוש בכלי חדש של מיקרוסופט לעבוד עם ה-SQL (אפשר לעבוד כמובן גם עם הכלים הרגילים):

וכאן יש וידאו כיצד לבצע Auto Tune עם SQL על לינוקס:

כלומר מבחינת עבודה עם SQL Server של מיקרוסופט, אתם יכולים לעבוד עליו בדיוק כאילו התקנתם אותו על שרת Windows. הרשיון הוא אותו רשיון ואין צורך בתשלום נוסף ולאנשי ה-DBA אין שינוי כלשהו שצריך לבצע. לעומת זאת, לאנשים שאוהבים לעבוד ב-CLI, מיקרוסופט מספקת את mssql-cli שמאפשר עבודה ב-cli (כפי שמודגם בוידאו הראשון) ויש גם את פקודת sqlcli שמאפשרת לגבות DB, לשחזר וכו' וכו'. מנסיוני, ה-sqlcli עובד יפה (רק חבל שמיקרוסופט לא הטמיעו שיטה להכנסת סיסמאות מוצפנות דרך ה-cli).

אחד העניינים שכמובן חברות גדולות יתעניינו בו, הוא עניין האשכולות (Clusters). מה עושים כשרוצים להריץ SQL Server כ-Cluster בתשתית? התשובה במקרה הזה די פשוטה: משתמשים בכלי לינוקס כמו CoroSync ו-PaceMaker כדי לבצע זאת (הוראות נמצאות כאן).

אבל אחד היתרונות הגדולים של SQL Server של מיקרוסופט בלינוקס – זה שאפשר להריץ אותו כקונטיינר, ואז כל עניין ה-Cluster מתייתר. כל מה שצריך לעשות זה להריץ את גירסת הקונטיינר של SQL Server של מיקרוסופט תחת Kubernetes או OpenShift ואז תקבלו לא רק ביצועים גבוהים, אלא שרידות הרבה יותר גבוהה ממה שהייתם משיגים מכל פתרון Cluster קלאסי (לינוקס או Windows), החל מרמה פשוטה של הרצת SQL ב-Pod שכשהוא נופל אוטומטית Pod אחר קם ואז ניתן לעבוד שוב, וכלה בפתרון של הרצת 3 PODs כשבכל אחד מהם רץ SQL Server וכאשר אחד מהם נופל, מתקיים תהליך "בחירות" אוטומטי והזוכה נהיה ה-Primary. אפשר לראות הדגמה של כך בלינק הזה.

לסיכום: SQL Server של מיקרוסופט מאפשר לכם לעבור מ-Windows ללינוקס מבלי להיתקל ביותר מדי בעיות ומבלי לשלם על רשיון SQL נוסף. תגבו את כל ה-DB בגירסת SQL ל-Windows, תקימו SQL Server ללינוקס, תשחזרו נתונים על הלינוקס ותתחילו לעבוד (וכן, אפשר לחבר את המכונה ל-AD). אתם יכולים גם להשתמש בכלי אוטומציה שקיימים ללינוקס ולבצע פעולות רבות על ה-SQL ללינוקס בדיוק כמו לכל שרת לינוקס אחר. אין Kernel Modules (מיקרוסופט העיפה את כל ה-syscalls של Windows) כך ששום דבר לא אמור להפריע למערכת לעבוד בצורה נורמלית, יש את כל התמיכה ב-SystemD וכן .. זה רץ גם על אובונטו 🙂

וירטואליזציה והעתיד

עולם הוירטואליזציה ידע ב-30+ שנים האחרונות תהפוכות רבות. זה התחיל ב-IBM עם המיינפריים, המשך למערכות יוניקס השונות עם פתרונות מסוגים שונים (רובם מבוססי חומרה), המשיך בצעדים קטנים בעולם ה-PC (בדסקטופ, לא בשרתים), ובשרתים מודרניים זה התחיל עם "מעין וירטואליזציה" כמו chroot, jails ובסולאריס עם Zones.

עד שהגיעו VMWare שגם הם התחילו בהתחלה בדסקטופ (ה-Workstation, אחרי זה ה-GSX, אחרי זה ESX ולבסוף ESXI) והם "לקחו את הקופה" בכל הקשור להצעת וירטואליזציה מלאה. מה שהיית יכול (בד"כ) להריץ על שרת בודד, אתה יכול להריץ בשרת וירטואלי ללא שינויים. VMware נכנסה לשוק די ריק וכבשה אותו ורק לאחר מספר שנים נכנסה מיקרוסופט עם ה-Hyper-V ולאחריה נכנסו אחרים כמו אורקל עם ה-VM Server שלהם וגם רד האט עם RHEV (כיום זה נקרא RHV), ופתרונות אחרים כמו Proxmox ואחרים.

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

  • פתרון וירטואליזציה רגיל – ערימת שרתים שכל התוכן נשמר בדיסקים מקומיים.
  • פתרון וירטואליזציה רגיל – עם NAS או SAN כאשר ה-DATA נשמר על אותו פתרון אחסון.
  • פתרון וירטואליזציה hyperconvergence – שבו הכל יושב בארון אחד ובלוגיקה מאוחדת – ה-storage, הרשת (נהיית כמעט כולה וירטואלית – SDN ), וה-Compute – כמו פתרונות של Nutanix, או Simplivity או RHV (לשעבר RHEV, בגירסה החדשה 4.2 שתצא בקרוב).
  • פתרון וירטואליזציה משולב קונטיינרים – מכונות ה-VM משמשות כ-nodes והקונטיינרים רצים בתוך ה-Nodes.
  • פתרון של קונטיינרים בלבד – ה-Nodes יושבים על מכונות פיזיות (ללא וירטואליזציה) והקונטיינרים רצים על המכונות הפיזיות (פתרון לא מומלץ, הואיל וכך קשה לנטר ולטפל בשרתים).

קונטיינרים נכנסו בסערה לשוק ב-4 שנים האחרונות כאשר Docker הוביל בשוק שהיה עד כה עם פתרון Zones של Solaris ומספר פתרונות לא-ממש-משוייפים בלינוקס כמו LXC והפשוטים כמו chroot ו-jails (שקיים לגרסאות BSD). פתרון הקונטיינרים הראה לעולם מה שמנהלי Solaris ולינוקס ידעו ממזמן – אתה יכול להרים קונטיינר ב-2-3 שניות ולהריץ עליו אפליקציות. הפתרון היה מוגבל, אבל הוא בהחלט הצית את הדמיון ומספר אנשים החלו לעבוד על פתרון משלים בגוגל ולאחר זמן מה גוגל החליטו להוציא את הפתרון שלהם שמשתלב עם Docker ונקרא Kubernetes (או בקיצור: K8S ובתרגום השם מיוונית: טייס – pilot) ו-K8S נותן לך פתרון כמעט מלא לקונטיינרים – החל בשרידות, גדילה דינמית, בדיקת "בריאות" קונטיינרים, תקשורת ביניהם (באמצעות תוסף צד ג' – יש מספר פתרונות מובילים) ועוד ועוד.

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

זה המצב כרגע בשוק.

ומה העתיד צופה לנו?

מי שנמצא בתחום המחשבים עשרות שנים יכול בוודאי לראות שפתרונות ישנים תמיד עושים "סיבוב" נוסף וחוזרים כפתרונות מודרניים. קחו Mainframe מלפני 30+ שנה, דברים עתיקים כמו System/360 של IBM ונוכל לראות שם ש-IBM הריצו מערכות נפרדות כ… קונטיינרים, בשמות אחרים, במושגים שונים, אבל במבט על – אפשר להשוות זאת לקונטיינרים והנה כיום השוק חוזר ל.. קונטיינרים. אותו דבר בוירטואליזציה (גם שם ל-IBM יש הרבה קרדיט ו.. אלפי פטנטים. אם IBM היתה רוצה להתנהג כמו שמיקרוסופט התנהגה בשנות ה-90 – הייתם משלמים היום הרבה הרבה יותר על פתרונות וירוטאליזציה וקונטיינרים).

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

איפה זה נכנס? הבעיה כיום עם קונטיינרים היא שההפרדה בין קונטיינר לקונטיינר היא חלקית. אם נפעיל קונטיינר A ונכנס אליו, הוא לא יכול לדבר כברירת מחדל עם קונטיינרים אחרים או עם ה-host אלא אם נגדיר לו כך ספציפית (בצורה של Volume או בהגדרות רשת). יחד עם זאת, אם אני מצליח לקבל גישת root ל-host עצמו, אני לא רק שיכול לראות את כל התליכים שהקונטיינרים מריצים, אני יכול לשבש את כל המערכת. יש פתרונות לכך כמו SELinux ו-AppArmor אבל הרוב לא משתמשים בכך ובחברות גדולות כמו בנקים וכו' העניין די מעכב הכנסת פתרונות מבוססי קונטיינרים. (אצל חברות הענן כמו אמזון וגוגל, המצב שונה לחלוטין וגם אם תצליח לפרוץ את הקונטיינר – לא ממש תגיע ל-host, והם משתמשים בפתרונות חומרה כדי להגן על הדברים, פתרונות חומרה משלהם שהם אינם מוכרים. ככלל, שרתים אצל יצרני הענן שונים מאוד בתצורה הסופית מהשרתים שחברות קונות).

כאן נכנסים ה-VC. ה-Virtualized Containers הם בעצם מכונות וירטואליות לכל דבר ועניין שיריצו את האפליקציה שלכם, רק שהם בנוים בצורה אחרת. לדוגמא עניין ה-BIOS ותצורת ה-PC הקלאסית – הועפו החוצה ודברים רבים שונו כך שה-VC לא יצרכו משאבים כמו VM רגיל, אבל מצד שני תקבל את ההגנות של וירטואליזציה כך שגם אם יש לך root ל-host עצמו, זה לא אומר שתוכל לראות תהליכים רצים (תוכל לראות מכונות וירטואליות שרצות אבל די קל גם להגן עליהן עם פתרונות הצפנה, שימוש ב-HSM וכו' וכו').

אפשר לקבל מעט יותר פרטים על כך ב-Kata Containers , הגירסה הבאה של OpenStack כאן שתתמוך בפתרון VC, ואני משער ש-Kubernetes יתמכו בהמשך גם ב-VC של חברות אחרות ושל אינטל.

ומה עם הפתרונות של VMware?  ל-VMWare כיום יש את vSphere integrated containers אבל אני מאמין שב-vSphere 7 הפתרון יהיה שונה, וגם ב-VMWare יבינו שרעיון ה-VC הוא רעיון לא רע בכלל להטמעה ושימוש, ומכיוון שב-VMWare יש צוות ענק של אנשי לינוקס, הם יכינו פתרון כזה (הימור שלי: פתרון ה-VC שלהם יתאם ללינוקס, לא ממש ל-Windows, לפחות לא בגירסה הראשונה) כך שתוכל להרים לך קונטיינר או VM, וזה לא ישנה הרבה, והפתרון יכלול גם Scale Out דינמי. (אין לי NDA מול VMWare וידע פנימי רשמי מה שקורה שם ולכן אני מסייג את הדברים, אלו רק שמועות ששמעתי).

עוד תחום שלדעתי יקבל יותר ויותר מקום (אך הדבר יקח זמן עקב שמרנות של חברות) הם מעבדי ARM. חברות כמו Qualcomm, Cavium ואחרות מתחילות להוציא מעבדי ARM V8-A עם 16/32/64 ליבות, מיקרוסופט עובדת ותשחרר בקרוב Windows 2016 לשרתי ARM ויש שמועות שגם ב-VMware וחברות אחרות עובדים על כך (הפצות לינוקס לשרתי ARM כבר קיימים כיום (גירסת SuSE קיימת כאן, וכאן ההכרזה של רד-האט, וכאן של Ubuntu). הרעיון עצמו הוא פשוט: בשרתים כאלו יש לך עשרות ליבות ואתה לא צריך לשלם 10000$ על מעבד כזה, והליבות הללו יכולות להריץ דברים קטנים ביעילות מופלאה. קונטיינרים הם (יחסית) קטנים, אז למה שלא תריץ את הקונטיינרים שלך על מעבדי ARM? צריך ברזלים? HPE הכריזו על כמה דגמים, DELL ו-Lenovo ממלאים את פיהם מים כרגע, אבל בוודאות אני יכול לאמר לכם – הם בונים כאלו בימים אלו לקראת הכרזה בקרוב.

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

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

יהיה בהחלט מעניין 🙂

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

אני רוצה להתחיל את הפוסט במשהו שאמרתי למפתחים בחברה גדולה (שאינה חברת תוכנה): יכול להיות שאינכם משתמשים כיום בקונטיינרים, אבל מחר, מחרתיים, אולי עוד שנה ואולי מעט יותר – אתם תעברו להשתמש בקונטיינרים וה-Push לעבור לקונטיינרים יגיע מכל מיני כיוונים, אם זה מצד יצרני מערכות הפעלה (מיקרוסופט, רד-האט, SuSE, סאן/אורקל), אם זה מהמנמ"ר או מנהל ה-IT הראשי שיבינו שעל אותה תשתית שמריצה כיום את האפליקציות אפשר להריץ יותר אפליקציות ומכל מיני כיוונים אחרים – זה יגיע בסוף. קונטיינרים זה לא משהו שקשור לטרנד (זה קיים בתצורות שונות כבר 30 שנה, תשאלו את IBM, ואת Sun לשעבר) – זה קשור לניצול תשתית בצורה טובה יותר, לחסכון בעלויות (כשאתם משתמשים בתשתיות של ספקי ענן/פלטפורמה ציבורית) ובקיצור – זה לא משהו שאולי תעברו אליו, זו שאלה של מתי תעברו לזה. קונטיינרים אינם מחליפים תשתית וירטואליזציה, הם משתמשים באותה תשתית וירטואליזציה קיימת כך שאין צורך להחליף תשתיות.

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

הבה ניקח שפה כמו Python. נניח שאתם רוצים ללמוד את השפה. אתם לוקחים ספר, אולי קורס וידאו אונליין ואתם מתחילים לאט לאט ללמוד איך לבנות מערכים, מחרוזות, איך להדפיס למסך, איך לקרוא ולכתוב קבצים ועוד דברים רבים. בשביל לנסות את הדברים ולכתוב בעצמכם, אתם תתקינו Python על מערכת ההפעלה החביבה עליכם (בלינוקס ובמק זה מובנה) ואתם תתחילו לעבוד עם כל עורך טקסטים כדי לבנות את קבצי ה-Python ולאחר מכן להריץ אותם בעזרת פקודת python פשוטה. מאוחר יותר שתרצו לבנות פרויקטים ב-Python (ובעצם כמעט בכל שפה אחרת) אתם תשתמשו ב-IDE כלשהו שיעשה לכם את החיים יותר קלים. אם אתם עובדים בצוות, אז סביר להניח שתשתמשו ב-GIT כדי לאחסן את הקוד (ובוודאי ה-IDE יתמוך ב-GIT כדי להקל על העבודה). בקיצור – אם אתה מכיר Python, את עניין העבודה בצוות ושימוש בכלים שונים או ב-API שונים תוכל ללמוד תוך זמן קצר. אף אחד לא יסרב לשכור אותך אם אינך מכיר API זה או אחר או כלי IDE זה או אחר.

עם קונטיינרים לעומת זאת .. הדברים שונים. (בפוסט זה אני אתייחס לקונטיינרים וכו' כשהם רצים על תשתית שלכם מקומית או על מכונות EC2, ולא ECS של אמזון או GKE של גוגל). עם קונטיינרים יש לנו 2 (או 3) "שכבות שונות".

הדבר הראשון שאתם צריכים להכיר, זה: מה זה קונטיינר? את העניין שקונטיינר הוא בשום פנים ואופן לא מכונה וירטואלית (VM), את העניין של מה זה DockerFile (או docker compose – כל אחד והעדפותיו… לא שופט), מהו Image, איך הוא נוצר, מהם 2 מצבי הרשת שיש לקונטיינרים, איך קונטיינרים מתקשרים בינם לבין עצמם ובינם ל-Host, מהם "שכבות" ה-File-system בקונטיינרים, שימוש ב-Container Registry, אבטחת קונטיינרים ויש עוד כמה וכמה נושאים שצריך ללמוד בכדי להכיר טוב קונטיינרים. כמו שאתם יכולים להבין, לא מדובר במשהו שיושבים אחה"צ או באיזה ערב אחד בבית ולומדים במכה אחת. תצטרכו לזה כמה ימים כדי להכיר זאת – והכרת הקונטיינרים היא חובה לכל איש Devops או לכל מי שיבנה קונטיינרים בחברה.

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

השלב השני הוא מה שנקרא מערכת ניהול Scheduling – זו בעצם תהיה המערכת שתעשה מה שתיארתי לעיל והרבה יותר, וזו מערכת שמשתשמת ב-Docker כדי לבצע את הדברים אך היא מוסיפה דברים רבים (שוב, כפי שתיארתי לעיל וזהו תיאור מאוד מתומצת). ישנן מערכות ניהול רבות אבל בד"כ אתם תשתמעו על Kubernetes, Docker-Swarm, ו-Apache Mesos (ויש כמובן עוד אחרות).

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

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

השלב הבא הרבה יותר קצר והוא מצריך שתהיה לכם גישה למערכת וירטואליזציה כלשהו (גם VirtualBox יספיק לשם כך). בשלב זה כדאי ללמוד על מערכות הפעלה רזות. בלינוקס זה מערכת כמו Atomic. ה-Atomic זו מערכת הפלה מאוד רזה שנועדה להתקנה על שרתים או מכונות VM שיריצו את הקונטיינרים, את Kubernetes ועוד. זו אינה מערכת שמבוססת על DEB או RPM אלא מערכת של קובץ אחד (כך שאין אפשרות לעדכן חלק אחד בה. עדכון שלה הוא עדכון של כל המערכת והיא אינה שומרת מאומה למעט דברים מסויימים בתיקיה מסויימת). יתרונה הגדול על פני מערכות לינוקס מסורתיות הוא שמבחינת משאבים – המערכת מנצלת מעט מאוד. אם אתם משתמשים ב-Windows, אז כדאי שתכירו את ה-Nano Server שעליו ירוצו הקונטיינרים ומערכת ה-Scheduling.

סיימנו? כמעט 🙂

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

וכאן אני ממליץ על OpenShift – גירסת הקוד הפתוח (Origin) או הגירסה המסחרית. OpenShift בעצם מרחיב את היכולות של Kubernetes בכך שהמערכת עצמה מוסיפה דברים שתיארתי לעיל כמו projects, HAProxy, אבטחה עם SELinux, עבודה באופן מסודר עם Storage (תוך הפרדה של יצירת Volume ע"י מנהל המערכת ושימוש ב-Volume ע"י משתמש רגיל. משתמש רגיל אינו יכול ליצור Volume ב-OpenShift אבל מכיוון ש-Kubernetes לא ממש מכיר אבטחה, הוא מאפשר לכל משתמש גם ליצור Volume, לחרדת מנהל הסטורג' בחברה). עם OpenShift אנחנו יכולים לבנות את השרותים, קונטיינרים וכל הדברים דרך ממשק ה-WEB או דרך קבצי YAML או JSON (שוב, כל אחד והעדפותיו…), תוך שימוש במשאבים נוספים הקיימים כמו קטלוג שרותים שהוקם לחברה פנימית (דבר שלא קיים ב-Kubernetes). יתרון נוסף שיחשף בקרוב (לגבי Kubernetes ו-OpenShift) זה שבגירסה הבאה תוכלו להריץ קונטיינרים גם על Windows וגם על לינוקס על מערכת Kubernetes/OpenShift אחת.

אני מניח שאחת השאלות שישלחו אליי לאחר פוסט זה תהיה לגבי תיעוד, וכאן ההמלצה שלי היא לקחת תיעוד נפרד לכל דבר. גם על Kuberentes וגם על Docker יש תיעוד מעולה של חברת Oreilly. אם אתם רוצים ללמוד על OpenShift – התיעוד הרשמי הוא די טוב – רק אם למדתם טוב את 2 הדברים שציינתי, אחרת התיעוד שקיים לא יעזור לכם הרבה (מנסיון! מה לעשות שכשזה מגיע לתיעוד טוב, תמצאו 2 חברות שעושות טוב את העבודה: IBM ו-מיקרוסופט).

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

חג שבועות שמח לכולם 🙂

עוד נקודות חשובות לפני מעבר לענן

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

לעומת זאת, חברות לא מעטות בארץ ובחו"ל מעדיפות את הענן של מיקרוסופט, וכאן איש ה-Devops יצטרך יודע ידע בטכנולוגיות של מיקרוסופט (PowerShell ואחרים) כדי לעבוד. מיקרוסופט נותנים SDK לשפות אחרות ו-CLI למערכות הפעלה פופולריות, אך מי שעובד לדוגמא הרבה עם AWS ויעבור להשתמש ב-Azure, יגלה לאחר זמן מה שמיקרוסופט יותר משקיעה בטכנולוגיות שלה מאשר בטכנולוגיות האחרות. כך לדוגמא אם תרצה לבצע אוטומציה עם הכלים הפופולריים בלינוקס, החיים שלך לא יהיו כל כך קלים.

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

על רשיון 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 כל הזמן.

 

בעניין 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 נראה כפתרון שהכי יכול להשתלב ולעזור לחברות בין לאומיות, אבל גם כאן – אני ממליץ לנקוט בזהירות.