Figure 3.33 The three planes that enable network virtualization for HNVv2
Network Controller
The network controller was taken directly from Azure and uses the same codebase as
the Azure implementation. It is a new role in Windows Server 2016. As the brain of
SDNv2, it is responsible for relaying the configuration request from the management
tools to the Hyper-V hosts in addition to tracking and distributing the CA-to-PA
mappings for all of the required hosts.
It has a Northbound and a Southbound API. The Northbound API, which extends
upward to the management plane, is used to communicate with the management tools
from which it receives the configurations, such as required virtual networks, ACLs,
QoS, and so on. The Northbound API is implemented as a REST interface, which
means that it can easily be communicated to any management platform that supports
REST. However, the primary management tools are those already mentioned:
PowerShell, Azure Stack (which uses REST), and SCVMM.
The network controller then uses its Southbound API to communicate the policies
that make up the various flow tables in the VFP and more to the Hyper-V hosts, to
enable network virtualization to work. The Southbound API is also used to discover
information about network devices, service configurations, and other assets.
You typically have multiple Network Controllers, because of their criticality. This is
enabled through a component called Service Fabric, a clustering technology that
started life in Azure (although it is completely separate from the Failover Clustering
feature in Windows Server). Service Fabric enables multiple instances of a service to
operate and to synchronously exchange state information, removing the need for any
shared or common storage because each instance has a complete copy of the data.
This model provides great scalability and fast failover in the event of a problem. One
instance is the primary controller, and one or more secondary controllers