Wednesday May 15, 2013

How to go Physical to Virtual with Oracle Solaris Zones using Enterprise Manager Ops Center

Many customers have large collections of physical Solaris 8, 9 and 10 servers in their datacenters and they are wondering how they are going to virtualize them. This leads to a commonly asked question. Can Enterprise Manager Ops Center 12C be used to P2V (Physical to Virtual) my old servers? Ops Center does not have a single button P2V capability, but it is possible for Ops Center to deploy physical servers, LDOMs and branded zones based on flash archives(flars) that have been taken of your existing physical servers. Ops Center achieves P2V by deploying flars and leveraging its patching and automation capabilities, to make the P2V process consistent, repeatable and as cost effective as possible.

As with any virtualization project, there will be a number of things that will need to be updated as you move from a physical to a virtual environment. It is a common misconception that you can virtualize a system and change nothing about it. There are always a few things that have to be changed on an OS or process level to make it compatible with the virtualized environment. As a best practice, there are many more things that should be updated, re-allocated and redesigned as part of a virtualization project but that is a subject for another blog.

In this blog, we will be covering migrating physical servers to Oracle Solaris Zones.

We will also review this in our community call on Monday , 05/20/2013. Here are web conference details.

----

Topic: How to P2V to Oracle Solaris Zones using Enterprise Manager Ops Center
Date: Monday, May 20, 2013
Time: 5:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 594 835 639
Meeting Password: oracle123
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://oracleconferencing.webex.com/oracleconferencing/j.php?ED=236653047&UID=1653030737&PW=NNzUxYjUwOWY5&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: oracle123
4. Click "Join".

To view in other time zones or languages, please click the link:
https://oracleconferencing.webex.com/oracleconferencing/j.php?ED=236653047&UID=1653030737&PW=NNzUxYjUwOWY5&ORT=MiMxMQ%3D%3D

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Call-in toll-free number:       1-866-682-4770  (US/Canada)      
Other countries:
https://www.intercallonline.com/listNumbersByCode.action?confCode=7629343

Conference Code:       7629343#
Security code:            7777# 
-----

Ops Center does not do anything differently to what you could do by hand, it just automates the process and, by the use of templates and wizards, drives consistency and repeatable results.

Physical Server to Branded Zones

Let’s first look at converting existing Solaris 8, 9 and 10 physical servers into Solaris 8/9 branded zones (on Solaris 10) and Solaris 10 branded zones (on Solaris 11).

There are 4 basic steps involved in converting a physical server to a virtual server.

Capture

This is done by creating a flash archive of the source system. If the source system is a Solaris 10 environment with a ZFS root, it is possible to use a ZFS based flar, but for consistency and ease of coding in the grooming scripts, I recommend that all flars be taken as a cpio flash archive.

When capturing the flar, we should include all the root files systems that will be required for the new zone to boot. If the application data is small, it can be included in the flar, but if it is large, you should copy the application data after the P2V migration is complete.

Example flar capture command line

# flarcreate -n [HostNameOfSourceSystem] -S -c -L cpio \

-x /[Dir where archive will be stored] \

 /[Dir where archive will be stored]/[HostNameOfSourceSystem].flar

Note that we are using the –x flag to exclude the directory where we are storing the archive. You can use multiple –x flags to exclude any other directories you do not want to include as part of the archive, such as large application data. Large archives just become difficult to unpack/pack and upload. As you can imagine, if your source archive contained 100 GB of application data, you would need probably 300-400 GB of space just to perform grooming, and that would make the process much slower.

Grooming

The first question I often get is, “Why do I need to groom my flar?” In an ideal world, you would not need to, but rarely do we live in an ideal world:

1). If your environments are like most customers', there are a wide variety of configurations, patching levels and processes that have been applied to the source system during its lifecycle. This level of entropy means that there may well be things that must be fixed, like the following “real world” examples of problems with source flars that I have observed:
    • A customer’s patching methodology had disabled the startup scripts that are required for a branded zone to boot.
    • Some Solaris “df” command patches were missing that are mandatory for Solaris 8/9 branded zones (with a separate /var) to work.
So formalized grooming is a chance to automate the fixing of these anomalies and to help standardize your new environment.

2).  A common restriction that is placed on you, in a migration project, is that you cannot alter/update/reconfigure the source machine to suit its target virtualized environment. So you have to at least apply any mandatory fixes needed to the archive file itself and preferably also remove anything that may conflict with/fail in the new virtualized environment. So, once again, a formalized grooming is an ideal way to address these requirements.

You will often come across the argument that everything must be identical on the new virtualized environment, in an attempt to minimize change. Let’s be honest here, while virtualization will aim to provide a functionally identical environment, there is a massive amount of change that is happening under the covers when you virtualize a machine and there are a few things that must be changed to make it work. The history of virtualization projects has shown that once the existing servers are virtualized, they are almost never revisited to cleanup the idiosyncrasies of the source machines to bring them into a standard format. Therefore, I am a supporter of more aggressive grooming and the cleaning up of years of entropy as part of the P2V process.

