אחת למספר שנים מתרחשים שינויים מהותיים בתחום הסטורג'. לפני מס' שנים נכנס דבר שנקרא Object Storage – זו צורה שונה לאחסון קבצים ונתונים שבמקרים רבים אינה משתמשת ב-File system רגיל. חברות כמו Seagate לדוגמא הוציאו מספר דיסקים קשיחים ובנו חיבור חדש לדיסקים – חיבור Ethernet ישירות לדיסק, מה שמחייב כמובן מערכת אחסון אחרת. (נכון להרגע, הפתרון הזה יותר מתאים לחברות כמו אמזון, גוגל ומיקרוסופט, או לחברות שבונות את ה-Object Storage שלהם, גם מבחינת חומרה).
אחד השינויים הגדולים שנכנסו היה עניין ה-Scale Out וכיום כל יצרן סטורג' שמכבד את עצמו מציע דגם זה או אחר (או משפחה) של פתרונות אחסון Scale Out.
אך מהו בעצם פתרון Scale Out?
חברות אחסון רבות לקחו את המושג "Scale Out" לכיוון שהם רוצים. יש חברות שמייצרות HCI (כלומר Hyper Converged) שלקחו את המושג Scale Out לכיוון הוספת שרתים שיתנו לך יותר משאבי מחשוב/רשת/אחסון. חברות אחרות לוקחות את זה לכיוון שאם אתה מרים ערימת שרתים, אתה מתקין VM בכל אחד מהם שמחובר לדיסקים המקומיים בכל שרת וישנה תוכנה שמתחברת לכולם ובכך נוצר Storage (אין Networking גודל בכל מכונה והמכונה לאו דווקא מריצה מכונות VM אחרות) ויש כמובן את ה-Scale Out שעליו דיברתי בפוסט הקודם – ערימת שרתים מלאים דיסקים שלא מריצים מכונות VM או Payload משלך אלא תוכנה יעודית של יצרן הפתרון בלבד.
לעומת פתרון Scale Out – יש פתרון ותיק שנקרא Scale Up, שבו יש פתרון שמורכב ממערכת אחת (או 2 לשרידות) ודרך הגדלת האחסון היא הוספת דיסקים מכניים (או SSD אם רוצים יותר IOPS), אך כמות הברזלים נשארת זהה.
המכנה המשותף לכולם הוא פשוט: צריך עוד מקום אחסון? אתה מוסיף עוד שרתים, או שאם אתה רוצה – אתה מוסיף דיסקים, אבל לכל השרתים שיש בהם דיסקים (למעט HCI, בפתרונות אחרים, במיוחד בתחום HPC – מוסיפים שרתים כי Resizing לכל מכונה יקח זמן רב מדי).
לא כל פתרון Scale Out מתאים לכל הסיטואציות. בתחום HCI לדוגמא, אתה יכול להוסיף עוד כמה טרהבייט בחישוב הכולל בכך שתוסיף עוד כמה דיסקים (מכניים/SSD) פר מכונה ובכך תקבל יותר אחסון ויותר IOPS, אבל פתרון כזה אינו מתאים אם לדוגמא אתה צריך מאות טרהבייטים עד פטהבייטים (ומעלה) של אחסון ואין לך צורך בהרבה מקום נוסף למכונות VM. בסיטואציה כזו אתה חייב פתרון אחסון Scale Out שידע לעמוד בשרידות של שרת אחד או 2 שנופלים ולא פתרון Scale Up (למרות שרוב פתרונות ה-Scale Up מתהדרים בכך שהם יכולים לגדול לפטהבייטים).
אחד הדברים הראשונים שקורים כשחברות מתחילות להתעניין בפתרון אחסון Scale Out ורואים את מחירי יצרני הפתרונות הקנייניים – זו התעניינות אוטומטית מה יש לקוד הפתוח להציע. אחד הדברים שאני לא ממליץ לעשות, זה להוריד גירסת קוד פתוח חופשי ולהטמיע בשרתים, מכיוון שהגרסאות האלו משתנות תדיר וקהילת המפתחים לא כל כך עוזרת עם בעיות/באגים – במיוחד אם אתה צריך את הפתרון פה ועכשיו, ולכן אם הולכים על פתרון מבוסס קוד פתוח, אני ממליץ את הדברים הבאים:
- אם מדובר במערכת HCI שתהווה אלטרנטיבה ל-VSAN/Simplivity/Nutanix – אז יש את GlusterFS והוא מגיע יחד עם RHV.
- אם מדובר במערכת Scale Out שלא הולכת לגדול מעבר למספר קטן של שרתים (כמה עשרות) – ניתן לרכוש את GlusterFS בנפרד.
- אם צריכים מערכת אחסון שתורכב מעשרות שרתים ואחסון בגדלים של מאות טרהבייט ומעלה, או שתריץ מערכת ענן פרטי כמו OpenStack בחברה – מערכת SES של SuSE או Red Hat Ceph Storage יתנו לכם מערכת מבוססת CEPH שבנויה לדברים הללו (הפתרון של SuSE בארץ זול משמעותית בהשוואה למחיר שרד-האט מבקשים, ויש את אותה פונקציונאליות בשתיהן).
- גם Ceph וגם GlusterFS מתאימות אם אתם הולכים להריץ קונטיינרים/Kubernetes/OpenShift על הברזלים.
לסיכום: פתרון Scale Out טוב (שאינו מבוסס HCI) הוא פתרון שנותן:
- להגדיל את כמות האחסון למימדים גדולים (מאות טרהבייט ומעלה)
- שרידות הרבה יותר גבוהה מפתרון Scale Up (מערכת ששורדת גם כששרת אחד או יותר המאחסנים את הפתרון נופלים)
- תמיכה בסטנדרטים אחרונים (Object Storage, Persistent Volume, ,Cinder וכו')
פתרון Scale Up אינו דבר רע, אבל חשוב לדעת מהן המגבלות שלו (למרות שהיצרן מציין אחרת). אני לא ממליץ לאף אחד לזרוק מערכת כזו (אלא אם זו מערכת ישנה מאוד) ולרוץ ל-Scale Out, אבל אם מצד שני צריכים להרים מערכת אחסון גדולה מאוד, כדאי להסתכל ולבקש הצעות לפתרונות Scale Out.