Dave Levy's Weblog
Dave Levy Online
(C) more...

blogging bruxelles business cec2006 cloudcomputing community computer culture datacenter datacentre economics eu europe future futurology games google grid group holiday howto html ict2008 innovation internet ipodtouch italy java laptop linux london losug nessi news opensolaris opensource politics qube rdbms research roller rss search silly software solaris spain suncec2007 sunlabs sunw tagging tags technology theme travel twitter uk user video virtualbox virtualisation virtualization virtualworlds web2.0 windows www2006

« Maximising Creativit... | Main | Musings on wireless... »

Thursday September 16, 2004

UNIX Consolidation - Top tips for right sizing

I've been Sun UK's Principal Consultant in our Data Centre Practice since Autumn 2003 and together with colleagues been talking to customers and creating a consolidation planning methodology. The consulting offerings available to customers in the UK are described here......

The methodology involves defining the problem area or scope, creating a detailed catalogue and describing the systems, system costs, the cost scalability rules, the system capabilities and utilisation. We then map the current system consumptions onto a future state architecture, costing the transition and then performing a traditional investment analysis. This involves understanding the expected costs of the future state solution, and designing to obtain the benefits of new systems which are smaller, cheaper, faster and more reliable. We have some key rules of thumb when designing a future state, these include

Always deploy full systems; the card cage and backplane work harder justifying their cost. i.e. the cost/CPU is higher on half empty systems. ( This is a true rule of thumb, and is more appropriate for smaller systems (1-12 way)).

Big systems (& hence domains) will deliver higher utilisation, and hence the acquisition costs to obtain the necessary capability will be lower; you pay for unused capability as well as used.
Using large systems as if they were multiple small systems is silly. Only buy huge systems if you need big domains (or are at the margin of requiring big domains and value the scalability &/or flexibility).
The premium payed in buying scalable systems can be seen as an option purchase for a bigger system than deployed. i.e. buy 48 CPUs and an option for 24 more.

(2004-09-16 03:30:18.0) Permalink Comments [2]

Comments:

------ Big systems (& hence domains) will deliver higher utilisation, and hence the acquisition costs to obtain the necessary capability will be lower; you pay for unused capability as well as used. Using large systems as if they were multiple small systems is silly. Only buy huge systems if you need big domains (or are at the margin of requiring big domains and value the scalability &/or flexibility). --- These 2 sentences appear to contradict themselves, also this seems to ignore the benefits of segmenting smaller than domains using Zones or VMWare etc.

Posted by Anonymous on September 24, 2004 at 06:10 AM PDT #

You caught me. There's some careless language here, I was trying to make the point that there is a contradiction between high utilisation, (big domains) and cost/cycle. Running a big domain empty is silly. (I'm sure you'll agree). Running a big system as if they were multiple smaller systems is not as cost effective unless you value flexibility etc

I don't think I am ignoring the option of dividing systems ( although I don't say much in this article). You correctly point out it can be done. My comments (IMO) remain relevant in determining the start point at which you begin to divide the OS managed resource. This is based on one's wealth and the extend to which one values high utilisation & flexibility.

Posted by Dave Levy on September 24, 2004 at 07:32 AM PDT #