Question about cache setup

[freak82]

Здрасти Емо,

Понеже нямам друг контакт реших да пробвам през GitHub :).
Да те питам само нещо. Преди като бачкаше в x3me-a си беше направил един сетъп, ако помня правилно при който имаше един host и един guest, и на guest-a ти вървеше кеша. И ако помня правилно като искаше да тестваш само си рутираше трафика през guest-a? А на guest-a какъв ти беше сетъпа? Връщаше ли трафика от guest-a обратно на host-a? Ако го връщаше обратно на host-a как го изстрелваше после към интернет този трафик?

Сигурно не ги помниш тези неща, че мина много време, ама ако се сещаш нещо?
Че с един колега се опитваме да направим нещо подобно но не се получава.

Павел.

[epenchev]

Здравей Павка, извинявам се за късния отговор дано да е полезен (не съм предполагал че някой ще ми пише в github :) ).

Трафика със сигурност не го връщах към host OS всичко си минава през guest OS.

Сетъпа на guest OS доколкото си спомням беше че guest и host споделяха мрежовия адаптер тоест не в режим NAT а share physical device така guest OS си ставаше част от x3me мрежата.

На самия guest имах стандартното правило iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE за NAT и стандартното /proc/sys/net/ipv4/ip_forward = 1. Тези 2-те неща превръщат guest OS в един стандартен рутер.

Допълнителното което се правеше беше един policy base routing с iproute 2 и допълнителна routing таблица и едно редирект правило с iptables.

Мисля че това ще свърши работа стига да сте ядро >= 4.18 има tproxy.
https://www.kernel.org/doc/Documentation/networking/tproxy.txt
Ако е тест машина би трябвало сте ок.
https://github.com/txthinking/brook/wiki/How-to-run-transparent-proxy-on-Linux%3F

Аз мисля че го правих по тези стари инструкции.
https://www.tldp.org/HOWTO/TransparentProxy-6.html
6.2 Second method (more complicated, but more general)
Като игнорираш настройките за squid-a естествено.

Дано да съм бил полезен.

[freak82]

Здрасти Емо, Нямах друг контакт та затова писах през github :). Мерси за инструкциите. Ще ги имаме в предвид ако пак ни се наложи нещо такова. Ние го измислихме финално с две машини. Едната го играе рутер и там са сложнотиите по извъртането на трафика, а другата е машината на която върви кеш-прокси софтуера. Рутера праща трафика към кеш машината, тя го връща в рутера и той го праща към нета. И после на обратно по същия път минава. Не можем да излезем към интернет директно от кеш машината, щото пробваме сега едни неща с Intel DPDK-a и bypass на Linux-кия TCP stack. И от там става сложно на кеш машината да се рутират неща. Та в момента кеш машината просто си праща изходящия трафик по същия NIC окупиран от DPDK-a към MAC-a на рутера и последния вече се оправя както намери за добре. Павел.

…

On Thu, Jan 2, 2020 at 6:34 PM Emil Penchev ***@***.***> wrote: Здравей Павка, извинявам се за късния отговор дано да е полезен (не съм предполагал че някой ще ми пише в github :) ). Трафика със сигурност не го връщах към host OS всичко си минава през guest OS. Сетъпа на guest OS доколкото си спомням беше че guest и host споделяха мрежовия адаптер тоест не в режим NAT а share physical device така guest OS си ставаше част от x3me мрежата. На самия guest имах стандартното правило iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE за NAT и стандартното /proc/sys/net/ipv4/ip_forward = 1. Тези 2-те неща превръщат guest OS в един стандартен рутер. Допълнителното което се правеше беше един policy base routing с iproute 2 и допълнителна routing таблица и едно редирект правило с iptables. Мисля че това ще свърши работа стига да сте ядро >= 4.18 има tproxy. https://www.kernel.org/doc/Documentation/networking/tproxy.txt Ако е тест машина би трябвало сте ок. https://github.com/txthinking/brook/wiki/How-to-run-transparent-proxy-on-Linux%3F Аз мисля че го правих по тези стари инструкции. https://www.tldp.org/HOWTO/TransparentProxy-6.html 6.2 Second method (more complicated, but more general) Като игнорираш настройките за squid-a естествено. Дано да съм бил полезен. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALLJAKGWLXIA4GBVHFOYV3Q3YJSHANCNFSM4J4HK24Q> .

[epenchev]

Интересно успех в начинанието.
Аз преди време прочетох за една сравнително нова концепция даже почти бяхме решили да я пробваме но проекта пропадна така или иначе.
Може и да си го срещал вече но все пак реших да споделя.
https://lwn.net/Articles/728682/

А това е самия проект.
https://github.com/includeos/IncludeOS

И доколкото четох може да boot -не x86 система, но не съм го пробвал.

[freak82]

Да. Гледах преди време презентация на главния dev там на CppCon. Ние в момента пробваме с това - https://openfastpath.org/index.php/service/technicaloverview/. Те всъщност са 3 компонента - DPDK-a е най отдолу. После върху него е OpenDataPlane-a, който може да работи върху стандартен линукс или върху DPDK. И най отгоре е OpenFastPath-a, който основно е TCP/IP stack взет от BSD 8.1 (или 8.3 забравих коя точно версия). Главния проблем, е че няма голям избор от UserSpace TCP stack-ове. Хората са си писали някакви, но не може да се разчита на тях, щото не са battle tested. Само този, и още един са направени като е взет стек-а от BSD. Но пък абсолютно никой от стековете не е оптимизиран да работи в DPDK сценарий, тоест отделен stack per core да има и стековете да нямат общи структури (като arp таблици, routing таблици, etc) и да няма излишно заключване. Друг проблем, е че искаме само проксито да работи върху fast-path-a, а останалите неща да си работят върху стандартния Linux (така наречения SlowPath в случая). Та от един NIC искаме определен трафик да минава през OpenFastPath стека, друг (SSH например) да си минава през стандартния Linux. Има решения DPDK KNI кернел модул, TUN/TAP interface, ама не са най бързото нещо под слънцето, и допълнително забавят трафика предназначен за Linux-a. OpenDataPlane-a може да работи върху DPDK (бързо) или върху TUN/TAP device (бавно). Ако подържаше работа върху XDP сокет ( https://www.kernel.org/doc/html/v4.18/networking/af_xdp.html) щеше да е най добре според мен, щото XDP-то е малко по бавно от DPDK-а (10-20% му дават по бавно по презентации), а понеже е стандартен linux feature разпределянето на трафика става вътре в самия кернел, с eBPF, и няма допълнително забавяне за SlowPath трафика. Та така. В момента пак експериментираме. Основната идея е ако можем да пускаме софтуерите на всякакви кошници :). Че имаме примерно едни клиенти от Камбоджа, дето пускаха 20-25 Gbps HTTP трафик през xproxy машината и тя до 20-22 Gpbs се държеше що годе добре, но като се качеше на 25 Gbps вече самата машина не беше много стабилна. Но ония си купиха хардуер за 80 хил евра. Скоро добавиха още трафик и затова го разделиха на 2 машини и вече на скача на 20 Gbps. Та пробваме да намалим разходите за хардуери в момента, на клиентите. Павел.

…

On Fri, Jan 3, 2020 at 9:53 AM Emil Penchev ***@***.***> wrote: Интересно успех в начинанието. Аз преди време прочетох за една сравнително нова концепция даже почти бяхме решили да я пробваме но проекта пропадна така или иначе. Може и да си го срещал вече но все пак реших да споделя. https://lwn.net/Articles/728682/ А това е самия проект. https://github.com/includeos/IncludeOS И доколкото четох може да boot -не x86 система, но не съм го пробвал. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALLJAJ7ZTMPUUNHDMP2V43Q33VI5ANCNFSM4J4HK24Q> .

[epenchev]

Разгледах openfastpath проекта, излгежда интересен.
Да би било най лесно OpenDataPlane да работи върху XDP, така определено няма да се налага да делите прокси трафик и management linux трафика по някакви по сложни/бавни начини с копиране към TUN/TAP device.
OpenDataPlane API стандарта изглежда нещо много добро пък и доста големи компании стоят зад него като прочетох.

Успех от мен и дано да ви се получи.