RSS Записей | RSS Комментариев
Ядоблог - Stay upwind

Архив ‘nginx’ Категории

MongoDB, хранение файлов в базе

февраля 13, 2012 | 5 комментариев

В интернетах бытует мнение, что хранить файлы в БД — школоло. Разрушаем стереотип с Mongo GridFS.

Введение:
MongoDB предоставляет возможность хранить файлы любого размера в Mongo GridFS
Для драйвера PHP — это обычная коллекция, в которой есть поле для хранения бинарных данных.
Бинарные данные в свою очередь разбиваются на чунки(небольшие куски).
Бинарные данные можно извлечь как целиком, так и почунково(это экономит память).

Плюсы хранения данных в БД MongoDB:
MongoDB может хранить миллионы файлов в БД, хранение такого объёма данных в файловой системе может вызвать проблемы(начиная с IO проблем, заканчивая проблемами доступа к данным из разных серверов).
MongoDB реплицирует данные на все сервера, что упрощает доступ к данным на отдельно взятом сервере.
Нет проблем с бекапами и целостностью данных на разных серверах. надёжность обеспечивается MongoDB.
К загруженному файлу можно прикрепить метаданные (описание, комментарии, лайки, и.т.д.)
Т.к. файлы хранятся в чунках — можно работать с любой частью файла.

Минусы:
Быстродействие ниже, чем nginx + файловая истема. Сравним:
nginx + файловая система, получаем 6559.31 операций в секунду
apache + файловая система: получаем 2625.37 операций в секунду
nginx + модуль nginx-gridfs, получаем 1083.88 операций в секунду

Вывод: nginx + fs на высоте, но это решение не даёт масштабируемости и гибкости.
nginx + nginx-gridfs даёт приличные результаты, которые существенно возрастут, при использовании нескольких серверов MongoDB.

Благодарность, http://tokarchuk.ru за тесты.

nginx, в случае отсутвтвия файла запросить апач

января 11, 2012 | 2 комментария

решение:

location / (
    error_page 404 @fallback;
)
 
location @fallback (
    proxy_pass http://backend;
)

В двух словах: эта штуковина позволит на слабом серваке иметь отдачу под 200 страниц в секунду, если правильно настроить бэкенд (кешировать, временно статические страницы в файлуху(ramfs)).

Apache, nginx IAD

nginx, upstream sent too big header while reading response header from upstream, client

августа 26, 2011 | Комментариев нет

subj лечится добавлением в конфиг нгинкса пары строчек в http секцию:
proxy_buffers 8 16k;
proxy_buffer_size 32k;

thanks to: http://phpsuxx.blogspot.com/2009/11/upstream-sent-too-big-header-while.html

Apache, nginx IAD

Как сделать домен доступным через несклько интерфейсов

июля 22, 2011 | 2 комментария

Допустим у нас дома стоит сервер и для надёжности подведено несколько провайдеров. Как сделать доступными сайты этого сервера, если допустим основной провайдер упадёт?

Решение красивое =). смотреть тут:http://www.bloged.org/2009/07/nginx.html

Суть:
1. Берём VDS где-нить в ацко надёжном месте. например тут: TinyVDS
2. Настраиваем на нём проксирование nginx’ом запросов на нужные сайты (можно всех). Об этом я писал тут nginx, Двойное проксирование, реальный IP, только указываем наш mycloud вместо IP как получателя с чем-то вроде max_fails=3 fail_timeout=120
3. Настраиваем nginx на основном сервере, с кучей провайдеров
Наслаждаемся =)

Есть ещё решения? делитесь =)

upd, статья, вдруг сайт удалится:

Простая конфигурация

Допустим, вы разместили ваше приложение на нескольких серверах, пусть это будут три сервера с именами myserv-1.local, myserv-2.local и myserv-3.local, расположенные в вашей локальной сети (конечно же, на самом деле без разницы, где они будут размещаться). Для того, чтобы описать такое «облако» из трёх серверов в Nginx используется опция upstream:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
}

Описанное таким образом «облако» из нескольких upstream-серверов теперь можно использовать в качестве значения параметра proxy_pass, рассмотренного в предыдущей статье. Везде, где Nginx будет наталкиваться на ссылку (в нашем случае — «mySuperCloud»), он будет по алгоритму Round-Robin выбирать следующий сервер и выполнять обратное проксирование к нему и от него. Таким образом, теперь, описывая виртуальный хост, вы можете сослаться на ваше «облако»:

server {
  listen 192.168.0.1:80;
  access_log /var/log/nginx/proxy.log;
  location / {
    proxy_pass http://mycloud;
  }
}

Привязка клиента к серверу

Часто бывает нужно, чтобы один и тот же клиент, начав делать запросы к какому-то определённому серверу, не переключался на другие. Для этого в Nginx предусмотрена опция ip_hash. Если она определена, сервер будет запоминать IP-хеши клиентов и стараться проксировать каждого из них на один и тот же сервер.

upstream mySuperCloud {
  ip_hash;
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
}

Исключение сервера из «облака»

Если какой-то сервер по каким-то причинам вам необходимо отключить, чтобы Nginx не проксировал к нему клиентов, воспользуйетсь опцией down:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local down;
  server myserv-3.local;
}

Определение «веса» сервера

«Вес» сервера, грубо говоря, определяет насколько часто сервер будет использоваться. Например, вес сервера myserv-1.local равен 3, вес myserv-2.local равен 1 и вес myserv-3.local равен 2. В этом случае Nginx проксирует первых трёх клиентов к серверу myserv-1.local, четвёртого — к myserv-2.local, а пятого и шестого — к myserv-2.local, после чего круг начнётся сначала. Для определения веса сервера используется директива weight, значение по умолчанию которой равно единице.

upstream mySuperCloud {
  server myserv-1.local weight=3;
  server myserv-2.local;
  server myserv-3.local weight=2;
}

Автоотключение серверов

Если какой-то из upstream-серверов перестанет отвечать на запросы, то подключение к нему станет невозможным. Nginx в этом случае переключиться на использование следующего сервера из «облака», однако каждый раз будет пытаться подключаться к неработающему серверу, растрачивая время. При помощи директивы max_fails параметра server можно определить максимально-допустимое количество неудачных попыток подключения к upstream-серверу, после чего тот будет считаться нерабочим и запросы к нему прекратятся. По умолчанию значение этого параметра равно единице, то есть после одной неудачной попытки Nginx на определённое время прекратит попытки новых подключений с нерабочему серверу. Это «определённое время» определяется значением опции fail_timeout, по умолчанию равным 10 секундам.

upstream mySuperCloud {
  server myserv-1.local max_fails=3 fail_timeout=120;
  server myserv-2.local;
  server myserv-3.local;
}

Резервные серверы

Под понятием «резервный» в Nginx выступает сервер, который используется тогда, и только тогда, когда все «не резервные» upstream-серверы определены как нерабочие, т. е. не отвечающие на запросы. Резервные серверы отмечаются с помощью директивы backup:

upstream mySuperCloud {
  server myserv-1.local;
  server myserv-2.local;
  server myserv-3.local;
  server backup-server-1.local backup;
  server backup-server-2.local backup;
}

IAD получил эпик фэйл

февраля 8, 2011 | 8 комментариев

Правил конфиги нгинкса и обнаружил, что пропала вся статика напрочь, на всех доменах, кроме того, к которому подвязывал зону РФ.
Вроде обычный конфиг:

----вырезано----
     server
    {
        listen       айпишнег:80;
        server_name  site.ru www.site.ru мухрю.xn--p1ai;
 
        location /
        {
            client_max_body_size 8M;
            client_body_buffer_size 128k;
 
            proxy_pass http://айпишнег:81/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $remote_addr;
            #proxy_set_header X-Forwarded-For $proxy_add_x_forwarder_for;
        }
        location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$
    	{
            root /var/www/site.ru/;
	}
    }
 
    server
    {
        listen       айпишнег:80;
#       server_name  .my;
 
        location /
        {
            client_max_body_size 8M;
            client_body_buffer_size 128k;
 
            proxy_pass http://апача:81/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $remote_addr;
            #proxy_set_header X-Forwarded-For $proxy_add_x_forwarder_for;
        }
        location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$
    	{
            root /var/www/$host/;
		}
    }

но ошибка заключается в том, что если нгинкс не находит правило для полученного запроса, то передаёт запрос первому серверу!

Если в запросе нет заголовка «Host» или же в нём указано имя, неописанное ни в одном сервере, слушающем на адресе и порту, на которые пришёл запрос, то запрос будет обслужен сервером, у которого первым описаны эти адрес и порт.

Об этом нужно помнить.
Решение — поменять блоки server местами

Часто ли вы проверяете на нагрузочное тестирование сайты?

января 11, 2011 | 3 комментария

первый раз осилил многобукаф в названии поста, собственно продолжим.

если вы линупсоид,выполните

ab -c 100 -n 10000 http://мой_сайт.ru/

Эта команда выполнит лёгенький ддос на ваш сайт(10000 запросов суммарно по 100 запросов параллельно) =)
что интересного можно узнать из результата:

Нажать

Нажать

Ну вот, кроме всяких скоростей есть поле failed requests. Это количество ошибок. Если их нет, то хорошо.

Естественно такие данные как ниже вас должны ввергать в неконтроллируемый страх и ужос, как и повёл себя товарищ пилящий =)

Кликабельно

Кликабельно

nginx, Двойное проксирование, реальный IP

июля 27, 2010 | 4 комментария

Порой бывает необходимо сделать цепочку nginx->nginx->apache. При такой структуре маршрутизации теряется реальный IP клиента(пользователя). Предлагаемое решение избавит от этой проблемы. Используйте дополнительную переменную для передачи реального IP.

Основной nginx (первичный):

location / {
proxy_pass http://IP:80; #адрес где стоит второй nginx
proxy_read_timeout 60;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header realip $remote_addr; # сохраним IP посетителя в переменную
}
Второй nginx:

location / {
proxy_pass http://IP:81; #IP:порт с apache
proxy_read_timeout 60;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $http_realip;
proxy_set_header X-Forwarded-For $http_realip;
proxy_set_header realip «»; # удалим переменную
}

Удачного дня.

© 2010 Ядоблог. Все права защишены.
Powered by Лаборатория Яда. Написать администратору