This chapter describes high availability aspects of the Administration Server.
This chapter includes the following topics:
Section 8.3, "Administration Server High Availability Topology"
Section 8.4, "Configuring Administration Server High Availability"
For more information on the Administration Server and Node Manager, see the following topics:
Table 8-1 Administration Server Topics
For information on... | See this topic... |
---|---|
Starting and Stopping the Administration Server |
"Starting and Stopping Administration Server" in the guide Oracle Fusion Middleware Administering Oracle Fusion Middleware |
Configuring virtual hosting |
"Configuring Virtual Hosting" in the guide Administering Server Environments for Oracle WebLogic Server |
Using Node Manager |
In the guide Administering Node Manager for Oracle WebLogic Server: |
The Administration Server is the central control entity for configuring the entire domain. It maintains the domain's configuration documents and distributes changes in the configuration documents to Managed Servers. The Administration Server serves as a central location from which to manage and monitor all resources in a domain.
Each domain must have one server instance that acts as the Administration Server.
The failure of an Administration Server does not affect the operation of Managed Servers in the domain. If an Administration Server fails because of a hardware or software failure on its host computer, other server instances on the same computer may be similarly affected.
For more information on Administration Server Failure, see "Impact of Managed Server Failure" in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
For the procedure to restart an Administration Server, see Oracle Fusion Middleware Using Clusters for Oracle Server.
With shared storage, the backup host has access to the same Oracle binaries, configuration files, domain directory, and data that the active host has. You configure this access by placing these artifacts in storage that all hosts in the highly available Administration Server configuration can access. Shared storage can be a network-attached storage (NAS) or storage area network (SAN) device. See Chapter 4, "Using Shared Storage" for more information.
For each WebLogic Server domain you create, a per domain Node Manager configuration is created by default, complete with security credentials, a properties file, domain registration, and start scripts
You can configure the scope of Node Manager:
per domain With a per-domain Node Manager, the Node Manager is associated with a domain and is configured to control all servers for the domain on a machine.
per host With a per host Node Manager, the Node Manager process is not associated with a specific WebLogic Server domain but with a machine. You can use the same Node Manager process to control server instances in any WebLogic Server domain, as long as the server instances reside on the same machine as the Node Manager process. A per host Node Manager must run on each computer that hosts WebLogic Server instances—whether Administration Server or Managed Server—that you want to control with Node Manager.
Node Manager failure does not affect the operation of any of the servers running on the machine.
Note:
Oracle recommends that you run Node Manager as an operating system service so that it restarts automatically if its host machine restarts.
For more information about Node Manager, see "What is Node Manager?" in the guide Oracle Fusion Middleware Understanding Oracle Fusion Middleware Concepts.
As a single entity, the Administration Server can be active on a single host at any one time. To achieve high availability, you configure the Administration Server on a virtual host so that if the machine that the Administration Server runs on fails, you can fail it over to another host in the domain. The Administration Server is configured to use a virtual IP to overlap the backup hosts. You configure the Administration Server to listen on this virtual IP. The benefit of using a virtual host and virtual IP is that you do not need to add a third machine; if failover occurs, the virtual host can be mapped to a surviving host in the domain by "moving" the virtual IP.
The two hosts share a virtual hostname and a virtual IP. However, only the active host can use this virtual IP at any one time. If the active host fails, the backup host is made active and you must move (manually) the virtual IP to the new active host. The new active host will then service all requests through the virtual IP. (You configure a high availability deployment to listen on this virtual IP.)
Figure 8-1 shows a highly available Administration Server. In this topology, the Administration Server runs on a virtual host, APPHOST0
. APPHOST0
overlaps to APPHOST1
or APPHOST2
by means of a virtual IP. At first, APPHOST0
maps to APPHOST1
, but if the Administration Server fails due to the failure of APPHOST1
, APPHOST0
is failed over to APPHOST2
by moving the virtual IP.
Figure 8-1 Administration Server High Availability Topology
This section describes how to configure the Administration Server for high availability. It includes the following topics
In a highly available Administration Server environment, both hosts must have access to shared storage. The domain directory is maintained in shared storage. During normal operation, the Administration Server on the active host owns the domain directory in shared storage. If the active host fails, the backup host takes over and restarts the Administration Server from the shared domain directory.
To configure a highly available Administration Server, your environment must meet the following requirements:
Conform to the standard installation topology. See Section 1.5, "Understanding the Oracle Fusion Middleware Standard HA Topology" and Figure 1-1, "Oracle Fusion Middleware Highly Available Deployment Topology (Typical Enterprise)".
Include two hosts, APPHOST1 and APPHOST2, to implement a WebLogic Server cluster (cluster_1
). In Section 8.4.2, "Configuring the Administration Server", the IP addresses for APPHOST1 and APPHOST2 are ip1
and ip2
, respectively.
APPHOST1 and APPHOST2 mount a common directory from shared storage and have read/write access rights to the directory. This directory is used for installing the products and storing the domain directories.
A reserved virtual IP address (vip0
) to "point" to the host that is running the Administration Server. This floating virtual server IP address is configured dynamically on the host that the Administration Server runs on.
Node Manager instances to manage the Administration Server and migrate it from the failed host to the designated standby host.
To configure the Administration Server for high availability, you must start with the standard high availability topology that has one cluster (cluster_1
). See Section 1.5, "Understanding the Oracle Fusion Middleware Standard HA Topology".
To set up a highly available Administration Server, you run the Administration Server on a separate, virtual host (APPHOST0
). You set up APPHOST0
so that it maps to one of the existing hosts in the cluster (APPHOST1 or APPHOST2) by configuring a (virtual) server IP for APPHOST0
on that existing host. If failover occurs, APPHOST0
fails over by moving its virtual server IP to a surviving host. The domain configuration is on shared storage so that the surviving host can access it.
Note:
There are a variety of ways to invoke Administration Server services to accomplish configuration tasks. No matter which method you use, the Administration Server must be running when you change the configuration.
Table 8-2 Host and Node Manager Terms
Term | Description |
---|---|
|
Virtual machine that the Administration Server runs on |
|
Machines that host the application tier. |
|
Virtual server IP address that the Administration Server listens on |
|
Per-domain Node Manager that manages the Administration Server that runs on APPHOST0 |
|
Instances of Node Manager that run on APPHOST1 and APPHOST2, respectively |
|
IP addresses of APPHOST1 and APPHOST2, respectively |
To configure the Administration Server for high availability:
Configure a virtual server IP address (vip0
) on APPHOST1
to represent virtual host APPHOST0
.
See "Configuring Virtual Hosting" in the guide Administering Server Environments for Oracle WebLogic Server for more information.
Use an Oracle Fusion Middleware expanded installation procedure to install the Oracle Fusion Middleware binaries and configure the domain into a directory on shared storage. Use vip0
as the Administration Server listen address.
Create a virtual machine, machine_0
, and add the Administration Server to it. The machine machine_0
represents the virtual server host APPHOST0
with the IP address vip0
.
Create a cluster (cluster_1
) that has two Managed Servers, server_1
and server_2
, that are assigned to machine_1
and machine_2
, respectively.
machine_1
represents APPHOST1
and machine_2
represents APPHOST2
.
server_1
and server_2
are set up to listen on ip1
and ip2
, respectively.
Scale out the virtual server to APPHOST1
and APPHOST2
. See Section 7.2, "Roadmap for Scaling Out Your Topology." You scale out by packing the domain in shared storage and unpacking it to a local directory on APPHOST1
and APPHOST2
.
From APPHOST1
, start a per-domain Node Manager (NMa
) to manage the Administration Server listening on the configured virtual server IP vip0
on APPHOST1
. Start this instance of Node Manager from the domain directory in shared storage.
On APPHOST1
, start a per-domain Node Manager (NM1
) to manage server_1
listening on ip1
. Start this Node Manager (NM1
) from the domain directory that you unpacked to local storage in APPHOST1
in step 5.
On APPHOST2
, start a per-domain Node Manager (NM2
) to manage server_2
listening on ip2
. Start this Node Manager (NM2)
from the domain directory that you unpacked to local storage in APPHOST2
step 5.
Use Node Manager (NMa
) to start the Administration Server on APPHOST1
.
Start Managed Servers server_1
and server_2
using NM1
and NM2
, respectively.
Verify that the Administration Server and the Managed Servers are working properly. Connect to the Administration Server using the virtual IP address vip0
.
See the following topics to fail over or fail back the Administration Server:
This procedure describes how to fail over the Administration Server to APPHOST2 if APPHOST1 fails.
Configure vip0
on APPHOST2
.
Start Node Manager NMa on APPHOST2
from the domain directory in shared storage.
Start the Administration Server on APPHOST2
using NMa
.
Start the Administration Console to verify that the Administration Server is running.
This section describes how to fail back the Administration Server. You fail back the Administration Server to its original host after it restarts.
When APPHOST1
comes back online, fail back the Administration Server to APPHOST1
using the following procedure
Stop the Administration Server on APPHOST2
using Node Manager NMa.
Remove vip0
from APPHOST2
.
Stop Node Manager NMa on APPHOST2
.
Configure vip0 on APPHOST1
.
Start Node Manager NMa on APPHOST1
using the domain directory in shared storage.
Use Node Manager NMa to start the Administration Server on APPHOST1
.
Start the Administration Console to verify that the Administration Server is running.