 Print-friendly Version
User Scenarios for Sun Java System Web Server 7, Solaris Zones, and a DMZPartha Dey, November 2006 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:
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 ScenarioUsing 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 ZonesWhole 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 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 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 ZonesWeb Server 7 installation has been tested in different scenarios, under different types of zones, as follows:
Typical Real-Life Implementation of Web Server 7The 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.
Figure 1 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-2 is another server that may be configured as reverse proxy. Different Installation and Configuration OptionsIn 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
Run 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.
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 Run 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.
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 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.
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.
Deploying a Web Application
Monitoring This feature provides information on the state of runtime components and processes that can be used to:
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
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:
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. ConclusionI 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: Sun Fire T1000 Server with CoolThreads Technology Outperforms All Competing 1U Systems on the Market. Related Links
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License. |
  |
 | |
