Independent Software Vendor Support

HP has been shipping Resource Partitioning for over 10 years and Workload Management for over five, and we frequently get the question"How do the ISVs support this technology?" The problem can really be broken down into three key issueswhether the application can run in a partitioned environment, how it responds to automatic changes to resource entitlements, and whether there are any price breaks or penalties for using these technologies.

ISV Support of Partitions

We are primarily focused here on whether there will be any issues with an application being able to run correctly inside a partition. We will cover licensing later.

For nPars there is no issue. Each nPar is a fully electrically isolated set of hardware components. The software can't tell the difference between running in an nPar and running in a similarly sized separate system.

For vPars the same is true. Even though you don't have electrical isolation, you do assign separate hardware components to each partition. Again, the software can't tell the difference between running in a vPar and running on a separate system.

Any applications or management utilities that interact with the operating system using standard interfaces will not be affected by running in an Integrity VM. Some management applications might work differently; generally speaking, that is because they should. The design goal of the Integrity VM product is to emulate the hardware such that all management utilities should "do the right thing" when running in a VM. In other words, applications will not notice any difference and all management utilities should run without errors, or the errors you get should be expected. For example, instant capacity commands run in a VM will exit gracefully with an error that the system does not support instant capacity. This is correct because the CPUs in a VM are virtual CPUs and instant capacity operates on physical CPUs, so adding and deleting them doesn't make sense in this context. If you want to allocate additional capacity to a VM, you would activate the physical CPU in the VM host and the new CPU would then automatically be allocated to each of the VMs as appropriate.

The last partitioning solution to consider is Secure Resource Partitions. This is one where you are running multiple applications in a single copy of the operating system. The vast majority of ISV applications will run just fine with virtually any other ISV application on the same OS image. That really isn't the issue. The primary issue you need to be concerned about is whether the ISV will make life difficult for you when you call them for support. If they are going to force you to reproduce the problem on a system where their application is the only one running, it may not be worth the trouble. Of course, if you already have set up or plan to set up independent test environments, maybe this isn't such a big deal. In any event, this is one reason why we typically recommend consolidating multiple instances of the same application in an OS image. Virtually all ISVs will support running multiple copies of their own applications in a single OS instance.

ISV Support of Dynamic Resource Allocation

We are often asked whether an application will be able to take advantage of resources that are dynamically added to a partition while the application is running. How applications will handle the deallocation of resources is another common question.

The answer to the first question is yes in virtually all cases. The reason is that the OS process scheduler is responsible for allocating processes and threads on available CPUs. If additional CPUs are allocated to an OS image, the scheduler will simply spread the processes and threads out over more CPUs. This means there are fewer processes sharing each CPU and each will have access to more processing power. So the bottom line is that the application really doesn't have any choice in the matter.

The same thing can be said of the deallocation of a CPU. The process scheduler is notified that a CPU is going to be removed. It will then migrate any processes or threads that are on the run queue for that CPU to another CPU in the OS image. Once that is done, the CPU is deallocated. Once again, this is done completely transparently to the application.

The reason we said that the answer is yes in virtually all cases is that there is one case where a CPU could be added and not help. This is in the lightly loaded casewhen there are not enough processes or threads in the run queue to consume all of the CPUs that are active. In this case, adding another CPU would not help because there are no threads that can be scheduled on it.

ISV Licensing When Using VSE Technologies

The last major issue with ISV support is licensing. Many ISVs price their software based on the number of CPUs running on the system the software is running on. An interesting question is this: When you have a 16-CPU system and you are running multiple different applications there, how much should the ISV license cost? The licensing issue impacts the revenue stream of ISVs, so they are being very cautious in adopting support for these technologies. That said, many ISVs are indeed starting to support more flexible licensing schemes.

Virtually all ISVs will support licensing by the number of CPUs in an nPar. In other words, if you have a 16-CPU system partitioned into two eight-CPU nPars, you will only need to pay for an eight-CPU license if you are only running the software in one of the nPars. This is also becoming true of vPars. At this point, most ISVs will recognize that if you are running their application on only one vPar on a system, you should not have to pay for CPUs that the application can't access. You should work with your ISVs to make sure they understand the maximum CPU count configured for each vPar and make sure they will only charge you for that amount.

VMs are a more complex issue. Consider the sweet spot of running, say, four VMs, each with four virtual CPUs on a system or nPar with four physical processors. If you have an application in one of the VMs, it can realistically get access to more than three physical CPUs. Therefore, you will probably always have to pay for a four CPU license if you are running a VM with four virtual CPUs. Now consider the case where you have the same application in each of the four VMs. Should you have to pay for a 16-CPU license, even though the physical system only has four? Clearly this wouldn't be fair, and most ISVs will recognize this. However, most of them don't yet have firm across-the-board policies for how VMs should be handled. Therefore, if you are considering using VMs, you should engage the ISV's sales organization and work out a fair arrangement.

Secure Resource Partitions is the last partition option. Generally speaking, ISVs don't yet provide licensing for a subset of an OS image, although some of them are starting to investigate this. A workaround to this is the sweet spot described earlier in this chapter. Running multiple copies of the same application in a single OS image allows the resources to be shared and you can still get multiple application instances with fewer overall licenses.