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:

BackupVolatilitySpeed
- 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
1132: 50centos113/mnt/slhdd/ha/<service_name>manual
2132: 50centos213/mnt/slhdd/na/<service_name>automatic
2232: 50centos223/mnt/slhdd/tmp/<service_name>automatic

Specific Instances

TODO: update | Class Code | Implemented server(s) | Backup | Volatility | Speed | Persistent Volume (PV) name | Hostpath | | — | — | — | — | — | — | — | | 211 | 1: linux-wayne | 2 | 1 | 1 | nextcloud-config | /mnt/ssd/ha/nextcloud/config/ | | 212 | 1: linux-wayne | 2 | 1 | 2 | nextcloud-data | /mnt/hdd/ha/nextcloud/data/ |