For the last episode of 2024, I invited Deji Akomolafe to discuss running Microsoft workloads on top of VCF. I’ve known Deji for a long time, and if anyone is passionate about VMware and Microsoft technology, it is him. Deji went over the many caveats, and best practices when it comes to running for instance SQL on top of VMware VCF (or vSphere for that matter). NUMA, CPU Scheduling, latency sensitive settings, power settings, virtual disk controllers, just some of the things you can expect in this episode. You can listen to the episode on Spotify, Apple, or via the embedded player below.
Unexplored Territory Episode 086 – VCF 9 and vSAN 9 storage and data protection vision with Pete Koehler
I just rebooted the Unexplored Territory Podcast after a break of 2 months. In this episode I discuss the VCF 9 and vSAN 9 storage and data protection vision with my colleague and good friend Pete Koehler. I hope you enjoy the show!
Storage IO Control, aka SIOC, deprecation notice with 8.0 U3!
Recently it was announced that SIOC was going to be deprecated and that SDRS IO Load Balancing as a result would also be deprecated. The following was mentioned in the release notes of 8.0 Update 3:
Deprecation of Storage DRS Load Balancer and Storage I/O Control (SIOC): The Storage DRS (SDRS) I/O Load Balancer, SDRS I/O Reservations-based load balancer, and vSphere Storage I/O Control Components will be deprecated in a future vSphere release. Existing 8.x and 7.x releases will continue to support this functionality. The deprecation affects I/O latency-based load balancing and I/O reservations-based load balancing among datastores within a Storage DRS datastore cluster. In addition, enabling of SIOC on a datastore and setting of Reservations and Shares by using SPBM Storage policies are also being deprecated. Storage DRS Initial placement and load balancing based on space constraints and SPBM Storage Policy settings for limits are not affected by the deprecation.
So why do I bring this up if this was announced a while back? Well, apparently, not everyone had seen that announcement, and not everyone fully understands the impact. For Storage DRS (SDRS), this means that essentially, ‘capacity balancing’ remains available, but anything related to performance will not be available in a next major release. Also, noisy neighbor handling through SIOC with shares and, for instance, IO reservations will no longer be available.
Some of you may also have noticed already that in the UI on a per VM level the ability to specify the IOPS limit had also disappeared. So what does this mean for IOPS Limits in general? Well, that functionality will remain available through Policy Based Management (SPBM) as it is today. So, if you set IOPS limits on a per VM basis in vSphere 7, if you upgrade to vSphere 8 you will need to use the SPBM policy option! This IOPS Limit option in SPBM will remain available, even though in the UI it shows up under “SIOC” it is actually applied through the disk scheduler on a per-host basis.
VCF-9 Vision for a Federated Storage View and vSAN (stretched cluster) visualizations!
As mentioned last week, the sessions at Explore Barcelona were not recorded. I still wanted to share with you what it is we are working on, so I decided to record and share a few demos, and some of the slides we presented. In this video, I show our vision for a Federated Storage View for both vSAN and more traditional storage systems. This federated view will not only provide insights in terms of capacity and performance capabilities, it will also provide you with a visualization of a stretched cluster configuration. This is something that I have been asking for for a while now, and it looks like this will become a reality in VCF 9 at some point. As this revolves all around visualization, I would urge you to watch the below video. And as always, if you have feedback, please leave a comment!
VCF-9 announcements at Explore Barcelona – vSAN Site Takeover and vSAN Site Maintenance
At Explore in Barcelona we had several announcements and showed several roadmap items which we did not reveal in Las Vegas. As the sessions were not recording in Barcelona, I wanted to share with you the features I spoke about at Explore which are currently planned for VCF 9. Please note, I don’t know when these features will be generally available, and there’s always a chance they are not released at all.
I created a video of the features we discussed, as I also wanted to share the demos with you. Now for those who don’t watch videos, the functionality that we are working on for VCF-9 is the following, I am just going to do a brief description, as we have not made a full public announcement about this, and I don’t want to get into trouble.
vSAN Site Maintenance
In a vSAN stretched cluster environment when you want to do site maintenance, today you will need to place every host into maintenance mode one by one. This not only is an administrative/operational burden, it also increases the chances of placing the wrong hosts into maintenance mode. On top of that, as you need to do this sequentially, it could also be that the data stored on host-1 in site A differs from host-2 in site A, meaning that there’s an inconsistent set of data in a site. Normally this is not a problem as the environment will resync when it comes back online, but if the other data site fails, now that existing (inconsistent) data set cannot be used to recover. With Site Maintenance we not only make it easier to place a full site into maintenance mode, we also remove that risk of data inconsistency as vSAN coordinates the maintenance and ensures that the data set is consistent within the site. Fantastic right?!
vSAN Site Takeover
One of the features I felt we were lacking for the longest time was the ability to promote a site when 2 out of the 3 sites had failed simultaneously. This is where Site Takeover comes into play. If you end up in a situation where both the Witness Site and a data site goes down at the same time, you want to be able to still recover. Especially as it is very likely that you will have healthy objects for each VM in that second site. This is what vSAN Site Takeover will help you with. It will allow you to manually (through the UI or script) inform vSAN that even though quorum is lost, it should make the local RAID set for each of the VMs impacted accessible again. After which, of course, vSphere HA would instruct the hosts to power-on those VMs.
If you have any feedback on the demos, and the planned functionality, feel free to leave a comment!