Emulating an Infrastructure with EASE

In the last decade we have observed a tremendous adoption of distributed applications and a trend to host services in private or public clouds. However, service providers still need to own an infrastructure to test their applications or services. A
similar problem is faced by network operators when they want to introduce a new service in their production network. It is very difficult to determine the behavior of a new application or service without deploying it in the production environment. Bugs or misconfiguration can cause service outage and trigger customer churn along with loss of reputation. There are several publicly available testbeds such as Emulab, GENI or OFELIA that allow users to lease physical and virtual resources for emulation.
However, these testbeds do not provide performance guarantee. Acquisition of physical instances provides performance guarantee and isolation, but compromises overall system utilization. On the other hand, acquisition of virtualized instances lack guarantee and isolation resulting in an unrealistic emulation outcome. To address these limitations, we propose EASE, a next generation multi-tenant infrastructure emulator with an aim to maximize hardware utilization while providing performance guarantee, isolation and full-fledged support for SDN and NFV.

Transcript

1. Emulating an Infrastructure with EASE Arup R. Roy Shihabur R. Chowdhury, Md. Faizul Bari, Reaz Ahmed, and Raouf Boutaba
2. EASE: Emulation as a Service • A multi-tenant, distributed and virtualized shared emulation platform with built-in SDN • EASE can can emulate infrastructures consisting of compute, network and storage resources • Evolution of our prior work DOT* to a cloud-based service. *A. R. Roy et al. “Design and Management of DOT: A Distributed OpenFlow Testbed”, IEEE/IFIP NOMS 2014 2
3. Why EASE? • Quickly deployable SDN emulators (e.g., Mininet) cannot scale to network size and traffic volume*. • Large-scale SDN emulators (e.g., DOT*, Maxinet**) require up-front investment and time consuming setup. • Shared testbeds (e.g., EmuLab) do not provide all the desired features *A. R. Roy et al. “Design and Management of DOT: A Distributed OpenFlow Testbed”, IEEE/IFIP NOMS 2014 ** P. Wette et al. “Maxinet: Distributed Emulation for Software-Defined Networks”, IFIP Networking 201 3
4. Desired Features of a Shared Testbed • Performance isolation between testbed users • Resource guarantee to support reproducible emulation • Fault-tolerance for seamlessly resuming emulations • Maximize underlying infrastructure utilization ◦ To support more users 4
5. A Case Study: EmuLab • Emulab is a shared emulation platform for network emulations. • We deployed Internet2 (12 nodes, 15 links) topology on Emulab. • We measured link utilization of a selected link. • We varied traffic on links other than the one we selected for measurement. 5
6. A Case Study: Emulab (contd…) • Emulab provides isolation between the users by hard-partitioning resources. ◦ This reduces the number of simultaneous users • No Resource Guarantee ◦ Limits experiment reproducibility • No Fault-tolerance 6
7. EASE: Challenges • How to guarantee resources (CPU, network bandwidth, storage) for reproducible experiments while maximizing the number of simultaneous users? ◦ We use time dilation • How to implement time dilation across all resources? • How to provide transparency to the users, i.e., hide distributed nature of deployment? • How to ensure fault-tolerance for seamless execution of emulations? 7
8. Challenge-1: Resource Guarantee while Maximizing No. of Users • Solution: Time Dilation • Time dilation slows down the progression of time • Time dilation can stretch the perceived limits of the infrastructure ◦ A link with 50Mbps remaining capacity can appear as 100Mbps if the speed of time progression is halved 8
9. Challenge-1: Resource Guarantee while Maximizing No. of Users (contd…) • Heuristic Algorithm for emulation provisioning ◦ Binary search on TDF to determine the minimum TDF that yields a feasible embedding. ◦ Emulation request is partitioned in clusters. ▪ Cluster of virtual switches are deployed in a single VM with the required resources. ◦ Each cluster is placed on a different machine. ◦ First-fit algorithm for embedding. 9
10. Challenge-1: Resource Guarantee while Maximizing No. of Users (contd…) 10
11. Challenge 2: Implementation of Time Dilation. • Modify timer management in each subsystem ◦ Compute, Network, Memory • We modified timer management in KVM hypervisor for Intel processors ◦ Intercept rdtsc instruction that reads time stamp counter register from CPU ◦ Modify time-stamp computation to slow down time 11
12. Challenge 2: Implementation of Time Dilation (contd…) • Timer management is architecture specific. • Non-uniform methods to dilate all resources. ◦ We place the switches inside dilated VMs to dilate switching. ◦ Still open problem to dilate memory access time • Time dilation synchronization across multiple machines. ◦ All resources deployed on different machines should be identically dilated. 12
13. Preliminary Performance Evaluation Requires further investigation 13
14. Conclusion • EASE is a proposal for a distributed testbed that provides emulation as a service to the users. • Full-fledged implementation of EASE is yet to be done. • We leverage time dilation to maximize the number of users admitted in the system. ◦ Some challenges pertaining to time dilation are still open. 14
15. Questions? 15