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

לפני רכישה – כדאי לחשוב קדימה

כאן בארץ, לא חסרים ארגונים ועסקים שההתמחות שלהם היא בשיווק מוצרים לעסקים וחברות בכל מה שקשור ל-IT – בין אם מדובר בתוכנה, חומרה, שרותי אינטגרציה, תמיכה וכו'. זה הביזנס שלהם ומרביתם יכולים למכור לך כמעט כל מה שתרצה – בין אם זה כונן דיסקטים 5.25" ועד Mainframe – כולל שילוב ואינטגרציה של מה שהם מוכרים. לגטימי? בהחלט.

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

המקרה הראשון התרחש לפני מס' חודשים: קורא נאמן של הבלוג פנה אל עבדכם הנאמן בשאלה פשוטה: החברה הגדולה שהוא עובד שם מתכננים לרכוש 4 דיסקים Optane של אינטל מסוג P4800X דרך יצרן השרתים של החברה. הסיבה לרכישת הדיסקים האלו? מצגת שהראתה להם שבביצועי SQL – הדיסקים הללו יהיו מעולים לצרכיהם, הרבה יותר מכל סטורג' שהם יחברו (בקטע הזה המצגת צודקת. דגם ה-Optane הזה בהחלט מתאים ונותן ביצועים מטורפים!). הדיסקים האלו יכנסו לתוך שרת R740 של DELL, ימופו לתוך VM שיריץ שרת Windows Server 2016 ו-SQL Server. אמרתי לו שלדעתי תהיה בעיית ביצועים, אבל אם הם מעוניינים, אשמח לבדוק להם את העניין – בתשלום. החברה הסכימה. (בכל זאת, 2500$ פר SSD, כלומר $10000 דולר במחירי ארה"ב…)

תודות לכמה יבואנים הצלחתי להשיג את הציוד להשאלה אליי ל-LAB. השרת פורק, חיברתי את ה-backplane עם כניסות U.2, הצמדתי לדיסקים חיישני חום, הפעלתי והתחלתי להריץ בדיקות עומסים שונים. לקח 10 דקות עד שאחד ה-SSD הגיע ל-95 מעלות חום. כמה דקות אחרי זה שאר ה-SSD הגיעו בערך לאותו חום – והביצועים החלו לצלול. סיכום הדו"ח שלי ללקוח הצביע על הבעיה הפשוטה: הן שרתי ה-R740 (וגם כל שרת 2U של HPE או לנובו לצורך העניין) אינם מתאימים בתצורה זו ל-SSD מבוסס Optane של אינטל. הדיסקים הללו מפיקים הרבה יותר חום מדיסקים מכניים או SSD מתחרים. הדרך היחידה להכניס 4 כרטיסים כאלו היא לרכוש 4 SSD כאלו בתצורת AIC (כלומר כרטיס PCIe) ואז למפות אותם. עדיף במקום שרת 2U להשתמש בשרת 3U (אבל אז גם מחיר השרת מטפס הואיל ומה ש-DELL מוכרת בגירסת 3U זה שרת עם 4 מעבדים).

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

  • אבטחה – עם כל הכבוד ל-Kubernetes, הפלטפורמה עדיין אינה מאובטחת כמו OpenShift (תודות ל-SELinux ועוד מספר רכיבים).
  • Auditing, Compliance – בחברות גדולות ומשרדים ממשלתיים מאוד רוצים את זה.
  • מיגרציה בהמשך – תחשבו 4 שנים קדימה, אם Kubernetes עדיין תהיה קיימת, יהיה קשה מאוד להעביר אליה דברים שבנינו השנה לגירסה שתצא אז. במוצר כמו OpenShift היצרן מציע כלים לבצע מיגרציה.

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

המקרה השלישי קשור יותר ל"התלהבות" הולכת וגודלת לכל ה-Hyper Converge בוירטואליזציה (למי שלא מכיר: מערכות כמו vSAN, Simplivity, Nutanix מציעות להקים שרתים שיתנו את כל השרותים הכוללים Storage, Network, Compute – ללא צורך בסטורג' מאסיבי, סוויצ'ים יקרים וכו').

כמו תמיד, חברות כמו VMWare ואחרות לא המציאו מאפס את עניין ה-Scale Out הזה. מערכות File System ל-Scale Out קיימות זמן רב, כמו Lustre FS, מערכת Open Vswitch לצרכי Network, ופתרונות וירטואליזציה שונים הציעו זאת בסביבת HPC כבר זמן רב.  החולשה שיש ב-HPC קיימת בדיוק אותו דבר גם בפתרונות וירטואליזציה Scale Out: אם אתה צריך כמות IOPS מאסיבית של 7 ספרות ומעלה, תצטרך או לרכוש סטורג' יעודי או לרכוש הרבה יותר שרתים פיזיים מכפי שאתה צריך עבור Compute. אם אין לך צרכים כאלו, אז כן, פתרון Hyper Converge יכול להיות פתרון טוב.

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

קצת על Guacamole, כניסה מורשית ואבטחה

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

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

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

הנה שיטה שאני משתמש בה ואולי היא יכולה להיות ישימה גם אצלכם.

קצת רקע: עבדכם הנאמן נותן שרותי יעוץ ואינטגרציה למגוון פלטפורמות. חלקן פופולריות ומוכרות (כמו vSphere) וחלקן קצת פחות – כמו oVirt, OpenShift, OpenStack, Ceph, Gluster, Kubernetes (ויש עוד לא מעט תוכנות) וכמובן מערכות לינוקס שונות. כל המערכות הללו רצות נון סטופ אצלי ב-LAB מסיבות שונות:

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

וכאן אולי אפתיע אתכם: אני לא משתמש ב-VPN או תוכנות שליטה מרחוק מבחוץ. זה לא בעיה של רשיונות או בעיה של התקנת VPN.

אני משתמש ב-Guacamole.

למי שלא מכיר, Guacamole היא אפליקציית Java שרצה תחת Appplication Server כמו Tomcat או Wildfly (או JBOSS) המאפשרת חיבור מכשירים, תחנות ושרתים לממשק Web מאוחד, הגדרת משתמשים והרשאות וכניסה דרך הדפדפן לתוך כל חיבור. יש כמובן מספר תוכנות כאלו שנמצאות בכל חברה המאפשרות להתחבר ב-SSH/Telnet/RDP/VNC, רק שאת Guacamole לא צריך להתקין על כל מכונה. מספיק שיש דפדפן סטנדרטי ומודרני.

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

  • הראשון הוא עניין TOTP (כלומר Time-based One-time Password) – כך שמי שמתחבר מבחוץ יצטרך להשתמש ב-MFA בכל פעם שהוא מתחבר (בנוסף לשם משתמש וסיסמא)
  • הגישה שהוא מקבל – היא למכשיר/מכונה אחת או יותר שהוא צריך. אם הוא ינסה להיכנס למכונות אחרות – אני יוכל לראות זאת.
  • המכונה שהוא ניגש אליה – שמורה ב-snapshot ב-ZFS כך שאם הוא יגרום נזק, אפשר תוך שניות ספורות לחזור אחורה.
  • וכמובן הכל מוקלט – ל-Guacamole יש אפשרות "הקלטת session" שמקליט כל מקש שהמשתמש מבחוץ מקיש ומה הוא רואה על המסך, כך שאני יכול לראות בזמן אמת מה הוא מקיש ומאוחר יותר אני יכול להמיר את ההקלטה לקובץ MP4 כדי לראות בבירור מה בוצע במכונה.
  • מכונות קריטיות ב-LAB – אינן זמינות דרך ה-session.
  • הגישה מבחוץ זמינה רק לאחר שהפעלתי זאת. כברירת מחדל, אין גישה מבחוץ לשום דבר.

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

על מנת לממש את הדברים ב-LAN של חברה, מבצעים את הצעדים הבאים:

    • מקימים מכונת VM עם לינוקס ועליה מתקינים את Guacamole ומוסיפים את תוסף ה-TOTP (לחובבי אובונטו, יש בלינק הזה סקריפט מוכן להתקנת האפליקציה באופן אוטומטי)
    • מגדירים משתמשים (אפשר לחבר את זה ל-Active Directory לפי ההוראות בקובץ PDF זה. זה קצת מורכב) ומגדירים סשנים למכונות או ציוד שיש צורך בגישה אליהם. שימו לב – כל סשן למעט עם חיבור VNC מתנתק ברגע שסוגרים את ה-TAB, כך שאם רוצים להשאיר דברים רצים בלינוקס לדוגמא, אפשר להשתמש ב-nohup או להשתמש ב-screen או TMUX.
    • מגדירים אלו סשנים יהיו זמינים לאלו משתמשים
    • על מנת שסשן יוקלט, בכל הגדרת חיבור יש בסוף הדף הגדרות להקלטה. בד"כ יספיק path ושם כלשהו כדי להפעיל את ההקלטה (ההקלטה תישמר בתוך שרת ה-Guacamole, לא במכונה שמתחברים אליה דרך ה-Guacamole). חשוב לזכור, ההקלטה היא בפורמט דחוס שיש צורך בהמרה, ואותו כדאי לשמור בסטורג' או ב-NAS כך שמומלץ לחבר את שרת ה-Guacamole לאיזה NFS share על מנת לשמור הקלטות לעתיד לצרכי אבטחת מידע. כל הקלטה כזו ניתן מאוחר יותר להמיר לקובץ MP4 על מנת שלא לתפוס יותר מדי מקום באחסון.
    • ב-Firewall מגדירים Static NAT בין IP חיצוני ל-IP פנימי שמריץ את ה-Guacamole. את החוק הזה מכבים ומפעילים לפי צורך. (למתוחכמים – אפשר לכתוב סקריפט פשוט שמשתמש ב-CURL ומתחבר ל-API של ה-Firewall על מנת להפעיל/לכבות את החוק הספציפי).

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

טיפ: כשרוצים להוסיף דיסקים SSD מקומיים בשרת

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

בניגוד לשרתים רגילים שרוכשים מ-HP/לנובו/DELL ששם אתם מקבלים שרות מהקצה עד הקצה, בשרתי Tier 1 אתה מקבל אפס תמיכה טכנית (הדבר היחיד שכן מוכנים לעשות עבורך הוא להחליף ציוד תקול) והתשובה הקבועה שתקבל מהתמיכה הטכנית היא משהו כמו: זה שרת Tier-1, אין תמיכה טכנית, כך שאם מישהו רוצה לרכוש שרת כזה, עדיף שיכיר היטב איך לזהות חולשות ובעיות תכנוניות של לוח אם, איוורור, נתיבי PCIe מבחינה לוגית (לא רק פיזית) ועוד, אחרת בקלות אפשר לרכוש "פיל לבן". כך לדוגמא השרת בתמונה למעלה היה אמור להירכש על ידי חברה מסויימת בארץ – למטרת הקמת "סטורג'" מאוד מהיר (כל הדיסקים שנכנסים מקדימה הם SSD NVME בלבד). הם פנו לכל מיני אינטגרטורים שנתנו המלצה חיובית לרכישה ואז הם פנו אל עבדכם הנאמן דרך בלוג זה והמלצתי היתה שלא לרכוש מהסיבות הבאות:

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

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

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

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

טכנית, אני ממליץ לרכוש מיצרן השרת דיסקים SSD מבוססי SATA ולא SAS מכיוון ש-SATA Enterprise עבר כברת דרך ארוכה באמינות, ויתרון הערוץ הכפול לא רלוונטי בשרתים מודרניים הואיל ובקר ה-RAID הראשי מוטמע בלוח האם, כך שאם יש תקלה, השרת מושבת בכל מקרה. מבחינת ביצועים – כיום SATA עוקף SAS (ב-SSD).

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

יש לכם כבר 8 ורוצים להוסיף עוד? סביר להניח שתצטרכו בנוסף לדיסקים SSD לרכוש "Extension Kit" לשרת עצמו. אצל חלק מהיצרנים מדובר על מספר כבלים וכרטיס SAS Expander שאותו יש לחבר אל כניסות בקר ה-RAID ומה-SAS Expander לחבר את כל הכבלים אל ה-Backplane. יש מקרים שאתם תצטרכו לעשות זאת ויש מקרים שטכנאי מטעם היצרן יבוא ויעשה זאת (תלוי בחוזה שלכם מול יצרן השרתים). אם מדובר לעומת זאת בשרת ישן (נניח G7/G8 של HPE או R710/R720 של DELL או M2/M3 של IBM) – תהיה לכם בעיה כלשהי, ההסבר לגביה – בהמשך הפוסט.

יהיו מקרים, כמובן, שבחברה מסויימת ירצו להרחיב מעבר ל-16 דיסקים. במקרים כאלו בדרך כלל היצרן ימכור ללקוח כרטיס SAS Expander בערך כמו שיש פה בתמונה משמאל שמאפשר חיבור של 24 דיסקים. מבחינת חיבוריות – אין שום בעיה לחבר את הכל כמו במקרה של הרחבה מ-8 ל-16.

הבעיה – צוואר בקבוק.כמעט כל בקר RAID, בין אם מדובר בכרטיס ובין אם מדובר בשבב שנמצא על לוח האם, תופס 8 נתיבי PCIe (כלומר PCIe X8) ו-PCIe 3.0 X8 (שנמצאים בשרתים מודרניים) יכול להעביר ברוטו עד 8 ג'יגהבייט (קצת פחות בפועל). אם נזכור ש-SSD כשקורא נתונים – מעביר אותם במהירות של 450-550 מגהבייט לשניה, ונכפיל את זה כפול כמות ה-SSD בשרת (אני לא ממליץ על RAID-5 כמו שכתבתי לעיל, אבל מי באמת מקשיב?) – ואנחנו יכולים להגיע למצב שבקר ה-RAID "יחנק" עוד במצב של 16 דיסקים. אם כל הדיסקים (24) מחוברים ל-RAID והמערכת מוגדרת כ-RAID-5 על כל הדיסקים – הביצועים פשוט יצנחו בכל מה שקשור לקריאת נתונים. המצב חמור יותר בשרתים ישנים ששם בקר ה-RAID משתמש ב-PCIe 2.0 X8 שאז יש מחצית מרוחב הפס והבקר "יחנק" מ-8 דיסקים SSD אם המערכת קוראת וכותבת מכל הדיסקים במקביל.

לכן – אם מתעקשים להכניס לדוגמא 24 דיסקים SSD בשרת אחד (או בשרת ישן לעבוד עם יותר מ-8 דיסקים SSD), יש לשקול את האפשרויות הבאות:

  • להוסיף בקר RAID עם 2 כניסות SFF 8087 ולחבר אליו את ה-8 דיסקים SSD (אחרי 16). בשרתים ישנים אפשר לרכוש 2 בקרי RAID עם 2 כניסות SFF 8087 ולחבר אליהם את הדיסקים. החסרון בשיטה זו: אין RAID "המשכי" לכל הדיסקים, אבל גם לכך יש פתרון, המשיכו לקרוא.
  • לעצור ב-16 דיסקים.
  • לרכוש במקום בקר RAID – כרטיסי HBA (או כרטיס RAID במצב IT MODE) ולהקים RAID מבוסס תוכנה (כל מערכת הפעלה מאפשרת זאת, ויש גם תוכנות יעודיות לכך כמו FreeNAS, UnRaid, XPEnology ועוד). שימו לב – החלפת בקרים אינה דבר מומלץ ואינו נתמך רשמית על ידי יצרני השרתים.
  • לפצל לשרתים נפרדים. 2 שרתים עם 8 דיסקים SSD יתנו עבודה יותר מהירה.

לסיכום: זה שיש 24 מקומות לדיסקים SSD בשרת, לא אומר שהשרת באמת בנוי להפעיל 24 דיסקים SSD (ובשרתים ישנים – יותר מ-8 SSD במקביל, גם אם מדובר בבקר עם 4 כניסות SFF-8087), בדיוק כמו שרוב מוחלט של השרתים שנמכרים לחברות לא יכולים להפעיל 24 דיסקים SSD NVME (אל תנסו. תכנון הקירור, גם בדגמים הכי חדשים של DELL/HPE/לנובו לא מתאים לכך). עדיף לחלק את הדיסקים בין 2 מכונות פיזיות, ואם אתם מתעקשים "להפציץ" מכונה אחת בדיסקים SSD – עדיף לייעד אותה לשימוש כ-NAS עם מפרט נמוך ולהריץ את הדברים הדורשים ביצועים בשרת אחר.

נקודות למחשבה לגבי מעבר לענן (2019)

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

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

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

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

נניח וירון בוחר את השיטה להחליף "ברזלים" – נניח R710/R720 ב-R740 – העלות שלו תהיה Fixed ומשולמת מראש. נניח לשם הדוגמא ש-R740 עולה 10,000$ ויש לו 3 שרתים ישנים והוא מעוניין להחליף את כולם, אז העלות תהיה בעצם 30,000$. במחיר הזה ירון מקבל את האפשרות להביר מכונות VM לתשתית החדשה תוך שימוש ברשיונות קיימים (בדרך כלל, קיימות גם חריגות) והוא יכול בהמשך להוסיף עוד מכונות VM ללא עלות נוספת (שוב, למעט מקרים של רשיונות ל-OS וכו').

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

אז בואו נחשב מחיר: יש לנו 50 מכונות VM שפרוסים על 3 שרתים והם יתנו שרות לפחות ל-3 שנים הקרובות. מחיר פר VM יצא 600$. אפשר כמובן לקצץ ולרדת ל-2 שרתים עם מעבדים חזקים מרובי ליבות וכמות זכרון משמעותית (נניח 256 ג'יגה פר שרת פיזי). חושבים שזה יעזור? מהרגע שעוברים ממעבדים כמו Xeon SP Silver למשהו יותר רציני – המחיר יטפס בכמה אלפי דולרים, כך שלא בטוח שאם נרד בכמות השרתים (אך נשדרג במעמד ההזמנה את אלו שאנחנו רוצים לרכוש במפרט יותר "כבד") זה יעזור. אנחנו יכולים לרדת במחיר VM מ-600$ נניח ל-500$ ואפילו $400. המחיר ירד יותר אם אותן מכונות VM יעבדו יותר שנים, כמו לדוגמא 5 שנים – אז אנחנו יכולים לרדת ל-$133 פר VM.

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

אז בואו נאמר שב-AWS ניקח מכונה צנועה, 2 ליבות, 8 ג'יגה זכרון, תעבורת תקשורת נמוכה ו-80 ג'יגה דיסק (EBS). המחיר לחודש – 80$. את המחיר הזה ניתן "לחתוך" אם ירון מוכן לשלם לשנה מראש או 3 שנים מראש על אותו VM. אם זה לשנה, הוא יצטרך לשלם $1740 ואם זה ל-3 שנים, אז הוא יצטרך לשלם $1159 (כלומר אפקטיבית הוא כביכול ישלם 32.20$ לחודש) – אז בתכל'ס ניתן להגיע למחירים טובים פר VM (זה קיים אצל כל ספקי הענן הגדולים, אגב). יש,אגב, מסלולים שונים, תלוי בספק הענן.

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

  • רוצים קו יעודי (MPLS) של 100 מגה נניח מחברתכם אל אמזון? זה יעלה כמה אלפי דולרים, לאמזון ולספק התשתיות שלכם.
  • לא רוצים פתרון MPLS אלא VPN? אין בעיה. התשלום יהיה על ה-Instance שיריץ את פתרון ה-VPN ועל התעבורה היוצאת מאמזון אליכם (משלמים על הכיוון מאמזון החוצה, לא להיפך)
  • יציאה לאינטרנט – אתם משלמים על כל ביט שיוצא החוצה לאינטרנט מהתשתית שלכם בענן, ותלוי גם לאן התקשורת יוצאת – כל אזור והמחיר שלו (המחיר הולך פר ג'יגהבייט)
  • רוצים לגבות את התכנים? רעיון מעולה! כל ספקי הענן מציעים שרותי אחסון שונים (כמו S3 ועוד) ויש עלויות של כמה סנטים פר ג'יגהבייט (תלוי בענן, ובסוג שרידות שאתם מחפשים עבור הגיבוי).
  • כתובות IP אמיתיות – כל כתובת עולה כסף ואם ביקשתם הקצאת כתובות ולא השתמשתם – המחיר פר IP קופץ פי 3-4 (המחיר הוא בדרך כלל ל-IP אמיתי בשימוש בסביבות 1-2$ לחודש)
  • החלטתם להשתמש בשירותים שונים כדי לחסוך הקמה ותחזוקה של שרות דומה? יש מחירים Pay as you go ויש מקרים שאפשר לשלם מראש ולחסוך. ככל שיש יותר שימוש, המחיר עולה.

(עכשיו אתם מבינים מדוע אני מתייחס לעננים המקומיים שמציעות חברות תקשורת מקומיות שונות שמריצות תשתית של VMWare או Hyper-V כבדיחה?)

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

  • ב-On Prem אתה משלם על הציוד פעם אחת ואם אתה רוצה להוסיף נניח עוד מכונות VM, העלות תהיה אפסית (למעט במקרים שצריך שדרוג ציוד).
  • ב-On Prem כשיש תקלה, אפשר לטפל בה מקומית 24X7 ולא תלוים בספק הענן (אם משתמשים בשרותים של ספק הענן לדוגמא) עד שיתקנו את התקלה.
  • בענן אפשר תוך דקות ספורות להתחבר לשרותים שונים שחוסכים הקמת שרתים/הגדרות/תחזוקה ואפשר להשתמש ישירות בשירות. כך לדוגמא, במקום להחזיק Cluster של SQL, אפשר להשתמש בשרותי RDS.
  • בענן מחירי ה-VM יותר זולים – אם מוכנים לשלם מראש.
  • בענן אתה תמיד רץ על תשתית חזקה ואף אחד לא מכניס את ה-Instances שלך למכונות שכבר עמוסות. במקרים רבים ה-Instances רצים על מעבדים יחודיים חזקים שלא זמינים לשוק הרחב.
  • שרותי תמיכה בענן ישירות מספק הענן – אינם זולים.
  • נקודה חשובה: ב-On Prem אין לך הפתעות במחיר או בחשבונית חודשית.
  • כשזה מגיע לתשלום – בענן אין "שוטף/שוטף פלוס". התשלום הוא בתחילת החודש הבא.

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

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

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

עדכון ליבה בשרתי לינוקס – ללא Reboot

כשזה מגיע לתחזוקת שרתים, אחד הדברים שאנשי IT פחות אוהבים – הוא עניין העדכון. כשזה מגיע לשרתים שמריצים Windows Server, אתה לא תמיד תדע אם העדכון באמת עבר בדיקות איכות רציניות ומיקרוסופט "נתפסת" שוב ושוב עם בעיות עדכונים ששוברות תאימות. מילא זה – הבעיה הכי גדולה היא שבמקרים רבים – צריך לעשות Reboot ואינך יכול לדעת בוודאות של 100% שהמכונה תעלה והכל יפעל כשורה.

בלינוקס – ברוב המקרים אינך צריך לעשות Reboot לשרת גם לאחר שביצעת עדכונים. במקרה הכי גרוע אתה פשוט יכול להפעיל מחדש את השרותים שרצים על השרות – לאחר התקנת העדכונים. חברות כמו רד-האט ו-SuSE עושות את הכל כדי לשמור תאימות בינארית של 100% כך שקונפיגורציות ודברים אחרים פשוט אינם משתנים (ב-2 ההפצות, כשמתקינים גירסה חדשה של תוכנה על הגירסה הישנה, המערכת תייצר קבצי rpmsave באותה תיקיה שנשמרות בה ההגדרות של האפליקציה, כך שתוכל לראות מה השתנה).

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

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

לאחר זמן מה יצאה רד-האט עם kpatch וחברת SuSE יצאה עם Live patching. קנוניקל לא נשארה מאחור והם הכריזו על שרות שנקרא livepatch.

כל השרותים לעיל – הם בתשלום בלבד, כלומר העדכונים צריכים לעבור דרך מערכת עדכונים מורשית של ההפצה בלבד. לא מדובר באיזו חבילת RPM או DEB שאפשר להוריד ולהתקין חופשי על כל השרתים בחברה. ב-רד האט יש צורך לעשות זאת דרך שרות Satellite וב-SuSE דרך SuSE Manager. באובונטו נותנים בונוס למשתמשים – מי שנרשם, יכול לעדכן דרך שרות livepatch עד כ-3 מכונות דסקטופ בלבד (לא שרתים, זה כבר בתשלום).

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

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

לסיכום: אם יש לכם שרתי לינוקס בפרודקשן והם שרתים מבוססים על Red Hat או SuSE או אובונטו בתשלום – כדאי להשתמש בשרות ה-Live Patching ותחסכו לעצמכם דאגות על אבטחה וענייני Reboot.

פרילאנסרים: תמצאו את החתול

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

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

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

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

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

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

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

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

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

בהצלחה.

קונטיינרים וגדילה, צרכים מול מציאות

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

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

וירטואליזציה: לחזור לברזלים?

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

אולם לאחרונה נתקלתי במשהו חדש: מספר חברות שדווקא לא מעוניינות להריץ את הפלטפורמות שהן משתמשות כמכונות וירטואליות אלא להריץ אותן על Bare Metal (כלומר "על הברזל"). בפוסט זה ארחיב מעט על הנושא.

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

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

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

  • עלויות מטפסות: אם נניח יש לנו כיום 10 שרתים שמריצים את כל הדברים בוירטואליזציה ועתה נוסיף 10 שרתים נוספים שיריצו דברים "על הברזל", הדברים מסביב יעלו יותר: קירור, חשמל, תחזוקת השרת (מבחינת תוכנה וחומרה). בהתחלה זה נשמע כאילו מדובר בעלות קטנה, אולם מכיוון שאנחנו צריכים לאמץ את השרתים (כי לשם כך אנחנו מבצעים V2P) – עלויות החשמל והקירור יעלו באופן רציני.
  • שדרוג חומרה: תעיפו מבט בחומרת השרתים. לעיתים השקעה של כמה מאות או אלפי דולרים חד פעמית בשדרוג מעבדים ו/או זכרון יכולה להאיץ את הביצועים של המכונות הוירטואליות ולחסוך מעבר מוירטואלי ל"ברזל".
  • להתראות לדברים הנחמדים: וירטואליזציה נותנת לנו פונקציואנליות שקצת קשה להשגה כשדברים רצים ישירות "על הברזל". קחו לדוגמא Snapshot – סביר להניח שאינכם משתמשים ב-ZFS על הברזל, כך שיצירת Snapshot של הברזל היא קצת בעייתית (במיוחד אם אין לכם LVM או שלא הגדרתם ווליום לוגי שיאחסן את ה-Snapshots בנפרד). רוצים HA? לא תוכלו להשתמש ב-HA שהוירטואליזציה מספקת, תצטרכו פתרון נפרד, ובהצלחה בבניית Fault tollerance על ברזלים, ואלו רק חלק קטן מהפונקציונאליות שוירטואליזציה נותנת וריצה "על הברזל" לא נותנת.
  • גיבוי ושחזור – הרבה יותר איטיים מאשר גיבוי ושחזור מכונות וירטואליות.

לסיכום: אני בהחלט מודע לכך שלוירטואליזציה יש חסרונות. קחו לדוגמא את VAAI – דבר מעולה אם אתם רוצים לבצע מיגרציה של מכונות בתוך Cluster או להעתיק/להעביר קבצים בתוך/בין ה-Datastores השונים, מכיוון ש-VAAI פשוט "זורק" את העבודה שהסטורג' יבצע ויפנה את השרתים לעשות עבודות אחרות. יחד עם זאת, עם כל הכבוד ל-VAAI וטריקים אחרים, אם יש לכם VM שעסוק כל הזמן בלכתוב ג'יגהבייט כל רגע, הכתיבה תהיה עדיין יותר איטית בהשוואה לכך שברזל יכתוב לסטורג', כי מלכתחילה כך נבנו סטורג'ים – לעבודה מול ברזלים, VAAI וטריקים אחרים הגיעו הרבה יותר מאוחר.
יחד עם זאת, כפי שציינתי לעיל – יש לא מעט דברים שניתן לעשות על מנת להאיץ את הביצועים ולהגיע לרמות שרוצים אם מוכנים להשקיע כמה מאות או אלפי דולרים חד פעמית בשדרוג השרתים עצמם.

סטטוס וירטואליזציה מבוססת קוד פתוח – סוף 2018

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

מי שהולך לכנסים והרצאות של חברות שונות ושל ספקי ענן שונים, שומע בוודאי איך חברה X או חברה Y עברו לענן, הם מרוצים עד השמיים והכל ורוד ומאושר. המציאות, לפחות משיחה עם חברים פרילאנסרים שמבצעים אינטגרציות או מעברים לפלטפורמות שונות – קצת שונה. כן, ישנן חברות שמעבירות חלק מהמכונות VM שלהן לענן, חלקן מעיפות מכונות VM ומשתמשות בשרתי ענן שונים (כ-PaaS), אבל לא יצא לי להכיר שום חברה עם כמה אלפי מכונות VM בארץ שבסופו של דבר השביתה את ה-DC שלה והעבירה הכל מהכל לענן. ככלל, הויכוחים על העלויות השונות בטווח הזמן הקצר והארוך (בתוספת כמה מילות Buzz) גורמים ללא מעט חברות להאט מעבר לענן, לבצע Hybrid מדוד מאוד, והיו כמובן לא מעט מקרים שפשוט "חזרו הביתה" (אם כי זה לא סופי. מי שחושב שאין בתחום ה-IT מקרים שמקבלים החלטה X ואחר כך מבטלים ואחר כך שוב חוזרים – מוזמן להתעורר).

אני מודה שעד לאחרונה כל עניין הוירטואליזציה בקוד פתוח לא ממש תפס אחוז גדול בתחום ההטמעות ב-Enterprise. כמעט כולם הולכים ל-VMware, חברות שכמעט כל התשתית שלהם מבוססת מיקרוסופט משתמשים ב-Hyper-V ואלו שרוצים Hyper Converged הולכים על Nutanix או Simplivity. אחרי הכל – למוצרים האלו יש תמיכה, יש בארץ אינטגרטורים, לא צריך לקנות מחו"ל רשיונות, יצרני החומרה מאשרים שהמוצרים עובדים עם הברזלים. בקיצור, סבבה אגוזים.

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

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

בפוסט זה אציג, כמו בפוסטים קודמים – 3 מערכות (Proxmox, oVirt/RHV, OpenStack) ולמי הם מתאימים ומה השוני שלהם.

נתחיל במערכת שמתאימה יותר לחברה קטנה או ל-LAB מקומי: Proxmox.

תוכנת Proxmox מתאימה ליישומי וירטואליזציה הן על מערכות ישנות (כן, אותו שרת G7 של HP שיושב שם בצד) והן על מערכות חדשות. המערכת עצמה היא יחסית קלה ללימוד, ומי שעבד על ESXi עם vCenter בצורה לא מקצועית (כלומר לא עבר קורסים והכשרות של VMware) יוכל להקים תוך דקות ספורות מכונות וירטואליות על דיסקים מקומיים, לחבר NFS או iSCSI וגם להשתמש ב-HA ולבצע Live Migration (כל עוד יש אחסון משותף, זו לפחות הדרך המומלצת). בקיצור -אם אתם צריכים להקים מערכת וירטואליזציה על מספר קטן של שרתים, ללא הקמה של רשתות וירטואליות מורכבות או דברים הרבה יותר מורכבים (DVSwitch?) – אז Proxmox יכול להתאים למשימה.

המערכת הבאה יותר מתאימה לחברות שמריצות מערכות וירטואליזציה מורכבות עם רשתות וירטואליות שונות (המערכת משתמשת ב-Open Virtual Network ו-Open vSwitch, וכן רשתות SDN), סטורג'ים בפרוטוקולים שונים, חיבור ל-OpenStack, ודברים נוספים. המערכת היא oVirt. טכנית, oVirt נבנתה מגירסה 4 להריץ מערכות גדולות וכשאני מציין גדולות, אני מדבר על אלפי ועשרות אלפי מכונות וירטואליות. בשעה שפתרונות כמו ProxMox מתרכזים ב-Bridge Networking, מערכת oVirt תומכת במספר פתרונות רשתות וירטואליות, והיא בין המערכות היחידות שתומכות גם בפלטפורמות שאינן X86-64 כמו מערכות Power ו-S390 של IBM. מבחינת HA, היא בין המערכות המובילות בדיקות ברמת חומרה (דרך ILO/IMM/IDRAC) מה קורה לברזל והיא יודעת להעביר את ה-VM אם יש תקלה ולטפל בשרתים פיזיים בעייתיים – החל מהקמה של חדשים, שדרוג קיימים ועוד. מערכת oVirt מבוססת על מערכת KVM האחרונה (כן, אותה חברה שמפתחת את oVirt היא אותה חברה שמפתחת את KVM – זו רד-האט) כך שיש תמיכה בציודים וירטואליים חדשים, מערכות UEFI וירטואליות מודרניות ועוד), התממשקות ל-VCenter, המרה יעילה של מכונות וירטואליות ל-oVirt, תמיכה ב-AD/LDAP ועוד שורה ארוכה של פונקציות. בהשוואה ל-Proxmox, מערכת oVirt היא מפלצת ולכן היא פחות מתאימה לרוץ על שרתים עם מכונות וירטואליות שמאוחסנות על דיסקים מקומיים. oVirt, אגב, מגיעה מוכנה לשימוש הן כשרת שיתחבר לסטורג' והן כ-Hyper Converged.

oVirt מתאימה להטמעות גדולות הן כ-PoC והן כפרודקשן כל עוד יש בחברה ידע פנימי (או יועץ חיצוני) שיכול לתת תמיכה. מנהלים שמנוסים עם VMWare או Hyper-V ואינם מנוסים מספיק או בעלי ידע רציני בלינוקס יתקשו בניהול מערכת כזו ללא השקעה בלימוד הדברים, והסיבה לכך פשוטה: oVirt אינה מנסה להיות העתק של VMware והדגש של oVirt הוא יותר על פונקציונאליות מאשר חזותיות (אם כי חל שיפור ניכר בחלק הזה בגירסה 4.2 ובגירסה 4.3 שתצא במהלך 2019). חברות שמעוניינות במוצר ארוז ובתמיכה רשמית עם רשיונות – ניתן לרכוש את מוצר ה-RHV עם תמיכה.

ומכאן – למפלצת הגדולה: OpenStack.

אם oVirt היא מערכת גדולה, OpenStack היא גודזילה לכל דבר ועניין. ההבדל הגדול בין oVirt ל-OpenStack הוא ש-OpenStack מנסה לתת לך הכל מהכל. וירטואליזציה? יש. קונטיינרים? יש את Zun שמאפשר להריץ קונטיינרים כ-שרות. DB כ-שרות? יש. אחסון תואם S3? יש. אחסון Images ודברים אחרים? יש. צריך Load Balancer? תכיר את Octavia, ויש עוד עשרות חלקים. עם oVirt לעומת זאת – המיקוד הוא לכיוון מתן שרותי וירטואליזציה והשרותים מסביב, לא יותר מכך.

המטרה של OpenStack היא לתת לחברה להקים ענן פרטי, רק שבניגוד לדרכים ישנות יותר שבהם היינו מקימים מערכות VM מבוססות לינוקס ריקות ועליהן היינו מקימים כל מיני שרותים – כאן המערכת מוקמת על הברזלים עם השרותים שאתה צריך ואז אפשר להשתמש בשרותים כדי להקים מה שרוצים – מכונות וירטואליות, קונטיינרים, שרותים וכו'. חשוב לזכור: מערכת OpenStack היא מערכת מאוד מורכבת, ומחייבת שיהיה בחברה ידע פנימי רציני בלינוקס, SQL, פייתון, BASH וכו' (בלא מעט מקרים כדי לאבחן תקלה או כדי לטפל בתקלה,  העבודה נעשית מול Shell ולאו דווקא מול ה-GUI) ומאוד מומלץ יועץ חיצוני צמוד ל-OpenStack.

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

ומה העתיד?

פתרונות הוירטואליזציה ממשיכים להתקדם, גם הפתרונות המסחריים הסגורים אך גם הפתרונות מבוססי הקוד הפתוח. ב-VMWare הכריזו בכנס האחרון על ESXI ל-ARM, פלטפורמה שנכנסת יותר ויותר לספקי הענן הציבורי ו"זוחלת" לכיוון ה-Enterprise (תסתכלו על Ampere). פתרון הוירטואליזציה KVM ו-QEMU (שבהם כל מערכת בנייה כמו Yocto משתמשות) יש תמיכה בעשרות מעבדי ARM כבר 6 שנים ומעלה, מערכת OpenStack תומכת ב-ARM, ו-oVirt תתמוך כנראה בגירסה הבאה (אם לא תהיה גירסה כזו, אני כנראה בשנה הבאה ארכוש שרת ARM ואבצע BUILD לכך. מהנדסי רד-האט ישראל – תתכוננו להצקות ממני 🙂 ). עוד ארכיטקטורה שהולכת להיתמך היא מעבדים זולים מבוססי MIPS החדשים.

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

מבחינת אחסון: ישנו תהליך יחסית די חדש שיכנס לאט דרך יצרני ה-SSD והוא "העפה" של מערכת הבקר מה-SSD כך שמערכת הוירטואליזציה תחליט איך לנהל את ה-SSD, איך לבצע Garbage Collection לפי העומסים במכונה, לפי המכונות הוירטואליות שירוצו ועוד. אינטל גם תוציא את ה-Optane DC Persistent Memory – מקלות אחסון שיושבים היכן שמקלות הזכרון יושבים, מכילים הרבה יותר אחסון ממקלות זכרון ECC רגילים ועם ביצועים קרובים לביצועי זכרון. תמיכה לכך ב-OpenStack תהיה קיימת בקרוב (להלן השקפים), רק שמחכים למעבדים ושרתים מבוססי Cannon Lake SP.
עוד תחום אחסון שיקבל Boost רציני בוירטואליזציה הוא NVMEoF שיתן Latency מאוד נמוך.

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

אם יש לכם שאלות לגבי המוצרים, אתם מוזמנים ליצור קשר.

מעבר לענן – תכנונים, עדיפויות ומציאות

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

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

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

ניקח לדוגמא תשתית פשוטה: יש לנו 2 מכונות, אחת מריצה MySQL והשניה מריצה שרת Web NGINX ושרת שלישי שמריץ אפליקציות על Tomcat. התשתית הזו נגישה החוצה לציבור שמבצע אותנטיקציה עם שם משתמש/סיסמא והתשתית יושבת מאחורי Firewall (ואולי מערכות הגנה נוספות).

אם נסתכל על התשתית הזו בתצורה המקומית, סביר להניח שהמכונה שמריצה את ה-NGINX תהיה חשופה (מבחינת כתובת IP) לאינטרנט עם פורט 80 או 443 פתוח החוצה ב-Firewall עם כתובת IP אמיתית או שתהיה כתובת חיצונית ב-Firewall שתמופה אל כתובת IP פנימית. יהיו כאלו שיטמיעו את מכונת ה-NGINX ב-DMZ עם 2 רגליים – אחת ב-DMZ ואחת ב-LAN, כך שה-NGINX יוכל לדבר עם ה-Tomcat ברשת הפנימית (מכונת ה-Tomcat ומכונת ה-MySQL לא יהיו זמינות מבחוץ כלל).

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

  • אנחנו נצטרך להקים VPC שיכלול:
    • חלוקה ל-Subnets ששם ישבו מכונות בהתאם לקטגוריות שאנחנו בונים: Prod, testing, stage, devel וכו'. רובם לא יקבלו כלל כתובות IP אמיתיות.
    • Internet Gateway שיתן ל-Subnet שנבחר גישת אינטרנט החוצה
    • Elastic IP – שיהיה מחובר ספציפית למכונת ה-NGINX
    • NAT Gateway – שיאפשר למכונות הפנימיות לגשת לאינטרנט מבפנים החוצה (אך לא ההיפך)
    • Network ACL – שישמש כ-Stateless Firewall על מנת להחליט מי יכול לצאת ודרך איזה פורטים
    • Security Groups (שהולכים עם Network ACL) – שם נגדיר ספציפית מאלו כתובות ואלו פורטים יוכלו להיכנס לשרת(ים).
    • ויש עוד כמה צעדים, וחברות רבות גם יוסיפו כאן אולי Appliance Firewall מסחרי בנוסף למה שאמזון נותנת ועוד ועוד…

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

לאחר מכן אנחנו נקים מכונות ב-EC2. נצטרך לבחור Template של מכונה מהקטלוג, בחירת ה-VPC, וכמובן – גודל Storage מקומי למכונה. כאן הדברים שונים מהסטורג' שנמצא אצל חברות – ב-AWS תוכל לבחור בין General Purpose SSD לבין Provisioned IOPS SSD שהוא הרבה יותר מהיר והאפשרות השלישית היא דיסקים מגנטיים (מבלי אפשרות לבחור IOPS). ההבדל (חוץ מביצועים) בין ה-General ל-Provisioned מתבטא לא רק בביצועים אלא גם במחיר (ב-Provisioned הוא הרבה יותר גבוה) וראיתי מספר מקרים שבחרו ב-Provisioned והתפלאו מדוע המחיר טס בכמה מאות דולרים פר מכונה. לאחר הגדרות הסטורג' נצטרך לבחור תגים (Tags) אם נרצה, את ה-Security Groups (אם לא הגדרנו קודם), מפתח PEM להתחברות ולבסוף נאשר את הכל ו-AWS יקים לנו את המכונה. לאחר מספר דקות נוכל להתחבר אליה אם הגדרנו שהיא תקבל כתובת IP אמיתית דינמית או ללא כתובת IP דינמית דרך מכונת Bastian או דרך חיבור Direct שיש לנו אל ה-VPC. משם נגדיר פנימית את המכונה, נקים עוד כמה מכונות וכו' וכו'.

בקיצור – העברת תשתית ממקומית לענן היא לא בדיוק מספר קליקים בעכבר (אני לא מדבר על שימוש בפתרונות כמו VMWare on AWS), ויש כל מיני Gotcha בדרך, ויכול להיות שגם הביצועים לא יהיו כה-מרשימים אם דברים לא הוגדרו נכון (אמזון לא דוחפים מכונות VM לשרתי ברזל כמו סרדינים, כמו כל מיני ספקי Hosting), כך שלפחות בפעמים הראשונות – מיגרציה תיקח יותר זמן ולכן חשוב לקחת זאת בחשבון (כמובן שאם מישהו חיצוני מקצועי עושה זאת יקח פחות זמן אך עדיין יהיו דברים שלא היו צפויים מראש שהחברה תרצה וגם זה לוקח זמן). בהמשך, סביר להניח, יוכנסו כלים שונים כדי לבצע אוטומציה של הדברים, בדיקת מהירויות, ניטור דרך הענן ועוד.

אחד הדברים שיותר ויותר חברות מעוניינות בו, הוא פתרון ה-Hybrid, וכאן הדברים קצת מסתבכים..

כפי שציינתי לעיל, יש פתרון כמו VMWare on AWS שמאפשר לך "להרחיב" את המערכת המקומית שלכם לענן אך ממשיך להשתמש במושגים ובטכנולוגיות של VMWare. אם ניקח לדוגמא את 3 המכונות מהדוגמא הקודמת, נוכל בקלות לבצע עבורם Migrate לתשתית ה-VMWare on AWS בענן וכל מה שנצטרך לשנות לפני המעבר זה החיבור ל-vSwitch/DVSwitch, לבחור לאן לאחסן את המכונות ועוד מספר פרמטרים – והמערכת תבצע את השאר בצורה עצמאית.

חברות רבות לעומת זאת מחפשות משהו יותר "מעונן" – הן מחפשות דברים כמו שרצים בענן, אך שירוצו מקומית עם אפשרות שימוש ב-Hybrid להעברת עומסים, מבלי להיות תלוים בפתרון של VMware (או שהם כלל לא משתמשים ב-VMware). מיקרוסופט לדוגמא מציעה את Azure Stack – מדובר בערימה של שרתים שמריצים תוכנות, סקריפטים ודברים נוספים על המכונות הללו והתשתית הזו יושבת ב-DC המקומי של הלקוח והוא מקבל גירסה מזערית של Azure מקומית עם אפשרות להתרחב ל-Azure הגלובאלי ובכך לעבוד או מקומית בלבד תוך שימוש בכלים הרגילים על Azure (מתאים לגופים בטחוניים לדוגמא) או שימוש כ-Hybrid כמקומי והעברה פנימה והחוצה לענן הציבורי. גם אמזון הכריזה על פתרון דומה שנקרא AWS Outposts וגוגל גם בונים פתרון כזה (אם כי עדיין לא ראיתי שום הכרזה קונקרטית על משהו מצד גוגל).

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

אלו שרוצים משהו פחות מחייב ויותר מדבר על פתרון Hybrid שמתייחס לקונטיינרים ומכונות VM יכול להשתמש כמובן ב-Open Stack והוידאו הבא מסביר בהרחבה איך ניתן לחבר OpenStack מקומי לעננים הציבוריים השונים.

לסיכום: בין אם מתחילים להעביר תשתית ממקומית לענן ובין אם חושבים לעבור מתשתית מקומית בלבד/ענן בלבד ל-Hybrid – מומלץ להתאזר בסבלנות ולחקור את הפתרונות. תחום ה-Hybrid מקבל המון "באזז" לאחרונה וחלק מהפתרונות לא שווים אפילו PoC, אז לפני שקופצים למים – קראו על הנושא, קחו יעוץ ותראו מה הפתרונ/ות ששווים עבורכם.