Коя версия на фърмуера е най-„правилната“ и „работеща“? Ако една система за съхранение гарантира толерантност на грешки от 99,9999%, означава ли това, че тя ще работи без прекъсване дори без актуализация на софтуера? Или, напротив, за да получите максимална устойчивост на грешки, винаги трябва да инсталирате най-новия фърмуер? Ще се опитаме да отговорим на тези въпроси въз основа на нашия опит.
Малко въведение
Всички разбираме, че всяка версия на софтуера, независимо дали е операционна система или драйвер за устройство, често съдържа дефекти/бъгове и други „функции“, които може да не се „появят“ до края на експлоатационния живот на оборудването или да се „отворят“ само при определени условия. Броят и значимостта на такива нюанси зависи от сложността (функционалността) на софтуера и от качеството на тестването по време на неговото разработване.
Често потребителите остават на „фърмуера от фабриката“ (известният „работи, така че не се забърквайте с него“) или винаги инсталират най-новата версия (според тяхното разбиране най-новото означава най-работещото). Ние използваме различен подход - разглеждаме бележките към изданието за всичко използвано оборудване и внимателно изберете подходящия фърмуер за всяко оборудване.
До този извод стигнахме, както се казва, с опит. Използвайки нашия пример за работа, ще ви кажем защо обещаната 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. Ако бяхме малко по-ефективни, тази статия нямаше да съществува - грешката нямаше да се появи на по-нов фърмуер. По определени причини обаче актуализацията на тази система беше отложена.
В резултат на това леко забавяне на актуализацията доведе до изключително неприятна картина, както в описанието на линка: .
Да, във фърмуера на тази версия така нареченият APAR (оторизиран доклад за анализ на програмата) HU02104 беше подходящ. Изглежда, както следва. При натоварване, при определени обстоятелства, кешът започва да се препълва, след което системата преминава в защитен режим, в който деактивира I/O за пула. В нашия случай изглеждаше като прекъсване на връзката на 3 диска за RAID група в режим RAID 6. Прекъсването става за 6 минути. След това се възстановява достъпът до томовете в пула.
Ако някой не е запознат със структурата и именуването на логически обекти в контекста на IBM Spectrum Virtualize, сега ще обясня накратко.
Структура на логическите елементи на системата за съхранение
Дисковете се събират в групи, наречени MDisk (управляван диск). MDisk може да бъде класически RAID (0,1,10,5,6) или виртуализиран - DRAID (Distributed RAID). Използването на DRAID ви позволява да увеличите производителността на масива, защото... Всички дискове в групата ще бъдат използвани и времето за възстановяване ще бъде намалено, поради факта, че само определени блокове ще трябва да бъдат възстановени, а не всички данни от повредения диск.
Разпределение на блокове данни между дискове при използване на Distributed RAID (DRAID) в режим RAID-5.
И тази диаграма показва логиката на това как работи повторното изграждане на DRAID в случай на повреда на един диск:
Логика на DRAID възстановяване, когато един диск се повреди
След това един или повече MDisks образуват така наречения Pool. В рамките на един и същ пул не се препоръчва използването на MDisk с различни RAID/DRAID нива на дискове от един и същи тип. Няма да навлизаме в това твърде дълбоко, защото... планираме да разгледаме това в една от следващите статии. Е, всъщност Pool е разделен на томове, които се представят с помощта на един или друг протокол за блокиране на достъп до хостовете.
И така, ние, в резултат на ситуацията, описана в 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 препоръчва ограничаване на производителността на системата на ниво пул, както е показано на фигурата по-долу (снимката е направена в русифицираната версия на GUI). Стойността от 10000 IOPS е показана като пример и се избира според характеристиките на вашата система.
Ограничаване на производителността на съхранението на IBM
-
Необходимо е правилно да се изчисли натоварването на системите за съхранение и да се избегне претоварването. За да направите това, можете да използвате или IBM sizer (ако имате достъп до него), или помощта на партньори, или ресурси на трети страни. Наложително е да се разбере профилът на натоварване на системата за съхранение, т.к MB/s и IOPS производителността варира значително в зависимост от поне следните параметри:
-
тип операция: четене или запис,
-
размер на операционния блок,
-
процент на операциите за четене и запис в общия I/O поток.
Също така скоростта на операциите се влияе от това как се четат блоковете с данни: последователно или в произволен ред. При извършване на множество операции за достъп до данни от страна на приложението съществува концепцията за зависими операции. Също така е препоръчително да вземете предвид това. Всичко това може да помогне да се види съвкупността от данни от броячите на производителността на операционната система, системата за съхранение, сървърите/хипервайзорите, както и разбирането на работните характеристики на приложенията, СУБД и други „консуматори“ на дискови ресурси.
-
-
И накрая, не забравяйте да имате актуални и работещи резервни копия. Графикът за архивиране трябва да бъде конфигуриран въз основа на приемливи стойности на RPO за бизнеса и трябва да се проверяват периодични проверки на целостта на архивите (доста производители на софтуер за архивиране имат внедрена автоматизирана проверка в своите продукти), за да се осигури приемлива стойност на RTO.
Благодаря ви, че прочетохте до края.
Готови сме да отговорим на вашите въпроси и коментари в коментарите. Също, в които провеждаме редовни промоции (отстъпки за IaaS и подаръци за промоционални кодове до 100% за VPS), пишем интересни новини и обявяваме нови статии в блога на Habr.
Източник: www.habr.com