Administration Application Guide
|
 |
 |
|
|
 |
 |
This section describes WebLogic Enterprise Security features that support recovery from failure. It covers the following topics:
Figure 2-1 shows how WebLogic Enterprise Security System supports failover, through the use of a redundant component architecture. The Administration Console, external data sources (used by the LDAP providers), and the database server, all support failover through configuration in the Administration Console. To ensure reliable operations, you must consider the ramifications of the failure of each component.
To accommodate your basic needs, you can install two Administration Servers: a primary and a secondary. The number of redundant database servers you configure is totally up to you, although a minimum of two is recommended to maintain reliable services. The secondary Administration Server is only used when the primary becomes unavailable; likewise with the database server.
Figure 2-1 WebLogic Enterprise Security System Failover
The following sections discuss the failover considerations for the various WebLogic Enterprise Security components:
Figure 2-2 shows how failover works when the primary Administration Server fails. One benefit of the WebLogic Enterprise Security architecture is that even if all the Administration Servers go down (either for maintenance or due to failure), including the secondary Administration Servers, there is no impact on the applications in production or on the security services provided by those Security Service Modules and providers that you have configured. As long as you have back up instances of your policy database, external data sources, and back ups of application files, you can safely restart the Administration Server on another machine without interrupting services. However, you cannot install or enroll new Security Service Modules until the primary Administration Server is running or you have reconfigured the secondary server as the primary. You can only enroll Security Service Modules using a primary Administration Server.
For information on how to configure the Administration Server, see your Console Help: Configuring the Administration Server for Failover.
Figure 2-2 Administration Server Failover
Figure 2-3 shows how failover works when the primary Database Server fails. The number of redundant database servers you configure is totally up to you. A minimum of two is recommended to maintain reliable services: a primary database is read/write, while the secondary provides read-only access. The secondary database, created by using the database replication procedures, contains only the data that is needed for the Security Service Modules, rather than a complete set of the configuration and security data. The secondary database is primarily used for failover in Security Service Modules and not the Administration Server.
Because the Database Server contains all of the configuration and security data used by the Administration Application, to protect your applications and resources, you want to make sure it is highly available and reliable. This can be accomplished by implementing recommendations from your database manufacturer (for example, through the use of clustering architecture; hot standby).
Common methods of archiving high availability include periodic back-ups, fault tolerant disks, and copying files manually whenever they are changed. This is also the case for any optional external data sources you have configured. Both Sybase and Oracle offer database backup methods. Refer to Sybase and Oracle documentation for details. The backup can be used for database recovery in the case of disk failure. To provide high availability for the Security Service Modules when using the security providers supplied with the product, you must perform certain database replication procedures as described in the Database Replication in an Oracle Environment and Database Replication in a Sybase Environment.
Failover support through the Administration Console is provided for database-related providers and LDAP authentication providers. Configuration for database related providers includes the specification of the secondary (backup database) and support for LDAP authenticators includes the specification of the secondary LDAP server.
The following providers support configuration of a secondary database:
Note: The ASI Authorization Provider contacts an external process to evaluate its authorization queries. If that process dies, the ASI Authorization provider denies access to all resources. The ASI Authorization provider may contact an external metadirectory database to retrieve subject attributes and group membership for use in authorization and delegation decisions. If the database connection fails, the provider connects to the configured failover replicated metadirectory. The provider tries to reconnect to the failed database after a configurable timeout. If all metadirectory connections fail and the policy evaluation is configured to require user attributes and group membership, all access is denied. For additional information on starting and stopping services, see Starting and Stopping Services.
The following providers support configuration of a secondary LDAP server:
For additional information on how to configure the provider for failover, see Security Configuration or the Console Help for the specific provider.
Note: The NT Authenticator already supports multiple domain controllers. The WebLogic Authenticator, WebLogic Authorizer and WebLogic Role Mapper use the internal LDAP server for WebLogic server as its data store. No support for a redundant source is required.
The Service Control Manager has a mechanism for enrolling with multiple Administration Servers so that configuration can be administered from multiple Administration Consoles. A process manager is used to monitor the status of the Service Control Manager process and, if it stops responding or fails, the process manager restarts the Service Control Manager. The process manager runs as a Windows NT Service or UNIX daemon. This allows the Service Control Manager to be automatically restarted on machine reboots.
Note: If a Service Control Manager fails, all Security Service Modules controlled by the manager continue to run, but any new Security Service Module instances will not be able to start, because they cannot retrieve their configuration. However, a Security Service Module can still enroll with the Administration Server, even if the Service Control Manager fails.
To provide reliability and high availability of Security Service Modules, replication of part of the policy database is necessary. The replicated database objects needed for this replication process include tables and indices that are required by the Security Service Modules. They contain the data that are used by the following providers:
Note: The ASI Authorization and ASI Role Mapper providers are implemented using an out-of-process evaluation engine (the ARME process). If this process fails, access for all resources is denied. This process is monitored and restarted if an error occurs.
Most of the policy database used for security policy and for configuration administration and management is not replicated. The administration and management functions are performed against one and only one database. This means that the components such as the Administration Application, the Policy Distributor, and the Metadirectory Synchronization process are only connected to one database.
Warning: Your administrator needs to ensure that the primary database is backed up regularly using a database backup tool or using a hardware backup strategy to protect the database against fatal systematic errors, should one ever occur.
The steps included in following sections describe how to create a read-only database replica. While some scripts automate this process, to complete the replication, you need to perform certain steps manually. For instructions on how to replicate databases in the Oracle and Sybase environments, see the following sections:
WebLogic Enterprise Security uses the Materialized View (MV) Replication method to replicate the database objects from a master database (also called the master site) to one or more materialized view databases (also called the materialized view sites). In an earlier version of Oracle, such as Oracle 8i, a materialized view replication was called a snapshot replication, and a materialized view site was called a snapshot site. The master database is the database that is administered through the Administration Application. The database schema of the master database is installed and set up during the Administration Application installation. The materialized view database provides failover and availability for the Security Service Modules. You can set up the Security Service Modules at a later time, according to your business needs.
The following sections describe the replication tasks:
Use the following items as a checklist to prepare your replication environment.
Warning: If you are concerned with the database password being used in the scripts, you can run the replication setup manually. All passwords are designated as clear text in the set_repl_env_oracle.sh and set_repl_env_oracle.bat scripts. When you are through, you can either delete the script or remove the password from the script.
Requirements for the master site and the materialized view site include the following:
DB_NAME.DB_DOMAIN. This ensures that the database links can be set up correctly. You can check this by running this SQL statement after logging into the database:select * from global_name;
For detailed information on these parameters, refer to your Oracle Documentation. For Oracle 9i, see Chapter 6: "Planning Your Replication Environment" in Advanced Replication (for Oracle 9.2) or Oracle9i Replication (for Oracle 9.0). For Oracle 8i, see Chapter 7: "Planning Your Replication Environment" of Oracle8i Replication. Also check the Oracle documentation for details on how to set the initialization parameters.
Requirements for the master site include the following:
REPADMIN and PROXY_ADMIN does not already exist in this database. If either one already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create them. You need to set up the master site manually. You can use SQL select * from all_users to check for its existence.WLES user) and login password.TABLESPACE used by the WLES user is large enough to accommodate the extra storage needed by replication.Requirements for the materialized view site include the following:
DB_NAME.DB_DOMAIN.MVADMIN does not already exist in this database. If it already exists, you cannot automate the replication setup using the scripts because the scripts will fail to create it. You need to set up the materialized view site manually.WLES user as in master database does not exist in this database as this user is created. However, you need to locate a TABLESPACE for this WLES user before the setup using the scripts. By default, the temporary TABLESPACE for this user is set to TEMP.On this machine, set up Oracle Local Service Names for the master database and materialized view database, using the same names as their database names, in the form of:
Table 2-2 lists and describes the parameters that you must set before you can set up the replication. You must set these parameters in the setup script:
set_repl_env_oracle.bat(Windows)
set_repl_env_oracle.sh(Unix/Linux)
In addition to the parameters listed in Table 2-2, you need to set ORACLE_HOME, if it is not yet set in your environment, and the __REPL_SETUP_TYPE__ parameter, depending on what kind of replication setup you choose.
Use the following procedures to set up the Oracle database replication using scripts or manually.
Warning: You must set up the master site before replication setup can be performed for a materialized view site.
To use scripts to set up replication, perform the following steps:
WLES_HOME/bin
Save a copy of this file before editing. The parameter __REPL_SETUP_TYPE__ gives you the option to set up either a master site, a materialized site or both.
To set up replication manually, perform the following steps:
Warning: Replication clean up must be performed for all materialized view sites before the master site can be cleaned up.
To use scripts to clean up the replication, perform the following steps:
WLES_HOME/bin
Save a copy of this file before editing it. The parameter __REPL_SETUP_TYPE__ gives you the option to clean up either a master site, a materialized site or both.
To clean up the replication manually, perform the following steps:
To complete the replication of the Oracle database, perform the following steps:
DB_NAME.DB_DOMAIN. If the database name is not in this form, login to the database as DBA and run the following SQL command to change it:alter database rename global_name toDB_NAME.DB_DOMAIN;
db_name: to DB_NAME
db_domain: to DB_DOMAIN
service_name: to DB_NAME.DB_DOMAIN
global_name, update the Oracle listener setting, and then restart the listener. The GLOBAL_NAME is recorded in the Oracle configuration file called listener.ora in the ORACLE_HOME/network/admin/ directory.If you change the local service name that points to this database, you must update it on all applicable client machines. Change the SERVICE_NAME of the CONNECT_DATA to the new service_name in client configuration file tnsnames.ora, usually in the ORACLE_HOME/network/admin/ directory. If your system uses Directory Naming or Oracle Naming methods, update them instead of tnsnames.ora. Refer to your Oracle documentation for details.
WebLogic Enterprise Security uses the Sybase ASE Replicator to replicate the database objects from a primary database in primary Adaptive (ASE) server to one or more replicate databases in the replicate ASE servers. The ASE Replicator process is an external application that connects to and interacts with the ASE server, and coordinates all replication processing. The policy in the primary database is administered though the Administration Server. The database schema in the primary database is installed and set up during the Administration Application installation. The replicate databases provide failover and availability for the WebLogic Enterprise Security Security Service Modules. They can be set up according to your business needs at a later time. For more information, see the ASE Replicator User's Guide from Sybase.
The following sections describe the replication tasks:
The following sections provide checklists so you can prepare your replication environment:
Warning: If you are concerned with the database password being used in the scripts, BEA recommends that you run the replication setup manually. All passwords are designated in clear text in the set_repl_env_sybase.sh and set_repl_env_sybase.bat scripts. When you are through, you can either delete the script or remove the password from the script.
Make sure you are able to login to the servers as DBA (sa) and you have the privilege to restart the servers.
The primary ASE server and primary database requirements are as follows:
WLES user) and login password.disk init and create database isql commands, or use another GUI tool to set these up. Also, while this database is dropped when running the replication cleanup scripts, the database devices are not. See the Administration Application Installation Guide for instructions on how to set up the database.The replicate ASE server and replicate database requirements are as follows:
select @@maxpagesize to check them out.The requirements for the machine used to run the Sybase database replication setup Scripts are as follows:
Note: If you use the primary ASE server machine to run the Sybase database replication setup scripts, you do not have to do anything and you can skip this section.
Table 2-3 lists the initialization parameters you need to set before you set up the replication. You set these parameters in:
You also need to set SYBASE if it is not yet set in your environment. In addition, you need to set __REPL_SETUP_TYPE__ depending on what kind of replication setup you choose.
You also need to know the values for __SIZE_IDXCOL__ and __SIZE_COL__ when you set up a replication manually. The value for these two can be found in the policy database in the primary ASE server using SQL statement:
select__SIZE_IDXCOL__ = idx_column_size, __SIZE_COL__ = reg_column_sizefrom__DBUSER_WLES__column_sizes
Note: __DBUSER_WLES__ is substituted with the value described.
Use the following procedures to set up the Sybase database replication using scripts or manually.
Warning: The Primary ASE server and database must be set up and ASE Replicator started before you can perform replication setup on a replicate database.
To use scripts to set up Sybase database replication, perform these steps:
WLES_HOME/bin
Save a copy of this file before editing it. The parameter __REPL_SETUP_TYPE__ allows you to set up either a primary, replicate database, or both.
To set up Sybase database replication manually, perform these steps:
Login to the primary ASE server as sa (DBA) and execute: rep_pdb_conf.sql. You can do this statement-by-statement. You also need to restart the primary ASE server manually, after running this script. This SQL file performs the following tasks.
To start the ASE replication, perform these steps:
Note: You can restart the ASE Replicator by running either: aserep.bat or aserep.sh using the same command options, or by running the RUN script that is located under SYBASE/RPL-12_5/replicatorName and providing the -u and -p options.
To add a remote server in the primary ASE server for the replicate ASE server, perform these steps:
Login to the replicate ASE server as sa (DBA) and execute: rep_rdb_conf.sql. You can do this statement-by-statement. Before starting, make sure the replicate policy database already exists. This SQL file performs the following tasks.
Login to primary ASE server as ASE Replicator system user login and execute: rep_replication.sql. You can do this statement-by-statement. Before starting, make sure the ASE Replicator is running. This SQL file performs the following tasks:
Use the following procedures to automate replication cleanup or to do it manually. Replication cleanup also stops the ASE Replicator and drops the distribution database in the primary ASE server. If you experience a failure while using the scripts to clean up replication, you are advised to finish the cleanup manually.
Before attempting cleanup, make sure that there is no database connection for WLES user login to the replicate ASE server and for ASE Replicator system user login to both replicate and primary ASE servers. If there are connections, cleanup will fail. You can use sp_help loginName to check whether the user still has connections.
Warning: You must perform the replication clean up for all replicate databases before the primary database can be cleaned up and the ASE Replicator removed.
To use scripts to clean up Sybase database replication, perform these steps:
WLES user login to the replicate ASE server, and for ASE Replicator system user login to both the replicate and primary ASE servers.WLES_HOME/bin
Set the environment and input parameters in the following file:
Save a copy of this file before editing it. The parameter __REPL_SETUP_TYPE__ gives you the option to clean up either a primary database and ASE server, a replicate database and ASE server, or both.
To clean up Sybase database replication manually, perform these steps:
WLES_HOME/data/sybase/ directory, locate the following SQL files and save a copy of each one:Login to the primary ASE server as the ASE Replicator system user login and execute: rep_clean_replication.sql. You can do this statement-by-statement. This SQL file performs the following tasks:
Login to replicate ASE server as sa (DBA) and execute: rep_clean_rdb.sql. You can do this statement-by-statement. This SQL file performs the following tasks:
In the Primary ASE Server for the Replicate ASE Server, follow these steps to remove the remote server:
To stop the ASE Replicator, perform these steps:
Note: Alternatively, shutdown ASE Replicator manually.
Login to primary ASE server as sa (DBA) and execute: rep_clean_pdb.sql. You can do this statement-by-statement. This SQL file performs the following tasks.
To complete replication cleanup, remove the ASE Replicator process by deleting all of the files under RPL-12_5/replicatorName in your Sybase installation directory.
|
|
|