AZ-303 Microsoft Azure Architect Technologies – Implement Management Solutions

1. Migrating Workloads with Azure Migrate

One of the first steps many companies take when moving to the cloud is to perform a lift and shift of existing infrastructure, i.e. To perform a simple move of existing service from on premise into Azure. For migration of virtual servers, azure Migrates ports and provides a migration appliance. This is a specialized VM with the assessment tools preinstalled and can be run on either HyperV or VMware. The first step of any migration is knowing if a server can be moved to Azure.

This is known as the Server’s Readiness and not all servers can be moved. As we can see, there is a few different criteria a server must meet. So things like it must have less than 128 cores, less than 3892 gigabram, and so on. It’s also important to keep an eye on the OS. So for Windows, especially if you want anything later or newer than Windows 2008, which is 2003, then you’ll need an out of support agreement. Your existing servers may also have dependencies in each other.

So for example, a web server may have a dependency on a SQL Server. You also want to know what’s the right specification for your server when moving to Azure. And finally, you also want to have a cost estimation of what your infrastructure would be if you migrated it to Azure. For this reason, Microsoft offers Azure Migrate, which is a tool to help perform the above analysis and then actually migrate those servers for you. The service itself runs in two distinct phases analysis and then actual migration. And there are a number of tools depending on what you currently have and what you want to move to. First is the Azure Migrate server assessment.

So this is the tool that assesses virtual machines and physical machines. Combined with that is the actual Azure Migrate Server migration tool which is for the actual migration. In addition, you can have a data migration system. This is specifically for assessing on premise SQL Server databases for migration to Azure SQL Database, an Azure SQL Database managed instance or Azure VMs running SQL Server again. Along with that, there’s a separate tool for migrating actual databases from virtual machines into Azure. There’s a web app Migration system which is for assessing on premise IIS or Web applications and migrating them to Azure web apps. And then finally there’s a specialized service called Azure Databox which is for migrating offline data in volume. The server assessment uses a lightweight Zure Migrate appliance that you deploy on your premises.

The place itself runs on a VM or can even be set to run on a physical server. And you can easily install it by downloading a provided template the appliance discovers onpremises machines and it also continuously sends machine metadata and performance data to Azure Migrate. With the appliance discovery therefore is agentless, nothing else is needs to be installed on the discovered machines. After the actual appliance discovery, you can then gather discovered machines into groups and run assessments on each group. When you initially install the assessment tool, it performs an asis assessment. That is, it performs an immediate scan of your infrastructure to create this initial assessment. When assessments are run, you are given a confidence rating between one and five stars. A confidence of one star means the assessment tool only had a minimum number of data points on which to base its calculations. To get the highest confidence rating, it is better to leave the tool running for at least a day. This will give the tool more data points to analyze. You also, of course, need to ensure that VMs are powered on. When you are running performance based assessments, make sure you profile your environment for the assessment duration. So for example, if you create an assessment with the performance duration set to one week, you need to wait for at least a week after you start the discovery for all the data points to be collected. You also need to ensure that you recalculate assessments to always get the latest data. You can then group service as part of the assessment, and this helps you analyze and eventually migrate those servers in batches, which is ideal for phased migrations as opposed to a big bang approach.

When you are ready to migrate, you then install the appropriate migration tool. Depending on whether you are migrating virtual machines, databases or websites, some virtual machines might require changes so that they can run in Azure. Azure Migrates makes these changes automatically for certain VMs, specifically those that are running operating systems. Redact hint Linux Six, five and over sent OS six, five and over sus Linux Enterprise Server Twelve and over, and Ubuntu 14 LTS, Andover, and finally DBN eight and seven. If you’re migrating a Windows Virtual Machine, you need to make the following changes before migration. If you migrate the VM before you’ve made the changes, the VM might not boot up properly in Azure, those changes you need to make on a Windows machine include enabling the Azure Serial Console for the Azure VM. And if you’re migrating machines that are running Windows 2003, you have to install the HyperV Guest Integration Services on the VM operating system. For other types of Linux machines, you also need to install the HyperV Linux Integration Services. You might need to rebuild the init image so it contains the necessary HyperV drivers.

Again. You have to enable the Azure serial console logging. You need to update the device map with the device named Volume Association so you can persist device Identifiers update entries in the SS tab, remove any U dev rules that reserve interface names based on Mac addresses, and update the network interface to receive an IP address from DHCP. The migration tool itself will then replicate the data from your on premise network into Azure Virtual Machines. It uses Azure Site recovery services to replicate them. However, if you have large amounts of data, you can optionally order a data box.

