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 וגם בתחום זה צפויות הכרזות נוספות בקרוב.

מודעות פרסומת

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 🙂

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

שלכם,

ניר מליק

רעידת אדמה באיטליה – מחשבות על DRP

רעידת אדמה באיטליה – מחשבות על DRP

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

שלוש המלצות מסוג "אל תעשה" לגבי טיול בחבל ארץ יפה זה:

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

italy

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

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

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

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

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

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

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

להלן רשימה של שאלות לדוגמא שיש לספק עבורן מענה על מנת לייצר באופן נכון את רמות ה SLA בארגון:

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

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

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

שלכם,

ניר מליק