מאמר - תכנון מערכת NETAPP לארגון קטן וחשיבה מחוץ לקופסא - טכנולוגיית מידע - IT - HWzone פורומים
עבור לתוכן
  • צור חשבון

מאמר - תכנון מערכת NETAPP לארגון קטן וחשיבה מחוץ לקופסא


DXM

Recommended Posts

שלום לכולם,

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

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

*איני לוקח שום אחריות על שימוש במאמר זה, ושימוש בו הוא על אחריות המשתמש.

תכנון מערכת NETAPP לארגון בינוני-קטן וקצת מחשבה מחוץ לקופסא

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

לאחרונה עבדתי בחברה בה היתה קיימת מערכת FAS2040 שהיא המערכת הבסיסית ביותר של NETAPP. המערך כלל שני FILERS, ובנוסף 12 דיסקים של 600GB. אופן חלוקת המשאבים של מערכת הNETAPP הזו היה כושל והביא לבזבוז משאבים ניכר. לצערנו מערכת NETAPP הינה מערכת יקרה ביותר, ובזבוז משאביה עלול לגרור הוצאות רבות, כאשר מדובר בארגון קטן העלויות הללו עלולות להכביד מאוד.

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

על מנת להבין את אופי המערכת עלינו להכיר מספר מונחים שאשתמש בהם בהמשך המאמר ללא הסבר ולכן אסבירם כאן:

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

ב. RAID Dp- ברייד זה יש שני דיסקי זוגיות והוא מסוגל לספוג איבוד של עד שני דיסקים ברגע נתון.

ג. RAID GROUP- אוסף של דיסיקים הנמצאים בRAID מסויים. ייקרא RG.

ד. AGGREGATE- אוסף של RG, עליו ניתן להקצות VOLUME. ייקרא גם AGGR

ה. SPARE- דיסק נוסף שאינו שייך לRAID מסויים ונמצא במערכת לעת צרה ויחליף אחד מהדיסקים במערך מסויים על מנת לצמצם את מרחב הזמן בו דיסקים עלולים לאבוד.

ו. FILER הראש המנהל את הדיסקים, הכולל את כל חומרת השרת למעט .

ניקח לדוגמא FAS2040, המכיל שני פיילרים בקלאסטר ובנוסף 12 דיסקים SAS של 600GB כל אחד.

אם נחלק לפי ההגיון הפשוט את המערכת, נקבל 6 דיסקים לפיילר 1 ו6 דיסקים לפיילר 2. לכל פיילר נקצה AGGR מבוסס RG מסוג RAID DP ומכיל בנוסף דיסק SPARE. סה"כ אמורים להיות אם כך כ3.6 טרה בייט פנויים לכתיבה. אך עלינו לזכור כי לכל מערכת קיים wafl reserve, הלוקחת כ10% מהשטח שלו ולכן מדובר רק ב3.24TB פנוי. כלומר 1.6TB בכל פיילר.

זוהי שיטת החלוקת הקלאסית למערכת מסוג זה, אך כפי שראינו שטח האחסון בה נמוך במיוחד סה"כ 3.2TB. זוהי הבעיה העיקרית בתכנון מערכת כזו, אך יש לה מחלה נוספת, שעלולה להיות בעיה חמורה אף יותר. בכל AGGR קיימים סה"כ שלושה דיסקים, ולכן כמות הIOPS שהיא מסוגלת לספק נמוכה מאוד, והחישוב שלה פשוט: iops per disk*3 בערך (חישוב מסובך שלא אכנס אליו במאמר זה). במידה וקיים צורך במערכת עתירת ביצועי IOPS כגון מסדי נתונים בעלי עומס כתיבה/קריאה גדול או שרתי EXCHANGE ישן (בEXCHANGE האחרונים דרישת הIOPS נמוכה), עלול להווצר צוואר בקבוק.

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

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

למזלנו אצלנו אין בעיה של ימים, וניתן להגדיל את הנפח. הבעיה הזו נקראת ניצול, וכאשר קיים לנו AGGR אחד גדול (ראה סוף המשל) הוא עדיף על שניים קטנים (בהגבלות מסוימות). יתרון נוסף בAGGR גדול הוא האפשרות ליצירת VOLUME גדול (כאשר יש כד גדול ניתן להכניס אבן אחת גדולה יותר). כך למשל אם גודל הAGGR שלנו רק 1.6TB אזי שהגודל המקסימלי של ווליום הוא 1.6TB, ואילו גודל הAGGR שלנו 3.2 אזי הגודל המקסימלי של הVOLUME הוא 3.2 וזה לא רלוונטי אם יש לנו AGGR נוסף או לא.

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

