Configuring Managed Servers

Configuring Managed Servers

The screenshot shows creating a managed server with the Administration Console. You have already seen how to use the Domain Configuration Wizard to create a new managed server in the lesson titled “Using Administration Console and WLST.”

To create a managed server by using the WebLogic Administration Console, perform the following steps:

1.  Click Servers in the Explorer pane (to the left of the Administration Console).

2.  Click New to configure a new server.

3.  Enter the server details in the WebLogic console. If there are multiple servers on the same host, each server needs to have different listen ports. There is a difference from an SSL Certificate standpoint between localhost and 127.0.0.1, or between any DNS name or alias and an IP address. If you leave Server Listen Address blank, any host or alias name for that server will work in a URL. For example, for the lab, null (blank) is the same as localhost, wls-sysadm, edvmr1p0, and the FQN. However, if you enter localhost, http://wls-sysadm and http://edvmr1p0 would not work.

4.  Review the choices (not shown) and click Finish.

Even though the new server is created, it is not yet started.

 

 

java weblogic.WLST

wls:/offline> connect('weblogic','mypassword','t3://localhost:7020')

 Connecting to t3://localhost:7020 with userid weblogic ...

 Successfully connected to Admin Server 'MedRecAdmSvr' that belongs to
 domain 'MedRecDomain'.

wls:/MedRecDomain/serverConfig> cd('Servers')

wls:/MedRecDomain/serverConfig/Servers> edit()

wls:/MedRecDomain/edit> startEdit()

wls:/MedRecDomain/edit !> server1=create('MedRecSvr3','Server')

 MBean type Server with name MedRecSvr3 has been created successfully.

wls:/MedRecDomain/edit !> server1.getName()

 'MedRecSvr3'

wls:/MedRecDomain/edit !> ls('Servers')

 drw-   MedRecAdmSvr

 drw-   MedRecSvr1

 drw-   MedRecSvr2

 drw-   MedRecSvr3

wls:/MedRecDomain/edit !> save()

wls:/MedRecDomain/edit !> activate()

wls:/MedRecDomain/edit !> stopEdit()

wls:/MedRecDomain/edit> exit()

[oracle@wls-sysadm /]$

Creating a Managed Server with WLST

Note the following when you use the create command with WLST online:

•You must be connected to an administration server. You cannot use the create command for run-time MBeans or when WLST is connected to a managed server instance.

•You must navigate to the edit configuration MBean hierarchy using the edit command before issuing this command.

•You can use the create command to create an Oracle WebLogic Server configuration MBean that is a child of the current MBean type.

•Note the following when using the create command with WLST offline:

-When using WLST offline, the following characters are not valid in object names: period (.), slash (/), or backslash (\).

Syntax

create(name, childMBeanType, [baseProviderType])

Argument Definition

•name: Name of the configuration bean that you are creating

•childMBeanType: Type of configuration bean that you are creating. You can create instances of any type that are defined in the config.xml file except custom security types.

•baseProviderType: When creating a security provider, it specifies the base security provider type—for example, AuthenticationProvider. This argument defaults to None.

Using WLST, you can create a child configuration bean of type Server, named newServer for the current configuration bean, and store the stub as server1:

wls:/mydomain/edit !> server1=create('newServer','Server')
MBean Server with name newServer has been created successfully.
wls:/mydomain/edit !> server1.getName()
'newServer'
Here is an alternative way to programmatically create a series of servers and ports using a for loop:

servers = {'serverB':7021,'serverC':7031}

connect('myAdminuser','Welcome1','localhost:7001')

edit()

startEdit()

for name, port in servers.items():

   cd('/Servers')

   create(name,'Server')

   cd(name)

   set('ListenPort',port)

save()

activate()

disconnect()

exit()

Starting Oracle WebLogic Managed Servers

There are four ways to start a managed server as listed in the slide. The first two are covered in detail in the next few slides.

startManagedWebLogic

The startManagedWebLogic script is the easiest to run (only one line). It has no special requirements.

weblogic.Server

Calling weblogic.Server from Java has many options to type (and is prone to typos). It is probably used only inside of a script, not typed from the command line. For example, it is used by startManagedWebLogic.

WLST and Node Manager

WLST requires that Node Manager be set up on each machine beforehand. This is useful for scripts, but involves some work to get it working the first time.

Administration Console