This is a physical device that’s shipped to you to perform the initial copy of data on premise. You then ship the box back to Microsoft for copying into Azure. After all data is replicated, you can finally switch over to the Azure servers by switching off the on premise servers and performing a final migrate task in the Azure console. There are a number of limitations you need to be aware of. The Azure Migrate you can assess up to 35,000 VMware or hypervms in a single Azure Migrate project using the Azure Migrate Server. Migration you can select up to ten VMs at a time for actual migration. If you need to replicate more, replicate them in groups of ten. And for VMware agentless migration, you can run up to 100 replications simultaneously.

2. Azure Migration Assessment Walkthrough

This first step when planning your migration into Azure is to create a migration project. Create the migration project as we would any other resource in Azure. Search the marketplace or migrate and choose azure. Migrate? So we’re going a number of options here. And as you can see there is different scenarios in which we can do. The main ones are basic servers or even SQL under the databases. Depending on what you choose, you will get a different tool that you can use to plan your migration. We’re going to go for Windows and Linux servers. So I’m going to click this Assess and Migrate service here, which basically just takes us down to the Servers tab here on the migrations goal. So because this is the first time we’ve used this, I need to go ahead and click Add Tools. And then what we need to do is actually create a migration project. So the first thing we need to do as always, is create a resource group and give your migration project a name. Finally, just tell it the country that you’re in and click Next. Next we get to choose the actual assessment tool.

As you can see, there are quite a number of marketplace offerings. We’re going to go for the Azure Migrate service assessment. Next it will ask you to select a migration tool. Again, there are many different options. We can either choose Azure Migrate or we can say adding this for now because all we’re going to worry about at the moment is actually doing our assessment. And once we’re ready, click Add Tools. So this takes us back to our main page and what we need to do is click Discover here to actually start the assessment process. So it’s going to prompt us to download tools. What we need to do is download what’s called an appliance or an Azure Migrate appliance that will scan our infrastructure looking for virtual machines that we want to import.

Now we actually have two options depending on what your current on premise hypervisor is, or whether you’re using VMware or HyperV, or even if you’re using non virtualized or others. I’m going to go with HyperV. Then what I want to do is I want to download this VHD. So what I’ll do, I’ll click download first and then click Save. Now it’s a twelve gigabyte file, so depending on your internet connection, it can take a while. And what I’m going to do is I’m going to go to my server where I’ve already downloaded the tool and it’s downloaded the tool, this zip file. So what I want to do is I want to copy the hard disk and virtual machines to where my hypervisor virtual machines are. So in my case, the hypervisor and the virtual machines were in my HyperV director. So we’ve got the hard disk test. That’s the actual hard disk that we use for the appliance. And then the virtual machine is this XML document here because what we actually need to do is register this virtual machine.

So once you’ve copied those across to your server that’s running the hypervisor, I’m going to go into my HyperV and I’m going to say, import virtual machine. We need to tell it where we want to import the virtual machines from, which is the location where I downloaded or copied my virtual machine to. So I select the folder, it shows me the virtual machines that are in that folder and it’s the migrated planes that we want. Now you can either register the virtual machine, which is what I will be doing, because I’m going to use the virtual machine as it is, or we can copy the virtual machine.

So if you want to keep the source files or if you didn’t manually copy it, you can do that instead. But because I manually copied the hard disk and the virtual machine file over to my HyperV server, I’m just going to say to register it in place. Now it’ll probably come up with an error said it can’t find your ethernet switch and that’s because the virtual machine will obviously be configured with a different kind of ethernet switch.

What I want to do is go in and choose the ethernet switch that my hypothetical server is using and then click Finish. So that creates my appliance here. And so what I want to do now is I just want to connect to that and I’m going to start up the virtual machine. Now, the first time you start the virtual machine, it might take a while to start up while it registers itself with HyperV and sorts out its own internal workings on your platform. Once you’ve started the virtual machine up, log into it and it will automatically launch a browser within the virtual machine with the Azure appliance setup screen. So simply accept the license terms. The system will then go through checking that it’s got Internet connectivity and it’s synced with the time server. It will also go and download any updates. So depending on what version you have downloaded from the Azure website, it may want to do an update and restart. If that happens, then just let it restart. Once it’s ready, click continue. Then the next step is we need to actually need to register it with our Azure account. So simply click login. This will open a window asking you to sign in with your Microsoft account. Once you’ve signed in, if you go back to the appliance, it will then come up asking you to select your subscription and the migration project that we created earlier. And finally we need to give it an appliance name and click Register. The final step in the setup is we need to actually give it the details for how we can access the HyperV manager.

