Как стать автором
Обновить
39
0

Пользователь

Отправить сообщение

ARM-рестлинг

Время на прочтение9 мин
Количество просмотров50K


В последнее время всё чаще стали появляться новости о планах по завоеванию серверного рынка системами построенными на ARM-архитектуре. Более того, воплотились в кремнии настоящие серверные ARM-процессоры от Calxeda, а также системы на их основе от Boston Viridis и в скором времени от HP — Moonshot.

Сервера на базе Intel® Atom™ я использую уже 4 года, а вот ARM-ы мне знакомы только с мобильной телефонно-планшетной стороны. На что же он способен, современный ARM-процессор? Сможет ли он конкурировать с Atom-ами? Прямого сравнения на серверном фронте я не нашел, только синтетику на Phoronix. Интересное тестирование было на AnandTech, но там Xeon-ы. Calxeda в своём бенчмарке также сравнивает с Xeon-ами. Мне же было интересно сравнить именно с Atom-ами в связке Linux+NGINX для отдачи статики.
А Вам интересно?
Всего голосов 62: ↑60 и ↓2+58
Комментарии79

Оперативная реакция на DDoS-атаки

Время на прочтение4 мин
Количество просмотров51K
Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)
limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной.

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой
error_page 503 =429 @blacklist;

И соответствующий именованный location
location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт
Читать дальше →
Всего голосов 57: ↑50 и ↓7+43
Комментарии50

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность