DOC

Introducing System Center Operations Manager

By Jeffrey Austin,2014-03-28 06:27
8 views 0
Introducing System Center Operations ManagerIntrod

     Introducing Microsoft System Center Operations Manager 2007

David Chappell, Chappell & Associates

    April 2007

     ? Copyright Microsoft Corporation 2007. All rights reserved.

Contents

    AN OVERVIEW OF SYSTEM CENTER OPERATIONS MANAGER 2007 .................................................................... 3 THE CHALLENGES OF MONITORING AND MANAGEMENT ........................................................................................................... 3 ADDRESSING THE CHALLENGES: WHAT SYSTEM CENTER OPERATIONS MANAGER 2007 PROVIDES ............................................ 4

    A Common Foundation for Monitoring and Managing Desktops, Servers, and More......................................................... 4

    Customizable, Model-Based Management .......................................................................................................................... 6

    Service Monitoring for Distributed Applications ................................................................................................................. 8 MANAGEMENT SERVERS AND AGENTS ........................................................................................................................ 9 UNDERSTANDING MANAGEMENT SERVERS ............................................................................................................................... 9

    Root Management Servers ................................................................................................................................................ 10

    Management Groups ........................................................................................................................................................ 10 UNDERSTANDING AGENTS ...................................................................................................................................................... 11

    Installing Agents ............................................................................................................................................................... 11

    How Agents Gather and Send Information........................................................................................................................ 12

    Working with Many Agents: Managing Clients ................................................................................................................. 13

    Working with No Agents: Agentless Management ............................................................................................................. 14 ACCESSING MANAGEMENT INFORMATION .............................................................................................................. 15 USER INTERFACES .................................................................................................................................................................. 15

    The Console ...................................................................................................................................................................... 15

    The Web Console .............................................................................................................................................................. 19

    The Command Shell .......................................................................................................................................................... 20

    Other Options ................................................................................................................................................................... 21 REPORTING ............................................................................................................................................................................ 21 CONTROLLING ACCESS: ROLE-BASED SECURITY..................................................................................................................... 23 MANAGEMENT PACKS ...................................................................................................................................................... 24 WHAT MANAGEMENT PACKS DO: SOME EXAMPLES ............................................................................................................... 24 DESCRIBING WHATS MANAGED: OBJECTS ............................................................................................................................. 25 TRACKING OBJECT STATE: MONITORS .................................................................................................................................... 26 OTHER ELEMENTS OF MANAGEMENT PACKS ........................................................................................................................... 29

    Rules ................................................................................................................................................................................. 29

    Tasks ................................................................................................................................................................................. 29

    Knowledge ........................................................................................................................................................................ 30

    Views ................................................................................................................................................................................ 30

    Reports.............................................................................................................................................................................. 30 MODIFYING AN INSTALLED MANAGEMENT PACK .................................................................................................................... 30 MANAGING COMPLETE APPLICATIONS: SERVICE MONITORING .................................................................... 31 CONCLUSION ........................................................................................................................................................................ 32 ABOUT THE AUTHOR ......................................................................................................................................................... 33

    2

    Modern organizations of any size all have one thing in common: their computing environment isn’t simple. Everybody’s world contains hardware and software of different vintages from different

    vendors glued together in different ways. Managing this worldkeeping these diverse,

    multifaceted systems runningis unavoidably complex.

    Despite this complexity, two fundamental management requirements are clear. The first is the need to monitor the hardware and software in the environment, keeping track of everything from application availability to disk utilization. The operations staff that keeps the environment running must have a clear and complete picture of the current state of their world. The second requirement is the ability to respond intelligently to the information this monitoring produces. Whenever possible, this response should avoid incidents by addressing underlying problems before something fails. In any case, the operations staff must have effective tools for fixing failed systems and applications. The goal of Microsoft’s System Center Operations Manager 2007 is to meet both of these requirements. The successor to Microsoft Operations Manager (MOM) 2005, the product is focused on managing Windows environments, including desktops, servers, and the software that runs on them. It can also be used to manage non-Windows systems and software, devices such as routers and switches, and more. Released in early 2007, Operations Manager aims at providing a solution for monitoring and managing a Windows-oriented computing world.

    The Challenges of Monitoring and Management

    Think about what’s required for effective monitoring and management in an enterprise computing

    environment. Keeping track of what’s happening on the myriad of machines in an organization means dealing with diverse software, including desktop and server operating systems, databases, web servers, and applications, together with all sorts of hardware, such as processors, disk drives, routers, and much, much more. All of these components must inform the people managing this world of their status.

    This is bound to generate lots of information. The operations staff will certainly need some kind of dedicated interface that organizes this plethora of data into understandable graphics and numbers. They’d also probably like a Web version of this interface, an option that would increase their ability to manage this world remotely. And for some scenarios, such as creating scripts, a command line interface is the best choice. Yet while a variety of user interfaces are required for working with management data as it’s generated, the ability to generate reports on historical data is also essential. How can the people responsible for maintaining this environment know how they’re doing without some way to track their history? Real-time interfaces are certainly important, but so is an intelligent way to examine long-term trends.

    Here’s another challenge: No single organizationvendor or end usercan afford to have people

    on staff who are expert in managing each part of a complex IT world. Instead, a management and monitoring tool must provide a way to apply packaged expertise via software. The product must also be capable of providing a platform for third parties to create this kind of package. And there’s more. The IT Information Library (ITIL) and the Microsoft Operations Framework (MOF) both promote an IT Service Management (ITSM) approach. Rather than focusing solely on the

    3

    details of managing individual technologies, ITSM emphasizes the services that IT provides to the business it’s part of. Given that the business people who pay for it see IT entirely in terms of these services, this approach makes perfect sense. Yet doing it successfully requires explicit support for defining and monitoring distributed applications as a whole. An organization’s email service is made up of many parts, for example, including email server software, database software, and the machines this software runs on. Providing a way to monitor and manage this combination as a single service improves IT’s ability to offer the performance and reliability that the business expects.

    Effectively monitoring and managing a modern computing environment requires addressing all of these problems. The next section gives an overview of how Operations Manager does this.

    Addressing the Challenges: What System Center Operations Manager 2007

    Provides

    While Operations Manager provides a variety of functions, three of them stand out as most important: providing a common foundation for monitoring and managing desktops, servers, and more; taking a customizable, model-based approach to management; and supporting service monitoring of complete distributed applications. What follows describes each of these three. A Common Foundation for Monitoring and Managing Desktops, Servers, and More

    Despite the diversity of enterprise computing, a single product can provide a broad foundation for a significant part of an organization’s management challenges. Understanding how Operations Manager does this requires a basic grasp of the product’s architecture. The figure below shows its major components.

    Operations Manager Operations Manager Operations Manager

    ConsoleWeb ConsoleCommand Shell

    Operations ManagerOperations ManagerOperational Data Management ServerReporting ServerDatabaseWarehouse

    Operations

    Manager

    Agent

    Clients and Servers

    4

As the diagram shows, the software that comprises Operation Manager is divided into servers and

    agents. The servers, which run on Windows Server 2003 and the forthcoming Windows Server codename “Longhorn”, divide into two categories:

     The Operations Manager management server. This server relies on an operational database,

    and it’s the primary locus for handling real-time information received from agents. As the

    diagram shows, it also provides an access point for the product’s various user interfaces.

     The Operations Manager reporting server. This server relies on a data warehouse, a database

    capable of storing large amounts of information received from agents for long periods. The

    reporting server can run predefined and custom reports against this historical data. Unlike management and reporting servers, the Operations Manager agent runs on both client and server machines. This agent runs on Windows 2000, Windows XP, and Windows Vista clients, as well as Windows 2000 Server, Windows Server 2003, and Windows Server codename “Longhorn”. To manage non-Windows devices, such as routers and switches, Operations Manager managers and agents can connect to them using SNMP or the newer WS-Management protocol. There’s

    also an option that allows retrieving basic management information from Windows systems that aren’t running agents.

    Agents send four primary kinds of information to management servers:

     Events, indicating that something interesting has occurred on the managed system. An agent

    might send an event indicating that a login attempt has failed, for instance, or that a failed

    hardware component has been brought back to life.

     Alerts, indicating that something has happened that requires an operator’s attention. For

    example, an agent might send an event for every failed login, but send an alert if four failed

    logins occur within three minutes on the same account.

     Performance data, regularly sent updates on various aspects of the managed component’s

    performance.

     Discovery data, information about discovered objects. Rather than requiring an operator to

    explicitly identify the objects to be managed, each agent can discover them itself, a process

    that’s described later in this paper.

    All of this information is sent to the operational database and/or the data warehouse, and all of it can be accessed through Operations Manager’s user interfaces. Operations staff will most often rely on the Operations Manager console, a Windows application that can display events, show

    alerts, graph performance over time, and more. A large subset of the Console’s functions can also

    be performed through the Operations Manager Web console, providing browser-based access to

    this information. And for creating scripts or for people who just prefer a command line interface, the product also allows access via the Operations Manager command shell.

    This broad foundation is essential for modern monitoring and management. It’s not enough, thoughmore is required. How, for instance, can a single product address the diversity of managed components in a typical enterprise? How Operations Manager addresses this is described next.

    5

