פתרון VDI לעסקים קטנים

למי שזוכר (ולמי שלא) – בשנה שעברה פרסמתי מספר מאמרים על VDI, ובחלק מהמאמרים התייחסתי לכך ששום פתרון מהחברות הגדולות (Microsoft, VMWare, Citrix, ,Nutanix) אינו מתאים לעסקים קטנים שיש להם בין כמות חד ספרתית של מכונות דסקטופ לבין כמות דו ספרתית בינונית (30-50, נניח) של מכונות דסקטופ. עלות פתרון VDI כולל תוכנות, רשיונות, ברזלים – היא מעל ומעבר לתקציב של אותם עסקים קטנים.

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

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

אז איך VSAN בביצועים ובמחיר? (מאמר מעודכן 2/2020)

עריכה: יש עדכונים לפוסט – בסוף.

התבקשתי לאחרונה ע"י חברה גדולה להציע להם פתרון VDI ל-500 משתמשים. הפתרון אמור לכלול את כל מילות הבאז האחרונות: שיהיה Scale Out, שיהיה Hyper Converged, שלא יצטרכו סטורג' חיצוני, ובקיצור – שיכלול את הכל, אבל שלא יתפוס כמה ארונות.

אז הצעתי להם פתרון שכל הגודל שלו הוא 2U, של חברת Supermicro, דגם: A+ Server 2124BT-HNTR עם מפרט ארוך ומותאם לדרישות (את זה אני כבר לא יכול לפרט פה בבלוג). הפתרון הזה כולל הכל, עם פוטנציאל התקף לב מבחינת מחיר החומרה הדרושה ורשיונות. הייתי בטוח ב-99% שהלקוח זורק את ההצעה הזו לפח והולך עם איזה פתרון של Dell/HPE/Lenovo אבל במקום זה קיבלתי בקשה לשיחת סקייפ מאותה חברה. הם התרשמו מההצעה אך הם רצו לדעת קצת יותר לגבי החלק של ה-vSAN.

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

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

הפתרון עובד בשיטה של Disk Groups: קבוצות דיסקים המכילות שני סוגי דיסקים: דיסק Flash מהיר (עדיף NVME) שנקרא "Cache" ודיסקים מכניים או SATA SSD שנקראים "Capacity". כל קבוצה כזו חייבת דיסק אחד Cache ו-2 או יותר דיסקים (עד 7) ל-Capacity. כל שרת יכול להכיל עד 4 Disk Groups. לאחר הגדרות הדברים הללו, יש להגדיר את ה-Policies השונים ל-vSAN וכמו כן להגדיר בכל שרת אלו חיבורים פיזיים ישמשו את ה-vSAN. לאחר כל הגדרות הסלט הללו, יהיה לנו Cluster אחד שלתוכו נשלב את כל השרתים המשתתפים ומקבלים את שרותי ה-vSAN.

מכאן, נצלול קצת יותר לעומק בעניין ה-Disk Groups:

באופן עקרוני, ישנם שני סוגים של Disk Groups, האחד נקרא All Flash והשני נקרא Hybrid, כאשר כפי שניתן להבין, ה-Hybrid מדבר על שילוב של דיסק SSD מהיר (NVME) ועוד דיסקים מכניים, והסוג השני (All Flash) מדבר על כך שכל הדיסקים בקבוצה הם SSD. ההבדל הטכני בין הסוגים הוא העבודה של ה-SSD שמשמש כ-Cache. במצב Hybrid אותו SSD מהיר מבצע בעצם 2 עבודות: הוא גם משמש כ-Read Cache של התוכן שנקרא לאחרונה משאר הדיסקים המכניים וגם כ-Write Buffer שמאחסן זמנית תוכן שיעבור ברקע אל הדיסקים המכניים. במצב All Flash לעומת זאת, ה-SSD המהיר משמש רק כ-Write Buffer ואילו כל הקריאה מתבצעת משאר הדיסקים SSD באותה קבוצה.

אחד הדברים השונים ב-vSAN בהשוואה לרכישת אחסון רגיל (Scale Up) הוא שבאחסון רגיל מבקשים מאיש המכירות כמות טרהבייט שנרצה (ברוטו/נטו) וכיום יותר ויותר מבקשים שאותו אחסון יעמוד בכמות IOPS מסויימת גם בעומסים.

ב-vSAN לעומת זאת, החישובים הם שונים לחלוטין. עצם העובדה שהכנסנו נניח דיסקים בכמות כוללת, נניח, של 100 טרהבייט, לא אומר שישארו לנו נניח לאחר RAID-5 תוכנה כ-80 טרהבייט באיזה Datastore לשימושנו החופשי.

הנה דוגמא ל-vSAN על 4 שרתים שיבנה כ-RAID-5 (תוכנה) עם הפרמטרים הבאים:

  • כמות שרתים המשתתפת ב-vSAN (שרתים שמכילים דיסקים): 4
  • כמות Disks Group פר שרת: 3
  • כמות דיסקים המשמשים כ-Capacity פר קבוצת דיסקים: 5
  • כמות מקום פנוי לצרכי Slack Space (זהו מקום לאחסון Snapshots, Rebalancing ועוד): 30%
  • כמות מקום לצרכי Checksums (אם אתם רוצים לבצע דחיסה ו-Dedup – תצטרכו את זה): 5%
  • "יעילות מקום פנוי" (כלומר: Dedup) תהיה: 1.7
  • סוג וגודל הדיסקים שנשתמש: SSD בגודל 1.92 טרהבייט.
  • סה"כ כמות דיסקים SSD שנשתמש: 72, כאשר מתוכם 12 דיסקים יהיו NVME SSD (עדיף Mixed Intense/Mixed Use).

כל זה יתן לנו את הדברים הבאים:

  • אחסון "ברוטו" – 117 טרהבייט
  • אחסון "לשימוש" (לפני שנחתכים ממנו חלקים שונים): 100 טרהבייט, כך שזה מתחלק ל-:
    • אחסון Workload (כאן מתאחסן בעצם ה-Datastore שלכם): 91 טרהבייט
    • אחסון לצרכי Checksum דחיסה, dedup וכו' – 5.3 טרהבייט
    • אחסון לצרכי Replica או Parity – כ-30 טרהבייט
    • אחסון לצרכי File System – כ-1.17 טרהבייט
    • אחסון לצרכי HA ומצב Maintenance (כך כשהשרת במצב Maintenance הוא יוכל להמשיך לתת שרותי אחסון): 35 טרהבייט.

(אל תנסו לחשב סעיף+סעיף, יש פה הכללה צנועה של Dedup ביחס של 1:1.7)

הערה: למי שמעוניין, כאן יש את המחשבון שבו השתמשתי. ל-VMWare יש גם משהו, אבל הרבה יותר מורכב.

מכאן נעבור לביצועים: הביצועים עצמם תלויים בכמה דברים:

  • סוג הדיסקים שנשתמש בהם ל-Capacity. דיסק SSD SATA רגיל הוא מהיר בקריאה, אבל איטי בכתיבה רנדומלית או רציפה, במיוחד כשמדובר בהעתקה של מעט מספר ג'יגהבייטים. כמו כן, ב-SATA יש רק ערוץ אחד, הווה אומר שהדיסק יכול לקרוא או לכתוב בכל פעם, אך לא את שתיהם. בדיסק SSD NVME לעומת זאת אין את המגבלה הזו וגם מהירות הכתיבה בדיסק NVME אפילו Read Intense היא לא כזו רעה (בין כמה מאות ל-1-1.5 ג'יגהבייט בממוצע, תלוי בכמות הנתונים). ה-Disk Group שיתן את הביצועים הכי גבוהים הוא קבוצה שכולה תורכב מ-NVME SSD כ-Mixed Use/Mixed Intense.
  • רשת – אם כל הדיסקים הם SATA, אז תקשורת במהירות 10 ג'יגהבייט היא צורך בסיסי, אולם אם הכל NVME, תצטרכו רשת לפחות במהירות של 40 ג'יגהביט. חשוב לזכור: דיסקים SATA SSD יכולים להוות צוואר בקבוק.
  • זכרון – כל שרת יצטרך להיות עם לפחות 128 ג'יגהבייט זכרון וכמות ליבות נדיבה פר מעבד.
  • כמות השרתים עם דיסקים המשתתפים ב-vSAN – כמה שיותר, הביצועים עולים, אם כי לא בצורה ליניארית.

ולשאלה שאני נשאל לא מעט עליה – מי יותר מהיר, vSAN או הפתרון של Nutanix? התשובה: vSAN. הפתרון של Nutanix מבוסס על פתרון לינוקס שלא ממש יודע לנצל טוב דיסקים NVME, לפחות ממה שבדקתי.

כמו לכל דבר, יש יתרונות ויש חסרונות, גם ל-vSAN וחשוב לקחת אותם בחשבון:

  • שרות ה-iSCSI ש-vSAN נותן לא מאפשר חיבור שרתי ESXi אחרים דרך ה-iSCSI Initiator.
  • אין ל-vSAN תמיכה ב-DPM, Storage Profiles, Sparse Disks, RDM וכו'.
  • כל השרתים שיקבלו שרותים מ-vSAN צריכים להיות תחת אותו Cluster. צעד הזוי מצידם, אבל זה מה שיש.
  • המחיר די גבוה: יש ארבעה סוגי רשיונות ל-vSAN. הרשיון הכי פופולרי (Advanced) עולה בסביבות ה-4000$ (זה "על הנייר", תפעילו כישורי מו"מ!) והוא הכי מומלץ מבחינת פונקציונאליות ושרידות.
  • יש לרכוש רשיונות פר מעבדים בשרת, כלומר אם יש 10 שרתים כשבכל שרת 2 מעבדים, יש לרכוש 20 רשיונות, גם אם 4 שרתים מתוכם משתתפים במתן שרותי vSAN וכל השאר מקבלים שרותים. במילים אחרות: כל מה שמתחבר ל-vSAN, צריך רשיון פר מעבד.
  • עדיין חסרה תמיכה במסגרת Disk groups ביותר מדיסק Cache יחיד, כמו כן יש בעיות עדיין בתמיכה ל-Optane PMEM ב-vSAN עצמו.
  • כפתרון אחסון ל-VDI, המחיר מטורף (כמדומני 50$ פר VM).
  • אם אתם רוכשים דיסקים רק מיצרן השרתים – המחיר לכל הפתרון יהיה מאוד גבוה, במיוחד בדיסקים NVME (לדוגמא: דיסק 1.92 טרהבייט NVME Read Intense יעלה לכם בסביבות ה-$2500, ואילו NVME Mixed Use באותו גודל יכול להגיע למחיר של $4000). לכן, אם רוצים, אפשר ללכת על פתרון כרטיס הרחבה של HPE ל-4 כרטיסי M.2 ולרכוש 4 דיסקים NVME Mixed Use מצד ג' שנותן ביצועים טובים (הואיל ומדובר בפתרון Cache, השרידות אינה חשובה, ה-DATA נשמר ב-Capacity).

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

עדכון: תודה לגלעד בראון שציין בפניי כי ישנה חבילה שנקראת "Horizon 7 Enterprise" שכוללת את כל הרשיונות והפונקציונאליות הנחוצה ללא צורך ברשיונות vSAN נוספים והרישוי הוא לפי כמות המשתמשים (כלומר חבילות).

עדכון 2: עוד נקודה שגלעד ציין –  ה-Cluster vSAN יכול להיות או Hybrid או All Flash. לא ניתן לערבב.

הבעיות של מחשבי Thinkpad ו-Thunderbolt

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

יחד עם זאת, לפחות בשנה האחרונה, יש יותר ויותר תלונות של משתמשים על תקלות במחשבים הניידים הכוללים חיבורי Thunderbolt כ-USB-C, החל מבעיות של אי-טעינת המחשב, HDMI דרך Docking לא פעיל, ה-Thunderbolt לא מופיע ב-Device Manager ועוד שורה של תלונות.

הדבר הראשון שצריך להבין לגבי כל חיבורי ה-USB-C שיש באותם מחשבים, זה שהחיבורים, למרות שהם נראים מבחוץ זהים, הם שונים. יש חיבורי USB-C שהם בעצם Thunderbolt והם מסומנים באמצעות סימלון "ברק" ליד החיבור וחיבורים אלו מקושרים ישירות לשבבי Thunderbolt מסוג Alpine Ridge ו-Titan Ridge של אינטל, ואילו חיבורים אחרים הם חיבורי USB-C שמחוברים ישירות אל ה-Chipset שקשור למעבד במחשב ואין לו שום קשר ל-Thunderbolt. חיבורי USB-C רגילים יכולים לכלול החל מדברים מאוד בסיסיים כמו USB 2.0, הובלת חשמל (עד 100W), וחיבוריות ציוד מגוון מאוד. לעומת זאת, ה-Thunderbolt לוקח את מה שנתמך בסטנדרט USB-C רגיל ומוסיף לו שורת מצבים של Alternative Modes דרך ממשק PCIe תוך שימוש בשבבים שונים (ויקרים)שנמצאים בתוך המחבר (בדרך כלל הדבר יצוין עם סימלון ברק על המחבר).

לכן, בשלב הראשון יש צורך לבדוק מאיזו כניסה יש בעיה. לדוגמא – במחשבים כמו T480s ישנם שני חיבורים שנראים זהים, האחד עבור ה-Dock והאחד לחשמל. רק החיבור ל-Dock הוא חיבור Thunderbolt והשני הוא חיבור USB-C שמגיע מה-Chipset. (את החשמל, אגב, ניתן לחבר לכל אחד מהחיבורים, זה לא משנה, שניהם תומכים ב-Power Delivery).

לנובו טוענת שהבעיות שהוזכרו נבעו מקושחה (SPI-ROM) גרועה שהופצה ב-2018 עד אמצע 2019 וכי עדכוני קושחה שיצאו החל מאוגוסט 2019 (יצאו מאז לפחות 2 עדכונים קטנים נוספים) תיקנו את הבעיות הנ"ל, ולכן אם אחת מהבעיות שצוינו בקישור עדיין מופיעה לך, אתה צריך לפתוח קריאת שרות להחליף לוח אם ולהתקין את העדכונים האחרונים (כולל קושחה ודרייברים) ל-Thunderbolt. החלפה של לוח לא מתקנת את הבאג אבל כן כוללת בקר Thunderbolt שצריך את העדכון.

יחד עם זאת, ישנן עדיין בעיות שלא קשורות ל-Thunderbolt או ל-Dock וכן קשורות למערכת ההפעלה שאתה משתמש (במיוחד ב-Windows 10) הקשורות ל-Sleep. נניח שאתה לוקח את המחשב הנייד שלך לסבב ישיבות בחברה ואתה חוזר למשרדך, מחבר ל-Dock, לוחץ להפעלה לצאת ממצב שינה והופס – המחשב מתחיל תהליך Cold Boot, ותקווה שהמסמך שעבדת עליו – נשמר בהצלחה לפני שהמחשב החליט לעשות את השטות הזו. אישית, דיווחתי בעבר ללנובו על הבאג הזה פעמיים וקיבלתי תשובות שטותיות (כמו להסיר את התקנת האודיו של Realtek. ה"התקן" בסך הכל עושה Mixing, הוא לא מפעיל שבב נוסף כי אין שום שבב של Realtek במחשב הנ"ל). הבאג, אגב, אינו מתרחש עם מערכות הפעלה אחרות (אני עובד ברוב הזמן עם Fedora 31 על ה-Thinkpad שלי) כך שמדובר במשהו ספציפי ל-Windows שלנובו צריכים לתקן.

לסיכום: חלק מהבעיות אכן קשורות ל-Thunderbolt אך חלק מהבעיות קשורות ל-OS ודרייברים גרועים והגדרות שגויות של לנובו ללא קשר ל-Thunderbolt ב-Windows ובעיות כאלו קיימות גם במחשבים ניידים מתוצרת חברות אחרות (Dell, HP, ASUS, MSI ואחרים). הדור הבא של מחשבים ניידים מתוצרת כל החברות יכללו בחלקם את המעבדים החדשים של אינטל, הדור העשירי, שכוללים Thunderbolt בתוך המעבד, כך שיהיו דגמים רבים שכל חיבורי ה-USB-C שלהם יהיו חיבורי Thunderbolt עם תמיכה מלאה ובתקווה לכמות באגים אפסית.

דעה: כמה מילים על אחוזים

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

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

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

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

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

אני משער שכאן הקורא היקר יאמר "חץ, אתה מקבל עבודה, פרויקט!" ואותו קורא יקר יהיה צודק, רק שהבעיה היא שכמו לכל עצמאי או שכיר, כבר יש לי "שותפים טבעיים" שגוזרים להנאתם כמעט מחצית (תלוי בכל מיני פרמטרים) מההכנסות, ולפני שאני הולך להוסיף "שותף טבעי" חדש, אני רוצה לדעת מה אני מקבל ממנו, חוץ מהפרויקט. אחד הפרמטרים החשובים לי לדוגמא, הוא עניין תשלום: מקדמה ו/או תשלום נניח "שוטף" מאותו מפנה ללא קשר מתי החברה המבקשת את הפרויקט משלמת בפועל לעצמאי/חברה שהפנתה אותי, ולכן הצעות שבהם אני שומע את המילים "Back to Back" (למי שלא מכיר: אתה מקבל כסף רק אחרי שמבקשת העבודה משלמת בפועל) זו בשבילי עיסקה גרועה: אני הולך לשלם פר שעה רק בגלל הפניה חד פעמית שמישהו הפנה אותי, מבלי שהוא יקח שום סיכון לגבי איחור בקבלת כספים. No deal.

עכשיו אעבור לשכירים שעובדים דרך חברות "גולגלות", "כח אדם" וכו'. אותם שכירים יקרים מקבלים משכורת מאותן חברות כח-אדם/גולגלות בכל חודש, ללא קשר מתי הלקוח שהם עובדים אצלו – משלם לאותן חברות (במקרים רבים התשלום יגיע לאותן חברות בתנאים של שוטף+60,90,120 ויש גם כאלו שמשלמים שוטף+180), כלומר אותן חברות המעסיקות את השכירים ישירות סופגות את הסיכון לגבי תשלום מאוחר או אי תשלום. הדבר שאולי כדאי ששכיר ידע – מה המחיר שאותה חברה שהוא מגיע אליה יום יום, משלמת על שרותיו לאותה חברת כח-אדם ומה בעצם הוא לא מקבל. אם, לשם הדוגמא, כשכיר, אתה מקבל 80 שקלים לשעה (החישוב הגס הוא: חלוקת משכורת הברוטו שלך ב-200 שעות לחודש) ואתה מצליח להבין שהחברה שאתה נמצא משלמת עליך כ-160 שקלים לשעה, אז אתה בעצם מפסיד 50% (ברוטו, ברוטו, אנחנו בישראל) משכורת. איך ההרגשה לא לקבל עוד 50% (ברוטו) כל חודש?

לכן, לשכירים, אני ממליץ מספר דברים:

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

ולעצמאים:

  1. חישוב צריך להתבצע לפי מחיר פר-שעה, בניכוי כל המיסים (ביטוח לאומי, מס הכנסה, מע"מ, עכשיו הוסיפו גם צורך לשלם פנסיה בתנאים סופר גרועים).כמה העצמאי או החברה המפנה גוזרים, ומה הסכום שאתה מקבל בפועל. אם הם גוזרים סכום סביר (נניח 10%, אולי יותר, תלוי מה אתה מחשיב "סביר") ומדובר על עבודה ארוכה או עבודה שדורשת כמות שעות כל חודש, אז עבודה כזו יכולה להיות הכנסה מעולה לכסות מספר הוצאות שחוזרות כל חודש (שכר דירה/משכנתא, מיסי רשויות), וכדאי לסגור דיל. מצב נוסף שכדאי לקחת בחשבון – חברה מפורסמת עם פוטנציאל לעבודות עתידיות שם.
  2. … אבל מצד שני, אם אחרי כל הקיזוזים שהם חובה ("שותפים טבעיים") ובקיזוז מה שהמפנה גוזר מביא אותך לרף התחתון של המחירון שלך ומטה, או שהוא אומר את המילים "Back to Back", אני ממליץ לך לשקול היטב אם בכלל לקחת את העבודה הזו.

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

בקרוב: Azure בישראל – עם קצת יותר פרטים

מיקרוסופט הכריזה היום על כך שהם מקימים בארץ … Data Center, אם להאמין למאמרים שהתפרסמו ב-Geek Time. ב-The Marker כתבו נכונה שמיקרוסופט הולכים להקים בעצם Region, אבל גם הם נפלו בהסברה וכתבו "..חוות שרתים מקומית שתשמש את תשתית הענן שלה". אני יכול להמשיך, אבל אני חושב שהפואנטה ברורה…

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

אז כן, מיקרוסופט אכן מקימה Region. מה קרה שמיקרוסופט מכריזה עכשיו ולא לוקחת את הזמן ומודיעה בעתיד? חכו עוד קצת ותראו….

ה-Region שיוקם בישראל אינו מורכב מחוות שרתים אחת. ולמיטב ידיעתי, מיקרוסופט לא הולכת לזרוק כמה מאות/אלפי שרתים אצל בזק או סלקום ולהכריז "Region חדש!". בעסה לכל מיני ספקים בארץ, אז לא..

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

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

מכאן נעבור לחלק שמיקרוסופט לא תסכים לעולם לאשר או להכחיש (והאמת – לא דיברתי איתם על כך ישירות). מיקרוסופט יהיו בין הספקים הראשונים שיכניסו כאן את הדורות החדשים מבחינת תשתית מבוססת OCP מהדור האחרון, שימוש במעבדים של AMD EPYC (בדגמים שאי אפשר לרכוש, כמו 7H12), שימוש ב-CXL, טכנולוגיות מיתוג חדש בין ציוד למעבדים ועוד ועוד – בקיצור, אם השמועות שקיבלתי נכונות, הטכנולוגיה שתנחת כאן בארץ תהיה מה"מילה האחרונה".

בכל הקשור Azure 365 (כלומר Azure עם אינטרגציה ל-Office 365) – זה יגיע אחר כך. מתי? שאלה טובה.

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

ועוד נקודה קטנה: זוכרים ש-Med1 הכריזו שיש להם Azure ושפרסמתי שזה לא ממש Azure ושזה בסך הכל Azure Stack שממש לא שווה לרכוש כספית? אז בקרוב יהיה פה ה-"Real Deal" וספקי ההוסטינג/VPS/COLO המקומיים מוזמנים להתחיל להיכנס לפאניקה. נשארה עוד שנה-שנה וחצי.

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

VMWare על AWS – האם שווה להשכיר?

(אני רוצה להתחיל בהערה קטנה. אחרי שכתבתי את הפוסט על PKS קיבלתי מאנשים הערות שאני "אנטי VMware". אני לא. למען האמת, אני בשלבים של מעבר כל המכונות שלי ל-vSphere 6.7 ואני חושב שפתרון הוירטואליזציה של VMWare הוא מהטובים בשוק. יחד עם זאת, יש לי השגות לגבי חלק ממוצרי החברה ואת אותן השגות אני משתף, לא יותר מזה). נקודה נוספת: בעבר כתבתי על VMWare on AWS אבל הכל היה מבוסס על שמועות. הפעם ביקשתי מחבר שבעבודתו משתמשים במוצר להקדיש לי שעתיים ולהראות לי את התכונות ובדקתי גם את ההדגמות והקליפים הרשמיים טרם כתיבת פוסט זה.

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

לתוך הנישה הזו VMWare מוציאה "מוצר חדש" שנקרא VMWare on AWS ופתרון זה יוצר מעין "המשכיות בענן", אתה יכול להשתמש ב-SDDC Manager לנהל את הפתרון של VMware בענן יחד עם הפתרון שרץ אצלך מקומית (On Prem). אתה לא צריך לשנות מכונות וירטואליות לעבר הפתרון שלהם שרץ בענן של ה-סע"צ שבחרת, אתה פשוט מבצע Migrate של אותן מכונות וירטואליות לאותו DC מרוחק, ל-Cluster המרוחק ול-Datastore המרוחק, בוחר את הסוויצ', מאשר, וזהו – המכונות הוירטואליות בדרך לענן הציבורי. נשמע קל ופשוט, בלי הרבה כאבי ראש.. לא?

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

  • הפתרון VMWare on AWS הוא בעצם פתרון vSAN המוכר. אתם לא משלמים פר VM, אתם משלמים פר שרת פיזי ויש צורך במינימום 3 שרתים.
  • התמחור יכול להיות דינמי (פר שעה) או פר שנה או פר 3 שנים והמחיר עצמו טיפ טיפה גבוה .. אם לדוגמא אתם רוצים להקים זאת בארה"ב, בוירג'יניה, שם המחיר יהיה הכי "זול". כמה? ובכן, על 3 מכונות בסיס (נקראת i3) תשלמו 155,961 דולר לשנה. רוצים להריץ את זה בפרנקפורט, גרמניה? המחיר מטפס ל-185,952 דולר לשנה. המחיר כולל את הרשיונות ל-vSphere ו-vSAN אך אינו כולל VMWare Site recovery, ובשביל לכלול זאת יש לשלם $22,600 פלוס 347$ פר VM.
  • ישנן שתי סוגי מכונות: i3 metal, r5 metal. ה-i3 כוללת דיסקים NVME מקומיים (אחסון כולל Cache בסביבות ה-16 טרה), ואילו מכונת ה-i5 משתמשת באחסון של AWS (ה-EBS) כ-"דיסקים מקומיים", אחסון EBS אינו נכלל בסכומים שציינתי לעיל והתשלום הוא חודשי. פונקציה נוספת – Elastic vSAN (מאפשר להשתמש באחסון שבשרת גם אם אותו שרת הוא במצב תחזוקה) עולה $2.28 לשעה פר מכונה. אלו מחירים ל-3 שרתים בשרת ה"נמוך" (18 ליבות, i3-metal). אם אתם רוצים להשתמש באחסון של אמזון (EBS) ולקחת שרתים יותר רציניים (r5 metal, עם 48 ליבות) אז בוירג'יניה תצטרכו לשלם 174,411 דולר לשנה, ובפרנקפורט המחיר מטפס ל-210,396 דולר לשנה.
  • רוצים הנחות על המחיר? בשמחה, רק אם אתם משלמים מראש. אם אתם שוכרים את הברזלים ל-3 שנים מראש, יש לכם 50% הנחה. אם לשנה – 30% הנחה (לפי המסמך הזה).

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

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

אם נרכוש שלושה שרתים, בכל אחד מהם מעבד אחד AMD EPYC עם 32 ליבות (כך נחסוך במחצית את העלויות של vSphere ו-vSAN וכל מוצר אחר שמחושב Per Socket), עם חצי טרהבייט זכרון, עם 6 דיסקים NVME SSD ו-2 דיסקים NVME SSD Mixed Intense, עם כרטיס רשת של 10 ג'יגהביט, כל הרשיונות (ל-3 שנים) שצריך ולקינוח גם סוויצ' נחמד. צריכים את המערכת בגרמניה, או ארה"ב או אפילו מחוץ למשרדכם פה בארץ? חפשו ספק שמוכר שרותי COLO (כלומר Co Location) לאחסן 4U או 7U (שזה 3 שרתים, תלוי בגודלם הפיזי – פלוס סוויצ') עם רוחב פס נאה, ואתם תשלמו לו בערך 2000-4000$ לחודש.

ניקח את כל הערימה הזו ונחשב אותה – ותראו שלא תגיעו ל-$160,000 שתצטרכו לשלם בממוצע לשנה על VMWare on AWS, ובנוסף – הציוד והרשיונות הם שלכם, וזה כולל SLA לברזלים ולציוד עצמו.

אחד הדברים שחשוב להבין לגבי VMWare on AWS היא למרות שהשיווק יזכיר בכל שניה וחצי את המילה "ענן" – חוץ מהעובדה שזה יושב ב-DC של ספק ענן ציבורי, אין לפתרון הנ"ל כמעט כלום עם מה ש-סע"צ בעצם מייצג. (ה"כמעט" קשור למכונה r5 metal שמשתמשת באחסון של ספק הענן אבל זה בעצם לא ממש משנה כלום. EBS מאפשר גדילה דינמית, אבל vSAN לא יודע "לאכול" דיסק "פיזי" שגודלו השתנה). כל השירותי ענן שתשתמש בהם מתוך ה-VMware on AWS יהיו בדיוק כמו שתיקח את השרותים מבחוץ או ממכונות וירטואליות שה-סע"צ משכיר מהשרותים שלו.

הבה נסתכל על ההצעות של ה-סע"צ. רבים נוטים להתעצל ולבחור נניח מהעשיריה הראשונה של ההצעות ל-VM כדי לא להסתבך, אבל המציאות היא שכל סע"צ מציע מספר "דורות" של מכונות וירטואליות, חלק לא קטן מההצעות די זולות ויכולות להתאים למשימות שונות (הנה לדוגמא ההצעות של AWS. מיקרוסופט, לפחות ממה שבדקתי, לא מציעה טבלה כזו אז חברת Nakivo מציעה טבלה כזו עם הסברים, ובגוגל יש דף פשוט שמסביר את הסוגים. אז אם לדוגמא אתם צריכים להריץ אפליקציה שדורשת המון זכרון אך כמעט ולא עושה כלום עם המעבד, אתם יכולים לשכור Instance מדור ישן יותר ובכך לחסוך. צריכים מכונות VM שאליהן מחוברים דיסקים SSD פיזיים לוקאלית? יש. ב-VMWare on AWS אין חיה כזו – יש סוג אחד של מעבד (ישן, מלפני שלוש דורות – Xeon V4) ואין לך אפשרות לחבר SSD פיזי לוקאלית ל-VM (על VMware on AWS – כי זה מנוהל על ידי VMware).

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

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

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

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

השוואה: PKS מול OpenShift

יצא לי לשוחח עם לא מעט חברות שרוצות להשתמש בקונטיינרים. רבים כבר התחילו ממזמן להשתמש ב-Docker (הערה: לא הגיע הזמן להכיר ולהשתמש ב-cri-o?) והם החלו להשתמש ב-Docker-compose להרמת מספר קונטיינרים במכה אחת. חלקם מתחילים להשתמש בשרותים המנוהלים לקונטיינרים בעננים הציבוריים וחלקם רוצים פתרון On Prem ומטבע הדברים הם מתחילים לקרוא על Kubernetes וכשהם מתחילים להבין כמה הוא מורכב לתפעול (ומגירסה לגירסה זה נהיה יותר ויותר מורכב) – הם מבקשים המלצות על פתרון קל יותר להקים ולנהל אשכול Kubernetes (ובקיצור בשמו החביב: K8S).

רוב מוחלט של החברות הבינוניות והגדולות משתמשות ב-VMWare (מי שמשתמש ב-Hyper-V וירצה פתרון קל להתקנה וניהול ל-K8S – בהצלחה עם זה) ומטבע הדברים הם מעדיפים משהו מחברה גדולה וידועה כמו VMWare, ששמחה מאוד למכור להם את PKS. המוצר עצמו נמכר בשתי תמחורים שונים – פר POD (כאשר POD הוא מעין "קבוצה" כאשר כל POD מכיל קונטיינר אחד או יותר, ברוב המקרים יריצו קונטיינר עם אפליקציה ועוד קונטיינרים שמכילים אפליקציות נסמכות תחת POD אחד ואז יש גם תקשורת בין הקונטיינרים בקבוצה) או פר ליבות. זה מתחיל ב-50 PODS או ליבות. (המלצה: לא לרכוש פר POD. בכל ליבה אפשר להריץ עשרות PODs).

המתחרה העיקרי והיותר גדול ומיועד ל-Enterprise להרצת Kubernetes היא מערכת Openshift. גם היא תומכת באופן טבעי ומלא ב-VMWare (כן, כולל תמיכה ב-NSX-T), רק שבניגוד ל-PKS, היא לא מיועדת רק להקמה וניהול של Kubernetes במובן הסיסטמטי, אלא היא יותר מיועד לכל השרשרת – מרמת ההנהלה, אנשי אבטחת מידע, ומפתחים. ב-PKS אם אני רוצה להקים אפליקציה, אני צריך להשתמש ב-Cloud Foundry (או דרך ה-cli ב-kubectl), צריך במקרים רבים לכתוב קבצי YAML (ימח שמו וזכרו עם כל הקטע של רווחים!) שמצריכים ידע מספק ב-K8S. עם Openshift – יש לך Template (שתמיד אפשר לכתוב נוספים) והמתכנת עושה הכל דרך ה-Web UI. יש קטלוג מובנה שמאפשר להתחבר לאינטרנט ולהוריד אוטומטית templates נוספים והקמה של אפליקציות נוספות בכמה קליקים, יש אבטחת מידע הרבה יותר רצינית מ-PKS (בגלל זה רוב הקונטיינרים הזמינים לציבור לא ירוצו על Openshift אלא אם משנים הגדרת אבטחה שבחברה עלולים לפטר אותך אם תשנה אותה), יש גרפים וניטור מובנה, קל מאוד לשייך בין אפליקציה לשרות (נניח אפליקציית JAVA לקונטיינר אחר שמריץ MySQL – משתמשים ב-BIND בתפריט ותוך שניות ספורות המערכת תבנה את הכל) ויש עוד תוספות רבות שכלל לא קיימות ב-PKS. בקיצור, מי שיקים מערכת Openshift (קראו בהמשך על כך למי שמעוניין להתנסות אישית במחיר יקר של 0 שקלים) ויקים מערכת PKS, יראה את ההבדלים מהר מאוד. אגב, אחת האפשרויות שכיום אין ב-PKS ומאוד חשובה כשרוצים להוסיף ולהוריד מכונות וירטואליות המריצות קונטיינרים – כלל לא קיימת ב-PKS, אך קיימת בגירסת Openshift האחרונה.

וכאן אני מגיע להמלצה לא פופולרית שאני ממליץ: אל תרכשו PKS.

לא, זה לא קשור למחיר. מי שישווה בין Openshift ל-PKS יראה כי המחיר של Openshift ל-On Premise יותר יקר מ-PKS (בחלק מהמקרים, תלוי בחישובי ליבות, כמויות וכו')

הבעיה קשורה יותר ל-VMWare ולזמן הנוכחי. VMWare מציעה את PKS (גרסאות Essential, Enterprise) אבל אותה חברה גם מציעה את Tanzu Kubernetes Grid. היא מדברת על ניהול אשכולות של Kubernetes עם Tanzu Mission Control – אל תחפשו לרכוש או להוריד, זה מוצר של חברת Heptio (ש-VMWare רכשה) שעושים בו שינויים והוא כרגע בבטא ללקוחות VMware ולא זמין להורדה. יש גם את עניין ה-Health אשכול ה-K8S שלך והחלק הזה ממוצר וקוד מחברות ש-VMWare רכשה: Wavefront ו-CloudHealth.

בקיצור, VMWare מכינה איזה משהו גדול שמשולב מקוד ממקורות שונים שאמור לתת לך מענה מבחינת הקמת וניהול אשכולות K8S שונים הן מקומית והן בענן, אבל עד שזה יהיה מוכן ויציב – יקח זמן. כ-Enterprise, היציבות מאוד חשובה והדבר האחרון שאתם רוצים לעשות זה לעבור למשהו אחר השנה או שנה הבאה ולך תדע כמה זה תואם אחורה והאם המיגרציה תעבוד חלק…

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

לאלו שכן רוצים לנסות את Openshift על הדסקטופ שלהם (לא על ESXI או פתרון וירטואליזציה מרכזי, כל עוד יש לך 32 ג'יגהבייט זכרון, הגירסה המצומצמת שניתנת להורדה תופסת 16 ג'יגהבייט זכרון, לגמרי), מוזמנים לגלוש לקישור הבא. תצטרכו להירשם ל-רד-האט כדי להוריד "קוד סודי" ולהדביק אותו בזמן ההתקנה. האפליקציה נקראת Code Ready Containers והיא יכולה לרוץ על לינוקס, מק ו-Windows. המערכת משתמשת בוירטואליזציה במחשב המקומי כך שב-Windows היא תפעיל את אופציית Hyper-V. טיפ קטן: אם אתם מחוברים ל-Active Directory, תתחברו למכונה שלכם עם שם משתמש מקומי. באג ידוע.

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

אחסון: Scale Up מול Scale out (מאמר עדכון)

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

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

נתחיל בפתרון הפופולרי שיותר ויותר רוצים: פתרון Scale Out ובמקרה של VMWare מדובר כמובן ב-vSAN (עם Nutanix, Simplivity, Hyperflex הדברים מעט שונים). הדבר הראשון שצריך לקחת בחשבון זה עלות שדרוג רשיון ל-vSAN. בכל שרת שיש בו שני מעבדים, צריך לשלם כמדומני $5000 וזה רק על הרשיון, כלומר אם יש נניח 10 שרתים, אנחנו מדברים על $50K לפני שבכלל דיברנו על חומרה. אחרי שדיברנו על רשיונות, נדבר על דיסקים וסוג האחסון: Hybrid או All Flash, רובם כשהם מקבלים הצעות ל-All Flash ב-vSAN נרתעים מהמחיר אז נעבור ל-Hybrid. הדיסקים מקובצים כ-Disk Group. מבחינה טכנית, כל Disk Group יכול להכיל עד 7 דיסקים מכניים ודיסק SSD, המכניים הם ה-Capacity וה-SSD נקרא Cache. חישוב הדיסקים צריך להיות לפי רמת ה-RAID שאתם בוחרים, לפי כמות ה-Fault Domains, ה-Erasure Coding ועוד. לא מומלץ לנסות לחשב לפי Dedup מכיוון שיחס ה-Dedup הוא משתנה נעלם שמשתנה בהתאם לתוכן המאוחסן, כמות פעמים שאותם בלוקים מאוחסנים ועוד, למעוניינים – ניתן לקרוא יותר פרטים על כך כאן וכאן. נקודה חשובה לציון: VMWare גם נוטים להמליץ על דברים שייקרו את המערכת, כמו בקר RAID לכל קבוצת דיסקים (כי זה עוזר ב-Rebuild), תלוי במצב הקונפיגורציה שלכם, לא חייבים להקשיב ולרכוש. מה שכן, ותלוי בתקציב, מומלץ לרכוש SSD Mixed Intense ל-Cache (היחס קריאה כתיבה לדיסקים SSD שהם Read Intense הוא 80/20 או 75/25, ו-VMWare מבקשת 70/30 – לשיקולכם).

מכאן נעזוב את פתרונות ה-HCI ונעבור לאחסון כללי.

אין שום בעיה לאחסן 2-3 פטהבייט באחסון Scale Up. הנה לדוגמא JBOD של Western Digital שיכול לקבל עד 102 דיסקים מכניים של 12 טרהבייט ולתת כמות אחסון ברוטו של 1.2 פטהבייט. אפשר לשרשר קופסא כזו לעוד שלושה קופסאות נוספות כך שתיאורתית ניתן לאחסן ברוטו 3.6 פטהבייט. את הקופסאות האלו ניתן לחבר לשרת שמריץ את תוכנת האחסון (למען האמת, ניתן לחבר את זה כמעט לכל סטורג' חדש כיום, רק שיצרן הסטורג' לא יתמוך בכך מבחינת תמיכה ואחריות, אם כי יכול להיות שגם הוא מוכר משהו דומה) ואם רוצים – אפשר לחבר שתי קופסאות סטורג' ("ראשים") בתצורת High Availability ולקבל פתרון אחסון מעולה…

.. עד שמגיעים לבעיה המרכזית באחסוני Scale Up כאלו: אם בקר ה-SAS באחת מקופסאות ה-JBOD יתקלקל, פתרון האחסון יושבת (וכמובן השרתים המקושרים לו) ואנחנו מדברים על השבתה של מינימום 4 שעות במקרה הטוב, יום עסקים במקרה הפחות טוב, וכמה ימים במקרה הרע (מה לעשות, לא לכל יבואן יש כמה כאלו שהוא שומר בסטוק למקרה חרום, וכבר ראיתי מקרה כזה).

לכן חשוב להבין, מבחינת Scale Up, תיאורתית אפשר לאחסן בו המון, אך ככל שמכניסים יותר ויותר חלקים לפתרון (עוד בקרי RAID, עוד קופסאות JBOD וכו') הסיכוי להשבתה הוא יותר גדול, הזמן לבצע Rebuild לדיסק עם מספר דו ספרתי של טרהבייט – גודל בצורה משמעותית, ולכן מעשית – זה לא מומלץ

ב-Scale Out לעומת זאת, אפשר לשלב מספר קופסאות כמו הנ"ל בכך שנצוות קופסא מול שרת, מינימום שלושה שרתים (הכמות עולה במספר אי זוגי – 3,5,7 וכו' וכו') ואז גם אם יתקלקל JBOD, יתקלקל שרת אחסון Scale Out או שניהם ביחד – המערכת תמשיך לתת שרות. החסרון כמובן קשור לעלויות – צריך יותר שרתים יעודיים, צריך Backbone של 40 ג'יגהביט לפחות, סביר להניח שנצטרך שרת עם דיסקים SSD לצרכי Cache וכו', ולכן פתרונות כאלו מתאימים לפרויקטים גדולים כמו HPC, או Big Data ועוד, וכאן שימוש בפתרונות Scale Up לא יתן פתרון אחסון מהיר ויעיל. אותו דבר לגבי כמות אחסון – אם כל מה שאתה צריך לאחסן זה כמה עשרות או מאות בודדים (100-200) של טרהבייט, לך על Scale Up.

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

אבטחת מידע: קצת על Cloud Hopper

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

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

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

אחד הדברים המייחדים את הסינים בכל הקשור לריגול, גניבות, פריצות וכו' – זה הסדר שהם עובדים. אין "קפריזות". יש צוותים (שמוזכרים בקצרה בפוסט של Fox Business) וכל צוות אחראי על משהו אחר: צוות שאחראי על בדיקת הפריצות, על שמות משתמשים וסיסמאות שלא שונו, צוות שאחראי על מיפוי חוזר ונשנה של תשתיות החברות הנפרצות, צוות (גדול) שאחראי על התמודדויות מול אנטי-וירוסים, IPS/IDS, צוות שאחראי על כתיבת סקריפטים וכלים שונים כמו C&C, צוות שבודק פריצות חדשות שלא ידועות ציבורית, צוות שאחראי על קבלת Payload, רישומי דומיינים – ויש בוודאי עוד כמה צוותים.

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

פרויקט Cloud Hopper הוא פרויקט של הפורצים שמימן המשרד לבטחון הפנים הסיני. הקבוצה העיקרית שהיתה אחראית על הפרויקט נקראת APT10 וזו קבוצה סופר מתוחכמת שלא רק מכירה למי הם פורצים, הם בדרך כלל מכירים גם את רמת הידע של חברות שמנסות להגן על הלקוחות נגד פריצות וה-APT10 לא ממש ביישנים: הם יודעים מי מנסה "לצוד" אותם והם משאירים strings בכלים המותקנים על המכונות הפרוצות עם כל מיני הקנטות, כולל רמזים ללמוד איך עובד אנטי וירוס והמעקפים בכך שהם הפנו את ה-C&C לדומיין: gostudyantivirus.com ועוד (הטריק הזה אקסלוסיבי לא רק לסינים כמובן, גם החבר'ה ב-8200 ואחרים משתמשים בו)

קבוצת APT10 במסגרת Cloud Hopper החליטה למצוא לה אי שם ב-2014 מטרה חדשה: ספקי Cloud (או CSP כפי שזה מוכר יותר בשוק), לחדור אל תשתיות ה-CSP, להשיג הרשאות לתשתיות הוירטואליות של הלקוחות ופשוט להיכנס, לגנוב מידע, ולקפוץ (Hopping) מלקוח ללקוח באותה תשתית, כאשר לא מדובר בגניבה חד פעמית אלא מתמשכת.

ומי היו ה-CSP? אולי שמעתם את השמות, הכי מפורסמים הם HPE ו-IBM והיו עוד כמה עשרות CSP יותר קטנים. מי הלקוחות שנפרצו? גם כאן, אולי שמעתם עליהם: חברת Ericsson (כן, חברת התקשורת), פיליפס, חברת TATA ההודית, פוג'יטסו, ועוד רבים אחרים. המצב ב-HPE היה כל כך גרוע, שהפורצים פשוט "דרסו" כל נסיון חסימה מצד מנהלי אבטחת המידע של HPE והם נכנסו שוב ושוב לתשתית. אגב, ללקוחות ה-CSP לא הודיעו מאומה מחשש לתביעות (ואולי מחשש שהלקוח ינסה תוך שעות ספורות לעבור מיידית לספק אחר).

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

על ה-Cloud Hopper תוכלו לקרוא באתרים שונים, אבל אם יש משהו אחד שלא תמצאו שם – זה פריצה לשלושת האמיגוס. אין ספק שתוכלו למצוא מאמרים על פריצות לכל מיני מאגרים שהיו שמורים בתוך S3 Buckets שטיפשים לא הגדירו להם אבטחה מספקת, לתשתיות וירטואליות של לקוחות שהגדרות האבטחה בהן היו בדיחה – אבל לא תמצאו מאמרים על פריצות לתשתיות הפיזיות של AWS, GCP או Azure או לחלקים המאפשרים כניסה לתשתיות וירטואליות של לקוחות, מכיוון שאותה שלישיה בונה את הדברים בצורה שונה לחלוטין, משקיעה הרבה יותר מכל CSP שהחליט שזה אחלה רעיון לקרוא לעצמו "ענן", כולל השקעה בצוותים שאשכרה מנסים לפרוץ בכל דרך מבחוץ פנימה נון סטופ ומיישמים מיידית את הלקחים, במקום לסמוך על כל מיני חומות אש, IPS/IDS ו-MFA (להלן החדשות: רוב שיטות ה-MFA כבר נפרצו עוד לפני שנתיים!).

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

  • Firewall, IPS/IDS, Antivirus, Malware protection, עדכוני אבטחה – כל הדברים הללו נחמדים, אבל פורצים מקצועיים יודעים לעקוף את אותם כלים. אף אחד לא ינסה להיכנס ל-Firewall שלך ולשנות פורטים כי אין צורך בכך, וכל כלי שפורצים כותבים עובר בדיקה מול כל אנטיוירוס מסחרי אם הכלי מתגלה או לא (ואם כן אז משנים את הקוד), ולגבי IPS/IDS – ארמוז בעדינות שיש מספר דרכים לנצל חולשות שלו בתוך ה-LAN, ומדובר על רוב המוצרים המסחריים המצויים בשוק. לא קשה כל כך לזייף ב-Stream פיסות Headers.
  • כמו שמחליפים גירסת לינוקס או Windows, כדאי אחת לתקופה להחליף חלקים גדולים ממערך האבטחה – כלים, מתודות וכו'. תתחילו בשני דברים פשוטים: Zero Trust (זה מה שהשלישיה משתמשים), ו-U2F.
  • אתם מרימים תשתית וירטואלית בענן מקומי? (גם אם זה DR) – אל תתנו לאף אחד גישה ועדיף שזה יהיה על ברזלים ותשתית נפרדת שלכם, ואם צריך קו יעודי לכך שלא מחובר לתשתית של הספק בתוך ה-DC. לחשוב ש-VLAN מגן על משהו – זו בדיחה במקרה הטוב, לא מסובך לפורץ מקצועי להיכנס למתג. רק קחו בחשבון שספקים מקומיים ינתקו לכם את התקשורת אם אתם מותקפים ב-DDoS.
  • אם אתם מקימים תשתית וירטואלית אצל אחד משלישיית האמיגוס, תשתמשו בכלי אבטחה שלהם ולא בכלים צד ג'. הכלים של אותם ספקי ענן ציבורי הרבה יותר רציניים, מעודכנים תדיר (לא רק כשמגלים חור אבטחה וסוגרים אותו כמה ימים אחרי זה כמו אצל רוב הכלים המסחריים!), יכולים לבצע Scaling רציני ומנוסים שוב ושוב על ידי מאות אלפי לקוחות. להגדיר Security Groups ולחשוב שאתם מאובטחים – אתם ממש לא.
  • "התקמצנות" במפתחות פרטים/ציבוריים. רוצים לבצע Passwordless SSH? תשאירו את זה בצורה סופר מצומצמת לצרכי אוטומציה. בשאר המקרים – תקנו Yubikey ותשתמשו בו או מפתח Titan מ-גוגל. אפשר גם 2FA אבל תיזהרו לא ליפול לטריקים כאלו. זיכרו: העצלנות היא הגורם מספר אחד לפריצות קלות.
  • בעננים ציבוריים במיוחד – אף ספק ענן ציבורי לא נותן לך אבטחה כברירת מחדל ולכן תצטרך להשתמש בשרותים שלהם לצרכים אלו, ב-AWS יש רשימה שלמה, תעברו עליה, תבחרו ותגדירו את מה שאתם צריכים (הנה גם ל-Azure, אל תאכלו לי את הראש)
  • אני ממליץ לחשוב מחדש (לכיוון ויתור) על שירותי ניהול מרוחקים. אתם יכולים להגן על התשתית שלכם כמה שתרצו אבל אם עובד משרותי הניהול הוא סופר אהבל ופורצים למחשב הנייד/נייח שלו – ההגנות שלכם לא שוות כלום ומכיוון שיש לו הרשאות admin ברוב המקרים (כי הם מנהלים את התשתית) – יהיו לפורץ את אותן ההרשאות.
  • בדיקות Pen testing זה נחמד, אבל זה עובד מול שורת פריצות ופרמטרים ידועים מראש בתוך הכלי. רוצים להיות יותר בטוחים שאתם מוגנים? תשכרו מישהו שאשכרה ינסה לפרוץ בצורות קצת יותר .. מקוריות.

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