Storage Architecture

Storage Architecture

Storage architecture can be a complicated topic when working with (Bare Metal) Kubernetes clusters. There are a lot of War stories of organizations unable to restore their storage solution, e.g. in a complex RAID setup on in a distributed storage solutions such as Ceph, GlusterFS or StorageOS.

It took a significant amount of time to weigh the pros and cons of these solutions, but eventually I went for the “safest” solution, at least a solution which could not produce unrestoreable storage solutions as mentioned before:

  • Dynamically provisioned NFS storage in Kubernetes

Storage Tiers

A few predefined folder structures are used in this setup, each folder to simulate To simulate the behavior of more complex storage solutions:

- 1: Backed-up (High Availability)
- 2: Not Backed-up (Normal Availability)
- 1: Persistent, retained indefinite
- 2: Volatile, removed after 2 weeks
- 1: High speed SSD storage
- 2: Normal speed HDD Storage
- 3: Slower speed HDD storage

Generic Instances

Class CodeImplemented server(s)BackupVolatilitySpeedHostpathReclaim
1111: linux-wayne111/mnt/ssd/ha/<service_name>manual
2111: linux-wayne211/mnt/ssd/na/<service_name>automatic
2211: linux-wayne221/mnt/ssd/tmp/<service_name>automatic
1121: linux-wayne112/mnt/hdd/ha/<service_name>manual
212 (default)1: linux-wayne212/mnt/hdd/na/<service_name>automatic
2221: linux-wayne222/mnt/hdd/tmp/<service_name>automatic

Specific Instances

TODO: update

Class CodeImplemented server(s)BackupVolatilitySpeedPersistent Volume (PV) nameHostpath
2111: linux-wayne211nextcloud-config/mnt/ssd/ha/nextcloud/config/
2121: linux-wayne212nextcloud-data/mnt/hdd/ha/nextcloud/data/