так не выйдет нужно каждому серверу по отдельной директиве server {}
хотя можно наверное чере if $server_name с последующим переходом на именованный локейшн, но это априори неверный подход..
upd:
хотя нет, что-то я еще не проснулся
root /var/www/$server_name;
location \.(jpg|jpeg|gif|png)$ {
try_files $uri @backend
}
как-то так...
если действительно нужен полный чрут, то есть изоляция его уровня, то проще завернуть нужные процессы в lxc (не полный контейнер, а лишь процессы). правда тогда выйдет каждому юзеру по процессу, впрочем от mpm_itk это не сильно отличается в конечном итоге...
да все непонятно. куда, чего и как упал - неясно. можно даже предположить, что он у Вас со стойки вывалился, из-под самого потолка, стало быть упал на пол. тогда его бровью точно не подымут... :D
ну так сказал ТС ;)
нет конечно же
тот же lxc например (для его задач вполне пойдет, большая изоляция не нужна), даже в простейшем своем виде (контейнер приложения) все равно имеет возможности по ограничению ресурсов (и мониторингу) для процессов на порядок выше банальных лимитов для процессов (это просто удобная оболочка для cgroups), оверхед мизерный, а изоляция много лучше suexec-а и php-fpm-а... возникли тормоза/проблемы у клиента - снизил лимиты на cpu до 10% и пусть себе там делает что хочет :D
но тема себя исчерпала по-видимому ;)
это само-собой, тем более что и сервер не один будет
я несколько о другом говорил. как к кпримеру ТС будет квотировать базы мускула по объему? скрипты городить? и т.д. и т.п..., а контейнер, это один из вариантов упростить и автоматизировать ему подобные действия (разбить по клиентам, по задачам, да и не парится).
потому я и написал "может оказатся сложней, чем просто раскинуть сайты по контейнерам", а не однозначно лучше
по задачам еще. такие-то cms-ы в одном, визитки в другом, да мало ли... тем более, что у него и так все как-то же уже разбито там, просто он, как я понял, хочет полностью администрирование на себя взять
ну тут и ТЗ крайне скудно озвучена, так что почти и не о чем говорить
вот, пожалуйста -
нет. но у меня есть большой опыт работы в хостингах (как шаред, так и вдс/впс), в т.ч. и поднятие оных почти с нуля. 10 виртуалок (по 10 сайтов в каждой например) проще контролировать, чем один шаред-хостинг с сотней сайтов. начиная от распределения ресурсов и заканчивая защитой от ддос-ов...
при должном подходе не разойдутся. скрипты, панели в конце-концов...
50 серверов я конечно же не имел ввиду. но и не 1 апач и 1 мускул, потому что поди разберись (быстро) что именно заглючило, если вдруг что-то начнет их ронять...
возможно и нанять, тем более в свете незнания ТС-ом "никаких" квот/лимитов
а может и почитать тот же опеннет, прочие форумы (у того же Лисяры была довольно полная хаутушка, емнип) - тогда и вопросы сами-собой отпадут
я бы поспорил
грамотно построить шаред-хостинг может оказатся сложней, чем просто раскинуть сайты по контейнерам (jail-ам или vserver-ам в простейшем случае) и единожды задать лимиты на ресурсы, да какой-то скриптец для автодобавления в мониторинг разово написать... тем более если они сильно разные. ну и если если админ один... например та же проблема быстрой (живой) миграции, бекапов, раздачи квот, в т.ч. и на БД, да мало ли... тем более что оно уже в впс-ах..
но я конечно же не имею ввиду каждому сайту по контейнеру. тут в любом случае по месту нужно смотреть и думать, грамотно раскидать
вы не сказали на чем магазин... и какого рода ддос..
впрочем универсального решения (устраивающего и вас) вам вряд ли кто предложит, в смысле хостинга.
а vps посоветовать и настроить, пару скриптов, грамотная настройка nginx-а (лимитов)... - это тут легко не небольшую сотню-другую ;-)
ТС-у лучше использовать KVM
с любой вмварью (серверной) получится больше головной боли, чем толку. потому что, как уже сказал fahosting, оно требует тщательного подбора железа, сертефицировано, емнип, только под дремучую убунту и rhel и т.п. вытекающий головняк..
все вышеперечисленные ОС и задачи изкоробочный KVM (в виде вирт-манагера в федоре например) вполне потянет.. есть еще варианты более "тяжелые"...
варианты хоть и есть, но они вас не спасут, ибо как уже сказали раньше - проблема аппаратная (если вы даже kernel-panic не созерцаете)
ну разве что действительно роутер вопхнуть, но это "не то"..