|
Привет всем.
В продолжение моего предыдущего поста. (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
| 
