sv concepts

PRIMERGY ServerView Suite

ServerView SuiteBasic Concepts A. MatthäusFujitsu Siemens Computers GmbH München81730 Muniche-mail: email: [email protected].: (089) 61001-158Fax: (++49) 700 / 372 00000 Sprachen: En

Edition February 2005

Comments… Suggestions… Corrections…The User Documentation Department would like toknow your opinion of this manual. Your feedback helpsus optimize our documentation to suit your individual needs.

Fax forms for sending us your comments are included inthe back of the manual.

There you will also find the addresses of the relevantUser Documentation Department.

Certified documentation according to DIN EN ISO 9001:2000To ensure a consistently high quality standard anduser-friendliness, this documentation was created tomeet the regulations of a quality management system which complies with the requirements of the standardDIN EN ISO 9001:2000.

cognitas. Gesellschaft für Technik-Dokumentation mbHwww.cognitas.de

Copyright and Trademarks
Copyright © 2005 Fujitsu Siemens Computers GmbH.
All rights reserved.Delivery subject to availability; right of technical modifications reserved.

All hardware and software names used are trademarks of their respective manufacturers.

This manual is printed on paper treated with chlorine-free bleach.

http://www.cognitas.de

Contents1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1 Server Management Components . . . . . . . . . . . . . . . . . 32.1.1 Managed Servers with Agents . . . . . . . . . . . . . . . . . . . 52.1.2 Management Applications . . . . . . . . . . . . . . . . . . . . . 52.1.3 Management Consoles . . . . . . . . . . . . . . . . . . . . . . 62.1.4 Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Management Principle: Agent and Management Station . . . . . 72.2.1 Management Cycle . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Interface Between Monitoring and Analysis . . . . . . . . . . . 112.2.3 Interface Between Adaptation and Execution . . . . . . . . . . 122.2.4 Autonomous Management on the Server . . . . . . . . . . . . 142.3 Hierarchical Configurations . . . . . . . . . . . . . . . . . . . 152.3.1 Local Management . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Point-to-Point Management . . . . . . . . . . . . . . . . . . . 152.3.3 Central Management . . . . . . . . . . . . . . . . . . . . . . 182.3.4 Cascaded Management . . . . . . . . . . . . . . . . . . . . . 202.3.5 Integration Into Other Management Systems . . . . . . . . . . 212.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.1 SNMP - Simple Network Management Protocol . . . . . . . . . 232.4.2 CIM (Common Information Model) . . . . . . . . . . . . . . . 272.4.3 IPMI - Intelligent Platform Management Interface . . . . . . . . 302.4.4 PXE - Preboot Execution Environment . . . . . . . . . . . . . 322.4.5 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.4.6 HTTP - Hypertext Transfer Protocol . . . . . . . . . . . . . . . 332.4.7 SSL - Secure Socket Layer . . . . . . . . . . . . . . . . . . . 342.4.8 SOAP - Simple Object Access Protocol . . . . . . . . . . . . . 352.4.9 ITIL - IT Infrastructure Library . . . . . . . . . . . . . . . . . . 362.5 Helpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.1 DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.2 PXE Boot Server . . . . . . . . . . . . . . . . . . . . . . . . . 382.5.3 RARP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5.4 TFTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5.5 Mail Server (MAPI or SMTP) . . . . . . . . . . . . . . . . . . 392.5.6 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.7 MS Excel, Access or SQL Databases . . . . . . . . . . . . . . 402.5.8 Dynamic Reconfiguration (DR) . . . . . . . . . . . . . . . . . 40

Contents

2.6 Management Mode . . . . . . . . . . . . . . . . . . . . . . . . 412.6.1 Management Mode 1 . . . . . . . . . . . . . . . . . . . . . . . 412.6.2 Management Mode 2 . . . . . . . . . . . . . . . . . . . . . . . 422.6.3 Management Mode 3 . . . . . . . . . . . . . . . . . . . . . . . 432.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Positioning of ServerView . . . . . . . . . . . . . . . . . . . 473.1 ServerView Suite . . . . . . . . . . . . . . . . . . . . . . . . . 493.2 Integration Into Other Management Systems . . . . . . . . . . . 493.3 Integration of Other Components . . . . . . . . . . . . . . . . . 50

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

1 IntroductionThe PRIMERGY and PRIMEPOWER ServerView suite provides products for central administration of servers in a network. This manual contains general information about the basic principles of the server management architecture. The topic is dealt with in the context of the ServerView suite and is intended to give you an introduction.

The Section „Basic Concepts“ first of all categorizes the server management components and presents the management concepts that can be realized with them. The standardized protocols and programs that are a requirement for com-munication in a management system are then described. You will also be given an overview of how these are used in the ServerView suite. A further section deals with the management modes used for remote access.

The Section „Positioning of ServerView“ provides an outline of the links to other enterprise management systems.

As well as providing a quick overview, the manual is designed to allow you to gain a deeper basic understanding of the topic.

Some passages of text therefore have a gray background. They are intended to go deeper into a particular issue and are designed for experts or readers who want to find out more details about the topic. For normal use of the Ser-verView suite, these paragraphs can be skipped.

1

2 Basic ConceptsThe section provides an overview of the general principles and concepts in server management. It primarily deals with the topics that must be understood in order to achieve optimum planning, configuration and operation of PRIMERGY and PRIMEPOWER systems.

2.1 Server Management Components

Server management components can be divided into four categories:

– managed servers,

– management applications,

– management consoles and

– helpers.

Figure 1 is a schematic view of the interaction of these server management components.

3

4

Server Management Components Basic Concepts

Figure 1: Server management components

The components communicate with one another using protocols. They can be installed on different computers. However, it is also possible to install several components from different categories on a single computer. The four categories are briefly described below. Later, you will find out how they can be combined to form different network topologies and about their advantages and disadvan-tages.

Agent

Console

Agent Agent

ManagementApplication

Console

HELPERS

Helper

Helper

MANAGEMENTCONSOLES

MANAGEMENTAPPLICATIONS

MANAGED SERVERS WITH AGENTS



Basic Concepts Server Management Components

2.1.1 Managed Servers with Agents

To manage a server, at least one agent normally has to be installed on it. Agents that are installed on servers allow them to be remotely monitored and managed. To do this, the agent provides an interface, which it uses to

– receive requests to provide information

– deliver requested information

– receive requests to execute actions

– send unprompted messages (traps) as soon as it detects a special situation on the managed server

Agents communicate with management applications. Agents receive jobs to deliver information or execute actions from management applications. If they detect special situations, they send unprompted messages (e.g. traps). Agents thus execute jobs from management applications or supply them with infor-mation, i.e. they are the "extended arm" of the management applications on the servers to be monitored.

Managed servers communicate with the management applications using protocols such as SNMP, CIM-based protocols, IPMI (see also Section „Protocols“ on page 23).

2.1.2 Management Applications

Tasks from management applications include

– Performance of complex configurations

– Collection of data from several systems

– Consistency checks

– Graphical representation of information

– Responses to trap situations

– Installation of servers

– Server updates

– Creation of archives, reports etc.

5

Server Management Components Basic Concepts

Management applications communicate with:

– Management consoles

Consoles are the interface to administrators. All the functions of the management applications are available via consoles. The web browser is a frequently used console. In this case, the management application commu-nicates with the console using HTTP/HTML or HTTPS/HTML (see also Section „Protocols“ on page 23).

– Agents on managed servers

Management applications communicate with agents in order to obtain infor-mation from managed servers, read log files, execute actions, make settings, obtain information about special statuses etc.

– Other management applications

The components of the ServerView suite handle more complex tasks through co-operation between management applications. Here, management applications use services provided by other management applications. The protocols used are SOAP (see also Section „Protocols“ on page 23) or proprietary protocols.

– Helpers (see also Section „Helpers“ on page 37)

Management applications can also use services from helpers, for example services provided by operating systems. To do this, they communicate using the interfaces provided by these helpers. Repositories can be a component of management applications or may also be implemented as helpers.

Examples of PRIMERGY ServerView management applications are: ServerView Manager, ServerView S2, Download Manager, AlarmService, RemoteDeploy and Archive Manager.

2.1.3 Management Consoles

Consoles can be remote from management applications and thus allow the administrator to access the services provided by the ServerView management applications from any location and at any time.

