InfoCenter Home > 6.6.46: Administering WebSphere administrative servers (overview)The administrative server manages configurations and states of application servers, applications, and other resources in the WebSphere administrative domain. It keeps its administrative data in a database that you define during product installation.
Configuring the administrative server and databaseThere are a couple of ways to configure the administrative server, and provide information about its administrative database. Administrative configuration fileThe administrative server obtains its own configuration from the properties in the administrative configuration file. Some values are set during product installation, while others are primarily for modification later. New properties added for 4.0.x and later Three new properties have been added to WebSphere Application Server, including:
The com.ibm.ejs.sm.adminServer.asyncTaskThreadPoolSize=<integer_value> property allows you to control the number of threads in the Asyncronous Task Engine thread pool. The default value is 5. One aspect of tuning this thread pool size is that it affects the number of application servers that can be started at one time. You should be conservative in setting this property because it uses a lot of memory. The com.ibm.ejs.sm.adminService.verboseLogging=1 property causes the administrative service to produce additional entries in the Windows Application Event log when the value is set to non-zero. The com.ibm.ejs.adminService.waitForTimeOut=<number_of_seconds> property sets the number of seconds that the administrative service waits for the administrative server to tell it that all application servers have completed their startup. The default value is zero, which means that the administrative services do not time out. The former default timeout value for the administrative service is 8 minutes. This is only true on Windows platforms. Using SQL Server as the administrative repositoryTo use SQL Server as the WebSphere Application Server administrative repository, ensure that you have the WebSphere Application Server database in your SQL Server. To create the Enterprise Manager in SQL server, complete the following steps:
Adding Java command line arguments for the administrative serverThe admin.config file contains many administrative server properties you can set. In addition, you might want to pass the administrative server some generic Java command line arguments. In the admin.config file, add the properties and their values as arguments on the com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs property. Add them using standard Java command line syntax: -D property_name=property_value For example, this setting passes performance-related Java parameters to the Java process constituting the administrative server: com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=-ms32m -mx128m The admin.config file contains both default properties that apply to most configurations and non-default properties. You should be conservative when setting this value. In testing on a desktop workstation, memory depletion or Java virtual machine crashes were observed when the thread pool size was set to 10. Creating the database tables and default configurationIn most cases (see below for special cases), the administrative database tables are created, and populated with a default configuration, when you install WebSphere Application Server. During product installation, you must provide information regarding the administrative database you would like the installation's administrative server to use. Settings in the administrative configuration file record the database information, and determine whether the database tables are created and (or) populated with the default configuration. Special cases requiring additional steps after product installationIn some cases, the database tables are not created automatically during product installation, or the tables are not populated with the default configuration. If you need to, trigger the actions manually by setting properties in the administrative configuration file and starting the administrative server again.
install.initial.config=truein the administrative configuration file and start the administrative again.
Ensure that the user ID and schema lines reflect your actual database user ID and password: com.ibm.ejs.sm.adminServer.dbuser=your_user_name com.ibm.ejs.sm.adminServer.dbSchema=your_schema_name Then start the administrative server.
Edit the product_installation/bin/admin.config file to point to the Sybase 12.5 driver instead of the Sybase 12.0 driver. Change the setting from: com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=<sybase_home>/jConnect-5_2/classes/jconn2.jarTo: com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs=<sybase_home>/jConnect-5_5/classes/jconn2.jar Edit the DBDRIVER_JARS property in the product_installation/bin/setupcmdline command shell. Change the setting from: DBDRIVER_JARS=<sybase_home>/jConnect-5_2/classes/jconn2.jarTo: DBDRIVER_JARS=<sybase_home>/jConnect-5_5/classes/jconn2.jar Then start the administrative server. Establishing centralized administrationMultiple administrative servers can be configured to use the same administrative database, allowing configuration data to be kept in a centralized place for administration of WebSphere Application Server across multiple machines (known as administrative nodes). In a successful multiple node configuration, the administrative console tree view will show each of the administrative nodes and its contents. Configuring the 2nd through Nth machine in a clusterDo not create the database tables or populate them with the default configuration. When you are setting up a cluster of administrative nodes, only the WebSphere application server product installation needs to install the default configuration:
If you have already installed the second (or later) machine, with install.initial.config set to true, then the problem should work itself out after all machines in the cluster have been shut down and started again. Until then, you might notice these problems:
Configuring a remote DB2 database as the administrative database
Setting the dbserverName and dbportNumber for the data source (flags in the administrative configuration file) is not working in the case of a remote DB2 database. For example, if you have the application server and the DB2 client is installed on one machine, and are trying to connect the client to the DB2 server on another machine. This problem could be overcome in a subsequent WebSphere Application Server fix. Be sure to consult the release notes for each fix to see whether the problem is fixed. What to do if you must drop the administrative database tablesIf you must drop the tables in the administrative database for some reason, then reset the pertinent settings in the administrative configuration file to create the tables again. You will always need to set: com.ibm.ejs.adminServer.createTables=true If the machine is the first machine in a cluster of machines sharing an administrative database, then populate it with the default configuration: install.initial.config=true When you start the administrative server again, the settings will be applied. Miscellaneous topicsThe remainder of this article discusses miscellaneous topics pertaining to the administrative server and database. Backup copies of admin.configNote, commented out lines in admin.config will be removed completely when the administrative server starts. It is recommended you periodically save a backup copy of admin.config. For example, you might delete lines that you want to restore later. Configuring the nanny processOn UNIX-based systems, the nanny process tries to start an administrative server when the administrative server fails. The nanny settings are available in the admin.config file for the administrative server that the nanny is tending. |
| ||
|