>[оверквотинг удален]
>>с дисками. :)
>
>1U, SR15XX с двумя сокетами (8 ядер) 2 SAS/SCSI 147/300GB 15k, классическая
>связка Apache + Nginx, но(!):
>
>1. Сервера баз данных отдельно, но в одном L2
>2. Отдельная структура HTTP-акселераторов (и перед ними еще и LVS): удобно для
>блокировки DDoS, что бы не ложились бэкэнды
>
>= Спокойно, на одном бэкэнде, живут до 1000 сайтов на PHP :) А-а, ну тогда понятно. Уже после моего ухода там начали выносить БД в отдельный кластер… HTTP каждая машина тоже самостоятельно обрабатывала. Так что нагрузка немаленькая, но довольно равномерная была. По крайней мере, когда платформу в production вносили. Потом, понятно, жизнь заставила вносить коррективы. :)
>[оверквотинг удален]
>отрубаются, или увозятся в каратин, к себе подобным.
>
>>>На шаред-хостинге в таком случае просто отрубают сайт-источник проблем, для внутренних сервисов
>>>так не поступишь(разве что, перенести на другую, более свободную железку),
>>>поэтому на диской подсистеме, для нормальной изоляции сервисов, лучше не экономить.
>>
>>Это понятно, просто с посещаемыми сайтами в итоге, повторюсь, всё обычно упирается
>>в CPU.
>
>С посещаемыми, не на шаред-хостинге, имхо, в БД в ~80% случаев.
Правильно, а в БД всё обычно упирается в проц (при условии хорошей дисковой подсистемы), особенно при дебильных структурах БД (без реляционных зависимостей и т.д.). Клиенты такие клиенты… :)
>>>Кроме того, и на шаред-хостинге SAS зеркало для двухсокетовой машины это не
>>>такое уж и барство.
>>
>>Смотря на каком. В конторе, где я работал, ставили RAID5 + 1-2
>>hot spare, на SCSI/SAS. Проблем с пропускной способностью дисков не было.
>
>hotspare это хорошо, но гораздо лучше договоренность с дата-центром, что бы меняли
>hotswap диски с Вашей полочки (имхо)
У нас просто свои люди круглосуточно дежурили. ;) Сейчас у той конторы вообще свой дата-центр, все как дети радовались его запуску. :)
>>>>Можно динамически менять приоритеты, не проблема.
>>>
>>>Не удобно :(
>>
>>Кому как. Мониторинг всё равно надо вести, так что…
>
>Конечно, но чем меньше Вас будет доставать мониторинг, тем лучше, разве не
>так?
Если следишь, то и поводов для доставания как-то меньше случается. ;)
>[оверквотинг удален]
>>Ну в общем-то да, проще каждому заключённому в тюрьме нарастить стены внутрь
>>камеры с помощью железобетона, чем нанимать тюремщиков… Но всё же полагаться
>>только на систему мониторинга не стоит. В конце концов, она тоже
>>может сбойнуть или вообще отказать…
>
>Личный опыт: с нагруженным шаред-сервером(озвученного выше конфига) проблемы возникают (нужно выключать обнаглевшие
>сайты, увозить в каратин, и т д) ~ раз в три-четыре
>дня(даунтайм и лаги минут на 10 для клиентов), с нагруженной Virtuozzo
>нодой, раз в 3-6 месяцев (у некоторых аптайм был почти полтора
>года, но потом пришлось security fix накатить, и все перезагрузить)
С одним сервером раз в три-четыре дня?! Не, это не дело, конечно. За аптайм не скажу, где как было (с одним клиентом, помню, было несколько серий фильма «злые конкуренты давят нас бедных, dedicated мы не потянем» — это при том, что реклама этой конторы по всем радиостанциям крутилась). На сотню (примерно) серверов приходилось, не соврать, 1-2 серьёзных инцидента в неделю (доводящих до ребута), и десяток-другой помельче (повышенная нагрузка и лаги, но система работоспособна). Причём нередко траблы были в железе. При этом, повторюсь, каждая машина была изначально самодостаточной.
>Имхо, проще все внешние и внутренние сервисы растолкать в легкие контейнеры, и,
>если, например, Вы не хостер, а, например, аутсорсер - мы делаем
>именно так, - рассажать сервисы клиентов, что на Ваших серверах по
>контейнерам, поставив разумные лимиты сверху и снизу. Если проблемы вообще не
>будут возникать, вероятность того, что о них не узнает клиент, больше,
>чем с ручной, и быстрой реакцией на мониторинг = лучше сервис,
>лучше качество, лучше репутация, можно поднять цены, зарплаты сотрудникам, и т
>д.
У каждого свой опыт, в общем. :)
