Strategies for Migration Simulation

Migration Simulation supports two strategies to simulate the migration of a set of servers to the public cloud: Utilization-based and Lift-and-shift.

Utilization-based

With the Utilization-based approach, the migration simulation algorithm measures and analyzes the resource utilization of the source servers (VMs) to be migrated and then proposes resized instances on the public clouds. By doing so, VMs with idle and underutilized resources are not replicated with the same configuration on the public clouds but the ideal sizes for the target VMs are recommended. This is the default migration strategy that the product uses when you choose to simulate the migration.

This strategy considers the following factors to propose the target VMs:

  • Optimization behavior: Used to define how the utilization of the source VM resources (CPU, memory, and storage) is computed to suggest the ideal size of the target VM. 
    You can choose to be conservative in your approach by considering the spikes in the resource utilization or be aggressive by considering the typical average utilization. You also have the option of being balanced in your approach. You can select one of the following behaviors:

    Optimization behaviorDescription
    Aggressive

    Resource utilization in the server is computed by considering the average value of the hourly samples. Then, 95th percentile of the hourly value over the last 30 days is computed for each resource to generate the configuration of the target virtual machine or instance type. Spikes in the resource utilization within the hour are not considered.

    This optimization behavior does not require the server to be instrumented because granular or detailed metrics are not used for the computation.

    Balanced (Default)

    CPU utilization in the server is computed by considering the 90th percentile value of hourly samples. Then, 95th percentile of the hourly value over the last 30 days is computed for CPU to generate the configuration of the target virtual machine or instance type. 90% of spikes in the CPU utilization within the hour are considered.

    Utilization of memory and storage is computed by considering the 95th percentile of the average hourly values over the last 30 days.

    This optimization behavior requires the server to be instrumented to collect the granular or detailed metrics. For VMware vSphere, the server need not be instrumented because the vSphere Service ETL collects data at less than one minute granularity.

    Conservative

    CPU utilization in the server is computed by considering the 95th percentile value of hourly samples. Then, 95th percentile of the hourly value over the last 30 days is computed for CPU to generate the configuration of the target virtual machine or instance type. 95% of spikes in the CPU utilization within the hour are considered.

    Utilization of memory and storage is computed by considering the 95th percentile of the average hourly values over the last 30 days.

    This optimization behavior requires the server to be instrumented to collect the granular or detailed metrics. For VMware vSphere, the server need not be instrumented because the vSphere Service ETL collects data at less than one minute granularity.

    The computed resource utilization values are stored in the demand indicators (CPU Demand, Memory Demand, and Storage Demand). For more information, see Indicators.

    Information

    If you select the Conservative or Balanced optimization behavior for a server that is not instrumented, the results are based on the Aggressive behavior.

    BMC recommends the Conservative behavior for servers that are running business-critical applications.

    A server with a Capacity Agent installed on it to collect granular or detailed metrics.

  • Estimated CPU benchmark: Used to measure the compute power of the source and target VMs. 
    Using benchmarks ensures that the suggested target VM has the same computing power as that of the source VM even if the hardware is different. Typically, VMs on the public cloud run on new hardware. Using benchmarks enables you to estimate the benefit of moving to the newer hardware, which might require a smaller number of CPU cores than running the VM on-premises. 
    If the CPU benchmark value of the source VM is unavailable, then the resizing recommendation for the target VM is generated without considering benchmarks, which lowers the accuracy of the simulation scenario. 
    SPECint_rate2006 is used as the reference benchmark to compare the hardware of the source and target VMs.

Lift-and-shift 

With the Lift-and-shift or Rehosting approach, servers are replicated or re-hosted on the target public cloud without any redesigning. This is one of the most commonly used migration strategies. 

The migration simulation algorithm considers the hardware configuration of the servers to be migrated and proposes instance types with the same configuration on the public clouds. If two instance types with the same configuration are available, then the algorithm chooses the cheaper one.

Was this page helpful? Yes No Submitting... Thank you

Comments