Supporting Clusters

In Windows Server 2016, you can add cluster nodes to clusters with Windows Server 2012 R2 without affecting the operation, making migration and collaboration with the Network Controller easier. As with the VMs, it is also the case here that the new functions in Hyper-V and for the Network Controller are only available if you have upgraded all cluster nodes to Windows Server 2016. To do this, you need to update the cluster configuration using the Update-ClusterFunctionalLevel command. However, this process is a one-way street, so there's no going back.

If you are running nodes in a cluster with Windows Server 2016 and Windows Server 2012 R2, you can easily move VMs between the nodes. In this case, however, you should only manage the cluster from servers with Windows Server 2016. You can also only configure the new version for VMs with

Update-VmConfigurationVersion VM

for the VMs in the cluster when you have updated the cluster to the new version. Only then will the cluster work optimally with the Network Controller.

With cluster Cloud Witness, you can also use VMs in Microsoft Azure as a witness server for clusters based on Windows Server 2016. This is an important point – especially for cross-data-center clusters. The VMs in the Azure cloud and the responsible networks can also be managed and monitored using the Network Controller. Thanks to cluster compute resiliency and cluster quarantine, cluster resources are no longer unnecessarily moved between nodes if a cluster node has problems. Nodes are moved to isolation if Windows detects that the node is no longer working stably. All resources are moved from the node, and the administrators are informed. The Network Controller also detects faulty physical and virtual networks in this context and intervenes accordingly. The VMs are moved via live migration, including the transfer of memory by Remote Direct Memory Access (RDMA) via different network adapters that are also pooled and jointly monitored by the Network Controller.

Important Communication Interfaces

The southbound API – the interface between the Network Controller and network devices – can automatically detect and connect network devices and their configuration in the network. This API also transfers its configuration changes to the devices. The API handles communication between the Network Controller, administrators, and, ultimately, devices and can also involve Hyper-V hosts.

In turn, the northbound API is the interface between administrators and the Network Controller. The Network Controller adopts your configuration settings via this API and displays the monitoring data. Moreover, the interface is used for troubleshooting network devices, connecting new devices, and other tasks. The northbound API is a REST API with a connection that works via a GUI, with PowerShell, and (of course) system management tools like System Center. The new 2016 version of System Center can be seamlessly connected to the Windows Server 2016 Network Controller in this area – mainly the SCVMM. Monitoring is also performed using System Center 2016 Operations Manager.

Automated Network Monitoring

Microsoft places great emphasis on network monitoring with the Network Controller. You therefore have a tool available for troubleshooting in the network. The Network Controller not only detects problems related to latency and package losses, it also keeps you informed about where these losses come from and which devices in the network are causing problems. This means you can automatically start troubleshooting measures, such as live migrations or scripts, as desired.

The Network Controller can also collect SNMP data in this context and identify the status of connections, restarts, and individual devices. This means you are in a position to group devices such as switches in a particular data center, whole server racks, data center, or other logical groupings and therefore quickly identify whether a switch failure will affect certain VMs.

Another feature of monitoring is detecting network overloads through certain services, servers, or VMs. If a specific server rack, for example, loses the connection to the network or can only communicate to a limited extent, the Network Controller marks all VMs that are on Hyper-V hosts in this rack as faulty, as well as the connected virtual switches. The controller therefore also detects connections in the network and can provide information about problems in a timely manner or even implement measures itself.