CompTIA Cloud+ Cert Prep 3 (CV0-002): Migrating, Maintaining, and Troubleshooting

- At this point in the course, we've covered the basics of compute, storage, and networking related to the cloud. We've talked about important security issues in the cloud and even gotten a general overview of cloud technologies. Now what it's time to do is think about migrating to the cloud. Now that we understand the different things we can do in the cloud, how do we want to get our stuff into the cloud? And there's several topics to consider when it comes to migrating to the cloud. We have to think about how we convert existing systems to cloud systems, we have to think about getting our security into the cloud, we have think about getting our networking into the cloud. All of that has to be considered. So we're going to start this chapter by talking about the different methods that we can use to migrate machines to the cloud. We're going to be talking about the different migration types for the systems that we might have in our environment. And the first migration type is called Physical to Virtual, P2V. Now this is the most common type that you find yourself doing. When you're in a scenario where you've got a bunch of existing systems and you want to get them into the cloud. Physical to Virtual means converting physical servers to virtual servers. It may be performed for the cloud or simply for conversion to virtualization, so P2V has been with us since before we started talking about cloud concepts. When we first got virtualization, we had to start thinking about how we convert physical to virtual. But it involves to several actions. We have to migrate the operating system from the physical machine to the virtual machine, the applications and the data. And there are different things that might be considered here. When we migrate the operating system, we might need to first of all, do what's called generalize the operating system. We'll see this again for several other conversion considerations as well. Generalizing the operating system means that we are stripping down the unique things in the OS configuration based on the hardware that it's on, so that we can move it to a virtual platform and then replace all of that with the proper drivers for a virtual platform. Now the process of doing this P2V conversion can be manual, semi-manual, or fully automated. So manual means that we go into existing physical machine, we generalize it, shut it down, and then we boot off of a disc, or a CD-ROM, and we make an image of the machine. We then load that image into a virtual machine and install the appropriate drivers. So that's manual. Semi-automated may mean that we have a script that does all of the generalization for us, and then all we have to do is load the image and load the drivers. Fully automated means that we have scripting that takes care of all of it, or an application that takes care of all of it. Literally it goes in, it generalizes, it creates the image, it loads it up into a virtual machine, and then it loads the proper drivers. All of it, automatically. Now in addition to P2V, we have V2V. V2V is Virtual to Virtual, so you're converting a virtual server from one virtualization platform to another, or moving it from one location to another. Basically it's already a virtual machine, and many people do already have virtual machines on premises in their environment, and now they just want to get them into the cloud. So what we can do is we can convert it from our format for virtualization to Amazon AWS format, Google Cloud platform format, Azure format, wherever our destination is. Now platform-to-alternate-platform is another one that requires the same process as P2V. So even though we might have a virtual machine with one platform, and now we're moving to another virtual machine with a different platform, meaning instead of running on Python, it's going to run on PHP, we still have to do a lot more work to get that done. Platform-to-same-platform requires only a move of the VM. Now another way to think of platform to platform is to think of the virtualization engine itself. So, we may currently be on, let's say, Hyper-V internally, and we're going to move to AWS virtualization platform, so we're still going to have to do the generalizing which gets rid of the Hyper-V drivers out of the image, then load that disc image up to the cloud and run it there. Finally, and I say finally because it's the last one that really requires conversion, is Virtual to Physical, V2P. Here we're converting a virtual machine to a physical machine. It may be used to move from the cloud to on-premises or it may be used in some cloud providers to dedicate a physical machine to your process if you're getting a dedicated server, not a dedicated host, it's a physical server you're loading it onto. The machine should be generalized before the move, just like P2V. Then we have physical to physical. Now, this one really isn't conversion of the virtual machine or the physical machine so much. We're just migrating software from one physical server to another. We often do this with imaging or cloning. It could require generalization, it depends on the scenario, but quite often we're not even moving the operating system from one to the other. We're just moving the applications from one to the other. So we load the application on the new physical machine and then we just load up its data. So, it could require generalization if we're moving between different hardware, or moving between different models, or even within the same model but for some reason the vendor kept the model number but changed hardware in it. But, if you're not moving the OS, you don't have to do any conversion at all. You're just loading the application on the new machine and then migrating over the data. Now we also have to think about storage migrations. These are simpler than machine migrations because we're simply moving our data to a new place and then anything that points to that data, the pointers need to be redefined. So we might have applications that know where the data is, so those pointers need to be redefined. We might have mapped drives for users, so that needs to be redefined so they can get to the new location of the data. Scripts can be used to remap drives. So for example, let's say you had a login script for users where a certain storage that was local was being used for them to store their data and the login script did that. All you have to do is adjust the login script so it now points to a cloud location. And it's transparent to the users, all their data has already been replicated to that location, and so it's simply there. Now finally we have online vs. offline migrations. Online migrations allow users to continue accessing the system while you do the migration. This is most easily allowed when the data is stored external to the system. So the processes can continue to run while your migration is happening. The data is stored external to the system so when we get to our new destination, it's just looking at that external location as well, so there's no data loss in the process. It's hard to do online migrations if the data that's being changed has to be migrated to a new location as well. That can be an issue there. The system can be migrated and then the data is migrated later. That's the big key here. Offline migrations disable access to the system so no one can use it while the migration's taking place. It can be required for data consistency as I've already alluded to, and it's most useful when the data is an integral part of the system. So, just remember these key differentiators: Online migration, the users can still access it. Offline migration, they can't access it until it gets to its new location. That's the big difference.