The Administration Console is the most powerful and easiest way to manage servers through the GUI, but it requires the most setup work with Node Manager running on each machine beforehand.

Note: You learn how to start managed servers using WLST and Node Manager later in the lesson titled, “Configuring Node Managers.”

 

Starting a Managed Server Using startManagedWebLogic.sh

Your domain directory includes a start script named startManagedWebLogic that you can use to start managed servers. You can use this script to start all the managed servers in a cluster. This script does not use Node Manager to start and manage the server. Instead, it uses a Java command to invoke the weblogic.Server class, which is the main class for an Oracle WebLogic Server instance.

To start managed servers, perform the following steps:

1.  Start the domain’s administration server.

2.  In a shell (command prompt) on the computer that hosts the managed server, change to the directory that contains the startManagedWebLogic script:
DOMAIN_NAME/bin/startManagedWebLogic.sh

  Here, DOMAIN_NAME is the directory in which you located the domain. By default, this directory is <MW_HOME>\user_projects\domains\DOMAIN_NAME. If the administration server is on the same computer as the managed server, you need not type in the admin_url. 

startManagedWebLogic.sh managed_server_name [admin_url]

Here, managed_server_name (required) specifies the name of the managed server and admin_url (optional) specifies the listen address (host name or IP address) and port number of the domain’s administration server.

For each managed server that you want to start, open a separate command shell and follow the preceding steps. If you are starting managed servers on another machine, log in to that machine (remotely or locally), and then perform the same steps.

The startManagedWebLogic script does the following:

•It calls the startWebLogic script, which sets the environment variables by invoking DOMAIN_NAME\bin\setDomainEnv.sh.

•It invokes the java weblogic.Server command, which starts a JVM that is configured to run an Oracle WebLogic Server instance.

When the server successfully completes its startup process, it writes the following message to standard out (which, by default, is the command page):

<Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>

After completing the startup, the process creates the server directory structure in the domain if it did not exist before.

Command-Line Requirements for Starting the Managed Server Using java weblogic.Server

The weblogic.Server class is the main class for an Oracle WebLogic Server instance. If you were writing your own start script (you would not enter this each time), you could start a server instance by directly invoking weblogic.Server in a Java command.

•In a command shell, set up the required environment variables by running the following script:
<WL_HOME>/server/bin/setWLSEnv.sh

  where <WL_HOME> is the directory in which you installed the Oracle WebLogic Server software

In the command shell, change to the root of the domain directory, usually <MW_HOME>/user_projects/domains/DOMAIN_NAME. For example, change to /home/oracle/wls-sysadm/work/domains/MedRecDomain.

•Start an administration server using the following command:
java weblogic.Server

•If the domain’s administration server is already running, and if you have already defined a managed server in the config.xml file, you can start a managed server as follows:
java -Dweblogic.Name=managed-server-name
-Dweblogic.management.server=url-for-Admin-Server:port
weblogic.Server

When you start a managed server, you must specify the administration server URL that maintains the configuration information for the managed server. The weblogic.Server command that allows managed servers to point to their administration server is:

  -Dweblogic.management.server

If you exclude this command, by default, you start the server as an administration server and not as a managed server. In the preceding example, you would specify the following in the weblogic.Server command to start the managed servers:

  -Dweblogic.management.server=http://192.168.0.1:7001

You can also connect using HTTPS:

  -Dweblogic.management.server=https://192.168.0.1:7002

There should be no spaces surrounding the = sign, and in the event that embedded spaces must be present in the value, the value must be enclosed in double quotation marks.

Starting a Managed Server Using the Administration Console

1.  In the left pane of the Console, expand Environment and click Servers.

2.  In the Servers table, click the name of the managed server instance that you want to start.

3.  Click the Control tab and then the Start/Stop subtab.

4.  In the Server Status table, select the check box next to the name of the server that you want to start and click Start. Note that MedRecSvr2 is associated with a machine MedRecMch2, whereas MedRecSvr4, for example, might not be associated with a machine (blank in the Machine column). Therefore, MedRecSvr4 could not be started from the Administration Console.

5.  On the Server Life Cycle Assistant page, click Yes to confirm. The Node Manager starts the server on the target machine. When the Node Manager finishes its start sequence, the server’s state is indicated in the State column in the Server Status table.

Note: The Node Manager must be configured before you start the managed server by using the Administration Console. You learn how to configure the Node Manager in the lesson titled “Configuring Node Managers.”

 