So I’ve just got this running on a single server. If you are on a domain, then you will need to put your domain details in. But for me I’m just using the local admin account. Click Add and enter your server name. So this is the name of your actual HyperV server or servers. If you have more, click Validate to ensure that it can connect the server and then click Save and start Discovery. As you can see by the message, this can take approximately one and a half minutes per host. Depending on how quick your server is running, it may take a little bit longer. Once the discovery has finished, we can then go back to our portal. You may need to hit the refresh button and then we’ll see here the details of what’s being found. The first thing it will find is any discovered servers.

So what we now need to do is go and assess them. So click the Assess button and give it an assessment name. We also need to create a group to put them in. So this is handy when you’ve got multiple virtual machines because having them in groups allows you to migrate machines in groups rather than either one at a time or in one big batch. Groups also allows you to group servers together. So for example, if you had an Is Server and a SQL Server, you could put them in the same group to make sure that they get migrated together. Next we choose of the virtual machines we found which ones we want to bring across. We just want this one here because obviously we don’t want the actual migration appliance. And then we click Create Assessment.

Again, that can take a couple of minutes for the assessment to be performed. Click the refresh button and once it’s complete we can go here to see the assessments that the migrate system has created. So you can see how a group of Is servers and if we go into it. So this will tell us some details about our virtual machine. So it gives us a readiness score, so the server is ready to be migrated to, which means it can come straight over quite easily and it gives us an estimated cost to both the compute and the storage. It’s important to understand it’s made some decisions for you about how you would want to migrate the machine.

And if we click Edit Properties we can see what these are here. So for example, it’s chosen a three year reserve instance which means they are much cheaper, but you have to pay upfront for the full three years. It’s also choosing the storage for you, the target location and so on and so forth. These might not fit what you want, so instead what you can do is we could say no reserved instances. If however, we do that, we need to tell it what size we do want to use. So for example, I might want to go for standard A zero. Again, you might want to change different offers, change your currency pricing and so on and click save. Once it’s finished reviewing again, we get a new review again.

Obviously, it’s still ready to be migrated, but now we can see the cost has gone up because we’re not using reserved instances. Once that’s done, it gives you the tools that you need and the information you need to be able to actually decide which servers can be migrated, important, how much it will cost. So the next step will be to go ahead and start migrating them.

3. Azure Migration Walkthrough

Once our assessments are complete, we can then get on with migrating our servers. To do this, we actually have a couple of options. The first is we can add a migration tool through the Migrate Service project which actually automates the process of creating a Recovery services vault and setting up replication. So the second option will be to do that manually, i.e. Create a recovery services vault, install the client on the service we want to migrate, and then setting them to replicate into Azure. We’ll go through the migration tool method and show how it creates the vault as we go through. So within our Migrate Servers pane, if we go to click to add a migration tool and we’ll choose the Azure Migrate Server Migration tool. So the first step, again, as we did with the server assessment is we need to click Discover and again it asks us some basic questions. So the first is we’re going to be using HyperV. Again, the options are VMware or other for physical hardware.

Next we need to say which region we’re going to. Now once we’ve set this, we can’t change it. So you have to make sure you’re setting the correct target region, click Confirm and click Create Resources. So once that’s finished, we need to prepare the Hypervre service that we want to replicate to. So it’s prompted us to download this additional tool that we need to install, which is the usual site recovery provider. So the first thing we need to do is download the actual installer. Now because we need to install this on our HyperV server, what I’m actually going to do is copy that link and then I’m going to go to my HyperV server and download the tool. We also need to download a registration key file. So the Azure Services Site Recovery actually only has a five day license. We need to download that tool as well and open it up. So we’re going to need to store this file as well.

So again, what I’m going to do is just save that to my local laptop and again, I’m then going to copy that over to the virtual machine. So on my hypothesis server here, we’ve got the Site Recovery service provider and then we’ve got the key file that I’ve just downloaded. So let’s run the installer first. When installation is complete, we’ll be asked to register. So click the Register button and browse to the key file. That will prefill all the information we need. If you need to connect through a proxy server, you can set the details here. Otherwise, simply go through and wait for the registration wizard to finish. Once that’s done, click Finish and the agent will now be installed.

