In the last post, I talked about some of the important networking customer use cases for applications on smaller Azure Stack HCI clusters and how we can satisfy those requirements. In this part, I will dive into the design, deployment and management for some of these network services.
Read the previous post here: Networking services for Azure Stack HCI 2-node clusters: Part 1
Infrastructure Requirements
Infrastructure requirements will vary based on the customer use case. Requirements for some of the common use cases for 2-node deployments are:
|
Customer Use case |
Infrastructure |
Footprint |
|
You can protect your VM workloads from external network threats, by restricting access from specific sources and/or specific applications (port/protocol) |
Network Controller (NC)
|
1 VM* for 2-node HCI clusters
|
|
You can protect your VM workloads from lateral threats by using microsegmentation to implement zero trust network access in your Azure Stack HCI cluster |
||
|
You can ensure fair network allocation on a HCI host, thereby preventing particular workload VMs from hogging the bandwidth of HCI host machines |
* - The VM must be configured on clustered storage as a highly available VM
High Level Design
As you can see, all the above use cases require deployment of Network Controller (NC) VM. Below is a high-level architecture diagram for a 2-node Azure Stack HCI cluster with the NC VM.
Planning
If you are deploying applications on traditional VLAN networks, you need to ensure that the NC VM has connectivity to the Hyper-v hosts over the Management network.
NOTE: If you are deploying applications on virtualized networks, you must additionally setup a Provider network which serves as the underlying physical network over which the virtualized network traffic communication takes place. This is described here: Plan a Software Defined Network infrastructure - Azure Stack HCI | Microsoft Docs.
Deployment
You can setup NC using Windows Admin Center or SDN Express scripts. NC deployment with Windows Admin Center is described here. Deployment through SDN Express script is explained here: Deploy an SDN infrastructure using SDN Express - Azure Stack HCI | Microsoft Docs.
- If you are deploying NC for apps on traditional VLAN networks, refer to sample config file: link
- If you are deploying NC for apps on virtualized networks, refer to this sample config file: link
NOTE: Today, the deployment UI and scripts do not configure the NC VM as highly available VM. We will fix this soon. You can do this manually by following the below steps:
- Ensure that you provide a clustered storage location for the NC VM location. This will ensure that the VM files and the VHDs are stored on cluster storage. For example: C:\ClusterStorage\Volume1\NetworkController. NOTE: Do not provide UNC path for Cluster Storage.
- Change the VM to a clustered VM by running the command:
Add-ClusterVirtualMachineRole “<NC VM name>” -Cluster “<HCI Cluster Name>”
Usage
Once the infrastructure is deployed, you can configure policies for the relevant use cases.
Network Security from external and lateral attacks
As a customer, the Security team has asked as an HCI administrator that you protect all East-West traffic and external traffic for an Edge deployment. Further, you have SCADA/Regulatory requirements that must be enforced for business practice.
With network security policies, you can protect every traffic flow in your HCI cluster, allowing only the flows required for your applications to function.
- The first step is to create a logical network for your workloads hosted on VLAN networks. This is documented here.
- Next, you need to create the security ACL rules that you want to apply to your workloads. This is documented here.
- Once the ACL rules have been created, you can apply them to the network or a network interface.
After the ACL rules have been applied to the network, all virtual machines in that network will get the policies and will have restricted access based on the rules. If the ACL rule has been applied to a network interface, the network interface will get the policies and will have restricted access based on the rules.
Fair network allocation for workload VMs
As a customer, the Database team is concerned that they may not be able to gain a fair amount of bandwidth for workloads. On the other side, the developer team is concerned that they will compete with database VMs residing within the same cluster.
With Quality-of-Service policies, you can prevent network intensive applications from hogging the entire bandwidth of your HCI cluster hosts. You can configure this through PowerShell, support through Windows Admin Center is coming soon.
Step 1: Configure global QoS settings.
You can perform the below steps on a Network Controller machine or a management client of Network Controller. This will enable the global setting to configure QoS policies through Network Controller.
$vswitchConfig=[Microsoft.Windows.NetworkController.VirtualSwitchManagerProperties]::new()
$qos=[Microsoft.Windows.NetworkController.VirtualSwitchQosSettings]::new()
$qos.EnableSoftwareReservations=$true
$vswitchConfig.QosSettings =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -Properties $vswitchConfig
//ConnectionUri is the REST uri of the Network Controller. Example: https://nc.contoso.com
Step 2: Configure QoS policies on a workload VM network interface.
First, you will need to identify the Network Interface where you want to apply the policy.
$NwInterface=Get-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId Vnet-VM2_Net_Adapter_0
//ConnectionUri is the REST uri of the Network Controller. Example: https://nc.contoso.com
Then, you can configure the inbound and/or outbound maximum throughput allowed on the network interface.
$NwInterface.Properties.PortSettings.QosSettings= [Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::new()
$NwInterface.Properties.PortSettings.QosSettings.InboundMaximumMbps ="20"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $NwInterface.ResourceId -Properties $NwInterface.Properties
In Closing
All the above scenarios are very relevant for smaller clusters but are applicable for larger clusters as well. Please try these out and give us feedback at sdn_feedback@microsoft.com. Don't hesitate to reach out for any questions as well.