Title: Method of information collection of a complete infrastructure

Technical Field

The invention relates to a method of collecting information of an infrastructure.

Background

Today's IT installations cover plenty of different components as applications, applica- tion servers, message channels, databases, servers, LAN (Local Area Network) infrastructures and SAN (Storage Area Network) infrastructures.

These components are typically documented in tools as Word, Excel or other equivalent tools, aimed at specific goals. The documentation process is a manual process, which can be time-consuming. Due to the manual process and human mistakes, a number of errors could be introduced in this documentation.

An inaccurate picture of the infrastructure can lead to a poor performance, bad utilisation of devices, increased and time-consuming recovery processes.

A number of tools have been used to try to compensate this by having an agent on each server and communicating traditionally with devices through SNMP (Simple Network Management Protocol).

Disclosure of the Invention

The object of the invention is to provide a new approach for solving these problems in IT installations by means of an automated process, characterised by providing a data model of the infrastructure, said data model consisting of tables of a relation data base and by the information being retrieved automatically by a daemon process through a protocol.

The information for this process may according to the invention be collected automatically through the telnet or the SSH protocol. These protocols are normally used by per- sons skilled in the art as a part of a manual process.

The method according to the invention is an approach of information collection for a complete infrastructure. By correlating the information collected, the person skilled in the art can more easily obtain an accurate picture of the interconnections of the infrastructure without human interaction.

By introducing technical rules, describing standards for technical setup known to persons skilled in the art, the system will be able to validate towards the current configuration by performing some automatic SQL (Structured Query Language) processing of the correlated data model.

By creating some of the documentation not possible to be collected automatically as consoles, the system can check whether that information is valid, simply by trying this process as an automated process.

By introducing a time documentation in the information collected and correlated, the person skilled in the art is able to make searches on changes in the data model of a server and related components for a specific time period. As a result, a quick picture is obtained of the changes in the infrastructure, which is useful to diagnosing errors.

By having persons skilled in the art to ask for specific reports through a portal which is adapted to retrieve information from the data model, an instant overview can be obtained. This information is specified based on customers' choice and is the definition and the communication performed in the previous manually performed process.

Brief Description of the Drawings

The invention is explained in detail below with reference to the drawings, in which

Fig. 1 illustrates a model of a LAN infrastructure,

Fig. 2 illustrates a model of a SAN infrastructure,

Fig. 3 illustrates an architecture of the information system, and

Fig. 4 illustrates a window support for the information system.

Best Modes for Carrying Out the Invention

Fig. 1 illustrates a model of the relations between a number of components of a LAN infrastructure. Some of the components include tables with a number of keys illustrat- ing the relations between the tables. PK is a primary key, and FK is a foreign key related to another key.

The entity table 1 illustrated in Fig. 1 includes information entered manually by the user. The model illustrated in Fig. 1 also includes device specific tables referring to the entity table 1. These tables are a LAN_Switch 3 or a Host 5. A 1 G and a 2G scheduler table connected to the entity 1 include information on how to connect to the entity and at what time.

The scheduler table 2G contains information on when the entity should be polled. This information is entered manually via a GUI (Graphic User Interface). The information in table 2G contains enough information to pass it to a daemon process capable of keeping track of time and scheduling the task. The information is loaded from the table to the daemon process each time the scheduled is changed by user interaction. The information in table 2G is interpreted by the scheduler process as the following table in- dicates.

For an entity of the device type LAN_switch 3, the LAN_Switch 3 table will be the first table to be populated with automatic collected information.

The LAN_Switch 3 can have one or several ports. This is obtained by having a table LAN_Switch_Port 2 including an FK key to the LAN_Switch 3.

By using an output in form of a command from the LAN_Switch 3, the system will be able to see which MACs has been logged into which ports on LAN_Switch 3. A one to many MAC (Media Access Control) can be logged into LAN_Switch_Port 2, and the same MAC can exist on more than one port. This illustrated by the line MR2. The rela- tions are handled by means of a MAC_LAN_SWITCH_PORT 4 table connected to MAC 6. This table 4 includes an FK pair (FK1 and FK2). Each FK pair consists of a relation to said MAC table 6 and to an associated port LAN_Switch_Port 2.

As a result, a path through the data model from the entity 1 to MAC 6 has been ob- tained.

Data collected from a server are entered into the Host table 5. The Host can have one to many NIC 7 (Network Interface Card). The information is contained in NIC 7 FK3 Host_PK. NIC 7 can have one and only one assigned MAC 8, which includes FK2 MAC_PK.

As a result, a complete route has been established by means of correlated information fetched from LAN_Switch 3 and table Host 5. A report can display the relations between the devices and, hence, how the devices are interconnected.

The following is an explanation of the other tables, adding more information to the model of the structures.

NIC 7 can have zero to many IP 11 A, and one IP can belong to two NICs in case of a cluster. This is illustrated by the line MR3. These relations are included in a NICJP table 10A, each row containing a pair of two FK pointing to NIC 7 and IP_v4 11A.

An ARP (Address Resolution Protocol) 12A table connected to MAC 6 includes information on how MAC should be resolved to IP. This is a very simple relation including a pair of two FK's, each pair pointing to a MAC 6 row and a IP_v4 11 A row.

The tables 10B-12B represent a feature for the switch when using a VLAN. For LAN_Switch 3 we can create a VLAN 10B on the switch. We can have many to many VLAN for each LAN_Switch_Port 2. This is illustrated by the lines MR1 and MR4. The information is included in VLAN_Port 11 B with a pair of two FK respectively FK1 and FK2. VLAN 10B can span many switches. This is included in the switch_vlan_relation_table 12B.

An R table includes a feature of some OS (Operating System) flavours where you can team NICs and thereby obtain redundancy on configured NICs.

Table 8 contains a default router configuration for the Host 5 in question. Table 8 includes an FK1 referring to the Host 5 table.

The SAN model in Fig. 2 illustrates the relations between the different components of an infrastructure related to a SAN infrastructure.

The entity table 11 is the entry point for a Host 12 and a san_switch table 13. The Host 12 and the san_switch table 13 includes an FK to the entity table 11.

The san_switch 13 includes one to many ports. These ports are included in table 14, and each port includes an FK1 to a corresponding san_switch 13.

By using a command on the san_switch 13, one can extract wwn 16 logged into each port 14. A single port can have many wwn logged in, and in obscure configurations the same wwn might exist on more than one port. This is supported by a port_wwn 15 table and the FK pairs FK1 and FK2.

When extracting information from Host 12, an FK to the entity 11 will be created. The Host 12 will be the first table to be populated. Each Host can have zero to many discs 17. Each disc 17 includes an FK to the Host 12. A disc 17 can be either a local disc or a SAN attached disc. If the disc 17 is a SAN disc it will consist of a one to many LUN's (Logical Unit Number) in table LUN 18.

Each LUN 18 can have information about of WWN, this being included in FK3. The FK2 table 18 may point to the WWN used for communication for this LUN. The FK1 will point to the associated discs 17.

Each Host can have zero to many HBA 20. Each HBA will have FK1 pointing to Host 12. Each HBA 20 will have wwn assigned; this is contained in FK2 table 20.

The san_switch 13 contains one to many ports. These ports are included in the table port. The table port contains an FK to the table san_switch 13. Each port has one to many wwn registered in each port. This information is included in a relations table port_wwn 15. Each registered wwn is populated int the wwn table, if it has not been registered previously by a Host.

Thereafter, the san_switch 13 related tables includes information specific for zones and zonesets. A san_switch can only have one active zonezet at a time.

Tables 30-34 include the zone configuration of the switch. A san_switch 13 will always be connected to one fabric in table fabric 30. A fabric can coexist of many zonesets 31, each zoneset including a number of zones 33. Each zone consists of a number of wwn and/or ports. This is illustrated by tables 34, 32, 33. The FK1 in tables 32 and 34 are the keys referring to the zone table zones 33.

By having a SAN model populated, the user is able to see how the different components are interconnected.

Fig. 3 shows the complete architecture from a high level. The different components are in communication with devices, and it is illustrated how the data are transmitted through the system.

A device can be of any available type, of a SAN, a LAN, application, database or a server. The device will establish a communication link to a physical device and a database 21. When the information is collected from the physical device the information is transmitted to the database 21 through a database logic in an API (Application Program Interface) 22. Hence, the device does not need information on how data is organised in the database 21.

Status and configuration utility are provided through a GUI (Graphic User Interface) 22. The configuration setup and the status messages are transmitted via the database 21.

Fig. 4 illustrates information to be added when a solution is available and has been verified.

The method of collecting information of an infrastructure is as follows:

The information is collected via telnet or ssh.

The retrieval process is automated and scheduled by a daemon scheduler process.

If telnet has been specified by the user, a connection to the device is provided via the telnet protocol and commands are sent to the device and processed.

If ssh protocol has been specified, an ssh connection is established to the device. The commands are sent and processed by a textual processing language. Other connec- tion protocols are also possible.

If none methods are specified, the automated process will try and see which one is available for the device; the one with the highest priority is used.

