mirror of
https://github.com/mulgadc/spinifex.git
synced 2026-10-15 17:11:30 +00:00
Ben Duncan
42d87d7a5a
* feat(ebs): make nbdkit thread count and per-volume read cache configurable Both numbers that set a volume's export concurrency and memory were hard-coded: nbdkit ran on its own default of 16 threads per connection because no -t was ever passed, and the read cache was a 128 MiB literal in the mount path. Neither could be changed without a recompile, and neither was visible in the logs or the process argv. Add default_threads and cache_size_mb to [nodes.<node>.ebs]. Defaults are unchanged, so a config that does not set them behaves exactly as before. CacheSizeMB is a pointer so an explicit 0 (cache disabled) stays distinguishable from an unset key, matching how ViperblockConfig treats its own toggles. -efi volumes stay uncached regardless. Validation is a range check only. Both are operator tunables applied per nbdkit process, and there is one of those per volume, so the host cost is the value times the volume count -- left for the operator to weigh rather than second-guessed here. * feat(security): arm the firewall by install path and sync the clock at firstboot The host firewall armed itself from a code default, so a curl-to-bash install onto an existing Debian or Ubuntu machine applied a default-deny INPUT policy seconds after bootstrap. Anything the operator was already running that is not on the allow list stopped accepting connections, with nothing logged and no config key to set beforehand — no template writes firewall_enabled, so every install fell through to the default. Arming is now the install path's decision. setup.sh takes --firewall=on|off and records it in /etc/spinifex/firewall/mode, defaulting on under ISO_BUILD and off everywhere else: the ISO is an appliance on hardware we define, a package install is a guest on a machine that was already doing something. firewall_enabled becomes a three-state *bool so "unset" and "explicitly false" stay distinguishable. Flipping the default to false instead would have torn down a working policy on every existing node, because false is an instruction to disable rather than an absence. Resolution is config, then mode file, then on, so a node installed before any of this keeps what it has. The ISO had the opposite problem. setup.sh is the only place that enables spinifex-firewall.service and it returns before that line under ISO_BUILD, with no systemd in the chroot to talk to. Nothing else enabled it, so after a reboot the ruleset — runtime state — was gone, and ReconcileFirewall short-circuited on an unchanged peer file and never put it back. An ISO node was firewalled until its first reboot and open permanently after. firstboot now enables the unit, and the reconcile checks the table is loaded rather than treating an unchanged peer set as proof the policy is applied. Two policy changes: 443 is held for the nginx TLS edge so that rollout needs no per-node firewall change, and the SSH port is read from sshd_config and its Include drop-ins instead of being hardcoded to 22 — a host on Port 2222 was allowed exactly one port that was not the one it uses, and ct state established kept the operator's session alive until they disconnected. 53 stays open on every node, now with a comment saying so: northstar serves public authoritative DNS. Clock: firstboot steps and waits for sync before spx admin init mints credentials, since a certificate issued against a wrong RTC carries a NotBefore that outlives the correction. Bounded to 60s and non-fatal so an air-gapped install still completes, and once is enough because rtcsync writes the corrected time back. A chrony drop-in replaces Debian's makestep 1 3, which stops stepping after three updates and then slews at roughly 7 seconds a day — a node that burned those before the network came up never visibly converged. * fix(security): let a node join a cluster whose firewall is already armed Expanding a single-node ISO install into a cluster could not succeed. Two independent blockers, both from the same root: the peer set is derived from converged cluster state, but the ports needed to reach convergence are gated on that same set. The formation port is peer-scoped, and a node dialling in to join is not a peer yet, so the handshake was dropped rather than refused and the joiner retried in silence until it timed out. It cannot simply move to the public rule: outside formation the same port carries the daemon cluster manager, whose /health and /local/* routes report node topology, service inventory and running instances unauthenticated. So it is opened for the formation window only, by spx admin init, and closed again on every exit path. The reconcile then deadlocked. Holding out for the full chassis list is right on a node with no policy loaded, but on one armed for a smaller cluster the ports a joining node needs in order to register its chassis are exactly the ones the stale set blocks, so the list can never complete. Widen the peer set on the tunnel set already loaded, and report the partial state so the caller retries sooner than the steady-state interval. A converged cluster whose Southbound DB is briefly unreadable is still left untouched. * docs(install): explain the firewall around cluster formation An ISO-installed server is a cluster of one, and its firewall admits internal cluster traffic only from members it recognises. Forming a cluster out of such servers therefore needs the firewall off first: step 3 of the multi-node guide has each server dial node 1's OVN database on the raft ports, and those are peer-scoped like everything else on the cluster plane. Neither guide said so, and the failure is a silent drop that looks like a network fault. Both guides now walk the off / form / on sequence, and the multi-node guide gains a reference section covering which ports are public, how arming differs between the ISO and the binary installer, and how to verify membership landed. Re-enable the boot-time unit whenever the daemon arms the policy. Disabling the firewall to form a cluster also disables that unit, so re-arming used to look complete while leaving the node bare after its next reboot. * fix: make the ISO-to-cluster conversion path work end to end Forming a cluster from four ISO-imaged servers surfaced a run of bugs that share a starting state CI never exercises: the ISO delivers an initialized, armed, running node, while the conversion path was written against the binary installer's unconfigured one. - install-node.sh never disarmed the host firewall, so nodes 2 and 3 could not dial the first node on the OVN raft ports and formation could not proceed. It now owns the whole lifecycle: disarm, form, re-arm, then verify the loaded policy against the expected peer set. - spx admin init left the admin access key and secret empty on the preserve path. The pair cannot be read back, and the IAM store is rebuilt by formation, so the empty strings reached every joiner's bootstrap.json and crash-looped awsgw. It is reissued instead, and IAM seeding now skips an empty admin block rather than taking the gateway down on every restart. - node-reset.sh left /etc/default/ovn-central behind. Raft membership lives in that file, not in the databases the reset deletes, so ovn-central recreated the database as a cluster member dialling a peer that had itself been wiped. - node-reset.sh also destroyed the installed firewall policy, which nothing regenerates. set-peers then failed on every attempt and the node stayed open permanently and silently. The arming mode is read before the wipe and the stage regenerated after it. - spinifex-firewall-apply rejected every verb when the policy file was missing, including disable. Turning the firewall off is the recovery path, so that left a node that could be neither armed nor disarmed. - viperblock exited 0 on a fatal startup error, so Restart=on-failure never fired. During formation its JetStream bucket has no leader yet, so the EBS provider died for good and every volume request failed with no responders. predastore and qemunbd had the same bug. - spx admin images import created image directories at 0700, so the first sudo import locked group members out of a tree deliberately made group-writable. Three of these hid behind checks that cannot succeed: ovn-sbctl show against a clustered database, and the OVN northbound and southbound waits in setup-ovn.sh. All three failed to stderr and let the run continue, so a check that could never pass was indistinguishable from one that was merely slow. The USB install guide claimed the ISO leaves Spinifex unconfigured and told the operator to run spx admin init. firstboot has always done that itself, so the guide now describes what the ISO actually produces and how to start using it. * fix: let spread placement launch across every node A spread placement group reserved four distinct nodes correctly and then failed the launch with ServerInternal, having started only two or three of them. The scheduler was never at fault; two faults downstream stopped the instances following the reservation. vpcd subscribes to vpc.add-nat with QueueSubscribe, which delivers one message at a time, and the handler holds its reply across the OVN flows barrier. The 45s caller deadline was sized against a single 30s barrier, which is right for one instance and wrong for the N a spread launch issues at once — the third request waits behind two full barriers and times out. That one subscription now overlaps its handlers under a bounded semaphore. Each barrier still syncs after its own write, so the guarantee is unchanged while N barriers collapse into roughly one. With the requests overlapping, every barrier still ran to its alarm. install-node.sh computed OVN_REMOTE after building the database nodes and gave it only to compute nodes, so the database nodes were configured without --ovn-remote. setup-ovn.sh writes ovn-northd's NB/SB connections from that list and skips it on the localhost default, and it already documents what follows: a northd dialling only its local member stops advancing nb_cfg once raft leadership moves, wedging ovn-nbctl --wait=hv. The list is knowable before any node is touched, so it is computed first and passed to the database nodes too. Nothing reported an OVN fault while this was happening. Every chassis was registered, ovn-controller and IPsec were up, and the raft cluster was healthy. The only signal was the barrier logging that it had overrun and was continuing without confirmation — which reads like slowness and was a permanent wedge. * feat: sweep block sizes in the disk benchmark and add an iperf3 network benchmark * fix: use iperf 2 with CSV output and report why a remote start failed * fix: stop pkill matching its own shell and verify the iperf server is listening * ci: run the predastore throughput benchmark at the end of the nightly * ci: boot the ISO in the nightly, single-node and three-node * ci: use the existing CI node password secret in the ISO cells * ci: report free space before the benchmark instead of failing inside warp * ci: keep the benchmarks and node disks off tmpfs * ci: export the work directories from RUNNER_TEMP rather than job env * ci: run the ISO and benchmark workloads from the nvme scratch area * perf: run guest NICs on vhost-net with multiqueue Guest-to-guest VPC throughput measured 1.68 Gbit/s single-stream against 21.8 Gbit/s host-to-host on the same underlay, and did not improve with more streams. QEMU's -netdev tap defaults vhost to off, so the whole datapath ran in the main loop thread in userspace: that thread sat at 59-65% CPU while all four vCPU threads idled at ~4%. Every tap netdev now carries vhost=on, and VPC ENIs additionally run multiqueue at min(vCPUs, 8) queue pairs. Multiqueue needs all three of the tap, the netdev and the device to agree, so TapNetDev and NetDevice derive the netdev options and the 2N+2 MSI-X vector count from one queue figure rather than leaving callers to keep them in step. The QMP hot-plug path takes the same options as cold boot, with a test comparing it against the rendered cold-boot strings so the two cannot drift. MMIO machines stay single-queue: they have no MSI-X. * ci: check out the sibling repos the go workspace needs in the ISO cells * ci: skip cell-21 workload cleanup when the workload never ran * ci: size the cell-21 node at 8 GiB and keep its serial log * ci: keep the cell-21 node diagnostics alongside the serial log * fix: let the daemon open /dev/vhost-net and delete multi_queue taps Enabling vhost=on broke instance launch two ways. DevicePolicy=closed gates the cgroup device list before capabilities are consulted, so QEMU's open of /dev/vhost-net returned EPERM despite CAP_DAC_OVERRIDE; add the device to the allow list and bump the unit version. Separately, `ip tuntap del` re-opens the device with TUNSETIFF and fails with EINVAL on a multi_queue tap, leaking it on every teardown; route deletion through `ip link del`, which is flag-agnostic. * perf: default guest NICs to a single queue Multiqueue measured a net loss. Spreading one flow across queue pairs reorders packets and TCP reads that as loss: a 4-vCPU guest fell from 1.76 to 1.50 Gbit/s, with cwnd collapsing on spurious retransmits. The host overlay funnels a node pair onto one softirq core, so the extra queues have no headroom to win back what the reordering costs. Keep the plumbing and its tests behind MultiqueueNICs so re-enabling is one line once that funnel is fixed. vhost-net stays on unconditionally; it moves the datapath off the QEMU main loop, measured at 60% of a core under load against 3% with it. * fix: raise the UDP receive buffer for predastore's QUIC transport Predastore carries blob, meta and raft over QUIC and quic-go asks for a 7MiB receive buffer. Left at the kernel default of 208KiB it silently dropped datagrams under load: the four-node cluster had shed 80k-125k each, which failed shard writes, put raft into repeated elections, and ultimately handed guests an I/O error that cost two of them their root filesystems. Adds a sysctl stage writing /etc/sysctl.d/99-spinifex-net.conf, so the setting lands in the ISO image and on every node push rather than living in a runbook. * ci: give the cell-21 workload an identity the node accepts * feat: tie the guest MTU and NIC multiqueue to ipsec_enabled ESP costs 34 bytes on top of geneve's 58, so a cluster running the overlay in plaintext can advertise 1442 instead of 1408 — worth roughly 10% of guest throughput. Derive it from network.ipsec_enabled rather than hardcoding the conservative figure. Multiqueue moves with the same flag, because its sign depends on it. Behind IPsec it costs ~12%: ESP has no L4 ports, so RSS funnels a node pair onto one core and extra queues only reorder packets, which TCP reads as loss. Without IPsec the sending host's single vhost thread saturates first and queues are worth +54%. IPsec on with multiqueue on is the worst of the four combinations, so it stops being a standalone knob and becomes vm.Deps.MultiqueueNICs. The reconciler only ever created a subnet's DHCPOptions row and never revisited it, so the create-time MTU stuck for the life of the subnet and this change would have applied to new subnets only. Worse in the other direction: turning IPsec back on would have left subnets advertising 1442 over ESP, which drops large segments with no ICMP to recover from. applySubnets now diffs and updates in place. reconcile.Config takes IPSecDisabled rather than IPSecEnabled so the zero value is the conservative MTU — a caller that forgets it is merely slower. * docs: add an install-time performance tuning guide Measured on the four-node cluster rather than inferred: the UDP receive buffer sysctl, what IPsec actually costs and why, the multiqueue sign flip, the overlay MTU budget, and the jumbo-frame check that must precede enabling it. A starter doc — several sections end in an open question rather than a recommendation. * ci: keep the cell-21 node alive for the workload step * ci: collect the cell-21 qemu log and widen its timeout * feat: derive the guest MTU from the fabric, and deepen the virtio NIC config The overlay overhead is passed on to the guest rather than hidden from it. Hiding it means running the fabric far enough above 1500 that a standard guest MTU fits in the headroom, which is what the large public clouds do — but they own the switches. On a fabric we do not control, the honest figure is the one the path can carry, and a jumbo underlay should reach the guest: 9000 gives 8942, or 8908 with IPsec. network.underlay_mtu is the lever; SubnetMTU spends it. Configured rather than probed, because a node's own NIC MTU says nothing about the switch between it and its peers. host_mtu sets VIRTIO_NET_F_MTU so a guest that never takes a DHCP lease — statically addressed, or IPv6-only — still learns the ceiling. rx/tx_queue_size raise the virtio ring from QEMU's default 256. That default is a packet-rate ceiling rather than a memory saving: a vCPU preempted for a fraction of a millisecond fills all 256 slots and the overflow is dropped. ethtool is the only way to read NIC offload, ring and channel state, so a node without it cannot be diagnosed for throughput at all. * ci: give the cell-21 workload its own guest key * fix: set the guest MTU on the tap, not just in the guest The tap was created and brought up without an MTU, so it stayed at the kernel default of 1500 while DHCP and host_mtu told the guest something else. Harmless at 1442; it silently blackholed every large frame on a jumbo underlay, with no ICMP back because the drop is at the first hop. TapSpec.MTU comes from the same guest overlay MTU the DHCP option and host_mtu already use, and is applied in the bring-up call so a size the fabric cannot carry fails the launch instead of degrading quietly. * fix: stop setting tx_queue_size, which QEMU caps at 256 for tap QEMU only honours a tx_queue_size above 256 for vhost-user and vhost-vdpa backends. On a tap it rejects the value outright rather than clamping it, so every launch died with "must be a power of 2 between 256 and 256" and the instance went straight to terminated. rx_queue_size is unaffected and stays at 1024. A test pins the absence of tx_queue_size across machine types and queue counts. * docs: lead the tuning guide with the overlay segmentation finding The guide's headline was a 5.4x that came almost entirely from turning IPsec off, and it treated MTU and the fabric as the main levers. The host reaches 92.6 Gbit/s at MTU 1500 on the same NIC, so the fabric is not the constraint and the encrypted default is not the thing to tune away from. Adds the host-versus-guest comparison up front, documents network.underlay_mtu, and makes the missing segmentation offload the first open question. * ci: stop deselected matrix cells failing in teardown * docs: quantify what disabling overlay IPsec is worth The guide described the trade without the numbers an operator needs to make it. Adds the measured 4.9x, notes that the MTU and multiqueue changes follow ipsec_enabled rather than being separate knobs, and records two transition hazards: a stale wide MTU on running guests, and RunInstances failing while the OVN flows barrier catches up with the new SAs. * ci: collect and retain the e2e benchmark and cluster logs Cells 21 and 22 both copied two paths that only ever exist on the nodes, so the benchmark JSON was never uploaded and cell-22 collected nothing at all. Both now gather what they actually produce, and keep it for 90 days. * fix: quieten spx by installing an explicit CLI logger default spx never set a process logger, so it inherited whatever a linked package left behind — until now a JSON handler at Info on stdout, interleaving library log records with command output and breaking piped use. Execute() claims the default before any command runs: text on stderr, LevelError, so commands report failures through their own stderr writes and libraries stay quiet. --verbose/-v raises to info and SPX_LOG_LEVEL sets an arbitrary level, the flag winning over the environment. Service subcommands still call initTelemetry, which replaces the handler outright. No root --debug flag: viperblock, qemunbd, nats and awsgw each define their own --debug with a service-specific meaning, and a root persistent flag would shadow inconsistently depending on the command. The guard test samples the handler at package-init time rather than inside the test, because tests in this package start services that install their own logger legitimately. * feat: private /admin/CreateAccount for self-service tenant signup Add POST /admin/<Method> to the AWS gateway: SigV4-signed, JSON in and JSON out, callable only by an IAM user in the super-admin account holding spinifex:<Method>. CreateAccount is the one method, so a signup form can provision a tenant without an operator shell. No new service, port, unit or certificate — it mounts inside the gateway's existing authenticated group and inherits its auth, throttling and tracing. Provisioning is resumable rather than transactional, which fits stores that have no transaction. Two CAS creates carry the correctness: the client token admits one in-flight attempt and makes a lost response replayable for 24 hours, and the name reservation makes duplicate account names impossible. Every step after the account exists is create-if-absent, so a retry with the same token finishes the job instead of failing. The CLI and the endpoint share one provisioning helper, which closes a gap on both at once: CreateAccount never checked names, so running `spx admin account create` twice produced two accounts that differed only by ID. The response waits for the account's default VPC over a new ec2.EnsureDefaultVpc request/reply, rather than trusting the existing fire-and-forget iam.account.created publish — credentials for an account that cannot launch anything are worse than a slower call. [signup] max_accounts bounds how many accounts may exist; absent means uncapped, which is what every cluster does today. * fix: stop the awsgw template hardcoding one deployment's console URL console_url shipped as https://console.spx3.com, so every fresh install — including an on-premise cluster that will never run signup — was configured to point new accounts at our console. It is the only deployment-specific domain in any template. It now ships empty, and the gateway warns when it provisions an account without one, since a blank sign-in link is otherwise visible only to the customer who receives it. Extract the remote client from the command body while here. The signing, request shape and error decoding are the part a Cloudflare Worker mirrors, and as a function they are testable against a TLS test server rather than only by hand against a live cluster. * refactor: drop console_url from signup and default max_accounts to 128 The gateway never read console_url — it passed the value straight through to the response, and the idempotency record froze it for 24 hours so a corrected typo still replayed stale. The client that made the request already knows where it wants to send the new tenant. max_accounts is now a pointer in the parsed config so an absent [signup] section takes the 128 default while an explicit 0 still means uncapped. * feat: run the predastore fault-injection harness as cell-24 Cell-23 asks how fast predastore is when every node is healthy; cell-24 asks whether it survives one that is not. It runs after cell-23 rather than beside it: both want a quiet single runner, and a benchmark sharing a machine with a fault injection run measures the wrong thing. The port offset keeps the two clear of each other even so, and the job clears stale nodes on entry and exit, since a run killed before its cleanup trap leaves one holding ports that fail the next run somewhere unrelated. * ci: keep the throughput benchmark's output with its results The run log only existed in the job log, so the artifact it uploaded could not be read without going back to the run that produced it. * ci: keep the fault-injection run log with its results events.txt carries the timeline and the FAIL line, but not the build output or anything Warp wrote before the harness took over, so a failed cell could only be read from the job log it was printed into. * fix: serve the cluster region to the console instead of hardcoding it The console hardcoded ap-southeast-2 as its SigV4 region in seven files, so on any other cluster the credential scope was wrong and the gateway rejected every signed request. The SPA is embedded in the binary, so a build-time value would pin one binary to one region. The UI server now serves GET /api/config with the region, no-store so a proxy fronting several clusters cannot serve one the other's region, and the SPA loads it once before render. The region comes from the serving node's config because awsgw pins signature verification to that same field. Reading the cluster-wide [aws] region instead would let a cluster whose two keys disagree pass review and still fail to authenticate. Also relabels the login card as Spinifex credentials, since the fields are not AWS ones, and hides the CA install banner unless the console is reached directly: behind a proxy with a publicly trusted certificate there is nothing for the cluster CA to fix. * fix: say once when the host firewall will not be maintained Both quiet outcomes of the reconcile — no cluster config, and the policy switched off — return nil without logging, so a node that never arms is indistinguishable in the journal from one that armed on its first pass. * test: arm the host firewall before asserting on its peer set Only the ISO install arms the policy; every other path writes off to the mode file, so the daemon disables the firewall and never writes a peer set. The test read that file as its baseline, which it could never have. It now switches the mode on for its own duration and puts it back, waits for the peer set the way install-node.sh does, and on failure reports the mode, the node count and what the daemon said rather than just the missing file. * test: move the console region test to the external cmd package It was in package cmd, which test-package-check rejects, so preflight failed on the branch. The hook follows the pattern already in export_test.go. * test: make the reboot EIP diagnostic capable of naming the drop The two ofproto/trace probes injected packets with no TTL, so OVN's router killed them at lr_in_ip_input and both traces ended early for a reason that had nothing to do with the failure under investigation. A keyword filter then stripped the table-match lines, hiding where each trace stopped. Traces now carry a TTL and are kept whole, the real datapath megaflows for the guest reply are dumped alongside them, and any drop matching the guest source is resolved from its OpenFlow cookie back to the Southbound logical flow that installed it. * fix: exempt an EIP instance from the subnet drop gate with allow, not reroute A subnet with no route of its own carries a priority-1100 drop policy, and an instance with an external IP is lifted above it by a priority-1200 policy. That policy rerouted to the pool gateway, which in distributed NAT is outside every logical router port subnet, because the gateway LRP is the link-local /30. The static default route survives that by naming an output port; a routing policy has no such field, so ovn-northd discarded all three of them and the drop gate below swallowed everything the instances sent. The effect was that every external IP answered inbound traffic and none of it came back: the SYN reached the guest, the guest replied, and the reply died in the router's policy stage. Guest-initiated egress was lost the same way. The policy only ever needed to lift the gate. The router's default route already points at the gateway, so allow leaves the routing decision intact and gives northd nothing to reject. * test: match the log the firewall quorum gate actually emits The assertion waited for "chassis encap addresses; not writing a partial peer set", which no code has ever logged. The reconcile reports a short chassis list as "OVN reports N of M chassis encap addresses" and the maintain loop carries that into its retry warning, so the wait could only ever time out. Arming the node in the previous commit got the test as far as this assertion for the first time, which is why it surfaced now. The failure also prints the journal tail and the same inputs the earlier wait reports. * fix: stop one unreadable volume document failing every volume listing A single volume document whose shards no longer reconstruct made DescribeVolumes, DescribeVolumeStatus and DescribeVolumesModifications fail for every account, because the listing returned the first fetch error rather than skipping the document. ListVolumes now skips a document it cannot read or decode and logs the skip, mirroring ListAMIs. Callers whose answer would be wrong rather than merely partial take ListVolumesStrict: the orphan scan and the snapshot in-use check both gate destructive work on a complete list. The tolerance covers fetch failures as well as decode failures. An object whose shards no longer join is as unusable as one whose bytes will not parse, and it was the fetch path that took the cluster down.
13 KiB
13 KiB
title, description, category, tags, resources
| title | description | category | tags | resources | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Performance Tuning | Kernel, overlay and guest NIC tuning for Spinifex clusters, with measured results. | Install |
|
|
Performance Tuning
A starter guide. Everything here is measured on a four-node cluster rather than inferred, and every number states the configuration it came from. Expect this to grow — several sections end in an open question rather than a recommendation.
Test rig for all figures below: 4 nodes, AMD EPYC 7513 (128 threads), Mellanox
ConnectX-5 (MT27800) on a 100 GbE fabric, t3.xlarge guests (4 vCPU), Ubuntu 26.04,
kernel 6.12. Throughput is iperf between guest private addresses over the VPC
overlay, 4 streams, 60s.
Read this first: the dominant cost is not on this page
The single largest gap between a guest and its host is not any tunable below. It is that the VPC overlay currently gets no hardware segmentation offload, so the host CPU segments every guest packet in software.
Measured with the same script, same parameters, on the same NIC and switch, three clients into one server at 4 streams each:
| Host, on the underlay | Guest, over the VPC | ||
|---|---|---|---|
| aggregate | 92.6 Gbit/s | 17.6 Gbit/s | 5.3x |
| frame on the wire | 1518 B | 1518 B | identical |
| TSO super-packets | 4,165,267 | 0 | |
| wire packets per descriptor | 39.3 | 1.0 |
The guest's own offloads are fine — its GSO super-packets reach the host intact at ~64 KB. They are then broken into individual 1518-byte frames in software between the tap and the NIC. The cause is under investigation and is not yet fixed; it is independent of IPsec, and it is larger than every item in the table below combined.
Until it is resolved, treat the figures on this page as tuning within a constraint, not as the ceiling.
Summary — what moved the needle
| Change | Effect |
|---|---|
| UDP receive buffer sysctl | Fixes storage faults. No throughput change. |
| vhost-net on the guest NIC | QEMU main loop 60% of a core → 3%. No throughput change on its own. |
| Guest NIC RX ring 256 → 1024 | Removes a drop source under burst. |
| Guest NIC multiqueue | −12% with IPsec on, +54% with IPsec off |
| IPsec off (trusted links only) | 2.5x — see the warning in §2 |
| Guest MTU 1408 → 1442 | ~10%, and only valid with IPsec off |
| Jumbo frames | Untested end to end. Needs a switch that carries it. |
On a trusted-fabric configuration (IPsec off, multiqueue on) mean per-client throughput went from 1.23 Gbit/s to 6.64 Gbit/s and aggregate into one guest from 3.69 to 19.92 Gbit/s. That 5.4x is relative to an encrypted baseline — it is mostly the cost of encryption being removed, not tuning headroom being found. The default, encrypted configuration is the one most clusters should run.
1. Kernel tunables (sysctl)
Applied automatically by setup.sh's sysctl stage to
/etc/sysctl.d/99-spinifex-net.conf. Documented here because it is load-bearing and
because the failure mode it prevents is severe.
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
Predastore carries blob, meta and raft traffic over QUIC, and quic-go requests a
7 MiB UDP receive buffer. At the kernel default of 208 KiB it gets 416 KiB and
silently drops datagrams under load. On a cluster that had been running at the
default, the four nodes had shed 80k–125k datagrams each to UdpRcvbufErrors.
The consequence is not a slow cluster, it is a broken one: dropped datagrams fail
QUIC streams, which fail erasure-coded shard writes, which exhaust viperblock's retry
budget, which returns EIO to the guest, which aborts its ext4 journal and remounts
read-only. Two guests lost their root filesystems this way before the cause was found.
Verify with:
nstat -az | grep UdpRcvbufErrors # must not advance under load
journalctl -u spinifex-predastore | grep 'receive buffer size' # must be silent
2. IPsec on the overlay
Spinifex encrypts the geneve overlay with OVN native IPsec by default
(ESP transport mode, rfc4106(gcm(aes)) 128). This is the right default and matches
the AWS trust model. On a physically trusted fabric it is also the single largest
performance cost in the stack.
Why it costs so much
Not raw crypto throughput. The problem is CPU scaling.
ESP wraps each geneve packet in an outer IP header with protocol 50, which has no L4 ports. A NIC's receive-side scaling can therefore only hash on the source and destination IP, so all traffic between a given pair of nodes lands in one RSS bucket and is processed by one CPU core. Without ESP the outer header is UDP 6081 and OVN varies the source port per inner flow, which spreads across every core.
Measured on the receiving host during a transfer:
| busiest core | spread | |
|---|---|---|
| IPsec on | 97.4% busy, 71.8% softirq | 1 core above 15%, on a 128-thread box |
| IPsec off | 19% of NET_RX | 16 cores sharing it, none above 15% |
Things that do not fix this:
- ConnectX-5 has no IPsec crypto offload. ASAP² handles OVS flow offload but IPsec inline crypto needs ConnectX-6 Dx or BlueField. Not available on this hardware.
- RPS/RFS. The Linux flow dissector can hash ESP by SPI, but OVN creates one SA per node pair per direction, so the SPI is constant for all traffic between two nodes and every packet still hashes to one bucket.
- More TCP streams. Throughput is flat in stream count with IPsec on — 1 stream and 4 streams give the same number, because they all funnel through the same core.
Genuinely promising but untested: pcrypt, which parallelises a single SA's crypto
across cores while preserving ordering. It requires the SA to be created with a
pcrypt(...) template, which OVN does not currently expose.
What disabling it is worth
Measured on the test rig, three clients into one guest, 4 streams each, 60s:
| IPsec on (default) | IPsec off | ||
|---|---|---|---|
| aggregate into one guest | 3.58 Gbit/s | 17.6 Gbit/s | 4.9x |
| per client | 1.19 Gbit/s | 5.88 Gbit/s | |
| guest MTU | 1408 | 1442 | applied automatically |
| NIC queue pairs | 1 | 4 | follows ipsec_enabled |
| busiest receive core | 97.4% | under 15%, spread over 16 cores |
The MTU and multiqueue changes are not separate knobs — both follow
ipsec_enabled on their own, because the sign of the multiqueue result flips
with it (see §3). Turning encryption off is the whole change.
This is the largest single lever available today, and the trade is explicit: all east-west guest traffic goes on the wire unencrypted.
Disabling it for trusted links
Only for topologies where the underlay is physically trusted — a single rack, a private VLAN, no untrusted tenant on the fabric.
In /etc/spinifex/spinifex.toml on every node:
[network]
ipsec_enabled = false
Then restart the daemon: systemctl restart spinifex-daemon. Confirm with
ip xfrm state | grep -c '^src', which must reach 0 on every node.
Note that ovn-nbctl set NB_Global . ipsec=false is not sufficient on its own —
the daemon reconciles that value, so a manual override is transient. Change the
config file.
Restart guests after changing this in either direction. The guest MTU moves
with the setting, but a running guest holds its DHCP lease for up to an hour and
its device-level host_mtu until it is stopped and started. Going from off to on
narrows the path from 1442 to 1408 while the guest still believes 1442, which
blackholes large segments until it is restarted.
Expect launches to fail for a minute or two after the change. Re-enabling
IPsec makes RunInstances return ServerInternal with vpc.add-nat timing out,
because the OVN flows-ready barrier cannot confirm while ovn-controller reprograms
every tunnel for the new SAs. It clears once ip xfrm state settles. The error
is reported as a capacity problem, which it is not.
3. Guest NIC: vhost-net and multiqueue
vhost=on moves the guest NIC datapath into a kernel thread instead of copying every
packet on QEMU's main loop. It is unconditional and not tunable. Its effect is
dramatic on CPU (main loop 60% of a core → 3%) and, on its own, zero on throughput
— because with IPsec on, the ESP funnel downstream is the binding constraint. It
matters once that funnel is removed.
Multiqueue gives the NIC one queue pair per vCPU. Its value depends entirely on whether IPsec is on:
| 1 client | 3-client aggregate | |
|---|---|---|
| single queue, IPsec on | 1.75 | 3.69 |
| multiqueue, IPsec on | 1.54 | 4.35 |
| single queue, IPsec off | 4.46 | 9.97 |
| multiqueue, IPsec off | 6.85 | 18.23 |
With IPsec on, multiqueue costs throughput. Spreading one flow across queue pairs
reorders packets and TCP reads that as loss — guest counters showed reordering:189,
dsack_dups:116 and ssthresh collapsing. There is no headroom to win it back
because the bottleneck is elsewhere.
With IPsec off it is worth +54%, because the bottleneck moves to the sending host's vhost thread, which is exactly what extra queues relieve. At single queue that thread sits at 99.9%.
Because the sign flips, multiqueue is not a knob of its own: it follows
ipsec_enabled automatically, off when IPsec is on and on when it is off. There is
nothing to set.
4. MTU
The overlay path
The guest MTU is advertised by DHCP and is 1408 with IPsec on, derived as
1500 − 58 (geneve) − 34 (ESP). With IPsec disabled the ESP term disappears and it
becomes 1442, worth roughly 10%. This follows ipsec_enabled on its own, and the
reconciler converges existing subnets on the next pass — a guest picks the new value
up at its next lease. To apply it immediately without waiting, renew in the guest
(dhclient -r && dhclient) or set it directly: ip link set enp0s16 mtu 1442.
Never widen it by hand on an encrypted overlay. Advertising 1442 over ESP is the failure this budget exists to prevent.
Jumbo frames — check the fabric first
Set network.underlay_mtu in /etc/spinifex/spinifex.toml to the figure the fabric
between nodes actually carries. It defaults to 1500. The guest MTU is derived from it
— 9000 gives a guest 8942, or 8908 with IPsec — and reaches the guest three ways: the
DHCP option, the virtio device's host_mtu, and the host-side tap. A running guest
needs a stop/start to pick up a new host_mtu.
Jumbo would substantially mitigate the software-segmentation cost described at the top of this page, because it cuts the descriptor count roughly sixfold. It does not remove it. Note that the 92.6 Gbit/s host figure above was measured at MTU 1500, so the fabric is not the binding constraint it was once assumed to be.
But the host NICs are only half the path. On the test cluster, raising both the
physical NIC and br-vpc to 9000 on all four nodes produced total packet loss above
1500 bytes — the switch was not configured for jumbo:
payload 1472 : 2 received <- 1500 MTU
payload 1972 : 0 received
payload 8972 : 0 received
Always verify before enabling, and revert if it fails — a host at 9000 behind a 1500 fabric black-holes every large frame, and an L2 switch sends no "fragmentation needed" back, so path MTU discovery cannot recover:
ip link set <dev> mtu 9000 # both ends
ping -M do -s 8972 -c 3 <peer> # must succeed
5. Measurement notes
Throughput on this stack is noisy — repeated identical 20s runs varied between 7.4 and 15.4 Gbit/s in the best configuration. Take medians of at least three runs before believing a change helped.
The likely cause is vhost and softirq threads migrating across 128 threads and two NUMA nodes. Thread pinning and IRQ affinity are the obvious next tuning avenue and have not been explored.
Useful commands:
# Where is the receive work landing? One hot CPU means a funnel.
awk '/NET_RX/{for(i=2;i<=NF;i++) printf "cpu%d %s\n", i-2, $i}' /proc/softirqs
# Is vhost saturated? 99% on one thread means add queues.
top -H -p $(pgrep -f qemu-system-x86_64 | head -1)
# Confirm the guest negotiated the queues QEMU offered.
ethtool -l enp0s16 # in the guest
Open questions
- Why does the overlay lose GSO between the tap and the NIC? The two candidates are the mlx5 driver declining to offload a Geneve-encapsulated GSO skb on this firmware, and something in the OVS datapath dropping GSO before the driver sees it. They are distinguishable by running the same measurement over a VXLAN tunnel, which takes a different path through the driver's feature check. This is the highest-value open question on the page by a wide margin.
- Does
pcryptmake single-SA IPsec scale across cores, and can OVN be made to request it? - Would multiple SAs per node pair restore RSS spread while keeping encryption?
- How much does jumbo actually buy on a fabric that supports it? Untested.
- Does pinning vhost threads to the NIC's NUMA node remove the run-to-run variance?