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“.

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
21
22
23
24
25
26
27
28
29
30
   
       
Today