Please enable JavaScript.
Coggle requires JavaScript to display documents.
Container and Microservices (Features (Networking should adapt to the…
Container and Microservices
Features
Services can be moved and
deployed everywhere in the DC
Networking should adapt to
the dynamic changes and
react appropriately
Networking functions are
implemented as software
running on commodity servers (NFV)
In order to apply these NFs to the
microservices we need to redirect
packets inside them
DCNs have large requirements in terms of performance, elasticity and fault tolerance that should be applied to the NFS as well
Small autonomous services that
work together
Networking requirements
Elasticity
Problems
Often, new instances of the same microservice can be instantiated to handle an overload condition. A NF should be if needed, replicated in different servers and able to handle the same packets of the "original" instance. Without disrupting the service
Related Papers
SplitMerge - System Support for Elastic Execution in Virtual Middleboxes
An orchestrator is responsible for coordinating load balancing by invoking a migrate operation that reroutes a specific flow and moves the corresponding NF state
OpenNF - Enabling Innovation in Network Function Control
A control application runs in the SDN controller and is in charge of coordinating the transfer of network and NFV state between NFs. In this specific case they use the OpenFlow protocol and the OpenNF [2] protocol.
Centrally Controlled Distributed VNF State Management
This work extends OpenNF with a Distributed State Transfer (peer-to-peer) to avoid passing state and data transfer to the controller, removing also the need for packet buffering on the controller.
Efficiently Migrating Stateful Middleboxes
U-HAUL - Efficient State Migration in NFV
Of course, this is valid also when an instance scale out. The NF should be turned off without losing its internal connections
#
Asymmetric and
Multi-path
routing
Problems
Different protocols (e.g. Multipath TCP, ECPM) allow exploiting different paths for the same flow, enabling a better resource utilization and load balancing. Different NFs (placed in different paths) should be able to handle the same flows.
Resiliency
Problems
Since failures happen frequently in a DC, when a NF fails, the existing mapping (internal state) is lost, causing a break into the existing connections
Related Papers
Stateless Network Functions: Breaking the tight coupling of state and processing
The idea is that each NF state (e.g. address mapping in a NAT, server mapping in a load balancer) is stored in a distributed DB. Each NF reads and writes into this DB before performing a decision
Pico Replication: A High Availability Framework for Middleboxes
The idea is to use a framework that is able to replicate the state of a middlebox between different replicas. In this way, upon a failure, the SDN network can be updated to forward traffic into the replicated middlebox.
The work is based on frequent checkpoints of the middlebox state (with a flow-level granularity) among replicas. However, since the output commit property, the output packets referring to a modified flows cannot be release since a checkpoint of that flow is made, hence causing additional latency and packet bursting
Rollback-Recovery for Middleboxes
The idea is to add log all inputs received by the middlebox so that can be replayed on the newly created once the system fails. However, in a multithreaded environment, logging all inputs is not enough since there are non-deterministic variables that impact the overall system state.
Given that, the proposed approach stores also additional information needed for correct replay in the face of non-determinism.
Since a packet (following the output commit property) cannot be released if the information needed to recreate internal state consistent with that output have been committed to stable storage, the work proposes an optimization on how the logged information can be retrieved, save and committed in order to reduce the final per-packet latency mainly for log free operations.
When a microservice fails it can be scheduled in a different machine, hence the NF should follow this changes, possibly without disrupting the existing connections
#