ראשית אתחיל עם המגבלה העיקרית, לכל פיילר חייב להיות AGGR המכיל VOL0 שהוא המחיצה המוקצה למערכת הפעלה. כלומר לכל פיילר חייבת להיות מוקצת RG ובה דיסקים. נטאפ דורשת שכל RG יהיה בRAID ולכן המינימום דיסקים המוקצים לכל AGGR יהיה 2 בRAID4, שימו לב חשוב להבין שמדובר בRAID4 ולא בRAID1 (מראה), כיוון שבמידה ודיסק אחד קורס העומס על הפיילר עולה משמעותית כיוון שכאשר מדובר בזוגיות הוא צריך להשלים באופן וירטואלי את הזוגיות (הביט ההפוך מהכתוב) וכאשר מדובר במראה הוא לא צריך כיוון שאין צורך להפוך הביט. נטאפ אינה תומכת בRAID1.

החלוקה שאני מציע היא 10 דיסקים לFILER1 ו2 דיסקים לFILER2. כאשר FILER1 יכיל SPARE וAGGR בRAIDDP, ואילו FILER2 יכיל AGGR בRAID4 ללא SPARE. במצב זה בפיילר 1 יהיה קיים לנו 7 דיסקים לכתיבה כלומר כ3.8TB (בהורדת הWAFL RESERVE) המגובים בRAIDDP עם דיסק SPARE (לעומת 3.2TB במצב הקלאסי) ועוד כ540GB מגובים בRAID4 (שלא קיימים כלל במצב הקודם), בהם אפשר לשים ספריות של משתמשים שרמת החשיבות שלהם נמוכה או לחלופין להקפיד לגבות אותם. מצב זה מגדיל גם את כמות הIOPS שהרייד מסוגל לספק כיוון שכמות הדיסקים גדלה, מאפשר ניצול גבוהה יותר עקב AGGR אחד גדול יותר, ומאפשר יצירת VOLUME גדול יותר.

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

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

קישור לתוכן
שתף באתרים אחרים

  • 4 שבועות מאוחר יותר...

הבעיה עם Netapp שהוא בזבזני מאוד במקום - כלל האצבע אומר שהנפח הזמין נטו הוא 70% (כלומר על כל TB של דיסקים שתרכוש, תקבל 700GB נטו) וזה נכון רק ל-AGGRR'S גדולים - בכמות קטנה של דיסקים הביזבוז גדול יותר, יותר מזה, אם רוצים לנצל את יכולות ה-Snapshot (שהן הסיבה העיקרית להשתמש ב-Netapp) הניצול בפועל יהיה יותר לכיוון של 50%, בעיה נוספת היא ש-Cluster של Netapp מצריך דיסקים מחוברים לשני הראשים, כך שכל ראש משמש כ-Standby לראש השני. אני עובד עם מערכים בינוניים (עשרות TB ) של Netapp כבר שנים ומרוצה מהם, אבל עבור Storage של מספר TB לא הייתי ממליץ עליו, לאחרונה יצא לי להתקין v3700 שעובד בצורה שונה - Cluster של שני ראשים שעובדים active-Active מול אותו מערך דיסקים, כך שאין צורך להקצות VOL0 לכל ראש, המערך הזה עוד לא בייצור כך שאין לי משוב על הביצועים האמיתיים שלו, אבל בסה"כ נראה נחמד ויכול להוות פתרון לא רע ל-Storage עם יתירות לאתרים קטנים.

קישור לתוכן
שתף באתרים אחרים

ה V3700 של , הוא אחיו הקטן של ה V7000.

אכן יש לו 2 "קונטרולרים", אם תסתכל ב performance tab אתה תשים לב ש 1 מ ה nodes משמש בעיקר ל write ו ה 2 ל read כשהם במצב של active acitve.

ה v3700 זה ממש ה entry level של .

אחלה מערך סטורג', נוח מאוד לגדילה.

קישור לתוכן
שתף באתרים אחרים

netapp הוא הסטורג' הגמיש ביותר לדעתי, הבעיה שלו שצריך להבין איך הוא עובד באמת, אחרת תמצא את עצמך עם חמישים אחוז מידע זמין. הסיבה לכך נעוצה בחוסר ההבנה של המונח סנפשוט. יש צורך להבין שסנפשוט הוא חלק מסך המידע הזמין ולכן יש צורך להתייחס אליו ככזה גם במהלך התכנון. למשל אם נתכנן מערכת של 1 טרה ונרצה להקצות 20% סנפשוט נצטרך להקצות לו 1.2TB לכתיבה. בהתחשב בעובדה שנטאפ לוקח כ10% לWAFL RESERVE נבין כי אפילו שני דיסקים 600GB S .

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

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

קישור לתוכן
שתף באתרים אחרים

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

×
  • צור חדש...