Amazon Elastic Block Store (EBS) vs. Longhorn Block Storage

EBS is well-suited for use as a storage option for databases, including relational databases, NoSQL databases, and big data analytics databases. EBS can provide high IOPS (Input/Output Operations per Second) and low latency. EBS provides a high-availability storage solution, which ensures that your data is always available and accessible even in case of a single or multiple availability zone failures. EBS can also be replicated across multiple availability zones to ensure data durability. The scenario where I find it less appropriate is in terms of cost; EBS can be more expensive than other storage options, such as Amazon S3, especially for large amounts of data or for infrequently accessed data.

Incentivized

Longhorn Block Storage is well suited for most Kubernetes workloads where data storage is required, but when very high storage speed is essential, Longhorn Block Storage might not be the best solution. For those rare situations, we use local storage mounts. Longhorn Block Storage's ability to easily create/restore volume snapshots is a very frequently used feature among our dev teams because they can easily play multiple scenarios with the same data - modify data, restore it and modify it again.

• Raw storage capacity attached to your instance operative system
• Frequent data rewriting (mission critical for reporting)
• Low latency connectivity (14 reporting subsidiaries in different time zones)
• Videly spreaded for implementation
• Fast accessible drive
• Block storage are core for Java, Net mobile applications

Incentivized

• Creates read-write many (RWX) volumes
• Longhorn Block Storage is an easy to deploy solution
• Scheduled and on-demand volume snapshots can be created using web GUI
• Volume backups can be stored offsite on any S3 compatible storage solution
• Backups and snapshots can be restored using web GUI

• EBS volume can be attached to only one EC2 instance at a time
• The volumes are limited to the Availability zones of the instance they are attached to
• The maximum size is 64TB. We have had usecases where we needed larger volume
• The backup snapshots are stored on S3 and that's an additional cost.

Incentivized

• 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.

Amazon EBS is a great tool and fairly easy to use as long as you are familiar with the Amazon Web Service ecosystem. It allows a great way for you to move storage around easily and allows you to quickly provision storage as needed based on the business requirement. For us, it's easy to move between our EC2 images that had been linked with EBS storage between these Amazon accounts.

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.

The support for Amazon Elastic Block Store is great as long as you can articulate your needs. Like most tools, there may be some back and forth before you find a support person that is knowledgable in the tool and can provide you with necessary insights.

Volumes range from cost-effective dollar-per-GB to high performance with the fastest IOPS and throughput. You can change volume types, tune performance, or increase volume size without disrupting your critical applications. EBS volumes are replicated within an Availability Zone (AZ) and can easily scale to petabytes of data. Build your SAN in the cloud for I/O-intensive applications. Run relational or NoSQL databases.

Incentivized

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)

• In terms of ROI, I found it's really cost-effective since maintenance cost is not there. No need to spend extra money on the procurement of hard drives
• On demand feature of Ebs is quite effective when you require extra storage you can allocate and pay as per your need.
• Accessibility from everywhere and deployment of it across different geographical location.

Incentivized

• Longhorn is fully open source. One can try and/or use Longhorn for free even in enterprise and buy subscriptions only for environments that must be fully supported. We started with Longhorn in our lab environment and followed on through reference platform to non-production and production environments.
• Longhorn subscriptions are not cheap, but its biggest advantage is that price-to-functionality ratio is very reasonable.
• We have volumes with hundreds of gigabytes of data and these on Longhorn perform well in solutions where file-based GlusterFS volumes were corrupting data.