In this topic,  I will address the following resources in Azure Resource Manager (ARM):

• Azure VMs
• Availability Sets
• Load-Balancers

Lab overview for Highly Available IaaS 3-tier service

N.B: In this topic, I use PowerShell cmdlets to manage Azure resources. You can have further information here.

The goal of this lab regards the deployment of a 3-tier service:

• First tier: Web Servers
• Second tier: Application Servers
• Third tier: Database Servers

The user will connect to the Web Servers load-balancer. Then the Web Servers will connect to the application servers across the application load-balancer. Then Application servers will send a request to SQL Servers. The availability Set will be configured on each server role to support the 99,95% SLA.

Regarding the network, the virtual network is split into two subnets called external and internal subnet. All VMs are stored in the same storage account.

I have created the resource groups, the storage account and the virtual network. It only remains to create availability set, Azure VMs and load-balancer.

Availability Set

Usually to support High Availability, we use two servers that host the same role or/and application. Then these servers are spread across several racks, rooms or hypervisors (in case of VMs). In this way, even if an outage occurs, the others servers continue to deliver the service. In Azure, we use the Availability Set to spread in the datacenter, the Azure VMs which deliver the same service.

With Availability Set comes two concepts:

• Fault Domain: this is a physical unit for the deployment of an application. Thanks to fault domain, VMs are deployed on different servers, racks and switches to avoid a single point of failure.
• Update Domain: this is a logical unit for the deployment of an application. Servers which are associated with the same availability set will be arranged in the rack. In this way, one update domain will be unavailable at the same time when Microsoft makes an update. So servers in the remaining update domains continue to deliver the service.

To support the 99,95% SLA, I will create an availability set for each tier. To create the Availability Set from the portal, go to the Marketplace and select Availability Set. You can then specify the availability set name, the number of fault and update domains and the resource group.

You can do the same thing with PowerShell.

New-AzureRmAvailabilitySet -ResourceGroupName LabHAIaaS -Name AppTier -Location "West Europe" -PlatformUpdateDomainCount 2 -PlatformFaultDomainCount 2

Once I have created availability sets, I have three new resources in the resource group:

Azure VMs creation

N.B: At this moment, you can’t associate availability set to a VM already created (in Azure Resource Manager) from PowerShell or from the portal.

Now I will create Azure VMs with the availability set association. You can create it by using the portal:

Below you can find PowerShell cmdlets to create an external virtual machine: (the public IP is needed to connect to VMs from the portal. If you have a Site-to-Site VPN, you shouldn’t need the public IP)

# Set values for existing resource group and storage account names
$rgName="LabHAIaaS"
$locName="West Europe"
$saName="labhaiaasvm"
$AVName = "WebTier"
# Ask for VM credential
$cred=Get-Credential -Message "Type the name and password of the local administrator account."

# Set the existing virtual network and subnet index
$vnetName="LabHAIaasNetwork"
$subnetIndex=1
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName

# Create the NIC.
$nicName="ExtVM06-NIC"
$pip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id

#Availabiloty Set
$AvID = (Get-AzureRmAvailabilitySet -ResourceGroupName $RGName -Name $AvName).id

# Specify the name, size, and existing availability set
$vmName="ExtVM06"
$vmSize="Standard_A0"
$vm=New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $AvID

# Specify the image and local administrator account, and then add the NIC
$pubName="MicrosoftWindowsServer"
$offerName="WindowsServer"
$skuName="2012-R2-Datacenter"
$vm=Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
$vm=Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

# Specify the OS disk name and create the VM
$diskName="OSDisk"
$storageAcc=Get-AzureRmStorageAccount -ResourceGroupName $rgName -Name $saName
$osDiskUri=$storageAcc.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $diskName + ".vhd"
$vm=Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm

Once all Azure VMs are created, I have 6 VMs in the resource group with their own network interfaces.

In the below example, you can see that Azure VMs that belong to the WebTier availability set are spread between two fault and update domains.

