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

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

ההבדלים בין מעבדי אינטל שונים עבור שרתים (וידאו קליפ)

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

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

פרילאנסרים, מצלמה ושיחות וידאו

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

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

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

לפניכם תמונה. זוהי תמונה שלי באפליקציית זום. למי שלא מכיר – נעים מאוד 🙂

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

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

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

  1. הורידו והתקינו את אפליקציית OBS Studio מהקישור הבא (שימו לב: גירסת לינוקס אינה תומכת במצלמה הוירטואלית, נכון לגירסה 26.1, כך שזה יעבוד רק על Windows או מק).
  2. הפעילו את התוכנה והתרכזו בצד שמאל, בקוביה שכתוב עליה Sources
  3. לחצו על מקש ה- + בחרו Video Capture Device, תנו לזה שם, לחצו OK, ובחרו את המצלמה שלכם (חשוב שהיא לא תהיה בשימוש באפליקציות שיחות אחרות באותו זמן)
  4. באותו חלון של בחירה, יהיו אופציות שונות להגדרת המצלמה. אם אתם לא מבינים בתחום או לא מכירים – אל תשנו. לחצו OK
  5. אם הבחירה שלכם עבדה, אתם תראו את עצמכם בתוך חלון מוקף במסגרת אדומה. המסגרת מציינת אובייקט אקטיבי ב-OBS.
  6. אם אנחנו רוצים להוסיף לוגו, נלחץ שוב על ה- + ונבחר Image. חשוב: ה-Image אמור להיות בפורמט PNG אם רוצים רקע שקוף ללוגו (כמו אצלי בתמונה לעיל). תנו שם, לחצו על Browse ובחרו את הקובץ PNG עם הלוגו. לחצו OK לאישור. שוב אנחנו נראה ריבוע אדום מסביב לתמונה – השתמשו בריבועונים הקטנים מסביב לריבוע האדום הגדול כדי להקטין את התמונה ולמקם אותה היכן שתרצו.
  7. אם נרצה להוסיף טקסט (כמו שם, לדוגמא), נלך שוב לקוביית ה-Sources, נלחץ על + ונבחר Text +GDI – שוב, תנו לזה שם ולחצו OK. כעת יפתח חלון ובתוכו תהיה קוביה שחורה עם הכיתוב משמאל "Text" – הכניסו כאן את הפרטים שאתם רוצים (אפשר במספר שורות). שימו לב שהחלון שנפתח – נגלל, ויש אופציות שניתן לשחק איתן כמו פונט, צבע, ישור לימין, שמאל וכו'. הכניסו את הטקסט שאתם רוצים (אם אתם רוצים להכניס טקסט במספר גדלים, תצטרכו ליצור מספר אובייקטים של טקסט). אחרי שלחצתם OK, שנו את גודל ומיקום הטקסט על החלון.
  8. אפשר להוסיף אלפי דוגמאות נוספות וליצור דברים מדהימים (למי שלא ממש מרוצה מהאפקטים הוירטואליים של זום, ב-OBS יש תמיכה מלאה ב-Chroma Key, להלן קישור להוראות).

מרוצים ממה שאתם רואים? מעולה.

