| Oracle® Fusion Middleware Production Operations Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14245-03 |
|
|
View PDF |
| Oracle® Fusion Middleware Production Operations Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14245-03 |
|
|
View PDF |
Before you can deploy a WebLogic Portal application to a clustered environment, you need to use the WebLogic Configuration Wizard to set up and configure a WebLogic Portal domain specifically for a clustered environment. This chapter explains the basic steps to configure a clustered environment for your portal application.
Note:
WebLogic Portal supports the use of both multicast and unicast cluster messaging. For more information on multicast and unicast, see the WebLogic Server document Using Clusters.The topics discussed in this chapter include:
This chapter describes a set of prerequisite tasks you need to perform before you set up a clustered environment for WebLogic Portal applications. After the prerequisite tasks are complete, this chapter explains how to use the WebLogic Configuration Wizard to set up and configure the cluster, including JMS servers and Managed Server directories.
You need to perform several prerequisite tasks before you can configure a clustered production environment for your WebLogic Portal application. Detailed information on most of these prerequisite tasks is beyond the scope of this chapter, and is documented elsewhere (typically in WebLogic Server documentation). Where appropriate, cross-references to source and supplemental documentation are provided.
Note:
You can perform these tasks in any order, but they must be addressed before you proceed to configure the cluster environment.The prerequisite tasks include:
To deploy a portal application into production, it is necessary to set up an enterprise-quality database. For detailed information on setting up an enterprise-quality database, see Section 2.4, "Managing Databases." For details on configuring your production database see the Oracle Fusion Middleware Database Administration Guide for Oracle WebLogic Portal.
Note:
An instance of Derby database is installed when you install WebLogic Server, and is the default database. Derby is supported only for the design, development, and verification of applications. It is not supported for production server deployment.Once you have configured your Enterprise database instance, it is possible to install the required database DDL and DML from the command line as described in the Oracle Fusion Middleware Database Administration Guide for Oracle WebLogic Portal. You can also create the DDL and DML from the WebLogic Configuration Wizard when configuring your production environment.
JMS queues and JDBC names for WebLogic Portal are referenced in the DOMAIN_ROOT/config/config.xml file. JMS queues for WebLogic Portal are configured in DOMAIN_ROOT/config/jms/*.xml files. JDBC data sources are configured in DOMAIN_ROOT/config/jdbc/*.xml files.
Tip:
For detailed information on JMS queue configuration, see Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server. For detailed information on JDBC, see Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.Note:
WebLogic Portal supports the use of both multicast and unicast cluster messaging. For more information on multicast and unicast, see the WebLogic Server document Using Clusters.A cluster consists of multiple WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability. A WebLogic Portal application deployed to a cluster appears to clients to be a single application instance.
Note:
Multiple managed servers running a WLP application must be deployed to a cluster. Running a WLP application on multiple servers that are not configured as a cluster is not supported.By clustering a portal application, you can attain high availability and scalability for that application. Use this section to help you choose which cluster configuration you want to use.
This section includes the following topics:
Section 3.2.3.2, "Multi Cluster"
Note:
For more detailed information on server clusters, see "Cluster Architectures" in Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.Note:
In an early version of WebLogic Portal, it was possible to configure a portal application so that JSPs/Servlets and EJBs were deployed to separate servers. This split configuration is no longer supported.When setting up an environment to support a production instance of a portal application, the recommended configuration is to deploy your portal application directly to the cluster. For detailed information on this configuration, see "Cluster Architectures" in Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.
Figure 3-1 shows a WebLogic Portal-specific version of the recommended basic architecture.
Figure 3-1 WebLogic Portal Single Cluster Architecture
Note:
WebLogic Portal does not support a split-configuration architecture where EJBs and JSPs are split onto different servers in a cluster. The basic architecture provides significant performance advantages over a split configuration for WebLogic Portal.Even if you are running a single server instance in your initial production deployment, this architecture allows you to easily configure new server instances if and when needed.
A multi-clustered architecture can be used to support a zero-downtime environment when your portal application needs to be accessible continually. While a portal application can run indefinitely in a single cluster environment, deploying new components to that cluster or server will result in some period of time when the portal is inaccessible. This is due to the fact that while a new EAR application is being deployed to a WebLogic Server, HTTP requests cannot be handled. Redeployment of a portal application also results in the loss of existing sessions.
For more detailed information on the multi-cluster configuration, see "Recommended Multi-Tier Architecture" in Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.
A multi-cluster environment involves setting up two clusters, typically a primary cluster and secondary cluster. During normal operations, all traffic is directed to the primary cluster. When some new components (such as portlets) need to be deployed, the secondary cluster is used to handle requests while the primary is updated. The process for managing and updating a multi-clustered environment is more complex than with a single cluster and is addressed in Section 3.7, "Zero-Downtime Architectures." If this environment is of interest, you may want to review that section now.
Figure 3-2 WebLogic Portal Multi-Cluster Architecture
Before you build your domain with the WebLogic Configuration Wizard, you need to think about the network layout of the domain. Before configuring the domain, consider the total number of Managed Servers in the cluster, including:
The machines they will run on
Their listen ports
Their DNS addresses
In addition, decide if you will use WebLogic Node Manager to start the servers. For information on Node Manager, see Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server.
WebLogic Portal must be installed on all Managed Server machines and the Administration Server.
Note:
The Administration Server must always be running when WebLogic Portal is running in a clustered environment. This ensures that the cluster's policy data stays in sync with the references to that data that are stored by WebLogic Portal in the database.This section explains how to set up a clustered environment for a WebLogic Portal domain. This section steps you through the process of setting up a cluster using the WebLogic Configuration Wizard.
Note:
To achieve greater scalability, it is common to run a WLP application on multiple managed servers. Multiple managed servers running a WLP application must be deployed to a cluster. Running a WLP application on multiple servers that are not configured as a cluster is not supported.For more information on clusters, see Section 3.2.3, "Choose a Cluster Architecture" and Oracle Fusion Middleware Creating Domains Using the Configuration Wizard.
This section includes the following topics:
Section 3.3.2, "Creating the Customized Domain"
Tip:
You can remove some database files and components from your WebLogic Portal domain after you create it. For details, see Section 2.4.5, "Removing Unneeded Database Components."To run applications on WebLogic Server you must define and create a domain. To run WebLogic Portal applications, you must create a domain that includes the appropriate WebLogic Portal components.
A domain is the basic administration unit for WebLogic Server. It consists of one or more WebLogic Server instances, and logically related resources and services that are managed, collectively, as one unit. A basic domain infrastructure consists of one Administration Server and optional Managed Servers and clusters.
Tip:
For a more detailed description of these components, as well as a thorough introduction to domains, see Oracle Fusion Middleware Creating Domains Using the Configuration Wizard and "Understanding WebLogic Server Domains" in Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server.The Configuration Wizard guides you through the process of creating or extending a WebLogic Portal domain for your target environment. This process is accomplished using predefined configuration and extension templates containing the main attributes and files required for building or extending a WebLogic Portal domain.
Tip:
The Configuration Template Builder guides you through the process of creating custom configuration and extension templates from existing templates or domains. These templates can be used later for creating and updating domains using the Configuration Wizard. For detailed information on domain templates and instructions on using the Configuration Template Builder to create a domain template, see Oracle Fusion Middleware Creating Domain Templates Using the Domain Template Builder. It is a recommended best practice to create a custom domain template for use in a team development environment. For more information, see Section 2.3.3, "Creating a WebLogic Portal Domain Template.".You use the WebLogic Configuration Wizard to create a domain. The procedure for creating a customized domain includes these tasks:
Section 3.3.2.2, "Completing the Configuration"
Note:
The following procedure reflects the scope of the WebLogic Configuration Wizard, which handles many complex configuration tasks. We strongly recommend that you review and see Oracle Fusion Middleware Creating Domains Using the Configuration Wizard. This document contains more detailed information than is presented here on each of the wizard options.This section explains how to get started configuring a WebLogic Portal domain using the WebLogic Configuration Wizard.
Start the Configuration Wizard. In Windows, choose Start > All Programs > Oracle WebLogic > WebLogic Server 11gR1 > Tools > Configuration Wizard. You can also start the wizard by executing the file <WEBLOGIC_HOME>/common/bin/config.cmd (or config.sh). The Welcome dialog appears, as shown in Figure 3-3.
Tip:
You do not need to be running WebLogic Server to start the Configuration Wizard.Figure 3-3 WebLogic Configuration Wizard Welcome Window
In the Welcome dialog (Figure 3-3), select Create a new WebLogic domain, and click Next.
In the Select Domain Source dialog, select one of the following and click Next.
If you have not defined a custom domain template, select Generate a domain configured automatically to support the following Oracle products, and select the WebLogic Portal checkbox.
If you previously defined a custom domain template, select Base this domain on an existing template and use the Browse button to select the template file on your system.
In the Specify Domain Name and Location dialog, enter a domain name and specify the path to the directoy in which to place the domain.
In the Configure Administration Username and Password dialog, complete the User name and User password fields and, optionally, a description, such as the name of the administrator. This user is an administrator who can start and stop development mode servers. Click Next.
In the Configure Server Start Mode and JDK dialog, make the following selections and click Next:
Production Mode – Production mode is the recommended mode for running a production, or live, WebLogic Portal application. When running in production mode WebLogic Server takes advantage of optimizations that enhance performance.
JRockit SDK – The JRockit SDK is recommended for production environments. This JDK affords better runtime performance and management.
In the Configure JDBC Data Sources window (Figure 3-4) you can change the JDBC data source and JDBC component schema settings. For details on this window, see "Customizing JDBC Data Sources and Component Schema" in Oracle Fusion Middleware Creating Domains Using the Configuration Wizard.
Note:
When you click Next, the Configuration Wizard attempts to run a series of connection tests against the default Derby database. If the database is not running at this point, these tests will always fail. After the tests run, just click Next again. A warning dialog appears asking if you want to bypass testing. You can safely ignore this warning. Click OK to continue.Figure 3-4 Configure JDBC Data Sources Window
In the Run Database Scripts window, click Run Scripts.
Note:
This step is new as of WebLogic Portal 10.3.2. For past releases, these scripts were run automatically for the default Derby database. You must click the Run Scripts button before continuing.In the Select Optional Configuration window, you are give a chance to perform further configurations. These configurations include:
Administration Server
Managed Servers, Clusters, and Machines
Deployments and Services
RDBMS Security Store
For more information, see "Select Optional Configuration" in Oracle Fusion Middleware Creating Domains Using the Configuration Wizard.
The final screen lets you review the configuration.
The Review WebLogic Domain window allows you to review the detailed configuration settings of your domain before the Configuration Wizard creates it. Figure 3-5 shows a sample window. Click Next when you have completed your review.
Tip:
If you need to change anything, click the Previous button to return to a previous window.Figure 3-5 Review WebLogic Domain Window Sample
The Create WebLogic Domain window is the final window. Enter a name for the domain and a location for it. Click Create. A progress window appears indicating the progress of the domain creation.
In the progress window, click Done after the domain has been created.
The Administration Server requires a WebLogic Portal installation; however, do not deploy your WebLogic Portal applications to the Administration Server.
Note:
The Administration Server must always be running when WebLogic Portal is running in a clustered environment. This ensures that the cluster's policy data stays in sync with the references to that data that are stored by WebLogic Portal in the database.For detailed information on configuring startup scripts for the Administration Server, see Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server.
For detailed information and procedures to configure and manage basic JMS system resources, such as JMS servers and JMS system modules, see Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.
This section on creating Managed Server directories includes the following topics:
For more information on Managed Servers, see the WebLogic Server document "Understanding Oracle WebLogic Server Domains" in Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server.
Now that you have configured your domain, including defining your Managed Servers, you need to create a server root directory for each Managed Server. There are many options for this, depending on whether or not the Managed Server will reside on the same machine as the Administration Server and whether or not you will use the Node Manager.
Most of the files in the domain-level directory are not necessary for Managed Servers, so a domain (files directly in the domain directory) is not required on each Managed Server, especially if you are using the Node Manager to start and stop Managed Servers. For example, config.xml in a Managed Server domain is not used. Instead, the config.xml file in the Administration Server is used. The only requirement for Managed Servers is to have the wsrpKeystore.jks file one directory above the server directory (in the equivalent of a domain-level directory). This file is required if you want to use WSRP with SAML security between WebLogic Portal 8.1x and 9.2 or later domains.
If the Managed Server will run on a different machine than the Administration Server and you will not use Node Manager, the easiest option is to use the Configuration Wizard to create a full file system domain for the Managed Server, as described in the following procedure.
Note:
WebLogic Portal must be installed on all Managed Servers.This section lists the basic procedure for creating WebLogic Portal domains on the Managed Servers.
Note:
For more information about Managed Servers, see the WebLogic Server document "Understanding Oracle WebLogic Server Domains" in Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server. See also "Configuring Managed Servers" in Oracle Fusion Middleware Creating Domains Using the Configuration Wizard.Follow the basic steps of starting and using the Configuration Wizard as described in Section 3.3.2, "Creating the Customized Domain."
Tip:
You do not need to be running WebLogic Server to start the Configuration Wizard.In the Select Optional Configuration window, you are give a chance to configure Managed Servers. For detailed information on the Managed Server configuration options, see "Configuring Managed Servers" in Oracle Fusion Middleware Creating Domains Using the Configuration Wizard.
Tip:
For detailed information on configuring startup scripts for Managed Servers, see Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server.Once you have created a domain for a Managed Server, you can reuse the same domain for your other Managed Server on the same machine by specifying different servername parameters to your startManagedWebLogic script, or create new managed domains using the domain Configuration Wizard.
Complete the remaining wizard steps to create the domain, as explained in Section 3.3.2, "Creating the Customized Domain."
Note:
If you decide not to use a full domain for your Managed Servers (that is, not include all files in the domain-level directory), be sure you keep or put a copy of wsrpKeystore.jks in the directory directly above the server directory (in the equivalent of the domain-level directory). This file is required if you want to use WSRP with SAML security between WebLogic Portal 8.1x and 9.2 and later domains.This section includes the following sections:
Tip:
WebLogic Portal supports another method of zero-downtime deployment called production redeployment. Production redeployment is only supported for a limited number of use cases. For detailed information on this option, see Section 4.13, "Using Production Redeployment with WebLogic Portal."One limitation of redeploying a portal application to a WebLogic Server cluster is that during redeployment, users cannot access the site. For Enterprise environments where it is not possible to schedule down time to update a portal application with new portlets and other components, a multi-cluster configuration lets you keep your portal application up and running during redeployment.
The basis for a multi-clustered environment is the notion that you have a secondary cluster to which user requests are routed while you update the portal application in your primary cluster.
For normal operations, all traffic is sent to the primary cluster, as shown in Figure 3-6. Traffic is not sent to the secondary cluster under normal conditions because the two clusters cannot use the same session cache. If traffic was being sent to both clusters and one cluster failed, a user in the middle of a session on the failed cluster would be routed to the other cluster, and the user's session cache would be lost.
Figure 3-6 During Normal Operations, Traffic Is Sent to the Primary Cluster
When the primary cluster is being updated, all traffic is routed to the secondary cluster, then the primary cluster is updated with a new Portal EAR, as shown in Figure 3-7. This EAR has a new portlet, which is loaded into the database. Routing requests to the secondary cluster is a gradual process. Existing requests to the primary cluster must first end over a period of time until no more requests exist. At that point, you can update the primary cluster with the new portal application.
Figure 3-7 Traffic Is Routed to the Secondary Cluster; The Primary Cluster Is Updated
After the primary cluster is updated, all traffic is routed back to the primary cluster, and the secondary cluster is updated with the new EAR, as shown in Figure 3-8. Because the database was updated when the primary cluster was updated, the database is not updated when the secondary cluster is updated.
Figure 3-8 Traffic Is Routed Back to the Primary Cluster; The Secondary Cluster Is Updated
Even though the secondary cluster does not receive traffic under normal conditions, you must still update it with the current portal application. When you next update the portal application, the secondary cluster temporarily receives requests, and the current application must be available.
In summary, to upgrade a multi-clustered portal environment, you switch traffic away from your primary cluster to a secondary one that is pointed at the same portal database instance. You can then update the primary cluster and switch users back from the secondary. This switch can happen instantaneously, so the site experiences no down time. However, in this situation, any existing user sessions will be lost during the switches.
A more advanced scenario is a gradual switchover, where you switch new sessions to the secondary cluster, and after the primary cluster has no existing user sessions you upgrade it. Gradual switchovers can be managed using a variety of specialized hardware and software load balancers. For both scenarios, there are several general concepts that should be understood before deploying applications, including the portal cache and the impact of using a single database instance.
When you configure multiple clusters for your portal application, they will share the same database instance. This database instance stores configuration data for the portal. This can become an issue because when you upgrade the primary cluster it is common to make changes to portal configuration information in the database. These changes are then picked up by the secondary cluster where users are working.
For example, redeploying a portal application with a new portlet to the primary cluster will add that portlet configuration information to the database. This new portlet will in turn be picked up on the secondary cluster. However, the new content (JSP pages or Page Flows) that is referenced by the portlet is not deployed on the secondary cluster.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.Portlets are invoked only when they are part of a desktop, so having them available to the secondary cluster has no immediate effect on the portal that users see. However, adding a new portlet to a desktop with the WebLogic Portal Administration Console will immediately affect the desktop that users see on the secondary cluster. In this case, that portlet would show up, but the contents of the portlet will not be found.
To handle this situation, you have several options:
You can delay adding the portlet to any desktop instances until all users are back on the primary cluster.
You can entitle the portlet in the library so that it will not be viewable by any users on the secondary cluster. Then add the portlet to the desktop, and once all users have been moved back to the primary cluster, remove or modify that entitlement.
Tip:
It is possible to update an existing portlet's content URI to a new location that is not yet deployed. For this reason, exercise caution when updating the content URI of a portlet. The best practice is to update the content URIs as part of a multi-phase update.When running two portal clusters simultaneously against the same database, you must also consider the portal cache, as described in the next section.
WebLogic Portal provides facilities for a sophisticated cluster-aware cache. This cache is used by a number of different portal frameworks to cache everything from markup definitions to portlet preferences. Additionally, developers can define their own caches using the portal cache framework.
For detailed information on setting the portal cache, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
For any cache entry, the cache can be enabled or disabled, a time to live can be set, the cache maximum size can be set, the entire cache can be flushed, or you can invalidate a specific key.
When a portal framework asset that is cached is updated, it will typically write something to the database and automatically invalidate the cache across all machines in the cluster. This process keeps the cache in sync for users on any Managed Server.
When operating a multi-clustered environment for application redeployment, special care needs to be taken with regard to the cache. The cache invalidation mechanism does not span both clusters, so it is possible to make changes on one cluster that is written to the database but not picked up immediately on the other cluster. Because this situation could lead to system instability, it is recommended that during this user migration window the caches be disabled on both clusters. This is important when you have a gradual switchover between clusters versus a hard switch that drops existing user sessions.
|
 Copyright © 2010, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
