button-print-blu20 6 things to consider when planning #Workload #Migration

This document aims to highlight the considerations which should be made when planning the migration of workloads from one platform to another. For example from an on-premise solution to a Cloud Provider.

Before even starting this process, you should sit down and ask yourself these 6 questions:-

1      Physical or Virtual?

What is the workload that is under the microscope? If it’s physical, has anyone checked that the application ‘can’ be virtualised – not only from a practical aspect, but also from a licensing perspective. Does the software vendor support or even agree to ‘hypervisor’ platforms? Should the application remain physical (or on-site), as the business risk or existing support contract would stop the migration process.

2      What does it do?

Growth Rate – how much and over what period of time, is it a nice linear growth or bursty / seasonal? Historical data is very useful for this, depending upon how the existing workload is monitored or backed up, the customer may be able to help fill in the blanks. There is no ‘typical workload’ every machine is different – similarities can be drawn across workload types i.e. SQL Database growth is defined in the backend, as in how much does it grow when full. Email services can monitor the throughput of mails & the storage can be calculated.

3      What dependences exist?

It’s rare that a workload is completely isolated, most servers are “cogs within the machine”. Knowing what data a particular service consumes or provides is important in planning any migration strategy.

4      Downtime – How much is acceptable?

Again, often overlooked during initial discussions, but any form of migration may involve an element of downtime. The acceptable amount needs to be openly discussed early in the planning stage to avoid the awkward moment just before the live move, when someone needs to tell the customers MD his important business application won’t be available for a while!

The amount of tolerable downtime can help (or force the hand of) any migration strategy. Quite times need to be carefully planned and arranged, alongside adequate ‘support’ whether that be customer side, Cloud Provider or 3rd party.

Do you choose to migrate midnight on a Friday, at the end of a 40+ hour week, just before the weekly backup job is about to start, and vendor support is limited or even outside of the UK?

button-print-blu20 6 things to consider when planning #Workload #Migration  sun-870878_640-300x199 6 things to consider when planning #Workload #Migration
Image courtesy of Pixabay.com

Alternatively, Tuesday mid-morning, following a final project meeting on the Monday giving the green light – everyone is refreshed, awake & prepared and vendor support is at 100%?

5      Customer Access Options

After migration, does the customer actually need administrative access to the workload? If so, is it via a Web interface or a Portal, or is via RDP or SSH in order to manipulate the Operating System.

6      How Big is it?

Ultimately we will always end up asking this particular question.. These last points are absolutely essential for building a virtual version of an existing workload. That’s not to say that the existing configuration is perfect, nor that it is even transferable to a Cloud Provider – the underlying CPU frequencies and Storage latencies can have a huge impact on a running VM. In which case you should also ask:-

  • Number of Disks – A simple question but important. How many disks does the existing machine have and why. Would this configuration be supported / does it need to change? Does each disk have specific requirements e.g. capacity / performance (see below)
  • IO Requirements – How much data is put on and retrieved from, the disk subsystem
  • Storage platform/performance – SSD, SAS or SATA. Is the storage RAID or single disks
  • Storage connectivity – Internal Disk, external SCSI, USB, Network Attached, Raw Device Mappings (RDM’s
  • CPU / RAM usage – Is the workload multi threaded? Does it expand to use all the available RAM
  • Bandwidth Requirements – Some workloads require very little bandwidth, others such as email or SPAM filtering are wholly reliant on bandwidth. Getting an idea on how much is required and it’s direction (into or out of the machine)
  • Nature of the Data – SQL, Files, Mail, Archive, Images, Video

Leave a Reply

Your email address will not be published. Required fields are marked *