הבלוג של חץ ביז

נקודות למחשבה בעת קניית סטורג' – חלק שני

בחלק הראשון של הפוסט דיברתי בכלליות על סוגי פתרונות שקיימים, גדילה (Scale Up או Scale Out) והתייחסות לצוות שיווק (Pre Sales).

בעסק קטן עם נניח 1-2 שרתים ועוד כמה Share ל-Windows, המחשבות וההתלבטויות לגבי קניית פתרון אחסון הם אינן גדולות. קונים NAS טוב, דיסקים, מגדירים את הכל ומתחילים לעבוד. בד"כ הפרמטרים הכי חשובים שם זה מהירות מספקת לצרכי עבודה ומחיר טוב. בד"כ פתרון NAS טוב נותן את הדברים שהעסק שצריך החל מ-CIFS, iSCSI, שרידות מינימלית וזהו.

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

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

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

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

DeDuplication (או DeDup בקיצור): כשאנחנו משתמשים בוירטואליזציה, אנחנו מקימים מכונות VM רבים שיש בהם את אותה מערכת הפעלה ואותם קבצים. פונקציונאליות ה-DeDup מזהה חלקים זהים והיא "רושמת לעצמה" היכן נמצאים החלקים הזהים (ברמת Block או קבצים) אך היא שומרת עותק יחיד (במקרים מסויימים 2 עותקים) של אותם אזורים זהים, ובכך המערכת חוסכת מקום בסטורג'. ככל שיש יותר חלקים זהים, המערכת חוסכת יותר מקום.
Compression (דחיסה): פונקציואנליות נוספת "שכנה" של DeDup היא הדחיסה. יצרניות סטורג' שונות מאפשרות להקים Policy (שוב, ברמת בלוק או קבצים) המאפשרת דחיסה של נתונים שונים ופריסתם ברגע שצריך את הנתונים (הדחיסה והפריסה הם "שקופים").
Thin Provisioning: כשיש צורך בהקמת LUN (או משאב אחר הקשור בהקצאת שטח אחסון לטובת פרוייקט כלשהו) יש באפשרותנו להקצות חלק משטח האחסון ב-2 שיטות עיקריות: Thick Provisioning ו-Thin Provisioning. ב-Thick כל השטח המתבקש מוקצה מיידית לטובת אותו LUN לדוגמא ואילו ב-Thin יש רק "הכרזה" במערכת כי LUN X יקבל כך וכך שטח אך במציאות הוא מקבל מעט מקום ובכל פעם שיש צורך בעוד מקום, אותו LUN יקבל את מבוקשו עד גובה ההכרזה הראשונית. היתרון ב-Thin Provisioning הוא שאין צורך מיד "לכסח" חלק גדול ממקום האחסון אך החסרון הוא שכל בקשה לוקחת מעט יותר זמן (דבר שיכול להיות קריטי למערכות כבדות כמו שרת SQL וכו'). היתרון ב-Thick הוא בכך שיש את השטח לאפליקציה זמין כל הזמן והגישה היא יותר מהירה.
Snapshots: כל חברה נורמלית דואגת לגיבוי יומי של כל הנתונים בשרתים ובסטורג', אך הבעיה עם גיבוי ושחזור – זה ששחזור לוקח זמן. לעומת זאת, Snapshot מייצר "צילום" עכשוי של אחסון ספציפי (LUN או משאבים אחרים לדוגמא) וכך אם לדוגמא אנחנו משדרגים מערכת שמשתמשת ישירות בסטורג' ואיננו מרוצים מהתוצאה, אנחנו יכולים "לקפוץ אחורה" אל ה-Snapshot במקום לשחזר מהגיבוי, ופעולת החזרה אל ה-Snapshot היא מאוד מהירה.
Disaster Recovery: נשרף הראש, קרתה תקלה באחד הבקרים – מהי הדרך לשחזר, האם קיימת כזו, מה הזמן שלוקח לשחזר?
Tiering – עם Tiering פתרון האחסון עובד ב"שכבות" והוא מעביר קבצים לפי השימוש שלהם, כלומר אם יש לנו קבצים שיש בהם צורך מדי יום, הוא יאחסן אותם בדיסקים הכי מהירים שיש במערכת ואילו קובץ שקוראים אותו אולי פעם בכמה חודשים – עובר להישמר באחסון הכי איטי שיש (דיסקים SATA), ובכך המערכת מגיבה הרבה יותר מהר כי הקבצים שיש בהם צורך תכוף נמצאים בדיסקים הכי מהירים שיש.
IOPS – המושג שמשתמשים בו הכי הרבה בתחום הזה. כמה IOPS הסטורג' נותן בכתיבה ובקריאה? אל תתפתו להאמין לנתוני שיווק! דרשו מסמך התחייבות לכמה IOPS הפתרון נותן ומתי.

נקודות חשובות נוספות שכדאי לבדוק:

כמות תושבות PCIe: לפעמים יש צורך להכניס עוד כרטיסים לסטורג', כמו להוסיף כרטיסי תקשורת וכו'. כמה מקומות יש, אם בכלל?
כמות דיסקים וסוג: כל סטורג' יכול להכיל כמות מסויימת של דיסקים ולא מעבר לכך, ולכן חשוב לדעת מהי המגבלה, וכמו כן אלו דיסקים מתקבלים: SAS, NL-SAS, NVME, FC, SATA…
מעבדים מסייעים: בכל סטורג' היום נמצא מעבד Xeon כלשהו, והשאלה החשובה היא האם קיימים מעבדים מסייעים לעבודות שונות, כמו Block Storage Processor שלוקח עליו את העבודה בכל הקשור ל-Block Storage. קיומם של מעבדים כאלו במערכת מסייע מאוד בעבודה מהירה.
עדכונים ועדכוני אבטחה: בכל סטורג' חדש תקבלו עדכונים בשנתיים שלוש הראשונות כולל עדכוני אבטחה. השאלה החשובה היא מה קורה לאחר התקופה הזו. האם היצרן מתחייב לפרסם עדכוני אבטחה גם לאחר שלוש שנים? אם כן, לכמה זמן?
המשכיות: קניתם פתרון סטורג' מהיצרן ולאחר 3-4 שנים החלטתם לשדרג לדגם אחר – האם אפשר להשתמש בציודים הקיימים (מדפים ודיסקים) בציוד העתידי או שצריך הכל מחדש?
הדרכה/שרות/SLA: האם יש הדרכה רשמית שמדריך מגיע לחברה ומלמד את צוות ה-IT או שזורקים עליכם כמה קבצי PDF ותסתדרו? וכשזה מגיע לשרות – מה ה-SLA? זיכרו: במקרים רבים, כש-SLA לא מצוין, מדובר על יום העסקים הבא (NBD), וזה קורה במיוחד כשמוכרים לעסקים קטנים, קחו את זה בחשבון.

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

נקודות למחשבה בעת קניית סטורג' קנייני (סגור)

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

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

פתרונות סגורים לעומת זאת – הם הרוב המוחץ כרגע בישראל, החל מפתרונות NAS פשוטים לעסק הקטן, המשך בפתרונות SAN עם חיבורי FC (כלומר Fiber Channel) וכלה בפתרונות המכילים לא רק את שכבת הדיסקים/LUN וכו' אלא גם פתרונות לפרוטוקולים כמו NFS/CIFS ולאחרונה פה ושם ישנם פתרונות שמציעים בנוסף גם Object Storage. מכיוון שכל יצרן נותן לזה שם מפוצץ אחר, נקרא להם בפוסט זה "פתרון משולב".

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

צריך NFS/CIFS?
אם נקנה מחר פתרון SAN שכל מה שהוא נותן לנו זה iSCSI, אנחנו לא נקבל שרותים כמו CIFS/NFS. זה נראה חסרון קריטי במבט ראשון, אך מצד שני לא חסרים Appliance וירטואליים (שרצים כמכונות VM) שיתנו את אותן פונקציונאליות, בין בפתרון מבוסס קוד פתוח, או פתרון סגור לחלוטין. אותם Appliance עולים כסף (למעט אם הקמת מכונת לינוקס ובחברה יגדירו את הדברים) אך במקרים רבים אותם Appliances יעלו פחות מרשיון CIFS או NFS ופחות מפתרון משולב וישנם גם Appliances שעובדים כצוותא בצורה מעולה כ-Cluster (אקטיבי/אקטיבי או אקטיבי/פאסיבי). אפשר כמובן גם להשתמש ב-Windows עצמו כשרת קבצים לדוגמא (אם כי אינני בטוח שזהו פתרון טוב לאלפי חיבורים סימולטנית). חשוב לזכור: לא חשוב כמה הסטורג' יהיה יקר, מימוש דברים כמו NFS/CIFS מבוצע בתוכנה בלבד והכל עניין של מימוש. יש מימושים טובים יותר ויש מימושים טובים פחות הן ב-Appliances והן בסטורג'.

פתרון Cluster?
פתרון Cluster הוא פתרון מעולה לשרידות, הכל נכתב כפול ואם אחד נופל, השני ממשיך לתת שרות וכשאותו אחד שנפל הוקם, יש סינכרון ביניהם מבחינת קבצים. הבעיה בד"כ? המחיר. אם נניח פתרון סטורג' יחיד עולה 40,000$ (סתם זורק מספר), פתרון Cluster יעלה הרבה יותר מ-80,000$ בגלל הרשיון. על זה אפשר להתגבר כמובן, אך הבעיה המרכזית שבגינה חברות מחליטות לעבור לפתרון סטורג' אחר – הינם מחירי ההרחבות. אם נרצה להוסיף מגש, נצטרך כפול (וכמובן כפול דיסקים). מגש האצה? אותו דבר. אם תסתכלו באינטרנט על מחירי דיסקים ל-Enterprise (ולא משנה אם מדובר בדיסק מכני או SSD) – אתם תוכלו למצוא בכל מיני אתרים גרפים שמראים על ירידות מחירים, בשעה שאצל יצרני סטורג' אין כמעט דבר כזה. דיסק עולה 700$ היום והוא יעלה 700$ (אם לא יותר) גם עוד חודש. בלא מעט מקרים, כשלסטורג' יש כבר מעל שנתיים או שלוש "ותק" – תראו יותר ויותר חברות שכבר מוכנים לקחת סיכון ולקנות דיסקים ממקור חיצוני אחר ולא ספציפית מהיצרן (חשוב לשים לב שפורמט הסקטורים יכול להיות שונה, כמו במקרים של NetApp אם כי יש כלים בלינוקס שיכולים לשנות את פורמט הסקטורים למה שתרצו ובכך להשמיש דיסק "זר" לסטורג').

מעבר לפתרון Scale Out
מדי פעם אני נשאל "מתי לדעתך כדאי לחשוב על מעבר לפתרון Scale Out?" ותשובתי היא פשוטה: כמה טרהבייט של מידע יש לך? ככל שכמות המידע שלך גודלת ועוברת נפחים של עשרות טרהבייטים (נניח 80-100) – יהיה כדאי לחשוב על פתרון Scale Out.
בפתרונות Scale Out דברים רבים "נזרקים" החוצה בהשוואה לעולם הסטורג' עם ראש אחד או כפול. כך לדוגמא, כל האחסון מבוצע על שרתים (אם כי תמיד אפשר לחבר להם JBOD). ליצרן התוכנה לא משנה ממש איזה שרתים יש לך (כל עוד הם עומדים בפרמטרים מסויימים) וגם את הדיסקים אתה יכול לרכוש בעצמך מאיזה גורם שתרצה. ב-Scale Out עובדים יותר דרך Ethernet (או Infiniband – תלוי בכם) בחיבור Copper או סיבי (החלטה שלכם) כאשר הרשת בין השרתים צריכה להיות מינימום 10 ג'יגהביט (מומלץ יותר 40 או 50 ג'יגהביט). לא חייבים שהכל יהיה Flash אבל צריך כמה וכמה דיסקים SSD ומה שהכי חשוב – הכל מבוסס תוכנה וכאן מגיע שלב מעניין: רוב מוחלט של המשתמשים ב-Scale Out אינו פוסל פתרון מבוסס קוד פתוח (כמו CEPH) ומבחינת פונקציונאליות – מה יש לקוד הסגור, יש גם לקוד הפתוח. כמובן שאינני ממליץ להוריד מהאינטרנט ולהתקין אלא לרכוש את התוכנה (תצטרכו תמיכה, האמינו לי) כך שבסופו של דבר השיקול העיקרי כאן הוא המחיר רשיון ופחות מחיר שרתים (אין שום בעיה להשתמש בשרתים מדור קודם או לפניו).
עוד נקודה שחשוב לזכור בכל הנוגע ל-Scale Out: אם צריך יותר ביצועים, לא מרחיבים יותר זכרונות / מחליפים למעבדים מהירים יותר – אלא מוסיפים כל פעם שרתים נוספים שיריצו את התוכנה, וכך גם כמות המקום הפנויה גודלת והביצועים גדלים.

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

קצת על קורסים ללינוקס

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

אבל לפני כן, הבה נסתכל על קורסים, לאו דווקא על לינוקס. יש לא מעט קורסים על מוצרי מיקרוסופט, אורקל, VMWare, ועל מוצרים רבים אחרים. המכנה המשותף של כולם – מה שאותם לומדים בכיתה ומתאמנים במחשבים בכיתה, מתאמנים במחשבים ובבית ובמה שתעבדו בחברה – המוצר יהיה זהה לחלוטין. ה-Windows Server שלמדתם עליו בקורס? אותו דבר בעבודה, אותם פקודות, ומה שלמדתם תוכלו ליישם מיידית עליו.

בלינוקס – זה שונה. ישנה חלוקה די ברורה של הפצות לינוקס: רד-האט ו-CentOS תמצאו בחברות, אובונטו יותר בסטארטאפים, SuSE מתחילה להיכנס יותר לארץ ו-Debian בד"כ אצל הוותיקים (כמו תמיד, מלחמות הפצה קיימות מכאן עד הודעה חדשה, אבל זה נושא לפוסט אחר). כך לדוגמא יכול להיות שתוכנה מסויימת בגירסה X קיימת כחבילות מוכנות להתקנה על אובונטו אך אותן חבילות לא ירוצו על הפצת לינוקס אחרת (ולמתחכמים: כן, קיים כלי בשם alien שממיר חבילות, אבל לא תמיד זה עובד וזה ממש לא משהו קל לשימוש למישהו שרק התחיל אתמול ללמוד לינוקס). פקודות התקנת חבילות הן שונות, בלא מעט מקרים גם קבצי ההגדרות לתוכנות פופולריות כמו Apache או NGINX נמצאות במיקומים שונים ובחלק קטן מהמקרים – גם ההגדרות עצמן שונות ואפילו התקנת הלינוקס שונה: כשמתקינים לדוגמא רד-האט או CentOS עם הגדרות ברירת המחדל, המערכת תפרמט את הדיסק לווליומים שונים כך שאם תרצה להוסיף מחר דיסק קשיח, תצטרך פשוט להגדיל את הווליום ולגמור עניין בשעה שחלק אחר מההפצות כלל לא טורח לעשות זאת וכשצריך להוסיף דיסק – צריך להעביר קבצים, ליצור קישור בין תיקיות ולבצע שלל פעולות אחרות.

לכן, כשלומדים לינוקס, צריך קודם כל לדעת לבחור מה לומדים. אם לדוגמא הקורס הוא מבוסס רד-האט ויש לכם בבית או על המחשב שלכם אובונטו, דברים יהיו מעט שונים. בד"כ הפקודות הקשורות לקבצים, משתמשים, ולחלק גדול מההגדרות – יהיו זהים, אבל יהיו חלקים שלא יהיו זהים, ובגלל זה קורס לימוד לינוקס (ולא חשוב אם זה בכיתה או שלמדתם דרך אתר כמו Linux Academy) מצריך מהמשתמש יוזמה להשתמש בהפצות לינוקס שונות על מנת להכיר יותר לינוקס ולא להגיע למצב שמכירים מעולה מערכת אחת אבל לא מכירים כלל מערכת לינוקס אחרת. לכן, לדוגמא, קורסי לינוקס בארץ שמלמדים ספציפית על רד-האט לדוגמא, די "נועלים" את הלומד על הפצה ספציפית אחת תוך התעלמות מהפצות אחרות. לעומת זאת, קורסים המבוססים לדוגמא על LPI/LPIC מדגישים יותר את הבסיס המשותף להפצות לינוקס ומשם הלומד יכול להמשיך ללמוד בעצמו על הפצות לינוקס אחרות.

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

ישנם קורסים online שניתן לרכוש ב-20-40$ של UDEMY ואחרים (והח"מ קנה מספר קורסים כאלו), רק שהבעיה איתם שאתה בעצם "מהמר" על הקורס. לפעמים קשה להבין מילולית את המדריך (במיוחד שהמדריך מהודו ותלוי כמה הוא עבד על המבטא האנגלי שלו), לפעמים ההסבר אינו מספק ואי אפשר ליצור קשר עם המדריך כדי שיסביר בקצרה על מה מדובר, ולפעמים ההסבר כלל לא מכוון כלפי רמת לימוד שהלומד נמצא בה. אני יכול לדוגמא להסביר במשך שעתיים על Linux Schedulers וההבדלים ביניהם אבל אם המאזין לא יודע מה זה processes, ההסבר הולך לפח.

עד לפני כמה חודשים היה לי קשה להמליץ על אתר מסוים ללימוד כי הרבה מאוד אתרים מכרו לימוד על לינוקס בצורה די "חפיפניקית". זכור לי מקרה בו רציתי קצת יותר להעמיק את הידע על MySQL ולקחתי קורס ב-lynda.com על הנושא וכל הקורס דיבר רק על CRUD (כלומר create, read, update, delete), שום דבר על אינדקסים, join, left,right, מנועי database וכו' או קורס Python שלקחתי מאתר אחר ורק לאחר התשלום הבנתי שהמדריך כלל לא מתכוון להתעכב על ההבדלים בין Python 2.7 ו-Python 3 ומעלה, דבר די בעייתי שאתה מנסה להבין קוד שמישהו אחר כתב ממזמן …

כיום אני ממליץ בחום על Linux Academy (ולמעוניינים הנה קוד referral – ה-7 ימים הראשונים בחינם והשאר בתשלום חודשי של 29.50$). ההבדל בינו לבין אתרים אחרים הוא שבכל מה שקשור ללינוקס, יש שם הדרכות רבות לא רק על לינוקס אלא גם על כלים לעבוד איתם בלינוקס, אוטומציה, שפות תכנות, MySQL, וכמובן – עבודה בעננים ציבוריים שונים. יש להם 4 יתרונות גדולים על פני אתרים אחרים:

מכירים את זה שאתם משלמים ושוכחים להיכנס וללמוד? כבר בהתחלת כל קורס תקבלו אפשרות לקבוע לכם לוח זמנים ללימוד (ימים ושעות) והמערכת תשלח לכם התראות לפני כן על מנת לתזכר אתכם להיכנס ולהמשיך ללמוד..
לא הבנתם משהו? לכל קורס יש פורום, יש flash cards שאחרים כתבו כך שתוכלו ללמוד ולהיזכר בסיוע אחרים בדיוק באותם דברים שאתם מתקשים.
אין לכם סביבת לינוקס או שאתם לומדים על דברים הקשורים לעננים ואין לכם תקציב חופשי לחשבון ענן? אל דאגה: אתם מקבלים עד 6 שרתים ללא תשלום נוסף לנסות את הדברים שאתם לומדים בקורס. תתקינו Putty ואתם מסודרים.
כשתיכנסו לאתר תוכלו לראות מצד שמאל למעלה ציורית של ענן כתום – זהו החלק של Cloud Assesment, זהו החלק שיכול לבדוק אם אתם מוכנים לבחינה בנושאי ענן שונים כמו Solution Architect וכו'. יש גם את האייקון השלישי משמאל שנקרא Scale Your Code והוא יותר מורכב מהרצאות של אחרים על דברים שהם עשו.

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

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

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

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

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

מכאן נעבור לצד הטכני: האם מערכות סטורג' בקוד פתוח יכולות להוות תחרות מול סטורג' קנייני מבחינה טכנולוגית? התשובה: כן. האם הן יכולות לתת את 3 השרותים העיקריים שחברות מחפשות (CIFS/SMB, NFS, iSCSI)? בחלק המקרים. האם הן יכולות לגדול (Scale Out)? גם – בחלק מהמקרים. על מנת לפשט דברים, יצרתי טבלה פשוטה עם 3 המתמודדים הידועים בקוד פתוח, מה הם מסוגלים לתת ומה לא.

סוג מערכת	NFS	iSCSI	CIFS/SMB	Scale Out	Scale Up
ZFS	₂✔	₁✔	✔		₃✔
GlusterFS	✔		✔	₄✔
Ceph	✔	✔	✔	✔

₁ תמיכת iSCSI ב-ZFS על לינוקס עבור VMWare כולל תמיכת VAAI מחייבת Kernel 4.4 ומעלה.
₂ תמיכת NFS ב-ZFS על לינוקס תלויה בגירסת הפצת הלינוקס
₃ ניתן לעבוד עם ZFS בלינוקס כ-Cluster בשימוש כלים כמו Sanoid או PaceMaker.
₄ למרות שניתן לעבוד עם GlusterFS ב-2 שרתים – הדבר אינו מומלץ מעבר לרמת POC.

אלו המערכות העיקריות. לכל מערכת יש מספר גרסאות מסחריות (למעט GlusterFS). מערכת כמו ZFS ניתן לרכוש מערכת עם "ברזלים" ישירות מ-Oracle או ניתן להתקין FreeNAS, או להקים על שרת לינוקס עם הפצת Debian לדוגמא. תוכנת Ceph ניתנת לרכישה מ-רד-האט או מ-SuSE.

כשזה מגיע לתמיכה/תחזוקה – הדברים שונים בהתאם לגודל העסק/חברה:

לעסק קטן שמחפש סטורג' ואולי סטורג' עם שרת ב-Standby (כלומר Active/Passive – כ-Scale Up) הייתי ממליץ לבחור פתרון מבוסס ZFS. אם הלקוח מחפש פתרון Scale Out של כמה טרהבייט, אז אמליץ על GlusterFS וחוזה תמיכה עם אינטגרטור.
לעסקים בינוניים וגדולים, אם העסק מחפש פתרון מבוסס קוד פתוח ב-Scale Up, הייתי ממליץ על ZFS ופתרון Scale Out מבוסס Gluster. אם החברה מחפשת פתרון Scale Out בגדלים של Petabyte, אני ממליץ על Ceph. במקרים של GlusterFS ו-Ceph אני ממליץ לחברה לרכוש את התוכנה מהיצרן כולל תמיכה, כך שהאינטגרטור יתן תמיכה ואם יש עדיין בעיה – ניתן לפנות ליצרן התוכנה כך שבכל מקרה החברה מכוסה מבחינת תקלות תוכנה.
לחברות גדולות המחפשות פתרון סטורג' גדול מבחינת כמות DATA (שוב, פטהבייטים ומעלה) – אני ממליץ על ישיבה ויעוץ לגבי הפתרון מכיוון שבכל מקרה הפתרון הוא יקר ויש צורך לשמוע את 2 הצדדים (פתרון קנייני ופתרון מבוסס קוד פתוח).

בכל אחד מהסוגי לקוחות, הפתרונות המוצעים כוללים פתרון שרידות כך שלמעט תקלות חומרה או הפסקת חשמל, המערכת אמורה לשרוד נפילה אם יש תקלת תוכנה בסטורג' עצמו. אגב, בהזדמנות זו אני רוצה להדגיש: כאשר אתם קונים פתרון סטורג' שהוא Scale Up מ-NetApp או Dell/EMC, פתרון השרידות שלו הוא חלקי: זה שיש בקר RAID כפול, 2 מעבדים – תקלות כמו בעיית זכרון (ECC יכול לתקן תקלות עד גבול מסויים), או בעיה בלוח האם ב"ראש" – הסטורג' יפול, וכדאי לקחת זאת בחשבון כשרוכשים פתרון.

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

פריצת ה-Spectre – תיקוני סיליקון

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

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

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

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

מה שאינטל כן יכולה להוציא זה את מעבדי ה-Xeon SP החדשים עם תיקונים (שאגב, לפני התיקון תצטרכו לשדרג את ה-BIOS/UEFI אחרת המכונה לא תצליח אפילו לבצע Boot), רק שכאן הבעיה היא שאף חברה לא "זרקה" את כל השרתים שלה והחליפה אותם לשרתים עם מעבדי Xeon-SP, כל חברה נורמלית בד"כ כשהיא מחליטה לשדרג, השדרוג מחליף רק חלק מהשרתים. אין שום סיבה לזרוק מכונות עם מעבדי Xeon V4 לדוגמא.

אם כבר מדברים על Xeon V4, אינטל כנראה תצטרך להוציא את התכנון של ה-Xeon V4 ולבצע גם שם תיקונים ולייצר את המעבדים הללו מחדש עם התיקונים. הנחות על מעבדי Xeon SP לא יספקו לשום חברה כתירוץ לרכוש שרתים "במקום" ולהשקיע אלפי דולרים פר שרת (וגם לא ניתן להכניס מעבדי Xeon SP לתושבות Xeon V4). "למזלה" של אינטל – שרתים בעלי Xeon V3 יכולים לקבל מעבדי Xeon V4 כך שאם אינטל תוציא מעבד Xeon V4, היא תוכל "לכסות" שרתים עם Xeon V3. כאן מתעוררת בעיה לוגיסטית: בניגוד למעבדי דסקטופ, לקוחות לא יכולים לבוא, לפרק את המעבדים מהשרתים, לנסוע למקום כלשהו, לקבל מעבדים חלופיים בהחלפת המקוריים, לנסוע בחזרה לחברה, להחליף ושזה יעבוד (בכל מקרה זה לא יעבוד, צריך קודם לשדרג BIOS/UEFI ורק אז להחליף מעבד פיזית). אינטל תצטרך כנראה לדאוג שיצרני השרתים יסעו ללקוחות ויבצעו תהליך החלפה (אם זה אפשרי בכלל. מה עושים לקוחות שיש להם TYAN, סופרמיקרו או שרתים "לבנים" אחרים?), אבל .. מי בדיוק ישלם על זה? טכנאי, נסיעות, שעות עבודה – זה לא בחינם ואינטל תצטרך לשבור את הראש על כך, ועוד לא דיברנו על תהליך ולדיציה – איך בדיוק אינטל תדע כמה מעבדים יש לחברה? להציג חשבוניות – אף חברה לא תסכים לכך (מה גם שזה מאוחסן אי שם…) – בקיצור לאינטל יש הרבה על מה לחשוב.

כשזה מגיע לדסקטופ – הסיפור נהיה יותר מורכב. לוחות אם עם מעבדי Coffee Lake אינם תואמים למעבדי Skylake, והסיפור מסתבך מכאן. ושוב – האם אינטל מצפה שלקוחות יביאו את מחשבי הדסקטופ למקום כלשהו על מנת להחליף? ומה בכלל עושים עם לאפטופים? שם המעבדים בכלל מולחמים ללוח האם, האם אינטל מצפה שיצרני הלאפטופים יחליפו לאפטופים ללקוחות? יש לכך בערך 0% סיכוי.

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

על Spectre/Meltdown ועל יצרניות סטורג'

הערה: הפוסט הבא נכתב כטור דעה אישית בלבד ואינו בא "לתקוף מתחרים"

כולנו שמענו על הצרות עם Meltdown ו-Spectre. בחברות מסויימות מיהרו להטמיע עדכוני BIOS/UEFI רק כדי לראות מערכות שבאופן רנדומלי מבצעות Cold Reboot ללא השארת עקבות והצהרות מצד היצרנים לא להתקין את העדכונים האחרונים ואם הם הותקנו – יש לבצע Rollback.

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

תסלחו לי, אבל מדובר לדעתי האישית בחתיכת בולש*ט!

אני רוצה להפנות את תשומת לבכם למכשיר שאולי אתם מחזיקים כרגע ביד, או שנמצא על שולחנכם או בכיסכם: הסמארטפון שלכם. לא חשוב אם יש לכם אייפון או מכשיר מבוסס אנדרואיד של יצרן גדול וידוע. המכשיר שלכם יודע לבצע Boot והרצת דברים חתומים ומאושרים בלבד. במכשירי אנדרואיד של יצרנים כמו סמסונג, גוגל, LG, מוטורולה לדוגמא, אם תרצה לפרוץ את המכשיר ולשים לו ROM אחר, לא תוכל לעשות זאת אלא רק אם תבצע unlock למכשיר וברגע שתבצע – כל הנתונים האישיים שלך ימחקו מהמכשיר כולל שירים ווידאו שרכשת. באייפון אין בכלל אפשרות כזו. במידה ותנסה להתקין באנדרואיד תוכנה חיצונית שהורדת כקובץ APK, המכשיר לא יתן לך לעשות זאת אלא אם תלך להגדרות ותאפשר לו התקנה ממקורות חיצוניים (ואז תקבל חלונית אזהרה). באייפון זה יותר הדוק בכך שאינך יכול להתקין תוכנות חיצוניות שלא מהחנות ותצטרך לבצע jailbreak ולהתקין מס' תוכנות נוספות כדי לפרוץ את המכשיר. אך כמו שכולנו יודעים, גם לאנדרואיד וגם לאייפון היו (ויש) נוזקות, פריצות ועוד דברים אחרים, לא חשוב כמה המכשיר סגור, עדיין ניתן לפרוץ אותו כולל במערכות הפעלה החדשות וגם לאחר עדכונים, תמיד מישהו ימצא דרך לפרוץ.

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

כיום, מה שבד"כ רואים בפריצות למערכות, זה שמנסים לפרוץ אל השרתים ומכיוון שלשרתים אין גישה לכל מה שנמצא על ה-Storage, אפשר לגשת דרך השרת רק לחלק מהמידע. עכשיו תנסו לחשוב על פורצים מתוחכמים וממומנים. תחשבו על חברות מתחרות שיש ברשותן מאות מילונים/מיליארדי דולרים, תחשבו על מדינות כמו סין ורוסיה שמחזיקות צבא של פורצים ושהן מעוניינות במידע שלך. גם באותם גופים קוראים חדשות והם קוראים שיצרניות ה-Storage מתחמקות והן לא הולכות לבצע עדכוני Meltdown/Spectre. עכשיו אותם פורצים פשוט צריכים לשנות אסטרטגיה: עכשיו הם צריכים בעצם לפרוץ לתחנת עבודה שמריצה Windows או מק או לינוקס ומשם לפרוץ לממשק ווב או לקונסולה (CLI) של ה-Storage, להעלות משהו כמו busybox ואז להשתמש ב-חורים Spectre/Meltdown כדי לקבל מידע סודי/פנימי/חסוי. (הנה משהו שאולי יכול לעזור לכם: בדקו אם יש לכם ACL שנותן גישה לממשק רק למכונות מסויימות בחברה).

מדוע החברות Storage עושות זאת? אני יכול רק לנחש: אם הם יתקינו את הטלאים נגד Spectre/Meltdown – תהיה ללקוחות הנחתה רצינית מאוד בביצועים. כמה? אני יכול להמר בסביבות ה-5-40% תלוי כמובן כמה ה-Storage חדש או ישן. את הלקוחות לא יעניין שהחור קשור למעבדים של אינטל, הם יפנו אצבע מאשימה ליצרני ה-Storage ויצרניות ה-Storage יצטרכו להחליף לוח עם כמעט כל החומרה (למעט כרטיסים וספקי כח..) והמחיר לדבר כזה הוא אסטרונומי מבחינתם.

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

מה ההבדל האמיתי בין SSD רגיל ל-SSD ל-Enterprise?

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

הרשו לי להציג לכם את ה"יורש" של הסמסונג 850 PRO שיצא שלשום – אחד מכונני ה-SSD שהצליח במשך 3 שנים להתעלות מעל רוב כונני ה-SSD הביתיים מבחינת ביצועים. זהו הסמסונג 860 PRO. מבחינת ביצועים הן מבדיקות והן "על הנייר" – זו חיה: 560 מגהבייט לשניה בקריאה ו-530 מגהבייט לשניה בכתיבה (זהו כונן בחיבור SATA). מבחינת IOPS יש לו בהחלט מה להתגאות: 100000 בקריאה, 90000 בכתיבה, ואורך החיים שלו – אתם יכולים לכתוב עליו ולמחוק – עד 4800 טרהבייט בכל משך ימי חייו. שום דיסק מכני לא נותן דבר כזה כמובן. מחיר: $238 לחצי טרהבייט.

והנה ה"אח הבכור" – ה-960 PRO בגירסת M.2 NVME. הביצועים? 3.5 ג'יגהבייט קריאה, 1.9 ג'יגהבייט כתיבה. IOPS? טוב ששאלתם: 440000 בקריאה, 360,000 בכתיבה. המחיר: $300 לחצי טרהבייט. אפשר לכתוב עליו באורך חייו כ-400 טרהבייט. (כן, ה-860 מחזיק הרבה יותר).

תכירו את ה-SSD החדש ביותר של אינטל (כתבתי עליו בעבר) – ה-900P. הוא יקר יותר ($628 לגירסה של 480 ג'יגהבייט), הוא יותר איטי בגישה לנתונים (2.5 ג'יגה בקריאה, 2 ג'יגה בכתיבה) אבל כשזה מגיע ל-IOPS, הוא בועט בכולם: 550,000 בקריאה, 500,000 בכתיבה.

אז מי מהם מתאים לחברות ומי לא מתאים לבית? ומדוע ההבדלים?

נתחיל ב-900P (הוא "האח הקטן" של ה-DC P4800X). נניח שאתה רוצה SSD מהיר לבית, אתה עורך וידאו נניח או מוכן לשפוך סכומים רציניים על המחשב למשחקים שלך. הכסף לא ממש משנה לך. האם כדאי לקנות אותו? התשובה היא לא. אם נעמיד את ה-900P במבחן מול ה-960 PRO או ה-860 PRO, שתיהם ינצחו אותו בקלות, כלומר אתה יכול לחסוך 300 דולר ולקבל SSD שיתאים לך לבית.

עכשיו נלך לחברה. נניח שאנחנו מקימים Storage משלנו, נניח שאנחנו מקימים שרת SQL כלשהו (לא חשוב אם זה מיקרוסופט, אורקל או PostgreSQL או MySQL) או שרת אפליקציה שאמור לתת שרות למחשבים רבים או משתמשים רבים. כאן דווקא ה-900P יתן ביצועים הרבה יותר גבוהים בהשוואה ל-2 ה-SSD של סמסונג, הם "יחנקו" מהר מאוד.

ה-SSD ל-Enterprise בעקרון בנוי לתת שרות לכמה שיותר משתמשים/מחשבים/תחנות, כמה שיותר Clients, בשעה שה-2 השניים בנויים לתת שרותים לכמה שפחות, כלומר למחשב אחד, לכמה אפליקציות שרצות במקביל במחשב הביתי/תחנת עבודה. במילים אחרות – אם לא מעמיסים על דיסק SSD ל-Enterprise אתם תקבלו ביצועים רחוקים מאוד ממה שמוצהר ע"י היצרן.

פרסמתי כאן בתחילת השנה פוסט על SSD ל-Enterprise והוא רלוונטי בדיוק לפוסט זה. בפוסט הקודם הזכרתי את ה-QD (ה-Queue Depth) שצריך אותו כדי לתת שרותים לכמה שיותר Clients וזה בדיוק מה ש-SSD ל-Enterprise מצטיין בו ו-SSD לבית גרוע בו. ניקח לדוגמא את ה-960 PRO, אם תסתכלו בסקירה זו תיראו שברגע שמתחילים להעמיס עליו, הביצועים צונחים דרמטית.

עכשיו נשארנו עם בעיה אחת: נניח ואנחנו רוצים ביצועים מאוד גבוהים לשרתים עם דיסקים מקומיים (כן, לאלו שמריצים vSphere עם דיסקים מקומיים לדוגמא) אבל המחיר מפחיד. ה-DC P4800X לדוגמא בגירסה צנועה של 375 ג'יגהבייט עולה $1700 (המחיר קצת יקר באמזון, המחיר הרשמי הוא $1520) וגירסת ה-750 ג'יגהבייט עולה מחיר "צנוע" של $3,653. במחיר כזה, גם חברות גדולות מתחילות לחשוב פעמיים אם לקנות במחיר כזה.

מה ניתן לעשות? ישנן מס' אפשרויות:

לקנות כמה קטנים. אפשר לדוגמא לרכוש 2 כרטיסי 900P (אגב, אם השרתים שלכם חדשים, אז ניתן לקנות את ה-900P בגירסת U.2 שנכנסת מקדימה) ולחבר אותם ב-RAID-0 ולהגדיר אותם כ-Cache. זה מתאים למצבים שאנחנו רוצים להריץ את השרת כשרת קבצים או כשרת NFS/SAMBA ואליו נחבר לדוגמא שרתי vSphere.
אם אנחנו רוצים להריץ שרת SQL או שרת אפליקציה כבד, נוסיף דיסק SSD כלשהו למערכת, עליו נתקין את מערכת ההפעלה והאפליקציות אך ה-DATA ישב ב-RAID-0 (מתוך הנחה שיש לכם גיבוי יומי!) כ"כונן" נפרד.
נבחר כונני Enterprise יותר זולים. לאינטל יש את ה-750 שישן קצת (מ-2015) אבל נותן ביצועים יותר טובים, יש את ה-P4600 ו-4700, שהם מעולים. חברות גדולות, כמובן, לא קונות כוננים ישירות מאינטל או סמסונג, ולכן מומלץ לחברות אלו לבדוק מיצרן השרת שלהם אלו דיסקים ניתן לקנות (לא מומלץ לקנות עם חיבור SAS, לכולן יש פאנל קדמי לחיבור דיסקים SSD בחיבור U.2 או SATA).

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

על פריצת ה-Spectre V2

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

והאצבעות מופנות הפעם ל… אינטל. (היתה בעיה עם מעבדי AMD, היא כבר טופלה [כולל במעדי Epyc ו-Threadripper]).

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

את הפירצה בגירסה 2 של Spectre אפשר לסכם בפשטות כך: מריצים VM בוירטואליזציה כלשהי? (באמת שלא חשוב מה פתרון הוירטואליזציה, כולם משתמשים ב-VT-X, VT-D במעבדי אינטל) אז מאותו VM ניתן להגיע למכונות VM אחרות ול-HOST עצמו. מריצים קונטיינרים? אז מהקונטיינר ניתן להגיע אל ה-HOST עצמו וב-2 המקרים מספיק קוד זדוני די קטן כדי להשתמש בפירצה. מספיק חמור?

בניגוד למקרים אחרים, בכדי לטפל ב-Spectre V2 צריך עדכון מיקרוקוד ישירות למעבד וכאן הדברים מתחילים להיות טיפה יותר מורכבים: כשזה מגיע ללינוקס ול-VMWare (נו טוב, VMWare בחלקן מכיל תואמות ברמת ה-Host ללינוקס ברמה של ABI) – אז עדכון המיקרוקוד מגיע מיצרן הפצת הלינוקס או מ-VMWare, כך שלא צריך לפנות ליצרן החומרה כדי לקבל את העדכונים. בעקרון, לינוקס קורא אמנם את הגדרות ה-UEFI/BIOS אבל לא מתייחס לכל ההגדרות ברצינות (מפתחי Kernel ותיקים בלינוקס די מזלזלים במימושי ה-UEFI/BIOS, בהצדקה מסויימת).

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

אינטל שחררה עדכוני מיקרוקוד ויצרניות הפצת הלינוקס הכניסו אותו לעדכוני הפצת לינוקס, וגם VMWare הכניסה את העדכון (דרך ה-VUM), אלא שאז התגלתה הפדיחה של אינטל. כנראה שאינטל לא ביצעה מספיק ניסויים ובדיקות על מעבדי E5/E7 V3, V4 וחלק מהחברות שעדכנו את המיקרוקוד קיבלו "הפתעה" לא נעימה – אתה מפעיל את המכונה, מתחיל לבצע עבודות ולפתע – המחשב מבצע לעצמו Reset. אין לוגים, אין כלום. נסו לדמיין את זה על שרת שמריץ ESXI או איזה שרת DB כבד שפתאום מנתקים לו את החשמל.

כתוצאה מכך, VMWare, RedHat ואחרים החליטו לבצע Rollback וכנ"ל גם יצרני שרתים ששחררו עדכוני מיקרוקוד דרך מערכות העדכונים שלהם ל-Windows. במכונות לינוקס כשבודקים את עניין המיקרוקוד לאחר עדכונים מיום שלישי, זה נראה כך (ב-CentOS 7 וב-RHEL 7) כשבודקים את ה-Changelog. אני מאמין ששאר הפצות הלינוקס גם חזרו אחורה.

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

שימו לב: ההבדל העיקרי בין עדכונים מיצרן השרת לבין עדכוני לינוקס/VMWare בכל הקשור למיקרוקוד, הוא שבמערכות לינוקס/VMWare, עדכוני המיקרוקוד חלים על המערכת זמנית, אחר ה-Boot ואילו עדכוני המיקרוקוד של יצרן השרתים שנמצאים בחבילת ה-BIOS/UEFI הם קבועים. זה לא כל כך משנה בלינוקס וב-VMware אולם בהחלט משנים ברמה של מערכות מבוססות Windows.

אז מה עושים כרגע? לא ניתן לעשות יותר מדי דברים עד שיצא עדכון חדש. בשלב זה אם תיפנו ל-Red Hat (ואתם לא לקוח גדול כמו בנק או חברת Fortune 500) אז תופנו בנימוס ליצרן השרת שיטפל בכם (ויצרן השרת יפנה בנימוס ל-Red Hat כי עם כל הכבוד, תמיכת הלינוקס של יצרני השרתים היא לא בדיוק רמה גבוהה..) ואם תפנו בנימוס לאינטל, היא תפנה אותך ליצרן מערכת ההפעלה שלך ואם מערכת ההפעלה שלך היא Windows אתה תופנה בנימוס ל.. יצרן המכונה שלך. כיף!!

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

לסיכום: כרגע, לא ניתן לעשות הרבה זולת המתנה לאינטל שישחררו עדכון מיקרוקוד יותר יציב שנבדק על מעבדים ישנים יותר. אם יש לכם מערכות סריקה (IPS ושאר קיצורי שמות) – אני מאמין שהם הוציאו עדכוני חתימות לגלות אם מישהו מנסה להזריק לכם קוד שמשתמש ב-Spectre (אבל אני לא בטוח כמה זה יתפוס, אפשר להשתמש בפירצה הזו גם עם קוד JS פשוט ובמקרים רבים ניתן פשוט לבצע code obfuscation ["ערפול קוד"], במיוחד כשיש לכם מערכות חשופות לאינטרנט).

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

אחסון אובייקטים (Object storage) ו-Ceph

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

באופן עקרוני, בניגוד ל-GlusterFS ו-ZFS, ה-Ceph היא מערכת מבוססים אחסון קבצים (Object Storage). היתרון במערכת כזו היא שהיא "מפשיטה" את כל המורכבות של File System רגיל (כמו XFS, EXT4 וכו') ל"קוביות" קטנות אחידות בגודל 64 קילובייט ואת אותן "קוביות" (שהם בעצם Objects) המערכת משכפלת לשרתים אחרים על מנת ליצור שרידות גבוהה מצד אחד, והם נגישים ל-Clients השונים מכל שכפול, כך קורה מצב שאם לדוגמא מספר מכונות דורשות את אותו קובץ, הוא נקרא משרתים שונים. בנוסף, מאותו Object Storage המערכת בונה גם שרותים אחרים שהיא מציעה, בין אם מדובר באחסון דומה ל-S3, אחסון File System, או NFS (ש"רוכב" על ה-File System") או אחסון "בלוקים" עבור iSCSI.

עם Ceph ניתן לאחסן מיליוני קבצים (ומעלה) עם גישה מאוד מהירה כאשר מגדירים את האחסון וקריאה כמו שקוראים לקבצים ב-S3. היכן זה יכול לעזור לדוגמא? כאשר רוצים לשדר וידאו. בדרך כלל לא מומלץ לחבר שרתי שידור (כמו WOWZA) לאחסון כמו Ceph, אלא מחברים זאת למערכת CDN טובה שהיא מפיצה את התוכן לנקודות EDGE/POP במקומות שונים בארץ/בעולם ומאותן נקודות השידור עצמו מתבצע. באותה שיטה (רק ללא צורך ב-CDN ברוב המקרים) ניתן לדוגמא להקים ארכיב ענק של קבצי מסמכים (גם בגודל של פטהבייטים רבים) ולאפשר גישה מאובטחת למסמכים דרך REST API שניגש ל-RADOS ב-Ceph שמחבר את אותן "קוביות" לאובייקטים ומשם האפליקציה יכולה לקרוא את המסמך ולהנגיש אותו עבור הלקוח. יתרון נוסף הוא באבטחה: אם מישהו מחר גונב שרת ומצפה למצוא את הקבצים שהוא מעניין בהם, הוא יתאכזב לראות שאין ממש קבצי DOC/PDF, יש "קוביות" וצריך את כל המערכת בכדי לקבל את הקבצים הרצויים.

טכנולוגיה חדשה שנכנסת לשוק בשנים האחרונות הם אמצעי אחסון מוכוונים KV (כלומר Key Value) והם מיועדים בראש ובראשונה לאחסן אובייקטים. חברת Seagate לדוגמא הדגימה דיסקים מסוג SMR (שהם דיסקים המיועדים לארכיב – Shingled Magnetic Recorder) בצירוב SSD מאיץ מסוג Nytro נותן ביצועים גבוהים פי 11 בהשוואה לדיסקים מכניים רגילים עם Ceph (ניתן לקרוא על כך ולראות וידאו בנושא כאן).

במסגרת תערוכת CES האחרונה, סמסונג הציגה SSD בפורמט חדש (NGSFF) לשרתים, זהו ה-PM983 וניתן לרכוש אותו בגודל של 8 טרהבייט ובמחצית השניה של השנה, הדגם הזה ימכר בגודל מדהים של 16 טרהבייט למקל. חברת Supermicro הכריזה על שרת פיצה (דגם:SSG-1029P-NMR36L – שם ממש קליט…) בגודל 1U שיכול לאחסן 36 מקלות כאלו, כך שניתן לאחסן 288 טרהבייט על שרת כזה. זה נראה כך:

Supermicro_SSG_1029P_NMR36L

היתרון בשרת כזו הוא שהוא בנוי כולו לאחסון של Ceph. מקלות זכרון האחסון של סמסונג מובנים מראש לאחסון KV וסמסונג מדגימה זאת בתמונה הבאה:

Samsung_KV_Stack_diagram

כפי שאתם יכולים לראות, מצד שמאל זה המצב הרגיל שקיים כיום כשמקימים אחסון מבוסס Ceph: מכניסים דיסקים רגילים או SSD, יוצרים פרטישנים, File System ואז משם מקימים את ה-KV Store שעליו מאוחסנים האובייקטים. מצד ימין רואים פתרון של סמסונג שכל מה שצריך הוא דרייבר והשאר נעשה בצורה טבעית על קושחת ה-SSD, אין צורך בשכבת "המרה" בחזרה ל-File System. במילים אחרות: אם תרכשו לקראת הרבעון השלישי את המכונה הזו ומקלות של 16 טרהבייט, תוכלו לקבל עם 10 מכונות כאלו 5 פטהבייט לאחסון אובייקטים. פעם זה היה לוקח ארון שלם..

לסיכום: כשצריכים לאחסן המון קבצים (כשמדובר במיליונים ומעלה) אחסון מבוסס Object Storage הוא הפתרון, ואמזון הדגימה זאת לעולם במסגרת שרותי ה-S3 שלה, ו-Ceph נותן בדיוק את אותו פתרון, ועתה גם חברות חומרה נכנסות ומציעות אחסון בצורה טבעית שמורידה את כל שלב התרגום מ-Object ל-File system ובחזרה. זהו אינו פתרון זול (ובוודאי לא פתרון להחליף File Server רגיל) – אך פתרונות כאלו מציעים שרידות וביצועים למי שצריך זאת ומוכן לשלם על כך. למעוניינים בפתרונות Ceph בארץ אני ממליץ לפנות ל-SuSE ישראל.

אתם באמת צריכים איש Devops? (חלק שני)

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

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

אתן דוגמא: כפרילאנסר, אין לי שום בעיה להרים Software Defined Storage, או קונטיינרים או לבנות מערכות לינוקס גדולות לבצע תפקודים מסויימים, או מערכות וירטואליזציה סגורות או בקוד פתוח, אבל כשזה מגיע למערכות כאלו, יודעים כמה חברות גדולות יכנסו לדף ה"אודות" כדי להזמין אותי, לשפוך כמה מאות אלפי דולרים ולשלם לי כמה עשרות אלפי שקלים בפגישה הראשונה? אפס. אף אחד לא מוכן להקים מחר בבוקר מערכת כזו. כל מי שיפנה – אז הוא יצור קשר להתעניינות, אולי להיפגש ואם זה ישמע לו, הוא ירצה בתור התחלה PoC (כלומר Proof Of Concept) ורק אם ה-PoC מראה תוצאות טובות – אז החברה תיקח זמן לחשוב, אולי תסתכל על הצעות אחרות ואם הם ירצו – הם יפנו מחדש כדי להקים מערכת כזו. כל פרילאנסר שעובד עם גופים גדולים יכול לספר לכם על כך. באופן עקרוני – ככל שהגוף/חברה יותר גדולה, דברים נעשים יותר לאט. מה שאנשים מקצועניים עושים בסטארט-אפ מהבוקר שהם מתחילים לעבוד ועל הפסקת הצהרים – יתורגם לשבועות ואף לחודשים – בחברות גדולות.

בסטארטאפ, הדברים הם פשוטים: כולם עובדים יחד. יש כמובן צוותים, ובתוך כל צוות פיתוח – כל אחד כותב חלק מסוים של הקוד, וסביר להניח שהוא יכתוב את קוד ה-Units testing, את ה-UAT או את ה-User Stories (לפי ה-Agile Development) לאותו קוד שהוא כתב. בקיצור – יש הרמוניה, וכשיש דינמיקה, דברים זזים מהר, ותמיד יהיה מישהו שיהיה אחראי על אוטומציה, תשתית ושאר ירקות שקשורים ל-Devops.

בחברות גדולות לעומת זאת, דברים זזים לאט ולפעמים "נתקעים". אז אתה רוצה לעבוד במתודולוגיית Agile? כאילו ה-Devops הזה ששומעים עליו? אוקיי, נתחיל עם PoC. הגיוני, לא? רק שאז צצה לה ה"פוליטיקה" של הארגון. ההוא שם טיפוס מבודד שלא מוכן לעבוד עם אף אחד (ומה לעשות, הדבר הראשון ב-Devops זה עבודה ביחד) ההוא לא רוצה לעבוד עם ההיא וכו', אנשים לא רוצים עבודות נוספות כמו כתיבת טסטים, Stories וכו', יש חוסר רצון בולט בלעבור לכלים יותר מודרניים (גם אם אתה מציע כלים שישמרו על תאימות לדברים הקלאסיים) ובכלל – בארגונים רבים מנסים (וחברות גולגלות/כ"א די מסייעות לכך מבלי לשים לב) "לכמת" את זה למישהו מסוים, אולי 2-3 לצוות – בדיוק כמו שיש צוות לסטורג', לנטוורק, לוירטואליזציה – אז עכשיו יהיה "צוות Devops".

כאן, בשביל ה-PoC מישהו חיצוני (פרילאנסר) יכול להוות פתרון. החלק הראשון הוא ההסברה לגבי מה זה לכל הרוחות Devops, מה זה מתולודוגיית Agile software development, מה נדרש בעצם מהמפתחים, איך זה הולך להיות וכו', כלומר הרבה לפני שבכלל מרימים אפילו VM או קונטיינר אחד – יש ישיבות על גבי ישיבות, הסברה עם מצגות, צריכים הסכמות לגבי הדברים, אישורים עקרוניים מצד מנהלי צוותים שונים, חישוב ואישור תקציב – וכל זה לפני שאתה נוגע במקלדת בשביל לבנות משהו. האמינו לי, בחברה מסויימת אני אמור להקים קונטיינר יחיד ב-Docker. כמה זה מסובך? זה לא, אבל אנחנו כבר 6 חודשים בישיבות. בגלל זה, פרילאנסר מתאים לחלק של ה-PoC. הסכימה החברה לשנות את כל העבודה שלה ועבודת הצוותים? שם כבר יכול להיכנס שכיר (ולשכירים שנכנסים לגופים גדולים ההמלצה שלי: הצטיידו בטונות של סבלנות).

במהלך היום (אני קצת חולה עדיין) עברתי המון על קליפים ביוטיוב שיכולים להסביר בצורה עניינית ולא בצורה של בלה-בלה-בלה מה זה Devops ולבסוף מצאתי אחד שמסביר בצורה טובה (לדעתי) את הדברים. הוא לא נכנס לפרטים של איזה בדיוק כלי לבחור ולשם מה, אבל הוא מסביר את זה בקטגוריות. הוא גם מתייחס לדברים בחברות גדולות. אורכו של הקליפ הוא שעה וחצי, אבל יש חלקים שונים שאפשר לדלג מעליהם (השתמשו במקשים L ו-J [ללא shift] כדי לקפוץ 10 שניות כל פעם) ולדעתי הקליפ די עוזר לתפוס מה זה Devops.

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