Что такое облачный хостинг и как он работает

Облачный сервер – это виртуальная машина, по сути тот же VPS: своя операционная система, свой root, свой IP-адрес. В каждый момент времени она работает на одном физическом сервере, а не «на ресурсах множества машин сразу», как любят писать в рекламе. Облачной её делает платформа вокруг: ты сам создаёшь и удаляешь серверы за минуту, платишь по часам, диски и IP-адреса существуют отдельно от машины, а при поломке железа платформа умеет перезапустить или перенести твою VM на соседний хост.

Для одного сайта с ровной посещаемостью разница между облачным и обычным VPS почти незаметна, и выбирать стоит по цене, локации и качеству железа. Облако начинает окупаться, когда серверы приходится часто создавать и выбрасывать, когда проект собирается из нескольких машин или когда отказ хоста должен заканчиваться автоматическим перезапуском, а не тикетом в поддержку.

Облако или обычный VPS: короткий ответ

Ситуация	Что подходит	Почему
Один сайт, блог или небольшой магазин с предсказуемой нагрузкой	Обычный или облачный VPS, что дешевле при тех же ресурсах	Облачные функции будут простаивать, а платить за них придётся в цене тарифа
Тестовые стенды, проверка обновлений, разовые задачи	Облако с почасовой оплатой	Создал сервер на пару часов, удалил, заплатил за пару часов
Сезонные пики: распродажи, приём заявок, запуск рекламы	Облако, но с заранее подготовленной архитектурой	Ресурсы добавляются быстро, однако сайт должен уметь работать на нескольких машинах
Отказ железа не должен требовать ручного вмешательства	Облако с сетевыми дисками или несколько серверов в разных зонах	Одна VM на локальном диске падает вместе со своим хостом
Нагруженная база данных, много операций записи	VPS с локальным NVMe или выделенный сервер	Сетевой диск добавляет задержку к каждой операции ввода-вывода
Много исходящего трафика: видео, архивы, файлообменник	Провайдер, у которого трафик включён в тариф	У крупных облаков трафик наружу оплачивается за каждый гигабайт сверх небольшого лимита

Дальше разберём, откуда берутся эти различия, что реально происходит внутри облачной платформы и на чём новички теряют деньги и нервы.

Что на самом деле стоит за словом «облачный»

Самое внятное определение облака дал американский институт стандартов NIST ещё в 2011 году, и оно до сих пор хорошо работает как фильтр. Облако там описано через пять свойств, и каждое легко перевести на язык того, что ты увидишь в панели. Ты сам создаёшь сервер в панели или через API, без заявки и ожидания менеджера. Твоя машина делит физический сервер с чужими, и на какой именно хост её поставить, решает платформа, а не ты. Ресурсы добавляются и убираются за минуты. Потребление измеряется, т.е. счёт приходит за часы или минуты работы. Ну и всё это доступно по сети из любой точки.

Заметь, чего в этом списке нет: «сайт работает на мощностях многих серверов одновременно». Процессор и оперативная память облачной VM берутся с одного хоста, как и у любого VPS. Распределённым может быть хранилище, о нём ниже, и распределённой бывает сама платформа управления. Но если твой сайт упирается в процессор, облако не размажет нагрузку по соседним машинам, пока ты сам не поставишь вторую машину и не разделишь между ними трафик.

Когда собираешь тарифы для рейтинга, хорошо видно, насколько вольно рынок обращается со словом «облачный». Им называют и полноценную платформу с API, балансировщиками и сетевыми дисками, и обычный VPS с помесячной оплатой, у которого облачного только название тарифа. Проверка простая: можно ли создать сервер через API и платить по часам? Если нет ни того ни другого, перед тобой обычный VPS. Он от этого не хуже, просто сравнивать его надо с обычными VPS, а цену облачной надбавки за него не платить.

Технология виртуализации под капотом у большинства облаков та же, что и у классических VPS, чаще всего KVM. Чем она отличается от контейнерной, разобрано в статье о KVM и OpenVZ.

