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

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

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

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

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

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

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

יותר ליבות בפחות כסף

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

וכך יצא מצב שרוב החברות בארץ קונות שרתים כשכמות הליבות הרצויה מבחינתם – מחולקת ל-2. רוצים 16 ליבות? שלמו על 2 מעבדים של 8 ליבות, לדוגמא. אינטל הרוויחה מזה יפה מאוד.

ואז AMD הוציאה את EPYC עם הצעה מאוד מפתה (שרבים לא מודעים לה): קנה שרתים מהיצרנים מוכרים עם המעבדים שלנו, ותחסוך 40-60% בהשוואה למעבד עם כמות זהה של ליבות – של אינטל. אבל כאן זה לא נגמר: AMD הוציאה במקביל משפחה נוספת של מעבדים לשרתים עם האות P – ועם מעבדים אלו אתה משלם מחצית בהשוואה למעבד זהה ללא האות P.

אז אם לדוגמא אתם רוצים לרכוש מעבד Xeon Scalable 8180 עם 28 ליבות (מחיר – $17600 בשוק), מעבד EPYC 7551P עם 32 ליבות – עולה 2232$. אמרתי רבע מחיר? זה יותר כמו תשיעית מהמחיר. המחירים כמובן שונים כשקונים את השרת עם כל החלקים כבר מורכבים מיצרן השרתים המועדף עליכם, אבל עדיין – יש הבדל ניכר במחיר גם שם.

ההבדל בין השתיים? מעבד עם האות P יכול לעבוד כמעבד יחיד בלבד, גם אם תכניס אותו ללוח אם עם 2 תושבות למעבדים. בניגוד לאינטל, עם מעבד EPYC אתה מקבל גישה לכל המשאבים גם עם מעבד יחיד.

ב-HPE לדוגמא בנו שרת, ה-DL 325 Gen 10 מבוסס מעבד יחיד, ויש להם כמה דברים לאמר בנידון:

תנחשו מי מאוד התלהב מהרעיון? המתחרים. אינטל.

אינטל תוציא בקרוב 3 מעבדים חדשים בסידרת ה-Cascade Lake שלהם, וכמו ש-AMD השתמשה באות P לבדל את המעבדים, אינטל תשתמש באות U. בשאר הדברים אינטל די העתיקה את AMD – רוצה לדוגמא שרת עם 20 ליבות סה"כ? רכוש את ה-Xeon Gold 6210U, תקבל 20 ליבות במחצית המחיר בהשוואה ל-2 מעבדים של 10 ליבות כל אחד. המעבדים הנוספים שיהיו הם: Gold 6212U (עם 24 ליבות) ו-Gold 6209U עם 20 ליבות במהירות נמוכה ב-400 מגהרץ בהשוואה ל-Gold 6210U.

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

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

כשצריכים סטורג' לעסק קטן

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

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

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

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

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

הבעיה המרכזית לפחות ממה שאני רואה – שיש לא מעט כאלו שרוצים משהו שניתן להרחיב, שניתן להכניס 8-12 דיסקים (דיסקים מכניים הם יחסית זולים כיום, גם בגודל 8 טרהבייט), יש כאלו שרוצים חיבור כפול של 10 ג'יגהביט לשרידות, והרוב המוחלט שיודע שיש שרתים שנמכרים כיד שניה במחירים של 1000-3000 שקל – רוצים פתרון יותר זול ממה שהשניים מציעים. אחרי הכל, פתרון כמו Synology DiskStation DS3617xs מתחיל במחיר של $3000 עם 0 דיסקים.

האם יש איזה פתרון שעונה על הדברים הבאים?

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

יש.

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

היתרון הגדול של XPEnology הוא שאין צורך לרכוש חומרה מיוחדת. גם מעבד i7 ישן עם 8-16 ג'יגה זכרון יעשו את העבודה, ואת החומרה הזו תמיד ניתן לשדרג (אם כי החלפה של לוח אם ומעבד יצריכו, סביר להניח – התקנה חדשה. ה-XPENology מבוסס אמנם על לינוקס, אולם הוא רחוק שנות אמור מכל הפצת לינוקס שלא משנה מה החומרה שתזרוק לה – תכיר את הכל אוטומטית ב-Boot הבא), ולכן את ההתקנה הראשונית צריך לעשות מישהו שמכיר טוב את XPEnology, או שלא תצליחו אפילו לעשות Boot לקובץ ה-ISO הקטנטן. מנסיון. זה, אגב, גם החסרון שלה – הקושי בהתקנה עצמה.

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

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

מתי כדאי לרכוש את ה-Optane SSD של אינטל?

