User Scenarios for Sun Java System Web Server 7, Solaris Zones, and a DMZ

With the escalating costs of managing vast networks of servers and software components, attention is shifting towards developing new ways to reduce IT infrastructure costs and better manage systems. While server consolidation and virtualization techniques help improve data center management, better ways also exist to provision applications and enhance security and serviceability. For these resource management techniques to be effective, we must be able to manage applications independently, control resource utilization according to business needs, quickly isolate faults, and ensure security between multiple applications.

Solaris Zones (part of Solaris Containers technology) can provide an easy and efficient technique to enable this kind of environment at the OS level. We will see how using zones allows virtualization and consolidation of servers, and how Sun Java System Web Server 7 (henceforth, Web Server 7) can use this type of environment for improved provisioning and serviceability of applications.

This article discusses the following topics:

• Solaris Zones: What and Why
• Relevance of Zones in the Web Server Scenario
• Types of Zones and How to Create Zones
• Web Server 7 Support in Different Types of Zones
• Real-Life Implementation of Web Server 7
• Configuration Steps:
  • Admin Server
  • Admin Agents
  • Registration
  • Clustering
  • Session Replication
  • Deploying a Web Application
  • Monitoring
  • Reverse Proxy

What Are Solaris Zones?

Zones are an application and resource management feature of the Solaris 10 OS. This feature allows the OS to be represented to applications as virtual OS environments (or zones) that are isolated and secure. These zones combine the advantages of OS 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 OS resources can be centrally allocated and administered. From the point of view of a zones environment, OS resources include resources such as process management, memory, network configuration, file systems, package registries, user accounts, shared libraries, and (in some cases) installed applications.

Using zones provides a means of creating virtualized operating system environments within an instance of the Solaris OS, allowing one or more processes to run in isolation from other activity on the system. This isolation prevents processes that are running within a given zone from monitoring or affecting processes running in other zones, regardless of user ID and other credential information. A zone is a sandbox within which one or more applications can run without affecting or interacting with the rest of the system. This also provides an abstraction layer that separates applications from physical attributes of the machine on which they are deployed, such as physical device paths and network interface names, network routing tables, and so on.

Why Use Zones?

Security

Network services can be run in a zone, limiting the damage possible in the event of a security violation. An intruder who successfully exploits a security hole in software running within a zone is limited to the restricted set of actions possible within that zone. For example, an application running within most zones cannot load customized kernel modules, modify kernel memory, or create device nodes. The set of privileges available within a zone are a subset of those available in the system as a whole.

Isolation

Zones allow the deployment of multiple applications on the same machine — even where those applications operate in different trust domains, require exclusive access to a global resource, or require individualized configuration. For example, multiple applications running in different zones (but on the same system) can bind to the same network port using the distinct IP addresses associated with each zone. The applications are also prevented from monitoring or intercepting each other’s network traffic, file system data, process activity, and so on.

Virtualization

Zones provide a virtualized environment that can hide such details as physical devices and the system’s primary IP address and host name from the application. This can be useful to support rapid deployment (and redeployment) of applications, since the same application environment can be maintained on different physical machines. The virtualized environment can be rich enough to allow separate administration of each zone: One could give out the root password to a zone administrator, knowing that any actions taken by that administrator would not affect the rest of the system. Such a facility is of interest to service providers who are looking for more granular ways to subdivide systems among customers (both internal and external).

Granularity

Unlike physical partitioning technologies (such as domains or LPARs using Logical Partitioning), zones can provide isolation at almost any granularity. A zone does not require a dedicated CPU, physical device, or chunk of physical memory. Those resources can either be multiplexed across a number of zones running within a single domain or system, or allocated on a per-zone basis using the resource management features available in the operating system. The result is that even a small uniprocessor system can support a number of zones running simultaneously. The primary restriction (aside from the performance requirements of the applications running within each zone) is the disk space to hold the files that are unique within each zone.

Transparency

One of the basic design principles of zones is to avoid changing the environment in which applications are executing, except where necessary to achieve the goals of security and isolation. Zones do not present a new API or ABI to which applications must be “ported”. Instead, using zones provides the standard Solaris OS interfaces and application environment, with some restrictions. The restrictions primarily affect applications attempting to perform privileged operations.

Relevance of Zones to the Web Server Scenario

