Связка nginx-memcached и упавший узел с memcached ...

[Eugene Batogov]

Привет всем.
В продолжение моего предыдущего поста. (http://forum.nginx.org/read.php?21,204258)
--------------
Окружение :
OS: CentOs 5.5 x86-64
Hardware: IBM System x3650
nginx -V:
nginx -V
nginx: nginx version: nginx/1.0.4
nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
nginx: TLS SNI support disabled
nginx: configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-
path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-
path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --with-
http_secure_link_module --with-http_random_index_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --
with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_perl_module --with-debug --with-mail --
with-mail_ssl_module --with-cc-opt='-O2 -g -m64 -mtune=generic' --with-ipv6 --add-module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx-upstream-fair --add-
module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx-upload-progress-module --add-module=/usr/src/redhat/BUILD/nginx-1.0.4/mod_zip-1.1.6 --add-
module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx_upload_module-2.2.0 --add-module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx_mod_h264_streaming-2.2.7 --add-
module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx-push-stream-module --add-module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx_upstream_hash-0.3.1 --add-
module=/usr/src/redhat/BUILD/nginx-1.0.4/ngx_http_consistent_hash --add-module=/usr/src/redhat/BUILD/nginx-1.0.4/nginx-memcached-hash-pass --add-
module=/usr/src/redhat/BUILD/nginx-1.0.4/ngx_http_upstream_keepalive-2ee28064a04a
.....
-----------

У меня есть два узла с memcached, заключенные в upstream:
...
 upstream  memcached_cluster  {        
    server   192.168.1.1:11211;
    server   192.168.1.2:11211;
    hash   	 $uri;
    hash_again  1000;          # default 0    
   }
...

В секции http{...} я задаю следующие connection timeouts:
...
    #timeouts
    keepalive_timeout      45 45;
    client_header_timeout  45;
    client_body_timeout    45;
    send_timeout           45;
    reset_timedout_connection on;
    
    memcached_connect_timeout 3;
    memcached_read_timeout 20;
    memcached_send_timeout 20;    
    #timeouts end
...

Далее запускаю нагрузочный тест, который создает нагрузку ~ 1000 запросов в секунду.
Как видно из параметров:
    hash   	 $uri;
    hash_again  1000;          # default 0  

я использую ngx_http_upstream_hash_module
для правильного выбора узла с кэшем.
Этот модуль использует алгоритм CRC32.

Далее, после выхода системы в рабочий режим под нагрузкой, я эмулирую падение одного (192.168.1.2) узла с memcached, выполняя на нем команду: shutdown.
В результате nginx продолжает его считать рабочим, и все запросы, которые раньше шли на  192.168.1.2 так и пытаются туда идти, 
только теперь они ждут таймаут memcached_connect_timeout и потом проваливаются на backend.

Почему nginx в случае таймаута не может при каком-либо условии (например узла физически нет минуту )  просто выключать его из списка и 
производить rehash? 
А по прошествии, например часа, снова пробовать подсоединиться к узлу?
То есть, другими словами, очень необходима функциональность по динамическому распознаванию упавшего узла, и выключению его из списка кэш-серверов.
--
Далее попробовал модуль М.Дунина: ngx_http_upstream_keepalive и перенастроил upstream следующим образом:
...
 upstream  memcached_cluster  {        
    server   192.168.1.1:11211;
    server   192.168.1.2:11211;
    hash   	 $uri;
    hash_again  1000;          # default 0    
    keepalive 1024;
   }
...
Все работает отлично, если все ноды с кэшем исправны. Но в случае падения одного из них, ситуация аналогична описанной выше :(.






-- 
Best Regards, Eugene Batogov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20110607/c3fec2f9/attachment-0001.html>