bukatchukМодель облачных услуг: IaaS/PaaS/SaaS, регионы, зоны, ответственность
Lesson from the course “Курс подготовки DevOps-инженеров”
Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: 1–2 часа.
Кратко о чём урок: Что именно арендуется, разделение ответственности между провайдером и клиентом, регионы и зоны доступности, влияние на архитектуру отказоустойчивости, vendor lock-in по факту.
1. Что изучаем
После урока вы сможете:
- называть для любого облачного сервиса, что именно арендуется и какая часть работы остаётся на вас — резервные копии, обновления, доступы;
- проверять, в каких зонах доступности вашему каталогу реально можно создавать ресурсы, и не путать это со списком зон, который отдаёт API;
- объяснять, какие ресурсы привязаны к зоне, а какие к региону, и показывать это командами;
- переводить задержку между зонами и процент SLA в числа, пригодные для решения: миллисекунды на запись, минуты простоя в месяц, рубли компенсации;
- перечислять, что из вашего решения переносится к другому провайдеру как есть, а что придётся переписать.
2. Зачем это нужно и где применяется
Облако продаёт не «серверы», а готовые слои инфраструктуры. Чем выше слой, тем меньше вы делаете руками и тем меньше контролируете. Это не абстракция: от ответа на вопрос «чья это забота» зависит, что вы найдёте утром после аварии.
Ситуации, из-за которых этот урок существует:
- «Облако же надёжное, зачем бэкапы» — ВМ удалили по ошибке вместе с диском. Провайдер отвечает за то, чтобы диск не потерялся из-за отказа железа, но не за то, что вы его удалили;
- «Поставили в две зоны — значит, отказоустойчиво» — база осталась в одной зоне, её диск зональный и к ВМ в другой зоне не подключается;
- «У нас SLA 99,95 %» — это 21,6 минуты простоя в месяц, которые провайдер не считает нарушением, и компенсация процентом от стоимости сервиса, а не от ваших убытков;
- «DNS указывает на старый адрес» — ВМ остановили на выходные, эфемерный публичный адрес после запуска сменился;
- «Перенесём к другому провайдеру за неделю» — образы и манифесты переносятся, а описание прав, сетевых правил и настройки управляемых сервисов пишутся заново.
3. Теория (30 минут)
Файлы для работы: blocks/11-cloud/examples/11.01-cloud-model/
Стенд: Yandex Cloud, регион
ru-central1, CLIyc1.37.0, каталог с рольюeditor. ВМ — прерываемые, Debian 13, 2 vCPU с долей 20 %, 1 ГБ памяти (0,46 ₽/ч по прайсу на 2026-09-26). Все числа урока сняты на этом стенде; задержки в другом каталоге и в другой день будут близкими, но не совпадут до сотых.
3.1. Что именно арендуется
Определения моделей услуг, на которые опираются и провайдеры, и стандарты, дал NIST в SP 800-145. Про IaaS там сказано так: «The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications».
Разница между моделями — в том, где проходит граница:
| Модель | Что вы получаете | Что остаётся вашим | Пример в Yandex Cloud |
|---|---|---|---|
| IaaS | ВМ, диск, сеть | ОС и её обновления, всё ПО, резервные копии, доступы, сетевые правила | Compute Cloud, VPC |
| PaaS | готовую платформу: базу, очередь, кластер | данные, схема, настройки, доступы, выбор окна обслуживания | Managed Service for PostgreSQL, Managed Kubernetes |
| SaaS | готовое приложение | пользователи и их права, сами данные | Yandex Tracker |
Там же NIST описывает свойство, которое отличает облако от аренды сервера, — общий пул: «The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model… the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter)». Последняя оговорка — это и есть регионы и зоны: единственный уровень, на котором вы выбираете место.
3.2. Кто за что отвечает
Yandex Cloud описывает разделение в документе «Разделение ответственности за обеспечение безопасности». Общий принцип: «Безопасность систем, использующих облачные сервисы, требует разделения ответственности между клиентом и провайдером». Для IaaS: «Провайдер отвечает за физическую безопасность и отказоустойчивость самой платформы», а «Клиент должен сам выполнять резервное копирование виртуальных машин, защищать виртуальную сеть». Для PaaS клиент «самостоятельно проводит классификацию данных, обеспечивает разграничение доступа к данным». И одна строка, которую стоит запомнить: «Во всех четырех ситуациях только клиент контролирует и управляет правами доступа» — четыре ситуации это свой сервер, IaaS, PaaS и SaaS.
Отсюда рабочее правило: доступ — всегда ваш, данные — всегда ваши, резервные копии — ваши везде, кроме управляемых сервисов, где их делает сервис, но настраиваете и проверяете вы. Провайдер отвечает за то, что лежит под вашим слоем, и ни за что над ним.
Два последствия, которые проверяются на практике:
- удаление — это ваше действие, а не отказ платформы. Удалили ВМ — загрузочный диск ушёл вместе с ней (так настроено по умолчанию), и восстановить его провайдер не обязан;
- подключённый диск, наоборот, переживает удаление ВМ. В опыте урока ВМ удалены, а два диска данных остались в каталоге и продолжали стоить денег, пока их не удалили отдельно. Это первая из утечек денег, которые разбираются в уроке 11.09.
3.3. Регион и зоны: список API против реальности
Регион — географическая площадка, зона доступности — её часть с независимым питанием, сетью
и охлаждением. Документация Yandex Cloud
(«Регионы и зоны доступности»)
на 2026-09-26 говорит: «Платформа Yandex Cloud размещается в четырех дата-центрах Яндекса»,
и перечисляет зоны ru-central1-a, ru-central1-b, ru-central1-d («рекомендуемая зона для
новых проектов»), ru-central1-e и ru-central1-m (отдельная зона сервиса BareMetal). Там же
оговорено: «Когда появляются новые зоны доступности или изменяется расположение старых,
Yandex Cloud уведомляет об этом всех клиентов».
А вот что отвечает API в тот же день:
$ yc compute zone list
+---------------+--------+
| ID | STATUS |
+---------------+--------+
| ru-central1-a | UP |
| ru-central1-b | UP |
| ru-central1-c | DOWN |
| ru-central1-d | UP |
| ru-central1-e | UP |
| ru-central1-k | UP |
+---------------+--------+
Зона c в списке есть, но выключена; зоны k нет в документации, а API сообщает UP.
Попытка создать в ней подсеть:
$ yc vpc subnet create --name lab-k --zone ru-central1-k --network-name lab-net --range 10.10.9.0/24
ERROR: … rpc error: code = PermissionDenied desc = Operation is not permitted in the folder
Вывод практический: список зон — это не список мест, где вы можете работать. Проверяется
созданием ресурса, и план размещения составляется по результату проверки, а не по выводу
zone list и не по старой статье, где зоны называются иначе.
3.4. Сколько стоит расстояние между зонами
Пять ВМ: две в зоне a и по одной в b, d и e. Задержка из зоны a, 50 пакетов ping,
два прогона:
| Откуда → куда | Среднее, мс (прогон 1) | Среднее, мс (прогон 2) |
|---|---|---|
| a → a (соседняя ВМ, контроль) | 0,364 | 0,349 |
| a → e | 0,337 | 0,342 |
| a → b | 3,505 | 3,443 |
| a → d | 5,207 | 5,166 |
Прогон лабораторной на другом наборе ВМ дал те же значения: 0,39–0,40 / 0,35–0,37 / 3,52–3,57 /
5,13–5,37 мс. Между b и d — 6,2 мс. Контрольная строка обязательна: без неё не понять, что такое «быстро».
С ней видно главное:
- между зонами задержка в 10–15 раз больше, чем внутри зоны (3,4–5,2 мс против 0,35 мс). Транзакция, которая ждёт подтверждения из соседней зоны, получает эти миллисекунды на каждый обмен. Для синхронной репликации базы это прямая добавка ко времени записи;
- зона
eиз зоныaнеотличима от соседней ВМ в той же зоне — 0,34 мс против 0,35 мс. Документация называетeзоной «на базе нового дата-центра», а измерение говорит, что по сети она рядом сa. Что это значит для совместных отказов, по задержке сказать нельзя — независимость зон обещает провайдер, а неping. Но выбирать пару зон для репликации только по задержке, не прочитав документацию, нельзя.
Одна оговорка про измерения со своей машины. С ноутбука автора задержка до тех же ВМ была около 300 мс, потому что трафик шёл через VPN за границу, а до одного адреса ICMP проходил, а TCP на порт 22 — нет. Изнутри облака тот же порт открывался. Задержка «от клиента» — свойство пути клиента; меряйте её отдельно и не смешивайте с задержкой внутри облака.
3.5. Что привязано к зоне, а что нет
Архитектура отказоустойчивости начинается с вопроса: что я смогу поднять в другой зоне, если эта пропадёт? Проверено командами:
| Ресурс | Привязка | Проверка |
|---|---|---|
| ВМ | зона | --zone обязателен при создании |
| подсеть | зона | ВМ зоны b в подсети зоны a: Zone in subnet does not match expected zone, код 1 |
| сеть (VPC) | регион | одна сеть объединяет подсети всех зон |
| сетевой диск | зона | attach-disk к ВМ другой зоны: disk belongs to different availability zone, код 1 |
| снимок диска | регион | у снимка нет поля zone_id; диск из него создаётся в любой зоне |
| эфемерный публичный адрес | ВМ | после остановки и запуска сменился: 158.160.224.114 → 158.160.187.112 |
Опыт со снимком целиком: на диск 1 ГБ в зоне a записана метка, снимок сделан за 16–18 с, из
снимка в зоне b создан диск за 18 с, и ВМ в зоне b прочитала метку ЗАПИСАНО-В-ЗОНЕ-A.
Снимок хранит 32 МБ, а не весь гигабайт, — платят за фактически занятое.
Из таблицы следуют три правила, на которых держатся уроки 11.03 и 11.07:
- данные в одной зоне — это не резервная копия. Диск зоны
aв аварии зоныaнедоступен вместе с ВМ. Копия, пригодная для переезда, — снимок (или копия в объектном хранилище, урок 11.06); - перенос между зонами — это пересоздание из копии, а значит, потеря всего, что записано после снимка. Отсюда RPO, которое вы сами выбираете частотой снимков;
- на эфемерный адрес нельзя завязывать ничего снаружи: DNS, списки разрешённых адресов у партнёров. Для этого есть статические адреса и балансировщики (урок 11.05).
3.6. SLA: что на самом деле обещано
Уровень обслуживания Compute Cloud для единичной ВМ — «99,95%». Переведите процент в минуты: за месяц в 30 дней это 0,0005 умножить на 43 200 = 21,6 минуты простоя, которые нарушением не считаются. Недоступностью считается «потеря связности или загрузочного диска Виртуальной машины» по причинам на стороне провайдера. Компенсация — «10,0%» при доступности от 99,00 до 99,95 %, 15 % ниже 99 % и 30 % ниже 95 % — процент от стоимости потреблённого сервиса. Для ВМ за 1,4 ₽/ч это рубли, даже если ваш сервис стоял полдня.
И отдельная строка из документации прерываемых ВМ: «Для прерываемых машин не действует соглашение об уровне обслуживания (SLA)». Их останавливают, «если с момента запуска виртуальной машины прошло 24 часа» или «если возникнет нехватка ресурсов для запуска обычной виртуальной машины в той же зоне доступности». Зато цена: ядро с долей 20 % стоит 0,166 ₽/ч против 0,52 ₽/ч у обычной ВМ, память — 0,083 против 0,33 ₽ за ГБ·ч, то есть в три-четыре раза дешевле. Для учебных стендов, сборок и пакетной обработки это правильный выбор; для сервиса, который должен отвечать, — нет.
Вывод: SLA описывает, когда провайдер вернёт часть денег, а не сколько будет работать ваш сервис. Доступность сервиса вы строите сами — несколькими зонами, копиями и проверенным восстановлением.
3.7. Vendor lock-in по факту
Привязку к провайдеру удобно раскладывать не на «есть/нет», а по слоям:
| Слой | Переносимость | Почему |
|---|---|---|
| приложение в контейнере | высокая | образ OCI запускается где угодно (урок 08.11) |
| манифесты Kubernetes | высокая, кроме классов хранилища и балансировщиков | стандартный API (блок 13) |
| данные в S3-совместимом хранилище | высокая | API общий, инструменты те же (урок 11.06) |
| образ ВМ | средняя | формат переносим, но драйверы и агенты облака внутри |
| сеть, группы безопасности, маршруты | низкая | у каждого провайдера своя модель и свои умолчания |
| права доступа (IAM) | низкая | роли, иерархия и сервисные аккаунты свои у каждого |
| настройки managed-сервисов | низкая | параметры, версии, окна обслуживания — свои |
| способ входа и автоматизация вокруг API | низкая | меняется по решению провайдера |
Последняя строка — не теория. При подготовке этого урока старый способ входа в CLI перестал
работать: yc отвечал OAuth token … issued after '2026-06-01', is not supported for IAM token exchange, и обновление CLI само по себе не помогло — пришлось переходить на вход через браузер,
а для автоматизации на сервисный аккаунт с ключом (урок 11.02). Все скрипты, которые полагались
на OAuth-токен в переменной окружения, остановились в один день без единого изменения в них.
Практический вывод не «избегать облачных сервисов», а знать цену выхода: держать переносимым то, что дёшево держать переносимым (контейнеры, данные, описание инфраструктуры кодом — блок 12), и осознанно платить привязкой за то, что облако делает лучше вас.
3.8. Сводка: что показали замеры
| Утверждение | Что показал замер |
|---|---|
| «зон в регионе столько, сколько в списке» | из шести в zone list одна DOWN, одна отвечает PermissionDenied; рабочих четыре |
| «между зонами почти как внутри» | в 10–15 раз медленнее: 3,4–5,2 мс против 0,35 мс |
| «разные дата-центры — значит, далеко» | зона e из зоны a неотличима от соседней ВМ по задержке |
| «диск можно подключить к любой ВМ» | только в своей зоне; между зонами — через снимок |
| «удалил ВМ — удалил всё» | загрузочный диск да, подключённые — нет |
| «публичный адрес закреплён за ВМ» | эфемерный сменился после остановки |
| «SLA гарантирует работу сервиса» | гарантирует компенсацию процентом от цены; прерываемых ВМ не касается |
3.9. Примеры и варианты реализации
Одна задача — разместить сервис так, чтобы он пережил потерю площадки, — в трёх средах.
| Среда | Как решается | Что нужно иметь |
|---|---|---|
| Локальный стенд (Docker / VM / kind) | площадку потерять нельзя: всё на одной машине; тренируется только логика — несколько узлов kind, восстановление из копии | одна машина |
| VPS / bare-metal | вы сами выбираете и арендуете вторую площадку, связываете их сетью, настраиваете репликацию и переключение | два провайдера или две площадки одного, VPN между ними, время на сопровождение |
| Yandex Cloud | подсети в нескольких зонах одной сети, ВМ или группы ВМ в разных зонах, снимки и копии, managed-сервисы с хостами в разных зонах | каталог с правами, бюджет на вторую копию всего |
Локальный стенд. Отказ площадки на одной машине не моделируется в принципе: у всех «узлов» одно питание и одна сеть. Полезно ровно одно — отрабатывать восстановление из копии и переключение, как в уроках 13.11 и 14.12. Задержки между «зонами» здесь нулевые, и привычки, выработанные на них, в облаке обманывают.
VPS / bare-metal. Зон доступности у одного VPS-провайдера обычно нет, есть дата-центры в разных городах с задержкой в десятки миллисекунд. Всё, что облако даёт одной командой, — общая сеть на несколько площадок, переносимые снимки, балансировщик перед ними — собирается руками: VPN (урок 05.14), копии на другую площадку, свой балансировщик. Дешевле по счёту, дороже по времени и по числу мест, где можно ошибиться.
Yandex Cloud. Это вариант урока: четыре рабочие зоны с задержкой единицы миллисекунд, одна сеть на все зоны, снимки на уровне региона. Цена — вторая копия всего, что должно пережить отказ зоны, и обязательная проверка, что копия действительно поднимается в другой зоне.
Что выбрать. Для учёбы и экспериментов — облако с прерываемыми ВМ и уборкой после каждого опыта: стенд из пяти ВМ стоит около 2,6 ₽/ч. Для сервиса, простой которого стоит денег, — облако с размещением в двух-трёх зонах и проверенным восстановлением. Свои площадки оправданы, когда облако запрещено требованиями или когда постоянная нагрузка настолько велика, что разница в цене окупает команду эксплуатации.
4. Практика на занятии (30 минут)
Курс проходят самостоятельно, поэтому каждый шаг говорит, что ввести, зачем, что должно
получиться и что делать при неудаче. Опыты — в
lab-zones.sh, инвентаризация каталога —
yc-inventory.py, цены —
yc-prices.py. Нужны yc с профилем и каталогом,
где у вас роль editor, ssh и python3. Стенд стоит около 2,6 ₽/ч; в конце занятия его
надо убрать.
Шаг 1 (4 минуты). Какие зоны доступны вашему каталогу.
- Что ввести:
cd blocks/11-cloud/examples/11.01-cloud-model
YC_PROFILE=<ваш профиль> ./lab-zones.sh zones
- Зачем: список зон из API и реально доступные каталогу зоны — разные вещи, и это первое, что стоит проверить перед планом размещения.
- Ожидаемый результат: таблица вида из раздела 3.3 —
ru-central1-a/b/d/e/kв статусеUP,ru-central1-cв статусеDOWN. - Если не так: пустой вывод или ошибка авторизации — проверьте
YC_PROFILEи что профиль вообще существует (yc config profile list);PermissionDeniedна этом шаге означает, что у профиля нет доступа даже на чтение зон, и это отдельная проблема с ролью. - Ответьте: какая зона есть в API, но недоступна вам?
Шаг 2 (6 минут). Стенд.
- Что ввести:
./lab-zones.sh up
- Зачем: поднять пять прерываемых ВМ в разных зонах — без них нечем мерить задержку и привязку ресурсов к зоне.
- Ожидаемый результат: пять ВМ в зонах
a,a,b,d,e; публичный адрес только у первой — через неё идёт вход к остальным. - Если не так:
ResourceExhaustedна сети или квоте — в каталоге уже есть чужие ресурсы, смотрите урок 11.09 про квоты; долгое ожидание без результата — ВМ прерываемые, и при нехватке ресурсов в зоне создание может не завершиться вовсе, тогда стоит попробовать позже.
Пока ВМ создаются, посчитайте цену стенда в час по прайсу:
- Что ввести:
export YC_TOKEN=$(yc iam create-token) YC_SKU_CACHE=/tmp/skus.json
./yc-prices.py "Preemptible" "Ice Lake" "20% vCPU"
./yc-prices.py "Preemptible" "Ice Lake, RAM"
./yc-prices.py "Public IP address (dynamic"
- Зачем: прежде чем создавать платные ресурсы, знать их цену по действующему прайсу, а не по памяти — цены меняются.
- Ожидаемый результат: цены, согласующиеся с разделом 3.6: ядро с долей 20 % — 0,166 ₽/ч, память — 0,083 ₽/ГБ·ч.
- Если не так: пустой вывод —
YC_TOKENне создался (проверьтеyc iam create-tokenотдельно) либо название SKU в прайсе изменилось — ищите ближайшее совпадение черезyc-prices.pyбез фильтра.
Шаг 3 (6 минут). Задержка между зонами.
- Что ввести:
./lab-zones.sh rtt
- Зачем: задержка между зонами — не абстракция из документации, а число, которое ляжет в бюджет времени синхронной репликации.
- Ожидаемый результат: таблица вроде раздела 3.4 — контрольная строка
a → aоколо 0,35 мс, остальные зоны заметно медленнее. - Если не так: все значения примерно одинаковые — проверьте, что ВМ действительно в разных
зонах (
./lab-zones.sh zonesпокажет список созданных ВМ); аномально большие числа (сотни миллисекунд) — вы измеряете не изнутри облака, а со своей машины через VPN, это задержка другого пути (см. раздел 3.4). - Ответьте: найдите контрольную строку. Во сколько раз задержка до ближайшей чужой зоны больше? Какая зона ведёт себя как соседняя?
Шаг 4 (9 минут). Диск, снимок и адрес.
- Что ввести:
./lab-zones.sh disk
./lab-zones.sh ip
- Зачем: проверить не по документации, а командой, что диск привязан к зоне, а перенос данных между зонами идёт только через снимок; и что эфемерный адрес не постоянен.
- Ожидаемый результат: первый режим — отказ
disk belongs to different availability zoneпри прямом подключении, затем успешный перенос через снимок (раздел 3.5); второй режим — два разных адреса до и после остановки ВМ. - Если не так: подключение диска к чужой зоне прошло без ошибки — проверьте, что диск и ВМ правда в разных зонах, а не в одной; адрес не изменился после остановки — возможно, у ВМ статический, а не эфемерный адрес, тогда сравнение ничего не покажет.
Шаг 5 (5 минут). Уборка и проверка.
- Что ввести:
./lab-zones.sh down
./yc-inventory.py
- Зачем: деньги за забытые ресурсы продолжают списываться и после того, как ВМ удалены — подключённые диски их переживают (раздел 3.2).
- Ожидаемый результат: инвентаризация отвечает
каталог пустс кодом 0. - Если не так: код 1 и список ресурсов в выводе — в каталоге осталось что-то платное
(чаще всего диск данных, не удалённый вместе с ВМ); удалите его явно и прогоните
yc-inventory.pyснова.
Что обсудить в конце занятия. Сервис из блока 07: прокси, приложение, PostgreSQL, Redis. Какие из этих компонентов вы положите в две зоны, а какие оставите в одной, и чем заплатите в каждом случае — деньгами, миллисекундами или потерей данных?
5. Домашняя работа (1–2 часа)
Задание. Составьте карту отказов сервиса из блока 07 по заготовке
failure-map.md: для каждого компонента —
модель услуги и кто делает копии; ваши собственные замеры задержки между зонами; что привязано
к зоне; что остаётся работать при отказе каждой зоны и какие данные теряются; стоимость
раскладки в одну, две и три зоны по текущему прайсу; что будет трудно перенести к другому
провайдеру. Замеры делаются лабораторной lab-zones.sh, цены — yc-prices.py.
Критерии приёмки.
- Таблица из раздела 1 заготовки заполнена для всех пяти компонентов, и для каждого указано, кто делает резервные копии.
- Числа задержки сняты своим прогоном
lab-zones.sh rtt(два прогона), контрольная строка «a → a» заполнена. - Для диска и снимка указана команда, которой проверена привязка, и её результат.
- Раздел «Отказ зоны» заполнен для каждой зоны раскладки, названы конкретные данные и период их потери.
- Цены указаны с датой и источником.
- После работы
./yc-inventory.pyотвечаеткаталог пуст, вывод вставлен в файл.
6. Частые ошибки и подводные камни
Ресурс не создаётся в зоне, которая есть в списке. Симптом:
PermissionDenied … Operation is not permitted in the folder при создании подсети или ВМ.
Причина: yc compute zone list показывает зоны платформы, а не доступные вашему каталогу.
Что делать: проверять зону созданием ресурса и сверять с документацией; для новых проектов
документация рекомендует ru-central1-d.
Диск не подключается к ВМ. Симптом: disk belongs to different availability zone.
Причина: диск зональный. Что делать: снимок и новый диск из снимка в нужной зоне — и помнить,
что это копия на момент снимка, а не перенос.
Деньги списываются после удаления ВМ. Симптом: ВМ нет, а в счёте диски. Причина:
подключённые диски не удаляются вместе с ВМ, удаляется только загрузочный (с настройками
по умолчанию). Что делать: после каждого опыта — инвентаризация каталога (yc-inventory.py),
а не проверка списка ВМ.
Сломался DNS после остановки ВМ. Симптом: сервис не отвечает по имени, ВМ работает. Причина: эфемерный публичный адрес сменился при запуске. Что делать: статический адрес или балансировщик (урок 11.05), на эфемерный адрес ничего не завязывать.
«Отказоустойчиво, потому что в двух зонах». Симптом: при аварии одной зоны сервис всё равно лежит. Причина: в другой зоне только приложение, а база и её диск — в пострадавшей. Что делать: пройти карту отказов по каждой зоне (домашняя работа) и для каждого компонента назвать, где копия и как долго её поднимать.
Прерываемая ВМ под сервисом. Симптом: сервис пропадает раз в сутки или без причины. Причина: прерываемую ВМ останавливают через 24 часа и при нехватке ресурсов, SLA на неё не действует. Что делать: прерываемые — для стендов, сборок и пакетных задач; для сервиса — обычные ВМ или группа ВМ, которая сама поднимает остановленные (урок 11.03).
Выводы о задержке по замеру с ноутбука. Симптом: «облако медленное, 300 мс». Причина: в числе путь от вас до облака — VPN, провайдер, другой город. Что делать: мерить задержку между ресурсами изнутри облака, а путь клиента — отдельно.
7. Проверка усвоения
- Вы перевели базу из ВМ в managed-сервис. Какие обязанности ушли к провайдеру, а какие остались у вас? Назовите хотя бы по две.
yc compute zone listпоказывает зонуUP. Достаточно ли этого, чтобы включить её в план размещения? Как проверить?- Задержка внутри зоны 0,35 мс, между зонами — 3,5 мс. Транзакция делает три синхронных обмена с репликой. На сколько вырастет время записи, если реплику перенести в соседнюю зону?
- Почему снимок годится для переноса данных между зонами, а диск — нет? Чем вы платите за перенос через снимок?
- SLA единичной ВМ — 99,95 %. Сколько минут простоя в месяц это допускает, и что вы получите, если сервис простоял четыре часа?
- Какие части решения из блоков 07–08 перенесутся к другому провайдеру без изменений, а какие придётся переписать?
- Почему после удаления всех ВМ счёт может продолжать расти? Что проверить?
8. Материалы
- NIST SP 800-145. The NIST Definition of Cloud Computing — первоисточник терминов IaaS, PaaS, SaaS и пяти существенных свойств облака. Три страницы по существу; стоит прочитать целиком один раз, чтобы спорить о терминах по тексту.
- Yandex Cloud: регионы и зоны доступности — актуальный список зон и рекомендуемая зона для новых проектов. Сверяйте с ним любой план размещения.
- Yandex Cloud: разделение ответственности за обеспечение безопасности — что делает провайдер и что клиент в моделях IaaS, PaaS и SaaS.
- Прерываемые виртуальные машины и уровень обслуживания Compute Cloud — условия остановки прерываемых ВМ и точные формулировки SLA с таблицей компенсаций.
- Site Reliability Engineering, глава «Embracing Risk» — как переводить проценты доступности в допустимый простой и почему «100 %» — неправильная цель. Книга Google в открытом доступе, на английском.
- AWS Well-Architected Framework: Reliability Pillar — подробное руководство по размещению в нескольких зонах. Написано для AWS, но зоны и регионы устроены так же; удобно читать вместе с уроком 11.10.
← Предыдущий: 10.08. Границы применимости: cloud-init, Packer, IaC · Блок 11 · Следующий: 11.02. Yandex Cloud: организация, облака, каталоги, IAM, сервисные аккаунты →
Practice materials
Scripts, cheat sheets and starter files for the lesson tasks. The lesson text is on this page.
-
Lesson materials 11.01 «Модель облачных услуг IaaS PaaS SaaS, регионы, зоны, ответственность».zip