APEX Block Storage for AWS – A Candidate for Database Workloads? Let’s Unpack……. (Part 1)

Post by Simon Stevens and Damian Erangey

While speaking with a partner recently around APEX Block Storage for AWS as a candidate for database workloads, the conversation quickly turned into a discussion about the different AWS Volume types – by that, they were interested in the differences in price, performance, manageability etc. – and where (and how) does APEX Block Storage fit into this landscape. After all, APEX Block Storage for Public Cloud leverages EBS instances under the hood right?

It quickly becomes obvious that the various AWS EBS volume types and performance characteristics must be understood should a customer wish to consider moving from away from native EBS volumes for DB workloads, or SaaS services such as like Amazon RDS.

In reality, these are actually two separate questions, however they are both are related.

1. Why consider APEX Block Storage for AWS over a Native EBS Volume mapped to a DB VM?
2. Is APEX Block Storage for AWS a good candidate to replace an Amazon DB service such as RDS?

There is a lot to unpack if we want to highlight APEX Block Storage for AWS as a solution to those questions – we need to consider things from multiple standpoints – architectural, feature, and TCO. With the official launch of APEX Navigator for Multicloud Storage (announcement here), the conversations regarding potential deployments of APEX Block Storage are now getting very real as we start exploring the finer details and start to understand the costs and new operating models that APEX Navigator enables. Exciting times indeed !!

To that point, we will explore 3 key pillars of the Dell APEX Block Storage for Public Cloud offer:

1. Scalable, Linear & Predictable Performance.
2. Space Saving Architecture; thin provisioning + space-efficient snapshots.
3. Multi-AZ Availability.

And finally, we will look at the potential benefits of APEX Block Storage over a cloud native AWS Database service such as RDS (we’ll cover that in the second blog)

Understanding AWS EBS Volume Types

To begin with, we need to take a look at the AWS EBS General Purpose volume types to understand the capabilities offered by these volumes and how APEX Block storage leverages them, and, more importantly, aggregates them.

Reference https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html

The AWS documentation page on General Purpose SSD volumes covers two types of SSD volumes offered by Amazon EBS: General Purpose SSD (gp3) and General Purpose SSD (gp2) volumes.

1. General Purpose SSD (gp3) Volumes: These are the latest generation of General Purpose SSD volumes and are the lowest cost SSD volume offered by Amazon EBS. They provide a balance of price and performance, allowing for independent scaling of volume performance and size. Gp3 volumes have single-digit millisecond latency, high durability, and can continuously sustain their full provisioned Input/Output Operations Per Second (IOPS) and throughput performance. Their baseline IOPS performance is 3,000 IOPS and can be increased up to 16,000 IOPS for larger volumes. The throughput performance is a consistent 125 MiB/s, upgradable to 1,000 MiB/s. gp3 volumes range in size from 1 GiB to 16 TiB​​.
2. General Purpose SSD (gp2) Volumes: These are the default volume type for Amazon EC2 instances, providing cost-effective storage for a broad range of workloads. gp2 volumes offer single-digit millisecond latency and high durability. Their performance scales with volume size, providing a baseline IOPS performance that scales linearly between 100 and 16,000 IOPS. For smaller volumes under 1 TiB, gp2 can burst to 3,000 IOPS for extended periods, governed by I/O credits. Each volume starts with an initial I/O credit balance, enabling fast initial boot cycles and efficient application bootstrapping.

General Purpose SSD volumes, such as gp2 and gp3 offered by Amazon EBS, are designed to provide a balance of price and performance for a wide range of transactional workloads. While they can support medium-sized single instance databases and are recommended for most workloads, they might not be the optimal choice for highly demanding, IOPS-intensive database workloads. Ok, so what is recommended?

For critical or high-performance database workloads that require low latency and consistent IOPS, Amazon EBS’s Provisioned IOPS SSD volumes, like io1 and io2, are typically more suitable. These are specifically designed for I/O-intensive workloads, particularly database applications, and provide more consistent and higher performance compared to General Purpose SSD volumes.

Referred to as Provisioned IOPS EBS Volumes. Again, we can refer to the User Guide that is freely available from the AWS document store:  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html

1. Types of Volumes:
   • io2 volumes
   • io2 Block Express volumes
   • io1 volumes
2. Design and Performance:
   • io1 and io2 volumes are tailored for I/O-intensive workloads,  especially databases, needing consistent storage performance.
   • io1 volumes offer 99.8% to 99.9% durability, while io2 volumes offer a higher durability of 99.999%.
3. Size and IOPS:
   • These volumes range from 4 GiB to 64 TiB in size, with configurable IOPS from 100 to 256,000 per volume (depending on volume type)
   • The IOPS-to-size ratio is 50:1 for io1 and 500:1 for io2.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html

Now, knowing what we know about the EBS volume types, performance, and scalability we can build upon this knowledge and try to draw some real-world comparisons to understand where the APEX Block for Multi Cloud storage story becomes compelling. There are many factors that go into a decision. However, I find it easier to start with performance and ease of scalability, allied with just how easy it is to manage all this natively, in order to draw our baselines.

Cloud native approach to aggregate performance

Aggregating multiple AWS gp3 EBS (Elastic Block Store) volumes into a single pool for an EC2 (Elastic Compute Cloud) instance involves several complexities:

You can attach up to 20 volumes on a single instance and they need to reside in the same availability zone

1. Volume Management: Managing multiple EBS volumes as a single pool requires careful orchestration. You need to ensure that data is distributed and replicated across volumes in a way that maximizes performance and reliability.
2. Performance Considerations: Each volume has its own performance characteristics in terms of throughput and IOPS. When aggregating volumes, it’s important to balance the load across them to avoid any bottlenecks.
3. Data Consistency: Ensuring data consistency across multiple volumes can be challenging, especially in the event of failures or when performing data backups and snapshots.
4. Cost Implications: More volumes mean higher costs. It’s important to balance the need for storage space and performance against the cost implications of using multiple gp3 volumes.
5. Failover and Redundancy: Designing a system that can handle the failure of one or more volumes without data loss or significant downtime is complex. This may involve setting up RAID configurations or using AWS services like EBS Multi-Attach.
6. Capacity Planning: Predicting future storage needs and scaling the storage pool accordingly without over-provisioning or under-provisioning can be difficult.
7. Networking Bandwidth: The aggregated throughput of multiple EBS volumes might exceed the network bandwidth available to the EC2 instance, leading to a potential bottleneck.
8. Monitoring and Maintenance: Continuous monitoring is required to ensure optimal performance and to identify issues like volume degradation or imbalanced load distribution.
9. Integration with AWS Services: Integrating this setup with other AWS services (like RDS, S3, or AWS Backup) for a comprehensive data management strategy requires careful planning and execution.
10. Technical Expertise: Implementing and managing such a configuration requires a high level of technical expertise in AWS services, distributed storage systems, and network architecture.

APEX Block Storage approach to aggregate performance – Scalable, Linear & Predictable Performance.

We know that customers can not only obtain, but also go way beyond the IO performance of AWS io2 block express storage (up to 256K IOPS/volume) by using Dell APEX Block Storage for AWS using AWS gp3 storage (16K IOPS/volume) or io2 Volumes etc. Not only can we do this, but we can do it in a much simpler fashion.

Simply put, we take those EBS gp2/3 or io2 volumes and aggregate them. Everything is abstracted and presented as a single resource pool, from which multiple thin volumes can be carved out and presented to VM’s, Containers etc.

Everything that you already know about Dell PowerFlex’s scale-out capabilities are done here, only with this offer, we are leveraging these capabilities when running them on cloud components.

So how is an APEX Block Storage cluster deployed? Each cluster node is granular, comprised of compute and storage from the cloud provider.  The configuration can start with between 3 to  5 virtual nodes (depending on the cloud and the initial storage options) and can scale to 512 virtual cluster nodes. If the penny has not yet dropped here – each virtual cluster node here is a discrete AWS instance.

This means that, with scale, we can obtain:

• A potential maximum capacity of 8PiB raw / 4PiB usable of consolidated, active online capacity – that is to say, not tiered capacity (where just a small subset of the storage handles the “busy stuff”),
• 6×9’s plus levels of availability, and an architecture that allows Multi-Availability Zone deployments to ensure that the storage remains available, even in the event of an entire Availability Zone outage!
• Storage Pool performance that can easily be scaled to provide millions of IOPS
• And since it is deployed on the cloud providers network, we can transact storage IO operations with micro-second latencies (not “in the single milli-seconds” that the AWS offerings provide!). Meaning that we can provide an infrastructure experience which behaves like an on-premises deployment even though it is in the public cloud.

All of this means that customers can easily consolidate and manage many performant workloads into a single cluster’s storage pool.  Native cloud storage is unable do this without a lot of re-architecting (sure, it is possible, but it is complex to do so), and many, if not most of our competitors, simply do not have this linearly-scaling capability.  This is powerfully robust Enterprise storage… yet it is served directly in the public cloud.

When new storage instances are added into an existing system, Dell APEX Block Storage for Public Cloud automatically adds the net new raw capacity and the net new additional IO performance into the cluster. While there will of course be a cloud cost for the instance and storage used, there is no additional charge for its increased performance. Dell APEX Block Storage for Public Cloud offers significant advantages in IO performance when compared to other cloud native solutions:

As the infrastructure grows, our customers will see that the aggregated resources predictably generate near-linear growth in performance, since both the maximum IOPs and throughput levels continuously scale as more nodes (instances) are added into the system. With a 128-node test, we saw that we can achieve over 31 million IOPS, which equates to over 6 Terabits per second of throughput!  It is worth pointing out that these numbers will continue to scale all the way to the 512-node max capability of the cluster.

Such amazing levels of performance have been proven across our current on-prem PowerFlex install base, across different verticals, over a number of years. Indeed, when you have this level of linearly scalable and predictable performance, such scalability demonstrates a solid future-proofing by the very nature of its design.

Further on in this post, we will work though a real sizing example. But let us for now accept point number 1. Which is that “APEX Block Storage aggregates EBS volumes, thus offering linear performance in a fashion that is much easier to administer and manage than only using native EBS volumes.”

Now let us move the discussion on and let us talk about efficiencies that can be obtained if customers wish to use Snapshots on the public cloud….

Snapshots

Amazon Elastic Block Store (EBS) snapshotting is a feature provided by AWS (Amazon Web Services) for creating backups of EBS volumes, which are block-level storage volumes used with EC2 instances. Here are some key points about EBS snapshotting:

1. Snapshot Basics: An EBS snapshot is a point-in-time copy of your EBS volume. It’s stored in Amazon S3 (Simple Storage Service), which provides high durability.
2. Incremental Backups: When you take a snapshot, only the blocks on the device that have changed since your last snapshot are saved. This means that snapshots are incremental and can save on storage costs and time to create the snapshot.
3. Data Consistency: To ensure data consistency, it’s often recommended to stop any write operations on the volume or detach the volume before taking a snapshot, especially for databases or other applications with a lot of write operations.
4. Performance Impact: While taking a snapshot, there might be a slight performance impact, but AWS has optimized this process, so the impact is typically minimal.
5. Costs: The cost of EBS snapshots is based on the amount of storage space your snapshots consume. Remember, since snapshots are incremental, you only pay for the storage of the changed blocks.

When using Amazon EBS snapshots, it is important to be aware of certain limitations and potential pitfalls to ensure effective and efficient data management. Here are some key points to consider:

1. Performance Impact During Initial Snapshot: The first snapshot of an EBS volume can take longer to complete because it captures the entire volume. Subsequent snapshots are incremental and typically complete more quickly, but the initial snapshot may temporarily impact performance.
2. Data Consistency Issues: If you take a snapshot of a volume that’s attached to a running instance, the snapshot might not capture data that’s cached by applications or the operating system. To capture a consistent state, it’s best to unmount the volume or use file system tools to flush the cache before taking a snapshot.
3. Snapshot Lifecycle Management: Without proper management, snapshots can accumulate, leading to increased storage costs. It’s essential to have a policy for regular review and deletion of old snapshots that are no longer needed.
4. Restoration Time: Restoring an EBS volume from a snapshot can take time, depending on the size of the volume and the amount of data. This might impact recovery time objectives in a disaster recovery scenario.
5. Cross-Region Latency: If you’re copying snapshots across regions for redundancy, be aware of the time it takes to copy the snapshots, which can vary based on size and network conditions.
6. Encryption Restrictions: If a snapshot is encrypted, it can only be shared with others if they have access to the same encryption keys. This might limit the snapshot’s usability in some collaborative scenarios.
7. IOPS (Input/Output Operations Per Second) Performance: Snapshots do not capture the IOPS performance of the original volume. When you create a new volume from a snapshot, you need to specify the desired performance characteristics.
8. Cost Management: Costs for snapshot storage can add up, especially if there are many changes between snapshots. It’s important to regularly review and delete unnecessary snapshots to manage costs.
9. Region and Availability Zone Dependencies: Snapshots are associated with a specific region, and while they can be copied across regions, this requires additional steps. Also, snapshots do not provide high availability across availability zones.
10. Bandwidth Considerations: When you’re working in a bandwidth-constrained environment, creating and restoring snapshots can consume significant network resources.

Having seen all that AWS Snapshotting has to offer, again, why should I consider APEX Block Storage? In short, we need to remember that APEX Block Storage uses Dell PowerFlex under the hood to provide enterprise-grade storage capabilities to the public cloud. This includes space-efficient snapshots.

APEX Block Storage Snapshot Features:

1. • Granular Snapshots: highly granular snapshots at the volume level. This means you can create snapshots of individual volumes without affecting other volumes in the system.
   • Speed and Efficiency: The snapshots are typically fast and efficient. They are designed to minimize performance impact on the primary storage system.
   • Writeable Snapshots: Supports creating writeable snapshots, which means you can not only use snapshots for backup and recovery but also for testing and development purposes by writing data to the snapshots without affecting the original volume.

1. • Snapshot Consistency Groups: You can group multiple volumes into a consistency group and snapshot them simultaneously. This ensures data consistency across volumes, which is crucial for applications that span multiple volumes.

1. Highly Space-Efficient at Creation: Snapshots are exceptionally space-efficient when initially created. They utilize a unique methodology that does not require an immediate allocation of additional storage space. This means that at the moment of creation, these snapshots do not consume extra storage capacity, which is a significant advantage in terms of storage optimization.
2. Intelligent Copy-on-Write Mechanism: Employs an intelligent copy-on-write mechanism. This approach ensures that the snapshot only starts consuming additional storage space when changes are made to the original data. This delayed space consumption allows for more strategic storage planning and management, as it minimizes the immediate impact on storage resources.
3. Optimized for Rapid Snapshot Creation: The ability to create snapshots without initially consuming additional space means that snapshots can be created rapidly and without performance overhead. This is particularly beneficial for environments that require frequent data protection activities, such as dynamic production or development environments.
4. Ideal for Data Protection and Recovery: The space-efficient nature of PowerFlex snapshots makes them ideal for data protection and recovery strategies. Organizations can create point-in-time copies for backup purposes without worrying about immediate large-scale storage consumption.
5. Supports Agile Testing and Development: In testing and development scenarios, the ability to create snapshots quickly and without initial space concerns supports an agile and efficient workflow. Developers can create and revert to snapshots easily, facilitating a more iterative and dynamic development process (we’ll talk about this more in a future blog post)
6. Cost-Effective Storage Management: By minimizing initial space usage, PowerFlex snapshots provide a cost-effective solution for storage management. Organizations can defer the costs associated with storage capacity expansion, as the incremental space consumption aligns more closely with actual data changes over time.
7. Enhanced Flexibility in Storage Planning: The space-efficient nature of PowerFlex snapshots offers enhanced flexibility in storage planning and allocation. It allows for more efficient use of existing storage resources and aids in delaying the need for immediate storage expansion.

In essence, PowerFlex’s snapshot technology results in a thoughtful balance between immediate space efficiency and long-term data protection needs. This approach provides significant advantages for organizations looking to optimize their storage infrastructure while maintaining robust data protection and recovery capabilities.

Since the APEX Block Storage snapshots simply utilize the gp3 or io2 volumes that are already providing the cloud storage capacity to the APEX Block Storage cluster, there are no extra costs incurred for using snapshots with APEX Block Storage for Public Cloud!

So far, so good. Next, let us talk about availability and redundancy.

Multi AZ availability

Amazon EBS (Elastic Block Store) supports a form of replication mainly focused on ensuring data durability and availability. Here is how it works:

1. Data Replication Within an Availability Zone (AZ):

• • Each EBS volumes data is automatically replicated within its Availability Zone. This replication is designed to protect your data from the failure of a single component.
  • This kind of replication is inherent to all EBS volumes, regardless of type, and is part of the service’s core feature to ensure high durability and availability.

1. Snapshot Replication Across Regions and AZs:

• • EBS allows you to create snapshots of your volumes, which are stored in Amazon S3. These snapshots can then be replicated across different Regions or Availability Zones.

• • • This feature is particularly useful for disaster recovery purposes. In case of a regional outage or if you want to migrate data to a different region, you can create a new volume from the snapshot in the target region or AZ.

1. Cross-AZ Replication:

1. • While EBS inherently replicates data within a single AZ, cross-AZ replication can be implemented at a higher level in your architecture.
   • This is typically achieved through manual methods or AWS services like Amazon RDS (for databases) that provide options for multi-AZ deployments. For instance, you can set up an application to write data to volumes in multiple AZs or use AWS services that handle this replication.

1. Use of AWS Data Services for Replication:

1. • AWS offers other services like AWS DataSync or AWS Backup that can be used alongside EBS for more complex replication strategies, including replication across multiple AZs or regions.

Each of these replication methods serves a different purpose, from ensuring high availability and durability within an AZ to providing disaster recovery solutions across regions. The choice of replication strategy would depend on the specific requirements for data availability, durability, and recovery objectives of your application or workload.

Drawbacks

• Complexity in Setup and Management: Setting up and managing replication, especially for cross-AZ or cross-region scenarios, can add complexity to your AWS architecture. This might require more sophisticated monitoring and management strategies.

• Potential Latency: Replication, particularly across regions, can introduce latency. This is important to consider for applications requiring real-time data access or low-latency operations.

• Bandwidth and Performance Considerations: Replicating large volumes of data can consume significant bandwidth and might impact the performance of other applications or services.

Management Difficulty

• Automation and AWS Services: AWS provides services and features to automate many aspects of EBS volume replication, such as automated snapshots and AWS DataSync. Setting up these services requires a certain level of expertise in AWS.

• Monitoring and Maintenance: Regular monitoring and maintenance are needed to ensure the replication process is functioning correctly and efficiently.

Considerations

• Data Durability and Availability Needs: Your replication strategy should align with the durability and availability requirements of your application. More critical applications might require more robust replication strategies.

• Disaster Recovery Planning: Replication is a key component of disaster recovery planning. You should consider how quickly you need to be able to recover data and continue operations in a different AZ or region in case of an outage.

• Cost-Benefit Analysis: Evaluate the cost implications versus the benefits gained from various replication strategies. For some use cases, a simpler and less expensive replication setup might be sufficient.

In summary, while EBS volume replication provides high durability and availability, it requires careful planning, can introduce additional costs, and adds complexity to your AWS environment. Balancing these factors against your specific requirements and constraints is essential for an effective and efficient replication strategy.

What about APEX Block Storage ?

Dell APEX Block Storage self-healing architecture simplifies and increases the availability of infrastructure. It is designed to remain running even when it encounters failures. With fast rebuilds, Dell APEX Block Storage recovers rapidly from failures and keeps operating, without degrading performance or compromising availability. You can also extend this availability and configure it to protect your application availability across multiple availability zones.

Durability is defined by:

• Using the Dell APEX Block Storage Fault Set architecture.
• When spanning a single cluster across multiple availability zones or deploying into a single zone, the solution aggregates the capacity and performance. Having more instances means more performance and more resiliency.
• Retaining critical response time and IOPS performance properties.
• Rapid data re-protection from an instance failure, or even an entire AZ failure, with rapid rebuilds that start automatically as soon as a failure is detected.
• Architecting fault sets, or fault domains, within the public hyperscalers, provides unprecedented levels of storage availability that were previously unavailable in any public cloud platform.

The unique multi-AZ architecture is defined by:

• Choose your instance configurations based on the use case.
• The industry-first feature of a single cluster spanning multiple availability zones, that allows customers to set up non-replication-based fault tolerance across an entire AWS region.
• Scales linearly by federating instances.
• No performance limitations.
• Protection across Availability Zones.

Below is a fantastic video highlighting the simplicity of a Multi AZ, resilient, performant SQL workload, running on APEX Block Storage

It can be seen that with Multi-AZ availability, there is a lot to cover in terms of understanding customers’ RTO and RPO objectives and how APEX Block Storage can shine from a number of perspectives – ease of management, data redundancy and zero-application-downtime perspective. As this blog has already become long enough and we have now touched upon the key highlights, we will dive deeper into these – and other – discussion points, in future blogs.

Knowing what we know –  Let us run through the numbers !

So let us now break this down into some real numbers…..

• Let us use an example where there is the need for a storage infrastructure in the public cloud that is able to provide 500TB usable capacity and delivers 1M IOPS.
• The table below shows the cost for 500TB and 1M IOPS on AWS, using EBS gp3 and io2 instances with EBS snapshotting (1 snapshot/day, 1% data change delta):
• By using AWS calculators, it can be seen that a customer would be paying $70k for gp3 and $155k for io2 at list price to hit the capacity and performance numbers natively on AWS. These costs are before we start to consider the complexity & trade-offs that would be needed when taking such an approach. For a start – would your admin team be happy having 445 *EBS gp3 or 42* io2 volumes to manage?!!
• If you remove snapshotting (and I would find it hard to believe that anyone running a transactional database in production does not use them) – then the AWS Bills are $41k and $129k per month (list price) respectively.
• AWS volume snaps are sent to S3. The first snapshot is a Full Copy, while all others are incremental after that. No de-dupe is offered on AWS or on Azure (we will revisit this point in a later blog).

Here you see the see list price numbers using APEX Block Storage – assuming that we use a thin provisioning ratio of 2:1 and also use snapshotting.

• Why call out snapshotting? Because with APEX Block Storage for Public Cloud, snapshots come at no extra cost! (as we already covered – putting us at an advantage over a native EBS approach) – so immediately there are cost savings to be made when compared to the AWS native offerings.
• Taking all the above into account – the list price math works out to a $31k – $37k AWS Bill (depending on the instance being used) per month. Of course, there will also be a cost per month for the APEX Block Storage license, which is dependent upon how much raw capacity is required. At the capacities being discussed in this example, the solution including APEX Block Storage licensing will still come out cheaper per month over a three-year term. We can see that we are incredibly competitive on a per-month total cost basis, when compared to the native AWS EBS offerings above.
• Even if we were to assume that there were no thin provisioning savings to be had (which may be a possibility, depending on the application) we would still come in cheaper ($62 – $74k of AWS cost with APEX Block Storage vs $70k – $155k for AWS EBS gp3 and io2). Plus, remember that these are list prices being discussed here.
• So, if the customer were to pay the licensing upfront – then the TCO break even vs gp3 would be between 6 & 8 months, while for io2 it would be even shorter – as little as between 2 to 3 months !!

The examples above use simple calculations and exclude the compute instance costs (this is a storage blog after all, right?!?!). But we have clearly shown that APEX Block Storage for Public Cloud is exceedingly price competitive, that it is much easier to scale for performance , provides Multi-AZ deployment option for the highest levels of availability (while also being much easier to manage),  provides capacity efficiencies thanks to the use of thin-provisioned volumes (that would cost more with AWS) and is cheaper to snapshot / archive.

Finally….. Let talk about Databases !

Remember the original questions?

1. Why consider APEX Block Storage for AWS over a Native EBS Volume mapped to a DB VM
2. Is APEX Block Storage for AWS a good candidate to replace an Amazon RDS service ?

I believe we have explored, highlighted some key challenges and differences of cloud native vs APEX Block Storage and worked a conceptual tco to address question 1. If you have made it this far well done ! In our next blog post we’ll explore and look to highlight the features and benefits of APEX Block storage as a candidate to replace an AWS services such as Amazon RDS.

#IWORK4DELL

Opinions expressed are entirely our own and may not be representative of the views of Dell Technologies.