Jak jsme vyřešili limity Kazan Onyx2 pomocí vlastní SPDK proxy vrstvy

V jednom z našich předchozích článků jsme detailně popisovali, jak fungují naše NVMe JBOF storage boxy postavené na HPE J2000 a FPGA akcelerátorech Kazan Onyx2 (dnes Western Digital). Psali jsme o tom, jaká je reálná latence, jak Onyx2 mapuje NVMe namespace přímo přes PCIe do NVMe-oF a jak se nám podařilo tyto jednotky rozchodit jako jeden z nejrychlejších storage backendů v naší infrastruktuře.

Tentokrát navážeme tam, kde jsme tehdy skončili. Při dalším rozšiřování jsme totiž narazili na problém, který není na první pohled vidět – limit počtu NVMe controllerů na FPGA.

A tento detail nakonec vedl k tomu, že jsme implementovali vlastní SPDK proxy vrstvu mezi hypervisory a J2000 storage. A změnilo to způsob, jak náš NVMe-oF storage cluster škálujeme.

Proč Kazan Onyx2 na J2000 vůbec používáme

Než se dostaneme k samotné proxy, krátce připomeňme technologii.

Onyx2 = FPGA NVMe-oF target engine

Kazan Onyx2 není síťová karta ani DPU. Je to specializovaná FPGA pipeline, která implementuje NVMe over Fabrics:

• čtení a zápisy jdou přímo z RDMA/TCP do DMA enginů FPGA,
• žádný kernel, žádné CPU, žádný kontext switch,
• ultra-nízká latence díky hardwarovému fast-pathu,
• deterministické chování bez jitteru,
• prakticky line-rate výkon i v QD=1.

Onyx2 je tedy čistá NVMe-oF hardwarová brána mezi síťovým provozem a fyzickými NVMe disky.

HPE J2000 + 6× Kazan Onyx2 (dual-path)

V našich J2000 chassisech máme typicky:

• 24 NVMe disků,
• 6× Onyx2 karet,
• dual-path topologii (A/B redundantní porty),
• plnou podporu multipathu.

Tento design se nám osvědčil – výborná latence, spolehlivost, velmi slušná efektivita.

Jenže…

Našli jsme limit, který nás zastavil: 32 NVMe controllerů na FPGA pár

FPGA Onyx2 implementuje vlastní interní NVMe-oF target. A ten target má pevně definovaný limit:

Maximálně 32 NVMe controllerů na jeden FPGA pár (A/B).

Reálně to znamená:

• 32 controllerů na port A,
• 32 controllerů na port B,
• pokud potřebujeme více, není jak.

A zde jsme narazili.

Protože:

• J2000 máme zapojené redundantně přes dual path,
• v jednom boxu je 6 Onyx2 karet,
• hypervisorů máme v cloud klastru výrazně více než 32.

Navíc každý hypervisor si zakládá vlastní NVMe-oF controller session pro multipath. To znamená, že při větším počtu hypervisorů se 32 controllerů vyčerpá velmi rychle.

Pro výkon to nebyl problém. Pro kapacitu taky ne. Ale škálovat se s tím prostě nedalo.

Řešení? Vložit mezi hypervisor a storage „chytrou“ proxy

Potřebovali jsme něco, co bude:

• na straně Kazanu fungovat jako NVMe initiator,
• na straně hypervisorů jako NVMe-oF target,
• bude umět zachovat identitu disků (EUI64/NGUID),
• bude přidávat minimum latence,
• a nebude mít limit 32 controllerů.

A přesně to poskytl SPDK.

SPDK Proxy – architektura

Výsledná architektura vypadá zjednodušeně takto:

Hypervisor → NVMe-oF Initiator → SPDK Proxy → SPDK NVMe Initiator → Kazan Onyx2 → NVMe disk

SPDK proxy server tedy:

1. naváže NVMe-oF spojení na Onyx2 FPGA (bdev_nvme initiator),
2. připojí jednotlivé namespaces,
3. vytvoří nad nimi vlastní SPDK blockdevy,
4. a vystaví je dál jako SPDK NVMe-oF target.

Hypervisory už nekomunikují přímo s J2000, ale s proxy.

Co bylo potřeba upravit a vyřešit

Nasazení SPDK jako proxy není jen o spuštění nvmf_tgt. Museli jsme řešit několik poměrně hlubokých detailů.

1) EUI64/NGUID – kritická část pro multipath

Hypervisory očekávají, že:

• target A i target B budou hlásit stejný EUI64,
• a identifikátor musí odpovídat tomu, co hlásí původní NVMe namespace.

Kazan ale vrací EUI64 v jiném byte-order, než co vrací vlastní NVMe identify (a než očekává Linux).

Museli jsme tedy:

• patchnout SPDK,
• přidat EUI64 parsing do JSON výstupu,
• ručně správně poskládat EUI64 bajty podle NVMe specifikace,
• zaručit, že SPDK target bude exportovat stejnou identitu jako Onyx2 namespace.

Toto byla jedna z nejnáročnějších částí, protože multipath je na konzistenci identifikátorů extrémně citlivý.

2) Automatická regenerace SPDK konfigurace

Proxy musí po restartu:

• zjistit namespaces,
• načíst EUI64/NGUID,
• spustit NVMe initiator,
• vytvořit subsystémy,
• přidat namespace,
• nastavit controller-id range,
• spustit listener,
• a teprve potom povolit hypervisory.

Celé jsme to automatizovali vlastními skripty, které SPDK konfiguruje přes RPC. Díky tomu je start proxy deterministický a opakovatelný.

3) Hardware a ladění latence

Proxy server nesmí být bottleneck. Po testech jsme skončili u konfigurace založené na:

• AMD EPYC (kvůli vysokému single-core výkonu),
• ConnectX-5/6 Dx pro 100G RDMA/TCP,
• pinned cores: SPDK poll-loop běží na izolovaných jádrech,
• kernel parametrech typu: idle=poll, nohz_full, isolcpus, rcu_nocbs, nosmt, default_hugepagesz=1G, hugepages=4,
• IOMMU a hluboké C-states vypnuté.

Tím jsme dostali jitter pod ±3 μs a proxy přidávala pouze 8–12 μs navíc, což je v podstatě nerelevantní proti celkové latenci end-to-end.

Výsledky v produkci

Po nasazení SPDK proxy jsme získali několik klíčových výhod:

1) Žádné limity NVMe controllerů na hypervisory

Hypervisory teď komunikují jen s proxy, která se dokáže tvářit jako stovky controllerů. Kazan má pořád jen několik desítek – a to stačí.

2) Stabilní, konzistentní multipath

EUI64 i NGUID jsou konzistentní a identické napříč celou cestou. Linuxový NVMe driver tak nemá důvod hlásit chyby typu „IDs don't match for shared namespace“.

3) Nezávislost na implementaci NVMe-oF v FPGA

Všechny multipath a host-specific detaily běží v SPDK na serveru, ne ve firmware. Kazan Onyx2 zůstává tím, čím je nejlepší – extrémně rychlým NVMe-oF targetem.

4) Velmi nízká režie

Přidání ~10 μs latence je naprosto zanedbatelné vzhledem k počtu hypervisorů, které obsluhujeme, a získané flexibilitě.

5) Jednodušší upgrade / rolling updates

Proxy můžeme restartovat nebo nahrazovat bez potřeby šahat na samotné storage chassis. Hypervisory cílí na stabilní endpointy, které kontrolujeme my.

Závěr

Tím, že jsme mezi hypervisory a J2000 storage vložili SPDK proxy vrstvu, jsme vyřešili zásadní limit, který by jinak bránil dalšímu růstu celé platformy.

Kazan Onyx2 je stále perfektní backend – FPGA NVMe-oF target, který poskytuje konzistentní a extrémně nízkou latenci. SPDK pak doplňuje to, co FPGA hardware neumí: flexibilitu, kontrolu nad identitou disků, automatizaci a škálování.

Výsledkem je řešení, které kombinuje:

• hardwarovou latenci Kazanu,
• flexibilitu SPDK,
• robustní multipath,
• a škálovatelnou NVMe-oF topologii bez limitů FPGA.

Tato kombinace nám umožnila posunout storage infrastrukturu o generaci dál, připravit ji na vyšší počet hypervisorů a zároveň si zachovat náskok v I/O latencích, který považujeme za jednu z klíčových konkurenčních výhod.