הבעיה עם MySQL והפתרון של אמזון

כמעט כל אתר קטן שרץ על לינוקס וצריך DB (ואיזה אתר לא צריך?) -אתרים רבים התחיל את דרכם עם MySQL. השפה עצמה יחסית קלה, התוכנה חינמית, יש תיעוד מכאן ועד הודעה חדשה לכל פונקציה ולכל בעיה והוא עושה את העבודה בצורה לא רעה. יש כמובן יותר טובים ממנו כמו PostgreSQL שגם הוא מבוסס קוד פתוח, אבל אם תשאלו כמעט כל סטארט אפ שהתחיל והשתמש ב-RDBMS, סביר להניח שההתחלה היתה על MySQL.

יחסית, MySQL יודע להסתדר די טוב עם כל חומרה שתזרקו לו, החל מ-512 מגהבייט של זכרון ודיסק SATA מכני פשוט ועד מעבדי Xeon E7 עם ליבות מרובים, מאות ג'יגהבייטים של זכרון ודיסקים SSD מבוססים NVMe. תצטרכו כמובן להגדיר דברים מסויימים בקובץ my.cnf, אבל בד"כ איש סיסטם טוב ידע להסתדר עם זה.

הבעיות מתחילות כשאנחנו צריכים להתרחב מבחינת כמות שרתים מעבר לשרת יחיד. מכאן אנחנו עוברים לשיטות כמו Master/Slave, אנחנו יכולים להשתמש ב-Sharding ויש עוד כמה שיטות. לכשזה עובד – הדברים עובדים בצורה טובה… עד שקורה Crash, צריך להשתמש ב-mysqlbinlog והסיפור לוקח זמן. בעיות אחרות יכולות לקרות אם הסינכרון נופל היכן שהוא. שורת הקללות שאיש הסיסטם (או ה-DBA) יפלוט – תהיה ארוכה.

חברות שונות כשגודלות מחליטות מסיבות שונות לעבור לפתרונות מבוססים NoSQL, בין אם זה DynamoDB, או MongoDB ופתרונות אחרים ששם עניין ה-Scalability נבנה בצורה אחרת והוא יכול להתפרס על פני מאות Nodes ויותר ב-Data Centers שונים בעולם. אם תסתכלו כאן לדוגמא, תראו שחברות גדולות מאוד ומפורסמות משתמשות ב-MongoDB והן מרוצות, מאוד.

אבל מה לעשות, חברות רבות לא רוצות או לא יכולות לעבור מפלטפורמת DB אחת לאחרת שהיא שונה מהותית. חלק מאותן חברות לדוגמא, משתמשות בוורדפרס כמערכת עיקרית שעליה הם כותבים את האפליקציות שלהם. חברות אחרות השקיעו עשרות אלפי שעות אדם בכתיבת אפליקציות שעובדות מול MySQL ושכתוב חלק גדול ל-NoSQL אינו בא בחשבון, כך שבסופו של יום – יש לא מעט חברות וארגונים שבשבילם MySQL הוא דבר חיוני מאוד, והם לא מעוניינים לעבור למשהו אחר שונה.

באמזון, חברת הענן הציבורי הגדול בעולם, החליטו בהתחלה להציע את שרות ה-RDS ואחת האופציות העיקריות שם היא MySQL מנוהל. אתה מגדיר בהתחלה אם אתה מעוניין ב-Instance יחיד קטן או שאתה מעוניין בשימוש מספר Availability Zones (כך שתהיה רפליקציה של ה-DATA באזורים שונים ב-Data Center), אתה מחליט על גודל מכונה, כמות אחסון וכמות IOPS (חישוב שאני אישית שונא) ואתה מקבל Instance של MySQL שאמזון מנהלים עבורך. מבחינת חברות שכבר שמות את האפליקציה שלהן בענן – זה פתרון טוב יותר מאשר סתם לשכור מספר Instances ולהתחיל לעשות את כל עבודת ה-MySQL ידנית, אבל עדיין, מבחינת השוואת ביצועים – Instance שאתה תרים על מכונה חזקה מאוד – יהיה יותר מהיר מ-RDS (אם כי כמובן אתה תפסיד הרבה מהפונקציונאליות של RDS ואתה תצטרך לבצע הרבה דברים ש-RDS מבצע לבד).

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

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

לכן באמזון בנו מוצר חדש שנקרא Aurora שבא בעצם לתת פתרונות לכמה דברים:

  • הוא בנוי מהרגע הראשון ל-High Availability. צריך Instance יחיד לבלוג שלך או שה-? חזור ל-RDS עם MySQL.
  • אין יותר הגדרות של Storage וה-Storage הוא אינו חלק מהמכונה. מעתה ה-Storage מנוהל ע"י אמזון והוא גודל דינמית לפי הצרכים של ה-DB שלך עד לגודל מפלצתי של 64TB!
  • היא מהיר הרבה יותר מ-MySQL – פי 3-5.
  • אתה יכול לבצע מיליוני טרנזאקציות בדקה מ-Instance ואם אתה צריך עוד רפליקות, אתה יכול להוסיף עד 15 רפליקות.
  • ה-DB נופל ברפליקה מסויימת? שכח מזה, Aurora מטפל ומנטר לבד הכל.
  • ה-DATA שלך שמור בלא פחות מ-3 עותקים ב-AZ, כך שאם יש לך Crash, השחזור הוא מיידי.
  • יש לך Snapshots ואתה יכול לבחור Snapshot ולהשתמש בה כ-DB עיקרי מיידית.
  • אין לך צורך לנהל כמעט שום דבר, גם עדכוני תוכנה מבוצעים מיידית בזמן שתגדיר במערכת
  • מכונות גדולות – אתה יכול להרים מכונה עם עד 244 ג'יגהבייט זכרון ו-32 ליבות.
  • אפשר תוך מספר קליקים לעבור מ-RDS עם MySQL ל-Aurora

ומה שהכי חשוב: Aurora תואם MySQL 5.6 בתצורת On the wire, כלומר האפליקציה שלך לכשתתחבר אל ה-Instance, תחשוב שמדובר ב-MySQL לכל דבר ועניין.

לכן, הפתרון עם Aurora נותן מעלה טוב מאוד לכל אותן חברות שרוצות להמשיך עם MySQL אבל רוצות לתת פתרון שיכול לעמוד בקצבים גבוהים ובגידול מאסיבי בתוך זמן קצר מאוד (פיקים לדוגמא) וכל זאת מבלי לשבור את הראש על קלאסטרים, Sharding, Master/Slave ועוד הגדרות רבות.

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

יש גם חסרונות:

  • אם גודל ה-Datasize שלך הוא די קטן (כמה אלפים) – Instance שתרים משלך עם 3000 IOPS ירוץ יותר מהר מ-Aurora (אם תשתמש ב-DB חלופי ותואם כמו Percona)
  • ה-Aurora עדיין לא מהיר ברוב המקרים בהשוואה ל-Percona גם ב-Datasize גדול (אתם מוזמנים לקרוא את המאמר שלהם כאן).
  • אם יש לך איש סיסטם בחברה, הוא יכול לבנות פתרון יותר טוב מ-Aurora  בין אם בשימוש Percona או גם MariaDB, עם אחסון בעל IOPS גבוה ובניית שרידות שמורכבת מ-AZ, כך שבשביל חברות כאלו – Aurora לא יתן הרבה.

הדבר היחיד שחסר בזה – איזה Free Tier לשחק איתו 🙂

סוגי מחשוב ענן

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

לדוגמא – כאן בישראל ישנן מספר חברות שתוקעות את המושג "ענן" על שרותים שכל חברה יכולה להריץ במשרד שלה כאשר בתכל'ס מציעים לך VM או מספר מכונות VM, והם מציעים עוד שרותים שרצים על שרת 2012 כמו "VDI", תיבות מייל וכו'. לא בדיוק מה ש-Corporate צריכים אבל עסקים קטנים כן צריכים ועסקים גדולים יכולים אולי להשתמש בזה כמכונות חרום שיושבות בחוץ או כמכונות מופרדות מהתשתית להצגת אתר החברה וכו'.

חברות ענן נוספות מוכרות שרות מסוים וזה בעצם המוצר שלהן, הן לא מנסות למכור לך 1001 שרותים אלא אך ורק שרותים במסגרת קטגוריה מסויימת. כך לדוגמא חברת Deserve-IT מציעה שרות DR בתצורה מעניינת: לא חשוב מה ה-Hypervisor שאתם מריצים ב-Corporate שלכם, בין אם זה vSphere או Hyper-V – השרות שלהם יוכל לסייע לך להפעיל במקרה חרום את המכונות שלך מחוץ לתשתית המקומית שלך. (נכון לזמן כתיבת שורות אלו, הם תומכים ב-ESX ו-Hyper-V ובקרוב תהיה תמיכה מול OpenStack).

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

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

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

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

על רשיון VDA ועל פתרונות עוקפים