Examples of management consoles used with the PRIMERGY ServerView Suite include web browsers, Telnet consoles or pocket PCs. In the PRIME-POWER suite, web browsers, LAN consoles and system management consoles are used as management consoles.

6

Basic Concepts Management Principle: Agent and Management Station

2.1.4 Helpers

Services or programs that are not actually part of the ServerView suite but are or can be used when operating the ServerView suite are referred to as helpers.

Examples of helpers used in the ServerView Suite include the DHCP service (cross-reference) and the TFTP service (cross-reference) that are used by RemoteDeploy, or Microsoft Excel/Access, which can be used to manually edit files created using PRIMERGY/PRIMEPOWER ServerView. Dynamic reconfig-uration (DR) is a further helper used in the PRIMEPOWER ServerView suite.

2.2 Management Principle: Agent and Management Station

To explain the management principle, it makes sense to further abstract the categories presented above. The abstraction in this section is based on the architecture description in the SNMP standards. Here, there are agents on monitored elements (server, network components etc.) and management stations:

– Agents

Agents execute tasks from the management applications on the managed servers.

– Management station

Management applications, management consoles and helpers that co-operate with one another are summarized in a single unit and referred to as management stations. The management station is considered to be the counterpart of the agents, where the management station is a logical entity that can physically run either on a single computer or distributed across several computers.

7

Management Principle: Agent and Management Station Basic Concepts

Based on this agent and management station principle, the procedure for management operations is explained below, using the examples of certain typical actions.

2.2.1 Management Cycle

Server management is a continuous process, which can be represented schematically by the cycle shown in Figure 2.

Figure 2: Management cycle

The four phases in the cycle are monitoring, analysis, adaptation and execution.

– Monitoring provides the current management information for the managed server and its components.

– Analysis involves deriving findings from this information. Examples include exceeding threshold values, prediction of resource bottlenecks and deter-mining the cause for a sequence of traps.

– Adaptation comprises planning the actions are to be used in response to a situation detected in the analysis phase. Examples of adaptation could be reconfiguration, restarting services, stopping servers, re-installation of servers, update installations, changing the allocation of resources etc.

– Execution refers to the actual implementation of the planning from the adaptation phase on the managed server.

Particularly for the analysis and adaptation phases, knowledge and rules are necessary:

Knowledge& Rules

Monitoring Execution

Analysis Adaptation

8


– Knowledge is made up of an understanding of the interrelationships between components, knowledge of the behavior of components or the significance and effect of various configurations. Knowledge also includes an awareness of what impact different actions could have and any side effects they might have.

– Rules comprise instructions, that are either stated directly in the form of specifications or derived service level agreements, using knowledge.

The management cycle therefore includes two communication interfaces between the agent and the management station, shown on the left-hand side of Figure 2 between monitoring and analysis and on the right-hand side between planning and execution. These two interfaces are dealt with in more detail in the following sections.

9


In principle, this cycle is run through continuously, whereby the "driver" can be at two points.

– Analysis (internal driver)If a situation necessitating adaptation s detected in the analysis phase during the ongoing operation of a system, a new run of the cycle is generated.

– Planning (external driver)If the administrator makes a decision, for example to install an additional server or change the allocation of resources following amendments to a service level agreement, a new run of the cycle is triggered starting from the planning phase.

This means that the assignment of these phases to the agent and management station management principle can easily be derived:

– Agent

The agent is primarily used for the monitoring and execution phases. In some cases, it also contributes to the analysis phase, e.g. threshold value monitoring, sending traps or through the PDA functionality (Prefailure Detection Analysis) of ServerView agents. However, alternative tools or actions can also be used to execute planning decisions, such as reconfiguration of the operating system or manual replacement of hardware components.

– Management station

The administrator and his knowledge is crucial in the analysis and adaptation phases. He uses the management station to obtain the infor-mation necessary for the analysis from the agents and also to implement the planning formulated in the adaptation phase on the systems via the agents. Routine management tasks are becoming increasingly automated. In such cases, the analysis and adaptation phases run completely on the management station with no intervention by the administrator. Here, the ServerView suite provides the opportunity to configure the Alarm Service in such a way that scripts are automatically executed when particular traps are received. For PRIMEPOWER, EventAdmin also makes it possible to automatically move system boards dynamically between PRIMEPOWER partitions according to the system load, in line with set rules.

10


2.2.2 Interface Between Monitoring and Analysis

At this interface, agents co-operate with the management station to transport information from the monitoring phase into the analysis phase. As is shown below, this can involve permanent communication, particularly in the case of polling.

Polling

Management protocols such as SNMP or CIM are primarily used in polling mode. In this mode, the initiative comes from the management station, which requests information from the agent. Under normal circumstances, the agent then delivers the required information to the management station. In the analysis phase, a decision is then made as to whether a situation exists that necessitates a planning phase. If so, the management cycle is triggered and the planning phase commences.

Regardless of this, the process is executed repeatedly in the sense that the management station regularly requests and analyzes current information from the agent at particular time intervals. If the time intervals used for this polling are too short, this can lead to additional network load on the one hand and to the agent consuming resources on the server on the other, e.g. CPU power. Of course, longer polling intervals mean that the information is not as up to date. How up to date the information needs to be depends on the relevant management information, how quickly the information can change and how rapid any response would need to be. For example, the PDA information that a drive could fail in three days does not need to be polled at an interval of milli-seconds. ServerView therefore automatically uses different meaningful polling intervals. In addition, other intelligent techniques (e.g. caching) are used to keep the load caused by polling as low as possible. As a further alternative, ServerView also offers update buttons on the console, which can be used to explicitly trigger a polling operation.

11


Traps

Certain events that can easily be detected, e.g. exceeding a temperature value, are detected directly by the agent. In such cases, the agent sends an unprompted message, known as a trap, to the management station. There is no permanent communication here. In the analysis phase, a decision is then made as to whether the event reported by the trap requires a planning phase.

2.2.3 Interface Between Adaptation and Execution

When considered in more detail, this interface is also more than simply a transfer of information. After an action is triggered, the status of this action or the successful resolution of an error situation must be reported back to the planning phase. If the action cannot be performed successfully, the plan may need to be modified in a new adaptation phase and then executed again.

12


The following four examples are designed to illustrate the co-operation between the management station and agent at this interface.

Example 1

An administrator detects performance problems with a server LAN connection and analyzes that a configuration parameter for the TCP/IP stack needs to be changed. He can implement this plan from his management console, by using the management application to send a corresponding job to the agent. The agent then confirms that this action has been successfully performed.

Example 2

A server is "hanging" - i.e. its agent, which is running on the operating system, is not responding. The administrator decides that he wants to restart this server. He can implement this plan from his PRIMERGY ServerView console. He triggers this action, for example using the RemoteView Service Board, which plays the role of an agent that is on the server regardless of the status of the operating system.

Example 3

A decision is made to install a new blade server. To do this, RemoteDeploy from the PRIMERGY ServerView suite is used to install or clone the individual server blades. In this case, no agent is initially present on the server blades. RemoteDeploy uses PXE (see also Section „Protocols“ on page 23) to automatically add agents to the server blades. These agents then co-operate with the RemoteDeploy components and other helpers to execute the instal-lation or cloning process.

Example 4 (Dynamic reconfiguration)

Due to an expected or existing high server load on one of the partitions of an enterprise server, the administrator decides to add an additional system board to this partition. To do this, he uses the PRIMEPOWER ServerView suite to determine the number of free system boards, selects one and starts the Vconfig management application. This applications checks that the request is permissible (e.g. the CPU frequency must match) and then, with the assistance of a helper application Dynamic Reconfiguration, triggers the commissioning of this board. During this process, the graphical user interface shows the progress of the operation and any messages from the system program. After completion, the data displayed is automatically updated.

13


2.2.4 Autonomous Management on the Server

So far, we have dealt with the phases of the management cycle. Another important aspect to be considered is the running location for these phases. In principle, the design of a management cycle should be as local as possible. Let us consider an example in which an administrator is involved in the analysis and adaptation phases. The administrator will attempt to resolve a problem that has occurred on his own. He will only involve another administrator in the decision if the particular problem makes this necessary. In other words, the administrator attempts to keep the management cycle as local as possible.

If the management cycle runs completely automatically and without the inter-vention of an administrator, it is known as an autonomic cycle.

The autonomic cycle should also be implemented as locally as possible. For example, if an autonomic cycle runs completely on the managed server, this has the advantage that the autonomic cycle is not dependent on other remote components or a functioning network. Two examples of this are described below.

– Automatic Server Reconfiguration & Restart (ASR&R)

Here, the entire autonomic cycle is already implemented by PRIMERGY servers at BIOS level. If a system failure is caused by defective components, such as faulty RAM modules or - in multi-processor systems - by faulty processes, these components are masked. An attempt is made to restart the server. Parameters that control this autonomic cycle, such as the number of restart attempts before the system is shut down, can be set by the adminis-trator on the ServerView console.

– Local AlarmService

The AlarmService receives traps and then decides what is to be done. Possible actions include informing one or more administrators of a particular event by e-mail or SMS, creating an entry in a log file or sending a trap to another service, for example a higher level AlarmService. However, it is also possible to execute a script automatically, which triggers actions that are necessary in the particular situation.

Note: The term autonomic cycle is derived from the term autonomic nervous system, the vegetative nervous system. This system continuously adapts the organism to new situations without the person being aware of this. For example, the pulse or breathing rate is automatically increased during physical activity.

14

Basic Concepts Hierarchical Configurations

The ServerView AlarmService can be installed and operated either remotely or locally on a managed server. The option of combining the automatic execution of scripts with the reception of traps makes it possible to set up autonomic cycles completely on managed servers.

2.3 Hierarchical Configurations

This section describes the topologies that can be set up using the abstract management console, management application, agent and helper components described.

Some typical examples that can be realized with the ServerView suite are presented. Their properties, advantages and disadvantages are discussed.

2.3.1 Local Management

If all components, i.e. agent, management application, any helpers and the management console, are installed on one server, this is a configuration for local management. This is theoretically possible with the ServerView suite, but certainly only makes sense in exceptional cases, for example if the ServerView suite is to be used for local monitoring and management of a single server.

2.3.2 Point-to-Point Management

In point-to-point management, both the agent and the management application are installed on each managed server. The console is physically separate. It is also possible to use multiple consoles. A characteristic feature of point-to-point management is that only individual servers can be directly managed from the console; for example, it is not possible to display a list of servers or combine them into groups.

15

Hierarchical Configurations Basic Concepts

Figure 3: Point-to-point management

The advantages of this configuration are increased security and greater avail-ability.

– Increased security

The SNMP protocol that is frequently used between agents and management applications offers security mechanisms that may not be suffi-cient for some usage scenarios. For monitoring purposes, this is no problem but if actions are to be triggered via SNMP, the level of security is often unacceptable. As no SNMP messages are sent via the network in this configuration, the use of SNMP does not result in any security risk. Protocols that can be safeguarded using SSL (cross-reference) are used for commu-nication between the console and the management application.

Agent

ConsoleMANAGEMENTCONSOLES

MANAGEDSERVER


Agent


16


– Greater availability

If the manager is running on a central computer rather than using point-to-point management, server management is only available when that computer is available. It may therefore need to be duplicated.

With the point-to-point configuration however, the manager runs on the managed server, removing this dependency.

Typical example configurations for point-to-point management with the PRIMERGY ServerView suite components include:

– Agent and ServerView S2 on the managed server.

In this case, the computer can be managed from any web browser. The communication between the console and the manager can be safeguarded using SSL (HTTPS).

– The RemoteView Service Board (RSB), the RemoveView Management Controller (RMC) or a management blade can also be accessed via HTTPS. These components provide the information and also represent them graphically as web pages; they therefore play the roles of agent and manager simultaneously (see also Section „Management Mode 3“ on page 43).

– Agent and ServerView AlarmService on the managed server. In this case, no traps are sent via the network and they cannot therefore be lost. For example, the AlarmService can inform the administrator of problems directly from the managed server or automatically execute scripts.

The same applies for the PRIMEPOWER servers. Here, the eXtended System Control Facility (XSCF) provides functions that are comparable with those of the RSB.

17


2.3.3 Central Management

With this configuration, the management application runs on a separate central computer. The advantages described for point-to-point management are thus no longer applicable.

The advantages of this configuration are a consolidated overview, generation of groups and comprehensive automation solutions.

– Consolidated overview

As the manager has access to information from several servers, it can present a consolidated overview, e.g. as a server list. This representation also includes the overall status of each server.

– Generation of groups

In the consolidated server list representation, the administrator can also combine several servers into a server group. He can then simply apply an operation to a group rather than applying the operation n times to each server individually. This makes his work significantly easier.

– Comprehensive automation solutions

Comprehensive automation solutions that require an overview of several servers can only be incorporated with central management applications.

18


Figure 4: Central management

Typical PRIMERGY ServerView configurations for a consolidated view are realized by installing the ServerView S2 and/or the ServerView AlarmService on a central computer.

The consolidated view is also the normal and recommended scenario for PRIMEPOWER. This is the only way in which all hardware components of an enterprise server can be monitored and configured.

Agent

ConsoleMANAGEMENTCONSOLES

MANAGEDSERVER

Agent



19


2.3.4 Cascaded Management

Management applications that can simultaneously behave like agents can be cascaded. This results in a topology similar to that shown in Figure 5. The cascading is designed to aggregate the information from the lower levels at the higher levels.

Figure 5: Cascaded management

In the PRIMERGY ServerView suite, it is the AlarmService that can play both the management application and agent roles. In the management application role, it receives SNMP traps from all agents that are configured to send traps to this AlarmService. However, the AlarmService can also be configured so that it sends traps itself in certain situations and thus behaves like an agent. For example, it can filter received traps and only forward very particular ones.

Agent

Console

MANAGEMENTCONSOLES

MANAGEDSERVER

Agent


Agent…




20


2.3.5 Integration Into Other Management Systems

The PRIMERGY/PRIMEPOWER ServerView suite can also be integrated into other management systems, such as CA Unicenter, Tivoli or BMC Patrol. Special ServerView products exist for this.

Figure 6 shows a schematic view of how server management components can be integrated into these higher level enterprise management systems.

Figure 6: Integration into other management systems

By configuring several AlarmServices accordingly from a management console, it is possible to specify which traps are sent to the next level up by which AlarmService.

Cascading of PRIMERGY ServerView AlarmServices makes sense if a large number of servers are to be managed. If security considerations make it necessary, hierarchies with redundant paths can also be set up.

Agent

EnterpriseManagement

System

ENTERPRISEMANAGEMENTSYSTEM

MANAGEDSERVER

Agent


Agent



21


Such integration solutions comprise the three integration types of trap integration, status integration and call integration.

– Trap integration

The are two options for trap integration: On the one hand, agents can be configure so that they send their traps directly to the enterprise management system. The second option is similar to the cascading of Alarm Services. Agents send their traps to the ServerView AlarmService, which forwards either all traps or filtered traps to the enterprise management system, depending on its configuration.

– Status integration

ServerView agents are used by the enterprise management system to establish the existence of managed servers in the network (discovery). In addition, they also provide the enterprise management system with the overall status of the server. Based on this information, the managed servers can then be represented, in topology views for example, where an icon normally indicates the type of server and the color of the icon the overall status of the server.

– Call integration

As described above, enterprise management systems represent managed PRIMERGY or PRIMEPOWER servers using corresponding icons. Double clicking on one of these icons automatically opens up a management console, which provides the administrator with access to the managed server indicated by that icon via a ServerView management application.

A similar kind of integration consists of an enterprise management system, e.g. MOM (Microsoft Operations Manager), evaluating entries in the event log file managed by the operating system. As the ServerView Alarm Service enters SNMP traps in this log file as events, to some extent this can be thought of as indirect trap integration.

22

Basic Concepts Protocols

2.4 Protocols

Protocols are independent of the operating system. Communication via protocols allows computers with different operating systems to co-operate with no problems. This is particularly important for management tasks.

The ServerView suites use standardized protocols for all communication paths, where the corresponding standards or de-facto standards exist and are also accepted and used globally.

2.4.1 SNMP - Simple Network Management Protocol

