Аналогичная проблема была (где-то год-полтора назад). Пытался посылать на abuse, и не один раз. Ответ всегда один и тот же: «если ваше письмо не дошло, пошлите письмо от адреса отправителя на ящик abuse@corp.mail.ru».
Ну так в том-то и дело, что iptables'ом точно также можно менять правила на ходу. И нормальные правила тоже позволяют не прерывать текущие подключения.
Или это что-то «мы тут сваяли клевую штуку, т.к. нам лень было разбираться с iptables»?
А вот кто подскажет, зачем нужен этот Dynamic Firewall?
То, что нашлось
«Most Linux systems use IP tables type firewalls and the problem is that if you want to make a change to the firewall, it's hard to modify on the fly without reloading the entire firewall»
Какой MySQL-proxy использовать собираетесь?
Какое-то время назад пытался искать, что пишут про прокси. Родной mysql-proxy довольно сильно страдает по производительности, т.е. с ним проблема может быть уже не с самим сервером БД, а именно с проксированием.
Другие прокси не отличались стабильностью.
Если дела сейчас обстоят также, то может есть смысл не включать прокси, а просто менять в конфиге базу, с которой работает веб-сервис. Тем более, что в таком случае mysql на сервере БД будет нагружен поменьше.
Плюс стоит производить анализ запросов на веб. Если там идет такое же большое количество запросов, то переключать обратно на свой сервер не следует, иначе получится передергивание туда-сюда серверов (нагрузка снизилась -> переключили на default -> нагрузка повысилась -> переключили на cloud -> нагрузка снизилась ->… и так по кругу).
А откуда возьмется простаивающая машина?
Есть настоящий сервер, который либо работает как сервер (норм режим), либо перекидывает (проксирует) запросы на второй сервер.
Второй сервер — это сервер Amazon, у которого покупается *время* работы, т.е. включил его — платишь денежки, выключил — не платишь.
Мнда, сей продукт Parallels доставил и доставляет немало хлопот. Начиная от корявых зависимостей в пакетах и привязанных к ним дырам в безопасности, что подкрепляется тяжелым их исправлением, и заканчивая грядущим обновлением, в успехе которого не уверен никто. Предыдущий опыт обновления был очень печальный.
А уж по выбору хостинговой панели можно судить и о самом хостере :)
Скриптик — это ldapclient? Можешь тогда кокретную команду указать? Ибо у меня id user выдает данные, а вот залогиниться user не может. Хотя от рута su — user работает.
Количество пользователей, к сожалению, не подскажу. Могу сказать, что в час на каждый из 3х DNS сыпалось около 50тыс запросов (старая поддержка *очень* любила прописывать DNS вручную).
По поводу звонков — с учетом того, что переключались пользователи на это перенаправление отдельными диапазонами, а не все скопом, нагрузка на поддержку не была высокой. По этому поводу, вроде бы, где-то около 10-15 звонков в час — не всем помогали инструкции :)
dpkg -i2. http_dav_module даже в 0.6.32 есть, зачем его перекомпиливать?
Или это что-то «мы тут сваяли клевую штуку, т.к. нам лень было разбираться с iptables»?
То, что нашлось
вообще какой-то бред…
> Об этой 64-ядерной машине
А еще интереснее — как будут поступать с ботнетами.
Какое-то время назад пытался искать, что пишут про прокси. Родной mysql-proxy довольно сильно страдает по производительности, т.е. с ним проблема может быть уже не с самим сервером БД, а именно с проксированием.
Другие прокси не отличались стабильностью.
Если дела сейчас обстоят также, то может есть смысл не включать прокси, а просто менять в конфиге базу, с которой работает веб-сервис. Тем более, что в таком случае mysql на сервере БД будет нагружен поменьше.
Плюс стоит производить анализ запросов на веб. Если там идет такое же большое количество запросов, то переключать обратно на свой сервер не следует, иначе получится передергивание туда-сюда серверов (нагрузка снизилась -> переключили на default -> нагрузка повысилась -> переключили на cloud -> нагрузка снизилась ->… и так по кругу).
Есть настоящий сервер, который либо работает как сервер (норм режим), либо перекидывает (проксирует) запросы на второй сервер.
Второй сервер — это сервер Amazon, у которого покупается *время* работы, т.е. включил его — платишь денежки, выключил — не платишь.
А уж по выбору хостинговой панели можно судить и о самом хостере :)
У меня некоторые графики как раз начинали рисоваться после того, как запустишь поллер вручную :)
Я думаю, в CentOS'е есть спец утилита для данных операций
По поводу звонков — с учетом того, что переключались пользователи на это перенаправление отдельными диапазонами, а не все скопом, нагрузка на поддержку не была высокой. По этому поводу, вроде бы, где-то около 10-15 звонков в час — не всем помогали инструкции :)
Тем не менее, подумать мне немножко пришлось.