Re: nginx SSL offload в highload проекте

Илья Шипицин chipitsine at gmail.com
Thu Aug 23 07:27:05 UTC 2012


23 августа 2012 г., 13:05 пользователь ShivaS <nginx-forum at nginx.us>написал:

> Илья, огромное спасибо за то, что так подробно ответили и проявили интерес!
> Запуск намечаем на сегодня ;-)
> Ну а теперь подробнее, и в самом конце приведу свой полный конфиг
>
> Илья Шипицин Wrote:
> -------------------------------------------------------
> > 22 августа 2012 г., 2:04 пользователь ShivaS <nginx-forum at nginx.us>
> > написал:
> >
> > > Добрый вечер,
> > >
> > > Возникла интересная возможность применения nginx в очень нагруженном
> > > проекте.
> > >
> > > Мы активно пользуемся Амазонон (ЕС2) и соответственно лоад
> > балансером ELB,
> > > который на данном этапе делает оффлоад на SSL и общается с пуш
> > серверами.
> > > Сервис достаточно большой, и на определенном этапе мы поняли, что
> > ELB
> > > перестал справляться с нагрузкой, да и его вечное отсоединение
> > соединений с
> > > пуш серверами уже надоело.
> > >
> > > Провели тестирование с nginx на одном из серверов в амазоне, которое
> > > показало неплохие результаты, но все уперлось в память.
> > > Значит надо много серверов с большим кол-вом памяти. На удивление,
> > несмотря
> > > на SSL, процессоры вообще не напрягались и LA постоянно оставался <
> > 1, что
> > > дает возможность брать сервера с большим кол-вом памяти, малым
> > кол-во
> > > процессоров и экономить.
> > >
> >
> > LA = Load Average, это показатель, который соответствует количеству
> > процессов, ожидающих ввода-вывода. При высокой дисковой нагрузке,
> > соотвественно упирается в потолок. В случае терминации SSL он и не
> > должен расти больше единицы.
> >
>
> Ну насколько я понимаю LA не обозначает именно дисковые проблемы, а любую
> проблему (и не обязательно проблему) с ожиданием процессоров. При 8
> воркерах
> я и ожидал около 8 в какой-то момент, так как боялся тормозов установки SSL
> сессии и, что SSL поест процессоры без разбору. Но видимо все обошлось и,
> как Вы написали, логично получил <1. Видимо я не до конца осознал всю
> глубину глубин ;-)
>
>
>
> > >
> > > Система: CentOS 6; nginx 1.2.3
> > >
> > > конфиг подправлял в паре мест.
> > > Вот тут:
> > >
> > > listen       *:443 default backlog=4096 so_keepalive=30m::10;
> > >
> > > И еще немного тут:
> > >
> > > worker_processes  8;
> > > worker_rlimit_nofile 204800;
> > >
> > >
> > > events  {
> > >         worker_connections  20000;
> > >         use epoll;
> > >         multi_accept on;
> > >   accept_mutex on;
> > >         }
> > >
> >
> >
> > серьезный момент - сколько запросов делает один клиент ? если
> > несколько (в
> > нашей ситуации в среднем 5), то очень серьезный выигрыш получается за
> > счет
> > keepalive до клиента (у вас он не включен).
> >
> > в SSL очень дорогой хендшейк, он идет на несимметричной криптографии,
> > keepalive позволяет уменьшить количество дорогих хендшейков. реально,
> > CPU
> > падает в разы (если один клиент делает несколько последовательных
> > запросов
> > и они попадают в одну keepalive-сессию)
> >
> >
>
> Запросов может быть очень много. Есть клиенты которые подсоединяются и в
> силу своих крутых интернетов остаются висеть "на связи", а есть такие,
> которые постоянно отваливаются и передподсоединяются. С ними вот и много
> траблов в основном. Речь о мобильниках, точнее смартфонах. Соединение идет
> одно. Это не бразуеры с декстопов, которые любят пооткрывать много чего с
> самого начала.
> Т.е. получается клиент либо подсоединился и висит, ожидая пуша, либо
> отвалился и пробует переподсоединиться, и тогда возможно упадет снова на
> тот
> же сервер, где ему ssl_session_cache и поможет осуществить задуманное в
> краткие сроки ;-)
>
> > >
> > > Стоит ли ставить много воркеров и малое кол-во коннекшенов на каждый
> > или
> > > достаточно один и сразу выставить максимальное кол-во подсоединений?
> > Диски
> > > не задействованы совсем.
> > >
> >
> > один воркер может задействовать одно ядро. если воркеров меньше, чем
> > ядер,
> > то сервер будет недонагружен.
> >
> > с другой стороны, если у вас интенсивно используются механизмы,
> > требующие
> > согласования воркеров между собой  (например limit_req), то может быть
> > оверхед на согласование.
> >
> > трассируйте, смотрите :-)
> >
> >
>
> Нет, ничего такого не используется. Просто SSL оффлоадер с пуш серверами в
> бекенде.
> Я 8 так и оставил, просто думал что может памяти чуть отгрузить, раз
> процессоры недогружены, а каждый воркер берет по сотке МБ.
> Но наверно не стоит.
>
> >
> > > Приведенные выше настройки использовались на сервере с 7ГБ памяти.
> > > каждый воркер берет память, а при 60кб на клиент, даже несколько
> > сотен
> > >
> >
> > версия nginx какая ? недавно пробегал патч (включенный в последние
> > версии),
> > отключающий компрессию на уровне SSL, заметно снижающий потребление
> > памяти.
> >
> >
>
> Я изначально написал, что 1.2.3, но хитро спрятал в конце предложения ;-)
> Т.е. взял самую последнюю стабильную. Да, я читал про отмену сжатия и
> очистку памяти от старых подсоединений. Или что-то около того ...
>
> > > мегабайт при большом кол-ве серверов может дать некоторый выигрыш.
> > >
> > > Использую ssl ciphers AES256-SHA, для относительной надежности и
> > скорости.
> > >
> >
> > современные процессоры умеют AES-NI инструкции, в openssl они есть
> > начиная
> > с 1.0.1 (или чуть раньше ?). мы такое тестили - отвал башки, в
> > продакшен
> > скоро будем запускать. на амазоне - не знаю, там же Xen ? посмотрите
> > на
> > /proc/cpuinfo, светится там AES ?
> >
> >
>
> Вроде как не светится:
> flags           : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2
> ss ht syscall nx lm rep_good aperfmperf unfair_spinlock pni ssse3 cx16
> sse4_1 sse4_2 popcnt hypervisor lahf_lm dts
>
> На самом деле я взял AES256-SHA еще и потому, что он используется на самом
> балансере амазона (ELB), т.е. хотел сделать идентичное с нгинкс для более
> четкого сравнения.
>
> > >
> > > стоит ли ставить OpenSSL 1.0.1? ECDHE не пользуем, да и тормознутый
> > он
> > > (судя
> > > по бенчмаркам, которые мы гоняли) и в скорости обработки
> > подсоединений и в
> > > объеме потребляемой памяти. Кроме этого, никаких преимуществ особо
> > не нашел
> > > в 1.0.1
> > >
> >
> > в 1.0.1 есть аппаратное ускорение AES.
> >
> > ECDHE - не более тормознутый, он быстрее за счет того, что
> > эллиптическая
> > криптография обеспечивает сопоставимую сложность при меньших ключах.
> > вы
> > случайно не такого же размера ключи выбирали ?
>
> Что-то вот тут я не понял. Сертификат 2048 bit, это Вы имели в виду?
> Остальное я ничего не выбирал...ну или не совсем понимаю вопроса.
>

навскидку, на эллиптических кривых длину ключа можно делить на три и будет
такая же криптографическая сложность, как для традиционной криптографии.
если и там и там делать по 2048, то, конечно, ECDHE втупит на тестах :-)


>
> >
> > у ECDHE минус в том, что он пока не очень поддерживается на стороне
> > клиента. но не в производительности.
> >
> >
>
> Я еще читал про патч от Гугла который это дело разгоняет нехило, ЕСС, но
> вроде там какие-то траблы с лицензией, только в определенных страннах
> использовать и т.д..
> Я в принципе пока и не рискую этим пользоваться, потестировал, посмотрел,
> память съелась ну и решил сделать идентично с ELB
> Основная проблема в этих вечно отваливающихся клиентах и ELB таймаутах.
> Таймауты то решиться должны вроде, а вот с отваливанием клиентов посмотрим,
> когда будет продакшен. iDevices и Андроиды работают без этого сервиса,
> напрямую TCP. А вот для всех остальных терминация сервиса идет по https,
> возможно не везде я что-то правильно выбрал и не все девайсы индо-китая
> могут поддержать то, что я им навязываю. Ну и BB и Win7 phone тоже сюда,
> хотя они четко работают и не отваливаются.
>
> >
> > > Может, там что-то и подкручено, но меня интересует в основном
> > потребление
> > > памяти, а разницы с 1.0 в тестах не заметил
> > >
> > > Кеш выставил, но шансы что клиент переподсоединиться на тот же
> > сервер -
> > > минимальны, но сотню мегов не жалко ;-)
> > >
> >
> > ssl_session_cache  ?
> > в приведенном конфиге ее нет.
> > покажите полный конфиг ?
> >
>
> Да, укажу его в самом конце.
>
> > >
> > > ну и sysctl соответственно тоже.
> > >
> > > Сейчас вот подумываем очень серьезно о полном переходе на nginx в
> > качестве
> > > основного оффлоадера.
> > >
> >
> > какая у вас нагрузка ?
> > мы держим 100-200к одновременных ssl-запросов на обычных серверах (и
> > ни в
> > какой потолок не упираемся).
> >
>
> Надо около 600к-1000к постоянных коннекшенов держать и с клиентом и с пуш
> серверами
>

