Good day everyone. It been a few weeks, like busy with work and such. Anyways, this post will go into how Management & Operations are done in S2D. Now, my biggest pet peeve is complex GUI management and yet again, Microsoft doesn’t disappoint. It still a number of steps in different interfaces to bring up S2D, Check out Aidan Finns blog post on disaggregated management from last year. It still rings true to this day with the release of 2016. It shouldn’t be this complex IMO 🙁 That being said, let move to the details.
Management & Operations
Microsoft is pushing everyone to use PowerShell as the primary management tool for Storage Spaces, but you can also manage it with a combination of Windows Failover Cluster Manager, SCVMM, and SCOM as mentioned above. So if you are good at Powershell, management is fairly simple. If not, then you have the classic switching between different tools management experience :(. This is why everyone really needs to start their PowerShell training now, to survive as an architect in Microsoft land going forward ;).
There is a Health Service built into Windows Server 2016 that provides some decent system health and status information for Storage Spaces. I just saw a few demos at ignite16 and have not played with it yet, so I’ll have to dig into this further and see how they stack up in a future post.
S2D supports cluster aware updating that integrates with the Windows Update Service. Like VSAN, because they run in kernel, they need to live migrate VMs off the host server, perform the update, reboot, and then migrate everything back. I’ll note that this is only the case for the hyper-converged deployment model. In a converged model where the VMs are on a separate compute tier, you can update the storage controllers one at a time fairly seamlessly without impacting VMs on the separate compute tier.
While I am not a big fan of the management, this could give rise to tools like 5nine if they decide to support S2D management. Next up. Application and Performance, Until next time, Rob.