8 Administration Server High Availability

This section describes high availability aspects of the Administration Server.

This section includes the following topics:

For more information on the Administration Server and Node Manager, see the following topics:

Table 8-1 Administration Server and Node Manager Topics

For information on... See this topic...

Starting and Stopping the Administration Server

"Starting and Stopping Administration Server" in Oracle Fusion Middleware Administering Oracle Fusion Middleware

Configuring virtual hosting

"Configuring Virtual Hosting" in Administering Server Environments for Oracle WebLogic Server

Using Node Manager

In Administering Node Manager for Oracle WebLogic Server:

8.1 Role of the Administration Server

The Administration Server is the central control entity for configuring the entire domain, and manage and monitor all domain resources. It maintains the domain's configuration documents and distributes changes in these documents to Managed Servers. Each domain requires one server that acts as the Administration Server.

8.1.1 Administration Server Failure and Restart

Administration Server failure does not affect how Managed Servers in a domain operate. If an Administration Server fails due to a hardware or software failure on its host computer, other server instances on the same computer may also be affected.

For more information on Administration Server failure, see "Impact of Managed Server Failure" in Oracle Fusion Middleware Administering Oracle Fusion Middleware.

To restart an Administration Server, see Oracle Fusion Middleware Using Clusters for Oracle Server.

8.1.2 Shared Storage and Administration Server High Availability

With shared storage, a backup host can access the same artifacts (Oracle binaries, configuration files, domain directory, and data) that an active host can. You configure this access by placing artifacts in storage that all hosts in the highly available Administration Server configuration can access. Shared storage is a network-attached storage (NAS) or storage area network (SAN) device. See Chapter 4, "Using Shared Storage".

8.2 Role of Node Manager

For each WebLogic Server domain you create, a per domain Node Manager configuration is created by default. This Node Manager comes complete with security credentials, a properties file, domain registration, and start scripts

You can configure the scope of Node Manager:

  • per domain Node Manager is associated with a domain to control all servers for the domain on a machine. Default configuration.

  • per host Node Manager is associated with a specific machine, not a domain. One Node Manager process can control server instances in any 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 that you want to control with Node Manager, whether the WebLogic Server instances are an Administration Server or Managed Server(s).

Note:

Oracle recommends that you run Node Manager as an operating system service so that it restarts automatically if its host machine restarts.

Node Manager failure doesn't affect any servers running on the machine.

For more information, see "What is Node Manager?" in Oracle Fusion Middleware Understanding Oracle Fusion Middleware Concepts.

8.3 Administration Server High Availability Topology

Administration Server can be active on one host at any one time. To set up high availability, you configure the Administration Server on a virtual host so that if the machine that it runs on fails, you can fail it over to another host in the domain. Administration Server is configured to use a virtual IP to overlap the backup hosts. You configure Administration Server to listen on this virtual IP. The benefit of using a virtual host and virtual IP is that you don't need to add a third machine; if failover occurs, you can map the virtual host 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 becomes active and you must move (manually) the virtual IP to the new active host. The new active host then services all requests through the virtual IP. (You configure a high availability deployment to listen on this virtual IP.)

The following figure 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

Description of Figure 8-1 follows
Description of "Figure 8-1 Administration Server High Availability Topology"

8.4 Configuring Administration Server High Availability

This section 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.

8.4.1 Administration Server High Availability Requirements

To configure a highly available Administration Server, your environment must meet the following requirements:

8.4.2 Configuring the Administration Server for High Availability

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.6, "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 multiple ways for 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

APPHOST0, machine_0

Virtual machine that the Administration Server runs on

APPHOST1, APPHOST2

Machines that host the application tier.

vip0

Virtual server IP address that the Administration Server listens on

NMa

Per-domain Node Manager that manages the Administration Server that runs on APPHOST0

NM1, NM2

Node Manager instances that run on APPHOST1 and APPHOST2, respectively

ip1, ip2

IP addresses of APPHOST1 and APPHOST2, respectively

To configure the Administration Server for high availability:

  1. Configure a virtual server IP address (vip0) on APPHOST1 to represent virtual host APPHOST0.

    See "Configuring Virtual Hosting" in Administering Server Environments for Oracle WebLogic Server for more information.

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

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

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

  5. Scale out the virtual server to APPHOST1 and APPHOST2. See Section 6.2, "Roadmap for Scaling Out Your Topology." To scale out you pack the domain in shared storage and unpack it to a local directory on APPHOST1 and APPHOST2.

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

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

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

  9. Use Node Manager (NMa) to start the Administration Server on APPHOST1.

  10. Start Managed Servers server_1 and server_2 using NM1 and NM2, respectively.

  11. Verify that the Administration Server and the Managed Servers are working properly. Connect to the Administration Server using the virtual IP address vip0.

8.5 Failing Over or Failing Back Administration Server

See the following topics to fail over or fail back the Administration Server after host failure:

8.5.1 Failing Over the Administration Server if Original Host Fails

To fail over the Administration Server to APPHOST2 if APPHOST1 fails.

  1. Configure vip0 on APPHOST2.

  2. Start Node Manager NMa on APPHOST2 from the domain directory in shared storage.

  3. Start the Administration Server on APPHOST2 using NMa.

  4. Start the Administration Console to verify that the Administration Server is running.

8.5.2 Failing Back the Administration Server to the Original Host

You fail back the Administration Server to its original host after it restarts.

To fail back the Administration Server to APPHOST1 when APPHOST1 comes back online:

  1. Stop the Administration Server on APPHOST2 using Node Manager NMa.

  2. Remove vip0 from APPHOST2.

  3. Stop Node Manager NMa on APPHOST2.

  4. Configure vip0 on APPHOST1.

  5. Start Node Manager NMa on APPHOST1 using the domain directory in shared storage.

  6. Use Node Manager NMa to start the Administration Server on APPHOST1.

  7. Start the Administration Console to verify that the Administration Server is running.