FlashStore OSD op Proxmox VE: Wat Het Vergde op Eén Node

Een Rust-OSD, Op De Dag Dat Hij Uitkwam

croit zette FlashStore OSD op 9 november 2026 in public preview¹. Het is een Ceph-OSD, vanaf nul geschreven in Rust, met een eigen object store in plaats van BlueStore, en hij spreekt het Ceph-wireprotocol. De belofte is dat hij in een cluster past dat je al draait: je monitors, je managers, je ceph-CLI en je clients blijven zoals ze zijn, en je vervangt één schijf tegelijk¹.

Die belofte telt zwaarder voor een Proxmox-omgeving dan voor de meeste. Op een hyperconverged Proxmox VE-node installeer je Ceph niet apart. Het komt uit de Proxmox-GUI, uit de eigen repositories van Proxmox, gebouwd en gepatcht door Proxmox, en het geheel wordt aangestuurd door pveceph. Als een OSD van iemand anders daarin kan zitten zonder iets te breken, krijg je een nieuwe storage-engine zonder de tooling op te geven. Kan dat niet, dan merk je het op de harde manier, op een node die ook je VM’s draait.

Dus heb ik het geprobeerd.

Ik werk voor croit, dat FlashStore maakt. Daarom probeerde ik het binnen twee dagen na de release, en het is ook de reden dat hieronder niets wordt verzacht. Het is een preview, de README zegt dat hij “not yet recommended for production data” is¹, en dit is een verslag van wat het vergde op echte hardware, geen brochure.

Kort antwoord: het werkt. Acht FlashStore-OSD’s leveren op dit moment een RBD-pool aan een VM op een standaard Proxmox VE 9.2-node, HEALTH_OK. Het lange antwoord is dat het twee fixes kostte die de documentatie niet noemt, de ene vanwege de manier waarop Proxmox zijn Ceph-config opslaat en de andere vanwege de kernel van Proxmox, en de rest van deze post gaat over die fixes en hoe ze gevonden zijn. Wil je het alleen draaiend hebben, dan staat er tegen het eind een script dat alles doet, en het is op deze node gedraaid.

De Machine

Het lab is één node, pve2, op mijn thuisnetwerk, en het is een brakke Minisforum B550-mini-pc uit 2021. Ceph op één node is niet hoe je productie draait, en de CRUSH-regel verderop is de prijs daarvan, maar elke stap hier is hetzelfde op een node met buren.

De Optanes zitten erin omdat FlashStore twee harde eisen stelt waar veel schijven op zakken. De schijf moet bescherming tegen stroomverlies hebben, en de namespace moet 4096-byte-blokken gebruiken, als hele namespace zonder partities of bestandssysteem erop¹. FlashStore bevestigt een schrijfactie zodra die duurzaam op de schijf staat, dus een schijf die met een vluchtige cache over duurzaamheid liegt, wordt bij mkfs geweigerd³. Elke P4800X meldt in zijn Identify-gegevens geen vluchtige schrijfcache (vwc 0), en dat is de schijf zelf die zegt dat de cache geen bevestigde schrijfactie kan kwijtraken.

Daarmee is de mini-pc de beperkende factor in deze deep dive, niet FlashStore en niet de schijven. Acht cores betekent één per OSD en niets over, 58 GiB moet Ceph en de VM’s allebei voeden, en acht Optanes delen één PCIe 3.0-link omdat de APU niet meer te bieden heeft. Lees elk getal hieronder als wat deze machine toelaat.

Umbrella Of Niets

FlashStore wordt gebouwd voor één Ceph-release tegelijk. De branch bepaalt het: main spreekt Ceph 21.2.0 Umbrella, en een branch v20.2.4 spreekt 20.2.4 Tentacle⁴. De daemon controleert bij het starten de release van het cluster en weigert er een buiten zijn venster⁴. De pakketten op de releasepagina zijn gebouwd uit main, en de binary zegt dat zelf: croit-flashstore-osd 21.2.0 umbrella.

Proxmox VE 9 biedt drie Ceph-repositories, en maar één daarvan sluit aan.

Tentacle is de standaard van Proxmox, dus is dat de veilige keuze? Het is degene die niet werkt. De Proxmox-repository heeft Tentacle tot en met 20.2.5-pve1, en de Tentacle-branch van FlashStore mikt precies op 20.2.4. Umbrella in de repository van Proxmox is 21.2.0-pve1, dezelfde release waar main op mikt.

Proxmox verstopt niet wat Umbrella is. PVE/Ceph/Releases.pm noemt hem met unsupported => 1⁵, en de GUI-wizard zegt het in duidelijke woorden zodra je hem kiest.

“Technology Preview”, geen enterprise-repository, en de installer vraagt het in de terminal nog een keer, continue (y/N)?, voordat hij apt aanraakt. Dat is precies genoeg waarschuwing, en het is goed om het te lezen als uitspraak over de hele stack: een preview-OSD op een preview-release van Ceph.

