חדשות חול המועד- vSAN, Pure וחרושת שמועות

VMware vSAN 6.6

מרגיש כאילו רק לפני רגע דיברנו על 6.5 והנה VMware הכריזו השבוע על גרסה 6.6 של vSAN. מדובר בהכרזה הכי גדולה שלהם מעולם מבחינת כמות החידושים הכלולים בה. אחד החידושים הכי מעניינים לדעתי הוא מנגנון ההצפנה המובנה ל Data at rest. לא, אני לא סתם מתחנף אל אשת אבטחת המידע שלי, אני אוהב את הפיצ'ר הזה כי יש בו טריק. יש הרבה פתרונות להצפנת מידע במערכות אחסון, אנחנו ב Infinidat למשל משתמשים בדיסקים בעלי מנגנון הצפנה חומרתי מובנה. vSAN הוא פתרון תוכנה בלבד ולכן כמובן לא יכול להשתמש בדיסקים כאלו ולכן חייב לבצע הצפנה ברמת התוכנה. נקודה חשובה שצריך לתת אליה את הדעת – מידע מוצפן במקור הוא בדיוק כמו מידע דחוס במקור, למערכת האחסון אין דרך אפקטיבית לבצע dedup או דחיסה למידע מוצפן ולכן מדגישים ב VMware שסדר הפעולות ב vSAN הוא שקודם הבלוקים מחולקים ליחידות של 4K ואז לפי הסדר יוצרים להם checksum, מבצעים dedup, מבצעים דחיסה ורק אז מצפינים. זה משמעותי מאד אל מול היכולת המובנית ב 6.5 למשל בה אם הפעלנו את יכולת ה VM encryption איבדנו את כלל יכולות ה storage efficiency ומאד מגניב כי גם יכולות ה dedup והדחיסה שופרו בגרסה הזו.

בשעה טובה גרסה 6.6 כבר לא דורשת multicast ככה שמבנה התקשורת נהיה נוח וקל יותר לשימוש. שיפור משמעותי נוסף מדבר על היכולת להתגונן גם מפני כשל מקומי וגם מפני כשל של אתר מלא, עד גרסה זו, אם השתמשנו ביכולת stretch cluster נאלצנו לעשות פשרה בעצם, כל אובייקט היה מוגדר בתצורת raid-1, עותק אחד בכל אתר, ככה שאם הייתה בעיה באתר אחד היינו נשארים רק עם העתק יחיד באתר השני ואז היינו לא מוגנים מפני כשל נוסף. עכשיו יש בעצם שתי הגדרות נפרדות, אחת שמגדירה אם האובייקט מרופלק לאתר המרוחק או לא והשני קובעת את הרמת ההגנה שלו באתר המקומי (riad 1, 5,6).

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

Pure NVMe X blade

