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).
The team in charge of implementing Scality has to be full stack in order to guarantee the correct functioning of the entire system. However, you have to think very carefully about the balance between servers and disks, perhaps adopting smaller fully populated servers instead of large semi-populated servers, which would mean that over time our disk updates will not have a fully useful life.
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.
Longhorn is mature software defined storage solution that is still developed and receive new functionalities. From the beginning every Longhorn volume have multiple (at least two) replicas, can leverage manual or automatic snapshots and backup to external S3 volume. Longhorn provides nice and clear GUI for administrators, but also can be managed from CLI.
As an organization, it took us a while to understand the shift from a traditional black box SAN to software-defined storage, but now we are much more certain of what this means. The time invested and the resources were not very high, thanks on the one hand to the technical support and on the other to the coherence and good development of the platform.
GlusterFS was first Persistent Storage solution used in our Kubernetes-based clusters. It is file-based what in some usages led us to many data corruptions. CEPH is object-based persistent storage which can be used as file-based Persistent Storage in Kubernetes. It is also is much more resource-hungry than other solutions including Longhorn. Dell PowerScale (or Isilon) is a hardware-software solution, that provides volumes that can be accessed by file-based NFS and CIFS protocols. Recently was added access to its volumes with object-based S3 protocol. Longhorn is in the middle. It is block-based, it is build on industry standards like iSCSI, performs very well on 10Gbit or faster LAN and commodity hardware (or in virtual machines)
Due to the nature of our business we require extensive encryption and availability for sensitive customer data. The erasure encoding that Scality provides gives us the assurance that documents are rest are never in a state of being downloaded or available to a casual data thief. This is something that can be found with other vendors but at a fraction of the same cost. Having this kind of performance, availability and redundancy at the cost that Scality provides has made a large difference to our organization.
Keeping sensitive customer data secure is a must for our organization and Scality has great features to make this happen.
We replaced a single SAN with a Scality ring and found performance to improve as we store more and more customer data.
Being able to lose various portions of our Scality ring and allow it to continue to service customers while maintaining high performance has been key to our business.
