האם לעבור ל-vSAN/Nutanix/HCI?

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

ואז הגיעה חברת VMware עם vSAN ואחריה Nutanix שהחלה "לגנוב" ל-VMWare לקוחות, וגם Simplivity ואפילו רד-האט עם פתרון ה-RHV בגירסאות האחרונות. בקיצור – ב-4 שנים האחרונות חברות החלו יותר ויותר להציע פתרונות עם העדפה ל-Scale Out מאשר Scale Up. פה בישראל Nutanix כובשת יותר ויותר לקוחות מכיוון שהמערכת שלה גמישה כדי להריץ את הוירטואליזציה הנוכחית שלך או את פתרון הוירטואליזציה שלהם (KVM).

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

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

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

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

נתחיל ב-Scale Up ונתייחס לבחירה הפופולרית בארץ לוירטואליזציה – של VMWare. נניח שיש לי כאן 10 שרתים שמריצים ESXi, ועל 2 מכונות רץ VCSA ומכונה שלישית משמשת כ-Witness ("עד") על מנת ש-VCSA ירוץ תמיד (בבקשה, תיפטרו כבר מה-vCenter שרץ על Windows). מה עושים כל שאר השרתים? מריצים מכונות וירטואליות. הם שרתים "טיפשים" וחוץ מהשרותים ש-ESXi שמריץ, המכונה כמעט ולא מריצה שום דבר אחר אלא את המכונות הוירטואליות שלכם. כל מה שקשור לדיסקים לדוגמא "נזרק" לביצוע ע"י הסטורג' עצמו (אם הוא תומך ב-VAAI וכו'), ועבודת ה-Network בקושי לוקחת משאבים, והיא מנוהלת ע"י ה-vCenter/VCSA (כשמדובר ב-DVSwitch) או ה-ESXi (כשמדובר ב-vSwitch רגיל). כל עניין ה-Compute רץ על המעבדים והזכרון.

ב-Scale Out לעומת זאת, הכל הפוך. בפתרון של VMWare יש לנו מודול נוסף של vSAN שיוצר לנו Datastore מבוסס על הדיסקים המקומיים (בקבוצות של SSD+זוג מכניים) וגם על הדיסקים של השרתים השכנים, כלומר בשרתים מוקצה זכרון ו-CPU לניהול האחסון, שרידות וכו' וכו'. במקרים של Nutanix/Simplivity – יש ערימה שלמה של שרותים נוספים שרצים פר שרת. נקודה חשובה נוספת: בשביל לקבל IOPS גבוה, חייבים לרכוש מספר גדול של שרתים, אין דרך להתחמק מכך.

העניין החשוב שצריך לקחת בחשבון הוא לא הקניה של ה-3-5 מכונות בשביל Nutanix/Simplivity, או הרשיונות והדיסקים שצריכים לקנות עבור ה-vSAN, אלא הגדילה העתידית.

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

בסיטואציית Scale Out לעומת זאת, כמעט הכל הוא פי כמה וכמה, כלומר אם אנחנו רוצים אחסון נוסף, אז עם vSAN אנחנו צריכים זוג מכניים+SSD מהיר כפול כמות המכונות שיש לנו (לפחות לפי ה-Groups שהגדרנו). צריכים עוד זכרון? אפשר כמובן להרחיב בצורה יחידנית וכנ"ל לגבי מעבדים, אבל ההמלצה היא לא לעשות כך אלא להוסיף עוד שרתים פיזיים עם כמות מסויימת של דיסקים זכרון ומעבדים, כך שכל פעם כשאנחנו צריכים משאבים נוספים, אנחנו מזמינים שרתים נוספים. טכנית אין שום בעיה להגדיל אחסון מ-2 טרה ל-20 טרהבייט באחד מהשרתים, רק שאותה מכונה שהגדלנו תהיה בקושי מסונכרנת עם האחרים כי היא תצטרך לעבוד הרבה יותר קשה מהשרתים האחרים.

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

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

  • כמה סטורג' אנחנו באמת משתמשים?
  • האם את מס' ה-VM שיש לנו אנחנו יכולים לשים בכמות השרתים שנקנה לצרכי Scale Out?
  • מה לגבי מכונות VM שאינן פרודקשן? האם כדאי לחשוב על פתרון וירטואליזציה חינמית כדי להריץ אותם שם על המכונות הקיימות?
  • האם החברה מתכננת פרויקטים נוספים שיצריכו רכישת שרתים נוספים עם פתרון Scale Out?
  • האם החברה חושבת על פתרון סטורג' מבוסס קוד פתוח שישרת מכונות שאינן פרודקשן או פרויקטים פנימיים אחרים?

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

