ENTERPRISE

The HP Virtual Server Environment : Combining Partitioning Solutions, Independent Software Vendor Support

10/14/2013 7:11:23 PM

1. Combining Partitioning Solutions

The various partitioning solutions in the VSE are almost arbitrarily stackable. The only exception is the fact that you cannot run Integrity VM and vPars in the same nPar. Inside each partition type you can run:

  • nPartitions: Virtual Partitions, Integrity VMs, or Secure Resource Partitions. In other words, you can run any one of these to subdivide each nPar. In addition, you can mix and match these in any combination in separate nPars.

  • Virtual Partitions: Secure Resource Partitions. You can run SRPs inside vPars if you want to save on the management and maintenance costs of separate OS images for each application.

  • Integrity VM: Secure Resource Partitions. You can run SRPs inside VMs as well.

If we take a look at all the sweet spots and think about how they might be combined to take advantage of all the technologies where they are most useful, we would get something along the lines of Figure 1.

Figure 1. Combining the Sweet Spots of All the Partitions in a Two-Node High-Availability Cluster

This figure shows what is possible with the partitioning continuum. It is likely that you will choose one or two partitioning alternatives and roll those out. That said, the real benefit we are trying to show here is the flexibility; you can implement whatever combinations make sense for your solution. Let's analyze this configuration:

  • We have the ability to run 32 workloads of various sizes on the two nodes.

  • Each system has a total of 64 physical CPUs, but only 32 of them are active. This is sufficient to handle the normal peak load of the 32 workloads. This provides us room for growth and the ability to react to short-term peaks in load. This also makes these systems significantly less expensive than they would be if we needed to purchase all the spare capacity up front. Effectively, HP is paying for much of the cost of your headroom.

  • Each system is configured with four nPars. This ensures that a hardware failure will not take down more than 25% of the system. This load can easily be absorbed by the other system on a failover because of the Instant Capacity available there.

  • Each of these systems has Temporary Instant Capacity as well.

  • Spreading this load over two nodes allows us to provide high availability.

  • Two of the workloads have their own nPars. These are relatively large workloads that normally peak out at about eight CPUs but will occasionally go over that. These nPars have 16 physical CPUs each and we will use temporary capacity for the infrequent times that they go over eight CPUs.

  • We have 16 Integrity VMs that each have four virtual CPUs. These workloads can consume a small fraction of a CPU if they are idle and can go up to four full CPUs when they get busy. These nPars also have instant capacity processors, so in the infrequent case where we have more than a few of these VMs getting busy at the same time, we can instantly activate additional capacity.

  • We have eight vPars, each of which can scale from one to four CPUs. These are for our smaller I/O-intensive workloads where peak performance is critical. Again, there are eight instant capacity processors available in each nPar just in case more than a few of these workloads get busy at the same time. If only a few of them are peaking at any time, the peaking vPars can be scaled up by borrowing CPUs from the other idle vPars.

  • Finally we have two nPars running Secure Resource Partitions. These are all running the same version of the same application, so we get the benefits of lower maintenance costs in addition to the lower software and hardware costs because we can run six copies on the 16 active CPUs. If we put these on individual systems or partitions they would each need six CPUs. We just dropped our active CPU count for hardware and software licensing from 36 to 16. And, as before, we have instant capacity processors that can take these nPars up to a total of 32 processors if more than a few of these peaked all at once.

There you have it. These systems are using all of the partition types, have an incredible amount of flexibility and scalability, and are paired for high availability. Some of you might be concerned about how you would manage an environment like this.

2. 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 issues—whether 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 case—when 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.
Other  
  •  Microsoft Lync Server 2010 : Microsoft Communicator Client for Macintosh - Client Integrations with Other Applications
  •  Microsoft Lync Server 2010 : Microsoft Communicator Client for Macintosh - Web Conferencing
  •  Microsoft Lync Server 2010 : Microsoft Communicator Client for Macintosh - Audio/Video Calls and Conferencing
  •  Microsoft Lync Server 2010 : Microsoft Communicator Client for Macintosh - IM Features
  •  Microsoft Lync Server 2010 : Microsoft Communicator Client for Macintosh - Getting Around in the Client
  •  Microsoft Lync Server 2010 : Microsoft Communicator Client for Macintosh - Installing the Client
  •  Sharepoint 2010 : Enterprise Content Management - Document Sets
  •  Sharepoint 2010 : Enterprise Content Management - Document IDs
  •  Active Directory 2008 : Configuring DFS Replication of SYSVOL
  •  Understanding and Installing Active Directory Certificate Services (part 3) - Practice Installing a CA Hierarchy
  •  
    Most View
    Spring Is Here (Part 2)
    Is 802.11ac Worth Adopting?
    BlackBerry Z10 - A Touchscreen-Based Smartphone (Part 1)
    LG Intuition Review - Skirts The Line Between Smartphone And Tablet (Part 5)
    Fujifilm X-E1 - A Retro Camera That Inspires (Part 4)
    My SQL : Replication for High Availability - Procedures (part 6) - Slave Promotion - A revised method for promoting a slave
    10 Contenders For The 'Ultimate Protector' Crown (Part 3) : Eset Smart Security 6, Kaspersky Internet Security 2013, Zonealarm Internet Security 2013
    HTC Desire C - Does It Have Anything Good?
    Windows Phone 7 : Understanding Matrix Transformations (part 2) - Applying Multiple Transformations
    How To Lock Windows By Image Password
    REVIEW
    - First look: Apple Watch

    - 10 Amazing Tools You Should Be Using with Dropbox
    VIDEO TUTORIAL
    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
    Popular Tags
    Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS
    Top 10
    OPEL MERIVA : Making a grand entrance
    FORD MONDEO 2.0 ECOBOOST : Modern Mondeo
    BMW 650i COUPE : Sexy retooling of BMW's 6-series
    BMW 120d; M135i - Finely tuned
    PHP Tutorials : Storing Images in MySQL with PHP (part 2) - Creating the HTML, Inserting the Image into MySQL
    PHP Tutorials : Storing Images in MySQL with PHP (part 1) - Why store binary files in MySQL using PHP?
    Java Tutorials : Nested For Loop (part 2) - Program to create a Two-Dimensional Array
    Java Tutorials : Nested For Loop (part 1)
    C# Tutorial: Reading and Writing XML Files (part 2) - Reading XML Files
    C# Tutorial: Reading and Writing XML Files (part 1) - Writing XML Files