Implement the external load-balancer

Now that Azure VMs are created and are in availability sets, we can create the Load-Balancer. First, I create the external Load-Balancer for the Web servers (WebTier). Open the marketplace and type Load-Balancer. Then create it and chose the Public scheme. Create a public static IP as below and select the resource group.

Once the load-balancer is created, open settings and select Backend Pools.

Then create a backend address pool, and choose the WebTier availability Set and the Azure VMs as below.

Now you can create a probe to verify the health of your application. In the below example I create a probe for a web service which listens on HTTP/80.

Once the probe is created, we can create a load-balancing rule related to the probe health. If a server is not healthy, the load-balancer will not route traffic to this server.

Implement internal Load Balancer

As the external Load-Balancer, create again a load-balancer but this time select the Internal scheme. Then select the virtual network and the internal subnet (where are the application servers). To finish, select the resource group and set a static IP address.

Next, open the settings of this load-balancer and select Backend Pools.

Then create a backend pool and select the AppTier availability set and its Azure VMs.

Then I create a probe to verify the health of the application on port TCP/1234.

To finish, I create the load-balacing rule based on the previous probe to route the traffic to healthy servers.

The post Deploy highly available IaaS service in Azure Resource Manager appeared first on Tech-Coffee.

In this topic, I’ll talk about Azure IaaS and how to deploy a first virtual machine in ARM from scratch. I’ll show you how to deploy resources by using GUI or PowerShell. Covered features will be:

• Resource group
• Storage account
• Virtual Network
• Azure VMs

Install Azure RM PowerShell module

To install the PowerShell module and to manage resource by using ARM, you have to download and install the module. By using PowerShell v5, you can run the below commands:

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM
Install-AzureRM
# Import AzureRM modules for the given version manifest in the AzureRM module
Import-AzureRM

Logon to Azure Portal and select the subscription

To logon to the Azure Portal by using the web browser, you can browse to https://portal.azure.com. By using PowerShell, you can run the below command:

Add-AzureRMAccount

If like me, you have multiple subscriptions associated to your tenant, you have to select the right one. If you use the web browser, you can select the subscription by clicking on your name on top right.

In PowerShell, you have to use this cmdlet:

Select-AzureRMSubscription

But before running this command you need to get the subscription id by using Get-AzureRMSubscription:

Once you have the subscription ID you can use the Select-AzureRMSubscription as below:

Create the resource group

All resources that I will create will belong to the same resource group. This resource group will contain the storage account, the virtual network and the Azure VMs (and its NICs).

To create the resource group by using the GUI, click on resource groups and select add. Then give a name to your resource group and chose the location.

By using PowerShell, you have just to run the below command:

New-AzureRmResourceGroup -Name MyRG -Location "West Europe"

Now I have my resource group which is ready.

Create the storage account

To have more information about how works storage account, you can read this topic.

To create a Storage Account by using the GUI, just select new Data + Storage and select Storage account.

Then give a name (lower case, no special char) to your storage account and choose the storage account type. Then select the resource group that you have previously created.

To create the same storage account by using PowerShell, you can run the below command:

New-AzureRmStorageAccount -ResourceGroupName MyRG `
                          -Name stoaccountlab `
                          -Type Standard_LRS `
                          -Location "West Europe"

Then your storage account is created:

Create the virtual network

The virtual network is required to connect Azure VM to the network. The virtual network is an address space (as 10.0.0.0/8) that have to be split in the subnet. Then Azure VM will belong to a subnet.

To create the virtual network, just click on New, Networking, Virtual Network and create.

Then give a name to the virtual network, specify the address space, the subnet name and its address range. Select the resource group that you have previously created and select the location.

New-AzureRmVirtualNetwork -Name MyNetwork -ResourceGroupName MyRG -Location "West Europe" -AddressPrefix 192.168.0.0/16
$VirtualNetwork = Get-AzureRmVirtualNetwork -Name MyNetwork -ResourceGroupName MyRG
Add-AzureRmVirtualNetworkSubnetConfig -Name Internal -VirtualNetwork $VirtualNetwork -AddressPrefix 192.168.0.0/24
Set-AzureRmVirtualNetwork -VirtualNetwork $VirtualNetwork

You can see the subnets in the virtual network, you can click on settings and select subnets. You can add more subnets by clicking on Add.

Create the Azure VM in Resource Manager

In this example I will create a Windows Server 2012R2 Azure VM. Its virtual disk will be stored in the storage account that we have created and connected in the above subnet. To create the VM, just click on New, Compute and select the Windows Server 2012 R2 Datacenter image.

Then specify the basic settings of the VM as its name, a username and password. Specify also the resource group that we have created previously.

Next chose the size of the VM and click ok.

To finish, specify the storage account, the virtual network and the subnet. The public IP is required if you need to access to your VM from an IP address. The network security group enable you to deploy filter as a firewall.

Once you have finished to set your VM, you can jump to summary section and click on OK to launch the VM creation.

You can do the same thing by using PowerShell but it is a little bit more complex than previous PowerShell operations.

# Set values for existing resource group and storage account names
$rgName="MyRG"
$locName="West Europe"
$saName="stoaccountlab"
# Ask for VM credential
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
# Set the existing virtual network and subnet index
$vnetName="MyNetwork"
$subnetIndex=0
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName

# Create the NIC.
$nicName="VM01-NIC"
$pip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id

# Specify the name, size, and existing availability set
$vmName="VM01"
$vmSize="Basic_A1"
$vm=New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize

# Specify the image and local administrator account, and then add the NIC
$pubName="MicrosoftWindowsServer"
$offerName="WindowsServer"
$skuName="2012-R2-Datacenter"
$vm=Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
$vm=Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

# Specify the OS disk name and create the VM
$diskName="OSDisk"
$storageAcc=Get-AzureRmStorageAccount -ResourceGroupName $rgName -Name $saName
$osDiskUri=$storageAcc.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $diskName + ".vhd"
$vm=Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm

Once the script has run, the VM is created with a public IP and a private IP. This VM belongs to MyRG resource group.

And as you can see, all resources that I have created previously are in MyRG resource group.

Conclusion

I think the new Azure deployment model is more flexible than the old. First, Cloud Services are not required anymore for IaaS and it is a great thing. Secondly the resource group are great to manage the lifecycle of an application because you can update resources without impact on other application in others resource groups. Thirdly you can use a JSON to deploy consistently on AzureStack and Microsoft Azure. To finish, cmdlets are the same than the old deployment model except that the commands contain RM (ex: Get-AzureRMVM). So why not move to the new deployment model? J

The post Getting started with Azure IaaS in Resource Manager appeared first on Tech-Coffee.

Requirements

To follow this topic you need:

• A working Virtual Machine Manager with at least Update Rollup 6;
• An Azure Subscription.

Moreover Azure VM created from the Azure Resource Manager are currently not manageable from VMM.

Create and import in Azure a management certificate

Create from an enterprise PKI

First, you need to create a management certificate. You can use your enterprise Public Key Infrastructure to make a certificate. This certificate must be in the personal user store as below.

Next, export this certificate as CER.

Create from MakeCert

The other method consists of using MakeCert from visual studio to create a self-signed certificate (for further information read this topic):

makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"

Once the certificate is generated, you can find it in your personal certificate store.

Import the management certificate in Azure

Now that your CER file is generated, you can navigate to the Azure Portal and select Settings. Click on Management certificates and choose Upload a Management Certificate.

Next, select your CER file and click on OK.

After a couple of minutes, you should see the certificate as below.

Add the Azure Subscription to Virtual Machine Manager

First you need your Subscription ID. You can use the Add-AzureAccount cmdlet as below.

Next, open your Virtual Machine Manager console and select Add Subscription as below:

Then specify a Display Name and your Subscription ID. To finish, select the certificate (you can compare the thumbprint with the CER previously imported in Azure).

After the initial synchronization (it can take few minutes), you should see your Azure VM as below.

It’s a great feature but …

Thanks to this feature you can see and manage the power of your VM. You can also connect to your Azure VM by using RDP from VMM console.

But I think this feature is not finished. For example only Azure VM created from the Azure Portal are visible from VMM console. The Azure VM created from Azure Resource Manager are not manageable from VMM. For example, below I have some resources created from an Azure Resource Manager Template (JSON file):

The Azure VM circled in red are VM created from Azure Resource Manager. If you compare the two last screenshots, you can see that VM circled in red are not manageable from VMM.

Next I think that not enough actions are possible from VMM to manage Azure VM. For example I would like to manage the size of the VM, the availability set or the VM creation. But it is not yet possibleJ.

However the Azure VM management from VMM has been released in the last Update Rollup (UR6). I trust the team responsible for VMM to improve this feature J.

The post Manage Azure VM from Virtual Machine Manager 2012 R2 appeared first on Tech-Coffee.

What is a generalized image

A generalized image is a capture of an already installed Operating System without the machine specific settings and without user’s settings. For example the machine name, its SID, the administrator password and so on are not retained when capturing the image. That enables to customize your own image before deploying it in large scale. You can for example, install IIS role in the image before capturing it. In this way, each server deployed by using this image will have IIS pre-installed. And each server deployed with this generalized image will have its own server name, SID and so on.

To create a generalized image of a Windows Server, you have to use Sysprep. For a Linux machine you can use WAAgent (Windows Azure Agent).

When you use Sysprep, you have to specify the above settings to create your generalized image. For more information to create a generalized image, you can read this topic.

Upload you own generalized image to Azure

N.B: To follow this guide, the Azure PowerShell module must be installed and the settings profile must be imported. For further information, please read this topic.

Once you have created your generalized image in your Datacenter, you can upload it to Azure. Be careful because currently Azure supports only VHD files. If you have created a VHDX, you can convert the VHDX to VHD by using the Hyper-V GUI or convert-VHD PowerShell cmdlet. To convert a VHDX to VHD, the disk must not be used by a running Virtual Machine.

Once you have your Generalized Image in VHD format, open PowerShell. The cmdlet Add-AzureVHD enables you to upload a local VHD to a Page Blob storage. For further information about blob storage, you can read this topic.

I have uploaded a VHD file to Azure by using my home internet provider with an awesome 70KB/s… And 5 days after, my VHD was stored in Azure J.

So the next step is the creation of the VM image from the VHD previously uploaded in Azure. I open again PowerShell to run the Add-AzureVMImage cmdlet.

Once the VMImage is created I can deploy a Virtual Machine from this image. So I open the Azure Portal and I select new virtual machine. Then I select My Image as below.

I select W2012R2-Datacenter-1.4 VM Image and I click on next. Then I configure my VM as usually.

When you have finished to create the virtual machine, the provisioning should start by using your generalized image J.

Create a generalized image from Azure

To create a generalized image from Azure, first you have to create an Azure VM. When the VM is deployed you can make any customization. On my side I have installed the IIS role. Next run the Sysprep utility as below:

Once the Azure VM is shutdown, you can click on Capture as below.

Next give a name and a description to your image, and don’t forget to check the box I have run Sysprep on the Virtual Machine. When the capture process will be finished, the source Azure VM will be deleted.

Next you can check in Images tab that your new VM image is available as below.

Now you can create an Azure VM from My Image repository and you can select your new imageJ.

Conclusion

In this topic we have seen how to upload an existing generalized image to Azure and how to capture a generalized image from an Azure VM. Thanks to these images, it is possible to deploy a large amount of Azure VM with consistent base installation.

The post Deploy Azure VM from a generalized image appeared first on Tech-Coffee.

Storage account

To use the Microsoft Azure storage solution, it’s necessary to create a Storage Account. This storage account gives you a single namespace where only you (by default) can have access. Each Storage Account handles up to 20.000 IOPS, and 500TB of data. If you use this storage account for Standard Virtual Machines, you can store until 40 virtual disks (a disk from a standard virtual machine provides 500 IOPS).

To authenticate on the Microsoft Azure Storage, the Storage Account comes with two keys, called the primary key and the secondary key. Each key can be regenerated when you want. Two key are provided to ease the key regeneration process. For example, if an application uses the primary key to access to the storage, you can:

1. Regenerate the secondary key ;
2. Modify the application to use the secondary key;
3. Regenerate the primary key.

Moreover, if you want to give temporary administrator right to someone, you can give him the secondary key and regenerate it 24h after if you want.

When you create a storage account, several REST endpoints are created to manage the contents of your storage:

• Blob endpoint: https://<Storage Account Name>.blob.core.windows.net
• Queue endpoint: https://<Storage Account Name>.queue.core.windows.net
• Table endpoint: https://<Storage Account Name>.table.core.windows.net
• File endpoint (preview): https://<Storage Account Name>.file.core.windows.net

The Azure Blob (Binary Large OBject) storage enables to store files as docx, pdf, vhd and so on. There are two blob types called page blobs and block blobs. I’ll talk longer about the differences of these two kind of types after. The Queue storage is useful for messaging and communication between Cloud Services Components. The Table storage is used for NoSQL structured datasets. To finish, the File storage provides SMB 2.1 shares that can be managed from Windows Explorer for example. SMB 2.1 has been chosen for compatibility reason with Linux. This feature is still in Preview.

In the next section, I’ll talk only about blob storage because Virtual Disks are stored in the blob storageJ.

BLOB Storage

Entities and Hierarchy

First it’s important to understand the entities which play a role in blob storage:

• Storage Account: this is the root of the hierarchy,
• Container: you can compare container to a folder. You can manage access right from this entity,
• Blob: this is the binary you want to store (docx, pdf, vhd and so on),
• Metadata: you can associate your own metadata to a blob.

Block and Page blobs

Before I have told there are two kinds of blobs: the Block blob and the Page blob. So it’s time to explain that :):

• The page blob is designed for IaaS usage as Virtual Machine disks. The maximum size for a page blob is exactly 1023GB;
• The block blob is mostly used to store data as documents, photos, videos, backups and so on. The maximum size for a block blob is 200GB.

Access right management

By default, blobs in a container are not accessible anonymously. However you can change this behavior by changing the access type. There is three access types:

• Private (Off): No Anonymous Access;
• Blob: Access blobs via anonymous requests;
• Container: List and access blobs via anonymous requests.

When you want to give access to a container or a blob to someone for a specific period of time and with specific permissions you can use Shared Access Signatures.

Replication

Your data are replicated to avoid to lose them. Currently there are four replication options:

• Locally redundant storage (Standard_LRS): the data is replicated synchronously three times in a single datacenter;
• Zone redundant storage (Standard ZRS): this replication option is only available for block blobs. Three copies of data are made on multiple datacenter;
• Geographically redundant storage (Standard_GRS): the data is replicated synchronously three times in a single datacenter and three others asynchronously copy in a second datacenter;
• Read-Access geographically redundant storage (Standard_RAGRS): same things as Standard_GRS and you can have a read access to the data in the second datacenter.

Manage Blob Storage

Create a Storage Account

To create an Azure Storage Account, you can use the PowerShell cmdlet New-AzureStorageAccount:

New-AzureStorageAccount -StorageAccountName "techcoffee01" `
                        -label "techcoffee01" `
                        -description "Storage Account to store Virtual Machines" `
                        -Location "West Europe" `
                        -Type "Standard_LRS"

The StorageAccountName parameter enables you to give a name to your Storage Account. Next provides the datacenter where you want to create this storage account by using location parameter. To finish choose a replication option with Type argument. Below this is a screenshot of a successfully Azure Account Storage creation.

Next if I open the Azure Portal, I can retrieve my new Azure Storage Account information as endpoints, location or replication option.

You can also retrieve these information by using Get-AzureStorageAccount cmdlet PowerShell.

Create Azure Storage Context

Before being able to manage containers and blobs, you have to create an Azure Storage Context. First you have to get the primary or the secondary key of your Storage Account by using the command Get-AzureStorageKey.

You can see in the above screenshot the primary and the secondary key. Now we can use the cmdlet New-AzureStorageContext to create the context as below:

New-AzureStorageContext -StorageAccountName techcoffee01 `
                        -StorageAccountKey $Key.Primary

In the next part I’ll use the $ctx variable when the context is required.

Manage containers

To create a container, you can use the New-AzureStorageContainer as below:

Be careful because the container name must be a valid DNS name as MSDN says:

• Container names must start with a letter or number, and can contain only letters, numbers, and the dash (-) character.
• Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names.
• All letters in a container name must be lowercase.
• Container names must be from 3 through 63 characters long.

You can list the container from PowerShell by using the cmdlet Get-AzureStorageContainer:

Moreover you can manage your containers from the Azure Portal:

To finish, you can modify the permissions associated to the container by using Set-AzureStorageContainerACL. Bellow I modify the permission of the oldvhds container to blob:

To finish you can delete easily the container by using the cmdlet Remove-AzureStorageContainer:

Upload a VHD

If you want to upload a VHD to create your own image to deploy Virtual Machines, you can use the cmdlet Add-AzureVHD cmdlet:

Delete Storage Account

To delete the storage account you can use the cmdlet Remove-AzureStorageAccount as below:

The result is the same from the Azure Portal:

Conclusion

The Microsoft Azure Storage is a feature that enables you to store binaries, backups, shares and so on. To have your own storage namespace, you have to create a storage account. Each storage account  handles up to 20.000 IOPS and 500TB of data. When Virtual Machines are created in Azure, the VHD files are stored in a page blob storage. You can manage your blob storage easily by using PowerShell cmdlets. You can have the list of PowerShell cmdlet related to Azure Storage with this cmdlet: get-command *AzureStorage*.

