In response to Miguel’s post, here are my thoughts:

I’m sure at least one of the VMware dudes Miguel was talking to was once a Windows System Administrator. I’m also sure that that same VMware dude cringed at the thought of needlessly putting multiple services on a single VM. He probably thought that as long as the customer had enough money for Windows Server licenses, compute and disk resources, that one should obviously separate each service into their own server. Now, to take a step back, let us say that, yes, it certainly is possible to put all the services you mentioned, vCenter, SQL 2008, VUM, and maybe even SRM on the same box, whether virtual or physical. But of course, whether this is possible or not is not in question. It’s whether it should or should not be done in the first place. I’m going to pull out the age old consultant’s answer and say, “It depends.”

It depends on if the customer has the budget for more Windows or SQL licenses. Does the customer have the compute and disk resources for several more servers? Is there already an existing SQL box or cluster that could be used? Is a DBA on staff, or at least a competent Windows Server admin? Does the customer’s environment even need a full blown SQL installation or would SQL Express do fine?

Now I’m coming from a background of government contracting where money is usually thrown at such projects. Resources for such an implementation are little thought about because they’re going to be there no matter what. This question could impact SMBs more, but probably not large corporations.

I think there are certainly right and wrong ways to implement based on circumstances. On the one hand, if you have the licenses, compute, disk, and administrative resources, I say absolutely, put each service on it’s own separate box. In more constrained environments, you may need to double up two or more services.

That’s not the least of it. Recovering from a failed VM will cost you less in time, effort, and hopefully, money. With an “all your eggs in one basket” approach, if one VM goes down, is somehow unrecoverable, then you’ve lost a lot of data. Separating your services reduces the liklihood that any one VM failure/loss will result in mutlitple services lost.

Google

vmmojo

So I was having a discussion with a few fellow VMware dudes, and we were discussing the vCenter installation methods. One train of thought is to install vCenter, VUM, SQL 2008,, and SRM on 1 VM with 2 vCPUs, 4 GB of memory an a 100 GB drive, Monitor for performance and adjust as required by analyzing the performance data. I have alwbeen doing installations this way lately without issue. I have also done installations on dedicated SQL boxes \ VMs. I have gotten good performance out of the environment with having all services on a single VM. In larger environments of 20 or more hosts and 300 + VMs, I have used a dedicated SQL server. The SRM documetation recommends a separate server for the SRM installation, but I have not seen any issues with it on the same box, and there was not any performance degradation in an…

View original post 147 more words


3 Comments on “”

  1. vMario says:

    Hi Mike,
    I am currently doing a project, where I am exactly at this point where I need to take a decision about the vCenter & SRM (and the other related services) design.

    To be globaly the answer “It depends” like you said is propperly the best 🙂

    In my case the environment has around 25 hosts and 300 VMs and will be growing more and more in the future, but it is not expected to be more as 50 hosts and 500 VMs.
    It´s splitted up into two data centers with its own vCenter running in linked mode.

    In this project the budget is not unlimted so saving licence costs would be nice. Additional to the Windows and SQL licence there could be some products which are licenced by the number of VMs (like vOPS, SRM etc.).

    You mentioned that an advantage of splitting up the services to multiple VMs would be, that if a single VM goes down “just” one service is affected instead of all (if running inside one single VM). If you take a look on the dependencies of these service you will quick discover that if your vCenter VM goes down all other services (VUM, SRM, WebClient etc.) get useless even if the are running.
    Of course if just the server with the VUM installation goes down, vCenter, SRM etc. keeps going.
    The splitting up szenario brings also a little bit more complexity to your environment and you need to make 120% sure that services like DNS, firewalls etc. work properly (ok that should be done anyway). But still it´s easier if you don´t need to take care about it and just typ localhost into the configurations 🙂

    At the moment I lean towards to splitt the installation up into two servers:
    1. vCenter, vCenter-DB, VUM, WebClient
    2. SRM, SRM-DB

    Putting the SRM installation on a seperate server as vCenter is also recommended by VMware.

    Regards,
    Mario

  2. Hi Mario,

    It seems the choice of multiple services sharing the same box is a question a lot of people have. Where official VMware recommendations exist, one can choose to follow them. Other times, it is perhaps most dependent on the size of the infrastructure, such as a large enterprise versus a small business and therefore the predicted loads on each service. When left to make a decision, one should take all available information into account, then make an educated choice as to which services to co-locate on the same box. Personal experiences are useful in these situations, as well.

    Thanks for reading.

    Cheers,

    Mike

  3. So this is a good discussion on design, best practice and experience in the field with a multitude of customers. It is difficult to provide an answer if the experience is limited to a few installations and customers based on other’s designs as the responsibility is the designers and not of the implementer.Most good Engineers will evolve as they gain experience in the field based on the number of years in virtualization, the number of implementations, the number of designs and the number of projects they have under their belt. The whitepapers and VMware documentation provide excellent guidelines based on they believe is a good design and good practice that will help the customer stay within the confines of performance and availability.

    The use of the documentation in conjunction with your experience can help you arrive at a decision that is best for your customer in regards to availability and ease of management. You have to put yourself in the customer shoes. They are going to manage it long after you are gone. If you have ever been a VMware administrator in a medium environment of 300 to 500 VMs, you will soon see that VM sprawl can make your life difficult. Most, if not all organizations have people wearing multiple hats, keeping AD, SQL, storage and the other services that make up an organization. Remember IT is a service provided to the customer, and we have to manage it.

    Based on my experience in the field, VMware documentation, and a solid design background, I opt for less servers providing services in a virtual environment. I leverage the capabilities of the product and the design to develop a project and implementation plan. I am currently on a project that has VUM, vCenter, and SQL all on different VMs. This is definitively the first time I have ever seen this type of implementation, but it is not my design, so I am implementing it. I have worked with customers ranging from fortune 100 oil companies, banking institutions, universities, hospitals with 20 to 100 hosts to small high schools and 3 host clusters, and I or we dependent of the company I worked for put vCenter, VUM and SQL on the same box. I agree that SRM should be on a separate VM, but have also seen it all on vCenter without issue in a 12 host, multi-datacenter environment without issue. The fail-overs were flawless and administration was simple.I have also seen and implemented several decentralized SQL DBs hosting the vCenter\VUM design.

    Mario has an excellent point in his design and the failure of vCenter rendering it useless regardless of the location of the DB and VUM. Which will give you better performance? What are the recommendations for memory and vCPUs for the vCenter with SQL and VUM in a single platform? What has been your experience with the different types of designd and what was the empirical data to substantiate the performance? A lot of questions to know and answer regarding a design.

    If I lose vCenter, what do I lose? Have you ever lost a vCenter in a production environment and what were the consequences? Is production affected? Is it difficult to stand up a vCenter? Are you using vCenter Heartbeat, HA and DRS? Are we thinking physical or virtual?

    Simple and robust, or complex and a pain to administer, I would choose to make an educated and experienced choice, and I would not hesitate to ask for help and advice on my design.

    Great subject.


Leave a comment