Comments 26
Добрый,
В вашем посте есть здравые мысли, но есть несколько «но». Куда же без этого =)
С увеличением количества серверов (железа) — увеличивается и количество аппаратных проблем.
Теорию вероятности никто не отменял.
Кроме того — необходимо обеспечить качественную инфраструктуру для работы оборудования (цод, сетевая коммутация).
Вместе с тем, чем больше кол-во серверов, тем больше потребление энергии, в т.ч. на охлаждение.
Как правило в «зоне риска» новые серверы, где идет регистрация новых пользователей, за ними нужно следить особенно.
В рез-те, при значительных объемах, разумно выбирать меньшее число более мощных серверов и конечно не перегружать их пользователями =)
В вашем посте есть здравые мысли, но есть несколько «но». Куда же без этого =)
С увеличением количества серверов (железа) — увеличивается и количество аппаратных проблем.
Теорию вероятности никто не отменял.
Кроме того — необходимо обеспечить качественную инфраструктуру для работы оборудования (цод, сетевая коммутация).
Вместе с тем, чем больше кол-во серверов, тем больше потребление энергии, в т.ч. на охлаждение.
Как правило в «зоне риска» новые серверы, где идет регистрация новых пользователей, за ними нужно следить особенно.
В рез-те, при значительных объемах, разумно выбирать меньшее число более мощных серверов и конечно не перегружать их пользователями =)
Верно, полностью согласен с Вами. Потому отдельным пунктом выделил важность нормального Дата Центра. Большее потребление энергии это конечно же минус — плохо для экологии. С другой стороны, если энергия Дата Центра экологически чистая и в избытке, если у нас стоит задача наоборот как можно быстрее заполнить большую партию серверов, то почему нет…
В случае, если стоит задача экономить и энергию — можно использовать блейды. Это будет лучше мегасерверов.
В случае, если стоит задача экономить и энергию — можно использовать блейды. Это будет лучше мегасерверов.
Экологически-чистой энергии не бывает по определению. Ветер, солнце и вода — требуют правильного обслуживания. Везде есть что-то, что не дает сделать эту самую энергию на 100% чистой, разве только солнечный ветер, но его надо поймать еще =) Вопрос из серии аптайма в 100% )
Имхо, стратегия построения хостинга не может опираться на задачу «быстрого заполнения большого количества серверов». Нужно стараться думать дальше. Как обслуживать серверы, что делать, если вдруг энергия станет дорогой и места в цод станет мало.
Ну и в целом, ферма из большого количества серверов под виртуализацией — позволит использовать железо более надежно и эффективно.
Система на блейдах вполне себе рабочая. Сложная, но дорогая и рабочая.
Каждая задача имеет несколько решений — проблема правильного выбора двигает мир =)
Имхо, стратегия построения хостинга не может опираться на задачу «быстрого заполнения большого количества серверов». Нужно стараться думать дальше. Как обслуживать серверы, что делать, если вдруг энергия станет дорогой и места в цод станет мало.
Ну и в целом, ферма из большого количества серверов под виртуализацией — позволит использовать железо более надежно и эффективно.
Система на блейдах вполне себе рабочая. Сложная, но дорогая и рабочая.
Каждая задача имеет несколько решений — проблема правильного выбора двигает мир =)
Занимаясь хостингом прошли путь от дорогих серверов к самосброныи декстопам, а затем к блейдам. Для shared хостинга это, наверное, идеальный вариант по соотношению надежности и качества.
Есть проблема. Больше аппаратных серверов => больше затрат на содержание. Я бы, скорее, остановился на небольших контейнерах по 10-20 клиентов и живой миграции проблемного контейнера в «отстойник» (дада, есть такой сервер у всех хостеров — для неудобных клиентов).
1) За вычетом входящего трафика > 1 Гбит у меня виртуалка может делать что угодно — она никому не помешает. Ни по IO, ни по памяти, ни по процессору.
2) Тарифа по $1 нет, зато можно сделать машину с потреблением <50р/месяц, а в выключенном состоянии она почти не потребляет. Есть клиенты у которых виртуалки 5-10р в месяц приносят.
3) Анлима нет ни на что — за всё платит клиент. И только когда использует. Не использует — не платит.
4) Количество доменов… Знать не знаю. Сколько в конфиге пропишут, столько и будет.
5) Тарифных планов нет — только цена ресурсов.
6) До сотни (рекорд — 110) виртуалок на хост. Контролируется только потребление — как только кто-то начинает есть — его перекидывают на соседний хост.
7) Разрешённый размер базы данных — до 30 Тб.
ЧЯДНТ?
2) Тарифа по $1 нет, зато можно сделать машину с потреблением <50р/месяц, а в выключенном состоянии она почти не потребляет. Есть клиенты у которых виртуалки 5-10р в месяц приносят.
3) Анлима нет ни на что — за всё платит клиент. И только когда использует. Не использует — не платит.
4) Количество доменов… Знать не знаю. Сколько в конфиге пропишут, столько и будет.
5) Тарифных планов нет — только цена ресурсов.
6) До сотни (рекорд — 110) виртуалок на хост. Контролируется только потребление — как только кто-то начинает есть — его перекидывают на соседний хост.
7) Разрешённый размер базы данных — до 30 Тб.
ЧЯДНТ?
Но есть же и недостаток в этой схеме habrahabr.ru/company/selectel/blog/152351/ (как раз то, о чем я писал — упало сразу все и на долго, ибо был серьезный факап, на который видимо не рассчитывали в проекте, а в столь сложной схеме устранить последствия оказалось не просто) + подобная реализация недоступна небольшим хостинг-провайдерам как раз из-за сложности и затратности на разработку. Это основные минусы применения этой схемы на мой взгляд. Дорого, на первый взгляд практично, но много подводных камней, всплывающих в результате того или иного факапа.
Да и на счет доходной части тут нужно думать:
" Есть клиенты у которых виртуалки 5-10р в месяц приносят."
А стоят ли Ваши знания того, чтоб потом зарабатывать с клиента 5-10 рублей в месяц или даже 50 рублей в месяц? Вам виднее тут.
Клиентам то хорошо, конечно, платить дешевле, чем многие тратят в день на пиво, они Вам благодарны, вот только не совсем бизнес как по мне получается. Минимальная плата не должна быть столь низкой, вне зависимости от потребляемых ресурсов. Само решение стоило то Вам каких-то сил и денег. Причем подозреваю не малых.
Да и на счет доходной части тут нужно думать:
" Есть клиенты у которых виртуалки 5-10р в месяц приносят."
А стоят ли Ваши знания того, чтоб потом зарабатывать с клиента 5-10 рублей в месяц или даже 50 рублей в месяц? Вам виднее тут.
Клиентам то хорошо, конечно, платить дешевле, чем многие тратят в день на пиво, они Вам благодарны, вот только не совсем бизнес как по мне получается. Минимальная плата не должна быть столь низкой, вне зависимости от потребляемых ресурсов. Само решение стоило то Вам каких-то сил и денег. Причем подозреваю не малых.
Э… В нашем случае легла сеть. Вся. Количество серверов при этом не играет никакой разницы. Заметим, за сию драму кому надо хвосты накрутили и соотв. изменения сделали.
Основная идея с обширной массой дешёвых клиентов — их обслуживают роботы. И только. Как только клиентов начинают обслуживать люди, это уже не облако, а энтерпрайз лохматый с «персональным менеджером» получается.
Поскольку у нас внутренний учёт идёт только в ресурсах, вопрос «сколько у нас клиентов?» просто не стоит. Вопрос стоит «сколько ресурсов у нас за сегодня продалось?». И ARPU нас не волнует (какая разница — виртуалка на 10000т.р. в месяц или сотня виртуалок на 100 р в месяц?).
То есть за айпишники мы напряглись, да, но это просто потому, что адреса не бесконечные. На ipv6 — никаких причин не делать дёшево.
Ресурсы при этом стоят своих денег. У меня на примете несколько характерных вирталок, просто для понимания:
некая виртуалка имеет avg по процу в районе 400%, с полочками в районе 790%, 1Гб памяти, смехотворное IO, умеренный трафик.
Другая — иногда делает IO на 2-3т.р. в день. Иногда молчит и ничего не делает.
Есть виртуалка, которая генерирует около 300Мбит трафика при 512Мб оперативки, 10% CPU и очень малом IO.
Каждому из них удобно — а на выходе для нас — агрегированный шум, который нужно обслуживать, и в котором нет разницы между сотней мелких или одним большим. Скорее, товарищ с полочкой в 790% доставляет больше затруднений, ибо его балансировать труднее (потому и запомнился).
Основная идея с обширной массой дешёвых клиентов — их обслуживают роботы. И только. Как только клиентов начинают обслуживать люди, это уже не облако, а энтерпрайз лохматый с «персональным менеджером» получается.
Поскольку у нас внутренний учёт идёт только в ресурсах, вопрос «сколько у нас клиентов?» просто не стоит. Вопрос стоит «сколько ресурсов у нас за сегодня продалось?». И ARPU нас не волнует (какая разница — виртуалка на 10000т.р. в месяц или сотня виртуалок на 100 р в месяц?).
То есть за айпишники мы напряглись, да, но это просто потому, что адреса не бесконечные. На ipv6 — никаких причин не делать дёшево.
Ресурсы при этом стоят своих денег. У меня на примете несколько характерных вирталок, просто для понимания:
некая виртуалка имеет avg по процу в районе 400%, с полочками в районе 790%, 1Гб памяти, смехотворное IO, умеренный трафик.
Другая — иногда делает IO на 2-3т.р. в день. Иногда молчит и ничего не делает.
Есть виртуалка, которая генерирует около 300Мбит трафика при 512Мб оперативки, 10% CPU и очень малом IO.
Каждому из них удобно — а на выходе для нас — агрегированный шум, который нужно обслуживать, и в котором нет разницы между сотней мелких или одним большим. Скорее, товарищ с полочкой в 790% доставляет больше затруднений, ибо его балансировать труднее (потому и запомнился).
Дай Бог конечно, чтоб у Вас все было стабильно годами и без подобных критических проблем, но гарантии быть увы не может. Я немного другое имел ввиду, вспоминая тот случай. Проблема с сетью в Вашем случае повлекла проблемы на самом облаке, Вы потратили не мало времени на восстановление уже после начала работы сети, при этом лежало увы много клиентов («облачные серверы на старых хранилищах, увы, получили I/O Error для дисков» и т.п.). То, что приняли меры — замечательно. Эта проблема больше не возникнет, но не дай Бог может быть другая, которую не учли.
Титаник тоже считали непотопляемым, а его аналог Британик утонул только из-за того, что у него были открыты иллюминаторы во время подрыва на мине. Я это к тому, что нельзя думать, что факапа быть не может. Иногда мелочь может сыграть большую роль.
Именно потому я не фанат облачных решений. Тут риск на самом деле больший, потому что если ляжет — ляжет все и на долго, потому что решить такую крупную проблему сложнее.
Да и даже на облаке товарищей с большим потребление ресурсов труднее балансировать с Ваших слов, значит небольшие проблемы могут создавать… В чем тогда преимущество для других провайдеров в реализации такого решения?
Как уже сказали выше — Вы больше, чем хостер, с огромным опытом, знаниями и достаточным бюджетом. Уверен, на не мало граблей наступили в процессе и уже знаете что к чему, но пытаться делать это с 0 — невероятно сложная задача. Потому такая схема применима разве что для Вас и провайдеров Вашего уровня.
Что касается метода оплаты «платишь только за то, что используешь» и минимальное оплате в 5-10 рублей, возможно в Вашем случае и есть смысл предлагать такие условия, так как у Вас четко считается нагрузка. Это дополнительный шанс увеличить клиентскую базу, так как клиент не знает свой нагрузки, может подумать, что у него расход будет такой-то, заказать услугу, а в итоге платить больше, чем планировал, но тем не менее продолжить использовать ибо услуга стабильна и качественна. Потому да, этот подход применим, но только для облачных решений.
Титаник тоже считали непотопляемым, а его аналог Британик утонул только из-за того, что у него были открыты иллюминаторы во время подрыва на мине. Я это к тому, что нельзя думать, что факапа быть не может. Иногда мелочь может сыграть большую роль.
Именно потому я не фанат облачных решений. Тут риск на самом деле больший, потому что если ляжет — ляжет все и на долго, потому что решить такую крупную проблему сложнее.
Да и даже на облаке товарищей с большим потребление ресурсов труднее балансировать с Ваших слов, значит небольшие проблемы могут создавать… В чем тогда преимущество для других провайдеров в реализации такого решения?
Как уже сказали выше — Вы больше, чем хостер, с огромным опытом, знаниями и достаточным бюджетом. Уверен, на не мало граблей наступили в процессе и уже знаете что к чему, но пытаться делать это с 0 — невероятно сложная задача. Потому такая схема применима разве что для Вас и провайдеров Вашего уровня.
Что касается метода оплаты «платишь только за то, что используешь» и минимальное оплате в 5-10 рублей, возможно в Вашем случае и есть смысл предлагать такие условия, так как у Вас четко считается нагрузка. Это дополнительный шанс увеличить клиентскую базу, так как клиент не знает свой нагрузки, может подумать, что у него расход будет такой-то, заказать услугу, а в итоге платить больше, чем планировал, но тем не менее продолжить использовать ибо услуга стабильна и качественна. Потому да, этот подход применим, но только для облачных решений.
Ну… У нас просто шли работы. Ладно, оправдываться глупо, была херня. Поправили. В принципе, та авария задела больше по неработе сети, чем перезапуска виртуальных машин.
Проблема с балансировкой больших товарищей ровно одна: вместо одной-двух миграций нужно делать несколько десятков (разгребать место). В принципе, для меня это лишь увеличение времени процесса (глубины рекурсии).
А преимущество в том, что человек, формально, платя за виртуалку больше, чем за аренду сервера, с виртуалки не уходит, ибо в какой-то момент он платит, а в какой-то — нет. Другими словами, «сжатие» и «расширение» происходит по фактической надобности, а не по изменению тарифов.
Впрочем, это всё мелкие нюансы. Моё мнение — shared-хостинг обречён. Контейнеры, виртуальные машины, строгая изоляция одного клиента от другого, свобода в выборе софта (и его версий)… shared (без cgroups и контейнеров) — это такая коммуналка. Со всеми вытекающими удобствами.
Проблема с балансировкой больших товарищей ровно одна: вместо одной-двух миграций нужно делать несколько десятков (разгребать место). В принципе, для меня это лишь увеличение времени процесса (глубины рекурсии).
А преимущество в том, что человек, формально, платя за виртуалку больше, чем за аренду сервера, с виртуалки не уходит, ибо в какой-то момент он платит, а в какой-то — нет. Другими словами, «сжатие» и «расширение» происходит по фактической надобности, а не по изменению тарифов.
Впрочем, это всё мелкие нюансы. Моё мнение — shared-хостинг обречён. Контейнеры, виртуальные машины, строгая изоляция одного клиента от другого, свобода в выборе софта (и его версий)… shared (без cgroups и контейнеров) — это такая коммуналка. Со всеми вытекающими удобствами.
Да, shared-хостинг не столь удобен, это бесспорно. Но лично я на облако пока морально не готов, как и многие другие хостеры, слишком сложно и дорого это, при большом риске положить всех клиентов одновременно (опыта как у Вас, у нас столько нет, наверняка будет много проблем). Так что Вы освоили отличную нишу с минимальной конкуренцией :)
С другой стороны, как Вы сами сказали, пользователи платят за виртуалку больше, чем за аренду физического сервера. Те, кто это понимают — будут арендовать сервер (если только им не нужно кластерное решение и пиковые нагрузки невелики)… И причина не только в цене. Там есть свой ряд других преимуществ, но не будем отклоняться от темы.
С другой стороны, как Вы сами сказали, пользователи платят за виртуалку больше, чем за аренду физического сервера. Те, кто это понимают — будут арендовать сервер (если только им не нужно кластерное решение и пиковые нагрузки невелики)… И причина не только в цене. Там есть свой ряд других преимуществ, но не будем отклоняться от темы.
Кстати, что будет с облаком если на него упадет очень сильный DDOS не дай Бог? Проблему ощутят все клиенты? Тут ведь получается сложнее ситуация, чем если отдельный сервер в ДЦ атакуют и просто занулрутить ай пи того сервера. Или на одном IPv4 адресе у Вас не очень много сайтов и его тоже можно отправить в null-route? В тоже время, интересно, как это повлияет на все облако до этого момента.
У нас один ipv4 на одну виртуалку. То есть теоретически, есть возможность полной изоляции. На практике, большинство ddos'ов меньше нашего входного канала, так что достаточно мигрировать виртуалку на отдельный хост, где она будет получать гигабит из вошедших, например, 5-7.
Блокировка происходит автоматически при превышении какого-то порога пакетов в секунду или все же нужно вручную? Ощущают ли атаку другие пользователи до момента блокировки? Если не секрет, какой входящий канал?
На нашего клиента в Украине в этом году упал DDOS, так всем клиентам ДЦ было плохо. Печально то, что сейчас атаку в 10-15 Гбит / с могут некоторые умельцы организовать за $30 в час. 50 Гбит / с — дороже. Но уже тоже не крайне фантастические деньги. Потому увы полагаться на то, что атака не превысит входящий канал уже нельзя наверное и надо также учитывать этот риск.
На нашего клиента в Украине в этом году упал DDOS, так всем клиентам ДЦ было плохо. Печально то, что сейчас атаку в 10-15 Гбит / с могут некоторые умельцы организовать за $30 в час. 50 Гбит / с — дороже. Но уже тоже не крайне фантастические деньги. Потому увы полагаться на то, что атака не превысит входящий канал уже нельзя наверное и надо также учитывать этот риск.
Если ddos терпим для нашей инфраструктуры — разруливается штатными средствами, не как dos, а как «большая нагрузка»… pps мы вообще не контролируем, благо ovs с этим справляется на ура.
Если придёт 50Гб в одно горло — будет нехорошо. У нас коммутатор на пул (группу хостов) 20Гбит аплинк имеет, и тут потребуется участие людей (автоматика в одиночестве не справится). Придёт 100+ либо завернём на входе, либо честно ляжем.
Если придёт 50Гб в одно горло — будет нехорошо. У нас коммутатор на пул (группу хостов) 20Гбит аплинк имеет, и тут потребуется участие людей (автоматика в одиночестве не справится). Придёт 100+ либо завернём на входе, либо честно ляжем.
Интересно, спасибо. Возможность помещать на облако сайты под атакой и оплачивать «фильтрацию» в виде платы за ресурс, который использует атака и только во время атаки — это круто, ничто не фильтрует DDOS лучше такого решения. Зачастую атаки до 10 Гбит / с, так что тут Ваше решение действительно не заменимо.
Немного не так. Есть пользователи, которые в некоторые дни платят больше, чем платили бы за сервер. У большинства таких пользователей пики в десятки/сотни мегабит, то есть им бы пришлось докупать полосу (много полосы). Но бывают такие, у которых один ресурс сильно перекошен. Например, делать пару тысяч iops'ов на обычном сервере просто не возможно. А если у человека это основная нагрузка, то зачем ему при этом десятки гигабайт и пачки ядер (как было бы в случае большого сервера)?
Идеей «оплаты по потреблению» является мысль, что у каждого сервера свои запросы. И если человек будет оплачивать только нужные ресурсы, для него это будет выгоднее, чем оплачивать комплект из нужных и ненужных ресурсов. А для провайдера ресурсы продаются с наценкой, то есть тоже с выгодой.
Банальное повышение эффективности и всё.
Идеей «оплаты по потреблению» является мысль, что у каждого сервера свои запросы. И если человек будет оплачивать только нужные ресурсы, для него это будет выгоднее, чем оплачивать комплект из нужных и ненужных ресурсов. А для провайдера ресурсы продаются с наценкой, то есть тоже с выгодой.
Банальное повышение эффективности и всё.
Пожалуй, соглашусь с amarao: «Моё мнение — shared-хостинг обречён.»
У меня два корпоративных сайта в Селектеле. Когда изучал вопрос хостинга, был выбор: или искать действительно хороший быстрый хостинг или положить сайты на свои «большие» сервера.
В результате выбрал ни то ни другое — виртуалка Селектела. Для меня по факту тот же хостинг (по цене), но только весь софт настроен оптимально под сайты.
У меня два корпоративных сайта в Селектеле. Когда изучал вопрос хостинга, был выбор: или искать действительно хороший быстрый хостинг или положить сайты на свои «большие» сервера.
В результате выбрал ни то ни другое — виртуалка Селектела. Для меня по факту тот же хостинг (по цене), но только весь софт настроен оптимально под сайты.
Sign up to leave a comment.
Стабильный хостинг — миф или реальность?