SOAP works with any programming or scripting language, any object model and any Internet wire protocol. Audience: ITM 6. It also covers some examples and troubleshooting the Universal Agent. Presented by: Scott Wallace Date: September 25, Special focus will paid to the latest version of the Fixpack, version Postemsg lets you send alert to TEC from an external source like a script or application.
This isn't exactly a postemsg equivalent in ITM 6 because I'm limited to the attributes in the. IBM Tivoli Monitoring v6. Agent Installation and Configuration hints, example of usage in the real life and troubleshooting will be detailed. Introduction to ITM Agent Builder Introduction to the new Agent Builder tool components, review of the features available for creating custom agents and quick look at the available debugging options.
General troubleshooting is discussed for the TEMS and TEPS, and common problems and troubleshooting techniques are detailed for elements such as situations, policies, communication issues, and data collection. ITM v6. Tivoli Monitoring v6. IBM Tivoli Monitoring 6. This STE will show you differences between versions 6. It simplifies and reduces the need to diagnose problems encountered with IBM products. Interim fix 3. Patch 3. ITM 5. No summarisation and prunning at scheduled time.
Parameters used to control background collections for an agent builder agent What settings can I change to disable or configure background collections for an agent builder agent?
Data is Not Returned from Agent Builder Custom Data Providers Several of the data providers used in agent builder developed agents require Java in order to collect data. This itself is not a problem. The problem arises if Java is not in the PATH environment variable of the user under which the agent is running.
When this happens, the data provider will be unable to return any data for the related attribute groups. Similar type messages can be seen in the agent's log file: 49A4C After GSKit 7. TEPS does not start. The customer is using the ITM 6.
The customer wants to know how to configure this parameter in the mdl file. Agent Builder agent install fails.
Be sure the ODI files doc??? Unable to load application suppport, code 1. Using fields longer than required can also cause additional work to evaluate the situation. Making the changes below have, in some instances, reduced CPU usage on a TEMS from close to full utilization to nearly completely idle. Referencing Configuration Parameters within Agent Builder Scripts How you can reference parameters that are set in the agent configuration within scripts when developing a solution using the agent builder?
The issue occurs for "tacmd listSystems" command also. When configuring TEPS with itmcmd command, the following error occurred. Please check for errors or problems. After re-seeding or the installation of an ITM 6. After installing ITM 6. The same problem will occur if the TEMS is manually re-seeded. Windows: Defining hubs. Adding users. Windows: Adding users. Verifying the configuration. Part 4. Setting up data warehousing. Tivoli Data Warehouse solutions. Planning assumptions.
Preliminary planning is complete. This is not a single computer installation. The data warehouse is remote from the portal server. Agent warehouse database upgrade. Firewall considerations for the Tivoli Data Warehouse. Next steps. Chapter 9. Configuring permissions for a monitoring server on a non-NIS Solaris. Increasing virtual memory on AIX for large environments. Additional Tivoli Enterprise Portal configuration. Tivoli Data Warehouse solution using DB2.
Prerequisite installation. Solution steps. Creating a warehouse user on Windows. Creating a warehouse user on Linux or UNIX Limiting the authority of the warehouse user Setting database and instance configuration values. Step 2: Install and configure communications for the Warehouse Proxy agent. Cataloging a remote data warehouse. Before you begin. Starting the Warehouse Proxy.
Step 4: Install and configure communications for the Summarization and Pruning agent. Starting the Warehouse Proxy agent. Configuring the portal server ODBC connection. Tivoli Data Warehouse solution using Oracle. Implementing a Tivoli Data Warehouse solution using Oracle. Tivoli Data Warehouse solutions: common procedures. Starting the Summarization and Pruning agent.
Installing and configuring multiple Warehouse Proxy agents. Installing and configuring the proxy agents. Setting a permanent socket address for a proxy agent. Testing the connection between the portal server and the Tivoli Data Warehouse. Tuning the performance of the Warehouse Proxy Database initialization. Work queue. Connection pool. RPC threads and export requests. Timeout values. Verifying installation and configuration.
Starting and stopping the situation update forwarder. Part 5. Integrating event management systems. Setting up event forwarding to Tivoli Enterprise Console.
Installing from a wizard. Installing from the command line. Installing from the command line using a silent installation. Manually importing the event synchronization class files and rule set.
Creating a new rule base. Creating a new rule base and importing an existing rule base into it. Modifying an existing rule base. Installing monitoring agent. Configuring your monitoring server to forward events. Starting and stopping the Situation Update Forwarder process. Changing the configuration of the event synchronization component on the event server.
Defining additional monitoring servers to the event server. Upgrading to Tivoli Event Synchronization component version 2.
Upgrading from a wizard. Upgrading from the command line. Upgrading from the command line using a silent installation. Part 6. Installation worksheets Windows hub monitoring server worksheet. Linux or UNIX hub monitoring server installation worksheet. Windows remote monitoring server worksheet.
Linux or UNIX remote monitoring server installation worksheet. Windows portal server worksheet. Linux portal server worksheet. Generic Windows monitoring agent worksheet.
Windows portal desktop client worksheet. Linux portal desktop client worksheet. Monitoring server communications protocol details worksheet. Appendix B. Running the silent installation from the command line with parameters. Using SMS. Installing components with a response file. Configuring components with a response file. Appendix C. Flow of connection establishment. Permission at the firewall.
Server address continuity. Number of internet zones. Basic automatic implementation. Implementation with ephemeral pipe. Implementation with partition file.
Sample scenarios. Creating or modifying the partition file in Manage Tivoli Monitoring Services. Windows: Editing the partition file. Sample partition file. Implementation with firewall gateway. Updating the OMNIbus db schema. Configuring the EIF probe. Configuring error event flow to OMNIbus optional. Configuring the monitoring server. Customizing the OMNIbus configuration. Appendix D. Scenario with secureMain.
Uninstalling the Warehouse Proxy. Appendix H. Documentation for the base agents Related publications. Other sources of documentation. Appendix G. Uninstalling the environment on Windows.
Uninstalling a component on Windows. Removing an agent through the Tivoli Enterprise Portal. Appendix I. Support for problem solving.
Obtaining fixes. Receiving weekly support updates. Determining the business impact. Describing problems and gathering Submitting problems. Figures 1. IBM Tivoli Monitoring environment. Configuring Hot Standby for a remote monitoring server. Configuring a monitoring agent to connect to a standby hub monitoring server. Hierarchy for the heartbeat interval.
Intranet with integral Web server. Intranet with external Web server. Intranet with integral Web server; Internet with external Web server. Intranet and Internet with integral and external Web servers.
Two host addresses, intranet and Internet, with integral and external Web servers. Summary of support for the Tivoli Data Warehouse. Configure Warehouse Proxy window Agent Parameters tab. Configuring the connection to a DB2 data warehouse. Configuring the connection to an Oracle data warehouse. Sources tab of Configure Summarization and Pruning Agent window. Scheduling tab of Configure Summarization and Pruning Agent window. Work Days tab of Summarization and Pruning Agent configuration window.
Log Parameters tab of Summarization and Pruning Agent configuration window. Additional Parameters tab of Summarization and Pruning Agent configuration window. Create Query window. Window shown when no Tivoli Enterprise Console event server is found. Upgrade data collection window. Confirming the uninstallation. Stopping Tivoli components prior to uninstallation. Removing the portal database. Database information. Uninstallation progress window.
GSKit uninstallation. Successful uninstallation. Tables 1. IBM Tivoli Monitoring base monitoring agents 3 2. Overview of the design process. Description of four factors that affect the number and types of monitoring servers required in simple and complex environments. Determining the number and type of monitoring servers based on the number of monitoring agents.
Tivoli Data Warehouse database size estimation worksheet. Database size examples. Options for Tivoli Monitoring components resiliency. Resiliency characteristics of Tivoli Monitoring components and features. Basic steps to set up Tivoli Monitoring on a cluster. Control interface publishing. Installation and configuration steps. User security configuration method. Supported Windows operating systems 71 Supported Linux operating systems.
Supported databases for the portal server 77 Supported databases for the Tivoli Data Warehouse. Configuration information for the portal server database. Configuration information for the Tivoli Data Warehouse database.
IBM Tivoli Monitoring high-level installation steps. Communications protocol settings for the hub monitoring server.
UNIX monitoring server protocols and values Parameters for the itmcmd manage command Remote monitoring server communications protocol settings. Steps for installing a portal server on a Linux or AIX computer. Hub monitoring server protocols and values Configuration information for the Tivoli Enterprise Portal Server database. Communications protocol settings.
Procedures for installing and enabling application support. Installation media and instructions for installing application support for non-Base monitoring agents. Remote agent deployment tasks. Agent depot management commands Configuration tasks available through Manage Tivoli Monitoring Services.
SOAP methods associated with access privileges. Information topics related to installation of prerequisite software for a Tivoli Data Warehouse solution.
Tasks for creating the Tivoli Data Warehouse database. Default values for Tivoli Data Warehouse parameters. Script for creating required bufferpool and tablespaces for the Tivoli Data Warehouse. Tasks for installing and configuring communications for the Warehouse Proxy agent.
Tasks for configuring communications between the portal server and a DB2 data warehouse. Tasks for installing and configuring communications for the Summarization and Pruning agent. Tasks for configuring communications between the portal server and a Microsoft SQL Server data warehouse. Goals for achieving a Tivoli Data Warehouse solution using Oracle. Configuration information for the Tivoli Data Warehouse database on Oracle. Tasks for configuring communications between the portal server and an Oracle data warehouse.
Configuration information for a Tivoli Data Warehouse database on Oracle. JDBC driver names. Tivoli Enterprise Console event synchronization installation and configuration steps. Options for rule base modification. Mapping of situation attributes to OMNIbus attributes.
Windows hub monitoring server installation worksheet. Windows remote monitoring server installation worksheet. Windows portal desktop client worksheet Linux portal desktop client worksheet Silent installation parameters for UNIX Component product codes for infrastructure components and base monitoring agents.
EIB Files. Planning your installation The chapters in this section describe the architecture of the IBM Tivoli Monitoring products and provide information to help you plan your deployment and prepare to install or upgrade the base components of the product.
To minimize problems during deployment, you should read these chapters carefully. The information in this section is also relevant to these products. Chapter 2, Planning your deployment, on page 13, contains information that assists you in assessing your environment and planning the deployment of product components. Chapter 3, Preparing for installation, on page 59, helps you collect the information you will need during installation and configuration and details the hardware and software requirements for various components and configuration.
It also addresses special considerations for the installation of the Tivoli Data Warehouse and Tivoli Enterprise Portal clients. Chapter 1. These products are based on a set of common service components, referred to collectively as Tivoli Management Services. Tivoli Management Services components provide security, data transfer and storage, notification mechanisms, user interface presentation, and communication services in an agent-server-client architecture Figure 1 on page 4.
This book contains information on deploying, installing and configuring the common services components and the monitoring agents that comprise the base IBM Tivoli Monitoring product Table 1 on distributed systems. If you purchased a product other than IBM Tivoli Monitoring that uses Tivoli Management Services, use this book to install and configure the common components.
Do not install the base agents unless you have purchased IBM Tivoli Monitoring as a separate product. If you purchased additional IBM Tivoli Monitoring products, refer to their documentation for agent-specific installation and configuration information.
Table 1. Tivoli Management Services components and Monitoring agents provide inventory signature files and usage definitions that allow License Manager to report installed products and product usage by computer. License Manager support is an optional capability that requires License Manager version 2. Components of the monitoring architecture Tivoli Monitoring products, and other products that share Tivoli Management Services, participate in a server-client-agent architecture.
Monitoring agents for various operating systems, subsystems, databases, and applications known collectively as Tivoli Enterprise Monitoring Agents collect data and send it to a Tivoli Enterprise Monitoring Server.
Data is accessed from the monitoring server by Tivoli Enterprise Portal clients. A Tivoli Enterprise Portal server provides presentation and communication services for the clients.
Several optional components such as an historical data warehouse extend the functionality of the framework. Before deciding where to deploy the components of the Tivoli Monitoring product in your environment, you should understand the components of the product, the roles that they play, and what affects the load on these components.
Every installation requires the following components: v One or more Tivoli Enterprise Monitoring Servers, which act as a collection and control point for alerts received from the agents, and collect their performance and availability data. The monitoring server also manages the connection status of the agents. One server in each environment must be designated as the hub. The portal server retrieves data from the hub monitoring server in response to user actions at the portal client, and sends the data back to the portal client for presentation.
The portal server also provides presentation information to the portal client so that it can render the user interface views suitably. Tivoli Enterprise Portal offers two modes of operation: desktop and browser. These agents collect data from monitored, or managed, systems and distribute it to a monitoring server.
An installation optionally includes the following components: v Tivoli Data Warehouse for storing historical data collected from agents in your environment. To store data in this database, you must install the Warehouse Proxy agent. To perform aggregation and pruning functions on the data, you must also install the Summarization and Pruning agent. The following sections describe each of these components in more detail. Tivoli Enterprise Monitoring Server The Tivoli Enterprise Monitoring Server referred to as the monitoring server is the first component to install to begin building the Tivoli Management Services foundation.
The monitoring server is the key component on which all other architectural components directly depend. The monitoring server is the collection and control point for performance and availability data and alerts received from monitoring agents. It is also responsible for tracking the online or offline status of monitoring agents. Because of the number of functions the monitoring server performs, large-scale environments include a number of monitoring servers to distribute the load.
One of the monitoring servers is designated the hub monitoring server, and the remaining servers are termed remote monitoring servers. Each remote monitoring server must be located on its own computer and have a unique monitoring server name node , but the architectures of various remote monitoring servers might differ from each other and from the hub monitoring server. In other words, a remote monitoring server running on UNIX can report to a hub monitoring server running on Windows.
The portal server communicates with the hub, which in turn controls the remote servers, as well as any monitoring agents that might be connected to it directly. The monitoring server storage repository is a proprietary database format referred to as the Enterprise Information Base, or EIB.
The hub holds the master copy of the EIB, while the remote servers maintain a subset of the EIB relevant to them, which is synchronized with the hub.
The Tivoli Enterprise Portal Server referred to as the portal server manages data access through user workspace consoles the clients. The portal server is configured to connect to a hub monitoring server. It retrieves data from the hub in response to user actions at a portal client, and sends the data back to the portal client for presentation.
The portal server uses a DB2 or Microsoft SQL database to store various artifacts related to presentation at the portal client. The portal client provides access to the Tivoli Enterprise Portal.
There are two kinds of portal client: v Browser client interface automatically installed with Tivoli Enterprise Portal Server : In your Internet browser, to start Tivoli Enterprise Portal browser client, you can enter the URL for a specific Tivoli Enterprise Portal browser client installed on your Web server. Running the browser client is supported only on Windows computers. After the desktop client is installed and configured, you can use it to start Tivoli Enterprise Portal in desktop mode.
You can also download and run the desktop client using Java Web Start. See Planning considerations for the Tivoli Enterprise Portal client on page 26 for a discussion of the comparative advantages of each type of portal client. Tivoli Enterprise Monitoring agents Monitoring agents are data collectors.
Agents monitor systems, subsystems, or applications, collect data, and pass the data to Tivoli Enterprise Portal through the monitoring server. The agents pass commands from the user to the system, subsystem, or application.
An agent interacts with a single system or application and, in most cases, is located on the same computer where the system or application is running. There are two types of monitoring agents: v Operating system OS agents that monitor the availability and performance of the computers in your monitoring environment.
You can use the Universal Agent to monitor any data that you collect in your environment. For example, you can use the Universal Agent to monitor the status of your company Web site to ensure that it is available.
This is the same DVD that you use to install the monitoring servers, portal server, and portal desktop clients. IBM Tivoli Monitoring 5. The Base DVD also includes application support for a small number of non-base distributed monitoring agents.
See Selecting the correct support media on page for more information. You can generate warehouse reports for short-term or long-term data through the Tivoli Enterprise Portal.
Warehouse reports provide information about the availability and performance of your monitoring environment over a period of time. You can also use third-party warehouse reporting software, such as Crystal Reports or Brio, to generate reports. Two specialized agents interact with the Tivoli Data Warehouse: v The Warehouse Proxy agent receives data collected by monitoring agents and moves it to the Tivoli Data Warehouse database.
Figure 2 on page 8 shows the flow of situation events from the monitoring server to the event server as Event Integration Facility EIF events and the flow of updates to the situation events back to the monitoring server. If you are monitoring event data from a supported event management system in the Tivoli Enterprise Console event view or the Common Event Console view, you can filter out forwarded events.
For information about the various configurations of monitoring servers and event servers that you can have in your environment, see Part 5, Integrating event management systems, on page New in this release The following are changes in this release that affect installation or configuration.
Application support for additional V6. This DVD contains the national language versions of the help and presentation files for the following languages: French, German, Italian, Portuguese Brazilian, Spanish. Changes to runtime prerequisites and platform support Runtime prerequisites have changed in several environments, especially AIX.
Support for some platforms have been added and support for others have been dropped. Carefully review the information in Hardware and software requirements on page 70, especially the table footnotes, for V6.
See Upgrading the warehouse on page The hub monitoring server can now be configured to validate user IDs and passwords using either the local system registry or a central LDAP authentication and authorization system. This enhancement permits the sharing of user authentication information among products and prepares for future cross-product integration such as single sign-on. For more information, see Understanding security options on page 67 and Configuring user authentication on page The Help Server is installed with the Tivoli Enterprise Portal Server and can only be started and stopped by starting and stopping the portal server.
Reverse synchronization for forwarded events changes at the event server returned to the originating monitoring server is provided by an event synchronization component SitUpdateForwarder. For more information, see Event integration scenarios on page 52 and Part 5, Integrating event management systems, on page Common Event Console view for events from multiple event servers The Common Event Console enables you to view and manage events from the Tivoli Enterprise Monitoring Server in the same way as the situation event console.
Event data is retrieved from an event system by a common event connector, which also sends user-initiated actions to be run in that event system. To have the events from a specific event system displayed in the common event console, you must configure a connector for that event system. During configuration of the Tivoli Enterprise Portal Server you can edit the default connector for the Tivoli Enterprise Monitoring Server and you can configure additional connectors for other event systems.
Remote installation of application support files using Manage Tivoli Monitoring Services on Linux In previous versions, the Manage Tivoli Monitoring Services utility on Windows can be used to FTP application catalog and attribute files to non-local monitoring servers.
The utility can also be used to transfer the. In V6. Flexible scheduling of Summarization and Pruning agent The Summarization and Pruning agent has been enhanced to allow for flexible scheduling and to have the warehouse and warehouse aggregation logs trimmed automatically after a specified number of days, months, or years. Validation of monitoring server protocols and standby configuration In previous versions, there was no validation of hub and remote monitoring server protocols and standby configuration.
You may see warnings if you enter incorrect values during configuration. Base components and Monitoring agents provide inventory signature files and usage definitions that allow License Manager to report installed products and product usage by computer.
See Installing into Solaris zones on page 65 for more information. Table 2 describes the planning topics and where to find them in this publication. Table 2. Understand the needs of your existing environment so that you can identify the components of IBM Tivoli Monitoring that you need.
Where to find information Overview of the design process Assessing the existing environment on page Design your environment based on planning Designing your deployment on page 16 guidelines, the components you need, and security considerations.
Understand the requirements for the Tivoli Data Warehouse Decide the type of Tivoli Enterprise Portal client to use Review sample environment configurations. Planning considerations for the Tivoli Data Warehouse on page 19 Planning considerations for the Tivoli Enterprise Portal client on page 26 Scenarios for small, medium, and large environments on page 27 High availability scenarios on page 34 Event integration scenarios on page Overview of the design process To create a monitoring design, you must know how the existing environment is organized, as well as the current status of platforms, networks, applications, procedures, and processes.
With this information, you must determine what kind of monitoring is needed, and what resources can be made available to IBM Tivoli Monitoring software to provide the solution. Table 3 describes the design tasks and where to find them in this publication.
Table 3. Overview of the design process Goal Perform an assessment of the existing environment, including what needs to be monitored. Determine the number and type of monitoring servers required. Decide where to locate the monitoring servers and portal server. Additional information if applicable Assessing the existing environment on page 14 Determining the number of monitoring servers needed on page 16 Determining server placement on page Overview of the design process continued Goal Determine how to deploy the monitoring agents.
Additional information if applicable Determining when to use the remote deployment feature on page 19 Chapter 7, Deploying monitoring agents across your environment, on page Decide on the number and placement of Warehouse Proxy agents and the Summarization and Pruning agent.
Determine how to configure the Tivoli Data Warehouse server. Scenarios for small, medium, and large environments on page 27 Planning considerations for the Tivoli Data Warehouse on page 19 Appendix C, Firewalls, on page Assessing the existing environment Before selecting and installing the IBM Tivoli Monitoring components, fully review and document the environment you plan to monitor.
You can create an optimal design only after carefully considering the organizational needs and limitations for example hardware availability and understanding the technical capabilities of the IBM Tivoli Monitoring software.
Understanding the following conditions accelerates your design efforts and ensures that the solution performs as expected: v A thorough and accurate picture of your networking environment.
The number of factors that need to be considered and their influence on the architecture vary for each organization. Viewing these factors from both a physical and organizational perspective offers a way to arrange factors into manageable groups. The physical perspective is the network physical topology, such as available equipment and configuration of systems, in which IBM Tivoli Monitoring must operate. The existing environment influences how and where you deploy systems. In many ways, the physical environment forms baseline constraints for the entire design.
The organizational perspective includes expectations and limitations derived from the way you do business, and the division of authority and control of the systems to be managed. Organizational factors can influence the goals and means to deploy a monitoring solution.
The factors in the following sections, ordered by priority, are not a comprehensive list. Additional factors might be important in your environment.
Physical perspective The following sections provide information about the physical perspective for a monitoring environment. Network factors Prepare a network diagram or sketch of the network topology, if one is not already available for your organization.
This network design information is necessary for the design process and should at a minimum provide details about the following critical and important considerations: v Line speed of each network connection. The line speed impacts the number of hub monitoring servers and the placement of remote monitoring servers and the Tivoli Data Warehouse.
Determine if there are bandwidth restrictions that must be honored to share limited bandwidth with other applications. It points out the recommended strategy for the Tivoli historical date collection. We highly advise structuring the historical collection flow as outlined in the diagram. Architecture and planning 13 In a large installation, implementing the Hot Standby node is strongly recommended.
Performing an accurate plan and assessment stage is imperative for the large installation. Mapping all component topology with the recommended hardware specifications is critical in order to achieve a highly distributed environment with realistic goals.
We recommend having a thorough understanding of the monitoring environment before preceding to implement any architectural design. It is important to account for all variables within the topology. Network bandwidth, latency, and firewall restriction all require assessment. After installation, it begins leveraging the best practice functionality immediately. Default situations start running, and if historical data collection is turned on, the default attribute groups begin analysis and warehousing.
These default services can impede the large installation performance throughput, especially if unnecessary attributed group collections are enabled.
This practice ensures the freedom to execute the business plan strategy defining managed system list, customized situation, event mapping, date warehousing intervals, and so forth that are generated from the assessment and planning phrase. It is vital to the health of the large installation that only the desired situations and attribute groups are enabled. A large monitoring installation supports approximately 1, managed systems in an environment. For the large installation, the estimate is three agents per managed system.
In this installation, a disproportionate distribution of agents is highly anticipated, and this scenario should complement your own environment analysis phrase. Keeping agents as the high point per monitoring server allows for capacity expansion without exhausting the resources of the infrastructure. The Tivoli Data Warehouse data requirement will be substantial. We always recommend keeping these two components together.
However, the large installation can contain a reasonable increase in volume of event flow, and the Tivoli Enterprise Console is better adapted for large event flow management and Chapter 1. Architecture and planning 15 The entire large installation can be managed from a single GUI presentation layer down to installing and upgrading agents.
The scope of the huge installation is similar to the large installation, except for additional configuration guidance. It demonstrates the high-level component interaction between two installations that handle 4, agents each, totaling 8, agents entirely. A huge installation can warehouse historical data collections to one single database server repository from two distinct IBM Tivoli Monitoring 6.
Best practice design is critical to ensure a stable, scalable environment. Architecture and planning 17 The two installations are still built separately from each other. Because the Summarization and Pruning agent requires connections to a TEMS, one of the monitoring installations must be logically designated as the master.
A flexible feature that is needed in the huge installation is the ability to configure multiple TEP instances in a single TEP desktop client. Type the instance name and click OK Figure Figure Entering the Instance Name into the dialog box Chapter 1. Architecture and planning 19 Architecture and planning 21 For a successful implementation, it is important to understand the component communication flow.
The connectionless UDP protocol requires opening up multiple ports across firewalls to allow multiple connections from each individual IBM Tivoli Monitoring 6.
Also, using the IP. Note: When IP. PIPE is specified as your communications protocol, you may still see other ports being used in communication traces and logs, but these ports are virtual and multiplexed over the default IP.
PIPE port. The IP. Any processes above 16 will fall back to using the IP protocol only if configured. This mainly is a restriction when running large numbers of Tivoli Enterprise Management Agents on one physical system. This may occur only when a system is required to run more than 16 Universal Agents or has more than 16 Database Agent instances. If firewall restrictions force the use of the IP.
The TEMS may run out of sockets listen threads. The maximum value that can be set is Use this table as a quick reference to understand the standard ports for an installation. Although modifying these default values is supported, it is not recommended.
Refer to Example on page Tip: Do not deviate from the default listening ports without a valid reason, even though this is supported. Using IP. PIPE enables a few well-known ports to be open through the firewall. You can use Example on page 24 to calculate which port to open. If the firewall is not using NAT Network Address Translation , the computation should be sufficient to have the components connect through the firewall. Architecture and planning 23 Note: is the default well-known port.
Any well-known port can be configured, as long as the entire environment matches this port number. Ideally, all components that need access through the firewall should use the lower-number ports, and components that do not cross the firewall use higher-number ports. See Example on page If the process is unable to bind to the highest port respective to N, it immediately fails to start up.
If the process is unable to bind to the port respective to N, it will keep trying using the algorithm until all available ports are exhausted. Total views On Slideshare 0. From embeds 0.
Number of embeds 1. Downloads 8. Shares 0. Comments 0. Likes 0. You just clipped your first slide! Clipping is a handy way to collect important slides you want to go back to later. Now customize the name of a clipboard to store your clips. Visibility Others can see my Clipboard. Cancel Save.
0コメント