A Typical Nerdio for Azure Deployment
Nerdio is designed to be safe and non-disruptive to existing environments. When you provision a new Nerdio account into Azure, it creates an empty resource group and only manages resources in that one resource group. You can have a single Azure AD tenant with a single Azure subscription and segregate customers by resource groups (or by Azure subscriptions or Azure AD tenants). The resources in each of these groups will be independent and isolated. Nerdio will manage the deployment in each unique resource group as its own Nerdio account.
Every Nerdio for Azure deployment is designed to start out as a “greenfield” deployment without any existing legacy information, other than connectivity to an existing Office 365 account. The goal is to enable an MSP to set up a greenfield Azure environment and conduct a pilot with a customer without disrupting the existing IT infrastructure. Once the pilot is successful, the Nerdio deployment is “plugged into” an existing IT environment and added to production, making it accessible to users. Once in production, users, data, and server workloads can be seamlessly moved into the new Nerdio deployment in Azure.
“Plugging” Nerdio Into an Existing IT Environment
There are three top-level steps involved in plugging a greenfield Nerdio deployment into an existing IT environment.
- Extend the network – this is typically accomplished by setting up a site-to-site VPN between the Nerdio for Azure environment and an existing environment. It is also possible to use the VNet peering capability of Azure in some cases, as we’ll see below.
- Extend Active Directory – Making the same Active Directory Domain Services available in Azure is fully automated by Nerdio with our Nerdio Hybrid AD™ functionality. Extending AD into Azure gives the Nerdio Admin Portal (NAP) visibility into the existing Active Directory, allowing it to manage user objects and assign virtual desktops without any changes to the existing environment. Once the AD is extended from the existing environment to Azure, it spans both locations and allows seamless movement of servers from one to the other.
- Move VM workloads – Once network connectivity is established and AD is extended into Azure, servers and data can be moved from the existing environment to Azure using Azure Site Recovery (ASR), another VM replication technology, or the Azure Resource Move process, as we’ll see below.
The result of the three steps above is a Nerdio-managed Azure environment with connectivity to an existing IT environment, AD visibility, and the ability to move VMs from one environment to the other without the need to re-join the domain or reconfigure the operating system.
In the following section, we’ll focus on extending the network into the new Nerdio deployment in Azure.
This is the most common method to connect the new Nerdio deployment to an existing environment. Azure offers a product called VPN Gateway, which can be used to connect an Azure virtual network to an on-premises environment. VPN Gateways support IKEv2 route-based and IKEv1 policy-based VPN connections and come in multiple flavors that determine the aggregate throughput of all VPN connections, the maximum number of site-to-site (S2S) VPN connections, and the cost of using a VPN gateway.
Under the hood, a VPN gateway is a virtual machine that’s managed by Microsoft, which provides VPN encryption capabilities. The larger the VM capacity, the more throughput the VPN Gateway can support and the more expensive it is.
The Basic VPN Gateway starts at $26 per month and can support 100mbps of bandwidth and up to 10 S2S tunnels. A static public IP address is required to be associated with the VPN Gateway and a special subnet called GatewaySubnet must be created in the Azure VNet for VPN to work. Once the VPN Gateway is provisioned (which takes about an hour), new VPN connections can be added, and connectivity will be established with on-premises firewalls. The Nerdio Admin Portal fully automates the creation of the VPN Gateway, public IP assignment, subnet, and VPN connections.
Once a VPN connection is established, network connectivity exists between an on-premises environment and the Azure VNet, with VMs inside. This is the first requirement for migrating Active Directory, data, and applications.
Azure VNet Peering
If the existing deployment being migrated to the Nerdio Azure deployment is already in Azure, it is still possible to use VPN Gateways and site-to-site VPN connections between these virtual networks. However, it is far easier to leverage Azure VNet peering capability.
Azure supports two types of VNet peering:
- VNet peering – connecting VNets within the same Azure region
- Global VNet peering – connecting VNets across Azure regions
There are multiple advantages to using VNet Peering instead of site-to-site VPN. Network traffic is private, low-latency, and high-bandwidth. That’s because it traverses Azure’s private network backbone instead of leveraging public internet infrastructure.
VNet peering has all the expected functionality, including no downtime for the VMs when creating the peering, the ability to apply Network Security Groups (NSG) to control traffic flow and access if needed, and by default, complete and simple connectivity of all resources in peered networks without additional setup.
There is a charge associated with using VNet peering. When data travels within the same Azure region (both inbound and outbound, unlike public internet bandwidth), there is a charge of $0.01/GB of transfer. To transfer a 100GB virtual disk from the existing virtual network in Azure to the Nerdio deployment will cost about $1. When peering VNets across Azure regions (Global VNet Peering), the cost is about $0.035/GB in most US regions.
The alternative to the public internet routed site-to-site VPN is Azure’s private connectivity called ExpressRoute. It is a private, point-to-point connection leased from an authorized carrier that connects an on-premises environment with an Azure deployment. ExpressRoute is a high-speed, low latency, private connection but it comes with an associated price tag. We rarely see ExpressRoute used by MSPs and as a result will not devote much attention to it here.