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