תחום האחסון בעוד 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 שרתים מינימום) ומשם גודלים.