Customizable, Model-Based Management

    Any attempt to address the broad problem of monitoring and management in a single product faces an unavoidable limitation: No one vendor can have all of the specialized knowledge required to handle the wide range of software and hardware that its customers use. Instead, what’s needed is a generalized framework for packaging specialized management knowledge and behavior, packages that can then be plugged into a common management foundation.

    This is exactly what’s provided by Operations Manager’s management packs (MPs). Each MP

    packages together the knowledge and behavior required to manage a particular component, such as an operating system, a database management system, a server machine, or something else. These MPs are then installed into Operations Manager, as the figure below shows. MonitorsRulesViews

    TasksKnowledgeReports

    Management Packs

    Windows ServerWindows VistaExchange

    Server

    SQL ServerOther Hardware

    and Software

    Operations Manager

    Management Server

    Operations ManagerOperations Manager

    AgentAgent. . .

    Managed Clients and Servers

    Since creating an MP requires specialized knowledge about managing the component this MP targets, each one is typically created by the organization that knows the most about that component. As the figure above suggests, for example, Microsoft has created MPs for client and server versions of Windows as well as for Exchange Server, SQL Server, and other Microsoft

    products. Other vendors have created MPs for non-Microsoft software and hardware about which

    6

    they have specialized knowledge. Hewlett-Packard provides an MP for its ProLiant server machines, for example, while Dell offers MPs for its servers.

    As the figure shows, each MP can contain several things, including the following:

     Monitors, letting an agent track the state of various parts of a managed component.

     Rules, instructing an agent to collect performance and discovery data, send alerts and events,

    and more.

     Tasks, defining activities that can be executed by either the agent or the console.

     Knowledge, providing textual advice to help operators diagnose and fix problems.

     Views, offering customized user interfaces for monitoring and managing this component.

     Reports, defining specialized ways to report on information about this managed component. When an MP is installed, its various parts wind up in different places. The monitors and rules, for instance, are downloaded to the agents on the appropriate machines, while the knowledge and reports remain on the management and reporting servers. Wherever its contents are used, the goal is always the same: providing the specialized knowledge and behavior required to monitor and manage a particular component.

    To get a sense of how the various components of an MP might work together, imagine that an application running on some managed system notices that it lacks sufficient disk space to function. This application writes an event into the system’s event log indicating this, then shuts itself down.

    The Operations Manager agent on this system continually monitors the event log, and so it quickly notices this event. If the application’s MP contains an appropriate rule, the agent will send a specific alert to the management server when this event occurs. The operator sees the alert in the Operations Manager console, and he also sees the MP-provided knowledge associated with this alert. Reading this knowledge, he learns that he should direct the agent to run a task that deletes the temp directory on the application’s machine, then restart the application. This entire process, from detection of the problem to its ultimate resolution, depends on the information contained in the MP.

    Of course, it would be better to avoid this problem in the first place. One way to do this is to keep an eye on things such as free disk space on the machine hosting this application, then inform an operator when a problem looms. Doing this requires creating a model of what a healthy managed component looks like, then indicating any deviation from its normal state. In Operations Manager, this is exactly what monitors are for. Each MP defines a set of objects that can be managed, then

    specifies a group of monitors for those objects. These monitors keep track of the state of each object, making it easier to avoid problems like application crashes before they occur. In the language of Operations Manager, the set of monitors for a managed object comprise a health

    model for that object. By tying together the health models for the various objects on a system, an overall health model can be created that reflects the state of the system as a whole. Allowing each MP to define its own set of managed objects makes sense. Yet the best an MP’s creators can do is define generic objects; they can’t know exactly what’s on any given system. For

    example, the SQL Server MP defines an object representing a database. When this MP is installed on a real system, that machine might have one, two, or more actual databases. How are these

    7

    concrete instances of the MP’s generic object type found? One approach would be to require an operator to identify each instance manually, a task that nobody would enjoy. Instead, Operations Manager allows each MP to include specific discovery rules (also called just discoveries) that let

    the agent locate these instances. The goal is to make finding the things that need to be managed as straightforward as possible.

    Providing this generalized approach to defining management knowledge and behavior requires a common technology to create these definitions. Like other products in the System Center family, Operations Manager relies on an XML-based language called the System Definition Model (SDM)

    to do this. All MPs are expressed in SDM, providing a standard format for their creators to use. Defining MPs with SDM also implies a more general, less Windows-specific infrastructure for management. Although Operations Manager remains a Windows-oriented product, it’s significantly

    less wedded to the Microsoft world than was its predecessor.

    In fact, SDM is the basis of an in-progress standard known as the Service Modeling Language

    (SML). Embraced by Microsoft, BEA, BMC, CA, Cisco, Dell, HP, IBM, and Sun, SML will provide a vendor-neutral foundation for describing managed systems. The value of a model-based approach to this problem is clear, and it’s a fundamental aspect of Operations Manager.

    Service Monitoring for Distributed Applications

    The goal of virtually every IT department is to provide services to the organization it’s part of.

    Monitoring and managing the various parts of the IT environment is an essential aspect of doing this. Yet business people don’t really care about the state of individual components. Instead, their concern is for the services they see. Can they send and receive email? Are the applications they need right now running effectively? This service-based concern makes sense, since it reflects what’s most important to the organization as a whole. Yet each service is likely made up of a number of underlying components, including both software and hardware. Looking at each of an application’s components separately isn’t enough.

    What’s needed is a way to monitor and manage a distributed application—the combination of

    components that underlie a particular serviceas a whole. Operations Manager provides this

    through service monitoring. The diagram below illustrates this idea.

    8

    Operations Manager

    Management Server

    Operations ManagerOperations ManagerOperations Manager

    AgentAgentAgent

    Internet ASP.NET SQL ServerInformation DatabaseApplicationServices (IIS)

    Service

    Think, for example, about a custom ASP.NET application. As the figure suggests, this application’s main components might include IIS, the application itself, SQL Server, a specific database, the network used to connect these components, and more. From a technology point of view, all of these are distinct pieces, and without some way to group them together, an operator would be hard pressed to know that they actually comprise a single distributed application. From the perspective of a business user, however, all that matters is the service this entire application provides. If any part of it is malfunctioning, the entire service is likely to be unavailable. Letting the operator know that, say, a failed disk drive is actually part of this business-critical application can help that operator understand the importance of getting it back on line as quickly as possible. Rather than viewing their world as discrete components, operations staff can instead have a perspective that’s closer to what their customers see: a service-based view.

    Getting a grip on Operations Manager requires understanding a number of different concepts. None of these ideas are more fundamental than management servers and agents, and so the place to begin is by looking more deeply at these bedrock parts of the product.

    Understanding Management Servers

    Management servers are at the center of Operations Manager. Agents send them alerts, events, performance data, and more, and they’re also the access point for the product’s user interfaces.

    9

    While the basic architecture is straightforward, as shown earlier, understanding Operations Manager requires knowing a bit more about management servers. This section takes a slightly more detailed look at this important part of the product.

    Root Management Servers

    Every agent communicates with exactly one management server. While many organizations could potentially meet their needs with a single management server, it’s common to install two or more management servers, then divide agents among these servers. In this case, the first server that’s installed becomes the root management server. This root server communicates with any other

    management servers that have been installed, and it also communicates with its own agents. The root management server performs several unique functions. All of Operations Manager’s user interfaces connect only to the root management server, for example, as shown earlier. Given this central role, it’s common to cluster a root management server. (All of these connected management servers rely on a single operational database, so it’s also a good idea to cluster it.) If

    a root management server fails, an administrator can promote another management server, allowing it to become the new root.

    Management Groups

    A collection of Operations Manager servers and agents is known as a management group. Each

    management group contains one root management server, zero or more other management servers, an operational database, and zero or more agents. The figure below illustrates how the various parts of a management group fit together.

    Console

    RootOperational Management ServerDatabase

    Management ServerManagement Server

    AgentAgentAgentAgentAgentAgent

    AgentAgentAgent

    Operations Manager can support many agents in a single management groupthe exact number depends on a variety of factors--but organizations that need more than this can install multiple

     management groups. And although it’s neither required nor shown in the diagram, a management

    group can also contain a reporting server.

    10

Report this document

For any questions or suggestions please email
cust-service@docsford.com