Дызайн віртуалізаванага ЦАД

Дызайн віртуалізаванага ЦАД

Увядзенне

Інфармацыйная сістэма з пункту гледжання карыстальніка добра вызначаецца ў ДАСТ РВ 51987 – «аўтаматызаваная сістэма, вынікам функцыянавання якой з'яўляецца прадстаўленне выходны інфармацыі для наступнага выкарыстання». Калі разглядаць унутраную структуру, то ў сутнасці любая ІС з'яўляецца сістэмай рэалізаваных у кодзе ўзаемазлучаных алгарытмаў. У шырокім разуменні тэзы Цьюрынга-Чэрча алгарытм (а сл-на ІС) ажыццяўляе трансфармацыю мноства ўваходных дадзеных у мноства выходных дадзеных.
Можна нават сказаць, што ў трансфармацыі ўваходных даных і ёсць сэнс існавання інфармацыйнай сістэмы. Адпаведна каштоўнасць ІС і ўсяго комплексу ІС вызначаецца праз каштоўнасць уваходных і выходных дадзеных.
Таму праектаванне павінна пачынацца і браць за аснову дадзеныя, падладжваючы архітэктуру і метады пад структуру і значнасць дадзеных.

Захоўныя дадзеныя
Ключавым этапам падрыхтоўкі да праектавання з'яўляецца атрыманне характарыстык усіх набораў даных, якія плануюцца да апрацоўкі і захоўвання. Гэтыя характарыстыкі ўключаюць у сябе:
- Аб'ём дадзеных;
- Інфармацыя аб жыццёвым цыкле дадзеных (прырост новых дадзеных, тэрмін жыцця, апрацоўка састарэлых дадзеных);
- Класіфікацыя дадзеных з т.з. уплыву на асноўны бізнэс кампаніі (гэта трыядзе канфідэнцыйнасць, цэласнасць, даступнасць) разам з фінансавымі паказчыкамі (напр. кошт страты дадзеных за апошнюю гадзіну);
- Геаграфія апрацоўкі дадзеных (фізічнае размяшчэнне сістэм апрацоўкі);
- Патрабаванні рэгулятараў па кожным класе дадзеных (напр. ФЗ-152, PCI DSS).

Інфармацыйныя сістэмы

Дадзеныя не толькі захоўваюцца, але і апрацоўваюцца (трансфармуюцца) інфармацыйнымі сістэмамі. Наступным крокам пасля атрымання характарыстык даных з'яўляецца максімальна поўная інвентарызацыя інфармацыйных сістэм, іх архітэктурных асаблівасцей, узаемазалежнасцей і патрабаванняў да інфраструктуры ва ўмоўных адзінках да чатырох відаў рэсурсаў:
- Працэсарная вылічальная магутнасць;
- Аб'ём аператыўнай памяці;
- Патрабаванні да аб'ёму і прадукцыйнасці сістэмы захоўвання дадзеных;
- Патрабаванні да сеткі перадачы дадзеных (вонкавыя каналы, каналы паміж кампанентамі ІС).
Патрабаванні пры гэтым павінны быць на кожны сэрвіс/мікрасэрвіс у складзе ІС.
Асобна неабходна адзначыць абавязковую для карэктнага праектавання наяўнасць дадзеных па ўплыве ІС на асноўны бізнэс кампаніі ў выглядзе кошту прастою ІС (рублёў у гадзіну).

Мадэль пагроз

У абавязковым парадку павінна быць у наяўнасці фармальная мадэль пагроз, ад якіх плануецца абараняць дадзеныя/сэрвісы. Пры гэтым мадэль пагроз уключае ў сябе не толькі аспекты канфідэнцыйнасці, але і цэласнасці і даступнасці. Г.зн. напрыклад:
- Выхад са строю фізічнага сервера;
- Выхад са строю камутатара top-of-the-rack;
- Разрыў аптычнага канала сувязі паміж ЦАД;
- Выхад са строю аператыўнай СГД цалкам.
У некаторых выпадках мадэлі пагрозаў пішуцца не толькі для інфраструктурных кампанентаў, але і для канкрэтных ІС ці іх кампанентаў, як, напрыклад, адмова СКБД з лагічным разбурэннем структуры дадзеных.
Усе рашэнні ў рамках праекту па абароне супраць не апісанай пагрозы з'яўляюцца залішнімі.

Патрабаванні рэгулятараў

Калі апрацоўваныя дадзеныя пападаюць пад дзеянне адмысловых правіл, усталёўваных рэгулятарамі, у абавязковым парадку неабходна інфармацыя аб наборах дадзеных і правілах апрацоўкі/захоўванні.

Мэтавыя паказчыкі RPO / RTO

Праектаванне любога віду абароны патрабуе наяўнасці паказчыкаў мэтавай страты даных і мэтавага часу аднаўлення сэрвісу для кожнай з апісаных пагроз.
Пры гэтым у ідэале RPO і RTO павінны мець асацыіраваныя кошты страты дадзеных і прастою ў адзінку часу.

Дызайн віртуалізаванага ЦАД

Падзел на пулы рэсурсаў

Пасля збору ўсёй першаснай уступнай інфармацыі першым крокам з'яўляецца групоўка набораў дадзеных і ІС у пулы, зыходзячы з мадэляў пагроз і патрабаванняў рэгулятараў. Вызначаецца выгляд падзелу розных пулаў - праграмна на ўзроўні сістэмнага ПА або фізічна.
Прыклады:
- Контур, які апрацоўвае персанальныя дадзеныя, цалкам фізічна аддзелены ад астатніх сістэм;
- Рэзервовыя копіі захоўваюцца на асобнай СХД.

Пры гэтым пулы могуць быць з няпоўнай незалежнасцю, напрыклад, вызначаецца два пулы вылічальных рэсурсаў (працэсарная магутнасць + аператыўная памяць), якія выкарыстоўваюць адзіны пул захоўвання дадзеных і адзіны пул рэсурсаў перадачы дадзеных.

Працэсарная магутнасць

Дызайн віртуалізаванага ЦАД

Абстрактныя патрэбнасці ў працэсарнай магутнасці віртуалізаванага ЦАД вымяраецца ў колькасці віртуальных працэсараў (vCPU) і каэфіцыенце іх кансалідацыі на фізічных працэсарах (pCPU). У дадзеным канкрэтным выпадку 1 pCPU = 1 фізічнае ядро ​​працэсара (без уліку Hyper-Threading). Колькасць vCPU сумуецца па ўсіх вызначаных пулам рэсурсаў (кожны з якіх можа мець свой каэфіцыент кансалідацыі).
Каэфіцыент кансалідацыі для нагружаных сістэм атрымліваюць эмпірычным шляхам, зыходзячы з ужо існуючай інфраструктуры, або пры пілотнай усталёўцы і нагрузачным тэставанні. Для ненагружаных сістэм ужываюцца "best practice". У прыватнасці, VMware заве сярэднім каэфіцыентам 8:1.

Аператыўная памяць

Агульнае запатрабаванне ў аператыўнай памяці атрымліваецца шляхам простага падсумоўвання. Выкарыстанне перападпіскі па аператыўнай памяці не рэкамендуецца.

Рэсурсы захоўвання

Патрабаванні па рэсурсах захоўвання атрымліваюцца шляхам простага сумавання ўсіх пулаў па аб'ёме і прадукцыйнасці.
Патрабаванні па прадукцыйнасці выяўляюцца ў IOPS у спалучэнні з сярэднім суадносінамі чытанне/запіс і пры неабходнасці максімальнай затрымкай водгуку.
Асобна павінны быць указаны патрабаванні па забеспячэнні якасці абслугоўвання (QoS) для канкрэтных пулаў ці сістэм.

Рэсурсы сеткі перадачы даных

