Запровадження
Інформаційна система з точки зору користувача добре визначається в ГОСТ РВ 51987 - "автоматизована система, результатом функціонування якої є подання вихідної інформації для подальшого використання". Якщо розглядати внутрішню структуру, то, по суті, будь-яка ІС є системою реалізованих у коді взаємопов'язаних алгоритмів. У широкому розумінні тези Тьюринга-Черча алгоритм (а сл-но ІС) здійснює трансформацію безлічі вхідних даних у безліч вихідних даних.
Можна навіть сказати, що в трансформації вхідних даних є сенс існування інформаційної системи. Відповідно цінність ІВ та всього комплексу ІВ визначається через цінність вхідних та вихідних даних.
Тому проектування має починатися і брати за основу дані, підлаштовуючи архітектуру та методи під структуру та значущість даних.
Збережені дані
Ключовим етапом підготовки до проектування є отримання характеристик всіх наборів даних, що плануються до обробки та зберігання. Ці характеристики включають:
- Обсяг даних;
- Інформація про життєвий цикл даних (приріст нових даних, термін життя, обробка застарілих даних);
- Класифікація даних з т.з. впливу на основний бізнес компанії (то тріаді конфіденційність, цілісність, доступність) разом із фінансовими показниками (напр. вартість втрати даних за останню годину);
- Географія обробки даних (фізичне розташування систем обробки);
— Вимоги регуляторів кожного класу даних (напр. ФЗ-152, PCI DSS).
Інформаційні системи
Дані як зберігаються, а й обробляються (трансформуються) інформаційними системами. Наступним кроком після отримання характеристик даних є максимально повна інвентаризація інформаційних систем, їх архітектурних особливостей, взаємозалежностей та вимог до інфраструктури в умовних одиницях до чотирьох видів ресурсів:
- Процесорна обчислювальна потужність;
- Об'єм оперативної пам'яті;
- Вимоги до обсягу та продуктивності системи зберігання даних;
— Вимоги до мережі передачі (зовнішні канали, канали між компонентами ІС).
Вимоги при цьому мають бути на кожен сервіс/мікросервіс у складі ІС.
Окремо необхідно відзначити обов'язкове для коректного проектування наявність даних щодо впливу ІВ на основний бізнес компанії у вигляді вартості простою ІВ (рублів на годину).
Модель погроз
В обов'язковому порядку має бути в наявності формальна модель загроз, від яких планується захищати дані/сервіси. У цьому модель загроз включає у собі як аспекти конфіденційності, а й цілісності і доступності. Тобто. наприклад:
- Вихід з ладу фізичного сервера;
- Вихід з ладу комутатора top-of-the-rack;
- Розрив оптичного каналу зв'язку між ЦОД;
— Вихід із ладу оперативної СГД цілком.
У деяких випадках моделі загроз пишуться не тільки для інфраструктурних компонентів, але і для конкретних ІС або їх компонентів, як-от відмова СУБД з логічним руйнуванням структури даних.
Усі рішення у рамках проекту із захисту проти не описаної загрози є зайвими.
Вимоги регуляторів
Якщо дані, що обробляються, підпадають під дію спеціальних правил, що встановлюються регуляторами, в обов'язковому порядку необхідна інформація про набори даних і правила обробки/зберігання.
Цільові показники RPO/RTO
p align="justify"> Проектування будь-якого виду захисту вимагає наявності показників цільової втрати даних і цільового часу відновлення сервісу для кожної з описаних загроз.
При цьому в ідеалі 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 - Середовище, обмежене за продуктивністю процесорною потужністю. Додавання оперативної пам'яті нічого не змінить з точки зору продуктивності (кількості ВМ на сервер).
Пам’ять прив’язана - Середовище, обмежене оперативною пам'яттю. Більше оперативної пам'яті на сервері дозволяє запустити більшу кількість ВМ на сервер.
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
flash-кеш – загальна назва для всіх фірмових технологій використання флеш-пам'яті як кеш другого рівня. При використанні флеш кешу СХД як правило розраховується для забезпечення з магнітних дисків навантаження, в той час як пікову обслуговує кеш.
При цьому необхідно розуміти профіль навантаження та ступінь локалізації звернень до блоків томів зберігання. Флеш кеш - технологія для навантажень з високою локалізацією запитів, і практично не застосовується для рівномірно навантажених томів (наприклад, для систем аналітики).
Розрахунок гібридних систем low-end/mid-range
Гібридні системи нижнього та середнього класів використовують багаторівневе зберігання з переміщенням даних між рівнями за розкладом. При цьому розмір блоку багаторівневого зберігання кращих моделей становить 256 МБ. Дані особливості неможливо вважати технологію багаторівневого зберігання технологією підвищення продуктивності, як помилково вважається багатьма. Багаторівневе зберігання у системах нижнього та середнього класів – це технологія оптимізації вартості зберігання для систем з вираженою нерівномірністю навантаження.
Для багаторівневого зберігання розраховується насамперед продуктивність по верхньому рівню, тоді як нижній рівень зберігання вважається лише таким, що вносить недостатню ємність зберігання. Для гібридної багаторівневої системи обов'язково використання технології флеш кешу для багаторівневого пулу з метою компенсації просідання продуктивності для даних, що раптово нагрілися, з нижнього рівня.
Використання SSD у багаторівневому дисковому кулі
Використання SSD у багаторівневому дисковому пулі має варіації залежно від особливостей реалізації алгоритмів флеш кешу у даного виробника.
Загальна практика політики зберігання дискового пулу з SSD рівнем — SSD first.
Read Only Flash Cache. Для флеш кешу тільки для читання рівень зберігання на SSD з'являється при значній локалізації операцій запису незалежно від кеша.
Read/Write Flash Cache. У випадку з флеш кешем на запис спочатку встановлюється максимальний об'єм кешу, а рівень зберігання на SSD з'являється лише при недостатності розміру кешу для обслуговування всього локалізованого навантаження.
Розрахунок продуктивності SSD та кешу проводиться щоразу виходячи з рекомендацій виробника, але завжди для найгіршого варіанту.
Джерело: habr.com