כל איש IT שמבין משהו בדיסקים, מכיר בוודאי את הכלל הפשוט הבא: דיסקים מכניים מיועדים  לאחסון גדול, דיסקים SSD מיועדים לביצועים. שילוב של השניים נותן בעצם ביצועים די טובים, והקונפיגרציה הזו "מאיצה" את הקריאה/כתיבה לדיסקים. עד כאן הכל טוב ויפה. יצרני ה-SSD כמובן מנסים להתחרות בגיזרת הגודל SSD מול הדיסקים המכניים, אך המחיר שלהם מרתיע. לפני מספר שבועות קיבלתי דיסק SSD מסוג Nytro של Seagate לבדיקה, דיסק SSD בגודל 15.3 טרהבייט. מנמ"ר שקפץ לביקור אליי ראה את הביצועים והתרשם (לעניות דעתי הביצועים אינם משהו הואיל וזה דיסק שמתחבר ב-SAS ולא U.2) – אך כשהראתי לו את המחיר של הדיסק (6,500 דולר – בחו"ל) – ההתלהבות ירדה במהירות.

כל פתרון אחסון, בין אם מדובר באחסון סגור או אחסון בניה עצמית – עובד פחות או יותר באותה שיטה של "פירמידה" – מהאמצעי הכי מהיר לאמצעי הכי איטי: זכרון RAM כ-Cache ראשוני (או במקרים של אחסון קנייני כמו EMC לדוגמא – NVRAM), מתחתיו SSD שבנויים משבבי NAND SLC או MLC, ובשכבה האחרונה – הדיסקים המכניים. כל שלב ב"פירמידה" מאיץ בעצם את החלק מתחתיו (כשמסתכלים מלמעלה כלפי מטה).

