תכירו את rCUDA

כל מי שעובד/מפתח AI, או Deep Learning או מבצע Training למודלים שונים בתחומים הנ"ל, מכיר את העובדה הפשוטה והידועה: אם אתה רוצה ביצועים, אתה חייב GPU טוב באותה מכונה שאתה מריץ עליה את הקוד. לא חשוב כמה חזק השרת שאתה מריץ עליו את הקוד, אם תריץ את הקוד על ה-CPU – הביצועים יהיו גרועים (אינטל חולקת על כך ומציעה את מעבדי ה-Cascade Lake AP לשם כך, רק שהביצועים של אותם מעבדים בלינוקס נכון להרגע – הם לא משהו לרוץ לספר לחבר'ה. יש טלאי שמתקן זאת שיצא לפני מס' ימים, אבל יקח כמה חודשים עד שהפצות הלינוקס יכניסו אותו ל-Kernel שלהם).

מי שמכיר את עניין ה-Training, מודע בוודאי לסיטואציה שגם אם יש לכם שרת מפלצת עם 4,8 או אפילו 10 כרטיסי GPU – אם הוא עמוס מבחינת עבודה על GPU אבל לא עמוס מבחינת CPU – אתה לא יכול "לגייס" מכונות אחרות שיש להן כרטיסי GPU והן לא עמוסות כרגע.

וכאן מגיעה תוכנת rCUDA לסייע.

תוכנת rCUDA מאפשרת לעשות משהו חדש: לבצע הידור או אימון (Training) במכונה מרוחקת (גם כשהקוד נמצא מקומית) עם כרטיס GPU אחד, עם מספר כרטיסי GPU באותה מכונה, או בשיטת ביזור של ניצול מספר מכונות שיש להן כרטיסי GPU. כך לדוגמא אם יש לך קוד על המכונה שלך ויש 4 שרתים כשבכל אחד מהם יש 2 כרטיסי GPU – תוכל להשתמש בכל ארבעת השרתים לבצע את הקימפול/אימון ללא שינויי קוד. אתה כמובן תוכל להריץ את הקוד או את האימון גם אם ישנם דגמים שונים של כרטיסי GPU (כל עוד מדובר בכרטיסים של nVidia מהדורות האחרונים – Pascal ומעלה).

השיטה שבה rCUDA עובדת היא שיטת Client/Server: בכל מכונה שיש בה כרטיסי GPU רץ Daemon שמקבל את הנתונים מהמכונות המרוחקות ומזין אותו אל ה-GPU פנימה והחוצה דרך הרשת, כך שבמקום המצב הרגיל שכל התוכנה נמצאת ב-RAM וקבצי האימון נמצאים על דיסקים מקומיים (לדוגמא) – פה הכל עובר דרך הרשת המקומית וה-Daemon מקבל את המידע דרך הרשת, מזין ל-GPU ומוציא את המידע בחזרה למי ששלח אותו. בצד ה-Client ישנם קבצים בינאריים שדואגים לעניין הקבלה והשליחה, כך שהכל נעשה בצורה שקופה ובד"כ מצריך רק הגדרות של מספר Variables ואפליקציה קטנה ב-Client וב-Server.

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

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

  • בשביל להריץ את כל הדבר הזה, יש צורך ברשת מהירה. כמה מהירה? לפחות Infiniband או תקשורת Ethernet של 50 ג'יגהביט ומעלה. במידה וכל הקוד רץ על ה-GPU בלבד וכל תוכן ה-Training נמצא ב-NFS/iSCSI לדוגמא – יהיה אפשר לדעתי לרדת לתקשורת במהירות 10 ג'יגהביט, אך תקשורת במהירות 1 ג'יגהביט – תזחל.
  • מבחינת הרצת קוד – אפשר להריץ קוד שמשתמש ב-CUDA עד גירסה 9.0 (תמיכה לגירסה 10.1 תהיה בתחילת שנה הבאה) ואפשר להשתמש גם ב-CuDNN, TensorFlow, Caffe וכו'.
  • התוכנה אינה מבוססת קוד פתוח ומה שמקבלים זה קבצים בינאריים בלבד.
  • בשלב זה התוכנה אינה עולה כסף אך יש צורך בהרשמה על מנת לקבל רשיון. בעתיד, יכול להיות שהתוכנה תעלה כסף.
  • שינוי שיטת העבודה (ממקומית ל-רשת) יכול לגרום למצב שתצטרכו שדרוג או רכישת סטורג' על מנת לאחסן את כל ה-DATA, הואיל והכל צריך לעבור דרך הרשת, והעברת DATA ל-Training מתחנת עבודה לשרת זה דבר איטי מאוד.
  • האפליקציה (rCUDA) עם השרותים – רצים רק על לינוקס.