De installatie is standaard Proxmox. Datacenter → Ceph → Install, versie Umbrella, repository No-Subscription, daarna het publieke netwerk en de eerste monitor.

Dertien pakketten bijgewerkt, 46 nieuw, 107 MB gedownload. Eén ding op die lijst is nieuw in Umbrella: ceph-osd-classic naast ceph-osd. Geen van beide wordt hier gebruikt, omdat er nooit een klassieke OSD wordt aangemaakt. Ongeveer een minuut later draaiden mon.pve2 en mgr.pve2, meldde ceph versions 21.2.0 … umbrella, en was de health OK, met nog niets om op te slaan.

Vier Schijven Op 512 Bytes

Vier van de acht Optanes waren doorgegeven aan een lab-VM en stonden nog op 512-byte-formaat, met oude ZFS-labels erop. Twee andere hadden het juiste formaat en dezelfde labels. De oplossing is voor beide simpel: haal ze van de VM af, formatteer naar 4 KiB, wis de labels.

De P4800X biedt 4096 bytes zonder metadata aan als LBA-formaat 3, wat nvme id-ns weergeeft als lbaf 3 : ms:0 lbads:12.

nvme format /dev/nvme0n1 --lbaf=3 --force --timeout=900000
wipefs -a /dev/nvme0n1
sgdisk --zap-all /dev/nvme0n1

De eerste poging mislukte, en een latere ook. Beide keren kwam nvme format terug met Interrupted system call en stond de schijf nog op 512 bytes. De kernellog geeft de reden:

nvme nvme0: I/O tag 0 (0000) opcode 0x2 (Admin Cmd) QID 0 timeout, reset controller
nvme nvme1: I/O tag 9 (0009) opcode 0x6 (Admin Cmd) QID 0 timeout, reset controller

Opcode 0x2 is Get Log Page en 0x6 is Identify. Geen van beide is de format. Een P4800X formatteert het hele medium, en dat duurde hier 345 tot 351 seconden per schijf. Zolang dat loopt, beantwoordt de controller geen andere admin-commando’s, dus alles wat de schijf een vraag stelt, moet wachten. Na de admin-timeout van 60 seconden geeft de kernel het op en reset hij de controller, en die reset maakt de format kapot.

De oplossing is elke format in een tijdelijke unit met een lange timeout te draaien, één schijf tegelijk, en de schijven met rust te laten tot hij klaar is:

systemd-run --unit=fmt4k /root/fmt4k.sh
journalctl -u fmt4k -f       # read progress from the journal, not from the drive

Zo is de journal de enige voortgangscontrole, en bereikt niets de controller. Daarna gaven alle acht 4 KiB in nvme list.

Het Pakket

De releasepagina heeft .deb- en .rpm-pakketten, met daartussen Debian 13 trixie, waar Proxmox VE 9 op gebouwd is². Eén build bedient elke distributie en vraagt glibc 2.34 of nieuwer⁶.

B=https://github.com/croit/ceph-rust/releases/download/snapshot-2026-11-10-0b6783237291
curl -LO "$B/flashstore_21.2.0+git.20261110063351.c5792750020e_debian-trixie_amd64.deb"
curl -LO "$B/sha256sums.txt"
sha256sum flashstore_*_debian-trixie_amd64.deb
grep debian-trixie/flashstore_ sha256sums.txt

Controleer het met de hand. sha256sum -c kan deze download niet controleren, omdat het checksumbestand hem debian-trixie/flashstore_…_amd64.deb noemt terwijl het asset flashstore_…_debian-trixie_amd64.deb heet. De hashes komen overeen, ce1fb352…26c8 aan beide kanten, dus het bestand is in orde en alleen de lijst loopt niet gelijk met de assets.

apt install ./flashstore_*_debian-trixie_amd64.deb
croit-flashstore-osd --version

croit-flashstore-osd 21.2.0 umbrella (build 0.0.0) git c5792750020e
net tiers: kernel (+rdma upgrade)

Hij installeerde netjes naast de eigen ceph-osd en ceph-osd-classic van Proxmox. Het pakket installeert alleen een minimale ceph-osd.target op hosts die er geen hebben⁶, en Proxmox heeft er al een, dus de FlashStore-units hangen aan dezelfde target als de klassieke zouden doen.

Drie dingen over het pakket die je moet weten voordat je ertegen scripts schrijft:

De middelste rij is belangrijk. De SPDK-tier, de NVMe-driver in user space die de schijf aan vfio-pci gebonden wil hebben, zit niet in het gepubliceerde Debian-pakket. Wat er wel in zit, is de kernel-tier: de schijf blijft op de eigen nvme-driver van de kernel en FlashStore praat ermee via io_uring. De broncode laat zien dat die erin gecompileerd is, omdat de feature knet kernel-nvme binnenhaalt⁸, ook al noemt de samenvattingsregel van de hostcheck hem “compiled out of this build”. Die regel klopt niet. Een lezer die hem gelooft, zou daar stoppen.

Wat De Hostcheck Zegt

croit-flashstore-osd --check is alleen-lezen en draait voordat er iets geschreven wordt. Hij controleert de build, CPU, geheugen, IOMMU, elke NVMe-controller, de NIC, de kernel en de config, en geeft voor elke bevinding de exacte fix⁹. Op deze node draaide hij 115 checks, en hij is goed: elke bevinding komt met het commando dat hem oplost, en dat scheelde een hoop zoekwerk.

Reken op de tweede FAIL. De check telt elke controller in de machine, en de boot-SSD heeft een schrijfcache, dus hij zakt voor de stroomverliestest, ook al markeert dezelfde check hem terecht als “in use, not a candidate”. De tutorial zegt dat exit 0 betekent dat er geen FAIL is⁹. Op elke host die van een consumenten-SSD boot, en dat zijn veel Proxmox-hosts, kan --check nooit exit 0 geven, wat je ook oplost. Schrijf je scripts tegen de regels per check, niet tegen de exitcode.

De tuning-WARN’s bleven staan. Elk daarvan vraagt een wijziging van de kernel-commandline en een reboot, en dit is een uitrol, geen benchmark. Ze zijn de juiste lijst om af te werken voordat iemand een getal van deze machine noemt.

Cores en hugepages voor acht OSD’s

FlashStore draait thread-per-core, en de check legt uit wat dat betekent: “one core = one shard/PG owner”, hoogstens 8 cores per OSD, en elke OSD-core op een eigen fysieke core in plaats van gedeeld met een SMT-sibling. Acht fysieke cores en acht OSD’s betekent één core per stuk, flashstore_lcores = 0 tot en met 7, met de SMT-siblings over voor Proxmox en de VM’s. Opnieuw gedraaid met dat in de config, markeert de check elk coreplan als OK.

Kijk nog eens naar de hugepages. De check vraagt 2048 MiB per OSD, wat de standaard --mem van de daemon is, dus acht OSD’s hebben 16 GiB gereserveerd nodig. Draaiend heeft elke OSD 512 MiB van zijn 2048 gebruikt. Dat klopt met de eigen ontwerpnotitie van croit voor de kernel-backend, die een kwart van --mem reserveert voor de payload-allocator¹⁰. Op deze machine, met alle acht draaiende OSD’s, staat er dus 12 GiB RAM als hugepages gereserveerd waar niets aankomt, op een host die ook VM’s moet voeden. Een storagenode zou zijn schouders ophalen. Op een Proxmox-node was dat geheugen een VM, en verderop wordt het ingekort tot wat de OSD’s gebruiken.

Mag Ik Vragen Waarom Hij ceph.conf Niet Kan Lezen?

Met de schijven geformatteerd, het pakket erop en de hostcheck in orde, wilde de eerste OSD niet starten.

croit-flashstore-tool: refused: /etc/ceph/ceph.conf: Permission denied (os error 13)

Op Proxmox is /etc/ceph/ceph.conf een symlink naar /etc/pve/ceph.conf, en /etc/pve is pmxcfs, het clusterbestandssysteem dat de config van elke node gelijk houdt. Bestanden daar zijn root:www-data 0640, en pmxcfs laat je dat niet per bestand veranderen¹¹. De eigen Ceph-daemons van Proxmox redden zich omdat ze als root starten, de config lezen en dan overstappen naar de gebruiker ceph, en dat is wat --setuser ceph --setgroup ceph op elke ceph-osd@-unit doet.

De unit van FlashStore start niet als root. Hij is User=ceph vanaf de eerste instructie, ExecStartPre inbegrepen¹², dus hij komt nooit aan het lezen van het bestand toe.

Mag ik vragen waarom een pakket dat voor Debian gebouwd is, voor een product dat als drop-in wordt aangeboden, niet getest is op het meest gangbare Ceph-platform op Debian-basis dat er is? Ik vraag niet wie. pveceph bewaart zijn config op pmxcfs, en elke FlashStore-OSD op een node die door pveceph beheerd wordt, loopt hier bij de eerste start tegenaan.

De daemon heeft het antwoord al ingebouwd. De broncode beschrijft een klassieke drop via --setuser/--setgroup: “started as root by a classic unit (--setuser ceph --setgroup ceph), the daemon becomes that user before it opens the store, a socket or a file”¹³. Een drop-in die de unit start zoals Proxmox zijn eigen OSD’s start, zou dus genoeg moeten zijn.

Bijna. Gestart als gewone root was de volgende weigering de schijf.

activate: device kernel:/dev/ng0n1 not ready: /dev/nvme0n1: Permission denied (os error 13)

De CapabilityBoundingSet van de unit laat CAP_DAC_OVERRIDE weg¹², dus root is gebonden aan gewone bestandsrechten, en de namespace-nodes zijn van ceph:ceph. Starten als root met de groep op ceph dekt beide: root is eigenaar van het configbestand, de groep ceph opent de schijf, en de daemon stapt over naar ceph voordat hij iets anders doet.

# /etc/systemd/system/croit-flashstore-osd@.service.d/pve-ceph-conf.conf
[Service]
User=root
Group=ceph
ExecStart=
ExecStart=/usr/bin/croit-flashstore-osd run --id %i --cluster ${CLUSTER} -f --setuser ceph --setgroup ceph

De daemon bevestigt de overstap in zijn eigen log: set uid:gid to 64045:64045 (ceph).

Er is een kortere fix, SupplementaryGroups=www-data, en die heb ik niet gebruikt. Die zou de OSD elk groepsleesbaar bestand onder /etc/pve laten lezen, niet alleen de Ceph-config. Een OSD heeft niets te zoeken in de rest van de clusterconfiguratie, en de drop-in hierboven geeft hem niets meer dan Proxmox zijn eigen OSD’s geeft.

Dan de device-nodes. De docs van FlashStore zeggen dat de namespace-node schrijfbaar moet zijn voor ceph, “(udev rule)”¹⁴, en het pakket levert er geen mee. Deze matcht de schijven op model, dus hij kan de bootschijf niet raken, wat de nummering ook doet:

# /etc/udev/rules.d/70-croit-flashstore-optane.rules
SUBSYSTEM=="nvme-generic", KERNEL=="ng*n*", ATTRS{model}=="Dell Express Flash NVMe P4800X*|INTEL SSDPE21*", OWNER="ceph", GROUP="ceph", MODE="0660"
SUBSYSTEM=="block", KERNEL=="nvme*n*", ENV{DEVTYPE}=="disk", ATTRS{model}=="Dell Express Flash NVMe P4800X*|INTEL SSDPE21*", OWNER="ceph", GROUP="ceph", MODE="0660"

Na udevadm trigger waren de zestien Optane-nodes ceph:ceph 0660 en bleef de SN750 root.

De Passthrough Die Deze Kernel Weigert

De kernel-tier heeft twee modi, en de node die je opgeeft, kiest ertussen. kernel:/dev/ngXnY stuurt NVMe-commando’s via io_uring rechtstreeks naar de schijf, wat croit kernel-cmd noemt. kernel:/dev/nvmeXnY doet O_DIRECT-reads en -writes op het blockdevice, kernel of direct genoemd¹⁰. croit mat kernel-cmd als sneller in elke cel die ze testten¹⁰, en de quick start van de README gebruikt hem zelf¹, dus dat heb ik geconfigureerd.

Met de rechten op orde stapte de daemon over naar ceph, las zijn config, en stopte bij de eerste read:

croit-flashstore-osd: --dev kernel:/dev/ng0n1: /dev/ng0n1: kernel-cmd fixed-buffer probe read: Errno(13)

Dezelfde probe was een minuut eerder geslaagd in activate, dat nog de capabilities van root had. De vraag is dus of deze kernel een proces zonder rechten I/O-commando’s door /dev/ngXnY laat sturen. Dat valt te beantwoorden zonder FlashStore, met dezelfde read via nvme-cli, als ceph:

Alle acht Optanes gaven hetzelfde antwoord, ook twee die ik nooit had geformatteerd of gereset, met de firmware van Intel in plaats van die van Dell. Het ligt dus niet aan de schijven en niet aan de formats van die ochtend.

Upstream zegt dat het zou moeten werken. In Linux 7.0 laat nvme_cmd_allowed() een proces zonder rechten een I/O-commando sturen als de Commands Supported and Effects-log van de schijf het als ondersteund markeert zonder bijzondere effecten, en eist alleen een schrijfbare open voor commando’s die data schrijven of veranderen¹⁵. De effects-log van de P4800X markeert Read als ondersteund, 00000001, en verder niets. De read is toegestaan.

De kernel van Proxmox is niet die van upstream. De changelog van deze build bevat een gebackporte fix op precies dit pad, CVE-2026-90227: nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed(), die op het eerste gezicht een andere ioctl betreft dan degene die ik testte. Ik heb niet vastgesteld welke wijziging in de 7.0.14-28-pve-kernel het verschil maakt, en ik ga er niet naar raden. Wat vaststaat, is het gedrag: op deze kernel wordt NVMe-passthrough-I/O zonder rechten geweigerd.

FlashStore heeft een terugvaloptie voor geweigerde passthrough, en die sloeg niet aan. De ontwerpnotitie van croit zegt dat een kernel-cmd-device, als Identify geweigerd wordt, terugvalt op directe I/O op zijn block-node en dat bij het starten meldt¹⁰. Hier is Identify toegestaan en Read niet, dus de terugval treedt nooit in werking en de OSD stopt in plaats daarvan.

Directe I/O maakt het niet uit. Het is één regel per OSD:

flashstore_store_backend = kernel

Daarmee kwam osd.0 op.

croit-flashstore-osd: store mounted (1 shards, replayed 4 txns in 16 ms)
croit-flashstore-osd: set uid:gid to 64045:64045 (ceph)
[    1.398] crush location set (create-or-move updating item name 'osd.0' weight 0.3359 at location {host=pve2,root=default} to crush map)
[    2.406] osd.0 is now active (up_from 10, map 10)

Actief in 2,4 seconden.

De OSD’s Voorbereiden En Starten

Elke OSD krijgt een sectie in de Ceph-config, wat op Proxmox betekent dat je /etc/pve/ceph.conf bewerkt, en dat mag gewoon met de hand.

[osd.0]
	flashstore_dev = spdk:0000:05:00.0
	flashstore_store_backend = kernel
	flashstore_lcores = 0

Het device wordt benoemd met zijn PCI-adres, niet met /dev/nvme0n1, en het voorvoegsel spdk: betekent hier geen SPDK. Met een kernel-backend ingesteld zoekt de daemon het adres bij elke start op in sysfs en vindt hij de huidige nodes van de controller¹⁰.

Dat doet er hier toe. De SN750-bootschijf was in oktober nvme7 en is nu nvme8, en de minors van de generieke nodes volgen de schijfvolgorde ook niet, met ng1n1 op minor 0 en ng0n1 op minor 2. Een config die /dev/nvme4n1 zegt, kan na een reboot naar een andere schijf wijzen. Een config die 0000:0b:00.0 zegt, kan dat niet.

Dan één commando per schijf, dat de store schrijft en de OSD bij de monitor registreert:

croit-flashstore-tool prepare --dev spdk:0000:05:00.0 --id 0

kernel-cmd /dev/ng0n1: fixed-buffer NVMe passthrough probe ok (IORING_URING_CMD_FIXED on)
mkfs: device lba 4096 B x 91573146 (375083606016 B), awupf 1 lba, vwc false, max_xfer 32 lba
mkfs: 1 store shards, WAL ring 4096 MiB each
osd.0 prepared in /var/lib/ceph/osd/ceph-0

Twee seconden, als root. prepare leest de bootstrap-sleutel uit /var/lib/ceph/bootstrap-osd/ceph.keyring¹⁶, die pveceph pas schrijft wanneer het voor het eerst een eigen OSD aanmaakt, dus zonder klassieke OSD’s moet je hem eerst ophalen:

ceph auth get client.bootstrap-osd -o /var/lib/ceph/bootstrap-osd/ceph.keyring

Zes schijven gingen in één keer door prepare. Twee werden geweigerd:

croit-flashstore-tool: refused: device is not empty (non-zero data in the first 8192 bytes); --wipe destroys it
croit-flashstore-tool: refused: device is not empty (non-zero data at 65536 bytes); --wipe destroys it

lsblk en blkid hadden die twee schijven allebei als leeg gemeld. Wat erop stond, was het tekstmetadatagebied van een LVM-volumegroep uit een eerder lab, allang verwijderd, met het label vooraan al op nul gezet. De probe van FlashStore leest de eerste 8 KiB en de gebieden op 64 KiB en 256 KiB¹⁷, verder dan de gebruikelijke tools kijken, en hij had gelijk. Een schijf weigeren waar ook maar iets op staat, tenzij je --wipe zegt, is precies wat een OSD-tool hoort te doen. Ze wissen is een beslissing voor wie de schijven bezit, niet voor de tool. Toen dat besloten was, bereidde --wipe beide in zo’n twee seconden voor, en ze kwamen erbij na de installatie verderop. Daarom tonen de schermafbeelding van het paneel en de cijfers van de installatie er zes.

Dan starten:

systemctl enable --now croit-flashstore-osd@0

ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         2.01535  root default
-3         2.01535      host pve2
 0   nvme  0.33589          osd.0      up   1.00000  1.00000
 1   nvme  0.33589          osd.1      up   1.00000  1.00000
 2   nvme  0.33589          osd.2      up   1.00000  1.00000
 3   nvme  0.33589          osd.3      up   1.00000  1.00000
 4   nvme  0.33589          osd.4      up   1.00000  1.00000
 5   nvme  0.33589          osd.5      up   1.00000  1.00000

Elke OSD zette zichzelf onder host=pve2 met device class nvme. Wat ze het cluster over zichzelf vertellen, is één keer lezen waard:

Het BlueStore-antwoord is bewust. flashstore_report_objectstore staat standaard op bluestore omdat klassieke monitors sommige features pas aanzetten als elke OSD het meldt, dus de standaard houdt een gemengd cluster werkend⁷. Het is niet waar, en dat is goed om te weten voordat je de metadata van het cluster leest en gelooft.

Wat Proxmox Ervan Maakt

Het OSD-paneel van Proxmox toont ze alle zes, up en in, class nvme, versie 21.2.0, 344 GiB per stuk. Het noemt ze ook FileStore.

FileStore is de object store die BlueStore heeft vervangen. Proxmox bepaalt het label in PVE/API2/Ceph/OSD.pm: heeft de metadata van de OSD een sleutel bluefs, dan is het BlueStore, en al het andere is FileStore¹⁸. FlashStore heeft geen BlueFS, omdat er geen RocksDB onder zit, dus hij meldt BlueStore in het ene veld en krijgt het label FileStore op grond van een ander. Geen van beide klopt. En het paneel is waar de meeste Proxmox-beheerders het eerst kijken.

De latency-kolommen staan in rust op 0 / 0. Tijdens de installatie hieronder meldde ceph osd perf commit-latencies van 0 tot 3 ms over de zes.

Start, Stop en Restart in het paneel sturen ceph-osd@N aan, de klassieke unit, en dat is niet wat er draait¹⁹. Daarom is het paneel een weergave van deze OSD’s, geen bediening. Gebruik systemctl … croit-flashstore-osd@N en de CLI voor alles wat de daemons raakt, en blijf hier ver weg van Create: OSD en Destroy.

Een Pool, Een Storage En Een VM Met Fisher-Price OS (Windows)

De eerste PG in het cluster, die van de .mgr-pool van de manager, stond op undersized+degraded zodra de OSD’s opkwamen. Dat komt door de ene node. De standaard replicated_rule zet elke kopie op een andere host, en er is één host.

ceph osd crush rule create-replicated replicated_osd default osd nvme
ceph osd pool set .mgr crush_rule replicated_osd

Een regel met failure domain osd en device class nvme²⁰ zet elke kopie op een andere OSD, en de PG ging binnen een paar seconden naar active+clean. Op een echt cluster met drie of meer hosts houd je de host-regel en sla je dit over.

Alles daarna is de Proxmox-GUI zoals altijd. Ceph → Pools → Create: naam flashstore, size 3, min size 2, regel replicated_osd, Add as Storage aangevinkt. Later ging hij naar size 2, min size 1, voor de belastingstest verderop.

Proxmox maakte de pool en de RBD-storagedefinitie in één keer aan, en flashstore verscheen in de boom met 654 GiB bruikbaar, wat de 2 TiB ruw gedeeld door drie kopieën is, minus overhead. 129 PG’s gingen naar active+clean, en de autoscaler bracht de nieuwe pool kort daarna van 128 naar 32.

De testgast is een VM met Fisher-Price OS (Windows). Dat is geen voorkeur, het is wat een groot deel van de klanten echt op hun Proxmox-pools draait, dus het is de belasting die telt: 16 GiB geheugen, 4 cores, een schijf van 60 GiB op flashstore met discard en iothread aan. Het is bovendien praatgraag richting de schijf en gaat er inefficiënt mee om, en daar gaat het juist om: een storagetest wil de gast die de schijf het zwaarst belast.

De pool elke tien seconden bemonsterd, gedurende de eerste vijftien minuten van de installatie:

Dat zijn de cijfers van een installer, met de VM en de OSD’s op dezelfde host en de tuning-WARN’s onaangeroerd, en ze zeggen niets over de snelheid van FlashStore. Wat ze wel zeggen, is dat een klassieke Proxmox-client een installatie van een besturingssysteem op Rust-OSD’s heeft gezet, 35 GiB ruw, zonder fout, en dat is de bewering die deze post wilde testen.

Wat Het Doet Onder Belasting

Een installatie bewijst dat het werkt. Het vertelt je niet hoe de VM in gebruik aanvoelt.

Dus kreeg de VM CrystalDiskMark 9.0.3²¹, drie keer: het profiel Real World Performance [+Mix], Read&Write [+Mix], een bestand van 16 GiB op C: en een mix van 70% lezen en 30% schrijven, één keer met drie passes en twee keer met negen. Dat profiel stuurt alles één verzoek tegelijk af op één thread, en dat is wat een desktop of een kleine database echt doet, niet wat een datasheet doet.

Inmiddels was de opstelling sinds de installatie veranderd. De VM had zes cores, en de pool was in de GUI omgezet naar size 2, min size 1 en 256 PG’s. Size 2 met min size 1 is een labinstelling op één machine: met nog maar één kopie blijft de pool writes aannemen die één enkele storing daarna kan kwijtraken. Overal anders: houd 3 en 2 aan.

De disk stond op de standaard van Proxmox, geen cache, wat sinds Proxmox 2 de standaard is²².

Writes en de latentie van kleine blokken blijven van run tot run binnen ongeveer 1%. Sequentieel lezen stijgt over de drie met 45%. Dat is het eerste teken dat de leeskolom niet meet waar hij op lijkt.

De host werd tijdens alle drie elke vijf seconden gesampled, uit /proc/diskstats voor de acht Optanes, ceph status voor de pool en /proc voor elk proces en elke thread, en die twee beelden vertellen niet hetzelfde verhaal.

Writes: De Disk Is Het Kleine Deel

De disk is minder dan 5% van een kleine write. De overige 393 µs is de reis: QEMU, librbd, de messenger naar het OSD, het OSD zelf en het wachten op de tweede kopie. Niets daarvan is hier apart gemeten, dus ik zet niet op elk stuk een eigen getal. Wat het wel zegt, is dat op deze machine de Optanes niet de grens zijn voor I/O die één voor één komt, en dat een snellere disk die 410 niet veel zou verschuiven. De grens ligt nu bij de client, de librbd die Proxmox meelevert, en daar komt meer over zodra croits eigen librustyrbd hier draait.

Lezen: De Cache, Niet De Optanes

In de laatste run deed de random read van 4 KiB 5.700 reads per seconde over het hele bestand van 16 GiB, en de acht Optanes lazen helemaal niets. De sequentiële pass haalde 2,2 GB/s op de pool terwijl de reads van de disks zelf van 755 MB/s naar nul zakten. CrystalDiskMark gaat om de cache van de gast heen en de disk heeft er in QEMU geen, dus het geheugen dat het werk doet zit in de OSD’s. flashstore_obj_cache staat in deze build standaard aan, het deel van het bestand per OSD is bij size 2 zo’n 2 GiB, en elk OSD was gegroeid tot ongeveer 2,6 GiB. FlashStore rapporteert zijn hits niet, dus noem het bijna zeker in plaats van bewezen. Daarom steeg sequentieel lezen ook bij elke run: meer van het bestand was er al. Lees de leeskolom als een cachecijfer, niet als een cijfer van de store.

CPU: Waar De Cores Heen Gingen

De drie kolommen van de VM komen uit haar threads: QEMU geeft de vCPU’s van de gast een naam, en de messenger- en workerthreads van librbd draaien in hetzelfde proces.

De OSD-kolom beweegt nauwelijks. Acht pollende OSD’s kosten 3,3 cores als ze niets doen en 3,9 op vol vermogen, dus op een machine met 16 threads is een vijfde van de CPU weg voordat een VM ergens om vraagt. Niets anders kwam in de buurt van zijn grens. De drukste losse thread was een vCPU van de gast op 47%, en de drukste van librbd bleef onder 15%. Bij één verzoek tegelijk is de grens het wachten, niet het werk, en een CPU-cijfer kan geen wachten laten zien.

Geheugen: Reken Op De Piek

De hugepage-regel is de budgetsectie opnieuw, dit keer onder belasting: 512 MiB per OSD, en de andere 12 GiB nooit aangeraakt.

Gewoon geheugen is het getal om in de gaten te houden, want de cache hierboven bestaat eruit. Zodra een read het bestand had binnengehaald, stond elk OSD op zo’n 2,5 GiB, en dit hield Ceph vast op een host van 58,7 GiB:

Het komt terug, maar niet volgens een schema dat ik kon zien. Het bleef 25 minuten op 19,9 GiB, pauzes meegerekend, zakte toen aan het eind van de laatste run naar 13,9 GiB, en de host had weer 10,2 GiB om uit te delen. osd_memory_target stond bij dit alles op de standaard van 4 GiB per OSD, dus acht OSD’s hadden recht op 32 GiB voordat er ook maar één hugepage geteld is. Op een node die ook VM’s moet draaien, is de piek het budget om uit te rekenen vóór de disks, en daar doen de 12 ongebruikte GiB aan hugepages het meeste pijn.

Drie VM’s Tegelijk, Met Een Krapper Budget

Eén VM laat ruim plaats. Bij drie moet het budget kloppen. Dus veranderden eerst twee instellingen.

ceph config set osd osd_memory_target 1073741824   # 1 GiB per OSD, was 4
sysctl -w vm.nr_hugepages=2048                     # what eight OSDs use, was 8192

Het doel heeft verder niets nodig: elk OSD meldde de nieuwe waarde binnen enkele seconden, en ze werden toch één voor één herstart, met alle 257 PG’s terug op active+clean voor de volgende. De hugepages hebben een addertje. Voor elke OSD-start wil croit-flashstore-prep een hele --mem vrij hebben, 2048 MiB, en vergroot de pool als die tekortschiet, maar verkleint hem nooit meer. De herstart van osd.7 na het inkorten trok de pool meteen weer omhoog:

croit-flashstore-prep[7]: hugepages 2048kB: free 256 < need 1024, nr_hugepages 2048 -> 2816

De ondergrens die een herstart of reboot overleeft, is dus wat de OSD’s gebruiken plus de marge voor één start: 2.816 pages, 5,5 GiB, tegenover de 16 GiB die de check vraagt. Het installatiescript hierboven reserveert nu precies dat. Opnieuw inkorten naar 2.048 zodra alle acht draaien, levert tot de volgende herstart nog 1,5 GiB op.

Daarna draaiden drie klonen van de VM, elk met 10 GiB, tegelijk CrystalDiskMark: Real World Performance [+Mix], drie passes, maar op een bestand van 1 GiB per VM in plaats van 16 GiB. Daarmee is de leeskolom meer dan ooit een cachecijfer, dus lees de writes.

Drie VM’s haalden 2,3 keer de kleine writes van één, en elke VM betaalde daarvoor ongeveer 27% aan latentie. De Optanes waren nog steeds niet de reden. Ze piekten op 20.900 writes per seconde van elk 17 µs, dezelfde 17 µs als bij één VM, en de drukste van de acht was 14% bezet.

FlashStore houdt zich dus wel aan osd_memory_target. Op de piek van een read-pass ging het er 15% overheen en kwam het er weer onder, met de cache die zijn werk binnen het budget doet in plaats van erbuiten. Tussen het doel en het inkorten kregen de VM’s op dezelfde machine 26 GiB terug.

Drie gasten booten belastte de CPU zwaarder dan ze benchmarken. De storage eronder kwam er nooit bij in de buurt, en dat is de mini-pc die de grens bepaalt, zoals vanaf het begin vaststond.

Alles In Eén Script

Alles hierboven zit in één script. Geef het de PCI-adressen van de schijven die OSD’s moeten worden en het doet de rest, in de volgorde van deze post, met de twee Proxmox-fixes ingebouwd.

lspci -D -d ::0108                                    # find the drives
bash flashstore-pve-setup.sh --dry-run 0000:05:00.0   # show the plan, change nothing
bash flashstore-pve-setup.sh 0000:05:00.0 0000:06:00.0

Er wordt niets vernietigd tenzij je erom vraagt. --format-4k formatteert een schijf die niet op 4 KiB staat opnieuw, één tegelijk in een eigen unit zodat niets hem onderbreekt, en --wipe laat het een schijf met data overschrijven. --single-node voegt de regel replicated_osd toe, en een tweede run slaat schijven over die al OSD’s zijn.

Het is hier getest, niet alleen geschreven. Het weigerde de SN750 vanwege zijn schrijfcache, weigerde de schijf van osd.7 zolang daar nog een store op stond, en bouwde osd.7 daarna, gepurged en met zijn device nodes terug bij root, vanaf niets opnieuw op in 10,5 seconden, waarbij het zelf de backend kernel koos. Wat het niet doet, is Ceph installeren. Die stap vraagt je een Technology Preview te accepteren, en dat is jouw beslissing, niet die van een script.

Wat Gerepareerd Moet Worden

Niets hiervan houdt een vastberaden beheerder tegen, en alles hiervan houdt een drukke tegen. Elk punt is een uitspraak die croit doet aan iedereen die het pakket downloadt, en op elk ervan liep ik bij de eerste poging.

Niets hiervan is nieuw werk. De daemon heeft de privilege drop, de directe backend en de terugvallogica al. Ze zijn alleen nog niet aan elkaar geknoopt voor het platform waar de meeste mensen hem als eerste op zullen proberen.

Een Preview Is Waar Je Dit Ontdekt

Een preview is de juiste plek voor al die bevindingen, en de verkeerde plek om ze te laten liggen. Daar is een preview voor: iemand neemt hem mee naar huis, zet hem op de hardware die hij echt heeft, en schrijft op waar het omvalt. De onderdelen die ertoe doen, hielden stand. De store kwam in milliseconden op, de OSD’s gingen een cluster in dat met de tooling van een ander gebouwd was, en de installatie van een besturingssysteem ging erop zonder fout.

Wat het liet struikelen, was alles rond de daemon. Een configbestand op een bestandssysteem dat de unit niet kon lezen, een kernel die nee zegt tegen een aanroep die upstream toestaat, een bootschijf die de check niet ophield mee te tellen. Niets daarvan is moeilijk. Alles daarvan is het verschil tussen software die werkt en software die op jouw machine werkt, en de enige manier om dat te dichten, is testen op de machines die mensen hebben in plaats van op de machines die je ervoor gebouwd hebt.

Ondanks dat alles is dit een veelbelovend begin. Op een brakke mini-pc, met aan de clientkant nog de klassieke librbd en alle acht schijven op één PCIe 3.0-link, worden de Optanes hier harder aan het werk gezet dan onder BlueStore. Naarmate dit zich ontwikkelt, kom ik erop terug en graaf ik dieper, naarmate meer van de stack vervangen wordt, en met ook een blik op CephFS2.

“Drop-in” is een belofte aan een beheerder die geen tijd heeft om de broncode te lezen. De monitors van Proxmox, de GUI van Proxmox, de kernel van Proxmox en een pakket van iemand anders: dat is precies de situatie waar die belofte voor bedoeld is. Hij houdt hem nu bijna. Negen kleine fixes en hij houdt hem wel, en ik ben liever degene die ze op een woensdagochtend vond dan een klant die ze op een vrijdagavond vindt.