SNMP (Simple Network Management Protocol) was adopted at the beginning of the 1990s and quickly achieved widespread use as it is simple and extremely robust. However SNMP, later referred to as SNMPv1, transfers the data with no protection. SNMPv2 (1994) and SNMPv3 (1998) were expanded to include appropriate security concepts. This made the standard more complex to realize and made the use and configuration of the corresponding components more expensive, which meant that these two versions have not become so widely used.

23

Protocols Basic Concepts

Figure 7: SNMP (Simple Network Management Protocol)

SNMP was originally designed for network management. However, it quickly became apparent that from a protocol perspective there are essentially no differences between network, system, device and application management. Figure 7 illustrates the concept on which SNMP is based.

From the outset, the SNMP protocol and the management objects were separate. The SNMP protocol specifies the operations, while the managed objects are defined separately in a Management Information Base (MIB). These objects are uniquely identifiable using a naming system based on a globally defined tree structure and are sequentially ordered by this tree structure.

Get

TrapSimple Object:- Name- Value

Agent Agent

MANAGEDSERVER WITH AGENTS

MANAGEMENTSTATION Console


Getnext

Set

Response

Simple Object:- Name- Valuet

24


In principle, the SNMP protocol provides four operations for management of a server or, more generally speaking, a component.

– The management station can request information.

There are two different operations for this. The Get operation can be used to request the value of a specified object. The Getnext operation can be used to request the value of the next object, referring to the sequential ordering of object names.

SNMPv3 also provides a Getbulk operation, which can be used to read a defined quantity of objects with a single operation.

– The management station can change values (Set operation), for example changing a configuration or indirectly triggering actions.

– The agent supplies the requested information or confirms the setting of a value (Response operation).

– The agent itself can be active and inform the management station of particular events (trap, notification). Examples include exceeding a threshold value, a status transition in a sub-system or a PDA message.

Although the data is transferred unencrypted with SNMPv1, the community concept does provide a method for configuring access privileges. A community is a group of elements (management stations and agents) that communicate via SNMP. The group is uniquely identified by the community string. Only systems that belong to the same community can communicate with one another. A system can belong to several communities.

For communication between a management station and an agent, the community string takes on the role of a password. The agent requires it from the management station before it provides information about the agent's system. This applies to each SNMP package.

25


As mentioned above, the management objects are not defined in the SNMP standard. The semantics, syntax and range of values for the objects are defined separately in MIB files. They are simple objects, consisting of a name and a value. For example, for SNMP there are several thousand standardized object definitions and even more manufacturer-specific object definitions. However, a user-friendly user interface on the management station must take these semantics into account so that the management information is represented in a meaningful way. Otherwise, only representation in a table is possible, which is often unclear, in MIB browsers for example.

The MIBs recognized by ServerView include the standard MIB2 and all ServerView-specific MIBs. ServerView recognizes the semantics for these objects and represents them accordingly or interprets them using these semantics, for example if a threshold value is exceeded.

Further information about MIBs and SNMP can be found at http://www.simpleweb.org/ietf/

The possible access type for each object, e.g. read only or read-write, is specified in an MIB. The privileges with which a management station can access information from the agent is also linked to a community string. The access privileges associated with the community string can be used to further restrict the MIB access types. An extension is not possible. If the MIB definition specifies read only for an object, it cannot be used as read-write, even if the community string is associated with read-write access privileges. The following example illustrates the use of community strings and access privileges:

Example:An SNMP agent belongs to a community with the name public and read only access privileges. The public community also includes a management station, which can request information from this SNMP agent by sending a corre-sponding message with the community string public. At the same time, the SNMP agent belongs to a second community called net_5, which is associated with read-write access privileges. The community net_5 includes another management station. In this example, only the second manager in the net_5 community is entitled to use the SNMP agent to execute write operations.

If particular events occur with a network component, the SNMP agent can notify one or more management stations of this event by sending traps. The acceptance of an SNMP trap by the management station is also expressed by a community string. If the SNMP agent sends a trap message to a management station, it must use the necessary trap community string so that the management station will accept the message.

26


More details can also be found in the technical literature, for example “The Simple Book“ by Marshall T. Rose.

2.4.2 CIM (Common Information Model)

A few years after SNMP was available as a standard, the standardization of CIM commenced. While with SNMP the protocol was standardized first and MIBs then defined gradually, a different route was taken with CIM. Definition of the objects was started first - this is also the origin of the name Common Information Model, and the specification of transfer protocols was then commenced. These standardization processes have not actually been completed yet, although the first specifications have of course already been implemented and are in use

First of all, we will look at the modeling method. The essential difference between CIM and the simple object definition in SNMP is that CIM includes a class hierarchy and a new object can only be defined in the context of that hierarchy: A class B derived from a class A inherits all properties of class A, i.e. it has its own properties plus those of class A. The class hierarchy thus defines the "inheritance tree".

27


Figure 8: CIM (Common Information Model)

The CIM is developed by DMTF and consists of the following major compo-nents:

– Meta schema

This specification from DMTF does not specify any objects, but defines the rules for how schemata are to be defined.

– Core schema

In this schema, DMTF defines the top level classes in the inheritance hierarchy. All CIM classes must be derived from these classes - directly or indirectly, i.e. across several levels. Relations such as depends on are also defined as classes, which can then be refined in derived schemata. Relations are an important means of expression for expressing complex interrelationships within the variety of management data.

. . .Extensionschemata

(manufacturer-spezific)

Common Schema (DMTF)Systems Network Applications ...

WIN32 Schema

FSCSV Schema

Ref

inem

ent

ConcreteSpezifications

AbstractSpezifications

MOF

MOF

MOF

Core Schema (DMTF)

Meta Schema(DMTF)

28


– Common schema

Common schemata derive classes for specific areas from the classes in the core schema. These classes are also defined by the DMTF. At present, the areas for which common schemata have already been adopted or on which DMTF working groups are current working include: System and devices, networks, user and security, behavior and state, databases, applica-tions/metrics, policy, pre-OS and utility computing. All of these class defini-tions are manufacturer neutral and standardized by the DMTF.

– Extension schema

Manufacturers can define their own classes in extension schemata. However, these classes should be derived from common schema classes and may only be derived from the core schema classes in exceptional cases. Compared to the MIB definitions for SNMP, this has the advantage that even unknown manufacturer-specific classes can be interpreted to a limited extent in the context of the inheritance tree. With CIM, the "uncontrolled growth" of manufacturer-specific MIB objects is thus prevented.

Examples of manufacturer-specific schemata are the Win32 Schema from Microsoft and the FSCSV (Fujitsu Siemens Computers ServerView) schema for PRIMERGY ServerView, both of which are derived from the common schema System and Devices.

– MOFs (Managed Object Format)All schemata can be abstractly defined as required, preferably as UML (Unified Modeling Language) diagrams.. So that they can be automatically interpreted and exchanged, a syntax has been defined for so-called MOFs. The concrete specification of a schema is therefore a text file with MOF syntax.

Further information about CIM can be found on the DMTF's CIM page: http://www.dmtf.org/standards/cim

In order to gain remote and manufacturer-independent access to CIM objects, a meta schema-based coding known as CIM-XML has been developed. Meta schema-based means that the hierarchy of associated CIM class definitions have to be requested and transferred in addition to the CIM objects. The associated complexity is probably the reason why this protocol is hardly ever used. At present, the standardization bodies are considering the development of a leaner protocol for access to CIM.

29


2.4.3 IPMI - Intelligent Platform Management Interface

The IPMI standard defines management functions that are implemented at hardware and/or firmware level. This makes all functions available, regardless of the status of the main processor, the BIOS and the operating system. They can even be available when the system is shut down.

Figure 9: IPMI (Intelligent Platform Management Interface)

IPMI provides an interface on which the management software can place stacks. Figure 9 shows this IPMI interface and an example of how some standards are structured in the stack above it.

IPMI implementations are based on a Baseboard Management Controller (BMC). A BMC is a micro controller, which is independent of the actual computer because it has its own processor and memory. This controller performs all functions provided via the IPMI interface. IPMI has been continu-ously developed over the years, increasing the scope of the management functions.

The components of the PRIMERGY ServerView suite use the IPMI interface for both their in-band management, i.e. if the operating system and management agents are running on the system, and their out-of-band management, i.e. if no operating system is running on the system or the system is defective.