לסיכום: rCUDA יכול לסייע רבות כשרוצים להשתמש במשאבי GPU שונים בצורה מרוכזת, גם כשהם לא נמצאים בשרת פיזי אחד. יחד עם כך, יש צורך להיערך בהתאם ולקחת בחשבון שאין את התמיכה לגירסת CUDA האחרונה ויכול להיות שחלק אחר מהאפליקציות לא יעבדו (כמו שימוש ב-API של הדרייברים של ה-GPU), כך שאם זה מעניין אתכם, מומלץ לעשות PoC לפני שמשקיעים בתשתית.

להלן וידאו עם הדגמה:

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

למי מתאים OpenStack?

"היי חץ, אנחנו שוקלים מעבר מפלטפורמת VMWare למשהו אחר, עדיף יותר זול. האם OpenStack יכול להתאים לנו?"

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

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

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

  • הקמת והגדרת Cluster
  • ביצוע Live Migration למספר מכונות VM בין Clusters
  • ביצוע Live Migration בין 2 Datastores
  • הגדרות Fault Tolerance

איך אתם תבצעו את הדברים?

  • דרך ה-Vcenter web client (הממשק הוובי) או ה-vcenter client שרץ על מכונת Windows
  • דרך PowerShell או דרך סקריפטים שכתבתם בפייתון או בשפה אחרת

התוצאות:

  • אם אתם משתמשים אך ורק בכלי ה-GUI/WEB ש-VMWare מספקת – תרדו מהמחשבה על מעבר ל-OpenStack.
  • אם אתם "פוחדים"/מתעצלים/לא מעוניינים להשתמש ב-API או לכתוב סקריפטים לאוטומציה או שימוש On Demand במקרה הצורך – רדו מ-OpenStack.

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

ברכותיי, חסכתם כמה מאות שקלים של דמי יעוץ 🙂

אחד הדברים שבגינם אני כותב את הפוסט הזה, זו המחשבה המוטעית ש-OpenStack הוא איזה פתרון CSN (כלומר Compute, Storage, Network) שמהווה תחליף ל-VMware. מבחינה טכנית "על הנייר" – הוא מסוגל בהחלט לתת שרותי CSN, אבל לא בשביל זה קונים ומטמיעים את OpenStack, כמו שלא מקימים מערכת Kubernetes בשביל להריץ 2-3 קונטיינרים.

