WebSphere Application Server Concepts for Sametime Users

October 7, 2017 | Author: Chris Sparsott | Category: Computer Cluster, Web Server, Databases, Command Line Interface, Information Technology
Share Embed Donate


Short Description

WebSphere Application Server Concepts for Sametime Users...

Description

Lotus

®

Version 1

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators



Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators This document covers several WebSphere® Application Server concepts that come into play when administering IBM® Lotus® Sametime®, such as terminology, common commands, and the servers involved in a WebSphere Application Server deployment.

Time required It should take approximately 80 minutes to complete this content.

Prerequisites and system requirements There are no prerequisites or system requirements for this content. No prior WebSphere Application Server knowledge is required.

Learning topics The following learning topics are covered: v Define terminology related to WebSphere Application Server architecture. v Describe the function of a WebSphere Application Server Profile. v Define WebSphere Application Server terminology related to Lotus Sametime topologies. v Describe the key WebSphere Application Server profiles related to Lotus Sametime. v Define which types of server components are installed in relation to other WebSphere Application Server components. v Discuss the WebSphere Application Server setting inheritance model, also known as resource scope. v Start and stop WebSphere Application Servers using several methods. Log on to the WebSphere Application Server administrative console. Check the status of the server using the serverStatus command. Describe the servers that comprise a WebSphere Application Server environment. Describe the function of the WebSphere Application Server's Deployment Manager. Define WebSphere Application Server types in the context of Sametime. Explain the function of Deployment Manager and Integrated Solutions Console in the context of Sametime. v Troubleshoot issues with accessing Sametime System Console. v Use WASServiceCmd utility to set up Sametime servers to load as Windows services v v v v v v

Agenda Read through each of the sections in the order that they are listed in the following table: Title

Approximate Timing (in minutes)

“IBM WebSphere Application Server Terminology” on page 2

30

“Common WebSphere Application Server commands” on page 19

30

“WebSphere Application Server types in the context of Lotus Sametime” on page 23

20

Total:

80

1

IBM WebSphere Application Server Terminology In this document you will learn about IBM WebSphere Application Server terminology and how it is used in an IBM Lotus Sametime environment.

Time needed It will take approximately 30 minutes to complete this content.

Objectives After reading this document, you should be able to: v Define terminology related to WebSphere Application Server architecture. v Describe the function of a WebSphere Application Server Profile. v Define WebSphere Application Server terminology related to Lotus Sametime topologies. v Describe the key WebSphere Application Server profiles related to Lotus Sametime. v Define which types of server components are installed in relation to other WebSphere Application Server components. v Discuss the WebSphere Application Server setting inheritance model, also known as resource scope.

The ABC's of IBM WebSphere Application Server In this section, you will learn about commonly used WebSphere Application Server architectural terms. The following diagram shows one possible architecture of a WebSphere Application Server environment:

2

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

Below, you will find definitions for each of the terms shown in the graphic above. Application Server According to the WebSphere Application Server Glossary, an application server is "a server program in a distributed network that provides the execution environment for an application program." More specifically: The application server is the primary runtime component in all configurations and is where an application actually executes. All WebSphere Application Server configurations can have one or more application servers. ... With Network Deployment, you can build a distributed server environment consisting of multiple application servers maintained from a central administration point. In a distributed server environment, you can cluster application servers for workload distribution. Source: WebSphere Application Server V6 Technical Overview Cell Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

3

The WebSphere Application Server Glossary defines a cell as: "A group of managed processes that are federated to the same deployment manager and can include high-availability core groups." The IBM Redbooks® publication WebSphere Application Server V7: Concepts, Planning, and design provides the following, more detailed, explanation: A cell is a grouping of nodes into a single administrative domain. ... In a Network Deployment environment, a cell can consist of multiple nodes (and node groups), which are all administered from a single point, the deployment manager. If your cell configuration contains nodes running on the same platform, it is called a homogeneous cell. It is also possible to have a cell made up of nodes on mixed platforms. This is referred to as a heterogeneous cell. Cluster A cluster is defined as "a group of application servers that collaborate for the purposes of workload balancing and failover" in the WebSphere Application Server Glossary. In other words: ... A cluster is a logical collection of application server processes that provides workload balancing and high availability. Application servers that belong to a cluster are members of that cluster and must all have identical application components deployed on them. Other than the applications configured to run on them, cluster members do not have to share any other configuration data. For example, one cluster member might be running on a large multi-processor server while another member of that same cluster might be running on a small mobile computer. The server configuration settings for each of these two cluster members is very different, except in the area of the application components that are assigned to them. In that area of configuration, they are identical. The members of a cluster can be located on a single node (vertical cluster), across multiple nodes (horizontal cluster), or on a combination of the two. When you install, update, or delete an application, the updates are automatically distributed to all members in the cluster. Source: WebSphere Application Server V6 Technical Overview Deployment Manager A Deployment Manager is "a server that manages operations for a logical group or cell of other servers," as stated in the WebSphere Application Server Glossary. A more detailed explanation is that the deployment manager is: ... the central administration point of a cell that consists of multiple nodes and node groups in a distributed server configuration. ... The deployment manager uses the node agent to manage the application servers within one node. A deployment manager provides management capability for multiple federated nodes and can manage nodes that span multiple systems and platforms. A node can only be managed by a single deployment manager and must be federated to the cell of that deployment manager. The configuration and application files for all nodes in the cell are centralized into a master configuration repository. This centralized repository is managed by the deployment manager and synchronized with local copies that are held on each of the nodes. Source: WebSphere Application Server V7: Concepts, Planning, and design Node As defined in the WebSphere Application Server Glossary, a node is "a logical grouping of managed servers." In particular:

4

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

A node is an administrative grouping of application servers for configuration and operational management within one operating system instance (virtualization allows multiple operating systems on one machine). It is possible to create multiple nodes inside one operating system instance, but a node cannot leave the operating system boundaries. In a stand-alone application server configuration, there is only one node. With Network Deployment, you can configure a distributed server environment consisting of multiple nodes, which are managed from one central administration server. Source: WebSphere Application Server V7: Concepts, Planning, and design Node Agent A Node Agent is "an administrative agent that manages all application servers on a node and represents the node in the management cell" according to the WebSphere Application Server Glossary In addition: In distributed server configurations, each node has a node agent that works with the deployment manager to manage administration processes... A node agent is created automatically when you add (federate) a stand-alone node to a cell. It is not included in the Base and Express® configurations. Source: WebSphere Application Server V7: Concepts, Planning, and design In simpler terms, the node agent's purpose is to pass information between the deployment manager and the application server. Profile A profile is "an instance of a WebSphere Application Server configuration." More specifically: Profiles are collections of user files. They share core product files. A profile contains its own set of scripts, its own environment, and its own repository. Each profile is stored in a unique directory path selected by the user at profile creation time. Profiles are stored in a subdirectory of the installation directory by default, but they can be located anywhere. WebSphere Profiles were introduced in WebSphere Application Server v6.0. One main advantage of profiles is that they allow an administrator to have multiple application servers on a single machine that all use the same binaries from one install of WebSphere Application Server. Administration is greatly enhanced when using profiles instead of multiple product installations. Not only is disk space saved, but updating the product is simplified when you maintain a single set of product core files. Also, creating new profiles is more efficient and less prone to error than full product installations, allowing a developer to create separate profiles of the product for development and testing. Templates for several types of profiles are provided with WebSphere Application Server Network Deployment: v Cell – This environment creates two profiles: - A management profile with a deployment manager - An application server profile added (federated) to the management profile v Management – A management profile provides components for managing multiple application server environments. Possible profiles are as follows: - Deployment manager Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

5

- Administrative agent - Job manager v Application server – An application server profile runs your enterprise applications and makes them available to the internet or to an intranet. It contains a stand-alone application server. v Custom – A custom profile contains an empty node with no servers. However, a server can be added after the profile is created. v Secure proxy (configuration-only) – A secure proxy (configuration-only) profile is for use with a DeMilitarized Zone (DMZ) secure proxy server. This configuration-only profile is intended only to be used to configure the profile using the Integrated Solutions Console. After you configure the profile, you can export the profile configuration and then import it into the secure proxy profile in your DMZ. Secure proxy (configuration-only) profile is only an administrative component. Source: WebSphere Application Server V7: Concepts, Planning, and design For more information on profiles, watch the IBM Education Assistant module WebSphere Profiles The following screen capture shows where profiles, cells, nodes, and servers are found in a simple WebSphere Application Server deployment with no Lotus products installed:

Note: The colors of the boxes correspond to the color scheme of the first graphic.

6

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

The following screen capture shows where profiles, cells, nodes, and servers are found in a WebSphere Application Server deployment, with no Lotus products installed, that uses a Deployment Manager:

Note: The colors of the boxes correspond to the color scheme of the first graphic.

WebSphere Application Server terminology in the context of Lotus Sametime In this part you will learn how the WebSphere Application Server components that you learned about in the previous part come into play with the Lotus Sametime System Console, Lotus Sametime Meeting Server, Lotus Sametime Proxy Server, and the Sametime Media Manager. You will explore the following configurations of Lotus Sametime: v Standalone environment (installed using the Cell Profile option) v Vertical Cluster v Horizontal Cluster

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

7

The following graphics show how profiles, cells, nodes, and servers are used in a WebSphere Application Server configuration with Lotus Sametime installed: In the first graphic, Lotus Sametime is installed using the Cell Profile option with all servers installed on the same machine. When you select the Cell Profile option during the configuration of Lotus Sametime, two profiles are created in each cell: a Deployment Manager profile, DMProfile and a federated Application Server profile, PNProfile. In this configuration, the Application Server is federated to the cell of the Deployment Manager.

8

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

9

In the second graphic, Lotus Sametime is installed using the Network Deployment option with horizontal clustering configured. Horizontal clustering is the most commonly used clustering topology for Lotus Sametime configurations. As described in the Lotus Sametime Information Center topic Clustering Sametime servers for high enterprise availability, "A horizontal cluster contains multiple physical machines (or nodes), each with one type of Sametime server. A horizontal cluster distributes the load across servers on multiple machines as needed. The advantage of a horizontal cluster is that users can still use the Sametime application even if one machine in the cluster fails." Although this graphic shows the Lotus Sametime System Console as the deployment manager, the clustering guided activity can use any deployment manager visible to the Lotus Sametime System Console within its own product, ie: A Lotus Sametime Meetings server can only use a deployment manager that has been installed for a Lotus Sametime Meetings server. Using the Lotus Sametime System Console as the deployment manager is the configuration recommended by IBM Lotus Development.

10

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

11

In the third image, Lotus Sametime is installed using the Network Deployment option with vertical clustering configured. The Lotus Sametime Information Center topic Clustering Sametime servers for high enterprise availability defines a vertical cluster as follows: v A vertical cluster contains multiple instances of one type of Sametime server hosted on the same physical machine (or node). v A vertical cluster distributes the load as appropriate across servers. Machine maintenance in a vertical cluster is easier and more convenient because everything is on one machine. As is the case with horizontal clustering, although this graphic shows the Lotus Sametime System Console as the deployment manager, the clustering guided activity can use any deployment manager visible to the Lotus Sametime System Console within its own product, ie: A Lotus Sametime Meetings server can only use a deployment manager that has been installed for a Lotus Sametime Meetings server. Using the Lotus Sametime System Console as the deployment manager is the configuration recommended by IBM Lotus Development.

12

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

WebSphere Application Server Profiles in Lotus Sametime As described previously in this document, a profile is "an instance of a WebSphere Application Server configuration." Each Lotus Sametime server installation uses several WebSphere Application Server profiles, as shown in the following table:

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

13

Table 1. Profiles used by Lotus Sametime servers Lotus Sametime Server

WebSphere Application Server profiles

Lotus Sametime System Console

v STSCAppProfile v STSCDMgrProfile

Lotus Sametime Meeting Server

v serverNameMediaDMProfile v serverNameMediaPNProfile

Lotus Sametime Proxy Server

v serverNameMeetingDMProfile v serverNameMeetingPNProfile

Lotus Sametime Media Manager

v serverNameProxyDMProfile v serverNameProxyPNProfile

The following graphic shows where these profiles are found at the Operating System level for a Cell Profile configuration:

Keep the location of these profiles in mind when examining log and configuration files. The files associated with the server that you are troubleshooting will be located under the profile for that server. For example, if you are troubleshooting an issue with the Lotus Sametime System Console, then you would look for the log and configuration files under the profile for the Lotus Sametime System Console deployment manager profile. On a Microsoft Windows machine using the default installation directories, the log files for the Lotus Sametime System console are located in the C:\Program Files\IBM\WebSphere\ AppServer\profiles\STSCDMgrProfile\logs\dmgr directory, as shown in the following screen capture:

14

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

Keep the same thoughts in mind when troubleshooting the configuration files for a particular server. For example, if you are trying to solve a problem with the Lotus Sametime System Console, the only place that you should need to make a change to a configuration file is in the Lotus Sametime System Console deployment manager profile. The security.xml file is located in the C:\Program Files\IBM\WebSphere\ AppServer\profiles\STSCDMgrProfile\config\cells\ directory on a Microsoft Windows machine using the default installation directories, as shown in the following screen capture:

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

15

The wimconfig.xml file is located in the C:\Program Files\IBM\WebSphere\AppServer\profiles\ STSCDMgrProfile\config\cells\\wim\config directory on a Microsoft Windows machine using the default installation directories, as shown in the following screen capture:

The Websphere Application Server components, such as clusters, nodes, and cells need to be taken into account when configuring resources for Lotus Sametime. Certain settings can be configured at multiple

16

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

levels, or scopes, using the Lotus Sametime System Console. This concept is referred to as resource scope. The IBM Redbooks Publication WebSphere Application Server V7: Concepts, Planning, and design describes resource scope as follows: Resource scope is a powerful concept to prevent duplication of resources across lower-level scopes. For example, if a data source can be used by multiple servers in a node, it makes sense to define that data source once at the node level, rather than create the data source multiple times, possibly introducing errors along the way. Also, if the data source definition needs to change (maybe due to changes to an underlying database), the data source definition can be changed once and is visible to all servers within the node. The savings in time and cost should be self-evident. Some thought needs to be put toward outlining what resources you will need for all the applications to be deployed and at what scope to define each. You select the scope of a resource when you create it. The following list describes the scope levels, listed in order of granularity with the most general scope first: Cell scope The cell scope is the most general scope and does not override any other scope. [It is] recommended that cell scope resource definitions should be further granularized at a more specific scope level. When you define a resource at a more specific scope, you provide greater isolation for the resource. When you define a resource at a more general scope, you provide less isolation. Greater exposure to cross-application conflicts occur for a resource that you define at a more general scope. The cell scope value limits the visibility of all servers to the named cell. The resource factories within the cell scope are defined for all servers within this cell and are overridden by any resource factories that are defined within application, server, cluster, and node scopes that are in this cell and have the same Java Naming and Directory Interface (JNDI) name. The resource providers that are required by the resource factories must be installed on every node within the cell before applications can bind or use them. Cluster scope The cluster scope value limits the visibility to all the servers on the named cluster. The resource factories that are defined within the cluster scope are available for all the members of this cluster to use and override any resource factories that have the same JNDI name that is defined within the cell scope. The resource factories that are defined within the cell scope are available for this cluster to use, in addition to the resource factories that are defined within this cluster scope. Node scope (default) The node scope value limits the visibility to all the servers on the named node. This is the default scope for most resource types. The resource factories that are defined within the node scope are available for servers on this node to use and override any resource factories that have the same JNDI name defined within the cell scope. The resource factories that are defined within the cell scope are available for servers on this node to use, in addition to the resource factories that are defined within this node scope. Server scope The server scope value limits the visibility to the named server. This is the most specific scope for defining resources. The resource factories that are defined within the server scope are available for applications that are deployed on this server and override any resource factories that have the same JNDI name defined within the node and cell scopes. The resource factories that are defined within the node and cell scopes are available for this server to use, in addition to the resource factories that are defined within this server scope. Application scope The application scope value limits the visibility to the named application. Application scope resources cannot be configured from the Integrated Solutions Console. Use Rational Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

17

Application Developer Assembly and Deploy V7.5, or the wsadmin tool to view or modify the application scope resource configuration. The resource factories that are defined within the application scope are available for this application to use only. The application scope overrides all other scopes. You can define resources at multiple scopes but the definition at the most specific scope is used. When selecting a scope, the following rules apply: v The application scope has precedence over all the scopes. v The server scope has precedence over the node, cell, and cluster scopes. v The cluster scope has precedence over the node and cell scopes. v The node scope has precedence over the cell scope. When viewing resources, you can select the scope to narrow the list to just the resources defined at the scope. Alternatively, you can select to view resources for all scopes. Resources are always created at the currently selected scope. Resources created at a given scope might be visible to lower scopes. For example, a data source created at a node level might be visible to servers within the node. Be sure to keep this precedence structure in mind when configuring Lotus Sametime. Here is a screen capture of one place where you will see resources configurable by scope:

For more information, consult the IBM Redbooks Publication WebSphere Application Server V7 Administration and Configuration Guide , Chapter 5.1.5.

18

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

Common WebSphere Application Server commands In this section, you will learn about common server commands used when administering Lotus Sametime.

Time needed It will take approximately 30 minutes to complete this section.

Objectives After reading this section, you should be able to: v Start and stop WebSphere Application Servers using several methods. v Log on to the WebSphere Application Server administrative console. v Check the status of the server using the serverStatus command.

Starting and stopping WebSphere Application Server There are several ways to start and stop WebSphere Application Server: v From a command line v From the WebSphere Application Server administrative console v If you are using Microsoft® Windows®, from the Microsoft Windows Start Menu v If you are using Microsoft Windows, by starting the Microsoft Windows Service if the application server is registered as a service Be sure to always start the servers in the correct order: 1. Deployment Manager 2. Node Agent 3. Application Server Note: When stopping servers, the order does not matter if all will be shut down. However, as a best practice, shut down the servers in the reverse of the order listed above.

Starting and stopping an application server using the command line Use the following steps to start a server from a command line:

Procedure 1. If WebSphere Application Server Network Deployment is installed, you must first start the deployment manager. To start the deployment manager, navigate to the bin directory under the deployment manager profile from a command line. For example, C:\Program Files\IBM\WebSphere\ AppServer\profiles\MyDMgrProfile\bin 2. On Microsoft Windows systems, enter the command startManager.bat. On AIX®, Linux®, or Solaris systems, the command is startManager.sh. 3. Next, start the node agent. Navigate to the bin directory under the profile for the server. For example, C:\Program Files\IBM\WebSphere\AppServer\profiles\MyAppSvrProfile\bin. 4. On Microsoft Windows systems, enter the command startNode.bat. On AIX, Linux, or Solaris systems, the command is startNode.sh. 5. After the node agent successfully starts, enter the command startServer.bat where is the name of the application server. For example, startServer.bat MyAppSvr. Note: On AIX, Linux, or Solaris systems, the command is startServer.sh Attention: The name of the server is case sensitive, even for servers running on Microsoft Windows. Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

19

The results returned will resemble the following screen capture:

Note: Although this screen capture was taken from a Microsoft Windows system, the output will be similar on other operating systems. 6. To stop the application server, enter the command stopServer.bat where is the name of the application server. You can append the -username and -password parameters to the command or you will be prompted to enter the credentials for your WebSphere Application Server administrator. Note: On AIX, Linux, or Solaris systems, the command is stopServer.sh. 7. To stop the node, enter the command stopNode.bat. You can append the -username and -password parameters to the command or you will be prompted to enter the credentials for your WebSphere Application Server administrator. Note: On AIX, Linux, or Solaris systems, the command is stopNode.sh. 8. To stop the deployment manager, navigate to the bin directory under the deployment manager profile. Enter the command stopManager.bat. You can use the -username and -password parameters or you will be prompted to enter the credentials for your WebSphere Application Server administrator. Note: On AIX, Linux, or Solaris systems, the command is stopManager.sh

What to do next Note: When you start the servers you do not need to enter the WebSphere Application Server administrator credentials. It is only when you stop the servers, or check the server status, that the credentials are needed.

Starting a server using the Microsoft Windows Start Menu On a Windows machine, you can start an application server using the Start Menu.

Procedure 1. First, start the deployment manager by clicking Start → All Programs → IBM WebSphere → Application Server Network Deployment V7.0 (or the folder corresponding to your WebSphere Application Server install) → Profiles → (such as MyDmgrProfile) → Start the Deployment Manager

20

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

2. After the deployment manager starts, start the node agent by opening a command prompt and navigating to the bin directory under the profile for the application server. For example, C:\Program Files\IBM\WebSphere\AppServer\profiles\MyAppSvrProfile\bin. 3. Enter the command startNode.bat. Note: On AIX, Linux, or Solaris systems, the command is startNode.sh. 4. Next, start the application server by clicking Start → All Programs → IBM WebSphere → Application Server Network Deployment V7.0 (or the folder corresponding to your WebSphere Application Server install) → Profiles → (such as MyAppSvrProfile) → (such as MyAppSvrProfile) → Start the server.

Starting a server using the Windows Service Procedure 1. All servers must be registered as Windows Services for the following steps to work. Open the Windows Services utility by clicking Start → All Programs → Administrative Tools → Services. Depending on your Operating System, the sequence to open the Windows Services utility may differ. 2. First, start the service corresponding to the deployment manager. 3. Next, start the service corresponding to the node agent for the server. 4. Last, start the service corresponding to the application server.

Starting a server using the IBM Integrated Solutions Console Procedure 1. Start the administrative console server if it is not already running. Tip: You will learn how to check the status of a server in the next part. 2. Launch the administrative console in a Web browser. Tip: You will learn how to launch the administrative console in the last part. 3. In the administrative console, navigate to Servers > Server Types > WebSphere application servers. 4. Click the check box next to the server that you want to start, and then click the Start button.

Checking the status of a server At times, you may need to check the status of a particular server. You can use the serverStatus command to list the status of one or all servers of the servers configured in a node.

Procedure 1. Navigate to the bin directory under the profile for the server. For example, C:\Program Files\IBM\WebSphere\AppServer\profiles\MyAppSvrProfile\bin 2. To view the status of all of the servers in the configuration, enter the command serverStatus.bat -all. To view the status of a particular server in the configuration, enter the command serverStatus.bat - where is the server. Note: On AIX, Linux, or Solaris systems, the command is serverStatus.sh. Tip: You can append the -username and -password parameters to the command. For example: serverStatus.bat -all -username wasadmin -password waspassword. Otherwise, you will be prompted to enter the credentials for your WebSphere Application Server administrator. The status of the specified server(s) will be displayed on the command line.

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

21

3. Alternately, you can check the server status using the WebSphere Application Server administrative console. Launch the administrative console and navigate to Servers → Server Types → WebSphere application server. The status of each of the application servers in the configuration are displayed in the status column. The following screen capture shows the results of running the serverStatus command from both the Deployment Manager profile and the Sametime System System Console Server profile:

Note: Although this screen capture was taken from a Microsoft Windows system, the output will be similar on other operating systems.

Logging on to the IBM Integrated Solutions Console The IBM Integrated Solutions Console (ISC) is a Web-based tool that is used to administer a WebSphere Application Server environment. Before accessing the IBM Integrated Solutions Console through the Web browser, you must first start the server that is hosting the console. In a stand-alone environment, the console is hosted on the application server. Therefore, you need to start the application server before attempting to access the console. In a distributed environment, available with the use of the IBM WebSphere Application Server Network Deployment, the console is hosted on the deployment manager server, which must be started before accessing the console. Use the following URL to access the WebSphere Administrative Console: http://:/ibm/ console where WC_adminhost is the admin port. If you are not sure of the admin port, locate the portdef.props file in the properties directory under the profile for the server hosting the admin console. For example, C:\Program Files\IBM\WebSphere\ AppServer\profiles\MyDMgrProfile\properties. In the portdef.props file, WC_adminhost is the default admin port and WC_adminhost_secure is the secure port used if administrative security enabled. Note: If you use the default port and administrative security is enabled for the server, you will automatically be redirected to the secure port.

22

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

WebSphere Application Server types in the context of Lotus Sametime In this section you will learn about the servers that comprise a WebSphere Application Server environment and where the Lotus Sametime servers/components fit into the WebSphere Application Server structure.

Time needed It will take approximately 30 minutes to complete this section.

Objectives After reading this section, you will be able to: v Describe the servers that comprise a WebSphere Application Server environment v Describe the function of the WebSphere Application Server's Deployment Manager v Define WebSphere Application Server types in the context of Sametime v Describe the function of the Deployment Manager and the Integrated Solutions Console in the context of Sametime v Troubleshoot issues with accessing Sametime System Console v Use WASServiceCmd utility to set up Sametime servers to load as Windows Services

Server types in a WebSphere Application Server environment System requirements for IBM WebSphere Application Server, such as supported Database servers, Directory servers, and Web servers, are found in: IBM WebSphere Application Server Detailed Requirements and in WebSphere Application Server V7: Concepts, Planning, and design. This part briefly explains the function of some of the server types that are used/required in a WebSphere Application Server deployment. The graphic below represents the servers to be defined. Skip ahead to the next part if you already know the function of these servers and want to see how they are used in a Lotus Sametime deployment.

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

23

Application Server The first section of this document defined an application server as follows: The application server is the primary runtime component in all configurations and is where an application actually executes. All WebSphere Application Server configurations can have one or more application servers. ... With Network Deployment, you can build a distributed server environment consisting of multiple application servers maintained from a central administration point. In a distributed server environment, you can cluster application servers for workload distribution. Source: WebSphere Application Server V6 Technical Overview Web Server The function of the Web/HTTP server in the WebSphere Application Server environment is explained in theWebSphere Application Server V7: Concepts, Planning, and design as follows: WebSphere Application Server can work with a Web server (like the IBM HTTP Server included in WebSphere Application Server) to route requests from browsers to the applications that run in WebSphere Application Server. A WebSphere Web Server Plug-in is

24

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

provided for installation with supported Web servers. This plug-in directs requests to the appropriate application server and performs workload balancing and fail-over among servers in a cluster. Although Web servers are products that are separate from WebSphere Application Server, they can be defined in the WebSphere Application Server administration process, to enable the administrator to associate applications with one or more defined Web servers in order to generate the proper routing information for Web server plug-ins. In addition, Web server management capabilities are available in some circumstances. Source:WebSphere Application Server V6.1 Planning and Design Database Server The database server plays an integral role in the WebSphere Application Server environment. The database server is defined on the IBM Terminology site as: 1. A software program that uses a database manager to provide database services to other software programs or computers. 2. The server on which the database application and database are installed. 3. A computer that is dedicated to running a database manager to provide database services to other software programs or computers. See also data server. ..A server that provides services for the secure and efficient management of information. Directory Server The directory server is defined on the IBM Terminology site as: A server that can add, delete, change or search directory information on behalf of a client. A directory is a data structure that enables the look up of names and associated attributes arranged in a hierarchical tree structure. In the context of enterprise application servers, this enables applications to look up a user principal and determine what attributes the user has and of which groups the user is a member. Decisions about authentication and authorization can then be made using this information. Source: WebSphere Application Server V6.1 Planning and Design The common protocol used for the directory server is Lightweight Directory Access Protocol (LDAP) which is defined on the IBM Terminology site as: An open protocol that uses TCP/IP to provide access to directories that support an X.500 model and that does not incur the resource requirements of the more complex X.500 Directory Access Protocol (DAP). For example, LDAP can be used to locate people, organizations, and other resources in an Internet or intranet directory. Proxy Server A Proxy server is defined on the IBM Terminology site as: 1. A server that receives requests intended for another server and that acts on the client's behalf (as the client's proxy) to obtain the requested service. A proxy server is often used when the client and the server are incompatible for direct connection. For example, the client is unable to meet the security authentication requirements of the server but should be permitted some services. 2. A server that acts as an intermediary for HTTP Web requests that are hosted by an application or a Web server. A proxy server acts as a surrogate for the content servers in the enterprise.

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

25

WebSphere Application Server types in the context of Lotus Sametime 8.5 The IBM Lotus Sametime 8.5 system requirements document, Detailed system requirements - Sametime 8.5 provides, among other requirements, the supported database servers, directory servers, HTTP servers, etc. The previous section briefly explained the function of some of the key servers that comprise a WebSphere Application Server environment. This section discusses those server types in the context of the Lotus Sametime 8.5. Some of the servers cited in the requirements are shown in the graphic below .

Application Servers Most of the Lotus Sametime 8.5 servers run on the IBM WebSphere Application Server platform, and are application servers themselves. The purpose of each server is described briefly here: v The IBM Lotus Sametime System Console provides a central location for installing, configuring and administering the Sametime components. v The IBM Lotus Sametime Meeting Server provides a central meeting place for community members.

26

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

v The IBM Lotus Sametime Media Manager provides audio and visual services for Sametime meetings and chats. v The IBM Lotus Sametime Proxy Server hosts the Lotus Sametime client for browsers. v The IBM Lotus Sametime Gateway Server provides the means of sharing awareness with external instant messaging communities. Note: The IBM Lotus Sametime Community server runs on IBM Lotus Domino® server rather than WebSphere Application Server. Database Server Several of the Lotus Sametime servers/components require a Database server, specifically IBM DB2®, which can be downloaded with the Lotus Sametime 8.5 installation. For more information see the download document, IBM Lotus Sametime Standard 8.5. The Lotus Sametime System Console, the Lotus Sametime Meeting Server, and the Lotus Sametime Gateway Server all require DB2. The Lotus Sametime System Console requires DB2 to store user policy information and deployment topology information; this information is fed to the installers when setting up servers and also at runtime to connect to other servers. The Lotus Sametime Meeting Server requires DB2 for storing meeting room user data. The Sametime Gateway Server requires DB2 for policy information. Directory Server The Lotus Sametime System Console, the Lotus Sametime Meeting Server and the Lotus Sametime Gateway Server all require an LDAP directory server. The LDAP directory contains the person records for the users in the local Lotus Sametime Community, and these servers can search the LDAP directory and authenticate Lotus Sametime users when required. Proxy Server There are several roles for proxy servers in a Lotus Sametime deployment. One example is when the IBM WebSphere Proxy Server is configured to handle routing and caching tasks for a cluster of Lotus Sametime Meeting Servers. IBM WebSphere Proxy Server is distributed with the WebSphere Application Server that is included with the Lotus Sametime installation. The Lotus Sametime system requirements also lists several supported proxy servers that can be used for secure networking.

Deployment Manager and the IBM Integrated Solutions Console With the IBM WebSphere Application Server Network Deployment edition, you administer the servers and components associated with the WebSphere Application Server environment using the deployment manager. The environment where there are multiple servers being managed from a single deployment manager is referred to as a Distributed server environment. The deployment manager itself is a server that centrally manages and administers all servers and components in a given node(s) in a given WebSphere Application Server cell. The deployment manager also hosts powerful advanced deployment capabilities that are available in a distributed server environment; including high availability, dynamic scalability, and advanced clustering for workload balancing and failover. In a distributed server environment, the deployment manager contains the master configuration files (such as .xml files) and Java™ EE application files to start and run the WebSphere components and processes that run in the environment. The deployment manager synchronizes its configuration files with those held locally on each node associated with that deployment manager. Each node contains a node agent, and the deployment manager communicates with the node agents to synchronize the configuration information and file transfer, and perform other administrative activities on those nodes. The file synchronization process that occurs between the deployment manager and the nodes that are federated into the same cell where the deployment manager resides, is always one-way; from the Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

27

deployment manager to the nodes. Configuration changes made at the node level are temporary and will be overwritten by the master configuration on the deployment manager during the next file synchronization. Federation is an important process in a distributed server environment, and it is handled by the deployment manager. Federation is the process by which a node becomes a part of the deployment manager cell. During federation, a node agent server is created on the node to manage WebSphere Application Server environment on that node. A tool that is hosted by the deployment manager and executes the management and administration tasks in the WebSphere Application Server distributed server environment is the IBM Integrated Solution Console. The IBM Integrated Solutions Console, which has been cited throughout this document, is further defined in the WebSphere Application Server v7.0 Information Center topic Overview of Integrated Solutions Console as follows: Integrated Solutions Console provides a single, common interface for system administration. It provides the main platform on which IBM and non-IBM products can build administrative user interfaces as individual plug-ins to a common console framework. Standardizing product administration functions to run on the Integrated Solutions Console platform gives them a more common look and feel and a more consistent behavior, thereby reducing the learning curve and adoption as new management components are introduced. Administrators can interact with multiple IBM and non-IBM products from a single browser-based console.

Deployment Manager and the Lotus Sametime System Console Lotus Sametime 8.5.x can be deployed in several ways, but a recommended method is to use the Lotus Sametime System Console (SSC) as the central point of configuration for deployment planning. Once Lotus Sametime is deployed its runtime features and functions can be administered mostly using the IBM Integrated Solutions Console and the Lotus Sametime System Console. The document IBM WebSphere Application Server Introduction for Lotus explains that the Lotus Sametime System Console is built on Java EE technology and is a plug-in with a set of portlets within the IBM Integrated Solutions Console, which is hosted on the Deployment Manager. Here we will dig a little deeper by explaining the following image. .

28

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

There are three application servers, or Java Virtual Machines (JVMs), that run in the Lotus Sametime Console Server cell (labeled as SSC Cell in the diagram above): the Deployment Manager, Node Agent, and the Lotus Sametime System Console Server. As mentioned previously in this document, the Lotus Sametime System Console database (labeled as STSC DB in the diagram above), which runs on IBM DB2, stores user policy data and much of the Lotus Sametime deployment topology data; it feeds this data to the installers when setting up the Lotus Sametime servers, and at runtime to connect to the servers. The node agent is used for communication between the Deployment Manager and the Sametime System Console Server. The Deployment Manager hosts the Integrated Solutions Console, and Sametime System Console Portlets (labeled as SSC Portlets in the diagram above) within the ISC provide the user interface for administering the Sametime servers and components. The SSC Framework applications are used to drive the REST APIs that the Sametime installers connect to and also provide policy and administrative interfaces that the applications connect to in order to do necessary updates of information from the SSC. One of the important functions of the ISC and the SSC is to make sure that changes made at the deployment manager level are propagated to the nodes in the same cell as the deployment manager. When you make a change on an the Sametime System Console Server, such as increase trace levels, it is important to save the change to the master configuration, which is located on the deployment manager. To make sure the nodes know of the changes you made, you then trigger file synchronization by selecting System Administration → Save Changes to Master Repository → Synchronize Changes with Nodes → Save . Once the synchronization has completed, you must then restart the server. Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

29

Things to check when you cannot access the Lotus Sametime System Console The Deployment Manager, Node Agent, and Lotus Sametime System Console application server must all be running to access the Lotus Sametime System Console. Once all three of these servers are started, you log into the IBM Integrated Solutions Console (ISC), and access the Sametime System Console within the ISC, from your Web browser using http:///ibm/console. Details on determining the correct port to use were discussed previously in this document, in the section Logging on to the IBM Integrated Solutions Console. At times you may have trouble accessing the Lotus Sametime System Console; for example, you may not be successful when logging into the IBM Integrated Solutions Console and you may see an error in your browser such as "Unable to connect" or "Cannot display web page". In this case, these particular errors normally occur if the deployment manager is not running. As a first step, it is a good practice to verify that all three servers are running by executing the serverStatus command in your operating system's command prompt. Refer to the topic in the previous section of this document titled, Checking the Status of a Server for the proper syntax of the serverStatus command. If the deployment manager is running, the results of the serverStatus command execution will state: “ADMU0509I: The Deployment Manager "dmgr" is STARTED" If the deployment manager is not running, the serverStatus command will state “ADMUxxxxI: The Deployment Manager "dmgr" cannot be reached. It appears to be stopped." Note: The numerical portion of the ADMUxxxxI code in the console messages will differ depending on the server you are starting and its state. If the deployment manager is not running, start it using the appropriate command for your operating system. Refer to the previous section of this document titled Common WebSphere Application Server Commands for step-by-step instructions on navigating to the proper location for checking server status and starting not only the deployment manager server but also the node agent server and the Lotus Sametime System Console application server. At other times you may be able to successfully log into the ISC, but cannot access the specific Lotus Sametime System Console options.. The image below shows an example of an error that occurs when the deployment manager is running and you have successfully logged into the Integrated Solutions Console, but you cannot access some of the options in the Sametime System Console. A likely cause of this behavior is that the Lotus Sametime System Console application server is not running.

30

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

In this case, it is best to issue a serverStatus -all command in the proper directory to verify the status of both the node agent and the Sametime System Console server. If either or both servers are not running, start them accordingly. Again, a good place to verify your steps, and to see examples of the output you will see from the serverStatus command and others, is the previous section of this document titled Common WebSphere Application Server Commands. If you have confirmed that all three servers are started, but are still experiencing issues with accessing the Lotus Sametime System Console, first check the systemOut.log file located in the deployment manager profile's log directory: \profiles\STSCDMgrProfile\logs\dmgr for errors starting with AIDSC. All Sametime System Console errors begin with these characters, followed by a 4 digit number. Then check the Sametime System Console application server's systemOut.log file for the AIDSC errors; this systemOut.log is located in the Sametime System Console application server's log directory: \profiles\STSCAppProfile\logs\STConsoleServer. If you attempt to log into the Integrated Solutions Console and instead see a blank screen, it could be that the LDAP server is down or otherwise inaccessible. The SystemOut.log for the deployment manager under \profiles\STSCDMgrProfile\logs\dmgr (or trace.log in the same location, if you have trace enabled) will contain an error that resembles: "[date time] 0000002f exception E com.ibm.ws.wim.adapter.ldap.LdapConnection getDirContext com.ibm.websphere.wim.exception.WIMSystemException: CWWIM4520E The'java.naming.CommunicationException: :389 [Root exception is java.net.ConnectException: Connection refused]' naming exception occurred during processing. If you find this error in the logs, or otherwise suspect an issue with the LDAP server, add the parameter allowOperationIfReposDown=true to the wimconfig.xml fie. The presence of this parameter in Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

31

wimconfig.xml allows you to log into the Integrated Solutions Console and access the Sametime System Console even though the LDAP server is not accessible. If a defunct LDAP server is defined, you can then make the necessary changes. As cited in the section of this document titled WebSphere Application Server Profiles in Lotus Sametime, the wimconfig.xml file is located in the \ profiles\ STSCDMgrProfile\config\cells\\wim\config directory. Open the file in a text editor and locate these lines: Important note: Editing configuration files in general is not recommended. Extreme caution should be used when making edits to the wimconfig.xml file; incorrect changes could render the servers inaccessible. Add the parameter allowOperationIfReposDown="true" in the exact location specified below, and save the file: This change allows you to log into the Integrated Solutions Console as long as the credentials you enter are accepted by a working/running LDAP server. Once you have logged in you can view the LDAP repository configurations and make any needed changes (such as removing a defunct LDAP server that WebSphere Application Server is trying to query on login and causing the login failure) by selecting to Security → Global Security , and under the User Account Repository section, select Federated Repositories for Available Realm Definitions and select Configure. You will see the defined repositories in the realm. Make any necessary changes so that the settings reflect your current LDAP servers, then select Manage Repositories and make any needed changes there. After you select OK, make sure that you select Save at the top of the Global Security page to ensure the changes are saved to the master configuration.

How to Set up Sametime servers to automatically load as Windows Services For Microsoft Windows operating systems, one way to ensure that the servers associated with the Lotus Sametime System Console are started, thereby avoiding some of the access issues cited in the previous section, is for the servers to be defined as Windows Services so that they always start on operating system startup. However, there is an overall caveat where, by default, when you install any WebSphere Application Server components, Windows Services are not automatically created for them. There are several methods you can choose from to set up your Lotus Sametime servers to load as Windows Services. One method is to create and run batch files. Follow the instructions in the Lotus Sametime 8.5 wiki article Sametime 8.5 Components as a Windows service . As manual creation of the batch files can be susceptible to issues such as typos, another method is to use of the WebSphere Application Server utility WASServiceCmd. Perform the following steps to use the WASServiceCmd utility to set up the Sametime System Console servers as Windows services. 1. Detach the compressed file from the document, Using WASServiceCmd to create Windows services for WebSphere Application Servers, 2. Open a Windows cmd prompt and switch to the \bin directory. 3. Type wasservicecmd.bat and press ENTER. A list of menu options appears.

32

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

4. Type 1 to select the first menu option. A list of profiles, associated with the Application Server directory you started the utility from, appears. The same list of profiles appears under the \profiles directory. 5. Type the number corresponding to the profile containing the servers you want to set up as services. In this example, STSCDMgrProfile is the name of the profile associated with the Lotus Sametime System Console server's deployment manager. When you select the number corresponding to the profile, setupcmdLine.bat launches, which lists the Cell and Node associated with that profile as well as the server(s) associated with that node. In the example, the Deployment Manager server, "1 dmgr" is listed under Servers. 6. Type a desired service name for the server. Example: Since this server is the Deployment Manager server, type STConsoleServerDM or ConsoleServerDM. The following image shows an example of executing the steps above.

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

33

7. 8. 9. 10.

Once you have named the service, the utility will ask you several questions regarding your preferences on service startup and security. The image below shows these questions and choices. Select a desired Restart Policy. Select a desired Start Type. Indicate whether WebSphere Security is enabled. An Execute command will appear; type Y to run the service creation process.

11. Once the command completes and you are again prompted to type a number corresponding to the desired menu option, type 1 to initialize the steps to set up a Windows service for the node agent 12. Type the number corresponding to the profile containing the servers you want to set up as services. In the example graphic in step 5 above, STSCAppProfile is the name of the profile associated with the Lotus Sametime System Console server. 13. From the list of servers that appear select 2 nodeagent. 14. 15. 16. 17. 18. 19.

Type the desired service name . Example: ConsoleServerNodeagent. Select a desired Restart Policy. Select a desired Start Type. Indicate whether WebSphere Security is enabled Type Y to run the service creation process. Repeat these steps once more for the Lotus Sametime System Console server.

You can check if the services were successfully created by selecting Start - Run and typing services.msc. Look for a service starting with "IBM WebSphere Application Server v7.0 - ". The image below shows the

34

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

result of the steps taken above:

Repeat these steps to configure Windows services for the remaining Sametime servers associated with the cell. Note that with either method of setting up the services, the services will start with an operating system start or restart, but may not always start after a crash. It is always best to check the logs such as startServer.log for each server that is suspected of not starting or starting properly to determine whether the server fully started. A startServer.log file exists for each server in the each profile, and is located in the \profiles\\logs\ directory.

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators

35

36

Overview of IBM WebSphere Application Server Concepts for IBM Lotus Sametime Administrators



Printed in USA

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF