Recommended Use of Zones with Java ES

While the deployment of Java ES in a multi-zone environment has the general objective of providing for product component runtime isolation and efficient resource utilization, there area number of more specific objectives for which a multi-zone environment can be used. These are discussed in as discussed in Why Use Zones for Java ES?. Installation and administration strategies for Java ES in a multi-zone environment depend largely on which of these objectives you are trying to achieve.

Table A–2 compares five scenarios, the installation and administration strategies to which they correspond, and the objectives that they are meant to achieve. While mixing of these scenarios might be possible in some cases, the results can be problematic and are likely to cause administrative mayhem. Hence, Java ES Release 5 generally does not support deployments that mix these scenarios.

Also, Scenario 1 and Scenario 5 are problematic, so Java ES Release 5 does not currently support them (though accommodation might be made for specific product components in the case of Scenario 5).

Table A–2 Zones Installation and Administration Strategies for Java ES

Scenario (Installation Strategy)	Administration Strategy	Objective (See Why Use Zones for Java ES?)	Comments
1: Install product components and shared components in the global zone with propagation enabled. No components installed in non-global zones.*	Component life-cycle management: Global administrator   Configuration and runtime management: Zones administrators	Centralized product component life-cycle management   Organizational independence for product component configuration and runtime management	Problematic: Not yet supported for Java ES product components, except for Message Queue. Requires that product components support installation in global zone but configuration and runtime management in non-global zones.
2: Install shared components in the global zone and product components in whole root zones	Shared component life-cycle management: Global administrator   Product component life-cycle management: Zones administrators   Configuration and runtime management: Zones administrators	Centralized shared component life-cycle management   Organizational independence for product component life-cycle, configuration, and runtime management	Mostly applicable when all components are of the same Java ES version, or when upgrading all product components in all whole root zones.
3: Install shared components in the global zone and product components in sparse root zones**	Same as Scenario #2	Centralized management of shared component life cycle.   Organizational independence for product component life-cycle, configuration, and runtime management   Increased resource efficiencies over Scenario #2 (See Whole Root Zones vs. Sparse Root Zones)	This scenario recommended when installing product components in sparse root zones. (Some shared components cant be installed in sparse root zones and must therefore be installed in global zone.)
4: Install product components and shared components in whole root zones	Component life-cycle management: Zones administrators Configuration and runtime management: Zones administrators	Version separation	No shared components or product components should be installed in the global zone. Recommended scenario for whole root zones.
5: Install product components and shared components in sparse root zones.	Same as Scenario #4	Organizational independence for product component life-cycle, configuration, and runtime management  Increased resource efficiencies over Scenario #4 (See Whole Root Zones vs. Sparse Root Zones)	Problematic. Cannot generally be implemented because a number of shared components cannot be installed in sparse root zones.

* Scenario 1 does not distinguish between whole root and sparse root zone environments; it assumes that no product components are installed in non-global zones. Installation of product components in non-global zones is covered in Scenarios 2-5.

** Scenario 3 assumes that /opt has not been made a read-only directory in the sparse root zone. If /opt were read-only, most Java ES product components could not be installed in sparse root zones and would have to be installed in the global zone, as in Scenario 1, as an alternative approach.

Recommended Practices

With Table A–2 in mind, here are a number of recommended practices:

• Plan your Java ES zones deployment strategy in advance depending on the objective in Why Use Zones for Java ES?that you are trying to achieve. Different objectives require different installation and administration strategies, as shown by the different scenarios of Table A–2.

• Avoid mixing scenarios. In particular:

  • Keep your Java ES zones deployment and administration strategy as simple as possible. Do not mix whole root and sparse root deployments of Java ES components on the same computer. (Procedures and practices needed to support sparse root zone deployments as in Scenario 3 can interfere with whole root zone deployments as in Scenario 4.)

  • Do not install the same Java ES product component in both the global zone and non-global zones, even if they are of different versions. (Procedures needed to upgrade a global zone installation as in Scenario 1 can break the non-global zone installations as in Scenario 4.)

  • When Release 4 (or earlier) Java ES components have been installed in a whole root zone, do not install Java ES Release 5 components (neither product components nor shared components) in the global zone, and do not upgrade Java ES components to Release 5 in the global zone. In other words, Scenario 2 is not supported when there are pre-existing Java ES installations in a whole root zone. (Installation or upgrade in the global zone could result in a mixing of Release 4 and Release 5 files in the whole root zone.)

• Recommended installation practices:

  • If you want to run different Java ES product components in different zones, install the product components in non-global zones (Scenario 2, 3, 4, 5).

  • If you want to run different Java ES product components in different zones but centrally manage shared component life cycles, synchronize shared components in the global zone, then install the product components in non-global zones (Scenario 2, 3). (This is a recommended practice whenever installing product components in sparse root zones.)

  • If you want to achieve version separation of Java ES product components or, for other reasons to isolate deployments of Java ES product components (Scenario 4), then install and configure all Java ES components in whole root zones. Do not install any Java ES components in the global zone.

• Recommended upgrade practices:

  • If you want to upgrade all installed Release 4 product components to Release 5, synchronize all Java ES shared components in the global zone, then perform the upgrade of the desired product components in the zones where they have been installed. (Release 5 shared components are backwardly compatible.)

  • If you have Release 4 or Release 5 product components installed in a non-zones environment, and you wish to add non-global zones to the environment and install product components in the new non-global zones, be sure to do so in accordance with the recommended practices above. This might mean uninstalling components in the global zone and reinstalling them in non-global zones.

Deployment Architectures

The scenario descriptions in Table A–2 and the recommended practices noted above do not include recommended Java ES deployment architectures for a multi-zone environment. Such architectures would be an adaptation of deployment architectures created for multi-computer network environments. In other words, the availability of multi-zone environments does not change the basic deployment design approaches for achieving high performance, high availability, scalability, security, and serviceability for Java ES deployment systems. What a multi-zone environment allows you to do is consolidate such deployment architectures into fewer computers.

Details of how to adapt a Java ES deployment architecture to a multi-zone environment, however, are highly dependent on the administrative strategies you desire, as discussed in previous sections. Deployment architectures also depend on your strategy for achieving high availability.

Note that Table A–2 and the recommended practices above do not include recommended procedures for implementing the scenarios that are described. In some cases the order in which Java ES components are installed and the order in which non-local zones are created can be important.