Tuesday Jun 18, 2013

Moving Oracle Solaris 11 Zones between physical servers

As part of my job in the ISV Engineering team, I am often asked by partners the following question : is it possible to easily move a Solaris 11 Zone from a physical server to another?

The short answer is : YES ! The longer one comes with the following restrictions :

  • Both physical servers should be of the same architecture, x64 or SPARC (T-series and M-series systems are compatible).

  • Both physical servers should run Oracle Solaris 11.

  • The destination server should run at least the same or higher release of Solaris 11. This includes the SRU (Support Repository Update) level.

Given a physical server called “Source” hosting a Solaris 11 Zone called “myZone” on a ZFS filesystem, here are the steps to move the zone on another physical server called “Target” :
  1. Export the Zones configuration
    The zone needs to be configured on the destination server before it can be installed. The first step is to export the configuration of the Zone to a file:

    [Source]# zonecfg -z myZone export -f myZone.cfg

  2. Archive the Zone
    My favourite solution is to use the ZFS “send” functionality to archive the ZFS file system hosting the Zone in a single movable file, although this can also be achieved in other ways (cpio, pax)

    • Halt the Zone
      [Source]# zoneadm -z myZone halt

    • Take a recursive ZFS Snapshot of the rpool of the zone
      [Source]# zfs snapshot -r rpool/zones/myZone@archive

    • Archive the Zone using ZFS send (ZFS and cpio archives can be zipped using gzip or bzip2)
      [Source]# zfs send -rc rpool/zones/myZone@archive | bzip2 > /var/tmp/myZone.zfs.bz2
  1. Move the configuration and archive files to the destination server
    FTP, scp, NFS, removable hard drive, …

  2. Configure the zone on the destination server

    Depending on the configuration of the Targer server, you might need to tweak the zone configuration file before using it.

    [Target]# zonecfg -z myZone -f myZone.cfg

  3. Install the Zone

    If the zone is being installed in the same network, the zone configuration (IP address, DNS server, Gateway, etc) can be preserved using the "-p" option:

    [Target]# zoneadm -z myZone install -a myZone.zfs.bz2 -p

    If the Zone is being installed in a new network environment, using the "-u" option instead of "-p" will unconfigure the system. The Zone would need to be manually configured on the first boot. The configuration can be automatized during installation if a system configuration profile XML file is provided:

    # zoneadm -z myZone install -a myZone.zfs -u -c sc_profile.xml

    Quick Tip
    : To create a system configuration file, you can use the sysconfig program with option "create-profile":

    # sysconfig create-profile -o sc_profile.xml

    The configuration text wizard will walk you through the system configuration steps (same process as the first boot configuration wizard) but will not re-configure your system. It will simply create an output XML file with the defined system configuration. This files can then be manually tweaked if needed and act as a template for future use.

  4. Boot the Zone
    # zoneadm -z myZone boot

  5. You should now be able to log in the Zone which is the exact copy of the original Zone on the source server.

Obviously there are many more options and possibilities that go beyond the scope of this post. My intend was just to give a glimpse of what can be done, so don't hesitate to consult the documentation for more options.

Also, these simple steps cans be scripted to be made even more flexible and usable. Below are two scripts I have written for my own needs. There are only provided as an example and must not be considered as production ready scripts.




# archive_zone.sh


# This script creates a movable archive of an Solaris 11 Zone

# It take a single input parameter: The Zone name


BASE_DIR="$(pwd -P)"





SNAPSHOT=${ZONES_ROOT}/${ZONE_NAME}@`date '+%d_%m_%Y-%H:%M:%S'`

