Over the past few months, NetApp has built a self-service lab for testing NetApp Private Storage for Cloud (NPS for Cloud), a hybrid cloud solution. NetApp Private Storage for Cloud allows you place a NetApp System in a colocation facility near the cloud and then connect it to a public cloud through a dedicated link. When it comes to incorporating the public cloud into existing infrastructures, this solution gives you choice and control for your data.
The free POC Lab that NetApp offers at http://poc.netapp.com allows you to test the NPS solutions with AWS and Azure at nearly no cost (less than a couple of $/day). In this post we’ll focus on testing performance of the NetApp Private Storage for AWS solution.
There’s good news: Everything you know about performance testing still applies when you test NPS for AWS. However, since you’ll be testing in the AWS cloud environment, here are my personal top 3 points you should keep in mind:
1. Choose the right instance type
AWS offers a large variety of different instance types. They are characterized by the number of compute units, cores, memory, storage, architecture, network connectivity, and last but not least, the price. A good overview over the instance types gives this website. The network offerings range from “Very Low” up to “10 Gbit/s”. While AWS does not exactly specify what these terms refer to, a rough guideline that can be found online is:
- Very Low/Low – less than 100 Mbps
- Moderate – up to something around 300 Mbps
- High – Up to 1-2 Gbps
- 10 Gbit/s – theoretically up to 10 Gbit/s, but realistically more between 8-9 Gbps
For NetApp Private Storage, networking is a crucial point since the data flows between the instance and the storage through the AWS network infrastructure. This brings us to my first point:
Lesson 1: When testing NetApp Private Storage for performance, always make sure to choose at least an instance with the networking type “High” or “10 Gbit/s”.
2. Enable Enhanced Networking
Choosing the right network type is one thing, but especially when using instances with “High” or “10 Gbit/s” networking, it is important to enable the Enhanced Networking feature on the AWS EC2 instance (if available on the instance type). For Amazon Linux based instances, this is usually already enabled. However, for some instances, e.g., the SLES 11 SP3 stock image, it is not enabled. A guide on how to enable it can be found on the AWS Website:
Here’s a very quick comparison with Enhanced Networking disabled and then enabled (tested on the same instance):
No Enhanced Networking enabed:
100% Reads: [ec2-user@ip-**** ~]$ sudo dd if=/mnt/clemens/samplefile of=/dev/null bs=1M count=1024 iflag=direct 1073741824 bytes (1.1 GB) copied, 10.9279 s, 98.3 MB/s 100% Writes: [ec2-user@ip-**** ~]$ sudo dd if=/dev/zero of=/mnt/clemens/samplefile bs=1M count=1024 oflag=direct 1073741824 bytes (1.1 GB) copied, 6.06815 s, 177 MB/s
As you can see, especially the read performance is extremely poor. Let’s rerun the test after we enabled Enhanced Networking:
100% Reads: [ec2-user@ip-**** ~]$ sudo dd if=/mnt/clemens/samplefile of=/dev/null bs=1M count=1024 iflag=direct 1073741824 bytes (1.1 GB) copied, 3.11169 s, 345 MB/s 100% Writes: [ec2-user@ip-**** ~]$ sudo dd if=/dev/zero of=/mnt/clemens/samplefile bs=1M count=1024 oflag=direct 1073741824 bytes (1.1 GB) copied, 3.8384 s, 280 MB/s
As you can see, the improvement in performance is significant when enabling Enhanced Networking.
Lesson 2: Always enable Enhanced Networking (when possible).
3. Know the expectations
The cloud is a powerful way to get instant access to shared and dedicated services and resources. Some services and resources come with SLOs and SLAs, but not all do. In many cases, you are not the only one occupying a server, a CPU, the network, the storage, etc. Even if you provision dedicated resources or services – often those still have external, shared dependencies. For example, you can order a dedicated server/compute instance with guaranteed performance, but the network connection between this and other instances will still be shared. In an on-premise infrastructure you have full insight into the dependencies, in a public cloud environment, you usually don’t.
Some of my colleagues have published two Technical Reports, where they compared an on-premise setup with a comparable NetApp Private Storage setup:
- Technical Report – Oracle Performance Using NetApp Private Storage for Amazon Web Services (AWS)
- Technical Report – Oracle Performance Using NetApp Private Storage for SoftLayer
I think those reports are a good guideline to get a deeper understanding of how having shared/dedicated resources in the cloud behave.
Lesson 3: Most of the times, the public cloud is a shared environment. Often, dedicated resources or services in the cloud also have external, shared dependencies.
In order to have a successful NetApp Private Storage for AWS proof of concept, always keep in mind:
- Use an appropriate instance type in AWS
- Enable the Enhanced Networking feature on your EC2 instances
- Never forget that you are in a shared environment
If you have questions, feel free to reach out. I hope that this post was helpful for you!
Follow me on Twitter: @clemenssiebler