Патрабаванні па сетцы перадачы дадзеных атрымліваюцца шляхам простага сумавання ўсіх пулаў прапускной здольнасці.
Асобна павінны быць указаны патрабаванні па забеспячэнні якасці абслугоўвання (QoS) і затрымак (RTT) для канкрэтных пулаў або сістэм.
У рамках патрабаванняў да рэсурсаў сеткі перадачы дадзеных гэтак жа паказваюцца патрабаванні па ізаляцыі і/ці шыфраванню сеткавага трафіку і пераважным механізмам (802.1q, IPSec і т.д.)

Выбар архітэктуры

У рамках дадзенага кіраўніцтва не разглядаецца іншы выбар, акрамя архітэктуры x86 і 100% віртуалізацыі сервераў. Таму выбар архітэктуры вылічальнай падсістэмы зводзіцца да выбару платформы сервернай віртуалізацыі, формаў-фактару сервераў і агульных патрабаванняў па канфігурацыі сервераў.

Ключавым момантам выбару з'яўляецца вызначанасць у выкарыстанні класічнага падыходу з падзелам функцый апрацоўкі, захоўванні і перадачы дадзеных ці канвергентнага.

Класічная архітэктура разумее выкарыстанне інтэлектуальных вонкавых падсістэм захоўвання і перадачы дадзеных, у той час як серверы прыўносяць у агульны пул фізічных рэсурсаў толькі працэсарную магутнасць і аператыўную памяць. У лімітавым выпадку серверы становяцца цалкам ананімнымі, якія не маюць не толькі ўласных дыскаў, але нават сістэмнага ідэнтыфікатара. У гэтым выпадку выкарыстоўваецца загрузка АС ці гіпервізара з убудаваных флэш носьбітаў або з вонкавай сістэмы захоўвання дадзеных (boot from SAN).
У рамках класічнай архітэктуры выбар паміж лёзамі (blade) і стойкавымі (rack) ажыццяўляецца першым чынам з наступных прынцыпаў:
- Эканамічная эфектыўнасць (у сярэднім стойкавыя серверы танней);
- Вылічальная шчыльнасць (у ляз вышэй);
- Энергаспажыванне і цеплавылучэнне (у ляз вышэй удзельная на юніт);
- Маштабаванасць і кіравальнасць (ляза ў цэлым патрабуе менш намаганняў пры вялікіх усталёўках);
- Выкарыстанне карт пашырэння (для лёзаў вельмі абмежаваны выбар).
Канвергентная архітэктура (Таксама вядомая як гіперканвергентная) мяркуе сумяшчэнне функцый апрацоўкі і захоўванні дадзеных, што вядзе да выкарыстання лакальных дыскаў сервераў і як следства адмове ад формаў-фактару класічных лёзаў. Для канвергентных сістэм выкарыстоўваюцца альбо стойкавыя серверы, альбо кластарныя сістэмы, якія сумяшчаюць у адзіным корпусе некалькі сервераў-лёзаў і лакальныя дыскі.

CPU / Memory

Для карэктнага разліку канфігурацыі трэба разумець тып нагрузкі для асяроддзя ці кожнага з незалежных кластараў.
CPU bound – асяроддзе, абмежаванае па прадукцыйнасці працэсарнай магутнасцю. Даданне аператыўнай памяці нічога не зменіць з пункта гледжання прадукцыйнасці (колькасці ВМ на сервер).
Memory bound - асяроддзе, абмежаванае аператыўнай памяццю. Большая колькасць аператыўнай памяці на серверы дазваляе запусціць большую колькасць ВМ на сервер.
GB / MHz (GB / pCPU) - сярэднія суадносіны спажывання дадзенай канкрэтнай нагрузкай аператыўнай памяці і працэсарнай магутнасці. Можа выкарыстоўвацца для разлікаў неабходнага аб'ёму памяці пры зададзенай прадукцыйнасці і наадварот.

Разлік канфігурацыі сервера

Дызайн віртуалізаванага ЦАД

Для пачатку неабходна вызначыць усе віды нагрузкі і прыняць рашэнне аб сумяшчэнні ці падзеле розных вылічальных пулаў па розных кластарах.
Далей для кожнага з вызначаных кластараў вызначаецца суадносіны GB/MHz пры вядомай загадзя нагрузцы. Калі нагрузка не вядома загадзя, але ёсць прыкладнае разуменне ўзроўню загрузкі працэсарнай магутнасці, можна выкарыстоўваць стандартныя каэфіцыенты vCPU:pCPU для пераводу патрабаванняў пулаў у фізічныя.

Для кожнага кластара суму патрабаванняў пулаў vCPU дзелім на каэфіцыент:
vCPUсум / vCPU:pCPU = pCPUсум - патрабаваную колькасць фіз. ядраў
pCPUсумм / 1.25 = pCPUht - колькасць ядраў з папраўкай на Hyper-Threading
Выкажам здагадку, што неабходна зрабіць разлік кластара на 190 ядраў / 3.5ТБ АЗП. Пры гэтым прымаем мэтавую 50% загрузку працэсарнай магутнасці і 75% па аператыўнай памяці.

pCPU
190
CPU util
50%

Mem
3500
Mem util
75%

Разетка
Core
Srv / CPU
Srv Mem
Srv / Mem

2
6
25,3
128
36,5

2
8
19,0
192
24,3

2
10
15,2
256
18,2

2
14
10,9
384
12,2

2
18
8,4
512
9,1

У дадзеным выпадку заўсёды выкарыстоўваем акругленне да найблізкага цэлага ўгару (=ROUNDUP(A1;0)).
З табліцы становіцца відавочна, што збалансаванымі пад мэтавыя паказчыкі з'яўляюцца некалькі канфігурацый сервераў:
- 26 сервераў 2 * 6c / 192 GB
- 19 сервераў 2 * 10c / 256 GB
- 10 сервераў 2 * 18c / 512 GB

Выбар з гэтых канфігурацый у далейшым неабходна рабіць зыходзячы з дадатковых фактараў, як напрыклад цеплавы пакет і даступнае астуджэнне, ужо выкарыстоўваныя серверы, ці кошт.

Асаблівасці выбару канфігурацыі сервера

Шырокія ВМ. Пры неабходнасці размяшчэння шырокіх ВМ (параўнальных з 1 вузлом NUMA і больш) рэкамендуецца па магчымасці выбіраць сервер са канфігурацыяй, якая дазваляе такім ВМ застацца ў межах NUMA вузла. Пры вялікай колькасці шырокіх ВМ узнікае небяспека фрагментавання рэсурсаў кластара, і ў гэтым выпадку выбіраюцца серверы, якія дазваляюць размясціць шырокія ВМ максімальна шчыльна.

Памер дамена адзінкавай адмовы.

Выбар памеру сервера таксама ажыццяўляецца з прынцыпу мінімізацыі дамена адзінкавай адмовы. Напрыклад, пры выбары паміж:
- 3 x 4 * 10c / 512 GB
- 6 x 2 * 10c / 256 GB
Пры іншых роўных неабходна выбіраць другі варыянт, паколькі пры выхадзе аднаго сервера са строю (ці абслугоўванні) губляецца не 33% рэсурсаў кластара, а 17%. Сапраўды гэтак жа ўдвая змяншаецца колькасць ВМ і ІС, на якіх адбілася аварыя.

Разлік класічнай СХД па прадукцыйнасці

Дызайн віртуалізаванага ЦАД

Класічная СХД заўсёды разлічваецца па горшым варыянце (worst case scenario), выключаючы ўплыў аператыўнага кэша і аптымізацыі аперацый.
У якасці базавых паказчыкаў прадукцыйнасці прыманы механічную прадукцыйнасць з дыска (IOPSdisk):
- 7.2k - 75 IOPS
- 10k - 125 IOPS
- 15k - 175 IOPS

Далей колькасць дыскаў у дыскавым пуле разлічваецца па наступнай формуле: = TotalIOPS * (RW + (1-RW) * RAIDPen) / IOPSdisk. Дзе:
- TotalIOPS – сумарная патрабаваная прадукцыйнасць у IOPS з дыскавага пула
- RW - працэнтная доля аперацый чытання
- RAIDpen - RAID penalty для абранага ўзроўню RAID