הפירמידה הזו בשנתיים האחרונות "התרחבה" מעט כשאינטל וסמסונג הוציאו את ה-SSD שלהם (Optane בדגמים שציינתי לעיל) שמיועדים יותר ל-Cache. אינטל הוציאה את ה-900/905P לשוק הסמי-מקצועי ואת ה-DC P4800X לשוק ה-Enterprise ואילו סמסונג הוציאה 2 דגמים תחת המותג Z-NAND. הפתרונות הללו יושבים בין ה-RAM (או ה-NVRAM) של פתרון האחסון, לבין ה-SSD מכיוון שהם הרבה יותר מהירים מ-SSD אך אינם מגיעים למהירות של RAM. היתרון ב-Optane בדגמים לעיל הוא שהאחסון מתאים לרוב העומסים של Enterprise או בשימוש מקצועי (תיכף ארחיב), ואילו היתרון של Z-NAND מגיע כשצריכים מידע במהירות מאוד גבוהה (מ-100 ג'יגהביט ומעלה) או ב-Queue Depth מעל 128.

נשאלת השאלה: האם כדאי לרכוש בעצם את ה-Optane DC לצורך סטורג' כתחליף ל-SSD שרוכשים לשרתים (Read Intense/Mixed Intense/Write Intense)?

כדי להחליט אם לרכוש, צריכים להכיר את הטכנולוגיה. ה-Optane DC (ומשפחת ה-900) אינם מכילים שבבי NAND כמו כל דיסק SSD אחר. הם מכילים שבבי אחסון אחרים שאינטל מתעקשת לא לגלות מה יש בתוכם ואינטל קוראת להם 3D XPoint. ב-SSD הללו כל הכללים של SSD רגיל עפים מהחלון. אין צורך ב-Over Provisioning, אין צורך ב-TRIM, ב-SSD אין זכרון שמשמש כ-Cache עד שה-DATA יכתב לשבבים, ומבחינת DWPD (כלומר כמות הפעמים שמותר לכתוב על כל הדיסק ביום) – אינטל מציינת את המספר כ-30 בגירסת ה-P4800X (אני קיבלתי דיסק כזה ל-Torture testing וגם אחרי שכתבתי על כולו 50 פעם בחצי יום – הוא עדיין עבד מעולה. הצעקות שקיבלתי מהנציג באינטל – זה סיפור אחר 🙂 ). מבחינת ביצועי קריאה כתיבה – הוא עוקף את כל מה שיש בשוק (למעט ב-Queue Depth סופר גבוה – שם Z-NAND עוקף אותו). ככלל – היתרון הגדול של Optane DC זה ה-Latency המאוד נמוך שלו בהשוואה למתחרים.

הבעיה המרכזית קשורה למחיר מול ביצועים. שאל את עצמך – האם חברתכם מוכנה לשלם 3000$ על דיסק בודד בגודל 750 ג'יגהבייט? נניח שאנחנו מקימים מערכת וירטואליזציה מבוססת HCI עם VSAN. אנחנו צריכים לכל הפחות 3 דיסקים – 2 איטיים והשלישי מהיר. נאמר ש-2 ה"איטיים" יהיו SSD מבוססי Read Intense והמהיר יהיה Optane DC. יוצא מכך שרק על השלישיה הזו נוציא כמעט 4000$. לא דיברנו על רשיונות, על החומרה הנוספת בשרת, על דיסקים נוספים וכו'. מישהו שפוי ירצה לשלם מחיר כזה?

אישית, כשאני מקים פתרון סטורג' עבור לקוח – אחד הדרישות הראשונות שלי זה דיסק Optane 900P (ואם זה ל-Enterprise – אז DC P4800X) בגלל ה-Latency הנמוך. דיסק כזה משמש אותי אך ורק ל-Caching כשאני צריך לכתוב/לקרוא נתונים ממכונות/אל מכונות אחרות, כאשר החיבוריות היא לפחות 10 ג'יגהביט. במקומות אחרים, כשיש צורך ב-DB לפרודקשן שאמור לתת ביצועים מאוד גבוהים – אותו Optane DC מתאים כ-Cache בלבד, במיוחד אם מדובר ב-In memory Database, ואפילו שרת MySQL/MariaDB יכול לתת ביצועים גבוהים בהרבה בהשוואה לדיסקים SSD אחרים, אבל במקומות אחרים ה-Optane לא יתן לי הרבה בהשוואה למתחרים ופשוט לא יהיה שווה את הכסף.

אם כן חושבים לרכוש את הציוד הזה, חשוב לזכור איזו גירסה לרכוש מיצרן השרתים: AIC (מדובר בכרטיס PCIe) או U.2 (שנכנס מקדימה). בשרתים מודרניים כמו R740, DL380 וכו' לא מומלץ לרכוש מספר דיסקים כאלו להכנסה מקדימה, הואיל והקירור/איוורור אינו מספק (כן, ה-Optane דורש יותר, לכן הוא בין היחידים שכוללים צלעות קירור, לא שזה עוזר הרבה..), ועדיף לרכוש את גירסת ה-AIC. אגב, ה-Endurance של זה כזה גבוה שלעניות דעתי RAID מיותר. אתם לא תקבלו מהירות קריאה כפולה/מהירות כתיבה כפולה (בשביל זה תצטרכו לעשות Overclock לזכרון ולמעבד – דבר בלתי אפשרי במעבדי Xeon).

לסיכום: Optane 900p/DC P4800X הם דיסקים SSD בתצורה שונה, חיה אחרת שהכללים הרגילים שחלים על SSD לא חלים עליהם. הם נותנים ביצועים מטורפים, אך יחד עם זאת, הדיסקים הללו לא בנויים להחליף אחסון של SSD רגיל/מעורב. הם יותר מתאימים ל-Cache או כל דבר אחר שצריך Latency מאוד נמוך, כך שהם מתאימים רק לצרכים ספציפיים. אם יש לך צרכים כאלו, אז הדיסקים הללו יכולים לשמש כפתרון מעולה.

על תכנון מפרט שרתים

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

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

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

יש לא מעט אנשים בתחום הגדרות ומכירת שרתים שלא ממש מעודכנים בטכנולוגיות שנמצאים בתוך השרתים. ניקח לדוגמא את תחום הזכרון: השרתים הנמכרים כיום אצל רוב המשווקים – מבוססים על Xeon SP של אינטל או EPYC של AMD. ב-EPYC הדברים מאוד פשוטים: יש לכל מעבד 8 ערוצי זכרון לכל מעבד, ואם אתה רוצה את הביצועים המקסימליים שהמעבד יכול לתת, אתה פשוט קונה זכרון לכל הערוצים. כך לדוגמא אם אתה רוצה 256 ג'יגהבייט לשרת עם מעבד אחד, אתה פשוט קונה 8 מקלות SDRAM ECC מיצרן השרת, כשכל DIMM הוא בגודל 32 ג'יגהבייט.

באינטל המצב שונה. בעבר למעבדי Xeon היו 3 ערוצי זכרון וכל ערוץ זכרון הצריך 3 מקלות DIMM זהים, כך שעל מנת לקבל ניצול מקסימלי של ביצועי מעבד/זכרון, היית צריך להכניס 9 מקלות DIMM. רוצה לדוגמא להכניס 128 ג'יגהבייט זכרון למעבד? שדרג טיפה ל-144 ג'יגה זכרון ורכוש 9 מקלות של 16 ג'יגהבייט זכרון. כיום המצב שונה במעט, ולכל מעבד Xeon SP יש 2 בקרי זכרון, עם 6 ערוצים לכל מעבד. כל ערוץ מחובר ל-2 מקלות DIMM ויש דרכים שונות לקבל Balanced Memory. למי שמעוניין, המסמך הזה מ-LENOVO מסביר את הדברים בהרחבה (וההסבר מתאים לכל שרת מבוסס Xeon SP, לא חשוב מי היצרן).

גם בגיזרת הדיסקים דברים משתנים. לא מעט אנשי IT היו מריצים תוכנות מדידה שונות למשך יום יומיים כדי לקבל מצב ולהחליט אם לרכוש דיסקים SSD שהם Read Intensive או Mixed Intensive. אני חולק על השיטה הזו הואיל והיא לא יכולה לקחת בחשבון צרכים עתידיים, וההפתעה הכי גדולה שאני מבשר לאנשי IT – ההבדלים בין Read ל-Mixed מבחינת מחיר – צנחו. אם לדוגמא תשוו דיסק SSD של מיקרון או אינטל או סמסונג שהוא Read Intensive לדיסק SSD כמו PM883 של סמסונג (שנמכר ע"י כל יצרני השרתים, אגב, עם תמיכה מלאה ו-SLA) הוא 100-120$ כשאנחנו מדברים על גודל דיסק SSD זהה, וחיבור SATA. אז אם לדוגמא אתם רוכשים לשרת 5 דיסקים, האם הפרש של 500-600$ בעלות הכוללת של השרת, זה מה שישבור את הדיל?

תחום נוסף הוא חיבוריות לרשת. לא מעט חברות עוברות ל-10 ג'יגה ובמקרים רבים מתקבלת החלטה לחבר את השרת ב-teaming של זוג בשיטת חיבור Active/Passive, כך שאם חיבור אחד נופל, חיבור שני ימשיך לעבוד. צר לי, זה לא יעבוד אם מחברים את זה לאותו כרטיס או ללוח האם מסיבה פשוטה: בכרטיס או לוח האם יש מעבד אחד ואם יש בו תקלה, אף אחד מהחיבורים לא יעבוד. זה כן יכול לעבוד אם לדוגמא סיב נפגם, אבל על מנת לכסות את מקסימום האפשרויות לתקלות, תצטרכו 2 כרטיסי רשת נפרדים ולחבר אותם ב-Teaming.

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

  • בישראל אין חנות Online לאף יצרן שרתים ואתם גם לא תקבלו את מלוא הקטלוג של חלקי החומרה שהיצרן מייצר/משווק, לכן אני ממליץ להיכנס לחנות Online בחו"ל, ו"לבנות" את השרת שלכם. המחיר כמובן אינו כמו המחיר שתשלמו בישראל, אבל תוכלו לראות בדיוק את האפשרויות שיש לכם במקום לסמוך על איש שיווק שבמקרים רבים לא יודע על מה הוא סח (מבלי לפגוע במישהו).
  • תכננו את הזכרון באופן אופטימלי, אך תשדלו לא לרכוש דברים שלא תוכלו להשתמש בהם מאוחר יותר בעת שדרוג, כמו מקלות זכרון של 4 ג'יגהבייט.
  • אם אתם מתכננים פרויקט שהשרתים יבצעו בו עבודת Scale Out, יהיה עדיף לרכוש מספר מצומצם יותר של שרתים "חזקים" מאשר כמות גדולה יותר של שרתים "חלשים". הסיבה לכך פשוטה: יותר תחזוקה, יותר עלות של חשמל, תופס יותר מקום. אז במקום 20 שרתים חלשים, 10 חזקים יעשו את העבודה ויחסכו את הדברים שציינתי לעיל.
  • מעבדים: כיום המצב הוא שבאותו מחיר שאתם רוכשים מעבד אינטל עם 4 ליבות, אתם יכולים לרכוש EPYC של AMD עם 8 ליבות. לא עדיף לקבל יותר באותו מחיר? (ולא, אל תתנו למסמכי השיווק של אינטל לבלבל אתכם, במקרים רבים הנתונים מעוותים/מוטים).
  • דיסקים: לכו על Mixed ותחסכו לעצמכם הפתעות עתידיות. ההבדל במחיר אינו כה משמעותי.
  • רשת: עדיף 2 כרטיסי רשת מאשר לחבר לאחד עם 2-4 חיבורים לשם שרידות.
  • VDI: למי שלא מודע, nVidia כעת גובה על ה-Grid שלהם תשלום חודשי. הגיע הזמן שתכירו את ה-Fire Pro של AMD שעובד מצוין על VMWare, Citrix, Microsoft – שם לא תשלמו חודשי.