Service Abstraction and Communication Flows
3 min read
Previously we had talked about service-centric networking. Since then, we have now implemented a prototype experiment implementing the ideas from Serval that demonstrates ICMP ping migration involving the Linux iptables and Network Namespaces.
As a reminder of what we're dealing with, today's cloud infrastructure is increasingly viewing a group of machines as a "service" rather than just hosts connected to the internet.
Abstracting machines into services allows easier horizontal scaling as we can load balance between instances of those services. Doing this sort of abstraction requires a service name that is not associated to a particular machine. This name can be a "virtual" IP address. However, just because you can remap a name to point to a different concrete address, doesn't mean the endpoints on the 2 sides of the communication can continue the conversation transparently. Many communication protocols are not stateless. Therefore, remapping a virtual service name may involve complex state tracking and synchronisation.
Our experiment involves a network structure like below:
+----------------------------------------------------------------+
| |
| +-----+ +-----+ +-----+ +-----+ |
| |a.com| |b.com| |a.com| |c.com| |
| +--+--+ +--+--+ +--+--+ +--+--+ |
| | | | | |
| | | | | |
| +-----------+-----+-----+---------+ Host |
| | |
| | |
| +---------+---------+ |
| |orchestrator bridge| |
| +-------------------+ |
| |
+----------------------------------------------------------------+
Each domain listed above is just a human-readable name associated with an ICMP ping service running in their own network namespace. They are all connected to orchestrator via virtual ethernet. The orchestrator currently runs as a network bridge. The entire experiment is only within a Linux host.
We enter one of the network namespaces and initiate a ping operation to another service using an abstract service name ( represented as an IP address). Then inside the orchestrator, we stopped the receiving service, and started another service while preserving the same abstract service name. The servicing sending ICMP ping continued to work without any interruptions.
This experiment does not address zero-downtime migrations, it was only an exercise in using Linux OS tooling for preserving abstract service names between different services.
The experiment also raised issues such as having a NAT engine which is able to load balance as well (which iptables doesn't do) as well as further questions on whether DNS resolution is a suitable mechanism for flow establishment, naming of services and migration of communication state.
The experiment source can be found at: https://github.com/MatrixAI/Relay/tree/master/experiments/stateless_container_ping_migrations