Shutting Down a Server

1.  Click the Environment > Servers node in the left pane.

2.  Click the Control tab in the right pane.

3.  Select the check box for the server that you want to shut down.

4.  Select either “Force Shutdown Now” or “When work completes” from the Shutdown menu. A confirmation message appears in the right pane. Click Yes to proceed.

If you shut down the administration server, you will lose the browser console display. You will need to restart the administration server from a command line.

 

connect('weblogic','weblogic','t3://wls-sysadm.example.com:7001') 

ls('Servers')

shutdown('MedRecSvr1')

shutdown('MedRecAdmSvr')

exit()

Creating a Boot Identity File

A boot identity file is a text file that contains user credentials for automatically starting and stopping an instance of Oracle WebLogic Server. Technically you are not “logging in” as anybody, but simply validating that you have the credentials (authority) to start the instance. An administration server can refer to this file for user credentials instead of prompting you to provide them. Because the credentials are encrypted, using a boot identity file is much more secure than storing unencrypted credentials in a startup or shutdown script. If there is no boot identity file when starting a server, the server instance prompts you to enter a username and password.

If you use the Configuration Wizard to create a domain in development mode, the Configuration Wizard creates an encrypted boot identity file in the security directory of the administration server’s root directory.

If you start a managed server from a script that invokes the java weblogic.Server command (or if you invoke the java weblogic.Server command directly), the managed server can also refer to a boot identity file. If a managed server’s security directory contains a valid boot.properties file, it uses this file during its startup process by default. The boot.properties file will be different for each server instance in the domain (after encryption).

If you use the Node Manager to start a managed server, the Node Manager encrypts and saves the credentials with which it started the server in a server-specific boot.properties file for use in automatic restarts. This file is located in DOMAIN_NAME/servers/SERVER_NAME/data/nodemanager, where DOMAIN_NAME is the name of the directory in which you created the domain and SERVER_NAME is the name of the server.

For a given server instance, use only the boot identity file that the instance created. Oracle WebLogic Server does not support copying a boot identity file from the server root directory to another directory.

For example, if you use ServerA to generate a boot identity file, use only that boot identity file with ServerA. Do not copy ServerA’s boot identity file into the security directory of ServerB. Instead, create a boot identity file for ServerB.

Monitoring All Servers

This screenshot shows a list of all the servers, running and otherwise. To monitor the state of all servers, perform the following steps:

1.  Click Environment > Servers in the left pane.

2.  This page summarizes each server that has been configured in the current Oracle WebLogic Server domain. The available table columns include:

-Cluster: The cluster or group of Oracle WebLogic Server instances to which this server belongs

-Machine: The Oracle WebLogic Server host computer (machine) on which this server is meant to run. If you want to use a Node Manager to start this server, you must assign the server to a machine and configure the machine for the Node Manager.

-State: The current life cycle state of the server. For example, a server  can be in a RUNNING state in which it can receive and process requests, or in an ADMIN state in which it can receive only administrative requests.

-Health: The health state of the server as reported by the server’s self-health monitoring. For example, the server can report if it is overloaded with too many requests, if it needs more memory resources, or if it will soon fail for other reasons.

 

-Listen Port: The default TCP port that this server uses to listen for regular (non-SSL) incoming connections

-Listen Address: The IP address or DNS name that this server uses to listen for incoming connections. Any network channel that you configure for this server can override this listen address. If a server’s listen address is undefined, clients can reach the server through an IP address of the computer that hosts the server, a DNS name that resolves to the host, or the localhost string.

Creating a Managed Server on a Remote Machine

In some domains, you may want to run a managed server on a machine that is remote from the administration server for the domain. You can do so by using the pack command to create a managed server template (a .jar file that, by default, contains only the files necessary to create a managed server domain directory), copying the template to the remote machine, and unpacking the template to create a domain directory customized for a managed server.

The following are the steps to create a managed server domain directory on a remote machine:

1.  Install WLS software on both computers. They need to be the same version of WLS software, but not necessarily the same OS.

2.  Create a managed server on the local computer using the Administration Console that has the characteristics you want on the remote computer.

3.  Create a managed server template using the pack command. A managed server template, by default, contains only those files necessary to create a managed server on a remote machine.

