Chapter 4 Deployment Scenarios
This chapter describes how to deploy Sun Java System Web Server
7.0 on a single node and a cluster environment. The following topics are discussed
in this chapter:
Deployment Architecture
This section describes the single node deployment architecture.
The following figure represents Web Server in a single node
deployment set up.
In the figure, Web Server deployment set up comprises of the
following components:
-
Administration Server-
Administration Server is a specially configured web server instance. You can
deploy web applications on the administration server.
-
Administration Node-
Administration Node is deployed on a node or a server/host within a server
farm and has the ability to communicate with the remote Administration Server.
The server configurations available within the Administration Server can be
deployed to this node. All the Administration Nodes within the server farm
needs to be homogeneous. That is, all the nodes must use the same operating
system and have the same hardware architecture.
-
Configuration-
A configuration refers to a set of all configurable elements of a Web Server
instance, such as web applications, configuration files, and search collection
indexes. A configuration can be created, modified, or deleted. Web Server
can manage multiple configurations Instances can be created for a configuration.
Deploying a modified configuration updates the instance of that configuration.
-
config-store This
is the file system-based repository where all the configurations are stored.
Caution – Do not edit any file under config-store directory. The files under this directory are created by Sun Java
System Web Server for internal use.
If you must manually
edit the configuration file under the config-store directory,
deploy the configuration using the wadm deploy-config command.
For more information on using this
command, see the Sun
Java System Web Server 7.0 CLI Reference Manual.
-
Instance -
An instance refers to the environment of a web server on a given node, including
its configuration, log files, and other runtime artifacts such as lock databases,
caches, and temporary files. For management purposes, an instance can be
started, stopped, restarted, or dynamically re-configured.
Deployment Overview
You can consider deploying Web Server on a the single node
for the following purposes:
The following flowchart provides the schematic representation
of how to deploy Web Server on a node:
Figure 4–1 Flowchart representing the deployment
of web server on a single node
The deployment process is described in the following sections:
Pre-Deployment Requirements
To deploy the Web Server on a single node, prepare the system
by performing the following tasks:
-
Install Web Server on a node.
If you choose Express Installation option while installing Web Server, the
following default entities are created:
-
An Administration Server.
-
A default configuration with one HTTP
listener and a virtual server are created. The name of the configuration and
the virtual server are same as the host name.
-
An instance of the default configuration.
For information on installing the Web Server, see the Chapter 2, Installing
the Web Server, in Sun Java System Web
Server 7.0 Installation and Migration Guide.
For information on the supported platforms and the system requirements, see Supported
Platforms in Sun Java System Web Server
7.0 Release Notes.
-
Start the Administration Server.
The Administration Server starts running on a specified SSL
port.
Deploying Web Server
Use the following procedure to deploy Web Server on a node:
-
You can either use the default configuration
or create a new configuration..
If you are creating
a new configuration, specify a unique name for the configuration. The new
configuration creates a virtual server and a default HTTP listener.
Note –
If you are using the Administration Console
to create a configuration, the wizard prompts you to create a new instance.
If you are using the CLI, you must explicitly create an instance of the configuration
using the create-instance command.
All the configurations are stored in the config-store directory
located under <install_dir>/admin-server/ directory.
Caution – Do not edit any file under the config-store directory. The files under this directory are created by Sun Java
System Web Server for internal use.
-
Deploy the modified configuration.
Cluster Environment
A cluster is a group of multiple
server instances, spanning across more than one node, all running identical
configuration. All instances in a cluster work together to provide high availability,
reliability, and scalability.
With load balancing, a cluster offers uninterrupted service
and session data persistence by providing failover and session replication.
Hardware and Software Requirements
The use case described in this section, the Web Server cluster
consists of the following entities:
|
1) Four instances (running on four identical nodes)
|
|
2) An Administration Server
|
|
3) A reverse proxy for load balancing HTTP requests
|
To set up a cluster, you need two or more identical nodes
with the same operating system version and patches installed. For example,
if you select a machine with Solaris® 9 SPARC® operating system, other machines in the
cluster must also have Solaris 9 SPARC installed.
For information on supported platforms and patch requirements,
see the Sun Java System
Web Server 7.0 Release Notes.
The following figure describes a clustered environment.
Figure 4–2 Cluster Set Up
In the figure, nodes are configured in the De-Militarized
Zone (DMZ). The Administration Server is configured behind a firewall, the
Militarized Zone, to restrict and protect the Administration Server against
general access. Another node is configured as the Reverse Proxy Server. A
reverse proxy server resides inside the DMZ to enhance security.
Note –
The Solaris zone feature is supported only
on Solaris 10 operating system.
Setting Up a Cluster
This section describes the procedure to set up the cluster
and enable reverse proxy to support load-balancing of HTTP requests.
The following flowchart illustrates the procedure to set up
a cluster.
Figure 4–3 Flowchart illustrating the cluster
set up
-
On one of the nodes, install Web Server
that acts as the Administration Server in a cluster.
-
On other three nodes, install Web Server.
Select the option of installing Web Server as an Administration Node. During
the installation, choose the option of registering the node with the server.
-
Make sure the Administration Server is
using SSL port for communication, as an Administration Node can be registered
with the server only in secure mode.
-
Make sure the system date and time on
all the nodes where the Administration Server and the Administration Nodes
are installed are the same. The certificate associated with the server is
created based on the system date and time of the node where the Administration
Server is installed. If the system date of the Administration Node is earlier
than the Administration Server, the registration fails as the certificate
of the Administration Server will not yet be valid. As a corollary, the certificate
may be deemed valid if it is has expired.
-
Start the Administration Server from the install_dir/admin-server/bin/ directory.
install_dir/admin-server/bin>./startserv
-
Start the wadm command-line
tool from the Administration Node. The wadm command-line
tool is located in the install_dir/bin directory.
install_dir/bin>./wadm
-
Register each Administration Node with
the Administration Server. Use the register-node command
to register each node with the server.
For Example:
./wadm register-node -user=admin --host=abc.sfbay.sun.com --port=8989
|
Where,
-
abc.sfbay.sun.com
-
is the host name of the Administration
Server to which you are registering the Node.
-
port
-
is the SSL Port number of the Administration
Server.
-
You will be prompted to enter the administration
password. Enter the administration password of the Administration Server.
The Administration Server authenticates each other by the
Administration Server trusting the Administration Node's server certificate
and the Administration Node trusting the client certificate presented by the
Administration Server. During registration of an Administration Node, the
Administration Server generates a server certificate for that Administration
Node, which is then downloaded and installed on the Administration Node. The
issuer of the server certificate is also installed on the Administration Node.
Note –
The registration can be done only over SSL.
For information about registering nodes, see the Registering
the Administration Node From the Command-Line in Sun Java System Web Server 7.0 Installation and Migration Guide.
-
Start all the Administration Nodes using
the startserv command from the install_dir/admin-server/bin/ directory.
-
Using the Admin Console or the CLI, create
a new configuration in the Administration Server.
Provide
configuration information such as configuration name, HTTP Listener port,
and the server name for the new configuration.
-
Create instances of the configuration
on all the nodes.
-
Start the instances on all the nodes.
Note –
Web Server provides the flexibility to expand
or reduce your cluster. You can add or remove instances to the cluster at
any point of time.
Configuring Reverse Proxy for
Load-balancing
Web Server 7.0 provides a sophisticated built-in load balancer,
the reverse proxy. A reverse proxy is a gateway for Web Servers in a server
farm. By configuring reverse proxy, the requests are forwarded to multiple
similarly configured web servers
Use the following procedure to enable reverse proxy in Web
Server 7.0:
-
Install Web Server on the node that you
want to use for configuring reverse proxy.
-
Create a configuration. For example, rp.
-
Using the Administration Console, select
Configurations > Virtual Servers > Content Handling > Reverse Proxy tab. Click
the New button.
-
Enter the reverse proxy URI and the server
URLs of all the machines in the cluster separated by comma.
The format for entering the server URL is hostname:portnumber.
-
Save the changes.
-
Deploy the modified configuration to apply
the changes to the configuration.
-
Start all the instance of this modified
configuration.
This completes configuring reverse proxy for load balancing
HTTP requests.
Session Replication
Session replication is a mechanism used to replicate the data
stored in a session across different instances. However, the replicated instance
must be part of the same cluster. When session replication is enabled in a
cluster environment, the entire session data is copied on a replicated instance.
However, the session replication operation does not copy the non-serializable
attributes in a session and any instance specific data.
Session replication along with load balancing provides good
failover capabilities for web applications.
Session Replication and Failover
Operation
This section describes the session replication operation in
detail.
At the end of a web request, the Web Server determines whether
the session data needs to be copied through the session replication configuration
that is stored in the server configuration file, the server.xml.
Consider a use case of four instances forming a cluster and
the session replication is enabled on the Administration Server.
The session replication process in a Web Server cluster of
four instances (A, B, C, and D) running on four nodes is as follows:
-
Instance A is backup of D, B is backup
of A, C is backup of B, and D is backup of C. This forms a complete backup
ring.
-
Each instance in the cluster keeps track
of a static list of all the instances in the cluster and an active backup
instance.
-
Depending on the configuration, session
data is sent to the backup instance synchronously at the end of each request.
The failover process in a Web Server clustered environment
as follows:
Web Server 7.0 does not support the following features in
session replication:
-
Recover simultaneous failures of two or
more instances.
-
The interval between two failures must
be greater than the time needed for a resurrected instance to fully recover.
-
Session backup to more than one instance.
In normal operation, there are only two copies of any session: the primary
session and a backup session.
-
Session persistence: Sessions are only
backed up in memory of another instance for the purpose of failover
-
Web Server supports session replication
for only Java web applications. If you are using non-Java applications such
as CGI or PHP, the session data cannot be replicated.
Enabling Session Replication
You can enable session replication in a cluster either using
the Admin Console or the CLI. Before you enable session replication, make
sure that your browser is cookie enabled.
The server.xml file contains the information
related to session replication. A sample server.xml file
with session replication enabled is given below:
<cluster>
<local-host>hostA</local-host>
<instance>
<host>hostB</host>
</instance>
<instance>
<host>hostC</host>
</instance>
<instance>
<host>hostD</host>
</instance>
<instance>
<host>hostA</host>
<session-replication/>
</cluster>
If you are not using the default values for the following
elements, the entry for these elements will not be available in the server.xml configuration file:
|
Port number (default is 1099)
|
|
Protocol (default is jrmp)
|
|
Encrypted (default is false)
|
|
Getattribute Triggers Replication (default
is true)
|
|
Replica Discovery MaxHops (default is –1)
|
|
Startup Discovery Timeout (default is
?)
|
|
Cookie Name (default is CLUSTERSESSIONLOCATOR)
|
For more information about these session replication properties,
see the Sun Java System
Web Server 7.0 Administrator’s Configuration File Reference.
Configuring a Web Application
for Session Replication
To enable the server to replicate the session, the web application
must also be enabled for session replication.
-
To enable session replication for a web
application, modify the sun-web.xml configuration file
located in the <web-application>/WEB-INF directory.
The modification needed in the sunweb.xml is
as follows:
Change the element <session-manager/> to <session-manager persistence-type="replicated">
The sample sun-web.xml file
with session replication enabled is given below:
<sun-web-app>
<session-config>
<session-manager persistence-type="replicated">
</session-manager>
</session-config>
</sun-web-app>
-
After modifying the sunweb.xml file,
either rebuild the web application or re-jar the application to create a web
application archive (a war file).
-
Restart all the instances to make the
web application available on all the instances.
-
The web application is accessible from
all the nodes in the cluster. To access the web application, in a browser,
type the following:
http://webserver-name/webapplication-name/
Note –
A directory that is accessible to all nodes
is the best way to store the applications for deployment. This directory,
however, need not be accessible to the Administration Server. It is recommended
to make directory-based deployments of web applications that are more than
One MB in size.
For creating search collections, ensure
that the search collection resides in a common directory that is accessible
to all the nodes.
Monitoring a Cluster
The Administration Server can monitor all the instances in
a cluster. The monitoring feature in Web Server 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 capacity planning
-
Predict failures
-
Perform root cause analysis in case of
failures
Solaris Zones
Solaris Zones are an application and resource management feature
of Solaris 10. A zone environment typically consists of resources such as
process management, memory, network configuration, file systems, package registries,
user accounts, shared libraries, and in some cases, installed applications.
Zones provide a means of creating virtualized operating system environments
within an instance of Solaris, allowing one or more processes to run in isolation
from other activity on the system. It 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, and
network routing tables. This isolation prevents processes 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.
For detailed information about Solaris Zones, see the System Administration Guide — Solaris Containers-Resource Management
and Solaris Zones at http://docs.sun.com/app/docs/doc/817-1592.
Ladda ner denna bok i PDF (2845 KB)