Стабильный хостинг — миф или реальность?

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

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

Воспринимать данную публикацию, как руководство к действию, или нет – решать Вам. Я лишь расскажу о том, какой подход исповедуем мы, сравнительно небольшой хостинг-провайдер, который активно начал наращивать клиентскую базу в этом сегменте услуг в последнее время, что показатель реальной эффективности методики. Ранее мы также имели порой проблемы со стабильностью либо затратной частью, однако сейчас клиенты хостинга практически не беспокоят нас, а мы их :) Для статистики – на 1000 клиентов хостинга сейчас у нас приходится только 1 запрос в тех. поддержку в течении суток в среднем и то причина далеко не в проблеме технического характера на нашей стороне.

Никаких мегасерверов под хостинг


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

Вывод – лучше использовать несколько серверов меньшей производительности, вместо одного сверхпроизводительного сервера. Так как это:

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

Принцип формирования тарифных планов хостинга идентичен принципу построения меню хорошего ресторана


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

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

Защита от недобросовестных клиентов


Наиболее надежным сдерживающим фактором для спамеров и других недобросовестных клиентов, которые хотят воспользоваться Вашими услугами, является цена. Этот специфический контингент рассчитывает на то, чтоб «нагадить» и уйти, так как его непременно Вы заблокируете. Соответственно такие люди пытаются заплатить как можно меньше (или вообще не платить, а попросить тестирование) и уж точно не рассчитывают на продолжительное сотрудничество.

Десять раз подумайте, перед тем, как предоставлять хостинг за доллар. Заработать можете доллар, а получить проблем на сотню! Недорогие тарифные планы могут быть, но не с ежемесячной оплатой, а с оплатой на большой срок. Тем не менее, если Вы хотите предоставлять стабильную услугу, и чтоб Ваши клиенты были довольны – тарифов за доллар быть не может в принципе, далее объясню почему.

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

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

Хостинг должен быть недорогим не за счет низкого лимита на ресурсы


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

Но как тогда обеспечить низкую стоимость минимального тарифа, которая особенно критична для клиента с сайтом-визиткой? Все очень просто! Дайте возможность получить хорошую цену при долгосрочной оплате, скажем при оплате на год, сделайте скидку в 2 раза, а при оплате на 3-х месячный срок цена должна быть такой, как при оплате на 2 месяца, если оплачивать услугу ежемесячно. Это стимулирует даже новичков к оплате услуги минимум на 3 месяца и уменьшает количество отказов. Однако при годовом варианте оплаты цена минимального тарифного плана должна быть не менее $4 / месяц. Кто-то скажет, что это может быть слишком дорого для сайта визитки, но большое количество включенных ресурсов и гарантия стабильности услуги действуют безотказно. К тому же, Вам не надоело продавать услугу, которая к тому же включает труд Ваших админов, дешевле пинты пива?

Преимущества:

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

Никаких тарифов с безлимитным количеством доменов


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

Но даже самый дорогой тарифный план не должен давать возможность добавлять домены неограниченно.

Потому что в случае отсутствия ограничений на количество доменов:

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

Не более 50 клиентов на сервер при любых условиях


Стоимость аренды среднего по производительности сервера, а в моем понимании это конфигурация не ниже Intel Xeon E3-1230 / 8-16GB DDR3 / 2-4x1TB HDD, в наше время настолько низкая, что окупить затраты на амортизацию в более чем 2 раза можно разместив на сервере до 50 клиентов. Само собой нужно остановиться ранее, если общая нагрузка всех клиентов с сервера начнет достигать в пиках 50%, однако пока я такого не наблюдал :) При этом также нужно определить максимально возможное количество клиентов с тарифным планом выше минимального. У нас, к примеру, всего 3 тарифа, при этом максимальный отличается по ресурсам в 5 раз от минимального. Соответственно среди наших 50 клиентов не должно быть более 10 с максимальным тарифным планом.

Если в результате размещения 50 клиентов не используются ресурсы сервера даже на половину – ничего страшного, не нужно жадничать, окупаемость и необходимый уровень дохода с сервера достигнут, oversell — зло. Лучше не пытаться сэкономить и набивать сервер по максимуму, а поставить дополнительный сервер. Тем более при большом количестве заказов в сутки (более 10) – рассчитать реальную нагрузку будет сложно. Это убережет Вас от лишних трат на саппорт, от необходимости ротации клиентов между серверами по причине их развития (апгрейда тарифного плана) и увеличит стабильность. Ну и самое важное, при критической проблеме на сервере, будут испытывать неудобства только 50 клиентов, а не более. Кстати о преимуществах минимального количества клиентов на одном сервере уже говорилось выше, так что не буду повторяться.

Никаких индивидуальных тарифных планов


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

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

Нужно больше ресурсов, чем предусмотрено максимальным тарифом? Нужно неограниченно доменов и т.п.? Добро пожаловать на выделенный сервер, но не на хостинг. Рисковать стабильной работой остальных 49 человек из-за перспективы того, что 1 заплатит больше – глупо. Пусть платит еще больше и берет выделенный сервер ;)

Никаких больших баз данных и любителей парсинга на хостинге


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

Ваш сервер должен быть надежным и размещен в надежном Дата Центре, а не на складе


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

Однако некоторые лоукостеры сейчас предлагают серверы с 64 GB RAM, даже серверные конфигурации на первый взгляд, причем за недорого. Секрет в том, что некоторые комплектующие там все-таки декстопные и это самосбор, серверный, пожалуй, только корпус. Не гонитесь за дешевизной и мегацифрами. Они Вам к тому же не нужны. Много ли Вы знаете проектов, которые потребляют 64 GB RAM? Большинству проектов на самом деле хватит сервера с 4-8 GB оперативки с головой, даже много будет. Но зачем такое брать, когда есть с 64 GB RAM за меньшие деньги, думают многие, это ж не круто! Это тупой маркетинг и не более того, который, увы, действует. Даже если конфигурация реально серверная – все остальное будет никакое. Кроме того велик шанс попасть на мнимый «безлимит» в виде ограничения пропускной способности канала к серверу после превышения определенного объема трафика.

Не может качество стоить слишком дешево, лучше взять на первый взгляд менее производительный сервер за те же деньги, но в хорошем Дата Центре и в итоге использовать его ресурсы полноценно, так как для этого будут все возможности. Важна надежность, оперативность замены (вплоть до целого сервера в течение часа) и, конечно же, размещение. Это должна быть надежная площадка с отличной связностью и поддержкой, с адекватным абузным отделом, который не будет блокировать Ваш сервер по первой же жалобе от непонятно кого, а рассмотрит ее, проанализирует и если будет необходимо – свяжется с Вами и даст время на реагирование. Лоукосетры не способны содержать штат таких сотрудников, потому могут Вам направлять абсолютно все жалобы, как подтвержденные так и не подтвержденные, не брезговать Вашим отключением. У них и без Вас клиентов хватает и поток любителей халявы настолько велик, что им проще заменить клиента на менее проблемного, нежели разбираться с жалобами.

Жалобы на хостинг-серверах частое явление. Именно потому не достаточно арендовать сервер в надежном Дата Центре, нужно, чтоб сам Дата Центр находился в надежной по законодательству стране. Это убережет Вас от выноса мозга правоохранительными органами по поводу и без, так как законодательство некоторых стран носит дебильный характер, примером может быть запрет на размещение сайтов для взрослых и криминальное преследование таких вебмастеров, в то время, как во многих странах это абсолютно легально. Так же лучше не размещаться в тех странах, где законы действуют не всегда, и Ваш сервер могут изъять не только по решению суда, а просто по желанию в качестве доказательства либо под каким-то другим предлогом.

Результаты


— реальная нагрузка на серверах хостинга для вышеуказанной конфигурации в пределах 20-30% при 50 клиентах на сервере, огромный запас по ресурсам, потребление трафика в пределах 5-25 Мбит / с;
— на каждую 1000 клиентов приходится в среднем 1 запрос в тех. поддержку в сутки;
— серверы стабильны, сайты клиентов всегда работают, проблемы – невероятно редкое явление, необходимость в расходе времени на поддержку минимальна;
— превышение допустимой нагрузки благодаря высоким лимитам – крайне редкое явление и перевод на более дорогой тарифный план не вызывает бурю эмоций, так как на момент превышения вебмастер уже достаточно зарабатывает и уже далеко не новичок.

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

Sergii V. Sikorskyi, co-owner of ua-hosting.com.ua
ua-hosting.company
482,40
Хостинг-провайдер: серверы в NL / US до 100 Гбит/с
Поделиться публикацией

Комментарии 26

    +1
    Добрый,

    В вашем посте есть здравые мысли, но есть несколько «но». Куда же без этого =)

    С увеличением количества серверов (железа) — увеличивается и количество аппаратных проблем.
    Теорию вероятности никто не отменял.

    Кроме того — необходимо обеспечить качественную инфраструктуру для работы оборудования (цод, сетевая коммутация).

    Вместе с тем, чем больше кол-во серверов, тем больше потребление энергии, в т.ч. на охлаждение.

    Как правило в «зоне риска» новые серверы, где идет регистрация новых пользователей, за ними нужно следить особенно.
    В рез-те, при значительных объемах, разумно выбирать меньшее число более мощных серверов и конечно не перегружать их пользователями =)

      +1
      Верно, полностью согласен с Вами. Потому отдельным пунктом выделил важность нормального Дата Центра. Большее потребление энергии это конечно же минус — плохо для экологии. С другой стороны, если энергия Дата Центра экологически чистая и в избытке, если у нас стоит задача наоборот как можно быстрее заполнить большую партию серверов, то почему нет…

      В случае, если стоит задача экономить и энергию — можно использовать блейды. Это будет лучше мегасерверов.
        0
        Экологически-чистой энергии не бывает по определению. Ветер, солнце и вода — требуют правильного обслуживания. Везде есть что-то, что не дает сделать эту самую энергию на 100% чистой, разве только солнечный ветер, но его надо поймать еще =) Вопрос из серии аптайма в 100% )

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

        Система на блейдах вполне себе рабочая. Сложная, но дорогая и рабочая.
        Каждая задача имеет несколько решений — проблема правильного выбора двигает мир =)

      0
      Занимаясь хостингом прошли путь от дорогих серверов к самосброныи декстопам, а затем к блейдам. Для shared хостинга это, наверное, идеальный вариант по соотношению надежности и качества.
        0
        Есть проблема. Больше аппаратных серверов => больше затрат на содержание. Я бы, скорее, остановился на небольших контейнерах по 10-20 клиентов и живой миграции проблемного контейнера в «отстойник» (дада, есть такой сервер у всех хостеров — для неудобных клиентов).
          0
          нету. Честно говорю — нету.
            0
            Ну вы нечто большее, чем хостер.
              0
              А что мешает хостерам так же делать только на ванильном XCP? У нас неванильное там — только аккаунтинг и новый стек для API. И всё.
                0
                Хотя бы отсутствие специалистов, способных построить сторадж вменяемый. Или отсутствие денег на него =)
                  0
                  В XCP 1.6 появилась cross-pool migraion, так что закладываться на централизованное хранилище больше не надо.

                  У меня в лаборатории виртуалки между дата-центрами только так летают.
                    0
                    Хм… интересно. Спасибо, поковыряю.
          0
          1) За вычетом входящего трафика > 1 Гбит у меня виртуалка может делать что угодно — она никому не помешает. Ни по IO, ни по памяти, ни по процессору.
          2) Тарифа по $1 нет, зато можно сделать машину с потреблением <50р/месяц, а в выключенном состоянии она почти не потребляет. Есть клиенты у которых виртуалки 5-10р в месяц приносят.
          3) Анлима нет ни на что — за всё платит клиент. И только когда использует. Не использует — не платит.
          4) Количество доменов… Знать не знаю. Сколько в конфиге пропишут, столько и будет.
          5) Тарифных планов нет — только цена ресурсов.
          6) До сотни (рекорд — 110) виртуалок на хост. Контролируется только потребление — как только кто-то начинает есть — его перекидывают на соседний хост.
          7) Разрешённый размер базы данных — до 30 Тб.

          ЧЯДНТ?
            0
            Но есть же и недостаток в этой схеме habrahabr.ru/company/selectel/blog/152351/ (как раз то, о чем я писал — упало сразу все и на долго, ибо был серьезный факап, на который видимо не рассчитывали в проекте, а в столь сложной схеме устранить последствия оказалось не просто) + подобная реализация недоступна небольшим хостинг-провайдерам как раз из-за сложности и затратности на разработку. Это основные минусы применения этой схемы на мой взгляд. Дорого, на первый взгляд практично, но много подводных камней, всплывающих в результате того или иного факапа.

            Да и на счет доходной части тут нужно думать:

            " Есть клиенты у которых виртуалки 5-10р в месяц приносят."
            А стоят ли Ваши знания того, чтоб потом зарабатывать с клиента 5-10 рублей в месяц или даже 50 рублей в месяц? Вам виднее тут.

            Клиентам то хорошо, конечно, платить дешевле, чем многие тратят в день на пиво, они Вам благодарны, вот только не совсем бизнес как по мне получается. Минимальная плата не должна быть столь низкой, вне зависимости от потребляемых ресурсов. Само решение стоило то Вам каких-то сил и денег. Причем подозреваю не малых.
              0
              Э… В нашем случае легла сеть. Вся. Количество серверов при этом не играет никакой разницы. Заметим, за сию драму кому надо хвосты накрутили и соотв. изменения сделали.

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

              Поскольку у нас внутренний учёт идёт только в ресурсах, вопрос «сколько у нас клиентов?» просто не стоит. Вопрос стоит «сколько ресурсов у нас за сегодня продалось?». И ARPU нас не волнует (какая разница — виртуалка на 10000т.р. в месяц или сотня виртуалок на 100 р в месяц?).

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

              Ресурсы при этом стоят своих денег. У меня на примете несколько характерных вирталок, просто для понимания:

              некая виртуалка имеет avg по процу в районе 400%, с полочками в районе 790%, 1Гб памяти, смехотворное IO, умеренный трафик.

              Другая — иногда делает IO на 2-3т.р. в день. Иногда молчит и ничего не делает.

              Есть виртуалка, которая генерирует около 300Мбит трафика при 512Мб оперативки, 10% CPU и очень малом IO.

              Каждому из них удобно — а на выходе для нас — агрегированный шум, который нужно обслуживать, и в котором нет разницы между сотней мелких или одним большим. Скорее, товарищ с полочкой в 790% доставляет больше затруднений, ибо его балансировать труднее (потому и запомнился).
                0
                Дай Бог конечно, чтоб у Вас все было стабильно годами и без подобных критических проблем, но гарантии быть увы не может. Я немного другое имел ввиду, вспоминая тот случай. Проблема с сетью в Вашем случае повлекла проблемы на самом облаке, Вы потратили не мало времени на восстановление уже после начала работы сети, при этом лежало увы много клиентов («облачные серверы на старых хранилищах, увы, получили I/O Error для дисков» и т.п.). То, что приняли меры — замечательно. Эта проблема больше не возникнет, но не дай Бог может быть другая, которую не учли.

                Титаник тоже считали непотопляемым, а его аналог Британик утонул только из-за того, что у него были открыты иллюминаторы во время подрыва на мине. Я это к тому, что нельзя думать, что факапа быть не может. Иногда мелочь может сыграть большую роль.

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

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

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

                Что касается метода оплаты «платишь только за то, что используешь» и минимальное оплате в 5-10 рублей, возможно в Вашем случае и есть смысл предлагать такие условия, так как у Вас четко считается нагрузка. Это дополнительный шанс увеличить клиентскую базу, так как клиент не знает свой нагрузки, может подумать, что у него расход будет такой-то, заказать услугу, а в итоге платить больше, чем планировал, но тем не менее продолжить использовать ибо услуга стабильна и качественна. Потому да, этот подход применим, но только для облачных решений.
                  0
                  Ну… У нас просто шли работы. Ладно, оправдываться глупо, была херня. Поправили. В принципе, та авария задела больше по неработе сети, чем перезапуска виртуальных машин.

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

                  А преимущество в том, что человек, формально, платя за виртуалку больше, чем за аренду сервера, с виртуалки не уходит, ибо в какой-то момент он платит, а в какой-то — нет. Другими словами, «сжатие» и «расширение» происходит по фактической надобности, а не по изменению тарифов.

                  Впрочем, это всё мелкие нюансы. Моё мнение — shared-хостинг обречён. Контейнеры, виртуальные машины, строгая изоляция одного клиента от другого, свобода в выборе софта (и его версий)… shared (без cgroups и контейнеров) — это такая коммуналка. Со всеми вытекающими удобствами.
                    0
                    Да, shared-хостинг не столь удобен, это бесспорно. Но лично я на облако пока морально не готов, как и многие другие хостеры, слишком сложно и дорого это, при большом риске положить всех клиентов одновременно (опыта как у Вас, у нас столько нет, наверняка будет много проблем). Так что Вы освоили отличную нишу с минимальной конкуренцией :)

                    С другой стороны, как Вы сами сказали, пользователи платят за виртуалку больше, чем за аренду физического сервера. Те, кто это понимают — будут арендовать сервер (если только им не нужно кластерное решение и пиковые нагрузки невелики)… И причина не только в цене. Там есть свой ряд других преимуществ, но не будем отклоняться от темы.
                      0
                      Кстати, что будет с облаком если на него упадет очень сильный DDOS не дай Бог? Проблему ощутят все клиенты? Тут ведь получается сложнее ситуация, чем если отдельный сервер в ДЦ атакуют и просто занулрутить ай пи того сервера. Или на одном IPv4 адресе у Вас не очень много сайтов и его тоже можно отправить в null-route? В тоже время, интересно, как это повлияет на все облако до этого момента.
                        0
                        У нас один ipv4 на одну виртуалку. То есть теоретически, есть возможность полной изоляции. На практике, большинство ddos'ов меньше нашего входного канала, так что достаточно мигрировать виртуалку на отдельный хост, где она будет получать гигабит из вошедших, например, 5-7.
                          0
                          Блокировка происходит автоматически при превышении какого-то порога пакетов в секунду или все же нужно вручную? Ощущают ли атаку другие пользователи до момента блокировки? Если не секрет, какой входящий канал?

                          На нашего клиента в Украине в этом году упал DDOS, так всем клиентам ДЦ было плохо. Печально то, что сейчас атаку в 10-15 Гбит / с могут некоторые умельцы организовать за $30 в час. 50 Гбит / с — дороже. Но уже тоже не крайне фантастические деньги. Потому увы полагаться на то, что атака не превысит входящий канал уже нельзя наверное и надо также учитывать этот риск.
                            0
                            Если ddos терпим для нашей инфраструктуры — разруливается штатными средствами, не как dos, а как «большая нагрузка»… pps мы вообще не контролируем, благо ovs с этим справляется на ура.

                            Если придёт 50Гб в одно горло — будет нехорошо. У нас коммутатор на пул (группу хостов) 20Гбит аплинк имеет, и тут потребуется участие людей (автоматика в одиночестве не справится). Придёт 100+ либо завернём на входе, либо честно ляжем.
                              0
                              Интересно, спасибо. Возможность помещать на облако сайты под атакой и оплачивать «фильтрацию» в виде платы за ресурс, который использует атака и только во время атаки — это круто, ничто не фильтрует DDOS лучше такого решения. Зачастую атаки до 10 Гбит / с, так что тут Ваше решение действительно не заменимо.
                                0
                                Если мы увидим более-менее постоянный трафик на виртуалки за гигабит, то просто подключим хосты на 10G, чтобы клиент оплачивал всю входящую полосу.
                        0
                        Немного не так. Есть пользователи, которые в некоторые дни платят больше, чем платили бы за сервер. У большинства таких пользователей пики в десятки/сотни мегабит, то есть им бы пришлось докупать полосу (много полосы). Но бывают такие, у которых один ресурс сильно перекошен. Например, делать пару тысяч iops'ов на обычном сервере просто не возможно. А если у человека это основная нагрузка, то зачем ему при этом десятки гигабайт и пачки ядер (как было бы в случае большого сервера)?

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

                        Банальное повышение эффективности и всё.
                          0
                          Теперь понятно, спасибо.
                        0
                        Пожалуй, соглашусь с amarao: «Моё мнение — shared-хостинг обречён.»
                        У меня два корпоративных сайта в Селектеле. Когда изучал вопрос хостинга, был выбор: или искать действительно хороший быстрый хостинг или положить сайты на свои «большие» сервера.
                        В результате выбрал ни то ни другое — виртуалка Селектела. Для меня по факту тот же хостинг (по цене), но только весь софт настроен оптимально под сайты.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое