| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Solaris 10: Global Zone/Sparse Zone Combination |
« View previous topic :: View next topic » |
| Author |
Message
|
| SAFraser |
 Posted: Fri Aug 14, 2009 7:53 am Post subject: Solaris 10: Global Zone/Sparse Zone Combination |
 |
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
Per the IBM site, one of the supported configurations in Solaris 10 zones is:
| Quote: |
Approach: Installing WMQ into the Global Zone and using in non-global 'Sparse Root' zones
Overview
The principle here is to have one instance of your executables (/opt/mqm) which is visible to all non-global sparse root zones. Each non-global zone would have it's own /var/mqm and so it's own queue managers. With each zone having it's own IP address, which essentially gives you the appearance of multiple machines with WMQ, but all sharing the same installed executables.
Work required
Problem 1: Installing into the Global Zone does not create the necessary /var/mqm structure in non-global zones.
Workaround: The /var/mqm directory structure can be copied from the global zone to a non-global zone. Note that the security permissions will need to be carefully checked to ensure that they are copied correctly. Queue manager data files (contents of /var/mqm/qmgrs, with the exception of /var/mqm/qmgrs/@SYSTEM) should not be copied - having multiple copies of the same queue manager running in different zones should not be attempted.
Problem 2: The installer ensures that an 'mqm' user and 'mqm' group are created. As the installer is not being run in the non-global zones, these user and group ids are missing.
Workaround: An mqm user and group should be manually created in each non-global zone, and these used in security permission settings for /var/mqm/ files and directories in the zone. |
We are considering such a configuration on three physical servers, each with three sparse zones. We think we should be able to stop queue managers & brokers in a sparse zone, image the sparse zone on one machine, stop the zone, place the image on a different physical machine, start the zone, and start queue managers & brokers. The host name and IP address would be unchanged.
Has anyone tried this? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Aug 14, 2009 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This sounds something like a DR setup - 2 physical machines with zones sharing IP addresses. But why the third?
Disclaimer - not actually tried this. Sparse zones yes, imaging in the way you describe no.
Obviously attempting to start one of the zones with another "image" running would go off in a puff of smoke; aside from 2 identical queue managers, 2 machines with the same IP address will keep your network amused.....
Aside from that, if you keep the isolation of the zones pure it should all hang together.
Clearly if I have misunderstood your requirement or grasped any stick by an inappropriate end please correct me.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Mon Aug 17, 2009 11:55 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
It's more a business continuity strategy than a DR plan. We have about 30 queue managers to distribute across these three servers.
So my idea is to spread all thirty queue managers across six active zones, with three zones inactive. In normal operation, each physical server would have two active zones and one sleeping zone.
At anytime we wish to work on one of the physical servers (for patching, upgrades, hardware maintenance), we would move all the active zones onto two of the servers, leaving the third with no active zones. The servers will be quite powerful and can easily run three zones.
The trick, as you mentioned, will be the administration of it. Can't be sloppy and bring up queue managers in a zone that is supposed to be asleep.
As far as your ability to determine the proper end of the stick to grasp, I decline comment. Perhaps, though, exerk will have a thought. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 17, 2009 12:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| SAFraser wrote: |
| The trick, as you mentioned, will be the administration of it. Can't be sloppy and bring up queue managers in a zone that is supposed to be asleep. |
There's no way that immediately springs to mind to automate / enforce this. Naturally you would never commit such a faux pas, but the world is filled with trout targets yo-hos who might. I invite the wider community to suggest a "safety catch"
| SAFraser wrote: |
| As far as your ability to determine the proper end of the stick to grasp, I decline comment. Perhaps, though, exerk will have a thought. |
In his dreams. And my nightmares. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