миллион ? неплохо.



> И это будет только расти. Ну и непонятное кол-во отваливающихся мобилок, с
> которыми потом уже будем разбираться.
> Возможно, что применим Гео ДНС для облегчения инициализации их SSL сессии и
> лейтенси.
> Зараз даже тяжело сказать сколько будет подсоединений. Их очень много и
> видимо придется немного жертвовать мобилками и тьюнить беклоги и т.д.
> изначально. Но если Вы думаете, что большой беклог изначально - безопасно,
> то сразу и выставлю.
>
> >
> > > Хотим на днях запустить полноценный продакшен тест (а может и
> > финальный
> > > переход на nginx)
> > >
> > > Что еще можно подкрутить для уменьшения потребления памяти (если
> > возможно
> > > вообще)?
> > >
> >
> > GeoIP память тратит :-)
>
> геоайпи нема, только оффлоад и пуш на бекенде.
>
> > покажите nginx -V
>
> nginx version: nginx/1.2.3
> TLS SNI support enabled
> configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx
> --with-http_ssl_module --with-http_realip_module --without-http_gzip_module
>

эмм, а почему отключен gzip ?

для мобильноых абонентов, наверное, актуальна компрессия, там же каналы
могут быть очень плохого качества. мы в тестах видели 25 мегабайт в секунду
на одном ядре для дефолтного 6-го уровня сжатия. сервер с 24 ядрами может
на лету жать 5 гигабит в секунду.


> --without-http_fastcgi_module --without-http_empty_gif_module
> --http-log-path=/var/log/nginx --with-http_stub_status_module
> --without-http_ssi_module --without-http_geo_module
> --without-http_split_clients_module --without-http_uwsgi_module
> --without-http_scgi_module --without-http_memcached_module
> --without-http_charset_module --without-http_auth_basic_module
> --without-http_autoindex_module --without-http_referer_module
> --without-http_limit_conn_module --without-http_limit_req_module
> --without-http-cache --without-mail_pop3_module --without-mail_imap_module
> --without-mail_smtp_module --without-pcre --without-http_rewrite_module
>
> >
> >
> > > Может быть еще на что-то надо обратить внимание, без чего хорошего
> > > перформанс не достигнуть?
> > >
> > > Понимаю, что чудес наверно ждать не стоит, но вдруг кто сталкивался
> > с
> > > чем-то
> > > похожим и не спал ночами ;-)
> > >
> > > И еще вопрос многоуважаемым разработчикам:
> > > Когда планируется (и планируется ли вообще) поддержка CyaSSL?
> > > Промелькнуло пару постов, что вроде уже тесты идут, и по слухам
> > потребление
> > > памяти должно сильно упасть.
> > > Я в траке искал, но может не там...ничего не нашел
> > >
> > > Спасибо!
> > >
> > > Posted at Nginx Forum:
> > > http://forum.nginx.org/read.php?21,229967,229967#msg-229967
> > >
> > > _______________________________________________
> > > nginx-ru mailing list
> > > nginx-ru at nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> Привожу конфиг под сервер с 64ГБ памяти.
> с keepalive возможно перемудрил. Клиент висит и раз в 6 минут получает
>

keepalive я имел в виду на уровне http, не на tcp. у вас он включен, в
предыдущем конфиге это было непонятно.


> нолик, чтобы не отвалился, либо в любой момент получает пуш с данными от
> байтов до сот килобайт
>
> nginx.conf:
>
> worker_processes  8;
> worker_rlimit_nofile 409600;
> worker_priority -5;
>
> events  {
>         worker_connections  50000;
>         use epoll;
>         multi_accept on;
>   accept_mutex on;
>         }
>
> #GLOBAL SETTINGS
> http {
>
>
> log_format main      '$remote_addr - $host - $hostname - $http_name -
> $document_uri - $request_uri - $server_protocol - $server_name - $uri -
> $remote_user [$time_local] '
>                          '"$request" $status $bytes_sent '
>                          '"$http_referer" "$http_user_agent" ' ;
>
>
>     server_tokens       off;
>
>     error_log /usr/local/nginx/logs/error_log debug;
>     access_log off;
>     #access_log /var/log/nginx/access_log main;
>
>     default_type  application/octet-stream;
>
>     client_header_timeout  10m;
>     client_body_timeout    10m;
>     send_timeout           10m;
>
>     client_header_buffer_size    1k;
>     large_client_header_buffers  4 4k;
>
>     output_buffers   1 32k;
>     postpone_output  1460;
>
>     sendfile         on;
>     tcp_nopush       on;
>     tcp_nodelay      on;
>
> keepalive_timeout     600;
>
> keepalive_requests 1000000;
>
>
> upstream push {
> ip_hash;
>
> keepalive 60000;
>
> server 1.1.1.1;
> <<ну тут список из многих бекенд пуш серверов>>
>
>
> }
>
> include       mime.types;
> include       site.conf;
> }
>
> В теперь конфиг сайта самого
>
>
> ################
> # HTTPS server #
> ################
>
>     server {
>         listen       *:443 default backlog=4096 so_keepalive=30m::10;
>         server_name  имя;
>
>         access_log   off;
>         #access_log /var/log/nginx/access_ssl_log main;
>         error_log    /var/log/nginx/error_ssl_log debug;
>
>         ssl                  on;
>         ssl_certificate
> /usr/local/nginx/conf/ssl/conf/ssl/cert.com.pem;
>         ssl_certificate_key
> /usr/local/nginx/conf/ssl/conf/ssl/cert.com.key;
>
>         ssl_session_cache    shared:SSL:100m;
>
>         ssl_session_timeout  10m;
>
>        ssl_protocols TLSv1;
>        ssl_prefer_server_ciphers   on;
>        ssl_ciphers AES256-SHA:HIGH:!aNULL:!MD5;
>
>
>
>         client_max_body_size 0M;
>         client_body_buffer_size    128k;
>         client_body_temp_path      /var/tmp;
>
>         proxy_connect_timeout      75;
>         proxy_send_timeout         600;
>         send_timeout               600;
>         proxy_read_timeout         600;
>
>         proxy_buffer_size          4k;
>         proxy_buffers              4 32k;
>         proxy_busy_buffers_size    64k;
>         proxy_temp_file_write_size 64k;
>
>         proxy_temp_path            /tmp;
>
>   location / {
>       proxy_pass http://push;
>       proxy_http_version 1.1;
>       proxy_set_header Connection "";
>       proxy_buffering off;
>     }
>
>    }
>
>
> И добавки в sysctl.conf
>
> net.core.somaxconn = 3240000
> net.core.wmem_max = 16777216
> net.core.rmem_max = 16777216
> net.core.rmem_default = 8388608
> net.core.netdev_max_backlog = 5000
> net.ipv4.tcp_max_orphans = 300000
> net.ipv4.tcp_max_tw_buckets = 1440000
> net.ipv4.tcp_keepalive_intvl = 600
> net.ipv4.tcp_syncookies = 0
> net.ipv4.tcp_max_syn_backlog = 3240000
> net.ipv4.ip_local_port_range = 2000   65000
> net.ipv4.tcp_wmem = 4096      65536   16777216
> net.ipv4.tcp_rmem = 4096      87380   16777216
>
>
> вот что-то около того
>
> Спасибо!
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,229967,230015#msg-230015
>
> _______________________________________________
> 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/20120823/27515ce2/attachment-0001.html>


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