Further information about IPMI can be found at http://developer.intel.com/design/servers/ipmi/index.htm

CIMApplication

CIM Object Manager

CIM Provider

IPMI Interface Code

Instrumentation Code

Platform Mgmt. Controller

IPMI Interface

SNMPAgent

IPMI H/W Interface

Man

agem

ent

So

ftw

are

Sta

ckIP

MI

30


– IPMI V1.0 (1999):

A major task of IPMI V1.0 is monitoring However, IPMI does not do this by direct commands but via a model containing Sensor Data Records (SDR). SDRs describe the sensors present in the system that can be polled. This makes IPMI adaptable and flexible for different systems. A BMC also has a system event log (SEL) in its permanent memory, in which it enters event messages. This system event log can be accessed via the IPMI interface. This makes it possible to evaluate these event messages even if the system is shut down. IPMI also allows system components to be uniquely identi-fiable and enables this information to be requested via the IPMI interface. The basis for this is the concept of FRU (Field Replaceable Unit) infor-mation. The structure of this information is defined by the IPMI specification and can be expanded on a manufacturer-specific basis. Fujitsu Siemens Computers has defined these expansions for PRIMERGY components. FRU Information contains data such as the manufacturer, model and serial number and can be saved on SEEPROMs that are located on mother-boards, memory boards or controllers.

– IPMI V1.5 (2001)

An important function that was available with V1.5 is "IPMI over LAN". While with V1.0 the IPMI interface was only available as a local interface (I/O mapped), V1.5 defines how IPMI messages can be embedded in RMCP (Remote Management Control Protocol) messages and sent as UDP packages via the network. It is also possible to use SNMP traps to provide information about events that have occurred. This LAN communication can run on the system's LAN controller if this is configured so that the management port can be operated with a standby power supply, which means that this port remains operational when the system is shut down. Of course, it is also possible to use a LAN controller exclusively for IPMI.

– IPMI V2.0 (2004):

The new functions available with V2.0 includes VLAN (virtual LAN). VLAN support allows you to set up a management VLAN in which - isolated from other VLANs - only the devices configured in that VLAN can communicate with one another. The support for encryption, logins and firewall functions can be used to increase security.

31


2.4.4 PXE - Preboot Execution Environment

As part of its WfM (Wired for Management) initiative, Intel specified which functions and standards for the management of desktops, mobiles and servers need to be implemented on systems to meet the WfM requirements. These include SNMP and support for particular MIB objects or IPMI. It was also estab-lished that some standards were still not in place and therefore needed to be developed. One of theses standards was the PXE protocol (Preboot Execution Environment).

Among other things, PXE was developed to solve the following problem: New systems joining a network should be provided with a protocol that enables them to load configuration parameters and images automatically from a special server. Executing this protocol could then be used to install an operating system, for example.

To achieve this, the PXE protocol was defined, based on the TCP/IP, DHCP and TFTP Internet protocols. Essentially, the PXE protocol works as follows:

– The new system sends a broadcast to the network.

– If the network contains a DHCP server, as well as the IP address assigned to the new system, this server sends a list of suitable boot servers as a response.

– The new system then loads an executable file from one of these boot servers via TFTP and runs it.

– The system is thus brought to a status in which further management functions can be executed or initiated.

In the PRIMERGY ServerView suite, PXE is used by RemoteDeploy. For PRIMEPOWER, IETF (Internet Engineering Task Force) protocols providing similar functionality are used, namely RARP (Reverse Address Resolution Protocol), TFTP (Trivial File Transfer Protocol) and bootparam.

Further information about PXE and WfM can be found at :http://www.intel.com/technology/computing/wfm.htm

32


2.4.5 Telnet

Telnet was developed to log into remote computers via the Internet. Telnet is based on the concept of a Network Virtual Terminal (NVT). The two parties that are communicating via Telnet, map their local device properties to the properties of this virtual terminal.

In addition, the Telnet protocol defines numerous other options that can be negotiated between the two parties at the beginning of a session. To a certain extent, this makes it possible to communicate at the "lowest common denomi-nator" rather than at the lowest level.

The Telnet protocol was specified as long ago as 1983 by the IETF in RFC 854. Over the course of time, features were added to it, primarily relating to security. For example, Telnet can now be safeguarded using SSL.

In the PRIMERGY ServerView suite, the Telnet protocol is used by RemoteView components.

For PRIMEPOWER, Telnet is the basic function for the remote operation of Solaris.

Further information about Telnet can be found at http://www.ietf.org/rfc/rfc0854.txt

2.4.6 HTTP - Hypertext Transfer Protocol

HTTP is based on the idea that files can contain references to other files and that the corresponding file can be requested by selecting one of these refer-ences.

The HTTP client - normally a web browser - sends a request to the IP address of the HTTP server with the path name of the desired information. An HTTP service runs on the HTTP server and waits for HTTP requests. When it receives a request, it returns the desired files (a web page normally consists of several files) or an error message.

HTTP has been used on the worldwide web since 1990. HTTP is a request/response protocol, which normally runs on TCP/IP connections, but can also be processed by other reliable transfer services. The default port is TCP 80.

33


An HTTP service can deliver not only static information; when it receives an HTTP request, it can prepare current information and send this back as a response. For example, this happens when requesting current stock prices. The ability to request dynamic data via HTTP allows the HTTP protocol to also be used for server management. For ServerView, the data for monitoring the pages is always prepared dynamically.

The following two architectures are typical examples:

– An HTTP service is running on the managed server. When it receives a request, it retrieves the requested information via local interfaces, prepares it accordingly and sends it back as a response. In this case, we also refer to it as a web agent.

– The HTTP service is running on a separate server, which communicates with the managed servers via other protocols such as SNMP. When this kind of HTTP service receives a request, it retrieves the requested information from the managed servers, via SNMP for example, prepares it and sends it back as a response. It also has the possibility of consolidating information from managed servers, for example in a server list or database, or of buffering it in a cache and then preparing this information as a response.

Essentially HTTP is always used in ServerView if a web browser is used as the management console.

Further information about HTTP can be found at ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

2.4.7 SSL - Secure Socket Layer

SSL is located in the stack above the TCP/IP level and below the application protocol level, for example HTTP. The URL of HTTP connections that use a connection safeguarded by SSL begins with https... instead of http:....

Originally developed by Netscape, SSL achieved rapid acceptance and soon became widespread on the world wide web. TLS (Transport Layer Security) was also developed in the IETF based on SSL and published as a standard.

34


SSL enables three important functions to be used:

– SSL server authenticationIf the server has an SSL certificate issued by a recognized body, it can identify itself to a client as the server for which that certificate was issued.

– SSL client authenticationIf a client has an SSL certificate issued by a recognized body, it can identify itself to a server as the client for which that certificate was issued..

– Encrypted SSL connectionAn encrypted SSL connection ensures that the connection between the SSL client and the SSL server is secure, i.e. unauthorized persons cannot read or edit the transferred messages.

The PRIMERGY ServerView suite mainly uses the SSL encrypted connection function. This function does not require SSL certificates to be obtained from a recognized body and installed in return for a corresponding fee. SSL certificates are automatically generated by server management components and then used for the encryption. The connection is thus just as secure as when using certifi-cates generated by a recognized body. Other methods, such as accounts and passwords, are used for mutual authentication, with the communication for these authentication methods using SSL encrypted and therefore secure communication paths.

In the PRIMEPOWER ServerView suite, authentication using a certificate is supported in addition to encryption.

Further information about SSL can be found athttp://wp.netscape.com/eng/ssl3/

2.4.8 SOAP - Simple Object Access Protocol

SOAP is a protocol that enables remote access to web services. SOAP is used to execute Remote Procedure Calls (RPC), mainly based on the HTTP transfer protocol, which has the advantage that it normally makes firewalls penetrable for SOAP as they are usually open for HTTP. However, in principle SOAP can use other transfer protocols such as SMTP (Simple Mail Transfer Protocol) or MIME (Multipurpose Internet Mail Extension).

SOAP messages are XML documents, which means that their coding is independent of operating systems and transfer protocols. Like XML, the standardization of SOAP is the responsibility of the World Wide Web Consortium (W3C).

35


In the PRIMERGY ServerView suite, SOAP is used for communication between components from the management application category, for example between RemoteDeploy components.

Further information about SOAP can be found at http://www.w3.org/TR/soap orhttp://www.microsoft.com/mind/0100/soap/soap.asp

2.4.9 ITIL - IT Infrastructure Library

ITIL is the abbreviation for the IT Infrastructure Library guidelines developed by the CCTA (now OGC) in Norwich (England) on behalf of the British government. ITIL is now the de-factor worldwide standard for service management and contains comprehensive and publicly available technical documentation for the planning, provision and support of IT services. ITIL provides a basis for improving the use and effectiveness of an operational IT infrastructure.

ITIL was developed by staff from computer centers and specialists from consul-tancy firms to support and improve the use and operation of operational IT infra-structure. ITIL looks at two main aspects of IT service management: on the one hand the life cycle of IT services and on the other hand the customer view.

The ITIL books represent best practice guidelines for service management, describing the "What" and not the "How". The latter must be tailored to the size, internal culture and, above all, requirements of the specific company and then implemented accordingly. This means that , depending on the relevant IT environment and the services offered, the processes must be specifically defined for the computer centers - in principle, this can be compared to quality management to ISO 9000.

SOAP also plays a central role in Service Oriented Architecture (SOA) of Microsoft. The basis of this architecture is that the implementation and interface are completely separate. The implementation can change over time without this being noticed by the users of the service. Interfaces to the services are essentially defined as SOAP interfaces. This trend is not restricted to appli-cation software, however, it is also gaining in significance for management software.

36

Basic Concepts Helpers

The components of the ServerView suites support the management of servers throughout their life cycle. Server management is possible regardless of the status of the server and, with functions such as the creation of asset infor-mation, archiving or reports, provides important information for these processes. The ServerView suites are therefore ideally suited for implementing practical management processes conforming to ITIL.

Further information about ITIL can be found at http://www.itil.co.uk

2.5 Helpers

Helpers are services or programs that are not components of the ServerView suites but are or can be used by ServerView during its operation.

2.5.1 DHCP Server

DHCP (Dynamic Host Configuration Protocol) is used to assign a host an IP address from a central point (DHCP server) when starting up in a TCP/IP network and to configure the TCP/IP software.

A host can use a DHCP request to request an IP address via a broadcast, whereby it identifies itself using its MAC address. The MAC address is a hardware address that uniquely identifies every device in the network.

When the DHCP server receives such a request, it returns an available IP address, according to its configuration. The configuration of the DHCP server determines whether IP addresses are assigned statically or dynamically. In the former case, the DHCP server is configured in such a way that the fixed IP addresses reserved for the MAC addresses are assigned in a table. The response to the request would then deliver the IP address assigned to the relevant MAC address. In the latter case, an IP address is assigned dynamically from a pool of free IP addresses. IP addresses that are no longer required are returned to this pool. Mixed operation with both static and dynamic assignments is also possible

ITIL describes these processes in the following modules: Incident Management, Problem Management, Change Management, Configuration Management, Release Management, Service Level Management, Cost Management, Capacity Management, Availability Management and Contin-gency Planning.

37

Helpers Basic Concepts

The DHCP server is an important helper for the ServerView suite. PRIMERGY ServerView also uses the DHCP server in conjunction with the PXE boot server described below.

2.5.2 PXE Boot Server

PXE is the boot mode for the LAN controller. The BIOS of the computer to be booted using PXE must activate the LAN controller as the boot device during the boot operation, i.e. it starts the PXE LAN Boot Extension.

As well as the boot capability of the LAN controller, the PXE boot operation also requires a PXE server and a DHCP server in the LAN.

PXE boot servers are used as follows in the PRIMERGY ServerView suite:

– Remote use of ServerStart, where the ServerStart OS directory is created on the PXE boot server and copied and started on the server to be installed via PXE.

– Cloning operation with RemoteDeploy, where a PXE boot is normally carried out twice: First of all, a configuration agent from the boot server is copied and started, which sets up the RAID systems for example. A second PXE boot is then used to copy the actual image to the RAID system.

Further details can be found in the "PRIMERGY ServerView Suite, RemoteDeploy" manual.

For PRIMEPOWER, IETF (Internet Engineering Task Force) protocols providing similar functionality are used, namely RARP (Reverse Address Resolution Protocol) (see Section „RARP Server“), TFTP (Trivial File Transfer Protocol) (see Section „TFTP Server“) and bootparam.

The PXE boot operation described below illustrates this: The PXE Lan Boot Extension sends a DHCP request to the LAN as a broadcast, and the DHCP server responds with the requested IP address and any additional parameters. The IT address can also belong to the boot server. If the IP address of the boot server is transferred, this server can then only be addressed directly, otherwise the subsequent request is sent as a broadcast. This request asks the boot server for the name of the boot image assigned for the server. This decision is made by the boot server based on its previous configuration. The PXE LAN Boot Extension then retrieves this image via file transfer (TFTP or MTFTP), copies it to the address 07c0h and starts it.

38

Basic Concepts Helpers

2.5.3 RARP Server

RARP (Reverse Address Resolution Protocol) is a network protocol used to request the corresponding Network Layer Address for a Data Link Layer Address. For example, it can be used to request the IP address assigned to a MAC address. A RARP server is a service that has these assignments of MAC addresses to IP addresses stored in its configuration file and delivers the corre-sponding information as a response to RARP requests.

RARP and TFTP servers are often used instead of PXE boot servers in the UNIX environment, including the PRIMEPOWER ServerView suite.

2.5.4 TFTP Server

TFTP (Trivial File Transfer Protocol) is a very simple protocol, which can be used to read or write complete files only. It should not be confused with the signifi-cantly more powerful FTP (File Transfer Protocol). Many network components use a TFTP server to load their basic operating system or their initial configu-ration via the network.

The ServerView suite uses TFTP servers in situations where an effective stack of communication protocols is not yet available on the server, for example in certain phases of RemoteDeploy and GlobalFlash or in conjunction with RARP.

2.5.5 Mail Server (MAPI or SMTP)

Mail servers are used in the PRIMERGY and PRIMEPOWER ServerView suite to inform administrators when ServerView has detected certain situations. For example, the ServerView AlarmService can be configured such that it sends a mail to the administrator or service provider when it receives certain traps.

The ServerView AlarmService can work in conjunction with the following mail servers:

– Microsoft Exchange

This mail service can be addressed by server management components via MAPI (Messaging Application Programming Interface).

39

Helpers Basic Concepts

– SMTP server (Simple Mail Transfer Protocol)

This protocol was standardized by the Internet Engineering Task Force (IETF). SMTP servers are used as helpers in Linux or Solaris environments.

Further details can be found in the "ServerView AlarmService" manual.

2.5.6 Web Server

Certain components of the PRIMERGY ServerView suite allow you to use web browsers to access the management information. These components, which include ServerView S2, co-operation with web servers that then make the infor-mation prepared by ServerView available to any browsers via HTTP.

For example, the components from the PRIMERGY/PRIMEPOWER ServerView suites co-operate with the Apache Web Server, and the PRIMERGY ServerView suite also works with the Microsoft Internet Information Server (IIS).

Further details can be found in the "ServerView Installation" manual.

2.5.7 MS Excel, Access or SQL Databases

The Microsoft Excel/Access programs and SQL databases are other examples of helpers. The files generated by ServerView Export Manager, which contain inventory information, can be imported into MS Excel/Access or SQL databases, where they can be processed or linked to other data.

2.5.8 Dynamic Reconfiguration (DR)

Dynamic reconfiguration (DR) is available on partitions under Solaris 8 or later. Dynamic reconfiguration allows end users on PRIMEPOWER servers to add and remove system boards to/from partitions without rebooting.

PRIMERGY ServerView Suite uses these system commands to dynamically reconfigure an enterprise server.

40

Basic Concepts Management Mode

2.6 Management Mode

In the previous section, the server management components were assigned to categories, their interactions were described and the relevant standards were explained. In this section, we will look at the management modes. The table below differentiates between

– The operating system statuses of the managed server, whereby operating system refers to the target operating system that is used for normal operation. The statuses are OS-up and OS-down

and

– The communication paths used for remote management of the managed server.

In-band means that the same path (network controller) is used as is used for operation.