מצד ימין יש מספר כפתורים מוארכים (כמו Start Streaming וכו'). לחצו על הכפתור שנקרא "Start Virtual Camera")

זהו, אתם יכולים לבצע מינימליזציה של חלון ה-OBS (ב-Windows אפשר ללחוץ על אייקון ב-OBS בשורת האייקונים מימין/שמאל).

פתחו את אפליקציית הזום או סקייפ, לחצו על גלגל השיניים מצד ימין למעלה, לחצו על Video, ובחרו OBS Virtual Camera. אתם אמורים לראות מה שרואים ב-OBS. תוכלו לבחור אופציות אחרות כמו Mirror, תאורה וכו'.

ברכותיי, התצוגה המשופרת של עצמכם פעילה, תהנו מהחשיפה 🙂

מספר נקודות טכניות:

  • משתמשי מק – לא בטוח שהמצלמה הוירטואלית תעבוד (במיוחד עם Big Sur). כפי הנראה שתצטרכו להעיף חתימות, כפי שמוסבר כאן.
  • למי שרוצה – אפשר לבצע Up scaling של הוידאו. המצלמה הוירטואלית תשדר לפי הרזולוציה שמוגדרת ב-OBS. לשינוי – יש ללחוץ על Settings, על Video ולהגדר את ה-Output לרזולוציה שרוצים. שימו לב – סביר להניח שזה יאמץ את המחשב שלך במעט.

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

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

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

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

  • תכיפות שינויי קוד: חברות כמו רד-האט מפתחות את מוצריהן בצורה פתוחה וזמינה לכולם ב-github, ומכיוון שהפיתוח נעשה בצורה פתוחה וציבורית, מבוצעים שינויי קוד רבים, במקרים רבים – שינויים יומיים, וברוב המקרים, גם אם מוכרזת גירסה של הפתרון/ספריה/פלטפורמה – הגירסה אינה כוללת עדכוני אבטחה, בדיקות יציבות ותיקונים אחרים שקיימים בגרסאות המסחריות. מעבר לכך – אם המוצר קורס או גיליתם באגים – תהיה לכם בעיה לקבל סיוע, והכל יהיה תלוי בליבם הטוב של מתנדבים או עובדים (וגם על זה לא מומלץ לבנות, הואיל וחברות כמו סוזה, רד-האט, קנוניקל ואחרים – מקבלים הוראה לתעדף תיקוני באגים לאלו שרכשו גרסאות מסחריות או לאלו שמשלמים על חוזי שרות ליצרן התוכנה).
  • גרסאות תכופות – פתרונות כמו OpenStack, Kubernetes, Ceph, Gluster ופתרונות רבים אחרים משוחררים בתדירות די תכופה ע"י הקבוצות המפתחות אותם עבור יצרניות הפצת לינוקס. הן לוקחות את הקוד, מבצעות שינויים ותיקונים, מוסיפות עדכוני אבטחה (שיחזרו לקוד ה-Upstream יותר מאוחר), כותבות תיעוד ספציפי ועוד ועוד – ואז משחררות אותו במסגרת Life Cycle רשמי עם תמיכה רשמית ועוד, ומוציאות זאת כמוצר מסחרי, ובמילים אחרות – אותם מוצרים שיוצאים כגרסאות תכופות אינם מיועדים לפרודקשן.
  • האם יש לך צוות לינוקס בחברה? אם יש לך צוות In House שמבין היטב בלינוקס ויכול "לשחות" בתוך קוד של אחרים במקרה של תקלה במוצר/ספריה/פלטפורמה – במקרים כאלו קל יותר להטמיע פתרונות בקוד פתוח שעדיין לא יציבים כפרודקשן, ולכן כדאי להסתכל על הנקודה הבאה…
  • אבטחה – פתרונות קוד פתוח שלא מגיעים מיצרן כלשהו, בחלק גדול מהמקרים לא כוללים עדכוני אבטחה, ולכן אם החלטתם בכל זאת להטמיע את הפתרון בחברה, מומלץ כי אחת לחודש הצוות הפנימי בארגון יבדוק את הפתרון המותקן מול הפתרון שנמצא ב-github לדוגמא, ובמיוחד יבדוק אם ישנם תיקוני/עדכוני אבטחה שפורסמו בנפרד (כ-PR או במקומות אחרים) או גרסאות minor בהשוואה למה שמותקן פנימית – ויבצע עדכון ידני. ארגונים שאין ברשותם אנשי לינוקס, מומלץ מאוד יהיה לעבוד עם הגירסה המסחרית ולקבל את העדכונים מהיצרן.

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

להתראות CentOS??

בימים האחרונים יצאה הודעה כי CentOS 8 תעבור שינויים משמעותיים ובכללם – ההפצה תחדל מלקבל עדכונים בסוף שנת 2021, ולא תהיה הפצת CentOS המקבילה ל-RHEL מבחינת גירסא וקוד. הדבר היחיד שישאר הוא CentOS Stream שזו גירסת CentOS טיפה יותר "מתקדמת" מ-RHEL (אבל מבחינת עדכוני אבטחה – ה-Stream יקבל את העדכונים רק לאחר ש-RHEL יקבל).

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

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

ראשית, אני יכול להבטיח שאין ל-IBM יד ורגל בנושא ובהחלטה. רד-האט היא עדיין חברה עצמאית שמחליטה לעצמה החלטות, כולל את ההחלטה הזו.

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

שלישית – ולעניין זה לא תקבלו שום אישור מגורם רשמי: התקדמות טכנולוגית שגורמת להפסד פיננסי לרד-האט. בעבר, אם הייתי צריך להרים תשתית לינוקס גדולה לפיתוח, פרודקשן, עם backend ועוד דברים רבים – הייתי צריך בארגון גדול, לרכוש מספר לא קטן של רשיונות RHEL לכל שרת פרודקשן, בין מדובר בשרת פיזי או וירטואלי. כיום, לעומת זאת, המעבר לקונטיינרים חוסך לי בצורה משמעותית את כמות רשיונות ה-RHEL שאני צריך לרכוש לפרודקשן. אם פעם, לשם הדוגמא, הייתי צריך לרכוש 20 רשיונות, היום 4 רשיונות ל-Worker Nodes יספיקו, ופה מדובר רק בדוגמא אחת. רבים כיום יעדיפו הפצת לינוקס חינמית ברוב המקומות למעט היכן שחייבים בגלל ההנהלה להשתמש בהפצות RHEL מסחריות.

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

כל איש לינוקס ותיק ירגיש בוודאי תחושת דה-ז'ה וו בנושא. כבר היינו בעבר בסרט הזה. כשחברת רד-האט החליטה להוציא רק גרסאות לינוקס מסחריות בתשלום (מה שהיה RHEL, RHES), נוצרו מספר פרויקטים שלקחו את קוד המקור של RHEL וביצעו Fork לגירסה עם שם אחר אך עם תאימות מלאה (בעקרון, לא מדובר בתהליך של קימפול הכל מחדש באופן אוטומטי. יש לא מעט כלים לפתח, יש לא מעט סקריפטים לכתוב, להסיר קבצי לוגו וסימנים מסחריים של רד-האט וכו') כשה"זוכים" בפופולריות בסופו של דבר היו CentOS, Scientific Linux וכמובן Oracle שהחליטה פשוט לבנות את הכל בעצמה ולגנוב לקוחות מ-רד-האט.

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

לפיכך, להלן המלצותיי (לפי התיעוד הרשמי):

  • אם אתם משתמשים בגירסה כלשהי של CentOS 6 – שדרגו בדחיפות. ה-EOL שלה חל בחודש שעבר.
  • אם אתם משתמשים בגירסה כלשהי של CentOS 7 – אתם בטוחים, ואתם תמשיכו לקבל עדכונים לגירסה עד תאריך 30/6/2024. אם אינכם חייבים לעבור לגירסה 8, פשוט אל תעברו, במיוחד אם המכונות הן וירטואליות.
  • אם אתם משתמשים בגירסה כלשהיא של CentOS 8 – אתם תקבלו עדכונים עד סוף שנה הבאה (31/12/2021)
  • עכשיו, כל מה שנותר לעשות, זה להמתין ולראות מי "יקפוץ". האם רד-האט תחזור בה? (קהילות הלינוקס הן לא קהילות מנומסות, בלשון המעטה!) ואם לא, מי החברות שיכריזו על Fork ל-RHEL? (אמזון? מיקרוסופט? גוגל?) במשך השנה הקרובה אנחנו נראה את ההתפתחויות ואני מאמין שכבר בחודשים הקרובים נראה חדשות בנושא עם מפות דרכים והמלצות לאן להגר.

ולבינתיים, אני ממליץ לא לקחת המלצות פזיזות, אם אפשר.

"הר" פתרונות האבטחה שאינו רלוונטי כל כך

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

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

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

הנקודה הכי חשובה בכל הסתכלות על אבטחת מידע היא Zero Trust. לא לתת שום Trust בין אם מדובר בתקשורת מבחוץ פנימה או בין שרתים או בין מכונות דסקטופ לשרתים. אחרי הכל, אם מאן דהוא הצליח להשיג פרטי גישת VPN למערכת שלכם, מהרגע שהוא מתחבר, הוא נמצא בתוך התשתית של החברה, גם אם יש לו הרשאות מוגבלות (גם עם הרשאות מוגבלות אפשר ליצור נזקים גדולים). יקח לחברה זמן להבין שהפורץ משתמש בפרטי גישת VPN שנגנבו בפעולות Phishing ממשתמש לגטימי, ומאותו רגע שהפורץ מחובר, גרימת הנזק היא פנימית, ה-Firewall וה-WAF שלך לא עוזרים במאומה באותו זמן – וכאן, כדאי לזכור, פורץ חכם לא יחפש לגרום מיידית נזק, אלא יחפש בתשתית נקודות חולשה או תשתית "צדדית" שעליה הוא יכול להתקין את ה-Payload ורק לאחר מספר ימים להפעיל זאת ולהתחיל לגרום נזק/להצפין תוכן או להעביר תכנים.

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

  • להיפטר מסיסמאות: סיסמאות היו ויהיו – מקור לאחד מכאבי הראש הגדולים, כולל כל ה-Policies ליצור אותם, החלפתם וכו'. גם במיקרוסופט ובחברות תוכנה אחרות הבינו זאת מזמן והם מציעים פתרונות שונים המבוססים על טביעת אצבע, Windows Hello, מפתחות כמו Yubikey של Yubico (או Tian של גוגל, ויש גם מפתחות המבוססים בכלל על קוד פתוח כמו Solokeys). בנוסף, שימוש במפתחות מאפשר להשתמש בהצפנות שונות (נתמכות בעיקר ב-Yubikey) ויחסית די קל להטמיע את הפתרונות בכל מערכות ההפעלה.
  • הצפנת תכנים: הסיוט הכי גדול לחברות מבחינת אבטחת מידע, הוא גניבה ו/או הצפנה באמצעות כופרה של המידע, וארגונים גדולים מאוד (חברות כמו קאנון, אוניברסיטאות, בתי חולים ועוד) חוו את הסיוט ונזק משמעותי נגרם לאותם ארגונים. אחד הפתרונות שניתן לבצע הוא הצפנה של רוב התכנים החשובים, וביצוע Decryption דרך Gateway שאליו מחוברים מספר מצומצם של משתמשים. ניתן לדוגמא לבצע זאת בעזרת הקמת LUN שיחובר למערכת לינוקס וירטואלית. מערכת הלינוקס תבצע encryption/decryption עם כלי כמו LUKS-2 או בכלים אחרים, ושיתוף (לאחר decryption) עם SAMBA. אפשר להתגונן נגד כופרה תוך שימוש ב-snapshots (במכונת הלינוקס בשימוש LVM).
  • ביצוע Snapshots – באופן עקרוני, Snapshots ברמת File systems לא אמורים לצרוך כמות משאבים גדולה ליצירה ולכן מומלץ ליצור Snapshots בפתרון האחסון ל-File systems בצורה תכופה מאוד (כל שעה לדוגמא, ובמקרים חשובים כמו הנח"ש – כל מחצית שעה). כך, אם ישנה התקפת כופרה, ניתן לשחזר מה-Snapshot במהירות במקום לשחזר מקלטות.
  • Pen testing הוא פתרון חלקי שלדעתי אינו מספק: לצערי לא מעט ארגונים וחברות שוכרים מישהו מחברה שיבצע בדיקות (Penetration testing), ורובם גם משתמשים באותם כלים וב-Kali Linux (מתי אנשים יבינו ששימוש ב-Kali Linux הוא "אות קין" שלמשתמש אין הבנה רצינית בלינוקס? כל הפצת לינוקס כוללת את כל הכלים הדרושים!) כדי לבצע את הבדיקות, ובמתודה זו הבדיקות והסריקות פשוט אינן מספקות את התשובה המלאה.
    בדיקות הקשחה וחדירה זה לא רק שימוש בכלים כמו nmap, nessus ו-1001 כלים נוספים, אלא לימוד כל המערכת ועבודה בצוות כדי לחשוב על נסיונות חדירה מכל מערכת שרצה בארגון, חולשות שקיימות לכל שרת, לכל Appliance ולכל ציוד (במיוחד ציוד ישן שאין לו עדכונים כבר מספר שנים – ציוד כזה מומלץ להחליף כמה שיותר מוקדם), מי הם האנשים בחברה שפעולות Phishing עליהם יכולות לגרום נזק מהותי, היכן ניתן לעצור או להאט דליפת מידע אם גורם כלשהו הצליח לפרוץ, האם יש עצירה אוטומטית של תעבורת Upload ל-IP שאינו white listed לאחר כמה מאות מגהבייט לדוגמא (כשהפורץ מנסה לגנוב כמה שיותר קבצים), ובקיצור – הכלים הם רק חלק קטן מהעבודה, ודרוש צוות רציני כדי לנסות לפרוץ (מבלי להגביל את הצוות, אבל עם הנחיה לגבות את הכל ולרשום כל גילוי ושינוי) ולא מישהו שהקים Kali Linux על מכונה וירטואלית ומכיר כמה כלים.
  • "קמצנות כרונית" של הרשאות: תופעה שקיימת בכל ארגון – עודף הרשאות שניתנו למשתמשים שונים, הרשאות שנפתחו "זמנית" ונשארו פתוחות או הרשאות שנפתחו ברמת worldwide (בלינוקס/יוניקס זה מוכר כ-777) בגלל שמישהו התעצל לחפש בגוגל ולקרוא איך מגדירים הרשאות בלינוקס. מאוד מומלץ לבצע אחת לחודש או לתקופה לעבור על כל ההרשאות (גם הרשאות מקומיות!) ולצמצם את ההרשאות. אם רוצים להשתמש לדוגמא ב-passwordless ssh, יש להגביל את החיבוריות להרצת פקודות מסויימות, כניסה מכתובות IP מסויימות, ועוד.
  • עדכוני תוכנה ללא תאריכון: אחת הבעיות שכתבתי לגביה שוב ושוב בבלוג זה – מנמ"ר מחליט שעדכונים יהיו אחת ל-X חודשים ותו לא. לך תסביר לאותו מנמ"ר שחולשות אבטחה מתגלות כל הזמן ויש לא מעט מקרים שיש צורך דחוף בהתקנת עדכונים, אחרת התשתית חשופה. דוגמא פשוטה: אם אתם משתמשים ב-vSphere, האם עדכנתם את הטלאי הדחוף הזה?

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

תכירו: משפחת ה-Ryzen 5000

חברת AMD הכריזה לפני כשבועיים על מעבדי ה-Ryzen דור רביעי לדסקטופ (מבחינת מספרי הדגמים, הם החליטו לקפוץ מ-3000 ל-5000 לאחר שהם הצליחו ליצור סלט שלם בדגמי ה-4000). בפוסט זה אתייחס הן לדגמי הדסקטופ והן למעבדי ה-EPYC לשרתים שיצאו כבר בקרוב.

מעבדי Desktop לשרתים

מבחינת מעבדי הדסקטופ, ב-AMD ממשיכים להוציא את אותם מספרי דגמים שהוציאו בגירסה הקודמת, בקצה הגבוה נמצא 5950X עם 16 ליבות, 5900X עם 12 ליבות, 5800X עם 8 ליבות ו-5600X עם 6 ליבות, בדיוק כמו שהיה עם ה-3950X, 3900X, 3800X, 3600X, רק שהפעם אין בשלב זה דגמים ללא X כמו שהיו בדגמי ה-3000 (אלו יצאו בשנה הבאה). המחירים – עלו במעט, בממוצע כ-50$ בהשוואה למעבדים מסידרה 3000.

מבחינת ביצועים (שזה כמובן הדבר הכי חשוב למשתמשים) – AMD הציגה עליה משמעותית בביצועים של עד 19% – במיוחד בעבודות Single Threaded, ולראשונה במבחנים סינטתיים – AMD עוקפת את כל המעבדים שאינטל מוכרת בגיזרת הדסקטופ (שוב, בעבודות Single Threaded, ב-Multi Threaded המעבדים של AMD עוקפים ממזמן את המעבדים של אינטל). במבחן כמו Cinebench, מעבד כמו ה-5950X מגיע ל-640 ב-Single Threaded ומעבד 5900X מציג באותו מבחן את המספר 631. לשם השוואה, מעבד ה-10900K מגיע ל-539 באותו מבחן ומעבד כמו ה-Tiger Lake החדש לדסקטופ (דגם: Core i7-1185G7) מגיע ל-598 (אך זהו אינו מעבד לדסקטופ, זהו מעבד למחשב נייד).

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

ישנם לא מעט אנשים שכבר יש ברשותם מעבדי Ryzen והם מעוניינים לשדרג – הנה מספר נקודות לגבי הנושא:

  • אם יש לכם לוח אם מבוסס Chipset כמו X570 או B550 – תוכלו כבר בחודש הבא לרכוש את המעבד, לשדרג את ה-BIOS, להחליף את המעבד ולהמשיך לעבוד כרגיל.
  • אם יש לכם לוח אם מבוסס Chipset כמו X470 או B450 – לרוב הדגמים יצא שדרוג BIOS במהלך חודש ינואר אשר יוסיף תאימות למעבדים החדשים (אך יסיר תאימות ממעבדים ישנים כמו Ryzen מסידרה 1000 ו-2000, פשוט אין מקום בשבב הפלאש לכל העדכונים).
  • רשמית – המעבדים יצאו לשוק ב-5/11. הסיכוי שלכם לרכוש ולקבל מעבד כזה בארץ בתאריך הנ"ל – די טוב (נודע לי לאחרונה כי כבר יש מלאי בארץ, אך המכירה אסורה עד ה-5/11).
  • לאלו שאין ברשותם מעבד Ryzen וחושבים לרכוש (במסגרת בניה עצמית של מחשב) לוח אם ואז את המעבד, אני ממליץ להמתין: בהשקה הרשמית יכריזו יצרני לוח האם על לוחות אם חדשים עם תכנונים משופרים.

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

מעבדי EPYC לשרתים

באופן רשמי, ב-AMD עדיין לא מדברים/מספרים על מעבדי ה-EPYC מסידרה 7003 (שם קוד: Milan), והדברים יפורסמו באופן רשמי במהלך השבועות הקרובים (אני מאמין שבמהלך נובמבר), אבל עד אז – הנה כמה נקודות מעניינות:

  • שיפור ביצועים משמעותי בהשוואה ל-EPYC דור קודם (7002): כמו ב-Ryzen, גם כאן יש תכנון חדש לזכרון המטמון ברמות 1 ו-2, כך שבפועל ה-Latency נחתך בצורה משמעותית, מה שמתורגם לביצועים גבוהים, כאשר ברוב המקרים מדובר על שיפור דו ספרתי.
  • מבחינת וירטואליזציה – מעבד EPYC דור 7002 (הדור הנוכחי) נתנו מספר יתרונות מבחינת אבטחת וירטואליזציה בהשוואה למה שאינטל נותנים (אינטל תתן פתרון מועתק במשפחת מעבדי ה-Xeon הבאים בשנה הבאה, ע.ע. TME) ולאחרונה התבשרנו כי vSpehre 7 עדכון 1 יתן תמיכה בפונקציות החדשות להצפנת מכונות וירטואליות, דבר שיתקבל בהחלט בברכה במקומות שאבטחה היא במקום הראשון. במעבדי EPYC דור 7003 אנחנו צפויים לקבל עוד מספר שיפורים חדשים באבטחת וירטואליזציה (אם כי מבחינת תמיכה, זה אולי יהיה ב-vSphere 7U2 או בגירסה 8, אך אם משתמשים בוירטואליזציה מבוססת KVM – התמיכה תגיע בחודשים הקרובים)
  • אחת הנקודות שעולות שוב ושוב בפורומים שונים של משתמשי EPYC היא תאימות לאפליקציות שאינטל מבצעת בהם אופטימיזציה, כמו הוספת תמיכה ב-AVX 512. ובכן, בדגמי ה-EPYC החדשים יש תמיכה ל-AVX 512 ולעוד מספר טכנולוגיות ידועות.
  • תאימות לאחור – גם הפעם, יהיה אפשר להשתמש במעבד EPYC מסידרה 7003 על שרתים ישנים יותר (3 דורות אחורה). חשוב לציין כי את התמיכה לכך יש צורך לקבל מיצרן השרתים (בד"כ זה יהיה במסגרת KIT הכולל מעבד חדש או במסגרת עדכונים שהיצרן מוציא לשרתים). כל היצרנים יתמכו בשדרוג ממעבדי EPYC דור 7002 לדור 7003, אולם רק חלק מהם יתנו תמיכה לשדרוג מ-EPYC דור 7001.
  • שיפור ביצועים משמעותי בכל הקשור ללינוקס: ב-AMD הוסיפו פקודות חדשות, והוסיפו שיפורים למהדר כמו GCC (זה נקרא Znver3), כך שאם רוצים שיפורים מעבר לשיפורים שמקבלים כברירת מחדל, אפשר לקמפל עם הפרמטרים החדשים ולקבל ביצועים עוד יותר גבוהים

חשוב לציין: גם כאן, כמו עם מעבדי Ryzen, המעבדים שיצאו יהיו כנראה בחזקת "תחנה אחרונה". ב-AMD עובדים במרץ על EPYC דור 7004 (שם קוד: Genoa) שיתן תמיכה ב-PCIe 5, זכרון DDR5, תמיכה ב-CXL, וטכנולוגיות רבות אחרות, כולל שינוי כל ה"שיחה" בין ה-CPU לכרטיסי GPU (בהצלחה ל-NVIDIA עם NVLINK), ומעבדים אלו לא יהיו תואמים אחורה.

לסיכום: AMD פתחה את הרבעון האחרון של 2020 בהכרזה על מעבדי Ryzen, בהמשך החודש על כרטיסי ה-GPU לדסקטופ, ולאחר מכן יגיעו ההכרזות על מעבדי EPYC לשרתים, כרטיסי GPU לצרכי ML/DL. התחרות בתחומי ה-GPU – בשיאה (NVIDIA כבר הכריזה על הכרטיסים שלה, AMD יכריזו בחודש הקרוב, ואינטל במחצית הראשונה של השנה הבאה) והתחרות בתחום המעבדים תתחיל החודש הבא ואילו אינטל תתן מענה הן בתחילת שנה הבאה (ICE Lake, מעבדים שאני לא ממליץ לרכוש, הואיל ואלו מעבדים שיהיו רלוונטיים אולי במשך חצי שנה) והן במחצית השניה של 2021 שבה היא תציג את מעבדי ה-Sapphire Rapids שיהיו מבוססים ארכיטקטורה חדשה (ביי ביי, Skylake), ויהיו שונים מהותית ממה שאינטל מוכרת כיום, ועם שיפורים מדהימים ורעיונות.. יצירתיים.

Exit mobile version