מדוע חשוב לאמת תוכנה באחסון הזמינות הגבוהה שלך (99,9999%)

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

הקדמה קטנה

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

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

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

בחירת מערכת אחסון חדשה

בסוף השנה שעברה נוספה לתשתית שלנו מערכת אחסון נתונים מעניינת: דגם זוטר מקו IBM FlashSystem 5000, אשר בעת הרכישה נקרא Storwize V5010e. כעת הוא נמכר תחת השם FlashSystem 5010, אך למעשה זהו אותו בסיס חומרה עם אותו Spectrum Virtualize בפנים. 

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

IBM FlashSystem 5010

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

מערכת האחסון נרכשה כדי להכיל מידע ארכיוני או נתונים שאין גישה אליהם לעתים קרובות. לכן, הסט הסטנדרטי של הפונקציונליות שלו הספיק לנו: Tiering (Easy Tier), Thin Provision. גם ביצועים על דיסקים NLSAS ברמה של 1000-2000 IOPS היו מספקים עבורנו.

הניסיון שלנו - איך לא עדכנו את הקושחה בזמן

עכשיו לגבי עדכון התוכנה עצמו. בזמן הרכישה, למערכת כבר הייתה גרסה מעט מיושנת של תוכנת Spectrum Virtualize, כלומר, 8.2.1.3.

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

כתוצאה מכך, עיכוב קל בעדכון הוביל לתמונה מאוד לא נעימה, כמו בתיאור בקישור: https://www.ibm.com/support/pages/node/6172341. 

כן, בקושחה של אותה גרסה מה שנקרא APAR (דוח ניתוח תוכנית מורשה) HU02104 היה רלוונטי. זה מופיע כדלקמן. תחת עומס, בנסיבות מסוימות, המטמון מתחיל לעלות על גדותיו, ואז המערכת עוברת למצב הגנה, שבו היא משביתה את ה-I/O עבור הבריכה. במקרה שלנו זה נראה כמו ניתוק 3 דיסקים לקבוצת RAID במצב RAID 6. הניתוק מתרחש למשך 6 דקות. לאחר מכן, הגישה לכרכים בבריכה משוחזרת.

אם מישהו לא מכיר את המבנה והשמות של ישויות לוגיות בהקשר של IBM Spectrum Virtualize, עכשיו אסביר בקצרה.

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

הדיסקים נאספים לקבוצות הנקראות MDisk (דיסק מנוהל). MDisk יכול להיות RAID קלאסי (0,1,10,5,6) או וירטואלי - DRAID (RAID מבוזר). שימוש ב-DRAID מאפשר לך להגביר את הביצועים של המערך, כי... כל הדיסקים בקבוצה ישמשו, וזמן הבנייה מחדש יקטן, בשל העובדה שרק בלוקים מסוימים יהיה צורך לשחזר, ולא את כל הנתונים מהדיסק הפגום.

הפצה של בלוקי נתונים על פני דיסקים בעת שימוש ב-Distributed RAID (DRAID) במצב RAID-5.

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

ההיגיון של בנייה מחדש של DRAID כאשר דיסק אחד נכשל

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

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

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

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

תוצאות וההמלצות שלנו

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

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

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

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

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

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

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

• אם לא ניתן לעדכן מסיבה כלשהי, אז עבור גרסאות של תוכנת Spectrum Virtualize לפני גרסאות 8.2.1.9 ו-8.3.1.0 (כאשר הבאג המתואר לעיל רלוונטי), כדי להפחית את הסיכון להתרחשותו, התמיכה הטכנית של IBM ממליצה הגבלת ביצועי המערכת ברמת הבריכה, כפי שמוצג באיור למטה (התמונה צולמה בגרסת ה-Russified של ה-GUI). הערך של 10000 IOPS מוצג כדוגמה ונבחר בהתאם למאפייני המערכת שלך.

הגבלת ביצועי האחסון של IBM

• יש צורך לחשב נכון את העומס על מערכות אחסון ולהימנע מעומס יתר. לשם כך, אתה יכול להשתמש ב-IBM sizer (אם יש לך גישה אליו), או בעזרת שותפים או משאבים של צד שלישי. זה הכרחי להבין את פרופיל העומס על מערכת האחסון, כי הביצועים ב-MB/s ו-IOPS משתנים מאוד בהתאם לפרמטרים הבאים לפחות:

  • סוג פעולה: קריאה או כתיבה,

  • גודל בלוק פעולה,

  • אחוז פעולות הקריאה והכתיבה בזרם ה-I/O הכולל.

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

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

תודה שקראת עד הסוף.
אנו מוכנים לענות על שאלותיך והערותיך בהערות. גַם אנו מזמינים אתכם להירשם לערוץ הטלגרם שלנו, בהם אנו מקיימים מבצעים קבועים (הנחות על IaaS ומתנות לקודי קידום עד 100% ב-VPS), כותבים חדשות מעניינות ומודיעים על מאמרים חדשים בבלוג Habr.

מקור: www.habr.com