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

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

Разрабатывая полностью новый хостинг-сервис, которого еще не существовало на рынке хостинг-услуг, мы попытались решить ряд вопросов, остро стоящих в последнее время перед нами и, возможно, некоторыми другими хостинг-провайдерами, учесть пожелания наших клиентов. Попытались сделать услугу более надежной и понятной прежде всего для рядового пользователя хостинг-услуг. Пока рано говорить об успехе или провале проекта, но первые результаты говорят о том, что мы работаем не зря, а там посмотрим…

Проблематика хостинг-услуг

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

Итак, что же волнует пользователей хостинга? Доступность веб-сайта (надежность, отказоустойчивость), скорость работы, цена. Большинство при этом особое внимание может уделять цене, вынося её на первый план, как по объективным так и по субъективным причинам. И потому самая большая проблема, как для новичков, так и для продвинутых веб-мастеров — выбор тарифного плана.

Выбор тарифного плана

Этот выбор может оказывать значительное влияние на взаимоотношения между провайдером и вебмастером в ходе сотрудничества. И речь не о том, что у некоторых хостинг-провайдеров отношение лучше к тем, кто платит больше (воздержимся от дачи оценок таким случаям, статья не об этом), а о том, как легко допустить ошибку из-за неопытности и сэкономить лишнее, тем самым спровоцировав конфликтную ситуацию в дальнейшем, а она несомненно будет. Начинающие вебмастера зачастую искренне обижаются на провайдеров за письма о повышенной нагрузке, пишут гневные отзывы в Интернете. Через это проходил наверное каждый, в том числе и мы. Свято верят, что сайт, практически лишенный посещаемости, не может создать такой проблемы. И они правы! Потому как слишком не опытны и еще не могут знать, что система управления сайтом (CMS), отягощенная множеством модулей, да еще и не оптимально настроенная, может создавать значительное потребление. Либо потому как не догадываются, что провайдер с целью охвата большего количества потенциальных клиентов, мог создать слишком недорогой тарифный план, рассчитаный разве что на небольшую домашнюю страничку.

В тоже время выбор более дорогих тарифов осложнен не меньше. Хостинг-инфраструктуры у разных провайдеров различаются в значительной степени, также как и методы учета потребляемых ресурсов. В результате такой показатель потребления ресурсов, как процессорное время, оказывается практически бессмысленным при переходе от одного поставщика услуг к другому, так как с большой долей вероятности процессоры на хостинг-нодах различны. И даже если пользователь опытный и может представить разницу в производительности, то степень оптимальности настройки серверного ПО представить уже проблематично, так как это зависит исключительно от опыта специалистов технического отдела поставщика услуг. А еще есть неписаный негласный параметр — заполняемость хостинг-нод. Иногда провайдер держит определенных пользователей с повышенной нагрузкой не беспокоя и не требуя дополнительных оплат, просто, чтоб продать ресурсы за любые деньги, так как остальные клиенты не потребляют, либо нода слишком свободна и выгодно получать с нее хоть что-то, чем ничего.

Что мы имеем в итоге? Неприятные ситуации даже с клиентами на более дорогих тарифных планах, когда пользователь переходя от одного провайдера к другому с удивлением обнаруживает, что то, что работало там, создает чрезмерное потребление здесь. Получаем очередные «письма счастья». Недовольны все, и провайдеры и клиенты.

Выход?

На протяжении нескольких лет мы искали его. Мы обеспечили низкую цену на хостинг не за счет низкого лимита на ресурсы, оградили себя от спамеров и недобросовестных клиентов за счет ввода невыгодной для них системы тарификации, когда услугу выгодно заказывать исключительно на долгосрочный период, что лишено смысла в случае темных целей. Значительно повысили стабильность услуги без сложных технических решений, тысяча клиентов создавала не более 1 запроса в тех. отдел за сутки, минимизировали возможные конфликтные ситуации. Решения и результаты были подробно изложены в нашей статье от 2012-го года «Стабильный хостинг — миф или реальность?».

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

Ввод четкой тарификации потребления CPU / RAM / IOPS / BANDWIDTH, как на облачных сервисах, увы, не стал бы ответом и решением. Рядовых веб-мастеров не волнуют и не должны волновать эти параметры, их волнует только посещение их сайтов и их волшебная работа. Так почему не начать тарифицировать ресурсы исключительно в том, в чем измеряется доход вебмастеров, в посетителях?

