Monday Jul 06, 2015

Understanding Plans, Profiles and Policies in Enterprise Manager Ops Center

Enterprise Manager Ops Center uses a combination of Plans and Profiles to maximize repeatability and reuse, while giving you the degree of flexibility to provision and update what you need to in your environment. The structured building block approach will allow reuse of many of the components instead of re-entering data each time, but does make the whole thing look very confusing until you understand the relationship between plans and profiles.

The sort activities covered by plans and profiles are:

  • OS provisioning and configuration
  • BIOS and Firmware updates
  • LDOM creation
  • Zone creation
  • Boot environment creation
  • Patching and adding packages (S10 and S11)
  • Configuration files and pre/post action scripts (S10)
  • Automation using operational plans (scripts)

The Building Blocks

So, firstly, let's look at the building blocks and see what is the difference between a Plan and a Profile.

Profiles

Profiles contain the configuration information required to perform an action eg:

  • OS Provisioning plan - contains type/architecture, resourcing, OS version, software group, language, timezone, password, filesystems, name services
  • OS configuration - contains type/architecture, agent/agentless, multipathing, network configuration
  • Discovery - contains asset type, tags, IP address, credentials, grouping
  • Logical Domains - contains type, name, CPU/Cores, memory, automatic recovery, storage, networks

These are just some examples of the 16 types of profiles available in the BUI. 

Plans

Plans are objects that can be run (executed) to make something happen. Plans contain profiles, other plans, policies, or a combination of these.

Policies

In addition to these profiles, there are update and monitoring policies and credentials that can also be created and edited here.

Examples

Let's look at a couple of examples from a process prospective and how they actually look in the BUI. A side note here is the screenshots have been taken from an Ops Center 12.2.2 environment. Ops Center 12.3.0 introduces new styles of icons, but the principles are still all the same.

Process overview

For example, if we were going to provision a bare metal physical sever, you would have 2 choices:

  • A simple provision that would just lay down an operating system
  • A complex provision that
    • could update the BIOS on an X86
    • lay down the OS
    • update (patch) the OS
    • Add applications
    • Run scripts
    • Apply a non default monitoring profile
    • etc.

You choose the one that best suits what you are trying to do.

Simple OS Provisioning

If you just wanted to get an OS laid down, basic network/filesystems configured and possibly an agent installed, you would choose a "Provision OS" plan

This plan contains 2 profiles, an "OS Provisioning" profile and an "OS Configuration" profile. These profiles contain the answers to the same questions that would have been asked if you provisioned the server manually. A point to remember: it is required that you create your profiles (answering the questions that the wizard presents) before they are available to be added to a plan.

In the BUI it looks like this:

Complex OS provisioning

This plan must have the same 2 plans that the simple approach did, but has the option to add many other plans to be able to patch the deployed OS (Update OS, Update software), add software (Install, Operational plans), and further configure the OS/Application using scripts (Pre-install, Post-install, Operational plans)

In the BUI it looks like this:

The steps (profiles) you choose will be determined by what you want to achieve and if you are provisioning Solaris 10/Linux or Solaris11. 

Duplicating steps

In addition, most of these optional steps can be duplicated to allow you to execute more than one profile. To do this, add your first profile for that step, then select (highlight) that step and if it is available, the copy icon (with 1, 2 shown on it) will become active.

 Click that icon and the step will be duplicated allowing you to run more than one profile.


This makes the whole operation much more flexible, as you could have an update profile for your OS , one for web servers and one for databases. So if this plan was to build a web server, your plan would contain both the OS update profile and the web server update profile, avoiding the need to have the OS patches in 2 profiles.

 Other examples

 Another example of this would be if you wanted to build and LDOM or if you wanted to build an LDOM and deploy an OS into it (complex or simple), you would choose the appropriate plan.

Building an LDOM

Building an LDOM requires a "Create Logical Domain" plan

which only has a single step, which is a "Logical Domain" profile.

Building an LDOM and provisioning an OS

You can build the LDOM and provision the OS into it in a single action by creating a "Configure and Install Logical Domains" plan

which contains two steps, which is a "Logical Domain" profile and an "Install Server Profile"

Summary

By now, hopefully, the pattern has become clear. Plans and profiles are just the building blocks that allow you to deploy your system in the way you want. Each of the components are modular, so they can be re-used as much as possible and make it easier to maintain as you have fewer places you need to change when you want to change your configurations. There are many other types of plans offered by Ops Center that will create zones , build M-series physical domains and deploy OVM for X86 virtual machines, individually or combined with OS deployment, but they all follow the same basic structure. While how to do this is all laid out in the online documentaion, my best advice is to get yourself some test systems and try it out. There is often no substitute for having actually done it.

Regards,

Rodney Lindner


    Tuesday May 26, 2015

    Data to collect when logging a Service Request on Enterprise Manager Ops Center

    If you ever have to log a Service Request (SR) on your Enterprise Manager Ops Center instance, the question often arises as to what data you should include with the SR. Including the right information when you log the SR will greatly reduce your Time To Resolution (TTR).

    So, what data should you add to the SR? That will depend on what type of issue you are experiencing.

    Basic Information for All SR's

    While the My Oracle Support (MOS) portal will help by asking you relevent questions, here is a list of things to think about while answering them:

    1. A clear problem description - Tell us about what you were attempting to do when you encountered the issue, what host(s) were involved and what error message you saw. You would be surprised how many SR's get logged with "It didn't work" or just the error message as the problem description without telling us what you were actually trying to do. 
    2. Time and date - Tell us the time and date you saw the issue. The log files are time stamped, so knowing the time the issue occurred (at least approximately) will reduce the extent of searching of the log files that will need to be done.
    3. Software Version - Always tell us what version of Enterprise Manager Ops Center you are using. To find out your version, look on your Ops Center BUI under [Administration] ==> [Enterprise Controller] and at the top of the middle panel (Summary Tab) will be listed the Enterprise Controller Version. Don't forget to include if there are any IDR's (Patches) that have been applied to your Enterprise Manager Ops Center instance.


    Additional Data to include with your SR

    The most common thing to include with your SR is an OCDoctor --collectlogs output (# /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs), but it will often depend on which part of the process Ops Center was at when the issue occurred. If your issue falls under multiple sections below, please supply the data from all relevant sections.

    It should be noted that all of the Ops Center logs will rollover over time and on a busy environment that may not be a long time. So, it is important to collect any log files as soon as possible after you have seen your issue or you should reproduce the issue just before collecting the logs.

    Browser User Interface (BUI) issues

    • Collect screen shots of what you are seeing in the browser
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file

    Job related issues (Job fails)

    • Provide the job number
    • Provide the full job logs
      • In the BUI, click through to the failed task on the job and then export the logs
      • Select the radio button for "Full Job Log" and save the job log
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file

    OS provisioning issues

    • Capture the full job log (as described above)
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant Proxy Controller and collect the output file
    • Capture any console logs of either the physical server or, if deploying to LDOMs, capture /var/log/vtnds/[LDOM name]/console.log
    • If deploying to an LDOM, run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant CDOM and collect the output file

    Patching issues

    • Capture the full job log (as described above)
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the system being patched and collect the output file
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file

    Discovery issues

    • Capture the full job log (as described above)
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on your Enterprise Controller and collect the output file
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant Proxy Controller and collect the output file

    Agent deployment issues

    • Capture the agent install output and logfile (/var/tmp/agent_install, /var/scn/install/log)
    • Capture the agent configuration output and logfile (/var/tmp/agentadm.log)
    • If the agent has actually been installed, run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the system you are installing the agent on and collect the output file
    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs on the relevant Proxy Controller and collect the output file

    Domain Model issues

    • Run # /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --collectlogs -u [EC Master Admin User] on your Enterprise Controller and collect the output file
      • This will collect the domain model information as well as the normal output from OCDoctor log collect. Note:  this can take a long time to run
      • The [EC Master Admin User] is the user that you specified as part of the initial install. On some customer systems, this will be root but it does not have to be.

    Collecting the right information and providing it as part of the initial logging of the SR will make it easier for the engineer to analyze your issue and avoid a lot of unnecessary back and forth. Overall, it will get your issue resolved quicker. I hope this information will help you if you ever have to log a SR on Enterprise Manager Ops Center.

    Regards,

    Rodney Lindner






    Thursday Jun 26, 2014

    Creating A Secondary I/O domain with Ops Center 12.2

    Contributed by Juergen Fleischer and Mahesh Sharma.

    The purpose of this blog is to show you how to create a Secondary I/O domain. The First I/O domain is commonly known as Control Domain (CDOM). There are various terms that are used for a Secondary domain, like alternative I/O domain or redundant I/O domain.

    The secondary I/O domain will have been assigned some physical I/O devices, which may be a PCIe bus root complex, a PCI device, or a SR-IOV (Single Root I/O Virtualization) virtual function.

    Within Ops Center when creating a Secondary Domain we also use the terms Physical I/O Domain and Root Domain. The Physical I/O Domain maps PCI device end points, and the Root Domain maps PCIe buses, which also has an option to create SR-IOV functions.

    In this blog we will show you how to create a Root Domain by assigning PCIe buses, so that we have a redundant I/O domain which will enable us to shutdown the CDOM without affecting any of our guests.

    Our host a T5-2 (we’re using the same host as in the previous blogs) has two free PCIe buses that have not been assigned to domains (pci_2 and pci_3). So let’s create a Secondary I/O domain (Root Domain) with these buses and give the domain two whole cores with 4 GB of Memory.

    We’ll start by creating a Logical Domain Profile. This is created from:

    Navigation -> Plan Management -> Profiles and Polices, then click on Logical Domain. On the right under Actions select Create Profiles

    From the Identify Profile screen, give the Profile a name (Secondary-I/O in our case) and select Root Domain in the Sub-type, as shown above. Click Next.

    Step 2: is where we provide a name for our Secondary I/O domain, we called ours secondary and click Next to continue.

    The next screen, show below, we entered the amount of cores and memory.

     Step 4: is where we specify how many PCIe buses we will assign to this secondary domain. In our cases we have specified two for  pci_2 and pci_3.

    The next few steps are optional and are not required for this example.

    Step 7: Is the Summary, if everything looks correct click Finish.

    Note: The Metadata is on the local disk (file://guest). This is fine for the Secondary Domain as it will not be migrated. It’s just the Logical domains and their Guests that will get migrated, therefore making it mandatory to have the metadata on shared storage for these – if you want migration to succeed!

    Now that we have created the Profile, we will create our Secondary domain (Root domain).

    This is done from Navigation -> Plan Management -> Deployment Plans – Create Logical Domain and select the plan we have just created. From the Actions panel on the right select "Apply Deployment Plan".

    From the Select Target Asset pop-up, select the CDOM and move it to the Target list. Select Next.

    Complete Step 1, by specifying the secondary name.

    Step 2, we pick the PCIe Buses that will be assigned to the secondary domain.

    In step 3: we kept the default Virtual Disk Sever (vds) name.

    The next few screens are not required in this example.

    From the Summary screen click Finish. This will create the Secondary Domain.

    Once the Secondary Domain has been created we can check if it’s built as we specified. We can check via the Ops Center BUI and also command line.

    Let’s do both:

    And from the command line

    While on the command line we can also check if the buses have been assigned correctly.