- ManageEngine OpManager: Comprehensive monitoring for on-prem, cloud, and containers - Thu, Mar 23 2023
- Install K3s, a lightweight, production-grade Kubernetes distro - Mon, Mar 20 2023
- VMware NSX Advanced Load Balancer: Installation and configuration - Fri, Mar 10 2023
Most organizations are at least "dipping their toes" into cloud Infrastructure-as-a-Service (IaaS) and Software-as-a-Service (SaaS) environments to some degree. Administrators who manage hybrid environments are tasked with managing both on-premises environments with traditional Windows Server management tools and cloud environments, such as Microsoft Azure IaaS.
Is there a way for you to manage resources on-premises as an extension of your Azure cloud IaaS environment? Microsoft has introduced a new solution that helps to bring on-premises workloads into the management scope of Microsoft Azure. It is called Azure Arc. What is Azure Arc? How is it deployed and what can it do? Let's see.
What is Azure Arc?
Let's take a look at what Azure Arc is and see how it can help streamline control of servers, both in the cloud and on-premises. Azure Arc is a new solution from Microsoft to bring together the management of servers across on-premises environments, multi-cloud environments, edge environments, and others. It enables organizations to deploy Azure services anywhere and then enables extending Azure management to those resources.
Most businesses today do not fit a model where all resources reside in a single silo—on-premises, cloud, or edge. Most have a combination of infrastructure located in all of the above.
Microsoft Azure uses a solution called Azure Resource Manager (ARM) to control and automate resources across the Azure environment. Now with Azure Arc, Microsoft is essentially extending the Azure Resource Manager outside the Azure environment. This will allow managing and controlling resources such as Windows and Linux servers running on-premises, VMware vSphere VMs, and even VMs running in different clouds such as Amazon EC2 and Google Compute Engine.
Microsoft has even enabled the management of Kubernetes clusters running outside Azure. Once these are onboarded, they can be managed like Microsoft's own Azure Kubernetes Service (AKS). When you register a virtual or physical Windows or Linux machine with Azure Arc, it is managed as a resource in Azure. The machines connected via Azure Arc receive an Azure resource identifier and are managed as part of the resource group that is contained inside the Azure subscription.
What are the advantages of Azure Arc?
- Always current Azure management: You get the benefits of Azure management that is always updated with the latest Azure features. In addition, you can set up automatic updates to receive the latest patches/upgrades without downtime. This gives you control over your infrastructure across the board according to business policies.
- Unlimited scalability: You have the power of cloud automation working for you with Azure Arc. You can scale up new instances in very little time as well as scale workloads based on capacity.
- Unified management across cloud, on-premises, and edge: Using multiple tools and dashboards is cumbersome and inefficient. Azure Arc allows consolidating the management of resources under your Azure dashboard.
- Azure security extended to on-premises and edge workloads: You get the benefits of Azure security with the likes of Azure Security Center and Advanced Threat Protection (ATP) protecting your workloads.
Onboarding on-premises servers into Azure Arc
Microsoft has made the process of onboarding your physical or virtual Windows and Linux servers into Azure Arc easy. It's handled in a couple of different ways.
- Add machines using an interactive script
- Add machines using an Azure AD Service Principal Name
What operating systems are supported?
- Windows Server 2012 R2 and higher (including Windows Server Core)
- Ubuntu 16.04 and 18.04 (x64)
- CentOS Linux 7 (x64)
- SUSE Linux Enterprise Server (SLES) 15 (x64)
- Red Hat Enterprise Linux (RHEL) 7 (x64)
- Amazon Linux 2 (x64)
Let's look briefly at the difference between the two approaches to onboard your machines.
Add machines using an interactive script
The first approach requires a bit less configuration. Microsoft provides a template script that automates every step of the installation of the Azure Arc agent on the on-premises workload. One of the downsides of this method is that the administrator must interactively run the script with an account that has permissions both at the Azure level and on the target machine.
This method is a bit less desirable for scale reasons as well as security permissions since it is an interactive process and requires high-level permissions at both the Azure and the server levels.
Add machines using an Azure AD service principal name
Using an Azure AD service principal allows using a specialized management identity that has limited privileges. Only the minimum privileges are required to connect machines to Azure. This is a much safer approach than the administrator permissions required using the script installation approach.
Onboarding script walkthrough
Let's take a look at the onboarding script and see how this process works to manually add machines with Azure Arc to your ARM control plane. Click the Create machine – Azure Arc button.
The first thing you have to choose is how you want to onboard the device into Azure Arc. Here, we will generate the script needed to manually onboard an on-premises Windows Server 2019 server.
Select your subscription, resource group, region, and operating system, and configure any proxy details if needed in your environment. Afterwards, click Review + generate.
Before downloading the script, you need to click the Register button, which registers your subscription before connecting your machines to Azure Arc. After you click, Azure notifies you that it may take a few minutes to register. Also, above the script, there is a note that you need to run the script with local administrator permissions. Click Download to download the onboarding script, which will download as OnboardingScript.ps1.
Copy the script to your local server and run. The first part of the script generates an activation code displayed in the PowerShell window. You will need to open a browser, navigate to the following link, and enter the code displayed along with your Azure username.
When you open the link, it will first ask you to enter your code.
After entering the code, enter your Azure username.
The machine will now be authenticated and signed into Azure. You can close your browser window.
After you close the browser session, you will see that the script will have proceeded to enroll the machine in Azure Arc. You should see the Successfully Onboarded Resource to Azure message. Note that the machine is assigned an Azure VM ID as well.
If you return to your Azure Arc dashboard displaying the enrolled machines, you should see the on-premises server appear as a resource.
The beauty of Azure Arc is that your on-premises server now "looks" and functions much like a native Azure resource. As you can see, there are various Azure functions that are now enabled for the server, such as:
- Activity log
- Access control (IAM)
- Update management
- Change tracking
- …and others
Note that Microsoft has not enabled many of the functions to be carried out using the Azure Arc portal. These functions will need to be performed using PowerShell or the Azure CLI.
Azure Arc is a great new tool and solution from Microsoft to help consolidate the many control planes that often exist when dealing with cloud, on-premises, and edge environments. Using Azure Arc will help to bring all these resources under one umbrella of control and automation tools.
Subscribe to 4sysops newsletter!
The onboarding process is simple enough. However, if you are onboarding more than a handful of VMs or other machines, the onboarding script does not scale very well. The service principal approach will be a better solution for onboarding a large number of resources.
Want to write for 4sysops? We are looking for new authors.
Great overview! Do you intend to do a follow-up blog on the Service Principal onboarding approach?