Постановка задачи: ресурсы CPU / RAM / IOPS практически не ограничиваются, учитывается только трафик (посещаемость)

Результатом стала постановка задачи реализации принципиально нового хостинг-сервиса, которого не существовало на рынке ранее, где учитывается только посещаемость, фактически трафик, так как между этими параметрами есть четкий и понятный коэффициент. Для примера возьмем 100 ГБ трафика, много это или мало? Для визуализации в посетителях возьмем средний размер веб-страницы 700 КБ, количество просмотров — результат деления трафика на усредненный размер веб-страницы, к примеру для 100 ГБ трафика получаем 100*1024*1024/700 = 149 796,57 просмотров. Таким образом, если средний размер страниц Вашего веб-сайта будет меньше, к примеру составлять 200 КБ, а не 700, Вы можете получить гораздо больше просмотров — 100*1024*1024/200 = 524 288, и наоборот. Разумеется, что эти значения нужно воспринимать исключительно, как ориентировочные. Они не учитывают служебный трафик, трафик потребляемый поисковыми системами и паразитный трафик, который может появится и исчезнуть в любой момент.

А что с нагрузкой? Между потреблением серверных ресурсов и трафиком существует также более-менее стабильная связь для 99,5% интернет-проектов, потому необходимость учитывать нагрузку исчезает. Достаточно включить стоимость ресурсов в стоимость трафика и разногласия с веб-мастерами из-за создаваемой ими нагрузки будут полностью исключены, она действительно не будет учитываться отдельно. Да, у кого-то скрипт может быть более оптимизирован, у кого-то менее, но в среднем результат оказывается реально прогнозируемым и его можно учесть в счете за услуги хостинга, а самое главное — спрогнозировать расходы веб-мастера с большой степени точности, подобрать оптимальное по цене решение.

Требования и проблемы

Отсутствие тарификации и явного ограничения CPU / RAM / IOPS предъявляет особые требования к оборудованию и архитектуре решения. Наша задача обеспечить максимально быструю и бесперебойную работу всех сайтов веб-хостинга. А это значит, что решение должно быть построено на основе нод с максимально возможной производительностью и при этом быть распределенным с целью повышения надежности, обеспечивать возможность масштабирования.

Так как современные многопроцессорные решения обладают колоссальной производительностью и способны удовлетворить нужды тысяч пользователей хостинга, размещаемых в пределах ноды, выставляются особые требования и к производительности массива под файловое хранилище, базы данных. Массивы SATA/SAS дисков оказываются просто непригодными, так как они не способны эффективно справляться с запросами тысяч абонентов — один диск способен обеспечить не более 70-210 операций чтения / записи в секунду (IOPS), чего может быть явно недостаточно даже в случае применения массива из 12 дисков.

Единственным правильным вариантом в данном случае будет построение решения исключительно на твердотельных (SSD) накопителях, обеспечивающих от 50 000 IOPS и более, что практически в 1000 раз превосходит обычные HDD по производительности. Еще несколько лет назад применение таких накопителей значительно увеличивало бюджет решения, стимулируя хостинг-провайдеров к созданию «костылей» в виде гибридных рейдов или кэширующих CDN-cерверов, когда ssd применяются для кеша или только для баз. И это называли SSD-хостингом, чем в принципе некоторые не брезгуют и сейчас, вводя клиентов в заблуждение, чтоб максимально сэкономить средства. Да, накопители по-прежнему значительно дороже SATA, однако те преимущества которые они открывают, как в плане производительности, так и в плане надежности — неоспоримы.

Причем, как писал недавно amarao в своей статье «SSD + raid0 — не всё так просто», эти диски в массиве могут быть не эффективны по приросту производительности записи за счет различной латентности, в отличии от HDD — raid0 будет ожидать подтверждение от самого медленного диска в массиве. Соответственно диски лучше использовать независимо и достигать повышение производительности за счет скриптов, а не за счет raid.

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

Реализация

В целях повышения степени отказоустойчивости и обеспечения максимально низкой стоимости для абонентов мы решили отойти от присвоения отдельным нодами каких-то ролей. Для построения решения были использованы 4 х-процессорные платформы с десятиядерными процессорами Intel Deca-Core Xeon E7-4850 с возможностью установки до 1ТБ оперативной памяти и до 16 SSD накопителей. При этом, чтоб избежать эффекта «мегасервера», когда проблема с одним абонентом (повышенная нагрузка, атака), становиться причиной проблем в работе сайтов всех абонентов ноды, мы разбили ноду на несколько виртуальных машин, применив виртуализацию, при которой каждая из машин может использовать максимум доступных ресурсов, но не в ущерб работе остальных виртуальных машин. Это позволило повысить степень отказоустойчивости, так как теперь в случае серьезной проблемы с нагрузкой / атакой на какого-то из пользователей, ее могут ощутить только часть абонентов ноды (от 1/16 до 1/32 на наших нодах). Помимо прочего, программное обеспечение позволяет незамедлительно блокировать такого проблемного клиента и перенести его на отдельную виртуальную среду для решения проблемы, а в том случае, когда атака идет по IP-адресу, переместить всех его соседей.

Для этой цели каждую из нод мы подключили Интернет-каналом гарантированной пропускной способности в 10 Гбит / с с возможностью расширения, который не только позволяет обеспечить практически любой необходимый трафик для наших абонентов, но и оперативно мигрировать, как отдельных абонентов, так и целые виртуальные машины, оперативно создавать резервные копии в удаленные хранилища и разворачивать их. Уже описанная выше четкая взаимосвязь между генерируемым трафиком и потребляемыми вычислительными ресурсами позволила тарифицировать только трафик (посетителей), сделав тарификацию прозрачной и удобной, а выбор тарифного плана максимально простым и понятным.

Результаты

Со времени запуска нового хостинг-проекта (январь 2015-го года) мы не получили ни одного недовольного клиента, uptime равен 100% и в будущем, надеемся, что это значение будет близким к 100. Конечно прошло еще слишком мало времени, чтоб оценить все преимущества и недостатки решения, но пока что каких-либо существенных недостатков данного решения мы не видим. Возможно увидите Вы?

Для всех читателей habrahabr мы предоставляем уникальную возможность заказать услугу «Волшебный хостинг» cо скидкой 60%, использовав промокод (действительный до конца июня): HABRHM2015

http://www.ua-hosting.company/hosting — ждем Вашу критику и отзывы.

Что мы предлагаем?

— Вам доступна мощь минимум 4-х десятиядерных процессоров Intel Deca-Core Xeon E7-4850;
— мы уверены, что должны обеспечивать Вам возможность потреблять столько трафика, сколько необходимо, потому каждый из хостинг-серверов обладает Интернет-подключением пропускной способностью не менее 10 Гбит / с, с возможностью увеличения до 40 Гбит / с;
— в то время, как большинство серверов хостинга до сих пор применяют «медленные» жесткие диски SATA, обеспечивающие не более 50-140 операций чтения / записи в секунду (IOPS), мы строим решения исключительно на твердотельных накопителях SSD, которые обеспечивают 50 000 IOPS и более! До 1000 раз быстрее в сравнении с традиционным SATA-хостингом! Позвольте Вашим сайтам «летать»!

И в дополнение, при долгосрочном сотрудничестве — волшебные скидки, что делает цену доступной даже для сайта-визтки!

Какие ограничения?

— для выбранного Вами тарифного плана ограничивается только максимальное количество посетителей в месяц — трафик, тем не менее Вы можете приобрести столько трафика, сколько Вам необходимо, увеличить Ваш тарифный план до необходимого Вам предела;
— так как потребляемый трафик неразрывно связан с потребляемыми ресурсами CPU / RAM / IOPS — мы практически не применяем их ограничения, ведь благодаря производительному оборудованию потребление носит мгновенный характер, что позволяет использовать ресурс хостинг-серверов полноценно и более эффективно;
— на хостинг-сервере запрещено размещение проектов с целью проксирования трафика, конвертации медиафайлов или проведения других подобных сложных вычислений (стандартные сайты не подпадают под эти ограничения, имеются ввиду вычислительные процессы занимающие минуты процессорного времени, как при конвертации больших видеофайлов);
— запрещено размещение политических сайтов, сайтов, подверженных DDOS-атакам, а также ресурсов, заблокированных для пользователей из России Роскомнадзором либо с высоким потенциальным риском такой блокировки;
— нормы пользования сетью, принятые рабочей группой OFISP, а также Договор-оферта, должны соблюдаться в полной мере.