Towards Practical Multi-layer Performance Management in Cloud Networking and NFV Infrastructures

Transcription

1 Towards Practical Multi-layer Performance Management in Cloud Networking and NFV Infrastructures COST 134 MC meeting, Lovran, Croatia, Oct Kurt Tutschku Blekinge Institute of Technology (BTH), Faculty of Computing Department of Communication Systems (DIKO)

2 Vehicular Networks Future Internet: Applications, Architecture and Performance Social Networks with Big Data Many (Virtual) Networks! Everywhere! Are these networks/clouds sustained? What about: Greenness: Energy? Mineral Resources? Economical durability: Lifespan? Investments? How can we operate these networks? Virtualization is very much about efficient use and sharing of resources Internet of Things Performance management is key Huge data centers for Clouds

3 What are the Issues? Cloud as a Service front end business logic back end Cloud Orchestrator (e.g. OpenStack) Customer IPv4-based Internet Customer Customer DPI or VPN Middle Box Load Manager Multiple Slices / Tenants Enterprise network of CN operator Storage Node Allow Failove r Storage Node Possible coordination between Cloud and network infrastructure Advanced Network controller (e.g. Floodlight OpenFlow controller)

4 What are the Issues? The Infrastructure project of the European Public- Private-Partnership on Future Internet Yes, BTH is here! What is the E2E service experience?

5 Dimensions of Resource Mgmt in Cloud Networking Compute Infrastructure Application Virtualization Cloud XaaS Services (MS Azure, Amazon AWS, Oracle, ) Operating System Hypervisor, Scheduling Cloud / Federation Virtual Machine Resources Virtualization type (Type 1/2) Server Hardware Network Infrastructure Vertical integration: layering concept (even recursive) Horizontal integration: end-to-end (multiple hops)

6 What are daily tasks in performance management in virtualized environment? Virtual appliances User Hypervisor (e.g KVM) Admin Host Kernel Host OS CPU RAM I/O Infrastructure Relationship between inside (virtual appliance/user) and outside (infrastructure/admin) is not obvious. Might even get less predictable when an end-to-end view or service chaining is considered!

7 How can we establish relationships? What can we do this with onboard instruments / standard pgkes? (Additional instrumentation often (still) impossible!) How do these tools behave and where are their limits? Measurements of tests in an experiment: Hardware: E3-123, 3.3GHz, 8 cores, 8 GB RAM Host OS: Ubuntu Desktop14.4 LTS, CentOS 6.6 Virtualization: kvm Guest OS: Ubuntu 14.4 server VM configuration: 2 vcpus Load monitoring: uptime, top, mpstat Load generators: stress/stress-ng

8 % CPU utilization in host % CPU utilization in host Some Results: mpstat Utilization when stressing one vcpu Ubuntu host centos host % CPU utilization in guest % CPU utilization in guest 1% 2% 3% 4% 5% 1% 1% 2% 3% 4% 5% 1% Difficult to compare load across host operating systems! Large variations between multiple test Variation might in crease at lower load!?!

9 % CPU utilization in host % CPU utilization in host Some Results: mpstat Utilization when stressing two vcpu Ubuntu host 3 45 centos host % CPU utilization in guest % CPU utilization in guest 1% 2% 3% 4% 5% 1% 1% 2% 3% 4% 5% 1% Tool may show even higher variation at full load under centos! Is Ubuntu more predictable?

10 CPU load average in host Load average in host More Results: uptime CPU load when stressing one vcpu Host: CentOS Host: Ubuntu 1,4 1,2 1,2 1 1,8,8,6,6,4,4,2,2,2,4,6,8 1 1,2,2,4,6,8 1 1,2 CPU load average in guest Load average in guest 1% 2% 3% 4% 5% 1% 1% 2% 3% 4% 5% 1% Very high variations at full load under centos! Ubuntu: more direct variation

11 Load average in host Load average in host More Results: top CPU load when stressing one vcpu Host: CentOS Host: Ubuntu 1,4 1,2 1,8,6,4,2,8,7,6,5,4,3,2,1,2,4,6,8 1 1,2,2,4,6,8 1 1,2 Load average in guest Load average in guest 1% 2% 3% 4% 5% 1% 1% 2% 3% 4% 5% 1% Top might be more predictable Ubuntu shows some kind of exponential limit behavior

12 A Framework for Performance Data Integration Overall Concept Cloud Networking Control Application Layer CN (Umbrella) Controller Cloud Orchestrator (e.g OpenStack) Network Controller (e.g OpenFlow Controller) CN Profiler (provides vertical and horizontal integration) Data Integration Layer (part of future Cloud Networking Operating System) Data Representation and Storage Service Data Translation Service (Establish global Cloud Networking view) (coherent data structure and semantics) (Provides interoperability by translation) Data Collection Service (Reliable gathering of data) Cloud Networking Component Layer SDN-based OpenFlow switch IPv4/v6 router (Virtualized) Network Function Server Storage Server Cloud Computing Server Application Specific Virtual Machine

13 Data Integration Layer A Framework for Performance Data Integration Data Integration Layer Data Representation and Storage Service Data Object A: QoE for VNF Data Object B: Host Load (OS XYZ) Data Object C: VM Load (Guest OS XYZ) Data Translation Service Translations Module A: QoE for VNF Translations Module B: Host Load on Compute Server using OS XYZ Translations Module C: Host Load on Compute Server using OS XYZ Raw Data Raw Data Raw Data Data Collection Service

14 Summary Performance management in virtualized systems is of increased complexity due additional dimensions virtualization techniques and scope. Interpretation of simple observations/measurements is still complex or in the beginning Reliable and und reasonable tools urgently needed to described load Significant differences for similar guest load among different operating systems Term network load in virtual infrastructures might comprise computational as well as network load in physical infrastructures vertical integration Horizontal integration not yet addressed Data integration layer might enable comparability of load descriptions

15 Tack så mycket! Frågor?