VMware has released a new KB article all about investigting the health of a vCenter database.
I’ve blogged before on the major issue with vCenter being a massive single point of failure and also on some steps to work out excessive growth in the database which is now included in this article.
This new KB article does provide good advice and plenty of additional troubleshooting steps for working out where your issues are but the fact still remains that the current design for vCenter is far too monolithic, relying on a database that vCenter itself can corrupt, especially when VDI may require constant availability and more and more management products “bolt-on” to vCenter
Also, alarmingly, the final troubleshooting step is:
Reinitializing the vCenter database
A reinitialization of the vCenter database will reset it to the default configuration as if the vCenter server was newly installed. The following are a few situations which could warrant reseting the database:
- Rebuild of vCenter is required
- Data corruption is suspected
- At the request of VMware Support
Ouch!
This post is the last in the series: Designing a Virtual Infrastructure that Scales.
I hope I’ve managed to give you some information on what you need to be considering when scaling your virtual environment but this series isn’t actually about giving you all the answers but rather to help you think about the questions you need to be asking to make sure you are getting the answers specific to your environment.
So, in summary:
- Keep it simple!
- Engage everyone
- Do your research
- Do thorough planning
- Think big
- Think ahead
- Start small
- Create modular building blocks
- Make it the same everywhere
This all started as a presentation at the London VMware User Group meeting, #LonVMUG where I talked about some of the things you should be thinking about when scaling your virtual infrastructure.
Here are the links to all the posts:
Part 1, Taking Stock
Part 2, Speak to the People
Part 3, Scaling for VDI
Part 4, Designing Thinking
Part 5, So, after all that…
This post is the fourth in the series: Designing a Virtual Infrastructure that Scales.
In Part 3, Scaling for VDI, I went through some of the considerations specific to VDI and talked about how big your environment can get if you decide to go VDI.
In this post it’s time to talk about actual infrastructure design and start thinking and planning for how to handle scale.
In Part 1, Taking Stock, I talked about how the virtual hosting environment you built a few years ago may be starting to get a little unwieldy to manage. I suggested: “Now is the time to pause if you can and take stock. Have a good look at your current environment and then zoom out and look at the big picture to plan the next stage of your virtual infrastructure because if you don’t you may find it running away from you.”
Hopefully by now you have an idea of what you actually need to virtualise. You’ve identified the number of servers and workstations, what resources they will require, who is going to be accesssing them, from where and at what times. You should know which VMs require business recovery and to where. You have done some calculations on how many hosts you will need to host your VMs and planned failover capacity for HA and DRS. You have an idea of VM network requirements, storage space and IOPS required.
Now is the time to use all that information gathering and see how you can build an infrastructure to run it all.
Read more…
This post is the third in the series: Designing a Virtual Infrastructure that Scales.
In Part 2, Speak to the people, I went through some communication ideas to involve more people in the information gathering stage to ultimately be able to put together a better infrastructure
In this post I’m tackling the things you need to be thinking about when you consider VDI.
So…VDI, the promised solution to all your IT needs. No PCs on desks, thin clients, zero clients, happy clients, automated provisioning, stateless VMs, thin apps, streaming.
VDI is certainly a very different way of delivering IT to clients, it can be seen as terminal services on steroids, using some of the benefits of shared resources but allowing separation when you need it.
Why is VDI any different from just having VM workstations which people connect to?
Read more…
This post is the second in the series: Designing a Virtual Infrastructure that Scales.
In Part 1, Taking Stock, I talked about looking at your current environment and seeing where you need to get to by doing a bit of crystal ball future capacity planning combined with understanding your current infrastructure limitations.
In this post I’m going to talk about something that isn’t done enough in infrastructure projects and that’s actually talking to real life people.
Many enterprise IT departments are pretty big places aften spread across the globe working in different timezones in multiple separate vertical silos. You quite possibly may not have met everyone in your own team let alone know what everybody else does in your office.
If you’re going to think about an infrastructure change to support a much bigger virtual environment, isn’t it worth looking at the really super-duper-bigger picture. Unless you know anything and everything (and there are some of you that may do!) you really should be getting other people involved from the very beginning to see if they would like to jump on the bandwagon and make changes to their environment for the greater good.
Read more…
I recently had the privilege of presenting at the London VMware User Group meeting, #LonVMUG where I talked about some of the things you should be thinking about when scaling your virtual infrastructure.
I’ve turned part of the presentation into a series of posts, going through some of the aspects you should be considering when your virtual environment demands bigger, better, faster, more!
Part 1, Taking Stock
Part 2, Speak to the People
Part 3, Scaling for VDI
Part 4, Designing Thinking
Part 5, So, after all that…
Designing a Virtual Infrastructure that Scales: Part 1, Taking Stock
Read more…
After my previous post about vCenter availability I thought I should expand on some other factors related to availability and what you should be thinking about to protect your business against failure.
Too often IT solutions are put in place without properly considering what could go wrong and then people get suprised when they do. Sometimes the smallest things can make the biggest difference and you can land up with your business not operating because some very small technical glitch that could have been avoided brings everything down.
Planning for failure should be a major part of any IT project and the cliche is certainly true, “If you fail to plan you plan to fail.” Planning for failure includes big things like a full site disaster recovery plan but also includes small things like ensuring all your infrastructure components are redundent and you don’t have any single points of failure.
Read more…
I’ve been meaning to write this post for ages and its been gnawing at my brain for months begging to be written so grab a big cuppa and settle down for a long one!
vCenter in my opinion is now the major weakness in VMware’s software lineup. Unfortunately it is that big fat single point of failure that just doesn’t cut it any more in terms of availability.
Lets think back to when VirtualCenter as it was then called was unleashed on the world in 2003.
At the time it was the wonder application that connected your ESX servers together allowing the game changer that was VMotion. You could easily provision VMs from templates, monitor your hosts and VMs and generate alerts. The VMware SDK was what allowed the building of PowerCLI, one of the best powershell examples out there. The VMware management layer was born.
Since then Virtual Center became vCenter and until probably some time last year this was all good. It was a great single pane of glass to look at and manage your virtual environment, hosts, clusters, resource groups, DRS, vMotion, HA etc.
It didn’t need to be highly available. If vCenter went down vMotion and DRS would be affected and you wouldn’t be able to provision new VMs but your underlying VMs running on the hosts would not be affected. HA was configured in vCenter but the information was held on the hosts so even if vCenter failed HA would still be able to recover VMs in the event of a host failure.
Now the situation is very different, there are more and more VMware management products that rely on vCenter. Have a look at the VMware Management Products picture in the VMware Virtualization and Cloud Management solutions overview.
That’s a lot of applications that now rely on vCenter and this doesn’t even cover everything.
Read more…
Recent Comments