Разве я ничего не сказал о техподдержке? Больше половины моего предыдущего поста о ней, дочитайте, пожалуйста.
Если Вы тут не перепутали аппаратную и програмную базы, то про аппаратную я ни слова не сказал.
Никак не отделаетесь от МакДоналдс-хостинга. Этого, пожалуй, хотелось бы, но так не бывает.
Вы думаете у руководителей так уж редко возникает вопрос "Купить или разработать самим"? Дешеве(что совсем не странно) как раз-таки купить. Способность IT-компании вести собственные софтверные разработки сегодня это вопрос просто выживаемости, иначе в определенный момент развития компания оказывается в ступоре.
Если Вы глубоко убеждены, что того, что описали вполне достаточно для массового хостинга, и вопрос только в цене, я могу только пожелать Вам удачи - Вас ждет много чудесных открытий. Если речь о действительно массовом виртуальном хостинге.
"Поставил и забыл" "купил и забыл" "написал и забыл" - так не бывает. Даже в случае с PBA не обойдесь без своих интеграторов, знающих api/sdk/whatever, либо будете постоянно привлекать внештатных.
Похоже, что от темы "Что нужно современному клиенту хостинга" перешли к вопросу "Что нужно современному хостеру". Что нужно клиенту, я уже написал в первом ответе.
Виртуальный хостинг в технически части куда более сложнее, чем VDS или сервер на клиента. Открытые решения, указанный вами LAMP, в частности, пока просто не преспособлены делить ресурсы и обеспечивать безопасность клиентам виртуального хостинга, и требуют существенного вмешательства в код всюду - от ядра до сервисов и прикладного ПО. Проблем с виртуальным хостингом больше, они серьезнее и нетривиальнее.
Это работа для опытного системного программиста, которая требует знаний, гораздо бОльших, чем просто настроить apache и nginх. А такие специалисты в силу указанных причин в хостинговых компниях, как правило, не оседают.
По поводу обучения - я уже сказал про текучку техподдержки, которая это самое обучение сводит на ноль. И недостаточно просто знаний, как клиенту объяснить процедуру настройки The Bat'а для pop3, в каждой хостинговой компания есть масса своих внутренних нюансов и особенностей, которые прочтением мануалов и инструкций сразу не усваивается. Да, есть повторяемость какой-то массы проблем, с которыми обращаются клиенты, но даже ее объем таков, что за обычный небольшой срок работы студента в тех. поддержке этому студенту ее не освоить. И что самое главное - привычка повторять заученное - очень плохой навык для тех.поддержки. Хостинг услуга в принципе своем это не МакДоналдс, где нарядил человека, научил говорить "Свободная касса", около двери уже стоит разноцветный пенопластовый клоун, и вперед. Это техническая услуга, и уровень ее качества прежде всего отпределяет технический состав по всей цепочке.
И чем массовее, тем все это это острее.
Можете даже не возражать всему этому - не переубедите :)
Рейтинг по какому критерию? Если по кол-ву доменов на dns'ах хостера - stat.nic.ru и 1stat.ru. Также есть статистика, которую периодически подготавливает Алексей Тутубалин -
http://www.rukv.ru/runet-2008.html , она отличается от предыдущих другим принципом учета, тут учитывается фактическое расположение сайтов по ip адресам, то есть, здесь учтено, что ns запись может обслуживаться регистритором или собственным сервером, но указывать на ip адрес хостинг провайдера, или ns у одного хостера, а сайт у другого
Достаточно много балансеров, которые сохраняют треки tcp соединений с одним определенным бэкэндом. Попробуйте в тесте простой балансер, например, pen (http://siag.nu/pen/). (Работают они довольно просто, при желании Вы можете осилить написать собственный балансер, который будет работать по нужным Вам правилам.) Этим вскроете возможные подводные камни в части работы вашего веб-проекта с сессиями, потом можно внедрять более продвинутые балансеры.
Kashey кстати упомянул memcached, imho, если пришло время под один веб-проект ставить дополнительно сервера, то лучше(да, хотя в большинстве случаев и затратнее) переписывать проект под распределенную работу, чем выстраивать балансировку с привязкой сессий к бэкэндам.
Можно поинтересоваться, из каких соображений Вы держите собственную почту на gmail.com? Как-то, наверное, не комильфо для хостера.
{{{
yeshost.ru has address 78.108.179.100
yeshost.ru mail is handled by 10 ASPMX5.GOOGLEMAIL.COM.
yeshost.ru mail is handled by 1 ASPMX.L.GOOGLE.COM.
..
}}}
Были проблемы с каналами РТКОММ'а, этой весной довольно частые - это, строго говоря, не в их ответственности, но клиенту от этого не легче. В отношении решения внутренних вопросов - все предельно обстоятельно.
Вообще, если вопрос был о крупных площадках для размещения в СПб, p8 на серверо-западе, пожалуй, самая крупная. Хотел написать "и старая", но вспомнил про Демос - это без рекомендации, лет 6 назад последний раз с ними приходилось общаться, какие там сейчас условия, не знаю.
http://p8.ru
Извините, может, по причине позднего часа, но схема мне видится мутноватой
rl0 rl1 - это разные интерфейсы? Как-то странно видеть адреса одной подсетки на разных линках.
Вообще не прозрачнее ли было объединить линки в etherchannel?
Погодите, речь шла о том, почему за 7 лет критерии конфигурации тарифов на шаредах не изменились - то есть, как прыгали от дисковой квоты, так и прыгаем, а с памятью и процессором на шаредах до сих пор как-то всё невнятно получается везде и всюду.
ТС, я правильно перефразировал?
Если так, то корни невнятности именно в технической плоскости. Маркетологи небось бы и рады в тарифах на массовый виртуальный хостинг написать четко выделенные лимиты на процессор/память, да технари для шаредов не могут организовать такой "потолок" так же агрегированно и однозначно, как дисковую квору. Лимиты на процесс это не то. Речь о фиксированном "потолке" на аккаунт. Вот и сидят люди и субъективно оценивают "вес" аккаунтов и сайтов. Да, есть технические средства, которые помогают это оценить, собрать аргументы о тяжести сайта для клиента. Но так, чтобы фиксированно выделить клиенту на шаред хостинге память/процессор и забыть о том, что какой-то клиент может загрузить - пока, увы, нет.
Если Вы или кто-либо из читателей темы это умеет делать - напишите просто, мол, да, мы без лукавства это умеем. Как инженер, я знаю, что технически это можно делать, но никто, насколько мне известно, так не поступает.
Кстати сказать, в том, что такого нет на шаредах, есть и плюсы - и для хостера и для клиента - хостер имеет возможность оверселлить, клиент имеет возможность пиками забирать больше ресурсов, чем ему полагалось бы, пики размажутся усредненными значениями.
В любом случае пока на шаред хостинге все именно так и происходит - рано или поздно владелец "тяжелого" аккаунта получает письмо от саппорта или робота о том, что так, мол, и так, Ваш аккаунт потребляет слишком много ресурсов - вам нужен ВДС или выделенный сервер.
Разработчики решений для ВДС одарили маркетологов возможностью писать лимиты на виртуальный сервер в мегагерцах и мегабайтах (хотя тут тоже достаточно моментов от лукавого). Для шареда таких решений "из коробки" пока нет (а может есть, но я не знаю). Но, в любом случае, это - технические решения, никак не маркетинговые.
