סקירה כללית: מעבד AMD Threadripper 2990WX

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

ככה זה. (יש כמובן יוצאים מן הכלל).

ל-AMD יש היסטוריה שאינה כל כך "זוהרת". תמיד הם הציעו מעבדים, אבל ההצעות שלהם בד"כ הגיעו עם יתרון אחד: מחיר נמוך יותר. ביצועים כמו של אינטל? אפילו לא קרוב. כל זה השתנה עם ארכיקטורת ZEN. בהתחלה עם מעבדי ה-Ryzen 1XXX ועם מעבדי ה-Threadripper (המעבד הראשון בעולם שהציע 16 ליבות במחיר שלא קורע את הארנק והכיס) וכעת עם ארכיקטורת +ZEN שמשפרת מספר דברים הן במשפחת מעבדי ה-Ryzen 2XXX והן ב-Threadripper 2XXX ושוב – מחיר נמוך יותר מהמעבדים של אינטל ועם ביצועים שלפעמים עוקפים את המעבדים של אינטל ולפעמים לא.

ואז יש לנו את מעבד ה-Threadripper 2990WX. בפעם הראשונה מוצע לצרכנים הכבדים שמחפשים תחנות עבודה רציניות (או שרתים ל-LAB) מעבד עם 32 ליבות, 64 נימים, תמיכת זכרון 128 ג'יגהבייט (או עד 1 טרהבייט ECC) במחיר של $1800!

למי המעבד הזה מיועד? הוא מיועד למספר סקטורים:

  • ה-Pixel Pushers – אלו שעובדים בתוכנות תלת מימד, החל מ-Blender, Maya ועוד כלים שיודעים לנצל כמה שיותר ליבות.

ה-Multi Taskers – אותם אלו שעובדים בתלת מימד אבל גם עובדים עם עריכת וידאו במקביל. אחד החסרונות במעבדים של אינטל (עם 10 ליבות לדוגמא) זה כשאתה מרנדר דברים מקומית (אפטר, פרמייר, דה וינצ'י) – קשה להמשיך לעבוד עם אפליקציות כבדות אחרות במקביל. ה-2990WX לא מגיע לביצועי קידוד וידאו של המעבדים מרובי ליבות (10 ומעלה) של אינטל, הוא נותן בערך אותה תוצאה אבל מכיון שרוב תוכנות העריכה/אפקטים בקושי משתמשים בכמות של 4-8 ליבות, יש לך מספיק ליבות פנויות לעבוד על דברים אחרים מבלי שהביצועים יהיו גרועים.

  • לינוקס – מכיוון שתוכנות רבות ללינוקס לא בנויות עם מגבלת ליבות ויכולות לנצל כמה שתתן להן, ה-2990WX פשוט "בועט" בכל מעבד אחר. כאן תוכלו לראות סקירה ארוכה עם Benchmark לגבי כמעט כל דבר שמשתמשים בלינוקס ולראות איך ה-2990WX משאיר אבק לאינטל.
    במילים אחרים: צריכים לבנות מערכת Build רצינית שמקמפלת קרנל שלם (ללא שימוש ב-ccache) ב-30 שניות? צריכים מערכת Jenkins שתבנה המון חבילות במקביל? זה המעבד עבורכם.
  • וירטואליזציה – ה-2990WX מציע בעצם לראשונה מערכת חזקה לצרכי וירטואליזציה למחלקות הפיתוח מבלי לקרוע את הכיס, כל פתרונות הוירטואליזציה נתמכים.

אם נחזור לאותן חברות שלא ממש מוכנות (במידה מסויימת של צדק) לרכוש ציוד חדש למחלקות הפיתוח, אז ה-2990WX יכול לראשונה להציע פתרון מאוד חזק, אך יחסית זול (בהשוואה לתחנת עבודה של חברות כמו HP, DELL,Lenovo) שיכול להתאים הן כתחנת עבודה והן כשרת לא-פרודקשן.

מה תהיה התשובה של אינטל? סביר להניח שנשמע עליה בחודשים הקרובים, אבל אם אינטל תוציא מעבד 32 ליבות, תהיו בטוחים שהוא יעלה הרבה הרבה יותר מ-1800$.

לסיכום: ב-Anandtech, ב-Toms Hardware, ב-OC3D, ובאתרים אחרים יש סקירות על ה-2990WX וכולם מסכימים עם אותם דברים: אם אתה צריך להריץ דברים כבדים ב-Multi task, אם אתה מריץ אפליקציות שיודעות לנצל כל ליבה – המעבד הזה יכול להתאים לך. אני מוסיף שכאן בחברות, ה-2990WX יכול לעזור היכן שצריך ביצועים אבל אין תקציב לשרתים רציניים.

נקודות למחשבה כשרוצים לרכוש סטורג' חדש

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

לא מעט חברות בארץ משווקים (או Reseller) של מוצרי סטורג'. חלק מהמוצרים הם סטורג' "אמיתי" וחלק מהמוצרים הם לא יותר מאשר שרת סטנדרטי שהוכנסו לתוכו דיסקים, מערכת הפעלה קניינית הכוללת פתרון סטורג' בתוכנה – והרי לכם סטורג' מבוסס תוכנה. כמעט אף אחד, אגב, לא יאמר לכם שזה SDS (כלומר Software Defined Storage) למרות שרוב הסטורג'ים שמוכרים בקצה התחתון עד בינוני הם SDS לכל דבר ועניין, רק שאתם תשלמו מחיר הרבה יותר גבוה ממחיר שרת רגיל שיש בו דיסקים ואיזו תוכנה. מדוע? וולקאם טו איזראל!

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

  • 22 דיסקים של סמסונג מסוג PM883 בגודל 1 טרהבייט מסוג Mixed Intensive
  • 2 דיסקים של אינטל 900P (לצרכי Cache, ZIL, Logs) בגודל 280 ג'יגהבייט
  • 256 ג'יגהבייט זכרון DDR4 ECC במהירות 2666 מגהרץ
  • מעבד יחיד Xeon V4 עם 4 ליבות
  • מערכת הפעלה: Fedora 28 עם ZFS
  • חיבורי רשת של 25 ג'יגהביט

המערכת הזו עבדה במשך חודשיים תוך כדי שהיא מחוברת ל-15 שרתי ESXi ונתנה הן שרותי iSCSI והן שרותי NFS (נפרדים, ישירות ל-VM). מבחינת IOPS – זה נע בין חצי מיליון ל-מיליון.

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

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

  • ה-256 ג'יגהבייט זכרון – זה ה-RAM של המערכת, זה הדבר הכי מהיר שיש
  • 2 הדיסקים 900P של אינטל – יש להם Latency יותר גבוה מ-RAM אבל יותר נמוך מכל דיסק אחר
  • דיסקים SSD

בסטורג' קנייני לעומת זאת (StorWiz של IBM, או VNX של EMC לדוגמא) ה-Tiering מעט שונה:

  • שכבת ה-RAM
  • שכבת NVRAM – זהו זכרון מסוג מיוחד שאינו נמחק ברגע שאין חשמל
  • שכבת ה-SSD
  • שכבת הדיסקים המכניים / SSD שליפים (במדפים)

בשרתי סטורג' שהם SDS אין שכבת NVRAM ובמקרים רבים גם אין בקרי RAID כפולים, כך שה-Tiering הוא כמו זכרון, SSD, ודיסקים. כאן, חשוב לדרוש שיהיו SSD שלא מותקנת עליהם מערכת ההפעלה, ה-Cache אמור לשבת ב-SSD נפרדים ושיהיו Mixed Intensive. ברוב ההצעות מחיר שתקבלו, ה-SSD יהיו Read Intensive ויש הבדל ניכר במחיר.

דבר נוסף שחשוב הוא עניין החיבוריות: כמעט כל מי שמוכר פתרון סטורג', מוכר אותו עם פתרון FC (כלומר Fiber Channel) במהירות 16 ג'יגהביט. זהו פתרון טוב לדיסקים בחיבור SAS ו-SAS2 או SATA למדפים/JBOD או בדיסקים שיושבים בשרת, אבל אם אתם חושבים על NVME – פתרון ה-FC יהווה צוואר בקבוק – חיבור 16 ג'יגהביט מאפשר ברוטו 2 ג'יגהבייט לשניה, ו-NVME מעביר בין 1.5 ל-2.5 ג'יגהבייט לשניה ואני מדבר על דיסק יחיד, ומכיוון שלעולם לא תכניסו SSD NVME יחיד, החיבור יחנק, ולכן אולי כדאי לחשוב על פתרונות Infiniband או Ethernet מהירים במהירות 25 ג'יגהביט ומעלה (ובקשר ל-Latency – ישנם מס' פתרונות עם Latency נמוך, כולל RDMA וחבריו).

אם כבר דיברנו על FC, לא מומלץ לסמוך על 4 חיבורי ה-FC שקיימים ותמיד מומלץ לקנות מתג לחיבור המהיר, במיוחד אם יש לכם רק 3 שרתים ואתם חושבים לגדול בהמשך. יש תחרות, נצלו אותה לשם מו"מ כדי להשיג מחירים טובים.

נקודה נוספת שחשוב לקחת בחשבון היא גיבוי הסטורג' עצמו. כן, יש Veeam שמגבה מכונות וירטואליות (והוא מגבה ל.. סטורג') אך תקלה רצינית בסטורג' (ותקלות תמיד קורות, תשאלו את מרפי) לא תאפשר לכם לא לשחזר מכונות VM או דברים אחרים, ולכן כדאי לגבות את הסטורג' לקלטות גיבוי או למכונת NAS זולה אחרת (במכונות שהן אינן G8/G9/G10 של HPE שהן אינן ביצור/פרודקשן אפשר גם להכניס SATA "ביתיים" גדולים זולים, רק חשוב להוסיף SSD לשם Cache). כאן, אגב, אני רוצה להזהיר בהזדמנות שדיסקים SSD של אינטל ש-HPE משווקת, במקרים רבים הקושחה כזו גרועה, שדיסקים נופלים גם בצוותים!

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

ומה לגבי כל ההתלהבות לגבי HCI עם vSAN/Nutanix/Simplivity במקום סטורג' יעודי? הם טובים, אבל הבעיה האמיתית שלא תמיד שמים לב אליה היא עניין גדילת כמות הסטורג': במקרים כמו vSAN לדוגמא תצטרכו להוסיף 3 דיסקים (2 מכניים או SSD Read פלוס SSD מהיר) פר שרת שמשתתף ב-HCI, ומהירות IOPS גבוהה מקבלים רק כשכמות השרתים המשתתפים ב-HCI היא גדולה (ארון פלוס). נוסיף לכך שבניגוד לדיסקים ביתיים, דיסקים ל-Enterprise יקרים והמחירים בקושי יורדים (וחברה כמו HPE לוקחת עשרות אחוזים יותר בגלל … מדבקה ושינוי כמה ביטים בקושחה) – זה יכול להוות בעיה בטווח הארוך.

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

פוסט עדכני על קורסים בחברות

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

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

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

  • קורסים מסויימים מלמדים על כמה הפצות לינוקס במהלך הקורס. זו, לעניות דעתי, טעות. לי, אישית, כשאני לומד עדכון של הפצה שאני כבר מכיר, לוקח לי כמה שעות במשך כמה ימים ואילו הפצה חדשה לוקח לי יותר זמן ללמוד (מה לעשות, צריך גם להתפרנס, לא? 🙂 ). לעומת זאת, מישהו שהוא חדש בתחום  הלינוקס, יקח לו הרבה יותר זמן ללמוד, ולימוד הפצות שונות באמצע די מבטיח בלבול רציני. כבר ראיתי מישהו שדי חדש בלינוקס מתעקש במשך שעה לנסות להתקין חבילות תוכנה עם פקודת zypper (שקיימת להפצת SuSE) בשעה שהוא היה צריך להשתמש בפקודת yum (שקיימת בהפצות Red Hat ו-CentOS) ולכן קורס טוב לדעתי צריך להתמקד בהפצה עיקרית אחת.
  • שיטת לימוד של "נזמין את המדריך ליומיים שלוש" להדרכה, היא שיטה די בטוחה שהכסף שיושקע ילך לטמיון. לינוקס זה לא לימוד MCITP ורוב מוחלט של החומר הנלמד הם פקודות טקסטואליות שצריך לשנן, ולנסות. קורס יומיים? תהיה בטוח ש-90% מהחומר ישכח ע"י רוב התלמידים, ועל כך יכול להעיד המייל אצלי. יש צורך לפרוס את זה ליום או יומיים בשבוע לשעות ספורות.
  • רלוונטיות: מכיוון שהשוק פתוח וכל אחד יכול להציע קורסים כאוות נפשו, מגיעים אליי כל מיני שאלות אם אני יכול להעביר קורס על טכנולוגיה זו או אחרת. טכנית, אין לי בעיה להעביר, אבל התועלת לחברה חשובה לי לא פחות מכך וצריך לבדוק (כן, תחת NDA) היכן זה משתלב. כך לדוגמא פנו אליי בעבר להעביר קורס מעמיק ב-Docker. זה, לדוגמא, קורס שהתוכן שרלוונטי הוא אולי 10% כי בסופו של יום אם מתחילים לבנות בחברה קונטיינרים, משתמשים במערכת ניהול והרצת קונטיינרים כמו OpenShift או Kubernetes – כך שללמד איך לבנות קונטיינרים – כן, איך להריץ ואת החלקים הפנימיים ב-Docker – לא ממש, תשאירו את זה להדרכות על כלי הניהול.

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

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

על גריטת שרתים ישנים ומה ניתן לעשות

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

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

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

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

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

  • HP G9 לסוגיו
  • DELL X30 (ה-X מוחלף ב-400, 600, 700 וכו'. האות שבשם לא ממש משנה)

הדבר הראשון שצריך לבדוק הוא אלו מעבדים יש לכם (אפשר להסתכל ב-BIOS/UEFI). אם יש לכם Xeon V3 אז אתם יכולים לפנות ליצרן ולרכוש Kit שדרוג למעבדים, אפשר להכניס מעבדי Xeon V4 לשרת (יש צורך לעדכן את ה-BIOS/UEFI לפני כן, אם לא שדרגתם לאחרונה). הביצועים לא יהיו כמו שרת דור קדימה (G10, X50), אבל אתם תקבלו ביצועים שגבוהים בין 30-60% (ההפרש בביצועים הוא בגלל הזכרון, בשרתים כמו G10,X50 הזכרון הוא DDR4 במהירות יותר גבוהה ממה שיש לכם עם ה-DDR3).

הבעיה בעניין השדרוג קשורה לדרך שאתם רוצים לשדרג. אם אתם לדוגמא חושבים לפנות ליצרן, המחיר שיגבה מכם לא ממש זול. אם לדוגמא יש לכם שרתי X30 של DELL (שוב, ה-X מוחלף במספר 430,630,730 וכו'), תצטרכו לשלם בסביבות ה-800-6000 דולר (תלוי במעבד) כפי שאתם יכולים לראות כאן. אם לעומת זאת אתם קונים מסוחר יד שניה שמביא טכנאי שעושה לכם זאת, המחיר זול יותר. כך אתם מאריכים את חיי השרתים הללו בעוד כמה שנים.

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

שרתים ישנים יותר כמו:

  • HP G7 לסוגיו
  • IBM M3 לסוגיו
  • DELL X20 (שוב, תחליפו את ה-X ב-620,720,420 וכו', לא חשוב האות)

אלו שרתים שניתן ניתן לשדרג מעבדים אבל רק לאותה משפחה (כלומר Xeon V1, לרשימה הזו וגם אז, רק ה-E5-2XXX או E5-4XXX אם יש לכם שרתים עם 4 תושבות למעבדים), כך שאתם יכולים לדוגמא לעבור ממעבדים עם 4 ליבות, למעבדים עם 12 ליבות. השדרוג יוצא יותר זול מהדוגמאות לעיל, אבל הביצועים, למען האמת, לא יהיו כאלו גבוהים כי הם לא כוללים טכנולוגיות יותר מתקדמות שקיימות ב-Xeon V4 והזכרון מאוד איטי בהשוואה לשרתים הכוללים זכרון DDR4.

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

שרת NAS מהיר.

נדמיין לנו סיטואציה: יש לנו מחלקת פיתוח ויש לנו 2 שרתי ESXI שמיועדים לדברים שאינם פרודקשן. עם אותו שרת ישן אנחנו יכולים לספק שרותי NAS ל-2 שרתי ה-ESXI במהירות 10 ג'יגה.

כיצד? די פשוט:

בשרת הישן אנחנו נתקין בקר RAID די מודרני (LSI/AVAGO) ונחליף את כל הדיסקים לדיסקים SATA או NL-SAS (אנחנו לא רוצים להשקיע יותר מדי כסף, נכון? זה לא פרודקשן) ואנחנו נוסיף דיסק SSD (יחיד או זוג, תלוי בכם) שישמש כ-Cache מהיר. את ה-Back Plane של השרת אנחנו ננתק מבקר ה-RAID הפנימי ונחבר לבקר ה-RAID החדש.
כרטיס נוסף שנצטרך הוא כרטיס רשת QSFP (יש גם +SFP) של 10 ג'יגהביט עם 2 פורטים (אפשר להתקין 2 כרטיסים כאלו עם כניסה יחידה בכל אחד מהם, מכיוון שבשרת יש לנו רק PCIe 2.0) ובשרתים נתקין גם כרטיס רשת כזה.
מה עם סוויצ'? לא צריך. אנחנו מחברים כבל DAC בין ה-NAS לבין כל שרת ESXI.

מבחינת מערכת הפעלה, זה כבר תלוי בכם: אתם יכולים להתקין לכם Windows עם Storage Spaces, לינוקס רגיל ולהגדיר דברים ידנית, FreeNAS ויש עוד מספר פתרונות. אחרי ההתקנה של הפתרון אנחנו יכולים לבחור מה אנחנו רוצים לייצא החוצה (לא לשכוח להגדיר את ה-SSD כ-Cache במערכת שהקמנו) – בין אם זה NFS או iSCSI או CIFS ו"לשדך" את זה למערכת ה-ESXi (ה-CIFS הוא למקרים אם אתם משתמשים ב-Hyper-V לדוגמא).

והרי לנו שרת NAS שיכול לתת לנו פתרון שעוקף פתרונות NAS הרבה יותר טובים מפתרונות NAS זולים סגורים.

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

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

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

כמעט אצל כל חברה שיש לה תשתית מחשבים רצינית עם שרתים (או בענן), בדרך כלל קיימות הפרדות בין חיבורי רשת לאינטרנט לבין חיבורי LAN. שרתים ומחשבים מקבלים כתובות IP פנימיות ולא כל מחשב או שרת מקבל גישה לאינטנט. מבחינת כניסה לא מורשית מבחוץ – בדרך כלל יהיה פתרון Firewall ובחברות שמשקיעות – יהיה כנראה גם פתרון IDS/IPS ואולי עוד כלים נוספים, הכל כדי למנוע פריצה של גורמים זדוניים מבחוץ.

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

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

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

בדרך כלל, לפני פריצה כזו, הם יבצעו תחקיר בסיוע כל דבר אפשרי (ריגול דרך האינטרנט ברשתות חברתיות, ריגול "קלאסי" תוך שימוש בסוכנים שנמצאים בארץ) כדי למצוא מי האנשים שאותם הם הולכים לתקוף במובן הסייבר. הם יחפשו אנשי IT ואם אפשר – אנשים שיש להם כמה שפחות ידע/נסיון בתחום ה-IT אך שיש להם גישה פנימית למערכות, אחד כזה שלמחשב שלו בעבודה יש חיבור לאינטרנט ול-LAN הפנימי, והוא לא ממש שם לב לשינוי בין URL כמו secure.iec.co.il ל-secure.iec.co.il.info (דוגמא פיקטיבית, אין לי מושג ירוק בתשתית של חברת חשמל). נניח שהראשון מפנה ל-ADFS או משהו חשוב אחר. ה-URL השני שנתתי הוא מזויף והפורצים הקימו אותו (כולל העתקה של גרפיקה עד לביט האחרון) כך שאותו איש IT לא יחוש בסכנה ויכניס את פרטיו האמיתיים להיכנס למערכת. (אגב, טריק ששמעתי שמשתמשים בו אחרי הכנסת שם משתמש וסיסמא הוא להציג הודעה של שם משתמש/סיסמא שגויים כדי "לשאוב" שמות משתמש וסיסמאות נוספות מאותו איש IT).

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

מהרגע שאותו קובץ פועל, לפורצים יש בעצם גישה. סביר להניח שהם יפתחו איזו מערכת C&C (ר"ת Command & Control) כדי לראות איך לגשת אל המערכת, ומכיוון שמשתמשי IT רבים משתמשים בתוכנות כמו SecureCRT ותוכנות אחרות המאפשרות גישה במקביל לשרתים, יש עכשיו לפורצים דרך להיכנס למערכות האחרות עם ההרשאות של אותו איש IT ומהמחשב שלו, כך שסביר להניח ששום מערכת מניעה לא ממש תזהה פעילות חריגה. תזכרו – בשלבים הראשונים, הפורצים לא משנים קבצים וקונפיגורציות, הם לומדים.

אז … מה ניתן לעשות כדי להקשות?

יהיו כאלו שיציעו להשתמש ב-Smart Card. רעיון לא טוב, מכיוון שבד"כ ה-Smart Card נמצא בתוך המחשב ולא מוציאים אותו ואת ה-PIN אפשר לתפוס עם key logger. אז הפתרון הזה עף החוצה.

פתרונות אחרים שיכולים לעזור, הם פתרונות שבעצם מבוססים על אימות כפול, תוך שימוש בטביעת אצבע עם ציוד בחיבור USB או באמצעות TOTP (ר"ת Time Based One Time Password) שמותקן על הטלפון הסלולרי. אפליקציה פופולרית לכך (שנמצאת ב-Repo של כל הפצת אינטרנט) היא Google Authenticator (האפליקציה לא מצריכה חיבור אינטרנט).

איך מיישמים זאת? בכמה צעדים, תלוי במערכת:

  • מערכות לינוקס רחוקות עם כניסת SSH: אם נחליט על TOTP עם שימוש באפליקציה כמו ה-Google Authenticator (יש אפליקציות אחרות ויש גם את המפתחות RSA המפורסמים, כולם עושים את אותה עבודה), נוכל לעקוב אחר ההוראות כאן כדי להתקין זאת. משהו שצריך לקחת בחשבון – תצטרכו להעיף מפתחות SSH מקובץ ה-authorized_keys על מנת שה-TOTP יפעל. כך שתנסו להיכנס לאפליקציה, המערכת תבקש ממכם קוד וידוא שיופיע לכם באפליקציה בטלפון (או במפתח RSA הפיזי).
  • מערכות לינוקס/Windows מרוחקות עם כרטיס Yubikey (גוגל בקרוב מוציאה מוצר מתחרה שנקרא Google Titan, גם הוא פתרון מבוסס FIDO2) – בדרך זו יש לחבר ל-USB מפתח ובכל פעם להעביר את האצבע כשיש צורך לבצע אותנטיקציה. השיטה הזו יותר מאובטחת משיטות שימוש בקורא טביעות אצבע שמובנה במחשב). גם כאן, תצטרכו לבצע תהליך התקנה, רק שכאן יש גם שימוש ב-OpenPGP. כל הפרטים נמצאים כאן.
  • מערכות Windows (תוך שימוש ב-RDP): פתרון חינמי אין למיטב ידיעתי, יש פתרון מסחרי שתומך גם ב-TOTP וגם ב-FIDO2, יש פתרון של חברת ROHOS כאן.

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

האם לעבור ל-vSAN/Nutanix/HCI?

תחום ה-Scale Out היה עד לפני מס' שנים תחום די "ישנוני". כאחד שמכיר את התחום, בדרך כלל הייתי מקבל שאלות לגביו רק מגופים גדולים – אוניברסיטאות, צה"ל, מכוני מחקר גדולים וכל מי שמבחינתם צ'ק של 6-7 ספרות (בדולרים) הוא לא כזה ביג דיל. כשאלו קונים מכונות, זה נעשה בכמות דו ספרתית כמינימום (כל פעם), כולל ערימת מתגים, דיסקים וכו'. מבחינתם כל עניין ה-Scale Up יותר מתאים "לאחרים", לא בשבילם.

ואז הגיעה חברת VMware עם vSAN ואחריה Nutanix שהחלה "לגנוב" ל-VMWare לקוחות, וגם Simplivity ואפילו רד-האט עם פתרון ה-RHV בגירסאות האחרונות. בקיצור – ב-4 שנים האחרונות חברות החלו יותר ויותר להציע פתרונות עם העדפה ל-Scale Out מאשר Scale Up. פה בישראל Nutanix כובשת יותר ויותר לקוחות מכיוון שהמערכת שלה גמישה כדי להריץ את הוירטואליזציה הנוכחית שלך או את פתרון הוירטואליזציה שלהם (KVM).

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

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

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

יחד עם זאת, הנה כמה כללי אצבע וכמה דברים שכדאי לחשוב עליהם.

נתחיל ב-Scale Up ונתייחס לבחירה הפופולרית בארץ לוירטואליזציה – של VMWare. נניח שיש לי כאן 10 שרתים שמריצים ESXi, ועל 2 מכונות רץ VCSA ומכונה שלישית משמשת כ-Witness ("עד") על מנת ש-VCSA ירוץ תמיד (בבקשה, תיפטרו כבר מה-vCenter שרץ על Windows). מה עושים כל שאר השרתים? מריצים מכונות וירטואליות. הם שרתים "טיפשים" וחוץ מהשרותים ש-ESXi שמריץ, המכונה כמעט ולא מריצה שום דבר אחר אלא את המכונות הוירטואליות שלכם. כל מה שקשור לדיסקים לדוגמא "נזרק" לביצוע ע"י הסטורג' עצמו (אם הוא תומך ב-VAAI וכו'), ועבודת ה-Network בקושי לוקחת משאבים, והיא מנוהלת ע"י ה-vCenter/VCSA (כשמדובר ב-DVSwitch) או ה-ESXi (כשמדובר ב-vSwitch רגיל). כל עניין ה-Compute רץ על המעבדים והזכרון.

ב-Scale Out לעומת זאת, הכל הפוך. בפתרון של VMWare יש לנו מודול נוסף של vSAN שיוצר לנו Datastore מבוסס על הדיסקים המקומיים (בקבוצות של SSD+זוג מכניים) וגם על הדיסקים של השרתים השכנים, כלומר בשרתים מוקצה זכרון ו-CPU לניהול האחסון, שרידות וכו' וכו'. במקרים של Nutanix/Simplivity – יש ערימה שלמה של שרותים נוספים שרצים פר שרת. נקודה חשובה נוספת: בשביל לקבל IOPS גבוה, חייבים לרכוש מספר גדול של שרתים, אין דרך להתחמק מכך.

העניין החשוב שצריך לקחת בחשבון הוא לא הקניה של ה-3-5 מכונות בשביל Nutanix/Simplivity, או הרשיונות והדיסקים שצריכים לקנות עבור ה-vSAN, אלא הגדילה העתידית.

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

בסיטואציית Scale Out לעומת זאת, כמעט הכל הוא פי כמה וכמה, כלומר אם אנחנו רוצים אחסון נוסף, אז עם vSAN אנחנו צריכים זוג מכניים+SSD מהיר כפול כמות המכונות שיש לנו (לפחות לפי ה-Groups שהגדרנו). צריכים עוד זכרון? אפשר כמובן להרחיב בצורה יחידנית וכנ"ל לגבי מעבדים, אבל ההמלצה היא לא לעשות כך אלא להוסיף עוד שרתים פיזיים עם כמות מסויימת של דיסקים זכרון ומעבדים, כך שכל פעם כשאנחנו צריכים משאבים נוספים, אנחנו מזמינים שרתים נוספים. טכנית אין שום בעיה להגדיל אחסון מ-2 טרה ל-20 טרהבייט באחד מהשרתים, רק שאותה מכונה שהגדלנו תהיה בקושי מסונכרנת עם האחרים כי היא תצטרך לעבוד הרבה יותר קשה מהשרתים האחרים.

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

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

  • כמה סטורג' אנחנו באמת משתמשים?
  • האם את מס' ה-VM שיש לנו אנחנו יכולים לשים בכמות השרתים שנקנה לצרכי Scale Out?
  • מה לגבי מכונות VM שאינן פרודקשן? האם כדאי לחשוב על פתרון וירטואליזציה חינמית כדי להריץ אותם שם על המכונות הקיימות?
  • האם החברה מתכננת פרויקטים נוספים שיצריכו רכישת שרתים נוספים עם פתרון Scale Out?
  • האם החברה חושבת על פתרון סטורג' מבוסס קוד פתוח שישרת מכונות שאינן פרודקשן או פרויקטים פנימיים אחרים?

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

וירטואליזציה ודיסקים מקומיים. כדאי?

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

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

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

ל-NAS יש יתרון אחד שדווקא לא קיים במרבית פתרונות הוירטואליזציה והוא קשור לאופטימיזציה. הדרייברים שנמצאים בתוכנת הוירטואליזציה הם דרייברים בסיסיים. הם מאפשרים עבודה רציפה עם הדיסקים ותו לא. כך לדוגמא אינך יכול להכניס לשרת וירטואליזציה 1-2 דיסקים SSD ולהגדיר אותם כ-Cache (ה-Read Cache במקרה של vSphere לדוגמא, מיועד להאצת עבודה חוזרת של מכונות VM, לא לשמש כ-Cache ל-Datastore). לעומת זאת, אם נרים NAS על שרת ישן (זה יכול להיות גם PC עם דיסקים במקרים שאין תקציב) ונכניס לו 1-2 דיסקים SSD, נוכל בעזרת התוכנה ב-NAS להגדיר אותם כ-Cache. בנוסף, אם אנחנו רוצים מהירות גישה רצינית אל/מאת ה-NAS ולא להיות "חנוקים" במהירות של 1 ג'יגהביט – אפשר לרכוש בזול כרטיסי רשת QSFP (או +SFP) שנותנים חיבור במהירות 10 ג'יגהביט עם פורטים כפולים וכבלי DAC ולחבר אותם בין ה-NAS ל-2 שרתים שמריצים מכונות וירטואליות. כך הדברים ירוצו הרבה יותר מהר ואין צורך לרכוש סוויצ' 10 ג'יגהביט יקר לשם כך (אגב, התוספת מחיר על כך מגיעה בד"כ בסביבות ה-300$).

מצד שני, יש בהחלט מקום בשימוש בדיסקים מקומיים כאשר אנחנו משתמשים בתצורת Hyper Converge. בקונפיגורציה כזו, המערכת צריכה לפחות SSD אחד על מספר קטן של דיסקים מכניים והיא משתמשת ב-SSD לשם כתיבה/קריאה מואצת וכמובן כ-Cache (רק שחשוב לשים לב איזה SSD Intense אתם רוכשים, אם רכשתם את הלא נכון, הביצועים יהיו מופחתים) אך גם כאן חשוב לשים לב לא רק לסוג ה-Intense אלא גם לסוג החיבור של ה-SSD. חיבור SATA לדוגמא "נחנק" במהירות 560 מגהבייט ואילו SSD בחיבור U.2/NVME יתן ביצועים ורוחב פס עד פי 4-5 בהשוואה ל-SATA.

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

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

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

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

  • עבודות פרויקט: חברת XYZ מעוניינת בפרויקט מעבר תשתית ל-ABC. לאחר שאקבל את המפרט, אני אוכל לדעת פחות או יותר את כמות העבודה ואוכל לתמחר את ההקמה ב-2 אפשרויות מקובלות:
    • אפשרות ראשונה היא אפשרות Fixed לפרויקט – אני אבקש נניח 1000 שקל עבור הפרויקט. בדרך הזו אני קובע את המחיר כמחיר קבוע ללא כמות שעות שאדרש על מנת להקים את הפרויקט. היתרון הוא יותר לכיוון הלקוח: הלקוח יודע שהוא יצטרך לשלם 1000 שקל ולא שקל אחד מעבר לכך. החסרון שלה הוא בכך שאם אני כפרילאנסר אצטרך להשקיע יותר שעות ממה שחשבתי מלכתחילה, אני אפסיד על הפרויקט. מחיר פר פרויקט יותר מתאים לפרויקטים גדולים כאשר המחירים נעים בין 6 ל-7 ספרות ואין אפשרות לתשלום פר שעה.
    • אפשרות שניה היא מחיר פר שעה: באפשרות זו הפרילאנסר מציין מחיר לשעה וכמות שעות מוערכת שיקח להקים את הפרויקט. אפשרות זו עוזרת להימנע מבעיות בהמשך הדרך אם צצות להם פעילויות שיש צורך לבצע שלא נלקחו בחשבון (מכיוון שהן לא היו ידועות) מכיוון שהלקוח יצטרך לשלם על שעות עבודה נוספות על דברים מעין אלו, לעומת מחיר Fixed ששם הפרילאנסר יצטרך לספוג את הפעילות הבלתי צפויה. שוב, בפרויקטים גודלים – החברה הקבלנית תצטרך במקרים רבים לספוג את הפעילות הבלתי צפויה אם היא לא העריכה זאת מראש. היתרון ללקוח בעבודה עם בנק שעות הוא שניתן להשתמש בשעות הנותרים לצרכי תמיכה או לצרכים אחרים שהוגדרו מראש ללא תשלום נוסף.
  • עבודות Pre Sale כאיש מקצוע מלווה: חברה מעוניינת לשווק לגוף גדול מוצר או שרות. לרוב אנשי ה-Pre Sale אין את הידע המקצועי הרחב שיש לפרילאנסר שנותן כבר שרות/הטמעה למוצר, ולכן במקרים רבים חברות שונות מבקשות מפרילאנסר להצטרף אליהן לפגישות עם הגופים הגדולים על מנת לשכנע את הגוף הגדול לרכוש את אותו מוצר או שרות. לעיתים הפרילאנסר יצטרך להכין Demo או מצגת או ניירות עבודה עבור אותן פגישות.
    בעבודות כאלו, מול חברות אינטגרציה גדולות (כמו Matrix) – בד"כ אפשר לסגור את הנושא בכך שהפרילאנסר ירשום את שעות העבודה ושעות הפגישות ויגיש אחת לחודש חשבונית על כך. לעומת זאת, יש לא מעט מקרים עם חברות אינטגרציה יותר קטנות המבטיחות לפרילאנסר שאם הן יצליחו למכור את המוצר/שרות – הוא יוכל להרוויח מכך כסף, כך שהוא לא ירוויח משעות הפגישה/הכנת מסמכים/Demo וכו' וכאן אני חייב להדגיש עבור חבריי הפריאלנסרים: עם הבטחות אי אפשר לקנות בסופרמרקט ולכן אני ממליץ להתעקש על תשלום שעות על הדברים הללו (תתפלאו, אישית אני שבע מרורים מהבטחות שבסוף לא התקיימו כי הגוף הגדול החליט ללכת על מוצר/שרות אחר ואני נשארתי מבלי שקיבלתי אגורה שחוקה על כל ההשקעה שלי).
  • עבודות שזמנן אינו ידוע: חברה מעוניינת שתבצע איזו עבודה, ובהמשך הדרך לבצע עבודות נוספות זהות ללקוחות החברה. גם כאן מופרחות להן הבטחות שמדובר בכמות שעות גדולה, תצטרך להתחייב לבצע את העבודה במהירות רבה, וכמובן – מחיר נמוך כאילו מדובר במאות שעות לחודש. הבעיה: לא ניתן להעריך את כמות שעות העבודה ומתי הדברים יתבצעו, מכיוון שמדובר בתלות בגורמים שונים.
    במקרים כאלו, אני ממליץ לבחור במסלול בנק שעות שהלקוח יצטרך להחליט את כמות השעות והיא תשולם ב-X תשלומים (מקדמה, תשלומים חודשיים בהתאם לפריסה שסיכמת עם הלקוח). מדוע דרך זו? מכיוון שכפרילאנסר, תצטרך במוקדם או במאוחר להתחייב לזמנים ותאריכים מסויימים עבור לקוחות אחרים והדבר האחרון שהם מעוניינים זה בפרילאנסר "מבריז" עבור לקוחות אחרים. אינך מעוניין להגיע למצב שהלקוח שהבטיח "מאות שעות" סיפק לך בחודש מסויים 4 שעות עבודה ומכיוון שהתחייבת לו, לא תוכל להתחייב לאחר ובכך להפסיד עבודות. לכן, קבעו בנק שעות, ותנו ללקוח לשבור את הראש איך להשתמש בבנק השעות, ואתם לא תגיעו למצב של פרנסה מופחתת בגלל הבטחות.
  • עבודות ריטיינר (כמות שעות חודשית שנמכרת ללקוח): הנה משהו שחשבתי שהוא מוכר ומוסכם, אולם להפתעתי התברר לי שלא כך, ולכן אסביר את הדברים החשובים בעבודות ריטיינר:
    • הלקוח קונה X שעות בחודש. ה-X שעות היא כמות מינימום. במידה והפרילאנסר עובד יותר שעות מעבר ל-X, הלקוח צריך לשלם על כמות השעות הנוספת (מומלץ לפרילאנסר להודיע ללקוח לפני סיום ניצול ה-X שעות).
    • חשוב לקבוע על מה תינתן העבודה: במסגרת החוזה, יש לציין על מה תינתן העבודה, על אלו מערכות ואלו אפליקציות. הלקוח רוצה יותר? כנסו למו"מ על מחיר. (יש כמובן פרילאנסרים שתמורת הריטיינר הם יעשו הכל, חוץ מטאטוא המשרד…).
  • שיתופי פעולה: כפרילאנסרים, ככל שתהיו יותר מפורסמים, כך תקבלו יותר ויותר פניות לשיתופי פעולה – בביצוע עבודות, במכירת מוצר או שרות וכו'. אין בכך שום דבר רע כמובן, ומה שמביא הכנסות – מבורך, אבל חשוב לזכור, כמו בעניין ה-Pre Sale: אם מבקשים מכם דברים, גבו על כך תשלום ואל תתנו לאמרות חלקלקות להוציא מכם עבודות בחינם. תזכרו שאתם עדיין צריכים לשלם למדינה מסים, שכ"ד/משכנתא, אוכל וכו' וכו'.
  • עבודות דרך צד ג': בלא מעט מקרים תקבלו הצעות עבודה דרך חברת אינטגרציה אצל לקוח שלה. גם כאן, כמו בבנק שעות, חשוב לבדוק את כמות השעות ולא להאמין להבטחות שיהיו עוד לקוחות ובהתאם לקבוע את מחירכם (החברה כמובן תוסיף מחיר תקורה כלשהי, ולכן חשוב לקבוע מה יהיה מחיר השעה שלכם) – אל תתנו מחיר של 60 שעות בחודש כמו מחיר של 200 שעות בחודש.

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

בהצלחה

וירטואליזציה כקוד פתוח – כפתרון טוב

לפני כשבועיים פרסמתי את הפוסט הזה שמדבר על פתרונות אלטרנטיביים ל-vSphere של VMWare. הפעם אני רוצה לדבר על פתרונות קוד פתוח כפתרונות טובים לוירטואליזציה ומדוע RHV/oVirt הוא פתרון שעולה על רוב פתרונות הקוד הפתוח.

פתרונות וירטואליזציה בקוד פתוח מתחלקים בעצם ל-2: אלו שמעוניינים לנהל מספר קטן של שרתים פיזיים וצרכי הוירטואליזציה שלהם בסיסיים, ואלו שמעוניינים בפתרון וירטואליזציה מלא כולל הדברים המתקדמים, משהו כתחליף ל-Hyper-V (עם הניהול המרכזי) או תחליף ל-ESXI+vCenter.

כשמדובר בצרכים בסיסיים לוירטואליזציה ומדובר בכמות קטנה של שרתים (נניח 2-5), ומדובר, לשם השוואה, בדברים ש-ESXi עצמאי (ללא vCenter) יכול לתת – אז הפתרונות שהצעתי בפוסט הקודם יכולים לתת זאת ללא בעיה. יותר מכך, כל הפתרונות (למעט שימוש ב-KVM וב-libvirt עם סקריפטים) שהצעתי גם יכולים לתת לכם ניהול מרוכז של השרתים שלכם בממשק Web.

לעומת זאת, כשאנחנו מעוניינים בדברים יותר מתקדמים כמו:

  • שימוש ב-vSwitch (בגירסת הקוד הפתוח – Open vSwitch) כ-SDN
  • הקמה אוטומטית של מכונות VM
  • שימוש ב-Grafana לתצוגת מצבי מכונות, דיסקים, מעבדים וכו'
  • High Availability מלא
  • אופטימיזציה לשימוש ב-NVME SSD תוך הגדלת I/O Threads
  • תמיכה מובנית ב-DR
  • יצוא/יבוא OVA/OVF
  • תמיכה במעבדי Power של IBM
  • תמיכה בכל פרוטוקולי הסטורג' (NFS, iSCSI, Fiber) + דיסקים מקומיים ו-GlusterFS
  • תמיכה במעבדים חדשים (EPYC, Xeon SP – ברוב הפתרונות המוצעים זה לא יעבוד טוב, במיוחד כשמדובר ב-HA).
  • ניהול מרוכז של כמות שרתים גדולה (עד 400 מכונות פיזיות)
  • פרופילים (סוגי מכונות, גדלים ועוד) כולל High Performance VMs.
  • תמיכה מורחבת ל-Over Commit
  • יבוא/יצוא של Images מ-OpenStack Glance (לא חייבים OpenStack מותקן בחברה).
  • פורטל למשתמשים (לאלו שצריכים לגשת למספר מכונות VM, ולנהל את אותן מכונות VM)
  • תמיכה במספר סוגי LDAP (כולל AD)
  • התממשקות ל-vCenter ויבוא מכונות VM
  • אפשרות לעבוד במצב הרגיל או במצב HCI.
  • תמיכה מלאה ב-GPU וב-VDI.
  • ועוד הרבה פונקציות אחרות.

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

האם פתרון כמו RHV/oVirt יכול להיות תחליף מלא ל-vSphere? התשובה היא: עדיין לא. העניין קשור יותר ל-Kernel ולדברים מתקדמים אחרים שלא קיימים ב-RHEL-7/CentOS-7 (שעליהם oVirt/RHV רץ):

  • Fault Tolerance עדיין לא זמין בגירסה הנוכחית (4.2)
  • VAAI/VVol – יש תמיכה ב-Kernel 4.X כך שנצטרך להמתין ל-RHEL-8/CentOS-8.
  • תוספים כמו vRealize ואחרים (שהם בתשלום) – יש להם חלופות. חלקם בחינם, חלקם בתשלום.

בכל הקשור לפתרונות וירטואליזציה, הגענו לזמנים טובים, למען האמת. רק לפני 3 שנים אם חברה גדולה היתה שואלת אותי לגבי פתרונות אחרים ל-VMWare או Hyper-V, הייתי ממליץ להם לנהל מו"מ בינם לבין מיקרוסופט ו-VMWare כי הפתרונות לא היו מספיק לדעתי טובים לשום Enterprise. פתרונות כמו Proxmox או פתרונות מבוססי Xen היו קיימים, אך לדעתי הם אינם נותנים מענה מספק ל-Enterprise (אם כי הם היו בהחלט יכולים לתת מענה לעסקים קטנים). בשנים האחרונות, החברה שהשקיעה הכי הרבה בפיתוח פתרון וירטואליזציה טוב היתה דווקא רד-האט. המצב בשוק פשוט התהפך: מיקרוסופט ו-VMWare היו עסוקים בפתרונות וירטואליזציה ואילו רד-האט היו עסוקים בפיתוח פתרונות מבוססי קונטיינרים (OpenShift) וב-3 השנים האחרונות רד-האט משקיעה הרבה יותר בפיתוח פתרון וירטואליזציה וגם בשיפור OpenShift, בשעה שמיקרוסופט ו-VMWare בשנתיים האחרונות יותר מתעסקים בפתרונות קונטיינרים.

לסיכום: שום פתרון (פתוח או סגור) אינו Drop In Replacement. לכל פתרון יש יתרונות וחסרונות וכדאי לשקול את הדברים. בכל מקרה תהיה תקופת מעבר ויהיה צורך לפתור לא מעט בעיות. פתרונות בקוד פתוח לא מחייבים תשלום Up front (למעט במוצר מסחרי כמו RHV, אם כי יש Trial חינמי), אבל כן מחייבים יעוץ, אינטגרציה והדרכה – שזה כן עולה כסף.

תובנות על OpenShift בחברות גדולות

יוצא לי בלא מעט מקרים לתת יעוץ לחברות גדולות לגבי עניין המעבר ל-Devops, שימוש בקונטיינרים, Docker, שימוש ב-Jenkins ושאר כלים. כמובן, כמו תמיד, בחברות גדולות, אף אחד אינו רץ להטמיע טכנולוגיה זו או אחרת רק בגלל שחץ בן חמו (או נציגי Presale של רד-האט, אין לי קשר אליהם) המליץ עליה. יחד עם זאת, בדרך כלל ההמלצה שלי לפני שמרימים אפילו PoC של OpenShift – אני מבקש מהחברה שתתן לי להיות "הטיפש" – להיות עם צוות שינסה את הדברים החדשים ובעצם ללמוד את התהליכים שהצוות משתמש בהם – החל מכתיבת קוד, שימוש ב-SCM, קומפילציה, טסטים, תהליכים נוספים עד לתוצר הסופי (קבצים בינאריים, Artifacts וכו').

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

  1. ניהול קוד (Source Code Management – SCM)
    ברוב המקרים שישבתי לפגישת היכרות ושיחה על המערכות הקיימות, בד"כ מערכת ניהול הקוד היתה TFS של מיקרוסופט או בחלק מהמקרים SVN. מקומות בודדים הכניסו איזו "תת מערכת" של GIT (בשימוש של Gitlab או BitBucket).
    הבעיה: שום מערכת קונטיינרים המבוססת על Kubernetes לא תומכת באופן רשמי לא ב-TFS ולא ב-SVN. כולן תומכות באופן טבעי ב-GIT.
    הפתרונות שיש הם מאוד עקיפים:
    עם TFS יש פתרון די עקיף לבעיה כפי שמוסבר כאן.
    עם SVN הפתרון הוא למשוך את הקוד למכונה מקומית שמחוברת לשרת GIT, ולאחר מכן לבצע Commit, Push לשרת ה-GIT המקומי. זה פתרון די "מכוער" ובעייתי מכיוון שאם מישהו שכח להוריד ולהעלות קוד ל-GIT, ה-Build יהיה בעייתי. אגב, שרת SVN הוא יחסית קל מאוד להמרה ל-GIT, במידה והחברה מעוניינת לעבור ל-GIT.
  2. מכונות Windows ולינוקס ביחד.

    לא מעט חברות גדולות כותבות קוד ל-Windows וסקריפטים ל-Windows (ראיתי גם מקרים של Build ל-JAR/WAR שכתובים ב-Batch file), וכאן ישנה בעיה מהותית – Kuberenetes בעצמו לא רץ בצורה טובה על Windows והפתרון שיגיע בשנה הבאה יאפשר גם ל-Kubernetes וגם ל-OpenShift להשתמש ב-Nodes שהם גם Windows וגם לינוקס (אם כי שרתי ה-Master וה-Infra יצטרכו להיות מבוססי לינוקס).
    עד אז תהיה בעיה לקמפל קוד בצורה יציבה של דברים כמו DOT Net (כדאי לעבור ל-Dot Net Core שנתמך ורץ על לינוקס), ויהיה צורך להמיר קבצי batch ל-shell כדי לקמפל את הדברים על Windows.

  3. בחירת אסטרטגיה ב-OpenShift
    באופן עקרוני, שימוש ב-OpenShift מחייב בחירת אסטרטגיה, ו-OpenShift תומך ב-4 אסטרטגיות פופולריות: Docker, Source to image (S2I), Jenkins Pipeline ו-Custom (שהוא מאוד מתקדם וברוב המקרים לא יהיה בו שימוש אלא במקרים מיוחדים ששאר האסטרטגיות אינן עונות על כך)

    1. אסטרטגיית Docker מאפשרת שימוש ב-Images קיימים מבחוץ (ממקומות כמו Docker Hub לדוגמא) ושניבנו פנימית כחלק מהרמת אפליקציות. יש עם האסטרטגיה הזו 3 בעיות:
      1. רוב ה-Images שתמצאו בחוץ לא יפעלו עם OpenShift כי הם רצים כ-root ו-OpenShift בנוי בראש ובראשונה לאבטחה הדוקה ולכן הוא חוסם מיידית הרצה של Images כאלו (אפשר לבטל זאת אבל אז מישהו יחטוף על כך ממחלקת אבטחת מידע)
      2. בלא מעט מקרים שוחררו Images שמריצים מספר אפליקציות במקביל בתוך אותו Image וזה הורס כל דבר שקשור לגדילה רוחבית (Scaling) ולכן לא מומלץ להשתמש ב-Image כזה.
      3. טכנית, מבחינת אבטחה בקונטיינרים, דברים צריכים לרוץ רק ב-Foreground ולא ב-background ולכן קונטיינרים שיריצו דברים ב-background (שרותים כמו nginx, apache, postfix ועוד ועוד) – הקונטיינר "ימות" לאחר זמן קצר והמערכת תנסה להקים אותו שוב ושוב, מה שיצור loop (במיוחד אם מופעל Replication Controller – RC).
    2. אסטרטגיית Source to image (כלומר S2I): עם אסטרטגיה זו מערכת OpenShift מושכת ImageStream (כלומר Image "שלד"), יוצרת Image חדש שאליו היא "שופכת" את הקוד מ-GIT, מבצעת שינויים שצריך (הרשאות, התקנת קבצים נוספים כמו דרך PHAR ב-PHP או NPM עבור Javascript ועוד ועוד), ולבסוף בונה Image סופי שאותו המערכת מריצה ומקימה POD עם קונטיינר המכיל את ה-Image. באסטרטגיה זו ניתן "לקשור" (דרך Webhook) בין REPO של GIT לבין אפליקצייה ב-OpenShift וברגע שיש שינוי ב-GIT, המערכת תבנה אוטומטית Image חדש וכשתסיים היא תוריד את ה-POD הקיים ותפעיל מיידית את ה-POD עם הקונטיינר החדש (ניתן כמובן לבצע Blue/Green Deployment – פרטים כאן וזה קיים לא רק ברמת אפליקציות אלא גם ברמת מכונות)
    3. אסטרטגיית Jenkins: עם אסטרטגיה זו אנחנו מגדירים הכל מראש: מאיפה הקוד ימשך, מה ה-pipelines וכו' וכו' ו-OpenShift יקים בכל פעם קונטיינר Jenkins, יקמפל, יריץ את ה-pipelines, יפזר מה שצריך לפזר, יבנה Image חדש ויריץ POD עם קונטיינר המבוסס על ה-Image החדש. הדרך הזו יכולה להתאים לאלו שכבר משתמשים ב-Jenkins על לינוקס.

ישנם עוד חלקים הקשורים להקמת מערכת שיש צורך לערב הן את מחלקת אבטחת מידע והן את צוות ה-Storage. בגופים פיננסיים ובטחוניים יהיה צורך לשים דגש על שרתי Registry מקומיים (לחשיפה מופחתת לאינטרנט, אבל עדיין יש צורך לשאוב קבצי Image, בלי זה אי אפשר להקים שום דבר, ואין זה משנה אם מדובר ב-OpenShift או בכל מערכת אחרת מבוססת Kubernetes), שילוב עם Active Directory, הרשאות וכו' (מובנה ב-OpenShift, לא קיים ב-Kubernetes) ועוד דברים רבים.

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