עננים: מעבר לענן ושרידות מאוד גבוהה

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

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

מכאן נעבור לחברות שרוצות להעביר את התשתית שלהן לענן: חברות הענן אינן מנסות למכור לכם VM גדולים בזול. הן תמיד תהיינה יותר יקרות מכל ספק אחר שאינו ענן. מה שכן הן מנסות – זה למכור לכם את השירותים שהן מציעות במקום שתרים אותם על השרתים שלך אצל אותו ענן. לדוגמא: צריך SQL כלשהו? (לא חשוב אם זה MySQL או מיקרוסופט SQL או DB של אורקל) כמובן! אז במקום שתרים אחד כזה, אמזון מציעה לך שרות RDS (כן, גם ל-SQL Server וגם לאורקל), וישנם המון סוגי שרותים אחרים שהיתרון שלהם הוא מחיר (יחסית) זול, ושאתה לא צריך לתחזק כלום (ובין כה הם עושים שרות תחזוקה הרבה יותר מקצועי ממה שרבים עושים). אתה תשלם רק על הדברים שתגדיר ותשתמש, אין תשלום מינימום ואין תשלום מראש.

לכן, עם שרותים אלו, כמות ה-VM שתצטרך תצטמצם משמעותית. יכול להיות כמובן שתצטרך VM חזק בשביל שרת אפליקציות שלך, אבל לא תצטרך שרת בכלל עבור DB. יש לך מספר משתמשים גדול? אתה לא צריך קופסאות Load Balancing, אתה פשוט משתמש בשרותים של אותו ספק ענן לביצוע איזון עומסים. מתעקש על חומת אש מה-Brand האהוב עליך? יש לך VM מוכן יחד איתו, בחר, תקים ותשתמש, תשלם פר שעה עליו, ומה שהכי חשוב – אין יותר צורך בתחזוקת חומרה, סוויצ'ים, וכו'. הכל כבר מטופל ולבחירתך מגוון מסלולי תמיכה, כך שגם אם יש תקלות ביום כיפור – יש מי שיענה לך.

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

  • איזו מערכת הפעלה רצה על ה-VM אצלך שאתה רוצה להעביר? כל ספקי הענן הגדולים טוענים כי הם תומכים בכל מערכות ההפעלה. זה נכון בצורה חלקית. רשמית מה שהם מצהירים הוא נכון אולם בתכל'ס אם רוב ה-VM שלך מבוססים לינוקס, אין לך מה לעשות בענן של מיקרוסופט. לך לגוגל או אמזון. אישית, צמחו לי מספיק שערות לבנות מהתמיכת לינוקס של מיקרוסופט.
  • מי נותן לך קרדיט ראשוני (וכמה)? ספקי ענן שונים נותנים קרדיט ראשוני שנע בין כמה מאות דולדרים לכמה אלפי (או עשרות אלפי) דולרים. כמה ספק הענן מוכן לתת לך כדי להתחיל לעבור?
  • ניהול, תחזוקה, הגירה, הגדרות וכו' של השרותים וה-VM אצל ספקי ענן לא מבוצעים בד"כ דרך ממשק GUI אלא דרך כתיבת סקריפטים או אפליקציות תוך שימוש ב-API של ספק הענן. האם הספק תומך בשפות שאנשי ה-IT שלך מכירים או שהם רק יודעים PowerShell והספק מצריך ידע ב-Python/PERL? נכון, ספקי הענן ברוב המקרים נותנים תמיכה גם וגם, אולם ישנם לא מעט עניינים של פתרונות תקלות המצריכות שימוש בשפות ש"חביבים" אצל ספק הענן.
  • מעבר לענן מצריך שינויים מאסיביים בכל תכנון התשתית כולל דברים כמו Storage, Networking ועוד. פה יש לך NetApp/EMC שעליו אתם זורקים הכל, בענן אם תנסה לבצע את אותו טריק, תקבל חשבונית חודשית מבהילה! יש צורך בהפרדה של תכנים סטטיים ודינמיים, אפליקציות ו-VM שצריכים IOPS גבוה וכאלו שיכולים להסתדר עם כל דבר שתזרוק עליהם – לכן חובה לקחת בחישוב השכרת יעוץ/פרילאנסרים שיסייעו לך בתכנון המעבר ולאחר מכן ביישומו.
  • האם לספק הענן יש נציגות טכנית מקומית שנציגיה יכולים להגיע למשרדכם? טלפון/מייל זה טוב, אבל לפעמים פגישה פרונטלית יכולה לסגור קצוות רבים בפגישה אחת.

מכאן נעבור לשרידות: אצל ספק ענן אתה יכול לקבל שרידות גבוהה יותר ממה שאתה מקבל אצל ספק VM/VPS כלשהו. אפשר להשתמש בשרותים שונים כדי להרים VM מוכנים במקרה ויש עומסים פתאומיים (ולשרשר אותם מיידית ל-Load Balancer), והשרתים מתוחזקים בצורה כזו שגם אם VM נופל, הוא מיד קם על מכונה אחרת מיידית ללא צורך בהתערבות ידנית. ככלל, כל ספקי הענן נותנים לך תיעוד איך להקים את האפליקציה שלך/שרות שלך כ-Fault Tolerance.

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

לשם כך מומלץ לחשוב על אחד מהפתרונות הבאים:

  • כל ספק ענן מכובד (במיוחד השלישיה) מציע את השרותים במספר אזורים שונים בעולם. מה שאתם יכולים לעשות הוא להקים את התשתית שלכם בתצורה המינימלית בעוד אזור (Region) עם סינכרון דו כיווני (או רב כיווני, בהתאם לתשתית שלכם) בין האזורים וכל מה שצריך הוא מכונת VM קטנה מאוד שתדגום את האזורים כל הזמן. היה ואזור עיקרי לא מגיב, ה-VM הקטן ישנה את ה-DNS ושאר פרמטרים כדי שלקוחותיכם יקבלו שרות מהאזור המשני שהקמתם. (האזורים מופרדים מבחינת מערכות כך שנפילה באזור 1 אינה משפיעה על אזור 2)
  • ישנן מספר ספריות שונות (כולן בקוד פתוח) המאפשרות לך לעבוד דרכן ולהקים את השרותים שלך אצל יותר מספק ענן יחיד, כך שתוכל לקבל שרידות יוצאת מן הכלל. החסרונות בשיטה זו:
    • אתה צריך לשלם על התעבורת סנכרון בין ספקי הענן
    • ספריות אלו לא תמיד מעודכנות ולעומת זאת ספקי הענן משנים API במקרים רבים כך שהספריה לא כל כך תעזור.
    • יש הרבה יותר עבודה לעשות בהקמה/הגדרות וגם תחזוקה.

לסיכום: ענן זה לא לכל אחד. מחפש VM/VPS זול בשביל האתר שלך? תציץ ל-Digital Ocean לדוגמא (והם מאוד יציבים, מנסיון). אם לעומת זאת יש לך אתר/שרות מאוד גדול, כדי לעבור על הנקודות והדברים שציינתי לעיל לפני שתחליט לעבור ולפני שתזרוק כספים על הפרויקט/אנשים/תכנון/יעוץ וכו'. אם האתר שלך בעל תעבורה רבה והוא מקור הרווח שלך, כדאי לחשוב ברצינות על שרידות תוך שימוש באזורים.

חג שמח 🙂

הערה קטנה: אני מחפש עבודת 50% משרה קבועה (תשלום כפרילאנס) בתחומי לינוקס/וירטואליזציה/סטורג' מבוסס תוכנה. אם אתם מכירים משהו, אשמח אם תיצרו עימי קשר.

האם VSAN יכול לשמש כתחליף ל-Storage יעודי?

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

השאלה פשוטה: האם VSAN יכול להחליף פתרון Storage יעודי?

אסביר: במקרים רבים לחברות יש Storage יעודי שנקנה לפני מס' שנים ועלות חידוש חוזה תמיכה/תחזוקה גורמת להרהורים לגבי פתרון חלופי. יש מקרים שה-Storage מגיע ל-End Of Life ויש גם מקרים שמוצאים שמי שהחליט לרכוש Storage החליט להקשיב יותר לנציג השיווק מאשר לבדוק מספרים טכנית לגבי מה ה-Storage יכול להנפיק והתוצאות כרגע לא מספקות.

אם תקשיבו לתשובה מנציגי המכירות של VMWare (או ריסלרים שלהם) אז במקרים רבים התשובה תהיה ש"כן", בוודאי ש-VSAN יכול להחליף קופסת Storage.

החלק שהם לא כל כך ישימו עליו דגש – זה המחיר שצריך לשלם כדי להגיע לביצועים של Storage רציני מודרני מהשנתיים האחרונות. אם לדוגמא יש לך 10 ברזלים ואתה מחפש מקסימום IOPS, תצטרך למלא כל תושבת PCI וכל כניסת SAS ב-SSD מבוססי PCIe או SAS (מה-12 ג'יגהביט) מהקצה העליון כלומר שכל SSD כזה עולה לך כמה אלפי דולרים טובים. כך תקבל באמת מקסימום Performance ומיליוני IOPS אבל אתה כבר מדבר על עשרות אלפי דולרים ומעלה, ובמקרים כאלו, לעיתים הכדאיות הכלכלית נוטה לכיוון הארכת חוזה על ה-Storage הקיים ושדרוגו. אחרי הכל, קל יותר לדחוף מגש SSD, לשדרג/להוסיף SP (כל זה אם האפשרויות קיימות) מאשר להתחיל מאפס.

גם במקרים בהם ה-CEO וה-CTO מחייכים ומוכנים לממן VSAN עם כל הציוד שתיארתי בלינק ועם מילוי כל חור ב-SSD מהקצה הגבוה – ישנה בעיה מהותית אחת.

כפי שאנו יודעים, ב-Corporate טיפוסי במקרים רבים הוירטואליזציה אינה אחידה. פה הכניסו Hyper-V שנשאר כ"ירושה" מה-CTO הקודם שהחליט לעבור לפתרונות מבוססי מיקרוסופט בלבד, שם החבר'ה שמפתחים בלינוקס הכניסו Docker, ובל נשכח כל מיני שרתי ESXi ישנים שקיימים פה ושם כי מישהו הנחית הוראה מגבוה לא לשדרג כי אין יותר דרייברים חדשים לכרטיסים שבתוך ה-ESXi והמערכת עובדת ו"נא לא לנגוע" (כן, ראיתי גם מקרים כאלו). במקרים של Storage רגיל – אין בעיה, לכאן אתה מוציא SMB, לכאן אתה מוציא NFS ולשם אתה מכין כמה LUNs ומייצא כ-iSCSI ונגמרה הבעיה.

אבל VSAN לא יודע לעבוד כך. VSAN מכין Datastore ענק שהוא מיועד עבור ה-VM שרצים ב-hosts שמשתתפים ב-VSAN. יש לך ערימת שרתי ESXi שלא משתתפים ב-VSAN או שהם עם וירטואליזציה אחרת? הפתרון היחיד שיש לך הוא הקמה של VM באשכול השרתים שמשתתפים ב-VSAN ומשם לייצא החוצה CIFS/NFS/iSCSI. כמה זה מהיר וטוב? זה מאוד תלוי מה רץ על ה-VM שמייצא את השרותים הללו החוצה, אבל בכל מקרה אני מהמר שמול Storage מודרני מול VM כזה, ה-Storage המודרני ינצח עם יד קשורה מאחור מכיוון שיש לו הרבה יותר פונקציונאליות ממה ש-VSAN בתוספת ה-VM שמייצא – נותנים. בל נשכח של-VM עם VSAN אין גישה ישירות לבקר או לדיסקים, את זה יש רק ל-VSAN כך שאין לך דברים כמו dedup, tiering וכו'.

היתרון הגדול של VSAN הוא רק כשאתה מריץ ESXi וכל השרתים משתתפים ב-VSAN (אגב, לא חובה "לפוצץ" את כל הברזלים ב-VSAN, אפשר למלא את רובם ולחבר עוד כמה ללא SSD/דיסקים מכניים ואותם שרתים ישמשו כ-Compute Only). אז באותם מקרים אפשר לקבל שרידות מעולה ואין מקרים של "Storage נופל וכל ה-VMs למטה". גם אם שרת פיזי יקרוס אז המכונות VM שרצו עליו יעשו reboot בשרתי ESXi האחרים ואפשר גם להגדיר ש-2-3 שרתים נופלים, אז ה-VM החשוב יעלה במכונה תקינה (מה שנקרא FTT ולזה כמובן יש מחיר מבחינת כמות נמוכה יותר של Free space בדיסקים).

כל מה שתיארתי לעיל מדבר על גירסת VSAN הנוכחית (6.0). ב-VMWare החליטו שעם כל הכבוד לחברה האחות (EMC) – הם יתחרו בשוק ה-Software Defined Storage ואין לי ספק שהם יוסיפו הרבה מאוד פונקציונאליות ל-VSAN כדי לפתור גם את הבעיות שתיארתי לעיל, כך שכדאי לעקוב. כנס VMWorld יתחיל ביום שלישי כך שסביר להניח שביום שני והלאה יצאו הכרזות מצד VMWare ושותפים לגבי גרסאות חדשות למוצרים. אני אפרסם את ההודעות החשובות בפורום VMWare בפייסבוק ואתם מוזמנים להצטרף.

גילוי נאות: הח"מ מספק שרותי הטמעה גם ל-VSAN 🙂

פתרונות קוד פתוח כתחליף ל-Hypervisor מסחרי

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

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

האם קוד פתוח יכול לתת פתרון הולם כתחליף לדברים כמו ESXI?

ישנן לא מעט חברות שחושבות על פתרון כמו Open Stack כתחליף ל-ESXI. הרעיון עצמו על פניו נשמע הגיוני, אחרי הכל Open Stack מאפשר לך גם Network, גם Compute וגם Storage, אבל כשבודקים בפונקציות ההכרחיות שצריכים מה ESXI נותן ומה Open Stack נותן, התוצאות לעיתים מעודדות ולעיתים לא.

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

בנוסף – Open Stack עדיין מתאים לחברות ממש גדולות והוא לא ממש מתאים לחברה שיש לה מספר קטן של שרתים פיזיים.

פתרון אחר הוא Xen שמוכרות חברות שונות כמו Citrix או Oracle או להריץ את הגירסה הפתוחה ב-Xen Project ולחבר לזה את ה-Client של Citrix דרך Windows או להשתמש בכלים אחרים. אם יש לך כמות VM קטנה יחסית, הפתרון הזה יכול לעבוד לא רע בכלל. הפתרון של Citrix דווקא נותן "פייט" לא רע לפתרון של ESXi אבל אם אתה צריך תמיכה – תצטרך לרכוש את המוצר המסחרי.

עוד פתרון שחלק חושבים שיכול לסייע להם (אך הוא לא) הוא KVM. בעקרון KVM הוא בעצם "מנוע" וירטואליזציה, הוא זה שבסופו של דבר גורם ל-VM לפעול. הוא לא יודע ליצור דיסק ל-VM, הוא לא יודע להגדיר שום דבר ל-VM, אתם צריכים להזין לו את כל הדברים ידנית (או דרך סקריפט) ולכן KVM בד"כ לא מומלץ לשימוש "ידני", אלא מומלץ לשימוש בשילוב כלים, לדוגמא virsh שנותן command line לנהל את כל ה-VM או libvirt שזו ספריה שתומכת ב-binding בשפות רבות כך שניתן בשפה החביבה עליך להרים מכונות מבוססות KVM, לכבות, לעשות מיגרציה, ופעולות רבות אחרות.

אבל כמו שרובינו יודעים, אנשי IT אוהבים GUI, תן להם GUI גרפי, והם מחייכים, ואם אפשר שאת אותו GUI לממשק אותו דרך API לשפה החביבה על אנשי הלינוקס בחברה -אז כולם יכולים לחייך.

פה נכנס כלי שרד-האט מפתחת שנקרא oVirt. הכלי הזה יודע לנהל יפה שרתים שמריצים את Ovirt Node (שזו גירסת לינוקס מאוד מקוצצת שמותקנת "על הברזל") ומאפשרת פונקציות רבות שקיימות במערכות vSphere. למי שרוצה, יש גם גירסת LIVE שלא מצריכה התקנה, רק להוריד ISO, לעשות Boot ולשחק עם זה (רק כדאי שיהיה מחשב נוסף שישמש כ-Node). גם כאן, אם אתם צריכים תמיכה, תצטרכו את זה מ-רד-האט בתשלום לפי תושבת, או דרך ה-Mailing list / IRC אם אתם בוחרים באופציית החינם. שימו לב ש-oVirt הוא כלי שמצריך השקעה בלימוד.

עוד אופציה שיש בקוד פתוח היא מערכת שנקראת  ProxMox, ודרכה אתה יכול להרים VM, ולבצע ניהול ודברים נוספים. היתרון של Proxmox על פני פתרונות אחרים הוא קלות השימוש בכלי. הוא לא מציע פונקציות רבות כמו oVirt אולם אם יש לכם מספר שרתים קטן והרשת הולכת להיות די פשוטה, Proxmox יכול להוות פתרון לא רע.

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

ולבסוף – הנה קישור שאני מציע לכולם לראות – טבלה המשווה בין הוירטואליזציות השונות.

תחום האחסון בעוד 5 שנים

אני רוצה שנחזור אחורה בזמן (לותיקים מאיתנו) בערך 20 שנה אחורה, לתחילת שנות ה-90. אם היית צריך שרת "עצבני" – היו לך מספר פתרונות, כולם קנייניים – בין אם זה HP-UX, או IBM AIX, או כמובן Solaris של Sun. אם רצית להריץ UNIX טוב על מערכת מבוססת X86, הפתרון המסחרי שהיה לך הוא של SCO ואם חיפשת לחסוך בכך שתלך ל-X86, היית מוצא מהר מאוד שטעות בידך – SCO דרשה בזמנו סכום של בערך $4500 דולר עבור רשיון ל.. TCP/IP, וזה פר שרת. היית יכול כמובן לנסות את גרסאות ה-BSD או את המערכת הצעירה שנקראת Linux, אבל אם היית מראה את זה ב-Corporate, היית מסתכן בצרות. אם היית שואל חברות אחרות על Linux, הן היו אומרות לך שזו מערכת "נחמדה" אבל לא יציבה ולא חזקה ולא תומכת בהרבה דברים וכדאי שתשכח ממנה ותתרכז בפתרון הקנייני שישאר איתך "לשנים רבות" ורק ישתפר.

נחזור חזרה ל-2015, וכיום אם אתה מרים מערכת שאינה Windows, סביר מאוד להניח שהיא תהיה Linux. איפה SCO? נעלמה. איפה AIX או HP-UX? נמצאים במקומות בודדים מסויימים, ושאר מערכות ה-UNIX המסחריות למיניהן מתו. נשארו הגרסאות בקוד פתוח כמו BSD לסוגיו וכמובן הפצות הלינוקס. כיום ב-Corporate (לפחות הבינלאומי, הרבה פחות בישראל) אינו נראה כדבר נורא וחברות למדו לאמץ את מערכת ההפעלה, במיוחד שחברה כמו Red Hat נותנת להם שקט לעשור שנים פר גירסה, והיצרנים מקבלים את ה"הכשר" של Red Hat שה-Corporate מאוד רוצה לראות. יש גם תמיכה 24/7 וגם הגנה נגד תביעות של פטנטים. כיום אם תרצה להכניס Solaris במקום Linux, זה יהיה לך הרבה יותר קשה, כמו שלפני 2 עשורים מאוד היה קשה להכניס Linux.

גם תחום הוירטואליזציה עבר פחות או יותר את אותו מסלול אם כי בפחות זמן. ל-IBM היו פתרונות "וירטואליזציה" עוד משנות ה-70 (DISCO) ולחברות אחרות היו גם פתרונות של "וירטואליזציה" (אתם יכולים לראות רשימה מלאה, אם כי לא עדכנית – המסמך נכתב ב-2004 כאן) כך שחברות שהריצו מערכות MainFrame יכלו להריץ עוד עותקים של אותה מערכת הפעלה כתהליך (Process) עצמאי (פחות או יותר) וב-2004 חברת Sun הציגה את Solaris Container, שנתן פחות או יותר את מה ש-IBM נתנו 30 שנים לפני כן. בערך באותו זמן החלה חברה צעירה בשם VMWare להציע פתרון וירטואליזציה מעניין – בהתחלה בדסקטופ ואחר כך לאט לאט בשרתים – את ה-ESX (שנהפך במשך הזמן למשפחה ענקית [ולפעמים ענקית מדי] של מוצרים).

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

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

אנחנו נמצאים עכשיו בתקופת מעבר מעט שונה שאני מאמין שתחל להיות מיושמת בשנה שנתיים הקרובות וביתר שאר ב-4-5 שנים הקרובות, והיא – מעבר ל-Storage שאינו "ארון".

אם נסתכל היום על Storage ממוצע, נמצא שהוא מורכב מהרבה "מדפים" (Shelves), אולי מתג לסיב אופטי, (Storage Processor(s (שעושים בעצם את כל העבודה) ואולי עוד כמה מודולים, בהתאם ליצרן ה-Storage, דגם וכו'.

נסו לדמיין את ה-Storage שיש לכם ב-Corporate. ה"מפלצת" הזו, עתירת הטרהבייטים שנותנת שרותי קבצים, NFS, iSCSI ואולי עוד שרותים – היא היא ה"לב" של ה-Data Center והיא מאחסנת את המידע החשוב שלכם. את הדבר הזה אתם צריכים שיהיה הכי יציב שיש. אם זה נופל – שרותים רבים לא יהיה זמינים למשתמשים שלכם. אם יפול לכם מתג (Switch) בחברה, תוכלו להתגבר בכך שתנתבו חלק מהכניסות למתגים אחרים. אם שרת פיזי יפסיק לפעול, אתם תבצעו העברה/הפעלה של המכונות הוירטואליות במכונה פיזית אחרת, אבל אם כל השרתים מקבלים שרותי Storage מאותה קופסא ענקית והיא מושבתת – אף VM לא יעלה.

הותיקים מבינינו יקבלו אולי תחושת Deja-Vu קלה – ככה בדיוק מכרו ל-Corporate שרתים של Sun וחברות גדולות אחרות לפני 20 שנה. מפלצת גדולה, חייבת להיות יציבה ואם היא מפסיקה לתת שרותים – הצרות יגיעו (כולל כמה מאות טלפונים  ו-SMS בהולים).

כיום – שרתי ה-Solaris הגדולים של SUN נזרקו מרוב החברות ואותם שרתים הוחלפו במכונות Linux שמאוחר יותר עברו P2V להיות VM, וכיום יש לנו מספיק פתרונות טכנולוגיים לתת שרידות ל-VM כדי שגם אם יפול מתג, או Storage או שרת פיזי – ה-VM ימשיך לעבוד. אחרי הכל, להכין FT או HA ב-ESXI זה לא בדיוק מסובך כמו להטיס חלליות…

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

האם אתם יודעים על איזה שרת אתם רצים? (מבחינת Brand), האם אתם יודעים איזה דיסקים יש בפנים? האם יש דיסקים בשרת הפיזי או שזה מחובר לארון שמריץ שרותים שנותן שרותי דיסק ב-LAN עם דברים כמו LUN/iSCSI? התשובה לכל השאלות האלו היא פשוטה והיא: לא, אתם לא יודעים. אם תתהו מה יש מאחורי הקלעים, אמזון יאמרו לכם שהם עושים כל מיני דברים סודיים שלא אמורים לשנות לכם כלום – מבחינתם, הם צריכים לתת לך VM עם תכונות X,Y,Z שרצית וזהו. לא אמזון, לא גוגל ולא מיקרוסופט – אף אחד מהם לא מפרט לעומק מה ה"נוסחה" שהם בונים את התשתית שנותנת את ה-VM שאנחנו מקבלים בסוף. יש לנו רמזים על חלקים מסויימים (אמזון משתמשת ב-Xen, גוגל ב-KVM ומיקרוסופט ב-Hyper-V), אבל לא על הדיסקים, לא על הרשת, ולא על רפליקציות וכו'.

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

נחזור ל-Data Center שיש ב-Corporate ונדמיין לעצמנו שאנחנו לוקחים מברג ומחליטים לפתוח את אותו פתרון Storage קנייני גדול (טיפ: לא לנסות בחברה, מתכון בטוח לפיטורים מהירים) ולראות מהו אותו "קסם" שהם עושים בפנים. מבלי להיכנס ליותר מדי פרטים טכניים, אנחנו נמצא שישנה מערכת הפעלה קניינית של היצרן, מעבדים, זכרונות ועוד כמה חלקים, כך שה-Storage עצמו בנוי בצורה שלא ממש רחוקה משרת ממוצע שיש לנו (כמובן שאין שם מעבדי X86). אם נסתכל ונכיר קצת יותר את ה-Storage Processor ונשווה אותו למעבדים גנריים אחרים, אולי נופתע מכך שהמעבד עצמו הוא חלש בהשוואה לאחרים. כמה חלש? מעבד Xeon ישן מאוד שיש לך בשרת ישן – הרבה יותר חזק מה-SP עצמו ומסוגל לעשות את אותם פעולות מבלי להתאמץ ממש (כן, גם אם ניתן לו לעשות את החישובים של דחיסה, RAID וכו' במקביל).

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

כאן מגיע דבר שנקרא במקומות רבים SDS ר"ת של Software Defined Storage. ב-SDS אתה הוא מי שבעצם מתכנן ובונה את ה-Storage ואתה יכול להקים עליו איזו תוכנה שתרצה כדי לנהל את ה-Storage וכאן יש לך מגוון של תוכנות, החל מקוד פתוח ועד פתרונות סמי-קוד-פתוח כמו של EMC ScaleIO  ופתרונות קוד סגור אחרים. גם מבחינת גדילה אתה יכול להתחיל במסלול של Scale UP ולחבר JBOD או יותר ועד למצב של Scale Out עם 3 שרתים ומעלה (ומומלץ רשת של 10 ג'יגה בין אותם שרתי Storage). אפשרות נוספת שיש לך היא בעצם להשתמש במשהו שכבר קיים אצלך, כך לדוגמא אם כל השרתים הפיזיים שלך מריצים ESXI, אתה יכול להשתמש ב-VSAN ולהכניס דיסקים מגנטיים ו-SSD לכל אחד מהשרתים ולבנות בעצם Storage מתוך אותם משאבים (בין כה VSAN לעולם לא עובר את קו ה-10% שימוש במשאבי מעבד/זכרון כך שהוא לא יחנוק לך את השרתים).

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

האם ב-Corporate יעברו לפתרון כזה? כשחשבתי על כך בעבר, תשובתי היתה "לא", אולם כיום כשחברות מוצאות את עצמן צריכות לשלם על הארכת חוזה תמיכה סכומים רציניים מאוד, ומאות אחוזים נוספים על דיסקים, נראה לי שחברות יהיו מוכנות יותר לשמוע על הרעיון. לא לעבור אליו מחר, אבל עצם הרעיון נשמע להם "מעניין". אני מאמין שבמהלך ה-5 השנים הקרובות נראה יותר ויותר חברות עוברות ל-SBS. אם מסתכלים על הדוחות הפיננסיים של חברות יצרני Storage כבר כיום רואים חברות כמו EMC שלא מראות ממש צמיחה והם מתכננים קיצוץ כ"א, וכנ"ל ב-NetApp כך שנראה שחברות פחות ופחות רוצות לקנות את הקופסאות הענקיות הללו.

כמה נקודות חשובות לגבי תכנון הטמעת VMWare VSAN 6

יצא לי לאחרונה להיתקל במה שאני קורא "סקרנות" של כל מיני חברות לגבי VSAN-6 של VMWare וראיתי פה שם כל מיני תכנונים והצעות שחברות הציעו כדי להטמיע לנסיון את VSAN ב-DC של החברות ובחלק מהמקרים היו מספר דברים שאינם נכונים או אינם מומלצים. לפיכך, הנה המלצות שנוסו ואינם רק "פרי" של הסתכלות במצגות השיווקיות של VMWare.

אחלק זאת למספר חלקים:

דיסקים
בגירסה 6 של VSAN ישנה תמיכה של All Flash, כלומר גם הדיסקים שאמורים לשמש כתכולה (Capacity) וגם הדיסקים שמשמשים לביצועים (Performance) יכולים להיות SSD. זה מעולה, אבל המחיר של דיסקים SSD מבוססי SAS (שלא לדבר על NVME) מאוד יקרים, ולכן VMWare ממליצה שתבחרו בסקאלה בין דיסקים שיכולים להכיל טרהבייטים של מידע אך אינם מהירים לבין דיסקים מגנטיים מהירים אך שאינם יכולים להכיל הרבה מידע.

האמת היא שהדיסקים המהירות במהירות 15000 RPM לא יסייעו לכם הרבה מכמה סיבות:

  • כל דיסק SSD הכי פשוט (כל עוד הוא מבוסס SAS) יתן לכם IOPS הרבה יותר גבוה מדיסק של 15000 RPM.
  • הכתיבה לדיסקים האלו בין כה נעשית ברקע וגם דיסקים NL-SAS במהירות 7200 RPM יתנו תוצאות שנמוכות באחוזים בודדים מדיסקים במהירות 15000 RPM
  • בדיסק מבוסס NL-SAS תוכל להכניס הרבה יותר מידע, חשוב לזכור – מידע של VM נשמר במספר שרתים במקביל כך שבכל מקרה לא תקבל 4 טרהבייט אם הכנסת 4 דיסקים של 1 טרהבייט (לדוגמא)

נקודה נוספת שמאוד חשובה בתכנון – VSAN אינו תומך בשום RAID וגם כמות הדיסקים שהוא תומך כקבוצות (קבוצה = דיסק SSD + לפחות דיסק מגנטי אחד) היא קטנה, עד 7 דיסקים מגנטיים בקבוצה, כך שאינך יכול לבוא ולחבר JBOD עם 20-60 דיסקים לדוגמא. תצטרך לכל קבוצת דיסקים להוסיף דיסק SSD (בחברות – SAS או NVME או PCIe, ב-LAB גם SATA יספיק), כך שאם לדוגמא אתה מתכנן להכניס 24 דיסקים של 1.2 טרהבייט מבוססים SAS, תצטרך לפחות 4 דיסקים SSD. נקודה חשובה נוספת – גודל ה-SSD המומלץ הוא לפחות 10% מגודל הדיסקים בקבוצה (כלומר אם הקבוצה מכילה 4 דיסקים של 1 טרה, תצטרך SSD בגודל של לפחות 400GB).

עוד נקודה ש-VMWare מאוד ממליצה עליה היא חלוקה קטנה של דיסקים, כלומר אם יש לך 4 דיסקים, חלק אותם ל-2 קבוצות כאשר לכל קבוצה יהיו 2 דיסקים ודיסק SSD. עוד המלצה של VMWare (שבחלק מהמקרים היא פרקטית ובחלק לא, תלוי בגודל השרת) – היא שכל קבוצת דיסקים יהיה בקר דיסקים יעודי (אגב, אם אתם קונים שרתים מוכנים ל-VSAN, מה שנקרא Node Ready, ברוב המקרים לא תמצאו 2 בקרי דיסקים אלא רק אחד). כמובן שקבוצות קטנות נותנות יותר ביצועים – אבל הכל תלוי בתקציב שלך.

רשת ב-VSAN
כשזה מגיע לרשת, לא מומלץ לעבוד במהירות של 1 ג'יגהביט (ו-LAG בין כה לא יעזור הרבה, מנסיון..) ומומלץ לעבוד עם חיבורי 10 ג'יגהביט בזוגות, כאשר ההמלצה האישית שלי היא להשתמש בסה"כ ב-6 פורטים לפי הפירוט הבא:

  • זוג 10 ג'יגהביט לתעבורת VSAN – אין מה לעשות, VSAN מעביר המון מידע נון סטופ (ואגב, לידיעת מנהלי הסוויצ'ים, הוא משתמש ב-Multicast כדי "להכריז" על שרתים) בין השרתים. את הזוג מומלץ להגדיר כ-Fail Over.
  • זוג 10 ג'יגהביט לתעבורת VM – חובה אם אתם חושבים להשתמש ב-SAN בשילוב Horizon לשם VDI. גם כאן – Fail Over.
  • זוג 1 ג'יגהביט – ל-Management. גם כאן – תצורת Fail Over.

שימוש ב-vCenter
לא מומלץ להקים את תשתית ה-vCenter על תשתית ה-VSAN, מכיוון שאם השרתים יפלו (יותר מ-1) – לא יהיה לך vCenter, ולכן מומלץ להשתמש ב-vCenter שרץ על ESXI שלא קשורים למערך VSAN. לחוצים במקום ובמשאבים? תקימו ESXI קטן ועליו vCenter Appliance לינוקסי כ-VM, זה יספיק.

הוספת ESXI כ-Compute Only
אם אתם רוצים להוסיף שרתי ESXI שישמשו כ-Compute Only (ללא דיסקים בתוכם) זה בהחלט אפשרי, אבל לא מומלץ להקים VSAN Cluster עם 3 שרתים שכוללים דיסקים ועוד 4 שרתים שלא כי אז העומס יזרק על כל השלישיה הראשונה. מומלץ להוסיף קבוצות דיסקים קטנות לשרתים שאתם מייעדים ל-Compute Only אם כמות השרתים הנ"ל תהיה גדולה, כך שהעומס יתפזר.

שימוש מאסיבי ב-Storage Profiles
בעקרון VSAN מאפשר לכם להגדיר כל מיני פרופילי Storage עם מאפיינים שונים כמו כמות שכפולים (Replications), או FTT (ר"ת failures to tolerate – כמה ה-VM ישאר חי אם X שרתים פיזיים נופלים) ועוד, אבל כדאי לתכנן זאת בחוכמה, ככל שתגדילו את ה-FTT וכמות הרפליקציות, כך ישאר לכם פחות מקום בדיסקים וכל מערכת הדיסקים תעבוד הרבה יותר אגרסיבי. אז כן, אם הרמתם VM שמריץ DB פרודקשן של אורקל או של מיקרוסופט, כדאי להגדיר לו FTT של 2 (לדוגמא), אבל אם אתם מריצים VDI ויש לכם 20 VM של Windows 7, במקרה ושרת ימות וה-VM יפלו – לא יפול העולם.

צורך ב-DEDUP וכו'.
ישנן מספר חברות שמוכרות Appliance VM שנותנים שרותים כמו File Server, DeDup, דחיסה ועוד. לגבי File Server, אם אין לכם רשיון 2012 פנוי, תמיד אתם יכולים להרים לינוקס עם SAMBA, לחבר אותו ל-AD שלכם ולתת שרותים כאו. לגבי שאר הפונקציונאליות – חכו להכרזות בסוף חודש הבא 🙂

רכישת SSD מאוד יקרים
ישנם כרטיסי SSD PCIe מאוד יקרים שנותנים יותר מ-100K IOPS בכתיבה וקריאה. הם מעולים, אבל הם לא נתמכים רשמית ב-6 VSAN, כך שלא מומלץ לבצע השקעה כזו.

כרטיסי בקר
אם אתם מסבים שרת קיים לשימוש ב-VSAN, ודאו שיש לבקר Queue Depth כמה שיותר גבוה (256 זה לא רע בתור התחלה, כמה שיותר – יותר טוב). כרטיסים פשוטים כמו LSI 9211 ומעלה נותנים Queue Depth של 640 וכרטיסים יותר מעודכנים נותנים 1024. בדקו את הבקר אם הוא ב-HCL כאן.

לסיכום: זה מאוד מאכזב לבנות מערכת VSAN, להרים עליה כמה עשרות VM בתור התחלה ואז לראות שהיא בקושי "סוחבת". הסיבה לכך בד"כ היא תכנון לא נכון מבחינת דיסקים (או שימוש ברשת של 1 ג'יגה). הכל תלוי מה ה-VMs שהולכים לרוץ עליה. VM של דסקטופים מצריכים קבוצות קטנות של דיסקים עם SSD מהירים (מומלץ PCIe או NVME) מכיוון שמדובר בד"כ בהרבה יותר כתיבה מאשר קריאה, בשעה ש-VM של שרתים בד"כ מצריך הרבה יותר קריאה מאשר כתיבה, ולכן חשוב לתכנן מראש לפני שקונים ציוד. מתחילים בקטן (3 שרתים מינימום) ומשם גודלים.

איך לרכוש את המוצרים של VMWare בזול

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

המצב כיום ב-2015 שונה מהמצב ב-2005. יותר ויותר חברות גדולות מחפשות מומחה לוירטואליזציה שזו תהיה העבודה העיקרית שלו (אפשר לראות בנקל אם מדובר בחברות גדולות או קטנות – אם הם מחפשים מישהו עם ידע בוירטואליזציה, אבל בדרך שידע גם סטורג', Windows, Linux, והטסת חלליות..). כיום מנהלים רבים או שמשתמשים ברשיון שהם "השיגו" מעבודה או דרך חבר שלקח מהעבודה או שבדרך הידועה של הורדת טורנט ושימוש באיזה keygen/keymaker..

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

אז כן, אם אתה צריך להקים אצלך למטרת טסטים או למטרת מעבדה בבית מערכת כמו vSphere עם vCenter, אז אתה יכול למצוא לך פתרון כלשהו.

אבל מה עם המוצרים האחרים? נניח ואתה רוצה להשתמש ב-VSAN בבית שלך, או שאתה מעוניין להשתמש ב-VMWare Horizon, או להכיר מה זה לכל הרוחות ה-vRealize, למה משמש vCloud? טכנית אתה יכול לקבל 30-60 יום רשיון Evaluation, אבל אחרי זה המערכת לא תתן לך להיכנס (אלא אם תתקין אותה מחדש). חושבים שטורנטים יעזרו לכם כאן? כי סביר להניח שלא תמצאו שום keygen שיוצר לזה מפתחות.

ב-VMWare החליטו לתת לזה פתרון.

הפתרון נקרא VMUG Advantage. מדובר בעצם בקבוצות (User Groups) שמדברות ונפגשות בכל העולם ומשוחחות על מוצרי VMWare וב-VMWare מעוניינים לצ'פר את המצטרפים. לשם כך יש לשלם סכום של 200$ לשנה.

ומה נותן לך המנוי הזה? טוב ששאלת 🙂

המנוי הזה נותן לך דבר שנקרא EVALExperience ועם EVALExperience אתה מקבל רשיון ל-365 יום למגוון מוצרים:

vmug

(שימו לב – כל המוצרים הם הגרסאות האחרונות – כך שאין vSphere 5.5 וגם אם תורידו מאתר VMWare, המפתח לצערי לא ממש יעבוד)

בנוסף, המנוי מעניק לך מספר דברים מעניינים נוספים כמו:

  1. 20% הנחה על קורסים (Online או offline)
  2. 20% הנחה על עלות הבחינות
  3. 50% הנחה על VMWare Fusion או VMWare Workstation האחרון
  4. נוסע לכנס של VMWorld? יש לך $100 הנחה לכנס
  5. גישה בחינם לתכנים מ-VMWorld 2015 (ללא VMUG Advantage המחיר הוא $699)
  6. 35% הנחה על VMWare Lab Connect (בשביל לנסות א הארכיטקטורה שאתם מתכננים)
  7. וכמובן הזמנות לכנסים של VMWare בישראל (מתי שהם יקיימו אותם…)

שווה $200? לדעתי כן

כל זה כמובן מגיע עם הגבלות די פשוטות:

  1. אין להשתמש ברשיון למטרות פרודקשן. רוצה להקים LAB בבית? בכיף. למטרת טסטים? אהלן וסהלן. פרודקשן? VMWare אוסרים על כך.
  2. אתה לא זכאי לקבל תמיכה, לא טלפונית ולא דרך מערכת הטיקטים שלהם. יש לך בעיה? תעבור דרך הפורומים השונים.
  3. אין אפשרות לקבל גרסאות מוצרים קודמות או מפתחות למוצרים ישנים. (בעסה!)
  4. כמות ה-Hosts מוגבלת ל-3 שרתים (עד 2 מעבדים פר שרת).

ויש גם הנחה שמתאימה ל-Corporates: אם החברה שלכם מחליטה ככה ברגע שהיא חטפה מצב רוח של נתינה – לקנות מספר מנויים ל-VMUG, אז אפשר לקבל הנחות כמו 2 משתמשים – המחיר יורד ל-180$, 3 משתמשים זה יורד ל-170$, אז אולי כדאי לדבר עם הבוס…

רוצים להצטרף? אחלה. גשו לאתר כאן ותעברו תהליך של Join. אחרי זה כנסו ללינק כאן ותרכשו מנוי. אחרי שתרכשו, תצטרכו להמתין בין 24-48 שעות לקבלת אישור (אני המתנתי 24 שעות) ואז יגיעו לכם כמה מיילים נוספים כדי לרשום אתכם לחנות שמשרתת את ה-VMUG ומנפיקה מפתחות, וגם לרישום ל-MY VMWare כדי שתוכלו להנות מההנחות, השיעורים וכו'.

משהו אחד לסיום: לא, אני לא מקבל שקל מכל הפוסט הזה ומההפניה הזו, כך שאני לא מרוויח מזה כלום. תהנו 🙂

על 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 יכול להוות פתרון די טוב.

על Virtual Flash Cache ב-ESXI 5.5

אחת הפונקציות המעניינות שקיימות ב-vSphere נקראת Virtual Flash Cache. ב-VMWare התחילו להטמיע את זה אמנם מגירסת vSphere 5.0 אולם רק בגירסה 5.5 עניין ה-Cache עובד בצורה טובה ומלאה. ב-VMWare קוראים לזה בקצרה vFRC, נשתמש בפוסט זה במושג המקוצר.

נתחיל בהסבר של מה זה vFRC: זו בעצם טכנולוגיה שקיימת גם בשאר מערכות הפעלה שונות (כמו לינוקס לדוגמא) המאפשרת לנו להשתמש ב-SSD שיושב מקומית בתור שרת ה-ESXi (ולא ב-Storage המרכזי) ובעצם הוא מאחסן חלק מהנתונים שנקראים תדיר ע"י מערכת ההפעלה ומאפשר בעצם Read & Write Cache. ה-Cache אינו בא להחליף את ה-Storage שלכם וכל ביט שיכתב ב-Cache יכתב גם ב-Storage, כך שאם ה-SSD המקומי מתקלקל, אפשר להחליף, לפרמט ולחזור להשתמש בפונקציונאליות.

מערכת ה-Cache נמצאת ב-2 מקומות מרכזיים: במקום אחד שבו אתם יכולים להגדיר כמות X ג'יגהבייטים שהמערכת תשתמש בעת מצב שהיא תהיה עמוסה ואז אותם X ג'יגהבייטים ישמשו כ-Swap (ואם אתם משתמשים ב-Swap, הגיע הזמן לשוחח עם הקודקודים למעלה על שדרוג מהיר)

המקום השני הוא שבו משתמשים ב-vFRC הוא על המכונות הוירטואליות, וכאן אני צריך להסביר משהו חשוב: לא חשוב מה ה-Storage שיש לכם, בכל פעם שה-VM צריך מידע לקרוא או לכתוב על ה"דיסק" – ה-VM צריך לעשות "טיול" ל-Storage שלכם דרך ה-Datastore, ובין אם ה-Datastore שלכם מבוסס על iSCSI, NFS או FC, מדובר (פחות או יותר) ב"טיול" שלוקח זמן. נכון, זמן קצר, אך בכל זאת.

אם ניקח דיסק SSD מקומי על ESXI ונתקין עליו VM, הביצועים שלו יהיו מעולים בהשוואה למה ש-Storage נותן (למעט בתקשורת של 10Gbit), אבל אז כמובן לא תוכלו להשתמש בפונקציות מתקדמות כמו HA, DRS וכו'.

עם vFRC, זה לא חשוב מה ה-Storage שיש לך, בין אם הוא מורכב מכמה דיסקים SATA שהצלחת לקושש או שמדובר על מערכת EMC או כל מערכת יוקרתית בטירוף – ל-vFRC זה לא משנה. ה-vFRC שומר חלק מהנתונים (בהתאם לגודל שהגדרת) מקומית על SSD שקיים בתוך ה-ESXI והוא מזין את הנתונים שנכתבו בחזרה ל-Storage "מאחורי הקלעים" כך שמבחינת ה-VM, המערכת ממשיכה לפעול גם אם הכתיבה בין ה-vFRC ל-Storage מתבצעת כרגע. כנ"ל לגבי קריאה – קטעים שהמערכת מוצאת שנקראים שוב ושוב (נניח אפליקציה גדולה שרצה על ה-VM ומטעינה ספריות שונות) מאוחסנים ב-SSD המקומיים ומוזנים ל-VM ישירות ברגע שה-VM צריך את אותם קטעים. המערכת גם מספיק חכמה להעיף חלקים ישנים מה-Cache שאין צורך או שנגמר המיקום שמוגדר ל-Cache ויש צורך לכתוב מקטעים חדשים.

הקמת ה-vFRC היא פשוטה: לאחר שהכנסתם SSD ל-ESXI, הפעילו את ה-vCenter (ה-WEB, לא ה-Client הישן), לחצו על ה-HOST שהוספתם, לחצו על Settings, ולמטה אתם תמצאו את ה-Virtual Flash. להלן דוגמא ממערכת טסטים בביתי (לחצו להגדלה):

vfrc

המלבנים האודמים מציינים מה ללחוץ, המלבנים הכחולים מציינים את הכונן שנבחר והגודל שזמין ל-Cache עבור VM (במקרה הספציפי הזה הגדרתי 20 ג'יגה ל-Swap). המלבן הירוק מציין סה"כ כמות מקום פנוי במידה והכנסת יותר מ-SSD אחד (חשוב לציין: Virtual Flash עובד ברמה של RAID-0 מכיוון שכל ה-DATA הוא זמני)

כפי שציינתי, הגדרות Cache ל-VM נעשות פר VM (אם כי יש כל מיני כלים לעשות זה באופן קבוצתי, אני פשוט משתמש ב-BASH ו-sed לשם כך 😉 ) על מנת להגדיר כמות ג'יגהבייט Cache. כך זה נראה (לחצו להגדלה):

vfrc2

וכאן מגיע החלק הלא-כל-כך-פשוט של ההגדרות. לחיצה על כפתור ה-Advanced תתן לכם הגדרות יותר מתקדמות כפי שמופיעות בתמונה הבאה:

vfrc3

רואים את ה-Block Size? הגודל עצמו חשוב מאוד וזה תלוי ב-VM, גודל ה-DATA שהוא כותב וכו'. חישוב לא נכון יתן מה שנקרא Cache Miss מה שיוריד מהביצועים. החישוב אינו כל כך פשוט אך ב-VMWare הכינו מסמך שמסביר את ה-vFRC מבחינת ביצועים, חישובים שצריך לבצע וכו'. להלן המסמך.

[scribd id=268003224 key=key-UjCvDIBCgd52bjCNMHWt mode=scroll]

לסיכום: vFRC יכול לעזור הרבה (לפעמים עד מצב של 300% שיפור) בביצועים, אם עושים את זה נכון. אני לא ממליץ לרוץ מיד לקנות SSD מבוסס PCIe אלא להתחיל בטסטים עם SSD פשוט מבוסס SATA. יש שיפור? עכשיו אפשר לחשוב להוסיף דיסקים SSD בין אם הם מבוססים SAS או SATA או PCIe (אם יש לכם מקום פנוי בשרת). אפשר כמובן להכניס יותר מאחד.

vFRC עוזר בכל מיני סוגי VM ואין צורך בשום שינוי ב-VM עצמו (ב-Guest), וזה בהחלט יכול לעזור אם מקימים VDI, רק חשוב לשים לב לגודל הבלוקים. גדלים כמו 1024 (המקסימום) קילובייט יבטיח לכם Cache Miss וירידה בביצועים, ומצד שני כמות בלוקים קטנה (4-8K) לא ממש תיתן ביצועים רציניים. קראו את המסמך, ותנסו (אין צורך לכבות ולהפעיל את ה-VM מחדש כשמשנים, אם כי מומלץ לסגור את האפליקציה ב-VM ולהפעיל אותה מחדש).

בעניין Hyper Converged

מי שקורא חדשות טכנולוגיה המיועדות ל-IT/CTO/CIO בוודאי שמע בשנתיים-שלוש האחרונות את המושג Hyper Converged (או HC בקיצור), מושג שיותר ויותר חברות משתמשות בו כדי להציע משהו חדש למנהלי ה-IT.

על מנת להבין את עניין ה-HC, כדאי שנראה מה יש ברוב החברות כיום:

כשזה מגיע לוירטואליזציה (ואין זה משנה איזה פתרון Hypervisor אתם משתמשים), בד"כ יש מספר שרתים שהם ה-Host, והם מחוברים ל-Storage כלשהו ומשתמשים בשרותים כמו NFS או iSCSI (או SMB במקרה של Hyper-V) כדי לאחסן קבצים של המערכות הוירטואליות. במקרים מסויימים משתמשים בדיסקים שנמצאים מקומית בשרת עצמו כשמדובר על שרת (Host) שמריץ מערכות וירטואליות עצמאיות או במקרים שאין Storage גדול רציני.

כשאנחנו מעוניינים ליצור אשכול לצרכים שונים (High Availability, Fault Tolerance וכו'), אנו צריכים 2 שרתים (במינימום) שהם זהים מבחינת החומרה ו-Storage חיצוני שיהיה מחובר ל-2 השרתים, ואנו מגדירים דרך הפאנל של הויראטואליזציה (כמו vCenter או VSA/VCSA) את 2 השרתים כאשכול. יש כמובן "ערימה" של דברים להגדיר כמו סוג האשכול, הגדרות אחסון, כתובות, קבוצות פורטים וכו' – אבל זה בעקרון Cluster.

בשיטת ה-HC הדברים שונים לחלוטין: בשיטה זו אין לנו צורך יותר ב-Storage חיצוני. במקום זה השרתים יהיו עם דיסקים מסוגים שונים (SSD, דיסקים מכניים מבוססי SAS/NL-SAS/SATA) וכל השרתים יהיו מחוברים באשכול למתג של 10 ג'יגהביט (מינימום, כאשר כל הכניסות במתג הם 10 ג'יגהביט). על השרתים מותקנת מערכת וירטואליזציה (בד"כ vSphere אך גם KVM נתמך בחלק מהמקרים) ובנוסף מותקן VM מיוחד בכל שרת פיזי שמתחבר ישירות לדיסקים והוא מנהל אותם (ולא ה-vSphere). בשיטה זו הנתונים נכתבים לכל הדיסקים בכל השרתים והמערכות הוירטואליות רצות על השרתים כאשר האחסון הוא על הדיסקים המקומיים וכש-VM "עובר דירה", חלק מהנתונים עובר מהדיסקים המכניים (האיטיים ויתר) ל-SSD וכך ניתנת לנו האפשרות לבצע Live Migration או כל פעולת High Availability אחרת שנרצה (HA, FT וכו'). במצב כזה (וברוב מערכות ה-HC) אנחנו יכולים לסבול מצב ששרת פיזי אחד נופל מבלי שאף מערכת וירטואלית תיפול.

ישנן מספר חברות שמוכרות מוצרי HC, נתמקד בשלישיה המובילה: Nutanix, Simplivity ו-EVO:Rail.

ל-Nutanix יש פתרונות מ-2 סוגים: הפתרון המבוסס תוכנה (אתה מתקין על השרת שלך) או פתרון חומרה (אתה קונה את השרת מהם), כאשר בפתרון שלהם חייבים לפחות 3 שרתים. ההתקנה עצמה היא קלה (לוקח בערך רבע שעה) ויש לך ממשק GUI נחמד ובנוסף יש לך CLI (שהוא בעצם לינוקס עם אובונטו, ככלל – כל המערכת היא בעצם סקריפטים של לינוקס + מודולים קנייניים שלהם) ויש גם ממשק RESTful API למפתחים. המערכת קלה (יחסית) ללימוד, אך היא אינה מחליפה את הצורך ב-vCenter/VSA אם אתה משתמש בפתרון מבוסס VMWare. ניתן במקום vSphere להשתמש בוירטואליזציה הפתוחה KVM אם כי בשלב זה הם עדיין לא מאפשרים להריץ מכונות VM מבוססות Windows (וגם ה-KVM שיש להם די ישן למען האמת, מגירסת CentOS 6.5).

הפתרון השני הוא של Simplivity וגם הוא מאפשר לך לבצע Cluster אך עם טוויסט מעניין: אתה יכול להוסיף את הענן של אמזון כ"חווה" (DC) משלך ואתה יכול להעביר מכונות הלוך ושוב בין DC שונים, ובנוסף יש לך את הדברים שאתה רגיל אליהם מעולם ה-Storage כמו DeDup, Replication, Snapshots וכו' כאשר הדגש הוא בעצם לא "לחנוק" לך את רוחב הפס בין השרתים שיושבים אצלך בבניין לבין ה-DC האחרים. בניגוד לפתרונות המתחרים, הכמות המינימלית שאתה צריך זה שרת אחד.

הפתרון השלישי הוא של VMWare שנקרא EVO:Rail והוא מתבסס על פתרון ה-vSAN ש-VMWare מוכרת, רק שכאן מדובר על שרתים פיזיים שאתה רוכש מיצרנים שונים כקופסא סגורה. גם כאן, יש צורך ברכישה של מינימום 4 שרתים שישמשו כ-Block אחד.

למי שמעוניין להיכנס יותר לעומק ולקרוא על ההתקנה, השימוש, מה נתמך במה, אני ממליץ לקרוא את המאמר המעולה של בריאן סור על הפתרונות הנ"ל.

אז מה? להתחיל לארגן מכרז למכור את ה-Storage הגדול שלכם? ממש לא.

תחום ה-HC כרגע "שורץ" בפתרונות מחברות צעירות וחברות סטארט-אפ. Nutanix כרגע מובילה את שוק ה-HC עם שיווק מאוד אגרסיבי, אבל הפתרונות שלהם גם מאוד יקרים. כמה יקרים? 6 ספרות במונחים ישראלים ואם תרצה משהו יותר רציני כמו ארון שלם – 7 ספרות. החברות הגדולות המייצרות מוצרי Storage כבר לוטשות עיניים לעבר החברות הקטנות וסביר להניח שנשמע בקרוב על כמה רכישות, ומכיוון שתחום ה-IT הוא תחום שמרני, מומלץ לא לסגור עסקאות עתה אלא להמתין.

תחום ה-HC נותן פתרונות שיכולים מצד אחד לחסוך הרבה עבודה (תקים פעם אחת, תוסיף ניטור משלך ועדכונים מעת לעת – ואתה מסודר. תיאורתית לפחות), אבל מי שוותיק בתחום הזה יכול להיזכר בתקופות קודמות בהן גם חברות מכרו ל-IT מוצרים שנתנו "HC" בתחומים אחרים (זוכרים Self Healing?) וכעבור מספר שנים אותן קופסאות ישבו בחוות השרתים ו… צברו אבק. פתרונות ה-Storage שיש לנו כיום מלכתחילה לא תוכננו לאחסון דיסקים של VM והפתרונות שיש הם (בלי שאף אחד יודה בצורה רשמית) הם "hacks" רציניים (פתרון כמו iSCSI היה בכלל מדובר להתחברות ל-initiator יחיד, בינו ל-LUN שמוגדר ב-Storage, והשינויים ב-VMFS ש-VMWare עשו איפשרו לו להתחבר ל-2 שרתים במקביל, ו-NFS היה צריך גם שינויים ברמת ה-Storage בקוד על מנת לאפשר לו לעבוד טוב מול Hypervisor). פתרון טוב, לעניות דעתי, הוא פתרון Cluster אך מופרד ועדיף פתרון שמקובל על רובם או כולם: פתרון שיתן לנו לייצא מ-Cluster שמיועד ל-Storage איזה Block Device, אבל שיהיה בצורה טבעית ניתן לשיתוף בין Clients שונים לדוגמא, פתרון שאם אני מחבר אותו למערכת וירטואליזציה, שאינו צריך להמתין ל-Acknowledge שהתוכן נכתב לפני שהוא מאפשר למכונה הוירטואלית להמשיך לעבוד כרגיל.  אלו פתרונות שעדיין לא קיימים כיום בצורה יציבה ומלאה (הכי קרוב שידוע לי שקיים – זה Ceph). בעיה נוספת שקיימת עם פתרונות ה-HC הוא עניין הבטחון לגבי העתיד – מה תעשה אם אותה חברה שרכשת ממנה קופסאות מחר תיעלם או שיתגלעו ביניכם חילוקי דעות לגבי מחירי חידוש תמיכה?

ב-The Register הופיע לאחרונה מאמר של טרוור פוט על כך ש-VMWare "מפחדת" מחברות כמו Nutanix שתסחוף את השוק לכיוונה ומכיוון שב-Nutanix הוירטואליזציה היא (כמעט) אינה פתרון רק של VMWare, אז VMWare יכולים להפסיד את השוק וחברות אחרות מתחרות ל-Nutanix יכולות להעתיק את אותה שיטה ושוב – VMWare תהיה בצרות. מבחינתו, כמנהל IT הוא יוכל לעבור בין פתרון אחד לאחר בקלות. זו דעתו כמובן, אך מנסיון שלי כאחד שהקים כמה פתרונות שמבוססים הן על VMWare והן על פתרונות וירטואליזציה אחרים, אני יכול לאמר כי מעבר בין פתרון וירטואליזציה אחד לפתרון אחר אינו קל כלל וכלל ובמקרים רבים התוצאות והתהליך יגרמו אי נוחות למנהל ה-IT, ועוד לא התחלתי לדבר על מעבר מפתרון שיש NetApp (לדוגמא) לכל פתרון אחר, שגם הוא, איך נאמר בעדינות – הדרך אינה סוגה בשושנים.

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

על אחסון וגדילה – חלק שני

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

לפני שאתחיל להסביר לגבי Scale Out, אני רוצה לענות על שאלה שנשאלתי בכמה הזדמנויות: האם פתרון Scale Out מתאים לכולם או לרובם? האם זה יכול להחליף פתרון אחסון שיש כיום לרוב החברות?

התשובה אינה יכולה להסתכם ב"כן" או "לא". אם לדוגמא יש לך 10 שרתים פיזיים שמריצים נניח 100 מכונות VM ויש לך אחסון כלשהו (בין אם זה של Oracle, NetApp, EMC ואחרים) – אז התשובה היא "לא" – פתרון Scale Out לא יתאים לך מכיוון שמדובר בהגדלה והוספה של לפחות 4-5 שרתים פיזיים וערימות של דיסקים קשיחים מסוגים שונים. עלות של דבר כזה תעקוף בקלילות עלות של אחסון זהה למה שיש לך כיום כך שלא תרוויח מזה הרבה. במקרים כאלו אם אתה רוצה להחליף את האחסון הנוכחי באחסון מבוסס קוד פתוח לדוגמא – עדיף שתסתכל על פתרון מבוסס ZFS לדוגמא.

היכן זה כן יכול להתאים? במקומות שיש צורך בדברים כמו:

  1. הרצה של אלפי מכונות וירטואליות מבוססות KVM או XEN (כמובן גם Open Stack)
  2. מקומות שיש כמויות קבצים עצומות (עשרות מיליונים ומעלה) עם המון משתמשים שניגשים
  3. חוות HPC
  4. ארכיבאות ענקית
  5. פתרונות Cold Storage (נתונים שהגישה אליהם היא נדירה אך כמות המידע היא ענקית ונמדדת ב-Petabytes, Exabytes ומעלה)
  6. שידורים (Streaming)

תעשיות שצריכות פתרון Scale Out לדוגמא:

  1. חברות ביטוח
  2. שימוש בסימולטורים שונים במגוון תחומים
  3. חברות שרוצות לעבד נתונים כמו גז, נפט, מים וכו'
  4. מחקר גנום
  5. בנקים
  6. ועוד

מה נותן לנו Scale Out? גישה שונה לאחסון/שימוש במידע. אין יותר שרת X שממנו אנו ניגשים לקבל את המידע. ליתר דיוק יש לנו "שרת X" אבל הוא לא ממש שרת, הוא משמש יותר כ-Gateway שמצוין על ידי שם host שעבורנו יהיה קל יותר לפנות, אך מה שחשוב לזכור הוא שאיננו פונים לשרת שמאחסן את הנתונים. אם יהיו לנו 100 שרתים פיזיים שמריצים את אותו פתרון אחסון שהוא בנוי ב-Scale Out, אין לנו צורך לפנות לאחד מהשרתים. ה-Gateway כבר יפנה למי שצריך.

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

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

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

  1. פתרון מבוסס Ethernet – תוכל לבחור בין 10/25/40 ג'יגהביט
  2. פתרון מבוסס Infiniband – עם פתרון זה גם תוכל להגיע ל-100 ג'יגהביט, אבל תצטרך להשקיע לא מעט במתגים וכרטיסים, ומתגים מנוהלים ב-Infiniband ממש אינם זולים.

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

באחסון Scale Out לעומת זאת, יש 3 סוגים:

  1. אחסון "תמונות" – מדובר באחסון קבצים סטטיים, קבצים שלא ישונו בשרת האחסון וההרשאות לגישה לקבצים הן קטנות ופשוטות. השם שקולע במדויק הוא שרות של אמזון – ה-S3 שלהם, זה בדיוק זה.
  2. אחסון "בלוקים" – אחסון "שטחים" שמהם המערכת תייצא החוצה Block Device, בדיוק כמו שמערכת iSCSI מייצאת החוצה. אתה מתחבר ל-Block Device ומפרמט אותו לפי הצרכים שלך ב-Client. מבחינת מערכת האחסון עצמה, אין לה מושג ירוק מה תאכסן באותו בלוק, כך שאם תפרמט את זה ל-NTFS או VMFS או EXT4 או XFS – האחסון לא יהיה מודע לכך.
  3. אחסון קבצים סטנדרטי – בדיוק כמו באחסון רגיל שאנחנו מכירים, כאן מתאחסנים קבצים עם גישה דרך CIFS/SMB או NFS וכו'.

מבחינת פתרונות Scale Out, ישנם פתרונות קנייניים מכל יצרניות האחסון, החל מ-EMC עם Isilon, דרך IBM עם XIV, ממשיכים ב-NetApp (סידרת FAS8000 ומעלה), ויש עוד כמה. האם הם טובים? כן, אם כי לכל אחד מהם יש חסרונות ויתרונות (בקשו מאנשי המכירות של IBM לדוגמא לשלוח לכם את המצגות הפנימיות שלהם על חסרונות של מוצרים מתחרים, תתפלאו כמה הם "חפרו" לעומק המוצרים האחרים כדי לגלות כל פיפס וכל פאק רציני בכל מיני עומסים) – אבל החסרון הגדול של כולם הוא המחיר. הוא מטורף וזה יכול להגיע למצבים שגם חברות מאוד מבוססות לא חותמות כל כך מהר על הזמנת הפתרון.

מהצד השני יש פתרונות קוד פתוח וכאן יש כמה שמות ידועים כמו: Luster, GlusterFS, iRods, HDFS. אלו פתרונות שידועים ונמצאים בשימוש בכל מיני מקומות גדולים עם שימוש מאסיבי. החסרון שלהם הוא בכך שאינך יכול לכתוב פקודת mkfs והאחסון יהיה מוכן, ותצטרך להשקיע זמן רציני כדי לתכנן ולהכין ולבדוק את המערכת אחסון לפני שתוכל ממש להשתמש בה, אך מצד שני ה-TCO יגרום להרבה מנהלים לחייך.

ויש את Ceph.

בעקרון, Ceph מכוונת להיות One Stop Solution אם אתה מחפש פתרון Scale Out. בזמן שפתרונות מבוססי קוד פתוח כמו Luster יכולים לתת לך פתרונות כמו Block Device, Images, FS – החסרון של Lustre זה שהכל עובר דרך שרת פיזי אחד, מה שאומר שתקבל "צוואר בקבוק" תוך זמן קצר, וכנ"ל גם iRODs עם אותה בעיה. אם נדבר על HDFS לדוגמא – הוא מעולה לאחסון קבצים אבל צוואר הבקבוק בו קשור ל-NameNode. לסיום Gluster לא מאפשר Block Device או FS (אם כי פונקציונאליות זו אפשרית עם plugins).

אז Ceph נותן את השלישיית סוגי אחסון מידע שאנו צריכים בפתרון גדול. להלן תרשים איך Ceph מורכב:

Ceph

בחלק התחתון יש לנו את RADOS (ר"ת של Reliable, Autonomous, Distributed, Object Store) והוא החלק האחראי על אחסון הנתונים עצמם. מעליו יש לנו "גישות" שונות לנתונים:

  • גישת ה-APP, הגישה שמתאימה למפתחים: אתה יכול לגשת במספר שפות פיתווח שונות דרך ספריה שנקראית librados אל הקבצים (יש כמובן גם Authentication שלא כל אחד יוכל לגשת). זהו פתרון מעולה אם החברה מפתחת את הכל בעצמה או שהיא רוצה להתממשק עם ממשק משלה ל-Ceph.
  • גישת ה-RADOSGW – זו גישה שתואמת הן את S3 של אמזון והן ל-Swift של Open Stack, כך שאם יש לך קוד שניגש ל-S3, תצטרך שינויים מינוריים כדי לגשת לנתונים.
  • גישת RBD – בגישה זו אתה יכול ליצור ולקבל גישה אל Block Device, כאשר ה-Block Device הוא בעצם מורכב מאובייקטים שפזורים על פני ה-Nodes השונים באשכול Ceph. דרייברים קיימים כיום ללינוקס, ל-KVM ול-XEN, דרייבר ל-Hyper-V יצא בחודשים הקרובים ואחריו דרייבר ל-ESXi.
    ניתן גם לחבר Block Device לשרת לינוקס אחר, ומאותו שרת לינוקס לייצא את הבלוק כ-iSCSI או לפרמט את הבלוק ולהגיש אותו דרך SAMBA או NFS (דרך Ganesha)
  • גישת Client – מאפשרת לך להשתמש ב-CephFS כשרת קבצים לכל דבר ועניין, כאשר ה-FS יכול להיות XFS, BTRFS או EXT4. הלינוקס קרנל תומך בכך עוד מגירסאות 2.6.32 ומעלה.

אחד הדברים שצריך להפנים עם Ceph (וחלק מהפתרונות Scale Out שמבוססים בקוד פתוח) הוא שאין צורך ב-RAID יותר. אתה יכול להשתמש כמובן ב-RAID איזה שתרצה אבל אתה פשוט תפחית ביצועים למערכת כי היא בנויה מההתחלה להפיץ את החלקים השונים בין ה-Nodes. יש מקרים ש-RAID כן יכול לסייע לך כמו RAID-0 לשם Cache בין מספר כונני SSD. (כן, RAID-0 הוא לא לשם שרידות, אבל בין כה Cache אינו שורד).

Ceph, כמו ZFS, מפריד בין ה-Data ל-MetaData. כך לדוגמא אם יש לי תמונת נוף, אז התמונה עצמה היא ה-DATA אולם שם הקובץ, הרשאות גישה, היכן הוא מאוחסן ועוד פרמטרים – הם Meta Data והם נשמרים ב-Journal, רק שבניגוד למערכת לינוקס רגילה, מומלץ את ה-Journal לשמור על פרטישן בכונן SSD להאצת ביצועים (בדיוק כמו ב-ZFS את ה-SLOG מומלץ לשמור על SSD). בניגוד ל-ZFS שכותב קודם כל את ה-Meta Data והטרנזאקציה עצמה ל-SLOG ובכך מונע בעיה שבמקרה של הפסקת חשמל יאבדו הנתונים – עם Ceph מומלץ שבקר הדיסקים שלך יהיה עם סוללת גיבוי.

הגישה לדיסקים ב-Ceph נעשית ע"י Daemon מיוחד שנקרא OSD (או Object Store Daemon), זהו תהליך שרץ על כל דיסק. בעקרון, Ceph מפרמט כל דיסק שמוכנס אליו בברירת המחדל ל-XFS (אך אפשר להגדיר זאת ל-EXT4 או BTRFS) כפי שתוכלו לראות בתמונה הבאה:

osd

וכך נראים ערימה של שרתים שמחוברים עם הדיסקים שלהם בתמונה הבאה:

nodes

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

mds

אחד הדברים ש-Ceph אימץ מתוך NFS-4 הוא רעיון ה-MDS (כלומר MetaData Server). גם הוא, כמו Monitor, רץ רק מספר קטן של פעמים (ולא בכל ה-Nodes), ותפקידו הוא בעצם להצביע היכן נמצאים האובייקטים ומה צריך להגיע ל-Clients. הוא לא מעביר את הקבצים עצמם ל-Clients כך שהוא תמיד פנוי לקבל פניות כדי להצביע היכן נמצאים קבצים. אם משתמשים ב-Ceph ולא משתמשים ב-CephFS אז אין צורך ב-MDS.

איך Ceph כותב קבצים אם הם מחולקים ל-Nodes שונים? ב-Ceph יש מושג שנקרא CRUSH (ר"ת Controlled, Scalable, Decentralized Placement of Replicated Data). הנה תמונה שמבהירה מעט יותר:

crush

אז CRUSH הוא אלגוריתם שלוקח בחשבון כל מיני פרמטרים ובהתאם – מאחסן חלקים של הקובץ בצוורה שווה בין ה-Nodes ב-Cluster. הוא עושה את החישוב בצורה מאוד מהירה. CRUSH (בסיוע ה-Monitor ו-OSD) יודע גם לטפל בבעיה אם נופל שרת או דיסק, הוא ידע מהיכן לקחת את הנתונים ולהיכן לשכפל.

נקודה חשובה שיש ל-Ceph זה שכל ה-Block Devices שהוא יוצר הם Thin Provisioned, כך שאם יש לך מאסטר אחד וממנו אתה רוצה להרים כמה מאות או אלפי VM ומהר, תוכל לעשות זאת ללא צורך בעשרות ומאות שכפולים. רק ה-Delta של השינויים עצמם יכתבו. כנ"ל לגבי Snapshots – ניתן ליצור Snapshots ו-Incremental Snapshots (כן, כמו ZFS). בכל הקשור לכתיבה, גם כאן, כמו ZFS, מערכת Ceph מבצעת Copy on Write, וכן, כמו ב-ZFS גם ב-Ceph יש Scrub (לבדיקת שלמות הנתונים על הדיסקים).

מכיוון ש-Ceph תהיה ממומשת במערכים גדולים של מאות ואלפי דיסקים, ישנה בעיה של מהירות כתיבה. אחרי הכל, אף גוף שפוי (אוקיי, רובם..) לא יסכים להכניס רק SSD, צריכים שתהיה גישה מהירה יותר וכאן Ceph שוב מעתיק מ-ZFS, רק שהוא לוקח את זה 10 צעדים קדימה ומאפשר לך דבר שנקרא Cache Tier. אתה יכול להגדיר לכל Pool היכן תשתמש בדיסקים מהירים (כמו SSD) לכתיבה מהירה, היכן הכתיבה תהיה איטית ועוד. תוכלו לקרוא על כך בהרחבה כאן.

כפי שאתם יכולים לנחש, Ceph זו חתיכת מערכת אחסון שמנסה לענות על כל הצרכים לחברות שצריכות אחסונים שונים ובצורות שונות. היא יכולה להחליף לדוגמא אחסון של Hadoop, אם החברה מריצה Open Stack אז היא יכולה לתת פתרון גם ל-Object Storage וגם Block לשרתים הוירטואליים, וגם לתת שרותי FS (אם כי כדאי לזכור שהחלק הזה עדיין בשלבי QA).

עד כאן הכל טוב ויפה, אבל אני מניח ש-3 שאלות צצות למנהלי תחומי IT:

  • האם יש GUI לכל הדבר הזה? התשובה, גם כאן, אינה בדיוק פשוטה. כן, יש GUI שיועד יותר לסטטיסטיקות (ונקרא Calamari), כמו מה מצב ה-IOPS שלך, כמה השתמשת והיכן, פילוחים שונים, מצבי דיסקים ועוד. לא, אם צריך לעשות תחזוקה לדברים – צריכים את זה לבצע דרך ה-Shell בלינוקס. וידאו של אותו GUI בסוף פוסט זה.
  • מי החברה שעומדת מאחורי זה? מי נותן תמיכה? (טוב נו, חוץ מהעסק שלי 🙂 ) – התשובה היא שרד-האט מוכרת כיום את Ceph ו-רד-האט ישראל משתתפת בפיתוח Ceph. (ד"ש חם ליהודה שדה מ-רד-האט ישראל).
  • מה עם תמיכה מלאה ב-Hyper-V ו-ESXi? בחודשים הקרובים תהיה תמיכה מלאה ל-2 המוצרים.

ולסיום, וידאו הכולל הדגמה של Ceph וה-GUI: