מחבר maliknir

קהילה,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

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

שלכם,

ניר מליק

sharing is caring and the phoenix project

Sharing is caring – למה אתם לא חולקים את הידע שלכם?

השבוע היה שבוע בסימן נוכחות ברשת ופעילות ברשתות החברתיות,

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

באותו היום ממש שאל חבר שלי, אמיר כוכבי, שכתב עד לא מזמן את הבלוג "זבובונים באישונים", אם אנשים עוד כותבים בלוגים בימינו

kochavi-blog

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

והשני הוקדש למאמר של קאל ניופורט שפורסם לאחרונה בניו-יורק טיימס ונקרא quit social media, your career may depend on it. ניופורט בתורו מתייחס למאמר של אנדרו סאליבן I used to be a human being שבו סאליבן מתייחס להפגזה התמידית שהאדם המודרני סופג, הפגזה של מידע, דעות, שנינויות וסרטוני חתולים, כולם מוערבבים אחד בשני ללא סינון, אימות או תיעדוף.

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

מה דעתכם, אני צריך להקים גם פודקאסט? מישהו יקשיב לי מברבר שעה פעם בשבוע-שבועיים? אולי אתם צריכים להקים פודקאסט? או לפתוח בלוג? או סתם להיות יותר פעילים ולתרום מידע אחד לשני? יש עוד מקומות שאני צריך לדעת עליהם בהם יש מישהו שחולק מידע עדכני ומסודר בעברית על עולם ה IT?

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

The phoenix project – קריאה מומלצת לכל מנהל, קריאת חובה לכל מנהל בעולם ה IT

בחודשים האחרונים שמעתי הרבה על הספר the phoenix project. נתקלתי בהרבה מאד ציוצים ופוסטים שמזכירים את הספר כולל למשל גלן דקהייזר שדיבר על הספר לא מעט ב Insight Berlin האחרון במהלך הקלטת הפודקאסט tech ONTAP על הבמה במהלך הכנס

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

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

הספר עצמו מתאר באופן סיפורי את כניסתו של ביל לתפקיד VP of IT operations בארגון גדול. האבולוציה שביל והארגון שלו חייבים לעבור באופן מאד מהיר כדי לשרוד את קצב השינויים האדיר בעולם המחשוב שלנו מאד מעניינת ולכל אחד מאיתנו יש מה ללמוד מהעקרונות שהספר מתאר. זהו ספר עלילתי ולא עוד ספר הדרכת מנהלים משעמם, יש בו דמויות, עלילה, אקשן, תחכים (תחכי IT אמנם ולא 007 אבל בכל אופן תחכים), הוא נקרא בכייף ולא עוד text book משעמם ויומרני. לכל מי שמחפש את ה Buzz word המתאים, ג'ין קים והספר שלו נחשבים ממובילי תנועת ה DevOps.

phonix project.jpg

https://read.amazon.com/kp/card?asin=B00AZRBLHO&preview=inline&linkCode=kpe&ref_=cm_sw_r_kb_dp_3rsCybMDRP7RK

למי שמחפש קיצורי דרך יש גם מהדורה מתומצתת או אם תרצו "תקציר ארוך" של הספר

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

שלכם תמיד,

ניר מליק

מה זה גיבוי ומה הופך פתרון גיבוי לפתרון טוב

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

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

 נתחיל בהגדרה מילונית, מה זה גיבוי?

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

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

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

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

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

לא כל הגיבויים נולדו שווים?

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

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

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

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

מה עוד יכול פתרון טוב לכלול?

 אחד הטרנדים המובילים היום בעולם הגיבוי וניהול המידע הוא copy data management. אם אנחנו מיישמים סנפשוטים על מערכת האחסון הראשית שלנו על מנת לאפשר שחזור מהיר, יוצרים כמה העתקים של המידע שלנו על מנת לספק סביבות לפיתוח ובדיקות תקינות, מרפלקים את המידע שלנו לאתר משני לצרכי DR ומיישמים גיבויים לדיסק ולקלטות, הרי שמרבית המידע שאנחנו מחזיקים ומנהלים אינו מידע הייצור שלנו, המידע הפעיל שלנו, אלא העתקים של המידע שלנו. ההיגיון מאחורי הטרנד של copy data management הוא לאפשר לארגונים למנף את העתקי המידע ולהשתמש בהם. אם בעבר תוכנות גיבוי שמרו את המידע על גבי קלטת בלתי נגישה בפרוטוקול יעודי, סגור, הרי שפתרון גיבוי וניהול מידע מספק את היכולת להנגיש את המידע ישירות מיעד הגיבוי ובכך לקיים סביבות בדיקות, סביבות analytics, סביבות מעבדה וכל צורך אחר שאינו זקוק בהכרח לרמת ביצועים גבוהה אבל כן זקוק למידע מקורי ואמין.

בשבוע שעבר הוכרזה חבילת העדכונים SP6 עבור Commvault 11. אחד הכלים המעניינים ביותר שנכללו בחבילה זו תחת Early Release הוא כלי מיגרציה של מידע מגובה מתוכנת הגיבוי הקודמת אל תוך ObjectStore מקוטלג של Commvault. הכלי מספק מענה לאחד האתגרים הכי משמעותיים בפרויקטים של החלפת פתרון גיבוי, ברוב המקרים, הפתרון הכי נפוץ עד היום היה פשוט להשאיר בצד את פתרון הגיבוי הישן לצרכי שחזור עד סיום ה retention. אם הלקוח הוא לא חברה בת יומיים התהליך הזה יכולת לקחת כמה שנים טובות שבהן צריך להמשיך לתחזק את הפתרון הישן, גם אם בתחזוקה בסיסית ביותר, לצד הפתרון החדש, Commvault  מאפשרת עכשיו להתגבר על פרויקט המרת הקלטות הכואב ולבצע מעבר מלא, כולל ה retention אל פתרון הגיבוי החדש.

אז מה עושים עם זה בפועל?

מדיניות גיבוי נפוצה היא מדיניות 3-2-1: שלושה העתקים של המידע, על שני סוגי מדיה שונים, לפחות העתק אחד מחוץ לאתר. על פי מרבית המקורות מייחסים הצלם דיוויד קרוג היה הראשון לנסח את המדיניות הזו והוא מקבל את הקרדיט הזה אפילו במסמך ההמלצות של US-CERT  כך שכנראה יש בזה משהו. לאחרונה ראיתי הרחבה של החוקיות הזו בבלוג של Veeam. זה לא פוסט חדש אבל נתקלתי בו רק לאחרונה והוא מדבר על 3-2-1-0 כאשר 0 הוא 0 טעויות. היכולת לבצע ולידציה של הגיבוי שנקראת אצלם SureBackup מסייעת לוודא שמשימות הגיבוי אכן התבצעו באופן תקין וכי ההעתקים קריאים ונגישים.

גם בשימוש ב snap manager for exchange  למשל, ניתן לשלב במשימת הsnap shot הרצה של eseutil כדי לוודא שההעתק שנוצר תקין. כאן, כשאני מזכיר את NetApp, אני בעצם סוגר מעגל שלם אל ראשית הבלוג וכאן התחיל הדיון אותו הזכרתי, מהו גיבוי? האם סנפשוטים הם גיבוי? לא, לדעתי לא, לא לבד בכל אופן. סנפשוטים יכולים להיות חלק מפתרון הגיבוי, הם במרבית המקרים הדרך הכי מהירה ליצור העתק של המידע וכן, במרבית המקרים, גם הדרך הכי מהירה לשחזר מידע מהעתק קצר טווח אבל, לבדם, הם לא עונים על מה שמגדיר בעיני פתרון גיבוי טוב, הם לא מקטלגים את המידע, לא שומרים אותו על עוד סוג מדיה, לא מוציאים העתק מחוץ לאתר וכו'.

פתרון כמו Commvault, פתרון כמו Veeam ברמות הרישוי הגבוהות או פתרון IntelliSnap שהוא רכיב Commvault המשולב כ OEM במערכות NetApp FAS, פתרון כזה משתמש באופן מובנה ותחת מדיניות גיבוי ארגונית אחת ביכולות הסנפשוט או הרפליקציה של מערכת האחסון וזה כבר עונה להגדרות שפירטתי.

איפה נרשמים?

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

אשמח לשמוע מה דעתכם

שלכם,

ניר מליק

מערכות קטנות (פיזית) וסקסיות, דגמים חדשים של NetApp All Flash

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

בשבוע שעבר הושקה באופן רשמי מערכת ה NetApp All Flash FAS A200 הסקסית והנה היא כאן לפניכם

בחזית 24 דיסקים SSD ומאחור שני בקרים, 8 פורטים 10/16Gb ועוד 2 פורטים 10Gb יעודיים לקישוריות קלאסטר.

a200-back

המערכת תומכת בגידול עד 144 דיסקים עבור זוג בקרים יחיד ותמיכה בתצורת Scale-Out בת 8 בקרים. אם נזכרים בדיסקים של 1.44MB אז זה ממש מרשים לחשוב על 24 דיסקים של 15.3TB או 1PB  אפקטיבי במארז של 2U !

a200-front

בנוסף, כדי לעשות עוד קצת שרירים, הושקה השבוע אחות למערכת ה High End, מערכת ה A700, קוראים לה A700s והיא מספקת את אותם ביצועים אבל בלי כל כרטיסי ההרחבה והמארז הענק ככה שמי שצריך רק את העוצמה אבל בלי כל הגמישות הזו, מערכת ה A700s מגיעה בתצורת 4U וכולל גם היא 2 בקרים מאחור עם 24 דיסקים בחזית.

עדיין קשה לקרוא למכונה הזו מכונה קטנה, 8 חריצי PCIe, פורטים מובנים של 40GbE ו 32Gb FCP, טרה של RAM…מסחרר!

עכשיו, אם עוצרים לחשוב, מצרפים את השקת המכונות החדשות האלו לפוסט הקודם שדיבר על Fabric Pool והפוטנציאל כאן הוא אין סופי, מערכת All Flash שמספקת, נגיד, אם נהיה שמרנים, 1PB effective capacity במארז פצפון של 2U, משלחת כמה מאות אלפי IOps בזמני תגובה של חצי מילי-שניה בכל השרתים והשירותים, ודוחפת החוצה ל S3 את כל הבלוקים הקרים שלה, מה שמתקבל כאן זה נפח אינסופי של All Flash בחסות ה DataFabric! מוצפן, דחוס, מדודפ, מנוהל ממיקום מרכזי, מתרפלק למערכות אחרות, מתממשק אל כל מנועי האוטומציה והאורקסטרציה, תומך באופן מלא בכל ההייפרויזורים והקונטיינרים ועונה בכל הפרוטוקולים הנפוצים, זו ארמדה שלמה במארז של 2U, מקסימום 4U. לאף מתחרה בשוק אין כלים כאלו, פשוט אין. חלק אומרים שיש להם אבל פשוט אין.

אגב למי שדאג, השבוע הוכרזה ONTAP 9.1 RC2 ככה שנראה שההשקה הרשמית של 9.1 כבר מעבר לפינה. אחד החידושים בהכרזה הזו נמצא בצד השני של הקשת, אם אמרתי שיש מערכות חדשות שהן קטנות וסקסיות אז RC2 מאפשר מהצד השני בריון אחד שקט, מדף הדיסקים החדש DS460C המכיל 60 דיסקים בגודל 3.5" LFF במארז של 4U עם קישוריות 12Gb SAS.

תחת גרסאת מערכת ההפעלה הנדרשת, המדף נתמך בכל המערכות מסדרה 8000 ומעלה. talk about density!

שלכם תמיד,

ניר מליק

אולימפיאדה, ברברים ועננים – NetApp Fabric Pool

אולימפיאדה, ברברים ועננים – NetApp Fabric Pool

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

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

מערכות אחסון מודרניות חיות היום גם הן על האיזון בין הקצוות, בין דיסקים גדולים מאד המסתובבים באיטיות ודיסקים קטנים מאד מהירים. העולם בו אנו חיים נשלט על ידי שתי אימפריות ישנות, אימפריית ה SAS שדגלה תמיד בביצועים על חשבון נפחים ואימפריית ה SATA שדגלה בנפחים על חשבון ביצועים. מבחינה היסטורית, אנחנו נמצאים עמוק בימיה האחרונים של האימפריה הראשונה, הברברים של ה SSD עומדים על חומות אימפריית ה SAS וברור שיימי האימפריה ספורים. כאיש ימי הביניים תמיד צחקתי שאם המסמכים המקוריים נכתבו באנגלית אז זו לא היסטוריה אלא רכילות, חוק פרטי זה תקף גם לגבי האימפריה השניה כנראה. נכון, עוד קצת מוקדם להספיד לגמרי את אימפריית ה SATA אבל לא מוגזם לשער כי הפשיטות של שבטי הענן גורמים גם למנהיגי אימפריה זו לרעוד מאחורי ביצורי ה helium encased drives וה shingled drives  . העלויות הנמוכות לשימוש באחסון אובייקטים S3 ואף יותר מכך Glacier הופכות מיום ליום גם את השימוש בדיסקים מסוג SATA לפחות הגיוני, בטח לשימושים כמו גיבוי או ארכוב. נכון לעכשיו, תחילת דצמבר 2016, עלות טרה אחד S3 בשירות AWS הוא כ 31$ לחודש ועלות טרה אחד בשירות Glacier הוא כ 11.5$ לחודש והמחירים כל הזמן יורדים.

אחד מסודות ההצלחה של כל אחת מהאימפריות הגדולות בהיסטוריה היה תמיד היכולת להתפתח ולהתאים את האימפריה לזמנים המשתנים, פרגמטיות שכזו היתה מאפיין של האימפריה הרומית, האימפריה העותומנית ואפילו הצלחתה של הנצרות במאות הראשונות לספירה מיוחסת לפרגמטיות שהנהיג השליח פאולוס. NetApp מוכיחה בשנתיים האחרונות שהיא אימפריה פרגמטית. סל המוצרים האטרקטיבי, ביחד עם תפיסת הפעלה כוללת – מארג המידע או ה Data Fabric, מספקים מענה למרבית אתגרי המידע בעולם המחשוב היום, מערכות אחודות מובילות בעולם ה All Flash, מערכות SAN לסביבות high density, מערכות SolidFire לניהול אחסון במודל ענן, פתרונות לגיבוי חכם אל הענן, פתרונות מבוססי תוכנה בלבד software defined, מערכות וירטואליות לסביבות ענן, כלים להגירה בין פתרונות NFS מקומיים לשירות אובייקט בענן, NetApp היא אתלט קרב עשר מדהים – כוח מתפרץ וגם סיבולת לטווח ארוך, מהירות וגם טכניקה, ליצרן הזה יש מענה מוביל והוא חלק ממארג שלם של כלים ולא מענה נקודתי או חלקי.

יכולת חדשה שמדגישה את השילוב הזה בין היכולות והדיסציפלינות היא יכולת ה Fabric Pool החדשה שנחשפה לאחרונה בכנס ה Insight, התייחסתי אליה בקצרה באחד הפוסטים הקודמים ועכשיו אני רוצה להרחיב עליה קצת. יכולת זו שתהיה זמינה בקרוב, מאפשרת להשתמש בו זמנית בשני כלים משני קצוות הקשת, מחד, לאמץ את הברברים של ה SSD ולהשתמש במערכת עתירת ביצועים מובילה על מנת לספק מאות אלפי IOps בזמני תגובה הנמדדים כיום במיקרו-שניות ומאידך, על פי מסורת שבטי הענן, להכיר בעובדה שבסופו של יום, מרבית המידע בארגון אינו מידע "חם" כלומר, חלק ניכר מהמידע שאנחנו מחזיקים הוא מידע שלא משתמשים בו ולהעביר באופן אוטומטי ושקוף את המידע ה"קר" אל שכבת אחסון משנית מבוססת פרוטוקול S3, אחסון אובייקטים סטנדרטי בין אם בוחרים ליישם שכבה משנית זו על ידי פתרון מקומי כמו NetApp StorageGrid או פתרון מרוחק כמו AWS S3.

פשוט כך, ללא צורך לשנות שום דבר מצד ה front-end, ללא הגבלה על פרוטוקול הגישה, ללא כל צורך בשינוי מצד האפליקציות או הרגלי המשתמשים, באופן שקוף לחלוטין, מערכת האחסון תנהל לעצמה את עדכוני ה Meta-Data ותדע להעביר בלוקים קרים אל הענן כך שמחד מערכות הארגון יקבלו שירות ברמה של All Flash ומאידך לא נהיה חייבים לשמור את כל המידע על דיסקים יקרים. בואו נרחיב לגבי השקיפות הזו: אחד הפקטורים המשמעותיים במערכות All Flash הוא חסכון בנפח האחסון, יכולת ה Fabric Pool שקופה לחלוטין לטכנולוגיות ה Efficiency המובנות ב All Flash FAS, כל החיסכון שמתקבל בשימוש ב in-line De-Duplication, In-Line Compression ו in-Line Compaction נשמר, המערכת מודעת לחסכון ושומרת עליו גם במעבר הבלוקים הקרים לענן. אותה שקיפות נכונה גם ליכולת ה Volume Encryption שנשמרת, אין ביצוע Decrypt כאשר מעבירים מידע ויתר מזאת ניתן כמובן לבצע הצפנה על הצפנה ולהצפין את הבלוקים גם במנגנון המובנה ב StorageGrid  למשל או יכולת ההצפנה של S3.

fabric-pool

מבחינה מעשית, כל מה שנדרש לעשות זה להגדיר קישור אל AWS ואז יש שני דברים להגדיר מצד מערכת האחסון, עבור אילו Volume'ים אנחנו רוצים להפעיל את יכולת ה Fabric Pool ואם אנחנו רוצים להפעיל אותה עבור כלל המידע ב Volume או רק על הסנפשוטים. נשמע פשוט? אכן פשוט. אפשר להפנות כמה מערכות אחסון אל אותו מנוי S3 וכמובן שהפתרון נתמך גם בשימוש ביכולת multi-node scale-out כלומר גם כאשר מערכת ה All Flash FAS שלנו כוללת יותר מזוג בקרים אחד, הפתרון נתמך, עובד ושקוף.

which-volume

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

report

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

מי שרוצה ללמוד עוד קצת היסטוריה מוזמן לפנות לפודקאסט המדהים של דן קרלין ומי שרוצה לקרוא עוד קצת על Fabric Pool מוזמן לקרוא את הפוסט הבא של ג'ף בקסטר

כמו תמיד אשמח לשמוע מה דעתכם על הפוסט, על Fabric Pool ועל החיים

שלכם,

ניר מליק

*הערה – כן, אני יודע שכבר יש דיסקי SSD יותר גדולים מדסיקי NL-SAS אבל התמחור שלהם משאיר אותם עדיין קצת פחות רלונטיים עבור מרבית הלקוחות בישראל

NetApp Insight 2016 – מחשבות רנדומליות לסיכום שבוע עמוס

NetApp Insight 2016 – מחשבות רנדומליות לסיכום שבוע עמוס

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

אז מה היה לנו שם?
שרתי קריוקי בטסלה שחורה:

התראיינתי לVLOG של TECHunplugged

"התראיינתי" לפודקאסט האהוב עלי TechONTAP

אכלתי המבורגרים

burger

הצטלמתי עם מייסד החברה, דייב היץ:

hitz

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

dvaendave

ובסוף גם למדתי כל מני דברים מגניבים.

אחד הדברים למשל היה פתרון מבוסס E-Series לסביבת Ceph.

כמובן שהשאלה הראשונה עליה צריך לענות היא מי צריך פתרון אחסון Enterprise אם הוא משתמש ב Ceph, זה לא סותר אחד את השני? אז זהו, שלא, למעשה, זה אחד העקרונות בתפיסת ה Data Fabric, לספק תשתית איכותית לכל סגנון ואופי של לקוח, גם כזה שרוצה לנהל את צריכת האחסון שלו במודל פתוח לחלוטין.

מה ש NetApp הוכיחה במעבדה מאד מקיפה, זה שפתרון Ceph מבוסס על מערכות E-Series במקום על שרתים מבוזרים עם DAS מספק ביצועים זהים באיכותם אבל טובים יותר ביציבות שלהם. במקרה של נפילת דיסק למשל, הפתרון הבסיסי, הנפוץ, מבצע העתקות רבות של מידע כדי לפצות על נפילת דיסק דווקא בגלל התפיסה של no-raid.יש צורך לאזן מחדש את המידע וזה עולה לנו בהרבה מאד IOps.

NetApp הוכיחה שדווקא ההיפך הוא הנכון ואם מתבססים על Riad במערכת ה E-Series אפשר לספוג נפילה כזו בלי פגיעה בביצועים ולתת למערכת האחסון לשאת בנטל ה rebuild

rebuild-ceph

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

ceph

יש כמובן תיעוד מלא למה שתיארתי מעלה ב TR-4549-0916 וכל מי שרוצה לשמוע על זה עוד מוזמן לפנות אלי, אני מכיר את האנשים שיכולים לעזור 🙂

אחד האיזורים המעניינים ב"רחבת התערוכה" הראשית של הכנס היה Developers Cafe. פתרונות כמו פתרון ה Ceph שתיארתי מעלה, פתרונות לעולם ה OpenStack ולעולמות ה Docker, קיבלו מקום משלהם, מקום מכובד בו ניתן היה לפגוש את אנשים שתפקידם להיות השדכנים בין מנהלי המוצרים ב NetApp ובין אנשים שחיים את חיי הפיתוח, לקוחות ושותפים שצריכים לנהל בפועל את כל הסביבות החדשות האלו. לדעתי היה מאד מעניין לראות את האינטראקציות בחלל הזה, אנשים כמו Josh Atwell או כמו Andrew Sullivan שעוסקים בליווי לקוחות בהטמעות מורכבות ומעניינות של פתרונות אלו ישבו והקדישו זמן לסשנים 1:1 עם לקוחות מתעניינים, הראו להם איך בפועל הדברים עובדים ומה עוד אפשר לעשות כדי לשלב פתרונות מתקדמים וחדשניים אל תוך המערכות שלהם מבלי לוותר על היתרונות של מוצרי Enterprise בעלי תמיכה, שירות וצוותי מומחים.

סבסטיאן, אחד מחברי לצוות ה A-Team אמר בראיון שלו ל Tech ONTAP שזה מרגש לראות את ה Data Fabric הופך ממוצרים לפתרון מלא, לדעתי הוא פוגע בדיוק בלב המשמעות של כנס כמו NetApp Insight. הכנס מספק למי שנוכח בו תמונה מלאה ומקיפה על כלל החלקים הנעים, על החזון, האסטרטגיה, הכלים, המוצרים, התפישות והקהילה שמרכיבים את עולם ה IT המודרני, לפעמים קשה לראות את התמונה כולה, ולקשר מערכות אחסון אולטרה מהירות אל הענן אל כלי הגיבוי אל כלי הניטור ואל סביבת האוטומציה, כנס שכזה מראה את השילוב בין הרבדים האלו ומספק את הקהילה שתומכת, בין אם אתה מנהל IT של חברה קטנה, מנהל פיתוח של חברת ענק או יועץ שעוזר ללקוחות במעבר מעולם כזה לעולם אחר, NetApp שם עם סוללה של פתורנות ומומחים לסייע.

הדגש על הקהילה סיקרן אותי במיוחד, כפי שכתבתי בפוסט הראשון בבלוג הזה, זו בעצם אחת המטרות שלו, אחת המטרות שלי, ליצור ולפתח את הקהילה והיכולת שלנו לעזור זה לזה. הכנס שם על זה דגש ואפילו נתן לזה מקום וזמן, מי שרצה יכול היה לשבת עם Amy Lewis למשל, שעוסקת בשיווק ופיתוח קהילות וחברה בפודקאסטGeek Whisperers לסשן mentoring נקודתי לגבי פיתוח הקריירה האישית שלו, אני ציניקן בדרך כלל אבל לדעתי זה אומר משהו על החשיבות של קהילה תומכת בעולם שמתשנה בכל יום, אפילו אם זו קהילה מכוונת וחברי הקהילה נמצאים בצד השני של הים.

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

שלכם,

ניר מליק

נ.ב.

מי שרוצה כבר לסמן ביומן, נפגשים בשנה הבאה שוב בברלין, 13 עד 16 בנובמבר.

הענן ההיברידי – מיני פוסט אסטרטגי לפני NetApp Insight

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

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

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

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

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

ישראל נבחרה להיות אחת משתי מדינות ב EMEA, ביחד עם גרמניה, בה NetApp משיקה שירות חדש כפיילוט, שירות שכולל למעשה יעוץ אסטרטגי הכולל מומחי טכנולוגיה, משפט ופיננסים על מנת לספק ללקוחותיה מענה בכלל הרבדים שציינתי מעלה. השירות החדש נקרא hybrid cloud readiness services וכלולים בו יעוץ של אנשי מקצועי מובילים בתחומם, מדובר בשת"פ עם משרד עורכי דין גדול, משרד יעוץ פיננסי ושירותי היעוץ הטכנולוגי של NetApp העולמית ככה שניתן להרחיב את ה DATA Fabric אל מעל הרובד הטקטי של ביצוע הפועל אל הרובד האסטרטגי של מה לבצע, איך לבצע, האם כדאי לבצע, ואיך יוצאים משם ביום שזה לא יהיה יותר כדאי.

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

לכל מי שירצה לעקוב בלייב אני נמצא בטוויטר @maliknir

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

redcross

כל מי שירטווט אותי יזכה למצוות ויעזור לי לזכות בתחרויות הפנימיות של #ATeamEMEA ותבוא עליכם הברכה

שלכם,

ניר מליק

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 וכל מני כאלו, אבל לדעתי זה ממצה את הדברים העיקריים שכדאי לדעת.

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

שלכם,

ניר מליק

לייב-בלוג: מה חדש בקומוולט 11 עדכון 5

נסיון ראשון ללייב-בלוג אני עם רוני קפטל, מנהל הפריסייל של קומוולט ישראל, שמעביר וובינר על החידושים בגרסה 11 עדכון 5 בתוכנת הגיבוי וניהול המידע קומוולט

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

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

התצורה החדשה היא תצורה שנקראת solution set ובוא ניתן למכור רישוי קרוב יותר למה שהלקוח מעוניין לבצע. זה רישוי דומה באופי שלו לרישוי per socket לשביבה וירטואלית ודבר ראשון מוסיף רמות רישוי. ברמת advanced כלול גם הרישוי לאינטליסנאפ וגיבוי לענן כמו גם פורטל ה self service.

הרישוי הזה כולל גם כמובן רישוי לגיבוי application aware לסביבות מבוססות חלונות

רישוי ה complete מוסיף ל advanced גם רישוי live sync ורישוי live sync לענן

רישוי ה complete כולל גם את רישוי ה active DR

(ספויילר – ב 15 לחודש בכנס השנתי של קומוולט יוסי אשכנזי יעביר דמו מלא לגיבוי לענן!)

מודל רישוי חדש ומעניין הוא מודל solution set לסביבה הפיזית. רישוי זה אינו מוגבל בנפח.

רכיב רישווי מיועד ל file systems וכולל רישוי בלתי מוגבל בנפח. הרישוי כולל גם ארכוב ומתומחר לפי יחידה ככה שאם יש לי סביבה וירטואלית גדולה ורכיב NAS אחד בסביבה אפשר לגבות את ה NAS עם הרישוי הזה ואת הסביבה הוירטואלית ברישוי per socket/VM

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

כוכבית, לא בדיוק בלתי מוגבל בנפח אלא כולל 150TB לכל יחידה.

ה set האחרון הוא למעשה אינטליסנאפ מפושט שמאפשר רק ניהול snap shots של מערכת האחסון בצורה חכמה אבל בלי הורדה לקלטות וכו'

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

עכשיו לחלקים הטכניים:

שני עדכוני התוכנה האחרונים מייצגים החרבה משמעותית של היכולות בעולם הוירטואלי כולל תמיכה ב nutanix acropolis, open stack, oracle VM, KVM וכמו כן כניסה לעולם של live sync לענן וכו'

שיפורים בתמיכה ב GAD HDS בניהול intelisnap, תמיכה ב extreme IO ורפליקציה של isilon כמו גם SRDF וגם PURE storage ואפילו ניהול snapshot של AWS

כולל ניהול snap and replication של isilon

סוכן חדש לארכוב exchange

admin console הוא שיפור ביכולת לספק למנהל האפליקציה או הסביבה dashboard יעודי עבורו

בתוך ה dashboard היעודי תהיה תצוגה יעודית למנהל האפקליציה שכוללת את האופציות הרלונטיות עבורו בצורה נגישה ופשוטה

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

scale-out storage pool פתרון חדש לספק שירותי אחסון ל media agents שלנו כ scale out storage. הפיצ'ר הזה יחליף בסוף את ה disk library וה storage policy. הוספה של דיסקים או media agents תגדיל אוטומטית את ה pool

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

oracle livesync/ replication משתמש ביכולת גיבוי ברמת ה block וה CBT על מנת לבצע שחזור מתוזמן אוטומטי באתר ה DR לשכפול סביבות על בסיס הגיבוי

בעולמות ה big data קיים גיבוי ל GPFS ו hadoop:

distributed backup – היכולת להגדיר הרבה אייג'נטים ולייצג אותם כאייג'נט יחיד ולמעשה "לתקוף" קלאסטר מכמה נקודות במקביל. שימושי בסביבות GPFS למשל כאשר יש לנו הרבה מאד מידע לגיבוי אנחנו יכולים להגדיר כמה סטרימים של גיבוי במקביל כדי לנצל את כל המשאבים שלי לגיבוי מהיר ויעיל

קייימת עכשיו גם תמיכה ב HDFS לגיבוי מהירי ויעיל של סביבות hadoop גדולות

יש שיפור ביכולות הארכוב של exchange לבצע גרנולריה לארכוב ברמת המשתמשים ושיפור ביצועים משמעותי

גיבוי בעולם ה azure – גיבוי ושחזור מכונות וירטואלית

הסוכן של VSA נכתב מחדש, לא צריך יותר מכונה וריואלית לבצע live sync/ live brows, live mount אלא אם זה מכונות וירטואלית מסוג linux ישנות יותר. לשאר הסוגים ניתן לבצעכ ישירות מתוך ה storage

application aware backup תומך באופן מלא גם ב CBT בעולם ה hyper-v כולל תמיכה ב 2016 כבר כיום וגיבוי אפקליציות כולל SQL, exchange, oracle for windows

שיפור יכולת גיבוי AWS EC2 אל תוך S3 כולל ניהול amazon snap engine

השתלבות אל תוך עולמות ה VMware vRealize automation ולספק אל תך הפרוטל יכולות גיבוי ושחזור

גרסה זו כוללת תמיכה מוקדמת ביכולת VVoL האהובה עלי, נכון לא פתרון מאד נפוץ עדיין בעולם וכמעט שלא מוטמע בארץ בכלל אבל כמו שכתבתי כאן בעבר לדעתי זה עומד להשתנות בקרוב ועכשיו VVOL מנוהל תחת אינטליסנאפ כמו hardware snapshot

בשעה טובה אין יותר צורך ב offline mining tool ועכשיו אפשר לשחזר פריטים בודדים הגיבוי ישירות. המשמעות היא שלא חייבים יותר לגבות את ה exchange פעמיים!!!

מנוע SMTP פנימי מאפשר לבצע גיבוי וארכוב של ה journal ולהנגיש את המידע באופן ישירות

cloud global repository cell – תמיכה בשחזור מרכזי לאתרים מבוזרים גם בלי dash copy וגם בלי רפליקציה של dedup database

intelisnap תומך גם ב db2 וכל מני כאלו היום

VSA נכתב גם לסביבת linux היום ומתאים גם ל open stack כולל streaming ו crash consistent

KVM כולל פדורה, REHL ו centos

כן, ככה זה כשכותבים תוך כדי ריצה, הרבה בלגן וכותרות שמנותקות מהתוכן שלהן אבל היה כיף!

כל מי שרוצה יכול לקבל מרוני לינק להקלטה של הסשן המקורי וכמובן שכל מי שהיה רשום אליו במקור יקבל אותו באופן אוטומטי.

מוזמנים לקבל גם ישירות ממני אל תהיו ביישנים

שלכם,

ניר מליק

 

 

 

 

 

סקירה קצרה ולא מחייבת של הסשנים המעניינים בעיניי בכנס 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

ניר מליק

NetApp Cloud Sync – מארג המידע מתעבה לנגד עיננו

באחד הפוסטים הקודמים, הצגתי את תפיסת ה Data Fabric של NetApp וחזרתי לזה גם כשדיברתי על ONTAP 9 ועל ONTAP 9.1.

לאחרונה, הציגה NetApp שירות חדש בשם Cloud Sync שמרחיב את יכולות ה Data Fabric אל מעבר לסל המוצרים של NetApp עצמה. זו נקודה מאד חשובה ומעניינת כי עד עכשיו דיברנו בעיקר על סנכרון, רפליקציה, הגירה או גיבוי של מידע בין המוצרים השונים של NetApp תוך התממשקות לשירותי הענן השונים. עכשיו, עם ההשקה של cloud sync, נחשף שירות הניתן לרכישה על פי תשלום ישירות מאמאזון, לסינכרון של פתרונות NFS אל פתרונות S3 גם אם המקור והיעד אינם מוצרים של NetApp.

כל מה שצריך זה מנוי ב AWS וקישור מאובטח בין אתר הלקוח ובין שירות הענן כלומר, השירות יפעל בתוך ה VPC של הלקוח (AWS Virtual Private Cloud ) ללא מעורבות של NetApp, ללא "עין" נוספת שנחשפת אל המידע הארגוני.

cloud-sync_overview

עם הקמת השירות יופעל רכיב וירטואלי חדש בתוך סביבת ה VPC בשם Data broker. רכיב זה הוא למעשה הרכיב האקטיבי המקשר בין ה NFS directory/server ובין ה S3 bucket. יש להזכיר כי ה bucket וה data broker צריכים לפעול באותו איזור גיאוגרפי של AWS.

להלן רשימת האזורים הנתמכים כיום:

  • Asia Pacific (Sydney)

  • EU (Ireland)

  • US East (N. Virginia)

  • US West (Oregon)

הצעדים הנדרשים לביצוע הם סה"כ די פשוטים וברורים,

לאחר כניסה ל http://cloud.netapp.com/cloud-sync יש לבצע כניסה לשירות באמצעות משתמש amazon.com (לא באמצעות משתמש aws). לאחר מכן יש להכניס את שם החברה ולאשר את תנאי השימוש.

לאחר תהליך ההרשמה יש לבחור copy to S3 תחת select an AWS Service.

בחירת שרת ה NFS יכולה להיעשות באמצעות כתובת IP או באמצעות שם דומיין מלא. כמובן ששרת ה NFS צריך גישה מאובטת אל ה VPC שלנו בו נמצא ה bucket אליו אנחנו רוצים לסנכרן.

לאחר בחירת שרת ה NFS מקימים את ה Data broker ובשלב זה נתבקש לבצע גם כניסה לשירות ה AWS שלנו. שוב נדגיש שיש להקים את ה data broker ב region הנכון כדי שתהיה לו גישה אל תוך ה VPC שלנו.

region

הקמת ה data broker לוקחת כחמש עד עשר דקות ולאחר ההקמה ניתן להכנס ולבחור תיקיות לסנכרון מצד שרת ה NFS ולאחר מכן לבחור את ה bucket אליו מסנכרנים.

לאחר יצירת ה relationship ניתן לצפות בסטטוס של הקשרים השונים תחת ה dashboard.

view_in_dashboard

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

 למי השירות מתאים? בעצם לכל מי שמעוניין לצבור מידע באופן מקומי אבל להנגיש אותו לביצוע אנליטיקה כשירות בענן. לקוחות המשתמשים ב MAPR או RDS וכדומה. הלקוח משלם רק על המידע שמונגש אל שירות הענן, רק כל עוד הוא נדרש והמאסה העיקרית של המידע נשארת on-premises כך שניתן יהיה להסיר את המידע מaws לאחר ההרצה.

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

cloud-sync-cost

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

שירות ה cloud sync מצטרף לעולם ה Data fabric ומחזק את יישום החזון של NetApp. בשנה שעברה, ניתנה בכנס הצצה ליכולת לרפלק בין מערכות ONTAP למערכות AltaVault. השנה נחשפה יכולת זו באופן רשמי וכיום ניתן לנהל גיבויים אל הענן ללא כלי חיצוני בהתבסס על כלי NetApp בלבד.

כמו בעבר, הכנס סיפק גם הצצה לעתיד. ג'ו קרדונה שראינו בכל הסרטונים מעלה הוא ארכיטקט ה Data Fabric ובסרטון הבא הוא מציג יכולת מובנית במערכות All Flash לבצע Tiering אוטומטי אל מערכות אחסון מסוג Object, הן מערכות On-Premises והן מערכות בשירות ענן כמו Amazon S3 שדיברנו עליהן קודם

באמצע החודש הבא יערך הכנס המקביל, NetApp Insight EMEA בברלין. אני מאמין שנראה בכנס וסביבו עוד הכרזות מאד מעניינות להרחבת והעמקת חזון ה Data Fabric המלא. הישארו עימנו!

שלכם,

ניר מליק

 

New NetApp Software & Flash Systems are here, have a look!

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

במהלך אירוע הפתיחה הוכרזו החידושים המרכזיים במערכת ההפעלה החדשה ONTAP 9.1 וכן הושקה סדרה חדשה של חומרה, בקרים ומדפים, לקו מוצרי ה FAS וה All Flash FAS. כזכור NetApp היתה היצרן הראשון להכריז תמיכה בדיסקים מסוג 15.3TB SSD ועכשיו מוכרזת תמיכה מלאה בקישוריות 40GbE, 32Gb FC וקישוריות 12Gb SAS וזאת על מנת לאפשר את ניצול כלל המשאבים שהסוסים החדשים יודעים לספק.

