The EU Cloud Sovereignty Framework breaks digital sovereignty into eight objectives and rates each on the SEAL scale. Your weakest objective decides your grade, not your average. So a single closed component can cap the score of everything built on top of it.

This talk takes one unglamorous layer and runs it through that test: highly available block storage.

The technical picture first. DRBD replicates block devices synchronously across nodes inside the Linux kernel, so a virtual machine or a container mounts what looks like a local disk while every write is committed on more than one node. LINSTOR orchestrates LVM, ZFS, and DRBD across a cluster and decides where replicas live. No proprietary appliance sits in that path; the replication runs on the same commodity servers as the workloads. The stack ships as LINBIT SDS with drivers for Apache CloudStack, OpenStack, Kubernetes, OpenNebula, Proxmox VE, and XCP-ng, which matters for the framework's lock-in objective: the storage layer does not decide which virtualization platform you can run.

Then the audit. Using DRBD and LINSTOR as a worked example, open source and developed mainly in Austria, I go through the objectives one by one: which ones an open source component satisfies by construction, which ones it merely enables while the operator still has to do the work, and which ones it cannot help with at all.

The framing is European, but the questions are not. An operator in Asia or the Americas asks the same things in different vocabulary: Economic security, supply chain resilience, technological leadership. Attendees leave with a way to audit their own infrastructure component by component, rather than trusting a label.