Using zones can help achieve the following objectives.

Server Consolidation and/or Utilization

Using zones enables more efficient resource usage on a computer. Web Server instances running on dedicated, under-utilized computers can be consolidated by running them in different non-global zones of a single computer. Global administrators can dynamically allocate resources among zones, depending on the resource requirements of the components running in those zones.

Centralized Life Cycle Management

Zones make it possible to centralize life cycle management. Web Server can be installed, upgraded, and uninstalled in the zone without disturbing other installations in other zones. Running components in multiple non-global zones provides for runtime isolation, security, scalability, and other needs. For example, you can install Web Server in the global zone and run multiple instances in different non-global zones. To achieve this objective, life cycle management is performed by a global administrator, but configuration and runtime management is delegated to zone administrators.

Version Separation

Parallel sets of different versions of Web Server can be run in different zones. This allows for migration from one Web Server version to another over a period of time.

Organizational Independence

Different organizations can maintain separate deployments of Web Server, or separate runtime instances of Web Server, all coexisting and running on the same computer. For example, different groups of developers can use their own distinct instances of Web Server, or different organizations can use different deployments of Web Server for testing, pre-production staging, or production. Organizational independence can be achieved in various ways, depending on specific objectives: either by centralizing Web Server 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.

Types of Zones and How to Create Zones

Whole Root Zones

In this particular model, all packages required for a zone that make up a particular metacluster are installed, as well as any other packages selected by the global administrator. When a whole root non-global 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 packages are copied onto the non-global zone, creating a dedicated and independent copy of all files.

This model has the advantages of enabling zone administrators to customize the file system layout of their zone (for example, creating a /usr/local) and to add arbitrary unbundled or third-party packages. The disadvantages of this model include losing sharing of text segments from executables and shared libraries by the virtual memory system, as well as a much heavier disk footprint for each zone that is configured this way.

Sparse Root Zones

This model contains 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. The global administrator selects which file systems to share with a sparse root zone at the time the sparse root zone is created (by default, the /usr, /lib, /sbin, and /platform directories).

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 tradeoff 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. 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.

Creating a Local Zone With the Command Line

Here’s an example:

# zonecfg -z <zone_name>
<zone_name> No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:<zone_name>> create -b (create -b option will create \
Whole Root Zone and without -b option will create Sparse Root Zone)
zonecfg:<zone_name>> set autoboot = true
zonecfg:<zone_name>> set zonepath = /<path>/<zone_name>
zonecfg:<zone_name>> add net
zonecfg:<zone_name>:net> set physical = <network_interface> eg; hme0
zonecfg:<zone_name>:net> set address = <ip_address>
zonecfg:<zone_name>:net> end
zonecfg:<zone_name>> verify
zonecfg:<zone_name>> commit
zonecfg:<zone_name>>^d
#
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- <zone_name> configured /<path>/<zone_name>
#
# zoneadm -z <zone_name> install
#
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- <zone_name> installed /<path>/<zone_name>
#
# zoneadm -z <zone_name> boot
# zlogin -C <zone_name>

<== Here give all the required input such as Lang, TERM type, hostname, NIS etc.
....
SunOS Release 5.10 Version s10_u1wos 64-bit
Copyright 1983-2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: <zone_name>
NIS domain name is <nis_domain_name>

 

Web Server 7 Support in Different Types of Zones

Web Server 7 installation has been tested in different scenarios, under different types of zones, as follows:

• Install Web Server in the global zone. You can install Web Server before and after creation of local zones.
• Install Web Server in the whole root local zone. You can install Web Server before or after creation of other local zones, or after installing in the global zone.
• Install Web Server in the sparse root local zone. You can install Web Server before or after installing in the global zone or any other local zones.
• Install Web Server in any zone (global or local), and then delete the other local zones (except the global zone). Even if you delete the other local zone, the Web Server installation will not be affected
• Install Web Server Admin Server in the global zone and create instances in other local zones (whole root or sparse root) through Admin Server, after installing Admin Agent on those local zones and registering those with Admin Server. In this way you can create a global administrative server for better management and security.

 

Typical Real-Life Implementation of Web Server 7

The following is an example of a use case scenario where nodes have been configured in different zones behind a firewall (Demilitarized Zone, or DMZ), and Admin Server has been configured behind another firewall (Militarized Zone, or MZ) such that Admin Server is the most secured and restricted from the outside world. One of the nodes can be configured as a reverse proxy server. A reverse proxy server can reside outside the firewall or may reside inside the DMZ to enhance security. The actual web server is accessed using the reverse proxy server. The reverse proxy server retrieves the web resources through the firewall from the actual web servers, thus greatly reducing vulnerability to attacks. Inside the DMZ there can be one directory server, and inside the MZ there can be a database server.

 

Inside MZ (Militarized Zone): Admin Server (private/unregistered IP addresses to be used as it is inside MZ)

Inside DMZ (Demilitarized Zone): Nodes (IP addresses in the above figure are not actual; examples only)

Four different zones have been configured in a server, as shown in the preceding example, in the DMZ area. The host names and types are as follows:

• GZ-1: Global Zone
• WRZ-1: Whole Root Local Zone
• SRZ-1 and SRZ-2: Sparse Root Local Zone

GZ-2 is another server that may be configured as reverse proxy.

 

Different Installation and Configuration Options

In the previous example, you need to install one Admin Server and one or more nodes (four in the preceding example) to create a server farm.

Ways to Install Admin Server

CLI mode: Install Admin Server through console.

Run ./setup --console.

After the License Agreement, select Custom Install, and then choose Install as Admin Server. You need to specify SSL/Non SSL port.

GUI mode: Install Admin Server through the GUI.

./setup will invoke the GUI screens for installation.

After the License Agreement, component selection, and Java configuration, select Custom Install, and then choose Install as Admin Server. You need to specify SSL/Non SSL port. Complete the installation process. You can also specify your own Java path. The minimum J2SE version required is 1.5.0_08 for UNIX and 1.5.0_07 for Windows.

Ways to Install Admin Agent So That Nodes Are Part of the Server Farm

CLI mode: Install Admin Agent through console for nodes.

Run ./setup --console.

Select Custom Install and choose Create an Admin Node. Specify the host name and the port. The node can be registered to an admin server during install. When prompted for registration, specify the host name and port of the remote admin server to which you wish to register the node.

GUI mode: Install Admin Agent through the GUI.

./setup will invoke the GUI for installation.

Select Custom Install, and choose Create an Admin Node. Specify the host name and the port. The node can be registered to an admin server during install. When prompted for registration, specify the host name and port of the remote admin server to which you wish to register the node.

Ways to Register Nodes to Admin Server

In case you didn’t register nodes during installation, you can still register them after installation using the wadm command from a node. Admin Server must be running to register successfully.

Register nodes after installing Admin Agent:

../wadm --host=<admin-server-host> --port=<admin-ssl-port> \
--user=<admin-user> ( will prompt for password )

wadm> register-node

Unregister nodes (if necessary):

../wadm --host=<admin-server-host> --port=<admin-ssl-port> \
--user=<admin-user> ( will prompt for password )

wadm> unregister-node

Creating a Cluster Configuration

Prerequisite: A server farm must be present. Create a server farm with the above steps.

All the instances in a cluster are required to be homogeneous.

Assumptions: The config is called config1; the admin server is on the node called AS1; and the admin agents registered to it are on the nodes called WRZ-1, SRZ-1, and SRZ-2.

1. Create a configuration.

   wadm> create-config --http-port=3456 --server-name=AS1 config1

   GUI Navigation: Common Tasks –> Configuration Tasks –> New Configuration
   You can create more than one config with this process.

2. Create an instance.

   wadm> create-instance --config=config1 AS1

   GUI Navigation: a) An instance can be created during create config, as in step 1. In the Wizard, the first page is Configuration Information–>Next–>Listener Properties–>Next–>Configuration Properties–>Next–>Create Instances.
   b) Common Tasks page. Select the configuration. Click New Instance.

3. Create multiple instances.

   wadm> create-instance --config=config1 AS1 WRZ-1 SRZ-1 SRZ-2

   GUI Navigation: a) Same as 3a. When on the Create Instances page, select more than one node and add them all to create multiple instances.
   b) Same as step 2b. Now a simple cluster configuration is complete. To make those configs active, you have to deploy them on local and remote nodes, as in the next step.

4. Deploy the configuration.

   wadm> deploy-config config1

   GUI Navigation: Go to the Configurations tab. Select the config by checking the check box. Use the drop-down menu More Configuration Actions, and select Deploy.

