שימוש ב-Wireguard כפתרון VPN מלא

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

עד כה הפתרונות המוכרים ורצים במקומות שונים, היו פתרונות כמו IPsec, או OpenVPN או פתרונות קנייניים של יצרנים שונים (גם יצרני נתבים ביתיים כמו ASUS הוציאו פתרונות VPN כמו Instant Guard … שלא נתמך ב-Windows , Mac או לינוקס אלא רק למובייל) שעובדים בצורה מעולה. הבעיה בדרך כלל כשמדובר על גוף עם תקציב קטן (או ברצון לא להוציא כסף) – הפתרונות הנ"ל לא היו יכולים לבוא בחשבון, ומה שכן בא בחשבון סבל ממגבלות של רישוי (OpenVPN – מקסימום 2 משתמשים), ניצול גרוע של רוחב פס (במיוחד כשמתחברים לתשתית ביתית או upload בכמות מגהביט מזערית) והבעיה הגדולה מכולן – חוסר עדכונים לפתרונות הללו. בנוסף, פתרונות רבים מבוססי נתבים ביתיים מקבלים כמות קטנה מאוד של עדכוני תוכנה, כך שפתרון VPN מבוסס נתבים כאלו יכול להיות פתרון די מסוכן.

הפתרון שמקבל תאוצה בשנים האחרונות מגיע מכיוון אחר, מעולם הלינוקס, והוא פתרון ה-Wireguard. למי שלא מכיר, Wireguard מממש פתרון VPN, אולם הוא עושה זאת תוך שימוש בצופנים מודרניים שאינם "חונקי מעבד" ולא מצריכים פתרונות חומרה במעבדים. כך לדוגמא, Wireguard שרץ על Raspberry Pi 4 ויכול לתת תעבורה מוצפנת במהירות של 400 מגהביט, מספר הרבה יותר גבוה מ-OpenVPN (שנותן רבע או שליש מזה) ובחלק מהמקרים הוא עוקף פתרונות IPSec שונים מבחינת ביצועים ורוחב פס.

ל-Wireguard יש מספר יתרונות גדולים:

  1. ההגדרות עצמן די קלות, ולמי שמסתבך, יש כלי שנקרא PiVPN (שגם רץ על דביאן ואובונטו על מכונות X86-64) שעוזר להגדיר את ה"שרת" ואת ה-Clients בקלות.
  2. אין צורך בהגדרות משתמשים וסיסמאות. שרת ה-VPN צריך בסך הכל את המפתח הציבורי של ה-Client וה-Client צריך את המפתח הציבורי של השרת. השאר – הם הגדרות כתובת IP, DNS ומספר דברים נוספים לא ממש מורכבים.
  3. מבחינת שינויים בנתב – השינוי היחיד שצריך לבצע הוא הגדרת Port forward ב-UDP אל המכונה שמריצה את ה-Wireguard כשרת. אפילו הנתבים של בזק יכולים לתת זאת בלי בעיה. (הערה: בימים האחרונים פרסמתי כי יש לי בעיה בנתבים מסויימים עם הגדרות ל-Wireguard, מסתבר כי זו היתה בעיית הגדרה של firewalld במכונה)
  4. אתה יכול לנצל את מלוא רוחב הפס Upload שיש לך להנאתך. במקרים של חיבורים כמו DSL או כבלים, רוחב ה-Upload הוא מספר נמוך מאוד של Megabits (בד"כ עד 5) ופתרונות VPN מתחרים יוציאו מתוך זה אולי 1-2 מגהביט. עם Wireguard לפי נסיון שערכתי – מתוך 4 מגהביט Upload, קיבלתי רוחב פס של כ-3.5 מגהביט מוצפן החוצה (Upload).
  5. מבחינת Clients – כל מערכת הפעלה תומכת ב-Wireguard – כל הפצות הלינוקס, אנדרואיד, iOS, מק, Windows, כולל Tizen (אם יש לך את ה-SDK ואתה רשום כמפתח..).
  6. הגדרות Client די קלות במובייל – צור Tunnel, צלם תמונה (עקוב אחר ההוראות של PiVPN), שמור. נגמר. ההגדרות גם קלות ב-Windows ומק – העבר קובץ conf שיצרת עבור ה-client למערכת ההפעלה הנבחרת, הפעל Wireguard client, בצע יבוא (Import tunnel) והפעל.
  7. הקץ להעברת כל התעבורה דרך VPN – הגדרת AllowedIPs תאפשר להגדיל ניתוב VPN רק לתשתית מסויימת (Split DNS), וכל השאר יעבור בצורה רגילה דרך האינטרנט. הקץ לגלישה שעושה "טיול" בחו"ל – לאתרים מקומיים.
  8. כשמדברים על מערכות עם עדכוני אבטחה, כל הפצת לינוקס שתתקין (למעט Fedora) תגיע עם הבטחת עדכונים ל-5 שנים לפחות (גרסאות כמו Rocky/Alma/Oracle לינוקס – ל-10 שנים)

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

השוואת Proxmox למתחרים

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

קצת מידע על Proxmox – מדובר מערכת ותיקה שהחלה את חייה עוד לפני שלמעבדי X86 היו יכולות וירטואליות בחומרה כמו שיש להם כיום, ולפיכך המערכת תמכה בפתרון וירטואליזציה כמו OpenVZ – הרצת מערכת לינוקס (ומערכות אחרות, אך לא Windows) בקונטיינר (אם כי פורמט הקונטיינר שונה מפורמט כמו של Docker וכו'). מאוחר יותר, כש-KVM בלינוקס צבר עם QEMU פופולריות, הוא הוטמע בפתרונות רבים (כל ספקי הענן הציבורי משתמשים ב-KVM הלינוקסי, מיקרוסופט ב-Azure משתמשת ב-KVM ב-Instances המאפשרים Nested Virtualization) וגם ב-Proxmox וכיום כשמקימים מכונה וירטואלית ב-Proxmox, היא תרוץ עם KVM.

כשזה מגיע לוירטואליזציה, Proxmox עומד בכבוד מול המתחרים ויש לו כמעט את כל מה שיש בפתרונות Hypervisor מתחרים. אין בעיה להצמיד ב-VM חומרה מסוגים וחיבורים שונים, המערכת תקבל בשמחה כל דיסק עם כל File system כ-Storage, כולל ext3, ext4,btrfs, zfs,ceph, glusterfs, והמערכת גם כוללת תמיכה שיתופית באחסון: יש לך דיסקים במכונה אחת אך לא במכונה אחרת? אין בעיה! בהגדרת ה-Storage, בחר ב-All Nodes (ראו תמונה לעיל, לחצו להגדלה) והמערכת תייצר עבורך NBD מבלי שתצטרך להרים NFS או CIFS עם כל ההגדרות. גם כשזה מגיע לשרידות, יש ל-Proxmox מה להציע (כל עוד יש לך 3 מכונות פיזיות) – הגדר את המכונות הוירטואליות שאתה מעוניין שישרדו, והמערכת תבצע להן מיגרציית Live אם אחד השרתים יורד בצורה מסודרת, או שהיא תריץ את ה-VM מחדש במכונה אחרת (כל עוד האחסון מבוסס על NFS או CIFS. קצת בעייתי לבצע שרידות שכל הדיסקים יושבים על שרת אחד שבדיוק מכבים אותו)…

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

מה קורה אם ניקח את Proxmox ונשווה אותו לפתרונות יותר גדולים כמו oVirt/RHV או vSphere של VMware? התשובה פשוטה: אין ל-Proxmox סיכוי להתחרות, הואיל ו-Proxmox לא כולל חלקים רבים. קחו לדוגמא עניין כמו איזון עומסים של מכונות VM בשרתים (ב-VMWare זה נקרא DRS, ב-oVirt/RHV זה נקרא Scheduling Policies) – זה לא קיים ב-Proxmox. עוד דוגמא קשורה לניצול כל הדיסקים הקיימים בשרתים ליצירת מערך אחסון גדול ושורד. נכון, יש GlusterFS שנתמך ב-Proxmox, אולם ל-Proxmox אין מושג ירוק מה קורה עם ה-GlusteFS – אתה יכול לבצע Mount וזהו. ב-VMware לעומת זאת, פתרון vSAN ליצירת אחסון מדיסקים – נלקח הרבה יותר ברצינות (ב-oVirt/RHV היה פתרון Hyperconverged מבוסס GlusterFS אולם הוא היה פתרון חצי אפוי והוחלט בשקט לבעוט אותו החוצה). אם נבחן לדוגמא את עניין הרשתות ושימוש ברשתות וירטואליות, הממשק ב-Proxmox מאוד אנמי (אין לך אפשר להגדיר דברים כמו VLAN, Slaves ודברים רבים דרך הממשק, אין לך אפילו אפשרות לראות אם החיבור נפל או לא, ואם אתה מתעקש להגדיר, אתה צריך לעבוד בדרכים הישנות, כמו לפני ש-NetworkManager או Netplan היו קיימים) ואילו ב-vSphere או RHV הדברים נלקחים בצורה הרבה יותר רצינית (הנה דוגמא ב-oVirt), ועוד לא דיברנו על ההתעקשות של מפתחי Proxmox לא לשלב את libvirt – ה-API הגדול והמשמעותי ביותר לכל ענייני וירטואליזציה בלינוקס ובמערכות הפעלה אחרות.

לסיכום: Proxmox הוא פתרון מעולה, למצבים מסוימים – אם רוצים להעביר משרד קטן P2V לשימוש ב-Thin clients כשהכל רץ על שרת אחד או שניים, לסטארט אפ קטן שאין לו תקציבים כרגע להשקיע בתשתית והוא לא רוצה/לא יכול להתחיל לעבוד בענן ציבורי ועוד, אך מעבר לכך – ארגונים גדולים, חברות גדולות, מוסדות ועוד – מומלץ שימשיכו להשתמש בפתרונות של VMware (או Nutanix) ומומלץ גם להכיר מה הולך לקרות ב"גל" הבא – ועל כך אפרסם פוסט נפרד.

על חוות שרתים מעל ומתחת לאדמה

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

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

התשובה עצמה – קצת מורכבת, וברשותכם – אפרט.

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

מה שתמיד מומלץ ללקוחות לעשות, זה לעבוד עם הכלים והפלטפורמות של ספקי הענן הציבורי הגדולים בכל הקשור לשרידות, ולהזניח את שיטות ה-DR הקלאסיות. שלושת ספקי הענן הגדולים, לדוגמא, מאפשרים להקים תשתית וירטואלית של שרותים ומכונות VM שפועלות במקביל במספר Availability zones (או Regions), כך שאם AZ או Region (תלוי בטרמינולוגיה של ספק הענן הציבורי) נופל או נפגע, התשתית הוירטואלית של הלקוח תמשיך לפעול מה-AZ או ה-Region האחר שנמצא גיאוגרפית במיקום שונה. לאלו שמוכנים להשקיע עוד, ניתן אפילו לבנות זאת בצורה של שימוש ב-3 Regions (או Region נוסף מחוץ לישראל ו-2 Availability zones), כך שלא חשוב מה יקרה בישראל, המערכת של הלקוח עדיין תמשיך לעבוד. אפשרות נוספת (ותמיד מומלצת) היא שימוש ב-Multi Cloud תוך שימוש בשרותים של ספקי ענן ציבורי שונים והקמה של התשתית אצל ספקי ענן ציבורי שונים, כך שאם קורה מקרה נדיר בה כל התשתית של ספק ענן ציבורי כלשהו נופלת – המערכת של הלקוח תפעל אוטומטית מהתשתית של ספק ענן ציבורי אחר.

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

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

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

אז מה עושים אם יש לנו מכונת אובונטו מגירסה ישנה כמו 14? זה כבר לא נתמך במסגרת ה-LTS (כלומר Long Term Support) שלא לדבר על המקרים בהם הותקנה גירסת אובונטו אך משום מה לא התקינו גירסת LTS…

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

כפי שניתן לראות – המשבצות הסגולות מכוסות דרך Ubuntu Advantage, כך שגם הפצות ישנות מאוד מקבלות עדיין "חיים" עד לפחות לשנת 2024.

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

  • קבלת תמיכה בהתאם לחבילה – מענה תוך שעה, 4 שעות וכו' – לתמיכה ל-OS עצמו
  • קבלת תמיכה לאפליקציות מסויימות תוך עמידה ב-SLA, כולל תיקוני באגים.

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

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

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

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

ההזדמנויות הבאות לחברות אינטגרציית שרותי ענן

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

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

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

אחת הנקודות שרבים פספסו לגבי הפרויקט, החשכ"ל וגופים ציבוריים ומשרדי ממשלה – הוא עניין ההגירה מ-Azure, הווה אומר: משרד ממשלתי או גוף ציבורי שאימץ את כללי חשכ"ל – יצטרך להעביר את התשתיות שלו מ-Azure אל GCP או AWS, ובמידה ואותו משרד או גוף ציבורי מתכנן מעבר תשתיות מ-On Prem, הספקים היחידים שהוא יוכל להקים אצלם תשתית ענן הם אמזון (AWS) או גוגל (GCP) או שילוב של שניהם (Multi Cloud).

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

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

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

בהצלחה לכולם 🙂

כמה מילים לגבי בזק והסתכלות קדימה

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

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

להלן מספר נקודות למחשבה:

  1. יו"ר בזק, גיל שרון, ציין בכתבה כי "הרכישה נועדה להשלים ולחזק את היכולות שלנו בתחום הענן. זהו תחום צומח מאוד, בין היתר לאור מכרז נימבוס למגזר הציבורי, ובעקבותיו ההגעה של חברות הענן הגלובליות לישראל….". נחמד, אך אם הוא היה שואל מספר אנשים, אולי היה נודע לו כי משרדי ממשלה וגופים ציבוריים רבים ינטשו בקרוב את Azure, ובמילים אחרות – הרווח הצפוי להתקבל ממשרדי ממשלה על שרותים אלו – יחתך בצורה משמעותית מאוד.
  2. החברה שבזק רוכשים, מתמחה באינטגרציה של שרותי מיקרוסופט/Azure, אך אין שום דבר שמציין כי לחברה יש נסיון עשיר במתן שרותי אינטגרציה בעננים אחרים כמו AWS או GCP. אם נסתכל על הסעיף הקודם, נראה כי משרדי ממשלה וגופים ציבוריים יצטרכו לעזוב, ובעצם ההכרזה כי CloudEdge מוכרת רק שרותים של מיקרוסופט, הם יוצרים "עבודה קלה" למתחרים, שיחפשו בדיוק "לחטוף" את הנתח היוקרתי הזה לטובת מתן שרותי אינטגרציה על העננים הציבוריים המתחרים. תמהני אם בבזק לא חשבו על כך.
  3. עוד נקודה אחת: האם בזק ניסו לבדוק את שוק חברות האינטגרציה, עם דגש על מתן שרותי אינטגרציה למגוון ספקי ענן ציבורי? אם לא, מדוע בזק חושבים שמיקרוסופט תזכה בכל העוגה כאן? אדרבא, דווקא ארגונים גדולים ורבים בארץ (כולל מוסדות פיננסיים גדולים וידועים) עושים צעדים לעבור ל-AWS וזהו דבר ידוע, אז מדוע להתעלם מכך?

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

לטובת המעורבים, כולי תקווה שאני טועה.

אורקל הפסידה בערעור לגבי נימבוס – ניתוח

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

פסק דין ערעור אורקל

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

להלן כמה נקודות שעלו לי בראש בזמן קריאת המסמך:

  1. מן היקב ומן הגורן. השופט ציין שאורקל הביאה סיבות שונות מדוע יש לפסול את המרכז, ובמסגרת הטיעונים, היא הביאה טיעונים די מגוכחים, בלשון המעטה, החל מכך ש"פרצו" לגוגל ולאמזון עם "הוכחות" של קטעי עיתונות שרק הראו בעצם כי ה"פריצות" הן הגדרות שגויות של הלקוחות בתשתיות הוירטואליות (של אותן לקוחות) ללא שום הוכחה כי אכן אירעה פריצה לתשתיות של גוגל או אמזון. בנוסף הביאה אורקל את עניין ה-מחאות של עובדי גוגל ואמזון על הקמת תשתית בישראל וקריאה לבטל הסכמים, מה שגרם כמובן לגוגל ואמזון להודיע חגיגית לבית המשפט ששום חוזה לא הולך להיות מופר, והם כבר השקיעו סכומים גדולים בישראל, כולל השגת כל האישורים הנחוצים להקים את התשתיות כאן.
  2. לאורקל לא היו השגות על הזוכים (תיכף ארחיב על כך) והערעור הוא על כך שאורקל לא נבחרה בעצם כ"כשיר נוסף", כלומר כזוכה נוסף, והיא הביאה פרשנות די מקורית משלה, פרשנות שהשופט די מהר פסל תוך ציטוט ממסמכי המכרז ומבלי צורך לפרשן יותר יותר מדי.
  3. אורקל מתעקשת לשמש כ"כשיר נוסף" למרות שהיא לא מגיעה לציונים הנדרשים, לא מבחינה טכנולוגית ולא מבחינת סייבר, ובוודאי שלא ב"ציון איכות מזערי" שהמינימום הנדרש בו הוא 75%, ולמרות זאת – היא רוצה שוועדת המכרזים תתעלם מהמספרים ותוסיף אותה.
  4. אורקל ערערה לא רק עם נסיבות הזויות כמו שכתבתי לעיל, אלא גם ערערה על תשובות עורך המכרז והצוותים, וצוות המכרז השיב לה לגבי ההערות, אולם העניין לא הגיע לדיון והשופט החליט לדחות את הערעור ולקנוס את אורקל ב-270 אלף שקל (90,000 שקל למשרד האוצר, לגוגל, ולאמזון).

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

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

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

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

אני מכין את הפופקורן.

פוסט תגובה ל-"לא להינעל" (המאמר של ליאור קיסוס)

קראתי את מאמרו של ידידי היקר ליאור קיסוס באתר PC, וחשבתי להגיב לגבי הדברים.

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

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

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

את הריצה המטורפת לשימוש ב-SAAS אני רואה מכל עבר, ואני חוזר ומציין תחת כל עץ רענן כי ברוב מוחלט של המקרים, שרותי ה-SAAS הם מיותרים לחלוטין אם לא מדובר בפרודקשן שחייב להיות זמין 24/7. אדרבא, ככל שמשתמשים בכמה שיותר שרותי SAAS, האפשרות למעבר לספק ענן מתחרה הופך להיות יותר ויותר קשה, במיוחד כשרוב מוחלט של ספקי הענן הציבורי כיום כלל לא מציעים שום Migration Path נורמלי מענן אחד לשני, ואף אחד כמובן לא מוכן לממן את השינויים בסקריפטים ובמקומות אחרים שצריכים לשנות כדי לעבור ענן.

יש נקודה מסויימת שאינני מסכים עם ליאור, והיא קשורה למחיר: מחירי הענן לא עולים ועולים, ואני אומר זאת באחריות: אני משתמש בשרותי ענן של אמזון כבר 6 שנים לצרכיי האישיים, וכיועץ אני מתעדכן תדיר במחירים של הספקים השונים מבחינת מחירי תשתיות ושרותים. כמעט בכל מצב, תמיד אפשר למצוא דרכים לחסוך כספים בענן, אם מוכנים קצת, טיפה, להתאמץ: במקום להשתמש ב-RDS, תפסיקו להתעצל ותקימו בעצמכם תשתית SQL (לדוגמא). במקום להשתמש ב-CDN הסופר יקר של ספק הענן, תשתמש ב-CDN של מתחרים שאינם נופלים בביצועים ובאיכות ממה שספק הענן שלכם מציע, יש "שכבות" שונות לאחסון Object Storage כמעט אצל כל ספק ענן וניתן בעזרת סקריפט פשוט להעביר קבצים (אם לא רוצים לשלם על Tiering חכם), וזה – על קצה המזלג, כך שבעזרת תכנון נכון וניטור מתמשך, לא צריך להגיע למצב של "שריפת" תקציבים אצל ספק הענן הציבורי.

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

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

חושבים להתחבר לסיבים?

האם אתם חושבים להתחבר לאינטרנט בסיבים בבית? האם העסק שלכם רץ מהבית?

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

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

צפיה נעימה.

קצת פרטים לגבי DCPMM של אינטל

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

בשנים האחרונות אינטל הוציאה את מקלות ה-DCPMM (ר"ת DC Persistent Memory Module). אלו מקלות אחסון שאינם משתמשים ב-NAND כמו אחסון SSD אחר, אלא 3D Xpoint, שיטה חדשה שמאפשרת כתיבה וקריאה במהירות מאוד גבוהה ושרידות (מבחינת DWPD לדוגמא) גבוהה בהרבה, בהשוואה לפתרונות Flash אחרים שקיימים בשוק. אינטל הוציאה גם פתרונות אחסון קונבנציונאליים מבוססי 3D Xpoint (תחת השם Optane, למרות שתחת השם הזה הם הכניסו עוד סוגים שונים של אחסון, למה לא לבלבל את הלקוח הפוטנציאלי!) אך ה-DCPMM היה שונה בכך שהוא הרבה יותר מהיר והוא משובץ בתושבות הזכרון בשרת, וכתוצאה מכך, שימוש ב-DCPMM יחד עם זכרון RDIMM יכול לתת פתרון די טוב לזכרון בכמות גבוהה, במחיר יותר נמוך בהשוואה לכמות זהה של זכרון אם כולו היה מבוסס DRAM RDIMM.

בוידאו הבא אסביר קצת לגבי דברים כמו:

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

להלן הקליפ.

נקודות חשובות נוספות לגבי הנושא:

  • כאן יש מסמך חשוב מאוד מחברת לנובו המשווה את ביצועי המערכת אם משתמשים רק בזכרון, או שילוב של יותר זכרון ומעט DCPMM, וההיפך, וכמו כן הוא נותן דוגמאות לגבי יחסים RDIMM עם DCPMM מצוותים. מומלץ לקרוא.
  • הפתרון אינו קיים למערכות שאינן מבוססות אינטל (כמו AMD) הואיל ומדובר בפתרון סגור וקנייני של אינטל.
  • לא מומלץ להשתמש במצבי אחסון Block Storage כשמשתפים מקלות DCPMM משני מעבדים שונים (או יותר, במקרה ומשתמשים במעבדי ה-Cooper Lake) אלא אם יש לכם מעבדים מסידרה L או מעבדי GOLD, אחרת נוצר צוואר בקבוק שקשה לשחרר.
  • ולחבריי הגיקים שצופים בערוץ היוטיוב של ServeTheHome – אכן ראיתי את הקליפ של פטריק אתמול, וזה הזכיר לי שעל הנושא לא הוצאתי כמעט כלום, אז בגלל זה החלטתי לבצע "השלמות" 🙂