proxy_next_upstream + haproxy

Nikolay Grebnev nikolaygrebnev at gmail.com
Thu Nov 29 15:39:21 UTC 2012


Просьба не ругать за криворукость :)

Придется начать из далека.
Картинки у нас хранятся в hbase (не очень много, пока всего чистыми данными
500 гигов). Извлекаются от туда руби с рельсами. Для ускорения процесса был
настроен сквид. Который тупо кешировал все
http://127.0.0.1:8000/show_pictures/........  (он торчал на 8000 порту)
Потом появился локальный сквид на машинке которая раздает 90% траффика.
Этот сквид имел парента - предыдущего сквида. Все было нормально.
Но тут у hetzner-а в DC10 наступил сбой во внутренней маршрутизации. Я с
перепугу тот сервер перезагрузил (кто знал что не надо). Они потом мне
прислали "ну типа незапланированный сбой поэтому предупредить не могли). В
общем, когда все начало работать, то оказалось что картинки раздаются
только с одного диска, и производительнось отдачи зависит тупо от одного
диска. И пока не нарастится кеш в памяти то все страшно тормозит!

Срочно сквиды были переведены в режим sibling (с перепугу было настроено
еще 3 дополнительных сервера под это), Но после этого оказалось что тк урлы
которые к ним идут отличаются от  http://127.0.0.1:8000/ , и, как
следствие, нифига не закешированы.
Haproxy мгновенно спас ситуацию - он висит на 127.0.0.1:8000 и берет из
сквидов именно то что нужно (сквиды переехали на исторический 3128 порт).

Собственно, все.  Возможно сквиды умеют работать в режиме акселератора и не
обращать внимания на название хоста, но я этого быстро не нашел, а нужно
было спасать ситуацию.

2012/11/29 Maxim Dounin <mdounin at mdounin.ru>

> Hello!
>
> On Thu, Nov 29, 2012 at 06:10:00PM +0400, Nikolay Grebnev wrote:
>
> > Спасибо!!!
>
> Пожалуйста.  В качестве ответной любезности - а расскажите pls,
> чего именно в вашем случае в nginx'е не хватает, что приходится за
> ним ставить haproxy?
>
> --
> Maxim Dounin
> http://nginx.com/support.html
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20121129/8731937f/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru