въведение
Информационната система от гледна точка на потребителя е добре дефинирана в GOST RV 51987 - „автоматизирана система, резултатът от която е представянето на изходна информация за последваща употреба“. Ако вземем предвид вътрешната структура, тогава по същество всеки IS е система от взаимосвързани алгоритми, внедрени в код. В широк смисъл на тезата на Тюринг-Чърч, алгоритъм (или IS) трансформира набор от входни данни в набор от изходни данни.
Може дори да се каже, че трансформацията на входните данни е смисълът на съществуването на една информационна система. Съответно стойността на ИС и целия комплекс на ИС се определя чрез стойността на входните и изходните данни.
Въз основа на това проектирането трябва да започне и да бъде управлявано от данни, приспособявайки архитектурата и методите към структурата и значението на данните.
Съхранени данни
Ключов етап от подготовката за проектиране е получаването на характеристиките на всички набори от данни, планирани за обработка и съхранение. Тези характеристики включват:
- Обем на данните;
— Информация за жизнения цикъл на данните (растеж на нови данни, продължителност на живота, обработка на остарели данни);
— Класификация на данните от гледна точка въздействие върху основния бизнес на компанията (триадата на конфиденциалност, интегритет, достъпност) заедно с финансови показатели (например цената на загуба на данни през последния час);
— География на обработката на данни (физическо местоположение на системите за обработка);
— Регулаторни изисквания за всеки клас данни (например Федерален закон-152, PCI DSS).
Информационни системи
Данните не само се съхраняват, но и се обработват (трансформират) от информационните системи. Следващата стъпка след получаване на характеристиките на данните е най-пълната инвентаризация на информационните системи, техните архитектурни характеристики, взаимозависимости и инфраструктурни изисквания в конвенционални единици за четири вида ресурси:
— Изчислителна мощност на процесора;
— Количество RAM;
— Изисквания към обема и производителността на системата за съхранение на данни;
— Изисквания към мрежата за предаване на данни (външни канали, канали между компонентите на ИС).
В този случай трябва да има изисквания за всяка услуга/микроуслуга като част от ИС.
Отделно е необходимо да се отбележи, че за правилния дизайн е задължително наличието на данни за въздействието на ИС върху основния бизнес на компанията под формата на разходите за престой на ИС (рубли на час).
Модел на заплаха
Трябва да има формален модел на заплахи, от които се планира защита на данните/услугите. Нещо повече, моделът на заплахата включва не само аспекти на поверителността, но също и целостта и наличността. Тези. Например:
— Отказ на физическия сървър;
— Повреда на горния превключвател;
— Прекъсване на оптичния комуникационен канал между центровете за данни;
— Отказ на цялата оперативна система за съхранение.
В някои случаи моделите на заплахи се пишат не само за инфраструктурни компоненти, но и за специфични информационни системи или техни компоненти, като повреда на СУБД с логическо разрушаване на структурата на данните.
Всички решения в рамките на проекта за защита срещу неописана заплаха са ненужни.
Нормативни изисквания
Ако данните, които се обработват, са предмет на специални правила, установени от регулаторите, е необходима информация относно наборите от данни и правилата за обработка/съхранение.
RPO/RTO цели
Проектирането на какъвто и да е тип защита изисква наличието на целеви индикатори за загуба на данни и целево време за възстановяване на услугата за всяка от описаните заплахи.
В идеалния случай RPO и RTO трябва да имат свързани разходи за загуба на данни и престой на единица време.
Разделяне на ресурсни пулове
След събиране на цялата първоначална входна информация, първата стъпка е да групирате набори от данни и IP в пулове въз основа на модели на заплахи и регулаторни изисквания. Определя се вида на разделяне на различните пулове - програмно на ниво системен софтуер или физически.
Примери:
— веригата за обработка на лични данни е напълно физически отделена от другите системи;
— Архивите се съхраняват на отделна система за съхранение.
В този случай пуловете могат да бъдат ненапълно независими, например са дефинирани два пула от изчислителни ресурси (мощност на процесора + RAM), които използват един пул за съхранение на данни и един пул от ресурси за предаване на данни.
Мощност на обработка
Резюме, изискванията за мощност на обработка на виртуализиран център за данни се измерват по отношение на броя на виртуалните процесори (vCPU) и тяхното съотношение на консолидация на физически процесори (pCPU). В този конкретен случай 1 pCPU = 1 физическо процесорно ядро (с изключение на Hyper-Threading). Броят на vCPU се сумира във всички дефинирани пулове ресурси (всеки от които може да има свой собствен коефициент на консолидация).
Коефициентът на консолидация за натоварени системи се получава емпирично, въз основа на съществуваща инфраструктура или чрез пилотно инсталиране и тестване на натоварване. За ненатоварени системи се използва „най-добра практика“. По-конкретно, VMware цитира средното съотношение като 8:1.
Оперативна памет
Общата необходима RAM памет се получава чрез просто сумиране. Не се препоръчва използването на презаписване на RAM.
Ресурси за съхранение
Изискванията за съхранение се получават чрез просто сумиране на всички пулове по капацитет и производителност.
Изискванията за производителност се изразяват в IOPS, комбинирани със средно съотношение четене/запис и, ако е необходимо, максимално забавяне на отговора.
Изискванията за качество на услугата (QoS) за конкретни групи или системи трябва да бъдат посочени отделно.
Мрежови ресурси за данни
Изискванията за мрежата за данни се получават чрез просто сумиране на всички пулове с честотна лента.
Изискванията за качество на услугата (QoS) и латентност (RTT) за конкретни групи или системи трябва да бъдат посочени отделно.
Като част от изискванията към мрежовите ресурси за данни са посочени и изисквания за изолиране и/или криптиране на мрежов трафик и предпочитани механизми (802.1q, IPSec и др.).
Избор на архитектура
Това ръководство не обхваща избори, различни от x86 архитектура и 100% сървърна виртуализация. Следователно изборът на архитектура на изчислителната подсистема се свежда до избора на платформа за виртуализация на сървъра, форм-фактора на сървъра и общите изисквания за конфигурация на сървъра.
Ключовата точка на избора е сигурността на използването на класически подход с разделяне на функциите за обработка, съхранение и предаване на данни или конвергентен.
класическа архитектура включва използването на интелигентни външни подсистеми за съхранение и предаване на данни, докато сървърите допринасят само за процесорна мощност и RAM към общия пул от физически ресурси. В екстремни случаи сървърите стават напълно анонимни, като имат не само собствени дискове, но дори и системен идентификатор. В този случай операционната система или хипервайзорът се зарежда от вграден флаш носител или от външна система за съхранение на данни (зареждане от SAN).
В рамките на класическата архитектура изборът между блейдове и стелажи се прави основно въз основа на следните принципи:
— Рентабилни (средно монтираните в стелажи сървъри са по-евтини);
— Изчислителна плътност (по-висока за блейдове);
— Консумация на енергия и разсейване на топлина (лопатките имат по-висока специфична единица за единица);
— Мащабируемост и управляемост (блейдовете обикновено изискват по-малко усилия за големи инсталации);
- Използване на разширителни карти (много ограничен избор за блейдове).
Конвергентна архитектура (също известен като хиперконвергиран) включва комбиниране на функциите за обработка и съхранение на данни, което води до използването на локални сървърни дискове и, като следствие, изоставянето на класическия блейд форм фактор. За конвергентни системи се използват или шкафови сървъри, или клъстерни системи, комбиниращи няколко блейд сървъра и локални дискове в един корпус.
Процесор/Памет
За да изчислите правилно конфигурацията, трябва да разберете вида на натоварването за средата или всеки от независимите клъстери.
Обвързан с процесора – среда, ограничена в производителността от мощността на процесора. Добавянето на RAM няма да промени нищо по отношение на производителността (брой виртуални машини на сървър).
Обвързана с памет – среда, ограничена от RAM. Повече RAM на сървъра ви позволява да стартирате повече виртуални машини на сървъра.
GB / MHz (GB / pCPU) - средното съотношение на консумация на RAM и мощност на процесора от това конкретно натоварване. Може да се използва за изчисляване на необходимото количество памет за дадена производителност и обратно.
Изчисляване на конфигурацията на сървъра
Първо, трябва да определите всички видове натоварване и да вземете решение за комбиниране или разделяне на различни изчислителни пулове в различни клъстери.
След това за всеки от дефинираните клъстери се определя съотношението GB / MHz при предварително известно натоварване. Ако натоварването не е известно предварително, но има грубо разбиране за нивото на използване на мощността на процесора, можете да използвате стандартни съотношения vCPU:pCPU, за да преобразувате изискванията на пула във физически.
За всеки клъстер разделете сумата на изискванията за vCPU пул на коефициента:
vCPUsum / vCPU:pCPU = pCPUsum – необходим брой физически единици. ядра
pCPUsum / 1.25 = pCPUht – брой ядра, коригирани за Hyper-Threading
Да приемем, че е необходимо да се изчисли клъстер със 190 ядра / 3.5 TB RAM. В същото време приемаме целево натоварване от 50% мощност на процесора и 75% RAM.
pCPU
190
CPU util
50%
Mem
3500
Помощна програма Mem
75%
Гнездо
Ядро
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%. По същия начин броят на VM и IS, засегнати от аварията, намалява наполовина.
Изчисляване на класически системи за съхранение въз основа на производителност
Класическите системи за съхранение винаги се изчисляват, като се използва най-лошият сценарий, като се изключва влиянието на оперативния кеш и оптимизацията на операциите.
Като основни индикатори за производителност вземаме механична производителност от диска (IOPSdisk):
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
След това броят на дисковете в дисковия пул се изчислява по следната формула: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSдиск. Където:
- Общо IOPS – обща необходима производителност в IOPS от дисковия пул
- RW – процент на операциите за четене
- RAID писалка – RAID наказание за избраното RAID ниво
Прочетете повече за Device RAID и RAID Penalty тук - и и
Въз основа на получения брой дискове се изчисляват възможните опции, които отговарят на изискванията за капацитет за съхранение, включително опции с многостепенно съхранение.
Изчисляването на системи, използващи SSD като слой за съхранение, се разглежда отделно.
Характеристики на изчислителните системи с Flash Cache
Флаш кеш – общо име за всички собствени технологии за използване на флаш памет като кеш от второ ниво. Когато се използва флаш кеш, системата за съхранение обикновено се изчислява да осигурява стабилно натоварване от магнитни дискове, докато пикът се обслужва от кеша.
В този случай е необходимо да се разбере профилът на натоварване и степента на локализация на достъпа до блокове от обеми за съхранение. Флаш кешът е технология за работни натоварвания със силно локализирани заявки и е практически неприложима за равномерно заредени томове (като например за системи за анализ).
Изчисляване на хибридни системи от нисък/среден клас
Хибридните системи от по-нисък и среден клас използват многостепенно съхранение с данни, движещи се между нивата по график. В същото време размерът на многостепенния блок за съхранение за най-добрите модели е 256 MB. Тези характеристики не ни позволяват да считаме технологията за многослойно съхранение като технология за увеличаване на производителността, както много хора погрешно вярват. Многостепенното съхранение в системи от нисък и среден клас е технология за оптимизиране на разходите за съхранение при системи с изразена неравномерност на натоварването.
За многослойно съхранение първо се изчислява производителността на най-горното ниво, докато се счита, че долното ниво на съхранение допринася само за липсващия капацитет за съхранение. За хибридна многослойна система е задължително да се използва технология за флаш кеш за многослойния пул, за да се компенсира намаляването на производителността за внезапно нагряване на данни от по-ниско ниво.
Използване на SSD в многослоен дисков пул
Използването на SSD в многостепенен дисков пул има вариации в зависимост от конкретното изпълнение на алгоритми за флаш кеш от даден производител.
Общата практика на политиката за съхранение за дисков пул с SSD ниво е SSD първо.
Флаш кеш само за четене. За флаш кеш само за четене, слоят за съхранение на SSD идва със значителна локализация на записите, независимо от кеша.
Флаш кеш за четене/запис. В случай на флаш кеш, размерът на кеша за запис първо се задава на максималния размер на кеша и нивото на SSD съхранение се появява само когато размерът на кеша е недостатъчен за обслужване на цялото локализирано работно натоварване.
Изчисленията на производителността на SSD и кеша се правят всеки път въз основа на препоръките на производителя, но винаги за най-лошия сценарий.
Източник: www.habr.com