The same processes were tested on a FlashArray running Purity 5.1.15 and then the other FlashArray was running Purity 5.3.6. In the tests there are 1000 vVol based VMs in the environment. Both FlashArrays had the same amount of workload running on them, about 50k IOPs, and similar load metrics.
The first test was to power on 100 VMs at once until all 1000 VMs were powered on, so 10 batches of 100 power on requests.
- On Purity 5.1.15 the process to power on all 1000 VMs took just over 3 hours to complete. This was done several times and generally was between 2 1/2 hours and 3 hours to complete the process.
- On Purity 5.3.6 the process to power on all 1000 VMs took just over 20 minutes. This was also done several times and would generally be between 18 and 22 minutes to complete the task.
Where we really see the huge jump is doing these requests at high load and scale. For example, with the Purity 5.3.6 array, we cranked the workload up to 150k IOPs and the array was just over 70% load. The same process of powering on 1000 VMs took just 30 minutes.
Another test was to see how long it took to put a host into maintenance mode when there were 100+ vVols based VMs powered on the Host.
- On Purity 5.1.15 the process to place a single host into maintenance mode took between 60 and 90 minutes.
- On Purity 5.3.6 the process to place a single host into maintenance mode took between 6 and 9 minutes.
- When we cranked the workload up to 150k IOPs and the array was at 70% load, it only took between 10 and 12 minutes.
The difference between the two performance tests is quite dramatic. The next test that we wanted to run through was to take managed snapshots of the vVols based VMs when all 1000 VMs were powered on. The process was to take a managed snapshot of 100 VMs at the same time, and then do it 10 times to get all 1000 VMs. Then once those requests finished, wait 15 minutes and then destroy the managed snapshots of 100 VMs at the same time, etc.
- On Purity 5.1.15 the managed snapshot process took aver 90 minutes, but only about 20% of the managed snapshots completed successfully.
- Destroying the managed snapshots took between 15 and 20 minutes. Keep in mind that this is only destroying 20% of the managed snapshots requests that completed.
- On Purity 5.3.6 the managed snapshot process took just over 6 minutes with 100% of the managed snapshots completing successfully.
- Destroying the managed snapshots took between 10 and 14 minutes.
- Then on Purity 5.3.6, testing at 150k IOPs and 70% load, the process took 20 minutes, but only 85% of the snapshot requests completed successfully. Keep in mind that all 1000 VMs are powered on, the array is under higher levels of load and 100 snapshot requests come in at the same time.
- Destroying the managed snapshots took between 12 and 15 minutes.
Once more we can see the significant difference between Purity 5.3.6 with VASA 1.1.0 and Purity 5.1.15 with VASA 1.0.2. Here is a table that summarizes some of the tests that were ran:
|
Tests at 50k IOPs and ~30% Load |
Purity 5.1.15 Test Completion Time |
Purity 5.3.6 Test Completion Time |
|---|---|---|
|
Cloning 1000 VMs from Template in batches of 100 |
80 Minutes |
20 Minutes |
|
Powering on 1000 VMs in batches of 100 |
180 Minutes |
20 Minutes |
|
Taking Managed Snapshots of 1000 VMs in batches of 100 |
100 Minutes (20% Success Rate) |
6 Minutes (100% Success Rate) |
|
Destroying Managed Snapshots of 1000 VMs in batches of 100 |
20 Minutes (only destroying the 20% success) |
7 Minutes (Destroying the 100% Success) |
|
Placing a host into Maintenance mode with 100+ vVols based VMs powered on that host |
60 Minutes |
8 Minutes |
|
Powering off 1000 VMs in batches of 100 |
90 Minutes |
10 Minutes |
|
Destroying 1000 VMs in batches of 100 |
60 Minutes |
10 Minutes |
There are additional tests that are still being ran and with differing tuning of the VASA Provider. The main takeaway here is that VASA Performance is dramatically improved in VASA 1.1.0 and that with a consistent performance baseline Pure will be able to continue testing at differing scale and load on the FlashArray.