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

על דיסקים SSD – אחריות, ביצועים, יד שניה ועוד

לקראת השנה האזרחית החדשה החלטתי לכתוב פוסט חדש המבוסס על דוח"ות שכתבתי עבור לקוחות שונים והחלטתי לקחת חלקים מהם (ברשות) ולאחד אותם לפוסט אחד. כל מה שאני כותב בפוסט זה מבוסס הן על תיעוד של היצרניות והן על בדיקות Stress testing שביצעתי עבור לקוחות. שמתי לב שרבים מאנשי ה-IT (וחלק קטן מאנשי השיווק) מביאים/מציגים פרטים ישנים או רלוונטיים ולכן בפוסט זה אתייחס לסוגים שונים של דיסקים. הן ללקוחות קצה ביתיים/סמי-מקצועיים והן ל-Enterprise. הטכנולוגיה והמושגים רלוונטיים בערך לשנתיים האחרונות.

אתחיל בנושא אחריות ו"טחינת דיסקים", מושג שמתאים לדיסקים מכניים ולא ל-SSD ואסביר מדוע.

אחריות על דיסקים נמדדת ב-2 מושגים שונים, תלוי בשוק. בשוק הביתי/סמי-פרו, היא נמדדת ב-TBW – שזה Terabyte Written, כאשר מדובר על הכמות הכוללת של מידע הנכתב על הדיסק מרגע יציאתו מפס היצור. פירמוט, חלוקה לפרטישנים, כתיבה מחדש, פירמוט מחדש, חלוקה מחדש – אינה "מאפסת" את כמות הנתונים הנכתבים על הדיסק וניתן לראות את כמות הקריאה וכתיבה על דיסק באמצעות כלים שיודעים לקרוא את ה-S.M.A.R.T בדיסק (לא חשוב אם מדובר ב-SATA, SAS, NVME). היצרן מציין כמות מסויימת ולאחריה נדלק "דגל" של WEAR out ב-S.M.A.R.T ומאותו רגע – פגה האחריות. היצרן גם מציין כמות שנות אחריות למקרה ולא מגיעים לכמות הכתיבה/שכתוב המותרת, בדרך כלל זה 3 או 5 שנים (רק בחלק קטן של הדיסקים יש אחריות ל-10 שנים, כמו לסמסונג 850 PRO)

בדיסקים ל-Enterprise המדידה היא שונה והולכת לפי DWPD, כלומר Drive Write Per Day, ובמילים פשוטות: כמה פעמים אתה יכול לכתוב על הדיסק מאפס כל יום ולמלא אותו (אף פעם לא מומלץ למלא SSD עד הסוף, תמיד מומלץ להשאיר 5-10% מחוץ לפרטישן שכותבים עליו, וזאת כדי לאפשר לבקר להזיז נתונים שנכתבים על תאים בעייתיים ובכך לתת לדיסק להמשיך לפעול כמצופה) וגם כאן יש כמות שנים לאחריות (3-5). על הנייר, במידה ותעבור את כמות ה-DWPD, דגל ה-Wear Out ב-S.M.A.R.T ידלק והאחריות תפוג.

כל מה שהזכרתי כאן – הוא "על הנייר", אבל המציאות שונה לחלוטין.

בניגוד לדיסקים מכניים, דיסקים SSD (שוב, אין זה משנה איזה חיבור, ולמעט דיסקים Optane מהקצה הגבוה – שהם אינם מבוססי NAND Flash) צריכים טמפרטורה מסויימת כדי לכתוב. בדרך כלל SSD במצב אידיאלי שלא מבצע עבודה יהיה בטמפרטורות הנעות בין 30-40 מעלות וכשמתחילים לכתוב נתונים, החום עולה, וככל שכותבים עוד ועוד נתונים (עשרות עד מאות ג'יגהבייט) החום עולה ברציפות וכשהוא מגיע בערך ל-78 מעלות ומעלה, מהירות הכתיבה יורדת משמעותית (אגב, זה קורה גם ב-Mixed Intense SSD אם כי בצורה פחות דרסטית) לעשרות מגהבייט עד קצת מעל 100 מגהבייט לשניה כשכותבים מעל 30-50 ג'יגהבייט באופן רצוף. בכתיבה אקראית/מזדמנת קצרה (עד 5-10 ג'יגהבייט, תלוי ב-SSD), ה-SSD יפעיל אלגוריתמים שונים שכל מטרתם היא לחסוך בכתיבה, כך שגם בעבודות כבדות מאוד, ב-99.99% מהמקרים לא תגיעו לכמות הכתיבה המותרת ביום (כמות הקריאה ביום אינה מוגבלת מבחינת אחריות בשום SSD), ולכן – אין זה משנה אם המערכת שלכם כותבת ביום 2 ג'יגהבייט או 300 ג'יגהבייט ביום על SSD – זה לא "טוחן" אותו (ולא תשמעו ממנו קולות כמו בדיסקים מכניים ישנים).

הדברים שכן יאיטו SSD הם:

  1. ניצול 100% מהדיסק כך שלא נשאר למערכת מקום להעברת מידע שמאוחסן בתאים דפוקים (ראו המלצה לעיל בנוגע ל-Provision).
  2. דיסקים SSD ביתיים זולים (Corsair MX300, MX500, סאנדיסק ביתיים ישנים)
  3. דיסקים SSD לא DRAM או SLC Cache שמשמש כחוצץ ל-NAND.

נקודה חשובה לגבי אחריות דיסקים (SSD או מכניים): היצרן מעניק אחריות לדיסק למשך מספר שנים המצוין (או לפי כמות כתיבות או לפני DWPD). בחברות שקונות את הדיסק מיצרן השרתים – התהליך קל ופשוט – נותנים אחד, מקבלים אחד. במקרים של קניה מאמזון – אפשר לפנות ישירות ליצרן, תצטרכו להציג חשבונית על מנת להתחיל תהליך החלפה. אצל חלק מהמוכרים בארץ של דיסקים דגמים ישנים לציוד ישן – האחריות היא מול המשווק בלבד (אולטרייד לדוגמא). בכל המקרים של החלפה מול היצרן, האחריות שתהיה על הדיסק המוחלף אינה אחריות מלאה ל-3-5 שנים אלא רק ליתרה של האחריות. לדוגמא: אם יש לנו מערכת בת 4 שנים (שקנינו אותה יחד עם הדיסקים שיש להם אחריות ל-5 שנים) ואנחנו מחליפים דיסק תקול, היצרן יתן אחריות למשך שנה בלבד (או 90 יום אם האחריות נגמרת עוד חודש נניח), ולכן במקרים כאלו אולי כדאי לשקול לקנות דיסקים חדשים.

נעבור מכאן לדיסקים SSD יד שניה: ישנם מדי פעם באתרי מכירה שונים (איביי, אמזון וכו') דיסקים משומשים של Enterprise במחיר זול ומפתה. אלו דיסקים שלא ממש יתאימו לחברות מכיוון שהיצרן לא יתן לכם כרוכשים אחריות כלשהי. מה שכן, הם יכולים להתאים למקומות ואנשים שלא אכפת להם לרכוש בזול תוך נטילת סיכון שלא תהיה אחריות. מבחינת ביצועים – לא אמורה להיות בעיה איתם. חשוב, אם אפשר, לבקש מהמוכר לראות תמונת סטטוס של ה-S.M.A.R.T לפני רכישה (בלינוקס אפשר לבדוק זאת עם smartctl, ב-Windows יש S.M.A.R.T. Monitoring Tools) ולבדוק מה הגבולות כתיבה שהיצרן ציין לגבי אותו SSD.

נקודה נוספת שחשובה הן בדיסקים NVME חדשים או יד שניה: אם אתם מחברים מספר דיסקים כ-RAID כלשהו (לא RAID-5!) ואתם מצפים לראות ב-OS מהירות כתיבה/קריאה כפול מה שכתוב על המדבקה/במפרט – תתכוננו להפתעות. Windows Server 2019 במערכת עם 12 דיסקים ב-RAID-6 לדוגמא נתנה ביצועים של … 10 ג'יגהבייט לשניה בקריאה, גם אחרי כיוונון כל הגדרה אפשרית, ובלינוקס עם ZFS יש תוצאות הרבה יותר טובות אך שאינן מגיעות למהירות המדבקה (אז אל תסמכו על JMeter).

דיסקים שכדאי לצפות לקראתם בשנה הבאה (לפי השמועות וההדלפות) – לכל אלו שצריכים דיסקים SSD NVME לעבודות כבדות (Cache, SQL) ואחרים:

  • סמסונג ZET דור שני וביצועים מאוד מרשימים בקריאה, ו-Latency שמאוד קרוב ל-DRAM
  • Optane דור שני – דיסקים יותר גדולים, פתרון יותר טוב לקירור, ביצועים בערך כמו הדור הנוכחי.
  • דיסקים SSD ל-Enterprise מבוססי QLC (כל היצרנים) זולים. עדיף לוותר, ביצועי כתיבה מחרידים!
  • שרתים עם דיסקים SSD בחיבור U.3 או מסוג Ruler. תהיו קונסרבטיביים ואל תרכשו – החברות (סמסונג, אינטל ועוד כמה) עדיין במריבות לגבי הסטנדרט. רוצים NVME? רק עם חיבור U.2 או כרטיסי PCIe.

על AWS וחסכון: Lightsail

במסגרת הפוסטים שלי לגבי חסכון במערכות AWS, אחת הפונקציות שלא רבים מתייחסים אליה היא שרות אמזון Lightsail: זהו שרות שמציע מכונות וירטואליות במחירים קבועים ומספר שרותים קטן מנוהל, יחד עם כתובת IP קבועה, ניהול DNS, ניהול חומת אש פשוטה, יצירת snapshot כגיבוי למכונה ועוד.

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

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

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

  • 3 שרתי לינוקס שמריצים WordPress עם מפרט נמוך 2-4 ליבות, 2-4 ג'י'גהבייט זכרון.
  • ה-DB לא ירוץ באותן מכונות, הוא ירוץ משרות ה-DB המנוהל ש-AWS מציעים – אפשר לבחור עם או בלי שרידות, כך שכל מה שאצטרך לעשות זה להגדיר את ה-DB בוורדפרס.
  • התכנים ישבו ב-DB והתמונות ישבו ב-S3 (שימוש ב-S3 מחייב תשלום נפרד על האחסון ועל התעבורה)
  • שרות Load Balancing מנוהל שמוצע במסגרת ה-Lightsail (עלות: $18 בחודש)
  • את הסינכרון בין השרתים אני יכול לבצע דרך GIT עם פקודות אוטומציה להוריד ולסנכרן מול הדיסק המקומי של המכונה. עלות: 0.
  • פעם בשבוע או בחודש אני יכול להוריד מכונה אחת, ליצור Snapshot כגיבוי ואם צריך – לבנות מה-snapshot מכונה חדשה.

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

עם Lightsail לא תוכל (ברמה העקרונית) להשתמש ברוב השרותים ש-AWS מציע אלא אם תריץ חיבור VPC Peering בין המכונות שנמצאות ב-Lightsail לבין ה-VPC שמוגדר לך בחשבון או שאתה בנית.

אסכם כך הדברים: Lightsail בעקרון מגיע כפתרון תחרותי מול ספקי ה-Hosting השונים ובמחירים מאוד מפתים. הפתרון הזה מתאים לדוגמא לי, כי אני מחפש "נראות חיצונית" לעסק שלי ולבלוגים שלי, והמחיר שאני משלם בחודש ($20) הוא ידוע וקבוע. הפתרון יכול להתאים גם לאחרים, כל עוד הם מחפשים מכונות לא חזקות, עם מפרט קבוע ומחיר קבוע – עבור לקוחותיהם לדוגמא, אך Lightsail אינו מתאים משאבי עיבוד גבוהים בצורה קבועה, ולמי שמחפש להקים מכונות וירטואליות זמניות (מה לעשות, עם Lightsail, הרמת מכונה רק ל-5 דקות, אתה חייב לשלם על כל החודש). אם אתם מחפשים להשתמש בכלים המתקדמים של AWS, חברו את המכונות הוירטואליות ב-Lightsail אל ה-VPC שלכם שבניתם או שבכלל תשתמשו ב-Instances של EC2.