Omezení XDP
Režim XDP, zjednoduše řečeno, umožňuje výrazně zrychlit zpracování DNS dotazů, které přichází standardním kanálem na port UDP/53. A to tak, že tyto dotazy a příslušné odpovědi jsou přímo předávány mezi síťovou kartou a DNS démonem. To je sice výhodné, protože odpadne režie jádra, průchod packetů síťovým stackem a podobně. Na druhou stranu je to ale komplikace pro administrátory, protože se k takovému serveru musí chovat zcela jinak než v rámci konvenčního provozu autoritativního DNS serveru.
Jednou z hlavních výzev, kterou jsme před nasazením museli řešit, bylo již zmíněné obcházení síťového stacku. Se spuštěným režimem XDP totiž není možné sledovat provoz přímo v operačním systému (např. utilitou tcpdump), není možné použít firewallová pravidla a také není možné standardním způsobem sbírat DNS provoz a posílat k dalším analýzám, v našem případě do infrastruktury projektu ADAM.
Další omezení se týká také oblasti routingu, neboť v tuto chvíli není možné použít Knot DNS 3.0 s XDP na standalone serveru, který má více konektivit (typicky místní IXP a tranzit), které v několika instancích provozujeme v zahraničí jako doplněk k DNS stackům. S kolegy z týmu Knot DNS se budeme snažit případ source-routingu řešit, protože by se nám tím otevřela možnost provozu velice výkonných uzlů anycastu ze standalone serveru, což by znamenalo snížení nákladů na provoz lokalit s takovýmto serverem.
Abychom tedy měli vhled do síťového provozu, připravili jsme vedle budoucího serveru ještě jeden server, který jsme pojmenovali NET. Server NET není vlastně žádnou novinkou, používáme jej u obou 100Gbps DNS stacků v Praze. Tento server je připojen dvěma dalšími uplinky do obou access switchů ve vybrané lokalitě a mirroruje síťový provoz z DNS serveru/ů. Ten se následně zpracovává standardními metodami pro projekt ADAM. A současně je možné přímo sledovat aktuální provoz tak, jak jsme zvyklí. Má to však jedno ale. V mirrorovaném provozu není možné rozlišit, jaký provoz byl odbaven pomocí XDP a jaký pomocí UDP. Jak sledovat přímo XDP provoz, popíšu závěrem.
Konfigurace XDP
Během léta jsme s kolegy z týmu Knot DNS konzultovali vše potřebné k tomu, abychom vůbec XDP mohli nasadit do produkčního prostředí. Řešili jsme ideální HW konfiguraci serveru, nastavení operačního systému a distribuci, zapojení do sítě (LACP ano nebo ne?) a další parametry. Nejzásadnějším parametrem byl co největší počet CPU jader (ideálně bez funkce hyperthreading), optimální rozložení RAM modulů, vhodná síťová karta, která umožňuje využití dostatečného počtu RX/TX front a verze linuxového jádra.
DNS server, který jsme pro Knota s XDP použili, má tedy následující konfiguraci:
- 2× Intel Xeon Gold 6140, každý 18C/36T s frekvencí 2,30Ghz
- 32 GB RAM
- 3× 480GB SSD MixUse
- 10GE Intel X710 SFP+
- Ubuntu server 20.04 LTS s jádrem 5.4
Server má tedy s vypnutou funkcí hyperthreading k dispozici celkem 36 jader, které jsme pro XDP rovnoměrně rozdělili mezi obě síťová rozhraní, neboť je server připojen do dvou access switchů s aktivním LACP.
# /sbin/ethtool -L ens3f0 combined 18 # /sbin/ethtool -L ens3f1 combined 18
Samotná aktivace XDP v DNS démonu je úplně jednoduchá. Po nastavení počtu front stačí ve stávající konfiguraci knot.conf přidat direktivu listen-xdp:
listen-xdp: ens3f0 listen-xdp: ens3f1
a restartovat démona knot. Dále je ještě potřeba rozšířit capabilities v se službě knot v systemd:
CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_RESOURCE AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_RESOURCE
Jak prosté!
Testování provozu XDP
Kolegové z týmu Knot DNS během vývoje samozřejmě prováděli různá svá měření výkonnosti. Podrobnosti můžete najít na stránkách projektu. I my jsme provedli několik našich testů, abychom si celé řešení „osahali“ a hlavně uvěřili proklamovanému nárůstu výkonu.
Ve verzi Knot DNS 3.0 je k dispozici nástroj kxdpgun, kterým je možné otestovat, kolik provozu DNS server zvládne odbavit při zadaném vzorku dat. Kolegové z týmu Knot DNS nám připravili tři vzorky dat:
- test č. 1.: DNS dotazy s malými odpověďmi o velikosti 61 B (pozitivní odpovědi bez DNSSEC),
- test č. 2.: DNS dotazy s velkými odpověďmi o velikosti 788 B (negativní odpovědi s DNSSEC),
- test č. 3.: DNS dotazy s odpovědmi o velikosti 179 B (pozitivní odpovědi s DNSSEC).
Všechny testy jsme prováděli z jiného serveru, který byl také připojen rychlostí 10 Gbps do stejných switchů. Výsledkem bylo:
- Při testu č. 1 server odbavil cca 10 milionů QPS!
- Při testu č. 2 jsme narazili na strop 10GE linky, server odbavil cca 1,5 – 2 milionů QPS.
- Při testu č. 3 server odbavil cca 5 milionů QPS.
I my tedy potvrzujeme, že výkonnost Knota se s podporou XDP zvýšila několikanásobně! Bez XDP jsme totiž na základě benchmarků uvažovali, že jeden DNS server zvládne při běžném DNS provozu odbavit maximálně 1–1,5 milionů QPS.
Provoz XDP
Jakmile jsme začali připravovat oba servery do provozu (tedy DNS server s Knot 3.0 a NET server pro sběr síťového provozu) přemýšleli jsme, kam je umístit a v rámci jakého písmenka DNS anycastu provozovat. Pokud bychom nový DNS server umístili do jedné z pražských lokalit, jeho provoz by zastínily oba 100Gbps DNS stacky. Směroval by na něj totiž velice malý provoz.
Nebo bychom naopak museli jedno písmenko DNS anycastu z obou stacků odstranit, což se jeví (alespoň z počátku spuštění XDP) jako velice riskantní. Vybrali jsme tedy naší třetí, neveřejnou, lokalitu, kde jsme letos v létě provedli upgrade páteřních síťových prvků (popíšu v jednom z příštích blogpostů) a kde také provozujeme několik standalone DNS serverů.
Nový DNS server jsme připravili pro provoz v rámci anycastu A. Abychom zajistili, že bude zpracovávat co největší objem provozu a mohli sledovat reálné chování, uměle jsme všem ostatním DNS serverům, v této lokalitě a se stejným písmenkem DNS anycastu, snížili BGP prioritu. To znamená, že jsou sice všechny v provozu, ale nestahují na sebe žádný provoz. Jakmile by ale došlo výpadku nového serveru, automaticky by převzali jeho roli a výpadek tohoto písmenka DNS anycastu by nebyl patrný.
Nový DNS server s podporou XDP jsme spustili v produkčním režimu 3. září 2020 v dopoledních hodinách.
Statistiky provozu
Jak jsem uvedl výše, pokud sledujeme a sbíráme DNS provoz standardními nástroji, není možné rozlišit XDP od UDP. Knot však nabízí interní statistiky, které stačí jen aktivovat v konfiguraci knot.conf.
template: – id: default … global-module: mod-stats
Pak stačí jen spustit příkaz knotc stats. Z výstupu získáme informaci o počtu dotazů via UDP, TCP, XDP a další statistiky od startu démona.
dns> knotc stats … mod-stats.request-protocol[udp4] = 15 mod-stats.request-protocol[tcp4] = 424336 mod-stats.request-protocol[udp6] = 2 mod-stats.request-protocol[tcp6] = 577667 mod-stats.request-protocol[udp4-xdp] = 228091218 mod-stats.request-protocol[udp6-xdp] = 57092138 …
Abychom tyto hodnoty mohli vizualizovat i do grafů, připravili jsme skript, který tyto data sbírá, počítá přírůstky a poté posílá ke zpracování do systému Munin. Jak vidno na grafu níže, po UDP není zpracován žádný provoz a po TCP je v zásadě také nulový.
Statistiky provozu Knot 3.0 s XDP pro .CZ anycast
Největší potenciál nasazení Knot DNS 3.0 s XDP vidím u serverů s výkonnými procesory AMD s velkým počtem jader, na DNS stackách s 10/40/100GE uplinkem. Na takové případy se již připravujeme a v blízké budoucnosti spustíme další instance XDP.
Budeme tedy schopni využít současnou infrastrukturu ještě efektivněji, plánovaná rozšíření nebo upgrady DNS anycastu v zahraničí budeme moci budovat s menšími nároky na místo a vyšší výkonností a v budoucnu budeme moci i snížit počet serverů ve velkých DNS stackách.
(Původně vyšlo na blogu CZ.NIC.)
