Overview - English
FUJITSU Software ServerView Suite
Basic Concepts
Edition April 2015
Comments… Suggestions… Corrections…
The User Documentation Department would like to
know your opinion of this manual. Your feedback helps
us optimize our documentation to suit your individual
needs.
Feel free to send us your comments by e-mail to
manuals@ts.fujitsu.com.
Certified documentation
according to DIN EN ISO 9001:2008
To ensure a consistently high quality standard and
user-friendliness, this documentation was created to
meet the regulations of a quality management system
which complies with the requirements of the standard
DIN EN ISO 9001:2008.
cognitas. Gesellschaft für Technik-Dokumentation mbH
www.cognitas.de
Copyright and Trademarks
Copyright © 2015 Fujitsu Technology Solutions 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.
Contents
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2
Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1
2.1.1
2.1.2
2.1.3
2.1.4
Server management components
Managed servers with agents . . .
Management applications . . . . .
Management consoles . . . . . . .
Helpers . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
. 9
. 9
10
11
2.2
2.2.1
2.2.2
2.2.3
2.2.4
Management principle:
agent and management station . . . . . .
Management cycle . . . . . . . . . . . . . .
Interface between monitoring and analysis .
Interface between adaptation and execution
Autonomous management on the server . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
15
16
17
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
Hierarchical configurations . . . . . . .
Local management . . . . . . . . . . . .
Point-to-Point management . . . . . . . .
Central management . . . . . . . . . . .
Cascaded management . . . . . . . . . .
Integration into other management systems
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
18
20
22
23
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.4.7
2.4.8
Protocols . . . . . . . . . . . . . . . . . . . .
SNMP - Simple Network Management Protocol .
CIM (Common Information Model) . . . . . . .
IPMI - Intelligent Platform Management Interface
PXE - Preboot Execution Environment . . . . .
Telnet . . . . . . . . . . . . . . . . . . . . . .
HTTP - Hypertext Transfer Protocol . . . . . . .
SOAP - Simple Object Access Protocol . . . . .
ITIL - IT Infrastructure Library . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
29
32
34
35
35
36
37
2.5
2.5.1
2.5.2
2.5.3
2.5.4
Helpers . . . . . .
DHCP server . . . .
PXE boot server . .
TFTP server . . . .
Mail server (SMTP)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
39
40
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
2.5.5
2.5.6
Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
MS Excel, Access or SQL databases . . . . . . . . . . . . . . . 41
2.6
2.6.1
2.6.2
Management mode . . . . . . . . . . . . . . . . . . . . . . . 41
Management mode „in-band“ . . . . . . . . . . . . . . . . . . . 41
Management mode „out-of-band“ . . . . . . . . . . . . . . . . . 42
2.7
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3
Positioning of ServerView
3.1
ServerView Suite
3.2
Integration into other management systems . . . . . . . . . 47
3.3
Integration of other components . . . . . . . . . . . . . . . . 48
. . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . 47
1
Introduction
The 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 chapter "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
communication 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 chapter "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
ServerView Suite, these paragraphs can be skipped.
5
2
Basic concepts
The 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 systems.
2.1
Server management components
Server management components can be divided into four categories:
– managed servers
– management applications
– management consoles
– helpers
Figure 1 is a schematic view of the interaction of these server management
components.
7
Server management components
MANAGEMENT
CONSOLES
HELPERS
Console
Console
MANAGEMENT
APPLICATIONS
Management
Application
Management
Application
Helper
Management
Application
Helper
MANAGED
SERVERS
WITH AGENTS
Agent
Agent
Agent
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
disadvantages.
8
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
information, 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 25).
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.
9
Server management components
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
communicates with the console using HTTP/HTML or HTTPS/HTML (see
also section "Protocols" on page 25).
– Agents on managed servers
Management applications communicate with agents in order to obtain
information 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 25) or proprietary protocols.
– Helpers (see also section "Helpers" on page 38)
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 ServerView management applications are: ServerView Operations
Manager, ServerView Download Manager, ServerView Event Manager,
ServerView Deployment Manager and ServerView 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 ServerView Suite include
web browsers and Telnet consoles.
10
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
(section "DHCP server" on page 38) and the TFTP service (section "TFTP
server" on page 40) that are used by ServerView Deployment Manager, or
Microsoft Excel/Access, which can be used to manually edit files created using
ServerView.
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 cooperate 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.
Based on this agent and management station principle, the procedure for
management operations is explained below, using the examples of certain
typical actions.
11
Management principle: agent and management station
2.2.1
Management cycle
Server management is a continuous process, which can be represented
schematically by the cycle shown in Figure 2.
Analysis
Adaptation
Knowledge
& Rules
Monitoring
Execution
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
determining 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.
12
Management principle: agent and management station
Particularly for the analysis and adaptation phases, knowledge and rules are
necessary:
– 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.
13
Management principle: agent and management station
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
information 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 ServerView Event Manager in such a way that scripts are
automatically executed when particular traps are received.
14
Management principle: agent and management station
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
milliseconds. 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.
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.
15
Management principle: agent and management station
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.
The following 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 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, Deployment
Manager from the ServerView Suite is used to install or clone the individual
server blades. In this case, no agent is initially present on the server blades.
Deployment Manager uses PXE (see also section "Protocols" on page 25) to
automatically add agents to the server blades. These agents then co-operate
with the Deployment Manager components and other helpers to execute the
installation or cloning process.
16
Management principle: agent and management station
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
intervention of an administrator, it is known as an autonomic cycle.
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.
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 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 administrator on
the ServerView console.
– Local ServerView Event Manager
The ServerView Event Manager 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 ServerView Event
Manager. However, it is also possible to execute a script automatically, which
triggers actions that are necessary in the particular situation.
17
Hierarchical configurations
The ServerView Event Manager 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.
18
Hierarchical configurations
MANAGEMENT
CONSOLES
MANAGED
SERVER
Console
Management
Application
Management
Application
Agent
Agent
Figure 3: Point-to-point management
The advantages of this configuration are increased security and greater
availability.
– Increased security
The SNMP protocol that is frequently used between agents and
management applications offers security mechanisms that may not be
sufficient 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/TLS are used for communication
between the console and the management application.
19
Hierarchical configurations
– Greater availability
If the manager is running on a central computer rather than using point-topoint 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
ServerView Suite components include:
– Agent and ServerView Operations Manager 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/TLS (HTTPS).
– The integrated Remote Management Controller (iRMC) 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 „out-of-band“" on page 42).
– Agent and ServerView Event Manager on the managed server. In this case,
no traps are sent via the network and they cannot therefore be lost. For
example, the ServerView Event Manager can inform the administrator of
problems directly from the managed server or automatically execute scripts.
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.
20
Hierarchical configurations
– 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.
MANAGEMENT
CONSOLES
Console
MANAGEMENT
APPLICATIONS
Management
Application
MANAGED
SERVER
Agent
Agent
Figure 4: Central management
Typical ServerView configurations for a consolidated view are realized by
installing the ServerView Operations Manager and/or the ServerView Event
Manager on a central computer.
21
Hierarchical configurations
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.
MANAGEMENT
CONSOLES
Console
Management
Application
MANAGEMENT
APPLICATIONS
Management
Application
Management
Application
Agent
Agent
…
Agent
MANAGED
SERVER
Figure 5: Cascaded management
In the ServerView Suite, it is the ServerView Event Manager 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 Event Manager. However, the ServerView Event Manager 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.
22
Hierarchical configurations
By configuring several ServerView Event Manager accordingly from a
management console, it is possible to specify which traps are sent to the next
level up by which Event Manager.
Cascading of ServerView Event Manager 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.
2.3.5
Integration into other management systems
The ServerView Suite can also be integrated into other management systems,
such as Microsoft SCOM,VMware vCenter, Nagios, and HP Systems Insight
Manager. 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.
ENTERPRISE
MANAGEMENT
SYSTEM
Enterprise
Management
System
Management
Application
MANAGEMENT
APPLICATIONS
Management
Application
Agent
Agent
Agent
MANAGED
SERVER
Figure 6: Integration into other management systems
23
Hierarchical configurations
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 ServerView Event
Manager. Agents send their traps to the ServerView Event Manager, which
forwards either all traps or filtered traps to the enterprise management
system, depending on its configuration.
A similar kind of integration consists of an enterprise management system,
e.g. SCOM (System Center Operations Manager), evaluating entries in the
event log file managed by the operating system. As the ServerView Event
Manager enters SNMP traps in this log file as events, to some extent this
can be thought of as indirect trap integration.
– 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 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.
24
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 Suite uses 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.
25
Protocols
MANAGEMENT
STATION
Console
Management
Application
Get
Simple
Object:
- Name
- Value
Getnext
Trap
Set
Simple
Object:
- Name
- Valuet
Response
Agent
Agent
MANAGED
SERVER WITH AGENTS
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.
26
Protocols
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.
27
Protocols
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
corresponding 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.
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/
28
Protocols
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".
29
Protocols
Meta Schema
(DMTF)
Abstract
Spezifications
Core Schema
(DMTF)
Extension
schemata
(manufacturerspezific)
Network
WIN32
Schema
Applications
FSCSV
Schema
...
...
MOF
Refinement
MOF
Common Schema (DMTF)
Systems
Concrete
Spezifications
MOF
Figure 8: CIM (Common Information Model)
The CIM is developed by DMTF and consists of the following major
components:
– 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.
30
Protocols
– 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,
applications/metrics, policy, pre-OS and utility computing. All of these class
definitions 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 schema for ServerView Suite, 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.
31
Protocols
2.4.3
IPMI - Intelligent Platform Management Interface
Management
Software Stack
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.
CIM
Application
SNMP
Agent
CIM Object
Manager
CIM Provider
IPMI
Instrumentation Code
IPMI Interface Code
IPMI H/W Interface
IPMI Interface
Platform Mgmt. Controller
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 computer
because it has its own processor and memory. This controller performs all
functions provided via the IPMI interface. IPMI has been continuously
developed over the years, increasing the scope of the management functions.
The components of the 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
32
Protocols
– 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
identifiable and enables this information to be requested via the IPMI
interface. The basis for this is the concept of FRU (Field Replaceable Unit)
information. The structure of this information is defined by the IPMI
specification and can be expanded on a manufacturer-specific basis.
Fujitsu 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
motherboards, 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.
33
Protocols
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
established 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 ServerView Suite, PXE is used by Deployment Manager.
Further information about PXE and WfM can be found at :
http://www.intel.com/technology/computing/wfm.htm
34
Protocols
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
denominator" 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/TLS.
In the ServerView Suite, the Telnet protocol is used by the components of the
Out-of-Band management.
Further information about Telnet can be found at
http://www.ietf.org/rfc/rfc0854.txt
2.4.6
HTTP - Hypertext Transfer Protocol
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.
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
references.
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.
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
35
Protocols
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
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).
36
Protocols
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
application software, however, it is also gaining in significance for management
software.
In the ServerView Suite, SOAP is used for communication between
components from the management application category, for example between
Deployment Manager components.
Further information about SOAP can be found at
http://www.w3.org/TR/soap or
http://www.microsoft.com/mind/0100/soap/soap.asp
2.4.8
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
consultancy firms to support and improve the use and operation of operational
IT infrastructure. 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.
37
Helpers
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
Contingency Planning.
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
information, 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
38
Helpers
The DHCP server is an important helper for the ServerView Suite. 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.
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 IP 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.
PXE boot servers are used as follows in the ServerView Suite:
– Remote use of ServerView Installation Manager, where the Installation
Manager OS directory is created on the PXE boot server and copied and
started on the server to be installed via PXE.
– Cloning operation with Deployment Manager, 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 "FUJITSU Software ServerView Suite,
Deployment Manager" manual.
39
Helpers
2.5.3
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
significantly more powerful FTP (File Transfer Protocol). Many network
components use a TFTP server to load their basic operating system or their
initial configuration 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 Deployment Manager and Update Manager or in conjunction
with RARP.
2.5.4
Mail server (SMTP)
Mail servers are used in the ServerView Suite to inform administrators when
ServerView has detected certain situations. For example, the ServerView Event
Manager can be configured such that it sends a mail to the administrator or
service provider when it receives certain traps.
The ServerView Event Manager can work in conjunction with the following mail
server:
– 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 Event Manager" manual.
2.5.5
Web server
Certain components of the ServerView Suite allow you to use web browsers to
access the management information. These components, which include
ServerView Operations Manager, co-operation with web servers that then make
the information prepared by ServerView available to any browsers via HTTP.
40
Management mode
2.5.6
MS Excel, Access or SQL databases
The Microsoft Excel/Access programs and SQL databases are other examples
of helpers. The files generated by ServerView Inventory 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.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.
– 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 „in-band“
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
communication path.
41
Management mode
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 „In-Band“
for management of the server. The ServerView Suite therefore also provides the
management mode described below.
A typical example of management mode „In-Band“ is management of a
managed server using the operating system-specific ServerView SNMP agents.
2.6.2
Management mode „out-of-band“
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/TLS. In contrast to management
mode „In-Band“, the management information is not provided by functions of the
target operating system but comes directly from sensors, via IPMI compatible
integrated Remote Management Controller (iRMC) or separate log files.
In the ServerView Suite the integrated Remote Management Controller (iRMC)
allows direct access to the server regardless of its status 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
ServerView Suite provides the following solutions: ServerView applications,
such as ServerView Remote Management and Deployment Manager,
communicate with the iRMC via IPMI-over-LAN and then provide the
administrator with communication via their user interfaces, e.g. HTTP.
However, these independent components used for management mode „Out-ofBand“ do not necessarily have to be exclusively assigned to a single managed
server. They can also be used as Secondary Management Channels for several
42
Summary
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 „Out-of-Band“ 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.
– 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. In these cases, management mode „Outof-Band“ 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.
43
Summary
– 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
hierarchical configurations to be set up. Five such configurations were
presented by way of example: Local management, point-to-point
management, consolidated management, cascaded ServerView Event
Manager and integration into other management systems.
– 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/TLS, SOAP and ITIL.
– Management modes
Depending on the operating system status on the managed server (OSup/OS-down) and the communication path used for management purposes
(in-band/out-of-band), there are different management modes that are
available for the management of PRIMERGY servers.
44
3
Positioning of ServerView
This section the relation between ServerView and other enterprise
management systems is discribed.
Figure 10 provides a schematic overview of the enterprise management area.
Management
Areas
System
Management
Applications
Management
Memory
Management
…
License
Management
Asset
Management
Accounting
Management
Productions
Management
Security
Management
Performance
Management
Error
Management
Management
Functions
User
Management
Enterprise Management
Network
Management
Figure 10: Enterprise management
A distinction is made here between management areas and management
functions.
45
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 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
– performance management
– asset management
46
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 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 servers, although at the same time - in an integrated
way - the ServerView functionality is available for system management.
47
Integration of other components
ServerView integration modules are available for management systems
including the following:
– Microsoft SCOM
– Microsoft SCCM
– Microsoft SC VMM
– Microsoft SC PRO Packs
– VMware vCenter
– Nagios
– Icinga
– HP Systems Insight Manager
– CA Spectrum
3.3
Integration of other components
Two concepts for how objects other than the PRIMERGY servers can be
integrated into management using the ServerView Suite are described below.
Integration into ServerView Event Manager
The realization of the ServerView Event Manager 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 Event Manager. If the Event Manager 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 ServerView Event
Manager. These include traps from fiber channel switches, RAID controllers,
storage systems, power supplies etc.
48
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 servers.
HP servers can now be integrated into the ServerView Suite using this method.
Heterogeneous environments can thus be completely managed using the
ServerView Suite. Details can be found in the white paper "Integration of HP
Servers into ServerView Operations Manager.
49