PCSCoherent StorageV10 Download source
Menu
OverviewArchitectureSimulatorImpactADR browserGlossaryFAQDownload source

ADR-MODELED SPATIAL ARCHITECTURE

One logical contract.
Peel back the system.

Follow an authorized inference request from TLS at the HAProxy boundary through OpenAI/OpenAPI translation and the Coherence-CE mesh, then down into accelerator memory, dual-rail RDMA, DPU-mediated NVMe-oF, and mirrored OpenZFS.

LAYER PEEL / SPATIAL SYSTEM VIEW

Client intent to durable NAND

See every contract and physical boundary in the request, memory, fabric, and persistence path. Move inward one responsibility at a time, then inspect only the implementation detail needed for the current question.

CLIENT EDGEDRILL INWARDEVIDENCE CORE
02 / ACTIVE RESPONSIBILITYLogical service and policy

Translates OpenAI-compatible requests into Coherence namespaces, placement, admission, and durability policy.

The contract firewall prevents DPU, vdev, QP, VLAN, CXL, and namespace selectors from crossing upward.

CONTEXT-DRIVEN DETAIL

Open only the drawing you need.

Control, transport, and consumer interfaces remain available as coordinated overlays instead of competing for attention in one all-at-once diagram.

CONTROL-PLANE OVERLAYDeclare intent. Reconcile capability.

Versioned intent becomes a capability-aware plan, provider calls, physical observations, and retained evidence.

OPERATOR / AUTOMATIONDeclarative request
->
01Versioned APIAuthN / AuthZ / audit
02Planner + reconcilerDesired vs observed state
03Capability registryProvider contracts and evidence
04Durable statePlans, events, rollback, optional Coherence roles
->
PROVIDER BOUNDARYExplicit support states
Host OS adaptersGentoo Linux | RHEL/Rocky Linux | FreeBSD
Storage + RDMANVMe-oF / iSER / pNFS / NFS RDMA
Fast pathVPP / OVS / QAT
DPU + remoteBF-2 / BF-3 / OFED / DOCA / DPDK / SPDK
PHYSICAL DEVELOPMENT LAB
RHEL/Rocky LinuxRPM / systemd / SELinux / kABIStorage targets + clientsRDMA fabricBlueField + QAT hardware

Enterprise-compatible host profile; qualify vendor drivers, kernel modules, SELinux policy, OpenZFS packaging, and lifecycle support. The OS profile changes packaging, drivers, services, and validation evidence, but not the logical client contract. Observations still flow back from every provider.

LAYER RESPONSIBILITY MATRIX

Where the design comes together.

Hardware, software, service, and protocol responsibilities remain separately observable even when they participate in one end-to-end request.

LayerPrimary responsibilityKey integrationSource
/v1/chat/completions / /v1/responses / Token streamingAPI token + tenant/project contextEngineering deep-dive
TLS ingress / authentication gate / rate limitingglobal -> region + region -> datacenterTop-down stack
REST validation / stream preservation / S3 mappingHAProxy -> gateway + gateway -> Coherence APIADR-012 API contract
lookup / publish / reserveAPI adapter + schedulerCoherence data path
lease / prewarm / throttleCoherence metrics + runtime capacityADR-007 scheduler
decode / prefix reuse / KV publishCoherence handles + GPU HBMADR-012 adapter
kv_hbm_active / kv_dram_warm / kv_cxl_warmruntime + Coherence placementADR-015 CXL tiering
collectives / accelerator memory access / pod-local exchangeruntime + scheduler localityPod-scale planes
remote hydration / replication / registered-memory transferCoherence + runtime stagingADR-004 RDMA paths
MR/QP fencing / tenant isolation / read steeringRDMA fabric + OpenZFS nodesADR-005 DPU boundary
checksum / snapshot / scrubDPU NVMe-oF + Coherence write policyADR-006 media layout
metrics / traces / timingevery data-plane layer + schedulerADR-009 observability
ADR

Architecture is inspectable, not decorative.
Every layer above maps to a repository decision or PlantUML source.

Browse full repository ->