מיד אסקור חלק מהחידושים שמציגה מערכת ההפעלה החדשה ONTAP 9.1 אבל ראשית אני רוצה להפנות את תשומת לבכם לעובדה שכלל יש מערכת הפעלה כזו, זה שינוי אדיר בקצב עדכוני התוכנה של היצרן והוא מצביע על השינוי המהותי שעוברת NetApp בזמן האחרון. השנה הוכרזו כבר ONTAP 9, Elements Florin וכן SANtricity 3.0, משהו טוב עובר על מחלקות הפיתוח של NetApp וציפור לחשה לי שיש עוד חידושים מאד משמעותיים בקנה להמשך השנה.

חידוש מעניין ראשון הוא יכולת ה Flex Groups שמחליפה את טכנולוגית ה infini-vol. הטכנולוגיה החדשה מרחיבה באופן משמעותי את היכולת לספק file system ענק לניצול כמות גדולה של בקרים ונפח אחסון ותומכת מעכשיו ב 20PB  של מידע וארבע מאות מיליארד קבצים, בתמיכה מובנית ב NFS  וכן SMB מדובר במפלצת Scale-Out לעולמות עיבוד, ניתוח, ניטור וריצוף גנטי.

החל מגרסא זו קיימת תמיכה מלאה גם ב Cloud ONTAP על גבי סביבות Azure בנוסף לתמיכה הקיימת בסביבות AWS והחידוש הכי מעניין בעולם הענן הוא התמיכה של מערכות ה All Flash בביצוע Cloud Tiering כלומר העברה אוטומטית של מידע "קר" ל S3! כזכור כתבתי בעבר שתפישת ה Data Fabric היא לא רק חזון או מסר שיווקי והחידוש הזה הוא צעד ענק להוכחה שצדקתי.

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

סדרת בקרי ה FAS החדשה כוללת שלושה דגמים, FAS 2600, FAS 8200 וספינת הדגל החדשה FAS9000.

ה FAS 9000 מציגה תפיסה חדשה לגבי מבנה פיזי של בקרי מערכת אחסון המזכירה מארזים של שרתי להב, שני מודולי הבקרים אינם כוללים רכיבי תקשורת כך שניתן יהיה להחליפם בקלות רבה יותר בעת הצורך והמארז כולל 10 חריצי הרחבה לכל בקר. זוג בקרים יחיד מדגם זה מסוגל לתמוך בנפח אדיר של 14PB והמשמעות היא יכולת גידול לקלאסטר של 172PB  בשימוש ביכולת ה Scale-Out של ONTAP. המבנה המודולרי מאפשר גם הרחבה או החלפה של רכיבי ה NVRAM בעת הצורך וכולל חריצים יעודיים לרכיבי NVMe SSD לשימוש ככרטיסי האצה, שדרוג של Flash Cache  המוכר והאהוב.

fas9000

דגם ה"ביניים" הוא FAS 8200 שיכלול 256GB RAM וכל בקר יגיע באופן מובנה עם 1TB NVMe וביחד עם Flash Pool המערכת תתמוך ב 48TB של SSD Cache. זוג בקרים יחיד יתמוך בנפח אחסון של עד 4.8PB ומקסימום של 57PB בשימוש ביכולות Scale-Out. דגם זה כולל הכפלה של כמות ליבות העיבוד לעומת FAS 8040, דגם ה mid-range בסדרה הקודמת ובהשוואה לאותו הדגם המערכת כוללת פי 4 יותר זיכרון RAM!

מערכות ה FAS 2600  יחליפו את מערכות ה FAS 2500 ויכללו גם הן באופן מובנה 1TB NVMe להאצת ביצועים. מערכות אלו יוצעו בשני תתי דגם, FAS 2620 שתכיל באופן מובנה דיסקים בגודל פיזי של 3.5 אינטש ו FAS 2650 שתכיל באופן מובנה דיסקים בגודל פיזי של 2.5 אינטש. סדרה זו כוללת הכפלה של משאבים לעומת הסדרה הקודמת ובכלל זה כמות ה RAM בבקרים וכמות ה NVRAM והכפלה פי 3! של כמות ליבות העיבוד. הגידול בכמות הפורטים המובנים מאפשרת שימוש בפורטים מסוג 10Gb לקישוריות קלאסטר ועדיין לספק 4 פורטי UTA בכל בקר לתקשורת אל השרתים. סידרת Entry Level שמספקת 100,000 IOps או 5Gb זה לא רע הא?!

שני דגמים חדשים בסדרת מוצרי ה All Flash  הם ה A700 שתתבסס על המבנה של FAS900 ותכיל 1TB RAM וה A300 שתתבסס על המבנה של FAS8200 ותכיל 256GB RAM. שילוש של בקרים אלו, דיסקי SSD  בלבד ותמיכה בכרטיסי התקשורת החדשים תאפשר לרדת לעולמות ה micro second בזמני התגובה וכל מה שנשאר ללקוחות זה להניח תשתית שתהיה מסוגלת למשוך (ולמשוך, ולמשוך) משאבים.

במסגרת השקת סדרת הבקרים החדשה הוכרזו גם דגמי מדפים חדשים על מנת לתמוך במהירות קישור של 12Gb SAS וגם בתחום זה צפויות הכרזות נוספות בקרוב.