So go back to our azure portal. What we may need to do is close this window down, hit Refresh and click Discover again. So now we should see this option to finalize Registration. As you can see, the next step will take around ten to 15 minutes. So we can come back when that’s completed. Once the registration is finalized, we can close down that window. And now we can see more information in our server migration area. So the next thing we want to do is choose one of our servers and we want to replicate it, go through the wizard. So this is going to be a HyperV server. We can either specify the settings manually, ie. Which virtual machines we want, or we can use the settings from the migration assessment. If we use the assessment, we simply select the group and the assessment we chose. We can see our Is server. Finally, we tell it where it to go.

So I’m going to put this into the Wind Servers resource group. We need a replication storage account. I shall put that in my storage account I created earlier. Again select which virtual network and subnet we want to.

So again, I will choose our Windows subnets. Because we’re migrating a machine, we can actually use the Azure Hybrid benefit because we’ve already got an eligible Windows Server license. It will automatically pick the best matching configuration based on the configuration of the virtual machine it’s discovered. Or you can go through and select your own and again simply select the OS type. And if you want it to be an availability set, if your virtual machine has multiple disks, you can choose to replicate one or all of them. Next, once we’re ready to go, hit replicate once the replication started. If we refresh the tools, we’ll see now that we’ve got one server in the Replicating Service part here, and if we click through, we can see the percentage of synchronization and whether it’s healthy and so on. So the first step in this migration is that we need to copy that server across. So that might take some time. While we’re waiting for the synchronization to finish.

I’ve also gone into the resource group where we set up our migration project and we can see here that the process is built as a recovery services vault in the background. So normally we’d build these manually and we would use them to do backups and recovery services, which we will look up later. But for now, if we look into this recovery vault, we can go into replicated items and we can see our Is server that is currently being replicated at the moment. If we look at our site recovery infrastructure and go to HyperV sites, you can see our Cloud migration Hip V site and we can see our registered host. The point of this is the Azure Site Migrate Service is basically just using a site recovery services in the background to perform our replication. And in fact, if we wanted, we could manually go and create our own site recovery. So for on premise machines, we would go through the Prepare Infrastructure Wizard and we would have said on premises to Azure and it’s just asking us if we would want to continue this way or whether we’d like to use Azure Cycle Cover.

We’re just saying yes. Say hiker. V say no to using System Center VMM. Okay? And that will then basically take us through a similar process to what we did whereby we need to download the tool to install on our HyperV horse and send that through. Depending on your connection speed and the size of the virtual machine you’re replicating, this process could take quite some time. Once it has synchronized, however, once and you’re happy to migrate it, what you would do is you will go into the virtual machine details and first thing you could try is a test migration. So the test migration will be possible after the first full synchronization is completed. And that will just do a failover test without actually bringing the virtual machine online properly just for you to make sure that it works.

Okay. Once you’ve finished, you would then perform a final migration by shutting the source virtual machine down and then running the migrate tasks within the portal itself. Once the migration is then finished, you would then come back into here and as a final step, stop the replication. So I’m going to stop the replication on this. Now. Once you’ve finished with the Azure migrate and you want to clean up the resource, what you need to do is go to the resource groups and find the resource group that you created it in, which in our case was RSG migrate.

And that will show us a key vault and our recovery services vault. But what we also need to do is tick this box here to show hidden types. And you’ll see there’s actually a number of services that is created in the background. So what we need to do is go through each of those and delete all of them. If you also did any migrations, you may also want to check your storage account that you selected when setting up the Azure migrate system and deleting any events the VHDs that it might have copied into there.

4. Resilience Setup

So over the next few lectures we’ll be looking at different types of load balancing scenarios. First we’ll be looking at traffic manager, but we’ll also be looking at load balancer and application gateway. And some of these require virtual machines built in an availability set. Therefore, I’m not going to be able to reuse the Linux virtual machines I used earlier. I’m going to create two new ones and unlike earlier, I’m going to create them both in what’s called an availability set. So first of all, I’m just going to go and create a resource. I’m going to create a new buntu server and I’m pretty much going to follow the same process I did before. So I’m going to go into the use the standard resource group that I used before, make sure you build it in the same region that you created your Linux virtual machine network before. And the biggest difference here is on this availability option.

So we’re going to go and say use an availability set because we don’t have any. The first thing I’m going to need to do is actually create an availability set. I’m going to change the size to quite a small one. We don’t need anything too powerful. I’m going to change the authentication type to username and password. I’m going to allow all Pulse, http, Https and SSH for the disk. I’m going to set it to a standard HDD. This will just reduce our costs for the virtual networking I’m going to go and use the network I created earlier. So it’s the resource group was the Vet Linux set, the default subnet. We want a public IP.