Падрабязней пра прыладу RAID і RAID Penalty распавядаецца тут. Прадукцыйнасць СХД. Частка першая. и Прадукцыйнасць СХД. Частка другая. и Прадукцыйнасць СХД. Частка трэцяя

Зыходзячы з атрыманай колькасці дыскаў разлічваюцца магчымыя варыянты, якія задавальняюць патрабаванням па ёмістасці захоўвання, у тым ліку варыянты з шматузроўневым захоўваннем.
Разлік сістэм з выкарыстаннем SSD у якасці ўзроўню захоўвання разглядаецца асобна.
Асаблівасці разліку сістэм з Flash Cache

Флэш-кэш - агульная назва для ўсіх фірмовых тэхналогій выкарыстання флэш-памяці ў якасці кэша другога ўзроўню. Пры выкарыстанні флэш кэша СХД як правіла разлічваецца для забеспячэння з магнітных дыскаў якая ўсталявалася нагрузкі, у той час як пікавую абслугоўвае кэш.
Пры гэтым неабходна разумець профіль нагрузкі і ступень лакалізацыі зваротаў да блокаў тамоў захоўвання. Флэш кэш - тэхналогія для нагрузак з высокай лакалізацыяй запытаў, і практычна непрымяняльная для раўнамерна нагружаных тамоў (як напрыклад для сістэм аналітыкі).

Разлік гібрыдных сістэм low-end / mid-range

Гібрыдныя сістэмы ніжняга і сярэдняга класаў выкарыстоўваюць шматузроўневае захоўванне з перасоўваннем дадзеных паміж узроўнямі па раскладзе. Пры гэтым памер блока шматузроўневага захоўвання ў лепшых мадэляў складае 256 МБ. Дадзеныя асаблівасці не дазваляюць лічыць тэхналогію шматузроўневага захоўвання тэхналогіяй падвышэння прадукцыйнасці, як памылкова лічыцца шматлікімі. Шматузроўневае захоўванне ў сістэмах ніжняга і сярэдняга класаў - гэта тэхналогія аптымізацыі кошту захоўвання для сістэм з выяўленай нераўнамернасцю нагрузкі.

Для шматузроўневага захоўвання разлічваецца перш за ўсё прадукцыйнасць па верхнім узроўні, у той час як ніжні ўзровень захоўвання лічыцца толькі якія ўносяць недастатковую ёмістасць захоўвання. Для гібрыднай шматузроўневай сістэмы абавязкова выкарыстанне тэхналогіі флэш кэша для шматузроўневага пула з мэтай кампенсацыі прасадкі прадукцыйнасці для раптоўна якія нагрэліся дадзеных з ніжняга ўзроўня.

Выкарыстанне SSD у шматузроўневым дыскавым пуле

Дызайн віртуалізаванага ЦАД

Выкарыстанне SSD у шматузроўневым дыскавым пуле мае варыяцыі, у залежнасці ад асаблівасцяў рэалізацыі алгарытмаў флэш кэша ў дадзенага вытворцы.
Агульная практыка палітыкі захоўвання для дыскавага пула з SSD узроўнем - SSD first.
Read Only Flash Cache. Для флэш кэша толькі на чытанне ўзровень захоўвання на SSD з'яўляецца пры значнай лакалізацыі аперацый запісу па-за залежнасцю ад кэша.
Read / Write Flash Cache. У выпадку з флэш кэшам на запіс спачатку ўсталёўваецца максімальны аб'ём кэша, а ўзровень захоўвання на SSD з'яўляецца толькі пры недастатковасці памеру кэша для абслугоўвання ўсёй лакалізаванай нагрузкі.
Разлік прадукцыйнасці SSD і кэша вырабляецца кожны раз зыходзячы з рэкамендацый вытворцы, але заўсёды для найгоршага варыянту.

Крыніца: habr.com

Дадаць каментар