The way to make grooming consistent and less manual and tedious is to convert the steps into an Operational Plan and use Ops Center to run them in a consistent manner.

Here are some of the modules I usually include in my grooming plans:

Module

What It Does

Get_FLAR_info

Export flar info as shell variables to be used elsewhere in the program.

Flar_Cpio_Fmt_Check

Check that the flar is in cpio format.

Unpack_Archive

Unpack the flar archive.

Min_OS_Release

Check that the OS release meets the minimum for branded zones.

ServiceTag_Identity

Remove the service tag identity file. Old service tags and duplicate service tags can confuse Ops Center.

SoftPartition_Check

Check that no soft partition data is included in the flar.

Clean_FMD

Remove any outstanding FMD faults from source machine.

Clean_SVM

Disable any references to disk suite (svm/sds/ods) from source machine.

Clean_NFS

Disable any NFS mounts in vfstab from source machine as they may not be available in the new virtualized environment and will stop the zone from booting.

Add_Packages

Add missing packages if required (the packages you want to add are laid out under a directory structure).

Add_Patches

Add missing patches if required (the patches you want to add are laid out under a directory structure)

App_Disable

Disable application startup in the flash archive. It is often advisable to disable automatic application startup as part of the P2V process, so that it cannot conflict/corrupt the production source machine.

Agent_Cleanup

Un-configure OC agent and cleanup OC identity files in case the source system was already under Ops Center control.

Pack_Archive

Repack the flar archive.

These are just some of the common modules that I have used over the years on P2V projects. You may not need any or all of these. You may need to create your own module if you find something unique in your source machines. Grooming is an iterative process, as your source machines can vary wildly from any machine I have ever come across. This is not an Ops Center thing; this is just the nature of P2V on a source pool of unknown quality. So if you hit an issue, troubleshoot it, add a new module to the Operational Plan and try again. To help get you started, I have included some sample code [Sample Grooming script]. This script provides examples of what can be done and should be considered an example of how you can build your own grooming script.

Loading the script into an Operational Plan is as simple as:

Creating a new Operational Profile
Give the plan a name, and select Operating System as the target type.

Creating an Operational Plan

Click browse to find the script and then load it. I have increased the profile time out to 180 minutes as grooming large flars can take a while.
Browse and load script
Finally, specify any variables for which the script requires user input. You can specify the variable as required or optional and provide a hint/description to help the user at run time.
Specify variable input


So how do I groom my flar?

Step 1) Copy the flar taken from the source system onto any system managed by Ops Center that has sufficient space.

Step 2) Launch your grooming “Operational Plan” against the system to which you copied the flar.

Laanching an op plan

Step 3) Have a cup of coffee... then check the logs

Check the logs

Step 4) You now have a flar ready for uploading into Ops Center.

Deployment

Deployment is where this process comes under full Ops Center control.

Step 1) Load your groomed flar into the EC library.

Load Groomed flar

Step 2) Create a profile for the zone you want to deploy.

Create zone profile

Step 3) Deploy the zone.

Deploy a zone

When the job completes, you have your source system as a zone.

Customization

What are the sorts of actions you can do here?

  • Add additional networks if you only deployed with a single network.
  • Update the application configuration.
  • Update secondary apps like backup software, application monitoring, etc.
  • Re-enable application startup scripts and remote file systems in vfstab.
  • Do any updates to patches/packages/applications.

 To make these actions repeatable and consistent, I employ Operational Plans or Update Profiles.

Operational Plans – These are scripts that make actions repeatable and can be modified by operator input (Operational Plan Variables) at run time.

Update Profiles - These can contain patches, packages, scripts and customized configuration files (based on the system you are deploying to).

Choose the right method for what you are trying to do or combine both of them together in a Software Deployment/Update Plan.

Congratulations you have P2Ved your system.

Conclusion

It is fairly straightforward to automate the migration of physical servers to Oracle Solaris Zones using Enterprise Manager Ops Center. Operational Plans and Update Profiles are great tools to automate many of those operational tasks and increase their reliability and repeatability.

Look out for a future blog on “How to P2V to Oracle Virtual Machine for SPARC using Enterprise Manager Ops Center“.

Tuesday Nov 27, 2012

Using Oracle Enterprise Manager Ops Center to Update Solaris via Live Upgrade

Introduction: LU99_AD

This Oracle Enterprise Manager Ops Center blog entry provides tips for using Ops Center to update Solaris using Live Upgrade on Solaris 10 and Boot Environments on Solaris 11.

Why use Live Upgrade?

  • Live Upgrade (LU) can significantly reduce downtime associated with patching
  • Live Upgrade avoids dropping to single-user mode for long periods of time during patching
  • Live Upgrade relies on an Alternate Boot Environment (ABE)/(BE), which is patched while in multi-user mode; thereby allowing normal system operations to continue with the active BE, while the alternate BE is being patched
  • Activating a newly patched (A)BE is essentially a reboot; therefore the downtime is ~= reboot
  • Admins can easily revert to the prior Boot Environment (BE) as a safeguard / fallback.

Why use Ops Center to patch via Live Upgrade, Alternate Boot Environments, and Solaris 11 equivalents?

  • All the benefits of Ops Center's extensive patch and package knowledge base can be leveraged on top of Live Upgrade
  • Ops Center can orchestrate patching based on Live Upgrade and Solaris 11 features, which all works together to minimize downtime
  • Ops Center's advanced inventory and reporting features assure that each OS is updated to a verifiable, consistent standard, rather than relying on ad-hoc (error prone) procedures and scripts
  • Ops Center gives admins control over the boot environment specifications or they can let Ops Center decide when a BE is necessary, thereby reducing complexity and lowering the opportunity for user error

Preparing to use Live Upgrade-like features in Solaris 11

Requirements and information you should know:

  • Global Zone Root file-systems must be separate from Solaris Container / Zone filesystems
  • Solaris 11 has features which are similar in concept to Live Upgrade on Solaris 10, but differ greatly in implementation
    Important distinctions:
    • Solaris 11 assumes ZFS root
    • Solaris 11 adds Boot Environments (BE's) as an integrated feature (see beadm)
    • Solaris 11 BE's avoid single-user patching (vs. Solaris 10 w/ ZFS snapshot=ABE).
    • Solaris 11 Image Packaging System (IPS) has hooks for BE creation, as needed
      • Solaris 11 allows pkgs to be installed + upgraded in alternate BE (e.g. instead of the live system) but it is controlled on a per-pkg basis
      • Boot Environments are activated across a reboot; instead of spending long periods installing + upgrading packages in single user mode.
    • Fallback to a prior BE is a function of the BE infrastructure (a la beadm).
    • (Generally) Reboot + BE activation can be much much faster on Solaris 11

Preparing to use Live Upgrade on Solaris 10

Requirements and information you should know:

  • Global Zone Root file-systems must be separate from Solaris Container / Zone filesystems
  • Live Upgrade Pre-requisite patches must be applied before the first Live Upgrade Alternate Boot Environments are created (see "Pre-requisite Patches" section, below...)
  • Solaris 10 Update 6 or newer on ZFS root is the practical starting point for Live Upgrade
    • Live Upgrade with ZFS root is far more straight-forward than any scheme based on Alternative Boot Environments in slices or temporarily breaking mirrors
    • Use Solaris best practices to upgrade the OS to at least Solaris 10 Update 4 (outside of Ops Center)
    • UFS root can (technically) be used, but it is significantly more involved (e.g. discouraged) -- there are many reasons to move to ZFS while going through the process to update to Solaris 10 Update 6 or newer (out side of Ops Center)
  • Recommendation: Start with Solaris 10 Update 6 or newer on ZFS root
  • Recommendation: Start with Ops Center 12c or newer
    • Ops Center 12c can automatically create your ABE's for you, without the need for custom scripts
    • Ops Center 12c Update 2 avoids kernel panic on unpatched Solaris 10 update 9 (and older) -- unrelated to Live Upgrade, but more on the issue, below.
NOTE: There is no magic!  If you have systems running Solaris 10 Update 5 or older on UFS root, and you don't know how to get them updated to Solaris 10 on ZFS root, then there are services available from Oracle Advanced Customer Support (ACS), which specialize in this area.

Live Upgrade Pre-requisite Patches (Solaris 10)

Certain Live Upgrade related patches must be present before the first Live Upgrade ABE's are created on Solaris 10.
Use the following MOS Search String to find the “living document” that outlines the required patch minimums, which are necessary before using any Live Upgrade features:

Solaris Live Upgrade Software Patch Requirements

(Click above – the link is valid as of this writing, but search in MOS for the same "Solaris Live Upgrade Software Patch Requirements" string if necessary)

It is a very good idea to check the document periodically and adapt to its contents, accordingly.

IMPORTANT:  In case it wasn't clear in the above document, some direct patching of the active OS, including a reboot, may be required before Live Upgrade can be successfully used the first time.

HINT: You can use Ops Center to determine what to expect for a given system, and to schedule the “pre-patching” during a maintenance window if necessary.

Preparing to use Ops Center

  • Discover + Manage (Install + Configure the Ops Center agent in) each Global Zone
  • Recommendation:  Begin by using OCDoctor --agent-prereq to determine whether OS meets OC prerequisites (resolve any issues)
  • See prior requirements and recommendations w.r.t. starting with Solaris 10 Update 6 or newer on ZFS (or at least Solaris 10 Update 4 on UFS, with caveats)

  • WARNING: Systems running unpatched Solaris 10 update 9 (or older) should run the Ops Center 12c Update 2 agent to avoid a potential kernel panic
    • The 12c Update 2 agent will check patch minimums and disable certain process accounting features if the kernel is not sufficiently patched to avoid the panic
      • SPARC: 142900-05 Obsoleted by: 142900-06 SunOS 5.10: kernel patch 10 Oracle Solaris on SPARC (32-bit)
      • X64: 142901-05 Obsoleted by: 142901-06 SunOS 5.10_x86: kernel patch 10 Oracle Solaris on x86 (32-bit)
    • OR
      • SPARC: 142909-17 SunOS 5.10: kernel patch 10 Oracle Solaris on SPARC (32-bit)
      • X64: 142910-17 SunOS 5.10_x86: kernel patch 10 Oracle Solaris on x86 (32-bit)
    • Ops Center 12c (initial release) and 12c Update 1 agent can also be safely used with a workaround (to be performed BEFORE installing the agent):
# mkdir -p /etc/opt/sun/oc
# echo "zstat_exacct_allowed=false" > /etc/opt/sun/oc/zstat.conf
# chmod 755 /etc/opt/sun /etc/opt/sun/oc
# chmod 644 /etc/opt/sun/oc/zstat.conf
# chown -Rh root:sys /etc/opt/sun/oc

NOTE: Remove the above after patching the OS sufficiently, or after upgrading to the 12c Update 2 agent

Using Ops Center to apply Live Upgrade-related Pre-Patches (Solaris 10)
Overview:

  • Create an OS Update Profile containing the minimum LU-related pre-patches, based on the Solaris Live Upgrade Software Patch Requirements, previously mentioned.
  • SIMULATE the deployment of the LU-related pre-patches
  • Observe whether any of the LU-related pre-patches will require a reboot
    • The job details for each Global Zone will advise whether a reboot step will be required
  • ACTUALLY deploy the LU-related pre-patches, according to your change control process (e.g. if no reboot, maybe okay to do now; vs. must do later because of the reboot).
    • You can schedule the job to occur later, during a maintenance window
  • Check the job status for each node, resolving any issues found
  • Once the LU-related pre-patches are applied, you can Ops Center to patch using Live Upgrade on Solaris 10

Using Ops Center to patch Solaris 10 with LU/ABE's -- the GOODS!
(this is the heart of the tip):

  • Create an OS Update Profile containing the patches that make up your standard build
    • Use Solaris Baselines when possible
    • Add other individual patches as needed
  • ACTUALLY deploy the OS Update Profile
    • Specify the appropriate Live Upgrade options, e.g.
      • Synchronize the active BE to the alternate BE before patching
      • Do not activate the BE after patching
  • Check the job status for each node, resolving any issues found
  • Activate the newly patched BE according to your change control process
    • Activate = Reboot to the ABE, making the ABE the new active BE
      • Ops Center does not separate LU activate from reboot, so expect a reboot!
  • Check the job status for each node, resolving any issues found


Examples (w/Screenshots)

Solaris 10 and Live Upgrade: Auto-Create the Alternate Boot Environment (ZFS root only)

ABE to be created on ZFS with name S10_12_07REC (Example)

Uses built in feature to call “lucreate -n S10_12_07REC” behind scenes if not already present

NOTE: Leave “lucreate” params blank (if you do specify options, the will be appended after -n $ABEName)

LU01_S10_AutoCreate_BE

Solaris 10 and Live Upgrade: Alternate Boot Environment Creation via Operational Profile (script)

The Alternate Boot Environment is to be created via custom, user-supplied script, which does whatever is needed for the system where Live Upgrade will be used.

Operational Profile, which provides the script to create an ABE:

  • Very similar to the automatic case, but with a Script (Operational Profile), which is used to create the ABE
  • Relies on user-supplied script in the form of an Operational Profile
  • Could be used to prepare an ABE based on a UFS root in a slice, or on a separate device (e.g. by breaking a mirror first) – it is up to the script author to do the right thing!
  • EXAMPLE: Same result as the ZFS case, but illustrating the Operational Profile (e.g. script) approach to call:
# lucreate -n S10_1207REC

LU02_S10_Create_BE_Contents

NOTE: OC special variable is $ABEName


Boot Environment Profile, which references the Operational Profile

  • Script = Operational Profile on this screen
  • Refers to Operational Profile shown in the previous section
  • The user-supplied S10_Create_BE Operational Profile will be run
  • The Operational Profile must send a non-zero exit code if there is a problem (so that the OS Update job will not proceed)

LU03_S10_Create_BE

Solaris 10 OS Update Profile (to provide the actual patch specifications)

Solaris 10 Baseline “Recommended” chosen for “Install”

LU04_S10_OSUpProf

Solaris 10 OS Update Plan (two-steps in this case)

“Create a Boot Environment” + “Update OS” are chosen.

LU05_S10_OSUpPlan

Using Ops Center to patch Solaris 11 with Boot Environments (as needed)

  • Create a Solaris 11 OS Update Profile containing the packages that make up your standard build
  • ACTUALLY deploy the Solaris 11 OS Update Profile
    • BE will be created if needed (or you can stipulate no BE)
    • BE name will be auto-generated (if needed), or you may specify a BE name
  • Check the job status for each node, resolving any issues found
  • Check if a BE was created; if so, activate the new BE
    • Activate = Reboot to the BE, making the new BE the active BE
      • Ops Center does not separate BE activate from reboot
  • NOTE: Not every Solaris 11 OS Update will require a new BE, so a reboot may not be necessary.


Solaris 11: Auto BE Create (as Needed -- let Ops Center decide)

  • BE to be created as needed
  • BE to be named automatically
  • Reboot (if necessary) deferred to separate step

LU06_S11_AutoCreateBE

Solaris 11: OS Profile

Solaris 11 “entire” chosen for a particular SRU

LU07_S11_OSUpProf

Solaris 11: OS Update Plan (w/BE)

 “Create a Boot Environment” + “Update OS” are chosen.

LU08_S11_OSUpPlan

Summary:

Solaris 10 Live Upgrade, Alternate Boot Environments, and their equivalents on Solaris 11 can be very powerful tools to help minimize the downtime associated with updating your servers.  For very old Solaris, there are some important prerequisites to adhere to, but once the initial preparation is complete, Live Upgrade can be used going forward.  For Solaris 11, the built-in Boot Environment handling is leveraged directly by the Image Packaging System, and the result is a much more straight forward way to patch, and far fewer prerequisites to satisfy in getting there.  Ops Center simplifies using either approach, and helps you improve consistency from system to system, which ultimately helps you improve the overall up-time across all the Solaris systems in your environment.

Please let us know what you think?  Until next time...
\Leon
--

Leon Shaner | Senior IT/Product Architect
Systems Management | Ops Center Engineering @ Oracle

The views expressed on this [blog; Web site] are my own and do not necessarily reflect the views of Oracle.



For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter

Monday May 21, 2012

Benefits of using Ops Center to deploy and manage Solaris 11

One of the more significant new features in Oracle Enterprise Manager Ops Center 12c is the ability to install Ops Center on Oracle Solaris 11, and to deploy and manage systems running Solaris 11.  The Solaris 11 capabilities are in addition to the analogous features for Solaris 10 and Linux, which can all be handled from the same Ops Center infrastructure.

When the Ops Center Enterprise Controller (EC) is installed on a system running Solaris 11, the EC can create a Solaris 11 Software Update Library containing Oracle Solaris Image Packaging System (IPS) content that is synchronized with the main Oracle repository at pkg.oracle.com. The Ops Center managed Solaris 11 repository becomes the package (pkg) publisher for downstream Solaris 11 deployments and updates on all Solaris 11 systems being managed by Ops Center.

Ops Center provides the ability to define Solaris 11 OS and Software Profiles comprised of Oracle Solaris 11 packages, user-supplied custom packages, scripts, and other files.  Such Software Profiles profiles can then be used to install and update software on systems already running Solaris 11 in a structured and consistent way.  Ops Center not only caches the main Oracle Solaris IPS repository, but more importantly it gives admins the ability to define their own preferred collection of packages so that systems can easily be kept in sync with each other, running a well-defined, life-cycle-managed Standard Operating Environment (SOE), instead of just whatever the latest content is at pkg.oracle.com.

Ops Center 12c also adds Solaris 11 features for bare-metal OS Provisioning, based on the Solaris 11 Auto Install (AI) facility.  Ops Center configures the Solaris 11 AI in a way that shields admins from needing to write custom AI manifests or custom "first boot" packages.  Solaris 11 deployments using Ops Center follow similar profile-based patterns as for Solaris 10 or Linux, all of which can all be deployed from the same Ops Center infrastructure running on Solaris 11.  The gory details of all these different times of bare-metal OS Provisioning are handled automatically for the user so that he or she does not need to put time and resources into manually creating and maintaining infrastructure for deploying different OS's natively -- Solaris 11 with AI, Solaris 10 JumpStart with JET, or Linux with Kickstart or AutoYast.  All of those OS's are handled by Ops Center under the covers, based on whatever network boot capability the OS requires (PXE/DHCP, WANBOOT, or AI), and all from the same Ops Center infrastructure running on Solaris 11.

Specific to Solaris 11 OS Provisioning (via AI), Ops Center provides its own "first-boot" package+scripts to customize the Solaris 11 deployment, and in particular this approach automatically installs the Ops Center agent.  With the Ops Center Agent in place right from the start, it is easy to handle post-install steps using the Ops Center features for handling Solaris 11 OS and Software Profiles containing additional packages, scripts, and content from the Solaris 11 Software Library, described above.

Tying bare-metal Solaris 11 deployment and post-install customization together is a key way that Ops Center simplifies the overall life-cycle management for Solaris 11 (in addition to Solaris 10 and Linux).   For example, a top-level plan based on "Configure and Install Logical Domains" can create numerous Logical Domains into an Oracle VM Server for SPARC "Server Pool" and provision Solaris 11 into each LDom Guest based on a powerful multi-step "Install Server" plan.  Such a plan can cover the end-to-end steps for installing and updating the OS, running scripts and adjusting monitoring parameters, etc.

Here is an example of the kinds of activities that can be performed in conjunction an OS Deployment, or separately, depending on the need:

Oracle Enterprise Manager Ops Center 12c Deployment Plan

NOTE: In the above example, the last step "Create Guests" can be used to create one or more Solaris Containers within the LDom Guest, rounding out the end-to-end deployment all the way from LDom Guest to Solaris 11 Global Zone to multiple Solaris Containers, if so desired.

One of the nicest aspect of deploying and managing Solaris 11 using Ops Center Plans and Profiles is that the same content can be applied as updates to existing Solaris 11 systems, aligned to the same content as chained off a bare-metal OS Provisioning.  It is up to the user which steps they want to include in a deployment plan -- whether they are updating Software Profiles on systems deployed 6 months ago to match the latest standard, or they are deploying new systems based on that same standard, Ops Center provides the means to insure that the outcome is consistent.

Here is an example of the kinds of activities that can be performed on an existing Solaris 11 OS -- either ad hoc, or immediately after a Solaris 11 OS Provisioning step, so that whether the life-cycle started with a new system, or the intent is to update a system deployed six months ago, the outcome can be the same:

S11 Update Multi-Step Plan

In short, Ops Center running on Solaris 11 can manage Solaris 10 and Linux systems, all from a common infrastructure, and all based on a simplified, consistent, profile- and plan-based way to do the OS and Software deployments and updates.  The net effect is an easy to use way to managing the life-cycle of heterogeneous systems, in a very consistent way through automation and re-use.

Please let us know what you think?  Until next time...
\Leon
--

Leon Shaner | Senior IT/Product Architect
Systems Management | Ops Center Engineering @ Oracle

The views expressed on this [blog; Web site] are my own and do not necessarily reflect the views of Oracle.



For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Apr 24, 2012

Demo Series : Gain Total Cloud Control of Systems with Enterprise Manager Ops Center 12c

Earlier this month, at Oracle Enterprise Manager Ops Center 12c launch, we published a series of demos of Oracle Enterprise Manager Ops Center 12c  managing various Oracle solutions from applications to hardware . You could see all of those demos by clicking the graphic below.  Following the graphics below, I have a brief overview of an enterprise customer scenario and various demos highlighting the management of various systems .

Demo Series - Explore Oracle Enterprise Manager Ops Center 12c

A Step-by-Step Journey to Enterprise Clouds

A large global financial company serving millions of customers worldwide has decided to investigate a private cloud infrastructure. They have multiple business units and are located in multiple regions worldwide.

Their enterprise applications include Oracle Siebel CRM, Oracle E-Business Suite Financials, and PeopleSoft HCM. They have recently added several Oracle Fusion Applications modules to enhance their CRM and HCM capabilities. Over time, they have also deployed a number of Java and web-based applications. They use Oracle Solaris/SPARC environments for their E-Business Suite applications. Their web servers, some of their application servers, and a number of the home grown applications run on Oracle Enterprise Linux and Oracle x86 servers. They have deployed Oracle virtualization solutions for x86 servers and SPARC.

This company is transitioning their IT to a private cloud environment to support the CEO’s new corporate strategy to increase operational efficiency by 10% while growing the top line by 30% in two years. The IT organization, led by their CIO, considered various options and concluded that achieving the CEO’s objectives would require them to transition their enterprise applications to the cloud, thereby creating real differentiation in how they service their customers. They reviewed several vendors and concluded that their private cloud solutions were adequate for small applications but too risky for enterprise applications. They decided to go with the an Oracle solution because only Oracle was able to demonstrate a proven solution to power enterprise applications while also leveraging SPARC and x86 virtualization for a complete cloud management solution.

They have already started to deploy Database-as-a-Service and Fusion Middleware-as-a-Service clouds using Oracle Enterprise Manger Self Service Application Portal. They plan to deploy Infrastructure-as-Service cloud based on both SPARC and x86 servers with Oracle virtualization solutions and manage them through Oracle Enterprise Manager Ops Center. They have recently deployed many ExaData systems. They are starting to deploy ExaLogic and Super Clusters Engineered systems as well to accelerate performance and time to market.

Integrated Linux Management in the Cloud

Linux Management functionality is available as part of Oracle Enterprise Manager 12c and is available to Oracle Linux Basic and Premier Support customers at no cost. The solution provides an integrated and cost-effective solution for complete Linux server lifecycle management and delivers comprehensive provisioning, patching, monitoring, and administration capabilities via a single, web-based user interface thus significantly reducing the complexity and cost associated with managing Linux operating system environments.

Using these rich Linux management features along with the complete Oracle Enterprise Manager product solution, the global financial company takes advantage of enterprise-scale service level management, automated change and configuration management, and comprehensive system and application performance management.

Integrated Lifecycle Management for Physical and Virtual Servers in the Cloud

Oracle VM offers server virtualization for both x86 and SPARC architectures that enable the deployment of agile cloud infrastructures. Virtualized server environments integrated with Oracle Enterprise Manager Ops Center allow you to easily create, deploy, clone virtual servers, and live migrate workloads while dynamically controlingcompute resources. Integrated lifecycle management of both physical & virtual servers with Ops Center simplifies the daily workflowneeded to control cloud infrastructures. This is one of the key reasons why this company decided power their private cloud with Oracle virtualization technologies.

Oracle Solaris 11 – The First Cloud OS

With its new and improved features, Oracle Solaris brings mission-critical enterprise class computing to cloud scale environments. These features include extremely agile, no overhead virtualization, simplified software lifecycle management, and built-in security across all layers. Oracle Enterprise Manager Ops Center understands all these new technologies, and therefore is the perfect tool to manage Oracle Solaris deployments at data center and cloud scales.

Manage Mission Critical Applications in the Cloud

Deploying and managing mission critical applications in cloud are one of the key strategic interests of the enterprises. Oracle SPARC based Infrastructure-as-a-Service ( IaaS ) offers the scale, reliability, and performance needed for those mission critical applications. In this demo, you will learn about how to manage SPARC server platforms, which is the foundation of the enterprise cloud this global financial company wants to deploy The Oracle SPARC technologies offers an extreme thread count and memory density in a small and eco-friendly form factor. This company wanted to insure they could leverage their existing SPARC population with not excluding new growth into the T4 chassis models. They found Ops Center offered them complete coverage of where they were the most invested.

Private PaaS and IaaS Cloud with Oracle Enterprise Manager

Oracle Enterprise Manager provides complete lifecycle management for cloud - from automated cloud setup, to delivery, to cloud operations. Learn how Oracle Enterprise Manager Cloud Control 12c and Oracle Enterprise Manager Ops Center 12c work together to provide an end-to-end solution to take you from zero to cloud in a day, whether the goal of your private cloud is Infrastructure as a Service (IaaS) or Platform as a Service (PaaS).

Managing DBaaS and MWaaS Cloud Services Delivery with Oracle Enterprise Manager

This demo showcases Engineered Systems Management capabilities of Oracle Enterprise Manager Cloud Control and Ops Center 12c. You can now manage all components of Oracle Exadata Database Machine, from databases to cell storage to network swicthes, from a single console. Similarly, you can now manage all aspects of Oracle Exalogic, including software and hardware, from a single console. Learn how Oracle Enterprise Manager is engineered systems-aware and provides insight into the performance, configuration and physical health of these highly performance machines.

Simplify Your Data Center with Exalogic Elastic Cloud

Oracle Exalogic Elastic Cloud is the industry’s Best Foundation for Cloud. It is hardware and software engineered together to provide extreme performance for Java applications, Oracle Applications, and other enterprise applications. Exalogic offers fully integrated compute nodes, storage and networking, fully integrated ZFS network attached storage appliance with 40TB of SAS disk storage, QDR InfiniBand IO Fabric, with 40 Gb/second throughput and microsecond latencies, Data center service network integration with 10 GbE, Scalable, open standard grid architecture. That means less effort spent by you on putting the pieces together and more time spend on extending the business value of your applications.

Check out this demonstration to learn more about Exalogic and the right configuration that meets your needs.

Oracle Software Runs Best on Oracle Hardware

Oracle Enterprise Manager offers the right amount of information across the stack, breaking down isolated IT organizations and helps make a stronger connection between the business services and the server assets they utilize.

To learn more, please go to Oracle Enterprise Manager  web page and stay connected with us at  :

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Apr 10, 2012

A new version of Oracle Enterprise Manager Ops Center Doctor (OCDoctor ) Utility released

In February,  we posted a blog of Oracle Enterprise Manager Ops Center Doctor aka OCDoctor Utility. This utility assists in various stages of the Ops Center deployment and can be a real life saver. It is updated on a regular basis with additional knowledge (similar to an antivirus subscription) to help you identify and resolve known issues or suggest ways to improve performance.

A new version ( Version 4.03 ) of the OCDoctor is now available . This new version adds full support for recently announced Oracle Enterprise Manager Ops Center 12c including prerequisites checks, troubleshoot tests, log collection, tuning and product metadata updates. In addition, it adds several bug fixes and enhancements to OCDoctor Utility.

To download OCDoctor for new installations:
https://updates.oracle.com/OCDoctor/OCDoctor-latest.zip

For existing installations, simply run:
# /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --update

Tip : If you have Oracle Enterprise Manager Ops Center12c EC installed, your OCDoctor will automatically update overnight.

Stay connected with  Oracle Enterprise Manager   : 

Twitter | Facebook | YouTube | Linkedin | Newsletter


Thursday Apr 05, 2012

Oracle Enterprise Manager Ops Center 12c is now available for download at Oracle technology Network

Oracle Enterprise Manager Ops Center 12c is available now for download at Oracle Technology Network (OTN ) .

Oracle Logo Enterprise Manager Ops Center Documentation

Oracle Enterprise Manager Ops Center web page at Oracle Technology Network

Join Oracle Launch Webcast : Total Cloud Control for Systems on April 12th at 9 AM PST to learn more about  Oracle Enterprise Manager Ops Center 12c from Oracle Senior Vice President John Fowler, Oracle Vice President of Systems Management Steve Wilson and a panel of Oracle executive.



Stay connected with  Oracle Enterprise Manager   : 

Twitter | Facebook | YouTube | Linkedin | Newsletter



Thursday Mar 08, 2012

Looking for an executive overview of Oracle Enterprise Manager 12c ?

IT professionals are excited by the technical advantages of cloud computing, and Line of Business managers look to the cloud as a driver of business growth, efficiency, and productivity. By transforming IT into a business-centric provider of services that users can access from anywhere, Oracle Enterprise Manager 12c helps you build a more agile, efficient, and  innovative enterprise.

You can get an executive overview of the Oracle Enterprise Manager 12c in this recently published executive brief


For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Mar 06, 2012

How to use Oracle Enterprise Manager Ops Center to patch your Solaris Systems ?

Oracle Enterprise Manager Ops Center allows you to update your Solaris systems with patches available from My Oracle Support (MOS).

Like always in life, there are multiple ways to perform a given task and the same is true for Ops Center.

Juergen Fleischer, Senior IT/Product Architect , Oracle Enterprise manager Ops center provided the content for this blog to guide you through different ways to perform Oracle Solaris patching depending on deployment scenarios.

Scenario 1 - Applying a single Patch to an Asset

Let's start with installing just a single patch to a system. To perform this task you would select the OS Asset and pick the action 'View/Modify Catalog' from the right hand side Actions panel.

From the pop-up screen, you can search for the patchid, see which revision is already installed and select a newer one if required.

Here is a MOS how-to document describing this in all detail:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=1390766.1


Scenario 2 - Applying multiple patches to several systems

If you have to apply a list of patches to multiple systems every now and then, creating an Update Profile would be the best method, as once you have created the Profile it can be used many times ensuring the exact same patches in the list are applied each and every time.

Update Profiles are located in the 'Plan Management' section. Update Profiles can be used in two ways: either you select a single or a group of OS assets and pick the action 'New Update OS Job'. Or, you pick the Update Profile in the Plan Management section and select 'New Update OS Job'. The wizard will allow you to select one or more target assets or groups.

Here is a MOS how-to with all the details:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=1390769.1

Scenario 3 - Regular Baseline Patching

For regular Baseline Patching 'Update Profiles' can be based on given patchsets which are made available by the Ops Center Knowledge Base (KB).

The KB offers two different patchsets, the monthly released Solaris Baselines (based on Oracle's internal EIS-DVD) and the current or archived versions of the "Recommended Patchset for Solaris". These are updated whenever a new critical patch gets released. Every quarter, one of these Recommended Patchsets for Solaris will be renamed as the 'Critical Patch Update' in line with standard Oracle practice. It's up to the Customer's patching policy and strategy to determine which patchsets should be used and how often they should be applied.

Scenario 4 - Latest & Greatest patchset

Finally, if required, Customers can select what is called "Latest & Greatest" patchset. These are all the latest available patches for all installed packages. To perform this task, use the 'Host Compliance Report' and tick the Security & Bug Fixes check box.

More details can be found in this blog entry
https://blogs.oracle.com/patch/entry/applying_the_latest_solaris_patches

or in this MOS how-to document:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=1390785.1


So far, we have talked about various scenarios around applying a single patch or multiple patches.  These patches can be applied on a running system or by using LiveUpgrade (LU).  LU allows creating Alternate Boot Environment (ABE), Synchronizing boot environments, Patching the ABE and then Activating the ABE.
For detailed examples and howto examples:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=1390757.1
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=1390764.1


Before using LiveUpgrade, please verify that the latest LU-Patch (sparc: 121430, x86: 121431) is  installed on the running system.

Furthermore, when payching zones always make use of the parallel zone patching feature, independent if using LU or not. Following blog entry describes this very well :
https://blogs.oracle.com/patch/entry/zones_parallel_patching_versus_update

Stay Connected:
Twitter | Facebook | YouTube | Linkedin | Newsletter

Tuesday Feb 07, 2012

Solaris and SPARC virtualization management features of Oracle Enterprise Manager Ops Center including "Live Migration"

This blog provides a short history of how Oracle technology in the Solaris and SPARC world has progressed to where we are with the SPARC-T4 Server family and Oracle VM Server for SPARC (formerly Logical Domains).  The entry continues with observations of why these technologies are relevant to business and IT stakeholders, today.  And finally, how Oracle Enterprise Manager Ops Center is piquing customer interest in moving forward with Logical Domains, followed by a short demonstration of LDom Migration in action.
[Read More]
About

Latest information and perspectives on Oracle Enterprise Manager.

Related Blogs




Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
3
5
6
7
9
10
11
12
13
14
15
17
18
19
20
23
24
25
26
27
28
29
30
   
       
Today