בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של 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.