System Support for Internet of Things

Transcription

1 System Support for Internet of Things Kishore Ramachandran (Kirak Hong - Google, Dave Lillethun, Dushmanta Mohapatra, Steffen Maas, Enrique Saurez Apuy)

2

3

4 Overview Motivation Mobile Fog: A Distributed Programming Model for the IoT The Analysis of Things Virtualization for the IoT Conclusion

5 Rise of Internet of Things

6 A Broad Set of IoT Applications Energy Saving (I2E) Defense Predictive maintenance Enable New Knowledge Intelligent Buildings Industrial Automation Enhance Safety & Security Agriculture Transportation and Connected Vehicles Healthcare Smart Grid Smart Home Thanks to CISCO for this slide

7 System Support for IoT Our Lab Focus Thanks to CISCO for this slide

8 Overview Motivation Mobile Fog: A Distributed Programming Model for the IoT The Analysis of Things Virtualization for the IoT Conclusion

9 Future Internet Applications on IoT Common Characteristics Dealing with real-world data streams Real-time interaction among mobile devices Wide-area analytics Requirements Dynamic scalability Low-latency communication Efficient in-network processing

10 Fog Computing New computing paradigm proposed by Cisco Extending the cloud utility computing to the edge Provide utility computing using resources that are Hierarchical Geo-distributed Mobile / Sensor Edge Core

11 Problem How can we easily develop future Internet applications on the fog computing infrastructure? Need a right programming model that Provides a simple API Ensures dynamic scalability Supports efficient in-network processing for wide-area applications Allows real-time interaction among nearby edge devices

12 Limitations of Existing Platform as a Service Based on large data centers High latency / poor bandwidth for data-intensive apps API designed for traditional web applications Not suitable for the future Internet apps

13 Network Performance of Cloud VS. Fog Bandwidth and latency measured between a mobile node and a computing node connected through GT-wifi (measured on Apr ) Bandwidth (Iperf) Latency (Ping) Bandwidth (Mbytes / sec) Latency (ms) Nearby EC2 Nearby EC2

14 Mobile Fog PaaS programming model on the Internet of Things Design Goals Simplicity: minimal interface with a single code base Scalability: allows dynamic scaling Context-awareness: network-, location-, resource-, capability-awareness Assumes Fog computing infrastructure Infrastructure nodes are placed in the fog IaaS interface for utility computing

15 Mobile Fog Application Model Network Hierarchy Mobile Fog application consists distributed processes connected in a hierarchy Each process covers a specific geographical region Location

16 Mobile Fog API (App Deployment) Mobile Fog Process App Code Start_App() On_create() Mobile Fog Runtime AppKey Region Level Capacity On_child_leave() On_new_child() On_create() Connect_Fog(appkey) On_new_parent()

17 Mobile Fog API (Communication) on_message() send_to()

18 Mobile Fog API (Context-awareness) query_location() Level 0 query_level() query_capacity() query_resource() Level 2 Level 1 Level 2 Level 3 Camera, speed, etc. CPU, RAM, storage

19 Mobile Fog Scalability Level 0 Application scales at runtime based on the workload Developer specifies scaling policy for each level Load balancing based on geo-locations Level 1 App Context Level 2 Level 2 send_up() send_up() send_up() send_up()

20 Mobile Fog Spatio-temporal Object Store App context object is tagged by key, location, and time get_object(key, location, time) put_object(key, location,time) Context objects are migrated when scaling F2 F1 F4 F3 Temporal Distribution A B C A B space F5 F2 F1 F1 F4 F3 F1 F5 F3 F1 C old time new Spatial Distribution A (F2) F3 = B + C F1 = A + B + C B (F4) C (F5) now 3 mins 3 mins 5 mins 5 mins 8 mins

21 Use Case Vehicle Tracking using Cameras Target Location Aggregation Target Tracking License Plate Recognition send_up(vehicle_id) send_up(motion_frame) Motion Filter Image Capture send_down(ptz_control)

22 Experiments Quad-tree topology covering the urban area Edge infrastructure nodes directly communicate with simulated vehicles 1000 vehicles in a 7.7 KM x 3.5 KM grid SUMO traffic pattern OMNET++ net sim

23 Experiments (Vehicle to Vehicle Video Streaming) Fog-based approach shows better latency and less net traffic relative to the cloud

24 Experiments (Traffic Monitoring) Location events from mobile devices are stored in Fog or Cloud Fog significant advantage when query range is within 0.5 KM Cloud-based approach is better when query range is large (> 0.8 KM)

25 Overview Motivation Mobile Fog: A Distributed Programming Model for the IoT The Analysis of Things Virtualization for the IoT Conclusion

26 Challenges to Application Development Sensor / actuator access Data transport Widely-distributes sensors / actuators Requires computational resources Distributed computation for parallelism for distributed sensors / actuators Application dynamism need elastic resources Massive scale number of sensors / actuators amount of data produced geographic diversity And more 26

27 What s missing from IoT? Systems Support for Live Streaming Analysis algorithms analyze data streams as they are produced brings intelligence to IoT proven by the success of Big Data Analytics in static data / batch processing world applies in many contexts: situation awareness cyberphysical systems financial analysis we refer to Live Stream Analysis in IoT as the Analysis of Things (AoT) 27

28 Internet of Things, in detail Myriad sensors and actuators, not just user devices digital representations of the real world Mobility Wireless Both simple and rich sensing feature extraction and advanced analysis required for rich sensing Heterogeneity Dynamic environment Machine-to-machine (M2M) and cyberphysical applications sense-process-actuate loop => low latency! Massive scale number of devices amount of data Geographical diversity (and geography matters!) location-sensitive & locationaware applications Hierarchical structure latency tolerance vs. time scale

29 Hierarchical Applications Corporate-wide: marketing decisions, corporate strategy Regional: what to carry in stores, product interactions Each Store: customer interaction (e.g., e- cupons, product recommendations)

30 System Requirements to Support AoT Abstract away system-level issues Execute applications on distributed resources Efficient and scalable stream transport Programming Model Execution Environment Execution Environment Stampede RT Stream registration and discovery Stream Registry Component-based design Connecting operator graphs to arbitrary inputs & outputs Widely distributed architecture Operator Store Drivers Federated Architecture

31 (Algorithm)I The Programming Model State Declarations Input / Output Stream Types Initialization Routine Operator Store Handler (Algorithm) Operator Operator Operator Operator Operator Operator

32 System Architecture Worker Node Operator Store Operator Code Worker Node Worker Node Resource Manager Operator Graph Worker Node Stream Registry

33 Running Application Operator Operator Operator Store Operator Container Operator Container Resource Manager Stampede RT Worker Node workerd Stream Registry

34 Stream Registry Sensors are tagged with location Stream metadata stored at sites based on sensor location Stream Registry queries must include a region of interest Queries sent to a subset of sites based on the region only Scalability Sites receiving the query filter based on the remaining query attributes Focus on the geographic part of the query

35 Sensor Registry Requirements Feature Requirements Traditional DHT Self-Organizing Scalable Robust vs. Node Failures Load Balance Range Queries 2-Dimensional Geographical Locality - allows geospatial queries

36 Federating the Design Multitude of sites at different geographical locations each has the system design just presented each is location-aware each component is federated separately Operator Store, Stream Registry, Resource Manager

37 Sharing Analysis Results Stream Registry Operator Operator Operator Operator Shared Stream Operator Operator Operator Operator Operator

38 Sensor Threshold Application source drivers S S { id, GPS, sensor value } threshold operators { list( GPS, sensor value ) } { cent. GPS, sum, count } AoT System s sink drivers S S S sum/mean operators S S s Alert!

39 Object Tracking Application source drivers JPEG decoder foreground detector object detector / tracker JPEG encoder AoT System sink drivers S DEC FG Track ENC s S DEC FG Track ENC s { M-JPEG video } { foreground mask } { M-JPEG video { raw video } { raw video w/ objects } w/ objects }

40 Overview Motivation Mobile Fog: A Distributed Programming Model for the IoT The Analysis of Things Virtualization for the IoT Conclusion

41 How Virtualization Fits In IoT? Servers, Cloud Setups Server Consolidation, Load Balancing, Usage Accounting, Fairness, Security Fog Nodes Security, Data/ Computation migration to Clouds Dealing with the underlying heterogeneity of the fog nodes Client Devices Versatility, Security in smart phones (other hand-held devices) Security of the critical components in automobiles Data/ Computation migration to fogs and clouds

42 Need for new research Virtualization has been well researched in the context of servers and cloud setups Introduction into fog nodes & client devices brings new challenges Rethink virtualization in the context of heterogeneity presented by fog nodes Set of applications running in the client devices may have different requirements Implications for the design and implementation of mechanisms Resource management in the context of needs of new applications/ usage-modes Migration becomes significantly harder Granularity of migration (whole VM/ process/ something else?) Dealing with the complexity of architectural difference among the nodes Dealing with difference in capabilities of I/O devices Dealing with geographical separation of the fog nodes and its implications for system and network virtualization

43 Examples of Relevant Research Virtualization getting introduced into client devices Xen-ARM VMWARE Mobile Virtualization OKL4 Mobile Virtualization Research Efforts: Cells, others Initial investigations about introducing into automobile software systems Cyber Foraging On-Demand Virtualization Resource Management

44 Memory Resource Management Core research problem: Dynamically partition the available physical memory among the set of virtual machines Why is it necessary? Memory is finite (as opposed to CPU, I/O Cycles) Amount of allocated memory has direct impact on the performance of a VM Memory need of VMs varies over time Static partitioning may be enough in case of over-provisioned systems Over-provisioning may result in under-utilization of resource for a majority of time Client devices, Automobile systems are not over-provisioned May be rather resource-constrained

45 Known Mechanisms Ballooning Based on a pseudo-driver called balloon driver inside each VM Two operations: Inflate, Deflate Transfers memory pages between the VMs and the hypervisor Transcendent Memory (T-Mem) Collect memory from the hypervisor and the guests into a centralized pool May use ballooning for collecting memory Provide indirect page-copy based interface to the pool get-page() / put-page() To be used by the VMs during memory pressure Other hybrid mechanisms

46 Why are these not good enough? Primary Reason: Not designed with the client device applications in mind Application Characteristics: Occasional Memory Spikes Latency Sensitivity Mix of critical and non-critical VMs Other Reasons: Stand-alone ballooning is not on-demand Lack of coordination among the VMs T-Mem Does not necessarily provide performance/usage benefit as compared to ballooning Youtube-Client

47 New mechanism Coordinated Memory Management On-demand Coordinated effort among the VMs to deal with memory spikes First implementation according to Xen split-driver principle Primary Issues Interference from other system constructs (schedulers) Latency overhead due to xenstore based coordination

48 Improving latency Scheduler optimization Optimization inside VM kernel Capture the event when a work item related to the mechanism gets allocated to a kernel thread Increase the priority level of the kernel thread for the time it works for the coordinated mechanism Optimization in the hypervisor A vcpu doing mechanism work is not de-scheduled Hypervisor based implementation Coordination Shared page, upcall, hypercall No xenstore operations Remove un-necessary dependency on Dom-0

49 Operational Latency (no workload) Latency of split-driver design Latency of xen-based design

50 Operational Latency (with workload) Latency of split-driver design Latency of xen-based design

51 Effect of scheduler optimization constructs Split-driver design Xen-based design

52 Comparison with intra-vm memory management mechanisms Intra-VM Inter-VM (CMM)

53 Conclusion Variety of IoT applications require proper system support Complexity of developing large-scale applications Requirement for real-time interaction and dynamic workload handling Applications run on resource-poor heterogeneous devices System support for IoT Programming Model Runtime System Virtualization