Virtual and Hardware partitioning

[Darrell McClure]

Greetings,

My management is looking at consolidating the HPUX server farm. What are the Pro's and Con's of hardware and virtual partitioning of a large RP class server?

Thanks,

Darrell

[Steven E. Protter]

Virtualiztion provides you more flexibility. If you have a virtual machine that is slowing down you can task another processor to the vpar.

That makes you able to deal with short term issues more easily.

There are still a few points of failure that can bring down lots of vpars or and entire complex. Thats a con.

SEP

[lawrenzo]

some information form notes I have:

Why partition a system:

fault isolation - hardware, OS, application

when a piece of hardware assigned to a partition fails it only effects the kernel and app running on that part. There are some hot swap componants that can be chjange without bringing down kernel or app. this is known as OLA/R

Performance -

different apps have different usage on the system, since each partition runs its own instance of the kernel the apps can be split ammoungst them allowing individual kernels to be tuned uniquely.

Flexibility as mentioned by SEP

Scalability -

The system is designed to allow the user to add new hardware to meet the demands for cpu, memory and I/O. The systems can be quickly configured making use of the addons resource in many cases without a reboot.

Cost and Space efficiency.

Datacentre floor space can be expensive therefor 2+ systems will reduce this.

One issue we have had is that if the frame goes down all partitions go down!

HTH

[Mark Nieuwboer]

Hi Darrell,

There are a lot of pro and contra but it is how your company is working with the hardware.

If you have to change our put hardware in systems often it's better to hard partition the systems because then only one partition has to be brought down.

If you make all your systems high available
i mean by that every hardware you have for a system (vpar or Napr) there is a backup for. You have limits for the amount of vpars you can make and you must look very carefull which hardware you take. For instance the rp7420 has 2 single pionts of failure and 2 irritating pionts.

Also the big hardware of HP is very expensive.

What about the vpars you can dynamcly add free hardware but it still means you have to reboot the vpar to let the change take place.

I have made also a plan for my company and we have decided to take a rp8410 with enough processors and memory.
From This hardware we make 4 npars. after this we have can make 2 vpars on the npars with each dynamcly 1 to 3 processors all our severs are high avalible.
This configuration means you are flexible but if something failes your not complete helpless.

i hope this information helps.

grtz. mark

[Ken Grabowski]

One point to remember, you can vPar on the SuperDome, 8400, 7400, and 5400. You can only nPar on the SuperDome, 8400.

[Jeff Schussele]

Hi Darrel,

Earlier answers taken, btu don't forget about the new "virtualization" available on the Itanium platforms - VSE (Virtual Server Environment).
This allows granularity down below the CPU level. In other words you can assign 1/2 a CPU to a virtual host and share the memory & even I/O.
We're currently evaluating migrating our Dev environment to this.
We calculate that we could literally stack 10 - 15 Dev "hosts" onto a maxxed out rx8620 saving millions of $.
I strongly suggest your management do the same eval on VSE.

My 2 cents,
Jeff

[Mark Nieuwboer]

Hi ken is not completly right you can npar also on a rp7420.

grtz. mark

[Alzhy]

I must have been sleeping..

Really? There is now a virtualization solution for the Itanic Integrity Servers that can do sub-CPU partitioning and even share I/O and LAN resources (ala vMware)?

I thought it is still vPars that you need to use to virtualize HP-UX instances?


Darrel, with regards to your question:

Hard Partitioning (nPars) has the advantage of being completely isolated whilst vPars (the only virtualization solution for HPUX that I know of) depend on the health of the host server or hard parition (nPar). However, unlike other hard paritioning solutions from SUN or IBM, online addition of resources (a whole cell/system board composed of cpu/memory/io-slots) is not possible.

Soft Partitioning has the advantage of allowing you to quickly re-provision your environments. With HP vPars however, the only resource that you can dynamically re-allocate is the CPU. The current solution also requires that each vPar has its own HBAs/PCI bus allocation for boot, storage and network -- so you are limited by the number of slots. Even with this limitation though - vPars is a very compelling and cost effective solution at server consolidation andmaking the most our of your otherwise idle big RP machine.

[Jeff Schussele]

Hi Nelson,

Yep - see the following doc:

http://docs.hp.com/en/T2767-90004/installing.pdf

And they also have a book out now from www.hp.com/hpbooks. This from the guys that spearheaded the project - The HP Virtual Server Environmant:

ISBN# 0-13-185522-0

Check it out - I really think this is HP's future. They're literally targetting the VMWare market. Smart move IMO.

Cheers,
Jeff

[Alzhy]

Thanks for the link Jeff! I guess I must have been sleeping!

;^)>

Now I am confused.. why then did HP still release vPars 4.x for Integrity HP-UX environments if they already have sub-CPU partitioning?

And why did they not port VSE to PA/HP9000 machines?

[Darrell McClure]

I appreciate all the valuable information. With all the experience here, has any one had any significant issues/failures with partitioning?

Thanks,

Darrell

[Jeff Schussele]

Hi Darrel,

No - no major problems, but there are issues with vPars such as initial loads of partitions after the first being more of a pain than usual & not being able to do make_tape restorals on any partitions w/o taking them all down. With nPars these are non-issues of course. Also vPars were not available for 11iv2 (11.23 both PA-RISC & Itanium) systems but it just came out.

Nelson - VSE or VM, if you will, can run *within* vPars, so it's not really a "competitor" to vPars, per se. Basically it's built upon the WLM framework. But it can do much, much more than WLM. But I see it as more of an add-on to nPars. I would envision a system using nPars "sliced" up in VMs. I don't think I'd want to add the vPar complexity to the mix - i.e. why would you want nPars, vPars AND VSE all in play? I think I'd not even nPar a system - just have one big system partition & THEN add VSE into the mix....Unless one needed to segregrate a subset of the hosts such that 1 set could be in maintenance (patches?) whilst the other(s) stayed up. Of course FW upgrades trump all.
And remember that these VM hosts could be running HP-UX, LINUX or eventually even MS op systems. Right now it's just 'NIX OS's.


My 2 cents,
Jeff

[Bryan Jacquot_3]

Hello,

It just so happens that your question on partitioning can be answered in the sample chapter of the book Dan Herington and I wrote. It has already been mentioned in this thread, but the sample chapter wasnâ t referenced. The title of the book is "The HP Virtual Server Environment" and it was designed specifically to answer these types of questions for each of the technologies in HP's Virtual Server Environment. This includes partitioning, clustering, utility pricing, and workload management technologies. You can see the sample chapter that discusses partitioning at the following location:

http://www.phptr.com/articles/article.asp?p=419049

Regards,

Bryan Jacquot

[Matti_Kurkela]

I think the original poster is after comparisions between nPar and vPar solutions.

Hardware partitioning (nPar):

+ nPar is based on cells you can power off individually, which minimizes downtime for hardware maintenance

- hardware requirements limit your partitioning possibilities rather severely (you need a Core IO for each nPar, and you cannot split cells apart freely)

- you cannot change nPar partitioning on the fly: to move a CPU to another nPar, you must reboot both the donor and recipient nPars.

Virtual partitioning (vPar):

- if you need to do hardware maintenance (e.g. swap a failed CPU or add some memory) you need to shut down all the vPars in the server (or in the affected nPar, if you have vPars inside nPars).

+ you can divide your CPUs and memory quite freely into different partitions

+ with vPars and Workload Manager, you can switch unbound CPUS (=ones that won't handle interrupts) from one vPar to another on the fly, and even automate that as needed

From my experience:
There is always something that requires you to power things down. If you use only vPars, it's all or nothing. When you are consolidating diverse servers into one chassis, you'll often find out that it becomes much more difficult to find a time for maintenance that is suitable for all your users.

Of course it all depends on your workload.

If you need many small partitions and/or your capacity requirements change often, you will need the flexibility of vPars - but consider grouping the vPars into nPars to give yourself a chance to avoid some "shut down everything" downtimes.

If you need partitions that are equal to a fully-populated cell or multiples of them and your requirements are mostly static and/or predictable, use nPars. It makes maintenance much easier.

However, there are times when the entire server must be brought down even when using nPars. This is mostly when a firmware upgrade is needed. Fortunately, you can usually plan ahead for that.

With consolidation, it is easy to end up in a situation where it is practically impossible to get a chance to shut down the entire large server for maintenance. Try to avoid that trap: when negotiating SLAs, make planned downtimes clear and explicit.

Be careful when designing High Availability clusters: assume that there will be times when at least one of your major servers is all the way down. If you can handle that without service breaks, your HA works. If you can handle that without serious processing delays, your HA works beautifully. You will sleep better - and have a chance of doing your hardware maintenance during regular office hours, not at zero-dark-thirty.

[Ted Buis]

Hardware partition electrically isolates partitions, so you can down one partition and add memory cards or I/O cards to that partition while others are still running. There is almost as much isolation with hard partitioning as with separate physical machines. The disadvantage of hard partitions is that it is more difficult to share resources, and unless you have extra iCAP (instant capacity) CPUs in more than one hard partition ith gWLM (Global Workload Manager), you can't rebalance even CPU resources across partitions. The vPars has no electrical isolation but beyond one CPU required per partition, CPUs can float from partition to partition as needed either manually or automatically with WLM. Memory and I/O are never shared with vPars. This provides more isolation and Integrity Virtual Machines (not available on pa-risc, only Itanium at 11.23 May 2005 release, to be available later this year), but less efficient use of memory and I/O resources. vPars has the advantage of having very low overhead, but you must have dedicated I/O cards, and RAM is fixed. Hard partitioning doesn't cost anything but vPars are extra cost. Both nPars and vPars don't run on all rp servers. IVM will be supported on all (rx) Integrity Servers. IVM will have more overhead and less isolation, since it is a true virtual machine OS on which guest operating systems are running. This allows for great efficency. vPars and IVM cannot be mixed in a hard partition. vPars or IVM can be inside an nPar, just not the same one. I haven't seen the pricing yet on IVM, but I expect there to be some cost. Along with Secure Resource Partitions, this is all part of a partitioning continuum, so the good news is you have choices, and the bad news is you have choices to make.

[Granite]

Hi Darell,

With Virtual Partitions (vPars) you can take almost any HP 9000 server and turn it into many "virtual" computers. These virtual computers can each be running their own instance of HP-UX and associated applications. The virtual computers are isolated from one another at the software level. Software running on one Virtual Partition will not affect software running in any other Virtual Partition. In the Virtual Partitions you can run different revisions of HP-UX, different patch levels of HP-UX, different applications, or any software you want and not affect other partitions.

There are some base requirements that must be met in order to run vPars on your system. At the time of this writing, the following minimum requirements must be met for each vPar on your system:

Minimum of one CPU.

Sufficient memory to run HP-UX and any other software that will be present in the vPar.

A boot disk off of which HP-UX can be booted. At the time of this writing it is not possible to share bus adapters between vPars. Therefore, a separate bus adapter is required for each of the vPars. This requirement may have been removed by the time you read this book.

A console for managing the system.