Essentials of Infrastructure Migration
Virtualization is everywhere! Exactly what is it and how should you make use of it?
The "Virtualization and Infrastructure Migration Technical Overview" course will help you discover the benefits of open source virtualization, how to better manage your virtualization assets, and the best way to move traditional workloads from one virtualization provider to an open virtualization.
In this course, you will learn to:
- Easily define infrastructure mappings.
- Create migration plans to confidently balance your workloads.
- Build migration plans to reduce your expenditure on virtualization.
Welcome back to the Technical Overview course on Virtualization and Infrastructure Migration. We will see now the Essentials of Infrastructure Migration. First, we need to know, what are the footprints where our workloads could be running on. The four footprints that we identified are bare metal, which is normally one server or a cluster of servers, traditional clusters. Then virtualization, which we just talked about in the previous video. Then there’s private cloud, when you have plenty of servers and you set up a full cloud environment in your own premises, or public cloud, when you’re consuming from one of the many public cloud providers out there.
So in this technical overview, we’re focusing on virtualization and how to move workloads as virtual machines without the minimum change possible. So what kind of workloads do we find in these virtual machines. We normally find scale up workloads, which means that you have something running, let’s say a traditional SQL database, on a virtual machine and to make it more available to more users, to more applications, you need to increase the memory on that virtual machine. You need to increase the number of cores or virtual CPUs on that virtual machine. And you need to increase the storage that this virtual machine has. So instead of adding more machines to be able to handle more workload, you just grow that machine. And this is what we call scale up workloads. This is intended to be used for large virtual machines.
Let’s say that you can have one terabyte memory virtual machine with 128 virtual CPUs. This is huge. So this kind of virtual machine is intended to run on traditional virtualization. There is another point which is very important, which is that the high availability for that virtual machine is handled by the virtualization platform, which means that if one of their hypervisors, one of the servers that this virtual machine is running on, falls or has any problem, this virtual machine will be restarted in a different server.
The good thing is that while there is no incidence, you can move the virtual machine from one hypervisor, from one server, to a different hypervisor easily and proceed to do maintenance tasks on that hypervisor. On the hypervisor, let’s say that we have a failed disk. So we move all the VMs from that hypervisor. We go there, we remove the disk, insert the new disk, rebuild the RAID, and we’re running again. This provides very good internal mobility within the virtualization platform but it does not provide external mobility, which is moving these virtual machines from one virtualization platform to a different virtualization platform.
So what is it that we want to do? I mean, let’s say that we have one VMware vSphere environment running and with one RAID that is getting full. And this is packed with virtual machines and we need to be able to add some capabilities to it. What if we could add one Red Hat Virtualization environment that is completely available, that is right configured? And then we could move virtual machines from vSphere to Red Hat Virtualization so it’s more balanced. And then we have a better and most cost-effective workload location.
How can it be done? Well, first we need to know we have the point of departure which is, in this case, a VMware vSphere. And we have the point of destination, which is Red Hat Virtualization. And in these two points, we have clusters. There’s a cluster in vSphere which will be equivalent of this cluster in RHV. And we have networks. So we need to map the networks. These networks, let’s say the administration network, let’s say the storage network, let’s say the service network, these networks need to be mapped to the same networks in the destination because they will probably use the same VLAN tagging. And also the storage domain.
If in the point of departure, we have a storage array that is very fast because it is fibre channel with full flash, we need to have an equivalent in the destination. Also a fibre channel with full flash. However, if we have a more cheaper or more cost-effective way of storing data, let’s say, an iSCSI disk array with the spinning disks, we could use the same kind of a storage in the destination.
Well in this case, with it being Red Hat Virtualization, you could even use Gluster which is some of the finest storage, which is pretty cool. And then, we need one piece of hardware or a virtual machine to be able to perform the task of converting the virtual machines. To do so we can choose the hypervisors in the point of destination, in Red Hat Virtualization. We will make use of the APIs available in Red Hat Virtualization to perform the conversion task.
So what is this conversion task? Well, VMs are stored in different formats in different platforms. So to be able to move them from one place to the other, we need to know the format. For example, the disk format in vSphere is VMDK. We need to transform it to QCOW2, which means Quick Copy On Write, which is that this format is very efficient and is the one that Red Hat Virtualization uses. And same with network. We need to map the network profiles in the source and the network profiles in the destination so they are connected to the same network and they have the same performance. And also the tools.
Normally when you have a virtual machine, you install in the guest operating system some tools to make management more easy. So we don’t need to take these tools and add the new tools. The good thing about Red Hat Virtualization tools is that they are all open source and normally most of them come with their kernel in your preferred Linux distribution. If you are using Windows, you can add them via an ISO image that is provided. So once we have this mapped, we need to identify the conversion host.
To identify the conversion host, we’ll use our orchestration platform, or cloud management platform, which is CloudForms. And we’ll choose one hypervisor and we’ll add two tags. One of them will identify the hypervisor as the conversion host and the second tag is to identify which method are we going to use to perform the transformation. Once we have that, we have the conversion host identified. And then we link it to the Cloud Management Platform so we can orchestrate the transformations. And well, we do a bulk migration and we have all the VMs in the destinations. This is being used to move hundreds, thousands of VMs in different customers. And this is what we are providing in this Technical Overview course. Hope you enjoyed it. See you in the next video.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).