Connecting North Carolina s Future Today. Application Monitoring: ClassScape Case Study. NCSU Centennial Networking Lab

Transcription

1 Connecting North Carolina s Future Today Application Monitoring: ClassScape Case Study John Bass NCSU Centennial Networking Lab Carla S. Hunt MCNC 1

2 Overview About MCNC and the School Connectivity Initiative K12 School Connectivity Projects Application Characterization: The Challenge Application Monitoring: Approach and Architectural Considerations ClassScape Case Study Topology and Netflow Implementation Results and Data Verification Limitations and Extending the Model 2

3 About MCNC We own and operate the North Carolina Research and Education Network (NCREN) Our customers include public and private universities, community colleges, K12 school systems, state government and other nonprofit institutions Our mission is to provide K20 connectivity to North Carolina s educational systems as requested by the state 3

4 NC School Connectivity Program Managed by the Friday Institute at North Carolina State University $6M one-time funding by the NC legislature A partnership between key institutions in NC; including MCNC and NC Department of Public Instruction (DPI) 4

5 Purpose of Program 5

6 NC School Connectivity Projects (K12) Connectivity Keep Local Traffic Local Increase Capacity Network Health Assessment NC End to End Performance Initiative Network Documentation Application Characterization Address configuration problems on a School System s local network Capacity planning E2E Performance Issues and Visibility Storage/Access to Network and Technology-related information Application Monitoring and Readiness

7 Application Characterization: What is the problem we are trying to solve? From the School System s perspective: 1. Existing Applications Poor application performance Or, Inability to run applications 2. New Applications Do we have enough bandwidth? How much bandwidth do we need? 7

8 Application Monitoring Approach: Ability to answer questions like, Do we have the capacity to run an application? And, How much bandwidth does an application need? Start to answer questions like, Can we run this application plus another one? Architectural Considerations: Scalability of Solution Data Management 8

9 Case Study Implementation Web-based application called ClassScape Online formative assessment program Examine traffic at the application hosting site Open Source Netflow (Softflowd and Nfsen) 9

10 ClassScape Netflow Topology port mirror is tx & rx of public port on load balancer ncsu net load balancer Nfdump (netflow collector) Nfsen (netflow sensor) switch db server web server n web server 2 web server 1 Softflowd (netflow probe) 10

11 Netflow Components 1. A netflow probe sorts traffic streams into flows in memory (Src/Dst IP and TCP/UDP port tuples) 2. When the probe determines a flow has terminated, it sends a netflow packet to a netflow collector 3. A netflow sensor analyzes and displays data from the collector Note: The netflow collector can receive netflow streams from multiple probes and write the netflow data to disk.

12 Nfsen Case Study Results Aggregate traffic for all School Systems Top Talkers Traffic for individual School System 12

13 Aggregate Traffic

14 Top Talkers

15 Traffic for an Individual School System Clicking on a destination IP Address in the list of Top Talkers returns the DNS name and owner information

16 Data Verification Nfsen and Softflowd appear to be a useful tool set for monitoring an application s incoming and outgoing traffic. To be sure, we need to verify our data. A couple of ways we could do this: Ask a School System for output from a packeteer (or some other method for evaluating the same traffic with a different monitoring infrastructure) Or, generate a known set of traffic monitored by nfsen and softflowd and compare results

17 Test Plan Two Main Objectives: Explore the limits of softflowd capabilities Determine softflowd/nfsen accuracy in the range of softflowd s operational limits Spirent Avalanche traffic analysis tool will be used to generate flows 17

18 Limitations Mirroring has to be implemented correctly Packets will be dropped if the total transmit and receive exceeds the transmit capacity of the mirror port No performance guidelines as to how many flows softflowd and the associated hardware can support 18

19 Extending the Model This was a proof of concept with: A single probe A single contiguous address space Theoretically, the architecture can be expanded to: Multiple probes Multiple address spaces 19

20 Next Steps Move the front end to MCNC s data center Consider alternative architecture for the probe Low cost Linux in a box Work with the NC Department of Public Instruction to identify applications to monitor 20

21 To Learn More ClassScape Softflowd (a netflow probe for linux) Nfsen NCSU Centennial Networking Lab John Bass or Carla Hunt for the accompanying paper and any additional information 21

22 Special Thanks John Bass Technical Director Centennial Networking Labs North Carolina State University 22