Appendix A Java ES and Solaris 10 Zones
This appendix describes the issues that arise when you install and configure
Java ES components in Solaris 10 zones, and recommends some practices regarding
for addressing those issues. This appendix contains the following sections:
What Are Zones?
Zones are an application and resource management feature of the Solaris
10 operating system. This feature allows the operating system to be represented
to applications as virtual operating system environments (zones) that are
isolated and secure. These zones provide the advantages of operating system
independence with some level of centralized resource management. Hence applications
can be isolated from one another by being installed and run in different zones,
while at the same time certain operating system resources can be centrally
allocated and administered.
From the point of view of an operating system supporting multiple zones,
operating system resources include resources such as process management, memory,
network configuration, file systems, package registries, user accounts, shared
libraries, and, in some cases, installed applications.
Structure of a Multi-zone Environment
A multi-zone environment consists of a global zone (the default operating
system) and one or more non-global zones. The global zone contains resources
that can be allocated among non-global zones by a global (zone) administrator.
Non-global zones provide the following features:
-
Security. By running distributed services in non-global zones,
you limit the damage possible in the event of a security violation. An intruder
who successfully exploits a security flaw in software within one zone is confined
to that zone. The privileges available within a non-global zone are a subset
of those available in the global zone.
-
Runtime isolation. Non-global zones allow for the deployment
of multiple applications on the same computer even if those applications require
different levels of security, require exclusive access to global resources,
or require individualized configuration. For example, multiple applications
running in different zones can bind to the same network port by using the
distinct IP addresses associated with each non-global zone. The applications
are prevented from monitoring or intercepting each others network traffic,
file system data, or process activity.
-
Administrative isolation. The virtualized operating system
environment allows for separate administration of each non-global zone. Actions
taken by a zone administrator (as opposed to the global administrator) in
a non-global zone, such as creating user accounts, installing and configuring
software, and managing processes, do not affect other zones.
There are two types of non-global zones: whole root zones and sparse
root zones:
-
Whole root zones. Contain a read/write copy of the file system
existing on the global zone. When a whole root zone is created, all packages
that are installed on the global zone are made available to the whole root
zone: a package database is created and all files are copied onto the whole
root zone for the dedicated and independent use of the zone.
-
Sparse root zones. Contain a read/write copy of only a portion
of the file system existing on the global zone (hence the name sparse root)
while other file systems are mounted read-only from the global zone as loop-back
virtual file systems. When a sparse root zone is created, the global administrator
selects which file systems to share with the sparse root zone (by default,
the /usr, /lib, /sbin,
and /platform directories are shared as read-only file
systems). All packages that are installed on the global zone are made available
to the sparse root zone: a package database is created and all files in the
mounted file system are shared with the zone.
Whole Root Zones vs. Sparse Root Zones
The choice between using whole root non-global zones versus sparse root
non-global zones depends upon a trade-off between resource efficiencies and
administrative control. Whole root zones allow you to maximize administrative
control (independence and isolation) at the cost of memory and other resources,
while sparse root zones optimize the efficient sharing of executables and
shared libraries (while using a much smaller disk footprint) at the cost of
administrative independence. There is currently no measure of the performance
advantage of sparse root zones over whole root zones; it is very likely to
be software-specific.
Package Propagation
Packages installed in a global zone are (by default) available to all
non-global zones: a process called package propagation. (For propagation to
take place, newly-created non-global zones must be fully booted, that is,
be in a running state.) Propagation provides local (non-global) visibility
and availability to packages that are installed in the global zone. Propagation
allows for application package life-cycle management (installation, upgrade,
un-installation) to be performed centrally by a global administrator, while
application configuration and runtime management are performed by (non-global)
zones administrators.
For whole root zones, propagation is achieved through the automatic
copying of installed files from the global zone to the whole root zones and
through automatic synchronization of registry information. For sparse root
zones, propagation is achieved through read-only file systems that are shared
between the global and sparse root zones and through automatic synchronization
of registry information.
Propagation of packages to non-global zones is controlled at the package
level using internal package attributes. For some values of these attributes
(the default values, at least), propagation can be disabled at install time
by using the pkgadd —G option, which overrides the
attribute values. Once installed, the propagation behavior of a package cannot
be modified, except by uninstalling and reinstalling the package. Patches,
for example, cannot change the propagation behavior of a package; in fact,
patches must be applied in accordance with the propagation behavior of the
package they are upgrading.
Why Use Zones for Java ES?
The isolation provided to applications running in different zones is
similar to the isolation provided by running applications in the operating
systems of different computers. Hence, instead of installing, configuring,
and running Java ES components on different computers in order to isolate
and secure them, those components can be installed, configured, or run in
different zones within the same computer.
This consolidation of Java ES components can also enable more efficient
resource utilization. Java ES components running in dedicated, under-utilized
computers, can be run instead in different non-global zones of a single computer.
Global administrators can dynamically allocate resources among the different
zones depending on the resource requirements of the components running in
those zones. (Note this possibility requires more knowledge and understanding
of the resource requirements of different components than is generally available
at the present time.)
A multi-zone environment can help achieve other objectives as well:
-
Version Separation. Parallel sets of Java ES components of
different versions can be run in different zones. This allows for migration
from one Java ES version to another over a period of time. For example, Java
ES Release 4 components in one non-global zone can be run in parallel with
Java ES Release 5 components in another non-global zone. To achieve this
type of version separation, life-cycle management (as well as configuration
and runtime management) is delegated to zone administrators.
-
Centralized Life-cycle Management. While not fully supported
due to Java ES limitations, zones make it possible to centralize life-cycle
management of Java ES components: components can be installed, upgraded, and
uninstalled in the global zone but configured and run in a number of non-global
zones to provide for runtime isolation, security, scalability, and other needs.
Centralization of life-cycle management is advantageous when there are a number
of instances of a component running in different zones, or when you want to
ensure that such instances are synchronized to the same release version.
For example, you would be able to install Application Server once in
the global zone and run multiple instances in different non-global zones.
The various Application Server instances could support Access Manager, Portal
Server, or other Java ES components (these can be the same or different components
in different non-global zones). Or different Application Server instances
could be used by different development teams in different zones.
To
achieve this objective, life-cycle management is performed by a global administrator,
while configuration and runtime management is delegated to the respective
zone administrators. This approach requires broad coordination when life-cycle
management tasks (such as upgrade) are performed.
-
Organizational Independence. Different organizations can maintain
separate deployments of Java ES components, or separate runtime instances
of Java ES components, all coexisting and running on the same computer. For
example, different groups of developers can use their own distinct instances
of Java ES components, or different organizations can use different deployments
of Java ES for testing, pre-production staging, or production. Organizational
independence can be achieved in various ways, depending on specific objectives:
either by centralizing Java ES life-cycle management while delegating configuration
and runtime management to zone administrators, or by delegating all management
functions (life-cycle, configuration, and runtime) to zone administrators.
The different objectives you can achieve using Java ES in a multi-zone
environment, and the usage scenarios they imply, require different strategies
for deploying and administering Java ES components across a multi-zone environment.
Some objectives make use of the isolation of different zones to independently
manage different Java ES components and their runtime instances, while other
objectives make use of the propagation capabilities of the global zone to
simplify life-cycle management of Java ES components.
Installation and administration strategies for using Java ES in a multi-zone
environment will be revisited after discussing some of the multi-zone environment
limitations imposed by the nature of Java ES software.
Zones Limitations of Java ES Components
Java ES components are grouped into different types, as described in Sun Java Enterprise System 5 Technical Overview. Accordingly, system service components
provide the main Java ES infrastructure services, while service quality components
enhance those system services. These two types of Java ES components are together
referred to here as product components, components that are selectable within
the Java ES installer.
Each product component depends on one or more locally shared libraries
known as Java ES shared components. Shared components are installed automatically
by the Java ES installer during product component installation, depending
on the product components that are being installed. They are not individually
selected, installed, or configured during deployment of Java ES product components.
Java ES Shared Components and Zones
The discussion in Why Use Zones for Java ES? focused
on the use of zones by Java ES product components: those that can be explicitly
selected in the Java ES installer and installed and configured in various
zones to achieve a desired deployment architecture and functional capability.
However, the shared components upon which product components depend set a
number of limitations on how Java ES is deployed in a multi-zone environment.
There are two issues regarding Java ES shared components and zones:
Synchronization of Shared Components
The difficulty of testing and supporting the large number (around 30)
and complex interactions between Java ES shared components and Java ES product
components mandates that all shared components within a single operating system
instance be synchronized to the same Java ES version. In other words, all
Java ES shared components installed in a non-zone environment, or in any single
zone within a Solaris 10 environment, must be of the same version. This requirement
sets certain restrictions on how Java ES can be used in a multi-zone environment.
This synchronization requirement has the following implications:
-
Different versions of Java ES shared components can only reside
in different zones. For example, you can install Java ES Release 4 shared
components in one zone and Java ES Release 5 shared components in another
zone, but you cannot combine them in the same zone.
-
If any shared component in a zone is upgraded or any new shared
component of higher version is introduced, then all shared components in that
zone must also be upgraded at the same time. (Shared components are required
to be backwardly compatible, so there is no problem for Release 4 product
components to work with Release 5 shared components.) For example, suppose
a Release 5 product component is installed in a zone in which one or more
Release 4 product components reside. Because the Release 5 product component
requires some number of Release 5 shared components, the synchronization requirement
means that all Release 4 shared components residing in that zone must be upgraded
to Release 5 at the same time the Release 5 product component is installed.
This is the case even if the Release 5 product component being installed requires
different shared components from those that are already installed in the zone.
-
When shared components are installed in and propagate from
the global zone (see Java ES Propagation Policies),
then special care must be taken to maintain synchronization of shared components
in all zones. Otherwise it would be possible for shared components of an earlier
version in a non-global zone to be mixed with Release 5 shared components
that have been propagated from the global zone. (Special care normally means
that shared component life-cycle management takes place only in the global
zone. For more information see Table A–2,
and Shared Component Special Cases.)
The shared component synchronization requirement imposes restrictions
on what the Java ES installer is constrained to do in a multi-zone environment
(for more information, see Zone Support in the Java ES Installer) and also impacts procedures for installing and upgrading
Java ES product components in a multi-zone environment.
Shared Components and Sparse Root Zones
Another issue impacting the use of Java ES in a multi-zone environment
is that a large number of shared components cannot be installed in sparse
root zones because of the read-only file systems in sparse root zones. Hence,
those shared components whose base directory is /usr (a
directory that by default is shared by the global zone) must be installed
in the global zone to be available in a sparse root zone.
The inability to install a number of Java ES shared components in sparse
root zones means that to successfully install product components which have
dependencies on such shared components into sparse root zones, the shared
components must first be installed in the global zone and propagated to non-global
zones.
Java ES Product Components and Zones
Some of the objectives discussed in Why Use Zones for Java ES? for using Java ES in a multi-zone environment,
and the usage scenarios they imply, make use of the propagation capabilities
of the global zone to simplify life-cycle management of Java ES product components.
Such usage scenarios, for example, call for life-cycle management of Java
ES product components to be performed in the global zone by the global administrator,
while the configuration and runtime management of those components is performed
in non-global zones by zone administrators.
In other words, product components would be installed and upgraded in
the global zone, but instances would be configured and run in non-global zones.
This usage scenario would combine the benefits of centralized life-cycle management
with the isolation and security afforded by non-global zones.
This scenario, however, depends upon the ability of each product component
to be installed in the global zone, but be configured and run in a non-global
zone. This separation depends upon how configuration of each product component
is achieved, where configuration and dynamic application data is stored, how
configuration data is located by executing binaries, and how upgrades are
performed. For example separation might depend upon what pre or post install
or upgrade scripts do: whether they start or stop component instances, set
up links to configuration data, or perform other tasks that blur the distinction
between life-cycle and configuration management.
This separation can also depend upon whether configuration is performed
in a whole root or sparse root zone. For example, if a product component's
configuration script writes to a read-only file system in a sparse root zone
(for example /usr) or if non-default file systems (such
as /opt) are shared with a sparse root zone, then the
configuration of a component can fail.
Note –
Nearly all Java ES product components are installed under /opt, which by default, is writable in sparse root zones. For more
information, see Sun Java Enterprise System 5 Installation Reference for UNIX
At the current time, the ability of each of the roughly 20 Java ES product
components to support the separation of life-cycle management and configuration/runtime
management between global and non-global zones has not been established. The
various product components have adopted different approaches to configuration
and upgrade. Given this situation, propagation of Java ES product components
(except for Message Queue) is not currently supported. For more information,
see Java ES Propagation Policies.
Zone Support in the Java ES Installer
Based on the usage scenarios discussed in Why Use Zones for Java ES?, and the Java ES component requirements and
limitations discussed in Zones Limitations of Java ES Components, the Java ES installer provides qualified zones support
for installation (and upgrade) of Java ES product components and for synchronization
of shared components. Policies have been implemented in the installer to help
prevent problematic installation and upgrade scenarios.
Java ES Propagation Policies
Based on the limitations discussed in Section 3, the Java ES installer
implements two Java ES propagation policies:
-
When product components are installed in the global zone,
they are set by default to not propagate into non-global zones (Message Queue
is an exception). Hence the non-global zones do not see them in their registries
nor have access to the installed components.
-
When shared components are installed in the global zone (for
example, as part of the installation of product components), they are set
to propagate into non-global zones. Hence non-global zones see them in their
registries and have access to the installed shared components. This policy
helps enforce the requirement that shared component versions be synchronized
within any zone as described in Java ES Shared Components and Zones.
Installation of Product Components
The Java ES installer can install product components as well as the
shared components needed to support each product component. Before installing
a selected product component, the installer checks for the existence of current
and previous versions of shared components. If the installer detects that
a shared component required by the selected component is of a previous version
or is missing, the installer will upgrade all shared components currently
installed and install any missing shared components required by the selected
component. This behavior, which meets the requirements of Synchronization of Shared Components, applies to
non-zone operating systems, global zones, and all non-global zones.
However, there are two exceptions to this behavior:
-
In sparse root zones, some shared components cannot be installed
or upgraded (see Shared Components and Sparse Root Zones), and installation is halted until such time as such shared
components have been installed or upgraded in the global zone. The installer
provides the following message: “The following shared components, required
by the components you have selected, cannot be installed or upgraded in a
sparse root zone. Please install or upgrade these shared components in the
global zone before proceeding. Use the All Shared Components option.”
For more information see Synchronize All Shared Components.
-
In a global zone, if non-global zones are present, instead
of upgrading all shared components currently installed and installing any
missing shared components required by a selected component, the installer
synchronizes all Java ES shared components, whether or not they are needed
by any specific product component. This allows all shared components to be
propagated to non-global zones, thus assuring that there is no intermixing
of shared component versions in non-global zones.
Upgrade of Product Components
A new capability has been implemented in the Java ES Release 5 to upgrade
product components in a few special cases: Application Server, Message Queue,
HADB, and Java DB. When the Java ES installer detects the previously installed
release versions of these product components, it marks them as upgradable
in the Component Selection page. If any of these four product components are
selected, the installer will upgrade them using logic similar to that used
for a fresh installation.
In particular, before upgrading a selected product component, the installer
checks for the existence of current and previous versions of shared components.
If the installer detects that a shared component required by the selected
component is of a previous version or is missing, the installer will upgrade
all shared components currently installed and install any missing shared components
required by the selected component. This behavior, which meets the requirements
described in Synchronize All Shared Components,
applies to non-zone operating systems, global zones, and all non-global zones.
However, there are three exceptions to this behavior:
-
In sparse root zones, some shared components cannot be installed
or upgraded and the upgrade operation is halted until such time as such shared
components have been installed or upgraded in the global zone. (For more information,
see Shared Components and Sparse Root Zones)
The installer provides the following message: “The following shared
components, required by the components you have selected, cannot be installed
or upgraded in a sparse root zone. Please install or upgrade these shared
components in the global zone before proceeding. Use the All Shared Components
option.” (For more information, see Synchronize All Shared Components.)
-
Both Application Server and Message Queue are bundled with
the Solaris operating system. Neither of these versions can be directly upgraded
in a sparse-root zone. For the details regarding these two bundled components,
see Product Component Special Cases.
-
In a global zone, if non-global zones are present, instead
of upgrading all shared components currently installed and installing any
missing shared components required by a component selected for installation,
the installer synchronizes all Java ES shared components, whether or not they
are needed at that time for any of the components selected for installation.
This allows all shared components to be propagated to non-global zones, thus
assuring that there is no intermixing of shared component versions in the
non-global zones.
Note –
There are a number of special cases or exceptions that might interfere
with the installation or upgrade of product components in non-global zones.
These cases are described in Special Cases or Exceptions.
Synchronize All Shared Components
A shared component synchronization option is provided to meet situations
in which all shared components must be synchronized. When the All Shared Components
option is selected, the installer will upgrade all shared components currently
installed and install any missing shared components, whether or not they are
needed by any specific product component. This option applies to global zones
and whole root zones, but not to sparse root zones.
The All Shared Components option, is needed in the following two zone-based
scenarios:
-
Manually upgrading product components. The All Shared Components
option is needed to perform the shared component installation and upgrade
needed when upgrading product components that cannot be upgraded using the
Java ES installer.
-
Installations or Upgrades in a Sparse Root Zone. Some shared
components cannot be installed in default sparse root zones. (For details,
see Installation of Product Components and Upgrade of Product Components.) Hence when running
the installer in sparse root zones, you might first be required to synchronize
shared components in the global zone, depending on the shared components involved.
You use the All Shared Components option in the global zone to perform the
shared component installation and upgrade required in this case.
Summary of Java ES Installer Behavior Regarding Shared
Components
The behaviors described above are summarized in the following table,
which shows how the Java ES installer's treatment of shared components depends
on the zone context as well as what has been selected in the component selection
page.
Table A–1 Installer Behavior Regarding Shared
Components
|
Zones Context
|
Product Component Selected
|
All Shared Components Selected
|
|
Non-zone operating System
|
Upgrade all shared components currently installed
Install any missing shared components required by the selected product
component
|
Upgrade all shared components currently installed
Install any missing shared components, whether or not they are needed
by any specific product component
|
|
Global zone: no non-global zones
|
Upgrade all shared components currently installed
Install any missing shared components required by the selected product
component
|
Upgrade all shared components currently installed
Install any missing shared components, whether or not they are needed
by any specific product component
|
|
Global zone: non-global zones exist
|
Upgrade all shared components currently installed
Install any missing shared components, whether or not they are needed
by any specific product component
|
Upgrade all shared components currently installed Install any missing
shared components, whether or not they are needed by any specific product
component
|
|
Whole root zone
|
Upgrade all shared components currently installed
Install any missing shared components required by the selected product
component
|
Upgrade all shared components currently installed
Install any missing shared components, whether or not they are needed
by any specific product component
|
|
Sparse root zone
|
Cannot upgrade or install some shared components in read-only directories.
If installer encounters such shared components, it blocks and instructs user
to manage shared components in the global zone.
|
Cannot upgrade or install some shared components in read-only directories.
Installer therefore blocks and instructs user to manage shared components
in the global zone.
|
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.
Special Cases or Exceptions
There are a number of special cases that arise mostly from the fact
that some Java ES shared components and some Java ES product components are
bundled with Solaris 10. By virtue of this bundling, these Java ES components
exist in the global zone, and therefore in any non-global zone that is created
from the global zone.
Product Component Special Cases
-
Message Queue is bundled with Solaris 10, and, as a result,
is automatically propagated when non-global zones are created (unless you
have first removed Message Queue from the global zone). Message Queue cannot
be installed in a sparse root zone. When installed or upgraded in a global
zone by the Java ES installer, Message Queue, by default, is propagated to
non-global zones, unlike other product components.
-
Application Server is bundled with Solaris 10, and, as a result,
is automatically propagated when non-global zones are created (unless you
have first removed Application Server from the global zone). When propagated
in this way, the bundled Application Server, which is installed in /usr, cannot be upgraded by the Java ES installer in a sparse root
zone (by default /usr is read-only). To address this
problem, the bundled Application Server must be manually removed from the
global zone before installing the Release 5 Application Server in a sparse
root zone.
-
Sun Cluster can only be installed in a global zone. Sun Cluster
is not supported in non-global zones.
Shared Component Special Cases
-
SJWC packages that are bundled with Solaris 10 (Update 1 and
Update 2) cannot be removed by the Java ES installer. These older SJWC packages
have had the SUNW_PKG_ALLZONES set to True, which means
the package must be identical in all zones and can only be managed by the
global administrator. As a result these packages must be manually removed
in the global zone to be replaced by the correct packages.
If
the Java ES installer is attempting to install a selected component in a non-global
zone and detects that SJWC needs to be upgraded, the installer will block.
This happens when installing on Solaris 10, Update 1 and 2.
As
a workaround, a special script has been developed that will remove the old
packages of SJWC from the global zone and replace them with SJWC 2.2.6, which
has the correct zones propagation attribute setting. As a result SJWC 2 2.6
is propagated to all non-global zones.
-
Common Agent Container. Version 1.1 is installed only when
Sun Cluster, Sun Cluster GE, or Sun Cluster Agents are installed. It is not
installed when the Synchronize All Shared Components option is selected. Only
version 2.0 is installed in that case.
-
Sun Explorer Data Collector. This shared component is installed
only when Sun Cluster, Sun Cluster GE, or Sun Cluster Agents are installed.
It is not installed when the All Shared Components option is selected.
An Illustrative Example: Install Application Server
in a Sparse Root Zone
The following example is provided to draw out some of the complexities
involved in Java ES zones support. In this example, the objective is to install
Application Server in a Solaris 10 sparse root zone. This installation is
complicated by the fact that Application Server (as well as Message Queue,
upon which Application Server depends), is bundled with Solaris 10, and therefore
the bundled version is installed in all non-global zones. For more information,
see Product Component Special Cases.
To install Application Server in a sparse root zone, you must first
remove the bundled version. (You cannot simply upgrade the bundled version
in the sparse root zone because it is installed in a read-only directory).
To remove the bundled version from the sparse root zone, you must remove it
in the global zone.
In addition, Message Queue is installed in the global zone, representing
a departure from Scenario 3 of Table A–2, in which only shared components
(not product components) are installed in the global zone. However, Message
Queue cannot be installed in a sparse root zone, because it installs in a
read-only directory, so it must be installed and upgraded in the global zone.
The procedure is as follows:
-
Verify Solaris 10 is running on your system.
This
example assumes a clean version of Solaris 10 with no Java ES components having
been explicitly installed in the global zone.
-
Create a sparse root zone (configure, install, and boot it).
This zone will include any Java ES components that are already installed
in the global zone, namely the versions of Message Queue and Application Server
bundled with Solaris 10.
-
Remove the bundled version of Application Server from the
global zone.
This must be performed by manually removing Application
Server packages:
pkgrm SUNWascmnse SUNWaslb SUNWasut ...
Where the full set of packages can be obtained using the following
command:
pkginfo -I|grep -I application server
The results would include packages such as:
SUNWascmnse,
SUNWaslb, SUNWasut, SUNWasac, SUNWasdem, SUNWasman, SUNWaswbcr, SUNWasacee,
SUNWashdm, SUNWasmanee, SUNWascml, SUNWasJdbcDrivers, SUNWasu, SUNWascmn,
SUNWasjdoc, SUNWasuee
And might include localization
packages as well:
SUNWLocaleasacee, SUNWLocaleascmnse,
SUNWLocaleasu, SUNWLocaleasuee
The removal of
Application Server from the global zone is propagated to the sparse root zone
that was created in Step 2. (This step and Step 2 can be performed in reverse
order.)
-
Install Java ES 5 Shared Components in the global zone.
-
Run the Java ES installer in the global zone.
-
Select All Shared Components from the component selection
panel. Do not select any other component.
-
Complete the synchronization of shared components. All of
the shared components are now synchronized in the global zone and propagated
to all non-global zones.
-
Upgrade Message Queue in the global zone.
The
version of Message Queue bundled with Solaris 10 is already installed in the
sparse root zone by virtue of Step 2. To upgrade Message Queue in the sparse
root zone, simply upgrade it in the global zone; the upgrade will propagate
to the sparse root zone. (Message Queue is the only product component which
cannot be installed in a sparse root zone, but when installed in the global
zone, will propagate to non-global zones.)
-
Run the Java ES installer in the global zone.
-
Select Message Queue in the component selection panel. Do
not select any other component.
-
Complete the upgrade of Message Queue.
-
Install Application Server in the sparse root zone.
-
Run the Java ES installer in the sparse root zone.
-
Select Application Server in the component selection panel.
Do not select any other component for upgrade. De-select Message Queue if
it is selected.
-
Complete the installation of Application Server.
Dieses Buch im PDF-Format herunterladen (755 KB)