Дизайн виртуализованного ЦОД

image

Введення

Інформаційна система з точки зору користувача добре визначається ГОСТ РВ 51987 — «автоматизована система, результатом функціонування якої є подання вихідної інформації для подальшого використання». Якщо розглядати внутрішню структуру, то по суті будь-яка ІС є системою реалізованих в коді взаємозв'язаних алгоритмів. У широкому розумінні тези Тюрінга-Черча алгоритм (а сл-але ІВ) здійснює трансформацію множини вхідних даних безліч вихідних даних.
Можна навіть сказати, що в трансформації вхідних даних і є сенс існування інформаційної системи. Відповідно цінність ІВ і всього комплексу ІС визначається через цінність вхідних і вихідних даних.
Виходячи з цього проектування повинно починатися і брати за основу дані, підлаштовуючи архітектуру та методи під структуру і значимість даних.

Збережені дані
Ключовим етапом підготовки до проектування є отримання характеристик всіх наборів даних, планованих до обробки і зберігання. Ці характеристики включають в себе:
— Обсяг даних;
— Інформація про життєвому циклі даних (приріст нових даних, строк життя, обробка застарілих даних);
— Класифікація даних з т. з. впливу на основний бізнес компанії (тріаді конфіденційність, цілісність, доступність) разом з фінансовими показниками (напр. вартість втрати даних за останню годину);
— Географія обробки даних (фізичне розташування систем обробки);
— Вимоги регуляторів по кожному класу даних (напр. ФЗ-152, PCI DSS).



Інформаційні системи

Дані не тільки зберігаються, але і обробляються (трансформуються) інформаційними системами. Наступним кроком після отримання характеристик даних є максимально повна інвентаризація інформаційних систем, їх архітектурних особливостей, взаємозалежностей і вимог до інфраструктури в умовних одиницях до чотирьох видів ресурсів:
— Процесорна обчислювальна мощностьl;
— Обсяг оперативної пам'яті;
— Вимоги до обсягу та продуктивності системи зберігання даних;
— Вимоги до мережі передачі даних (зовнішні канали, канали між компонентами ІС).
Вимоги при цьому повинні бути на кожен сервіс/микросервис у складі ІС.
Окремо необхідно відзначити обов'язкове для коректного проектування наявність даних щодо впливу ІВ на основний бізнес компанії у вигляді вартості простою ІС (рублів в годину).

Модель загроз

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

Вимоги регуляторів

Якщо оброблювані дані потрапляють під дію спеціальних правил, що встановлюються регуляторами, в обов'язковому порядку необхідна інформація про наборах даних та правила обробки/зберігання.

Цільові показники RPO / RTO

Проектування будь-якого виду захисту вимагає наявності показників цільової втрати даних і цільового часу відновлення сервісу для кожної з наведених загроз.
При цьому в ідеалі RPO і RTO повинні мати асоційовані вартості втрати даних і простою в одиницю часу.

image

Поділ на пули ресурсів

Після збору всієї первинної вхідної інформації першим кроком є групування наборів даних та ІС в пули, на основі моделей загроз та вимог регуляторів. Визначається вид поділу різних пулів – програмно на рівні системного або фізично.
Приклади:
— Контур, який обробляє персональні дані, повністю фізично відділений від інших систем;
— Резервні копії зберігаються на окремій СГД.

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

Процесорна потужність

image

Абстрактні потреби в процесорній потужність виртуализованного ЦОД вимірюється в кількості віртуальних процесорів (vCPU) і коефіцієнті їх консолідації на фізичних процесорах (pCPU). В даному конкретному випадку 1 pCPU = 1 фізичне ядро процесора (без урахування Hyper-Threading). Кількість vCPU підсумовується за всіма визначеними пулам ресурсів (кожен з яких може мати свій коефіцієнт консолідації).
Коефіцієнт консолідації для навантажених систем отримують емпіричним шляхом, виходячи з вже наявної інфраструктури, або при пілотній установці і навантажувальному тестуванні. Для ненавантажених систем застосовуються «best practice». Зокрема, VMware називає середнім коефіцієнтом 8:1.

Оперативна пам'ять

Загальна потреба в оперативній пам'яті виходить шляхом простого підсумовування. Використання перепідписання з оперативної пам'яті не рекомендується.

Ресурси зберігання

Вимоги по земельних ресурсах зберігання виходять шляхом простого підсумовування всіх пулів за обсягом і продуктивності.
Вимоги по продуктивності виражаються в IOPS в поєднанні з середнім співвідношенням читання/запис і при необхідності максимальною затримкою відгуку.
Окремо мають бути вказані вимоги щодо забезпечення якості обслуговування (QoS) для конкретних пулів або систем.

Ресурси мережі передачі даних

