Servers in Action: Towards Distributed Traffic Measurement in Data Centers Praveen Tammana & Myungjin Lee School of Informatics University of Edinburgh MSN’14 - Cosener's House, Abingdon 1
Network Measurement in Data Centers ● Data center applications – High Bandwidth – Latency sensitive ● Network Management – Control ● Routing, Access control – Measurement ● Traffic engineering, Security applications ● Basic requirements – Accuracy, Scalability ● Data center requirements – Programmable, Responsive, Evolvable 2
Data Center Measurement Requirements Responsiveness : Quick control ● loop decisions (Heavy flow scheduling) Core Aggregate Programmability : Adaptable to ● Edge dynamic workloads Evolvability: Software based ● measurement module (bloom filter, trie, hashtable) 3
Network Measurement Framework Traffic Engineering Accounting Fault diagnosis Forensic analysis Network Management Tasks SLA monitoring Anomaly detection worms, portscans, botnets Flow Collector ● Software Flow Monitoring ● Hardware 4
Software Based - Flow Monitoring # Bytes/Pkts Task 1 Sampling Task 2 ● – NetFlow, sFlow Counters – High traffic rates compliance with limited Task N switch resources (SRAM, CPU) Problem sampled ● – Not Accurate (Basic Requirement) Packet stream ➔ Flow coverage and accuracy are compromised. ➔ Not suitable for management tasks Management Tasks that requires fine grained flow details. Traffic Engineering Accounting Fault diagnosis Forensic analysis SLA monitoring Anomaly detection worms, portscans, botnets 5
Hardware Based - Flow Monitoring Task 1 Task 2 Task N Task Oriented ● – Task 1 : Anomaly Detection # Bytes/Pkts Counters Counters Counters (SRAM) – Task 2 : Traffic Engineering Problem ● – Not Evolvable (DC Requirement) ● Higher speed links (40/100 Packet stream Gbps) ● SLA monitoring in data centers 6
Data Center Network Is Evolving (Net Optics 2013) 7
Distributed Traffic Measurement ● Our approach : – Distribute flow monitoring overhead between switches and servers Collector 3 Aggregate pkts Report results Statistic pkts S t a t 2 i s t i c p k Flows t s f1 f2 f3 Monitor Flows f4 8 1 f5
Distributed Traffic Measurement Core Aggregate Administrators have complete control of switches and servers Edge - High computational resources (multiple cores, large memory) - Hosts observe relevant traffic of running services - Monitors less traffic than switch 9
Proposed Framework Aggregation module ● Consumers ● Aggregates statistic packets (s-pkts) ● Counters can be stored in high density DRAM Measurement module ● Producers ● Monitor traffic and generates statistic packets (s-pkts) (e.g., per flow record) ● Feeds s-pkts to ToR switch 10
Proposed Framework – Packet Processing Measurement module 1. Copy of regular packets NIC Reglular packets 11
Proposed Framework – Packet Processing Measurement module 2. statistic packets 1. Copy of (s-pkts) regular packets NIC Regular packets 12
Proposed Framework – Packet Processing Aggregation Module 3. Copy of statistic packets (s-pkts) Measurement module Ingress port Egress port 2. statistic packets 1. Copy of (s-pkts) regular Reglular packets packets NIC Regular packets 13
On going work : Statistic Packet Forwarding ● How to forward statistic packet ? – Packet path encoding and IP source route option – Use switch forwarding table 14
Usecase – Hierarchical Heavy Hitter (HHH) HHH: Longest IP prefix occupies more than fraction T of link bandwidth **** 40 after excluding any descendant HHH 1*** 0*** 40 0 00** 01** Threshold : T=10 19 21 000* 001* 010* 011* 12 7 12 9 0001 0010 0011 0101 0110 0000 0100 0111 11 1 5 2 9 3 5 4 Traffic volume for each IP Prefix 15
HHH Detection IP Prefix Trie (Source IP) Collector Report HHH HHH Aggregation Module Statistic pkts Statistic pkts HHH Measurement HHH Measurement Module Module f1 f1 f1 f1 Pre-filtering f2 f2 f3 Pre-filtering f3 f4 f5 16
Evaluation Simulation setup ● – Measurement module : Customized YAF – Aggregation module : IP Prefix Trie – Packet trace – T. Benson : University data center Aggregation module performance ● – HHH Accuracy – Computation overhead on Servers and switches – Compared with NetFlow 17
Preliminary Results FPR : False Positive Rate FNR : False Negative Rate Aggregation module overhead ( AMO ) HHH Accuracy Varying Sampling Rates over NetFlow overhead ( NFO ) 18
Preliminary Results FPR : False Positive Rate FNR : False Negative Rate Aggregation module overhead ( AMO ) HHH Accuracy Varying Sampling Rates over NetFlow overhead ( NFO ) Correctness : 100% Sampling rate – 100% Accuracy Overhead: AMO is just < 2% of NFO 19
Conclusions and Future work ● Conclusions – Our framework offloads overhead on switch – Evolves along with data center traffic volume – Provides more flexibility to data centre operators ● Future Work – Prototyping proposed framework – Exploring performance across different measurement tasks – Endhost based network trouble shooting (e.g., packet loss, delay) – Impact of packet loss on accuracy – Distributing measurement task overhead across network 20
Thank You Questions Praveen Tammana praveen.tammana@ed.ac.uk University of Edinburgh 21
Challenges – Handling multiple paths between End Hosts – Consistency with forwarding rules update 22
Measurement Tasks ● Hierarchical Heavy Hitter (HHH) ● Heavy Hitter ● Superspreader ● Flow Size Distribution ● DDoS 23
Proposed Framework : s-pkt forwarding Flow Path : S → T1 → A1 → T2 → R A1 Encodes path information into T1 T2 packet S S R 24
Proposed Framework : s-pkt Forwarding Flow Path : S → T1 → A1 → T2 → R s-pkt : R → T2 → A1 → T1 A1 t k p - s-pkt s T1 T2 s-pkt S S R 1. Generate s-pkt 2. Enables IP source routing option 25
Recommend
More recommend
