Сейчас рынок услуг хостинга развивается очень быстро. Причём изменяются не только количественные показатели (объём диска памяти и т.п.), но и качественные – появляются принципиально новые услуги.
С точки зрения пользователя всё это очень хорошо, т.к. высокая конкуренция приводит к снижению стоимости и улучшению качества обслуживания, но при этом компании очень часто под одними и теми же названиями предлагают совершенно разные услуги.
В этой статье я попытался классифицировать основные предложения, которые сейчас есть на рынке. Естественно, упор сделан на сервисы, с которыми я сам работал, но, думаю, никакие принципиальные моменты не упущены.
Также хочу предупредить, что названия услуг хостинга даны достаточно условно. Сейчас многие компании в рекламных целях манипулируют названиями как хотят. В основном, так или иначе, обыгрывается термин «облако». Поэтому классифицировать сервисы я решил по возможностям, которые они предоставляют. В результате получилась следующая табличка.
Теперь рассмотрим основные параметры.
1) Жесткое ограничение ресурсов
Означает, что вы оплачиваете какое-то количество ресурсов и не можете выходить за их пределы. Ограничения могут быть самыми разными. Объём места на диске, количество памяти, время работы и использование процессора скриптами (shared хостинг) и т.п. параметры. При этом цена не зависит от фактического потребления ресурсов. Хостер следит только за тем, чтобы вы не превысили лимит.
Тут сразу хочу сделать оговорку на счёт «безлимитных» тарифов. Ничего бесконечного на рынке хостинга не существует. Просто иногда для того, чтобы понять, в чём заключает ограничение нужно очень внимательно прочесть «условия предоставления услуг». Например, «безлимитный трафик» на практике означает, что если он превысит NNNN ГБ, то скорость порта для вашего аккаунта будет уменьшена со 100 до 10 Мб/с.
Если вы захотите изменить количество ресурсов, то вам придется, либо перейти на другой тарифный план (в случае shared хостинга и VPS), либо переехать на другой сервер.
Жесткое ограничение ресурсов характерно для «классических» услуг (shared, VPS и выделенный сервер). Облачные технологии подразумевают, что у хостера есть система, которая автоматически отслеживает текущее потребление ресурсов вашим аккаунтом и при необходимости тем или иным способом их изменяет (об этом чуть ниже). Тарификация осуществляет по фактическому потреблению.
2) Привязка к физическому оборудованию
Довольно спорный параметр. Все данные, так или иначе, находятся на каких-то физических серверах. Вопрос в том, что произойдёт в случае выхода этих серверов из строя.
В случае «классических» хостингов вам нужно будет переезжать на другой сервер. Переезд может осуществляться либо вами, либо службой тех. поддержки хостинга, не важно. Главное то, что какое-то время сайт будет «лежать», а все работы по переезду будут осуществляться в ручном режиме.
Использование облаков подразумевает, что у хостера есть система, которая автоматически «поднимет» сайт на другом физическом сервере. Технически реализовано это может по-разному. Например, у Amazon'а вы создаёте образы виртуальных машин (Amazon Machine Images — AMIs) с нужными вам настройками. Их система умеет автоматически создавать инстансы (виртуальные сервера) на основе этих образов и мониторить их работу. Т.е. если один инстанс по каким-то причинам падает, то автоматически создаётся второй. Такая система используется для услуги «сервер в облаке».
«Хостинг в облаке» обычно подразумевает, что ваш аккаунт размещён в серверном кластере, с возможностью «горячей» замены оборудования (т.е. без отключения питания). Вся информация хранится на дисковых RAID-массивах, т.е. выход из строя отдельного сервера может сказаться на общей производительности, но не приведёт к полному отключению сайта.
Естественно, могут быть ситуации вроде отключения питания во всём дата-центре (и такие случаи были), но их вероятность гораздо ниже, чем отказ какого-нибудь отдельного сервера.
3) Root-доступ
Подразумевает возможность установки/удаления и настройки параметров приложений. Предоставляется только для выделенных серверов. При этом если сервер находится в облаке, то процедура настройки несколько сложнее, чем для обычного сервера. Проблема в том, что инстансы запускаются автоматически и их адреса изменяются. Например, у амазона вам нужно выбрать нужный AMI-образ (который вы хотите настроить), создать и запустить на его основе новый инстанс, посмотреть его адрес в панели управления, подключиться к нему по SSH и сделать нужные настройки. Затем создать новый AMI на основе настроенного инстанса.
В случае хостинга нужно выбрать одну из настроенных хостером конфигураций. Некоторые параметры (но не все) можно изменить с помощью панели управления. Преимущество тут в том, что не нужно тратить время на настройку web сервера, базы и других приложений. Но если конфигурация хостера чем-то не устраивает, то root-доступ нужен.
4) Динамическое вертикальное масштабирование
По определению из википедии:
Вертикальное масштабирование – это увеличение производительности каждого компонента системы с целью повышения общей производительности.
В данном случае это означает, что ресурсы, выделенные для вашего аккаунта должны изменяться автоматически в зависимости от текущей нагрузки. Причём все выделенные ресурсы должны быть доступны приложению. Т.е. Amazon EC2 в эту категорию не попадает, т.к. автоматически он только запускает новые инстансы (это горизонтальное масштабирование), а изменить тип инстанса можно через админку в ручном режиме.
Такими параметрами обладает только «хостинг в облаке». Название может быть не очень удачно, т.к. часто подобные услуги относят к PaaS (Platform as a Service – платформа как услуга).
Рассмотрим пару примеров.
Первый – CloudControl. Этот сервис использует горизонтальное и вертикальное масштабирование одновременно. Ресурсы выделяются в виде контейнеров (горизонтальное масштабирование) размер которых может изменяться (вертикальное масштабирование) от 1х до 8х, где х = 128 МБ RAM.
Второй – тариф «Гибкий» от компании HostPro. Анонсировали эту услугу в прошлую субботу на семинаре (посмотреть слайды с презентации можно здесь). В этом варианте динамически изменяются три параметра – место на диске (считается фактически используемое), RAM и CPU.
5) Динамическое горизонтальное масштабирование
Из википедии:
Горизонтальное масштабирование – разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (или их группам) и/или увеличение количества серверов параллельно выполняющих одну и ту же функцию.
Разбить вашу систему на более мелкие структурные компоненты хостер самостоятельно (без вашей помощи) не сможет, поэтому в данном случае речь идёт только об изменении количества серверов параллельно обрабатывающих запросы.
Для реализации такой услуги хостер должен предоставить балансировщик, т.е. сервер который будет распределять входящие запросы, и механизм клонирования виртуальных серверов. Также удобно если хостер предоставляет инструменты для деплоя кода (не нужно их придумывать самому).
Правда есть проблема. Техническая реализация такой услуги у каждого хостера своя. Поэтому переезд становится болезненным мероприятием.
Например, у Amazon'а для деплоя кода используется специальный сервис – Elastic Beanstalk. CloudControl предоставляет специальную утилиту, с помощью которой можно задеплоить код прямо из Git репозитория. Хотя можно и без утилиты, т.к. технически на их серверах для вашего проекта создаётся Git репозиторий, из которого берётся код при создании инстансов. HostPro (если я правильно понял информацию на семинаре) предоставляет только API, т.е. настраивать деплой нужно самостоятельно.
6) Вертикальное масштабирование по запросу (вручную)
Реализуется в виде перехода на более дорогой (дешевый) тарифный план. При этом у вас изменяется доступное количество ресурсов.
В таблице я указал, что выделенные (dedicated) сервера таким свойством не обладают, хотя вы, конечно, можете заказать другой сервер и переехать на него. Просто сравнивать переезд на другой сервер с изменением тарифного плана не совсем корректно.
7) Горизонтальное масштабирование по запросу (вручную)
Такая возможность есть у некоторых облачных хостингов, например, у Amazon'а. Работает следующим образом. Вы заказываете определённое количество так называемых Reserved Instances. Это совершенно обычные EC2 инстансы, только оплата не за фактическое использование, а за 1 или 3 года вперёд. При этом цена в пересчёте на 1 час работы, естественно, значительно ниже. Т.е. если у вас более-менее равномерная нагрузка, то такой вариант позволяет сэкономить.
8) Цена
Тут всё просто. Все услуги, у которых в названии есть слово «облако» стоят дороже обычных 🙂
Рассчитывать на то, что они сильно подешевеют, тоже не приходится, т.к. в их стоимость входит разработка и поддержка самой инфраструктуры (балансировщики, система контроля нагрузки и распределения ресурсов, биллинг и т.п.).
Но при этом отказоустойчивость у облаков выше. Кроме того, возможность сэкономить есть, если нагрузка на приложение сильно изменяется. Например, приложением пользуются только в течении рабочего дня. Или, например, у сайта во время праздников посещаемость возрастает в десятки раз.
Заключение
К сожалению, универсальных рецептов в выборе я не знаю. Всё очень сильно зависит от особенностей приложения.
Появление облаков в какой-то степени ситуацию упрощает, т.к. теперь хостеры предоставляют услуги, которых раньше просто не было. Но зачастую даже банальное определение их стоимости является совсем не простой задачей. Реально помогают только эксперименты с настройками на работающем сайте.
Ещё приятно видеть, что отечественные хостеры пытаются догнать западных коллег. Тот же семинар HostPro произвёл положительное впечатление. По некоторым параметрам они ещё отстают, но, например, их CDN выглядит привлекательно. Хотя бы потому, что у Amazon'овского CloudFront’а нет серверов в России и Украине 🙂
В общем, ситуация складывается довольно интересная. Если есть вопросы или замечания, оставляйте их в комментариях.
Успехов!
