nmk

Лекція №5 (2 години). Основи IaaS: віртуальні машини та обчислювальні ресурси

План лекції

  1. Концепція IaaS та сценарії застосування
  2. Віртуальні машини: архітектура, типи та конфігурація
  3. Управління екземплярами: запуск, зупинка, зміна типу
  4. Автоматичне масштабування та групи доступності
  5. Спеціалізовані обчислювальні ресурси: GPU, HPC, ARM-інстанси

Перелік умовних скорочень

Списком


Вступ

Віртуальні машини є базовим будівельним блоком IaaS і, ширше, всієї хмарної інфраструктури. Концепція VM у хмарі є прямим розвитком технологій віртуалізації, що виникли ще у 1970-х на мейнфреймах IBM. Проте саме хмарна реалізація — з миттєвим розгортанням, гнучким масштабуванням і погодинною тарифікацією — перетворила VM із дорогого корпоративного інструменту на загальнодоступний ресурс.

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


1. Концепція IaaS та сценарії застосування

1.1 IaaS у контексті хмарних моделей

IaaS (Infrastructure as a Service) — модель хмарних послуг, за якої провайдер надає клієнту доступ до базових обчислювальних ресурсів: віртуальних машин, сховища та мередж. Клієнт управляє всім програмним стеком: операційною системою, проміжним ПЗ, застосунками та даними.

Якщо PaaS можна порівняти з оренддю повністю укомплектованого офісу (необхідно лише принести своїх співробітників), то IaaS — це оренда порожнього приміщення з підключеними комунікаціями. Ви самі вирішуєте, яку меблі (ОС), обладнання (ПЗ) і як організувати роботу.

1.2 Коли обирати IaaS

IaaS є оптимальним вибором у таких сценаріях:

Сценарій Обґрунтування
Lift-and-shift міграція Перенесення існуючих on-premise VM у хмару без переписування застосунків
Специфічні вимоги до ОС Потреба у конкретній версії ОС, кастомних ядерних модулях
Спадщинні застосунки Старі застосунки, що не підтримують PaaS-платформи
Повний контроль Корпоративні вимоги до безпеки: custom SELinux, специфічне мережеве налаштування
HPC та ML-тренування GPU-інстанси для ресурсоємних обчислень
Бази даних (self-managed) Специфічна СУБД або версія, що не підтримується DBaaS

2. Віртуальні машини: архітектура, типи та конфігурація

2.1 Технологія віртуалізації

Хмарна VM — це програмна емуляція фізичного сервера, що запускається поверх реального фізичного обладнання за допомогою гіпервізора (Hypervisor).

Гіпервізор — спеціалізований програмний шар, що:

Гіпервізор Тип 1 (Bare-metal): Встановлюється безпосередньо на фізичне обладнання. Найкраща продуктивність.

2.2 Родини типів EC2-екземплярів

AWS EC2 пропонує сотні типів VM, згрупованих у родини за оптимізацією під конкретне навантаження:

Загального призначення (General Purpose):

Оптимізовані під обчислення (Compute Optimized):

Оптимізовані під пам’ять (Memory Optimized):

Оптимізовані під зберігання (Storage Optimized):

Прискорені (Accelerated Computing) — GPU/FPGA:

2.3 Номенклатура типів EC2

Тип EC2 читається за чітким форматом:

m  7  g  .  2xlarge
│  │  │       │
│  │  │       └── Розмір: nano, micro, small, medium, large, xlarge, 2xlarge...
│  │  └────────── Процесор: g=AWS Graviton (ARM), a=AMD, пусто=Intel
│  └───────────── Покоління: 7 (новіше = краще)
└──────────────── Родина: m=general, c=compute, r=memory, i=storage, p/g=GPU

2.4 Розміри (Sizes) та ресурси

На прикладі родини m6i:

Тип vCPU RAM (GiB) Мережа (Гбіт/с) EBS-пропускна здатність
m6i.large 2 8 До 12,5 До 10 Гбіт/с
m6i.xlarge 4 16 До 12,5 До 10 Гбіт/с
m6i.2xlarge 8 32 До 12,5 До 10 Гбіт/с
m6i.4xlarge 16 64 12,5 10 Гбіт/с
m6i.8xlarge 32 128 25 25 Гбіт/с
m6i.16xlarge 64 256 50 50 Гбіт/с
m6i.32xlarge 128 512 50 50 Гбіт/с
m6i.metal 128 512 50 50 Гбіт/с (bare-metal)

2.5 AMI (Amazon Machine Image)

AMI (Amazon Machine Image) — шаблон, що містить операційну систему, налаштування та початковий набір програмного забезпечення для запуску EC2-інстансу.

Типи AMI:

Golden Image (Golden AMI):

Практика створення власного AMI зі всіма необхідними корпоративними налаштуваннями — патчами безпеки, агентами моніторингу, конфігурацією логування. Замість того щоб налаштовувати кожен новий сервер вручну — запускається golden image.