The post Understand Microsoft Azure Storage for Virtual Machines appeared first on Tech-Coffee.

Because Windows Azure Pack is multi-tenants and enables customers to manage their own resources in their clouds, Hyper-V Network Virtualization (HNV) is more interesting than VM networks based on VLAN and his limitations.

More precisely VLAN technology is based on 802.1Q standard that says that each Ethernet frame can be tagged with a maximum of 12bits (0 to 4095 in decimal). So if you use VLAN technology for your multi-tenants infrastructure, only 4096 isolated subnets can be created. To finish, VLAN technology needs a specific configuration on network devices (logical and physical switches and routers).

Network virtualization enables to isolate subnets without using tags and so without network devices configuration. But how it is work?

Hyper-V Network Virtualization

In HNV there are two types of IP addresses:

• Provider Addresses (PA): These IP addresses are used by virtual machines when the traffic is encapsulated on the provider network;
• Customer Addresses (CA): These IP addresses are set in Guest OS of VM so that they communicate together is the same subnet.

For example, the VM with the CA 192.168.1.3 wants to communicate with the VM with the CA 192.168.1.4 (in the blue subnet). So the packets are encapsulated and use provider addresses as source and destination addresses. In the encapsulate packets there are the subnet identifier (VSID: Virtual Subnet IDentifier), the mac and customer addresses of VM. In this example, all VMs belong to the same VM Network (192.168.1.0/24) but are isolated in two different subnets (the red and the blue). This allows to use the same address space in each subnet without IP address conflict.

NVGRE Gateway

In the above example, VMs can only communicate with VMs in the same subnet. But usually VMs have to communicate with the physical network to deliver the service. For that a NVGRE (Network Virtualization GRE) gateway has to be deployed. This can be a network device as F5 or a VM with the Remote and Routing Access Service (RRAS). If you choose the VM option, a Hyper-V host has to be dedicated to host the RRAS virtual machines. This part will be approached in a future article.

VM networks in Windows Azure Pack

/!\ In this topic I’m not installing a NVGRE gateway.

Of course it is possible to use a VM network based on VLAN in Windows Azure Pack. This can be done when configuring VM Clouds service in Plans:

But to avoid using VLAN and to let tenants manage their own network subnets, I use HNV. Because Windows Azure Pack relies on System Center Virtual Machine Manager, it is necessary to configure the VMM fabric first. My screenshots are taken from my test lab configuration that contains only one Hyper-V host. This is why I have not a Live Migration or a Hyper-V Replica network.

Provider Network creation

In your fabric, navigate to Logical Network and create one. First we create the PA Network. For that select One connected
network and check the box Allow new VM Networks created on this logical network to use network virtualization.

Next specify your network site. My PA network address space is 10.10.10.0/24.

Once your logical network is created, create a static IP Pool:

So on my test lab I have these logical networks:

• Cloud Management: logical network for hyper-V management NIC
• Cloud PA Network: Logical network for HNV
• Virtual Machines: logical network for my infrastructure virtual machines.

Port profile

Now that logical networks and IP pools are created, we have to add a Virtual Port Profile (VPP) for the Cloud PA Network. A VPP describes features enabled on vNIC and the QoS.

Once the VPP is created, you can add a port classification.

Now we have to create an Uplink Port Profile (UPP). This port profile describes the load balancing and the teaming algorithm. This profile describes also network sites that it supports.

Logical switch

Next we have to configure the logical switch. Give a name to your logical switch and click next.

Select virtual switch extension that you need. Usually the configuration is the same as below:

Specify the uplink port profile that is “connected” to your logical switch.

To finish, add virtual port profiles that will be used by VM or hyper-V host.

Hyper-V host configuration

Now that the network fabric is set, open the properties of your Hyper-V hosts. Navigate to Virtual Switches. Create a New Logical Switch and add some vNIC as below configuration:

Do not add a vNIC connected to your PA Network. Navigate to hardware and verify that all logical networks are available on your Network adapters:

Add virtual network from Windows Azure Pack

Now that Hyper-V hosts are configured, it is necessary to add the PA network in your VMM cloud:

This cloud must be part of a hosting plan in the Windows Azure Pack and a user have to subscribe to this hosting plan. When it is done, you can connect to your tenant Self-Portal and select New > Virtual
Network:

Once it is created you should see it in Networks windows:

In VMM you should have a new VM networks related to your configuration. The static IP Pool is also created.

Checking

When creating a Virtual Machine from Windows Azure Pack, you should be able to use the VM Network that you have created before:

While my VM is creating, I’m connecting to my Hyper-V host to obtain my Provider IP Address. For that I run Get-NetVirtualizationProviderAddress:

The IP Address of my Hyper-V host on Provider Network is 10.10.10.9. Once the VM is created and started, I run the command Get-NetVirtualizationLookupRecord:

This command shows me two objects. The first contains information about the Gateway while the second is related to my VM called VMTEST01. Before, in Hyper-V network virtualization part, I have talked about the VSID (Virtual Subnet ID). Thanks to the previous command I know that the VSID of this subnet is 16412478.

In this configuration, it is just missing the NVGRE gateway in order to VMTEST01 can communicate with the physical network. Maybe I will work on it on a next topic J (I need a new small Hyper-V host to dedicate the gateway role).

The post Windows Azure Pack – Manage VM Networks appeared first on Tech-Coffee.