Go to main content

Lift and Shift Guide - Migrating Workloads from Oracle Solaris 10 (ZFS) SPARC Systems to Oracle Solaris 10 Guest Domains

Exit Print View

Updated: February 2020
 
 

Lift and Shift Overview

This document provides instructions for performing a physical to virtual lift and shift. The techniques in this document are specifically aimed at migrating workloads running on Oracle Solaris 10 with ZFS root file systems on SPARC systems to Oracle Solaris 10 Guest Domains in Oracle Solaris 11.3 (or later) running on more modern sun4v hardware.

image:A figure showing an older SPARC system's physical environment moving to a newer SPARC system's virtual environment.

Scope

The instructions in this document are limited to the lift and shift of an Oracle Solaris 10 environment with ZFS root file systems to an Oracle Solaris 11 Environment that is configured with an Oracle Solaris 10 guest domain. The source Oracle Solaris 10 environment can be configured with Solaris zones. In such cases, such as the example in this document, the global zone, non-global zones, and associated applications and data are migrated to the target system. It is also possible to use this guide to migrate a non-virtualized Oracle Solaris 10 environment, as long as the environment is based on ZFS root file systems.

This procedure does not take down the source machine during the archive creation, therefore the source system is available for use. However, to maintain the integrity of the application (Oracle Database and Apache web server in this case), it is a best practice to cleanly shutdown the services.

The performance measurement of the source and target system is not within the scope of this document.

Lift and Shift Process

The lift and shift process involves using a variety of Oracle Solaris utilities to migrate the entire source configuration, including all associated applications and data, to an Oracle Solaris 10 guest domain on the target system. 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 that services are unavailable.

  • Identify and resolve all source system issues – (Not covered in this guide) Resolving issues before migration simplifies troubleshooting by eliminating the migration as a possible cause of issues. Consider checking log files for issues and applying the latest critical path updates (see Critical Patch Update Bulletins). In some cases, rebooting a system that hasn't been rebooted in a long time can reveal issues.

  • Assess the source system – 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, and workload resources.

  • Select the 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 the source system – Patches, which provide the necessary lift and shift utilities, are installed on the source system.

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

  • Prepare shared storage – Shared storage is used to capture the source workloads and then used to restore the workloads on the target system. Using shared storage is central to this lift-and-shift scenario. Storage on the target system is exported as a network file system and mounted on the source system, providing easy access to common storage from the source or target system.

  • Create an Oracle Solaris 10 guest domain on the target system – A new Oracle Solaris 10 guest domain is created on the target system using an Oracle provided OVM template. The guest domain will host the incoming Oracle Solaris 10 environment. The following illustration shows the commands that are used to prepare the guest domain.

    image:A diagram showing the three commands used to prepare the target system.
  • Lift – The ldmp2vz_collect command is used to capture the source system's OS ZFS file system, and capture the source's zone configuration (if present) into a flash archive (FLAR). Then, using various utilities, all zones, along with their associated storage content, applications, and application data are lifted from the source and copied to the shared storage.

  • Shift – The ldmp2vz_convert command uses the FLAR that is on the shared storage to restore the source system's OS ZFS file systems to the target guest domain in a new boot environment. The zone configuration and storage is also restored. If the zone storage is included in the root file systems, then that storage is also restored.

    image:A diagram showing the ldmp2vz commands used to lift and shift.
  • Transfer Applications and Data – Different utilities are used to transfer workload components based on the type of file system where the component resides. In some cases, the output of one command is piped to pigz or gunzip to improve efficiency through compression and decompression that those commands provide. This diagram shows the different utilities.

    image:A diagram showing the transfer utilities used to migrate different types of file systems.
  • Reconfigure – The shifted environment requires post-migration reconfiguration to function in the new environment. For example, the network configuration is carried over from the source environment, and usually needs to be changed to function in the new environment. If processor sets were used in the source environment, they might need some adjustment when they are restored in the target environment.