For several decades, software applications have primarily consumed storage resources using file system interfaces. In fact, even if the underlying storage infrastructure was block-based (SAN), most applications would consume it via a local file system layer (e.g. ext3/4, NTFS, etc.). This is still true in the cloud era, with most “cloud-native” applications consuming object storage via “pseudo” file system interfaces, using file system hierarchies (e.g. namespaces) and file system attributes (e.g. name, owner). Even so, delivering file storage “as-a-service” is a significant challenge. In fact, it is considerably more complex than building a block- or object-based service…as a result, only during the last few years has “file storage”-as-a-service become a first-class citizen within most public clouds. In 2015, Microsoft Azure was the first cloud to announce general availability of a file storage service, with Azure File Storage. The other public clouds are also making similar services available, both natively and via storage partners. Recently, Google and Elastifile were proud to jointly announce self-service availability for Elastifile Cloud File Service, the first scale-out file storage service on Google Cloud.
In this blog, I will compare Elastifile Cloud File Service on Google Cloud to the main file service offerings on the other public clouds, demonstrating that the Elastifile Cloud File Service on Google Cloud is the best choice for a wide variety of use cases.
“Elastifile Cloud File Service is a fully-managed, scalable file storage service. It delivers high-reliability, POSIX-compliant NFS and SMB file services and provides a full suite of cloud-native enterprise NAS features (including snapshots and multi-zone accessibility).” 1
Elastifile’s service is truly software-defined and cloud-native, enabling immediate use in any cloud region. Currently, Elastifile Cloud File Service is exclusive to Google Cloud and supports NFSv3, SMB 3.1, snapshots, automated data tiering to object storage and integrated backup services (e.g. durable, self-contained snapshots). Additional data services such as asynchronous replication, sub-namespaces, and file synchronization are planned.
Elastifile Cloud File Service currently supports 3 service classes, enabling users to choose the price and performance that aligns with their business needs. The service is billed by-the-minute and invoiced monthly on a user’s standard GCP bill. Charges are based on the provisioned capacity of primary storage and the consumed capacity for snapshots. For the purposes of this blog, I will focus on the highest-performance Elastifile service class (i.e. the “Performance Optimized” class).
“Amazon Elastic File System (Amazon EFS) provides a simple, scalable, elastic file system for Linux-based workloads for use with AWS Cloud services and on-premises resources.” 2
EFS supports partial 3 NFSv4, with redundancy delivered via support for multiple availability zones (i.e. “regional service”), a recently-added “Infrequent Access” storage class, and automatic data tiering. EFS charges are based on consumed capacity and/or by provisioned bandwidth. EFS seems to be targeted towards general-purpose, bandwidth-oriented use cases. It does provide a file synchronization solution, but lacks most enterprise data services, such as snapshots, asynchronous replication, and crash/application-consistent backups.
“Fully managed, cloud service that enables you to move your mission-critical workloads and applications to the cloud, and manage them with ease.” 4
CVS supports NFSv3 and SMB on AWS, Azure, and Google Cloud, with an apparent focus on AWS (based on the number of supported regions). CVS relies on NetApp hardware appliances that are physically deployed in locations near the main public cloud data centers and, therefore, provides service for a limited set of cloud regions (see the green dots here), with various levels of latency impact (see here in the “AWS regions” tab). CVS provides 3 service tiers with varying performance and pricing. For the purposes of this blog, I will focus on the highest-performance Cloud Volumes service class (i.e. the “Extreme” tier).
As of the time I am writing this blog, CVS supports snapshots, but does not support asynchronous replication, data tiering, object integration, or integrated backup abilities (primary snapshots not maintained on separate, resilient media). On AWS, CVS’ pricing model is based on monthly or annual subscriptions (as detailed here).
Note that the Cloud Volumes Service (CVS) should not be confused with the self-managed Cloud Volumes ONTAP software solution. Cloud Volumes ONTAP is fully-featured, but requires manual user management and cannot scale (supports single-head and dual-head configurations only). The ONTAP solution is not included in this discussion because it is not a managed service.
“Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard Server Message Block (SMB) protocol. Azure file shares can be mounted concurrently by cloud or on-premises deployments of Windows, Linux, and macOS.“ 5
Currently, Azure files supports a Standard storage level, which provides on basic functionality, and a public preview of a Premium storage level (as seen here). In addition, there is currently a “limited public preview” for a higher-performing version of the Premium storage class (as seen here). For the purposes of this blog, I will focus on the highest-performance Premium storage level, even though it is not yet publicly available. According to Azure documentation, this storage level provides SMB support, snapshots, integrated backups and file synchronization.
“Cloud Filestore is a managed file storage service for applications that require a filesystem interface and a shared filesystem for data. Filestore gives users a simple, native experience for standing up managed Network Attached Storage (NAS) with their Google Compute Engine and Kubernetes Engine instances.” 6
Cloud Filestore provides two classes of NFSv3 services – Standard and Premium. Advanced data services, such as snapshots and data tiering, are not currently supported. For the purpose of this comparison, the more performant Premium class is used.
In all cases, the data provided in this blog is taken from publicly available documents, most commonly from the official vendor documentation. The validity and accuracy of the data provided are not tested or independently verified in any way. In other words, I trust the vendor data. Based on my experience, this data seems accurate. I have endeavored to provide links to all data sources used.
In the general sense, file system performance is a very complex subject and is certainly out of the scope of this blog. In addition, since I rely on published (vendor) results, I have to use performance metrics that are common between services. As a result, I am focusing the performance comparison on file data performance…namely how fast you can read and write to a few large files, as measured in terms of IOPS and throughput (bandwidth). IOPS are measured for read-only and write-only random workloads with 4k block size. Bandwidth is measured in a similar way, but using medium/large block sizes (i.e. 32-64K or larger).
A few notes regarding the performance data reference below. Elastifile performance results correspond to a file system with 80 TB usable capacity. The performance of Elastifile Cloud File Service can be increased even further by increasing the size of the file system. 7 The performance numbers attributed to NetApp Cloud Volumes Service, Amazon EFS, Google Cloud Filestore, and Azure Files correspond to published maximum performance capabilities.
1. The data in the table above represents the performance you can expect using the current implementation of the Performance Optimized service class. Elastifile’s architecture can support much higher performance and if significant demand for a higher performance option emerges, Elastifile may add additional services classes. To be fair, this statement can be true also for some or all of the other services.
2. The benchmarks are done in the GCP region us-east1, zone b.
3. Elastifile’s architecture supports deduplication and compression. The data used in the tests above is not dedupable, but can be compressed (2:1 ratio) which enables Elastifile to achieve additional efficiency in some scenarios (e.g. heavy writes).
4. For the purpose of this blog, I have built an automated benchmark suite. The same benchmark suite can be applied to any NFS filer (and also to SMB filers with very small changes). If you want to use it to test Elastifile Cloud File Service or any other filer, please contact Elastifile support to gain access. I hope to clean it up and release it to the public, but I am not sure I will have the time for it.
Many so-called “cloud” solutions are simply ports of legacy architectures that were designed for on-premises environments, often rely on physical appliances, and/or were solely optimized for HDD and bandwidth-oriented use cases. Though porting legacy technology to a modern environment may be easier and faster compared to developing a new technology from scratch, this approach has key limitations (as illustrated in the comparisons above) and, likely, a limited lifespan.
Elastifile Cloud File Service, on the other hand, was architected specifically for the cloud and optimized to support the associated mix of storage media types and I/O profiles. Elastifile’s superior service offering is a direct result of this cloud-native approach. While the rigid nature of hardware-defined legacy approaches limits the lifespan of those solutions, Elastifile’s software-defined approach future-proofs our solution to align with the continued evolution of public cloud environments. And the best is yet to come…
From the customer’s point of view, key direct advantages of Elastifile’s cloud-native architecture are:
1. Efficient use of cloud-native storage and compute infrastructure, enabling tight integration and facilitating: an intuitive, easy-to-use user experience, elastic scalability with optimized performance, and cost-effective service options
2. Availability in all regions and zones (even new regions, once they are available to the public)
3. Automatically improves with the cloud infrastructure upgrades. For example, when the cloud’s network, compute, or storage become faster, Elastifile Cloud File Service benefits and can also become faster…in most cases without any changes required from Elastifile.
As demonstrated above, Elastifile is the best-in-class file storage service. It provides superior performance and features at similar or lower pricing than the service alternatives…and we’ll continue to make improvements across the board.
Best of all you can test it yourself, right now at https://console.cloud.google.com/marketplace/details/elastifile/elastifile-cloud-file-service.
3 See list of “unsupported NFSv4 features:https://docs.aws.amazon.com/efs/latest/ug/limits.html#nfs4-unsupported-features
7 Contact Elastifile at firstname.lastname@example.org if you require a file system with capacity beyond the default options in the deployment console. Larger file system capacities are available via the service upon request.