2.6 Azure VM та Google Compute Engine

Azure Virtual Machines:

Серії Azure VM: A (базові), B (burstable, аналог T3), D (загального призначення), E (пам’ять), F (обчислення), G/M (великий RAM), N (GPU).

Аналог AMI — Azure Marketplace image або Managed Image / Shared Image Gallery.

Google Compute Engine:

Типи машин GCE: E2 (загального призначення, дешевший), N2/N2D (збалансований), C3 (обчислення), M2/M3 (пам’ять), A2/A3 (GPU NVIDIA).

Preemptible VMs / Spot VMs — GCE-аналог AWS Spot Instances (розглядається далі).


3. Управління екземплярами: запуск, зупинка, зміна типу

3.1 Lifecycle (Життєвий цикл) EC2-інстансу

        pending           running          stopping         stopped
    ┌─────────────►  ┌─────────────┐  ◄──────────────  ┌──────────────┐
Launch            │  running      │  stop              │  stopped     │
                  │  (тарифікація)│  ──────────────►   │  (EBS-диск   │
                  └──────┬────────┘  start             │  зберігається│
                         │           ◄──────────────    └──────────────┘
                         │ terminate
                         ▼
                    terminated
                  (інстанс видалено)

Стани та тарифікація:

3.2 Типи зупинки та перезапуску

Stop (Зупинка): инстанс зупиняється, дані на EBS-диску зберігаються. При наступному запуску може бути запущений на іншому фізичному хості (зміниться публічна IP-адреса, якщо не використовується Elastic IP).

Hibernate (Сплячий режим): стан оперативної пам’яті (RAM) записується на диск. При наступному запуску — відновлення з попередньього стану. Корисно для збереження тривалих обчислень.

Terminate (Завершення): інстанс знищується назавжди. Root EBS-диск видаляється (за замовчуванням); додаткові EBS-томи зберігаються.

Reboot (Перезавантаження): перезавантаження ОС без зміни хоста, IP-адреса зберігається.

3.3 Elastic IP

Elastic IP (EIP) — статична публічна IPv4-адреса, що залишається незмінною незалежно від зупинки/запуску інстансу.

3.4 Зміна типу інстансу

EC2 підтримує вертикальне масштабування — зміну типу інстансу (більше vCPU та RAM):

  1. Зупинити інстанс (stop)
  2. Змінити тип (Change Instance Type)
  3. Запустити інстанс (start)

Обмеження: не всі типи сумісні між собою (деякі вимагають специфічної мережевої картки або драйверів).


4. Автоматичне масштабування та групи доступності

4.1 Моделі масштабування

Вертикальне масштабування (Scale Up/Down): Збільшення/зменшення ресурсів одного інстансу (більший тип VM). Потребує перезапуску. Обмежене максимальним розміром доступних інстансів.

Горизонтальне масштабування (Scale Out/In): Додавання або видалення екземплярів. Набагато гнучкіше, не потребує downtime. Є основою хмарної масштабованості.

4.2 Auto Scaling Group (ASG)

Auto Scaling Group (ASG) — група EC2-інстансів, якою AWS керує автоматично відповідно до налаштованих правил.

Ключові параметри ASG:

Min: 2,  Desired: 4,  Max: 10

Нормально:     ██ ██ ██ ██          (4 інстанси)
Пік:           ██ ██ ██ ██ ██ ██   (6 інстансів — AWS додав 2)
Спад:          ██ ██               (2 інстанси — AWS видалив 2)
(нижче мін. не опускається)

4.3 Політики масштабування

Target Tracking Scaling (рекомендований): Підтримує цільовий показник метрики. Наприклад: «Тримати середнє використання CPU на рівні 60%». ASG автоматично додає або видаляє інстанси для досягнення цього показника.

Step Scaling (Ступінчасте): Різні дії залежно від порогового рівня.

Scheduled Scaling (Планове): Масштабування у визначені дні та час:

Predictive Scaling: AWS використовує ML для прогнозування майбутнього навантаження на основі історичних даних та заздалегідь масштабує інфраструктуру.

4.4 Launch Template / Launch Configuration

Перед створенням ASG необхідно визначити Launch Template — шаблон конфігурації інстансу, що включає:

4.5 Health Checks та автоматичне відновлення

ASG автоматично замінює нездорові інстанси:

  1. EC2 або ELB (Load Balancer) позначає інстанс як нездоровий
  2. ASG завершує нездоровий інстанс
  3. ASG запускає новий інстанс на його місці

Приклад: У 3 годині ночі один із 5 веб-серверів виходить з ладу через kernel panic. ASG автоматично завершує його та запускає новий — без участі адміністратора.

4.6 Multi-AZ розгортання та Placement Groups

Multi-AZ для ASG: ASG рекомендується розгортати у двох або більше зонах доступності. При виході з ладу цілої AZ, ASG автоматично перезапустить потрібну кількість інстансів в інших AZ.

Placement Groups (Групи розміщення):

Тип Опис Застосування
Cluster Усі інстанси — в одній AZ на сусідньому обладнанні. Мінімальна затримка між ними HPC, низьколатентні кластери
Spread Кожен інстанс — на окремому обладнанні. Максимальна ізоляція відмов Критичні одиничні дузлові сервіси
Partition Групи інстансів на різних «стелажах» обладнання HDFS, Kafka, Cassandra

5. Спеціалізовані обчислювальні ресурси та моделі оплати

5.1 GPU-інстанси

Інстанси з GPU (Graphical Processing Unit) дозволяють виконувати масово-паралельні обчислення, що критично для:

AWS GPU-інстанси:

5.2 AWS Graviton (ARM-процесори)

Amazon розробила власні ARM-процесори AWS Graviton для своїх EC2-інстансів:

5.3 Моделі оплати EC2

On-Demand (За запитом):

Reserved Instances (Зарезервовані):

Savings Plans:

Spot Instances (Спотові):

Dedicated Hosts (Виділені хости):

Порівняння моделей оплати:

Модель Відносна ціна Переривання Зобов’язання
On-Demand 100% Немає Немає
Savings Plans 34–66% Немає 1–3 роки
Reserved 28–72% Немає 1–3 роки
Spot 10–30% Можливе Немає
Dedicated Host 150%+ Немає Немає або 1–3 роки

Висновки

  1. IaaS та VM забезпечують клієнту максимальний контроль над обчислювальним середовищем — від вибору ОС до повного адміністрування стеку. Це оптимально для lift-and-shift міграцій, специфічних вимог до ОС та спеціалізованих навантажень.

  2. Родини типів EC2 організовані за оптимізацією: загального призначення (m), обчислення (c), пам’ять (r), сховище (i), GPU (p/g). Правильний вибір типу безпосередньо впливає на продуктивність і вартість.

  3. AMI — шаблон VM — є ключовим інструментом для стандартизації та швидкого розгортання. Golden AMI практика скорочує час підготовки нових серверів.

  4. Auto Scaling Group реалізує горизонтальне масштабування автоматично, забезпечуючи еластичність та відмовостійкість. Поєднання ASG з Multi-AZ та Load Balancer є стандартом для production-розгортань.

  5. Моделі оплати (On-Demand, Reserved, Savings Plans, Spot) дозволяють оптимізувати витрати: стабільні навантаження — Reserved/Savings Plans; непостійні — Spot + On-Demand. Комбінування моделей дає максимальну економію.


Джерела

  1. AWS Documentation. (2024). Amazon EC2 User Guide for Linux Instances. https://docs.aws.amazon.com/ec2/
  2. AWS Documentation. (2024). Amazon EC2 Auto Scaling User Guide. https://docs.aws.amazon.com/autoscaling/
  3. Microsoft. (2024). Azure Virtual Machines Documentation. https://learn.microsoft.com/en-us/azure/virtual-machines/
  4. Google Cloud. (2024). Compute Engine Documentation. https://cloud.google.com/compute/docs
  5. Linthicum, D. (2020). Cloud Computing and SOA Convergence in Your Enterprise. Addison-Wesley.
  6. Fehling, C., Leymann, F., Retter, R., Schupeck, W., & Arbitter, P. (2014). Cloud Computing Patterns. Springer.
  7. Varia, J., & Mathew, S. (2014). Overview of Amazon Web Services. AWS Whitepaper.

Запитання для самоперевірки

  1. У яких сценаріях IaaS є кращим вибором, ніж PaaS? Наведіть три конкретних приклади.
  2. Що таке гіпервізор? Яку роль він відіграє у роботі хмарних VM? Які гіпервізори використовують AWS, Azure та GCP?
  3. Розшифруйте тип EC2-інстансу r6g.2xlarge. Що означає кожна частина найменування?
  4. Що таке AMI? Поясніть концепцію «Golden AMI image» та її переваги для корпоративних середовищ.
  5. Яка різниця між зупинкою (stop) та завершенням (terminate) EC2-інстансу? Які ресурси продовжують тарифікуватися при зупинці?
  6. Що таке Auto Scaling Group? Поясніть параметри min/desired/max capacity та їхній вплив на поведінку ASG.
  7. Порівняйте три типи політик масштабування ASG (Target Tracking, Step Scaling, Scheduled Scaling). Для якого сценарію підходить кожен тип?
  8. Що таке Spot Instances? Яку головну відмінність мають від On-Demand? For яких навантажень вони підходять, а для яких — ні?
  9. Порівняйте Reserved Instances та Savings Plans за критеріями гнучкості та знижки.
  10. У чому полягає перевага AWS Graviton (ARM) інстансів порівняно з x86-аналогами? Чи є обмеження?