nmk

Лекція №6 (2 години). Хмарне зберігання даних в IaaS

План лекції

  1. Типи хмарного сховища: блочне, об’єктне, файлове
  2. Блочне сховище (EBS, Azure Managed Disks, Persistent Disk)
  3. Об’єктне сховище (Amazon S3, Azure Blob Storage, Google Cloud Storage)
  4. Файлове сховище та NAS у хмарі
  5. Стратегії резервного копіювання, реплікації та аварійного відновлення

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

Списком


Вступ

Зберігання даних — один із трьох фундаментальних компонентів IaaS (поряд із обчисленнями та мережею). Хмарні провайдери пропонують три принципово різні парадигми зберігання: блочне (для VM і баз даних), об’єктне (для файлів, медіа, backup) та файлове (для спільного доступу з NFS/SMB). Вибір правильного типу сховища безпосередньо визначає продуктивність, надійність і вартість системи.


1. Типи хмарного сховища

1.1 Архітектурні парадигми зберігання

Характеристика Блочне Об’єктне Файлове
Аналогія Жорсткий диск USB-флешка з HTTP Мережевий диск (NAS)
Одиниця зберігання Блок (512 Б–4 КБ) Об’єкт (файл + метадані) Файл (ієрархія директорій)
Доступ Через ОС (block device) HTTP REST API NFS, SMB/CIFS
Прив’язка До одного хоста Через мережу, глобально Через мережу, кілька хостів
Максимальний розмір ТБ (один диск) Практично необмежено Практично необмежено
Продуктивність Найвища (низька затримка) Висока для великих файлів Середня
Застосування БД, ОС VM, транзакційні дані Медіа, backup, static web, big data Спільні файли, CMS, HPC
AWS EBS S3 EFS
Azure Managed Disks Blob Storage Azure Files
GCP Persistent Disk Cloud Storage Filestore

2. Блочне сховище

2.1 Amazon EBS (Elastic Block Store)

Amazon EBS — блочне сховище, що надає постійні томи (volumes) для EC2-інстансів. EBS-том поводить себе як фізичний жорсткий диск, підключений до сервера: на ньому можна форматувати файлові системи, встановлювати СУБД, зберігати дані ОС.

Ключові властивості EBS:

2.2 Типи EBS-томів

Тип Технологія Макс. IOPS Макс. розмір Застосування
gp3 (рекомендований) NVMe SSD 16 000 16 ТБ Більшість навантажень (ОС, БД)
gp2 SSD 16 000 16 ТБ Застарілий gp3-попередник
io2 Block Express NVMe SSD 256 000 64 ТБ Критичні БД: Oracle, SAP HANA
io1 SSD 64 000 16 ТБ Високопродуктивні БД
st1 HDD 500 MiB/s 16 ТБ Big data, Hadoop, послідовний рідер
sc1 (Cold HDD) HDD 250 MiB/s 16 ТБ Рідко використовувані дані, архіви

gp3 vs gp2: gp3 рекомендований — фіксована ціна + незалежне налаштування IOPS (3000 базових, до 16000) та пропускної здатності (125 MiB/s базових, до 1000 MiB/s) без збільшення розміру тому.

Провізовані IOPS (io1/io2): для додатків, що потребують гарантованої кількості IOPS незалежно від завантаженості хоста. Наприклад, продуктивна БД Oracle → io2: 50 000 IOPS.

2.3 EBS Snapshots

Snapshot — моментальний знімок EBS-тому, що зберігається в Amazon S3 (інкрементально):

Snapshot 1: ████████████████████ (повний, 100 ГБ)
Snapshot 2: ░░░░░░░████░░░░░░░░░ (лише зміни, 5 ГБ)
Snapshot 3: ░░░░████░░░░░░░░░░░░ (лише зміни, 3 ГБ)

Застосування snapshots:

2.4 Azure Managed Disks та Google Persistent Disk

Azure Managed Disks: Типи: Ultra Disk (до 160 000 IOPS, для SAP HANA), Premium SSD v2, Premium SSD (аналог io1), Standard SSD, Standard HDD.

Унікальна особливість: Shared Disks — підключення одного диску до кількох VM одночасно (для Windows Server Failover Clusters).

Google Persistent Disk: Типи: Extreme Persistent Disk (до 120 000 IOPS), SSD Persistent Disk, Balanced Persistent Disk, Standard (HDD) Persistent Disk.

Hyperdisk — новий клас GCE-сховища з налаштованою пропускною здатністю.


3. Об’єктне сховище

3.1 Концепція об’єктного сховища

Об’єктне сховище — це сховище, де дані зберігаються у вигляді незалежних об’єктів (файлів з метаданими та унікальним ідентифікатором), а не у файловій ієрархії або на рівні блоків.

Структура S3:

Amazon S3
└── Кошик (Bucket): my-company-assets
    ├── images/logo.png          (об'єкт, 120 КБ)
    ├── videos/intro.mp4         (об'єкт, 240 МБ)
    ├── backups/db-2024-01.sql.gz(об'єкт, 5 ГБ)
    └── logs/app-2024-01-15.log  (об'єкт, 50 МБ)

Кожен об’єкт має:

3.2 Amazon S3 — детальний огляд

Amazon S3 (Simple Storage Service) — один із перших і найбільш широко використовуваних сервісів AWS (з 2006 року). Характеристики:

3.3 Класи зберігання S3 (Storage Classes)

S3 пропонує декілька класів зберігання, що балансують між ціною та доступністю:

Клас Доступність Затримка доступу Ціна (відносно) Застосування
S3 Standard 99.99% Миттєво 100% Активно використовуваний контент
S3 Standard-IA 99.9% Миттєво ~46% Рідкий доступ, але швидкий при потребі
S3 One Zone-IA 99.5% Миттєво ~23% Дані, що можна відтворити; одна AZ
S3 Glacier Instant 99.9% Миттєво ~40% Архіви з рідким, але терміновим доступом
S3 Glacier Flexible 99.99% Хвилини–години ~10% Архіви (терміни: 1–5 хв, 3–5 год, 5–12 год)
S3 Glacier Deep 99.99% 12–48 годин ~4% Довгострокові архіви (compliance, backup)
S3 Intelligent-Tiering 99.9% Миттєво Авто Невідомий патерн доступу; авто-міграція між класами

Lifecycle Policies (Правила переміщення): Автоматичний перехід об’єктів між класами на основі часу:

День 0:   завантаження → S3 Standard
День 30:  → S3 Standard-IA (автоматично)
День 90:  → S3 Glacier Flexible (автоматично)
День 365: → S3 Glacier Deep Archive (автоматично)
День 3650:→ Delete (автоматично)

3.4 Версіонування та захист від видалення

Versioning (Версіонування): При включеному версіонуванні S3 зберігає всі версії кожного об’єкта. Видалення або перезапис не знищує попередні версії:

images/logo.png
├── Version: v3 (поточна, 2024-01-15)
├── Version: v2 (2024-01-10)
└── Version: v1 (2024-01-01)

Object Lock (WORM — Write Once Read Many): Захист від видалення або зміни об’єкту протягом заданого терміну:

3.5 S3 Security: Bucket Policy, ACL, Block Public Access

S3 Block Public Access: Глобальне блокування публічного доступу до кошиків та об’єктів — рекомендований стан за замовчуванням для всіх кошиків з конфіденційними даними.

Bucket Policy (Політика кошика): IAM-подібна JSON-політика для тонкого управління доступом:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789:role/WebApp" },
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-bucket/public/*"
}

Pre-signed URLs: Тимчасові URL для надання доступу до приватних об’єктів без передачі облікових даних:

Застосування: користувач застосунку отримує presigned URL для завантаження відео → завантажує напряму з S3 (не через сервер застосунку) → значне зменшення навантаження.

3.6 Використання S3 за сценаріями

Static Website Hosting: S3 може безпосередньо обслуговувати HTML/CSS/JS — без серверів. У комбінації з CloudFront — глобальний CDN для статичного сайту за мінімальну ціну.

Data Lake: S3 є де-факто стандартом для зберігання сирих і оброблених аналітичних даних (petabytes). Інструменти: AWS Athena (SQL по S3), EMR, Glue.

Backup & Archive: Поєднання Lifecycle Policies та Glacier Deep Archive дозволяє автоматично переміщати старі backup на надійне та надзвичайно дешеве зберігання ($0.00099/ГБ/міс для Deep Archive).

Event-Driven Processing: S3 може тригерити AWS Lambda при появі нового об’єкта → автоматична обробка (транскодування відео, аналіз логів, перевірка на віруси).


4. Файлове сховище та NAS у хмарі

4.1 Потреба у файловому сховищі

Об’єктне сховище доступне через HTTP і не підтримує POSIX-семантику (блокування, атомарні операції). Деякі застосунки вимагають традиційної файлової системи з монтуванням через NFS або SMB:

4.2 Amazon EFS (Elastic File System)

Amazon EFS — повністю керована NFS (NFSv4.1/4.2) файлова система для Linux.

Ключові властивості:

Класи зберігання EFS:

4.3 Amazon FSx — спеціалізовані файлові системи

Amazon FSx — сімейство керованих файлових систем для специфічних навантажень:

FSx продукт Файлова система Застосування
FSx for Windows NTFS + SMB Windows-застосунки, ActiveDirectory інтеграція
FSx for Lustre Lustre HPC, ML-тренування (до 1 ТБ/с пропускна здатність)
FSx for NetApp ONTAP NetApp ONTAP Корпоративна міграція з NetApp on-premise
FSx for OpenZFS ZFS Перенесення ZFS-навантажень

FSx for Lustre + S3 інтеграція: Lustre автоматично завантажує дані з S3 до файлової системи при першому зверненні → ідеально для ML-тренування на великих датасетах.

4.4 Azure Files та GCP Filestore

Azure Files:

GCP Filestore:


5. Стратегії резервного копіювання та аварійного відновлення

5.1 Ключові метрики DR

RTO (Recovery Time Objective) — максимально допустимий час відновлення після аварії. Питання: «Скільки часу може бути система недоступною?»

RPO (Recovery Point Objective) — максимально допустима втрата даних, виражена у часі. Питання: «За скільки хвилин/годин до аварії допустима втрата даних?»

Аварія відбулась: 14:00
RPO = 1 година → остання резервна копія не раніше 13:00
RTO = 4 години → система має бути відновлена до 18:00
Рівень критичності RTO RPO Вартість
Mission-critical (банківські транзакції) < 1 хв ~0 Дуже висока
Бізнес-критичні (ERP) < 1 год < 15 хв Висока
Стандартні (внутрішні системи) < 8 год < 1 год Середня
Некритичні (архіви) < 24 год < 24 год Низька

5.2 Стратегії DR

Backup & Restore (Найпростіша та найдешевша):

Pilot Light:

Warm Standby:

Multi-Site Active/Active (Найскладніша та найдорожча):

5.3 AWS Backup

AWS Backup — централізований сервіс управління резервним копіюванням кількох AWS-сервісів:

Backup Plan визначає:

5.4 Реплікація S3 між регіонами

S3 Cross-Region Replication (CRR): Автоматична реплікація об’єктів із основного кошика в кошик іншого регіону:

S3 Same-Region Replication (SRR): Реплікація між кошиками в одному регіоні: консолідація логів, виробниче → тестове середовище.


Висновки

  1. Три парадигми зберігання — блочне, об’єктне та файлове — вирішують принципово різні завдання. Вибір правильного типу є критичним архітектурним рішенням.

  2. EBS є стандартом для первинного диску VM та баз даних: гарантована продуктивність (IOPS), персистентність, шифрування. Тип gp3 є оптимальним для більшості навантажень.

  3. Amazon S3 (та аналоги) — найбільш гнучке та масштабоване сховище. Класи зберігання та lifecycle policies дозволяють радикально оптимізувати вартість. 11 дев’яток надійності роблять S3 надійнішим за будь-яке on-premise рішення.

  4. Файлові системи (EFS, FSx) необхідні для навантажень із POSIX-семантикою, спільним доступом і традиційним файловим монтуванням. FSx for Lustre є найкращим вибором для HPC та ML.

  5. Стратегія DR визначається бізнес-вимогами до RTO та RPO: від простого backup&restore (дешево, тривале відновлення) до active/active multi-region (дорого, миттєве відновлення). Більшість організацій використовують Warm Standby як баланс.


Джерела

  1. AWS Documentation. (2024). Amazon EBS User Guide. https://docs.aws.amazon.com/ebs/
  2. AWS Documentation. (2024). Amazon S3 User Guide. https://docs.aws.amazon.com/s3/
  3. AWS Documentation. (2024). Amazon EFS User Guide. https://docs.aws.amazon.com/efs/
  4. AWS. (2019). Disaster Recovery of Workloads on AWS. AWS Whitepaper. https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/
  5. Microsoft. (2024). Azure Storage Documentation. https://learn.microsoft.com/en-us/azure/storage/
  6. Google Cloud. (2024). Cloud Storage Documentation. https://cloud.google.com/storage/docs
  7. Sasikala, S. (2021). Cloud Computing: Theory and Practice. Springer.

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

  1. Назвіть три парадигми хмарного зберігання та їх ключові відмінності. Яке використовується для баз даних, яке — для медіафайлів та backup?
  2. Що таке EBS-том? Яку роль виконує snapshot, і як реалізується інкрементальне резервне копіювання?
  3. Порівняйте типи EBS gp3 та io2. Для якого навантаження підходить кожен?
  4. Поясніть структуру Amazon S3: що таке bucket, object, key та metadata?
  5. Які класи зберігання S3 ви знаєте? Опишіть сценарій використання S3 Glacier Deep Archive.
  6. Що таке Lifecycle Policy у S3? Намалюйте схему автоматичного переміщення об’єктів між класами за часом.
  7. Що таке S3 Pre-signed URL? Для якого сценарію він використовується?
  8. Чим Amazon EFS відрізняється від EBS? Чи можна один EFS-том підключити одночасно до 10 EC2-інстансів?
  9. Поясніть поняття RTO та RPO. Для системи з RTO=1 год і RPO=15 хв — яка стратегія DR є мінімально необхідною?
  10. Що таке S3 Cross-Region Replication? Як вона допомагає в стратегії аварійного відновлення?