Која верзија на фирмверот е „најправилна“ и „работна“? Ако системот за складирање гарантира толеранција на грешки од 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 (Authorized Program Analysis Report) HU02104. Се појавува на следниов начин. Под оптоварување, под одредени околности, кешот почнува да се прелева, а потоа системот оди во заштитен режим, во кој го оневозможува I/O за базенот. Во нашиот случај, изгледаше како да се исклучуваат 3 дискови за RAID група во режим RAID 6. Исклучувањето се случува 6 минути. Следно, пристапот до Томовите во базенот е обновен.
Ако некој не е запознаен со структурата и именувањето на логичките ентитети во контекст на IBM Spectrum Virtualize, сега накратко ќе објаснам.
Структура на логички елементи на системот за складирање
Дисковите се собираат во групи наречени МДиск (Управуван диск). MDisk може да биде класичен RAID (0,1,10,5,6) или виртуелизиран - DRAID (Distributed RAID). Користењето на DRAID ви овозможува да ги зголемите перформансите на низата, бидејќи ... Ќе се користат сите дискови во групата, а времето за обнова ќе се намали, поради фактот што ќе треба да се обноват само одредени блокови, а не сите податоци од неуспешниот диск.
Дистрибуција на податочни блокови низ дисковите кога се користи Distributed RAID (DRAID) во режим RAID-5.
И овој дијаграм ја покажува логиката за тоа како функционира обновата на DRAID во случај на дефект на еден диск:
Логика на обнова на DRAID кога еден диск не успее
Следно, еден или повеќе МДиск формираат таканаречен Pool. Во рамките на истиот базен, не е препорачливо да се користи MDisk со различни нивоа RAID/DRAID на дискови од ист тип. Нема да навлегуваме во ова премногу длабоко, бидејќи ... планираме да го покриеме ова во една од следните статии. Па, всушност, Pool е поделен на томови, кои се претставени со користење на еден или друг блок протокол за пристап до домаќините.
Значи, ние, како резултат на ситуацијата опишана во APAR HU02104, поради логичното откажување на три дискови, МДиск престана да биде функционален, што, пак, резултираше со откажување на Pool и соодветните томови.
Бидејќи овие системи се доста паметни, тие можат да се поврзат со системот за следење на облак базиран на IBM Storage Insights, кој автоматски испраќа барање за услуга до поддршката на IBM доколку се појави проблем. Се креира апликација и специјалистите на IBM од далечина вршат дијагностика и контактираат со корисникот на системот.
Благодарение на ова, проблемот беше решен доста брзо и беше добиена брза препорака од службата за поддршка за ажурирање на нашиот систем на претходно избраниот фирмвер 8.2.1.9, кој во тоа време веќе беше поправен. Тоа потврдува .
Резултати и нашите препораки
Како што вели поговорката: „Сè е добро што добро завршува“. Грешката во фирмверот не предизвика сериозни проблеми - серверите беа обновени што е можно поскоро и без загуба на податоци. Некои клиенти мораа да ги рестартираат виртуелните машини, но генерално бевме подготвени за повеќе негативни последици, бидејќи секојдневно правиме резервни копии на сите инфраструктурни елементи и клиентски машини.
Добивме потврда дека дури и сигурни системи со 99,9999% ветена достапност бараат внимание и навремено одржување. Врз основа на ситуацијата, за себе извлековме голем број заклучоци и ги споделуваме нашите препораки:
-
Неопходно е да се следи објавувањето на ажурирањата, да се проучуваат Белешките за издавање за корекции на потенцијално критичните проблеми и да се извршуваат планираните ажурирања навремено.
Ова е организациска, па дури и сосема очигледна точка, на која, се чини, не вреди да се фокусираме. Сепак, на оваа „рамна почва“ можете лесно да се сопнете. Всушност, токму овој момент ги додаде неволјите опишани погоре. Бидете внимателни при изготвувањето на прописите за ажурирање и следете ја усогласеноста со нив не помалку внимателно. Оваа точка се однесува повеќе на концептот на „дисциплина“.
-
Секогаш е подобро да го задржите системот со најновата верзија на софтверот. Згора на тоа, сегашната не е онаа што има поголема нумеричка ознака, туку таа со подоцнежен датум на издавање.
На пример, IBM ажурира најмалку две софтверски изданија за своите системи за складирање. Во моментот на пишување, ова се 8.2 и 8.3. Ажурирањата за 8.2 излегуваат порано. Слично ажурирање за 8.3 обично се ослободува со мало задоцнување.
Изданието 8.3 има голем број функционални предности, на пример, можност за проширување на МДиск (во режим DRAID) со додавање на еден или повеќе нови дискови (оваа функција се појави од верзијата 8.3.1). Ова е прилично основна функционалност, но во 8.2, за жал, нема таква функција.
-
Ако не е можно да се ажурира поради некоја причина, тогаш за верзии на софтверот Spectrum Virtualize пред верзиите 8.2.1.9 и 8.3.1.0 (каде што грешката опишана погоре е релевантна), за да се намали ризикот од нејзино појавување, препорачува техничката поддршка на IBM ограничување на перформансите на системот на ниво на базен, како што е прикажано на сликата подолу (сликата е направена во русифицираната верзија на GUI). Вредноста од 10000 IOPS е прикажана како пример и е избрана според карактеристиките на вашиот систем.
Ограничување на перформансите за складирање на IBM
-
Неопходно е правилно да се пресмета оптоварувањето на системите за складирање и да се избегне преоптоварување. За да го направите ова, можете да користите или големината на IBM (ако имате пристап до неа), или помошта од партнери или ресурси од трета страна. Императив е да се разбере профилот на оптоварување на системот за складирање, бидејќи Перформансите во MB/s и IOPS варираат во голема мера во зависност од барем следниве параметри:
-
тип на операција: читање или пишување,
-
големина на оперативниот блок,
-
процент на операции за читање и запишување во вкупниот проток на В/И.
Исто така, на брзината на операциите влијае и тоа како се читаат податочните блокови: последователно или по случаен редослед. При извршување на повеќе операции за пристап до податоци на страната на апликацијата, постои концепт на зависни операции. Исто така, препорачливо е да се земе предвид ова. Сето ова може да помогне да се види севкупноста на податоците од бројачите на перформанси на ОС, системот за складирање, серверите/хипервизорите, како и разбирањето на оперативните карактеристики на апликациите, DBMS и другите „потрошувачи“ на ресурсите на дискот.
-
-
И, конечно, не заборавајте да имате ажурирани резервни копии и да работат. Распоредот за резервни копии треба да се конфигурира врз основа на прифатливи RPO вредности за бизнисот, а периодичните проверки на интегритетот на резервните копии треба да се проверат (прилично неколку продавачи на резервни софтвери имаат автоматизирана верификација имплементирана во нивните производи) за да се обезбеди прифатлива вредност на RTO.
Ви благодариме што прочитавте до крај.
Подготвени сме да одговориме на вашите прашања и коментари во коментарите. Исто така, во кои одржуваме редовни промоции (попусти на IaaS и подароци за промотивни кодови до 100% на VPS), пишуваме интересни вести и објавуваме нови написи на блогот Habr.
Извор: www.habr.com