Въведение
Информационната система от гледна точка на потребителя се определя добре в ГОСТ РВ 51987 — «автоматизирана система, чийто резултат от функционирането е предоставянето на изходна информация за последваща употреба». Ако разгледаме вътрешната структура, всъщност всяка ИС е система от взаимосвързани алгоритми, реализирани в код. В широкия смисъл на тезиса на Тюринг-Чърч, алгоритъмът (а следователно и ИС) осъществява трансформация на множество входни данни в множество изходни данни.
Може дори да се каже, че смисълът на съществуването на информационната система е в трансформацията на входните данни. Съответно ценността на ИС и целия комплекс от ИС се определя чрез ценността на входните и изходните данни.
Изхождайки от това, проектирането трябва да започне и да се основава на данните, адаптирайки архитектурата и методите към структурата и значимостта на данните.
Съхранявани данни
Ключов етап в подготовката за проектиране е получаването на характеристики на всички набори от данни, планирани за обработка и съхранение. Тези характеристики включват:
— Обем на данните;
— Информация за жизнения цикъл на данните (прираст на нови данни, срок на живот, обработка на остарели данни);
— Класификация на данните от гледна точка на влияние върху основния бизнес на компанията (т.н. триада: конфиденциалност, цялостност, достъпност) заедно с финансовите показатели (напр. стойността на загуба на данни за последния час);
— География на обработка на данните (физическо местоположение на системите за обработка);
— Изисквания на регулаторите за всяка категория данни (напр. ФЗ-152, PCI DSS).
Информационни системи
Данните не само се съхраняват, но и се обработват (трансформират) от информационните системи. Следващата стъпка след получаването на характеристиките на данните е максимално пълна инвентаризация на информационните системи, техните архитектурни особености, взаимозависимости и изисквания към инфраструктурата в условни единици към четири вида ресурси:
— Изчислителна мощност на процесора;
— Обем на оперативната памет;
— Изисквания към обема и производителността на системата за съхранение на данни;
— Изисквания за мрежа за предаване на данни (външни канали, канали между компонентите на ИС).
Изискванията за това трябва да бъдат за всяка услуга/микросервис в състава на ИС.
Поотделно трябва да се отбележи, че е задължително за правилното проектиране наличието на данни за влиянието на ИС върху основния бизнес на компанията под формата на разходите за простоя на ИС (рубли на час).
Модел на заплахите
Задължително трябва да има формален модел на заплахи, от които се планира защита на данните/услугите. При това моделът на заплахите включва не само аспекти на конфиденциалността, но и на цялостността и достъпността. Т.е. например:
— Изпадане от строя на физическия сървър;
— Изпадане от строя на комутатора top-of-the-rack;
— Прекъсване на оптичния канал за връзка между ЦОД;
— Изпадане от строя на оперативната СХД изцяло.
В някои случаи моделите на заплахи се пишат не само за инфраструктурни компоненти, но и за конкретни ИС или техните компоненти, както например отказ на СУБД с логическо разрушаване на структурата на данните.
Всички решения в рамките на проекта за защита срещу неописаната заплаха са излишни.
Изисквания на регулатори
Ако обработваните данни попадат под действие на специални правила, установени от регулаторите, задължително е наличието на информация за набори от данни и правила за обработка/съхранение.
Целеви показатели RPO / RTO
Проектирането на всякакъв вид защита изисква наличието на показатели за целева загуба на данни и целево време за възстановяване на услугата за всяка от описаните заплахи.
В идеалния случай RPO и RTO трябва да имат свързани стойности за загуба на данни и простой в единица време.
Разделение на пулове ресурси
След събиране на цялата първоначална информация, първата стъпка е групиране на наборите от данни и ИС в пулове, въз основа на моделите на заплахи и изискванията на регулаторите. Определя се видът на разделението на различните пулове – софтуерно на ниво системен софтуер или физически.
Примери:
— Контурът, обработващ лични данни, е напълно физически отделен от останалите системи;
— Резервните копия се съхраняват на отделна СХД.
При това пуловете могат да бъдат с непълна независимост, например, определят се два пула изчислителни ресурси (процесорна мощност + оперативна памет), които използват единен пул за съхранение на данни и единен пул за ресурси за предаване на данни.
Процесорна мощност
Абстрактните нужди от процесорна мощност на виртуализирания ЦОД се измерват в броя на виртуалните процесори (vCPU) и коефициента на техния консолидация на физическите процесори (pCPU). В конкретния случай 1 pCPU = 1 физическо ядро на процесора (без да се отчита Hyper-Threading). Броят на vCPU се сумира за всички определени ресурси (всеки от които може да има свой собствен коефициент на консолидация).
Коефициентът на консолидация за натоварени системи се получава емпирично, на база на вече съществуващата инфраструктура или при пилотно инсталиране и натоварващо тестване. За ненатоварени системи се прилагат „най-добри практики“. Например, VMware посочва среден коефициент 8:1.
Оперативна памет
Общата необходимост от оперативна памет се изчислява чрез проста сума. Използването на пренасочване на оперативната памет не се препоръчва.
Ресурси за съхранение
Изискванията за ресурси за съхранение се получават чрез проста сума на всички пулове по обем и производителност.
Изискванията за производителност се изразяват в IOPS в комбинация със средно отношение на четене/запис и при необходимост максимална латентност на отговора.
Отделно трябва да бъдат посочени изискванията за осигуряване на качество на обслужване (QoS) за конкретни пулове или системи.
Ресурси за мрежова предавателна информация
Изискванията за мрежова предавателна информация се получават чрез проста сума на всички пулове с пропускателна способност.
Отделно трябва да бъдат посочени изискванията за осигуряване на качество на обслужване (QoS) и латентности (RTT) за конкретни пулове или системи.
В рамките на изискванията за ресурси на мрежовата предавателна информация също така се посочват изискванията за изолация и/или криптиране на мрежовия трафик и предпочитаните механизми (802.1q, IPSec и т.н.)
Избор на архитектура
В рамките на това ръководство не се разглежда друг избор освен архитектурата x86 и 100% виртуализация на сървърите. Следователно, изборът на архитектура на изчислителната подсистема се свежда до избора на платформа за виртуализация на сървърите, форм-фактор на сървърите и общи изисквания за конфигурация на сървърите.
Ключовата точка при избора е определеността в използването на класическия подход с разделение на функции за обработка, съхранение и предаване на данни или конвергентен подход.
Класическа архитектура предполагае използването на интелигентни външни подсистеми за съхранение и предаване на данни, докато сървърите допринасят за общия пул от физически ресурси единствено с процесорна мощност и оперативна памет. В краен случай сървърите стават напълно анонимни, без собствени дискове или дори системен идентификационен номер. В този случай се използва зареждане на ОС или хипервизор от вградени флаш носители или от външна система за съхранение на данни (boot from SAN).
В рамките на класическата архитектура изборът между лезвийни (blade) и стоечни (rack) сървъри се прави преди всичко на базата на следните принципи:
— Икономическа ефективност (във Average стойностите, стоечните сървъри са по-евтини);
— Комплексност на изчисленията (при лезвиите е по-висока);
— Енергопотребление и топлинно отделяне (при лезвиите е по-високо на единица);
— Масштабируемост и управление (лезвиите изискват по-малко усилия при големи инсталации);
— Използване на разширителни карти (за лезвийни сървъри наличният избор е много ограничен).
Конвергентна архитектура (също известна като хиперконвергентна) предполага комбиниране на функции за обработка и съхранение на данни, което води до използването на локални дискове в сървърите и в резултат отказ от форм-фактора на класическите лезвия. За конвергентни системи се използват или стоечни сървъри, или клъстерни системи, които обединяват в един корпус няколко сървъра-лезвия и локални дискове.
CPU / Памет
За правилно изчисление на конфигурацията е необходимо да се разбере типът натоварване за средата или всяко от независимите клъстери.
CPU bound – среда, ограничена от производителността на процесорната мощност. Добавянето на оперативна памет не променя нищо по отношение на производителността (броя на VM на сървъра).
Memory bound – среда, ограничена от оперативната памет. По-голямото количество оперативна памет на сървъра позволява пускането на повече VM на сървъра.
GB / MHz (GB / pCPU) – средно съотношение на потребление на оперативна памет и процесорна мощност от конкретно натоварване. Може да се използва за изчисления на необходимия обем памет при зададена производителност и обратно.
Изчисление на конфигурацията на сървър
За начало е необходимо да се определят всички видове натоварване и да се вземе решение за комбиниране или разделение на различни изчислителни пулове по различни клъстери.
След това за всеки от определените клъстери се определя съотношението GB / MHz при известна предварително натовареност. Ако натоварването не е познато предварително, но има приблизителна представа за нивото на натовареност на процесорната мощност, може да се използват стандартни коефициенти vCPU:pCPU за превод на изискванията на пуловете в физически.
За всеки клъстер, сумата на изискванията на пуловете vCPU разделяме на коефициента:
vCPUсумм / vCPU:pCPU = pCPUсумм – изискуемо количество физически ядра
pCPUсумм / 1.25 = pCPUht – брой ядра с корекция за Hyper-Threading
Да предположим, че е необходимо да се извърши изчисление на клъстер с 190 ядра / 3.5ТБ RAM. При това приемаме целево 50% натоварване на процесорната мощност и 75% по оперативната памет.
pCPU
190
CPU util
50%
Mem
3500
Mem util
75%
Socket
Основен
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 наказание за избрания RAID ниво
Повече за устройството RAID и RAID Penalty се разказва тук — и и
На базата на полученото количество дискове се изчисляват възможните варианти, които отговарят на изискванията за капацитет за съхранение, включително варианти с многостепенно съхранение.
Изчисляването на системи с използване на SSD като ниво на съхранение се разглежда отделно.
Спецификации на изчислението на системи с Flash Cache
Flash Cache – общо название за всички фирмени технологии за използване на флаш памет като втори кеш. При използване на флаш кеш, СХД обикновено се изчислява за осигуряване на натоварването от магнитни дискове, докато пикът се обслужва от кеш.
При това е необходимо да се разбере профилът на натоварването и степента на локализация на обращението към блоковете на томовете за съхранение. Флаш кеш – технология за натоварвания с висока локализация на заявките и практически не се използва за равномерно натоварени томове (както например за аналитични системи).
Изчисляване на хибридни системи low-end / mid-range
Хибридните системи от ниско и средно ниво използват многостепенно съхранение с преместване на данни между нивата по график. При това размерът на блока за многостепенно съхранение при най-добрите модели е 256 MB. Тези особености не позволяват да се счита технологията за многостепенно съхранение за технология, повишаваща производителността, както погрешно смятат мнозина. Многостепенното съхранение в системите от ниско и средно ниво е технология за оптимизация на разходите за съхранение при системи с изразена неравномерност в натоварването.
За многостепенно складиране се изчислява преди всичко производителността на горното ниво, докато долното ниво на складиране се счита единствено за допълващо липсващия капацитет на складиране. За хибридна многостепенна система е задължително използването на технологията за флаш кеш за многостепенния пул с цел компенсация на спадовете в производителността за внезапно активирани данни от долното ниво.
Използване на SSD в многостепенен дисков пул
Използването на SSD в многостепенен дисков пул има вариации в зависимост от особеностите на реализацията на алгоритмите за флаш кеш от конкретния производител.
Общата практика за политика на складиране за дисков пул с ниво SSD е — SSD първо.
Четиво само флаш кеш. За флаш кеша само за четене, нивото на складиране на SSD възниква при значителна локализация на операциите по запис независимо от кеша.
Четене / Запис флаш кеш. В случай на флаш кеш за запис, първо се установява максималния обем на кеша, а нивото на складиране на SSD се появява само при недостатъчност на размера на кеша за обслужване на цялата локализирана натовареност.
Изчисляването на производителността на SSD и кеша се извършва всеки път въз основа на изискванията на производителя, но винаги за най-лошия вариант.
Източник: habr.com
