Provisioning - how do you approach it?
Has virtualisation changed expectations unfairly?
Workshop Buying new physical servers has always taken time and effort. Unfortunately virtualisation has managed to create the perception that the provisioning of virtual machines is quick, easy and - very unfairly - free of charge. How has this expectation changed the necessary processes when new physical servers have to be acquired?
Ask any IT manager and they will tell you that when it comes to acquiring new physical servers, it takes time to get new systems delivered, never mind getting through the interminable internal sign off procedures required to spend any money in the first place. With the spotlight still targeted at keeping a tight grip on any capital spend, how is it to possible today to specify the physical characteristics of a server in an era when such machines may be called upon to support a wide variety of services over the course of their lifetime?
In days gone by, the process was straightforward, or at least relatively so. You looked at the application to be run, calculated (usually via guesswork) how many users would have to be supported concurrently and spoke with the ISV and did some rough and ready calculations. These defined the processor speed, memory, disk space and I/O characteristics needed, to which the prudent administrator would add a “contingency” factor. Naturally enough, this took time.
Next in line was a large chunk of time and labour to get through the internal procurement and vendor approval processes, the purchase order signed off and the order to the supplier. Finally came the long, long wait for hardware delivery and, perhaps an engineer to do the installation work.
Clearly this methodology is not entirely appropriate when it comes to working out just what configuration of a server is needed to support variable virtualized workloads. Is it possible to try and work out just what is likely to be needed to run and size appropriately? Or is it a better idea to buy the biggest server that fits the available budget and work on the premise that workloads will inevitably grow to fill the beast?
Buying the biggest server possible has much to commend it, assuming that the way IT projects are financed makes it possible for such server acquisitions to be funded. Now if a large machine is purchased it makes sense to make certain beforehand that the physical resources can be managed effectively, especially in these days when the operational costs of systems are coming under more scrutiny.
We know, from your feedback, that a significant number of organisations (but far from the majority) are now approaching application and server deployments with consolidation and virtualisation in mind. Hence service deployment and delivery is now slowly becoming separated from decisions concerning hardware acquisition.
But of course this requires the use of some form of internal cross-charging models and a sufficiently far-sighted and determined IT manager or CIO to make it happen. Of course there are still companies, some of whom should perhaps know better, who still cling to the one application, one server, one budget philosophy and who cannot provision anything much inside of a couple of months.
One area where good management is becoming more important concerns assessing if the tools allow physical resources to be powered down if they are not required to run a workload. Can disks be spun down? Can unused processors be powered down? Perhaps more importantly, are there monitoring tools available on the server that highlight underutilised resources allowing administrators to actively manage the physical resources of large servers? These are challenges that will face more and more IT professionals as more powerful x86 servers are deployed inside computer rooms and data centres, especially as business and external pressures mount to control carbon footprints and electricity bills
Another approach is to buy smaller servers or blades that are capable of hosting moderate workloads without having excess capacity and that can be bought when required, assuming that the supplier still delivers such kit, as resource demands grow. Clearly, if the workload requires larger physical resources than smaller servers can host on their own, some form of resource pooling virtualisation technology will have to be deployed.
There is no doubt that the physical provisioning of servers is becoming more complex as the choices available expand. How are you managing things in a world where the virtualisation vendors have succeeded in building an expectation that workload provisioning is nearly instantaneous? Have you found a good way to keep expectations under control? Please let us know in the comment section below. ®
COMMENTS
Just because it's virtual - doesn't mean it isn't real!
Just because you can power on a VM in 5 seconds doesn't mean a thing. The workloads they generate are real - FACT!
IT typically funds CAPEX intensive architectures like virtualisation by stealing from Peter and giving it to Paul. Management always has their pet projects and the only way to "divert" their funds is to oversize the requirement and hopefully replace some of the old crap in the DC (shh! it's a secret). As for saving OPEX to fund CAPEX - OPEX budgets are typically under the control of the ops folks - and they NEVER have enough! You can do a million TCO calcs and no ops manager is ever going to believe them or relinquish his grasp on the funds. Any idiot can spend $1m on hardware. Ops has SLA's which they get hammered on.
Until IT management and the CxO's of the world have the foresite to realise they are saving money by spending money on the latest and greatest of gear... i.e. embracing Moore's Law which is more than 3 decades old.. they will never see return on investement. Yes it's a paradox. Get with the program! Keeping a server for 5 years is RETARDED!!!
"Corporate capacity."
(Non developer) IT has (in my opinion) really broken into a few generalised groups.
The human cron job: Somewhere there needs to be a human cron job running around looking to do garbage collection wherever possible on old or unnecessary VMs. (S)he should also be scavenging storage off the storage arrays, and physical space in the data centers. An efficiency expert who simply repeats the same efficiency creating algorithms on a regular basis, because they are always required.
Cloudherders: Cloudherders are systems administrators, network administrators, storage administrators, virtualisation experts etc. Their job is to take the equipment they are provided and make the best possible use of it. Cloudherders also need to be capable of producing a report on a regular basis saying "we will need X amount of capacity by Y date, if current growth holds." They are the crew of the great ship datacenter; they keep her in repair and on course.
The Captain: (S)he is in charge of the whole mess, and must be able to make sense of the whole mess. (S)he must take the efficiencies found from the human cron job, the needs requirements from the cloudherders and must be high up enough up the corporate food chain to be plugged into any "big projects" coming down the pipe that will cause spikes in demand. Their job is to secure funding, design and prototype new systems, oversee the overall network design and architecture, deal with suppliers, vendors, inter- and intra- corporate management tantrums, coddle the egos of their staff and have backup plans for their back plans that are themselves backed up with back up plans. (Depending on the size of your organisation, the captain may or may not have a first mate. In smaller organisations the captain may be required to also be a cloudherder or human cron job.)
So, how to you deal with capacity issues? Well, you can’t look at it department-by-department, project-by-project any more. The corporation is a ship, and any good captain knows that issues with one area of the ship affect all the others. Capacity is now measured company wide, and must be dealt with as such. In some cases, (such as multi-corporate “clouds” or even “cloud provisioned services” bought fromt eh likes of Amazon,) capacity is something that extends even beyond the barriers of the corporation itself. Then you must start making considerations such as “fantastic, I’ve got a 100Mbit fibre pipe to my ISP, but who am I sharing a router with, what’s the backhaul from that router to the nearest C/O, and what kind of capacity constraints am I faced with trying to access my data which is now in locations A, B and C.”
Each of the roles in IT infrastructure are vital; they can’t be neglected and they can’t be marginalised. It just isn’t a “one piece of metal to a task” world anymore. (There are too many tasks, and not enough DC space or cooling.)
Your mileage will vary; the above is my personal take based entirely upon my experiences in the industry.
Process
We've been running VMWare for about 12-18 months and the funding has usually come from one major project. As an architect you find over time new projects realise they can save money and time by using virtual servers and it's then our job to ensure that we control the sprawl and try to fund new hardware without penalising one project. It's a difficult situation that we're only just beginning to understand and develop the processes to control.
"Oh just stick it on a VM." Is a sentence we are hearing more and more from PM's and SDM's...
Poisoning
I saw the title and read it wrongly:
Poisoning - How do you approach it?
(You don't owe me a new keyboard as it's my fault for not reading what's written.)
