Lift and Shift Guide - Migrating Workloads from Oracle Solaris 10 SPARC Systems to Oracle Solaris 10 Branded Zones

Lift and Shift Overview

This document provides instructions for performing a physical to virtual lift and shift. The techniques are specifically aimed at migrating workloads running on Oracle Solaris 10 with UFS or ZFS root file systems on SPARC systems to Oracle Solaris 10 branded zones in an Oracle Solaris 11.3 (or later) global zone.

Oracle Solaris 10 branded zones, also known as solaris10 branded non-global zones, run Oracle Solaris 10 applications in a virtualized Oracle Solaris 10 environment on top of the Oracle Solaris 11 operating system. Applications run unmodified in the secure environment provided by the non-global zone, and can take advantage of the enhancements made to the kernel and utilize some of the innovative technologies that are only available in Oracle Solaris 11 releases.

For additional information about Oracle Solaris zones, refer to the zone documentation in the Oracle Solaris Information Library for your specific release:

• Oracle Solaris 11.4 Information Library

• Oracle Solaris 11.3 Information Library

• Access to other Oracle Solaris Libraries

With a higher number of compute resources on newer SPARC systems, a single global zone can host a higher number of non-global zones, consolidating compute workloads. This lift and shift procedure can be used for each Oracle Solaris 10 single system that you plan to move to the newer SPARC system.

Lift and Shift Process

The lift and shift process uses a variety of Oracle Solaris utilities to migrate the entire source configuration, including all associated applications and data, to a solaris10 branded non-global zone on target system's Oracle Solaris 11 global zone. To accomplish this migration, the following activities are performed, although not necessarily in this exact order. The procedures in subsequent chapters order the activities to minimize the amount of time when services are unavailable.

• Analyze the source system to ensure migration suitability –(Note - This command is only available in Oracle Solaris 10 Update 9 or later.) One way to analyze the source system is to run the Oracle Solaris zonep2vchk utility. This utility evaluates a global zone or physical instance for potential migration issues. The utility can detect issues with the OS, network, and storage configuration, identify some OS features, application binaries, and applications that might not be supported in a non-global zone,

  

• Assess the source system resources and workloads – Determine the amount of resources used to support the workloads. Gain an understanding of the configuration so that you can replicate the configuration on the target system. Collect information about the CPU, memory, storage, network, and workload resources.

• Select a target system – Select a target system that has sufficient, or additional resources to support the workloads. The target system is usually a more modern system that provides security and performance improvements, and possible cost savings such as lower power, cooling, and support costs.

• Prepare shared storage – Storage on the target system is exported as a network file system and mounted on the source system, for the efficiency of the lift and shift process.

• Prepare the target system – CPU, memory, networking and storage resources are configured to accommodate the incoming Oracle Solaris 10 environment.

• Configure a solaris10 branded non-global zone on the target system – A new solaris10 branded non-global zone is configured, but not yet installed, on the target's global zone.

• Lift – The flarcreate command is used to capture the source system's file systems, including the OS, applications, and data, and compressing those items into a flash archive (FLAR) on shared storage.

• Shift – The zoneadm install command uses the FLAR to restore the source OS root file system to a ZFS root file system in the Solaris 10 branded zone.

  

• Reconfigure – The shifted environment might require post-migration configuration adjustments to function in the new environment. For example, if the network configuration is carried over from the source environment, the network parameters might need to be changed to function in the new environment.

• Verify functionality – Verify the functionality of the workloads. If possible, take performance measurements and adjust resources to run optimally in the new environment.