| Oracle® Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching 10g Release 5 (10.2.0.5.0) Part Number E14500-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching 10g Release 5 (10.2.0.5.0) Part Number E14500-04 |
|
|
PDF · Mobi · ePub |
Enterprise Manager Grid Control offers lifecycle management solutions in the form of Deployment Procedures to meet your provisioning and patching requirements. This chapter describes the overall coverage of the provisioning and patching features, the coverage of Deployment Procedures, and other aspects you must know before you begin using them.
Oracle strongly recommends you to read this chapter so that you understand the fundamentals and terms used in this context.
This chapter covers the following:
This section describes the following:
 |
Provisioning is the first phase of the software lifecycle that deals with installation and configuration of software, applications, or servers across different platforms, environments, and locations.
Enterprise Manager Grid Control offers provisioning Deployment Procedures that help you seamlessly deploy software across your enterprise configuration. |
 |
Patching is one of the phases of the software lifecycle that helps you maintain the software over a period of time and always keep it updated with the latest features offered by the software vendor. It is a process that deals with migrating from one version of the software product to another, higher, much-improved version.
Enterprise Manager Grid Control offers patching Deployment Procedures that help you seamlessly patch Oracle software across your enterprise configuration. |
Oracle releases patches periodically to help you migrate to a newer version of the software product and reap the benefits of an improved version. These patches contain critical enhancements and bug fixes that make the product better and offer more value to your organization.
For example, for the Oracle Database 10g Release 1 (10.2.0.1) base release, Oracle has released patches that help you migrate to either Oracle Database 10g Release 2 (10.2.0.2), Oracle Database 10g Release 3 (10.2.0.3), or Oracle Database 10g Release 4 (10.2.0.4); the last one being the most recent patch.
|
As described in the previous section, Patching refers to the process of migrating from one version to another, newer version of the software product within a particular release.
For example, if Oracle Database 10g is the release, then Patching refers to migrating from Oracle Database 10g Release 1 (10.2.0.1) to Oracle Database 10g Release 2 (10.2.0.2). Here, Release 2 (10.2.0.1), Release 2 (10.2.0.2), and so on are different versions of the 10g release. |
 |
Upgrading refers to the process of upgrading from one release to another, newer release of the software product.
For example, if Oracle Database 10g is one release and Oracle Database 11g is another release, then Upgrading refers to upgrading Oracle Database 10g to Oracle Database 11g. Here, 10g, 11g, and so on are different releases of the Oracle Database product. |
 |
Patches are periodic software updates released by Oracle. They contain bugs fixes only, and they must be applied on the software product to maintain a bug-free and improved version of the software.
Patches can be one-off patches, interim patches, or critical patch updates (CPU). Some of these may even be requirement-specific and released only to a few customers. Patches can be stored as generic components in Oracle Software Library. For information about Oracle Software Library, see Oracle Software Library. |
 |
Patch Sets are new releases of the software product released by Oracle. They contain a collection of patches, important enhancements, and bug fixes. They are much larger in size, and are released for all customers. They must be applied on the base or existing release of the software product to maintain an up-to-date version of the software.
Patch Sets can be stored as generic components in Oracle Software Library. For information about Oracle Software Library, see Oracle Software Library. |
This section describes the following:
 |
A Deployment Procedure is a procedure that contains a hierarchal sequence of provisioning or patching steps, where each step may contain a sequence of other steps. In other words, the workflow of all tasks that need to be performed for a particular lifecycle management activity is encapsulated in a Deployment Procedure.
For example, imagine a Deployment Procedure to be the "Coffee" button on the coffee vending machine. So, every time you need a cup of coffee, you press the "Coffee" button and it automatically adds the required ingredients and serves coffee through its nozzle. |
You select a Deployment Procedure in the Enterprise Manager Grid Control console to perform a particular provisioning or patching task. The Deployment Procedure contains a set of predefined steps that run one by one automatically to complete the entire task.
Enterprise Manager Grid Control comes with a set of default Deployment Procedures that help you accomplish common provisioning and patching-related tasks. Each Deployment Procedure is unique, and is designed to perform a particular operation according to the source being provisioned or target being patched. For example, the Deployment Procedure to patch a single instance database differs from the one to patch an Oracle RAC environment or an application server.
Understandably, your provisioning and patching-related requirements may vary from one environment to another, or from a test installation to a production installation. You can use the default Deployment Procedures and customize them according to your needs.
Deployment Procedures comprise various phases and steps that run serially or in parallel to perform a particular provisioning or patching operation.
A phase contains steps or more phases. The different types of phases are:
Rolling Phase
Rolling phase is a phase where steps are run serially across targets.
Parallel Phase
Parallel phase is a phase where steps are run in parallel across targets.
A step is an abstraction of a unit of work. For example, starting the database is a step. It is either part of a phase or independent. The different types of steps are:
Manual Step
Manual step is a task that requires user interaction and cannot be automated. Typically, Enterprise Manager Grid Control displays the instructions that need to be performed by you. After you perform those operations, you proceed to the next step. For example, logging in to a system and updating the kernel parameter, rebooting a system, providing special privileges to the user, and so on.
Computational Step
Computational step is a task whose operations are performed within Enterprise Manager Grid Control and they do not require any user intervention. This step gathers additional information for running a procedure. This step cannot be manually inserted by you. For example, running an SQL query against a schema to gather more data for other steps to run, retrieving target properties from the repository and updating the runtime information, and so on.
Action Step
Action step is a task that performs some operations run on one or more targets. They must be enclosed within a phase. The Deployment Procedure maps the Action Step and target pair to a job in the Enterprise Manager Job System. The Deployment Procedure can schedule, submit, and run a job per Action Step per target. For example, running a script, applying a patch, upgrading an Oracle home, and so on.
Also note that an Action Step is said to have completed successfully only when all its associated jobs have completed successfully. If a job fails, then the Action Step also fails. You may then manually restart the job in question or ignore and instruct the Deployment Procedure to proceed.
The different types of Action Steps include:
Job
Job Step is a special type of Action Step that executes a predefined job type on a target. This is used if you want to execute a job type as a part of a Deployment Procedure. You need to pass job parameters for a step.
Directive
Directive step is a special type of Action Step to deploy a directive alone. This is useful when users want to store their custom scripts in Oracle Software Library (Software Library) and reuse them in a Deployment Procedure.
Component (Generic or Registered)
Generic component step is a special type of Action Step to deploy a Software Library component and the associated Directive. Deployment Procedure Manager executes the directive with respect to the component. Components used for Generic Component Step generally have one directive associated with them. This association is done by selecting both the component and directive while creating the step. All directives that you associate with the component while uploading to the Software Library are ignored while running the step.
Host Command
Host Command Step is a special type of Action Step that encapsulates simple host commands. This step allows the user to enter a command line or a script (multiple commands) to be executed on the target host.
The activities involved in Deployment Procedures are design-time activities and run-time activities.
Design-time activities include creating components, directives, and images, and storing them in Oracle Software Library; and sometimes even customizing the default Deployment Procedures according to the needs of the organization.
Run-time activities include using these Deployment Procedures to actually provision or patch software, applications, or servers.
In a typical data center, the main users of Deployment Procedures are Designers (Lead Administrators) and Operators.
 |
Designers (Lead Administrators) are users who perform design-time activities described in Activities Involved in Deployment Procedures. Essentially, they are responsible for setting up the infrastructure for running Deployment Procedures. |
 |
Operators are users who perform run-time activities described in Activities Involved in Deployment Procedures. Essentially, they are responsible for running the Deployment Procedures to provision or patch a target. |
To view the default configuration settings of a Deployment Procedure and the steps involved in it, follow these steps:
In Grid Control, click Deployments.
On the Deployments page, in the Deployment Procedure Manager section, click Deployment Procedures.
On the Deployment Procedure Manager page, in the Procedures tab, from the table, select the Deployment Procedure for which you want to view details, and click View.
Enterprise Manager Grid Control displays the View Procedure page that shows the default configuration settings and steps involved in the selected Deployment Procedure.
Enterprise Manager Grid Control offers the following Deployment Procedures for provisioning:
| Target Type | Provisioning Deployment Procedure | Chapter No. |
|---|---|---|
| Oracle Database (Standalone) |
|
|
| Oracle RAC Database |
|
|
| Middleware |
|
|
| Virtualization |
|
Chapter 10 |
Note:
The Cloning Wizard is not supported from Enterprise Manager 10g Grid Control Release 4 (10.2.0.4.0).This section describes the following:
The following are the patching Deployment Procedures offered by Enterprise Manager Grid Control.
| Target Type | Patching Deployment Procedure | Chapter No. |
|---|---|---|
| Operating System Patching |
|
|
| Oracle Database (Standalone) | Patch Oracle Database | Chapter 15 |
| Oracle ASM | Patch Standalone Oracle ASM | Chapter 18 |
| Oracle RAC |
|
Chapter 16 |
| Oracle Clusterware |
|
Chapter 17 |
| Oracle Application Server | Patch Application Server | Chapter 19 |
Note:
The Patch Oracle Database Deployment Procedure supports 9.2.0.8 or higher database patch sets. For patch sets that are lower than 9.2.0.8, you cannot use Deployment Procedures, and therefore, you will have to manually apply them.
By default, for the "Patch Oracle Database" Deployment Procedure, the Stop CSS Daemon and Start CSS Daemon steps are disabled. However, if you are applying a 10.1.0.5 database patch set, then before running the Deployment Procedure, enable the Stop CSS Daemon and Start CSS Daemon steps, and set the Run Privilege setting of these two steps to Normal.
Using Deployment Procedures, you can apply a patch or patch set in either online mode or offline mode.
 |
Online Patching Mode helps you if the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support.
Using Enterprise Manager Grid Control, you can schedule a job that will run periodically and connect to My Oracle Support, check for the latest patches and patch sets, and automatically download them. This relieves you of the manual effort involved in searching the latest patches and patch sets, and downloading them whenever they are available. |
 |
Offline Patching Mode helps you if the host that runs Enterprise Manager Grid Control does not have an Internet connection to connect to My Oracle Support.
In this case, you must manually download the patch and patch sets from My Oracle Support using another host that has an Internet connection. Using Enterprise Manager Grid Control, you can manually upload these patches and patch sets to the Patch Cache so that they can be applied later. |
For Oracle RAC Database and Oracle Clusterware, you can patch all instances of the cluster either in a rolling or parallel mode. The parallel manner is called All Nodes in Enterprise Manager Grid Control.
Rolling mode refers to the patching methodology where the nodes of the cluster are patched individually, that is, one by one.
For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node until all the nodes are patched successfully.
This methodology is best suited for the following use cases:
When you are applying one-off patches that support this methodology.
Note:
Although most one-off patches support this methodology, there are some one-off patches that can be applied only using the All Nodes methodology. You can identify the supported methodology while downloading the one-off patches from My Oracle Support.When you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service.
Note:
You cannot use this methodology to patch shared Oracle homes. If you want to patch a shared Oracle home, then use the All Nodes methodology.All Nodes (or parallel) mode refers to the patching methodology where all the nodes are patched at a time, collectively. In this methodology, all the nodes are shut down and the patch is applied on all of them at the same time.
This methodology is best suited for the following use cases:
When you are applying patch sets, or one-off patches that support this methodology.
When you want to patch a shared Oracle home clusterware. In case of a shared Oracle home, all the nodes are shut down, but the patch is applied only on one of the nodes.
For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, and not on all the nodes.
Note:
Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.This section describes the following:
 |
Oracle Software Library (Software Library) is a repository that stores certified software images (for example, Oracle Database, operating system, Oracle Real Application Clusters, third party software, and so on) and other related entities. These can then be automatically mass-deployed to provision software, software updates, and servers using Enterprise Manger Grid Control in a reliable and repeatable manner. These provisioning operations, which are unattended and can be scheduled, lead to substantial cost savings.
For example, imagine Software Library to be the container inside the coffee vending machine that has smaller compartments for storing milk, coffee powder, and sugar. So, before you press the "Coffee" button, you would ideally stock milk, coffee powder, and sugar in those smaller compartments of the container inside the vending machine. |
The Software Library is part of and within Enterprise Manager Grid Control. It is not a separate, add-on product that needs to be installed separately. You can use the Enterprise Manager Grid Control console to access the Software Library and create components, images, directives, and store metadata and binary content.
For information about components, images, and directives, see Components, Directives, and Images, Network Templates, Hardware Templates, Disk Layouts, respectively.
For information about setting up the Software Library, see Setting Up Oracle Software Library. For information about using other options offered by the Software Library, see Appendix C, "Using Oracle Software Library".
 |
Components are entities in the Software Library that represent the primary building blocks for Deployment Procedures. A component can represent operating system software, Oracle software, or any third-party software and applications.
For example, imagine a Component to be an ingredient, such as milk, coffee powder, or sugar stored in the container inside a coffee vending machine. Without these, the vending machine cannot prepare a cup of coffee. |
Components are individually maintained within the Software Library, and you can associate versions, states, and maturity levels with each component. They may also be combined with other components as needed, to specify the complete software configuration or image that is provisioned on target hosts.
 |
Directives are entities in the Software Library that represent a set of instructions to be performed. These are constructs used to associate scripts with software components and images. These scripts contain directions on how to interpret and process the contents of a particular component or an image.
For example, imagine a Directive to be the program that runs inside the coffee vending machine to automate the process of preparing coffee. The program essentially instructs the vending machine to add the ingredients one by one, and then serve the drink through its nozzle. |
Directives encapsulate the script, the command line used to invoke the script, and the script configuration properties. They capture everything required for invoking the script on a machine during a provisioning operation.
Directives are usually categorized based on the provisioning life cycle phases they are targeted for, or the actions they perform. Imagine Directives as set of executable instructions that run from a supported shell (for example, borne-again, Perl, Python), programming language (for example, Java), or execution framework or interpreter (such as “make” or “ant”).
Directives are contained within a file stored in the Oracle Software Library and referenced from the software components that employ them. Versions, states and maturity levels can be associated with each directive.
 |
Images are entities that represent a collection of components along with the necessary directives that create a deployable configuration for a single or set of target hosts.
Network Templates, Hardware Templates, and Disk Layouts are used to define the network, hardware, and disk layout configuration of the target hosts, respectively. For example, imagine an Image to be a cappuccino flavored drink readily available in a paper carton. In this case, you do not prepare the coffee; the drink already contains milk, cappuccino coffee powder, and sugar, and it's all mixed and readily available for consumption. |
Images are stored in the Oracle Software Library and versions, states, and maturity levels can be associated with them.
Assignment is the activity to select an image and provision them on hardware servers. Assignments allow specifying properties (such as image properties, file system, root password, network profiles, port, IP address, etc.) that will be used during the provisioning of hardware servers. Assignments also allow for setting of advanced parameters like NTP, NIS, NFS and kernel parameters.
Linux Host Patching is a feature in Enterprise Manager Grid Control that helps in keeping the machines in an enterprise updated with security fixes and critical bug fixes, especially in a data centre or a server farm. This feature support in Enterprise Manager Grid Control enables you to:
Set up Linux RPM Repository based in Unbreakable Linux Network(ULN) channels
Download Advisories (Erratas) from ULN
Set up Linux Patching Group to update a group of Linux hosts and collect compliance information
Allow non-compliant packages to be patched
Rollback/Uninstall packages from host
Manage RPM repositories and channels (clone channels, copy packages from one channel into another, delete channels)
Add RPMs to custom channels
Manage Configuration file channels (create/delete channels, upload files, copy files from one channel into another)
The following are concepts related to Linux patching:
| Linux Host | A host target in Enterprise Manager Grid Control that is running the Linux operating system. |
| Linux Patching Group | A set of managed Linux hosts that are associated with a common RPM repository. Every group is configured with an update schedule according to which, a recurring job is triggered that will update the hosts of the group with the associated RPM repositories. |
| Unbreakable Linux Network (ULN) | Unbreakable Linux Network (ULN) is a Web site hosted by Oracle to provide updates for Oracle Enterprise Linux. |
| ULN Channel | A channel is a grouping of RPM packages on the ULN network. For example, el4_latest channel contains all packages for OEL 4. |
| RPM Repository | RPM repository is a directory that contains RPM packages and their metadata (extracted by running yum-arch and createrepo). The RPM repository is accessible via http or ftp. An RPM repository can be organized to contain packages from multiple channels.
For example, /var/www/html/yum/Enterprise/EL4/latest might contain packages from the el4_latest channel on ULN. |
| Custom Channel | A channel that is created by the user to store a set of custom RPM packages. Custom channels can be added to the RPM repository. |
| Configuration Channel | A channel that is created by the user to store a set of Linux configuration files. Configuration channels can be used in the Linux patching application GUI to deploy configuration files on Linux hosts. |
Virtualization management involves the monitoring, administration, and maintenance of virtual servers and guest virtual machines in your enterprise. Oracle provides the customer increased value by extending Enterprise Manager capabilities to monitor virtualized entities alongside the physical infrastructure and perform complete lifecycle management of virtual servers and software running on them.
This section describes the following:
The following describes the terms used in virtualization:
Oracle VM is server virtualization software. Installing Oracle VM on a bare metal box allows for the creation of multiple guest virtual machines on it. Just like Oracle databases and Oracle Fusion Middleware, Oracle VM is available for download on Oracle Technology Network (OTN).
Virtual Server is a generic term used to describe a physical box running virtualization software (hypervisor) on it. A new virtual server can be provisioned by installing Oracle VM server software on a bare metal physical box. "Virtual Server" is a target type in Enterprise Manager that represents the Oracle VM targets.
Every Oracle VM server can perform one or more of the functions described below:
The Master Server is the core of the server pool operations. It acts as the contact point of the server pool to the outside world, and also as the dispatcher to other servers within the server pool. The load balancing is implemented by the Master Server. For example, when you start a guest virtual machine, the Master Server will choose a Guest VM Server with the maximum resources available to run the guest virtual machine. There can be only one Master Server in a server pool. The state of a virtual server pool is equivalent to the state of the master virtual server.
The Utility Server is responsible for I/O intensive operations such as copying or moving files. Its function focuses on the creation and removal operations of guest virtual machines, virtual servers, and server pools. There can be one or more Utility Servers in a server pool. When there are several Utility Servers, Server Pool Master chooses the Utility Server with the maximum CPU resources available to conduct the task.
The primary function of the Guest VM Server is to run guest virtual machines, thus acting as a hypervisor. There can be one or more Guest VM Servers in a server pool. When there are several Guest VM Servers, Master Server chooses the Guest VM Server with the maxhmum resources available (including memory and CPU) to start and run the virtual machine.
When the Oracle VM Server Pool is created, the user is asked to provide the details of the Master Server for that pool. By default, this Oracle VM Server also performs the functions of the Utility Server and Guest VM Server.
The user can later change the Utility Server and Guest VM Server functions using the Edit Virtual Server action.
The monitoring server monitors the virtual server remotely. Multiple virtual servers are monitored by one agent. Enterprise Manager agent must not be installed on virtual servers. The Monitoring Server agent (Enterprise Manager agent that monitors Oracle VM servers) should be upgraded to version 10.2.0.5.0.
A Server Pool is a logical grouping of one or more virtual servers that share common storage. A virtual server can belong to only one virtual server pool at a time. Guest virtual machines and resources are also associated with server pools. Oracle VM Server Pool is an aggregate target type in Enterprise Manager to represent the server pool of Oracle VM Servers.
Guest Virtual Machine (also known as Guest VM) is the container running on top of a virtual server. Multiple guest virtual machines can run on a single virtual server. Guest virtual machines can be created from Oracle VM templates. Oracle VM templates provide pre-installed and pre-configured software images to deploy a fully configured software stack. Oracle VM templates can be downloaded from OTN at the following location:
http://www.oracle.com/technology/products/vm/templates.html
A guest virtual machine monitored by an Enterprise Manager agent is treated like any other Host target. This type of guest virtual machine is referred to as a "Managed Guest VM".
A guest virtual machine that is not monitored by any Enterprise Manager agent is referred to as an "Unmanaged Guest VM". Only limited monitoring and configuration information is available for such a guest virtual machine.
Table 2-1 lists the privileges required to perform administrative and provisioning tasks on server pools, virtual servers, and guest virtual machines.
Table 2-1 Privileges for Provisioning and Administrative Operations in Virtualization Central
| Task | Privileges |
|---|---|
|
Create Virtual Server Pool |
Add any Target system privilege |
|
Remove Virtual Server Pool |
Full privilege on the Server Pool Target and the member Virtual Servers |
|
Manage Virtual Server Pool |
Operator privilege on the Server Pool Target |
|
Create Guest Virtual Machine |
Operator privilege on the Server Pool Target |
|
Discover Guest Virtual Machine |
Operator privilege on the Server Pool Target |
|
Clear Operation Error (Virtual Server Pool) |
The Privilege check depends on the operation that has failed.
|
|
Register Virtual Server |
Add any Target system privilege |
|
De-register Virtual Server |
Full privilege on the Virtual Server and the Server Pool Target |
|
Edit Virtual Server |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Live Migrate All Guest Virtual Machine |
Operator privilege on the source Virtual Server and the Server Pool Target. Since the destination virtual server gets selected automatically and may be any virtual server in the Server Pool, Operator privilege on all member virtual servers of the Server Pool Target is essential. If preferred servers are set for the guest virtual machine, you will need Operator privilege on preferred virtual servers only. |
|
Stop Virtual Server |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Reboot Virtual Server |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Clear Operation Error (Virtual Server) |
Privilege check depends on the operation that has failed.
|
|
Live Migrate Guest Virtual Machine |
Operator privilege on the source Virtual Server and the Server Pool Target. Since the destination virtual server gets selected automatically and may be any virtual server in the Server Pool, Operator privilege on all member virtual servers of the Server Pool Target is needed. If preferred servers are set for the guest virtual machine, you will need Operator privilege on preferred virtual servers only. |
|
Clone Guest Virtual Machine |
Operator privilege on the Server Pool Target |
|
Save Guest Virtual Machine as Template |
Operator privilege on the Server Pool Target |
|
Edit Guest Virtual Machine |
Operator privilege on the Virtual Server and the Server Pool Target. An Edit Guest VM action may be performed on a Halted guest virtual machine as well. In this case privileges will be checked only on the Server Pool Target. |
|
Update Preferred Server List |
Operator privilege on the Virtual Server and the Server Pool Target. If the preferred server selection is set to Automatic, the guest virtual machine may come up on any virtual server within the server pool hence, you must have Operator privilege on all the members virtual servers in the server pool Target. If the preferred server selection is set to Manual, you must have Operator privilege on the specified list of member virtual servers. |
|
Delete Guest Virtual Machine |
Full privilege on the Server Pool Target |
|
Stop Guest Virtual Machine |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Start Guest Virtual Machine |
Operator privilege on the Server Pool Target. If the preferred server selection for that guest virtual machine is set to Automatic, the guest virtual machine may come up on any virtual server within the server pool. Hence, you must have Operator privilege on all the members virtual servers in the Server pool Target. If the preferred servers for that guest virtual machine is set to Manual, you must have Operator privilege on the specified list of member virtual servers. |
|
Reboot Guest Virtual Machine |
Operator privilege on the Virtual Server and the Server Pool Target. |
|
Pause Guest Virtual Machine |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Un-pause Guest Virtual Machine |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Suspend Guest Virtual Machine |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Resume Guest Virtual Machine |
Operator privilege on the Server Pool Target. If the preferred server selection for that guest virtual machine is set to Automatic, the guest virtual machine can come up on any virtual server within the server pool. Hence, you must have Operator privilege on all the members virtual servers in the Server pool Target. If the preferred server selection for that guest virtual machine is set to Manual, you must have Operator privilege on the specified list of member virtual servers. |
|
VNC Console |
Operator privilege on the Virtual Server and the Server Pool Target |
|
Clear Operation Error (Guest Virtual Machines) |
Privilege check depends on the operation that has failed.
|
|
View Virtual Server/Guest Virtual Machine |
View privilege on the Virtual Server Pool. If the User has Full/ Operator/View privilege on the Virtual Server Pool then the user gets View privileges on all the member Virtual Server targets automatically. |
Proliferation of low cost servers in our data centers has brought in a fresh set of management challenges. The well-acknowledged problems include the difficulty in managing consistency and compatibility across operating system and software deployments, server drifts and security vulnerabilities that lead to lack of compliance, difficulty in deploying software, difficulty in provisioning new servers with variety of configurations and applications, high cost of operation and difficulty in adapting to changes in workload of the environment. These lead to system administrators and DBAs spending significant amount of their time in software and server provisioning operations.
Oracle's answer to the Software and Server Management challenge is its Bare Metal Provisioning Application, which is a part of Provisioning Pack (available at http://www.oracle.com/technology/products/oem/mgmt_solutions/provisioning.html) of the Enterprise Manager Grid Control and Oracle Management Pack for Linux (available at http://www.oracle.com/technology/products/oem/omp_linux.html). Bare Metal Provisioning Application addresses the data center, server farm challenge to provision software and servers quickly, efficiently, and make them operational.
Bare Metal Provisioning Application provides server lifecycle management capabilities that enable one to build manage and optimize their server infrastructure. The application provides an automated, repeatable and reliable solution that:
Automates deployment of consistent, certified Linux operating system images along with other software on a larger number of servers.
Leads to faster, unattended deployment of software and operating systems.
Allows provisioning of middleware, Clusterware, Real Application cluster (RAC) etc. on top of Linux stack.
Supports heterogeneous hardware and network configuration.
Automatically discovers bare metal and live target servers for provisioning.
Especially for Oracle software the application encodes best practices out-of-the-box for deployment and patching.
Results in 10x or more reduction in manual labor that leads to substantial cost savings.
The application uses standardized PXE (Pre Boot Execution environment) booting process for provisioning both bare-metal and live servers. It provides a role based User Interface, for easily creating Gold Images and initiating automated, unattended installs.
The deployment environment in the data center needs to be setup in a certain manner in order to support the provisioning application. Besides the Oracle Management Server (OMS) which hosts Enterprise Manager and Provisioning Application, the following need to be setup and configured before using the provisioning application.
Software Library and its Entities
See Oracle Software Library for information about Software Library and its entities.
One of the key requirements of application is the ability of the hardware server to boot up over the network (rather than from a local boot device). A boot server must be set up so that it is able to service the requests from the designated hardware servers in order for them to boot over the network. Boot server must be an Enterprise Manager target and should be able to receive the BOOTP and TFTP (Trivial File Transfer Protocol) requests over the network from the hardware server. Refer to Setting Up Boot Server for setting up a boot server with DHCP/TFTP combination. Also refer to section Configuring Boot Server. It is also recommended that the users read about DHCP, PXE, and Redhat Kickstart technology before going through the boot server setup. Refer to Appendix G, "PXE Booting and Kickstart Technology" for a detailed discussion on PXE.
During provisioning of an image on hardware servers, the required binaries and files are first transferred to a stage server. This is known as Staging phase and is responsible for preparing images to be installed over the network, and exposing installable or executable software elements over the network to the target hardware server being provisioned.
The Provisioning application requires at least one stage server on which all the activities related to staging can be performed. From the networking perspective, you are advised to keep the stage server as close to the target machines as possible. It will help in bringing down the installation time drastically, by reducing the time taken to transfer image data from the stage server to the hardware servers. If you have multiple hardware server groups residing at physically different locations, it would be better to have one stage server for each of these locations. Stage server should again be an Enterprise Manager target. Refer to section Setting Up Stage Server for setting up a stage server. Also refer to section Configuring Stage Server.
A Reference Host (also called a gold machine) is the machine that the Provisioning application uses as a reference to create the Linux operating system component. The Provisioning application picks up the list of RPMs (along with their versions) installed on the reference host, and fetches those RPMs from a RPM repository to create an Linux OS component that represents the operating system installed on the reference host. The reference host must be an Enterprise Manager target.
The Provisioning application picks up the RPMs for the operating system from the RPM repository. At least one repository needs to be setup for use by the Provisioning application. Refer to section Setting Up RPM Repository for setting up a RPM repository. Also refer to section Configuring RPM Repository.
The provisioning process consists of the following two high-level tasks:
Setting Up Provisioning Environment ( Setting Up Infrastructure for Bare Metal Provisioning):
Setting up Boot/DHCP server and Stage server, setting up RPM repository and Software Library
Configuring above entities in Enterprise Manager
Provisioning Linux using Bare Metal Provisioning Application ( Provisioning Bare Metal Boxes):
Creating Linux "Default Image" by creating an image and associating the image with a particular network subnet or MAC address
Staging the image on the Stage server
Powering up the bare metal machine on the network to begin the PXE-based OS boot and install process
The user needs to perform a one-time activity of setting up a Boot server, Stage server, and RPM repository that are required by the provisioning application. Once this infrastructure is set up, it can be used repeatedly for provisioning Linux on several bare metal machines. See Setting Up Infrastructure for Bare Metal Provisioning for more information.
The following sections outline the steps to provision Linux. See Chapter 9, "Provisioning Linux Operating System" for more information.
Enterprise Manager allows the user to create a Linux "Default Image" from Linux installation on a reference machine. The default image consists of an OS binary component along with directives required to stage and provision the image. Once an image is created, it can be associated with a subnet prefix or a set of MAC addresses. Doing this ensures that the image gets provisioned on bare metal machines in the specified subnet or having specified MAC address. See Creating a Default Image for more information.
The user is required to stage the contents of the image, namely the binaries associated with the components, directives and other templates, on the stage server. This caches the image in the staging area in the subnet for improved performance and prepares the image to be provisioned. See Staging the Default Image for more information.
Once the image is staged, it is ready to be provisioned on bare metal machines that are powered on in the subnet. When a bare metal machine is connected to the subnet, the Bare Metal Provisioning Application discovers the machine and boots it over the network using the PXE protocol. It then installs the operating system and the Enterprise Manager management agent on the server. Installing the agent makes the server a managed target in the Enterprise Manager console. See Ready to Go for more information.
Figure 2-2 explains the sequence in the PXE process:
See Appendix G, "PXE Booting and Kickstart Technology" for a description of the PXE boot process.
This section describes the following:
 |
Provisioning Archive files or PAR files contain Deployment Procedures and/or components and directives from the Software Library. These are default Deployment Procedures offered by Enterprise Manager Grid Control. When you import or export Deployment Procedures using the default PARDeploy utility, you technically import or export PAR files.
For information on PARDeploy utility and how you can use it to import or export PAR files, see Appendix B, "Using PARDeploy Utility". |
 |
Oracle Patch Advisories describe critical software patches for Oracle products. To help ensure a secure and reliable configuration, all relevant and current critical Oracle patches must be applied.
To promote critical patch application, Enterprise Manager Grid Control performs an assessment of vulnerabilities by examining the host configurations collected for your enterprise to determine the Oracle homes that require one or more critical patches to be installed. |
 |
Staging Area is a temporary location on the target host where the generic component from the Software Library or the reference installation used for cloning will be staged for a short period, and then extracted and used for deployment.
The generic component or the reference installation may be in the form of a ZIP file. After it is placed in the staging area, once the Deployment Procedure is ready for deployment, the contents of the ZIP file are extracted and then deployed. You must always ensure that the staging area has write permission so that the Deployment Procedure can stage the ZIP file. |
All the Deployment Procedures offered by Enterprise Manager Grid Control require administrator privileges to run. While most steps within a Deployment Procedure can be run as a normal user, there are some steps that require special permissions and privileges, and unless you provide the administrator's credentials, you cannot proceed with the deployment.
Under such circumstances, you can do one of the following:
Customize the Deployment Procedure to disable the steps that require special privileges, run the other steps as a normal user, and have the administrator run the disabled steps later.
Customize the Deployment Procedure to use authentication utilities for running some steps within the Deployment Procedure with the privileges of another user. The authentication utilities supported by Enterprise Manager Grid Control are SUDO, PowerBroker, and Privilege Delegation.
For information on how you can customize Deployment Procedures and how Privilege Delegation scores over other two utilities, see Chapter 23, "Choosing Privilege Delegation Over SUDO and PowerBroker".
After you have submitted a Deployment Procedure, you can track its status from the Procedure Completion Status page. To access this page, follow these steps:
In Grid Control, click Deployments.
On the Deployments page, from the Deployment Procedure Manager section, click Procedure Completion Status.
On the Deployment Procedure Manager page, click the Procedure Completion Status tab.
On the Procedure Completion Status page, you can view the status of the Deployment Procedures.
Table 2-2 Deployment Procedure Status
| Status | Description |
|---|---|
|
Scheduled |
implies that the Deployment Procedure is scheduled to be executed at the date and time that you have specified. |
|
Running |
implies that the Deployment Procedure is currently being executed. |
|
Action Required |
Implies that the Deployment Procedure has stopped running as user interaction is required. |
|
Suspended |
Implies that the Deployment Procedure has been temporarily stopped from execution. You can resume from the paused step later. |
|
Failed |
Implies that the Deployment Procedure has failed and cannot execute the further steps. You can also ignore the error and proceed further. |
|
Completed |
Implies that the Deployment Procedure has successfully completed its execution. |
|
Stopped |
Implies that the Deployment Procedure has been permanently stopped from execution by the user. |
|
Saved |
Implies that the Deployment Procedure has not been given for execution, and has been saved. |
|
Completed with Errors |
Indicates that the Deployment Procedure completed, but completed with errors possibly because some of the steps within it might have failed and the steps might have the Skip target/Continue on Error flag enabled. |
You can also perform the following actions:
Search for a particular Deployment Procedure using the Search section. Click Search to refine your search criteria.
View the status of all Deployment Procedures. You can also manually refresh the page and view the updated status by clicking Refresh.
View real-time status information based on a particular refresh period such as 30 seconds, 1 minute, or 5 minutes.
Stop or suspend any Deployment Procedure by selecting them and clicking Stop or Suspend, respectively. You can resume at any point by clicking Resume or Retry.
Delete any Deployment Procedure by selecting them and clicking Delete.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
