>>Тогда зачем ее перезагружают :)? Зачем она пишет, что после обновления must
>>have ребут:)?
>
>Довольно редко пишет. Поледний раз в начале лета писало. apache например обновляется
>чаще. Притянуто за уши. Насчет Апача чушь, имхо. А еще, сравните время перезапуска сервиса, пусть и такого тяжелого, как Апач на бэкэнде, с временем ребута (и даунтайма) Win Server :( Время различается на порядок (или три порядка?)
после killall -9 httpd на "тяжелом" бэкэнде под LAMP (выделенный сервер исключительно под Апач 2 четырехядерных сокета, 4 Gb ОЗУ, около 200 воркеров), полностью сервис поднимается где-то через 8-10 секунд (в течение двух-трех он, пока запускает воркеры, тормозит), а что касается более легких Nginx и других сервисов, время даунтайма даже в HighLoad решениях может быть меньше секунды.
>Поддерживает через систему оповещений. Завершение приложения - дело рук самого приложения, Оно
>должно грамотно обслужить оставшиеся запросы и транзакции. killall - это извините
>серпом по яйцам всем транзакциям, вам пользователи потом стул вкрутят за
>такое. Ещё преимущества есть у этого "ядра на лету" ?
На сколько я понимаю (не уверена), но транзакции как раз завершатся, так как дамп памяти, после смены ядра, берется с диска.
А еще, есть Xen, KVM, VZ, а у Hyper-V до сих пор (не в релиз-кандидатах) нет даже Live Migration и нормальной кластеризации.
Вот в VZ, с которой я работала, после chkpnt транзакции, полсле восстановления контейнера (даже если он восстанавливается на другом хосте) транзакции завершаются всегда :)
> Которое
>на фиг ни кому не нужно, ибо кластеризация в серверах давно
>есть.
Нет нормальной кластеризации в MS. В том-то и дело. Ее просто нет.
И мантры и заклинания по поводу COM/.NET не помогут создать даже распределенную и отказоустойчивую файлопомойку без привлечения _сторонних_, неоправданно дорогих и железных решений :)
