The HPE MSA 2060 storage platform enables customers to deploy small scale yet highly available services in the most efficient and cost effective way. Solutions such as the HPE Primera and HPE Nimble Storage solutions usually scale up from medium to large infrastructure customers and offer a number of advanced features that appeal to this customer set. The MSA on the other hand appeals more to those looking for an ultra-small scale installation from 2 to 4 physical servers.
In this case the MSA competes more with the Microsoft Storage Spaces Direct (S2D) solutions, but does so more efficiently. I should note that HPE sells solutions based on SAN storage as well as S2D storage.
Now let’s explain how a SAN solution can be less expensive and more efficient than the equivalent S2D solution. We can start with a 2-node Windows Fail-over Cluster that could be used to run either Docker Containers, Hyper-V VMs, or the application(s) of your choice.
When deploying S2D you will need to deploy in such a way as to provide node-to-node mirroring so that your data survives the outage of a single node. The S2D solution also needs to provide local redundancy so that if a single drive were to fail on a single node, your data on that node is still available. When using S2D you have two choices to deploy depending on your application needs; You can use Mirrored Spaces for the local redundancy, or you can use Parity spaces for the local redundancy if performance is not a concern.
Now let’s lay this out on our hardware, obviously for an S2D solution we will need a Large Drive Count, and in this case, the HPE ProLiant DL380 Gen10 with 24 x Small Form Factor Drives makes a lot of sense. I selected this Server since it is the most commonly sold 2Rack-U server in the world.
Now there are a few limitations, firstly the boot drives for a S2D solution cannot be part of the S2D space, so I will need to separate a pair of drives (mirrored) to use as Node Boot Drives. This leaves us with 22 Drives which can be used for S2D in each node. If using Nested Mirroring, I will end up Mirroring 11 drives to the other 11 drives, and then that pool will be mirrored to the other node. This leaves us with 11 Drives worth of usable space out of the total solution drive count of 48 drives.
If on the other hand I wish to use Dual Parity Spaces due to the S2D requirements we obtain 16 drives worth of capacity out of the set of 22 drives, but of course, that is mirrored between nodes, so the complete solution usable space is only 16 drives out of the complete set of 48 drives.
Now compare this S2D solution to a Dual Parity and a Mirrored Solution deployed on an MSA 2060.
In a SAN based solution we still need the Boot drives in the local server, but the server does not need any other drives installed. This lets us optimize the Nodes, and instead of using the 2RU DL380 Gen 10, we may use the DL360 Gen 10, which only lacks support the high drive count at the advantage of only consuming 1Rack U worth of space.
Below are a few advantages of the MSA solution
- The licensing option for Windows Server as a S2D solution may only use the DataCenter Windows OS licensing, while the SAN based solution can use either Windows Server DataCenter Licensing, or the far less expensive Windows Server Standard Licensing.
- Upgrading either the node count, or the capacity on the S2D solution requires rebuilding the environment the S2D is fixed as a two node mirror. The only upgrade is to rebuild this as a 4-node S2D cluster. This differs from the SAN based solution since you can add an expansion shelf to the MSA and expand your usable storage without downtime. You can also add more nodes to the cluster and organically grow the cluster with added nodes also without downtime.
- Reduction in drives from 48 (S2D solution) down to 28 (MSA Solution) without a decrease is usable space or reliability.
- The MSA solution offers offloaded Snapshots which can be directly exposed to a backup infrastructure.
There are also a number of factors that simply are equal between the solutions
- Each solution supports using an embedded SSD cache tier to accelerate spinning drives. I did not go down that path since here since it would double the size of the blog.
- Each Solution requires a high speed network, in the case of S2D it is needed between nodes, and in MSA it will be used for iSCSI. These are roughly equal / cancel each other out.
- Each Solution consume roughly 4 Rack U, and roughly the same power/cooling.
- The DL380 supports using a rear drive bay which could let you use two more drives for the S2D solution, and the MSA can support a Boot-From-SAN type solution as well which could reduce its drive needs. The effort here was to keep the solution simple to blog
- The DL380 Gen10 and DL360 Gen10 both support the same processor and memory options.
While both the MSA and S2D solutions work in the data centre, the MSA solution excels when a scale down solution must be optimized for 2-node operations, or when that solution is expected to increase/grow organically over time. As an example, the MSA solution hosting a 2-Node Windows Fail-over Cluster can host a multitude of virtual machines to cover a consolidation effort for physical-to-virtual conversions.
Microsoft’s back-of-napkin evaluations will always favor the S2D solution since they rarely take into consideration the licensing costs of their own software.
Now that I have written this I just need to avoid the Microsoft Ninjas who now are honor bound to slay me. I will post a follow-up to this covering how this changes when you deploy a 4-Node or greater S2D solution as it does change the story radically.