Subject: Sizing Replacement Servers

Audience: All

Date: September 22, 2007

I use the following formula to size the minimum number of cores on replacement servers. The formula is based on "used" performance on the installed servers matching "used" performance on the replacement server**.

	
		(u1)(c1)(p1)
	c2   =      -----------------
		(u2)        (p2)

Where
	c1 = # cores on the installed server
	p1 = "performance per core" of the installed server
	u1 = % utilization of the installed server

	c2 = # cores on the replacement server
	p2 = "performance per core" of the replacement server
	u2 = % utilization of the replacement server

If consolidating multiple stand-alone servers to micropartitions, sum the replacement cores (c2) required for all the stand-alone servers.

The "performance per core" should be based on a relevant benchmark for your workload. The preferred metric is your application's benchmark. In absence of that information, pick an industry benchmark that approximates your work load. Historical and current benchmarks for AIX servers can be found at

http://www-03.ibm.com/systems/p/hardware/system_perf.html

In all cases, you should size for the peak utilization during your peak processing period (daily, "month end", "seasonal peak", etc). If the replacement server uses micropartitions, use the aggregate peak utilization. (Note: Servers peak at different times, so the aggregate peak is not the same as the sum of the individual peaks.) A good tool for determining the aggregate peak utilization is Steve Atkin's "NMON Consolidator Tool":

http://www-941.haw.ibm.com/collaboration/wiki/display/WikiPtype/nmonconsolidator

Choosing the CPU "% utilization" for the replacement server depends on whether its using LPARs or micropartitions. Here are my guidelines for the minimum sizing, with my standard disclaimer: "Your results may vary. Use your best judgement."

LPARs, Stand-alone Servers, Capped Micropartitions

1. Size for the peak processing period. Target the replacement server for 90-100%.
2. If peak processing unknown, size the replacement server for an average 30% utilization.

Round up to the nearest core.

Uncapped Micropartitions

1. Size replacement server for the aggregate peak of the installed servers. There is some overhead associated with micropartitioning, so size the replacement server for 80-90% utilization during the aggregate peak..
2. If aggregate peak is unknown, size the replacement server for the average utilization of the installed servers. Target the replacement server for 50%-70% utilization so it has spare capacity for the peaks.

Round up the shared pool to the nearest core.

Final comment. Micropartitioning has two at least two sizing advantages. Typically it requires half the CPUs as LPARs. And sizing micropartitions is more forgiving. If you size incorrectly, its easy to move resources to where its needed. My experience is that I oversize half the micropartitions and undersize the other half. On the average, the sizing is OK.

** Here's how to derive the formula:

	Installed server(s)                      =   		Replacement server
	Used performance                    =    		Used performance 
	(u1)(c1)(p1)	                          =   		(u2)(c2)(p2)

where 	c = # of cores (1 = existing server, 2 = replacement server)
	u = utilization
	p = performance per core 

Solve for the number of replacement cores "c2"