Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/02—Standardisation; Integration
  • H04L41/024—Standardisation; Integration using relational databases for representation of network management data, e.g. managing via structured query language [SQL]

Definitions

• the invention relates to a method of collecting information of an infrastructure.
• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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.
• OS Operating System
• 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.
• wwn 16 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.
• the Host 12 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.
• 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.
• 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.
• 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.
• API Application Program Interface
• 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.
• 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.
• ssh protocol 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.
• 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.
• SQL Structure Query Language
• PLSQL Structure Query Language
• the relational 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.
• 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.
• 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.
• 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.
• insert, delete and update The behaviour of the triggers is described in the following.
• 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, 1 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) ; ⁇

Landscapes

• Engineering & Computer Science (AREA)
• Databases & Information Systems (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Magnetic Resonance Imaging Apparatus (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=38480530

Family Applications (1)

Country Status (2)

Family Cites Families (3)

• 2007
  • 2007-06-01 EP EP07722639A patent/EP2030368A2/de not_active Withdrawn
  • 2007-06-01 WO PCT/DK2007/000262 patent/WO2007140773A2/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events