Testing ARES on the GTS framework: lesson learned and open issues. Mauro Femminella University of Perugia

Size: px

Start display at page:

Download "Testing ARES on the GTS framework: lesson learned and open issues. Mauro Femminella University of Perugia mauro.femminella@unipg."

Molly Cross
8 years ago
Views:

1 Testing ARES on the GTS framework: lesson learned and open issues Mauro Femminella University of Perugia

2 Outline What is ARES What testing on GTS? Our solution Performance evaluation Conclusion and open issues

3 ARES: Advanced networking for the EU genomic Research Genomic processing is expected to become more demanding than top three applicative domains (YouTube, Twitter, astronomy)*: data acquisition, storage, distribution, and analysis ARES is a networking & computing overlay to efficiently process genomic data sets, consisting of Routers Tenant in data centers *Stephens ZD et al., "Big Data: Astronomical or Genomical?", PLoS Biol, 13(7): e doi: /journal.pbio

a networking & computing overlay to efficiently process genomic data sets, consisting of Routers Tenant in data centers

4 System functional architecture Processing of genomic data done in virtual machines (VMs) in cloud data-centers Genomic pipelines VM File distribution assisted by caches Distributed NFV paradigm Deployed in routers and VM in data centers Processing request managed via easy-to-use web interface Central manager for service orchestration (genomic computing manager, GCM)

NFV paradigm Deployed in routers and VM in data centers Processing request managed via

5 The big picture (1/2) Overall service framework is composed of: An IaaS infrastructure to handle the computing in data centers A SaaS model to interact with the end users (biologists/doctors) An NFV-based content caching distribution to mitigate the impact of huge content transfers on the network

interact with the end users (biologists/doctors) An NFV-based content

6 The big picture (2/2) Service orchestration NFV

7 Involved technologies (1/2) IaaS: OpenStack as cloud management system KVM as hypervisor SaaS: Web interface to interact with users NFV Caching function Service virtualization platform: NetServ* Deployable in VM, also working with SDN *M Femminella, R Francescangeli, G Reali, JW Lee, H Schulzrinne, An Enabling Platform for Autonomic Management of the Future Internet, IEEE Network Magazine 25 (6), 24-32

Deployable in VM, also working with SDN *M Femminella, R Francescangeli, G Reali, JW Lee, H

8 Involved technologies (2/2) An orchestration engine (GCM) in Java Able to drive tenants operations interacting with locally deployed plug-in in data centers A novel signaling solution: off-path signaling protocol (OSP) able to find resources on the overlay

deployed plug-in in data centers A novel signaling solution:

9 High level signaling GCM

10 Physical Géant topology

11 Logical overlay topology DE1 DE1 DK DK NL NL PL PL CZ CZ IL IL CH CH LU LU DE2 DE2 BE BE UK UK IS IS IE IE FR1 FR1 PT PT FR2 FR2 AT AT GR GR LT LT LV LV EE EE ES ES IT IT SK SK PoP Data center Users in NRENs

12 What to test with GTS? (1/3) Our dream Implementing in a number of Géant PoPs (in GTS) a full fledged version of ARES A VM for each router At least 2 CPU cores (4 is better) not overbooked, 8 GB RAM, 120 GB of storage An OpenStack tenant for each datacenter Access to physical servers A new testing model (tenant-as-a-service) A set of VMs with many CPU cores (>8), GB of RAM (at least 64 GB), and storage (at least 400 GB) for running a virtualized OpenStack deployment virtualization inside virtualization is the evil Real users requesting processing of genomic data sets Not possible, too many resources!

not overbooked, 8 GB RAM, 120 GB of storage An OpenStack tenant for each datacenter Access to physical servers A new testing model

13 What to test with GTS? (2/3) Our desire Implementing the whole network in GTS, emulating the genomic processing but testing real data transfer Running a number of tests to characterize CPU, RAM, and storage requirements of a pipeline VM in our lab Done! Topology consisting of Routers with cache modules At least 2 CPU cores (not overbooked, better 4), 8GB of RAM, 120 GB of storage VMs with cache and management modules At least 2 CPU cores (not overbooked, better 4), 8GB of RAM, 120 GB of storage VM to emulate users sending processing requests Standard GTS VM is enough Still not possible, too many resources!

characterize CPU, RAM, and storage requirements of a pipeline VM in our lab Done!

14 What to test with GTS? (3/3) Backup Implementing the testbed topology Routers: 1 standard GTS VM Datacenter: 1 standard GTS VM No users and testing just the OSP signaling Better than nothing But topology generation is almost a nightmare The version of VM is slightly different than the one used in our testbed It has an impact on the OSP protocol implementation Not done, we have a smarter idea

GTS VM No users and testing just the OSP signaling Better than nothing But topology generation is

15 What we have done We have realized a hybrid testbed Core of the overlay is in our lab In our lab 8 PCs and 5 servers well provisioned VMs emulating routers with caches VMs emulating OpenStack tenants + caches Not enough CPU resources on GTS VMs Users requesting processing in GTS A VM for each user Off-load part of the computing burden from our testbed (~30% of nodes) Test data transfers with realistic latency Users submit many GBs of input files to the network

resources on GTS VMs Users requesting processing in GTS A VM for each user Off-load part of the computing burden

16 IS IS In our lab DE2 DE2 DK DK EE EE LV LV LT LT IE IE UK UK BE BE NL NL PL PL LU LU DE1 DE1 CZ CZ PT PT IL IL SK SK AT AT ES ES FR1 FR1 CH CH FR2 FR2 IT IT GR GR PC7 S1 S2 S3 S4 S5 Gre Tunnels PC8 PC1 PC2 PC3 PC4 PC5 PC6

17 In GTS ARES GTS testbed Replicated for each physical host in our lab VM1 VM2 PPP VPN tunnel PoP VM1 GRE tunnels PoP VM2 Physical host Soft-bridging

18 Performance evaluation (1/3) Network traffic per request 250 Average network traffic [GB] ARES Local Testbed ARES on GTS RAND MDU

19 Performance evaluation (2/3) Cumulative network traffic [TB] ARES Local Testbed ARES on GTS RAND MDU time [# of completed requests]

Local Testbed ARES on GTS RAND MDU 2 0 0 10

20 Performance evaluation (3/3) 700 Throughput per request Throughput [Mb/s] ARES Local Testbed ARES on GTS RAND MDU

21 Conclusion Our hybrid lab-gts deployment allows to test a number of interesting features Adding real WAN latency to data transfers Compete for bandwidth with usual traffic As it should be in a hypothetical deployment in Géant datacenters UniPG has 1 Gb/s connection towards GARR NREN Off-load our testbed from many VMs No testbed crashes during hybrid functioning A lot of crashes during full local deployment Validate results obtained in our lab

22 Open issues (1/2) Deploying a complex network is really timeconsuming Naming an interface «ethx» in DSL does not map into «internal ethx» interface in the VM A tool for designing complex topologies is definitely needed! VM size cannot be configured Number of CPU cores Amount of RAM Disk size Choice is present but not active up to some time ago

23 Open issues (2/2) Possibility of using a custom VM image would help a lot Saving of configuration and installation time Avoid compatibility issues of developed software IAG VPN not so stable We experienced some crashes of the PPP VPNs, not of the VM We have not tested the External Domain facility A front-end scheduler is required for massive usage How many resources are available to each user at a given time Possibility of scheduling VMs of variable size

GÉANT for HEAnet clients

GÉANT for HEAnet clients Guy Roberts GÉANT CTO Office HEAnet National Conference 12 th November 2015 Global R+E connectivity for Ireland HEAnet + GÉANT provide access for Irish R+E users to the world s