Якая версія прашыўкі самая "правільная" і "працоўная"? Калі СГД гарантуе адмоваўстойлівасць на 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 (Managed Disk). MDisk можа ўяўляць сабой класічны RAID (0,1,10,5,6) або віртуалізаваны - DRAID (Distributed RAID). Выкарыстанне DRAID дазваляе павялічыць прадукцыйнасць масіва, т.я. будуць выкарыстоўвацца ўсе дыскі групы, і паменшыць час рэбілда, дзякуючы таму, што трэба будзе аднаўляць толькі пэўныя блокі, а не ўсе дадзеныя з які выйшаў з ладу дыска.
Размеркаванне блокаў дадзеных па дысках пры выкарыстанні Distributed 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