For pay per use, the answer is fairly simple. You can size the system for your expected peak and you will only pay for the amount you are actually using. For Instant Capacity, you will want to purchase permanent capacity for the bulk of the normal load but use Temporary Instant Capacity for the highest of the peaks. If you have data about the utilization of your servers, you can use this data to determine how much spare capacity is needed for your workloads. The more data you have the better. If you have hourly or shorter- interval data you can determine what your peaks are and how long they last. The trick is to configure the nPar to have enough total capacity to handle the peaks but use Instant Capacity processors for the highest of the peaks. Let's use an example. The normal load on a system requires seven CPUs on average and fluctuates between 5 and 10 for all but one hour per day and goes up to 12 during that hour. For this system you could size the nPar so that there is sufficient capacity for the peak, plus, say, 30% growth and still get the nPar into two cells using dual-core processors. To summarize:
So the nPar now has two cells with eight CPUs each, but six of your CPUs are inactive Instant Capacity processors. The six Instant Capacity processors carry an up-front cost of less than two CPUs, so your cost is less than 12 CPUs instead of the 16 you would have paid for without Instant Capacity. So what happens when you need the extra two CPUs of capacity for one hour per day? You use Temporary Instant Capacity for that. Now let's consider the cost of the TiCAP. One 30-CPU-day TiCAP license is equivalent to 720 CPU hours. If you are using an average of two CPU hours per weekday, that is 10 per week. This means that a single TiCAP license will last you 72 weeks or almost sixteen months! |