Вимоги по мережі передачі даних виходять шляхом простого підсумовування всіх пулів пропускної здатності.
Окремо мають бути вказані вимоги щодо забезпечення якості обслуговування (QoS) і затримки (RTT) для конкретних пулів або систем.
В рамках вимог до ресурсів мережі передачі даних так само вказуються вимоги щодо ізоляції та/або шифруванню мережевого трафіку і кращим механізмів (802.1 q, IPSec і т. д.)

Вибір архітектури

В рамках даного посібника не розглядається інший вибір, крім архітектури x86 і 100% віртуалізації серверів. Тому вибір архітектури обчислювальної підсистеми зводиться до вибору платформи серверної віртуалізації, форм-фактора серверів і загальних вимог щодо конфігурації серверів.

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

Класична архітектура передбачає використання інтелектуальних зовнішніх підсистем зберігання та передачі даних, у те час як сервери привносять в загальний пул фізичних ресурсів тільки процесорну потужність і оперативну пам'ять. У граничному випадку сервери стають повністю анонімними, не мають не тільки власних дисків, але навіть системного ідентифікатора. У цьому випадку використовується завантаження ОС або гіпервізора з вбудованих флеш носіїв або з зовнішньої системи зберігання даних (boot from SAN).
В рамках класичної архітектури вибір між лезами (blade) і стоечними (rack) здійснюється насамперед з таких принципів:
— Економічна ефективність (у середньому стійку сервери дешевше);
— Обчислювальна щільність (у лез вище);
— Енергоспоживання і тепловиділення (у лез вище питомий на юніт);
— Масштабованість і керованість (леза в цілому вимагає менше зусиль при великих інсталяціях);
— Використання карт розширення (для лез дуже обмежений вибір).
Конвергентна архітектура (також відома як гиперконвергентная) передбачає суміщення функцій обробки і зберігання даних, що веде до використання локальних дисків серверів і як наслідок відмови від форм-фактора класичних лез. Для конвергентних систем використовуються або стійкові сервери, або кластерні системи, що поєднують в одному корпусі кілька серверів-лез і локальні диски.

CPU / Memory

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

Розрахунок конфігурації сервера

image

Для початку необхідно визначити всі види навантаження і прийняти рішення про об'єднання або розділення різних обчислювальних пулів по різним кластерам.
Далі для кожного з визначених кластерів визначається співвідношення 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% Socket 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%. Точно так само вдвічі знижується кількість ВМ та ІВ, на яких відобразилася аварія.

Розрахунок класичної СГД по продуктивності

image

Класична СГД завжди розраховується за найгіршого варіанту (worst case scenario), виключаючи вплив оперативного кеша і оптимізації операцій.
В якості базових показників продуктивності приймаємо механічну продуктивність диска (IOPSdisk):
— 7.2 k – 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 Cache – загальна назва для всіх фірмових технологій використання флеш-пам'яті в якості кеша другого рівня. При використанні флеш кешу СГД як правило розраховується для забезпечення з магнітних дисків сталою навантаження, в той час як пікову обслуговує кеш.
При цьому необхідно розуміти профіль навантаження і ступінь локалізації звернень до блоків томів зберігання. Флеш кеш – технологія для навантажень з високою локалізацією запитів, і практично непридатна для рівномірно навантажених томів (як наприклад для систем аналітики).

Розрахунок гібридних систем low-end / mid-range

Гібридні системи нижнього і середнього класів використовують багаторівневе зберігання з переміщенням даних між рівнями за розкладом. При цьому розмір блоку багаторівневого зберігання у кращих моделей становить 256 МБ. Дані особливості дозволяють вважати технологію багаторівневого зберігання технологією підвищення продуктивності, як помилково вважається багатьма. Багаторівневе зберігання в системах нижнього і середнього класів – це технологія оптимізації вартості зберігання для систем з вираженою нерівномірністю навантаження.

Для багаторівневого зберігання розраховується насамперед продуктивність по верхньому рівню, в той час як нижній рівень зберігання вважається лише вносить необхідну ємність зберігання. Для гібридної багаторівневої системи обов'язково використання технології флеш кешу для багаторівневого пулу з метою компенсації осідання продуктивності для раптово нагрілися даних з нижнього рівня.

Використання SSD в багаторівневому дисковому пулі

image

Використання SSD в багаторівневому дисковому пулі має варіації, в залежності від особливостей реалізації алгоритмів флеш кеша у даного виробника.
Загальна практика політики збереження дискового пулу з SSD рівнем — SSD first.
Read Only Flash Cache. Для флеш кешу тільки на читання рівень зберігання на SSD з'являється при значній локалізації операцій запису незалежно від кеша.
Read / Write Flash Cache. У випадку з флеш кешем на запис спочатку встановлюється максимальний об'єм кешу, а рівень зберігання на SSD з'являється лише при недостатності розміру кеша для обслуговування всієї локалізованої навантаження.
Розрахунок продуктивності SSD і кеша проводиться кожного разу, виходячи з рекомендацій виробника, але завжди для найгіршого варіанту.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.