4.  Create a managed server on the remote computer by copying and unpacking the managed server template on a remote computer. This also creates the remote managed server config.xml. The two computers do not need to have the same directory structure for WebLogic Server. The use of templates allows you to have your WLS installation at different locations on each machine if you want. (pack tokenizes all the scripts with @WL_HOME, and so on, and then unpack fills them back in.)

5.  Start the managed server on the remote machine.

  

pack and unpack:

[oracle@wls-sysadm]$ cd $WL_HOME/common/bin

[oracle@wls-sysadm]$ pack -managed=true
-domain=/u01/app/oracle/user_projects/domains/mydomain
-template=/home/oracle/work/mydomain_managed.jar
-template_name="My Managed Server Domain"

cd $WL_HOME/common/bin

[oracle@wls-mgdsvr2]$ unpack
-domain=/u01/app/oracle/user_projects/domains/mydomain
-template=/home/oracle/work/mydomain_managed.jar

Managed Server Independence (MSI)

Usually, a managed server contacts the administration server during its startup sequence to retrieve its configuration information. If a managed server cannot connect to the administration server during startup, it can retrieve its configuration by reading its locally cached configuration data from the config directory.

A managed server that starts in this way is running in Managed Server Independence (MSI) mode.

To configure a managed server to replicate a domain’s configuration files, perform the following steps:

1.  If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit.

2.  In the left pane of the Console, select Environment > Servers and click the name of the managed server instance.

3.  Select Configuration > Tuning and click Advanced at the bottom of the page.

4.  Make sure that the Managed Server Independence Enabled check box is selected.

5.  Click Save.

6.  To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

MSI Search Order

If a managed server cannot connect to the administration server during startup, it can retrieve its configuration by reading its locally cached configuration data from the config directory. A managed server that starts in this way is running in Managed Server Independence (MSI) mode.

In MSI mode, a managed server looks in its:

•Local config directory for config.xml, a replica of the domain’s config.xml

•Security directory for SerializedSystemIni.dat and for boot.properties, which contains an encrypted version of your username and password

If config.xml and SerializedSystemIni.dat are not in these locations in the server’s domain directory, you can copy them from the administration server’s domain directory.

Each Oracle WebLogic Server instance writes log messages to its local log file and a domainwide log file. The domain log file provides a central location from which to view messages from all servers in a domain.

Usually, a managed server forwards messages to the administration server and the administration server writes the messages to the domain log file. However, when a managed server runs in MSI mode, it continues to write messages to its local server log file but does not forward messages to the domain log file.

A managed server that starts in MSI mode deploys its applications from its staging directory: serverroot\stage\appName.

You cannot use the Node Manager to start a server instance in MSI mode, but you can use it only to restart it. For a routine startup, the Node Manager requires access to the administration server. If the administration server is unavailable, you must log on to a managed server’s host machine to start the managed server.

Note: The first time you start a managed server instance, it must be able to contact the administration server to get its copy of the config.xml. Thereafter, the managed server instance can start even if the administration server is unavailable.

When the Administration Server Is Down

One misconception about the administration server is that it represents a single point of failure. However, this is not true. Administration servers are needed only to start managed servers. After the managed servers are started, the administration server can go down without affecting them.

The only thing that may be lost in such a scenario is the domain-specific log entries, only while the administration server is down. Also, if a new managed server tries to start, it fails because it would not be able to connect to the administration server. Lastly, the Administration Console and other management tools would not be available.

SNMP Agent May Become Unavailable

In each WebLogic Server domain, you can optionally create multiple SNMP agents and organize them into a decentralized or centralized model for SNMP monitoring and communication:

•In a decentralized model, you create SNMP agents on each managed server. SNMP managers communicate with the agents on individual managed servers. Losing the administration server does not affect SNMP on the managed servers.

In a centralized model, you create an SNMP agent only on the administration server. SNMP managers communicate only with the SNMP agent on the administration server and the agent gathers monitoring data from all managed servers in the domain. This model is convenient and enables a single request to retrieve data for the entire domain. But, if the administration server is unavailable, you cannot monitor the domain through SNMP. 

Running Multiple WLS Instances

A multihomed computer is one in which multiple IP addresses are bound to a single computer. A multihomed computer may have multiple network cards or simply multiple IP addresses bound to a single network card. In either case, a computer with more than one IP address is considered to be multihomed. Multihomed computers can be configured to run multiple instances of Oracle WebLogic Server, each bound to a specific IP address and thus can simulate a multiple computer cluster environment on a single computer.