על דיסקים ואחסון

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

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

אבל מה קורה אם יש צורך להזמין כמות גדולה של דיסקים? (ב"גדולה" אני מדבר על כמויות של 30 ומעלה – בתור התחלה). ניקח את זה יותר לכיוון המציאות: אתם רוצים להקים תשתית וירטואליזציה Scale Out עם vSAN או Nutanix. אתם לא רוצים עדיין לרוץ לכיוון All Flash ולכן אתם רוצים לשלב דיסקים מכניים גדולים יחד עם SSD שישמשו כ-Cache. ב-2 הפתרונות המתחרים, כמות ה"ברוטו" מבחינת הדיסקים שתכניסו – רחוקה מאוד מכמות ה"נטו" שתקבלו בפועל לשימוש, ולכן אם נרצה כמות תלת ספרתית של אחסון נטו פנוי, נצטרך לרכוש לא מעט דיסקים עבור מינימום 3 שרתים. נניח לשם הפוסט – שנצטרך 21 דיסקים מכניים ו-3 SSD (כלומר 7 מכניים ו-1 SSD פר שרת).

לפני שנעבור לחישובים שונים, בוא נשנה לרגע נושא ונדבר על שרידות: כיום בשוק, אצל רוב מוחלט של החברות, מצב השרידות שקיים הוא מצב שהמערכת יכולה להמשיך לעבוד, כל עוד דיסק אחד הוא תקול. במקרה והתקלקל דיסק, מפעילים את ה-SLA ותוך 4 שעות יגיע טכנאי ויתן לכם דיסק חלופי, תחליפו את הדיסק בשרת/מערך אחסון, הפעילו תהליך Rebuild. מה יקרה אם יתקלקל עוד דיסק עוד לפני שהקודם הוחלף ובוצע Rebuild? תקוו שהגדרתם דיסק אחד כ-Hot Spare – אחרת אתם בצרות.

נחזור לחישובים: כיום, בין אם מדובר בישראל או כמעט בכל מקום אחר בעולם, רכישת דיסק קשיח, בין אם מדובר ב-SSD או מדובר בדיסק מכני, תעלה אצל יצרן שרתים פי 2-3 בהשוואה לרכישה מיבואן רשמי בארץ. תרגום: אם דיסק כלשהו עולה $100 אצל יבואן רשמי, אצל יצרן שרתים, אותו דיסק יעלה 300-$200. את ההבדל הזה די קל לבלוע כשמדובר על רכישה של שרת אחד עם 4-5 דיסקים. ראש שקט, רכישה חד פעמית, תשלום חד פעמי, לא עושים מזה סיפור.

אבל אם נסתכל על הדוגמא לעיל עם ה-Scale Out בשביל ה-Nutanix/vSAN (או GlusterFS, או Ceph), אנחנו מדברים על 21 דיסקים, ואנחנו נשלם בפועל מחיר של 50-60 דיסקים. אתם לא צריכים להאמין לי, אתם יכולים ליצור קשר ישירות עם היבואנים בארץ:

  • דיסקים של חברת טושיבה – חברת CRG
  • דיסקים של חברות Seagate, Western Digital – חברת ח.י.

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

אז במקרים שהרעיון של תשלום סכום כה מטורף קצת מפריע לכם – אפשר לחשוב על שרידות ברמה אחרת: במקום לרכוש 21 דיסקים מיצרן השרתים, אפשר לרכוש נניח 25 דיסקים מהיבואן (כל עוד לא מדובר עבור שרתי HPE – הם לא מקבלים דיסקים שאינם בעלי קושחה של HPE), ולאחסן 4 דיסקים בארון. במקרה והתקלקל דיסק, מוציאים אחד מהארון ובמקביל יוצרים קשר עם היבואן כדי לתאם שליחות/קבלה של דיסק חלופי אחר. במקרים כאלו, גם אם עוד דיסק ילך במהלך ה-Rebuild, יהיו לכם מספיק דיסקים חלופיים ועל הדרך תחסכו לא מעט כספים.

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

על אחסון, וירטואליזציה, ובעיות ביצועים

כמעט כל ארגון שמריץ פתרון וירטואליזציה (vSphere, Hyper-V, Xen, ואחרים) בדרך כלל משתמש בפתרון אחסון משותף לשרתים, בין אם מדובר בפתרון "הרכבה עצמית" (FreeNAS), פתרון קופסתי זול (Synology, Asustor, QNAP וכו') ובין אם מדובר במשהו קצת יותר גדול מצד חברות כמו HPE, IBM, Lenovo, Dell, NetApp, EMC וכו'. יש פתרון לכל תקציב.

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

אפשר לקטלג את סוגי התקלות ל-2 סוגים עיקריים. לסוג הראשון אני קורא "תקלות אבסולוטיות" ולסוג השני – "תקלות מעורפלות".

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

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

אני רוצה לתת דוגמא מה-LAB שלי. לפניכם צילום מסך מתוך מכונת VM ב-vSphere 6.7 שמריצה Windows 10 עם Crystal Diskmark 7. השרתים מחוברים לשרת ZFS עם 8 דיסקים מכניים ואין בו שום SSD, בחיבור 10 ג'יגהביט +SFP. על הנייר, כל מי שמבין באחסון, יאמר שהמספרים מעולים – 1.2 ג'יגהבייט קריאה/כתיבה על חיבור של 10 ג'יגהביט – זה המקסימום שאפשר לקבל.

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

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

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

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

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

  • הדבר הראשון שאני ממליץ, זה להשתמש בכלי בשם FIO. את הקוד של הכלי הזה אני ממליץ לקמפל באופן סטטי (בשימוש הפרמטר build-static– ), לפתוח תיקיה ב-Datastore כלשהו ולהעלות את הקובץ FIO הבינארי שקומפל לשם, ולוודא שיש לו הרשאות Executable. את הקובץ נריץ דרך SSH.
    הכלי (FIO) נותן לנו למדוד את מהירות הקריאה והכתיבה שיש לנו עם מדדים ופרמטרים שונים ובכך נוכל לדעת מהי מהירות הקריאה והכתיבה בין האחסון לשרת עצמו ישירות. כך נוכל לדעת אם הבעיה קשורה בתקשורת בין האחסון לשרת ולא בין האחסון למכונת VM כלשהי. חשוב: לבצע את הבדיקה עם כמה שפחות מכונות VM רצות על אותו שרת.
  • אנחנו יכולים להשתמש באותו כלי (ולחובבי Windows – יש את IOMeter שמבוסס על הקוד של FIO. את הכלי הזה, אגב, אפשר להריץ ישירות על Windows Server פיזי אם מדובר במכונה שנותנת שרותים דרך Hyper-V) כדי למדוד את אותם דברים שמדדנו קודם – אך הפעם אנחנו נמדוד בין מכונת ה-VM לאחסון, תוך שימוש ב-Datastore ובדיסק הקשיח הוירטואלי של אותו VM. שימו לב: התוצאות יכולות להיות שונות מהתוצאות שנקבל כתוצאה מבדיקה דרך הסעיף הקודם, הואיל והתרגום לדיסק הוירטואלי גובה מספר אחוזים בביצועים.
  • אם אתם מאלו שאוהבים כמה שיותר DATA כדי לאסוף כמה שיותר תובנות, בנו לעצמכם סקריפט שמשתמש ב-FIO כדי לבצע דגימות שונות ולאסוף את הנתונים לקובץ מסוים כדי לנתח אחר כך ולבדוק דגרגציה של פתרון האחסון ועוד.
  • אם הבעיה קיימת רק עם מכונות VM מסויימות, אז הבעיה אינה ממש קשורה לתקלות באחסון אלא יותר בכח של פתרון האחסון. הגיע הזמן להחליף למשהו יותר לכיוון ה-All Flash או לפחות עם פתרון Flash לכתיבה ו-Caching.
  • זה ישמע טריוואלי – אבל תפרידו תקשורת ברמה של פורטים ואם אפשר גם ברמה של סוויצ' – בין התקשורת מהאחסון לשרתים, לבין כל שאר הדברים. אני משער שחלק מהקוראים יאמרו "מה הבעיה עם VLAN?", אין בעיה – רק שבמקרים רבים אותם אלו שמגדירים נוטים לחתוך פינות ולפעמים ההגדרות לא יהיו נכונות ולא יסייעו. מצד שני – סוויצ' 10 ג'יגה כיום הוא דבר די זול.
  • דבר אחרון – כלים רגילים שמודדים ביצועים של דיסקים מכניים או SSD לא רלוונטיים במקרים של התקלות המדוברות בפוסט זה. זה נחמד להציג תמונות (או כדי למכור ללקוחות מצגת על פתרון) אבל התוצאות לא יהיו באמת נכונות (אתם באמת חושבים שמכונת ה-ZFS  הנ"ל בפועל יכולה לכתוב 1.2 ג'יגה בשניה בשעה שאין שום SSD? לא ממש, אבל ZFS יכול "לעבוד" על VMWare ובכך אפשר להציג את התוצאות הנ"ל, אם יש מספיק RAM בשרת, ובמקרה הזה – יש, 256 ג'יגה).

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

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

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

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

על דיסקים SSD – אחריות, ביצועים, יד שניה ועוד

לקראת השנה האזרחית החדשה החלטתי לכתוב פוסט חדש המבוסס על דוח"ות שכתבתי עבור לקוחות שונים והחלטתי לקחת חלקים מהם (ברשות) ולאחד אותם לפוסט אחד. כל מה שאני כותב בפוסט זה מבוסס הן על תיעוד של היצרניות והן על בדיקות Stress testing שביצעתי עבור לקוחות. שמתי לב שרבים מאנשי ה-IT (וחלק קטן מאנשי השיווק) מביאים/מציגים פרטים ישנים או רלוונטיים ולכן בפוסט זה אתייחס לסוגים שונים של דיסקים. הן ללקוחות קצה ביתיים/סמי-מקצועיים והן ל-Enterprise. הטכנולוגיה והמושגים רלוונטיים בערך לשנתיים האחרונות.

אתחיל בנושא אחריות ו"טחינת דיסקים", מושג שמתאים לדיסקים מכניים ולא ל-SSD ואסביר מדוע.

אחריות על דיסקים נמדדת ב-2 מושגים שונים, תלוי בשוק. בשוק הביתי/סמי-פרו, היא נמדדת ב-TBW – שזה Terabyte Written, כאשר מדובר על הכמות הכוללת של מידע הנכתב על הדיסק מרגע יציאתו מפס היצור. פירמוט, חלוקה לפרטישנים, כתיבה מחדש, פירמוט מחדש, חלוקה מחדש – אינה "מאפסת" את כמות הנתונים הנכתבים על הדיסק וניתן לראות את כמות הקריאה וכתיבה על דיסק באמצעות כלים שיודעים לקרוא את ה-S.M.A.R.T בדיסק (לא חשוב אם מדובר ב-SATA, SAS, NVME). היצרן מציין כמות מסויימת ולאחריה נדלק "דגל" של WEAR out ב-S.M.A.R.T ומאותו רגע – פגה האחריות. היצרן גם מציין כמות שנות אחריות למקרה ולא מגיעים לכמות הכתיבה/שכתוב המותרת, בדרך כלל זה 3 או 5 שנים (רק בחלק קטן של הדיסקים יש אחריות ל-10 שנים, כמו לסמסונג 850 PRO)

בדיסקים ל-Enterprise המדידה היא שונה והולכת לפי DWPD, כלומר Drive Write Per Day, ובמילים פשוטות: כמה פעמים אתה יכול לכתוב על הדיסק מאפס כל יום ולמלא אותו (אף פעם לא מומלץ למלא SSD עד הסוף, תמיד מומלץ להשאיר 5-10% מחוץ לפרטישן שכותבים עליו, וזאת כדי לאפשר לבקר להזיז נתונים שנכתבים על תאים בעייתיים ובכך לתת לדיסק להמשיך לפעול כמצופה) וגם כאן יש כמות שנים לאחריות (3-5). על הנייר, במידה ותעבור את כמות ה-DWPD, דגל ה-Wear Out ב-S.M.A.R.T ידלק והאחריות תפוג.

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

בניגוד לדיסקים מכניים, דיסקים SSD (שוב, אין זה משנה איזה חיבור, ולמעט דיסקים Optane מהקצה הגבוה – שהם אינם מבוססי NAND Flash) צריכים טמפרטורה מסויימת כדי לכתוב. בדרך כלל SSD במצב אידיאלי שלא מבצע עבודה יהיה בטמפרטורות הנעות בין 30-40 מעלות וכשמתחילים לכתוב נתונים, החום עולה, וככל שכותבים עוד ועוד נתונים (עשרות עד מאות ג'יגהבייט) החום עולה ברציפות וכשהוא מגיע בערך ל-78 מעלות ומעלה, מהירות הכתיבה יורדת משמעותית (אגב, זה קורה גם ב-Mixed Intense SSD אם כי בצורה פחות דרסטית) לעשרות מגהבייט עד קצת מעל 100 מגהבייט לשניה כשכותבים מעל 30-50 ג'יגהבייט באופן רצוף. בכתיבה אקראית/מזדמנת קצרה (עד 5-10 ג'יגהבייט, תלוי ב-SSD), ה-SSD יפעיל אלגוריתמים שונים שכל מטרתם היא לחסוך בכתיבה, כך שגם בעבודות כבדות מאוד, ב-99.99% מהמקרים לא תגיעו לכמות הכתיבה המותרת ביום (כמות הקריאה ביום אינה מוגבלת מבחינת אחריות בשום SSD), ולכן – אין זה משנה אם המערכת שלכם כותבת ביום 2 ג'יגהבייט או 300 ג'יגהבייט ביום על SSD – זה לא "טוחן" אותו (ולא תשמעו ממנו קולות כמו בדיסקים מכניים ישנים).

הדברים שכן יאיטו SSD הם:

  1. ניצול 100% מהדיסק כך שלא נשאר למערכת מקום להעברת מידע שמאוחסן בתאים דפוקים (ראו המלצה לעיל בנוגע ל-Provision).
  2. דיסקים SSD ביתיים זולים (Corsair MX300, MX500, סאנדיסק ביתיים ישנים)
  3. דיסקים SSD לא DRAM או SLC Cache שמשמש כחוצץ ל-NAND.

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

נעבור מכאן לדיסקים SSD יד שניה: ישנם מדי פעם באתרי מכירה שונים (איביי, אמזון וכו') דיסקים משומשים של Enterprise במחיר זול ומפתה. אלו דיסקים שלא ממש יתאימו לחברות מכיוון שהיצרן לא יתן לכם כרוכשים אחריות כלשהי. מה שכן, הם יכולים להתאים למקומות ואנשים שלא אכפת להם לרכוש בזול תוך נטילת סיכון שלא תהיה אחריות. מבחינת ביצועים – לא אמורה להיות בעיה איתם. חשוב, אם אפשר, לבקש מהמוכר לראות תמונת סטטוס של ה-S.M.A.R.T לפני רכישה (בלינוקס אפשר לבדוק זאת עם smartctl, ב-Windows יש S.M.A.R.T. Monitoring Tools) ולבדוק מה הגבולות כתיבה שהיצרן ציין לגבי אותו SSD.

נקודה נוספת שחשובה הן בדיסקים NVME חדשים או יד שניה: אם אתם מחברים מספר דיסקים כ-RAID כלשהו (לא RAID-5!) ואתם מצפים לראות ב-OS מהירות כתיבה/קריאה כפול מה שכתוב על המדבקה/במפרט – תתכוננו להפתעות. Windows Server 2019 במערכת עם 12 דיסקים ב-RAID-6 לדוגמא נתנה ביצועים של … 10 ג'יגהבייט לשניה בקריאה, גם אחרי כיוונון כל הגדרה אפשרית, ובלינוקס עם ZFS יש תוצאות הרבה יותר טובות אך שאינן מגיעות למהירות המדבקה (אז אל תסמכו על JMeter).

דיסקים שכדאי לצפות לקראתם בשנה הבאה (לפי השמועות וההדלפות) – לכל אלו שצריכים דיסקים SSD NVME לעבודות כבדות (Cache, SQL) ואחרים:

  • סמסונג ZET דור שני וביצועים מאוד מרשימים בקריאה, ו-Latency שמאוד קרוב ל-DRAM
  • Optane דור שני – דיסקים יותר גדולים, פתרון יותר טוב לקירור, ביצועים בערך כמו הדור הנוכחי.
  • דיסקים SSD ל-Enterprise מבוססי QLC (כל היצרנים) זולים. עדיף לוותר, ביצועי כתיבה מחרידים!
  • שרתים עם דיסקים SSD בחיבור U.3 או מסוג Ruler. תהיו קונסרבטיביים ואל תרכשו – החברות (סמסונג, אינטל ועוד כמה) עדיין במריבות לגבי הסטנדרט. רוצים NVME? רק עם חיבור U.2 או כרטיסי PCIe.

עננים ציבוריים מקומיים מול עננים ציבוריים אמיתיים

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

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

נדמיין עתה מצב תיאורתי שבו החלטתי להתחרות בכולם. אני משיג VC נחמדים ומשכנע אותם להשקיע בעסק שלי סכום נחמד של 8 ספרות (בדולרים). אני רוכש כמה עשרות ארונות, מפזר אותם בין ספקי האינטרנט השונים בארץ, "מפוצץ" את כולם בשרתים חדשים ואני מקים בדרך SDN ו-Software defined storage מפלצתי. על כל התשתית הזו אני מקים מערכת שתתן ללקוחות דרך ממשק WEB ודרך API את השרותים הבאים:

וירטואליזציה, קונטיינרים (עצמאית, ללא צורך בהקמת מכונות וירטואליות), Serverless, הקמת "ברזלים" יעודיים ללקוח, שרותי Object Storage ו-Block Storage, שרותי NFS/CIFS יעודיים לרשת שלך בלבד, שרות רשת פרטית משלך (כמו VPC), שרותי Load Balancer, שרותי DNS, שרותי identity, שרותי Imaging למכונות VM שלך, שרותי אורקסטרציה, שרותי Messaging, שרותי התראות, שמירת משאבים וחלוקתם על ידי הלקוח, אורקסטרציית קונטיינרים, ביג דאטה, שירותי גיבוי, שחזור ו-DR, תאימות ל-EC2 (כפרוקסי), מטריקות, ניטור מלא של הכל, שרותי Event (כמו Cloud trail), שרותי Governance ושרות יחודי של Benchmarks, וכמובן – שרותי Billing ו-Chargeback – וכל זה זמין ביום הראשון. תירשם, תכניס פרטי כרטיס אשראי וצא לדרך.

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

ספקי ענן מקומיים, בניגוד לספקי ענן ציבוריים גדולים – יכולים להציע כמות מוגבלת מאוד של שרותים, ובנוסף – לא יהיה לכם מושג מה תקבלו מבחינת ביצועים (לא מאמינים? קחו את החוזה מול הספק שלכם, חפשו את המילים CPU Pinning או התחייבות לגבי ביצועי Compute, סטורג' וכו'. אני מאמין שלא תמצאו את זה מוזכר במסמכים). טכנית, אם ניקח לדוגמא שרת עם 16 ליבות, אין שום מגבלה שיכולה למנוע הרצה של מכונה וירטואלית עם 32 ליבות. אתה כלקוח יכול לבדוק אם זה מה שאתה מקבל אם תריץ אפליקציית Benchmark כלשהי שוב ושוב במשך כמה ימים ותוציא את הפלט לקובץ ואז תוכל להשוות .. ולהתעצבן.

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

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

לסיכום, אני ממליץ לחשוב על 2 דברים חשובים:

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

כמה מילים על קונטיינרים "מבחוץ"

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

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

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

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

הפצות לינוקס כמו רד-האט, CentOS, SuSE, אורקל לינוקס, דביאן, אובונטו וכו' – נבנית בכל פעם מאפס על ידי הידור קוד של חבילות שונות עד שנבנית הפצה בסיסית לחלוטין. להפצה הזו המערכת תעשה Boot, ומשם היא תמשיך להדר את הקוד של כל החבילות שונות (ב-רד-האט, או כל הפצה מבוססת RPM יש חבילות מיוחדות שנקראות SRPM שמכילות קוד מקור + טלאים וסקריפטים כדי לקמפל אותה). ההפצה כוללת חבילות שונות מבחוץ שעברו בתוך יצרן ההפצה בדיקת קוד וברוב המקרים גם שינויים על מנת לרוץ על אותה הפצת לינוקס ספציפית.

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

בחברות גדולות (כמו בנקים וכו') בדרך כלל לא פותחים את חומת האש להורדת חבילות מיצרן ההפצה באופן ישיר ומשתמשים בתוכנת-אמצע (Middleware) כמו Red Hat Satellite כדי להתקין את ההפצות ועדכונים על שרתים ומחשבים נוספים. ברוב המקומות האחרים שאינם עובדים ישירות מול רד-האט או עובדים עם הפצות אחרות, יש כלי אחר חינמי ובקוד פתוח כמו SpaceWalk שמאפשר להפיץ פנימית בשרתי החברה (ובחשבון הפרטי בענן הציבורי של החברה) עדכוני תוכנה בצורה מאובטחת ומוצפנת (אפשר לשלב בתוך הכלי גם את ה-CA של החברה).

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

איך? די פשוט. כמעט בכל קונטיינר שמופיע ב-Repository ציבורי (כמו Docker Hub) אנחנו נמצא קישור ל-Github שמכיל את קוד ה-Dockerfile. נוריד את קבצי ה-Dockerfile ואחרים מה-git (פקודת git checkout) ואז פשוט נבנה את הקונטיינר מחדש. היתרון הגדול בבניית הקונטיינר מחדש הוא בכך שחבילות רבות מקבלות עדכוני אבטחה וקונטיינרים הזמינים ב-repo ציבורי לא תמיד מעודכנים, וכך נוכל לבנות אותם עם הגרסאות המעודכנות עם תיקוני אבטחה ומה שיותר חשוב – החבילות מגיעות ממקום ידוע (אם משתמשים ב-spacewalk – אז הם מגיעים משרת פנימי בחברה שהוריד את החבילות ממקור בטוח), ואפשר כמובן לאחסן את אותם קונטיינרים ב-Registry פרטי פנימי (הנה הוראות איך להקים אחד באובונטו).

במקרים מסויימים ה-Dockerfile כולל פקודת COPY וקבצי המקור אינם נמצאים ב-repo באותו git. התייחסו במשנה זהירות לקונטיינרים מסוג זה, ובמקרים כאלו אם אתם ממש צריכים את הקונטיינר הספציפי, אולי כדאי להריץ עליו סריקה עם אחד הכלים שהזכרתי לעיל.

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

כמה מילים על חברות תוכנה ומשחקים באש

כל מי שמכיר כיום את שוק התוכנה בארץ, יודע שיש המון חברות תוכנה שונות בגדלים שונים שמוכרות את המוצר שלהן או כמוצר מדף, כ-Appliance, כ-שרות SAAS ועוד. בלא מעט מקרים השיטה המקובלת ל-Delivery של תוכנה – היא Image להרצה על פתרון וירטואליזציה או כ-Image שנמכר בכל מיני "שווקים" של ספקי ענן ציבורי, וכמובן יש את אלו שמוכרים "ברזל" כשהכל מוכן, רק צריך לחבר, להגדיר IP, שם משתמש ולהתחיל לעבוד עם הפתרון.

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

אני רוצה לתת דוגמא מעולם ה-appliance שאני בונה ללקוחות לפעמים. לקוח פוטנציאלי פונה אליי, מציין שהם מפתחים תוכנה XYZ והם מעוניינים שאפתח להם פתרון "סגור" – כלומר קופסא (או Image, או שניהם) שיריצו את התוכנה, שהפתרון שלי יכלול הפצת לינוקס מינימלית כולל כל מה שהם צריכים, סקריפטים לעדכון (אוטומטי או ידני), ותמיכה מלאה בכל הפונקציונאליות של הקופסא (מספר חיבורי רשת, SNMP וכו').

בדרך כלל ההסכם שלי מול חברות כאלו הוא פשוט:

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

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

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

הבעיות של היום ומחר – עם פתרונות של אתמול ושלשום

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

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

לאחר קריאת החוברת או ההמלצות – אני מחזיר תשובה לפונה, בדרך כלל התשובה תהיה אחת משלושת האופציות הבאות:

  • ההמלצות טובות ונכונות (אם יהיו לי הערות או נקודות מסויימות – אציין אותן)
  • הרעיון העקרוני בהמלצות נכון, אבל מומלץ לשלב פלטפורמות X,Y וטכנולוגיות A,B.
  • אתם שילמתם על היעוץ הזה? ברצינות? אתם נמצאים בשנות ה-90 או ה-2000 או מה?

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

להלן שתי דוגמאות, מהחודשים האחרונים:

  • חברה מסויימת רצתה להריץ פלטפורמה מסויימת על לינוקס מספר רב של פעמים. המערכת אמורה להיות פתוחה לרשת וההפניות יועברו דרך Load Balancer (אני לא יכול לפרט עקב הסכמי סודיות). היעוץ שהם קיבלו: לרכוש 18 שרתים עם מפרט די "כבד", רכישה של Load Balancer חומרתי, סטורג' מפלצתי, לכל הברזלים רשיון VMWare Enterprise.
    ההצעה שלי (שהתקבלה): במקום 18 שרתים עם מפרט כבד, 2 שרתים עם מפרט נמוך, 4 שרתים עם מפרט כבד (יחסית, הרבה זכרון), מערכת OpenShift, ושרת נוסף קטן שיריץ ESXI כדי להריץ 2 מכונות VM שמריצות Windows. סטורג' – או בניה או לרכוש משהו קטן מכיוון שאין צורך ב-IOPS רציני או כמות אחסון גדולה. הפלטפורמה תרוץ כולה על קונטיינרים, ובהתבסס על הסטטיסטיקה שנמסרה לי, אני מתקשה להאמין שתהיה צריכת משאבים של יותר מ-40% בכל השרתים.
  • חברת מדיה מסויימת רצתה לאחסן תכנים רבים ולהערכתם הם יגדלו בכל שנה בסביבות ה-100-150 טרהבייט. הדרישה – אפשרות גדילה ללא SPOF (כלומר: Single Point of Failure) ומבלי לרדת בכמות רוחב הפס הפנימי, אדרבא – אם אפשר שתהיה גדולה יותר ויותר – הם ישמחו. כאן לא היתה חברה מסויימת שנתנה יעוץ, אלא החברה ביקשה מכל מפיצי הסטורג'ים הגדולים והמוכרים בארץ, ואני התבקשתי להמליץ על אחת מההצעות.
    הבעיה: אף הצעה לא כללה פתרון אחסון Scale Out. כל ההצעות היו פחות או יותר "תוסיף מדף" ובקשר לשרידות – קנה שתי ראשים. לפיכך המלצתי הפשוטה (שהתקבלה) היתה: זרקו את ההצעות ובקשו או פתרון Scale Out או לבנות פתרון Scale Out מבוסס קוד פתוח או תוכנה סגורה שמציעות יצרני שרתים וחברות אחרות, ורשת עם Backbone של 40 ג'יגהביט שיגדלו בהמשך לכיוון ה-100 ג'יגהביט.

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

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

יש לכם שרתים/סטורג' של HPE עם SAS SSD? מומלץ לקרוא

חברת HPE הוציאו לאחרונה עדכון דחוף לקושחות עבור מספר דיסקים SSD בחיבור SAS שנמצאים על מגוון הציוד ש-HPE מוכרת: שרתים (Proliant, Apollo), ועבור פתרוות אחסון: (JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4335,StoreVirtual 3200). דגמי הדיסקים וכל ההערות ולינקים לאפליקציות תיקון מופיעים במסמך ש-HPE פרסמה.

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

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

עקב באג בקושחת הבקר על דיסק ה-SSD, לאחר 32,768 שעות (כלומר 3 שנים, 270 יום, ו-8 שעות) כל הנתונים על דיסק ה-SSD יעלמו. זה לא "אם", לא "אולי", זה ודאי. מישהו כתב קוד די דבילי וזו התוצאה. התיקון עצמו משכתב קושחה חדשה לכונן ה-SSD ועל מנת שהקוד יפעל, יש צורך ב-Reboot למערכת (HPE כותבים שאין צורך לעשות Reboot, מהיכרות קודמת עם בקרי ה-Smart של HPE, אני ממליץ דווקא כן לעשות Reboot). התיקון הזה ימנע את ה-Time Bomb לכונני ה-SSD הנ"ל.

עכשיו הגירסה היותר "גיקית" לאנשים שצריכים לטפל בדברים. הדברים שאני כותב רלוונטיים למערכות VMWare ESXi ולהפצות לינוקס השונות (כרגע, רשמית, בלינוקס ההפצות הנתמכות הן RedHat, CentOS, SuSE, אם אתם עם אובונטו או דביאן, תצטרכו קצת להכיר את rpm2cpio).

מבחינה טכנית, לאחר הזמן הנ"ל (3 שנים, 270 יום, 8 שעות), מה שיקרה הוא שהמפות שהבקר משתמש בהם כדי לדעת היכן כל דבר מאוחסן, אלו תאים (Cells) דפוקים, אופטימיזציה וכו' – ימחקו. ה-DATA עדיין נשאר על שבבי ה-Flash, אבל בלי המפות אי אפשר לעשות כלום, אין כאן לצערי תהליך Rebuild שאפשר לעשות (טכנית, זה אפשרי, אם מלחימים JTAG ל-SSD ו"מדברים" ישירות עם הבקר SSD, אבל אז צריך להכיר את הבקר, פקודות, אסמבלר של ARM וכו' – והידע הזה לא קיים ציבורית).

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

  • בלינוקס קיים זמן רב שרות מובנה של עדכון קושחה מבלי שתצטרך לבדוק/לנחש איזה חומרה יש לך בתוך השרת. כל מה שצריך זה להתקין את חבילת fwupd מהפצת הלינוקס שלך, להריץ (כ-root) פקודה fwupdmgr get-updates ואת הפקודה fwupdmgr update והמערכת תוריד אוטומטית את הקושחות הרלוונטיות לשרת/מחשב שלך. כשתבצע Reboot הוא יפעיל אפליקציה דרך ה-UEFI שמעדכנת את הקושחות שצריך, וכשזה מסתיים, המערכת תבצע אוטומטית reboot ובכך העניין טופל. הבעיה? ב-HPE בקושי שולחים עדכוני קושחה לשרות הזה.
  • HPE מוציאים שני עדכונים שונים שמיועדים ל-SSD שונים. HPE כבר הוציאו אפליקציה בלינוקס מאוד ותיקה שיכולה לתשאל את בקר ה-SMART (היא נקראת: hpacucli) אלו דיסקים יש ובכך להשוות דגמים ולהתקין את הקושחה, אבל לא, הצורה שהם כתבו את סקריפט העדכונים תגרום לאנשי לינוקס ותיקים לרענן את קטלוג הקללות שלהם.

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

  • הראשונה – לתשאל את הבקר, וזה במקרה אם אתה מריץ לינוקס פיזית על השרת, פקודה כמו hpacucli ctrl slot=0 pd all show תציג לך את הדיסקים, דגם, מספר סידורי וכו', כאן grep ו-awk יכולים לעזור לך לעשות סדר ולמצוא את הנתונים.
  • השניה – לבצע reboot לשרת ולהיכנס לתפריט ה-SMART. שם מופיעים לך דגמי הדיסקים.
  • השלישית, קצת פחות מומלצת – ללכת לשרת, להוציא דיסק SSD החוצה ולהשוות את הדגם.

אם יש לך דיסקים שנכללים בעדכון, תצטרך לבחור להוריד את הסקריפט הרלוונטי, לעקוב אחרי ההוראות ולשלוח את העדכונים שיעברו דרך ה-SMART ישירות לבקר ה-SSD ויעדכנו אותו. האפשרות האחרת שיש זה להוריד SPP, להוריד את החבילות, לשים באיזו מכונת Windows או לזרוק הכל לדיסק און קי (לשים את החבילות תחת תיקיית packages/ ) ולהשתמש ב-SUM. זה כמובן אומר שתצטרך להשבית את המכונה עד שתעדכן את הקושחות באותם דיסקים.

חשוב לזכור: תהליך עדכון קושחת בקר SSD מבצע Reboot לאותו דיסק SSD (לא לשרת), ולכן יכולים "לקפוץ" לכם התראות על בעייתיות באותו דיסק SSD, עד שהמערכת "מבינה" שהדיסק תקין, קחו זאת בחשבון לפני שאתם נזעקים ממערכת ההתראות שלכם, ובגלל זה אני ממליץ במקרים שמדובר בשרת שמריץ ESXi לעשות את העדכונים לאחר שהעפתם ממנו (עם live migrate) את כל מכונות ה-VM ולאחר ה-Reboot לתת ל-DRS להזיז מכונות VM לשרת המעודכן (אם אין DRS, תזיזו ידנית).

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

קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

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

וזהו – שההצהרה לעיל נכונה רק בחלק מהמקרים. אם אתה מריץ יותר מ-5-10 שרתי Cassandra או Kafka כפרודקשן ואתה מכניס דרך ה"מפיקים" (Producers) המון מידע שמגיע ממאות/אלפי חיישנים או מקורות שונים, הסטורג' הקנייני יהפך די מהר לצוואר הבקבוק.

אחת השגיאות שאפשר לראות בפורומים שונים, זה שאנשים שעובדים עם פתרונות Scale Out מחפשים איך לאחסן את כמות הנתונים שהולכת וגודלת והם עדיין לא מכירים/מבינים את עניין ההוספה המתמדת של ברזלים ודיסקים מקומיים – והם תמיד יקבלו את הצעות הפתרונות שמתאימים ל-Scale Up: לתכנן את הגדילה למשך שנה וכו' וכו' ואז לבחור סטורג'. זו טעות, כי בעולם המדידות/דגימות ושימוש בפלטפורמות Scale Out אתה מחפש לקבל כמה שיותר מידע, לא כמה שפחות, ויכול להיות שהחודש הקרוב אתה תוסיף עוד 4 טרה מידע לחודש אבל בעוד 3 חודשים זה יקפוץ ל-15 טרה לחודש. בגדלים כאלו, שום פתרון סטורג' קנייני אינו מתאים, אלא אם רוצים "לשרוף" את תקציב החברה, ולכן יש צורך ללכת לפי הפתרון של הפלטפורמה, לא לפי שם/דגם של סטורג'.

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.