Любой хостинг с ISPmanager.
Наверно, на центосе сетевые скрипты потом поднимали eth0, который уже был добавлен в br0.
venet в OpenVZ и сетевой мост - разные вещи :)
Насколько я помню из извращений с qemu, мост работает при прописывании гейтвея, данного датацентром напрямую в впску без алиасов на самом сервере.
OpenVZ так же поддерживает сеть через мост, это называется veth, хорошо описано в вики и тоже не требует алиаса.
Думаю, на этом можно закрыть глупый спор :)
А еще ispsystem врядли сделает так :)
Если простои сервера некритичны, то можно попробовать дописать эти команды с суффиксом ">> /root/logfile" в /etc/rc.local и из rescue посмотреть, что написалось :)
А KVM есть?
Есть возможность показать после ребута, когда сеть не работает:
ifconfig -a
brctl show
?
Я правда это вчера сделал. Работать только лучше стало после yum reinstall (rpmdb уцелел, так как наст.оящий Одмин должен знать меру - во время нажать Ctrl+C).
Я сегодня на ноуте сделал rm -rf /*
Работает что надо!
Касательно такого подхода Фил Кулин когда-то читал доклад на ХостОбзоре. Если кратко - чем больше мы тормозим использование ресурсов в узких местах, тем больше нагрузки мы получим. Ведь когда мы тормозим приоритет процесса, мы заставляем его выполняться дольше. Это значит, что io будет более размазано по времени (больше долгих seek'ов), что память будет использоваться в несколько раз дольше, чем нужно, будет тратится cpu на переключения и планировщик. В совокупности и плохом случае мы получим засвопвшийся сервер со сдохшими дисками :)
Подобный limiter, по идее, должен уметь не ренайсить процессы в зависимости от нагрузки, а устранять причину этой самой нагрузки - например, отслеживать ботов/посетителей, которые вызывают слишком много нагрузки, и блокировать их. Как вариант - отслеживать наиболее грузящий скрипт или URL и блокировать его. Как более плохой вариант - отслеживать грузящий виртхост и блокировать его. Как еще большее плохой вариант - блокировать всего юзера, правда я не знаю, сколько клиентов останется у такого хостера и имеет ли это смысл на собственном дедике.
Таким образом, я не разделяю высокие нагрузки на прогнозируемые и непрогназируемые. На мой взгляд, есть только "в пределах нормы" и "ненормально высокая".
Аккаунтинг не пытается развести клиента на деньги, а смотрит динамику роста нагрузки в пределах нормы, пытаясь не допустить ненормально высоких нагрузок и пытается гарантировать равенство всех пользователей :) Иными словами, он используется как раз как мониторинг. Я вот аккаунтинг уже год делаю, он уже претерпел три полных переделывания, но все равно не могу понять, что надо считать и как, чтобы видеть и прошлое, и возможное будущее 😮
Ну а rlimit же помогает решать внезапные проблемы, когда под угрозой сама работа сервера, то есть - быстро реагирует на проблему. Лучше уж десяток необработанных запросов, чем тысяча тормозящих.
Кстати, у меня есть подозрения, что по LA считать текущую нагрузку не очень адекватно - ему на пересчет требуется время, которого иногда нет, и он не всегда показывает адекватную нагрузку - все зависит от задач. Есть сервера (при одинаковых физических конфигурациях), которые при LA 50 чувствуют себя нормально, а другие - дохнут уже при >8.
Мониторинг из юзерспейса, на мой взгляд, это вообще глупо. От некритичной периодической нагрузки спасет аккаунтинг, который, помимо всего, устранит ее причину или переведет ее на новый тариф :)
А при критической нагрузке Ваш демон ничего не сможет сделать. Зато rlimit и прочее от нее спасет.