הדברים שצריך להבין לגבי ה-OpenStack ומדוע הוא ה"דארלינג" של כל עסק HyperScale (כלומר עסק גדול שנותן שרותי ענן – כמו רוב חברות התקשורת הגדולות בחו"ל – AT&T, Verizon, SK-Telecom ועוד רבים אחרים) הם דברים מהותיים כמו:

  • OpenStack מאפשר לך להקים שרותים כמו Object ו-Block storage מצד אחד, אבל מצד שני, OpenStack יכול להתחבר בקלות לסטורג' שלך ולקבל את השרותים מהסטורג', וכל יצרני הסטורג' הגדולים (והיקרים) תומכים ב-OpenStack. שלח מייל ליצרן הסטורג' שרכשתם ותקבל בחזרה קובץ PDF או קישור איך לחבר ביניהם, כך ש-OpenStack לא מנסה להתחרות ביצרניות האחרות, אבל מצד שני אם אין לך את המשאבים/תקציב – הוא מאפשר לך להקים פתרון.
    אותו דבר מבחינת שרותי וירטואליזציה – אתה יכול להשתמש בשרותי ה-KVM של OpenStack או לחבר את ה-vSphere אל ה-OpenStack כך שמערכות ESXI יריצו את המכונות הוירטואליות. הנה התיעוד.
  • מבחינת רשתות (סיבה עיקרית שחברות הטלקום אוהבות אותו) ה-NFV (כלומר Network Functions Virtualized) של OpenStack מאפשר להתרחב למימדים מפלצתיים! גם כאן, אפשר או להקים או פשוט לפנות ליצרן ציוד התקשורת שלך שכבר תומך מספר שנים ב-OpenStack (כן, כל הגדולים תומכים).
  • שרותים, שרותים, שרותים: OpenStack התחילה את חייה כמערכת IAAS קלאסית, אבל כיום OpenStack מציעה מאות שרותים שאתה יכול לשלב ל-OpenStack ולתת/למכור את השרותים הללו ללקוחות. הלקוח רוצה שרותי ניהול DNS? אולי DB? להריץ קונטיינרים ב-Kubernetes או OpenShift? ניהול, הקמת והגדרות ברזלים (Provisioning)? שרותי Identity? שרותי Telemetry ועוד? יש, רק תגדיר במערכת ותתחיל להשתמש ולהציע ללקוחות – ולמנמר"ים שכמובן חושבים על תקציבים ותשלומים בראש ובראשונה – אני רוצה להכיר לכם את … CloudKitty.

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

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

ה"חסרון" של OpenStack – הוא שמדובר במערכת שאינה "קליק קליק קליק". כן, יש ממשק Web אך הוא יחסית די בסיסי (במיוחד אם מנסים להשוות אותו לממשקים כמו של VMWare) ורוב העבודה נעשית מול API או binding עם שפות כמו Python. זו מערכת מסובכת, מורכבת, אבל לאחרונה (בגירסת Stein) קיימת תת-מערכת חדשה, AirShip שמאפשרת הקמה והגדרת דברים בצורה קצת יותר קלה – עם YAML (אגב, למי שרוצה לשחק עם Airship על מכונת לינוקס, אפשר להריץ את הפקודות כאן ולהתרשם בעצמכם).

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

קליפים על הקמה/שימוש ב-OpenStack – בקרוב.

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

קצת על אחסון נתונים ונקודות חשובות לפני החלטה

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

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

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

לפני שאמשיך – הערה קטנה: תודות לחברות שונות (CRG, ווסטרן-דיגיטל, סופר-מיקרו ואחרות) השאלתי ציוד כדי להעביד אותו בפרך (Stress Testing) למשך חודש או חודשיים, 24/7 עם תעבורה רציפה מקסימלית (תקשורת/דיסקים, מעבדים, מאווררים, תלוי בטסטים המתבקשים) בהתאם לסטנדרטים של IEEE וארגונים אחרים על מנת לבדוק לחברות וארגונים שונים אם המפרט שהם מבקשים יכול לעמוד בעומסים שונים. כך שהדברים שיכתבו כאן – נוסו.

(בתמונה למעלה: לקוח שרצה לבדוק LACP של 12 פורטים עם תעבורת נתונים של 16 פטהבייט. המבחן עלה לו יותר מסוויצ' 10 ג'יגהביט Low End, אבל – הלקוח דורש ומשלם, אני לא אומר "לא".)

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

הבה נתחיל.

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

  • כמה אחסון נטו אתם צריכים? עזבו חישובים של RAID כזה או אחר, דחיסה, dedup ושאר ירקות. 2 האחרונים הם נחמדים, אך לא תמיד יתנו לכם את מה שאתם מבקשים (זה תלוי בתכנים).
  • כמה לקוחות (clients) הולכים להשתמש בזה? יש הבדל ענק בין אחסון שמשמש לכמה עשרות/מאות מכונות וירטואליות, כמה אלפי משתמשים פיזיים שמשתמשים באחסון כ-File Server או עשרות/מאות אלפי משתמשים דרך האינטרנט.
  • האם החיבור בין האחסון למכונות אחרות ישתמש בתקשורת מהירה? (FC במהירות 8/16 ג'יגהביט, תקשורת 10 ג'יגהביט קואקסיאלית, TwinAX, סיב, Infiniband וכו') והאם אתה צריך ציוד חדש לחבר את הכל ביחד (גם בצד של השרתים, גם מתגים, חיבור לסטורג' עצמו וכו')
  • אחריות, SLA ושאר נושאים פרוצדורליים.
  • והכי חשוב – יחס הקריאה/כתיבה וסוג התוכן.
  • דיסקים SSD שישמשו כ-Cache, שימוש ב-Cache כ-Tiering וכו'.
  • פתרונות של Synology או QNAP.
  • הרחבת אחסון, זכרון.

להלן הנקודות בפירוט:

  • אחסון נטו: נניח ואתה צריך 40 טרהבייט אחסון נטו. אם נשתמש במחשבון הזה תוכלו לראות ש-5 דיסקים של 10 טרהבייט יתנו לנו 40 טרהבייט אחסון נטו עם שרידות של דיסק אחד (כלומר RAID-5). מצד אחד זה יכול "לסגור פינות" שיש לנו כמות אחסון מספקת, וגם שרידות. הבעיה המרכזית: מהירות כתיבת נתונים ושליפתם. אין לנו שום האצה בכתיבת הנתונים, יש לנו האצה בקריאת הנתונים (שזה אידיאלי אולי לארכיבאות לדוגמא). בשביל לקבל האצה פי 4 בכתיבה ופי 8 (בהשוואה לקריאה/כתיבה מדיסק בודד) נצטרך 8 דיסקים של 10 טרהבייט ב-RAID-10. אם אנחנו רוצים מהירות קריאה/כתיבה יותר גבוהה בהרבה (X10 בכתיבה, X20 בקריאה) נצטרך לעבור מדיסקים של 10 טרה לדיסקים של 4 טרה בייט ולרכוש 20 כאלו (תגידו "היי" למארזי 4U). ככל שנבחר דיסקים יותר גדולים, כמות ההאצה שהמערכת תתן – היא יותר קטנה (לדוגמא: 10 דיסקים של 8 טרהבייט יתנו X5 בכתיבה, X10 בקריאה – הדוגמאות הם ב-RAID-10). טעות נפוצה, אגב, היא שימוש ב-RAID-5: הגדרות RAID-5 נותנת אפס האצה בכתיבה לאחסון.
  • לקוחות שהולכים להשתמש בסטורג'. אם מדובר על שרת קבצים לדוגמא, עניין המהירות הוא יחסית די שולי כי כולם משתמשים בתקשורת 1 ג'יגהביט שברוב הזמן מנוצלת חלקית, ואם מישהו יחכה עוד חצי שניה לשמירת קובץ האקסל שלו, השמיים לא יפלו.
    לעומת זאת – מכונות וירטואליות זה סיפור אחר לגמרי. פרוטקול כמו iSCSI הוא פרוטוקול "מפונק" ומערכת כמו VMWare לדוגמא דורשת אישור מהסטורג' על כל קבוצת נתונים שנרשמת, כך שאם אין איזה מנגנון ש"יאמר" ל-VMWare "קיבלתי, מאשר" בכל פעם ובאופן מהיר – המכונות הוירטואליות פשוט יזחלו בכל כתיבה. כיום ברוב פתרונות הסטורג' (סגורים ופתוחים) יש מנגנון שמטפל בכך, אבל אם תרימו מכונת לינוקס עם MDADM ל-RAID, זה לא יתן פתרון (אפשר לעקוף זאת על ידי ביטול ה-sync ב-ZFS לדוגמא, אבל זה מסוכן, במיוחד אם אין UPS למכונה).
    לכן, כשמדובר בסטורג' שיטפל בכל הקשור לאחסון מכונות וירטואליות, חשוב לבדוק שהסטורג' תומך ב-Sync On write, reclaim space, תמיכה ב-VAAI, VVOL ואחרים.
  • חיבור בין הסטורג' למכונות אחרת. הנה נקודה שרבים יתווכחו עליה מתוך איזה נסיון שיש להם, מתוך אמונות, מתוך שמועות, אך כמו שכתבתי למעלה – הנקודות נוסו על ידי הח"מ בתנאי Extreme.
    חיבורי ה-FC היו מעולים לזמנים שהתקשורת נחושת היתה במהירות 1 ג'יגהביט וחיבורי 10 ג'יגהביט היו יקרים מאוד. כיום, לעומת זאת, ישנם 5 אפשרויות פופולריות:

    • CAT6/CAT-6E – חיבורי נחושת של 10 ג'יגהביט, עובדים מעולה ואם רוצים, אפשר לעבוד עם LACP (או Bridge) בצוותים של 2 חיבורים לדוגמא לקבל מהירות יותר גבוהה. היתרון: עלות זולה יותר של כבלים וסוויצ'ים.
    • +SFP עם TwinAx (נקרא גם DAC) – עובד מעולה למרחקים קצרים (עד 5 מטר). חשוב לשים לב שהחיבורים יהיו מאותו מותג של הסוויצ' (בסוויצ'ים 10 ג'יגהביט בקצה הנמוך זה לא רלוונטי, הם מתעלמים מה-Branding Tag).
    • +SFP עם סיבים אופטיים – את זה כולם ימליצו. לא חוכמה 🙂
    • +QSFP – כמו ה-+SFP רק למהירות 40 ג'יגהביט. מדובר בחיבור פיזי גדול יותר כך שהוא אינו תואם אחורה. קיים גם כגירסת DAC/TwinAX וגם כחיבור עצמאי שאליו מחברים סיב אופטי.
  • אחריות, SLA וכו' – כל יצרניות השרתים מוכרות כיום פתרונות סטורג' (ברזלים יעודיים או תוכנה לשימוש בשרתים עצמם) משלהם, אך יחד עם זאת הן גם "מכשירות" (Certified) תוכנות אחרות, ובדרך כלל ביקור באתר יצרן תוכנת הסטורג' יראה את הלוגואים של היצרנים שנתנו "הכשרה" לתוכנת הסטורג', כלומר אם תפנו לתמיכת יצרן השרתים, אף אחד לא יעקם את האף מדוע אתם משתמשים בתוכנת סטורג' X. בחלק מהמקרים (תלוי בחוזה התמיכה) אולי יסייעו לכם עם תוכנת הסטורג' צד ג' או יפנו את בקשת התמיכה ליצרן התוכנה (במקרים בהם יצרן השרתים [כמו HPE] מכר לכם חוזה תמיכה על כל הציוד והתוכנות שברשותכם).
  • SSD, Caching: בכל סטורג' המשלב דיסקים מכניים ודיסקים SSD – המערכת תורכב מ"שכבות" (או במושג המקצועי: Tiering), כאשר השכבה המהירה מורכבת מהדיסקים SSD והשכבה האיטית יותר מדיסקים מכניים (SAS או SATA). ישנם כמובן סוגי סטורג' שונים שבהם יש עוד שכבות כמו מדף זכרון מגובה סוללות, NVRAM, או שכבות של דיסקים מכניים מהירים ובשכבה מתחת דיסקים SATA במהירות 7200 RPM.
    בכל המקרים הללו, ה-SSD נועד "להחביא" את הדברים הקשורים לכתיבה. הוא מקבל את ה-DATA ולאחר מכן ה-DATA מופץ לשכבות היותר איטיות, והוא גם מאחסן נתונים שנקראים תדיר (נניח יש לך 10 מכונות לינוקס, כולן רפליקציות מלאות או משורשרות – רוב הסיכויים שה-DATA יקרא מה-SSD). ה-DATA עצמו לא נכתב ישר אל הדיסקים המכניים, אבל הסטורג' מציג את הדברים כאלו שהנתונים כן נכתבו למכניים, והסטורג' ברקע עושה זאת.
    במערכות יקרות יותר (מילת קסם: AFA או All Flash Array) ישנם גם שכבות אם כי טיפה שונות: רוב הדיסקים הם Read Intense וחלק קטן מהם Write Intense או Mixed Intense ולפעמים יש שימוש ב-NVRAM או בזכרון מגובה סוללה (נדיר). במערכות הסופר-סופר-יקרות, מכניסים גם Optane, גם כרטיסי FPGA ודברים נוספים כדי להאיץ את הכל (ועוברים בדרך לפרוטוקול ה-RDMA הוותיק) – כמו במערכות NVMEoF לדוגמא.
  • פתרונות של Synology או QNAP: אלו פתרונות שאני יכול להמליץ עליהם בלב שלם כפתרונות לשמירה/קריאה של מידע, פחות למכונות וירטואליות (אם כי ל-LAB קטן הם בהחלט יכולים להספיק). כיום בכל QNAP או Synology ניתן להוסיף דיסק SSD לקבלת Cache בסיסי, אבל אל תנסו להכניס לשם SSD מסוג Optane  לדוגמא (כמו שינוי QD) – בשביל זה יש צורך לשנות כמה וכמה דברים בלינוקס ואין במכשירים הללו לא את הספריות ולא את האפשרויות לשנות פרמטרים.
  • הרחבת אחסון, זכרון: בכל מה שקשור לזכרון, רוב הסטורג'ים שמבוססים לינוקס/BSD/סולאריס ו/או ZFS ישתמשו בזכרון כ"מאיץ ראשי" לקבלת הנתונים ולשחרר את צוואר הבקבוק, כך שאם אתם יכולים להשקיע ברכישת RAM – מה טוב.
    לגבי הרחבת האחסון עצמו: בסטורג' סגור הפתרון תמיד יגיע עם "מדפים" לאחסון הדיסקים. בסטורג' פתוח לעומת זאת, חשוב לבדוק שיש חיבור מאחורה המאפשר לחבר JBOD אחד או יותר על מנת להוסיף קופסת JBOD או יותר עם דיסקים ומומלץ לבדוק שהחיבור הוא SAS-3 (נקרא גם HD MINI-SAS או בשמו המקצועי: SFF-8644). לפני שנתיים שוחרר סטנדרט שנקרא SAS-24G אך אני לא ממליץ לרכוש אותו הואיל ודיסקים קשיחים עתידיים (כמו אלו עם 2 מנועים שאמורים לצאת בשנה הקרובה/שנה הבאה) עוברים להשתמש בחיבור NVME. ה-24G פיספס את הרכבת.

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

הטעות הנפוצה לגבי מהירות המעבד

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

התשובה הפשוטה: אתה לא ממש יכול לעשות זאת, לפחות לא מה שאתה חושב שיצא.

ברשותכם, אסביר.

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

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

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

במכונות דסקטופ/תחנות עבודה/שרתי Tower אפשר להשתמש בפתרונות צינון-מעגל-סגור (Closed Loop Cooler או CLC), ששם יש רדיאטור, 2 או 3 מאווררים חזקים, ותעבורת מים שעוברת בצינורות ומגיעה לחלק שנמצא ישירות על המעבד, בין החומר הטרמי על המעבד לחלק שסופג את החום ומצנן את המעבד. שום פתרון שמבוסס על קירור אוויר אינו יעיל כמו CLC או כל פתרון קירור נוזלי.

וכך, לא חשוב איזה שרת 1U או 2U יש לך, גם אם המאווררים פעילים ב-100% ולא חשוב כמה CFM הם יכולים לדחוף, גם האווררים עם 2 מדחפים – הקירור עצמו אינו יעיל מספיק לקרר מעבד כשכל הליבות עמוסות לחלוטין ולפיכך מהירות המעבד תרד. אגב – המספרים בטבלה למעלה שאינטל מפרסמים? יהיה אולי ניתן להגיע אליהם בשרת 3U ומעלה כשהמאווררים מוחלפים ב-CLC. מנסיון.

לכן, אם המעבדים שלך מתוייגים לעבוד עד מהירות מקסימלית של 4 ג'יגהרץ – תזכור שאתה לא תקבל 4 ג'יגהרץ, ולא חשוב מה תגדיר ב-BIOS (בין כה אי אפשר לעשות Overclocking – הכל חסום ב-BIOS ומעבדי Xeon נעולים ל-Overclocking). אם אתה מחפש ביצועים יותר גבוהים לאפליקציות מסוימות, עליך לבצע 2 דברים:

  • לוודא שהאפליקציה שלך רצה ותומכת ב-Multi Threading
  • להצמיד למכונה הוירטואלית שמריצה את האפליקציה – עוד ליבות, עדיף במתודת CPU Pinning
  • הגדרות Governance ב-CPU ל-Performance ועוד.

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