Коя версия на фърмуера е най-добрата и работеща? Ако СХД гарантира устойчивост на откази от 99,9999%, означава ли, че ще работи безпроблемно дори без актуализация на софтуера? Или обратно, за да постигнем максимална устойчивост на откази, трябва винаги да инсталираме най-новия фърмуер? Нека се опитаме да отговорим на тези въпроси, базирайки се на нашия опит.
Кратко въведение
Всички ние разбираме, че всяка версия на софтуера, независимо дали е операционна система или драйвер за някакво устройство, често съдържа недоразвити функции / бъгове и други "особености", които могат или да не "излезнат" до края на експлоатацията на оборудването, или да се "разкрият" само при определени условия. Броят и значимостта на тези нюанси зависят от сложността (функционалността) на софтуера и от качеството на тестването при разработката му.
Често потребителите остават на "от заводския фърмуер" (известната фраза - "работи, значи не пипай") или винаги инсталират най-новата версия (в тяхното разбиране, последната значи най-работеща). Ние обаче използваме друг подход - гледаме бележките за версии за всичкото използвано оборудване и внимателно избираме подходящия фърмуер за всяко устройство.
До този извод стигнахме, така да се каже, с опит. Ще разкажем на нашия пример защо обещаните 99,9999 % надеждност на СХД не означават нищо, ако не следите своевременно актуализациите и описанията на софтуера. Нашият случай ще е подходящ за потребителите на СХД на всякакви производители, тъй като подобна ситуация може да възникне с оборудването на всеки производител.
Избор на нова система за съхранение на данни
В края на миналата година, към нашата инфраструктура добавихме интересна система за съхранение на данни: по-моделът от серията IBM FlashSystem 5000, който при покупката се наричаше Storwize V5010e. В момента той се продава под името FlashSystem 5010, но фактически това е същата хардуерна основа с един и същ Spectrum Virtualize вътре.
Наличието на единна система за управление е, между другото, основното отличие на IBM FlashSystem. При моделите от по-ниския клас тя практически не се различава от моделите с по-висока производителност. Изборът на определен модел просто предлага съответната хардуерна база, чиито характеристики дават възможност за използване на определен функционал или осигуряване на по-високо ниво на мащабируемост. Софтуерът идентифицира хардуерната част и предоставя необходимия и достатъчен функционал за тази платформа.
IBM FlashSystem 5010
Кратко за нашия модел 5010. Това е двуконтролерна блокова система за съхранение на данни от начален клас. Тя може да съдържа дискове NLSAS, SAS и SSD. Разположението на NVMe не е достъпно, тъй като този модел СХД е позициониран за решаване на задачи, за които не е необходима производителността на дисковете NVMe.
СХД беше придобита за съхранение на архивна информация или данни, до които не се достъпва често. Затова стандартният набор от нейния функционал: тиринг (Easy Tier), Thin Provision, беше напълно достатъчен за нас. Производителността на NLSAS дисковете на ниво 1000-2000 IOPS също ни удовлетворяваше напълно.
Нашият опит — как не обновихме фърмуера навреме
Сега за самото обновление на софтуера. В момента на придобиването, системата имаше вече малко остаряла версия на софтуера Spectrum Virtualize, а именно, 8.2.1.3.
Изучихме описанията на фърмуерите и планирахме обновление до 8.2.1.9. Ако бяхме малко по-бързи, тази статия нямаше да съществува — на по-новия фърмуер проблемът нямаше да възникне. Обаче, по определени причини обновлението на тази система бе отложено.
В резултат на малка забавяне в обновлението, се стигна до крайно неприятна ситуация, както е описано в линка: .
Да, в фърмуера на тази версия точно така нареченият APAR (Authorized Program Analysis Report) HU02104 беше актуален. Той се проявява по следния начин. Под натоварване, при определени обстоятелства, кешът започва да се препълва, след което системата влиза в защитен режим, в който деактивира вход-изхода за пул (Pool). В нашия случай изглеждаше като отключване на 3 диска за RAID група в режим RAID 6. Отключването продължава 6 минути. След това достъпът до томовете в пула се възстановява.
Ако някой не е запознат със структурата и именуването на логическите единици в контекста на IBM Spectrum Virtualize, сега ще разкажа кратко.
Структура на логичните елементи на СХД
Дисковете се събират в групи, наречени MDisk (Управляем Диск). MDisk може да представлява класически RAID (0, 1, 10, 5, 6) или виртуализиран – DRAID (Разпределен RAID). Използването на DRAID позволява да увеличите производителността на масива, тъй като ще се използват всички дискове в групата, и да намалите времето за ребилд, благодарение на това, че ще трябва да възстановите само определени блокове, а не всички данни от повредения диск.
Разпределението на данни по дисковете при използване на Разпределен RAID (DRAID) в режим RAID-5.
Тази схема показва логиката на работа на ребилда DRAID в случай на повреда на един диск:
Логика на работа на ребилда DRAID при повреда на един диск
След това един или повече MDisk образуват т.нар. Pool. В рамките на един пул не се препоръчва използването на MDisk с различни нива на RAID/DRAID на дискове от един и същи тип. Няма да навлизаме в подробности, тъй като планираме да разгледаме това в една от следващите статии. И, всъщност, Pool се дели на Тома (Volumes), които се представят по един или друг протокол за блочен достъп към хостовете.
И тъй, в резултат на възникването на ситуацията, описана в APAR HU02104, поради логичен отказ на три диска, спря да функционира MDisk, което от своя страна доведе до отказ в работата на Pool и съответните Тома.
Тъй като тези системи са доста "умни", те могат да бъдат свързани към облачната система за мониторинг IBM Storage Insights, която автоматично, при възникване на неизправност, изпраща заявка за обслужване в службата за поддръжка на IBM. Създава се заявление и специалистите на IBM дистанционно провеждат диагностика и комуникират с потребителя на системата.
Благодарение на това въпросът беше решен доста бързо, и от службата за поддръжка получихме бърза препоръка за обновление на нашата система до вече избраната от нас версия 8.2.1.9, в която този момент вече беше коригиран. Това потвърждава .
Заключения и нашите препоръки
Както се казва: «добро е това, което завършва добре». Проблемът с фърмуера не доведе до сериозни затруднения — работата на сървърите беше възстановена за кратко време и без загуба на данни. При някои клиенти се наложи да рестартираме виртуалните машини, но по принцип бяхме подготвени за по-негативни последици, тъй като ежедневно правим резервни копия на всички елементи от инфраструктурата и клиентските машини.
Получихме потвърждение, че дори надеждните системи с 99,9999% обещана достъпност изискват внимание и навременно обслужване. Въз основа на ситуацията направихме редица изводи и споделяме нашите препоръки:
Важно е да следите за излизането на актуализации, да изучавате Release Notes за приключването на потенциално критични моменти и навременно да извършвате планираните актуализации.
Това е организационен и дори доста очевиден момент, на който, изглежда, не трябва да се акцентира. Въпреки това, на това 'гладко място' можете да се спънете сравнително лесно. Всъщност, именно този момент добави описаните по-горе неприятности. Отнасяйте се много внимателно към съставянето на регламенти за актуализиране и не по-малко внимателно следете за тяхното спазване. Тази точка повече се отнася до понятието 'дисциплина'.
Винаги е по-добре да поддържате системата с актуална версия на софтуера. При това, актуалната не е просто тази с по-висока числова стойност, а именно с по-късна дата на излизане.
Например, 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 (ако имате достъп до него), или от помощта на партньорите, или от външни ресурси. Непременно трябва да разбирате профила на натоварването на системата за съхранение, тъй като производителността в МБ/с и IOPS значително варира в зависимост най-малко от следните параметри:
тип операция: четене или запис,
размер на блока на операцията,
процентното съотношение на операциите четене и запис в общия поток от входно-изходни операции.
Също така, скоростта на изпълнение на операциите влияе как се прочитат блоковете данни: последователно или произволно. При изпълнение на няколко операции за достъп до данни от страна на приложението съществува понятието за зависими операции. Това също е желателно да се вземе предвид. Всичко това може да помогне да се види комплекс от данни от броячи за производителност на ОС, системите за съхранение, сървърите/хипервизорите, както и разбиране на особеностите на работата на приложенията, СУБД и други "консуматори" на дискови ресурси.
И накрая, задължително е да имате резервни копия в актуално и работно състояние. Графикът за резервно копиране трябва да се настройва в зависимост от приемливите за бизнеса стойности RPO и периодично задължително да се проверява целостта на резервните копия (доста много производители на софтуер за резервно копиране реализирали в своите продукти автоматизирана проверка) за осигуряване на приемливо значение RTO.
Благодарим ви, че прочетохте до края.
Готови сме да отговорим на вашите въпроси и коментари. Също така, в която провеждаме редовни акции (отстъпки за IaaS и тегления на промокодове до 100% за VPS), публикуваме интересни новини и анонсираме нови статии в блога на Хабра.
Източник: habr.com
