Oracle Enterprise Manager Grid Control 11g R1: Business Service Management
上QQ阅读APP看书,第一时间看更新

Flavors of Oracle Enterprise Manager

As seen in the earlier section, 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 flavor 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 flavor 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 flavors of the OEM product that provide configuration support for the Oracle database and the Oracle middleware servers. Both these flavors 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 flavors 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 flavor of OEM that sits above the other flavors 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 flavors of OEM, this flavor must not only be able to manage different product installations, but also seamlessly manage the different version of these products. This flavor of OEM is referred to as Oracle Enterprise Manager Grid Control or OEM GC in short.

The Grid Control flavor 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 flavor 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 flavors of OEM:

Let's now look at each of these flavors 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 flavor 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 flavor 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 tables paces, 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.
  • Patch advisories: DB control can integrate with the patch delivery systems of Oracle to automatically recommend critical patch-sets that are required for the database. It can also alert the DBAs to all the available non-critical patches for the current version of the installed database.

    Note

    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 flavor 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 flavor 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 chapter and the book. 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.

    Note

    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 flavor 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 flavor of OEM. While these two flavors look at each installation, Grid Control looks at the entire enterprise as a whole. The Grid Control flavor 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 flavor, the remainder of this book will focus primarily on OEM Grid Control.

Note

More information is available at the official OEM Grid Control website at:

http://www.oracle.com/technetwork/oem/grid-control/overview/index.html

The subsequent sections of this book will rely heavily upon screenshots from OEM Grid Control as a tool to explain the relevant functionality and guide the reader into setting up models to manage business functions and services.