Browse Prior Art Database

Method to Calculate Application Toplogy in a Distributed Network

IP.com Disclosure Number: IPCOM000132069D
Original Publication Date: 2005-Dec-01
Included in the Prior Art Database: 2005-Dec-01
Document File: 4 page(s) / 468K

Publishing Venue

IBM

Abstract

This paper describes a method to automate the collection and analysis of data to determine application topology for consolidation and performance analysis. Data is collected in a non-intrusive, automated manner into a database for later analysis. The results of the analysis can be used to determine RAS-aware and optimal server consolidation (SCON), configuration changes for performance improvements, and the like.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 4

Method to Calculate Application Toplogy in a Distributed Network

Conventional server consolidation and performance analysis procedures require the collection of a large amount of data, primarily utilization, capacity, and utilization data, commonly collecting physical topology information. See Figure 1. While it is generally important to understand the physical topology of the system, it does not give insight useful to the server and application consolidation requirements. This physical data d oes not lend itself to analysis of the reliability, availability, or serviceability of a network of systems, nor does it fully account for performance analysis of distributed systems. As a result, intensive manual data collection and analysis is required to maintain system requirements. This method proposes to also collection of logical, or Internet Protocol (IP) connection data for analysis by monitoring or "sniffing" the network in one of several ways.

1

[This page contains 1 picture or other non-text object]

Page 2 of 4

With the IP connection information collected, it would be possible to produce an analysis of the customer's applications and how they interact at a "logical" level. For example, it would be possible to identify the machines at the "edge of the web", the servers running mid-tier business logic, and the back-end database machines. See Figure 2. This information could be used during the SCON analysis to provide improved recommendations for performance and fault-tolerance (or, generally, RAS). The systems shown in Figures 1 and 2 are physical servers, regardless of if they are illustrating physical or logical connectivity. It is not necessary to use physical servers to deploy a 3-tier application and one can use virtual servers or virtual machines instead.

There are various methods to retrieve the connection tables on each individual server and the most suitable method for a particular server will be chosen. In any case, some mechanism are agentless and require no new software to be installed on the servers

2

[This page contains 1 picture or other non-text object]

Page 3 of 4

themselves. An application can be written to collect data directly from the network and analyze the packets for source, destination, and protocol information; an application can seek out and record SNMP information such as from the iso.org.dod.internet.mgmt.mib-2.tcp.tcpConnTable and the iso.org.dod.internet.mgmt.mib-2.udp.udpTable entries ; an application can seek out information using remote command execution (e.g., ssh, Telnet, or Microsoft Monad); or an application may use other native resources peculiar to a target operating system or network component (router, bridge, etc.).

The information collected would be: ServerIP address, Local Address, Local port, Foreign address, Foreign port, and Connection state . This information would be analyzed in various ways, for example, using graph theory algorithms, to determine application-to-application or appl...