18 min read

 

Oracle Enterprise Manager Grid Control 11g R1: Business Service Management

Oracle Enterprise Manager Grid Control 11g R1: Business Service Management

A Hands-on guide to modeling and managing business services using Oracle Enterprise Manager 11g R1

        Read more about this book      

(For more resources on this subject, see here.)

IT staff in any enterprise need different perspectives to get a comprehensive view of the health of the various business services and the underlying IT infrastructure. In the previous article, the various models of visualizing the IT infrastructure were introduced. Oracle Enterprise Manager (OEM) is one of the industry leaders in the system management products arena. OEM 11gR1 addresses the complexities of managing today’s IT infrastructure by providing different models for visualization.

Oracle Enterprise Manager concepts

OEM is a software offered by Oracle that provides a single unified platform for modeling and managing enterprise data centers. Although targeted primarily towards managing the Oracle suite of products within an enterprise, it also has built-in capabilities to model and manage a limited set of widely adopted non-Oracle software products. It provides comprehensive monitoring and management capabilities for the entire Oracle Grid within the enterprise. It covers all aspects of the Oracle stack starting from the physical host management to database management. It also includes management for Oracle middleware components and the applications running on it. As discussed in the previous article, the mindset of IT executives has shifted more towards business enablement using IT infrastructure rather than just IT operations management. However, the shift in focus does not mean that IT operations can be ignored. In fact, companies are now keen to understand the impact of IT operations on their business service offerings.

Therefore, in the current context, an enterprise-wide IT infrastructure management product must be able to provide modeling and management functionalities for business services, along with excellent capabilities around the management of the day-to-day IT operations. OEM is one of the few products that provides complete capabilities around service modeling as well as tools to assess the impact of IT operations on the business service.

Let’s now look at some of the key features provided by OEM. OEM provides discovery, monitoring, and management of various pieces of the IT infrastructure. Each of the pieces or entities that need to be monitored and managed is known in the OEM parlance as a target. The above features provide the foundation for the rich set of management capabilities offered by OEM. Therefore, prior to proceeding any further, let’s take a cursory look at these features:

  • Target discovery: It involves finding, mapping, and then modeling a physical or logical entity in the IT infrastructure in OEM. Each of these entities that are part of the IT infrastructure must be modeled in OEM as one or more targets. The discovery part begins with finding the entity, then mapping it to a particular OEM type, and it ends with the creation of the actual target instance within OEM.
  • Target monitoring: It revolves around providing an insight into the basic functioning of the target. For example, target monitoring essentially provides the answer to the administrator’s question: “Is the target up, and if so is it performing as well as we expect it to?”
  • Target management: It revolves around performing active changes to either the current process status or the configuration of the target. As an example, changing the status of a target process might involve stopping a current process related to the target (or the entire target itself). Similarly, as an example, changes to the configuration might involve changing the number of simultaneous user requests a server might have to handle.

Target modeling and monitoring is the base on which other models can be designed. These higher level models are important and allow administrators to aggregate individual targets into buckets that are more aligned with the business. These buckets are also OEM targets in their own right and are modeled as such. These aggregate targets now allow OEM developers and integrators to build higher level features and capabilities that allow mapping of business priorities onto the IT infrastructure. These aggregate targets are of three main types:

  • Group: A group target is a collection of individual targets of the same type. This aggregation is intended to provide a mechanism to monitor and manage targets of the same type. A typical example of such an implementation is a database group. A DBA might be responsible for all the databases within such a group. The group target now presents the administrator with a view of all the databases of concern.
  • System: A system target is a collection of individual targets that form the base for providing a business service. While the group target can be viewed as more of a physical aggregation, the system target is intended to provide a functional one. An example of a system target is a website. This system will include disparate targets that are involved as part of the hosting website.
  • Service: A service target is a logical target and more often than not, represents the end user functional view of the IT infrastructure. The service model is the one closest to the business view and is used to represent the business functionality provided by the underlying infrastructure. It is therefore the target most likely used to map and subsequently track business priorities. An example of a service target is user authentication service. This service maps to the functional business service of providing user authentication. It might be modeled on an underlying authentication system that represents the physical infrastructure used to provide the functionality. The service target provides a mapping of the business function to the physical infrastructure.

These are very brief examples that are intended to introduce some of the concepts in OEM. A more detailed introduction and a deeper dive into these concepts are provided later in this article.

Flavors of Oracle Enterprise Manager

The OEM product provides features to manage and monitor the IT infrastructure within an enterprise. These features enable the users to perform configuration changes and also monitor the installed products. These installed products need to support the various business functions of the enterprise. It is therefore a reasonable assumption that these products are very complex in nature and need detailed support utilities and console applications to allow administrators to configure and manage them. To elaborate further with an example, let’s consider the case of an Oracle database installation. The database might be installed in a cluster to provide high availability and failover support. The database product by reason of having evolved over a couple of decades will expose many different installation and subsequent configuration options. In fact, the configuration of a database is very specific to the business function that it needs to support. There can be hundreds of options that an administrator needs to tweak in order to get the database configured just right. To support the above installation and configuration options of a specific database instance, the database comes equipped with a set of command-line utilities and also a console application.

As one can imagine, the command-line utilities and the console application are very specific to the database version and provide a means to view and change the configuration parameters. Just as any other product in the market, the database product also evolves with time. This evolution results in newer versions of the product with features that cater to the demands of the administrators, the end users, and the applications that run on it. Just as the old features, these new features also need to be configured and tuned to the environment in which the database will be installed. Therefore, along with the newer features, the associated command-line utilities and the console application that allows the administrators to view and configure the parameters also needs to change. Hence, the console application is closely tied to the version of the database. This console application is also a favor of OEM and is referred to as Oracle Enterprise Manager Database Control or OEM DB Control in short.

All the preceding arguments for the database product also hold true in the case of a middleware application server. In case of the application server as well, there are a set of command-line utilities and a console application that is deployed out-of-the-box that provides detailed configuration options. The console application and the command-line utilities are very specific to the application server and provide the ways and means to view and change any and all of the configuration parameters that are exposed by the middleware server. Just as in the case of the database, the console application that configures the various parameters of the middleware server is another favor of OEM and is referred to as Oracle Enterprise Manager Application Server Control or OEM AS Control in short. While AS Control is responsible for management of OC4J targets, Oracle Fusion Middleware (FMW) Control provides management capabilities for Oracle WebLogic server and the middleware components that are deployed on it.

We have now seen two favors of the OEM product that provide configuration support for the Oracle database and the Oracle middleware servers. Both these favors are very specific to the respective products that they come bundled with. Each installation of the database of the middleware server will be associated with its corresponding installation of the configuration application and utilities. From this, it is evident that each instance of these favors of OEM is only aware of the product installation that they are configured.

This leaves us with a huge gap at the wider enterprise level. This gap can be bridged by a favor of OEM that sits above the other favors and provides a wider view of the entire enterprise IT infrastructure. At the enterprise level, there might be hundreds, if not more, of these individual database and middleware server installations. It is also very likely and indeed is the case that these installations are of different versions. As an example, the data center of a large enterprise might have a few hundred installations that span the 10g and the 11g versions of the database. Similarly, there might be a few hundred installations of Oracle OC4J and WebLogic middleware servers. The OC4J servers versions can be 10.3.3 or 10.3.4 and the WebLogic servers can be of versions 10.3.0 and beyond. Unlike the previous two favors of OEM, this favor must not only be able to manage different product installations, but also seamlessly manage the different version of these products. This favor of OEM is referred to as Oracle Enterprise Manager Grid Control or OEM GC in short.

The Grid Control favor of OEM is centrally installed within the data center and is capable of providing a business view of the infrastructure. As seen by this description, this favor is not specific to one product, but is a step higher and looks at all the products in the enterprise data center. It is capable of reporting summary status of the infrastructure in a manner that is aggregated by the business function. The user can then drill down to a business service of interest, and then further drill down to any of the target instances from this view. This flow is much more meaningful as it not only provides a business service mapping of the infrastructure, but also provides significant information for the administrator to drill down to the correct target instance in case of service outage issues.

The following image provides a pictorial view of the three different favors of OEM:

Oracle Enterprise Manager Grid Control 11g R1: Business Service Management

Let’s now look at each of these favors and their functionalities in more detail.

OEM Database Control

OEM Database Control or just DB Control is a web-based console application that is shipped and optionally installed when an Oracle database product is installed. It may be noted right here that this favor of OEM is optional during the installation of the Oracle database product. In its absence, various command-line tools and utilities must be used to configure and manage a single database instance. However, the DB Control application provides a graphical and more intuitive view of the database installation.

The DB control favor of OEM primarily supports the database and the listener targets, and provides the following key set of features to the DBAs:

  • Database status: It shows the current status of the database and listener instances.
  • Administrative tasks: It provides graphical UIs to the DBAs to perform routine administrative tasks such as management of table spaces, indexes, and tables.
  • Backup recovery: It provides graphical UIs to the DBAs to configure a database instance for backup. It also allows the DBAs to manage the backup snapshots by setting retention policies. It is also capable of restoring the database using any of the available backup snapshots. Apart from a full database backup, it also provides UIs to export and import data from a specific schema of an instance.
  • User security management: It provides graphical UIs to the DBAs to view the current set of users and their corresponding roles. It also provides an exhaustive set of views to manage and audit these database users and roles.
  • Process control: It provides graphical UIs to the DBAs to view and edit all the initialization and memory parameters of the database. It supplements this by also allowing the DBAs to stop and restart the individual instances of the database.
  • Monitoring and tuning: It provides graphical UIs to the DBAs to monitor the availability and performance in real time and set thresholds on the key performance indicators of the database instance. When these thresholds are violated it raises alerts and can send e-mails to the configured administrative accounts. It also provides UIs that enable the DBAs to make use of the tuning features provided with the database.

More information on the latest version of OEM DB control is available at:http://download.oracle.com/docs/cd/E11882_01/server.112/e10897/toc.htm

OEM application server and Fusion Middleware Control

As seen above with the database, this favor of OEM is used for viewing and managing a single middleware instance. Under the Oracle middleware family, there are many suites of products available. Each of these comes bundled with its own console application that is used to view, configure, and manage the individual installations. Oracle middleware products run on two different application servers. These are Oracle Container for J2EE (or OC4J in short) and WebLogic Application Server. The console application shipped with the suite of products that run on OC4J is called OEM Application Server Control. The console application shipped with the suite of products that run on WebLogic is called OEM Fusion Middleware Control (or OEM FMW Control in short). It may be noted at this time that a number of products that run on the OC4J server, are deprecated and are replaced by the suite of products running on the WebLogic server.

The FMW Control favor of OEM primarily models the WebLogic domain, server, application deployments, and the suite of applications that provide the general middleware functionality. A comprehensive listing of the features of FMW Control is outside the scope of this article. However, some of the key features provided to the middleware administrators are listed as follows:

  • Status tracking: It shows the current status of all the middleware targets that are present in the installation.
  • Process control: It provides graphical UIs to the administrators to stop and start the individual pieces of the middleware installation.
  • Monitoring and tuning: It provides graphical UIs to the administrators to monitor in real time and set thresholds on the key performance indicators of the middleware targets. When these thresholds are violated it raises alerts and can send e-mails to the configured administrative accounts.
  • configuration pages: It provides detailed graphical UIs to the administrators to view and modify all the parameters of the applications and processes that form a part of the middleware suite of products.
  • Diagnostic tools: It provides graphical UIs that help administrators perform diagnostic activities for some of the products in the middleware suite.

More information on the latest version of OEM FMW control is available at: http://www.oracle.com/technetwork/middleware/docs/middleware-093940.html

OEM Grid Control (GC)

This favor of OEM works at the enterprise level and primarily focuses on managing the entire Oracle grid of products. It works one step above the DB Control and the FMW Control favor of OEM. While these two favors look at each installation, Grid Control looks at the entire enterprise as a whole. The Grid Control favor of OEM can manage the entire enterprise grid and covers most of the Oracle product suites. Apart from this it also comes with out-of-the-box support for some non-Oracle product suites. The Grid Control architecture is extensible by design, and allows third-party vendors and distributors to add support for newer products. These third-party extensions are known as OEM Grid Control Management plugins. Such a model enables external vendors and integrators to add to the breadth of products whose management is supported by OEM Grid Control.

As OEM operates at the enterprise level, it can provide a richer set of models to support mapping business functions and IT operations. At the same time, it can seamlessly link into the individual product controls as required by the administrators. As an example, consider the travel portal. With DB and AS control, while we can certainly monitor each middleware and database server, we cannot configure a perspective that shows the relevant IT infrastructure that is used to provide the portal function. However, by introducing Grid Control we can build this perspective as it has visibility into all the components of the IT infrastructure. At the same time, in case a change is required in the configuration of the database, it has built-in capabilities to navigate to the relevant page in the corresponding DB Control.

Another important distinction is that the Grid Control variety of OEM comes with its own repository where all the model and target data is stored. This repository is also used to store the performance metrics. This implies that Grid Control can provide views and trends of the performance of any component or a composite model. This enables the administrator to get a sense of the system performance on both a real-time and historical basis. By having snapshots of historical configuration and behavior, administrators can also compare these snapshots. In combination with the system and service models, this provides the administrator with a valuable tool to link business service behavior with configuration changes. As an example, consider that end users are reporting a sudden drop in performance on Monday morning as compared to the past Friday. The service administrator knows that there was a maintenance window scheduled during the weekend, but doesn’t know what parameters were changed. Using Grid Control the administrator can now compare the current configuration with the snapshot taken on Friday prior to the maintenance. If the comparison shows that database sort cache size was (inadvertently) reduced, the service administrator in conjunction with the DBA can immediately correct this and restore the service to normal levels.

OEM Grid Control provides the following key features:

  • Data center level visibility: As it resides and operates at a higher level, it provides insight into the entire data center by providing a comprehensive view.
  • Enterprise availability view: Provides an enterprise-level view of the targets that are currently up or down or in any other state.
  • Incident management: Provides an enterprise-level view of the various critical and warning alerts as well as policy violations.
  • Business modeling paradigms: Provides a richer set of modeling paradigms that enable the IT staff to map business functions to the underlying IT infrastructure.
  • Historical data and comparisons: As it comes with its own repository for data storage, it exposes historical views from which trends can be derived. It also allows comparison of data from two different times thus enabling the mapping of service behavior with underlying changes to IT configuration.
  • Scheduling of jobs: Using Grid Control administrators can schedule mundane operations such as running scripts and target stop starts. Based on the schedule these operations will automatically be run on the right set of targets. The status of these operations can be tracked independently at a later stage.
  • Data center inventory: Most often overlooked, but an important feature of Grid Control is the ability to provide the IT staff with an inventory of the components deployed within the data center. This eliminates the need to maintain complex sheets to track components and their locations.
  • Provisioning new components: Grid Control allows the creation and maintenance of a gold image of the configuration of supported products. These images can then be used to automatically provision new systems in the data center.
  • Information publishing using reports: Grid Control provides extensive reporting capabilities around the targets configured. This is supplemented by many out-of-the-box report templates that can be applied on targets to automatically publish information related to it. These reports can also be scheduled and e-mailed to the relevant IT staff
  • Always on monitoring: The architecture of Grid Control enables it to be always on and monitoring the enterprise grid. Rules can be set throughout the product to identify problems and alert the concerned IT staff based on the targets.

As the features related to BSM are provided by this favor, we will focus primarily on OEM Grid Control.

More information is available at the official OEM Grid Control website at: http://www.oracle.com/technetwork/oem/grid-control/overview/index.html

LEAVE A REPLY

Please enter your comment!
Please enter your name here