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

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

‍

‍

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

‍

אז מה עושים?

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

‍

לסיכום

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

‍

מאת: חץ בן חמו, יועץ ומומחה בנושאי ענן, וירטואליזציה, לינוקס, אחסון ועוד

רוצים להתעדכן בתכנים נוספים בנושאי ארכיטקטורת ענן? הצטרפו לפורום המקצועי של IsraelClouds בתחום > להרשמה