Как это устроено внутри: вычисления, диски, сеть

Облачную платформу удобно представлять тремя слоями. Первый – вычислительные хосты: физические серверы, на которых крутятся виртуальные машины. Второй – хранилище, где лежат диски этих машин. Третий – сеть, которая связывает машины между собой и с интернетом. От того, как провайдер собрал второй слой, зависит больше, чем от всех остальных параметров тарифа.

Где лежит диск твоей машины

Вариантов два, и у каждого своя цена.

При локальном хранении диск VM находится на NVMe внутри того же физического сервера, где работает сама машина. Это быстро и дёшево: между процессором и данными нет сети. Слабое место одно, но существенное. Если хост умер, твоя машина недоступна, пока его не починят или пока провайдер не восстановит данные. Так устроены корневые диски у многих популярных облаков среднего класса.

При сетевом хранении диск живёт в отдельном кластере хранения, чаще всего на Ceph, где каждый блок данных записан в двух-трёх копиях на разных серверах. Хост с твоей VM сгорел, а диск цел, и платформа поднимает машину на другом хосте с тем же диском, обычно за считанные минуты. За это платишь задержкой: каждая операция чтения или записи проходит через сеть дата-центра. Для статики и PHP-сайта с нормальным кэшем это почти незаметно, а вот база данных с частыми мелкими записями чувствует разницу сразу.

Многие провайдеры совмещают оба подхода: корневой диск локальный, а дополнительные тома (их обычно называют volumes) сетевые, и их можно отключить от одной машины и подключить к другой. Подробнее о таких томах в статье о блочном хранилище.

Провайдер не всегда пишет на странице тарифа, какой у тебя диск. Косвенно это видно по задержке. Поставь ioping и сделай десяток замеров:

sudo apt install ioping
ioping -c 10 /

На локальном NVMe внутри виртуалки задержка обычно держится в районе десятых долей миллисекунды. На сетевом хранилище типичны значения от половины миллисекунды до нескольких миллисекунд, и разброс между замерами заметно больше. Цифры условные, многое зависит от загрузки хоста и настроек платформы, но разница в разы обычно видна невооружённым глазом.

Живая миграция и что при этом видно изнутри

Крупные платформы умеют переносить работающую машину с хоста на хост без перезагрузки. Google описывает этот процесс подробно: сначала память VM копируется на новый хост, пока машина продолжает работать, потом её на мгновение останавливают, досылают изменившиеся данные и запускают уже на новом месте. Пауза, по их документации, обычно заметно меньше секунды, а системные часы могут скакнуть вперёд на несколько секунд. Так провайдер обновляет железо и прошивки, не трогая клиентов.

Изнутри это выглядит как короткий провал в графиках и рывок времени в логах, которых без мониторинга никто бы и не заметил. Если же хост отказал целиком и перенос невозможен, машина просто перезапускается на другом сервере, т.е. ты увидишь обычную перезагрузку.

Сеть: то, чего нет у обычного VPS

Сетевой слой облака даёт несколько вещей, которые на классическом VPS делаются через поддержку или не делаются вовсе. Плавающий IP (floating IP) можно за секунды перекинуть с одного сервера на другой, и это самый дешёвый способ организовать переключение на запасную машину. Приватная сеть соединяет твои серверы внутри дата-центра, и база данных может вообще не иметь публичного адреса. Облачный файрвол фильтрует трафик ещё до того, как он дойдёт до машины. Балансировщик нагрузки распределяет запросы между несколькими серверами.

Кстати, у облачных VM бывают ограничения, о которых на классическом VPS и не думаешь. Например, в облаке Hetzner прямо сказано, что вложенная виртуализация на облачных серверах невозможна, так что поднять внутри такой машины свой гипервизор вроде Proxmox не выйдет. Если такая задача стоит, читай о вложенной виртуализации до покупки, а не после.

Масштабирование: что происходит после кнопки «увеличить»

Обещание «ресурсы подстраиваются под нагрузку автоматически» звучит так, будто сервер сам растёт, когда на сайт пришла толпа. С одной машиной это не так. Масштабирование бывает двух видов, и работают они совсем по-разному.

