Longhorn - Block-based Software Defined Storage for Kubernetes
Rating: 10 out of 10
Use Cases and Deployment Scope
We use Longhorn Block Storage as primary Persistent Storage in our Kubernetes platform based on Rancher. Before changing to Longhorn we used file-based solutions NFS and GlusterFS, which were incapable of hosting databases especially NoSQL blob storage used in ElasticSearch, Redis, ETCD, RabbitMQ and similar products, what resulted in common data corruption issues. Longhorn Block Storage gave us what we needed: secure, replicated and reasonably fast persistent storage.
Pros
- Leverages industry standard protocol (iSCSI)
- Is block-based storage instead of file-based
- Is truly software defined storage (SDS)
- Can use commodity hardware to build redundant SDS
- Is open-source software
- Is one of the CNCF projects
- Provides enterprise functionalities like snapshots or backups
Cons
- ReadWriteMany Longhorn volumes are still using NFS (file-based) protocol in the core.
- Using iSCSI as main protocol instead of FC ties Longhorn to Ethernet-based LAN which is in most architectures much slower that FC-based SAN.
- Longhorn could implement S3 as alternative access protocol to its volumes.
- Backups, and snapshots configuration could be configured at each volume-level by administrators (maybe from additional CRD object?), because currently is configured at storage-class level which is not granular enough.
Likelihood to Recommend
Longhorn is performing well as storage for databases and in almost any solution that uses exclusive access to volumes (ReadWriteOnce in Kubernetes nomenclature). When write access is required from many clients (ReadWriteMany) Longhorn Block Storage covers its volumes with NFS (file-based) access. Longhorn Block Storage also is well fitted in every architecture where data security (snapshots, backups, multiple replicas) is more important than access speed (in terms on IOPS and MiB/s).