Ve středu 9. 9. 2020 vydali kolegové z Laboratoří CZ.NIC novou verzi autoritativního DNS serveru Knot DNS (3.0), která přináší mimo jiné i podporu XDP. Pokusím se shrnout, jak jsme pro novou verzi připravili trochu specifické prostředí, v průběhu léta testovali a následně spustili do ostrého provozu v našeho .CZ DNS anycastu.

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á 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 Knot DNS týmu 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 na závěr.

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:

– 2x Intel Xeon Gold 6140, každý 18C/36T s frekvencí 2.30Ghz
– 32 GB RAM
– 3x 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 knot systemd service

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 61B (pozitivní odpovědi bez DNSSEC),
– test č. 2.: DNS dotazy s velkými odpověďmi o velikosti 788B (negativní odpovědi s DNSSEC),
– test č. 3.: DNS dotazy s odpovědmi o velikosti 179B (pozitivní odpovědi s DNSSEC).

Všechny testy jsme prováděli z jiného serveru, který byl také připojen rychlostí 10Gbps 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 DNS 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. A 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 k 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 DNS 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 script, který tato 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ý.

Největší potenciál nasazení Knot DNS 3.0 s XDP vidím u serverů s výkonnými AMD procesory 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ší XDP instance. 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.

 

Autor: Václav Steiner