Block storage
Block storage is the basis of modern virtualization and container platforms. I develop and operate scalable, redundant storage solutions based on open technologies such as Ceph and ZFS to provide data in a high-performance, secure, and traceable manner, independent of proprietary SAN systems.
The goal is to break down the traditional boundaries between storage, virtualization, and networking—moving toward a flexibly orchestrated storage landscape that can be fully automated and monitored.
Architecture & Concepts
I plan storage solutions that guarantee both high performance and reliability. I rely on scalable architectures with clearly defined redundancy and recovery strategies.
The decisive factor here is not the individual product, but the interaction between hardware, network, workload profile, and operating model. Architecture decisions are always made with a view to growth, maintainability, and future expandability.
- Ceph clusters (RADOS, RBD, RGW) for block and object storage
- ZFS pools with snapshots, deduplication, and replication
- Multipath, iSCSI, Fibre Channel, NVMe over TCP
- Integration into virtualization and container environments (KVM, Kubernetes, Docker)
Operation & Automation
I value reproducible setups and continuous monitoring. All storage components are automatically configured with Ansible and documented with versioning.
The goal is to achieve a consistent operating state across all nodes, which makes changes traceable and minimizes manual intervention. Automation not only serves to increase speed, but above all to ensure operational reliability and transparency.
- Automated provisioning of Ceph nodes via Ansible
- Integration with Foreman and Bookstack for system documentation
- Monitoring via Prometheus, Node Exporter, and Ceph Dashboard
- Self-healing mechanisms and alerting via Grafana/Alertmanager
Performance & Optimization
Depending on the application (VM, database, container), I optimize block storage specifically for I/O load, latency, and parallelism.
In doing so, I take into account typical access patterns, database characteristics, and the interaction with hypervisors or orchestration platforms. Performance optimization is measurable and traceable—not based on assumptions, but on real load profiles.
- Tuning of I/O schedulers and writeback caches
- NVMe integration and queue adjustments
- Network optimization (jumbo frames, LACP, RDMA)
- Benchmarking with FIO and Ceph benchmarks
Security & Recovery
For me, security also means data security – through redundancy, snapshots, and backups. I use open tools for backup, deduplication, and disaster recovery testing.
It is important that recovery is not just a theoretical concept, but is regularly tested and documented to ensure that it works reproducibly in an emergency.
- Snapshots and clones (ZFS, Ceph RBD)
- Backup integration with BorgBackup, Bareos, Proxmox Backup Server
- Encryption at volume or pool level
- Documented recovery scenarios (recovery playbooks)
Trainings
You can find specific trainings and current topics in the Comelio GmbH training catalog.
Available in-house at your company, as a webinar, or as an open training—designed to meet different requirements.
Frequently asked questions about Block Storage
In this FAQ, you will find the topics that come up most frequently in consultations and training sessions. Each answer is kept brief and refers to further content where necessary. Can’t find your question? Feel free to contact me.
Active-active or active-passive?
Stateless services scale well active-active behind LB/Anycast. For state (DB/queues), primary-standby with synchronous commit often makes sense (consistent writes, calculable RPO/RTO). Decision based on consistency requirements, latency, and maintenance windows.
How can I really prevent split-brain?
Quorum + fencing: Corosync/Pacemaker with qdevice/quorum tie-breaker, STONITH/watchdog, unique failure domains. For VRRP: Set preempt/skew cleanly, avoid asymmetric routing, health checks/runbooks for failover & failback.
Is HA sufficient, or do I also need DR?
HA covers individual failures/updates. DR addresses site/data corruption: offsite backups/snapshots (immutable), replication across zones/regions, regular restore/cutover drills. Both belong together, controlled by clear RPOs/RTOs/SLOs.
When does Ceph RBD make sense—and when doesn’t it?
Ceph RBD is suitable for scalable, distributed block storage with high availability, especially for virtualization and Kubernetes. It plays to its strengths in horizontal scaling and reliability. For small setups or latency-critical single servers, ZFS may be the simpler and more efficient choice.
ZFS storage or Ceph – how do I make the right decision?
ZFS is ideal for single systems or manageable clusters with a focus on data integrity, snapshots, and easy administration. Ceph scales better across many nodes and offers native high availability. The decision depends on scaling requirements, operating model, latency requirements, and existing expertise.