| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Configuring and Managing WebLogic Server > Overview of WebLogic System Administration |
|
Configuring and Managing WebLogic Server
|
Overview of WebLogic System Administration
The following sections provide an overview of system administration for WebLogic Server:
Introduction to System Administration
WebLogic Server system administration tools allow you to install, configure, monitor, and manage one or more WebLogic Server installations. You also use the tools to manage and monitor the applications hosted on WebLogic Server. A WebLogic Server installation can consist of a single WebLogic Server instance or multiple instances, each hosted on one or more physical machines.
Using the system administration tools, which include an Administration Console, command line utilities, and an API, you manage services such as security, database connections, messaging, and transaction processing. The tools also include capabilities for monitoring the health of the WebLogic Server environment to ensure maximum availability for your applications.
The basic administrative unit for WebLogic Servers is called a domain. A domain is a logically related group of WebLogic Server resources that are managed as a unit by a WebLogic Server instance configured as the Administration Server. A domain includes one or more WebLogic Servers and may also include WebLogic Server clusters. Clusters are groups of WebLogic Servers that work together to provide scalability and high-availability for applications. Applications are also deployed and managed as part of a domain.
You can organize your domains based on criteria such as:
Note: All WebLogic Server instances in a domain must run the same version of the WebLogic Server software. The Administration Server must also have the same or later service pack installed as the Managed Servers in its domain. For example, the Administration Server could be running version 8.1, Service Pack 1 while the Managed Servers are running version 8.1 without Service Pack 1.
For more information about domains, see Configuring Domains.
Figure 1-1 WebLogic Server Domain
Figure 1-1 depicts a possible configuration of a WebLogic Server Domain—one of many possible configurations.
In the depicted domain, there are three physical machines.
Machine A is dedicated as the Administration Server and hosts one instance of WebLogic Server. The System Administration Tools communicate with the Administration Server to perform configuration and monitoring of the servers and applications in the domain. The Administration Server communicates with each of the Managed Servers on behalf of the System Administration Tools. The configuration for all the servers in the domain is stored in the configuration repository, the config.xml file, which resides on the machine hosting the Administration Server.
Machines B and C each host two instances of WebLogic Server, WebLogic Servers 1 through 4. These instances are called Managed Servers. The Administration Server communicates with an instance of Node Manager running on each machine to control startup and shutdown of the Managed Servers.
WebLogic Servers 2 and 4 are part of a WebLogic Cluster (outlined in red). This cluster is running an application that responds to HTTP requests routed to the cluster from a hardware load balancer. (You could also use an instance of WebLogic Server to provide load balancing.) The load balancer processes HTTP requests from the Internet after they have passed through a firewall. The load balancer and firewall are not part of the domain. A replicated copy of objects such as HTTP sessions is passed between the two cluster members to provide failover capability.
WebLogic Server 1 runs an application that uses Java Database Connectivity (JDBC) to access a database server running on another physical machine that is not part of the WebLogic Domain.
Note: The pictured domain is only intended to illustrate the concepts of a WebLogic Server domain and how you manage the domain. Many possible configurations of servers, clusters, and applications are possible in a WebLogic Server domain.
System Administration Infrastructure
System administration infrastructure in WebLogic Server is implemented using the Java Management Extension (JMX) specification from Sun Microsystems. The JMX API models system administration functions with Java objects called MBeans. Knowledge of this implementation as described in this discussion of system administration infrastructure is not necessary to manage a WebLogic Server domain.
There are three types of MBeans used to manage a WebLogic Server domain: administration, configuration, and runtime Mbeans.
Administration Mbeans contain a set of attributes that define configuration parameters for various management functions. All attributes for administration MBeans have pre-set default values. When the Administration Server starts, it reads a file called config.xml and overrides the default attribute values of the administration MBeans with any attribute values found in the config.xml file.
The config.xml file, located on the machine that hosts the Administration Server, provides persistent storage of Mbean attribute values. Every time you change an attribute using the system administration tools, its value is stored in the appropriate administration MBean and written to the config.xml file. Each WebLogic Server domain has its own config.xml file.
If you set any configuration attributes on the command line when you start the Administration Server using the -D arguments, these values override the values set by the defaults or those read from the config.xml file. These overridden values are also persisted to config.xml file by the Administration Server. For more information about these command-line arguments, see Configuring Servers.
Configuration Mbeans are copies of Administration Mbeans that each Managed Server uses to initialize its configuration. When you start a Managed Server, the server receives a copy of the of all the administration MBeans from the Administration Server and stores them in memory as configuration MBeans. If you override any configuration attributes when starting a Managed Server, those values override the values received from the Administration Server but are not written to the config.xml file. For more information about starting a Managed Server, see Starting Managed Servers.
Runtime Mbeans contain sets of attributes consisting of runtime information for active WebLogic Servers instances and applications. By retrieving the values of attributes in these runtime MBeans, you can monitor the running status of a WebLogic Server domain.
Mbeans may also contain operations used to execute management functions.
Although users with a knowledge of these Mbeans and the JMX API can create their own customized management system, most users prefer to use the system administration tools provided with WebLogic Server to perform these tasks. These tools do not require knowledge of the JMX API. For more information, see System Administration Tools.
The Administration Server and Managed Servers
One instance of WebLogic Server in each domain is configured as an Administration Server. The Administration Server provides a central point for managing a WebLogic Server domain. All other WebLogic Server instances in a domain are called Managed Servers. In a domain with only a single WebLogic Server instance, that server functions both as Administration Server and Managed Server.
For a typical production system, BEA recommends that you deploy your applications only on Managed Servers. This practice allows you to dedicate the Administration Server to configuration and monitoring of the domain.
For more information, see Starting and Stopping Servers.
Failover for the Administration Server
To prevent the Administration Server from becoming a single point of failure, Managed Servers can always function without the presence an Administration Server, but an Administration Server is required to manage and monitor the domain. By maintaining backups of the config.xml file and certain other resources for a domain, you can replace a failed Administration Server with a backup WebLogic Server instance that can assume the role of Administration Server. For more information, see Starting Administration Servers and Recovering Failed Servers.
When a Managed Server starts, it contacts the Administration Server to retrieve its configuration information. If a Managed Server is unable to connect to the specified Administration Server during startup, it can retrieve its configuration directly by reading a configuration file and other files located on the Managed Server's file system.
A Managed Server that starts in this way is running in Managed Server Independence mode. In this mode, a server uses cached application files to deploy the applications that are targeted to the server. You cannot change a Managed Server's configuration until it is able to restore communication with the Administration Server. For more information, see Recovering Failed Servers.
Domain-Wide Administration Port
You can enable an administration port for use with servers in a domain. The administration port is optional, but it provides two important capabilities:
For more information, see Configuring a Domain-Wide Administration Port.
Service Packs and WebLogic Server Instances
All WebLogic Server instances in a domain must run the same version of the WebLogic Server software. The Administration Server must also have the same or later service pack installed as the Managed Servers in its domain. For example, the Administration Server could be running version 8.1, Service Pack 1 while the Managed Servers are running version 8.1 without Service Pack 1.
Using JMX as the underlying architecture, system administration tools are provided for a variety of management functions. An Administration Server must be running when you use system administration tools to manage a domain.These tools are discussed in the next sections.
Security Protections for System Administration Tools
All system administration operations are protected based on the user name used to access a system administration tool. A user (or the group a user belongs to) must be a member of one of four security roles. These roles grant or deny a user access to various sets of system administration operations. The roles are Admin, Operator, Deployer, and Monitor. You can also set a security policy on WebLogic Server instances in a domain. For more information, see Protecting System Administration Operations.
The Administration Console is a Web Application hosted by the Administration Server. You can access the Administration Console using a Web browser from any machine on the local network that can communicate with the Administration Server (including a browser running on the same machine as the Administration Server). The Administration Console allows you to manage a WebLogic Server domain containing multiple WebLogic Server instances, clusters, and applications. The management capabilities include:
Using the Administration Console, system administrators can easily perform all WebLogic Server management tasks without having to learn the JMX API or the underlying management architecture. The Administration Server persists changes to attributes in the config.xml file for the domain you are managing.
The command-line interface allows you to manage a WebLogic Servers domain when using the Administration Console is not practical or desired—such as when you want to use scripts to manage your domain, when you cannot use a Web browser to access the Administration Console, or if you prefer using the command-line interface over a graphical user interface. You can use only the command-line interface to manage your domain, or you may use the command-line interface in combination with other system administration tools such as the Administration Console to manage you domain.
The command line interface invokes a Java class called weblogic.Admin. Arguments for this class provide the ability to perform many common management functions without the need to learn the JMX API. For more information, see:
If you require more fine-grained control than the weblogic.Admin management functions provide you can also use the command line interface to perform set or get operations directly on Mbean attributes. This feature requires knowledge of the WebLogic Server Mbean architecture. For more information, see the following resources:
Advanced Java programmers with knowledge of the JMX API from Sun Microsystems Inc. and WebLogic Server Mbeans can write their own management components as a Java class.
Use the Configuration Wizard to create a new WebLogic Server domain. This tool can create domain configurations for stand-alone servers, Administration Servers with Managed Servers, and clustered servers. The Configuration Wizard creates the appropriate directory structure for your domain, a basic config.xml file, and scripts you can use to start the servers in your domain.
You can run the Configuration Wizard either using a graphical user interface (GUI) or in a text-based command line environment. You can invoke the wizard as an optional part of the installation process or independently after installation. You can also create user-defined domain templates for use by the Configuration Wizard.
For more information, see Creating Domains and Servers.
Utility programs are provided for common tasks such as deploying an application and testing DBMS configurations. For more information, see Using the WebLogic Java Utilities.
Node Manager is a Java program provided with WebLogic Server that enables you to start, shut down, restart, and monitor remote WebLogic Server instances. To enable these capabilities, you run an instance of Node Manager on each physical machine in your domain.
For more information, see Creating Domains and Servers.
WebLogic Server includes the ability to communicate with enterprise-wide management systems using Simple Network Management Protocol (SNMP). The WebLogic Server SNMP capability enables you to integrate management of WebLogic Servers into an SNMP-compliant management system that gives you a single view of the various software and hardware resources of a complex, distributed system.
Many WebLogic Server operations generate logs of their activity. Each server has its own log as well as a standard HTTP access log. These log files can be configured and used in a variety of ways to monitor the health and activity of your servers and applications.
You can also configure a special domain log that contains a definable subset of log messages from all WebLogic Server instances in a domain. You can modify which logged messages from a local server appear in the domain log using the system administrating tools. You can view this domain log using the Administration Console or a text editor/viewer.
For more information, see Domain Log Filters.
You can manage a WebLogic Server domain by manually editing the persistent store for configuration, the config.xml. (Other system administration tools automatically save the configuration to the config.xml file.) Because of the difficulty of correctly editing the XML syntax required in this file, this method of configuration is not recommended but may provide advantages in limited situations.
Note: Do not edit the config.xml file while the Administration Server is running.
For more information, see BEA WebLogic Server Configuration Reference.
Resources You Can Manage in a WebLogic Server Domain
This section discusses the domain resources you manage with the system administration tools.
The administrative concept of a server represents an instance of WebLogic Server in your domain. Using the system administration tools you can:
WebLogic Server clusters allow you to distribute the work load of your application across multiple WebLogic Server instances. Clusters can improve performance and provide fail-over should a server instance become unavailable. For example, clusters provide several ways to replicate objects used in your applications so that data is not lost in the event of hardware failure.
You can architect combinations of clusters to distribute the work load in a way that provides the best performance for your applications.
Some services that are hosted on a single instance of WebLogic Server can be migrated from one server to another in the event of server failure. The system administration tools allow you to control these migrations.
For more information, see Using WebLogic Server Clusters.
The administrative concept of a machine represents the physical machine that hosts an instance of WebLogic Server. WebLogic Server uses machine names to determine the optimum server in a cluster to which certain tasks, such as HTTP session replication, are delegated.
Using the system administration tools you can define one or more machines, configure Node Manger for those machines, and assign servers to the machines. For UNIX machines, you can configure UID and GID information.
For more information, see Using WebLogic Server Clusters.
Network channels are an optional feature that you can use to configure additional ports with one or more WebLogic Server instances or clusters. All servers and clusters that use a network channel inherit the basic port configuration of the channel itself. You can also customize a channel's port settings on an individual server using channel fine-tuning. This fine-tuning process creates an additional network resource called a Network Access Point.
For more information, see Configuring Network Resources.
Java Database Connectivity (JDBC) allows Java programs to interact with common DBMSs such as Oracle, Microsoft SQL Server, Sybase, and others.
Using the System Administration tools you can manage and monitor connectivity between WebLogic Server and your database management system. Connectivity is usually established through connection pools.
For more information, see JDBC.
The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems that allow communication between applications.
Using the system administration tools, you can define configuration attributes to:
For more information, see Configuring JMS.
A Messaging Bridge transfers messages between two messaging providers. The providers may be another implementation of WebLogic JMS or a 3rd party JMS provider.
For more information, see Using the WebLogic Messaging Bridge.
Web Servers and Web Components
WebLogic Server can perform as a fully functional Web server. WebLogic Server can server both static files such as HTML files and dynamic files such as Java servlets or Java ServerPages (JSP). Virtual hosting is also supported.
For more information on managing Web server functionality in WebLogic Server, see Configuring WebLogic Server Web Components.
Application deployment tools, including the Administration Console allow you to deploy, manage, update, and monitor your applications. The application deployment tools also allow you to deploy and update applications in a cluster of WebLogic Servers.
WebLogic Server uses a two-phase deployment model that gives you more control over the deployment process. For more information, see WebLogic Server Deployment.
Using the system administration tools you can:
You deploy applications in one or more of the following J2EE application formats:
Editing and Creating Deployment Descriptors with WebLogic Builder
In addition to using the Administration Console to edit deployment descriptors you can also use the more robust WebLogic Builder tool that is included with your WebLogic Server distribution. WebLogic Builder is a stand-alone graphical tool for assembling a J2EE application, creating and editing deployment descriptors, and deploying an application on WebLogic Server. For more information, see WebLogic Builder Online Help.
A startup class is a Java program that is automatically loaded and executed when a WebLogic Server is started or restarted and after other server initialization tasks have completed. A shutdown class is automatically loaded and executed when a WebLogic Server is shut down either from the Administration Console or using the weblogic.Admin shutdown command.
You use the system administration tools to register and manage startup and shutdown classes.
For more information, see Starting and Stopping WebLogic Server Instances.
The Java Naming and Directory Interface (JNDI) API enables applications to look up objects—such as Data Sources, EJBs, JMS, and MailSessions—by name. You can view the JNDI tree through the Administration Console.
For additional information, see:
You use the system administration tools to configure and enable the WebLogic Server Java Transaction API (JTA). The transaction configuration process involves configuring:
The XML Registry is a facility for configuring and administering the XML resources of an instance of WebLogic Server. XML resources in WebLogic Server include the parser used by an application to parse XML data, the transformer used by an application to transform XML data, external entity resolution, and caching of external entities.
For more information, see Administering WebLogic Server XML.
The WebLogic Server security subsystem allows you to plug in third-party security solutions and also provides out-of-the box implementations for many common security systems. You can also create your own security solution and implement it in WebLogic Server.
For backwards compatibility, the security functionality available in version 6.0 and 6.1 of WebLogic Server is also supported when running in Compatibility Mode.
Using the administration tools, you can define realms, users, groups, passwords, ACLs and other security features.
WebLogic Tuxedo Connector provides interoperability between WebLogic Server applications and Tuxedo services. The connector allows WebLogic Server clients to invoke Tuxedo services and Tuxedo clients to invoke WebLogic Server Enterprise Java Beans (EJBs) in response to a service request.
For more information see WebLogic Tuxedo Connector.
Jolt is a Java-based client API that manages requests to BEA Tuxedo services via a Jolt Service Listener (JSL) running on a Tuxedo server.
For more information, see BEA Jolt.
WebLogic Server includes the JavaMail API version 1.1.3 reference implementation from Sun Microsystems.
For more information, see "Using JavaMail with WebLogic Server Applications" under Programming Topics.
Starting and Using the Administration Console
This section contains instructions for starting and using the Administration Console.
Browser Support for the Administration Console
To run the Administration Console, use one of the following Web browsers:
If you use a Web browser that is not on the above list you may experience functional or formatting problems.
Starting the Administration Console
http://hostname:port/console
Where hostname is the DNS name or IP address of the Administration Server and port is the address of the port on which the Administration Server is listening for requests (7001 by default). If you started the Administration Server using Secure Socket Layer (SSL), you must add s after http as follows:
https://hostname:port/console
For more information about setting up SSL for system administration, see Server --> Configuration --> Keystores and SSL
Note: If you have your browser configured to send HTTP requests to a proxy server, then you may need to configure your browser to not send Administration Server HTTP requests to the proxy. If the Administration Server is on the same machine as the browser, then ensure that requests sent to localhost or 127.0.0.1 are not sent to the proxy.
Using the Administration Console
For more information on using the Administration Console, see Configuring Your Domain Using the Administration Console.
Using WebLogic Server with Web Servers
You can proxy requests from popular Web servers to an instance of WebLogic Server or a cluster of WebLogic Servers by using one of the Web server plug-ins. Plug-ins are available for the following Web servers:
Because these plug-ins operate in the native environment of the Web server, management of the plug-ins is done using the administration facilities of that Web server.
For more information, see Using WebLogic Server with Plug-ins.
Special servlets are also available to proxy requests from an instance of WebLogic Server to another instance of WebLogic Server or to a cluster of WebLogic Servers. For more information, see:
The system administration tools contain extensive capabilities for monitoring WebLogic Servers, domains, and resources. Using the tools you can monitor:
For more information, see Monitoring a WebLogic Server Domain
WebLogic Server requires a valid license to function.
An evaluation copy of WebLogic Server is enabled for 30 days so you can start using WebLogic Server immediately. To use WebLogic Server beyond the 30-day evaluation period, you will need to contact your salesperson about further evaluation or purchasing a license for each IP address on which you intend to use WebLogic Server. All WebLogic Server evaluation products are licensed for use on a single server with access allowed from up to three unique client IP addresses.
If you downloaded WebLogic Server from the BEA Web site, your evaluation license is included with the distribution. The WebLogic Server installation program allows you to specify the location of the BEA home directory, and installs a BEA license file, license.bea, in that directory.
For more information, see Installing and Updating a WebLogic Server License.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