Вертикальное: та же машина, больше ресурсов

Ты меняешь тариф, машина получает больше ядер, памяти и, по желанию, диска. На большинстве платформ для этого сервер нужно выключить. DigitalOcean, например, прямо требует выключить машину перед сменой размера и предупреждает, что простой может растянуться до минуты на каждый гигабайт занятого места на диске: при смене тарифа машина иногда переезжает на другой хост, и данные копируются по сети. На практике обычно быстрее, но заложить окно простоя в план всё равно придётся.

Самое неприятное здесь в другом. Диск можно только увеличить. Уменьшить его обратно не дают ни DigitalOcean, ни Hetzner: сжимать файловую систему и разделы на живых данных слишком рискованно. Поэтому при апгрейде обе платформы предлагают вариант «только процессор и память», с прежним размером диска. Выглядит мелочью, но на клиентских проектах это одна из самых частых ловушек: тариф подняли целиком «на сезон распродаж», а после сезона выясняется, что вернуться на младший план нельзя, потому что диск уже больше, чем в нём положено.

Если диск всё же увеличил, на облачных образах Ubuntu и Debian раздел и файловая система обычно растягиваются сами при следующей загрузке: этим занимается cloud-init, его модули growpart и resizefs запускаются на каждом старте. Если после перезагрузки df показывает старый размер, растяни вручную:

df -h /
lsblk
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1

Имя диска смотри в выводе lsblk: это может быть vda, sda или nvme0n1, и номер раздела не обязательно 1. Для файловой системы XFS вместо resize2fs нужна команда sudo xfs_growfs /. Весь процесс по шагам, с LVM и без, будет в статье о расширении диска на VPS.

Горизонтальное: больше одинаковых машин

Вот здесь и живёт то самое автоматическое масштабирование. Платформа держит группу одинаковых серверов за балансировщиком и добавляет новые, когда нагрузка растёт. Механизм рабочий, но с одним условием: твоё приложение должно уметь работать сразу на нескольких машинах.

Возьмём обычный WordPress. Картинки загружаются в папку на диске конкретного сервера. Сессии и кэш тоже лежат локально. База данных стоит там же. Клонируешь такую машину, и у тебя два сайта с разными загрузками и разными базами, а не один сайт на двух серверах. Чтобы горизонтальное масштабирование заработало, базу выносят на отдельный сервер, файлы в объектное хранилище S3, сессии и кэш в Redis, а перед веб-серверами ставят балансировщик.

Облако тут ни при чём. Масштабируется архитектура, а не тариф.

Для большинства небольших проектов честный ответ звучит так: вертикального запаса хватит надолго, а горизонтальная схема окупается тогда, когда простой стоит дороже, чем пара лишних серверов и время на их настройку. Разница между подходами подробно разобрана в статье о вертикальном и горизонтальном масштабировании.

Почасовая оплата: где экономия, а где ловушка

«Платишь только за то, что используешь» – главная фраза облачной рекламы, и она верна лишь наполовину. Платишь ты не за нагрузку, а за выделенные ресурсы, и не за время работы, а за время существования сервера. Hetzner в своём FAQ формулирует это без обиняков: сервер оплачивается, пока он существует, независимо от того, включён он или выключен, ведь ресурсы за ним закреплены. Неполный час округляется до целого. Сверху стоит месячный потолок, дороже которого сервер не обойдётся.

Отсюда простая арифметика. Сервер, который работает круглосуточно, в облаке с почасовой оплатой стоит примерно столько же, сколько аналогичный VPS с месячной, а то и дороже. Экономия появляется, только когда машина живёт часть времени: тестовый стенд на вечер, сборка проекта, разовая выгрузка данных. Если сервер нужен раз в неделю, его выгоднее не выключать, а сохранить в снапшот и удалить, а потом создать заново из снапшота. Снапшот оплачивается за гигабайты хранения, и это обычно дешевле простаивающей машины.

Остальные статьи расходов в облаке разнесены по отдельным строкам счёта, и именно они набегают незаметно. Автоматические бэкапы у Hetzner стоят 20% от цены сервера. Публичный IPv4 там оплачивается отдельно от машины и продолжает списываться, даже если отвязан от сервера. Снапшоты копятся. Исходящий трафик у европейских провайдеров среднего класса часто включён в тариф терабайтами, а у крупных облаков оплачивается за каждый гигабайт сверх небольшого бесплатного объёма, и для сайта с видео или файлами это может оказаться главной строкой счёта.

Когда разбираешь чужие облачные счета, переплата чаще всего оказывается не в трафике и не в мощности, а в забытом: выключенный «на время» тестовый сервер, снапшот трёхмесячной давности, отвязанный адрес, том, который отключили от машины, но не удалили… Оповещения о расходах в панели помогают, но это именно оповещения. Hetzner отдельно подчёркивает, что они не ограничивают траты: перерасход будет списан, даже если письмо не дошло.

Из чего ещё складывается цена сервера, разобрано в статье о стоимости VPS.

SLA и надёжность: что обещают на бумаге

Фраза «облако – значит сайт всегда онлайн» разбивается о любое соглашение об уровне сервиса. Возьмём SLA Amazon EC2, одного из самых крупных облаков. Для отдельной машины обещана доступность 99,5% в месяц. Это около трёх с половиной часов простоя в месяц, при которых соглашение формально не нарушено. Цифра 99,99% там тоже есть, но относится к ситуации, когда твои машины работают одновременно минимум в двух зонах доступности, т.е. в физически разных дата-центрах региона.

Компенсация при нарушении SLA тоже выглядит скромнее, чем кажется. Это не возврат денег и не возмещение убытков, а скидка на будущие счета: 10%, 30% или 100% месячной стоимости пострадавшего ресурса, в зависимости от глубины провала, и только по заявке с логами. Выводы делай сам: SLA описывает, сколько тебе вернут, а не сколько будет работать сайт. Как читать такие документы у разных провайдеров, будет в статье о SLA и гарантиях аптайма.

С данными та же история. У облачных провайдеров есть понятие разделённой ответственности: провайдер отвечает за железо, гипервизор и сеть, а за всё внутри машины, включая сохранность файлов и базы, отвечаешь ты. Встроенные бэкапы и снапшоты провайдера удобны, но лежат они в его же инфраструктуре и привязаны к твоему же аккаунту. Заблокированный за неоплату аккаунт или случайно удалённый проект забирает их вместе с серверами. Поэтому копия данных должна лежать где-то ещё, об этом подробно в статьях об основах резервного копирования и о правиле 3-2-1.

Что непривычного ждёт в консоли облачного сервера

Облачные образы Linux отличаются от того, что ставится с установочного диска, и первое, с чем сталкиваешься, это cloud-init. Это служба, которая при первом запуске машины забирает у платформы её настройки: имя хоста, SSH-ключи, сетевые параметры, пользовательские скрипты. Часть модулей cloud-init срабатывает при каждой загрузке, и отсюда растёт целый класс вопросов «почему мои правки пропали после перезагрузки».

Классический пример – файл /etc/hosts. На многих облачных образах в его начале стоит комментарий о том, что файлом управляет cloud-init и изменения надо вносить в шаблон в /etc/cloud/templates/ или отключать параметр manage_etc_hosts. Комментарий честный, но его мало кто читает, пока правки не исчезнут после первого же ребута. С SSH похожая история: облачный образ может положить свой файл 50-cloud-init.conf в /etc/ssh/sshd_config.d/, и он снова разрешит вход по паролю, который ты только что запретил в основном конфиге. Как с этим справиться, разобрано в статье о первых шагах на новом VPS.

Несколько команд, чтобы понять, с чем имеешь дело:

cloud-init status --long
head -n 12 /etc/hosts
ls /etc/ssh/sshd_config.d/
systemd-detect-virt
top -bn1 | head -n 5

Первая покажет, отработал ли cloud-init и с каким источником данных. systemd-detect-virt назовёт тип виртуализации, на облачных платформах это обычно kvm. В выводе top присмотрись к полю st (steal time) в строке с загрузкой процессора: это доля времени, когда твоя машина хотела работать, но гипервизор отдал процессор соседям. На тарифах с общими ядрами несколько процентов steal – нормальная картина. Если он регулярно уходит за 10–20%, сайт будет тормозить при пустом на вид сервере, и это повод смотреть в сторону выделенных ядер. Чем они отличаются от общих, разобрано в статьях о vCPU и о shared и dedicated CPU.

Ещё один сюрприз ждёт тех, кто собирается отправлять почту прямо с сервера. Многие облачные провайдеры по умолчанию закрывают исходящий порт 25. Hetzner, например, блокирует порты 25 и 465 на всех облачных серверах и открывает их по запросу, не раньше чем через месяц после регистрации и оплаты первого счёта. Защищаются так от спамеров, которые любят дешёвые одноразовые машины. Письма через внешний SMTP-сервис по порту 587 при этом уходят без ограничений. Если планируешь свой почтовый сервер, сначала прочитай статью о почтовом сервере на VPS.

И мелочь, которая сбивает с толку: графики в облачной панели часто показывают процессор, диск и сеть, но не оперативную память. Платформа видит машину снаружи, а сколько памяти занято внутри, знает только сама ОС. Без своего мониторинга внутри VM утечку памяти по панели провайдера не поймаешь, инструменты для этого описаны в статье о мониторинге нагрузки.

Безопасность: облако не сделает её за тебя

Облачный файрвол на уровне платформы хорош тем, что лишний трафик отсекается до того, как дойдёт до машины. Но внутри VM всё равно нужен свой: правила платформы легко поменять одним кликом не на том проекте, и защита пропадёт целиком. Обновления ОС, пароли, ключи, права на файлы и сам сайт остаются твоей зоной ответственности. С чего начинать, описано в статьях о базовой защите VPS и о файрволах UFW и iptables.

Как проверить облачного провайдера до оплаты

Перед тем как переносить проект, задай провайдеру (или найди в документации) ответы на несколько вопросов. Они отделяют настоящую облачную платформу от VPS с облачным названием и заодно показывают, во что обойдётся год работы.

• Оплата почасовая или помесячная? Списываются ли деньги за выключенный сервер?
• Где лежит корневой диск: локально на хосте или в сетевом хранилище? Что происходит с машиной при отказе хоста?
• Нужно ли выключать сервер для смены тарифа и можно ли потом вернуться на тариф с меньшим диском?
• Сколько трафика включено в цену и сколько стоит перерасход?
• Есть ли API, снапшоты, приватные сети, плавающие IP, балансировщик?
• Какой процент доступности указан в SLA, на что он распространяется и чем компенсируется нарушение?
• Открыт ли исходящий порт 25 и как его разблокировать?
• Отдельно ли оплачивается IPv4 и сколько стоят бэкапы?

Потом стоит прогнать тестовый сервер хотя бы день: замерить диск, посмотреть на steal, проверить пинг из нужной тебе страны. Как это сделать, разобрано в статье о тестировании VPS перед покупкой, а сравнить облачные тарифы разных провайдеров можно в подборке Cloud VPS и в общем рейтинге VPS.

Если на половину вопросов провайдер отвечает «это обычный VPS с месячной оплатой», ничего страшного. Просто сравнивай его с обычными VPS по цене и железу, а облачные функции ищи у тех, кто их действительно продаёт.

Источники

• NIST SP 800-145: The NIST Definition of Cloud Computing
• Amazon Compute Service Level Agreement
• Shared Responsibility Model – AWS
• Live migration process during maintenance events – Google Compute Engine
• How to Resize Droplets for Vertical Scaling – DigitalOcean Documentation
• Hetzner Cloud: Billing FAQ
• Hetzner Cloud: Servers FAQ
• Module reference – cloud-init documentation
• Architecture – Ceph Documentation