چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنید

چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنید

کدام نسخه سیستم عامل "صحیح" و "کارساز" است؟ اگر یک سیستم ذخیره سازی تحمل خطا 99,9999% را تضمین کند، آیا به این معنی است که حتی بدون به روز رسانی نرم افزار بدون وقفه کار می کند؟ یا برعکس، برای به دست آوردن حداکثر تحمل خطا، همیشه باید آخرین سیستم عامل را نصب کنید؟ ما سعی خواهیم کرد با توجه به تجربه خود به این سوالات پاسخ دهیم.

معرفی کوچک

همه ما می‌دانیم که هر نسخه از نرم‌افزار، خواه یک سیستم‌عامل یا یک درایور برای یک دستگاه باشد، اغلب حاوی نقص‌ها/اشکال‌ها و «ویژگی‌های» دیگری است که ممکن است تا پایان عمر تجهیزات «ظاهر» نشوند، یا «باز» شوند. فقط تحت شرایط خاص تعداد و اهمیت چنین تفاوت هایی به پیچیدگی (عملکردی) نرم افزار و کیفیت آزمایش در طول توسعه آن بستگی دارد. 

اغلب، کاربران روی «سیستم‌افزار کارخانه‌ای» می‌مانند (معروف «این کار می‌کند، پس با آن کار نکنید») یا همیشه آخرین نسخه را نصب می‌کنند (در درک آنها، آخرین به معنای کارآمدترین است). ما از یک رویکرد متفاوت استفاده می کنیم - ما به یادداشت های انتشار برای هر چیزی که استفاده می شود نگاه می کنیم در ابر mClouds تجهیزات و با دقت سیستم عامل مناسب برای هر قطعه از تجهیزات را انتخاب کنید.

به قول خودشان با تجربه به این نتیجه رسیدیم. با استفاده از مثال عملکرد خود، به شما خواهیم گفت که چرا اگر شما به‌سرعت به‌روزرسانی‌ها و توضیحات نرم‌افزار را نظارت نکنید، قابلیت اطمینان 99,9999% سیستم‌های ذخیره‌سازی هیچ معنایی ندارد. مورد ما برای کاربران سیستم های ذخیره سازی از هر فروشنده مناسب است، زیرا وضعیت مشابهی می تواند با سخت افزار هر سازنده ای اتفاق بیفتد.

انتخاب یک سیستم ذخیره سازی جدید

در پایان سال گذشته، یک سیستم ذخیره سازی اطلاعات جالب به زیرساخت ما اضافه شد: یک مدل جوان از خط IBM FlashSystem 5000، که در زمان خرید Storwize V5010e نام داشت. اکنون با نام FlashSystem 5010 فروخته می شود، اما در واقع همان پایه سخت افزاری با همان Spectrum Virtualize در داخل است. 

وجود یک سیستم مدیریت یکپارچه، به هر حال، تفاوت اصلی بین IBM FlashSystem است. برای مدل‌های سری جوان‌تر، عملاً تفاوتی با مدل‌های تولیدی‌تر ندارد. انتخاب یک مدل خاص فقط پایه سخت افزاری مناسبی را فراهم می کند که ویژگی های آن امکان استفاده از یک یا آن عملکرد یا ارائه سطح بالاتری از مقیاس پذیری را فراهم می کند. این نرم افزار سخت افزار را شناسایی کرده و عملکرد لازم و کافی را برای این پلتفرم فراهم می کند.

چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنید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 آشنا نیست، اکنون به طور خلاصه توضیح خواهم داد.

چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنیدساختار عناصر منطقی سیستم ذخیره سازی

دیسک ها در گروه هایی به نام MDisk (دیسک مدیریت شده) جمع آوری می شوند. MDisk می تواند یک RAID کلاسیک (0,1,10,5,6،XNUMX،XNUMX،XNUMX،XNUMX) یا مجازی شده - DRAID (RAID توزیع شده) باشد. استفاده از DRAID به شما امکان می دهد عملکرد آرایه را افزایش دهید، زیرا ... از همه دیسک‌های گروه استفاده می‌شود و زمان بازسازی کاهش می‌یابد، به این دلیل که فقط بلوک‌های خاصی نیاز به بازیابی دارند و نه همه داده‌های دیسک خراب.

چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنیدتوزیع بلوک های داده در بین دیسک ها هنگام استفاده از RAID توزیع شده (DRAID) در حالت RAID-5.

و این نمودار منطق نحوه عملکرد بازسازی DRAID را در صورت خرابی یک دیسک نشان می دهد:

چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنیدمنطق بازسازی DRAID هنگامی که یک دیسک از کار می افتد

در مرحله بعد، یک یا چند MDdisk به اصطلاح Pool را تشکیل می دهند. در یک استخر، استفاده از MDisk با سطوح مختلف RAID/DRAID روی دیسک‌هایی از همان نوع توصیه نمی‌شود. ما خیلی عمیق وارد این موضوع نمی شویم، زیرا ... ما قصد داریم در یکی از مقالات زیر به این موضوع بپردازیم. خوب، در واقع، Pool به Volume تقسیم می شود که با استفاده از یک یا آن پروتکل دسترسی بلوک به هاست ارائه می شود.

بنابراین، ما، به عنوان یک نتیجه از وضعیت شرح داده شده در APAR HU02104، به دلیل خرابی منطقی سه دیسک، MDisk از کار افتاد که به نوبه خود منجر به خرابی Pool و Volume های مربوطه شد.

از آنجایی که این سیستم ها کاملاً هوشمند هستند، می توانند به سیستم مانیتورینگ مبتنی بر فضای ابری 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 توصیه می‌کند. محدود کردن عملکرد سیستم در سطح استخر، همانطور که در شکل زیر نشان داده شده است (تصویر در نسخه روسی شده رابط کاربری گرافیکی گرفته شده است). مقدار 10000 IOPS به عنوان مثال نشان داده شده است و با توجه به ویژگی های سیستم شما انتخاب می شود.

چرا مهم است که نرم افزار را در فضای ذخیره سازی با در دسترس بودن بالا (99,9999%) اعتبار سنجی کنیدمحدود کردن عملکرد ذخیره سازی IBM

  • لازم است بار روی سیستم های ذخیره سازی به درستی محاسبه شود و از اضافه بار جلوگیری شود. برای انجام این کار، می توانید از سایزر IBM (در صورت دسترسی به آن)، یا کمک شرکا یا منابع شخص ثالث استفاده کنید. درک مشخصات بار در سیستم ذخیره سازی ضروری است، زیرا عملکرد در MB/s و IOPS بسته به حداقل پارامترهای زیر بسیار متفاوت است:

    • نوع عملیات: خواندن یا نوشتن،

    • اندازه بلوک عملیات،

    • درصد عملیات خواندن و نوشتن در کل جریان ورودی/خروجی.

    همچنین، سرعت عملیات تحت تأثیر نحوه خواندن بلوک های داده قرار می گیرد: به صورت متوالی یا تصادفی. هنگام انجام چندین عملیات دسترسی به داده در سمت برنامه، مفهوم عملیات وابسته وجود دارد. همچنین توصیه می شود این را در نظر بگیرید. همه اینها می تواند به دیدن کل داده ها از شمارنده های عملکرد سیستم عامل، سیستم ذخیره سازی، سرورها/هایپروایزرها، و همچنین درک ویژگی های عملیاتی برنامه ها، DBMS ها و سایر "مصرف کنندگان" منابع دیسک کمک کند.

  • و در نهایت، مطمئن شوید که نسخه های پشتیبان به روز و کار می کنند. برنامه پشتیبان‌گیری باید بر اساس مقادیر RPO قابل قبول برای کسب‌وکار پیکربندی شود، و بررسی‌های دوره‌ای یکپارچگی پشتیبان‌گیری‌ها باید تأیید شود (تعدادی از فروشندگان نرم‌افزار پشتیبان تأیید خودکار را در محصولات خود پیاده‌سازی کرده‌اند) تا از مقدار RTO قابل قبول اطمینان حاصل شود.

ممنون که تا آخر خواندید.
ما آماده پاسخگویی به سوالات و نظرات شما در نظرات هستیم. همچنین از شما دعوت می کنیم در کانال تلگرام ما عضو شوید، که در آن تبلیغات منظم (تخفیف در IaaS و هدایا برای کدهای تبلیغاتی تا 100٪ در VPS) برگزار می کنیم، اخبار جالب می نویسیم و در وبلاگ هابر مقالات جدید را اعلام می کنیم.

منبع: www.habr.com

اضافه کردن نظر