One of the VMware product managers asked me to share this with you guys and ask you to please take the time to fill out this vCenter Server availability and performance survey. It is a very in-depth survey which should help the engineering team and the product management team making the right decisions when it comes to scalability and availability. So if you feel vCenter scalability and availability is important, take the time to fill it out!
vcenter
The Compatibility Guides are now updated with VSAN and vFlash info!
For those wanting to play with Virtual SAN (VSAN) and vSphere Flash Read Cache (vFRC / vFlash), the compatibility guides are being updated at the moment. Hit the following URL to find out what is currently supported and what not:
- vmware.com/resources/compatibility/
- For vSphere Flash Read Cache:
- Select “VMware Flash Read Cache” from the drop down list titled “What are you looking for”.
- Hit “update and view results”
- For Virtual SAN:
- Select “Virtual SAN (beta)” from the drop down list titled “What are you looking for”
- Select “ESXi 5.5” and click “Next”
- Select a category (server, i/o controller, hdd, ssd), at the time of writing only server was available
- Select the type of Server and click next
- Now a list is presented of supported servers
I know both lists are short today, this is an on-going efforts and I know many vendors are now wrapping up and submitting their test reports, more to be added over the course of the next couple of weeks so keep on coming back to the compatibility guide.
Drag and drop vMotion not working with the 5.5 Web Client?
A couple of weeks I bumped into this issue where I constantly received a red cross when I wanted to “drag and drop” vMotion a virtual machine using the vSphere 5.5 Web Client. Annoying as it is something which I was waiting for to use as I used this all the time with the vSphere Client. Unfortunately it so happened that I stumbled in to a bug. Apparently when you do a drag and drop migration certain scenarios are filtered out to avoid issues. I guess the filter is too aggressive as today it filters out drag and drop to a host without the use of resource pools. The screenshot shows what this problem looks like in the UI.
I filed the bug of course, but unfortunately it was too late for the fix to make it in to the release. The engineering team has told me they are aiming to fix this in the first update release. So consider this an FYI to avoid getting frustrated around not being able to get this drag and drop thingie working. The support team just published a KB article on this matter as well.
vSphere 5.5 nuggets: vCenter Server Appliance limitations lifted!
For those who haven’t seen it… the vCenter Server Appliance limitations that there were around the number of virtual machines and hosts are lifted. Where the vCenter Server Appliance with the embedded ternal database used to be limited to a maximum of 5 hosts and 50 virtual machines this has been increased with vSphere 5.5 to 100 hosts and 3000 virtual machines when you use the embedded database, with an external Oracle database the limits are similar to that of the Windows version of vCenter Server! If you ask me, this means that the vCenter Server Appliance with the embedded database can be used in almost every scenario! That makes life easier indeed.
Couple of other awesome enhancements when it comes to vCenter Server:
- Drag and drop functionality added! So you can simply drag and drop a VM on to a host again, or a host in to a cluster
- OS X support, I know many of you have been waiting for this one.
- Support for Database Clustering solutions, finally!
By itself they appear to be minor things, but if you ask me… this is a huge step forward for the vCenter Server Appliance! Some more details to be found in the what’s new whitepaper in vSphere 5.5 for Platform.
vCenter Single Sign On aka SSO, what do I recommend?
I have had various people asking me over the last 9 months what I would recommend when it comes to SSO. Would I use a multi-site configuration, maybe even an HA configuration or would I go for the Basic configuration? What about when I have multiple vCenter Server instances, would I share the SSO instance between these or deploy multiple SSO instances? All very valid questions I would say. I have kept my head low intentionally the last year to be honest, but after reading this excellent blog post by Josh Odgers where he posted an awesome architectural decision flow chart I figured it was time voice my opinion. Just look at this impression of the flow chart (for full resolution visit Josh’s website):
Complex? Yes I agree, probably too complex for most people. Difficult to digest, and that is not due to Josh’s diagramming skills. SSO has various deployment models (multi site, HA, basic), and then there is the option to deploy it centralized or localized as well. On top of that there is also the option to protect it using Heartbeat. Now you can probably understand why the flow diagram ended up looking complex. Many different options but what makes sense?
Justin King already mentioned this in his blog series on SSO (part 1, 2, 3, 4) as a suggestion, but lets drive it home! Although it might seem like it defeats the purpose I would recommend the following in almost every single scenario one can imagine: Basic SSO deployment, local to vCenter Server instance. Really, the KISS principle applies here. (Keep It Simple SSO!) Why do I recommend this? Well for the following simple reasons:
- SSO in HA mode does not make sense as clustering the SSO database is not supported, so although you just deployed an HA solution you still end up with a single point of failure!
- You could separate SSO from vCenter, but why would you create a dependency on network connection between the vCenter instance and the SSO instance? It is asking for trouble.
- A centralized SSO instance sounds like it make sense, but the problem here is that it requires all connecting vCenter instances to be on the same version. Yes indeed, this complicates your operational model. So go localized for now.
So is there a valid reason to deviate from this? Yes there is and it is called Linked Mode. Linked Mode “requires” SSO to be deployed in a “multi-site” configuration, this is probably one of the few reasons I would not follow the KISS principle when there is a requirement for linked-mode… personally I never use Linked Mode though, I find it confusing.
So there you have it, KISS!