Статья не претендует на абсолютную истину и не отражает весь спектр вопросов, связанных с предоставлением и использованием услуг хостинга, ставит вопросы, описывает проблемы и некоторые способы решения.
Будет полезно веб-мастерам лучше понять специфику используемых услуг, облегчить выбор правильного решения, а также может быть полезно хостинг-провайдерам.
Полное совершенство недостижимо, но важно стремление к совершенству, мы постоянно совершенствуем решения, которые предлагаем клиентам, внимательно прислушиваемся к критике и делаем все, чтобы соответствовать основному принципу нашей работы – мы рады сделать вас счастливее.
Иногда мы допускаем ошибки, иногда делаем недовольными наших партнеров, но мы всегда стараемся вместе найти выход из этой ситуации, ведь клиент для нас – прежде всего партнер, а мы – партнер для клиента.
И слушать друг друга крайне важно в этих отношениях.
Разрабатывая совершенно новую услугу хостинга, которой еще не существовало на рынке хостинговых услуг, мы постарались решить ряд вопросов, которые в последнее время остро встали перед нами и, возможно, некоторыми другими хостинг-провайдерами, и учесть пожелания Наши клиенты.
Мы постарались сделать сервис более надежным и понятным, в первую очередь, для рядового пользователя услуг хостинга.
Пока рано говорить об успехе или провале проекта, но первые результаты говорят о том, что мы работаем не зря, а там посмотрим.
Проблемы хостинга Первое, с чего следует начать решение любой задачи, — это правильно сформулированная задача и правильно поставленные вопросы к ней.
По личному опыту могу сказать, что правильно поставленный вопрос – это не просто большая часть решения, вопрос вполне может стать полноценным ответом, если разбить проблему на составляющие.
Итак, что же волнует пользователей хостинга? Доступность сайта (надежность, отказоустойчивость), скорость, цена.
Большинство может обратить особое внимание на цену, выдвинув ее на первый план, как по объективным, так и по субъективным причинам.
И поэтому самой большой проблемой как для новичков, так и для продвинутых вебмастеров является выбор тарифного плана.
Выбор тарифного плана Этот выбор может оказать существенное влияние на отношения между провайдером и вебмастером во время сотрудничества.
И речь идет не о том, что некоторые хостинг-провайдеры лучше относятся к тем, кто платит больше (воздержимся от оценки таких случаев, данная статья не об этом), а о том, как легко ошибиться по неопытности.
и сэкономить лишние деньги, тем самым спровоцировав конфликтную ситуацию в будущем, а она, несомненно, будет. Начинающие вебмастера часто искренне обижаются на провайдеров за письма о повышенной нагрузке и пишут гневные отзывы в Интернете.
Наверное, все через это прошли, в том числе и мы.
Они твердо уверены, что сайт практически без трафика не может создать такую проблему.
И они правы! Потому что они слишком неопытны и еще не могут знать, что система управления контентом (CMS), обремененная множеством модулей и не оптимально настроенная, может создавать значительное потребление.
Или потому, что не понимают, что провайдер, чтобы охватить большее количество потенциальных клиентов, мог бы создать слишком недорогой тарифный план, рассчитанный только на небольшую домашнюю страницу.
При этом выбор более дорогих тарифов не менее сложен.
Инфраструктуры хостинга сильно различаются у разных провайдеров, как и методы учета потребляемых ресурсов.
В результате такой показатель потребления ресурсов, как процессорное время, оказывается практически бессмысленным при переходе от одного поставщика услуг к другому, поскольку с большой долей вероятности процессоры на узлах хостинга разные.
И даже если пользователь опытный и может представить разницу в производительности, ему уже проблематично представить степень оптимальности настройки серверного ПО, поскольку это зависит исключительно от опыта специалистов технического отдела поставщика услуг.
.
А еще есть негласный негласный параметр — заполняемость хостинговых узлов.
Иногда провайдер держит определенных пользователей с повышенной нагрузкой, не беспокоя их и не требуя доплаты, просто чтобы продать ресурсы за любые деньги, так как другие клиенты не потребляют, либо нода слишком свободна и с нее выгодно получать хоть что-то.
а не ничего.
Что мы имеем в итоге? Даже с клиентами на более дорогих тарифных планах случаются неприятные ситуации, когда пользователь переходит от одного провайдера к другому и с удивлением обнаруживает, что то, что работало там, здесь создает перерасход. Мы регулярно получаем письма счастья.
Недовольны все: и поставщики, и клиенты.
Выход? Мы искали его несколько лет. Мы обеспечили низкую цену на хостинг не за счет низкого лимита ресурсов; мы защитили себя от спамеров и недобросовестных клиентов, введя невыгодную для них систему тарифов, когда заказывать услугу выгодно исключительно на длительный период, что не имеет смысла в случае теневых целей.
Значительно повышена стабильность сервиса без сложных технических решений; тысяча клиентов создали не более 1 обращения в техподдержку.
отделение в течение 24 часов, минимизируя возможные конфликтные ситуации.
Решения и результаты подробно описаны в нашей статье от 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-серверов, когда SSD использовались для кэширования или только для баз данных.
И это называлось SSD-хостинг, которым в принципе некоторые не брезгуют и сейчас, вводя клиентов в заблуждение, чтобы сэкономить как можно больше денег.
Да, накопители по-прежнему существенно дороже SATA, но преимущества, которые они предлагают, как с точки зрения производительности, так и с точки зрения надежности, неоспоримы.
Более того, как я недавно писал Амарао в его статье «SSD+raid0 — не все так просто» , эти диски в массиве могут быть неэффективны для повышения производительности записи из-за разной задержки, в отличие от HDD — RAID0 будет ждать подтверждения от самого медленного диска в массиве.
Соответственно, лучше использовать диски самостоятельно и добиваться повышения производительности через скрипты, а не через рейд. Кроме того, важна эффективная утилизация этих дисков.
Всем известно, что SSD «убивают» циклы перезаписи, поэтому создавать отдельные серверы баз данных нет смысла, так как диски будут распределяться неравномерно.
Помимо прочего, отдельные серверы баз данных снижают надежность, поскольку в случае возникновения проблем значительная часть абонентов может сразу их почувствовать.
Выполнение Чтобы повысить степень отказоустойчивости и обеспечить минимально возможные затраты для абонентов, мы решили отойти от назначения определённых ролей отдельным узлам.
Для построения решения использовались 4 x-процессорные платформы с десятиядерными процессорами Intel Deca-Core Xeon E7-4850 с возможностью установки до 1 ТБ оперативной памяти и до 16 SSD-накопителей.
При этом, чтобы избежать эффекта «мегасервера», когда проблема с одним подписчиком (повышенная нагрузка, атака) вызывает проблемы в работе сайтов всех подписчиков узла, мы разбили узел на несколько виртуальных машин.
, используя виртуализацию, при которой каждая из машин может использовать максимально доступные ресурсы, но не в ущерб работе других виртуальных машин.
Это позволило повысить степень отказоустойчивости, так как теперь в случае серьезной проблемы с нагрузкой/атаки на одного из пользователей это может почувствовать только часть абонентов узла (от 1/16 до 1/ 32 на наших узлах).
Помимо прочего, программа позволяет сразу заблокировать такого проблемного клиента и переместить его в отдельную виртуальную среду для решения проблемы, а в случае, когда атака основана на IP-адресе, переместить всех его соседей.
Для этого мы подключили каждый из узлов интернет-каналом гарантированной пропускной способности 10 Гбит/с с возможностью расширения, что не только позволяет обеспечить практически любой необходимый трафик для наших абонентов, но и быстро мигрировать как отдельных абонентов, так и целые виртуальных машин, быстро создавать резервные копии на удаленных хранилищах и развертывать их.
Уже описанная выше четкая связь между генерируемым трафиком и потребляемыми вычислительными ресурсами позволила тарифицировать только трафик (посетителей), сделав тарификацию прозрачной и удобной, а выбор тарифного плана максимально простым и понятным.
Результаты С момента запуска нового хостинг-проекта (январь 2015) мы не получили ни одного недовольного клиента, аптайм составляет 100% и в будущем, мы надеемся, что это значение приблизится к 100. Конечно, времени прошло слишком мало.
оценить все преимущества и недостатки решения, но пока мы не видим существенных недостатков этого решения.
Возможно, вы это увидите? Для всех читателей хабрахабра мы предоставляем уникальную возможность заказать услугу «Волшебный хостинг» со скидкой 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-атакам, а также ресурсов, заблокированных для пользователей из России Роскомнадзором или с высоким потенциальным риском такой блокировки; — стандарты использования сети, принятые рабочей группой ОФИСП, а также Договор Оферты должны соблюдаться в полной мере.
Теги: #хостинг в Нидерландах #магический хостинг #хостинг в США #хостинг без ограничений ресурсов #хостинг без ограничений ресурсов
Статья не претендует на абсолютную истину и не отражает весь спектр вопросов, связанных с предоставлением и использованием услуг хостинга, ставит вопросы, описывает проблемы и некоторые способы решения.
Будет полезно веб-мастерам лучше понять специфику используемых услуг, облегчить выбор правильного решения, а также может быть полезно хостинг-провайдерам.
Полное совершенство недостижимо, но важно стремление к совершенству, мы постоянно совершенствуем решения, которые предлагаем клиентам, внимательно прислушиваемся к критике и делаем все, чтобы соответствовать основному принципу нашей работы – мы рады сделать вас счастливее.
Иногда мы допускаем ошибки, иногда делаем недовольными наших партнеров, но мы всегда стараемся вместе найти выход из этой ситуации, ведь клиент для нас – прежде всего партнер, а мы – партнер для клиента.
И слушать друг друга крайне важно в этих отношениях.
Разрабатывая совершенно новую услугу хостинга, которой еще не существовало на рынке хостинговых услуг, мы постарались решить ряд вопросов, которые в последнее время остро встали перед нами и, возможно, некоторыми другими хостинг-провайдерами, и учесть пожелания Наши клиенты.
Мы постарались сделать сервис более надежным и понятным, в первую очередь, для рядового пользователя услуг хостинга.
Пока рано говорить об успехе или провале проекта, но первые результаты говорят о том, что мы работаем не зря, а там посмотрим.
Проблемы хостинга Первое, с чего следует начать решение любой задачи, — это правильно сформулированная задача и правильно поставленные вопросы к ней.
По личному опыту могу сказать, что правильно поставленный вопрос – это не просто большая часть решения, вопрос вполне может стать полноценным ответом, если разбить проблему на составляющие.
Итак, что же волнует пользователей хостинга? Доступность сайта (надежность, отказоустойчивость), скорость, цена.
Большинство может обратить особое внимание на цену, выдвинув ее на первый план, как по объективным, так и по субъективным причинам.
И поэтому самой большой проблемой как для новичков, так и для продвинутых вебмастеров является выбор тарифного плана.
Выбор тарифного плана Этот выбор может оказать существенное влияние на отношения между провайдером и вебмастером во время сотрудничества.
И речь идет не о том, что некоторые хостинг-провайдеры лучше относятся к тем, кто платит больше (воздержимся от оценки таких случаев, данная статья не об этом), а о том, как легко ошибиться по неопытности.
и сэкономить лишние деньги, тем самым спровоцировав конфликтную ситуацию в будущем, а она, несомненно, будет. Начинающие вебмастера часто искренне обижаются на провайдеров за письма о повышенной нагрузке и пишут гневные отзывы в Интернете.
Наверное, все через это прошли, в том числе и мы.
Они твердо уверены, что сайт практически без трафика не может создать такую проблему.
И они правы! Потому что они слишком неопытны и еще не могут знать, что система управления контентом (CMS), обремененная множеством модулей и не оптимально настроенная, может создавать значительное потребление.
Или потому, что не понимают, что провайдер, чтобы охватить большее количество потенциальных клиентов, мог бы создать слишком недорогой тарифный план, рассчитанный только на небольшую домашнюю страницу.
При этом выбор более дорогих тарифов не менее сложен.
Инфраструктуры хостинга сильно различаются у разных провайдеров, как и методы учета потребляемых ресурсов.
В результате такой показатель потребления ресурсов, как процессорное время, оказывается практически бессмысленным при переходе от одного поставщика услуг к другому, поскольку с большой долей вероятности процессоры на узлах хостинга разные.
И даже если пользователь опытный и может представить разницу в производительности, ему уже проблематично представить степень оптимальности настройки серверного ПО, поскольку это зависит исключительно от опыта специалистов технического отдела поставщика услуг.
.
А еще есть негласный негласный параметр — заполняемость хостинговых узлов.
Иногда провайдер держит определенных пользователей с повышенной нагрузкой, не беспокоя их и не требуя доплаты, просто чтобы продать ресурсы за любые деньги, так как другие клиенты не потребляют, либо нода слишком свободна и с нее выгодно получать хоть что-то.
а не ничего.
Что мы имеем в итоге? Даже с клиентами на более дорогих тарифных планах случаются неприятные ситуации, когда пользователь переходит от одного провайдера к другому и с удивлением обнаруживает, что то, что работало там, здесь создает перерасход. Мы регулярно получаем письма счастья.
Недовольны все: и поставщики, и клиенты.
Выход? Мы искали его несколько лет. Мы обеспечили низкую цену на хостинг не за счет низкого лимита ресурсов; мы защитили себя от спамеров и недобросовестных клиентов, введя невыгодную для них систему тарифов, когда заказывать услугу выгодно исключительно на длительный период, что не имеет смысла в случае теневых целей.
Значительно повышена стабильность сервиса без сложных технических решений; тысяча клиентов создали не более 1 обращения в техподдержку.
отделение в течение 24 часов, минимизируя возможные конфликтные ситуации.
Решения и результаты подробно описаны в нашей статье от 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-серверов, когда SSD использовались для кэширования или только для баз данных.
И это называлось SSD-хостинг, которым в принципе некоторые не брезгуют и сейчас, вводя клиентов в заблуждение, чтобы сэкономить как можно больше денег.
Да, накопители по-прежнему существенно дороже SATA, но преимущества, которые они предлагают, как с точки зрения производительности, так и с точки зрения надежности, неоспоримы.
Более того, как я недавно писал Амарао в его статье «SSD+raid0 — не все так просто» , эти диски в массиве могут быть неэффективны для повышения производительности записи из-за разной задержки, в отличие от HDD — RAID0 будет ждать подтверждения от самого медленного диска в массиве.
Соответственно, лучше использовать диски самостоятельно и добиваться повышения производительности через скрипты, а не через рейд. Кроме того, важна эффективная утилизация этих дисков.
Всем известно, что SSD «убивают» циклы перезаписи, поэтому создавать отдельные серверы баз данных нет смысла, так как диски будут распределяться неравномерно.
Помимо прочего, отдельные серверы баз данных снижают надежность, поскольку в случае возникновения проблем значительная часть абонентов может сразу их почувствовать.
Выполнение Чтобы повысить степень отказоустойчивости и обеспечить минимально возможные затраты для абонентов, мы решили отойти от назначения определённых ролей отдельным узлам.
Для построения решения использовались 4 x-процессорные платформы с десятиядерными процессорами Intel Deca-Core Xeon E7-4850 с возможностью установки до 1 ТБ оперативной памяти и до 16 SSD-накопителей.
При этом, чтобы избежать эффекта «мегасервера», когда проблема с одним подписчиком (повышенная нагрузка, атака) вызывает проблемы в работе сайтов всех подписчиков узла, мы разбили узел на несколько виртуальных машин.
, используя виртуализацию, при которой каждая из машин может использовать максимально доступные ресурсы, но не в ущерб работе других виртуальных машин.
Это позволило повысить степень отказоустойчивости, так как теперь в случае серьезной проблемы с нагрузкой/атаки на одного из пользователей это может почувствовать только часть абонентов узла (от 1/16 до 1/ 32 на наших узлах).
Помимо прочего, программа позволяет сразу заблокировать такого проблемного клиента и переместить его в отдельную виртуальную среду для решения проблемы, а в случае, когда атака основана на IP-адресе, переместить всех его соседей.
Для этого мы подключили каждый из узлов интернет-каналом гарантированной пропускной способности 10 Гбит/с с возможностью расширения, что не только позволяет обеспечить практически любой необходимый трафик для наших абонентов, но и быстро мигрировать как отдельных абонентов, так и целые виртуальных машин, быстро создавать резервные копии на удаленных хранилищах и развертывать их.
Уже описанная выше четкая связь между генерируемым трафиком и потребляемыми вычислительными ресурсами позволила тарифицировать только трафик (посетителей), сделав тарификацию прозрачной и удобной, а выбор тарифного плана максимально простым и понятным.
Результаты С момента запуска нового хостинг-проекта (январь 2015) мы не получили ни одного недовольного клиента, аптайм составляет 100% и в будущем, мы надеемся, что это значение приблизится к 100. Конечно, времени прошло слишком мало.
оценить все преимущества и недостатки решения, но пока мы не видим существенных недостатков этого решения.
Возможно, вы это увидите? Для всех читателей хабрахабра мы предоставляем уникальную возможность заказать услугу «Волшебный хостинг» со скидкой 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-атакам, а также ресурсов, заблокированных для пользователей из России Роскомнадзором или с высоким потенциальным риском такой блокировки; — стандарты использования сети, принятые рабочей группой ОФИСП, а также Договор Оферты должны соблюдаться в полной мере.
Теги: #хостинг в Нидерландах #магический хостинг #хостинг в США #хостинг без ограничений ресурсов #хостинг без ограничений ресурсов
-
Ты Недостаточно Крут, Чтобы Так Себя Вести
19 Oct, 24 -
Стилизация Изображений С Помощью Css3
19 Oct, 24
