Who is Midokura?
Midokura is the maker of an automatable virtual networking system called MidoNet. The product generally goes under the moniker “MEM,” short for Midokura Enterprise MidoNet.
By “virtual network” here, we mean that MEM creates overlay networks on top of any IP fabric. MidoNet agents run on hypervisor hosts, tunneling traffic to one another. MEM architecture is notable in that forwarding intelligence is distributed across the installed agents. As a result, Midokura claims that scaling up MidoNet agents scales up virtual network capacity.
“The MidoNet agents are the distributed brains of your virtual network. This is a software agent which installs on every hypervisor host. The MidoNet agent is responsible for setting up new network flows and controlling and the kernel fastpath to provide distributed MidoNet networking services such as switching, routing, NAT, etc. Since the brains are located on every hypervisor host, as you scale out your environment, you scale out the capacity of your virtual network.”
An open source version of MEM called MidoNet Community Edition has been available since late 2014.
What did Midokura announce?
On February 2, 2016, Midokura announced the availability of MEM 5.0. The 5.0 release makes it easier for OpenStack operators to run their network in a few major ways.
1. The new MEM Insights tool allows operators to peer more deeply into their virtual networks. Virtual networks are often distanced from their physical underlays, making correlation between a problem and root cause difficult to nail down. MEM Insights starts to bridge this gap via…
- historical flow data per physical host and virtual router or bridge.
- usage monitoring per tenant.
- traffic counters per virtual object.
- port mirroring per ports, bridges, and routers.
2. Service chaining, the initial implementation of which works with the Intel Security Controller. The big idea here is to help mitigate east-west security issues, i.e. the problems happening inside the data center that can be hard to spot.
3. SPOF mitigation. MEM 5.0 includes network application fault-tolerance.
Do you need this product?
Midokura’s primary success has been with OpenStack operators servicing multi-tenant environments. Ergo, if you’re in a business that shares common IT resources among distinct users, groups, business units, or other customers who must all be isolated from one another, MEM might be interesting to you.
According to Midokura, they have had good success with web services companies, media companies, traditional enterprises with significant development environments, hosting providers running OpenStack, and managed service providers running private cloud.
Note that while the association between OpenStack and Midokura is a close one, OpenStack is not a requirement to use MEM. MEM is configurable via API, and could conceivably be integrated into any sort of network environment or compute orchestration system.
The view from the hot aisle.
By all accounts from every major OpenStack user I’ve spoken with, implementing OpenStack is difficult. For network architects, OpenStack networking is challenging, in the sense that the point of OpenStack is to automate the creation of compute environments. Networking and automation are not good friends as of yet. Network automation is a nascent discipline with the annoying problem of having to deal with legacy network devices designed in a bygone era while at the same time keeping up with the requirements of modern compute infrastructure.
I see Midokura’s MEM as one reasonable answer to the divide found between networking and automation. MEM functionality seems reasonable for the task of supporting multi-tenancy in OpenStack, while at the same time offering good connectivity back to the legacy network via gateway services. A MidoNet Gateway can act as a router speaking BGP, or as a bridge mapping 802.1q tags to logical networks.
I find MidoNet to be even more interesting in that their network state database is distributed across the agent and gateway infrastructure. While there is a central management for certain functions, network state does not reside centrally. This distributed architecture takes on a problem that academics are starting to grapple with now, as the inherent problems of centralized network state maintenance have been revealed in real-world usage of early SDN architectures.
For more information.
- MidoNet architecture. http://www.midokura.com/midonet-architecture-technology/
- Midokura Unveils Next-Generation Network Virtualization Solution. http://www.midokura.com/press-releases/midokura-unveils-next-generation-network-virtualization-solution/