The service that OpenContrail provides to virtual-machines is quite simple. I always find myself struggling trying to explain simple concepts. Please bear with me…
A virtual machine exists to run applications; the goal of an orchestration system such as OpenStack is enable application developers to deploy and manage application components in a self-serve manager. That means that the resources that a virtual machine provides (memory, cpu, storage and network) should be simple to understand to the application developer.
When it comes to storage, the answer is simple. A virtual-machine has access to block storage, object stores and distributed file-systems (e.g. NFS). When it comes to networking there are plenty of unnecessarily complex models behind proposed; networking doesn’t have to be complex.
From an application developer’s perspective, a network is a collection of devices that can communicate with each other; each device having an unique identifier (ideally an hostname). It is useful to be able to group some of these devices by their characteristics such as who is allowed to manage them and what their role is. We can call these groups “sub-networks”. In practical terms each of these sub-networks corresponds to an application tier.
Application stacks are made of several different components with different management characteristics. Typically the database layer is a centralized service serving multiple applications; an application may include multiple application servers, some specific to that user visible application; others following a SOA model. Each of these “subnets” contains the collection of virtual-machine that implement that service; and needs connectivity to all the other collections of devices that it needs to communicate with.
A virtual-network in OpenContrail models that “subnet”: it is an IP subnet plus a set of policy that determines the connectivity of that subnet. That is it.
In what way is this new ? For all the talk around Software Defined Networks, most people are still trying to model networks in terms of bridges and routers and other artifacts that irrelevant to the goal of providing connectivity to the application.
Taking a physical appliance and instantiating it as a virtual-machine doesn’t necessarily make the network simpler to manage. It may actually create additional issues, since now all these appliances have to be managed. These virtual appliances will have lower capacity than existing physical based ones; they will need to address issues such availability and reliability.
What OpenContrail does is use a Logical Model of the connectivity. With this logical model we create an implementation that provides connectivity to virtual-machines based only in the ingress and egress hypervisor software. On top of any IP capable physical network. It gets rid of routers and switches in the application network topology.
Both hardware and software are poor choices to define networks around. Networks are about connectivity.
With the OpenContrail vrouter as the hypervisor switch, a virtual-machine interface (e.g. the tap interface used by KVM) is associated with a isolated forwarding table (VRF). In the absence of any network policy configuration, this VRF contains host routes for all other virtual machines in the same virtual network. When network policies are configured the OpenContrail control-node automatically informs the vrouter of any virtual-machine host routes or external routes that this VRF has connectivity to. Network policy expresses connectivity and traffic filtering policies. For instance, it is trivial to create a policy such that only a specific TCP port is forwarded between two different virtual-networks. Traffic forwarding and policy enforcement is performed directly at the ingress hypervisor. There is no need to bounce the traffic to a “virtual router” VM that adds latency and management complexity.