Tutor on Use of SNMP SNMP architecture for Free and CIM and WBEM

Tutor on Use of SNMP SNMP architecture  for Free and CIM and WBEM

The Simple Network Management Protocol (SNMP) was ratified by the Internet Engineering Task Force (IETF) and was originally a standard for the management of IP networks. Although there are, even now, protocols for this field that can be better adapted to the devices to be managed, SNMP is still the most frequently used protocol due to its simple architecture. Perhaps this is also the reason why SNMP has gained such great importance

in the field of storage networks. Management information bases In SNMP, management information is organized into so-called management information bases (MIBs). An MIB is a collection of so-called managed objects. Managed objects are represented by variables. Since an MIB can also exist as precisely one managed object, managed objects are also called MIB objects or even just MIB. In this manner a managed object is identified with its MIB. We differentiate between two types of managed objects:

• Scalar objects Scalar objects define precisely one object instance.

• Tabular objects Tabular objects bring together several related object instances to form a so-called MIB table. All the MIBs on the market can be divided into two groups:

• Standard MIBs General management functions of certain device classes are covered by standard MIBs.

• Private or enterprise MIBs Private or so-called enterprise MIBs permit individual companies to develop their own MIBs. Management functions can thus be offered that are specially tailored to individual devices and extend beyond the functions of the standard MIBs. In order to differentiate between the individual managed objects there is an MIB hierarchy with a tree structure (Figure 8.4). The various standardization organizations form

the top level of the tree. From there, the tree branches to the individual standards of this organization and then to the actual objects, which form the leaves of the hierarchy tree. In this manner an individual MIB object can be clearly defined by means of its position within the MIB hierarchy. In addition, each managed object is given a unique identification number, the so-called object identifier. The object identifier is a sequence of digits

that are separated by points. Each individual digit stands for a branch in the MIB tree and each point for a junction. The full object identifier describes the route from the root to the MIB object in question. For example, all MIB objects defined by the IBM Corporation hang under the branch 1.3.6.1.4.1.2 or in words iso.org.dod.internet.private.enterprises.ibm (Figure 8.4). Thus all object identifiers of the MIB objects that have been defined by IBM Corporation begin with this sequence of numbers.

SNMP architecture

SNMP defines three components (Figure 8.5): • Managed device

A managed device is a connection device or an end device that carries an SNMP agent. Managed devices collect and save their management data in an MIB.

 • SNMP agent The SNMP agent is a software module that runs on a managed device. Its task is to translate the MIB information collected by the managed device into an SNMP- compatible form upon request.

• Network management system (NMS) An application for the monitoring and configuration of various managed devices runs on the NMS. If the NMS knows the MIB of the device to be managed, then it can interrogate or change individual MIB objects by appropriate requests to the SNMP agent. The information regarding the MIB in question is loaded into the NMS in advance by means of a so-called MIB file. In our context the NMS corresponds with the management system. However, even the Syslog-Daemon of a Unix system can be

used as an NMS. SNMP operations SNMP defines four operations for the monitoring and configuration of managed devices:

• Get Get is used by NMS in order to request the values of one or more MIB object instances from an agent.

• GetNext GetNext allows the NMS to request the next value of an object instance within an MIB table from an agent after a prior Get request.

• Set Set allows the NMS to set the value of an object instance.

• Trap The Trap operation allows the SNMP agent to inform the NMS independently about value changes of object instances. Security with SNMP

SNMP has no secure authentication options. Only so-called community names are issued. Each NMS and each SNMP agent is allocated such a community name. The allocation of community names creates individual administrative domains. Two communication partners (an NMS and an SNMP agent) may only talk to each other if they have the same  community name. The most frequently used community name is 'public'.

If, for example, an NMS makes a Set request of an SNMP agent, then it sends its community name with it. If the community name of the NMS corresponds with that of the SNMP agent, then this performs the Set operation. Otherwise it is rejected. Thus anyone who knows the community name can make changes to the values of an object instance. This is one reason why many providers of SNMP-capable devices avoid the

implementation of Set operations on their SNMP agent, because community names only represent a weak form of authentication. In addition, they are transmitted over the network unencrypted. Application in storage networks An SNMP agent can be installed upon the various devices such as servers, storage devices or connection devices. SNMP thus covers the entire range of devices of a storage network.

• Discovery A management system can address the SNMP agent on a connection device in order to interrogate the properties of a device and to obtain information from it about the connected devices. It thus also gets to know the immediate neighbours and with that information can continue scanning the end devices insofar as all devices lying on this route support SNMP. In this manner a management system finally obtains the topology

of a storage network.

• Monitoring SNMP also supports the management system in the monitoring of the storage network. The SNMP agents of the end nodes can be addressed in order to ask for device-specific status information. Corresponding error and performance statistics can thus be requested

from the SNMP agent of a connection node, for example, from a Fibre Channel switch.

• Messages Due to the Trap operation SNMP is also familiar with the concept of messages. In SNMP jargon these are called traps. In this manner an SNMP agent on a device in the storage network can send the management system information via IP if, for example, the status has changed. To achieve this only the IP address of the so-called trap recipient has to be registered on the SNMP agent. In our case, the trap recipient would be the

management system. In contrast to the RSCN, in the in-band management of a Fibre Channel SAN, in which all registered nodes are informed about changes to a device by means of a message, an SNMP trap only reaches the trap recipients registered in the SNMP agent. In addition, the connection-free User Datagram Protocol (UDP) is used for sending a trap, which does not guarantee the message delivery to the desired recipient.

• Configuration SNMP also offers the option of changing the configuration of devices. If the device MIB is known, this can be performed by changing the value of the MIB variables on a managed device by means of the Set operation. Standard MIBs for Fibre Channel SAN There are two important standard MIBs for the management of a Fibre Channel SAN:

• Fabric element MIB This standard MIB developed by the Storage Networking Industry Association (SNIA) is specialized for Fibre Channel switches and supplies detailed information on port states and port statistics. Likewise, connection information can be read over this.

• Fibre Channel management MIB This MIB was developed by the Fibre Alliance. It can be used to request connection information, information on the device configuration or the status of a device. Access to the fabric name server and thus the collection of topology information is

also possible.

 CIM and WBEM

Today, numerous techniques and protocols are used for system management that, when taken together, are very difficult to integrate into a single, central management system. Therefore, numerous tools are currently used for system management that all address only a subsection of the system management. Web Based Enterprise Management (WBEM) is an initiative by the Distributed Management Task Force (DMTF), the aim of which is to make possible the management of the entire IT infrastructure of a company (Figure 8.6). WBEM uses web techniques such as XML and HTTP to access and represent management information. Furthermore, it defines interfaces for integrating conventional techniques such

as SNMP. WBEM defines three columns that standardize the interfaces between resources and management tools (Figure 8.7):

• Common Information Model (CIM) The Common Information Model (CIM) defines an object-oriented model that can describe all aspects of system management. It is left up to the components participating in a WBEM environment how they realize this model, for example in C++ or in

Java. The only important thing is that they provide the semantics of the model, i.e. provide the defined classes and objects plus the corresponding methods outwards to other components.

• xmlCIM Encoding Specification The xmlCIM Encoding Specification describes the transfer syntax in a WBEM environment. It thus defines precisely the XML formats in which method calls of the CIMobjects and the corresponding returned results are encoded and transmitted. As a result, it is pos-

sible for two components to communicate with each other in the WBEM architecture, regardless of how they locally implement the CIM classes and CIM objects.

• CIM operations over HTTP Finally, CIM operations over HTTP provide the transport mechanism in a WBEM environment that makes it possible for two components to send messages encoded in xmlCIM back and forth. This makes it possible to call up methods of CIM objects that are located on a different component. Common Information Model (CIM) CIM itself is a method of describing management data for systems, applications net-

works, devices, etc. CIM is based upon the concept of object-oriented modelling (OOM). Understanding CIM requires knowledge of OOM. OOM is based upon the concept of  object-oriented programming. However, OOM is not a programming language, but a formal modelling language for the description of circumstances of the real world on abstract level. In OOM, real existing objects are represented by means of instances. An instance has certain properties, which are called attributes, and allows for execution of specific actions, which are called methods. A class in OOM is the abstract description of an instance, i.e. it is the instance type. To illustrate: a Porsche Cabriolet in a car park is an object of the real world and is represented in OOM as an object instance. A Porsche Cabriolet is of the type car, thus it belongs to the class car. Thus, from an abstract point of view a Porsche Cabriolet – just like a BMW, Mercedes, etc. – is nothing more than a car. We hope that Porsche fans will forgive us for this comparison!

Classes can have subclasses. Subclasses inherit the attributes and methods of the parent class (Figure 8.8). Examples of subclasses of the class car are sports cars or convertibles. An inherited property in this case is that they have a chassis and four wheels. As we see, OOM can also be used to great effect for the description of non-computer- related circumstances. In order to describe complex states of affairs between several classes, a further construct is required in OOM: the association (Figure 8.8). An association is a class that contains two or more references to other classes. In that way it represents a relationship between two or more objects. Such relationships exist between individual classes and can themselves possess properties. Let us consider the class 'person'. In the language of OOM 'man' and 'woman' are subclasses of the parent class 'person'. A relationship between the class 'man' and the class 'woman' could be 'marriage'. A property of this relationship would be the date of the wedding, for example. Complex management environments can be described in abstract terms with the aid of the class and relationship constructs. An abstract description of a management environment using OOM is called a schema in CIM. CIM has three different types of schema: the Core Schema (also known as Core Model), the Common Schema (also known as Common Model) and further Extension Schemas The basis of the CIM model is the Core Schema. The Common Schema supplies abstract classes and relationships on the basis of the Core Schema for all those components that the different management environments have in common. By means of Extension Schemas the abstract basic Core Schema and Common Schema can be

concretized and expanded The Core Schema defines the abstract classes and their relationships necessary for the description and analysis of complex management environments. The Core Schema specifies the basic vocabulary for management environments. For example, the Core Schema specifies that in a management environment elements to be managed exist, which themselves have logical and physical components. A strict differentiation is always made between logical and physical units or properties. Systems, applications or net- works represent such elements to be managed and can be realized in CIM as extensions of this Core Schema. The Core Schema thus yields the conceptual template for

all extensions. The Common Schema builds upon the Core Schema to supply the abstract classes and relationships for all those components that the different management environments have in common, regardless of the underlying techniques or implementations. The abstract classes of the Common Schema all arise by inheritance from the classes of the Core Schema. The Common Schema defines the following submodels:

• System model The system model brings together all objects that belong in a management environment.

• Device model The device model represents the logical units of such a system that provide the system functions on a purely logical level in order to remain independent of the physical implementation. This makes sense because physical aspects of devices change but their importance on a logical level generally remains the same for the management of a system as a whole. For example, a Fibre Channel switch differs from an iSCSI switch

only in terms of its physical properties. The logical property of acting as a connection node to connect other nodes in the network together is  ommon to both components.

• Application model The application model defines the aspects that are required for the management of applications. The model is designed so that it can be used to describe both single location applications and also complex distributed software.

• Network model The network model describes the components of the network environment such as topology, connections and the various services and protocols that are required for the operation of and access to a network.

• Physical model  The physical model makes it possible to also describe the physical properties of a management environment. However, these are of low importance for the management, since the important aspects for the management are on a logical and not a physical level. Extension Schemas permit the abstract basic Core Schema and Common Schema to be further concretized and expanded. The classes of the Extension Schema must be formed by inheritance from the classes of the Core and Common Schemas and the rules of the CIM model have to be applied. In this manner it is possible to use CIM for the description of the extremely different management data of the components of a storage network, which  can be used for management by means of the following WBEM architecture.