if [ if [ ! -d ${ARCHIVE_FOLDER} ] ; then
   mkdir -p ${ARCHIVE_FOLDER}

zoneadm -z ${ZONE_NAME} halt

zonecfg -z ${ZONE_NAME} export -f ${ARCHIVE_FOLDER}/${CONFIG_FILE}

# Take a ZFS Snapshot of the rpool of the zone
zfs snapshot -r ${SNAPSHOT}

# Archive the Zone using ZFS send
zfs send -rc ${SNAPSHOT} | bzip2 > ${ARCHIVE_FOLDER}/${ARCHIVE_FILE}

# Delete the snapshot used to create the archive
zfs destroy -r ${SNAPSHOT}




# deploy_zone.sh


# This script deploys an archived Solaris 11 Zone

# It take a single input parameter: The Zone name



BASE_DIR="$(pwd -P)"




# Configure the Zone

# Install the Zone and configure the system
zoneadm -z ${ZONE_NAME} install -a ${ARCHIVE_FOLDER}/${ARCHIVE_FILE} -u

# Boot the Zone
zoneadm -z ${ZONE_NAME} boot

Monday Mar 12, 2012

Mobile Tornado adopts Solaris features for better RAS and TCO

Mobile Tornado provides instant communication services for mobile devices, with a focus on enterprise workforce management. Its solutions include Push-To-Talk and Instant Locate, Alert & Message applications.

As a software developer, Mobile Tornado's main challenges are up-time --the applications are largely sold today into the homeland security and defense markets-- and scalability --during network peak usage. With these challenges in mind, and as part of the on-going engineering collaboration between Mobile Tornado and Oracle's ISV Engineering, we investigated which Oracle Solaris technologies would improve the application's availability and scalability while reducing the solution's TCO.

We looked at the following Oracle Solaris technologies: Solaris Cluster, ZFS and Zones.

[Read More]

Wednesday Feb 15, 2012

Solaris SPARC live migration increases Oracle DB availability

One of the most significant business challenges for IT is to create and preserve value in a highly competitive environment, while keeping business applications available, improving hardware utilization and reducing costs. In particular, it is important to maximize application availability during planned or unplanned outages, without any compromise on resource allocation flexibility based on business needs, à la cloud computing.

Orgad Kimchi and Roman Ivanov at Oracle ISV Engineering describe in a new whitepaper "Increasing Application Availability by Using the Oracle VM Server for SPARC Live Migration Feature: An Oracle Database Example" how the Oracle VM Server for SPARC software (f.k.a. Sun Logical Domains or LDoms) can increase application availability, using the example of the Oracle database software.

The benefits of Live Migration are …

[Read More]

Tuesday Jan 17, 2012

ZFS secures your application

One of our ISV partner, a leading vendor in the financial services space, commonly recommends as deployment platform a commodity 2-socket Lintel server to minimize cost, but equipped with an internal RAID storage controller to increase the application uptime on such entry-level servers by mirroring the root disk. We recently worked with its professional services team to explore if we could improve on the solution, i.e. continuing to bring the cost down while increasing uptime.

The proposed solution was to use the Oracle Solaris 10 operating system and its ZFS file system in lieu of the hardware RAID to mirror the root hard drive. ZFS is a new kind of filesystem that provides simple administration, transactional semantics and immense scalability. ZFS natively supports all common RAID functionalities and also embeds advanced fonctionnalities in compression, encryption and snapshot, typically expected from proprietary high-end storage systems.

The benefits of the ZFS-based solution is …

[Read More]

Thursday Jun 17, 2010

Turn planned system outage into no application downtime

High-Availability in IT is a strategy to satisfy business availability needs. It is impacted by planned outages and unplanned outages --the result of a system or software fault, which we will not address here. Planned outages are typically a result of a preventive or corrective maintenance task that imposes an interruption to the day-to-day system operation. The traditional approach to planned outage is a careful planning of the intervention to minimize the downtime and the risk of the system not going back up properly. With virtualization, novel approaches can be taken where system downtime and application downtime can be decoupled.

Oracle VM Server for SPARC, f.k.a. Solaris Logical Domains, is a virtualization and partitioning solution supported on Sun CMT servers powered by the UltraSPARC T-class processors. Oracle VM Server for SPARC allows the creation of multiple virtual systems on a single physical system. Each virtual system is called a logical domain (LDom) and runs its own copy of the Solaris operating system. Among its many features, LDoms have the ability to do warm migration between two machines, i.e. to checkpoint and migrate an active LDom from one server to another one.

In ISV Engineering, we have demonstrated this Domain Mobility feature for a running installation of the Oracle 10gR2 database. During the migration, the database server is not shut down. The migration from one physical host to another one is also transparent to the client applications connecting to the database --as long as no timeouts are encountered, or conversely, timeout values can be appropriately set by the application's admin and/or developers for the warm migration to happen transparently-- such that there is no downtime for the application. This work has been documented in the following whitepaper on the Sun Developer Network : Increasing Application Availability Using Oracle VM Server for SPARC.

Good reading!


How open innovation and technology adoption translates to business value, with stories from our developer support work at Oracle's ISV Engineering.



« July 2016