The priority is selected by the user and will normally be the one with the highest security.

The information fetched from the device is placed into a dynamic structure, which is transmitted to API.

The API is aware of the data model and the passed dynamic structure into the normalised data model using SQL (Structure Query Language)/PLSQL. By using this approach, new devices will not need to be added to API, since API only passes the information delivered, and this information structure is delivered by using the same ap- proach for devices of the same type.

Data model

Reference is made to the relational model as to how the data is organised. The data model is updated by setting an active column and data when data is populated for each table. As a result, the user is able to see the deleted objects since the last run and when.

Before the data model is populated, all rows related to the updated entity with an active column is set to inactive.

Information retrieval

The process of information retrieval specifies the documentation required between the parties responsible for the infrastructure. A report is presented on a portal based on input from customers and technical personnel requirements.

Having the normalised data model in the database with correlated information, a validation process can be initiated. The validation process is scheduled by a time schedule specified by the user. The process is handled by the said scheduler daemon process.

Console information has to be entered manually. This information is validated by initiat- ing an automatic check.

This process is initiated by a daemon process with a time frame specified by the user.

The validation process is specified by a set of technical rules, and each technical rule is specified by a statement specifying known issues in an IT environment. An example of these rules may be that, for instance, NIC is configured in the same way as a corresponding point in LAN port. Do ZONES in the SAN environment consist of two devices of the types host. These rules are added on customer's choice according to the requirements of the customer.

A technical rule can trigger an action on customer's choice.

By introducing a time dimension in the correlated data model, the user can go back in time and run reports informing the user of how entities have changed over time and the changes. Moreover, the user can display all changes for all related entities.

Each table in the information model has a trigger implemented for the purpose of keeping a time record of changes in the environment.

Each table in the information has a corresponding mirror table called < table name >_ hist used to keep track of the times.

Each mirror table has in addition to the columns in the current configuration (except the active and data column) a start date and an end date. The start date is defined as the date of creation of the row. The end date is set to open when the configuration is active and to the end date when the configuration is closed.

The triggers are triggered as an event using standard behaviour from the chosen database. The triggers are implemented as an event in the following conditions: insert, delete and update. The behaviour of the triggers is described in the following.

On condition of an insert new row in the current configuration data model in a table, the following behaviour is triggered by the database.

An insertion is made in a history table (< table name>)_hist), setting the same values of the fields as in the corresponding table. The start date column is set to the current time. The end date is set to open. Hence, the configuration is shown as active.

On condition of an update existing row in the current configuration data model, the following behaviour is triggered by the database. The active row in < table name >_hist is closed by setting the end date to the current time.

An insertion is made in history table (< table name >)_hist), setting the same values of the fields as in the corresponding table. The start date column is set to the current time. The end date is set to open. Hence, the configuration is shown as active.

On condition of a delete row in the current configuration data model, the following behaviour is triggered. The active row in the <table name>_hist is closed by setting the end date to the closed (current time).

The examples of triggers are as follows:

drop trigger tg_api_san_switch_srt_a_upd$$

create trigger tg_api_san_switch_srt_a_upd after update on api_san_switch_srt for each row begin declare xTS timestamp; set xTS = sysdate ( ) ;

SUBSTITUTE SHEET

if (new.mode != old.mode or new. state != old. state or new. domain != old. domain or new. fabricosver != old. fabricosver or new. kernel != old. kernel or new. id != old. id or new.name != old. name or new.module_uc_id != old.module_uc_id or new. thoitimas != old.thommas or new.azone ! = old.azone or new. type != old. type or new. role != old. role or new.beacon != old.beacon or new.entity_uc_id != old.entity_uc_id ) {

update api_san_switch_srt_hist set enddate=xTS where orgid=new.id and enddate is NULL;

insert into api_san_switch_srt_hist (startdate, enddate, action,mode, state, domain, fab ricos- ver, kernel, id,name,module_uc_id, thoinmas, azone, type, role, beacon, entity_ uc_id) values (xTS,NULL, ¹ U' , new.mode, new. state, new. domain, new. fabricosver, new. ker nel , new .id, new.name, new.module_uc_id, new. thommas , new. azone, new. type, ne w. role, new. beacon, new. entity_uc_id) ; }

end$$

drop trigger tg_api_san_switch_srt_a_del$$

create trigger tg_api_san_switch_srt_a_del after delete on api_san_switch_srt for each row begin declare xTS timestamp; set xTS = sysdate ( ) ;

update api_san_switch_srt_hist set enddate=xTS, action='D' where orgid=old.id and enddate is NULL;

end$$

SUBSTITUTE SHEET