תגית: Storage

על 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 זה לא ממש יעניין אתכם.

אחסון אובייקטים (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 ישראל.

נקודות שיצרני Storage לא רוצים שתדעו

כפרילאנסר שמוכר שרות הטמעה/התקנה של SDS (כלומר Software Defined Storage) אני משתדל בדרך כלל להיות מעודכן גם ב"רכילות" של מה קורה אצל אלו שמוכרים פתרונות כ"קופסאות סגורות", מה-NetApp ו-Dell/EMC ועד ליצרני פתרונות AFA (כלומר All Flash Array) למיניהם. תמיד נחמד לדעת על כל מיני פתרונות שיצרני ה-AFA מכניסים או הולכים להכניס בשעה שהגדולים .. המהנדסים שלהם מדברים על פתרונות כאלו בארוחת צהרים, ההנהלה לא הכניסה את זה ל-Road Map עדיין.

כשזה מגיע ל-SDS, החיים קלים ופשוטים: הלקוח רוכש שרת, עם כל הציוד הנדרש, דיסקים וכו', הוא נניח שוכר את שרותיי, אני מציע לו מספר פתרונות, בין בקוד פתוח או סגור (כולם מבוססי לינוקס למעט Windows – ב-Windows יש לו כיום את Storage Spaces [שהוא אגב, אינטרגלי ב-Windows Server 2016] והוא ממש לא צריך אותי לשם כך), הלקוח בוחר, מרימים גירסה, אני מגדיר את כל מה שהלקוח מבקש, מריצים סידרת טסטים ואם הוא מרוצה – מכניסים לפרודקשן. במקרה ויש לו בעיות עם המערכת הוא פונה אליי ואני מטפל בבעיה אם מדובר בתוכנה או מבקש ממנו לפנות למי שהוא קנה ממנו את הברזל כדי להחליף דיסק/זכרון/לוח/כרטיס-רשת וכו'. פשוט וקל.

אבל כשזה מגיע לסטורג' סגור, אני ממליץ לעבוד בשיטה שאני קורא לה "הבן של מי אתה?"

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

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

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

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

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

  • אם אתם חושבים לרכוש סטורג' – ראשית מומלץ לבדוק לגבי המוצר שאתם רוצים לרכוש – האם הוא מוצר שיוצר בעבר ע"י חברה אחרת שנרכשה ע"י אותה חברה גדולה שאתה רוצה לרכוש ממנה. אם כן – עדיף לחפש מוצר אחר.
  • אם כבר רכשתם מוצר מחברה קטנה שנרכשה ע"י החברה הגדולה, תפנו זמן לצוות הטכני ותתנו להם הוראה להתחיל להתעמק ב"בפנוכו" של הסטורג', לא ברמת GUI אלא ברמת CLI. לא צריך לנסות דברים שיזיקו, אבל כדאי שיכירו את הפקודות, קבצי הקונפיגורציה ומי עושה מה.
    • עוד משהו שאתם יכולים לעשות – זה להיעזר בחברים ולרכוש בנק שעות תמיכה מאינטגרטור שמכיר את הסטורג' הזה. אישית אינני נותן שרותים לסטורג' סגורים, אבל מהיכרות עם חברים שנתנו תמיכה לכל מיני חברות ועסקים שיש להם סטורג'ים כאלו – ההשקעה בבנק שעות כזה הצילה חברות לא פעם ולא פעמיים בהשוואה ל"טקס מעבר-בגהינום" של התמיכה בחברה הגדולה. קנו לכם כמה עשרות שעות שיהיה לכם שקט במקרה של תקלות (יהיה לכם עדיין את היתרון שבמקרה ויש תקלת חומרה – החברה הגדולה תשלח נציג שיבוא ויחליף את הציוד התקול).
  • העולם עובר ל-Software Defined Everything, מסטורג' לרשת ודברים נוספים, ולכן מומלץ לשקול בחיוב לקחת פתרון Software Defined Storage. אל תאמינו לי, תשאלו את VMWare, Microsoft, Red Hat, Amazon וחברות מפורסמות אחרות. עם SDS אין לך שום "מסע גהינום" של תמיכה, יועץ/אינטגרטור נותן לך תמיכה ואם אינך מרוצה אפשר להחליף אותו ביועץ/אינטגרטור או חברה שנותנת את אותם שרותים ואם יש תקלת חומרה – החברה שמכרה לך את הברזל תחליף לך את הציוד, כך שזמן ההשבתה מתקצר משמעותית, יש למי לפנות וניתן לקבל בזמן קצר פתרונות.

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

על אחסון וגדילה

כשמדברים על אחסון (כ-Storage), רובנו נתייחס למכונה הגדולה שנמצאת בחברה, ה-Storage הזה שברוב מוחלט של המקרים הוא קופסא של יצרן כלשהו. זה יכול להיות של NetApp, של EMC, של IBM, של HP ושלל חברות גדולות וקטנות, כל חברה בד"כ תקנה לפני הצרכים או לפי ההמלצות, ואצל רובן תהיה "קופסא" אחת כזו שאליה משורשרים "מגשים" של דיסקים. זה יכול להיות דיסקים מכניים מבוססי SAS, דיסקים שהם SSD, דיסקים שהם NL-SAS או אפילו במקרים מסויימים – SATA.

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

מה קורה כשכמות המקום הפנוי היא קטנה? בד"כ מוסיפים עוד "מגש" (במקרים מסויימים זה נקרא גם JBOD) והדיסקים שיהיו בפנים יכולים להיות מסוגים שונים, בהתאם לתקציב ולביצועים שמעוניינים לקבל. הגישה הזו נקראת Scale Up.

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

בנוסף – ישנם 2 בעיות רציניות:

הבעיה הראשונה נקראת SPOF (או Single Point Of Failure): הגדרות שגויות, מעבד שמתקלגל, זכרון שנדפק, בקר שהפסיק לעבוד בצורה תקינה – והפתרון אחסון שלך יתן ביצועים גרועים או שבמקרה הגרוע – יפסיק לעבוד. נכון, יש SLA שסביר להניח שרכשתם ובו טכנאי של החברה המייצרת/יבואן הפתרון יתחבר אליכם מרחוק או יגיע אליכם תוך זמן קצר, אך עדיין, גם אם הוא יתקן את התקלה, תצטרך ברוב המקרים להפעיל את כל המכונות הוירטואליות מחדש, לוודא שכל השרותים למעלה, לוודא שהגדרות שביצעו אנשי ה-IT באמת נשמרו ולא צריכים להגדיר מחדש כדי ששרותים יעלו ובקיצור – כמעט שום תקלה שקשורה לתיקון האחסון אינה מסתיימת בדקות ספורות אלא יותר בשעות.

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

הבעיה השניה שהיא יותר מהותית באותם אחסונים כמו NetApp ואחרים – היא "קניינות" של הפתרון, כלומר שהכל סגור מבחינת ה"ברזל", הדיסקים והמערכות שעובדות בתוכו. אם מחר יפנה אליך לדוגמא יבואן דיסקים ויציע לך מבצע-משוגע של דיסקים מבוססי SAS גדולים במחיר של 3 ותקבל 4 (לדוגמא) – לא תוכל להכניס את הדיסקים הללו לאחסונים הנ"ל. ישנו קוד מיוחד שבודק את הדיסק שהכנסת ל"מגש" וברגע שהוא מוצא שהדיסק אינו מאותו יצרן/סוג מסויים שיצרן האחסון עובד איתו – המערכת פשוט לא תהיה מוכנה להכניס את הדיסקים החדשים שקנית לשימוש. אתה גם לא יכול להכניס JBOD שאינם של אותו יצרן אחסון לשימוש עם פתרון האחסון. בקיצור – הכל צריך לעבור דרך השיווק של יצרן פתרון האחסון שיש לך, והוא כמובן נוקב במחירים הרבה יותר גבוהים ממה שאתה יכול לקנות בשוק החופשי. (אם כי אסייג שבחלק מהפתרון לקצה היותר נמוך, במיוחד פתרונות NAS – אין בעיה להכניס דיסק של כל יצרן, אבל הבעיות של פתרונות כאלו הם עדיין ה-Scaling).

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

מ-Scale Up נעבור למושג שמוכר יותר בתחום ה-High Performance Computing ותחום הענן – זהו תחום ה-Scale Out בפתרונות אחסון.

סביר להניח שלקוראי פוסט זה יש חשבון אחד או יותר אצל אחד מספקי פתרון ענן כלשהו, בין אם זה אמזון , או Google Compute Platform או Azure של מיקרוסופט – ונגזרותיהם: לאמזון יש את S3, לגוגל יש את ה-Google Drive, למיקרוסופט יש את OneDrive ויש גם פתרונות אחרים כמו DropBox ואחרים.

המכנה המשותף לכל אותם פתרונות אחסון קבצים בענן – זה מערכות האחסון שלהם. אף אחד מספקי הענן לא משתמש ב-NetApp או EMC והם לא משתמשים בדיסקים SAS במהירות 15K RPM כדי לאחסן את הקבצים שאתה מעלה (אינני מדבר על אחסון של מכונות וירטואליות או EBS – לזה נגיע בהמשך). במה הם משתמשים? בדיסקים הכי פשוטים שיש (כן, גם דיסקים איטיים). מהי מערכת האחסון שלהם? לכל אחד מספקי הענן יש פתרון In House משלו שהמתכנתים שלו כתבו או השתמשו בפתרון קוד פתוח אחר (אף אחד מהספקים לא מפרט) וברוב המקרים זה רץ על לינוקס. הם כמובן משתמשים בדיסקים של SSD כחלק מהפתרון, ואת השרידות הם מבצעים בכך שהם כותבים את אותו הקובץ למספר מקומות אחרים באותו Data Center. מכיוון שמדובר בפתרון שמכיל מאות אלפי (ויותר) דיסקים קשיחים – הפתרון מבחינה טכנית אצלהם שונה לחלוטין ממה שיש ב-Corporate. אין RAID ברמה כלשהי, ואין מעבדים קניינים מיוחדים בתוך שרתי האחסון (שאליו מחוברים כמות רצינית של JBOD). כך מצד אחד הם חוסכים בהשקעה ומצד שני הם יכולים לתת רמת שרידות מעולה. אחרי הכל, במחיר של דיסק אחד ל-Enterprise אפשר לקנות 3 דיסקים הרבה יותר גדולים מבוססי SATA פשוטים.

כשזה מגיע לאחסון מכונות וירטואליות או אחסון שיותר מוכר כ-Raw Storage – לדוגמא EBS, PD, Drives – בהתאם לספק ענן, גם כאן ספקי הענן לא "רצים" לקנות את פתרונות ה-Enterprise והם מעדיפים פתרונות SSD שהם זולים, גם אם חיי המוצר יהיו קצרים, והספקים משתמשים בכל טריק אפשרי כדי לתת למכונות שלך בענן ביצועים גבוהים (יחסית), אבל שוב -אין שימוש בפתרונות אחסון קנייניים מבחוץ כמו של EMC ואחרים. זה פשוט לא שווה להם פיננסית, במיוחד בתחרות האכזרית כיום שכל ספק חותך בעשרות אחוזים את המחיר והשאר "נגררים" אחריו בחיתוכי מחיר לאחר מספר ימים.

הפתרונות שתיארתי מבחינת ספקי הענן – הם נכללים בקטגוריות ה-Scale Out, כלומר הפתרונות לא מבוססים על שרת אחסון יחיד ואולי עוד Mirror, אלא הם מתחילים ב-3 שרתים ומעלה כאשר העומס מחולק בין השרתים. במקרה של ספקי הענן מדובר כמובן בהרבה יותר מ-3, ומכיוון שהכל נכתב בכמה וכמה עותקים, גם אם יפלו שרתים שמחזיקים מאות דיסקים, אתה לא תרגיש בכלום, כי אתה תקבל את השרות משרתי אחסון שכנים שיושבים באותו Data Center.

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

בפוסט הבא אתאר כיצד פתרון Scale Out יכול להתאים ל-Enterprise/Corporate, מהם ה"מועמדים", יתרונות וחסרונות ובמיוחד – על Ceph.