Up next, on this special
edition of Microsoft Mechanics, we’re joined by Azure
Migration and Business Continuity engineering lead,
Abhishek Hemrajani, to explore the latest updates to Azure Migrate, to
provide one unified environment to discover and assess your servers, databases and
apps, and migrate them to Azure. Abhishek, welcome
to Mechanics!
It’s great to be on the show, Jeremy.
Thank you for having me!
So, about a year or so ago you and the team set out to provide a centralized hub and unified
toolset for migrating to Azure.
Since then, on Mechanics we’ve shown how you can use Azure Migrate for everything from the
agentless discovery and assessment of your VMs and bare
metal physical servers, through to right-sizing
them and lifting and shifting them into Azure, as well
as bringing your VMware workloads to run natively
in
Azure. We’ve also shown how you can discover and assess your database workloads and .NET Apps,
for migration to Azure. What have you and the team been focused on for this
latest round of updates?
So, we’ve really
been focused on making it easier for customers to discover, assess, and migrate their VMs,
databases, and apps with Azure Migrate.
With each major milestone, we set out to make these important migrations scenarios
as seamless as possible. Since the discovery and
assessment of your on-premises assets is the most critical phase in any migration project, we are
now merging the 3 tool sets for infra, apps, and data into one unified agentless at-scale
discovery and assessment flow. The first step towards that is
a guided discovery and assessment experience for Windows and Linux servers and SQL Server databases
And very soon we will be extending this experience to ASP.NET and other web apps.
And that’s pretty significant because
until recently you could do agentless discovery assessment of your VMs and bare metal servers in
Azure Migrate; but you would use integrations with the
Database Migration Assistant and the App Service
Migration Assistant to discover and assess your data
and web apps. What have you done to unify this
experience? Can you walk us through an example?
Absolutely, let’s dive right into a
demo and I’ll show you how things get better.
I’m going to start from the point at which you’ve set
up the Azure Migrate appliance to discover your
VMware VMs. These can be Windows or Linux VMs. Of course, you can also discover bare
metal servers with Azure Migrate. If you provide us VM credentials,
we can inventory installed software and help you perform application dependency analysis,
without installing any agents. That allows you to discover network paths that originate
and terminate on different VMs and the associated processes. Importantly, these credentials are
never to Microsoft and remain on your Azure Migrate appliance running in your datacenter.
With this release, we can now model servers running SQL Server
and the various instances and databases. Soon, we’ll do the same for IIS web servers.
Azure Migrate supports both Windows and SQL authentication for discovering properties of
SQL instances. Once the appliance is configured and discovery is initiated, Azure Migrate will
be able to collect the required information to help
you assess your SQL estate for migration to Azure
SQL Managed Instance or Azure SQL Database.
Here you can see that we’ve discovered 21364 servers.
980 are running SQL Server. I can also see the OS distribution.
In the discovery view: I
can see servers which are running SQL Server and how
many instances are on each of the servers. So,
if you are running multiple instances on the same server, we’ll be able to capture that information.
So, let me get this right, you can track multiple SQL Server instances on the
same server. Can you also discover the different user databases on them?
Absolutely, I can dive deeper into the instances to see the SQL version and edition, the user
databases, and other SQL specific details. For example, here I can see that my VM HRSQLVM04
is running 5 SQL Server instances. I can see the
various instances, SQL versions, count of user databases, SQL editions, and other details.
We are adding support for SQL Server 2008 to SQL Server 2019.
We will support the Enterprise, Standard, Developer, and Express editions.
I can also go deeper into each instance and see the various user databases, their size,
compatibility level, etc.
And previously, like you mentioned, you would have had to jump into a few tools to achieve
similar results... That’s right. But to be clear, Data
Migration Assistant, as part of Azure Migrate is already a great tool for database assessment.
We’ve now captured the best of its capabilities and built an at-scale discovery
and assessment experience for SQL Server. In addition to the discovery features, there are
also newer assessment types available for you. Now, we’ve always had Virtual
machine assessments, but you can now assess for Azure SQL,
Azure VMware Solution or AVS. And very soon, you’ll be able
perform Application Compatibility assessments for Windows Server.
Application Compatibility comes in handy when you want to upgrade your Windows Server operating
system and need to evaluate the compatibility of apps running on the server.
Let’s create an assessment for Azure SQL. As I mentioned before, when you create an assessment
for Azure SQL, we are assessing for both SQL Managed Instance and SQL Database.
When you create an assessment, most settings are applied automatically, but you can review
and edit assessment properties. You can select the target location.
I’ll stick with Southeast Asia. You can select the deployment type which I’ll keep
as the default ‘Recommended‘– I could choose Azure SQL Managed Instance or Azure SQL Database if
I want to go all-in on one or the other. You can also select the options for reserved
capacity, service tier, and performance history, which helps you better right-size your SQL
workloads.
I can then give this assessment a name and group the servers that need to be included.
I’ll create a group and name it ContosoVMSQL. Now I need to select my servers to assess. I
will find all servers with “SQLVM” in their name and select all of those.
Azure Migrate will ensure that only servers running SQL instances are included. Finally, I
can review the details and create the assessment. So once you’ve run the assessment,
what type of information do you get? I remember from VM assessments, you could get right sizing,
readiness, the VM SKU and cost recommendations, is similar capability now available for
SQL Server? It absolutely is. For SQL we
give you a recommendation for the Azure SQL Managed Instance or
Azure SQL Database service tier that is optimal for your workload.
It takes only a few minutes for the assessment to get created.
Once the assessment is created, you can start understanding the Azure SQL Readiness and Azure
SQL Cost Details for your instances. You can see that, in this case,
we assessed 57 servers running 207 SQL Server instances with 2925 databases.
You can see that the assessment gives you information about the readiness of your instances
for SQL Managed Instance, SQL Database, or where you may want to consider an Azure SQL VM.
You’ll also get the aggregate compute and storage cost.
So, let’s go deeper into the Azure SQL Readiness report and you’ll see that for every instance,
you get readiness for SQL Managed Instance or SQL Database.
We will also recommend which one might be a better target.
And for that recommended target we’ll also tell you the optimal configuration.
How does Azure Migrate determine those recommendations?
That’s the magic.
Let’s go deeper into the assessment for the SQL instances of one of our VMs – HRSQMVM01.
In this case, the VM is running 3 SQL instances.
The first instance MSSQLSERVER is not ready for SQL Managed Instance.
If you click on the recommendation detail, we’ll tell you the rationale behind it.
We classify migration information into issues and warnings. Issues are blocking conditions.
For example, MSSQLSEVER has a database with multiple log files, which is not supported.
Warnings, on the other hand, are non-critical
changes that may be needed to ensure that your applications run optimally post migration.
In this case, you can see that there is a PowerShell job that you should review.
Once, I understand that Azure SQL DB is in fact the right deployment type for the instance,
I can click on review Azure SQL DB configuration, and get a consolidated view
of all databases along with recommended SQL service tier for each of the user databases.
Next, let’s look at the DMS2016SQL instance.
This instance is ready for both SQL Managed Instance and SQL Database.
I am going to dive deeper into the instance to understand the reasoning behind the
recommendation. The recommendation is based on the configuration that will be most cost-effective.
I can also see information related to total database size, CPU
utilization, memory allocation and utilization, and IOPS. For this instance, there are no blocking
issues, but there are some warnings that I should be aware of.
That’s a lot of rich detail to understand readiness and migration issues.
Do you get similar details for cost?
Absolutely, Jeremy. Let’s
review the Azure SQL cost details. As you can see here, you can review compute
and storage cost for every instance that has been assessed. This information allows you
to estimate monthly compute and storage cost when you run your SQL Server databases on Azure SQL.
These cost components are calculated based on the assessment properties that
you specify when creating the assessment such as target Azure region, offers, and important
benefits such as the Hybrid Benefit. It’s awesome to see the details in
these assessments and the recommendations, what if you want to experiment and run
different assessments. Maybe you want to play around with what you may need in terms of
compute or storage for specific workloads, is there an easy way to run different assessments
and compare them? That’s a very important point, Jeremy.
You can modify your assessment properties at any time and recalculate the assessment.
For example, here I’ll edit the properties and
I can change the target deployment type to Azure SQL MI and recalculate the assessment.
Another useful feature is that once you’ve discovered
your servers and have grouped them, there’s really no limit to the number of assessments that you can
run on the same group.
You can then compare the assessments across the different dimensions that were used to
create them.
And this information is so useful when building your business case. But
what advice would you give to people watching – undertaking their first migration project?
First, you want to prioritize discovery and assessment. This helps you make key
decision related to infra, data, and apps that you can migrate first and the
appropriate migration approach for them. You'll also want to get ahead
of complexities and mitigate them. Think about your foundational architecture
or decisions to help you establish the right management and governance approach.
And lastly, adopt an iterative approach – it's more about how you create right-sized waves to start
executing your migration. Great progress -- What are
you working on next? So, today we showed you
unified discovery and assessment for SQL Server. Next we are extending into apps with discovery
and assessment of .NET web apps that you can migrate to
Azure App Service – all from Azure Migrate Also, now in preview is Azure Migrate App
Containerization, which lets you replatform your ASP.NET and Java web apps with containers that you
can deploy on Azure Kubernetes Service. Thanks Abhishek for the detailed
overview on the latest updates to Azure Migrate, how can people learn more.
Everything we’ve shown you is in preview, so you can try it out now. To
learn more and build your migration skills, you can find everything you need at
aka.ms/LearnAzureMigration And of
course, keep checking back to Microsoft Mechanics for the latest tech updates.
Subscribe if you haven’t already and thanks for watching.