קטגוריה: VMWARE

בניית מכונות VM בצורה יותר טובה

תחום הקונטיינרים קיבל בשנים האחרונות דחיפה רצינית תודות לפתרונות כמו Docker, OpenShift, Kubernetes ומערכות רבות נוספות, ואחד הדברים הראשונים שכל מי שנכנס לעולם הקונטיינרים לומד הוא שקונטיינרים זה דבר זמני – אתה מפעיל, מכבה, וכל התוכן שבקונטיינר עצמו – נעלם, ולכן משתמשים בפונקציות כמו Volume (במערכות כמו Kubernetes יש לנו את PV/PVC) כדי למפות משאב חיצוני (כמו תיקייה במכונה) אל קונטיינר ושם יאוחסן המידע, כך שגם אם הקונטיינר נמחק, ה-DATA נשאר.

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

הדבר שאני מדבר עליו – חלוקה.

נניח ואנחנו צריכים VM שיתן לנו שרות מסוים. נניח SQL, שרת Web, שרת GIT, ועוד ועוד, כל דבר שנותן לנו שרות. ברוב המקרים שאני ראיתי – מקימים VM, מתקינים עליו את מערכת ההפעלה הרצויה ואת האפליקציה שתתן לנו את השרות הרצוי. היכן יאוכסן ה-DATA שאותו אפליקציה תנגיש? בתוך ה-VM. אחרי הכל – תמיד אפשר להגדיל דיסקים וירטואליים, זכרון וכו'.

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

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

איך נמנעים? די פשוט: מתחילים להשתמש בשרותי ה-Network File שקיימים, דוגמאות:

  • אם אנחנו מרימים MySQL או SQL של מיקרוסופט על לינוקס, אפשר למפות את התיקיות DATA שהשרות נזקק להן – למפות ל-NFS Share (אם אתם מריצים SQL של מיקרוסופט על לינוקס עם NFS, ודאו כי מדובר ב-NFS 4.2 וה-mount צריך לכלול את הפרמטר nolock)
  • אם אתם מרימים שרת אפליקציית GIT או שרת WEB – אפשר למפות ל-NFS את התיקיה שה-DATA עצמו (כמו קבצי php,html, גרפיקה וככו') יאוחסן. כל מה שצריך זה פשוט ליצור בסטורג' את ה-NFS Share ולבצע mount שיוגדר בקובץ fstab.
  • ב-Windows נשתמש באותן שיטות, רק עם SMB במקום NFS.

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

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

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

פרויקט נימבוס – מחשוב הענן הממשלתי

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

anan

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

  1. אחד הדברים הבולטים לטובה במסמך הוא התייחסות למחשוב ענן כמו שספקי הענן הציבורי מציגים ומוכרים ולא כל מיני "ענני צעצוע" שכל מיני חברות בארץ מציעות/מוכרות. התנאים עצמם ישר פוסלים את אותם "ענני צעצוע" בכך שיש דרישות שלספקים בארץ אין אותם, הן מבחינת הכנסות והן מבחינת Availability Zones (שמשום מה במסמך הם נקראים "Domains"), מיקומים גיאוגרפים וכו' ואף אחד מהספקים בארץ גם לא מציע 500+ שרותים שונים באותו ענן.
  2. אני שמח לראות שבמשרד האוצר מחפשים שהזוכה יקים בעצם Region אחד ובתוכו Availability Zones אולם לעניות דעתי, חשוב שבמשרד יתעקשו על כך שה-AZ יהיו במרחק רב אחד מהשני.
  3. נקודה שלדעתי חסרה במסמך וחשוב שתצוין (ושהמשרד יעמוד על כך) – שה-AZ יהיה מחובר בחיבורי תקשורת מספקי אינטרנט שונים ולא מספק יחיד. רק לפני חודשים ספורים אלפי אתרים נותקו מהאינטרנט עקב "תקלת תקשורת" של ספק אינטרנט מרכזי. האם משרד האוצר רוצה לחוות חוויה כזו?
  4. אם המתמודדים הם בעצם ספקי הענן הציבורי, מומלץ לבקש לדעתי במסמכי המכרז כי הספק הזוכה ייבא וישתמש בציוד שלהם ולא בציוד COTS. הציוד של ספקי הענן שונה לחלוטין מציוד שחברות רוכשות החל ברמת המעבדים, זכרונות, לוחות, אחסון, תשתיות תקשורת וכו' ויש סיבה טובה לכך – ביצועים הרבה יותר גבוהים.
  5. בבקשה, בבקשה – בלי Azure Stack. כתבתי כאן מדוע לא.
  6. נקודה נוספת שאולי כדאי שמשרד האוצר יחשוב לגביה – שה-AZ יהיו מחוץ ל-Data Centers של ספקי האינטרנט שונים במיקומים כמו הגליל ובאר שבע לדוגמא. בחירה במקומות כאלו יכולה לייצר באופן ישיר מספר מקומות עבודה ובאופן עקיף לאורך זמן – יותר ויותר חברות שיעבדו במקומות אלו.

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

  • מיקרוסופט – Azure
  • אמזון – AWS
  • גוגל – GCP
  • אורקל – Oracle Cloud
  • IBM Cloud

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

יש משהו אחד שקצת לא מסתדר לי עם המכרז והפרויקט עצמו. כן, זה בהחלט דבר טוב שמשרד האוצר עושה צעדים להקים פה Region, אבל הבעיה הגדולה ביותר קשורה לשיטות העבודה והפיתוח במשרדי הממשלה השונים ושוחחתי בעבר עם לא מעט עובדים במשרדים הממשלתיים על כך: צריך לשנות מקצה לקצה את כל מתודות העבודה. להתחיל לעבוד מול GIT, לשלב CI/CD, אוטומציה, להוריד כמה שיותר את העבודה עם מכונות וירטואליות ולהתחיל לעבוד מול קונטיינרים ומול שרות/פלטפורמה כמו Kubernetes/OpenShift, לעבוד במתודה של Scale Out, להשתמש ב-Object Storage, להתחיל לעבוד במתודות Serverless אולי, ועוד ועוד – וכל אלו הם דברים שונים ממה שהמשרדים משתמשים כיום. אם משרד האוצר הולך לשלם על Region עם מספר AZ ושיטות העבודה ישארו השיטות הישנות, אז ניצול ה-Region יהיה אחוזים בודדים בלבד, ובכך יווצר בזבוז כספים משווע (ומה לעשות, לא מדובר פה בתשלום חד פעמי אלא חודשי), ולכן אני תוהה אם משרד האוצר מוכן כבר עכשיו לתכנן מהלך הדרגתי לעבור למתודות העבודה החדשות.

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

האם ה-Nvidia Grid עדיין רלוונטי?

כל מי שמתכנן וכל מי שהתחיל לעבוד עם מכונות וירטואליות בתצורת VDI בוודאי שמע ומכיר את ה-Grid של nvidia. פתרון ה-Grid מבוסס על מספר חלקים כמו ה-GPU, שרת רשיונות וכמובן חלקים נוספים הקשורים לפתרון ה-VDI עצמו בשרת וב-Client.

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

הבעיה קשורה יותר לכסף. בעבר הרחוק היית רוכש את פתרון התוכנה, את כרטיסי ה-GPU, מגדיר את הדברים ומתחיל לתת לעובדים שלך לעבוד, אבל כיום הדברים כרוכים בתשלום חודשי, והדברים מגיעים לכך שבחישובים של תשלום ל-3 שנים לדוגמא, עדיף לרכוש את הפתרונות של AMD המתחרה. שם אין תשלום חודשי והביצועים אינם פוחתים בהשוואה למה ש-nvidia נותנת, כולל פתרונות הדורשים OpenGL או DirectX 11/12 לעבודה, ויש תמיכה מלאה בפרוטוקולי Client של VMWare, של Citrix ושל מיקרוסופט.

אחד הנושאים שעולים לאחרונה בכל הקשור ל-Virtual GPU/Grid ותמיכה – קשור ל-AI ו-Deep learning. יותר ויותר חברות גדולות מגלות פלטפורמות כמו Tensor Flow או Caffe ומעוניינים לרתום את תשתית ה-Grid שלהם לשימוש עם אותם פלטפורמות.

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

אבל מבחינת ביצועים – כל כרטיסי ה-GPU מסידרה K,M,P במשפחת ה-GRID או Tesla או Quadro לא יתנו ביצועים גבוהים, במיוחד אם משתמשים בכרטיסים אלו לצרכי VDI – או אז במקרים כאלו המכונה מקבלת רק חלק קטן מה-GPU והביצועים .. בהתאם. כרטיסי Tesla או Quadro מסידרה V או T הרבה יותר מתאימים ליישומים אלו, אולם אם מדובר בכמות עבודה רצינית שאינה חד פעמית, אני ממליץ לנטוש מערכת GRID ולרכוש שרתים שיכולים להכיל מספר כרטיסי GPU ואז למפות מספר כרטיסים למכונה וירטואלית או מיפוי 1:1 בין GPU למכונה וירטואלית. יש כמובן גם אפשרות לרכוש כרטיסי RTX אולם כרטיסים אלו אינם מתאימים כל כך לשרתים הואיל והאיוורור שלהם הוא מהצד (Blower) ובמקרים רבים השרתים אינם בנויים לאיוורור כרטיסי GPU מהצד אלא מאחור.

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

לסיכום: אם אצלכם בחברה חושבים להשתמש/לפתח בתחומי ה-AI או ה-Deep Learning, כדאי לחשוב על הנקודות שצוינו בפוסט זה. פתרונות ישנים לא תמיד מתאימים ולמרות הפתרונות של Nvidia – היא אינה השחקן היחיד בשוק ואין צורך לוותר על תאימות פלטפורמות כדי לעבוד לכרטיסי GPU אחרים או ל-OpenCL.

כמה מילים על Azure Stack וספקי אינטרנט

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

בישראל החלה חברת Med One להציע שרותים המבוססים על Azure Stack ואני מאמין שהמתחרים בארץ כבר במחשבות או בדרך לרכוש ולהציע את השרותים הללו. חשוב לי להדגיש – הפוסט הזה אינו בא "לקטול" ספק ISP זה או אחר אלא לתת דגש לגבי פתרון Azure Stack (אם יש איזו חברה בארץ שהולכת להכניס את ה-Outposts של אמזון – אשמח אם היא תוכל ליצור עימי קשר).

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

מערכת Azure Stack בנויה לשימוש ב-2 אופנים: Connected ו-Disconnected, כאשר ב-Connected אתם יכולים להעביר את התשתית הוירטואלית/מכונות/קונטיינרים/אחסון לענן האמיתי של Azure ובמצב Disconnected – האינטרנט מנותק, והכל רץ מקומית בארונות של ספק ה-Azure Stack שלכם (או אצלכם מקומית אם רכשתם את המערכת).

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

החסרונות של Azure Stack לעומת היתרונות – גדולים:

  • הסיבה המרכזית שחברות עוברות לענן – זה ה-Scaling שאותו לא מקבלים באותה צורה ובאותו גדול בהשוואה לענן עצמו. כנ"ל לגבי שרידות – לכל ספק ענן ציבורי יש Zones ויש Regions ואפשר להקים שרידות נפלאה. איזו שרידות תקים ב-Azure Stack? בין שרתים שהכל מקומית? אנשים שוכחים בכל פעם את התקלות שיש פה לכל מיני ISP שמשביתות אלפי לקוחות במכה אחת, ובענן ציבורי אפשר לבנות מערכת שגם תעמוד ברעידות אדמה, זה לא כזה מסובך.
  • ביצועים – עם Azure Stack אנחנו חוזרים שוב למודל ה-Enterprise מבחינת ציוד, וזאת בניגוד מוחלט למה שיש בענן ציבורי: באף ענן ציבורי אין שרתי מותג, אין דיסקים Enterprise, אין מתגים של מותג מסוים – הכל בניה "מקומית", החל מרמת המעבד והזכרון וכלה באוורור, ובעברית: מכונת VM שרצה בענן תרוץ יותר לאט על השרתים הקנייניים שמריצים את Azure Stack כי גם המעבד וגם הזכרון שונים (ספקי ענן רוכשים גרסאות Custom של מעבדים וזכרונות הרבה יותר מהירים ממה שיש בשרתים הרגילים).
  • מחירים: בניגוד למצב רגיל שאתה לוקח מספק Hosting כלשהו מכונת VM נניח עם 4 ליבות, 8 ג'יגה זכרון, 40 ג'יגה דיסק ותעבורה של 5 מגהביט והכל כלול במחיר אחד – כאן הכל שונה, אתה משלם על כל פיפס בנפרד. נתראה בחשבונית החודשית (וכן – התכוונתי ל-Azure Stack. מיקרוסופט מכתיבה זאת).
  • שרותים – הבסיסיים נמצאים + עוד כמה שרותים. השאר? עדיין נמצאים רק בענן הציבורי.
  • תאימות API בין ריצה ב-Azure Stack ל-Azure הרגיל – חלקית בלבד. תצטרכו לעשות לא מעט פליק פלאק כדי להעביר דברים מהענן מקומית וההיפך.

מיקרוסופט מנסה כבר שנתיים למכור את ה-Azure Stack ואין לה הרבה הצלחה עם זה. היא גם מוציאה את Azure Stack HCI שמנסה להתחרות בפתרונות מקומיים (vSAN, Nutantix, Simplivity) שהיתרון היחיד שלו – זה אינטגרציה עם Azure. זה יכול להיות מעניין אולי עבור חלק מהחברות, רק שכדאי לקחת בחשבון שלהגדיר את הדברים שם – אתם תתלשו שערות מהראש.

לסיכום: אני לא מוצא ממש יתרונות לשימוש ב-Azure Stack מקומי או אצל ספק ISP. אם אתם צריכים משהו סגור וגדול – תחשבו על Open Stack כי גם עם Azure Stack תצטרכו צוות שלם (שעדיף שידע לינוקס) כדי לתחזק את הדבר הזה, שלא לדבר על כך שאתם תצטרכו לרכוש את הכל מחדש (אין אפשרות להשתמש בציוד קיים), רק שבמקרה של Open Stack אתם יכולים להשתמש בתשתית קיימת והוא גם הרבה יותר זול. אם אתם מחפשים להשתמש בגלל ה-Latency, אז תחשבו לשלב שימוש בשרות CDN וכך יהיה אפשר לנטרל חלק גדול מה-Latency.

מעבדי הדסקטופ החדשים של AMD

ביום ראשון, ה-7/7/2019, חברת AMD תשחרר רשמית את מעבדי הדסקטופ החדשים שלה במשפחת ה-Ryzen 3000. זה יהיה דור שלישי למשפחת ה-Zen (הראשון היה Zen, השני היה +Zen והשלישי Zen 2).

הדור החדש של מעבדי הדסקטופ מבית AMD מציג משהו שונה ומרענן: לראשונה, המעבדים של AMD נותנים ביצועים שאינם נופלים מהמעבדים של המתחרה המובילה, אינטל, לא רק באפליקציות המשתמשות ב-Multi Threaded (דבר ש-AMD ניצחה את אינטל עוד בדור השני בהשוואה למעבדים שאינטל הוציאה באותה תקופה) אלא גם לראשונה ב-Single Threaded, וגם הפעם מבחינת תמחור, AMD מציגה מחירים זולים בהרבה בהשוואה למה שאינטל מבקשים (מה שכמובן גורר כרגע הודעות בחדשות הטכנולוגיות שאינטל הולכת לחתוך את המחירים ב-עד 15%. אינטל כמובן לא מוכרת למשתמש הקצה כך שההנחה בסופו של דבר תגיע אולי ל-3-4%).

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

  • תאימות אחורה: אינטל שוברת תאימות מבחינת תושבת מעבד – על ימין ועל שמאל. רוצה מעבד חדש? קנה בדרך גם לוח חדש. ב-AMD לעומת זאת עדיין עובדים עם תושבת ה-AM4 הידועה, ויש סיכוי גבוה שאם יש לך מערכת AMD עם תושבת AM4 ואתה מעוניין לשדרג למעבד עם 4-8 ליבות, תצטרך פשוט לשדרג BIOS, להחליף מעבד (ואת המאוורר – הוא כלול באריזה), להפעיל את המחשב ולהנות, גם אם המחשב שלך בן 3 שנים. ישנם מעבדים ל-AMD שממש לא מומלץ להריץ על לוחות ישנים (מעבדים עם 12 או 16 ליבות) עקב בעיות VRM, אבל רוב האנשים לא מחפשים לרכוש מעבדים כאלו.
  • מחשבה קדימה: AMD היא הראשונה לתמוך רשמית ב-PCIe 4.0 והלוחות אם החדשים שיצאו באותו תאריך כוללים את התמיכה הזו (ולפיכך מחירי לוחות האם יהיו יותר יקרים מבעבר). שוב, זה לא ממש רלוונטי לאלו שרוכשים מחשבים עבור הרצת משחקים, אבל אם צריך ביצועים יותר גבוהים מבחינת SSD NVME לדוגמא, היא שם. גם מבחינת חיבוריות חיצונית יש תמיכה לסטנדרט האחרון של USB (הכוונה ל-USB 3.1 Gen 2) ללא צורך בשבב נוסף על לוח האם.
  • חסכון בחשמל: ב-AMD עברו לתהליך יצור של 7 ננומטר, מה שמוריד את צריכת החשמל ואכן המעבדים החדשים צורכים פחות – במעבדים בקצה הנמוך, וכך מעבדים זהים מדור קודם של AMD שהצריכו 105 וואט מינימום – יורדים בדור החדש ל-65 וואט.

עם המעבדים החדשים נוצרות הזדמנויות חדשות ליצרני תכנים שמעוניינים בביצועים גבוהים מצד אחד, אך לא מעוניינים להוציא $1600 על מעבד 16 ליבות בקצה הכי גבוה (בהשוואה ל-AMD). מעבד כמו Ryzen 9 3950X יעלה לך .. 750$ (ואם יש לך לוח X470 קודם מהקצה הגבוה, לא תצטרך להחליף אותו, יספיק שדרוג BIOS, כל עוד אינך מבצע Overclocking). במבחנים ש-AMD פרסמה, כל תוכנות העריכה הפופולריות רצות יותר מהר על המעבדים של AMD בהשוואה למתחרים באותה כמות ליבות מבית אינטל.

לסיכום: משפחת ה-Ryzen 3000 עם ארכטיקטורת Zen 2 הם המעבדים הראשונים ש-AMD מוציאה אחרי 3 שנות עבודה על המעבדים הללו. החלק הבא יהיה קשור לשרתים, דור שני של משפחת מעבדי EPYC עם מעבדים הכוללים עד 64 ליבות במחיר זול בהרבה ממה שאינטל מבקשים ואחריו, לקראת סוף השנה, AMD תוציא את "המפלצות" – מעבדי Threadripper שמיועדים ליוצרי תכנים כבדים, תחנות עבודה וכו' ולפי השמועות – יצא גם מעבד Threadripper עם 64 ליבות (אם כי עם 4 ערוצי זכרון, בניגוד לאחיו הגדול EPYC שתומך ב-8 ערוצי זכרון).

כמה מילים על WSL 2

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

מיקרוסופט בשנים האחרונות ביצעה כמה שינויים על מנת לכלול תאימות למערכות אחרות. כך לדוגמא ה-command prompt הישן קיבל מתיחת פנים הן ב-Power Shell ומאוחר יותר גם בתאימות להצגת טרמינלים מרחוק (בחיבור SSH או Telnet). זה לא היה מושלם – אבל זה היה צעד חשוב, במיוחד כשמיקרוסופט החלו לשלב גם SSH Client בתוך Windows 10 לגרסאותיו השונות.

בכנס Build האחרון מיקרוסופט הציגה את ה-Windows Terminal שלה – שיפור משמעותי לעומת ה-CMD הישן והקונסולה של PowerShell. הפעם יש טאבים, תמיכה ב-Emoji, קאסטומיזציה ועוד ועוד. בקצרה זה נראה כך:

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

מכאן נעבור לנושא הפוסט: WSL 2.

למי שאינו מכיר, WSL (ראשי תיבות Windows Subsystem for Linux) זו מערכת שמיקרוסופט פיתחה שמשתלבת עם ה-NT Kernel (כן, Windows 10 מבוסס על NT, כמו רוב גרסאות ה-Windows בשנות ה-2000). המערכת הזו משמשת כ"מתרגם" מה-API של ה-Linux Kernel (גירסה 4.4 של ה-Linux Kernel) ל-NT API. בנוסף, המערכת גם דאגה להרשאות מיוחדות של קבצים ותיקיות כך שלא היה צורך ליצור Partition של לינוקס מצד אחד, ומצד שני קבצים בינאריים של לינוקס לא יכלו לרוץ על Windows שלא מותקנת בה WSL. כל הקונסטרוקציה הזו נועדה לתת מספר דברים:

  • לאפשר לבנות הפצות לינוקס ידועות שירוצו ישירות עם ה-WSL ללא צורך במערכת לינוקס ב-VM
  • לאפשר להריץ אפליקציות לינוקס בהתאם להעדפות שלכם.
  • אין צורך בלשלב קוד GPL כמו ה-Kernel לתוך המערכת.

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

מיקרוסופט היו בהחלט מודעים לעניין, והם הבינו שהטריקים של המרה ל-NT-API לא ממש יעזרו. דרוש פתרון אחר ועדיף פתרון "טבעי".

התוצאה: WSL 2.

השינוי המהותי עם WSL 2 שהפעם יש מעין "מיני VM" קטן שעושה Boot ומטעין גירסה מאוד מקוצרת של ה-Kernel, אך ללא ה-1001 דרייברים שמגיעים עם ה-Linux Kernel וכל הדרייברים הנחוצים שלינוקס צריך – הוא מקבל אותם דרך דרייברים Paravirtualized (קצת מזכיר את ה-VMWare Tools שמתקינים). כך, מצד אחד ה-Kernel רץ בצורה מבודדת כ-VM קטנטן, ומצד שני מיקרוסופט לא צריכה להסתבך עם ה-GPL: הם ישחררו את שינויי הקוד שהם צריכים לשחרר ואין נגיעה ישירה לקוד של Windows.

בשיטה הזו, ה-WSL 2 מקבל מספר דברים:

  • אפשרות להשתמש בגירסת Kernel מודרנית (אני מאמין שמיקרוסופט תוציא מסמך איך לקמפל קרנלים משלך לשימוש ב-WSL 2)
  • אפשר להשתמש בדברים כמו cgroups, להריץ קונטיינרים (docker, cri-o וכו')
  • כל גישת ה-File/Directory תעבור דרך דרייבר שמיקרוסופט תשחרר ש"ידבר" עם NTFS, ומיקרוסופט טוענים כי בדיקות שלהם מראות כי הביצועים משתפרים פי 20 בהשוואה ל-WSL 1.
  • יותר אפליקציות יוכלו לרוץ.

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

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

אחסון: כמה שווה השקט שלכם?

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

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

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

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

  • 2-3 שיחות טלפון לשאול שאלות תמיכה
  • 1-2 דיסקים תקולים להחליף.

וזהו.. (כל הדברים הם כמובן בממוצע).

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

ואז מגיעה השאלה הקשה: לבלוע את הגלולה ולשלם על הארכת האחריות או להתחיל לחפש סטורג' אחר?

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

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

  • הציוד שמתקלקל בדרך כלל בסטורג' הוא – דיסקים, בין אם מכניים או SSD, ולכן אני ממליץ לרכושחומרה-כמה-שווה-השקט-שלכם מהיצרן (או מחברות צד ג' כמו אולטרייד ואחרים) 2-3 דיסקים מכניים ו-SSD, מה שיש לכם בסטורג' – שישבו בארון. זו התקלה הכי שכיחה בסטורג' ובמקרה וילך לכם דיסק, יקח כמה דקות לטפל בתקלה בלי לשלם לאף אחד.
  • חפשו חברות צד ג' שנותנות שרות לסטורג' שלכם. אני חושב ש-We Ankor מספקת אבל אני לא בטוח לאיזה ציוד היא מספקת שרות ואם היא מספקת שרות כשלציוד תמה האחריות. אתם מוזמנים לשאול בפורומים בפייסבוק, חברים וכו' (לי אין קשר ישיר, אבל אם יש חברות שמוכרות שרותי תחזוקה/תמיכה לציודים כאלו – שלחו לי מייל, בהזדמנות אפרסם או אפנה אליכם אם יתקבלו פניות). מכיוון שאתם לא הולכים להשבית את הסטורג' שלכם מחר בבוקר, דברו עם צד ג' על אחריות לשנה פלוס.
  • תתחילו להוציא "קול קורא"/מכרז לרכישת סטורג' בין החברות השונות. הנה פוסט שכתבתי לפני זמן קצר על נקודות עקרוניות וכמובן אל תשכחו את עניין ה-IOPS.
  • סטורג' מבוסס מוצר קוד פתוח? בניגוד למה שהרבה חושבים, אין שום קשר בין אם החברה משתמשת במוצרי קוד פתוח לבין שימוש בסטורג' מבוסס קוד פתוח (אגב, כשאתם עושים קניות ומשלמים ב-PayPal לדוגמא – רוב התשתית שדרכה עוברים פרטיכם – היא בקוד פתוח). כשאני ממליץ על פתרון כזה, אני ממליץ על פתרון שיש לו "אבא ואמא" מצד החברה המוכרת ונותנת תמיכה כמו SuSE ישראל, כך שיש תמיכה מסביב לשעון אם יש בעיה, בדיוק כמו בסטורג' קנייני. ההבדלים הגדולים: מחיר הרבה יותר זול וחופש לבחור על איזה ציוד זה ירוץ. אני לא אתקין ללקוח לדוגמא מערכת Ceph שמשכתי מ-GitHub (למעט אם זה PoC וגם אז, בדרך כלל אני אתקין גירסת Trial מסחרית). אגב, בקרוב אעלה וידאו הדגמה של המוצר.
  • לא חשוב איזה סטורג' קנייני תרצו לרכוש – אם אתם רוצים IOPS גבוה, שרידות רצינית וכמות אחסון גבוהה (50 טרה ומעלה נטו) – המחיר הולך להיות גבוה, במקרים רבים יותר ממה שאתם חושבים בהתחלה. במקרים שאתם מקבלים הצעות מחיר והם מאוד רחוקים מהתקציב שחשבתם להשקיע – יהיה כדאי לחשוב על "Offload" של הדברים, כך שרק הדברים שחייבים מצב "פרודקשן" ישבו על הסטורג' החדש והשאר ירוץ על הסטורג' הישן או להקים סטורג' מבוסס קוד פתוח כסטורג' משני או שלישוני. כל סטורג' רציני שעולה עשרות אלפי דולרים ניתן להרחבה גם ל-100 טרה ומעלה בלי בעיה.
  • בקשו הצעות מחיר שכוללות 5 שנות אחריות או 7 שנים (כמדומני שכל הגדולים מציעים גם 7 שנים) מראש. כמו שציינתי, רכישת הארכת אחריות בנפרד היא דבר מאוד יקר ואת המחיר הזול אפשר להשיג בעת הרכישה, לא לאחר מכן.

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

אחסון Scale Out בקוד פתוח – פוסט עדכון

כתבתי בעבר לגבי Ceph ולגבי GlusterFS. בפוסט זה אנסה לענות לשאלה שחוזרת מדי פעם אצלי באימייל: במי מהם לבחור אם הולכים על Scale Out Storage?

בשביל לענות, נתחיל מההתחלה הפשוטה: רוב הארגונים רוכשים לעצמם סטורג' קנייני כלשהו שעובד בשיטת ה-Scale Up: רוצה יותר אחסון? תוסיף מדפי דיסקים, SSD, Cache וכו' וכו'. ברוב הארגונים לעומת זאת, כשחושבים לדוגמא על Cluster Storage במובן של 2-3 מכונות סטורג' נפרדות שמסונכרנות ביניהם – המחיר של הפתרון הקנייני מרתיע ואז מתחילים להישלח אימיילים ולחייג ליועצים שונים.

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

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

מבחינת תחרות, יש 2 פתרונות, וכל אחד מהם מיועד לשוק ולצרכים מסויימים. אף אחד מהם לא הולך "לסגור את הבאסטה" בקרוב. 2 הפתרונות הם Ceph מול GlusterFS. את Ceph אפשר לרכוש מ-Red Hat ו-SuSE, ואת Gluster מ-Red Hat (את שתיהם כמובן אפשר להוריד בחינם, אבל אני לא ממליץ במערכות פרודקשן קריטיות להריץ את הגרסאות קוד פתוח).

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

  • משרד האוצר פונה אליי בבקשה להקים SDS בגודל 4 פטהבייט שיאכסן ארכיב של מידע ישן: הודעות לעיתונות, גיבויים, מסמכי הצעות שונות ותוכן נוסף שכולו מורכב מקבצי אופיס ופורמטים אחרים. הגישה אל האחסון למשתמשים תהיה דרך SMB/CIFS בלבד עם הרשאות AD. אין גישת Web או שום דבר אחר. אחסון קבצים קלאסי.
    ההצעה שלי אליהם: GlusterFS.
    מדוע? GlusterFS מיועד לתת גישה לקבצים בלבד, בין אם דרך NFS או SMB/CIFS. קל להרחיב אותו (מוסיפים עוד ברזלים עם דיסקים, מחברים לסוויצ', מתקינים מערכת הפעלה, מריצים כמה סקריטפים ותוך שעות ספורות יש עוד כמה מאות טרהבייט זמינים) והרבה יותר קל לנהל אותו בהשוואה ל-Ceph.
  • ערוץ "כאן" פונה בבקשה להקים SDS בגודל 20 פטהבייט. בסטורג' הזה יאוחסן כל הסרטים, הסדרות, החדשות וכל מה שצולם עוד מימי הערוץ הראשון והטלויזיה החינוכית – והכל יהיה זמין דרך פורטל VOD לגולשים בארץ דרך נגן HTML5 יעודי והוידאו יוגש בזרימה או להורדה לתצוגה ב-Offline.
    ההצעה שלי אליהם: Ceph.
    מדוע? במערכת Ceph כל דבר שמאוחסן – מאוחסן כאובייקטים שבתוכם יאוחסנו הנתונים בפורמט שאנחנו רוצים. במקרה של "כאן" לדוגמא – כל קבצי הוידאו יאוחסנו כ-Object Storage וכל קליפ מקבל זיהוי יעודי משלו, מה שעוזר מאוד בגישה מהירה לקליפ ולהתחלת השידור שלו. כך, אגב, רוב חברות המדיה מאחסנות באמזון את קבצי הוידאו שלהם (ב-S3 ולא תחת File system עם איזה סטורג' כלשהו). ל-Ceph יש יתרון של Seek מהיר מאוד, והעברת מידע מהירה.
  • משרד הבטחון מקים מרכז מיחשוב חדש לאחד מהחילות. במרכז יהיו 200 שרתים פיזיים שיריצו וירטואליזציה כלשהי (נניח OpenStack או VMware) ומערכת Kubernetes או OpenShift. במשרד מעוניינים ב-SDS בגודל 30 פטהבייט עם אופציה לגדילה מהירה.
    ההצעה שלי אליהם: Ceph
    מדוע? כי Ceph יכול לאפשר ליצור Block Devices וירטואליים וגישת קבצים קלאסית (File System – CephFS) עם שרידות גבוהה. אם לדוגמא הם ישתמשו ב-OpenStack, הם יכולים ליצור דרך Ceph דבר שנקרא RBD (כלומר Raw Block Devices) ואם הם משתמשים ב-VMware – הם יכולים לקבל iSCSI כמו שהם רגילים אליו, ואם הם מעוניינים ב-NFS – אפשר ליצור ולייצא את זה מ-Ceph דרך ה-CephFS ואפשרי לתת להם גם שרותי PV ל-Kubernetes לדוגמא.
  • חברת "שופרסל" מעוניינת ב-SDS  בגודל 5 פטהבייט שיאכסן גיבויים, קבצים וכו'. הם מעוניינים שבחוות שרתים אחרת ישב SDS זהה עם סינכרון מתמשך בין ה-2.
    ההצעה שלי: GlusterFS
    מדוע? מכיוון שגם כאן מדובר בקבצים בלבד בשיטה המסורתית ו-GlusterFS כולל  בתוכו פונקציות לסינכרון מתמשך בתנאי תקשורת שונים מבלי להעמיס על התקשורת או להאיט את שרותי ה-File Server.

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

נסכם את היתרונות והחסרונות של כל מערכת SDS:

  • ל-Ceph יש יתרון גדול בכך שזו מערכת רצינית לתת לך כל סוג של פורמט נתונים שאתה רוצה, בין אם מדובר ב-File Server קלאסי, Block Device, Object Storage ועוד. למערכת יש שרידות מצוינת (כך שאם נופל שרת Ceph – המערכת ממשיכה לעבוד כרגיל). ב-Ceph יש תמיכה ל-tiering, דחיסה, Dedup וכל הדברים שמוצאים ב-Scale Up.
  • ל-GlusterFS יש יתרון בכך שהיא מיועדת בדיוק לדברים הקלאסים של File Server (דרך CIFS/NFS) ותו לא. אפשר להקים אותה על ברזלים ישנים, היא תומכת גם ב-RAID חומרה או RAID תוכנה, היא לא דורשת המון משאבים (מבחינת CPU/זכרון) וממש לא אכפת לה מה ה-File System מתחתיה. ל-GlusterFS יש Load Balancing מובנה, כך שאם יש צורך ב-File Server שישרת מאות משתמשים ובגדלים של עשרות או מאות טרהבייט ומעלה – GlusterFS היא בחירה טובה ויחסית קלה יותר ללימוד בהשוואה ל-Ceph.

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

כמה מילים על SR-IOV

אם נסתכל היום כמעט בכל חברה שמשתמשת בפתרונות וירטואליזציה (לא חשוב אם זה vSphere, Hyper-V, XenServer או אחרים) – בד"כ הפתרון רץ כך:

  • יש סטורג' שמאחסן את ה-Datastore (יכול להיות סטורג' חיצוני, יכול להיות דיסקים מקומיים עם RAID-חומרה בתצורה כלשהי)
  • חיבורי רשת – או חיבור של 10 ג'יגה או חיבור של מס' פורטים 1 ג'יגה (בנפרד, ב-Teaming/Bonding)
  • מעבד יחיד או זוג Xeon פר מכונה
  • זכרון

ברוב מוחץ של אותם מקרים, כל ה"ציוד" בכל מכונה וירטואלית – הוא ציוד Paravirtualized, כלומר זהו ציוד "מדומה" חלקית, כאשר מאחורי הקלעים יש ציוד אמיתי שעושה את העבודה. כך לדוגמא אם אתם משתמשים בכרטיס רשת ב-vSphere, סביר להניח שאתם משתמשים ב-VMXNET3, זהו ציוד Paravirtualized שבעצם מתממשק לחלק ה-Network של ESXI (ה-VMKERNEL) ומשם הוא מתחבר לציוד הפיזי ופאקטים יוצאים ונכנסים. אם נשתמש לעומת זאת ב-E1000 (או e1000e שקיים בפתרונות וירטואליזציה אחרים כמו RHV/KVM) – כאן מדובר באמולציה מלאה של כרטיס הרשת של אינטל והאמולציה מדמה את הכרטיס (כמעט) אחד לאחד ובסופו של דבר מעבירה את הנתונים מ/אל ה-STACK רשת של פתרון הוירטואליזציה. אותו דבר קורה עם דיסקים, תצוגה וכו' וכו'.

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

SR-IOV (ר"ת של Single Root Input Output Virtualization) היא טכנולוגיה שפותחה ע"י הקבוצה שאחראית על פיתוח PCI, PCIe ועוד (PCI-SIG) ומטרת הטכנולוגיה הזו היא לפתח כרטיסים שמיועדים לשימוש בפתרונות וירטואליזציה.

כרטיס PCIe רגיל, בדרך כלל מיועד לפעילות אחת ולמערכת אחת. קחו לדוגמא כרטיס RAID או HBA, הוא מיועד לשבת ולתת שרותים למערכת אחת שרצה בשרת. אם לדוגמא אתם משתמשים בוירטואליזציה על אותו שרת, ה-OS (ה-ESXI לדוגמא) "יחטוף" את הכרטיס לשימושו האישי, ואתם לא תוכלו להשתמש בכרטיס ה-RAID ישירות במכונה וירטואלית. אנחנו כאן יכולים "לבדל" את כרטיס ה-RAID (כלומר Exclude) מה-ESXI אם לדוגמא נבצע Boot מ-USB או כרטיס SD ונגדיר ב-ESXI לעשות "Passthrough" לכרטיס ה-RAID לפי מספר ה-PCI ID שלו (כפי שניתן לראות כאן) ולאחר ביצוע Reboot לשרת, נוכל לבצע "מיפוי" של כרטיס ה-RAID למכונה וירטואלית אחת. למיפוי הזה יש מגבלות: אנחנו חייבים לתת מראש את כל משאבי הזכרון שאנחנו מגדירים ב-VM, לא ניתן לבצע Live Migration וכמובן – יש כרטיסים שלא ממש "מחבבים" את הרעיון של PCI Passthrough כמו כרטיסי GTX של nVidia (אם כי יש גם לכך פתרון).

עם SR-IOV הדברים שונים.

בכרטיסים המכילים פונקציונאליות SR-IOV (הכרטיסים האלו יכולים לתת את הפעילות הזו רק עם מעבדי Xeon E5 v3 ומעלה ומעבדי AMD EPYC), ישנם 2 חלקים חשובים: PF ו-VF.

ה-PF (כלומר Physical Function) מייצג פונקציונאליות פיזית שהכרטיס יכול לתת ואותה ניתן להגדיר. אם ניקח לדוגמא כרטיסים כמו GRID או Tesla של nVidia, אנחנו יכולים להגדיר כמה זכרון תצוגה יהיה לכל vGPU. מכיוון שיש לנו יכולת להכניס כמה כרטיסים בשרת אחד, יהיו לנו בעצם מספר PF, ואותם נוכל להגדיר כבודדים או כקבוצה עם הפרמטרים הרלוונטיים.

ה-VF הוא בעצם מעין "תת כרטיס PCIe" וירטואלי (Virtual Function) שאותו אי אפשר להגדיר (זהו בעצם "כרטיס טיפש") שאת הפונקציונאליות שלו מממש הכרטיס הפיזי. ברגע שהגדרנו את ה-PF בוירטואליזציה (לכל כרטיס יש כלים והגדרות אבל כולם משתמשים ב-PF, ו-VF), במערכת "יצוצו" כמות של כרטיסים וירטואליים חדשים שנראים כמו כרטיסי PCIe רגילים, ואותם אנחנו ממפים פר VM. ברגע שמיפינו והפעלנו את ה-VM, נצטרך להתקין את הדרייברים היעודיים לאותו כרטיס (במקרה של nVIdia ו-AMD – הדרייברים של ה-vGPU, לא לבלבל בין אלו לבין הדרייברים לוירטואליזציה) ואז נוכל להשתמש בפונקציונאליות החדשה.

בתחום ה-Network, כל יצרני כרטיסי הרשת (אינטל, Mellanox, Solarflare, ואחרים) נותנים פונקציונאליות SR-IOV בכרטיסים שלהם. אם לדוגמא אתם משתמשים בכרטיסי רשת של אינטל, אתם יכולים להסתכל ברשימה הזו ולראות אם יש תמיכת SR-IOV. חשוב לזכור: גם אם כתוב שיש תמיכת SR-IOV, במקרה של אינטל אין תמיכת SR-IOV בכרטיסים עם חיבורי 1 ג'יגהביט, או FCoE ו-SR-IOV.

עד כמה הביצועים שונים בין VNXNET3 ל-SR-IOV של כרטיס רשת? להלן גרף לדוגמא:

הגרף הוא מתוך מסמך  ש-VMWare שחררה בכתובת: http://delivery.acm.org/10.1145/2900000/2892256/p65-xu.pdf

עם כל הדברים הטובים שיש ל-SR-IOV להציע, יש גם כמה מגבלות:

  • נכון להרגע, ב-ESXI אין אפשרות לבצע Live Migration למכונה עם כרטיס וירטואלי ממופה (שזה קצת מוזר, בהתחשב בכך שבלינוקס עם KVM זה דווקא כן אפשרי).
  • אם אתם רוצים "לפוצץ" את המכונה בכרטיסים שיש להם יכולת SR-IOV, תוודאו שלמעבדים יש הרבה ליבות או שתרכשו שרתים עם EPYC, אחרת – תכירו את התקלה הזו. תזכרו שכל VF דורש Interrupt משל עצמו.
  • בחלק מהשרתים תצטרכו לעבור למצב Performance בשביל שפעילות SR-IOV תהיה פעילה (ניסיתי על Dell R740).
  • הגדרתם ל-VM כ-16 ג'יגהבייט זכרון וה-VM משתמש ב-2? הלכו ה-14 ג'יגהבייט זכרון הנוספים (יש להגדיר מראש במכונה להשתמש בכל הזכרון שמוגדר אחרת ה-VF מייצר תקלות), כך שיכול להיות ויהיה צורך לחשב מחדש את כמות מכונות ה-VM פר שרת. כמו כן, משחקי/הגדרות Balooning לא מומלצים על מכונות VM כאלו.

לסיכום: SR-IOV זו טכנולוגיה מעולה כשמעוניינים בביצועים גבוהים של פונקציונאליות מסויימת כמו רשת, GPU ועוד. אם יש לכם שרתים מה-4-5 שנים האחרונות (ויש בהם מעבדי Xeon V3 ומעלה) תצטרכו להפעיל ב-BIOS את ה-SR-IOV ותוכלו להנות מהפונקציונאליות המשופרת ומביצועים גבוהים. יחד עם זאת, ישנם מגבלות שחייבים לקחת מראש, כך שלא מומלץ מחר בבוקר להעביר את כל ל-SR-IOV.

בואו נדבר קצת על IOPS

IOPS, או Input Output operations Per Second – הוא אחד המושגים הכי ערמומיים שנכנסו לשוק הדיסקים והסטורג'. אם אינני טועה, מי שהתחיל עם העניין היתה חברת Sun עם ה-ZFS ששולב ב-Solaris 10. באותו זמן, החלו לצאת ה-SSD הראשונים (קטנים מבחינת כמות אחסון, ויקרים רצח).

עניין ה-IOPS בדיסקים SSD וגם בסטורג' המתהדרים ב-IOPS גבוה – זה שלא תמיד מקבלים מה שהובטח.

לשם כתיבת פוסט זה השתמשתי ב-SSD בתצורת M.2 NVME מסוג Samsung 960 EVO בגודל חצי טרהבייט על מנת לבדוק את הדברים בטרם אני כותב את הפוסט הזה ועל מנת להיות בטוח. הכלים שהשתמשתי במהלך הבדיקות לשם כתיבת פוסט זה: FIO ו-IOMeter.

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

על הנייר, ה-SSD הזה אמור לתת ביצועים מעולים! 330,000 IOPS בכתיבה בבלוגים של 4K כשיש 4 עבודות במקביל! נשמע פנטסטי, לא?

אז זהו. שלא. בעזרת שימוש בכלים כמו אלו שציינתי לעיל – אפשר להגיע למספר שציינתי לעיל (למען האמת, קצת יותר – 349,400 לפי הניסוי שלי). העניין הוא, שברגע שכשמייצרים Partition עם גודלי בלוקים שונים (ולא חשוב מה גודל הבלוקים, גם אם אתה מגדיר נכונה את הבלוקים ביחס לקבצים שאתה הולך לאחסן) ומפרמט ל-File system כלשהו ותנסה למדוד עם פרמטר direct=1 עם FIO לדוגמא, תגלה שמספר ה-IOPS צלל בערך במחצית! כלומר אם ננסה לגשת ישירות ולמדוד עם direct על ה-file system שב-SSD – המספרים יהיו הרבה יותר נמוכים. כמובן שאם נשתמש ב-SSD דרך מערכת ההפעלה ללא גישת Direct, המהירות תהיה גבוהה יותר, וזאת מכיוון שמערכת ההפעלה משתמשת בכל מיני דברים כמו Cache, Scheduling וכו' כדי להציג מהירות גבוהה (במיוחד שדברים נעשים ברקע ולא ישירות).

ה-IOPS עצמו נמדד בקטגוריות שונות כמו קריאה אקראית (Random Read), כתיבה אקראית (Random Write), קריאה טורית/רציפה (Sequential Read), כתיבה טורית/רציפה (Sequential Write). את מספר ה-IOPS מכפילים בגודל הנתונים שעוברים פר שניה והתוצאה היא כמה Bytes לשניה מקבלים (את זה נהוג בתוך כלל לחלק למגהבייט לשניה).

נחזור לטבלה של סמסונג המוצגת למעלה. אחד הנתונים שמופיעים שוב ושוב בסוגריים הוא QD, כלומר Queue Depth. בעקרון מדובר בעצם על מנגנון של "תורים", כאשר בכל תור נכנסים משימות לביצוע. ככל שיש יותר תורים לדיסק, כך ניתן לעשות יותר פעולות. בדיסק SSD בחיבור SATA למשל, ישנם 31 תורים. ב-SSD NVME לעומת זאת, עניין התורים הורחב משמעותית ושם יש 65,000 תורים ובכל תור יכולים להיכנס 65,000 עבודות! המספר הזה הוא כמובן רק תיאורתי, ולא מומלץ לנסות להגדיר את ה-Queue Depth מעבר ל-128 (אלא אם אתם ממש עשירים ואתם רוצים לרכוש SSD כמו Samsung 983 ZET, עניין של 2000$ לחצי טרה, ולמעט מקרים מיוחדים, הוא לא יתאים לרוב השימושים. כרטיס זה יודע לתת ביצועים טובים יותר ב-QD של 128 ומעלה).

עוד נקודה שמופיעה בטבלה היא Thread – ו-Thread בעצם מדבר על כמות עבודות במקביל לאותו SSD ולפי הטבלה של סמסונג, המספרים המוצגים הם כשרצים 4 עבודות, וזו אחת הנקודות שכדאי להתמקד עליה: SSD NVME – בין אם ביתי/מקצועי או ל-Enterprise יתן עבודה יותר מהירה כשיש מספר עבודות במקביל. יחד עם זאת, תריצו 100 עבודות כתיבה על הדיסק במקביל ותקבלו SSD זוחל, לא חשוב איזה דגם או מאיזה יצרן.

עוד נקודה שאמנם לא מופיעה בטבלה אך היא חשובה מאוד לביצועים – היא המתזמן במערכת ההפעלה (ה-Scheduler) לאותו ציוד. בלינוקס יש מספק Schedulers וכיום הפצת לינוקס עדכנית מזהה את הדיסק (מכני או SSD, חיבור SATA או NVME) ומתאימה אוטומטית את ה-Scheduler המתאים לדיסק (אפשר כמובן לשנות אם רוצים). ה-Scheduler חשוב מאוד ובחירה שגויה תפגע גם בביצועי ה-IOPS. חשוב לזכור: גם לבקר הדיסקים, ל-HBA וכו' יש הגדרות Queue Depth ואם אתם משתמשים ב-VMWare אתם יכולים לקרוא על כך בהרחבה כאן.

עניין ה-Block Size הוא גם דבר שיכול להשפיע על ה-IOPS, אבל בעקיפין. אם לדוגמא הגדרתי Dataset ב-ZFS בגודל 128 קילובייט ואני כותב קבצים בגודל 2-4 קילובייט, אז לא רק שאני מבזבז מקום, גם הביצועים ירדו. מצד שני, בחלק מהסטורג'ים זה לא כל כך ישפיע בגלל ה-Cache שיש בסטורג' עצמו, כך שזה נושא נתון לויכוח ובכל מקרה מומלץ לחשוב היטב לאיזה גודל בלוקים להגדיר את ה-Volume/Partition/Dataset ובמקרה של ZFS תמיד ניתן לשנות מבלי להרוס דברים.

מכאן נעבור לסטורג', החלק שרבים מתעניינים בו 🙂

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

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

  • הגדרות לא נכונות של מערכת ההפעלה ב-VM עם כמות זכרון מופחתת, מה שיכריח את ה-OS להשתמש ב-Swap. ה-Swap יושב ב.. סטורג'.
  • הגדרות Scheduling ב-VM עצמו.
  • העתקה/מיגרציה של קבצים רבים מסטורג' אחר
  • רפליקציות LIVE מתמשכות
  • פעילות שנעשית דרך VAAI (ה-VAAI או VVOL אינם הוקוס פוקוס, להזכירכם).
  • גיבויים (כן, גם ל-CBT יש מחיר, תלוי כמה מכונות VM מגבים)
  • הגדרות בלוקים לא נכונות ב-Volume/Partition.
  • כתיבות של טרהבייטים
  • ועוד ועוד..

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

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

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