על החומרה שמריצה את התוכנה שלנו

אני עושה כאן קצת ניסוי.

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

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

הקורסים מתחילים בבעיה של ייצוג ספרות, אולי מספרים עשרוניים, סט פקודות RISC vs. CISC, ואז אינדיאנים גדולים ואינדיאנים קטנים… – שהכל חשוב, אבל בגלל שנכנסים כ"כ לעומק בפרטים הללו – מסיימים אולי עם שכבות זכרון ו Cache של מעבד או הממשקים הנמוכים של הקוד עם מערכת ההפעלה. התמונה לא מתחברת לתמונה שלמה ושימושית עבור רוב האנשים.

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

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

אז אתה, כמתכנת, מבין במחשבים, או לא?

ואז בעבודה (את/) אתה שומע כל מיני הערות על SSD או ECC ואולי Blades – ואין לך מושג (אני מנחש – אני דווקא מכיר) על מה מדברים ואיך זה קשור לתוכנה שאתה כותב. אז אני יודע מה זה ALU ומה הם שערים לוגים – אבל מעולם לא נתקלתי בשיחה במסגרת העבודה שהגיעה לאיזורים הללו בכלל.

מקור: hdwallpapershoot

אז למה הפוסט הזה הוא "ניסוי"?

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

אני כותב אותו בעיקר בשביל הפאן.

הוא עדיין עשוי להיות מעניין ושימושי לרבים – ויהיה אפשר ללמוד ממנו. כלומר: ממישהו שיודע יותר, אפילו שהוא לא מומחה (שזה אני).

אז עם כל ההסתייגויות וההבהרות – נצא לדרך.

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

מקור: Rainbow Communication – computer and internet 101

הקופסה

אני אניח שאתם מבינים לעומק את ההבדל בין ה case ("המחשב") למסך וה Peripherals השונים. הנה וידאו קצר בו מפגישים חבר'ה צעירים עם מחשב משנות ה 90 עליו מותקנת "חלונות 95" ("את יכולה לנחש מה זה?" שואל המראיין – "המחשב הראשון שנוצר??" עונה הצעירה בפליאה) – אם אתם רוצים קצת להשתעשע.

בגדול יש 3 סוגי cases למחשבים (כלומר: שרתים, לא מחשב ביתי):

    • Tower – הזול ביותר, המשמש גם מחשבים ביתיים. קל להזיז אותו ולאחסן אותו בכל מקום – אך אינו יעיל בתפוסת המקום. מכיל הרבה אוויר ;-). לא ניתן להניח אותם זה על זה (בבטחה), ואין דרך טובה לארגן כבלים / את האוורור.
      • בסאפ היה לנו חדש שרתים עם Tower cases (עבור הפיתוח). שמו אותם על מן מדפים כאלו. 3 או 4 קומות.
    • Rack Mount – הוא סטנדרט אחיד ל Cases של שרתים כל שיוכלו להתאים באותו הארון ולהיות מאוחסנים ביעילות של מיקום ואוורור (לדוגמה הסטנדרט אומר שזרימת האוויר צריכה להיות מקדימה לאחור).
    • את השרתים מאחסנים בתוך ארון שנקרא Rack או Cabinet (בציור נראה כמו שלד – אך מדובר לרוב בארון מאסיבי). ה Rack מגיע עם קיטים של מסילות (Rail kit) שמבריגים על השרתים הפיסיים וכך ניתן לחבר אותם ל Rack.
    • המסילות מסייעות לגשת בקלות לכל יחידה. יש לרוב התקנים לסידור הכבלים כך שישבו יפה בתעלות משלהן.
    • הסטנדרט המקובל שאני מכיר הוא זה: בשרתים – הכבלים הם מאחור, בציוד תקשורת – הכבלים הם מלפנים. (יש הרבה יותר מה לחבר). אם אתם נכנסים לחדר שרתים (חוויה שהולכת והופכת לנדירה בימנו) ורואים בלאגן של כבלים – אתם כנראה רואים ציוד רשת.
    • בעוד הרוחב והעומק של ה cases של השרתים הוא זהה – הגובה יכול להשתנות ביחידות קבועות, הנקראות Rack Unit. בקיצור RU או רק U. ציוד תקשורת יהיה בד"כ 1U, ושרתים יהיו לרוב 2-4U גבוה. שרת של 4U תופס מקום של שני שרתי 2U. בארון יש בד"כ 42 או 48 U בסך הכל.
    • השרתים הם עדיין עצמאים (יש לכם ספקי כח ומאווררים משלהם), ויכולים להגיע מספקים שונים.
  • Blade – בכדי לחסוך עוד מקום, וגם לייעל כמה תהליכים (למשל: צריכת חשמל, חיבורי רשת) יצרו פורמט שנקרא Blade ("להבים"). שרתי ה Blade מורכבים בתוך שאסי (chassis = שלדה) שהיא בעצמה מורכבת בתוך Rack (והיא תתפוס משהו כמו 8-15U). השאסי מספק לשרתים חשמל, קירור וחיבורים (במקום כבלים) מה שמאפשר לכל אלו להיות יעילים ומאורגנים יותר.
    • אם תזדמנו לחדר שרתים, תוכלו לזהות Blade unit בכך שהיחידות הן אנכיות (כמו "להבים") ולא אופקיות כמו Rack units.
    • החיסכון הגדול במקום הוא במידה רבה בגלל היכולת לשתף Redundancy: בכל שרת Rack יהיו באופן טבעי שני ספקי כח (ספקי כח ודיסקים הם הרכיבים שמתקלקלים הכי הרבה), ואמצעי קירור (מאווררים, לרוב) יתירים. לא נרצה שהשרת יפסיק לפעול אם "נדפק" ספק הכח או נתקע מאוורר. מצד שני – היתירות בכל יחידה גוזלת הרבה מקום. ה Blade חוסך את היתירות לכל שרת ב Rack ומספק יתירות שיתופית לכל השאסי.
    • עד כמה שידוע לי, אין שום תקן אחיד לחיבור בין השאסי ל Blades עצמם. אם יש לכם שאסי של IBM – תוכלו לחבר אליו רק יחידות (שונות) מתוצרת IBM.
    • ה Blade נשמע כמובן הפתרון המועדף, אך יש לו גם חסרונות. המחיר – הוא לרוב החיסרון העיקרי, חוסר הגמישות לשלב בין יחידות של ספקים שונים או "להשתחרר" מספק – ללא השקעה כספית ניכרת. היחידות עצמן לרוב הן קבועות ולא ניתנות להרחבה (אין חריצי PCI ולעתים לא ניתן להוסיף דיסק או זכרון). ה Blade מתאים בעיקר ל Data Centers גדולים.
אני רוצה לציין משהו על צריכת חשמל: צריכת החשמל, עד כמה שידוע לי, היא כיום האתגר העיקרי בבניית Data Center. יותר כח מחשוב => יותר צריכת חשמל => יותר דרישת קירור.
לרוע המזל יש גבול לכמה קירור ניתן לספק לנפח מסוים, ועל כן לא ניתן לדחוס שרתים ללא גבול. דרישות הקירור הופכות לדרישות נדל"ן – שזו הוצאה גדולה בפני עצמה. כלומר: חשמל (של המחשבים + הקירור שלהם) והנדל"ן שמאחסן אותם הוא מרכיב העלות המרכזי של ה Data Center המודרני. כיצד מצמצמים עלויות?
  • רכישה של שרתים עם נצילות חשמל טובה יותר (הדורות החדשים של המעבדים לגמרי שם).
  • אופטימיזציות שונות. ספק כח (PSU) עם יעילות של 90%+ (platinum class) הוא דיי יקר – מאות דולרים ליחידה עבור שרת רגיל. עבור יחידות ב Rack לעתים קשה להצדיק את ההוצאה: שתי יחידות לכל שרת (עבור יתירות).
    ב Blade – אין בעיה להשקיע ב PSU יעיל הרבה יותר. להזכיר: ה PSU בעצם ממיר את המתח 110/240v לסדרת מתחים נמוכה (6/12/24v) לה רכיבי המחשבים בעצם זקוקים. תוך כדי ההמרה – אנרגיה מתבזבזת וממורת לחום. PSU זולים (מה שיש לנו בבית) לרוב מבזבזים כ 20-30% מהאנרגיה בהמרה – וייתכן שיהיה כלכלי יותר לקנות PSU יעיל מעט יותר (במידה ואנו משתמשים במחשב שעות רבות – כמוני).

    • יחידות Blade לרוב דורשות זרם תלת-פאזי, ושמעתי טענה ש PSU תלת פאזי יהיה בהגדרה יעיל יותר. אולי בגלל היכולת לנצל בכל פעם פאזה אחרת שהיא חיובית בכיוון הזרם שלנו ?!?! (ניחוש).
כך נראה Rack במציאות. Rack מסודר להפליא – עלי לציין. בחלק התחתון שלו ניתן לזהות יחידות Blade.
הערה: אם אתם מזהים יחידות אנכיות ממש קטנות (10-15 ס"מ) אלו אינם blades אלא דיסקים נשלפים ב Hot swap. אל תעשו לעצמכם פאדיחות 🙂

בתוך הקופסה

בתוך ה Case של המחשב לוח האם (motherboard) הוא זה שמחבר פיסית את כל הרכיבים השונים: הוא מקבל חשמל מספק הכח (PSU = Power Supply Unit) ומעביר מתחים לרכיבים השונים. הוא כולל גם את קווי החשמל עליהם עוברים נתונים בין הרכיבים השונים, מה שנקרא Bus, את החיבורים החיצוניים (USB, SATA), וכו'.

רכיבי המחשב השונים. מקור: How to know your computer hardware components

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

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

  • x86 (ידועה גם כ x86-64, x64, או AMD64) – הארכיטקטורה הנפוצה ביותר (כ 90% משוק השרתים). מריצה "חלונות", לינוקס, ומק. מיוצרת על ידי אינטל אבל גם ע"י מתחרתה AMD.
    • מעבדי AMD ואינטל דורשים לוחות אם שונים, אבל שאר הרכיבים (זיכרונות, חריצי הרחבה) – הם משותפים.
  • PowerArchitecture (לשעבר PowerPC) – ארכיטקטורה שמשמשת בעיקר את IBM בשרתי ה High-End שלה (Power 8, Power 7, ובקרוב Power 9), השנייה הנפוצה לאחר x86. מריצה בעיקר AIX (יוניקס של IBM).
  • Sparc של שרתי אורקל (לשעבר Sun Microsystems) – שולטת על אחוז או שניים משוק השרתים העולמי (לפני עשור או שניים – נתח השוק שלה היה גבוה משמעותית). מריצה בעיקר Solaris (יוניקס של Sun).
  • ARM – הארכיטקטורה שנפוצה מאוד במכשירי מובייל בשל חסכנותה בחשמל. ישנם גם יישומים שלה בצד השרת (עדיין לא נפוצה).

לאורך השנים המעבדים הגבירו את מהירות העבודה שלהם: על לוח האם ישנו שעון שמספק קצב למעבד: זה התחיל ב 4KHz (קילו-הרץ) והסתיים בערך ב 4.3GHz (ג'יגה-הרץ). חוקי הפיסיקה לא מאפשרים להעלות את מהירות המעבד מעל כ 4300~ מגה-הרץ בצורה יעילה (קירור בחנקן נוזלי יכול לאפשר 6GHz בערך – אך זו לא גישה כלכלית). לכאורה: יצרני המעבדים לא יכלו לייצר מעבדים מהירים יותר.
בפועל שיטות הייצור אפשרו למזער עוד ועוד את המעבדים והפתרון היה לייצר כמה cores בכל מעבד. כלומר: המעבד הוא "אריזה" שבתוכה ארוזים 2, 4 או יותר מעבדים "cores" כמעט-עצמאים שמבצעים את החישוב.

חשוב לציין שמהירות השעון (GHz) ומספר ה Cores הם לא מדד מוצלח להערכת כח-מחשוב. לדוגמה המעבד של אפל למובייל (A9) מכיל רק 2 cores במהירות 1.85GHz – אך הוא מהיר משמעותית ממעבדים בעלי "8 cores במהירות שעון של 2GHz" (להלן SnapDragon 810 של חברת Qualcomm).

עוד שינוי שהתרחש בשנים האחרונות בעולם ה Consumer הוא שבתוך ה"אריזה" של המעבד (CPU) נהוג היום לארוז גם מעבד גרפי (GPU, לעתים כמה cores) שנדרש עבור הרצת אפליקציות גרפיות ומשחקים.

את לוח האם מתאימים למעבד ע"פ דגם ה Socket (למשל LGA 1151 של אינטל) ו Firmware מתאים (כלומר: לוח האם צריך לציין שהוא תומך במעבדים מסדרת Skylake של אינטל – אחרת ייתכן ולא יידע להפעיל חלק מהיכולות שלהם).
Firmware היא התוכנה של רכיב אלקטרוני, במקרה שלנו ה Chipset של לוח האם – סדרת רכיבים אלקטרוניים שתומכים בארכיטקטורת המעבד. ה Chipset הוא "המוח" של לוח האם, והוא נקרא כך כי הוא בעצם סדרה של רכיבים אלקטוניים שמרכיבים במקומות שונים על לוח האם.

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

מעבד Sandy-Bridge של אינטל. מקור: www.bit-tech.net

בתוך "אריזת" המעבד כוללים 3 רמות שונות של זיכרונות Cache המסומנים כ L2, L1, ו L3. אתם בוודאי מכירים את העניין הזה, אך אני אחזור עליו בקצרה. מדוע 3 רמות שונות?

  • כאשר ה Cache הוא גדול יותר, ניתן לאחסן בו יותר נתונים אך החיפוש אחר ערכים (latency) – מתארך. יש פה Tradeoff מובנה בין מהירות תגובה לנפח אכסון.
  • בעבר למדתי ש L1 (הזיכרון הקטן והמהיר ביותר) נמצא קרוב יותר לליבת ה Core – מה שמקצר את ה Latency שלו, ו L2 הוא יותר רחוק. לא מצאתי אימות למידע הזה.
  • בסופו של דבר מחלקים את ה cache לשלוש רמות (בד"כ!):
    • L1 הכי קטן והכי מהיר – נמצא בתוך ה Core. ב Skylake לכל core יש 64KB של L1.
    • L2 קצת יותר גדול ופחות מהיר – גם נמצא בתוך ה core. ב Skylake לכל core יש 256KB של L2.
    • L3 הוא לרוב משותף בין כל ה cores (חבל להביא ולאחסן אותם נתונים בצורה כפולה בין ה cores). הגודל שלו הוא בין 2MB במעבדים הבסיסיים עד עשרות MBs במעבדי השרת.
    • ב Skylake הציגו גם לראשונה זכרון L4 (בחלק מהדגמים) – אך הוא נועד למעבד הגרפי (GPU).
  • ה Cache מחזיקים שני סוגי מידע:
    • קוד להרצה (שגם אותו צריך לטעון לזיכרון)
    • נתונים של התוכנה.
  • כל פעם שאתם קוראים בקוד התוכנה אפילו לביט אחד של נתונים מהזיכרון שאינו נמצא ב Cache, יש לבקש העתקה של בלוק (אם כבר מבצעים העתקה, מעתיקים לפחות כמה עשרות או מאות Bytes) מהזיכרון הראשי ל L3 ואז ל L2 ואז (אולי) ל L1.
    • ה RAM הוא לא באמת "Random Access" – מהירות התגובה שלו כלפי המעבד תלויה מאוד באילו נתונים נמצאים כבר ב Cache.

צלילה קצרה למעבדי אינטל (x86) השונים

בפוסט זה אני אתעלם כמעט לגמרי מהארכיטקטורות האחרות ואתמקד רק ב x86. הנה רשימת הדורות האחרונים של הארכיטקטורה:
Sandy Bridge הוא גאווה ישראלית: הוא פותח בסניף אינטל בחיפה. הוא הציג יכולות עיבוד וידאו שהיוו ממש קפיצת-מדרגה, וכלל עוד כמה חידושים מרשימים (Turbo Boost?). מאז לאינטל אין כמעט תחרות מצד AMD (המתחרה המשמעותי היחידי בעולם ה Desktop) והדורות הבאים כמעט ולא הציגו ביכולת העיבוד שלהם – רק השתפרו בצריכת החשמל. בצד השרתים דווקא יש התקדמות מתמדת – מכיוון שיש תחרות מצד יבמ, אורקל, וחשש לתחרות מצד מעבדי ARM.
מילה לגבי תהליך הייצור: בכל שנה בערך אינטל מוציאה דור חדש של ארכיטקטורת המעבד שלה (שהיא תואמת לאחור). דור אחד משפר את הליטוגרפיה (טכניקת הדפסת המעגלים, הנמדד במרחק המינימלי בין 2 קווים – בננומטר) – מה שנקרא "Tick". דור עוקב משפר את הארכיטקטורה וה Layout של המעבד – מה שנקרא "Tock".
כל קפיצה בתהליך הייצור מאפשרת לדחוס בערך פי 2 טרנזיסטורים בנפח נתון: "22 בריבוע" (שטח המעבד) הוא בערך חצי מ "32 בריבוע". כלומר: ניתן ליצור מעבדים עם יותר cores, או מעבדים קטנים יותר וחסכניים יותר בחשמל.ייתכן ומעכשיו, בשל הקושי לשפר את תהליכי הייצור כל שנתיים – אינטל תעבור למחזור תלת שנתי: ״תהליך״, ״ארכיטקטורה״, ו״אופטימיזציה״.

במעבדים השולחניים של אינטל יש כ 4 cores (בשל מחסור בתחרות?), במעבדים עבור מחשבים ניידים – 2 (עבור צריכת חשמל נמוכה, בכדי להאריך את חיי הסוללה), ובשרתים – עד 22 cores (עבור ביצועים).
ההערכה היא שלא ניתן יהיה ליצור תהליך קטן מ 7nm או 5nm – ובעתיד קצב השיפור של מעבדים ייעצר (או שיימצא טריק אחר על מנת לשפר אותם).
בכל דור של מעבדים אינטל מציגה כמה וריאציות שונות של הארכיטקטורה: השוני לרוב הוא בשימוש בזיכרון או ב Bus, זכרון מטמון וכיו"ב. הנה הווריאציות העיקריות:
בדוגמה הזו לקחתי את Ivy Bridge, אך לכל דור יש את גרסאות ה M, EP, E וה EX שלהם.
לרוב גרסאות ה EX וה E משוחררות מאוחר יותר, לעתים שנה או יותר לאחר שחרור גרסת ה Desktop / Mobile.
i3/5/7 ו E3/5/7 הן תתי סדרות בתוך הארכיטקטורות ומשמשים לעתים כשמות מרקטיאליים. למשל: המשמעות של i7 עבור מעבדים שולחניים ועבור מעבדי מובייל – היא שונה.
אינטל גם מוציאה מעבדים הממותגים תחת השמות Pentium ו Celeron – שהם המעבדים הזולים ביותר.
הנה דוגמה להבדלים בין הסדרות השונות במחשבים שולחניים (מבוסס על סדרת Skylake):
  • Celeron/Pentium – מעבדים בעלי 2 cores.
  • i3 – מעבדים בעלי 2 cores ויכולת HyperThreading (בקיצור HT). יכולת שמאפשרת הדמייה של פי-2 cores נוספים לצורך עיבוד מקבילי – ומקובל להעריך אותה כב 20% שיפור בכח החישוב. כלומר: כ 2.4 cores בהערכה פשוטה.
  • i5 – מעבדים בעלי 4 cores + יכולת Turbo Boost (בקיצור: TB) המאפשרת למעבד להגביר את קצב השעון אם חלק מה cores לא פעילים (עבור קוד שאינו concurrent). השיפור הוא כ 10% יכולת חישוב במצבים ספציפיים שכאלו.
  • i7 – מעבדים בעלי 4 cores ויכולות TB + HT.
  • i7 Extreme – מעבדים בעלי 4 או 6 cores, עם כל היכולות האפשריות ו Bus משופר (שזה השיפור העיקרי – בעיקר עבור gamers כבדים). אינטל אגב, היא גם היצרנית של ה Chipsets עבור המעבדים שלה.
והנה דוגמה להבדלים בין הסדרות השונות במעבדים עבור מחשבים ניידים (מבוסס על סדרת Skylake):
  • Celeron/Pentium – מעבדים בעלי 2 cores.
  • i3/m3/m5/m7 – מעבדים בעלי 2 cores ויכולות TB + HT.
  • i5/i7 – מעבדים בעלי 2 cores ויכולות TB + HT + זכרון L4 ייעודי עבור המאיץ הגרפי (לא בכל הדגמים).
  • i5 Extreme (מסומנים כ HQ) – מעבדים בעלי 4 Cores + יכולת TB + זכרון L4 ייעודי עבור המאיץ הגרפי.
  • i7 Extreme (מסומנים כ HQ או HK) – כמו מעבדי i5 Extreme + יכולת HT.
ישנם עוד הבדלים שונים (לרוב פחות משמעותיים) בין הדגמים השונים בתוך כל סדרה. בקיצור: כדאי לעקוב אחרי הפרטים!
במשך שנים מכרו מעבדי i7 לעולם המובייל שהיו מהירים בכ 30% בלבד ממעבדי i3 למובייל – למרות שעלו כפול ויותר מהמעבדים הפשוטים יותר. הרבה אנשים שילמו ומשלמים פרמיה על המדבקה עליה מתנוסס הלוגו "i7" ("זה הכי טוב!") – ללא ערך משמעותי להשקעה.

הזיכרון

זכרון פעם היה רכיב יקר למדי (אני זוכר שקניתי בתיכון 4MB זכרון ב 300$), אך הוא הפך ונהיה זול למדי, גם אבסולוטית וגם יחסית לשאר חלקי המחשב. מחשב אישי לרוב יכול להכיל עד כ 32GB זכרון (מחשב נייד: בד"כ חצי מזה), אך שרת יכול בקלות להכיל 256GB זכרון ואפילו ניתן למצוא שרתים עם 2TB זכרון. למה כ"כ הרבה זכרון? בד"כ עבור יישומים ייחודיים (למשל: In-Memory Databases).
הזיכרונות בארכיטקטורת אינטל הם מסוג DDR-SDRAM ומסומנים כ DDR3 או DDR4.מרגע שאינטל עברה לארכיטקטורה של 64-ביט, הכמות התאורטית של זכרון אליו המעבד יכול לגשת היא איננה מגבלה (המעבדים הנוכחיים משתמשים ב 48 ביט לייצוג זכרון, מה שמאפשר גישה תיאורטית ל 256TB זכרון). לרוב מה שמגביל את כמות הזיכרון שניתן להתקין הוא לוח האם, או מגבלות מלאכותיות של מערכת ההפעלה / התוכנה בה אתם משתמשים (Windows 7 Home Premium לא תאפשר להשתמש ביותר מ 16GB זכרון מבלי לשדרג לגרסה יקרה יותר של מערכת ההפעלה). אם בעבר (לפני עשור) ההמלצה הייתה תמיד לרכוש כמה זכרון שהתקציב שלכם מאפשר, כיום לרוב היישומים לא יהיה שימוש ליותר מ 8GB זכרון (בהנחה שמערכת ההפעלה צורכת כ 1GB זכרון).

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

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

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

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

The Most Common DDR DRAM Myths Debunked
DDR DRAM FAQs And Troubleshooting Guide

סוגי הזיכרון השונים

בחלוקה ראשונה אפשר לחלק את הזיכרונות ל2 קטגוריות בסיסיות:

  • זכרון סטטי (SRAM) – מהיר יותר, יקר מאוד, צורך הרבה חשמל, ותופס יותר מקום (6 טרנזיסטורים נדרשים לשמירת ביט אחד של זכרון) – ולכן משתמשים בו עבור זכרון מטמון L1 עד L3.
  • זכרון דינאמי (DRAM) – צפוף, פחות מהיר, פחות יקר, ודורש פחות חשמל – ולכן משמש לזיכרון הראשי של המחשב (גם שרתים).

הבנו מדוע אנו קוראים לזיכרון DRAM, אך מהיכן ה S ב SDRAM?

ה S היא עבור Synchronous מכיוון שהזיכרון מסנכרן את המהירות שלו מול ה BUS של לוח האם. לא 1:1 אלא בכפולות : פי 6 או פי 6.5 -למשל. בעבר הרחוק המעבד והזיכרון רצו באותה מהירות השעון: 33Mhz למשל, אך לא ניתן היה באותה תקופה להעלות את מהירות השעון של הזיכרונות מעבר לכך. הפתרון היה להריץ את המעבד ב 66Mhz ואת הזיכרונות ע"פ קצב של 33Mhz וליצור ביניהם פער של פי 2 במהירות השעון (להלן מעבד 486X2)

הזמנים השתנו ומעבדים רצים במהירות של בערך 3-4GHz, אך הזיכרונות עדיין לא מסוגלים לעבוד עם BUS מהיר בהרבה מ 1GHz.

נשארנו עם ה DDR (קיצור של Double Data Rate).
DDR  הוא תקן לזיכרונות שמעבירים נתונים פעמיים בכל פעולת שעון של ה BUS: פעם בנקודת השיא של השעון ופעם בנקודת המינימום (דמיינו גל סינוס). DDR3-1600 הוא זכרון שעובד עם ה BUS בקצב של 800Mhz, אך כיוון שהוא מבצע שתי העברות נתונים בכל אות של שעון – הוא מסוגל לבצע 1600 מיליון (מגה) העברות נתונים בשנייה, כאילו שהוא עובד עם שעון של 1600Mhz. רכיב הזיכרון עצמו, אגב, עובד רק במהירות של 200Mhz – אבל זה סיפור אחר.
אותו רכיב DDR3-1600 נקרא לעתים גם PC3-12800 בגלל שהוא מסוגל להעביר (תאורטית) כ 12.8GB נתונים בשנייה. כל העברת נתונים מעבירה את מלוא רוחב ה bus (כלומר: 64-ביט) כך שבכל העברת נתונים מעברים שמונה Bytes (שהם 64-ביט).

DDR3 ו DDR4 הן גרסאות שונות של התקן. התקנים אינם תואמים לאחור או לפנים, ואם יש לנו מעבד שלא תומך ב DDR2 לא נוכל להשתמש בזיכרונות מסוג DDR2 איתו. בשנות מעבר (למשל כעת) המעבדים יודעים לתמוך ב-2 תקנים, ומעבדי skylake של אינטל יודעים לתמוך היום גם ב DDR3 וגם ב DDR4 (אך לא ביחד – כמובן).

התקנים השונים של DDR מגדירים אגב מיקום שונה בכל גירסה לאיזה חריץ פיסי שנמצא על ה stick – כך שלא יהיה ניתן "בטעות" להכניס ל slot זכרון מדגם שלא נתמך. בכל גרסה של DDR עולה הצפיפות של הזיכרון (יותר נפח על Stick), עולה מהירות העברת הנתונים, ויורד המתח החשמלי הנדרש (פחות התחממות). התקן העדכני DDR4 (תקן מ 2014, החל להיות נפוץ לשימוש רק בחודשים האחרונים) תומך בנפח של עד 128GB ל stick, ובמהירות העברה (תאורטית) של עד 25.6 GB בשנייה.

עד כמה באמת משנה המהירות של הזיכרונות? לא כ"כ. ע"פ בדיקה שעשה האתר Hardware Canucks המעבר מ DDR3 ל DDR4 מקביל שיפרה בממוצע כ 2.5% בביצועי הקריאה של הזיכרון, 7% בביצועי הכתיבה, וכ 4% בביצועי ההעתקה בתוך הזיכרון. חשוב לציין שההשפעה של הזיכרון על הביצועים תלויה מאוד באפליקציה (והדרך שבה היא משתמשת בזיכרון), אך גם בדגם המעבד הספציפי (וה memory controller שלו) ובלוח האם. לא ניתן באמת להעריך רכיב זכרון מול רכיב זכרון ללא ההקשר המלא.

השפעה של DDR3 מול DDR4 במהירויות שונות על אפליקציית WinRar. במבחנים, זו האפליקציה שהושפעה הכי לטובה (ובבירור) מזיכרון מהיר יותר.
מקור: hardwarecanucks

למחשבים ניידים אגב, יש DIMMs (כלומר: Sticks) שהם קטנים יותר פיסית ונקראים SO-DIMM.
זיכרונות DDR (ואולי גם אחרים) מותקנים בזוגות על לוח האם בגלל טכנולוגיה שנקראת Dual Channel שאמורה לנצל את הזיכרונות בצורה יעילה יותר (אין קשר ל DDR). בדיקה שנעשתה (ב 2007 אמנם) מצאה שיפור מירבי של 5% בביצועים. כלומר: אפשר לשים זיכרונות בזוגות – אך ממש לא חייבים. היום פשוט מאוד לא מוכרים sticks של זיכרונות בבודדים (בגלל בעיות התזמונים שציינתי קודם לכן).
כאשר יש לוח-אם שתומך במספר מעבדים (לא cores) – יש חובה לשים כמה זיכרונות כי כל קבוצת DIMMs (מה שנקרא NUMA node) משרתת מעבד אחר (NUMA הוא שם הארכיטקטורה לתמיכה בכמה מעבדים). אלו לוחות אם ייעודיים לשרתים או תחנות עבודה "Workstation" והם עולים משמעותית יותר מלוחות אם התומכים במעבד אחד.

לוח אם התומך ב-2 מעבדים. ה slots לזכרונות מאורגנים בצורה שמבהירה בקלות אלו זכרונות משרתים כל מעבד. הזכרונות הם Quad Channel  (המקבילה הכפולה של dual channel) ולכן צבועים ברביעיות. מקור: Newegg

תזמוני זכרון (ידוע כ "CAS")

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

Latency של זכרון DDR מתואר ע"י 4 מספרים: tCAS, tRCD, tRP ו tRAS, למשל 9-9-9-28. ההסבר המדויק מה כל תזמון פחות חשוב. בסופו של דבר גישה לנתונים בזיכרון דורשת שרכיב הזיכרון ייבחר / "יתחבר" לשורה הנכונה ולטור הנכון בו נמצאים הנתונים ברכיבי הזיכרון. המדד tCAS, למשל, מתאר כמה cycles של שעון לוקח לבחור טור בזיכרון. גם לאחר שבחרנו את הטור והשורה הנכונים (בהנחה שהם לא היו selected קודם לכן) – יש להמתין זמן מה עד שאפשר להתחיל בהעברת הנתונים בפועל.
התיאור של זכרון כ "Random Access" או "גישה ב (O(1" היא הפשטה על המציאות המורכבת יותר. גם אם מתעלמים מה Caches שבאמצע.

כאשר המדדים הנ"ל נמוכים יותר – הזיכרון הוא בעל latency נמוך יותר. יש לזכור שהמספרים תלויים ב cycles של השעון, אז לא נכון להשוות מספרים של שני זיכרונות שרצים במהירות שעון גבוהה יותר. מהירות שעון גבוהה יותר = יותר cycles בשנייה. כלומר: tCAS של 9 בזכרון DDR4-2400 הוא טוב מעט יותר מ tCAS של 7 בזיכרון DDR4-1800.

אמינות של זיכרונות

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

ישנם זיכרונות מסוג ECC (קיצור של Error Correction Code). לזיכרונות הללו יהיה רכיב זכרון נוסף (תשעה במקום שמונה) על ה stick שמשמש כסוג של parity (שכפול נתונים). בתוספת של 1/8 מהזיכרון לא רק שניתן לדעת אם הייתה תקלה בזכרון – אלא גם להשלים את הנתון בתא שלא ידע לענות.

זיכרונות ECC הם יקרים יותר. יש שאומרים שאטיים מעט יותר (אני לא יכול לאשר) ונמצאים בד"כ רק בשרתים.

כשהארכיטקטורה שלנו מתבססת על ההנחה שיש הרבה nodes והם כושלים כל הזמן, האם יש עדיין הצדקה כלכלית לשימוש בזיכרונות ECC? האם אמזון AWS, למשל, משתמשים ב ECC?
בדקתי, והתשובה הייתה שכן – כל המכונות באמזון (שהן בהגדרה "commodity hardware") מצוידות בזיכרונות ECC. מעניין!

למערכות Ultra Mission Critical משתמשים במנגנונים של Memory Mirroring (קיצור שלי: MM).
MM עובד ממש כמו RAID 1: כל נתון שנכתב לזיכרון נכתב פעמיים, כך שאנו בעצם משתמשים בחצי מכמות הזיכרון הפנויה, ואנו צורכים פי-2 מה BUS – לכתיבה כפולה לזיכרון. אם רכיב זכרון (ביט או stick שלם) כושל – השרת ממשיך לעבוד כרגיל כאילו שום דבר לא קרה. איש operations יחליף את ה stick המקולקל – והכל יחזור להיות כפי שהיה. אם לוח האם תומך גם ביכולת בשם Memory Sparing, אז ניתן להתקין על לוח-האם כמה sticks של זכרון שלא יהיו בשימוש שוטף – אך יכנסו לשימוש אוטומטית ויחליפו sticks של זכרון שכשלו, וכך יאריכו את הזמנים ביניהם יש לעשות maintenance לשרת, כלומר: החלפה של sticks זיכרון תקולים. יכולות ה MM וה Memory Sparing הן יכולות של לוח האם, והן זמינות רק בעולם ה High-End של השרתים.

האם אמזון משתמשים גם ב MM? מה אתם אומרים?
בדקתי – ולא. אמזון לא משתמשים ב MM. אתם מוזמנים לבדוק לגבי Memory Sparing ולהגיב 🙂

סיכום

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

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

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

שיהיה בהצלחה!

לינקים רלוונטיים

ניתח הארכיטקטורה של Skylake באתר AnandTech

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

להבין Virtualization

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

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

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

רעיון הוירטואליזציה קיים ברמות הפשטה שונות:

  • זיכרון וירטואלי – הוא מימוש של וירטואליזציה לזיכרון. הוא מבצע multiplexing (חלוקת משאב פיסי אמיתי לכמה תהליכים אורחים במקביל) וגם emulation (בכך שהוא מנהל כתובות מדומות של הזיכרון הוירטואלי עמם התהליכים האורחים עובדים).
  • מנגנון ה LVM של לינוקס (קיצור של Logical Volume Manager) הוא דוגמה לוירטואליזציה של הדיסק. האופי שלו הוא אחר: הוא מבצע aggregation בכך שהוא גורם לכמה דיסקים פיסיים להראות כמו דיסק לוגי יחיד. זו עדיין וירטואליזציה.
  • מנגנון ה NAT (קיצור של Network Address Translation) של פרוטוקול IP, המשמש רכיבי רשת כמו proxy או reverse proxy בכדי להסתיר כתובות רשת אמיתיות של מחשבים – הוא דוגמה לוירטואליזציה של הרשת.
  • X-Server או VNC של לינוקס / Remote Desktop של חלונות – הם דוגמאות לוירטואליציה של ה Desktop. זהו עולם דיי עשיר עם פתרונות כמו App-V של מייקורוסופט ש\"מזרים\" אפליקציה שרצה בשרת מרוחק – למחשב השולחני המקומי (זו בעצם Application Virtualization).
בפוסט זה ארצה להתמקד בויאטואליזציה של החומרה כולה (זיכרון, דיסק, רשת, וכו\') – מה שרוב האנשים מכירים פשוט כ \"Virtual Machine\" או \"VM\".

במהלך הפוסט אנסה לענות על שאלות כגון:

  1. כיצד, בפועל, טכנולוגיות הוירטואליזציה חוסכות לארגון ה IT כסף רב?
  2. מה ההבדל בין hypervisors מ\"טיפוס 1\" ל hypervisors מ\"טיפוס 2\"? וכיצד בוחרים את העדיף לסיטואציה?
  3. מהי Paravirtuallization ומהם Linux Containers (שעושים כ\"כ הרבה רעש בשנתיים האחרונות)??
  4. למה לקח כ\"כ הרבה זמן לויטרטואליזציה לתפוס מקום מרכזי בתעשייה? אתם יודעים, כמעט 40 שנה?
  5. מי הם Popek ו Goldberg – ומה הקשר שלהם לכל הסיפור?

מוטיבציה

אנסה להעביר את המוטיבציה בעזרת סיפור קצר. בסיפור שלנו יהיה ארגון עם Data Center שכולל כמה שרתים שונים:

  • שרת קבצים (shares)
  • שרת ווב
  • שרת e-commerce
  • שרת דואר (Exchange)
(לצורך פשטות הסיפור אתאר רק 4 שרתים. בסביבה אמיתית סביר שיהיו הרבה יותר).

מקור: VMWare

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

  • Sandboxing: תקלה בשרת הדואר יכולה לגרום לקריסה של מערכת ההפעלה – ולא רוצים ששרת הווב או המסחר האלקטרוני לא יהיו זמינים בגללו. אולי שרת הדואר דורש עדכון של מערכת ההפעלה שגורם לבעיה חדשה בשרת הקבצים?
  • אמינות: כאשר כל שרת רץ על עותק שלו של מערכת ההפעלה – פשוט יש פחות תקלות. שני שרתים דורשים הגדרות תצורה מעט שונות – שלא אופטימליות או מוכרות עבור תוכנת השרת השנייה.
המציאות בפועל הייתה שאנשי ה IT דרשו מהארגון \"קופסה לכל שרת\" כתנאי עבודה בסיסי.
הקצאה של \"קופסה לכל תוכנת שרת\" סיפקה את היתרונות המצופים:
  • זמינות: שדרוג / עדכון של תוכנת שרת אחד, לא משפיעה על שרתים אחרים. 
  • דרישות סביבה שונות: שרת הדואר רץ על \"חלונות\", שרת המסחר על איזו גרסה של UNIX ושאר השרתים רצים על לינוקס בכלל. דרישות חומרה בד\"כ אפשר לכנס בקלות רבה יותר.
  • יתרונות אבטחה: קבלת הרשאות root על מחשב אחד, לא משפיעה על הגישה למחשבים האחרים.
כל זה טוב ויפה – אבל יקר. 
יקר בכלל הכפילות של החומרה שחלק גדול מהזמן נמצאת ב Utilization נמוך. אם שרת הווב, דורש לשעה בחודש כח עיבוד X, יש לספק לו כח עיבוד זה גם אם שאר החודש הוא זקוק לכח עיבוד של X/12 או אפילו X/60.

בנוסף: כשקונים שרת פיסי עבור תוכנה חדשה – כמה חומרה יש לקנות? האם מתכננים לחודש הראשון של השימוש או לשנה אח\"כ? בתעשייה נוצרה פרקטיקה בשם Sizing שמטרתה להעריך כמה חומרה תידרש, פרקטיקה מאוד לא מדויקת בה טעות של עד פי 2 – נחשבת כהצלחה.
שרתים פיסיים שרוב זמנם עובדים על כ CPU 10% – היו תמונה מקובלת.

לעלות החומרה יש עלויות נגזרות נוספות:

  • צריכת חשמל + צריכת החשמל של מערכות המיזוג שנגזרת ממנה (עלות משמעותית)
  • שטח אכסון (נדל\"ן – עלות משמעותית בערים צפופות)
  • עלות איש ה IT שעליו לנטר את המערכות ולתחזק את החומרה (התקנה, גיבויים, טיפול בתקלות, …)
    עונתיות בשימוש במשאב מחשוב

    הערך של וירטואליזציה

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

    מה קורה כאשר השרת הפיסי כושל? האם לא פגענו בזמינות של השרתים שלנו? ברגע שחומרת המחשב המשותף קורסת – יושבתו מיידית כל ה VMs שרצים עליה!!

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

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

    אתחול של VM הוא מהיר מאתחול של שרת פיסי, מה שמפחית את ה Mean Time To Recover (בקיצור: MTTR) של המערכת. האתחולים המהירים (בעת תקלות תוכנה) מתקזזים עם תקלות החומרה (הנדירות יחסית) של חומרת השרת המשותף – כך שבדרך כלל, וירטואליזציה דווקא מוסיפה לזמינות של כלל המערכת.

    הרצה של תוכנה על וירטואליזציה מספקת יתרונות נוספים:

    • היכולת \"להרים\" שרתים בקלות מפשטת את עבודת ה IT.
    • בזמן שדרוג, ניתן בקלות להרים VM עם גרסה חדשה יותר של התוכנה, במקביל לגרסה הישנה. ניתן להפעיל את המערכות זמן-מה במקביל ו\"לכבות\" את הגרסה הישנה רק לאחר שנצפתה עבודה תקינה של הגרסה החדשה.
    • שיפור הזמינות ע\"י חלוקה: אם ניקח מערכת שהיא easily scalable, למשל שרת ווב, ובמקום VM אחד נציב שני VMs שלו על אותה מכונה פיסית – נקבל זמינות משופרת. אם VM אחד קרס בשל בעיית תוכנה, ה VM השני יכול להמשיך ולספק שירות. כל זאת – עם אותה החומרה (אבל קצת יותר זיכרון).
    • Checkpoints: טכנולוגיית הוירטואליזציה מאפשרת לקחת snapshot של VM מסוים, ואז לשמור את ההעתק בצד – או לשכפל אותו ל VM נוסף. יכולות אלו מקלות מאוד על עבודת ה IT. יכולות אלו מקלות מאוד גם על פיתוח תוכנה: לבדוק את התוכנה על מערכות הפעלה שונות בגרסאות שונות, או מפתח אחד שמתקין את הגרסה החדשה ביותר – ומשכפל אותה שתהיה זמינה לכל חבריו לצוות.

    איך וירטואליזציה עובדת

    הסביבה שמריצה וירטואליזציה של מכונה נקראת Virtual Machine Monitor (בקיצור: VMM) או Hypervisor. מקור השם Hypervisor טמון בהרשאות מערכת ההפעלה שניתנות לה: בעוד ההרשאות הגבוהות במערכת ההפעלה שייכות למשתמש העל (supervisor) – ל VMM נדרשו הרשאות גבוהות אפילו יותר, דרגה מעל ה supervisor, כלומר hypervisor.

    הציפייה מ Hypervisor היא שהוא ימלא 3 דרישות עיקריות:

    1. Fidelity – התוכנה תרוץ על ה VM בדיוק כפי שהיא רצה על מערכת הפעלה שמותקנת ישירות על החומרה.
    2. Safety – תוכנה שרצה על VM תהיה מבודדת מתוכנה שרצה על VM אחר על אותו מחשב פיסי. פעולות שיעשה VM אחד (ניהול משאבים של מערכת ההפעלה, למשל) – לא יפגע בפעילות התקינה של ה VM השני.
    3. Efficiency – התוכנה על ה VM לא תרוץ \"הרבה יותר לאט\" מאשר על הרצה ישירות על החומרה הפיסית. 

    מקורה של הגדרה זו היא במסמך שפרסמו עוד ב 1974 Popek ו Goldberg – חוקרים אמריקאים שהיו חלוצים בנושא הוירטואליזציה. הם גם הגדירו את התנאים שמאפשרים וירטואליזציה. בגדול הם הגדירו 2 קבוצות של פקודות המעבד (instructions):

    • sensitive – פקודות שמבצעיות פעולות IO.
    • privileged – פקודות שיגרמו ל trap אם נקראו ב user mode.

    כידוע לכם (אני מניח), למעבדים יש 2 מצבי עבודה: user mode ו kernel mode. ה user mode נועד לתוכנות שרצות על מערכת ההפעלה (ולחלקים של מערכת ההפעלה) וה kernel mode נועד ל kernel של מערכת ההפעלה ורק בו ניתן לגשת ל I/O או לזיכרון ישירות. לכל mode יש סט פקודות זמין מעט שונה. אם פעולה של kernel mode נקראת ב user mode מתרחש אירוע בשם trap שגורם למעבד לעבור מצב ל kernel mode ואז להפעיל את הפקודה המבוקשת. מנגנון זה מאפשר לתוכנה לרוץ באופן ישיר על המעבד, בלי מעורבות של מערכת ההפעלה, ועדיין למערכת ההפעלה – לשלוט על כל הגישות לחומרה.

    Popek ו Goldberg הראו ש Fidelity בוירטואליזציה יתרחש רק כאשר הפקודות שהן sensitive הם subset של הפקודות שהן privileged (מצב שלא היה קיים במעבדי אינטל – נושא עליו נדבר בהמשך).

    דרך פשוטה ראשונה למשמש hypervisor היא כ interpreter שיפרשן כל פקודת שפת-מכונה של הקוד שרץ, ויחליט מה \"בטוח\" ולשלוח למעבד / מערכת ההפעלה – ובמה הוא רוצה להתערב ולשנות אותו. למשל: פקודת INC (כלומר: Increment) היא בטוחה, פקודה להשבתה של interrupt מסוים מהחומרה – היא לא, כי ייתכן שה interrupt הזה נועד ל VM אחר. בעזרת interpreter נוכל להשיג את דרישות הבטיחות והבידוד – אבל הביצועים יהיו גרועים.

    דרך יותר מעשית, והיא בעצם הדרך המקובלת היא להגדיר את ה Hypervisor כ\"מערכת ההפעלה של מערכת ההפעלה\":

    הדוגמה הספציפית היא ל type1 hypervisors אבל העקרונות נכונים גם עבור type 2 hypervisors עליהם נדבר בהמשך.
    ה hypervisor \"משתלט\" על ה kernel mode של המעבד – כי עליו לתפוס את כל הגישות לחומרה, ומריץ את מערכת ההפעלה המתארחת (Guest OS) ב user mode. פנימית עושים הבחנה בין מערכת ההפעלה שזוכה ל virtual kernel mode (כלומר: מדמים לה שהיא רצה ב kernel mode – למרות שהיא לא) ול virtual user mode – מה שמערכת ההפעלה המתארחת מצפה שיהיה user mode.
    הערה: במעבדי אינטל ספציפית יש 4 modes של ריצה שנקראים ring 0 (המקביל ל kernel mode) עד ring 3 (המקביל ל user mode). מימושים רבים של VMM מעל ארכיטקטורת אינטל פשוט משתמשים ב ring 1 בכדי לתאר את ה virtual kernel mode, כאשר virtual user model פשוט נותר ring 3. יש כאלו שמתארים את ה hypervisor כ ring -1 – אבל לא נכנס לפינה הזו בפוסט….
    כאשר הקוד ב virtual kernel mode (שחושב שהוא ב kernel mode) מפעיל פקודה שהיא privileged אזי יש trap שמעביר את השליטה ל hypervisor.
    כאשר הקוד ב virtual kernel mode מפעיל פקודה שהיא sensitive אבל לא privileged (כלומר: לא גורמת ל trap) אזי תהיה שגיאה וסביר שמערכת ההפעלה תקרוס. אאוץ!

    מצב זה (בו יש פקודות sensitive שניגשות לחומרה, אך לא privileged – לא גורמות ל trap) היה קיים בכמה מארכיטקטורות המעבדים הזמינים בעולם, בניהן הארכיטקטורה הנפוצה ביותר בעולם – i386 של אינטל. אחד מהערכים של אינטל הוא תאימות לאחור (שנוכל על המעבד החדש להריץ אותן תוכנות שרצו על מעבדים ישנים) – מה שגרם למצב בו ארכיטקטורה זו שלא מתאימה לוירטואליזציה השתמרה במשך כמעט 30 שנה. ואיפה סביר יותר שתצמח טכנולוגיית הוירטואליזציה – על מחשבים פשוטים וזולים (אינטל) או מערכות מחשבי-ענק של IBM?

    הבעיה נפתרה לבסוף בשנת 2005 כאשר אינטל, בשיתוף פעולה לא-שגרתי עם AMD, הוסיפו סט פקודות למעבד שפותר את המצב. באינטל מעבדים אלו מסומנים כ VT (כלומר: Virtualization Technology) וב AMD השם הוא AMD-V – אבל בעצם זה אותו הדבר.

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

    הערה: אינטל עדיין מוכרת דגמים בודדים של מעבדים ללא VT – אני מניח שעבור מערכות בהן שינוי זה פוגע בתאימות לאחור.

    מה עשו בעולם האינטל עד הופעת ה VT (ספציפית VT-x)?
    חברת VMWare הציעה פתרון וירטואליזציה כבר בשנת 1999. הפתרון של VMWare סרק את קוד המכונה שנטען ל VM ושינה אותו כך שלא יקראו פקודות sensitive ב user space. אולי זה נעשה ע\"י הרצת פקודה privileged תפלה קודם לכן – אולי בדרכים אחרות. פתרון נחשב פחות יעיל – אך הוא אפשר להריץ וירטואליזציה על מעבדי אינטל ללא VT (לא היו כאלה ב 1999).

    חלק גדול מפתרונות הוירטואליזציה היום (VMWare, VirtualBox, KVM, וכו\') יודעים לעבוד גם עם VT-x וגם בלי יכולת זו – ואז הם מבצעים fallback של שכתוב קוד המכונה למצב שמאפשר וירטואליזציה.

    הפתרון לשכתב את קוד המכונה לאי-שימוש בפקודות sensitive נחשב (מסיבות הגיונית) לפוגע Efficiency של הקוד הרץ על ה VM.
    אם תשאלו בפורום מקצועי את השאלה: \"מה קורה אם אני מריץ את ה VMM שלי ללא VT-x\", סביר שתשובה שתקבלו היא \"אז ה VM יזחל כמו עגלה!\".

    שני חבר\'ה מ VMWare הראו במאמר שפרסמו ב 2006 שמסקנה זו איננה כ\"כ נכונה. לכתוב קוד המכונה לפקודות לא sensitive יש אמנם עלות, אך הוא מפחית את השימוש ב traps במעבד. אירועי ה trap במעבד גורמים ל context switch שמייתר חלק מה caches של המעבד ומשבש חלק ממנגנוני ה prediction, והפחתה שלהם – יכולה להאיץ את הריצה.

    מסיבה זו – היעילות היא לא עניין של שחור או לבן, ולמרות שוירטואליזציה מבוססת חומרה יעילה יותר בד\"כ, יהיו מקרי שימוש ותסריטים בהם דווקא וירטואליזציה מבוססת שכתוב התוכנה – היא יעילה יותר. אם תמצאו בדיקות ביצועים השוואתיות תראו שיש בד\"כ יתרון קטן, אך לא דרמטי, להרצה על VT-X – בשונה ממה שניתן להבין מ\"דיון פתוח\" בנושא. שווה לציין שה Benchmarks בנושא זה (כמו נושאים רבים אחרים) – תלויות מאוד בתסריט והתצורה שנבדקו.

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

    מקור: אינטל

    סוגי Hypervisors

    Goldberg, אותו הזכרנו קודם, הוא גם זה שהגדיר את ההבחנה בין Type 1 Hypervisors ל Type 2 Hypervisors.


    Type 1 Hypervisors משמשים כמעין מערכת הפעלה והם התוכנה היחידה שרצה מעל החומרה / kernel mode. הם פשוטים ובד\"כ אמינים יותר ממערכות ההפעלה[ב] (תכונה שנגזרת מכך יש להם הרבה פחות שורות קוד), והמפתחים שלהם יכולים לבצע אופטימיזציות שלא ניתן לעשות ב Type 2 Hypervisors. לרוב נראה אותם בסביבת השרת – היכן שאמינות ויעילות חשובות יותר

    Type 2 Hypervisors הם תוכנה רגילה שרצה על מערכת הפעלה מסוימת (לינוקס, חלונות, וכו\'), אולי במקביל לתוכנות אחרות, ועדיין מספקת הפשטה של החומרה למערכת הפעלה המתארחת. Hypervisors אלו תלויים (לטובה, ולעתים כמגבלה) בשירותים שזמינים במערכת ההפעלה המארחת (Host OS). כאשר אנו כמפתחים משתמשים בתוכנת וירטואליזציה כדי להריץ VM – זהו כנראה Type 2 Hypervisors.

    למשל, בעולם של VMWare קל למפות את שני סוגי ה Hypervisors השונים:

    • ESX Server (ה hypervisor של חבילת vSphere) – הוא בעצם Type 1 Hypervisors.
    • VMWare Workstation / Player ו Fusion (למק) – הם בעצם Type 2 Hypervisors.

    באופן דומה ניתן לומר שגם VirtualBox (של סאן, עכשיו אורקל) הוא Type 2 hypervisors ו Hyper-V של מייקורוספט נחשב כ Type 1 hypervisor (הוא משולב במערכת ההפעלה).

    KVM (קיצור של Kernel based Virtual Machine), שהוא VMM בשימוש נרחב בעולם הלינוקס, הוא שנוי-במחלוקת מבחינת ההגדרה. הוא נארז כחבילה במערכת ההפעלה (כמו תוכנה hosted) ומקבל ממנה שירותים, אך יש לו גישה ישירה לחומרה (כמו type 1 hypervisor) – וכנראה שהוא נהנה מיתרונות דומים. ההגדרה, כמו הרבה הגדרות – היא טובה עד נקודה מסוימת.

    Paravirtualization

    עוד סוג של Hypervisors שקיימים הוא Hypervisors של Paravirtualization (\"מעבר-לוירטואליזציה\"). סוג זה של Hypervisors מנסה לשפר את ה Efficiency של הרצת ה VM, על חשבון מעט מה Fidelity. הרעיון הוא שהתוכנה שרצה על ה VM תהיה מודעת לכך שהיא שרצה בוירטואליזציה. ידע זה יתורגם לכמה קריאות API (נקראות Hypercalls) שבהן היא תשתמש במקרים מסוימים – שיאפשרו תהליך יעיל יותר של ההרצה. לרוב, מי שמודע לכך שהוא מתארח על סביבת ה Paravirtualization הוא מערכת ההפעלה המתארחת (ולא התוכנה שרצה עליה) והיא משתמש ב hypercalls לפעולות כמו עדכון הזיכרון הוירטואלי – פעולות שיכולות להיות פשוטות ומהירות יותר במידה והן נעשות בתיאום עם ה hypervisor.

     עוד נושא שמנסים להתמודד איתו ב Paravirtualization הוא העניין של \"זמן אמיתי\". מערכת ההפעלה המתארחת חושבת שהיא רצה על החומרה, ולא מודעת לכך שהיא משתפת את המעבד / I/O עם מערכות הפעלה אחרות – מה שגורם לפער בתפיסת הזמן (time) שלה. אם היא מסנכרת את תפיסת הזמן שלה בעזרת ה API (היעיל) של ה Paravirtualization Hypervisor – בעיה זו יכולה להיפתר.

    Hypervisor ידוע שעובד ב Paravirtualization הוא Xen של חברת Citrix, הזמין גם בגרסה חינמית (אך ללא עדכונים אוטומטיים).

    מקור: VMWare

    Operating System-level virtualization

    בנוסף לנושא ה Efficiency של ה VM, שתמיד נמוך מהרצה ישירה על החומרה, עניין שמתסכל את המשתמשים בוירטואליזציה הוא נושא ניצולת המשאבים. הבעיה לא גדולה אם אני מריץ VM אחד על המחשב הפיסי, אך מה אם אני מריץ עשרה?
    נאמר שאני מריץ 10 VMs של לינוקס בגרסה זהה – זה אומר שכל השירותים של מערכת ההפעלה רצים 10 פעמים, הקוד שלהם נטען לזיכרון 10 פעמים, ומבני הנתונים שהם מנהלים – מנוהלים 10 פעמים. זהו מחיר ה isolation בין ה VMs – וזה מחיר יקר.

    VMWare, למשל, בנתה מנגנון שיודע לשתף דפי זיכרון בין VMs. כל עוד תוכן דף הזיכרון זהה – ה hypervisor יספק את אותו הדף לכמה VMs, וברגע שהוא משתנה – יפצל את הניהול וכל VM יקבל את העותק שנכון בשבילו. כפי שאתם מבינים יש כאן חסכון בכפילות משאבים – אך במחיר זמן הריצה.

    את הניסיונות לפתור את בעיית המשאבים – מנסים לפתור ה Linux Containers: להיות משהו יותר רזה מ VMM, אך יותר מקיף מניהול תהליכים במערכת ההפעלה, שה isolation שלהם מוגבל, וחלוקת המשאבים (למשל priority של תהליך) – לא מדויקת.

    המסע ל Linux Containers התחיל במנגנון בשם chroot שהוצג על Unix7 בשנת 1979 (כבר אמרנו בפתיחה שוירטואליזציה היא לא דבר חדש). chroot יצר סביבת ריצה מעט שונה לכל תהליך – והתמקד בשיקולי אבטחה בין תהליכים. הוא בעצם שינה את ה root folder של כל תהליך כך שיראה רק אותו שלו של התיקיות, ולא יוכל להשפיע על תהליכים אחרים (ע\"י גישה לקבצים שלהם, למשל). הסביבה שנוצרה לתהליך נקראה chroot jail, שם שליווה עוד פתרונות דומים אחרים (למשל FreeBSD Jail – \"כלא BSD החופשי\" 🙂 )

    עם השנים, היכולות התפתחו, והמיצוב נעשה ידידותי יותר: לא עוד jail אלא container.
    מערכת ההפעלה לינוקס פיתחה יכולות ברמת הקרנל בכדי לתמוך באותם containers: בהתחלה cgroups (אריזת כמה תהליכים לקבוצה והקצאת משאבים מבוקרת לקבוצה) ולאחרונה LXC (קיצור של LinuX Containers, מבוסס על cgroups).

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

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

    תמורת פשרות הללו מקבלים Efficiency כמעט של מערכת ללא וירטואליזציה בכלל, וניצולת משאבים טובה הרבה יותר (דיסק, זיכרון, וכו\') מכיוון שרצה רק מערכת הפעלה אחת. ה mitigation לקריסת מערכת ההפעלה הוא בד\"כ להריץ על containers יישומים ב cluster על גבי כמה מחשבים פיסיים שונים, או להריץ תהליכים שה availability שלהם הוא לא קריטי.

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

    Docker

    LXC הוא בסיס טוב ל\"וירטואליזציה רזה\", אך הוא עדיין בסיסי לשימוש. מעליו צמחו פתרונות שונים לניהול workflows וניהול שוטף של העבודה. ללא ספק, הכלי שצמח הכי מהר בתחום זה הוא Docker. אם אתם עובדים בסביבת ענן / DevOps ולא שמעתם את השם הזה עד עכשיו – תבדקו את המקורות מהם אתם מתעדכנים.

    הקהילה (development community) של Docker היא מהמתפתחות במהירות הגבוהה ביותר בעולם הקוד הפתוח. בעת כתיבת הפוסט הפרויקט הוא בן משנה וחצי (החל במרס 2013), אך שימו לב לפופולריות שלו ב Github:

    כ Benchmark (הוגן, אני מקווה) בחרתי ב Chef – פרויקט באותו הדומיין פחות או יותר (אוטומציה של ניהול תצורה), פופולרי למדי, ושקיים כבר כ 5 שנים:

    אין דברים כאלו!

    ההתלהבות מ Docker היא קצת מעבר ל Github עצמו:

    • האגדה מספרת, שחברי הפרויקט החלו לעבוד ב Github בצורה ציבורית – ופתאום שמו לב שיש להם עשרות תורמים שהם לא מכירים (לרוב פרויקטי ה Open Source יש תורם משמעותי אחד).
    • יש כבר סטארט-אפים שסובבים סביב Docker: רשימת 10 הסטארט-אפים הטובים ביותר הבנויים מסביב ל Docker.
    • יש כבר כמה חברות שהחליטו לאמץ אותו כרכיב מרכזי בתשתית שלהן (למשל eBay, Rackspace, או Cloudflare).

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

    Docker מאפשר:

    • לבנות containers של הקוד שלכם מתוך סקריפט.
    • לנהל את הגרסאות השונות של ה containers ב repositories שונים.
    • לבצע deploy קל container על שרת שהוגדר.
    • להעביר בקלות container רץ משרת אחד לשרת אחר (עבוד Continuous Delivery, פיזור עומסים, או סתם כדי להעביר אותו לסביבה מעודכנת יותר).

    Docker עוזר לנהל כמה מהמגבלות של Linux Containers ולהפוך אותן למגבלות קטנות יותר. סביבות ניהול משוכללות כבר קיימות לפתרונות וירטואליזציה (למשל VMWare vSphere), אך לא כ\"כ ל Linux Containers – ובחינם. Docker הוא הבסיס לכזו סביבה, ויש לא מעט סטארט-אפים שמנסים להפוך אותו לסביבת ניהול שלמה. כפי שאמרנו Docker מתבסס היום על LXC, אבל בפרויקט כבר מדברים על אפשור היכולות שלו עבור סביבות וירטואליזציה שונות כגון Xen, KVM, או אפילו Hyper-V (של מייקרוסופט).

    הציפיות מ Docker הן דומות לאלו שהיינו מצפים היו ממכולות התובלה: לשנות את פני ניהול ה Data Center בצורה שתהפוך אותו לדבר שונה ממה שאנו מכירים אותו היום.

    סיכום

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

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

    למרות הדימוי ה\"בשל\" שיש לטכנולוגיות הוירטואליזציה – יש גם הרבה חידושים. התפר בין וירטואליזציה ל Operations הולך ומתטשטש ויש פתרונות שונים – לצרכים שונים.
    היום בו יהיה VM אחד דומיננטי בו כולם ישתמשו (למשל VMWare) – נראה רחוק מתמיד.

    עוד נושא קרוב, שלא דיברנו עליו בכלל הוא SDN – קיצור של Software Defined Network, תחום שעוסק בוירטואליזציה ואוטומציה של הניהול (המורכב) של הרשת. נשאיר משהו לפוסטים עתידיים.

    שיהיה בהצלחה!

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

    [ב] מאמר מפורסם בנושא הוא \"?Are Virtual Machine Monitors Microkernels Done Right\"




    חומרה: מבט מפוכח על מהפכת ה SSD

    טוב, אני יודע שרוב הקוראים של הבלוג הם אנשי תוכנה. מה לעזאזל יש למתכנת הג\'אווה / #C להתעסק בברזלים של המחשב שמתקין בכלל איש ה-IT?
    \"מבחינתי שיהיה בצבע ירוק עם כוכבים, העיקר שהקוד של IFile יעבוד\" – יכול לומר מתכנת אפליקציה שאינה דורשת ביצועים גבוהים.

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

    הנה 37Signals הראו שלא תמיד זקוקים לארכיטקטורה מתוחכמת כדי להשיג Internet Scale, צריך רק טרה זיכרון וכונני SSD על כל מכונה. רגע! טרה זיכרון?? – מסתבר שטרה זיכרון עולים כיום 12 אלף דולר – משכורת וחצי של מתכנת בארה\"ב.

    חכו רגע… אני שומע קולות ביקורת:
    \"בעיות ביצועים יש לפתור בתוכנה – לא בחומרה\"
    \"הממ לא מבינים כלום, זה טוב להתחלה – אבל הם לא ישרדו\"
    \"SSD יקרים מדי\"
    \"SSD נשחקים. פתאום כל המידע שנשמר עליהם יעלם – ואז מה?\"

    נכון ל 2007, היו ל BaseCamp, המוצר המדובר, 2 מיליון משתמשים ויותר ממליון פרוייקטים שמנוהלים בו. אני מהמר שאתם יכולים להכפיל, נכון להיום, את המספר פי  חמש עד עשר.
    להשקיע 200 אלף דולר בעבור כל השרתים ולחסוך רה-ארכיטקטורה שיכולה לקחת שנים – נשמע לי דווקא עסקה טובה.

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

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

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

    בראש אצים-רצים המעבדים, המכפילים את כוחם פי 2 כל 18 חודשים, או פי 100 בעשור. כיום הם כ\"כ מהירים כך שהם הפכו במידת מה למשאב עודף: רוב המחשבים הבייתיים לא זקוקים ליותר מהמעבד הבסיסי ביותר. \"גיימרים\" משקיעים את כספם במאיצים גרפיים במקום במעבד ובחוות השרתים יש מגמה לקנות המון זיכרון על חשבון כח העיבוד (כל נושא ה In Memory Database).
    אינטל – שחייה ממכירת מעבדים החלה להוסיף יכולות של כרטיס גרפי ישר לתוך ה CPU ולהתמקד בצריכת חשמל נמוכה [1]. מהירות המעבד הפכה כמעט ל Commodity.

    מקום שני אצה-רצה הרשת, עם קצב גדילה של מרשים 50% בשנה או פי 57 בעשור.
    אמנם הרשת החלה בנקודת פתיחה אומללה (למי שזוכר מודמים של 1200 סק\"ש – שבהתחשב בסיביות הביקורת זה 120 בתים בשנייה) – אך היא מתקדמת בקצב מרשים ביותר וכיום: \"אצלנו – אינרנט של 20Mbps זה סטנדרט!\" [2]

    מקום שלישי נמצאים הכוננים הקשיחים. אין לי נתונים מדוייקים, אך שיערוך גס שעשיתי מכמה גרפים מציג התקדמות בקצב ההעברה (transfer rate) של פי 15 עד 20 בעשור. קצב העברה של כוננים מגנטיים דיי נבלם בשנים האחרונות והוא עומד על כ 100MBps בערך [3]. יש לציין שנפח האיכסון, פרמטר חשוב אחר, גדל מעריכית ובקצב גדול בהרבה – בערך פי 100 בעשור.

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

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

    מהו כונן SSD? (בקצרה)
    SSD (קיצור ל Solid State Drive) הם כוננים מבוססי טכנולוגיה של זכרונות פלאש (בניגוד לדיסקים מגנטיים).
    מכיוון שאין להם חלקים מכניים הם שקטים יותר, צורכים פחות חשמל, ויכולים לספוג זעזועים קשים מבלי להפגע (לא באחרויותי!).

    ברשת ניתן להתקל במספרים לא מבוקרים שמצוטטים גם באתרי חדשות חשובים כגון \"SSD מהיר פי 1000 עד 10000 מכונן קשיח רגיל\". זה לא מקרה נדיר שאתרי חדשות מובילים מפרסמים מידע לא רציני. את הדיוק העיתונאי הם שומרים בעיקר למדור הפוליטיקה – שם יקנסו ב 300 אלף ש\"ח על כל טעות – על פי חוק חדש. אם תתקינו כונן SSD חדיש במחשב שלכם תזכו לזמן טעינה של תוכנות הקצר בממוצע פי 2. כלומר, וורד יטען ב 2 שניות במקום ב 4 שניות. מי שקנה כונן SSD בעקבות כתבה \"מהיר פי 1000 ויותר \" פשוט עלול להתאכזב.

    שלא תבינו לא נכון: קרוב לוודאי ש SSD הוא השדרוג הכי משמעותי שאתם יכולים לבצע כיום במחשב שלכם.

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

    הבלוף של יצרני ה SSD (או למה RAID 0 מת)
    עם הזמן, הופכים כונני ה SSD למוצר שיכול לרכוש גם המשתמש הביתי / הסטארט-אפ הקטן. בפחות מ 1000 שקל ניתן לקנות כונן בגודל 120GB שיכול להגיע לקצב קריאה של כמעט 600MBps! פי שש מכונן מגנטי מהיר!

    SSD – שימו לב כמה זמן הגישה הוא מהיר! כך זה שכל מה שזקוקים לו הוא זרם חשמלי ולא זרוע מכנית שצריכה לנוע.

    ווהו וואו – בטח אתם חושבים לעצמכם \"אני אהיה ממש טיפש עם לא אקנה אחד כזה\". \"אולי אפילו אקנה שניים\".

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

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

    מקרא: Sequential – הוא קצב קריאה רציפה (נאמר קובץ של 1M ומעלה) ויש גם נתונים על קריאה של קבצים קטנים יותר.

    מקור: theSSDReview.com

    מקור: theSSDReview.com

    ברור לי שאתם קוראים נבונים ותבחרו את הדיסק שמופיע במסגרת הכחולה. בעוד כונני SSD מציגים קצב קריאה של 500MBps לקריאה רציפה – נתון זה הוא לא מעניין כי פחות מ1% מהפעילות הרגילה של כונן קשיח היא פעילות על קבצים בגודל 512K ומעלה (למשל: העברת סרט וידאו מדיסק לדיסק. בתוך אותו הדיסק השינוי הוא רק ברישום של מערכת הקבצים) קריאה וכתיבה של קבצים בגודל 4K קוראת בקצב של עשרות MBps בכוננים המהירים ביותר.

    שני נתונים החשובים על מנת להבין את התמונה השלמה:

    • דיסק מגנטי קורא קבצים בגודל 4K בקצב של פחות מ 1MBps.
    • בשימוש ממוצע בכונן הקשיח – כ 70% מהפעולות הם על קבצים (ליתר דיוק \"בלוקים\") בגודל 4K או 8K – כך שנתון זה הוא בעל משמעות מכריעה.
    כאשר מציבים את המשקולות של אחוזי השימוש – ברור למדי שדיסק קשיח יש לבחור ע\"פ פעולות הכתיבה של בלוקים (\"קבצים\") בגודל 4K ו 8K.
    כונן SSD לא יעתיק קבצי ענק בצורה מהיר הרבה יותר והוא לא יגרום לתוכנות להטען מהר הרבה יותר.
    אך אם יש לכם בסיס נתונים או Cache שמבצע המון פעולות קריאה וכתיבה של בלוקים קטנים וללא הרף – ההבדל המעשי הוא בין כ 300 פעולות לשנייה האפשריות על דיסק מגנטי מהיר במיוחד מול כמה עשרות אלפי פעולות לשנייה האפשריות על דיסק SSD מהיר במיוחד. פאקטור של פי 100-200 יותר פעולות. מהפכה.

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

    אם הייתי עושה זאת הייתי מתאכזב מ 2 סיבות:
    א. בשעה 11 וחצי בלילה קשה למדי למצוא מישהו שימכור לי כונן SSD.
    ב. אם הייתי שם את המערכת שלי על כונן SSD ממוצע במחיר 1000 ש\"ח קרוב לודאי שהוא לא היה שורד חצי שנה. יותר גרוע: הוא היה הופך איטי יותר ויותר ופתאום המידע היה נעלם.  חתיכת באסה!

    רק בן חצי שנה – אבל נראה כמו בנג\'מן באטן

    העניין הוא שכונני SSD עוברים שחיקה מהירה.

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

    בכל מקרה עבור מחשב ביתי, אפילו כונן ללא תמיכה ב TRIM עשוי לשרוד כמה שנים בצורה סבירה [4].
    עבור מחשב לעבודה כדאי בהחלט שתהיה תמיכה ב TRIM.
    עבור שרתים גם TRIM לא יעזור: שרת שעובד 24×7, והכונן מאפשר לו רבבות של פעולות בשנייה – הולך לשחוק את הכונן בקצב מהיר.

    לעצם כך ישנם כונני SSD המוגדרים כ Enterprise Class – כוננים אשר לרוב משתמשים בטכנולוגיית SLC היקרה והנשחקת פחות ומשתמשים ב\"ספיירים\" של תאי זיכרון – ומתוכננים להחזיק מעמד כמה שנים תחת עבודה ממושכת. הם יעלו בערך פי 4 יותר, אם מדובר בשרת ממוצע. עבור מקרי קצה של כתיבה אינטנסיבית במיוחד ודרישות לכונן יציב כסלע – טושיבה תמכור לכם כונן 400GB אותו תוכלו לטחון ללא-אבחנה במשך 11 שנה במחיר פעוט של 7000$ לחתיכה.

    וריאנטים אחרים של כונני SSD לשרתים יכולים לספק מהירויות גבוהות במיוחד ולרוב מתחברים ישירות לחריץ ה PCI-Express על מנת לדלג על בקר הדיסקים (חיבור SATA) על מנת לספק בערוץ ישיר נתונים לתוך המעבד במהירות מסחררת.

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

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

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

    ייתכן ויהיו שימליצו לכם \"לקנות דיסק SSD עבור מערכת ההפעלה\". זוהי גישה מיושנת (אולי בת שנתיים) ולא כ\"כ יעילה – רוב רובם של הקבצים של מערכת ההפעלה שוכבים כאבן שאין לה הופכין. הכנסו למשל בחלונות 7 לתיקיה C:\\Windows\\winsxs והסבירו לי מה מאכסנת שם מערכת ההפעלה בנפח של קרוב ל 10GB.

    הגישה החדשה יותר (שנות העשרה) היא לתת לתוכנה לסדר לכם את הקבצים בהם משתמשים בתדירות גבוהה על ה SSD בעצמה: הקבצים אליהם ניגשים הרבה – על SSD וכל השאר – על הדיסק הגדול והאיטי. ניתן לעשות זאת בעזרת כונן SSD יעודי לתפקיד Caching כגון OCZ Synapse או Crucial Adrenaline המסופקים עם תוכנה מתאימה [5].

    ישנם כוננים המגיעים בחבילה אחת האורזת דיסק מגנטי ודיסק SSD כגון Seagate Momentus XT (מה שנקרא דיסק היברידי – אם אחרי הפרסומות לבנק מזרחי אתם יכולים עוד להתייחס למילה הזו ברצינות).

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

    עדכון 11.11.12: אפל הציגה גרסה משלה לכונן היברידי.

    כך נראה הדיסק ההיברידי הראשון. פשוטו כמשמעו.

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

    בסיסי נתונים ימשיכו להזרים מזומנים לקופות יצרני ה SSD הגדולים על מנת לשמר שרת יחיד לבסיס הנתונים – פיתוח מערכת מבוזרת עדיין תעלה יותר מכל מכל SSD שהם יכולים להציע…

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

    [1] היום, בחדרי השרתים, בוחרים מעבדים ע\"פ כח חישוב לוואט. על כל וואט משלמים לא רק בחשבון החשמל. מכיוון שקירור הוא כבר קרוב לאופטימום על וואט עולה גם בחשמל של מערכת המיזוג ובנדל\"ן – יש גבול כמה ניתן לקרר מטר מעוקב מבלי שהעלויות יזנקו.

    [2] חבר סיפר לי שבקליפורניה, לפני שנתיים, 100 מגה היה דיי מקובל בקרב חובבי מחשבים. הנה נתונים עולמיים של הממוצע הביתי. לא שחשבתי שלקחתם את הפרסומת ברצינות.

    [3] יש להבחין שנפח איכסון / קצב העברה של רכיבי אכסון נוהגים למדוד בבתים בשניה (Bps), בעוד מהירות של רשת מודדים בביטים לשנייה (bps) – מידה הקטנה פי 8 (כי יש 8 ביטים בבית). יש לשים לב האם האות B היא קטנה או גדולה על מנת לא להתבלבל.
    לכן, כשאתם גולשים באינטרנט \"5 מגה\", או 5Mbps, – אתם יכולים להעביר רק \"625KBps\".

    [4] שחיקה זו היא הסיבה מדוע ממליצים לא לבצע Defrag על כונני SSD. התמורה מאיחוד קבצים היא זניחה עבור כונן SSD (שקורא קבצים קטנים במהירות) – והשחיקה היא רבה.

    [5] התוכנה, בשם Dataplex, יודעת לנהל ברזולוציה אפילו יותר מדוייקת מקבצים: רזולוציה של בלוקים של מערכת הקבצים – שגודלם לרוב 4K.