אחת הבעיות המהותיות ביותר בהטמעת כמעט כל פתרון VDI, הוא עניין הרישוי מערכות הפעלה של מיקרוסופט. למיקרוסופט יש פתרונות ה-VDI משלה וכל פתרון אחר שאינו משלה מצריך תוספת כספית רצינית. מישהו עשה חישוב ומצא שאם אתה רוצה להרים פתרון VDI שאינו מבוסס על טכנולוגיית מיקרוסופט, תצטרך לשלם משהו כמו $100 פר תחנה, ולא מדובר על תשלום חד פעמי אלא מנוי שנתי.

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

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

פתרון 1
הפתרון הראשון הוא שימוש במערכת הפעלה של מיקרוסופט המיועדת לשרתים, ו"הפיכתה" למערכת דסקטופ. אפשר לבצע זאת הן על מערכת 2008/2008R2 והן על 2012/2012R2 בגרסאות Standard. מיקרוסופט עצמה מאשרת כי למערכת ש"הומרה" לדסקטופ, אין צורך רשיון VDA (אבל מצד שני גם לא תוכלו להשתמש במערכת הזו למשתמשים רבים אלא אך ורק מכונה פר משתמש). הנה מה שמיקרוסופט כותבת (מתוך ה-FAQ לגבי VDI – לחצו להגדלה)

vdaמי משתמש בטריק הזה? חברה אחת שאולי שמעתם עליה בשם .. אמזון, שמציעה שרותי דסקטופ תחת השם Amazon Workspaces. לפחות ממה ששמעתי מכל מיני אנשים שביצעו זאת, אין שום בעיה להריץ כל אפליקציה של Corporate.

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

הרבה, הרבה מאוד חברות לא אוהבות רעיון ה-VDA. תחשבו על זה לרגע – הדסקטופים שלכם והלאפטופים – בכולם יש Windows ששולם פעם אחת בלבד, וגם הרשיונות למערכות Windows 2012/2012R2/2008 שולמו באופן חד פעמי, ואילו VDA מצריך תשלום כל שנה, ולכן החברות הללו שהיו מעוניינות לחשוב על פתרון VDI פנו הן ל-Citrix והן ל-VMWare למצוא פתרונות חלופיים.

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

ה-VDI שיופעל עבור המשתמש הוא לינוקס לכל דבר ועניין, בין אם זו הפצת RHEL או Centos (גירסאות 6.6 ומעלה) או אובונטו 12 (שאר ההפצות לא נתמכות באופן רשמי אבל מנסיון – אין שום בעיה להשתמש בהן, כולל סביבות כמו KDE, XFCE ואחרות). ההטמעה בלינוקס (במקרה ומדובר ב-Horizon View של VMware, ב-Citrix זה שונה) כוללת התקנת VMWare Tools (ואני ממליץ לא להתקין את החבילה ש-VMWare נותנת אלא את Open VM Tools שזו גירסת הקוד הפתוח שהיא הרבה יותר יציבה, מעודכנת, וגם המהנדסים של VMWare משתתפים בפרויקט והחבילה כלולה בתוך ה-REPO ברירת המחדל של ההפצה), התקנת JRE (כן, ב-VMWare עדיין חושבים שלהריץ JAVA על דסקטופ זה דבר חכם…) ואת ה-View Agent והגדרות נוספות שונות שאיש הלינוקס יצטרך להוסיף. אגב, את עניין הרפליקציה של המכונות (בין אם Linked Clones או Full Clones יש צורך לבצע עם סקריפט שכתוב ב.. Power Shell. לך תבין מדוע..)

לאחר שהמשתמש מקבל את המסך הלינוקס (אחרי שהוא התחבר ל"פורטל"), הוא מבצע Login למערכת (אין שום בעיה שיבצע Login מול AD של מיקרוסופט) והוא יקבל סביבה גרפית שאיש הלינוקס בחברה בנה/שינה כדי שתיראה כמה שיותר "ווינדוזית". מכאן והלאה, שמשתמש יבצע Double Click על אייקון כלשהו (דפדפן, וורד וכו' וכו') הוא יקבל בעצם את האפליקציה משרת 2012/2008 כך שהלינוקס הוא רק "מעטפת", אתם לא תתחילו להריץ תוכנות לינוקסיות בחברה (אלא אם אתם רוצים, אבל זה משהו אחר. זו לדוגמא יכולה להיות הזדמנות מעולה להטמיע כרום ולשכוח מוירוסים)

בשיטה זו – אתם משלמים 0 פר VDI למיקרוסופט (שוב, למעט רשיונות שאתם צריכים לשלם על Published Apps)

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

 

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