Version | Effective: 30/11/2009 |
4.2.3. One application per zone
[ug] Another paradigm is to always install one application per zone.
A zone has very little overhead; basically, only the application processes are separated from the rest of the system by tagging them with the zone ID. This is implemented by the zone technology.
The profits gained by this decision are very high:
∙The administrator of the application can receive the password for root in the local zone without being in a position to jeopardize the operation of the entire computer in case of error.
∙If many applications are consolidated, the number of users with root privileges is reduced.
∙If you would like to install the application automatically, it is much easier since you know for sure that there is no other application that has modified the system.
∙Dependencies/malfunctions between applications in the file system and/or configuration files are omitted completely, which results in safer operation.
4.2.4. Clustered containers
[tf/du] Clustered containers can be considered and configured as virtual nodes or as resources. By means of containers as virtual nodes, virtual clusters,
In a cluster, operation as a black box container or in fully formed resource topologies is possible. In a black box container, the applications run are configured in the container only. The cluster does not know them; they are controlled within the container by Solaris only. This leads to particularly simple cluster configurations.
For a fully formed resource topology, each application is run under cluster control. Each application is thus integrated into the cluster as a resource and is started and monitored by it in the correct sequence. For fully formed resource topologies in containers, the HA container agent, or containers as "virtual nodes", have been available since Sun Cluster 3.2. For a container as a virtual node, applications are moved among containers bundled into resource groups. Several resource groups can run in one container and pan independently of one another.
Both concepts, HA containers, and containers as virtual nodes, have their own strengths. Helpful criteria for selecting the right concept for the respective use case can be found in "Sun Cluster Concepts Guide for Solaris OS“:
In cluster topology, applications in a container can be brought under cluster control. If containers are run as virtual nodes, standard agents or
•
•
If the requirement consists in achieving high availability in a data center, or high availability between two data centers, Sun Cluster is sufficient for scheduled and emergency relocation of containers or applications among computers. The maximum distance between two cluster nodes used to be set to 400 km for Sun Cluster and required the application of certified DWDMs (Dense Wave Division Multiplexers). Nowadays, evidence of maximum latency of 15 ms
If these requirements are met it unfortunately does not yet mean that the performance requirements of the application are also met. That is to say, if the latency of the mirroring or replication technology involved does not meet the performance requirements, Sun Cluster Geographic Edition can be used instead.
Sun Cluster Geographic Edition assumes clusters running in several data centers. The storage used is replicated by means of suitable techniques from data center A to data center B. Currently, Sun StorEdge Availability Suite (AVS) as a
47