So I’ll leave that as it is. That will create as a public IP and again everything else can be left the same. Turn off boot diagnostics, you’re not going to install any extensions so now we can go ahead and review and create it. So while that’s creating, I’m actually just going to go ahead and kick off a new one. And the process is exactly the same as we have just done. Except instead of creating a new availability set, I’m going to select the one we’ve just created. Once the two web servers are built, there’s a couple of things we need to do. First is I want to get their public IPS that have been assigned. So I’m going to take a copy of that. And the second one what I also want to do is configure DNS because at the moment we’re going directly to an IP address but I want to configure DNS for later on.

So I’m going to go is into my DNS configuration. I still want the IP address to be dynamic but I’m going to choose a name. Then we’ll go and do the same. Back on web one it’s now they’re built and a DNS name set. I just want to install Apache on both of them. So on each server in turn we’re going to connect them over SSH. So I’m going to run the command prompt and we’ll use the IP address for now, simply because it’s easy to type in. Now, we did this earlier in one of the other lectures, but in case you can’t remember, first of all, we need to update the package manager. Once that’s done, we can go ahead and actually install Apache. We’re installing Apache two.

And what I want to do now is just create a couple of HTML files. And this is to allow us to identify which server we’re hitting. So the first thing I want to do is navigate to VAR www HTML because as standard, this is where Apache stores its files. So once we’re in there, we’re going to use a program called Nano to create the basic file. So I’m going to type pseudo nano, and then I’m going to say node HTML. And this brings up a very basic text editor. And I’m just going to put in some very basic HTML. I’m going to save that and then exit out. And if you want to check that that’s working, I’m just going to go and copy that. And in a new browser window, just go to the root, which brings a Power Apache page.

And then if I go to Node HTML, it tells us that we’re on Node One. So once that’s done, I want to do exactly the same, but on my other server. So if we go back to Web Two and I’m going to actually launch a new command prompt here, we’re just going to repeat the exact same process. The only difference in this brand is we’re going to say hello, no too. And finally, again, we’ll just check to make sure that we are running on that server. So very quickly, two servers set up, each one on their own URL, each one with the same file in the same location, but telling you which node they’re on. So with that in place, we’re ready to go ahead and actually build the first of our load balancing solutions, which is a traffic manager.

5. Azure Traffic Manager

Azure provides a number of different load balancing solutions and each one has its own different nuances and suggested use cases. Over the next few lectures we’ll go through the most common ones. First we’ll look at traffic manager. Traffic Manager provides DNS load balancing that distributes your application to services in different regions according to rules you define. So for example, if you had a web application that you wanted to be available worldwide, one option would be to have a web app deployed in multiple regions, ie. One in Europe, one in the US.

However, you’d only have one URL for accessing the web app. Traffic Manager would then distribute traffic to both those endpoints based on various criteria. So for example, one of them could be proximity. Users in Europe would be directed to the European instance and those in the USA to the US one. It can also be used for LTAL failure over from one region to another in the event one region becomes unavailable, ie.

If the European region went down, then all users will be redirected to the US instance. It’s important to understand that unlike other load balancing solutions, traffic Manager does not inspect traffic. It merely gives clients an IP address for the DNS entry based on the rules you set up. The actual endpoints you use with Traffic Manager can be services hosted in Azure or even external services hosted outside Azure, in which case you can specify an IP or FQDN or Fully Qualified Domain Name. Or you can use Nested Endpoints whereby you can effectively combine multiple traffic mines profiles to create more complex rules. To support this, there are a number of different routing methods that you can use.

The first is weighted with a weighted routing method. Each endpoint is given a weight between one and a thousand. Endpoints are randomly assigned but sending more traffic to the higher end, weighted endpoints and the lower ones. Priority routing defines a list of endpoints in a priority order, so all traffic will go to the point with priority one first until that point degrades, at which point traffic will then get routed to the next highest priority. Performance uses Internet latent set to send traffic to the fastest endpoint for the user, which is similar but not exactly the same as geographic, which directs endpoints based on the user’s geographic location.

Therefore, it is still possible that with Performance routing method you could still get sent to an instance in another region if that of the region was performing better, whereas geographic you would always be sent to your local geographic location. There’s also a MultiValue option. So with this, Traffic Manager sends multiple healthy endpoints to the client. The client itself has to try each endpoint in turn and is therefore becomes responsible for determining which one to use. And finally, you can have subnet based routing. This route users based on the subnet that they are in, and this is most commonly used in hybrid and corporate scenarios.