Настройка FreeBSD, Linux, cisco и etc систем, открытых технологий таких как: NetGraph, dhcp, ipfw, shell, ssh и etc.

Игорь Сысоев: маштабируемая конфигурация nginx

Опубликовано admin в Пнд, 11/04/2011 - 10:14

Видео с доклада Игоря Сысоева на конференции http://devpoint.ru/.
В ней не будет рассказов о проксировании запросов или высоких нагрузках, автор расскажет как правильно писать конфиги для nginx.
Вначале сильно волнуется, но потом довольно быстро успокаивается ;) Читать далее

( categories: )

apache+nginx+gzip_static+yuicompressor

Опубликовано admin в Пнд, 11/04/2011 - 10:03
В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.
Читать далее
( categories: )

Ускоряем Drupal: Pressflow + Nginx + Varnish

Опубликовано admin в Пнд, 11/04/2011 - 09:51
Данная статья достаточно подробно показывает, как можно перейти на разработку сайтов Друпал с серьезной стрессоустойчивостью и возможностью обрабатывать большой трафик.

Это мой первый опыт подобной настройки, но как будет далее видно из статистики достаточно удачно справляющийся со своей основной задачей — ускорением работы сайта. Интересно будет услышать и увидеть настройки, дополнительные материалы от всех кто сталкивался с подобными задачами, так как в рунете пока еще мало свободной и качественной информации по этой теме относительно системы Друпал.

Довольно долго для разработки я использовал связку Drupal + Nginx с настройками сервера по умолчанию:

server {
listen 62.xxx.xx.xx:80;
server_name mysite.com www.mysite.com;
rewrite>^(/manager/.*)$>https://$host$1>permanent;
location ~* ^/(webstat/|awstats|webmail/|myadmin/|manimg/) {
proxy_pass 62.xxx.xx.xx:8080;
proxy_redirect mysite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location / {
proxy_pass mysite.com:8080;
proxy_redirect mysite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
root /home/pathto/drupal613;
access_log /home/httpd-logs/mysite.com.access.log;
error_page 404 = @fallback;
}
location @fallback {
proxy_pass 62.xxx.xx.xx:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}


Читать далее
( categories: )

Подводные камни при использовании кэширования в nginx

Опубликовано admin в Пнд, 11/04/2011 - 09:31

В web-сервер и reverse-proxy nginx (http://sysoev.ru/nginx/docs/) встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

Лирическое отступление 
Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*, а также внесите изменения в следующие директивы (чтобы уменьшить объем кэша):
proxy_cache_key "$request_method|$host|$request_uri";
proxy_set_header  If-Modified-Since  "";
proxy_set_header  If-None-Match      "";
Приведенный вариант работает во всех версиях nginx, начиная с 0.7.x (хотя в 0.8.31 и старше его можно упростить).
Читать далее

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о "высокой нагрузке". Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

( categories: )

История развития и оптимизаций одного высоконагруженного ресурса

Опубликовано admin в Пнд, 11/04/2011 - 09:09

Введение

Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP (http://ru.wikipedia.org/wiki/LAMP) проект. Сайт, на котором генераторами контента являлись обычные пользователи.
* К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.

Как обычно бывает с ресурсами, набирающими популярность, железки на которых все крутится, перестают справляться. Ресурс стоял на стареньком двухпроцессорном сервере, на котором крутились практически все сервисы для пользователей. В то время начальство не воспринимало ресурс как нечто стоящее вложений, поэтому, к моему сожалению (а позже – счастью), денег под новую железку мне не выделяли.
Читать далее
( categories: )

Siege — утилита для нагрузочного тестирования веб-серверов

Опубликовано admin в Пнд, 11/04/2011 - 08:45
Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

Читать далее
( categories: )

Cisco: ограничение скорости транзитного вилана

Опубликовано admin в Чт, 24/03/2011 - 17:25
Часто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают ingress policing на физическом интерфейсе, но если нужно ограничить не весь трафик из интерфейса, а отдельные виланы из транкового порта, всё становится сложнее. Особенно, если скорость должна быть ограничена не по сумме всех направлений вилана, а в каждую сторону независимо (а обычно оно именно так). Тем не менее, задача решается как на 3560 (3550, 3750, 3560-E и т.п.), так и на 6500.
Читать далее
( categories: )

Защищаем Apache от DDOS атак - Часть 1

Опубликовано admin в Чт, 24/03/2011 - 10:40
В 1й части мы будем устанавливать модуль Apache mod-evasive на Debian сервер. Этот модуль отслеживает количество подключений с определенного клиента и блокирует IP адрес на определенное время при превышении лимита.

sudo apt-get install libapache2-mod-evasive


Или берем отсюда:

http://packages.debian.org/lenny/libapache2-mod-evasive
Читать далее
( categories: )

Защищаем Apache от DDOS атак - Часть 2

Опубликовано admin в Чт, 24/03/2011 - 10:33
Собственно, речь пойдет о защите от SYN flood атак:

Очень популярная DoS атака заключается в посылке большого числа SYN пакетов на ваш сервер. При этом установка TCP связи не доводится до конца. Очередь полуоткрытых запросов соединений быстро заполняется, что мешает установке нормальных соединений. Так как соединение не должно быть обязательно завершено, такая атака не требует больших ресурсов от атакующей машины, поэтому её легко реализовать и контролировать.


Определить SYN атаку просто — команда netstat выдает огромный список полуоткрытых подключений:

netstat -n --tcp | grep SYN_RECV
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:1084    SYN_RECV   
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:1228    SYN_RECV   
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:2652    SYN_RECV   
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:3446    SYN_RECV


Можем просто подсчитать количество:

netstat -n --tcp | grep SYN_RECV | wc -l
238

Читать далее
( categories: )

Cisco ISG

Опубликовано admin в Ср, 23/03/2011 - 23:54
Постановка задачи

В небольшом интернет-провайдере отказаться от использования VPN (pptp) для контроля сессий.
Траффик контролировать непосредсвенно на уровне IP. Контроль валидность src-IP осуществляется на уровне сети доступа (DHCP-snooping + ACL), любой клиент который попадает на роутер с ISG имеет верефицированный src-IP.

Требуется поддреживать следующие тарифы:

  1. Volume-Based Prepaid (помегабайтный тариф)
  2. Безлимитные тарифы (ограничение по скорости)
  3. (опционально) Тарифы с ограничением по скорости и времени. (Lagacy-тарифы, которые были предназначены для создания альтернативы диал-ап, пока не реализовано.)

Restrictions for ISG Prepaid Billing Support

Внимание: Volume-monitor работает только с суммарным траффиком. Возможно, это ограничение можно обойти созданием 2-х сервисов на входящий и исходящий траффик, однако я не вижу в этом смысла для себя на данный момент.

Вот цитата с cisco.com

  • ISG volume-based prepaid billing is not supported on the Cisco 10000-PRE2. не важно для меня
  • ISG prepaid billing support can only be applied to traffic flows that have been defined by an ISG traffic class.
  • Quotas are measured in seconds for time and in bytes for volume. There is no way to change the unit of measure. не важно для меня, непонятно кому может быть нужно что то другое
  • The volume quota is for combined upstream and downstream traffic.

Общяя схема работы

Общяя схема работы такова: Биллинг (оригинальная разработка) управляет RADIUS-сервером (FreeRadius), который в свою очередь хранит информацию о пользователях и сервисах в "понятном" для ISG виде. При необходимости что-либо изменить непосредсвенно на маршрутизаторе с ISG (например, изменить текущий тариф, если пользователь поменял себе тариф и хочет наблюдать изменение скорости) биллинг посылает CoA-пакет который вызывает деавторизацию пользователя и потом - повторную авторизацию с новыми параметрами.

Пользователи Volume-Based тарифов перенаправляются на "портал" при исчерпании лимита траффика.Читать далее

( categories: )
RSS-материал