Re: freebsd network tuning
On 01/12/14 23:55, Михаил Монашёв wrote: Признаюсь, что не заметил каких-то ощутимых ускорений от этого тюнинга, Большая часть тюнинга не для ускорения, а для того, чтобы при достижении определённой нагрузки X сервер не превратился в тыкву, несмотря на то что свободная память ещё есть, а CPU загружен не на 100%. Соответственно нужно использовать утилиты для создания большой нагрузки и смотреть какую максимальную нагрузку сервер может выдержать с тюнингом и без. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Сборка nginx с кастомным openssl
Господа, а нельзя ли добавить в докуметацию вариант сборки с кастомным openssl, как например http://erny-rev.blogspot.ru/2012/11/compile-nginx-with-custom-openssl-in.html на nginx.org не нашел даже --with-openssl Тема очень актуальна для владельцев линуксов типа CentOS 5 и т.п. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Блокировка ботов, заходящих на страницу по IP-адресу. Возможно ли?
Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а видно, что периодически на страничку заходят боты не по доменному имени, а по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке по IP-адресу - чтоб только по доменному имени заходили, а по IP блокировались файрволом. С уважением, Геннадий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246311,246311#msg-246311 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Блокировка ботов, заходящих на страницу по IP-адресу. Возможно ли?
13 января 2014 г., 13:02 пользователь Sferg nginx-fo...@nginx.us написал:
Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а
видно, что периодически на страничку заходят боты не по доменному имени, а
по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке
по IP-адресу - чтоб только по доменному имени заходили, а по IP
блокировались файрволом.
С уважением, Геннадий.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246311,246311#msg-246311
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Что iptables знает про внутренности http запроса? Ни-че-го.
Можно сделать на уровне nginx. Catch-all для всех некорректных запросов
(без хоста или с неизвестным хостом):
server {
listen 80 default_server;
server_name _;
return 444;
}
Документация - http://nginx.org/en/docs/http/server_names.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Блокировка ботов, заходящих на страницу по IP-адресу. Возможно ли?
Можно попробовать через string # iptables -I INPUT 1 -p tcp --dport 80 -m string --string xxx.xxx.xxx.xxx --algo kmp -j DROP Более подробно https://wiztelsys.com/blog/?p=16 На виртуалке по крайней мере работает 2014/1/13 Sferg nginx-fo...@nginx.us: Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log Nginx'а видно, что периодически на страничку заходят боты не по доменному имени, а по IP-адресу. Возможно ли с помощью iptables ограничить доступ к страничке по IP-адресу - чтоб только по доменному имени заходили, а по IP блокировались файрволом. С уважением, Геннадий. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,246311,246311#msg-246311 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Блокировка ботов, заходящих на страницу по IP-адресу. Возможно ли?
Добрый день.
Всегда интересовал вопрос наличия server_name в указанной конфигурации.
В любом случае, если хост будет не указан или не относится к данному
серверу он попадет в дефолт. Или я чего-то не верно понимаю и
server_name таки тут обязательно должен присутствовать?
13.01.2014 13:39, Alex Vasilenko пишет:
13 января 2014 г., 13:02 пользователь Sferg nginx-fo...@nginx.us
mailto:nginx-fo...@nginx.us написал:
Здравствуйте. Имеется связка Nginx + PHP-FPM + MySQL. В access.log
Nginx'а
видно, что периодически на страничку заходят боты не по доменному
имени, а
по IP-адресу. Возможно ли с помощью iptables ограничить доступ к
страничке
по IP-адресу - чтоб только по доменному имени заходили, а по IP
блокировались файрволом.
С уважением, Геннадий.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246311,246311#msg-246311
___
nginx-ru mailing list
nginx-ru@nginx.org mailto:nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Что iptables знает про внутренности http запроса? Ни-че-го.
Можно сделать на уровне nginx. Catch-all для всех некорректных
запросов (без хоста или с неизвестным хостом):
server {
listen 80 default_server;
server_name _;
return 444;
}
Документация - http://nginx.org/en/docs/http/server_names.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Dmitriy Lyalyuev
http://lyalyuev.info
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_cache_key и fastcgi_cache_key
Hello! On Fri, Jan 10, 2014 at 09:57:21PM +0400, Валентин Бартенев wrote: On Friday 10 January 2014 19:42:18 Maxim Dounin wrote: Hello! On Fri, Jan 10, 2014 at 11:54:22AM +0200, Gena Makhomed wrote: On 09.01.2014 16:33, Maxim Dounin wrote: Смысл значения по умолчанию для proxy_cache_key состоит в том, что идентифицируется тот ресурс, куда осуществялется проксирование. Тем самым, если в разных виртуальных серверах проксирование осуществляется в одно и то же место - будет использован один и тот же элемент кеша. Ситуация, когда все размещенные на одном сервере виртуальные хосты имеют 100% идентичный контент и разные домены практически невозможна. Такая настройка nginx сейчас может появиться только в результате ошибки. Еще дефолтовая настройка nginx на $proxy_host может быть полезной тем, кто грабит корованы, то есть показыват на своем сайте контент, который был получен с других сайтов путем проксирования с кешированием. Например, это может быть отдельный location под общие элементы и/или ssi-инклуды. Именно под такие задачи оно исходно и программировалось, и именно потому и стоят такие значения по умолчанию - запрашиваем с бекенда то, что указано в proxy_pass, и кешируем то, что запрашивали. Просто следует понимать, что задач - больше одной. И хорошее решение для одной задачи - может оказаться плохим для другой. Проблема, на самом деле, в том, что прописанное в конфиге proxy_set_header Host $host существенно меняет суть запроса к бекенду, а значение по умолчанию proxy_cache_key об этом изменении не знает, его надо обучать этому вручную. Возможно, именно с этой стороны и следует подойти к этому вопросу. [..] Лично мне нравится идея привести значение proxy_cache_key по умолчанию к таковому fastcgi_cache_key, т.е. отсутствует и требуется задавать явно. ИМХО это полезно, как с точки зрения понятности конфига, так и с точки зрения унификации между различными upstream-модулями. Нет, я против. В http кешируемость определена достаточно хорошо, и идентификация запрашиваемого документа - это хороший, годный метод кеширования. Заставлять пользователя самостоятельно изобретать ключ кеширования - это негодный с точки зрения удобства использования вариант. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Re[2]: freebsd network tuning
Вот сколько раз встерчал такое - да там фигня в статье, кто так делает, надо так и так, это же очевидно. Вот нет бы, потратить 2 часа своего времени, взять и написать правильную статью с объяснением что и зачем. Нет же, все будут кусаться, колоться, но ... 2014/1/13 Илья Шипицин chipits...@gmail.com: настройка на 10Gb может быть единственным способом. берем, нагружаем 10Gb, смотрим, где узкое место и исправляем (без кунфу по части jmeter/gprof и подобных штук не обойтись) итерируем до достижения нужного эффекта. сайт calomel.org изобилует непонятно на чем основанными рекомендациями, порой такое чувство, что лишь бы побольше накрутить. типичный пример (в стиле calomel.org) : http://habrahabr.ru/post/56497/ взяли, поставили epoll, зачем ? по дефолту был бы epoll и далее по списку без вникания, open_file_cache - это же почти наверняка способ отстрелить себе ногу. хоть одно упоминание о побочных последствиях ? а ведь народ яростно плюсует, копипастит и драгндропит настройки. без мониторинга и профилирования что-то настраивать - это пальцем в небо. 13 января 2014 г., 16:41 пользователь Михаил Монашёв postmas...@softsearch.ru написал: Здравствуйте, Anton. Признаюсь, что не заметил каких-то ощутимых ускорений от этого тюнинга, Большая часть тюнинга не для ускорения, а для того, чтобы при достижении определённой нагрузки X сервер не превратился в тыкву, несмотря на то что свободная память ещё есть, а CPU загружен не на 100%. Соответственно нужно использовать утилиты для создания большой нагрузки и смотреть какую максимальную нагрузку сервер может выдержать с тюнингом и без. Ну сервер и так 600 мегабит отдаёт с настройками, которые Игорь тогда на конфе озвучивал. Думал, что, например, смена Congestion Control Algorithm, как описано тут http://dadv.livejournal.com/176159.html сильно поможет, но даже при больших буферах ничего не меняется. Как я понял, есть два основных вида тюнинга: для быстрой работы сервера и для безопасной работы. Т.е. работаешь с быстрой настройкой, а как начинают досить, переключаешься на безопасную. -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Re[2]: freebsd network tuning
ок :-) договорились 13 января 2014 г., 19:15 пользователь Alex Domoradov alex@gmail.com написал: Вот сколько раз встерчал такое - да там фигня в статье, кто так делает, надо так и так, это же очевидно. Вот нет бы, потратить 2 часа своего времени, взять и написать правильную статью с объяснением что и зачем. Нет же, все будут кусаться, колоться, но ... 2014/1/13 Илья Шипицин chipits...@gmail.com: настройка на 10Gb может быть единственным способом. берем, нагружаем 10Gb, смотрим, где узкое место и исправляем (без кунфу по части jmeter/gprof и подобных штук не обойтись) итерируем до достижения нужного эффекта. сайт calomel.org изобилует непонятно на чем основанными рекомендациями, порой такое чувство, что лишь бы побольше накрутить. типичный пример (в стиле calomel.org) : http://habrahabr.ru/post/56497/ взяли, поставили epoll, зачем ? по дефолту был бы epoll и далее по списку без вникания, open_file_cache - это же почти наверняка способ отстрелить себе ногу. хоть одно упоминание о побочных последствиях ? а ведь народ яростно плюсует, копипастит и драгндропит настройки. без мониторинга и профилирования что-то настраивать - это пальцем в небо. 13 января 2014 г., 16:41 пользователь Михаил Монашёв postmas...@softsearch.ru написал: Здравствуйте, Anton. Признаюсь, что не заметил каких-то ощутимых ускорений от этого тюнинга, Большая часть тюнинга не для ускорения, а для того, чтобы при достижении определённой нагрузки X сервер не превратился в тыкву, несмотря на то что свободная память ещё есть, а CPU загружен не на 100%. Соответственно нужно использовать утилиты для создания большой нагрузки и смотреть какую максимальную нагрузку сервер может выдержать с тюнингом и без. Ну сервер и так 600 мегабит отдаёт с настройками, которые Игорь тогда на конфе озвучивал. Думал, что, например, смена Congestion Control Algorithm, как описано тут http://dadv.livejournal.com/176159.html сильно поможет, но даже при больших буферах ничего не меняется. Как я понял, есть два основных вида тюнинга: для быстрой работы сервера и для безопасной работы. Т.е. работаешь с быстрой настройкой, а как начинают досить, переключаешься на безопасную. -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Если сделать еще одну запись А на IP второго провайдера, но при этом этот второй провайдер будет отключен как будет работать соединение с веб сервером и севером вообще? Как вообще клиенты будут работать нормально или же если не предсказуемо ? Половина попыток подключиться будет обламываться по таймауту. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
13.01.2014 20:41, Daniel Podolsky пишет: Если сделать еще одну запись А на IP второго провайдера, но при этом этот второй провайдер будет отключен как будет работать соединение с веб сервером и севером вообще? Как вообще клиенты будут работать нормально или же если не предсказуемо ? Половина попыток подключиться будет обламываться по таймауту. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru т.е. это не дело для продакшена ? в итоге клиенты будут не довольны ? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Половина попыток подключиться будет обламываться по таймауту. в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
On 01/13/14 20:30, VovansystemS wrote: Кстати, готовые решения есть? А то постоянно приходиться самому че-то сочинять. есть route 53 амазона, он умеет проверять на доступность и изменять днс записи по соответствующим правилам. Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не столько много зарабатываем ;). Едва ли это можно назвать фэловер при ненулевом TTL. да :( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сборка nginx с кастомным openssl
Про --help незнал, каюсь, однако же без хака # edit auto/lib/openssl/conf manually or use sed sed -i -e 's|\.openssl/||' auto/lib/openssl/conf собрать у меня не удалось On 13.01.14, 18:11, Alex Domoradov wrote: в 1.0.15 точно есть # ./configure --help | grep openssl --with-openssl=DIR set path to OpenSSL library sources --with-openssl-opt=OPTIONS set additional build options for OpenSSL 2014/1/13 Kostya Alexandrov koti...@mail.ru: Господа, а нельзя ли добавить в докуметацию вариант сборки с кастомным openssl, как например http://erny-rev.blogspot.ru/2012/11/compile-nginx-with-custom-openssl-in.html на nginx.org не нашел даже --with-openssl Тема очень актуальна для владельцев линуксов типа CentOS 5 и т.п. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Отдача больших файлов
Приветствую! Собственно, планируется сабж в ближайшем будущем. Размеры файлов - от 1 до 8-10 ГиБ, 400-500 сессий до 2-3 коннектов на сессию, траф - 4-5 ГБит/сек. Последние два параметра в перспективе могут вырасти ориентировочно до двух раз. Ось - FreeBSD, ФС - ZFS. Есть ли общие рекомендации настройки nginx для подобных конфигураций? Размер/кол-во буферов, метод отдачи файлов и т.п. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Отдача больших файлов
13 января 2014 г., 23:36 пользователь Михаил Монашёв postmas...@softsearch.ru написал: Вот тут об этом хорошо и подробно написано: http://goo.gl/Szvbiy Очень остроумно. Кстати, Вы забыли указать в запросе ещё два слова - ОС и ФС. Но боюсь, что меня больше интересует практический опыт людей, присутствующих в данной рассылке, именно поэтому письмо и было написано (что нисколько не отменяет поисковых запросов). ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re[2]: Отдача больших файлов
Здравствуйте, Anton. Вот тут об этом хорошо и подробно написано: http://goo.gl/Szvbiy Очень остроумно. За 4 минуты 6 переходов, однако! :-) Кстати, Вы забыли указать в запросе ещё два слова - ОС и ФС. Но боюсь, что меня больше интересует практический опыт людей, присутствующих в данной рассылке, именно поэтому письмо и было написано (что нисколько не отменяет поисковых запросов). А все, кто писал ранее, - теоретики, не стоящие Вашего внимания. -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re[2]: Отдача больших файлов
Здравствуйте, Anton. Да, КС site: я вижу. Забыл уточнить, что интересует более новый опыт, нежели 2009-го года, коих результатов больше всего. ;) Всё с точностью до наоборот. Раньше и зима была больше на зиму похожа. И девки краше. Особенно в 2009-ом. А сейчас уже всё не то, что раньше. -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Re[2]: Отдача больших файлов
13 января 2014 г., 23:46 пользователь Михаил Монашёв postmas...@softsearch.ru написал: А все, кто писал ранее, - теоретики, не стоящие Вашего внимания. За 5 лет разве ничего не изменилось ни во FreeBSD, ни в nginx? Кстати, если по указанной ссылке добавить дату с 01.01.2013, то релевантных результатов как-то и нет... Впрочем, это лишь переливание из. Писать текст в строку поиска я умею и так, а нового опыта (хотя бы за прошедший год) Вами не предложено. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сборка nginx с кастомным openssl
On Tuesday 14 January 2014 01:17:25 Kostya Alexandrov wrote: Про --help незнал, каюсь, однако же без хака # edit auto/lib/openssl/conf manually or use sed sed -i -e 's|\.openssl/||' auto/lib/openssl/conf собрать у меня не удалось [..] А не нужно было следовать приведенному руководству и собирать OpenSSL самостоятельно. Всё, что было нужно - это скачать архив с исходниками OpenSSL, распаковать, и просто указать в --with-openssl=DIR вместо DIR путь к исходникам. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сборка nginx с кастомным openssl
Валентин, возможно я не прав, но вот если бы я это увидел в доке к ssl модулю, то флейма и дурных вопросов не задавал бы, заодно бы час-другой сэкономил бы себе, думаю человек, написавший то руководство так же как и я бодался с тем чтоб собрать nginx с кастомным openssl. Скажем так, для себя я проблему решил, и мне кажется, что будущим покалениям было бы неплохо получить эти сокральные знания без гугла и десятка дурных и вредных советов, типа ставит пакеты от centos 6.5 с нодепс и тп. Решайте сами стоит ли добавить пару строк доки или нет. On 14.01.14, 2:51, Валентин Бартенев wrote: On Tuesday 14 January 2014 01:17:25 Kostya Alexandrov wrote: Про --help незнал, каюсь, однако же без хака # edit auto/lib/openssl/conf manually or use sed sed -i -e 's|\.openssl/||' auto/lib/openssl/conf собрать у меня не удалось [..] А не нужно было следовать приведенному руководству и собирать OpenSSL самостоятельно. Всё, что было нужно - это скачать архив с исходниками OpenSSL, распаковать, и просто указать в --with-openssl=DIR вместо DIR путь к исходникам. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
13.01.2014 21:46, VovansystemS пишет: Половина попыток подключиться будет обламываться по таймауту. в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Странно что уже много лет. Видимо это кому то нужно ( Всмысле существования и процветания бот нет сетей. Если я конечно правильно понимаю этот вопрос. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
13.01.2014 22:22, Валентин Бартенев пишет: On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: On 01/13/14 19:46, VovansystemS wrote: Половина попыток подключиться будет обламываться по таймауту. в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. Естественно NS сервер должен быть где-то в ДЦ. [..] Едва ли это можно назвать фэловер при ненулевом TTL. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru А нулевой TTL используется? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
14.01.2014 08:17, Лапочкин Константин пишет: Можно организовать схему, когда живость сайта будет проверять сам ДНС. Описание http://habrahabr.ru/post/177145/ -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Sergey Kobzar Sent: Tuesday, January 14, 2014 12:57 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? On 01/13/14 20:30, VovansystemS wrote: Кстати, готовые решения есть? А то постоянно приходиться самому че-то сочинять. есть route 53 амазона, он умеет проверять на доступность и изменять днс записи по соответствующим правилам. Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не столько много зарабатываем ;). Едва ли это можно назвать фэловер при ненулевом TTL. да :( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо. Очень хорошая подсказка. Только вопрос: Ведь здесь описывается несколько дата центров. В моем варианте - это не вариант. У меня просто двай провайдера и серверная в одном здании. В таком случае как лучше организовать доступ к сайту компании, при наличии двух провайдеров? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
RE: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
У вас даже всё проще. В случае с 2-я датацентрами, вам надо организовывать репликацию. В вашем случае - нет. Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns сервер и на запрос site.com отдавал свой белый ип. Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. Остальное по статье. Если днс провайдера видит, что dns сервер на x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут на y.y.y.y. -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Vladimir Skubriev Sent: Tuesday, January 14, 2014 10:43 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? 14.01.2014 08:17, Лапочкин Константин пишет: Можно организовать схему, когда живость сайта будет проверять сам ДНС. Описание http://habrahabr.ru/post/177145/ -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Sergey Kobzar Sent: Tuesday, January 14, 2014 12:57 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? On 01/13/14 20:30, VovansystemS wrote: Кстати, готовые решения есть? А то постоянно приходиться самому че-то сочинять. есть route 53 амазона, он умеет проверять на доступность и изменять днс записи по соответствующим правилам. Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не столько много зарабатываем ;). Едва ли это можно назвать фэловер при ненулевом TTL. да :( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо. Очень хорошая подсказка. Только вопрос: Ведь здесь описывается несколько дата центров. В моем варианте - это не вариант. У меня просто двай провайдера и серверная в одном здании. В таком случае как лучше организовать доступ к сайту компании, при наличии двух провайдеров? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
На что только не идут люди, лишь бы не покупать себе впс для хостинга 14 января 2014 г., 9:46 пользователь Лапочкин Константин kost...@gmail.comнаписал: Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность сайта. В вашем случае, если уже есть скрипт, который осуществляет переключение провайдера, допилить его на изменение А записи на удалённом (не вашем) dns сервере. С условием выставления минимального ttl для этой записи что-то может получиться. Однако, в этом случае ещё одной точкой отказа станет ваш скрипт. Ну, про Amazon Route 53 уже сказали. -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Vladimir Skubriev Sent: Tuesday, January 14, 2014 11:21 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? 14.01.2014 09:11, Лапочкин Константин пишет: У вас даже всё проще. В случае с 2-я датацентрами, вам надо организовывать репликацию. В вашем случае - нет. Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns сервер и на запрос site.com отдавал свой белый ип. Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. Остальное по статье. Если днс провайдера видит, что dns сервер на x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут на y.y.y.y. Все оказывается так просто - но не в моей ситуации (Увы)! За раскладку большое спасибо. Все по полочкам. Большая благодарность. Только можно еще один вопрос. Дело в том, что моё начальство программисты и угодить им - практически не возможно. По крайней мере сколько я себя знаю. На данное предложение - они обязательно скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и этот вариант скорее всего отметут. Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер в текущий момент работал - работал сайт. Т.е. требования одновременной работы нет. Хотя бы через одного провайдера бы работал - и этого достаточно. За самодеятельсность - серьезная вздрючка. Поэтому возникает вопрос какие еще могут быть альтернативные решения в такой ситуации. Я с таким еще не сталкивался. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR Artem V. Vasiliev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сборка nginx с кастомным openssl
Про --help незнал, каюсь очень странно, просто когда человек начинает собирать из исходников с кастомными ключами, то он, как правило, четко знает - что он делает, для чего и что он хочет получить в итоге :) 2014/1/14 Kostya Alexandrov koti...@mail.ru: Валентин, возможно я не прав, но вот если бы я это увидел в доке к ssl модулю, то флейма и дурных вопросов не задавал бы, заодно бы час-другой сэкономил бы себе, думаю человек, написавший то руководство так же как и я бодался с тем чтоб собрать nginx с кастомным openssl. Скажем так, для себя я проблему решил, и мне кажется, что будущим покалениям было бы неплохо получить эти сокральные знания без гугла и десятка дурных и вредных советов, типа ставит пакеты от centos 6.5 с нодепс и тп. Решайте сами стоит ли добавить пару строк доки или нет. On 14.01.14, 2:51, Валентин Бартенев wrote: On Tuesday 14 January 2014 01:17:25 Kostya Alexandrov wrote: Про --help незнал, каюсь, однако же без хака # edit auto/lib/openssl/conf manually or use sed sed -i -e 's|\.openssl/||' auto/lib/openssl/conf собрать у меня не удалось [..] А не нужно было следовать приведенному руководству и собирать OpenSSL самостоятельно. Всё, что было нужно - это скачать архив с исходниками OpenSSL, распаковать, и просто указать в --with-openssl=DIR вместо DIR путь к исходникам. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Ну вообще то ни один ДЦ/Хостинг не гарантирует вам 100% Uptime, хотя многие и пишут, но это маркетинг. 2014/1/14 Артем Васильев artem.vasil...@gmail.com: На что только не идут люди, лишь бы не покупать себе впс для хостинга 14 января 2014 г., 9:46 пользователь Лапочкин Константин kost...@gmail.com написал: Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность сайта. В вашем случае, если уже есть скрипт, который осуществляет переключение провайдера, допилить его на изменение А записи на удалённом (не вашем) dns сервере. С условием выставления минимального ttl для этой записи что-то может получиться. Однако, в этом случае ещё одной точкой отказа станет ваш скрипт. Ну, про Amazon Route 53 уже сказали. -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Vladimir Skubriev Sent: Tuesday, January 14, 2014 11:21 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? 14.01.2014 09:11, Лапочкин Константин пишет: У вас даже всё проще. В случае с 2-я датацентрами, вам надо организовывать репликацию. В вашем случае - нет. Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns сервер и на запрос site.com отдавал свой белый ип. Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. Остальное по статье. Если днс провайдера видит, что dns сервер на x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут на y.y.y.y. Все оказывается так просто - но не в моей ситуации (Увы)! За раскладку большое спасибо. Все по полочкам. Большая благодарность. Только можно еще один вопрос. Дело в том, что моё начальство программисты и угодить им - практически не возможно. По крайней мере сколько я себя знаю. На данное предложение - они обязательно скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и этот вариант скорее всего отметут. Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер в текущий момент работал - работал сайт. Т.е. требования одновременной работы нет. Хотя бы через одного провайдера бы работал - и этого достаточно. За самодеятельсность - серьезная вздрючка. Поэтому возникает вопрос какие еще могут быть альтернативные решения в такой ситуации. Я с таким еще не сталкивался. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR Artem V. Vasiliev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
Любой ДЦ/хостинг априори надежнее чем такое HA-решение на основе местных пионер-телекомов. И избавляет от подобных вопросов и прочей ненужной головной боли. 14 января 2014 г., 11:21 пользователь Alex Domoradov alex@gmail.comнаписал: Ну вообще то ни один ДЦ/Хостинг не гарантирует вам 100% Uptime, хотя многие и пишут, но это маркетинг. 2014/1/14 Артем Васильев artem.vasil...@gmail.com: На что только не идут люди, лишь бы не покупать себе впс для хостинга 14 января 2014 г., 9:46 пользователь Лапочкин Константин kost...@gmail.com написал: Да, появляется ещё один сервис, ДНС, от которого зависит работоспособность сайта. В вашем случае, если уже есть скрипт, который осуществляет переключение провайдера, допилить его на изменение А записи на удалённом (не вашем) dns сервере. С условием выставления минимального ttl для этой записи что-то может получиться. Однако, в этом случае ещё одной точкой отказа станет ваш скрипт. Ну, про Amazon Route 53 уже сказали. -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Vladimir Skubriev Sent: Tuesday, January 14, 2014 11:21 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? 14.01.2014 09:11, Лапочкин Константин пишет: У вас даже всё проще. В случае с 2-я датацентрами, вам надо организовывать репликацию. В вашем случае - нет. Вам надо организовать, что бы на каждом входящем интерфейсе слушал dns сервер и на запрос site.com отдавал свой белый ип. Допустим, у вас 2 белых адреса x.x.x.x и y.y.y.y Если через днс спросить у x.x.x.x адрес сайта site.com он ответит x.x.x.x. Если через днс спросить у y.y.y.y адрес сайта site.com он ответит y.y.y.y. Остальное по статье. Если днс провайдера видит, что dns сервер на x.x.x.x не отвечает, он спросит адрес у второго сервера и клиенты пойдут на y.y.y.y. Все оказывается так просто - но не в моей ситуации (Увы)! За раскладку большое спасибо. Все по полочкам. Большая благодарность. Только можно еще один вопрос. Дело в том, что моё начальство программисты и угодить им - практически не возможно. По крайней мере сколько я себя знаю. На данное предложение - они обязательно скажут, что держать свой DNS сервер для зоны нашего сайта - не надежно и этот вариант скорее всего отметут. Дело вот в чем, они хотят, чтобы в не зависимости от того, какой провайдер в текущий момент работал - работал сайт. Т.е. требования одновременной работы нет. Хотя бы через одного провайдера бы работал - и этого достаточно. За самодеятельсность - серьезная вздрючка. Поэтому возникает вопрос какие еще могут быть альтернативные решения в такой ситуации. Я с таким еще не сталкивался. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR Artem V. Vasiliev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- WBR Artem V. Vasiliev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