Now your cluster configuration is ready.

Session Replication

After clustering, the next important step is to configure session replication to enable failover of session of the applications deployed in an instance. The purpose of session failover is to provide high availability to web applications. Lightweight session failover achieves this by replicating HTTP sessions from one instance to another server instance of the same cluster. Then each HTTP session has a backup copy on a remote instance. In the event of failure of a single node at any particular moment, which renders one instance in the cluster unavailable, the cluster still maintains session continuity.

1. Create a configuration, and create multiple instances as shown previously.
2. Enable session replication:

   wadm> set-session-replication-prop --config=config1 enabled=true

3. Deploy the configuration and start all the instances.
   GUI Navigation: Config –> Instance –> Java –> Session Replication.
   Check the above configuration by deploying any web application and accessing the same from the client.

Deploying a Web Application

1. Add a web application to a configuration using the CLI:

   wadm> add-webapp --config=config1 -vs=config1 -uri=/simple warfile

   GUI Navigation: After clicking on config, click on VS. Then select Add webapp.

2. Deploy webapp and access for all instances.
3. You can also deploy a simple web application using ant.

Monitoring

This feature provides information on the state of runtime components and processes that can be used to:

• Identify performance bottlenecks
• Tune the system for optimal performance
• Aid in capacity planning
• Predict failures
• Do root cause analysis in case of failures

In addition, this feature can sometimes be used to make sure that everything is functioning as expected.

You can get monitoring data for local and remote instances through the wadm command. Here are some of the important monitoring commands:

wadm> get-stats-xml-prop --config=name --vs=name

Gets stats for a particular configuration, on a particular node

wadm> enable-stats-xml [--uri=uri] --config=name --vs=name

Gets stats for a particular configuration and particular node through the browser

wadm> get-perfdump-prop --config=name --vs=name

Gets perfdump values for a particular configuration, on a particular node

wadm> enable-perfdump --config=name --vs=name

Gets perfdump values of a particular configuration, on a particular node, through the browser

wadm> get-webapp-stats --config=name --vs=name --uri=path-of-web-app-uri

Gets stats for a particular web application

wadm> get-virtual-server-stats

Gets stats for a particular virtual server

GUI Navigation: Select Monitoring –> Instance.

Reverse Proxy

As stated earlier, one of the nodes in the preceding scenario can be configured as a reverse proxy server. A reverse proxy server can reside outside the firewall, or it may reside inside the DMZ to enhance security. The actual web server is accessed using the reverse proxy server. The reverse proxy server retrieves the web resources through the firewall from the actual web servers, thus greatly reducing the vulnerability to attacks. Basic reverse proxy capabilities (including URL re-write and round-robin load balancing) allow the server to be used to secure the DMZ and other server products. Combined with NSAPI filters this allows further manipulation of proxied content (string replacement, compression, and so forth).

Prerequisites:

• Reverse Proxy config name: RPConfig
• Origin Server1 host name: WRZ-1
• Origin Server1 Port: 3456
• Origin Server2 host name: SRZ-1
• Origin Server2 Port: 3456

1. Configure the reverse proxy to pass the request to an origin server. The HTTP request is made by the client to RP. The RP will pass the request to the origin server:

wadm> create-reverse-proxy --configRPConfig --vsRPConfig --uri-prefix / --server http://WRZ-1:3456

2. Configure the reverse proxy to pass a request for a simple sticky application to different servers. With this configuration, the second HTTP request should go to the same server that served the first request, and the second request should be able to retrieve the session information.

wadm> create-reverse-proxy --configRPConfig --vsRPConfig --uri-prefix \
/ --server http://SRZ-1:3456,http://WRZ-1:3456

GUI Navigation: Select Config –> Instance –> VS –> Content Handling –> Reverse Proxy.

Conclusion

I hope this article will provide you with guidelines to help setting up Web Server 7. Also, go through the Administrator’s Guide for other configuration details such as setting up security policies, search collections, pattern matching, and so on.

I believe your experience with Web Server 7 will be exciting given that it has many new features, has a completely revamped Admin, and was designed to be one of the most secure, stable, and best-performing products of its kind available in the market today. For more information, see test results using Java System Web Server 6.1 SP5: