Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Tempesta FW:
challenges,
internals,
use cases
Александр Крижановский
Привет :)
• Tempesta Technologies — с 2014, подразделение
NatSys Lab
• NatSys Lab — с 2008, разработка
высокопроизводитель...
Challenges (Зачем?)
• Современный Internet бывает зол
• Но есть Web-рыцари добра и света
Challenges (Зачем?)
• Современный Internet бывает зол
• Но есть Web-рыцари добра и света
• .., которые фильтруют плохие за...
Рыцарь WAF
• Оружие: XHTML, WSDL, Machine learning, Regexps
• Платформа: Nginx, Apache Traffic Server etc.
Пример: Nginx + regexps
0 5000 10000 15000 20000 25000 30000 35000
0
5000
10000
15000
20000
25000
30000
4168 4133
6855
Hyp...
Результат: WAF
15K HTTP RPS на 24 ядрах
(а хочется >100KRPS)
Снова об акселерации
Рыцарь Anti-DDoS CDN
• Оружие: DPI или Firewall + Machine Learning
• Платформа: Nginx
Application layer DDoS
Service from Cache Rate limit
Nginx 22us 23us
Application layer DDoS
Service from Cache Rate limit
Nginx 22us 23us
• Fail2Ban: пишем файл, парсим файл, пишем файл,
парс...
Application layer DDoS
Service from Cache Rate limit
Nginx 22us 23us
• Fail2Ban: пишем файл, парсим файл, пишем файл,
парс...
Что не может Web-сервер?
• Фильтровать DDoS трафик
– мелкие запросы
– флуды
Что не может Web-сервер?
• Фильтровать DDoS трафик
– мелкие запросы
– флуды
• Быстро работать (c10k => c100k) ??!!
Профиль Web-сервера
% symbol name
1.5719 ngx_http_parse_header_line
1.0303 ngx_vslprintf
0.6401 memcpy
0.5807 recv
0.5156 ...
Вызовы Web-сервера
epoll_wait(.., {{EPOLLIN, ....}},...)
recvfrom(3, "GET / HTTP/1.1rnHost:...", ...)
// parse HTTP
write(...
HTTP парсер
Start: state = 1, *str_ptr = 'b'
while (++str_ptr) {
switch (state) { <= check state
case 1:
switch (*str_ptr)...
HTTP парсер
Start: state = 1, *str_ptr = 'b'
while (++str_ptr) {
switch (state) {
case 1:
switch (*str_ptr) {
case 'a':
.....
HTTP парсер
Start: state = 1, *str_ptr = 'b'
while (++str_ptr) {
switch (state) {
case 1:
switch (*str_ptr) {
case 'a':
.....
HTTP парсер
Start: state = 1, *str_ptr = 'b'
while (++str_ptr) {
switch (state) { <= check state
case 1:
switch (*str_ptr)...
HTTP парсер
Start: state = 1, *str_ptr = 'b'
while (++str_ptr) {
switch (state) {
case 1:
switch (*str_ptr) {
case 'a':
.....
HTTP парсер
Асинхронный I/O
Асинхронный I/O
Асинхронный I/O
Асинхронный I/O
Итого: Web-сервер
• Медленный HTTP парсинг
• Контекст свитчи
• Копирование
• Асинхронная модель I/O
• Файлы и файловые дес...
Linux?
Linux zero-copy I/O - миф
tcp_transmit_skb(sock *sk, sk_buff *skb,
int clone_it, ...)
{
...
if (likely(clone_it))
skb = ps...
Что делают современники?
“...standard servers
running an in-house OS.
The key to achieve that
performance was to
disable I...
User-space TCP/IP
(~Exokernel ОС)
• Sandstorm
– Netmap
– Специализированный TCP/IP стек:
●
Web-сервер «знает» о пакетах
●
...
Итого: User- vs Kernel-space
• Проблемы Web-сервера не уходят
(прикладной уровень не «знает» о сетевом)
• Все равно есть s...
И снова синхронизация...
И снова синхронизация...
...приходим к тем же локам и копированиям
Не только TCP/IP, но и СУБД
• Web-cache
• Сессии
• Правила фильтрации
• Web Application Server: вообще что угодно
• WAF & ...
Что делают разработчики
СУБД?
• Buffer pool (page cache в ОС)
• Планирование I/O ( --''-- в ОС)
• Префетчинг блоков ( --''...
Что думают об этом
разработчики ядра
«In short, the whole "let's bypass the OS" notion is just
fundamentally broken. It so...
Tempesta FW
• Минималистичная и очень быстрая реализация в
ядре
– Web-прокси и Web-сервер
– Key-value in-memory база данны...
Tempesta FW
• Минималистичная и очень быстрая реализация в
ядре
– Web-прокси и Web-сервер
– Key-value in-memory база данны...
Tempesta FW
• Минималистичная и очень быстрая реализация в
ядре
– Web-прокси и Web-сервер
– Key-value in-memory база данны...
Tempesta FW: macrokernel?
• Прикладная логика в user-space
– Tempesta DB: tdbq → libtdb → kernel engine
– Tempesta FW: CGI...
Cинхронный I/O
• Вся работа в softirq
Cинхронный I/O
• Вся работа в softirq
• Нет очередей (на чтение)
Cинхронный I/O
• Вся работа в softirq
• Нет очередей (на чтение)
• Нет файловых дескрипторов
Cинхронный I/O
• Вся работа в softirq
• Нет очередей (на чтение)
• Нет файловых дескрипторов
• Меньше блокировок
Cинхронный I/O
• Вся работа в softirq
• Нет очередей (на чтение)
• Нет файловых дескрипторов
• Меньше блокировок
=> Быстре...
Synchronous Sockets
http://natsys-lab.blogspot.ru/2013/03/whats-wrong-with-
sockets-performance.html
Быстрый HTTP парсер
237ms 470ms
http://natsys-lab.blogspot.ru/2014/11/the-fast-finite-state-
machine-for-http.htmlc
Tempesta DB
In-memory Key-Value
Tempesta DB
In-memory Key-Value
• Cache conscious Burst Hash Trie
Tempesta DB
In-memory Key-Value
• Cache conscious Burst Hash Trie
• Lock-free (почти)
Tempesta DB
In-memory Key-Value
• Cache conscious Burst Hash Trie
• Lock-free (почти)
• Huge pages
Tempesta DB
In-memory Key-Value
• Cache conscious Burst Hash Trie
• Lock-free (почти)
• Huge pages
• Быстрый транспорт в/и...
Tempesta DB:
zero-copy транспорт
http://natsys-lab.blogspot.ru/2015/03/linux-netlink-mmap-
bulk-data-transfer.html
Web-кэш
• На основе Tempesta DB
• NUMA-aware
Web-кэш: NUMA sharding
Web-кэш: NUMA replication
Frang: HTTP DoS
• Rate limits
– request_rate, request_burst
– connection_rate, connection_burst
– concurrent_connections
Frang: HTTP DoS
• Rate limits
– request_rate, request_burst
– connection_rate, connection_burst
– concurrent_connections
•...
Frang: WAF
• Ограничения размеров
– http_uri_len, http_field_len, http_body_len
Frang: WAF
• Ограничения размеров
– http_uri_len, http_field_len, http_body_len
• Допустимые значения
– http_ct_required, ...
Frang: фильтрация
Frang: фильтрация
Frang: фильтрация
Frang: фильтрация
Балансировка нагрузки
• Динамический реконнект
Балансировка нагрузки
• Динамический реконнект
• Конфигурируемое число соединений к бакендам
Балансировка нагрузки
• Динамический реконнект
• Конфигурируемое число соединений к бакендам
• Планировщики
– HTTP (по гру...
Балансировка нагрузки
• Динамический реконнект
• Конфигурируемое число соединений к бакендам
• Планировщики
– HTTP (по гру...
Балансировка нагрузки
• Динамический реконнект
• Конфигурируемое число соединений к бакендам
• Планировщики
– HTTP (по гру...
Пример
srv_group static { # sched=round-robin
server 10.10.0.1:8080;
server [fc00::2]:8081;
}
srv_group dynamic sched=hash...
Sticky cookie
• Идентификация пользователей
• enforce: HTTP 302 redirect
sticky name=__tfw_user_id__ enforce;
А не страшно ли в ядре?
#include <linux/module.h>
static int oops_init(void)
{
BUG();
}
module_init(oops_init);
# insmod o...
Бенчмарки… :(
https://github.com/natsys/tempesta/issues/30
Спасибо!
Source Code (GPLv2):
https://github.com/natsys/tempesta
Blog:
http://natsys-lab.blogspot.com
E-mail:
ak@natsys-la...
Upcoming SlideShare
Loading in …5
×

Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempesta Technologies)

821 views

Published on

Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.

В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.

И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempesta Technologies)

  1. 1. Tempesta FW: challenges, internals, use cases Александр Крижановский
  2. 2. Привет :) • Tempesta Technologies — с 2014, подразделение NatSys Lab • NatSys Lab — с 2008, разработка высокопроизводительных систем – хранения – обработки сетевого трафика • Сделали cамую быструю реализацию lock-free очереди задач (Linux Journal, Jun 12, 2013) • Исследовали производительность Intel TSX
  3. 3. Challenges (Зачем?) • Современный Internet бывает зол • Но есть Web-рыцари добра и света
  4. 4. Challenges (Зачем?) • Современный Internet бывает зол • Но есть Web-рыцари добра и света • .., которые фильтруют плохие запросы
  5. 5. Рыцарь WAF • Оружие: XHTML, WSDL, Machine learning, Regexps • Платформа: Nginx, Apache Traffic Server etc.
  6. 6. Пример: Nginx + regexps 0 5000 10000 15000 20000 25000 30000 35000 0 5000 10000 15000 20000 25000 30000 4168 4133 6855 HyperScan Vanilla Nginx PCRE-JIT Target RPS ActualRPS
  7. 7. Результат: WAF 15K HTTP RPS на 24 ядрах (а хочется >100KRPS)
  8. 8. Снова об акселерации
  9. 9. Рыцарь Anti-DDoS CDN • Оружие: DPI или Firewall + Machine Learning • Платформа: Nginx
  10. 10. Application layer DDoS Service from Cache Rate limit Nginx 22us 23us
  11. 11. Application layer DDoS Service from Cache Rate limit Nginx 22us 23us • Fail2Ban: пишем файл, парсим файл, пишем файл, парсим файл…
  12. 12. Application layer DDoS Service from Cache Rate limit Nginx 22us 23us • Fail2Ban: пишем файл, парсим файл, пишем файл, парсим файл… - 21й век?!
  13. 13. Что не может Web-сервер? • Фильтровать DDoS трафик – мелкие запросы – флуды
  14. 14. Что не может Web-сервер? • Фильтровать DDoS трафик – мелкие запросы – флуды • Быстро работать (c10k => c100k) ??!!
  15. 15. Профиль Web-сервера % symbol name 1.5719 ngx_http_parse_header_line 1.0303 ngx_vslprintf 0.6401 memcpy 0.5807 recv 0.5156 ngx_linux_sendfile_chain 0.4990 ngx_http_limit_req_handler + довольно длинный хвост
  16. 16. Вызовы Web-сервера epoll_wait(.., {{EPOLLIN, ....}},...) recvfrom(3, "GET / HTTP/1.1rnHost:...", ...) // parse HTTP write(1, “...limiting requests, excess...", ...) writev(3, "HTTP/1.1 503 Service...", ...) sendfile(3,..., 383) recvfrom(3, ...) = -1 EAGAIN epoll_wait(.., {{EPOLLIN, ....}}, ...) recvfrom(3, "", 1024, 0, NULL, NULL) = 0 close(3)
  17. 17. HTTP парсер Start: state = 1, *str_ptr = 'b' while (++str_ptr) { switch (state) { <= check state case 1: switch (*str_ptr) { case 'a': ... state = 1 case 'b': ... state = 2 } case 2: ... } ... }
  18. 18. HTTP парсер Start: state = 1, *str_ptr = 'b' while (++str_ptr) { switch (state) { case 1: switch (*str_ptr) { case 'a': ... state = 1 case 'b': ... state = 2 <= set state } case 2: ... } ... }
  19. 19. HTTP парсер Start: state = 1, *str_ptr = 'b' while (++str_ptr) { switch (state) { case 1: switch (*str_ptr) { case 'a': ... state = 1 case 'b': ... state = 2 } case 2: ... } ... <= jump to while }
  20. 20. HTTP парсер Start: state = 1, *str_ptr = 'b' while (++str_ptr) { switch (state) { <= check state case 1: switch (*str_ptr) { case 'a': ... state = 1 case 'b': ... state = 2 } case 2: ... } ... }
  21. 21. HTTP парсер Start: state = 1, *str_ptr = 'b' while (++str_ptr) { switch (state) { case 1: switch (*str_ptr) { case 'a': ... state = 1 case 'b': ... state = 2 } case 2: ... <= do something } ... }
  22. 22. HTTP парсер
  23. 23. Асинхронный I/O
  24. 24. Асинхронный I/O
  25. 25. Асинхронный I/O
  26. 26. Асинхронный I/O
  27. 27. Итого: Web-сервер • Медленный HTTP парсинг • Контекст свитчи • Копирование • Асинхронная модель I/O • Файлы и файловые дескрипторы • Web-cache не имеет представления о NUMA
  28. 28. Linux?
  29. 29. Linux zero-copy I/O - миф tcp_transmit_skb(sock *sk, sk_buff *skb, int clone_it, ...) { ... if (likely(clone_it)) skb = pskb_copy(skb, gfp_mask); else skb = skb_clone(skb, gfp_mask); ... }
  30. 30. Что делают современники? “...standard servers running an in-house OS. The key to achieve that performance was to disable IRQs, no syscalls, no context switching, no kernel, no memcopy, new stack etc. Basically in few hundreds ticks a packet hits the nginx or whatever application runs on it.”
  31. 31. User-space TCP/IP (~Exokernel ОС) • Sandstorm – Netmap – Специализированный TCP/IP стек: ● Web-сервер «знает» о пакетах ● преаллокация пакетов – syscall batching (latency) • mTCP (http://shader.kaist.edu/mtcp/) – PSIO, DPDK – TCP/IP stack from scratch (~15KoL, linux >130KoL)
  32. 32. Итого: User- vs Kernel-space • Проблемы Web-сервера не уходят (прикладной уровень не «знает» о сетевом) • Все равно есть syscall'ы (немного) • Фиксированный размер буферов • Неконтролируемое вытеснение (lock-free, RCU, spinlock) • Большой дублирующий пласт кода
  33. 33. И снова синхронизация...
  34. 34. И снова синхронизация... ...приходим к тем же локам и копированиям
  35. 35. Не только TCP/IP, но и СУБД • Web-cache • Сессии • Правила фильтрации • Web Application Server: вообще что угодно • WAF & DDoS mitigation: модели обучения и пр.
  36. 36. Что делают разработчики СУБД? • Buffer pool (page cache в ОС) • Планирование I/O ( --''-- в ОС) • Префетчинг блоков ( --''-- в ОС) • Транзакционный лог ( --''-- в ФС) • open(O_DIRECT) (OS bypass)...
  37. 37. Что думают об этом разработчики ядра «In short, the whole "let's bypass the OS" notion is just fundamentally broken. It sounds simple, but it sounds simple only to an idiot who writes databases and doesn't even UNDERSTAND what an OS is meant to do.» Linus Torvalds «Re: O_DIRECT question» https://lkml.org/lkml/2007/1/11/129
  38. 38. Tempesta FW • Минималистичная и очень быстрая реализация в ядре – Web-прокси и Web-сервер – Key-value in-memory база данных (Tempesta DB)
  39. 39. Tempesta FW • Минималистичная и очень быстрая реализация в ядре – Web-прокси и Web-сервер – Key-value in-memory база данных (Tempesta DB) • Фаервол на сетевых уровнях IP, TCP, HTTP
  40. 40. Tempesta FW • Минималистичная и очень быстрая реализация в ядре – Web-прокси и Web-сервер – Key-value in-memory база данных (Tempesta DB) • Фаервол на сетевых уровнях IP, TCP, HTTP • Оптимизация и доработка вместо специализации
  41. 41. Tempesta FW: macrokernel? • Прикладная логика в user-space – Tempesta DB: tdbq → libtdb → kernel engine – Tempesta FW: CGI-like zero-copy интерфейс (TODO)
  42. 42. Cинхронный I/O • Вся работа в softirq
  43. 43. Cинхронный I/O • Вся работа в softirq • Нет очередей (на чтение)
  44. 44. Cинхронный I/O • Вся работа в softirq • Нет очередей (на чтение) • Нет файловых дескрипторов
  45. 45. Cинхронный I/O • Вся работа в softirq • Нет очередей (на чтение) • Нет файловых дескрипторов • Меньше блокировок
  46. 46. Cинхронный I/O • Вся работа в softirq • Нет очередей (на чтение) • Нет файловых дескрипторов • Меньше блокировок => Быстрее чтение (и парсинг HTTP!)
  47. 47. Synchronous Sockets http://natsys-lab.blogspot.ru/2013/03/whats-wrong-with- sockets-performance.html
  48. 48. Быстрый HTTP парсер 237ms 470ms http://natsys-lab.blogspot.ru/2014/11/the-fast-finite-state- machine-for-http.htmlc
  49. 49. Tempesta DB In-memory Key-Value
  50. 50. Tempesta DB In-memory Key-Value • Cache conscious Burst Hash Trie
  51. 51. Tempesta DB In-memory Key-Value • Cache conscious Burst Hash Trie • Lock-free (почти)
  52. 52. Tempesta DB In-memory Key-Value • Cache conscious Burst Hash Trie • Lock-free (почти) • Huge pages
  53. 53. Tempesta DB In-memory Key-Value • Cache conscious Burst Hash Trie • Lock-free (почти) • Huge pages • Быстрый транспорт в/из user-space
  54. 54. Tempesta DB: zero-copy транспорт http://natsys-lab.blogspot.ru/2015/03/linux-netlink-mmap- bulk-data-transfer.html
  55. 55. Web-кэш • На основе Tempesta DB • NUMA-aware
  56. 56. Web-кэш: NUMA sharding
  57. 57. Web-кэш: NUMA replication
  58. 58. Frang: HTTP DoS • Rate limits – request_rate, request_burst – connection_rate, connection_burst – concurrent_connections
  59. 59. Frang: HTTP DoS • Rate limits – request_rate, request_burst – connection_rate, connection_burst – concurrent_connections • Slow HTTP – client_header_timeout, client_body_timeout – http_header_cnt – http_header_chunk_cnt, http_body_chunk_cnt
  60. 60. Frang: WAF • Ограничения размеров – http_uri_len, http_field_len, http_body_len
  61. 61. Frang: WAF • Ограничения размеров – http_uri_len, http_field_len, http_body_len • Допустимые значения – http_ct_required, http_ct_vals – http_methods
  62. 62. Frang: фильтрация
  63. 63. Frang: фильтрация
  64. 64. Frang: фильтрация
  65. 65. Frang: фильтрация
  66. 66. Балансировка нагрузки • Динамический реконнект
  67. 67. Балансировка нагрузки • Динамический реконнект • Конфигурируемое число соединений к бакендам
  68. 68. Балансировка нагрузки • Динамический реконнект • Конфигурируемое число соединений к бакендам • Планировщики – HTTP (по группам серверов) ● Wildcards, full match, prefix ● Метод, URI, Host ● Любые заголовоки
  69. 69. Балансировка нагрузки • Динамический реконнект • Конфигурируемое число соединений к бакендам • Планировщики – HTTP (по группам серверов) ● Wildcards, full match, prefix ● Метод, URI, Host ● Любые заголовоки – Round-robin (внутри групп серверов)
  70. 70. Балансировка нагрузки • Динамический реконнект • Конфигурируемое число соединений к бакендам • Планировщики – HTTP (по группам серверов) ● Wildcards, full match, prefix ● Метод, URI, Host ● Любые заголовоки – Round-robin (внутри групп серверов) – Rendezvous hashing
  71. 71. Пример srv_group static { # sched=round-robin server 10.10.0.1:8080; server [fc00::2]:8081; } srv_group dynamic sched=hash { server 10.10.0.3:8080; # conns_n = 4 server [fc00::4]:8081 conns_n=8; } srv_group black_hole { } sched_http_rules { match black_hole hdr_raw prefix "X-Bad:"; match static uri prefix "/static/"; match dynamic * * *; }
  72. 72. Sticky cookie • Идентификация пользователей • enforce: HTTP 302 redirect sticky name=__tfw_user_id__ enforce;
  73. 73. А не страшно ли в ядре? #include <linux/module.h> static int oops_init(void) { BUG(); } module_init(oops_init); # insmod oops.ko || echo "$?, but I'm alive" Segmentation fault 139, but I'm alive # dmesg|grep oops.c kernel BUG at /root/oops_failover/oops.c:4!
  74. 74. Бенчмарки… :( https://github.com/natsys/tempesta/issues/30
  75. 75. Спасибо! Source Code (GPLv2): https://github.com/natsys/tempesta Blog: http://natsys-lab.blogspot.com E-mail: ak@natsys-lab.com

×