על VMWare VSAN

בפוסט זה אינני מדבר על VSAN 6.0 ועל גירסה זו יפורסם בעתיד פוסט נפרד.

בחברות רבות, תצורת השימוש ב-vSphere היא כדלהלן: יש X שרתים שהם מהווים את ה-Compute (ועליהם בעצם רצים המכונות הוירטואליות), יש Storage של חברה כלשהי (NetApp/EMC/HP/IBM וכו'), ויש כמובן מתג או 2.

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

ב-VMWare עבדו ב-3 שנים האחרונות על פתרון אחר שנקרא VSAN שמתאים במיוחד לחברות קטנות עד בינוניות, כאלו שלא יכולים להרשות לעצמם Storage יוקרתי, או כאלו שמעוניינים בפתרון Storage אחר.

השיטה של VSAN היא די פשוטה: בכל שרת יהיו מינימום 2 דיסקים, כאשר אחד מהם הוא דיסק מגנטי (בין אם זה SATA, NL-SAS או SAS) ודיסק אחד מבוסס Flash (שוב – SATA או SAS, אפשר גם PCIe או nVME). יש צורך בלפחות 3 שרתים (ליצירת "רוב" – Quorum) ושהם יהיו בתצורת אשכול (Cluster) וכמובן שיש צורך בסוויצ' טוב עם עדיפות ל-Switch במהירות 10 ג'יגהביט וכמובן – יותר מכניסת רשת אחת פר שרת.

ה-VSAN מאחסן את ה-VM בדיסק המגנטי וה-Flash משמש כ-Cache (הן לקריאה והן לכתיבה כאשר הנתונים מועברים לדיסק המגנטי מהדיסק FLASH ברקע) והוא גם משכפל את הנתונים לדיסקים האחרים בשרתים באשכול. אחד הדברים שיש צורך לתת את הדעת עליו הוא שאין RAID בתצורה כזו. הדיסק בשרת A משוכפל לדיסק בשרת B ולשרת C (זה קצת יותר מורכב מזה) ולכן אם לדוגמא מחליטים להוסיף דיסק, מומלץ להוסיף גם דיסקים בשאר המכונות ועדיף שיהיו כמות זהה של דיסקים.

מבחינת נפילה – כאשר נופל שרת, 2 השרתים האחרים "לוקחים פיקוד" היכן שהשרת האחר נפל ומכיוון שהנתונים נמצאים בשאר הדיסקים שקיימים באשכול, הנפילה כמעט לא תשנה למעט העניין שהמכונה תצטרך להיות מופעלת מחדש (אוטומטית). עם VSAN לא ניתן להשתמש בפונקציית Fault Tolerance. אם יפלו 2 שרתים לעומת זאת, ברוב המקרים המכונות שהיו ב-2 השרתים הנופלים לא יעלו (אגב, ניתן להרחיב את ה-VSAN גם לשרתים נוספים שאינם כוללים דיסקים מגנטיים או דיסקים בכלל, אולם אז המהירות לא תהיה גבוהה). ניתן "לעקוף" מגבלה זו בשימוש Storage Policies שתיכף ארחיב לגביו.

אחד הדברים ש-VMWare עושה בשנים האחרונות בכל הקשור ל-Storage הוא "לזרוק" משימות שונות שה-Storage יעשה בעצמו ולא שרתי ה-Compute שלך, מה שנקרא גם "האצה". בעבר הרחוק דבר כזה לא היה קיים ודבר כמו Snapshot היה מתבצע ע"י ה-vCenter תוך שימוש במשאבי השרת למרות שכל Storage שמכבד את עצמו כולל פונקציונאליות זו. בגירת vSphere 5 הציגה VMWare את ה-VAAI, שגם נקרא "Hardware Acceleration" שבו פעולות מסויימות נעשות ע"י ה-Storage מבלי לקחת משאבים מהשרתים. טכנולוגיה נוספת ש-VMWare הציגה היתה ה-VASA, כך שפונקציות כמו thin provisioning או Deduplication ופונקציונאליות נוספות היו ניתנות לביצוע ישירות מה-vCenter כאשר בסופו של דבר הן היו מבוצעות ב-Storage עצמו ללא לקיחת משאבים מה-Compute.

ב-VSAN ישנה גם פונקציונאליות כזו, אם כי היא בעצם חלקית. כך לדוגמא אתה יכול לקבוע שהתוכן שלך שמאוד חשוב לך ישוכפל על פעמיים או יותר על הדיסקים ב-Cluster, וזה מבוצע ע"י שימוש ב-Storage Policies. כל מה שעליך לעשות הוא להחליט מה הם ה-VM החשובים לך, ולבנות Policy שיאמר למערכת כמה שרתים נופלים המערכת תהיה מסוגלת "לסבול" ולהמשיך להריץ את אותו VM, כמה פעמים לשכפל את הנתונים, כמה מקום לשמור גם במצב של Thin Provisioning ועוד, ואת ה-Policy אתה מחיל.

ציינתי לעיל שב-VSAN זה חלקית, וכאן בעצם VMWare נותנת לחברות צד ג' "פרוסה מהעוגה", כך שהן יכולות ליצור VSA שישב לך על השרתים ואיתו תוכל לבצע פעולות של Dedup, replication וכו' שיבוצעו ע"י ה-VSA שנכתב ונמכר ע"י חברות שונות.

כעת נעבור לשלב הפחות טכני ויותר "מכירתי" – את VSAN לא צריך להוריד. אם יש לך vSphere 5.5 U1 ומעלה – הוא כבר שם ויש צורך להפעיל אותו במספר נקודות מבלי להוסיף שום דבר ל-vCenter. מה שכן תצטרך, זה רשיונות, והרשיונות נמכרים פר CPU פיזי בשרת במחיר של $2495 (לפני מו"מ), כך שאם יש לך לדוגמא 3 שרתים ולכל אחד מהם 2 מעבדים, תצטרך לשלם (שוב, לפני מו"מ) סכום מוערך של 15,000 דולר (המחיר הוא רק ל-VSAN, יש צורך גם ברשיונות ESXI ו-vCenter, ואגב – בלי vCenter אין VSAN), וכאן מתחילה ההתלבטות של חברות: לא שווה לקנות Storage פשוט-בינוני במחיר כזה?

כאן קשה לתת תשובה. טכנית, אם יש לך סוויצ' של 10 ג'יגה, ובהתחשב בכך ששלישיית שרתים תחזיק יותר דיסקים מ-Storage קטן, ו-VSAN יחזיק הרבה יותר מעמד מאשר Storage קטן מרכזי אחד – אז התשובה היא שעדיף להשקיע ב-VSAN. חשוב לזכור שבניגוד ל-Storage קטן, VSAN גם נותן שרותי QoS בהתאם ל-Policy שאתה מגדיר.

מצד שני, אם ה-Storage שלך משרת גם אחרים לשרותים כמו SMB/NFS, אז השיקול משתנה, מכיוון ש-VSAN לא בנוי לתת שרותים כאלו מכיוון שלא מדובר על מכונת VM שנותנת שרותי NFS/iSCSI לשרתים ושיטת האחסון שונה שם לחלוטין (ועל כך תוכלו לקרוא בהרחבה כאן). כמובן שאתה יכול להרים לך VM מבוסס לינוקס או Windows ודרכו לשתף קבצים הן דרך NFS והן דרך SMB, אבל לא לכולם זה נוח.

והנקודה הכי חשובה היא: מה אתה מייעד עבור המערכת? אם לדוגמא עבור VDI, אז הביצועים לא יהיו "מזהירים" למרות שיש שימוש מאסיבי ב-Flash כ-Cache (ולא, אי אפשר להכניס 2 דיסקים SSD בגרסאות VSAN קודמות ל-6, רק דיסק מגנטי ודיסק SSD, ובגירסה 6 אם תרצה להשתמש ב-All Flash, תצטרך להוסיף $1500 פר מעבד באשכול). אם אתה לעומת זאת צריך ערימה של VM שיעבדו בנפרד מה-Storage של החברה עקב ענייני אבטחה וכו' – VSAN יכול להוות פתרון די טוב.