גם החברים מ Pure השיקו מוצר חדש השבוע, תמיד כיף לפרגן למתחרים והם הראשונים להשיק מערך אחסון מבוסס NVMe. חלק מההכרזה מתרכז כמובן במסרים שיווקיים לחלוטין כמו 1PB ב 3U (רלוונטי רק אם מצליחים בפועל לספק יחס efficiency של כמעט 1:6) אבל חלק מדבר על המשך שינוי הכיוון של Pure מפתרון מבוסס תוכנה לפתרון מבוסס חומרה. בתחילת הדרך Pure היו יצרן תוכנה שהשתמש ב consumer grade SSD כדי לספק פתרון All Flash במחיר מאד תחרותי, הדגש שלהם בהכרזה הקודמת הולך ומעמיק בהכרזה הזו על פתרון שהוא פתרון חומרה טהור עם קצת טוויקים של התוכנה כדי להסיר שכבות מיותרות. זה לא רק שינוי כיוון משמעותי מהכיוון המקורי שלהם אלא גם כיוון שנוגד לחלוטין את הכיוון שלנו באינפינידט ככה שמאד מסקרן לראות לאן הם יצליחו להגיע עם זה. המספרים שפרסמו EMC בתחרות מול הדור הקודם של Pure (//M) היו, אם נגיד בנימוס, לא מאד מחמיאים ל Pure ככה שאני מאד סקרן לראות את הבנצ'מרקים של הדור החדש.

חרושת שמועות

גם שוק השמועות ממשיך להתפרע, the register הכריזו ב30 במרץ שHPE רוצה לרכוש את Veeam ולמרות שכרטיס מלור נוטה לפגוע בתחזיות שלו, מהלך כזה לדעתי לא יעשה הרבה הגיון עבור HPE שמפצלת את נכסי התוכנה שלה. אולי זו הייתה מתיחת האחד באפריל שלהם שפורסמה בטעות יום אחד מוקדם מדי?

שמועה נוספת היא השמועה, שוב, ש Cisco רוצה לרכוש את Nutanix. נראה לי ששוב מדובר על שמועה שנועדה סתם למלא מילים בבלוגים והיא מתבססת על פוסט מתחילת השנה שמקשר את הרכישה של HPE את Simplivity לרצון של Cisco לרכוש את Nutanix לפני שנתיים. הדבר היחיד שמעניין כאן זה המספר הנמוך יחסית שמיוחס לשווי הרכישה. לפני שנתיים דיברו על כך שCisco הציעו 4 מיליארד דולר עבור רכישת נוטניקס ואילו עכשיו, אולי לאור הרכישה הנמוכה יחסית של Simplivity וגם של Nimble המספרים יורדים לשכונה של מיליארד יחיד, עדיין מספרי unicorn אבל כבר לא עדר אלא חד קרן יחיד, קצת עייף.

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

שלכם,

ניר מליק

קהילה,vRNI, Hyper-Flex, פיניקס ולימון כבוש

חיי קהילה  – אני ממשיך ללחוץ עליכם

בפוסט הקודם המלצתי לכולכם לחלוק את הידע שלכם עם הקהילה.

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

eli-florental

השבוע גיליתי גם שידידי היקר, נתנאל בן שושן, מנהל תחום מיקרוסופט אצלנו בחברת We Ankor הוא אחד מתשעת החברים המכובדים בקהילה המיוחדת של VMware vExpert בישראל. זה אומר שגם הוא ממשיך את המסורת שהתחיל כ Microsoft MVP ומשקיע זמן ואנרגיה כדי לחלוק את הידע הרב שצבר עם קהילת ה IT שסביבנו.

VMware vRNI

נתנאל ואני השתתפנו בכנס שערכנו השבוע עבור אחד הלקוחות הגדולים שלנו, נתנאל דיבר על החידושים ב vSphere 6.5 ואני דיברתי על השימושים הנפוצים לפתרון VMware NSX.

באותו אירוע דיבר גם אבי יושי, מהנדס מערכות בכיר ב VMware ישראל, שהציג את פתרון ה VMware vRNI או בשמו המלא, vRealize Network Insight. כלי מאד חזק לוויזואליזציה של התעבורה בחדר השרתים. אחד האתגרים הנפוצים בבניית סט חוקי אבטחת מידע בסביבות מורכבות הוא מיפוי ומעקב אחר הגורמים השונים, לאיזה שרת מותר לתקשר עם איזה בסיס נתונים, איזה שירות Web מנסה להגיע אל איזה כרטיס רשת וכדומה. ככל שהסביבה גדולה ומורכבת יותר כך האתגר הזה מורכב יותר. תשתיות וירטואליזציה ותשתיות Software Defined מוסיפות נדבך של מורכבות כי חלק מהתעבורה ולפעמים חלק ניכר מהתעבורה כלל לא מגיע אל חומות האש הארגוניות או מתגי ה Layer 3 שלנו ולכן התעבורה אינה גלויה לתהליכי NetFlow.

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

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

vrni-vrealize-network-insight-application-connectivity

בתצלום הזה אנו רואים מיפוי של שירות web ספציפי לניתוח סוגי התעבורה השונים שלו

Microsegmentation-analysis.png

היום אירוע שני אירועי התפרצות לבתים במושב בו אני גר ובדיון בקבוצת הווטסאפ שלנו הזכירו כי "קו המגע לעולם ייפרץ". אחד הקוים המנחים ביישום מיקרו-סגמנטציה, ה use case הכי נפוץ של NSX, הוא שבתצורה זו קל יותר לגלות פריצה ולהכיל אותה משהתרחשה. ללא מיקרו-סגמנטציה, בעולם של VLAN'ים גדולים, מרגע שנפרץ משאב אחד, התנועה האופקית בתוך שכבת האבטחה שלו קלה יחסית ולפעמים גם נשארת חבויה ולכן השילוב של שני הכלים, vRNI+NSX יכול לייצר פתרון אבטחת מידע מאד אפקטיבי.

Cisco Hyper-Flex

בנושא אחר, יצא לי לשחק לאחרונה קצת עם פתרון ה Hype-Flex של Cisco. פתרונות ה hyper-Converged  הם נושא מאד חם בתקופה האחרונה ובטח יצא לכם לשמוע על הרכישה המשמעותית של HPE את SimpliVity.

הפתרון מבוסס שרתי Cisco בתצורת Rack ככה שכבר אנחנו יודעים שמבחינת החומרה אנחנו מקבלים פתרון מאד איכותי. כל השרתים מקושרים ל Cisco UCS FI סטנדרטי אז אין עקומת לימוד גדולה מדי לניהול תשתית החומרה וכשאני אני מתכוון שאין עקומת לימוד גדולה מדי אני מתכוון שגם ככה ממשק הניהול של UCS  הוא ממשק מעולה ונוח לשימוש. אגב, היות ומדובר באותו FI, ניתן לנהל גם סביבת Hyper-Flex וגם סביבת UCS רגילה באמצעות אותם מתגי ניהול, זה די נוח ללקוחות קיימים וכן מאפשר את הגמישות לקשר אל ה Hyper-Flex Cluster גם שרתי Compute בלבד מתוך מערך ה UCS Blade או שרתי UCS Rack אחרים המקושרים אל ה FI. אין צורך ברישוי Hyper-Flex עבור שרתי Compute only.

הקלאסטר כולל מינימום של 3 שרתים ועל כל שרת מותקן Storage Controller האחראי לכלל פעילות ה IO מול הדיסקים המקומיים בשרתים. מערכת ה"אחסון" משתמש בטופולוגית log structured שמאפשרת כתיבה ל buffer, ביצוע inline dedup/compression והורדה סיקוונסיאלית של המידע הנכתב אל הדיסקים. יכולות אלו משמעותיות מבחינת ביצועים בתצורות היברידיות ומבחינת flash cell wear leveling בתצורות all flash. תהליך ה stripe מתבצע על כלל הדיסקים המוקצים לקלאסטר על מנת לרתום את כל הספינדלים לתהליכי ה IOps. כלל ה Storage controllers נגישים לפעילות IOps ב pNFS לשרתי ה Compute כדי לא ליצור צוואר בקבוק בגישה אל המידע. תהליכי ה Snap Shot הם תהליכי redirect on write זריזים ויעילים כמקובל בימינו.

מתגי ה FI הם כאמור מתגי FI סטנדרטיים. היות וניתן לקשר אל מתגי FI מערכי אחסון ניתן במידת הצורך לחשוף לשרתים הוירטואליים החיים על ה Hyper-Flex גם LUN  ממערכת אחסון חיצוני. לא יודע אם זו תהיה תצורה נפוצה אבל נחמד שיש את הגמישות לעשות את זה הרי זו אחת נקודות הביקורת נגד פתרונות HCI, העובדה שחלקם מאד גמישים רק כל עוד נשארים בתוך מסגרת פתרון ה HCI.

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

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

hyperflex

The Phoenix Project

בפוסט הקודם דיברתי גם על the phoenix project והבטחתי לחזור ולהתייחס אליו. אז מה למדתי?

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

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

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

דבר נוסף שביל אנחנו לומדים בתהליך הוא השליטה בכמות העבודה, איך מחליטים איזו עבודה אנחנו מוכנים לקבל על עצמנו? שוב במתודה שביל לומד מניהול רצפות הייצור, אם מקבלים את כל העבודות שזורקים לכיוון רצפת הייצור ומקבלים אותן ללא סינון או סידור, תורי העבודה מתארכים, אין דרך יעילה לאזן את המשאבים (חומרי הגלם, המכונות, העובדים, אותו תנור קריטי שהזכרתי) ולכן כל העבודות, כל המשימות כולן מתעכבות, ככל שעומס העבודה יגבר כך למעשה יגברו רק האיחורים התיקונים והמשימות שיש לבצע שוב מחדש כי לא בוצעו כראוי בפעם הראשונה. אריק מספר כאן לביל על תיאוריות ייצור כמו lean, TQM ועל the theory of constraints ומראה שאם יש משאב קריטי שמנוצל במאה אחוז, למעשה הוא לא ממש יעיל כי הוא לא מסוגל לקבל שום עבודה חדשה, ככל שיש לנו יותר משימות פתוחות או יותר work-in-progress כך יתארך הזמן הנדרש להשלים כל משימה, להשלים כל WIP. באחד הפרקים בספר, שוב מגלים שיש עיקוב מאד גדול בפרויקט הכי חשוב של החברה, פרויקט פיניקס. תחקיר קצר מעלה שברנט אמר על משימה שקיבל שהיא תיקח רק 45 דקות אבל בפועל לקח לו מעל שבוע להשלים אותה. לאחר כמה ימים ארוכים של המתנה ברנט התפנה לאותה משימה שאכן לקחה בערך 45 דקות לביצוע. זמן העבודה בפועל לקח 45 דקות אבל משך הזמן המלאה לביצוע המשימה צריך לכלול את זמן ההמתנה להתפנות המשאב כלומר, שבוע + 45 דקות.

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

לימון כבוש

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

שוטפים היטב את הלימונים – עבור צנצנת בגודל כמו של צנצנת נס-קפה נדרשים כשישה לימונים יפים

חוצים את הלימונים לאורך ואז פורסים לרוחב לפרוסות.

lemon-knife

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

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

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

lemon-small

שומרים מחוץ למקרר שלושה ימים ואוכלים בתיאבון. מה שלא נאכל מיד נשמר במקרר לתקופה מאד ארוכה.

lemon-finished

כמו תמיד אשמח לשמוע מה דעתכם, אל תהססו!

שלכם,

ניר מליק

VMware VMworld 2016 roundup

ואוו איזה שפע, מאיפה מתחילים?

בשבוע שעבר התקיים VMworld Barcelona ובניגוד לשנים קודמות, האירוע של EMEA  לא היה רק שידור חוזר של האירוע האמריקאי אלא כלל שפע של הכרזות ולקראתו הוכרז גם שיתוף הפעולה האסטרטגי בין VMware לספקית מחשוב הענן הגדולה בעולם, Amazon (כולל היכולת למתוח את רשת התקשורת אל הענן הציבורי באמצעות NSX!)

זו מגמה חיובית ומעניינת בעיניי וכפי שכתבתי בעבר זה נראה לי כמו טרנד שהולך להתרחב.

אז צוללים קדימה:

VSAN

שני חידושים משמעותיים בגרסה 6.5 של מוצר SDS זה:

Virtual SAN iSCSI Service – אחד החסמים העיקריים לשימוש בפתרונות HCI הוא החשש מפני "גן סגור" היות ופתרונות אלו נוטים לשרת רק את עצמם. שירות ה iSCSI החדש של VSAN מאפשר לספק שירות Block storage גם לשרתים שאינם חלק מסביבת ה VMware עליה פעיל שירות ה VSAN ובכך נפרצת חומת הגן. מנגנון הניהול הינו אותו מנגנון ניהול ומבחינתו פשוט נוצר אובייקט חדש שמוצג החוצה ב LUN + iSCSI Target.

2-node direct connect – כבר בגרסה קודמת הוכרזה תמיכה בכמות מינימאלית של 2 שרתים בסביבת VSAN ועכשיו תצורה זו נתמכת גם בקישור 10Gb ישיר בין שרתי ה Host. תצורה זו מורידה עוד יותר את סף הכניסה וחוסכת בעלויות הפתרון המינימאלי הנתמך.

מבחינת רישוי, פתרון All Flash VSAN נתמך גם בגרסת רישוי Standard כך שמי שצריך ביצועים גבוהים אך לא חייב פיצ'רים מתקדמים יכול להסתפק ברישוי הפשוט יותר, שוב, סף כניסה נמוך יותר. נראה ש VMware עושה הרבה מאמץ להפוך את המוצר ל commodity.

vSphere 6.5 והתשתית שמתחת

VMFS 6.5 – תמיכה ב auto space reclamation – יכולת חדשה הנשענת על VAAI הישן והטוב וספציפית על VAAI UNMAP – בלוקים פנויים משוחררים עכשיו באופן אוטומטי למערך האחסון לשימוש על ידי volume אחרים

HA high availability – גרסה זו כוללת שיפורים משמעותיים בניהול ההתאוששות – ראשית, שיפור ביכולת לתעדף את סדר עליית שרתים הוירטואליים במקרה של HA ועכשיו ניתן לגם לסמן ששרתים בעדיפות נמוכה ימתינו לקבל hart beat מהשרתים שכבר עלו בעדיפות ראשונה או אפילו ימתינו לקבל hart beat מאפליקציה ספציפית.  יכולת זו מורחבת עוד יותר על ידי יכולת אורקסטרציה מובנית לתהליכי HA שם אנחנו יכולים לסמן קבוצות שתרים כתלויות אחת של השניה, אם שרתי אפליקציה תלויים בשרתי DB אז ניתן לקשור אותם ספציפית אחד לשני.

אחד החידושים היותר חשובים בתוך HA לדעתי הוא ProActive HA, חידוש זה מאפשר לקבוע פרמטרים לפיהם מכונות יבצעו fial over אוטומטי במקרה של ירידה ביציבות או צפי לפגיעה ביציבות. דאנקן אפינג מפרט על זה קצת יותר והוא מדבר על זה שזה נראה כמו רכיב DRS יותר מאשר רכיב HA אבל כך או כל זו יכולת מעניינת.

DRS – חידוש אחד ב DRS  הוא יכולת לניהול משאבי רשת בנוסף למשאבי Host ומשאבי אחסון. DRS דוגם גם את רכיבי הרשת, כולל הפורטים הפיזיים, כדי לוודא שהשרתים הוירטואליים מקבלים את המשאבים הנדרשים.

חידושים ב VVoL – זוכרים את הפיצ'ר החדש והכי מגניב בעיני? אז גם בו יש חידושים והחידוש העיקרי הוא תמיכה מלאה ברפליקציה כלומר תמיכה ברפליקציה מבוססת מערכי האחסון כולל יכולת יצירת קבוצות רפליקציה להגנה על סביבות או מערכות ולא רק על שרתים בודדים או כמו בעבר, volume המכיל כל מני שרתים. כמובן שצריך תמיכה רשמית מצד יצרנית מערכת האחסון וצריך לשדרג ל VASA בגרסה העדכנית אבל, היי, זה מתחיל להיות מעניין.

קצת הרחבה על השת"פ עם AWS – ראשית, לדעתי, המשמעות היא ש VMware ויתרה בפועל על להיות ספקית ענן בעצמה. זה בסדר, מדובר בשוק קשה ותחרותי והרווחיות שלו תלך ותקטן. שנית, המרוויחה הגדולה כאן היא AWS כי בפועל לקוחות השת"פ בעצם ינדדו אל תוך מעמקי השירותים השונים של AWS גם אם הם יתחילו על "ענן פרטי מנוהל". לקוחות יתחילו עם שירות VMware על החומרה היעודית של AWS, יראו שזה טוב, ירימו שירות אנליטיקה, או איזון עומסים או כל מני רכיבים שמשתלבים לתוך הפתרונות שלהם ויום אחד ימצאו עצמם פשוט רצים על AWS במקום על VMware. זה דיון מעניין כי בעצם אל יהיו גם לקוחות שפתאום יגלו כמה באמת עולה שירות הענן וכל נושא ה ROI יחזור לשחק תפקיד. הרבה פעמים צריך להזכיר ללקוחות שה ROI הוא רק אחד הפרמטרים במעבר אל או מהענן, העלות היא לא תמיד אטרקטיבית אבל אפשר לעשות דברים שקשה לעשות ב ON-prem.

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

אשמח לשמוע מה דעתכם, תרגישו חופשי.

שלכם,

ניר מליק

סקירה קצרה ולא מחייבת של הסשנים המעניינים בעיניי בכנס NetApp Insight 2016 ברלין

סקירה קצרה ולא מחייבת של הסשנים המעניינים בעיניי בכנס NetApp Insight 2016 ברלין

לכל מי שמתרגש כמוני לקראת NetApp Insight Berlin, פוסט זה יכלול תיאור לא סופי ולא מחייב של כמה מהסשנים המעניינים מבחינתי,

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

ביום הראשון לכנס אני מתרכז בשתי הדרכות מעשיות, הראשונה, 60719-3-TT, סוקרת את כלי הסייזינג של מערכות ה E-Series, בדגש על יכולת שהיתה חסרה לי עד עכשיו, היכולת לתכנן באופן מסודר מערכות בעלות יותר מסוג אחד של workload ובהתאמה יותר מסוג אחד של דיסקים. יכולת היברידית היא יכולת מובנית במערכות אלו כבר מזמן אבל כלי הסייזינג לא ידע לייצג יכולת זו.

ההדרכה השניה, 51231-2, מתמקדת בכלי המיגרציה השונים הקיימים במערכות על מנת לפשט את המעבר אל מערכות NetApp FAS בדגש מבחינתי על יכולת ה FLI או foreign LUN import.

היום השני מוקדש מבחינתי ליישום בפועל של NetApp Data Fabric. פרט לסשן אחד שמוקדש ליכולת ניתוח צווארי בקבוק במערכות , 60762-3-TT, שאר הסשנים מוקדים בפועל ל data fabric. הסשן הראשון בנושא, 95166-1, נקרא the evolution of the data fabric וסוקר במעוף הציפור את כלל הפתרונות הרלוונטיים בתוך מארג המידע של NetApp. הסשן השני, 84551-2, בהובלת ירון חיימסון מצוות הפיתוח של NetApp כאן בישראל, מתרכז בהדגמה בפועל של יכולת פתרונות הענן של NetApp כולל ONTAP Cloud, יכולות אוטומציה של תהליכים באמצעות כלים של NetApp בענן ותצורות ענן היברידי הלכה למעשה.

אחרי הצהרים יתקיים סשן אחד מאד מיוחד מבחינתי, 95160-1 הוא סשן מסוג inform and delight כלומר, סשן קצר וממוקד שאמור לתת טעימה של משהוא אחר, משהו עם טוויסט, ואכן סשן ספציפי זה הוא סשן של שני המייסדים, שני הדייב'ים, דייב היץ מייסד NetApp ודייב וורייט מייסד Solid Fire, והנושא הוא the future of storage. איך אפשר לפספס הזדמנות להיות עם שניהם באותו חדר ולשמוע מהם באופן ישיר לגבי התפיסה שלהם את עתיד התעשייה שלנו? את היום הזה אני מסיים בסשן 61538-2 במתרכז באחד היישומים הפשוטים והאהובים עלי ליישום תפיסת ה data fabric  והוא NetApp FAS Flex Array על גבי מערכות E-Series בדגש על ארכיטקטורה למערכות עתירות ביצועים.

הסשן הכי חשוב מבחינתי ביום השלישי הוא סשן 60713-3. סשן זה הוא סשן הסוקר את פתרונות S3 ופתרונות Swift. פתרונות גיבוי לענן כדוגמאת AltaVault, פתרונות ענן פרטי כמו open stack ופתרונות tier לענן כדוגמאת fabric pool מחייבים כולם הבנה של פרוטוקולים אלו.

היום האחרון של הכנס הוא יום קצת מעורבב מבחינתי כי הוא משלב גם סשנים המוקדשים לתחרות ומכירות וגם סשנים טכניים, הסשן הכי מעניין מבחינתי הוא 46735-2, Ceph on NetApp E-Series והוא הכי מעניין מבחינתי כי למעשה זה הנושא שאני יודע עליו הכי מעט מבין כל הסשנים המוצגים השנה. הסשן הכי חשוב מבחינתי הוא 60749-3 VMware and VVOL integration with NetApp SolidFire, משולבים כאן שלושה דברים מאד מאד חשובים מבחינתי, אחד הוא הצגה של פתרון VMware VVoL שלהערכתי יתפוס תאוצה בעתיד הקרוב בעיקר לאור דגש והכרזות גם של יצרנים אחרים לתמיכה מסודרת בפתרון זה (כמו HDS או Nimble), שני הוא מבט נוסף לתוך SolidFire, לדעתי אחד הפתרונות הכי סקסיים בעולם האחסון היום, ושלישי הוא הזדמנות לצפות Live בג'וש אטוול ביחד עם אנדי בנטה. חוויה. מקווה שיחלקו גרביים.

socks

זהו, שבוע עמוס, כמובן שלא הזכרתי את אירועי ה general assembly, אירועים לשותפים בלבד, המסיבה השנתית שתהיה השנה בנושא חורף קסום או משהו כזה וכמובן, הרבה הרבה בירה.

שלכם, בברכת #nextstopinsight

ניר מליק

VVOL – לצרוך שירותים ממערך אחסון מרכזי במודל של SDS

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

עם ההשקה של VMware vSphere 6 הוכרזה התמיכה הרשמית בטכנולוגיה חדשה בשם Virtual Volumes או בקיצור VVOLs. טכנולוגיה זו נתפשת בעיני כשלב ביניים מעניין באבולוציה. היא מאפשרת לנו להמשיך ולצרוך שירותים ממערך אחסון חיצוני ולהנות מכלל יכולותיו וחוזקותיו אך מפשטת ומפשיטה את השימוש והצריכה עבור שרתים וירטואליים בסביבות VMware vSphere כך שמנהל תשתית הוירטואליזציה מקבל את התחושה של SDS, הוא מקצה מה שהוא צריך להקצות דרך ממשק הניהול הרגיל שלו, vCenter, ואין לו צורך לדעת איזה מערך אחסון משרת אותו, כמה מערכי אחסון יש בסביבה וכו'.

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

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

VASA Provider

מערכי אחסון מודרניים מספקים מגוון רחב של שירותים. מנהל מערך האחסון מגדיר ומפעיל את השירותים בהתאם למה שהמערך מספק, צרכי הארגון, best practice של יצרן המערך וכו'. תפקידו של ה VASA Provider לשמש "שדכן" בין מערך האחסון וממשק ניהול תשתית הוירטואליזציה, vCenter. ה VASA Provider, VP, מציג ל vCenter את היכולות השונות הקיימות במערך האחסון. כאשר מקימים שרת וירטואלי חדש, בוחרים דרך ממשק ה vCenter את יכולות האחסון הנדרשות עבור השרת החדש ובאמצעות ההתממשקות אל ה VASA Provider ומערך האחסון תחתיו, מוקמים באופן אוטומטי ה virtual volumes הנחוצים עבור אותו שרת במקום הנכון על מנת לספק את השירותים שנבחרו. זו למעשה התורה על רגל אחת, מנהל מערך האחסון מפרסם את כל היכולות שיש לו לספק ומנהל תשתית הוריטאליזציה צורך אותן בהתאם לשרתים הוירטואליים השונים, מערך האחסון הופך "מודע" לכל שרת וירטואלי ולמעשה לכל דיסק ודיסק של כל אחד מהשרתים הוירטואליים, הרזולוציה המסופקת משתפרת מאד שכן עד עכשיו, עד השימוש ב VVOLs, מרבית מערכי האחסון לא היו מודעים כלל לשרתים הוירטואליים המקושרים אליהם וכלל השירותים סופקו ברזולוציה של LUN או Volume שאחסנו DATA Stores רבים ובתוכם שרתים וירטואליים רבים.

בחלק מהמקומות מתיחסים אל VASA Provider כ Vendor Provider ובכך מודגשת אחריות יצרן מערך האחסון, הוא כאמור אחראי לפרשנות שלו ליישום נכון של VVOLs ובהתאם הוא אחראי לאופן יישום ה VP והיכולות שהוא מספק.

Protocol Endpoint

בשימוש ב LUN  או NFS export לאחסון DATA Store, שרתי ה ESXi Host  היו מקושרים אל ה LUN או ה Export השונים במערך האחסון ובסביבות גדולות היה צריך למפות או לקשר את כולם, עובדה שיצרה כאב ראש ניהולי וכן, בסביבות מורכבות, יצרה מגבלות, למשל של כמות ה LUN המורשים בסביבה וכו'. בשימוש ב VVOLs קיימת ישות חדשה בשם Protocol Endpoint. ה PE הוא LUN יחודי בעולם ה SAN או mount point בעולם ה NFS. ה PE הוא נקודת ההשקה בין התשתית הוירטלאית למערך האחסון, כלל פעולות ה IO מבוצעות דרך ה PE. בעת הקמה של VVOL חדש, ה VVOL אינו נגיש לפעילות IO בעצמו, ה VASA Provider אחראי לביצוע "הצמדה" או Bind של VVOL אל PE.

VVOLs

VMware מפרטת 5 סוגים שונים של VVOL:

Config-VVOL כשמו כן הוא מכיל מידע על הקונפיגורציה של השרת הוירטואלי, VMX, Log וכו'. יש רק אחד כזה לכל שרת וירטואלי

DATA-VVOL – מקביל למעשה ל VMDK. לכל שרת וירטואלי יכולים להיות יותר מאחד, בהתאם לכמות הדיסקים הלוגיים שניצור לשרת

Memory-VVOL – נוצר עבור memory snap shots

Swap-VVOL – נוצר כאשר מדליקים את השרת הוירטואלי בהתאם לצורך בלבד

Other-VVOL – נתון לפרשנות של יצרן מערך האחסון ולמיטב ידיעתי עדיין לא בשימוש על ידי אף יצרן

5vvol

Storage Container

ישות זו הינה ישות לוגית המשמשת בעיקר להפרדה וניהול מצד מערך האחסון, היא המגדירה מגבלות נפח ולמעשה מחליפה את ה DATA store המוכר

סיכום

צריך לזכור כי קיימות מספר מגבלות ולכן הטכנולוגיה עוד לא מתאימה לכל אחד. VVOLs אינו "מוצר" של VMware ואין לו מק"ט, מדובר בטכנולוגיה וטופולוגיה המיושמות באופן שונה בין יצרני האחסון השונים. קיימת מגבלה בהתממשקות ליכולות vSphere  שונות כמו fault tolerance, התממשקות למוצרי VMware כמו NSX או תמיכה בסביבות IPv6, תצורות RDM וכו'.

למי שמתעניין במידע נוסף, להלן קישורים לפודקאסט שאני מאד אוהב, Virtually Speaking. כמובן ש Pete Fletcha הוא איש NetApp לשעבר ומשם אני מכיר אותו!

https://blogs.vmware.com/virtualblocks/2016/06/03/virtually-speaking-podcast-episode-14-solidfire-vvols-done-right/

https://blogs.vmware.com/virtualblocks/2016/09/15/vasa-provider-dr-ontap-vp-6-2/

מי שיחטט שם ימצא גם סקירה של אופן יישום VVOLs על ידי יצרנים אחרים אבל הי, אני אוהב את NetApp 🙂

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

שלכם,

ניר מליק

מחשבות בנושא NSX

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

עשור לאחר השירות הסדיר שלי, בערך, קיבלתי את תפקיד איש הפריסייל הראשון שלי בחברת "אינטרנט זהב" שלימים התאחדה עם "קווי זהב" שלימים התאחדה עם "פרטנר". אותם ימים נדמו לי כימים של פריחה בתחום אבטחת המידע, חברות רבות עדיין פעלו כמעט ללא כל אמצעי אבטחת מידע וחלק מהשיחות שלנו עם לקוחות עדיין עסקו בשאלה אם בכלל צריך להתקין חומת אש בארגון, האם יש צורך להשקיע בהתקנת תוכנת אנטי-וירוס טובה ועוד כל מני דיוני בסיס כאלו. מכרנו מאות יחידות חומרה של checkpoint ולצד זאת ביצענו גם לא מעט הטמעות של מוצרים יחודיים יותר כמוצרי One Time Password OTP, מוצרי NAC ופה ושם אפילו דיברנו על חומות אש אפליקטיביות, WAF, למרות שעבור מרבית הלקוחות הישראלים באותה תקופה היו מוצרים אלו יקרים מדי. מרבית הלקוחות הרלוונטיים, לקוחות ה Web,  הבינו את החשיבות של כלים אלו אבל גם עבורם לפעמים העלות הכספית היתה גבוהה ממה שנראה היה להם מוצדק לשלם.

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

עבר עוד עשור מאז, וירטואליזציה של שרתים היא כבר הסטנדרט בתעשייה ומרבית השרתים בעולם הם שרתים וירטואליים, וירטואליזציה של מערכות אחסון אינה חידוש אמיתי ואפילו וירטואליזציה של רשתות תקשורת היא מושג מאד ותיק לכל מי שמכיר רשתות Multi-Protocol Label Switching MPLS או Virtual Route Forwarding VRF. גם בתחום אבטחת המידע חלו שינויים מרחיקי לכת. ראשית, כמו שמפקד פלוגת מפקדה הוא היום מפקד הפלוגה הטכנו-לוגיסטית, גם תחום אבטחת המידע שינה לעצמו את השם לתחום ה"סייבר". שנית, באופן קצת יותר מהותי, גם תעשיית ה IT הפנימה ש"קו המגע לעולם יפרץ". אם בעבר חומת אש בנקודת הכניסה לרשת ותוכנת אנטי-וירוס על השרתים ותחנות הקצה היו מערך אבטחת המידע כולו, היום ברור כי מערך אבטחת המידע חייב להיות מערך רב שכבתי הכולל כלי בקרה וניטור, כלי תגובה וכלי ניתוח ושכמו תמיד, עדיין ולמרות הכל, מתקפות רבות מתרחשות בתוך ומתוך הארגון ובתוך הסביבה קשה כיום לראות ולהכיל אותן.

כחלק מהאבולוציה בעולם אבטחת המידע, מתפשטת התפיסה הנקראת Trust No One לפיה אין יותר חלוקה של הרשת הארגונית לאזורים בטוחים או מבודדים. כל שרת, מכונה ומשתמש הם סכנה פוטנציאלית ברשת, גם לאחר הזדהות בכניסה ועמידה בתנאי הסף לשימוש ברשת כמו עדכניות תוכנות ההגנה וכו'. על מנת ליישם תפיסה זו בפועל, יש צורך בעדכון טופולוגית הרשת שכן, עד היום, מרבית כלי השליטה והניתוח היו עיוורים לנעשה בתוך התת-הרשת, בתוך ה VLAN. מרבית כלי הניתוח והשליטה פעלו במעבר בין תת הרשתות, רק כאשר שרת פונה אל שרת ברשת אחרת התעבורה נבדקת בחומת האש או מתג הליבה.

פתרון NSX של חברת VMware (באמצעות רכישה של חברת Nicira) הינו פתרון וירטואליזציה של רשתות תקשורת. הפתרון עושה שימוש בטכנולוגית  vCloud Networking and Security vCNS ו"רוכב" על virtual distributed switch. באמצעות NSX, כל שרת פיזי, Host, כולל באופן מובנה בתוך תשתית הווירטואליזציה, Hyper-Visor, גם מתג Layer-2, נתב Layer-3, חומת אש וכלי איזון עומסים Load Balancer. כתבתי למעלה שווירטואליזציה של רשתות תקשורת היא לא רעיון חדש והיא לא אבל היישום של NSX, ש"עולה" רמה אל תוך תשתית הווירטואליזציה הוא חידוש מאד משמעותי. כלל האכיפה והבקרה מתבצעות בצמוד לכל שרת וירטואלי, אין צורך במעבר של Session כל הדרך אל כרטיס הרשת הפיזי של השרת המארח, דרך המתגים ועד לחומת האש לביצוע אכיפה.

הפתרון מאפשר למעשה ליצור תת רשת לכל שרת וירטואלי ולכל שרת וירטואלי סט הגדרות המוצמדות אליו ועוברות איתו בין שרתים מארחים ואפילו בין סביבות כולל במעבר לDatacenter אחר, במידה וגם בו מוטמע NSX כמובן. תצורה זו נקראת בשם Micro-Segmentation היות ויחידת הבקרה שלנו משתנה, מישור הייחוס שלנו אינו עוד VLAN אלא פנים ה VLAN, אנו מודעים עכשיו גם לנעשה בין שני שרתים וירטואליים ה"מדברים" ביניהם על גבי אותו שרת מארח, בלי אפילו לצאת למתג החיצוני, "שיחה" שבעבר היתה בדרך כלל חומק מהרדאר נאכפת ומנוטרת במלואה כיום.

eastwest

כפי שניתן לראות בתמונה מעלה, בעבר, גם שני שרתים וירטואליים על אותו שרת מארח היו צריכים לפנות אל חומת האש ולעבור 6 תחנות בדרך, hope, ואילו שימוש ב NSX מאפשר תקשורת ישירה ללא כל Hope ללא ויתור על סט החוקים המנוהל על ידי חומת האש הארגונית.

פתרון NSX הוא לא אי בודד בים ולא מוצר אבטחת מידע עצמאי אלא פתרון תשתית המאפשר eco-system שלם, שיתוף הפעולה בין VMware ויצרני אבטחת המידע והתקשורת המובילים בעולם מאפשר התממשקות בין תשתית ה NSX  למוצרי Palo-Alto, Checkpoint, F5 ואחרים כך שכל ארגון המטמיע פתרון NSX יכול להמשיך ולבחור את הכלים הטובים ביותר בעיניו בשיטת Best of Breed. אם למשל ארגון בוחר להטמיע חומת אש של חברת Palo-Alto, כלל בסיס החוקים והחכמה מנוהל על ידי חומת האש אך האכיפה בפועל מתבצעת על ידי NSX. תוצר נוסף של יישום פתרון בצורה זו הוא חסכון משמעותי בתעבורה בתוך חדר השרתים ועומס מופחת על חומת האש עצמה.

nsxecosystem

מעבר ליכולות אבטחת מידע, הזכרתי גם את נושא המיתוג והניתוב. על ידי שימוש ב virtual distributed switch עם יכולות Layer-2 ו layer-3, מאפשרת תשתית ה NSX גמישות ודינאמיות רבה בהגדרת רשתות התקשורת. למעשה, אנו יכולים להגדיר את רשת התקשורת בתוך חדר השרתים כרשת שטוחה ברמה הנמוכה, רמת המתגים, וכלל הגדרות הסגמנטציה של הרשת מתבצעות ברמה הגבוהה, רמת תשתית הווירטואליזציה hyper-Visor. גם במעבר בין רשתות וטווחי כתובות NSX יוצר את סט החוקים באופן יחידני, Ad-Hoc, על מנת לאפשר תעבורה במידה והיא מורשית על ידי סט החוקים.

פתרון NSX הוא יישום מרשים ויעיל לרעיון קיים. וירטואליזציה של רשתות תקשורת היא לא רעיון חדש אבל היישום הזה מאד מרשים, היכולת להקים ולהוריד מאות סביבות ולרבב סביבה אחת בתוך סביבה שניה רלוונטית לחתכי לקוחות מסויימים, ספקי שירות או סביבות מעבדה גדולות למשל. גם לקוחות המקימים ומעדכנים באופן תדיר סביבות לימוד והדרכה יכולים להנות מהפרדת רשתות והקמה של סביבות בלחיצת כפתור, בשילוב עם פתרון vRealize Automation. היכולת לבצע הפרדה מלאה של סביבות, micro segmentation או guest isolation היא יכולת שרלוונטית לכל לקוח שמבין שמתקפות יכולות לבוא גם מתוך הסביבה ולהתפשט בתוך מה שעד היום היה נחשב, בטעות, כאזור מוגן ומאובטח. קו המגע לעולם יפרץ.

השרטוט מטה מראה את ההבדלים ברישוי בין הגרסאות, הדגשתי באדום את החלק הכי חשוב לדעתי. לא משנה איזו רמת רישוי נרכוש, היא תכלול את יכולת Distributed switching and routing שהיתה עד היום כלול רק ברישוי vSphere ברמות רישוי גבוהות ויקרות ולכן יכולת זו היתה חסם עיקרי לאימוץ פתרון NSX על ידי לקוחות בעלי סביבות פשוטות, קטנות או אילוצי תקציב אגרסיביים. פתרון NSX מתקרב בעדכון רישוי זה לחתך מאד רחב של לקוחות שעד היום נאלצו לוותר למרות הבנה של הצורך

nsxlic

שימוש נוסף ומאד מעניין לפתרון NSX הוא בעולם של שרידות מרובת אתרים. חברות רבות מציעות מערכות אחסון בתצורת active/active geo-cluster. נציין את NetApp Metro-Cluster או IBM SVC כדוגמא. פתרונות אלו מאפשרים ללקוחות להקים תשתית אחסון שרידה בין שני אתרים פיזיים ופתרון NSX מפשט את הקמת תשתית השרתים שמעל למערכות אחסון אלו. אם בעבר היתה חובה להקים תשתית layer-2 על מנת לשמר את טווח כתובות ה IP של השרתים בדילוג בין חדרי השרתים, כיום ניתן באמצעות NSX ל"ייצר" תשתית Layer-2 מעל תשתית Layer-3 כמעט ללא הכנה מוקדמת ובכך לפשט מעבר שרתים בין האתרים באופן חלקי או מלא.שרת וירטואלי "לוקח איתו" את סט החוקים וההגדרות שלו והתשתית תספק לו את כלל הקישוריות הנדרשת. כמובן שהפתרון נתמך באופן מלא על ידי פתרון הניהול Site Recovery manager SRM על מנת לבצע בלחיצת כפתור את תהליך המעבר בין האתרים אך התהליך פשוט מאי פעם.

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

 

שלכם,

ניר מליק