When I first started with virtualization, the only option you had at the time was single core processors in the hosts. Scale up or scale out was the hot debatable topic when designing your infrastructure. On one side of the coin the idea was to scale up in that it was best to get a few of the biggest servers you could find and load them up with as much memory and processors that you could fit in the box. The end result were some very expensive servers able to run a lot of virtual machines for its time. The other side of the coin presented the idea that it was better to scale out with more, smaller servers to make up the cluster. I have worked in both type of environments and attitudes over the years and as for me, personally, I aligned myself with the scale out philosophy. The simple reason for aligning with the scale out group was host failure. When you have sixty to eighty virtual machines per host and lose that host it was really a lot of eggs in one basket and took some time to recover. When you have more, smaller servers, then the shock of losing a host was not as severe because there were not as many virtual machines running on single host and it would take less time to recover. This was during the time before vCenter, vMotion, HA and DRS when it was just you and the VMware ESX hosts.
Articles Tagged with vCenter
Have you ever considered the best way to plan, design and work with VMware Update Manager (VUM)? In the early days, using VMware 3.x when VUM was first released, I would end up installing VUM on the vCenter server itself. After all, that was the recommendation from VMware at the time. I propose that this is no longer the case and I would like to present a list of best practices to follow when working with VMware Update Manager. This list came from VMware, but should only be considered as a guide. Each environment is different and your mileage may / will vary.
There is a great deal of marketing hype about which hypervisor is better but I have spent some thinking about this and really have to wonder if the hypervisor is what we should really be focusing or concentrating upon. A lot of third party vendors are starting to port their products to be able to work with both hypervisors. To see a list of some of these products check out the post Growth of Citrix and Hyper-V EcoSystems. What about the management server itself? Isn’t this really the center of the virtual universe? When third party application vendors design their applications to work with VMware or Microsoft hypervisors they have been writing plug-ins for their product to work inside the management server systems and/or its client.
I am not going to get into the discussion of which platform is better. This argument and debate has been going on for quite awhile and the fact of the matter is no one platform will be the best at everything. This is why most large scale datacenters will have a mixture of Windows, Linux and possibly a mainframe or two. I believe the same thing will happen with the virtual infrastructure in that there will be no “one size fits all.” There are enough marketing comparisons posted everywhere on the internet that I find myself looking at another more interesting fact that currently no virtual management product out there will control and manage all the different types of hypervisors. So far what I had found is that SCVMM is able to control both Microsoft Virtual Systems as well as the VMware Infrastructure/vSphere and VirtManager is able to manage KVM and Xen.
I was posed with a question today, “I’m looking for some info on account & password management for consultants that visit a lot of customers where they have to do admin stuff.” with a secondary question of “how to manage the account if a constultant leaves?” This was specific to the VMware vSphere but would apply to any hypervisor.
There are two issues:
- How to control who can access the administrative functions within their own datacenter and how to access administrative functions on remote systems spread all over the world.
Almost every enterprise that I have spoken to about their experiences in virtualizing anything more than simple or tactical applications has come across one or more that did not perform well once virtualized. In most cases these were applications that used low amounts of CPU and reasonable and predictable amounts of memory, so it stood to reason that resource conflicts in these areas were not the cause of the performance issues. Most of these enterprises had the network support for the virtualized hosts dramatically over-configured with multiple-teamed NIC’s and redundant HBA’s, so there was every reason to believe that the network was most likely not the issue either.
On 5/27, EMC announced that it was acquiring ConfigureSoft one of the two leading independent vendors of configuration, change, and compliance management software (the other leading independent vendor being TripWire). The stated goal of the acquisition is to “Empower Customers to Automate Visibility and Control Across their Physical and Virtual Data Centers”.
EMC already has a significant IT management software portfolio with products like Smarts and Control Center. These products are primarily focused upon managing the physical servers, networks and SAN’s which (in the case of storage) comprise EMC’s hardware business, or (in the case of networks and servers) are immediately adjacent to the storage business.