Out-of-band means that a separate path is used for management. This path is sometimes referred to as the Secondary Management Channel.

The operating system status and communication path then determine the management modes described below.

2.6.1 Management Mode 1

This mode is characterized by the fact that the target operating system on the monitored server is operational and the communication path used for management is the same as the one used for operational purposes. Management is normally performed using agents, which run on the target operating system. Both polling and the sending of traps run on this communi-cation path.

OS-up OS-down

In-band Mode 1 Mode 2

Out-of-band Mode 3

Table 1: Management modes

41

Management Mode Basic Concepts

This management mode is used to monitor running servers. As the agents run on the target operating system and the communication path is also used for operational communication, management on the managed server consumes part of the processor capacity and network capacity. However, intelligent caching in the ServerView components and sensible polling intervals mean that this reduction in capacity is negligible.

If the managed server has a different status (not yet installed, not booted, booted but hanging) or, if the system cannot be brought to a run capable status due to hardware errors, it is not possible to use management mode 1 for management of the server. The PRIMERGY ServerView suite therefore also provides the two management modes described below.

A typical example of management mode 1 is management of a managed server using the operating system-specific ServerView SNMP agents.


Management mode 2 can be used if the target operating system is not booted or cannot be booted. However, it is a requirement of this mode that the standard functions of the system board are active and at least one CPU is running.

The PRIMERGY ServerView suite provides two options for systems with this status:

– The optional RomPilot BIOS extension allows a LAN connection to the server to be established automatically in the POST (Power on Self Test) phase. The RemoteView front end allows text console diversion, file transfer and remote power management.

– The diagnostic operating system (MS-DOS) can be started from the chipDISK, an optional independent IDE storage medium on the server, and a connection to the server established using an external modem. Testing and diagnostic tools on the chipDISK (RemoteView Diagnosis) can be started independently of the system hard drives on the server.

In other words, management mode 2 uses the hardware functions that are also used for operation, but uses special firmware or software that runs indepen-dently of the target operating system.

In the PRIMERGY ServerView suite, this management mode is primarily used by RemoteView. For PRIMEPOWER servers, the eXtended System Control Facility (XSCF) facilitates this mode.

42

Basic Concepts Management Mode


This management mode is totally independent of the hardware, firmware and software components used for operation on the managed server. Separate, independent hardware components, communication paths and software are used for management in this mode. This mode is therefore often referred to as Secondary Management Channel in the literature.

This independent hardware can be used to run SNMP agents, Telnet services or web agents - even safeguarded using SSL. In contrast to management mode 1, the management information is not provided by functions of the target operating system but comes directly from sensors, via IPMI compatible Baseboard Management Controllers (BMC) or separate log files.

Examples in the PRIMERGY ServerView suite are the RemoteView Service Board (RSB) and RemoteView Management Controller (RMC) server management components, which allow direct access to the server regardless of its status. Baseboard Management Controllers provide this option using IPMI-over-LAN. As IPMI-over-LAN is based on the Remote Management Control Protocol (RMCP), which it only makes sense to use within a network segment, the PRIMERGY ServerView suite provides the following solutions: ServerView applications, such as RemoteView and RemoteDeploy, commu-nicate with the BMC via IPMI-over-LAN and then provide the administrator with communication via their user interfaces, e.g. HTTP.

For PRIMEPOWER servers, this option is provided by the eXtended System Control Facility (XSCF).

However, these independent components used for management mode 3 do not necessarily have to be exclusively assigned to a single managed server. They can also be used as Secondary Management Channels for several managed servers - to a certain extent as concentrators. One example of this is the management blade, which is a concentrator that provides all server blades in a blade server with the Secondary Management Channel.

Typical situations in which management mode 3 is used include:

– Servers on which a target operating system is not yet installed. Server blades (bare metal blades) that are to be installed remotely.

– Servers that are turned off and are to be remotely turned on and booted using this mode.

43

Summary Basic Concepts

– Servers on which an operating system is running but are "hanging" and can no longer be contacted using the communication path used for operation. Such systems can then be monitored, analyzed and, if necessary, shut down and rebooted using the Secondary Management Channel.

– Servers with defective hardware, where it is impossible to boot the diagnostic software to obtain additional information or trigger actions in management mode 2. In these cases, management mode 3 can be used to operate additional diagnosis, providing a service engineer with valuable information before he travels to the site to resolve the problem.

2.7 Summary

This section described concepts that are important for planning and realizing server management using the ServerView suite.

The most important concepts are summarized once again below:

– Categorization of server management components

Agents that communicate with management applications normally run on the managed servers. Management applications provide management functions - if necessary in co-operation with other management applications or helpers. Management consoles can be used to access these management applications.

– Principle: Agent and management station

This section provided further abstraction of the monitored component (agent) and the monitoring component (management station). These two components are involved in the continuously running management cycle, which consists of the four phases of monitoring, analysis, adaptation and execution.

– Hierarchical configurations

The use of server management components at different levels allows hierar-chical configurations to be set up. Five such configurations were presented by way of example: Local management, point-to-point management, consol-idated management, cascaded Alarm Service and integration into other management systems.

44

Basic Concepts Summary

– Protocols

Openness is an important basic concept of the ServerView suite. Standardized protocols are therefore used wherever possible. The most important of these protocols were described in detail: SNMP, CIM, IPMI, PXE, Telnet, HTTP, HTTPS, SSL, SOAP and ITIL.

– Management modes

Depending on the operating system status on the managed server (OS-up/OS-down) and the communication path used for management purposes (in-band/out-of-band), there are three different management modes that are available for the management of PRIMERGY and PRIMEPOWER servers.

45

3 Positioning of ServerViewThis section the relation between ServerView and other enterprise management systems is discribed.

Figure 10 provides a schematic overview of the enterprise management area.

Figure 10: Enterprise management

A distinction is made here between management areas and management functions.

Err

or

Man

agem

ent

Use

rM

anag

emen

t

Per

form

ance

Man

agem

ent

Lic

ense

Man

agem

ent

Ass

etM

anag

emen

t

Acc

ou

nti

ngM

anag

emen

t

Pro

duc

tion

sM

anag

emen

t

Sec

urit

yM

anag

emen

tEnterprise Management

SystemManagement

ApplicationsManagement

MemoryManagement

NetworkManagement

…

ManagementAreas

ManagementFunctions

47

Positioning of ServerView

Management Areas

Management areas refer to the objects of management:

– System management comprises all objects that belong to computer systems, from hardware level through to operating system level. Of course, hardware and firmware-specific properties need to be taken into account here. The manufacturer of the systems is most familiar with these, which is why optimum system management can only ever originate from the system manufacturer. Standards are a means to achieve the maximum possible degree of manufacturer independence, but there are still certain areas that are not covered by standards.

– Application management always depends on the specific application. There are hardly any standards in this area.

– Memory management involves memory systems that provide memory capacity separately from the computer systems.

– Network management involves all objects that make up a network.

For each of these areas, an appropriate management system must support all the phases in the lifecycle of the relevant objects. This is represented by the "lifecycle arrow" in the graphic.

The management area of the ServerView Suite is the system management for PRIMERGY and PRIMEPOWER servers.

Management Functions

The management functions are represented as columns in the graphic. A function can be based on one or more management areas. For example, comprehensive asset management can access all four management areas to obtain information for all objects. The list of management functions in the graphic is not complete. It shows only a few of the important management functions, with new functions continuously being added over time to simplify the work of the administrators. The ServerView suite primarily provides the following management functions:

– problem management (PRIMERGY, PRIMEPOWER),

– performance management (PRIMERGY, PRIMEPOWER),

– security management (PRIMEPOWER) and

– asset management (PRIMERGY, PRIMEPOWER).

48

Positioning of ServerView ServerView Suite

If enterprise management systems with corresponding ServerView integrations are used, the ServerView suite provides valuable contributions to the management functions available in the enterprise management system.

3.1 ServerView Suite

The ServerView suite offers system management that is optimally tailored to the hardware and firmware of the PRIMERGY and PRIMEPOWER servers. Specific hardware/firmware properties of each model in this range of servers are optimally used in the ServerView suite, in all phases of their lifecycle.

The ServerView suite can also be used to monitor and manage a large number of servers. The limitations of ServerView lie not so much in the number or servers as in the focus on the server management area described above and the management functions addressed. The openness of the ServerView suite, which is described in the next two sections, allows integration in two directions:

– Integration of the ServerView suite into other management systems, which provide management functions that are not covered by the ServerView suite.

– Integration of individual objects from other management areas into the ServerView suite, for example various switches that are particularly important for PRIMERGY configurations.

3.2 Integration Into Other Management Systems

Standardized protocols and interfaces are the basis for integration of the ServerView suite into other management systems. ServerView integration modules create the link between ServerView components and other management systems. This allows management functions from these systems to be used for PRIMERGY or PRIMEPOWER servers, although at the same time - in an integrated way - the ServerView functionality is available for system management.

49

Integration of Other Components Positioning of ServerView

ServerView integration modules are available for management systems including the following:

– Computer Associates Unicenter

– HP OpenView Network Node Manager and HP Insight Manager and HP Systems Insight Manager (PRIMERGY ServerView only)

– IBM Tivoli TME 10 Framework T/EC

– IBM Tivoli NetView

– Microsoft SMS, MOM and ADS (PRIMERGY ServerView only)

– Novell Remote Manager

– BMC Patrol (PRIMERGY ServerView only)

In Altiris management systems, PRIMERGY servers are primarily integrated for deployment purposes. The typical usage scenario here is deployment in heter-ogeneous environments, i.e. with servers from different manufacturers. Integration is predominantly based on calling up PRIMERGY specific DOS tools in Altiris environments.

3.3 Integration of Other Components

Two concepts for how objects other than the PRIMERGY and PRIMEPOWER servers can be integrated into management using the ServerView suite are described below.

Integration into AlarmService

The realization of the ServerView AlarmService is based on the standardized management protocol SNMP. This allows other IT components to be integrated into the ServerView suite via SNMP.

IT components on which SNMP agents are running can send their traps to the ServerView AlarmService. If the AlarmService recognizes the corresponding trap definitions, it handles the traps in the same way as traps from ServerView agents.

Numerous trap definitions are already integrated into the ServerViewAlarm Service. These include traps from fiber channel switches, RAID controllers, storage systems, power supplies etc.

50

Positioning of ServerView Integration of Other Components

Integration via ServerView Agents

A further integration option involves installing ServerView agents on the monitored system. This results in information about such systems being presented on the ServerView consoles in the same way as the information about PRIMERGY and PRIMEPOWER servers.

HP and Compaq servers can now be integrated into the PRIMERGY ServerView suite using this method. Heterogeneous environments can thus be completely managed using the ServerView suite. Details can be found in the white paper "insight²: PRIMERGY ServerView - Active Integration of Servers from HP / Compaq".

ReliantUNIX, Linux and standard Solaris systems (i.e. Sun models from Solaris 8) can be integrated into the PRIMEPOWER ServerView suite in a similar way by installing the corresponding agent software.

51

Index
AAccess database 40adaptation 8, 12agent 5, 6, 7, 10, 13, 15, 20, 25, 41
ServerView 51SNMP 50

AlarmService 14, 17, 39, 50analysis 8, 10application management 48ASR&R 14asset management 48Automatic Server Reconfiguration &

Restart 14automation solution 18autonomic cycle 14, 15autonomous management 14availability 17

BBaseboard Management Controller

30, 43basic concepts 3BIOS extension 42BMC 30, 43boot

device 38image 38mode 38operation 38

Ccaching 11call integration 22cascaded management 20categories 3category 7central management 18chipDISK 42

CIM 27classes 28components 28object 27

classdefinition 29hierarchy 27

client authentication 35Common Information Model (CIM) 27common schema 29communication path 23, 41community 25

concept 25string 25, 26

components 3configuration 15

hierarchical 15Console 6console 6consolidated overview 18core schema 28cycle 8

DDHCP 37

request 37, 38server 37, 38

discovery 22Dynamic Host Configuration Protocol

37Dynamic reconfiguration 7, 13, 40

Eenterprise management system 21event log file 22execution 8, 12eXtended System Control Facility

(XSCF) 17, 42extension schema 29

53

Index

FField Replaceable Unit (FRU) 31file transfer 42File Transfer Protocol (FTP) 39firewall 35FRU information 31FTP 39

Gget operation 25getbulk operation 25getnext operation 25groups 18

Hhardware address 37helper 6, 7, 15, 37

Access database 40DHCP server 37dynamic reconfiguration 40mail server 39MS Excel 40PXE boot server 38RARP server 39SQL database 40TFTP server 39web server 40

hierarchical configuration 15HTTP 33, 35, 40

client 33protocol 34request 33server 33service 33

Hypertext Transfer Protocol (HTTP) 33

Iicon 22IETF 38In-band 41in-band 30inheritance tree 27integration 21, 49

call 22module 50status 22trap 22

Internet Engineering Task Force (IETF) 38

IP address 37IPMI 32

interface 30IPMI-over-LAN 31, 43IT Infrastructure Library (ITIL) 36IT service management 36ITIL 36

LLAN

communication 31controller 38

localAlarm Service 14management 15

log file 6, 22

MMAC address 37mail server 39manage server 5managed object 24Managed Object Format (MOF) 29managed server 5, 6management 41

application 5, 7, 15, 18, 20area 48autonomous 14blade 17cascaded 20central 18console 6, 7, 15cycle 8, 14function 30, 48point-to-point 15station 7, 10, 13, 25system 21

54

Index

Management Information Base (MIB) 24

management mode 1 41management mode 2 42Management mode 3 43MAPI 39memory management 48messages 5Messaging Application Programming

Interface (MAPI) 39meta schema 28MIB 26MIB2 26Microsoft Exchange 39MIME 35mode 41modeling method 27MOF 29monitored server 5monitoring 8MS Excel 40Multipurpose Internet Mail Extension

(MIME) 35

Nnetwork

component 26management 24, 48protocol 39

Oobject definition 26operating system status 41Out-of-band 41out-of-band 30

Pperformance management 48planning 10pocket PC 6point-to-point management 15polling 11, 41

intervals 11mode 11

POST phase 42Preboot Execution Environment

(PXE) 32problem management 48protocol 23

CIM 27HTTP 33ITIL 36PXE 32SNMP 24SOAP 35SSL 34Telnet 33

PXE 32boot server 38LAN Boot Extension 38protocol 32

RRARP server 39Remote Management Control

Protocol (RMCP) 31, 43Remote Procedure Call (RPC)) 35RemoteView

Management Controller (RMC) 17, 43

Service Board (RSB) 17, 43repository 6response operation 25RMC 17, 43RMCP 43

messages 31RomPilot 42RPC 35RSB 17, 43

Sschema

common 29core 28extension 29meta 28Win32 29

SDR 31

55

Index

Secondary Management Channel 41, 43

Secure Socket Layer (SSL) 34security 16

management 48Sensor Data Record (SDR) 31server

authentication 35group 18

Server Management Components 3ServerView agent 51service 37Service Oriented Architecture 36set operation 25Simple Mail Transfer Protocol (SMTP)

35, 40Simple Object Access Protocol

(SOAP) 35SMTP 35

server 40SNMP 23

agent 26, 50protocol 24

SOA 36SOAP 35

message 35use 6

SQL database 40SSL 34

certificate 35client authentication 35connection 35server authentication 35

standard MIB2 26summary 44system management 48, 49

TTCP/IP network 37Telnet 33

console 6text console diversion 42TFTP server 39time intervals 11

topology 15, 20transfer protocol 35trap 5, 12, 14, 20, 22, 41, 50

integration 22

UUML 29Unified Modeling Language (UML)

29

Vvirtual LAN 31VLAN 31

Wweb browser 6, 17web server 40WfM (Wired for Management) 32Win32 Schema 29Wired for Management (WfM) 32

XXML document 35XSCF 17, 42

56

Comments on ServerView Basic Concepts

CommentsSuggestionsCorrections

✁

Submitted by

Fujitsu Siemens Computers GmbHUser Documentation81730 MunichGermany

Fax: (++49) 700 / 372 00000

email: [email protected]://manuals.fujitsu-siemens.com

http://manuals.fujitsu-siemens.com

sv concepts

Documents

field replaceable

secure socket

secondary

comments suggestions

target operating

hypertext

preboot execution

enterprise