Simulating Heterogeneous Resources in CloudLightning
0 likes670 views
The document discusses the CloudLightning project, which aims to design a self-organizing, self-managing cloud infrastructure capable of efficiently managing heterogeneous resources such as multicore processors, GPUs, and DFEs. It emphasizes local decision-making for optimal execution and reduced power consumption, as well as introducing a new HPC resource-as-a-cloud delivery model. The project addresses the challenges of resource characterization and cloud simulation, highlighting its application in fields like genomics, oil and gas exploration, and ray tracing.
Simulating Heterogeneous Resources in CloudLightning
- 1. SELF-ORGANISING, SELF-MANAGING HETEROGENEOUS CLOUD Simulating Heterogeneous Resources in CloudLightning Dr. Christos Papadopoulos-Filelis
- 2. • Modern Cloud Computing infrastructures are gradually equiped with different types of hardware: • Multicore processors • Accelerators (i.e. Intel Xeon Phi, GPUs) paired with CPUs • DFEs paired with CPUs • CloudLightning project aims in the design of a system that can manage these heterogeneous resources efficiently. • CloudLightning is a self-managing, self-organizing system. • Local decisions based on user input and needs are performed from the system ensuring optimal execution and decreased power consumption. Overview of CloudLightning System
- 3. • Cloud environments allow for expansion of the underlying resources without substantial changes in software. • However, over-provisioning of resources was chosen as a method for assuring service availability, leading to underutilization and extensive power consumption (Barroso and Holzle, 2007). • Leveraging performance based on homogeneity (adding identical general purpose cores) poses problems such limitations on power density, heat removal, etc (Crago and Walters, 2015). • Currently delivery models (IaaS, PaaS, SaaS) are not designed for handling HPC applications. • Integration of different types of hardware and management of increasingly more complex Cloud environments is at an early stage. Facts and Challenges
- 4. • Clouds are complex environments. Alan Turing’s observation “global order comes from local interactions” reveals a way of managing and organizing without unnecessary overhead present in hierarchical control. Thus, self-management and self- organization is performed locally. • Use and management of specialized high performance hardware (i.e. GPUs, MICs, DFEs) with low Watt/FLOPS ratio. • Limit overprovisioning by adaptively peaking optimal sets (coalitions) of resources for each application. • Specialized Template based system for characterizing applications. • New delivery model, namely HPC Resource-as-a-Cloud. CloudLightning Perspective
- 5. • The life-cycle of the CloudLightning service begins by the Enterprise Application Developer (EAD). • EAD submits a Blueprint to the Gateway Service. • Blueprint is a graph representing the workflow of Services collectively composed to automate a particular task or business process. • Gateway Service is the front-end of the CL system providing a unified access interface as well as a graphical interface for EADs. • Getaway receives resource options capable to service the Blueprint. Moreover enables EAD to select and deploy the Blueprint. • The Gateway service contacts the “Cell” which contains the self-managing self-organizing system. • CL system is typically composed of multiple cells. Architecture
- 6. Architecture • Cell is associated to one geographical region. • Each Cell is composed of groups of resources called vRacks. • vRack maintains information about servers with same type of physical resources. • vRack Manager manages a logical group of these resources called a coalition. • vRack Group is composed of vRacks with same type of resources.
- 7. • Three HPC use cases have been chosen to validate CL system: • Genomics • Oil and Gas exploration • Ray tracing • General Sparse and Dense matrix computations should be also investigated. • These use cases require large scale computational infrastructures, which are costly to be build and operate on-site. • Cloud services are an effective choice for decreasing the cost of these applications. • These applications are suitable for use with modern accelerator type hardware i.e.: • Genomics: The local sequence alignment can be performed in DFEs (Smith-Waterman algorithm). • Oil and Gas exploration: The Real Time Migration (RTM) as well as the Open Porous Media framework based simulations can be efficiently accelerated in GPUs. • Ray-Tracing: A variety of ray tracing engines exist for accelerators such as Intel Embree that supports MICs and NVIDIA Optix that supports GPUs. Use Cases
- 8. • Resource characterization involves defining the parameters that describe the execution of applications with respect to underlying hardware. • The process of characterization becomes significantly more complex especially in the case of heterogeneous hardware. • The performance of modern processors is affected by an extensive number of parameters. Thus, modelling such hardware posses significant difficulties. • In order to limit the number of parameters required and obtain more accurate metrics, for the large scale simulation of the system, differential metrics with respect to a baseline executions can be used. • Moreover, the chosen tests should resemble the “type” of computational work. Resource Characterization
- 9. • Examples of applications that can be used for characterization of resources with respect to use cases are the following: • Genomics: • For CPUs: MUMer, (Kurtz et al., 2004) • For GPUs: MUMerGPU, (Schatz et al., 2007) • For DFEs: Smith Waterman, (Maxeler, 2015) • Ray-Tracing: • For CPUs: Embree, (Embree, 2016). • For GPUs: NVIDIA OptiX, (NVIDIA, 2016). • For MICs: Embree, (Embree, 2016). • Using CPU executions and acquiring metrics such as Performance, with respect to execution time, or GFLOPS and Energy consumption, a baseline set of results can be collected and used to produce indexes of performance. For example for Ray Tracing: 1 Resource Characterization
- 10. • The chosen type of indexes simplifies computation of accurate metrics with respect to chosen applications. • They can be easily induced with more characteristics such as energy consumption, scalability etc. • They are dimensionless numbers and can be combined with each other to produce collective indexes to characterize the performance of a system based on various applications. • They simplify the simulation process from the aspect of simulating the expected time of completion for a task based on the input data and baseline metrics. • Baseline metrics can be obtained using high end CPUs. Thus, enabling easy realization of the improvement gained by using the CL system for a given application. Resource Characterization
- 11. Performance Index { CPU Performance: Oil and Gas Exploration and Sparse and Dense Matrix Computations C1: SGEMM C2: DGEMM C3: Dense LU Factorization (SGESV, DGESV) C4: Sparse LU Factorization C5: SFFT C6: DFFT GPU Performance: Oil and Gas Exploration and Sparse and Dense Matrix Computations C1: SGEMM C2: DGEMM C3: Dense LU Factorization (SGESV, DGESV) C4: Sparse LU Factorization C5: SFFT C6: DFFT MIC Performance: Oil and Gas Exploration and Sparse and Dense Matrix Computations C1: SGEMM C2: DGEMM C3: Dense LU Factorization (SGESV, DGESV) C4: Sparse LU Factorization C5: SFFT C6: DFFT } Resource Characterization
- 12. • Oil and Gas exploration is not computationally monolithic since it involves dense and sparse matrix computations which have different memory access patterns and parallel performance. • Oil and Gas exploration involves general sparse matrix computations including: dense and sparse matrix multiplication and solution of large sparse and dense linear systems. • Thus, metrics for this use case can be obtained by a set of tests involving general sparse and dense matrix computations and not perform oil and gas simulations with variable data input. • Moreover, these metrics can be described by general sparse and dense matrix computations present most large scale simulations including in fields such as: Computational Fluid Dynamics, Computational Astrophysics or Computational Finance. Resource Characterization
- 13. • Two major categories of Cloud Simulation tools: • Discrete Event Based (DES): Avoid building and processing small simulation objects (like packets). Instead, the effect of object interaction is captured. (Better performance, Less accuracy). • Packet Level: Whenever a data message has to be transmitted between simulator entities a packet structure with its protocol headers is allocated in the memory and all the associated protocol processing is performed. • The is no “Holy Grail” for Cloud Simulation. • Various simulation tools can be used to simulate a cloud environment (CloudAnalyst (DES), CloudSched (DES), CloudSim (DES), DCSim (DES), GDCSim, GreenCloud (Packet Level), iCanCloud (DES), NetworkCloudSim) Simulation Tools
- 14. Simulation Tools GUI Virtualization Scheduling Network Models Energy Models Parallel Experiments CloudAnalyst ✓ ✓ ✓ Limited (latency) ✗ ✗ CloudSim (original version) ✗ ✓ ✓ Limited (latency) Limited ✗ CloudSched ✓ ✓ ✓ Limited ✓ ✗ DCSim ✗ ✓ ✓ ✗ ✓ ✗ GDCSim ✗ ✓ ✓ ✗ ✓ ✗ GreenCloud ✗ ✗ Limited ✓ ✓ ✗ iCanCloud ✓ ✓ ✓ ✓ ✗ ✓ NetworkCloudSim (integrated into CloudSim) ✗ ✓ ✓ ✓ (latency & bandwidth) Limited ✓
- 15. • The CL system has various components and services not present in todays Cloud systems, thus classical simulation environments cannot be used. • These components and services include: Coalition formation mechanism, vRack, vRack Manager, complex network communications, etc. • Moreover, the different strategies for coalition formation, i.e static or dynamic, impact the system and affect the complexity of the simulation. • Simulating the CL system requires the simulator to be inherently parallel since the increased complexity of the system results in increased computational work. • CL system targets three distinct use cases that can be modeled by the aforementioned dimensionless indexes. Elements of Simulation
- 16. • In order to accurately simulate a CL based cloud environment the time scale should be defined. A more general approach will be to discretize time in terms of a time unit (tu). For simplicity let us consider 1 tu=1 second. • A task can be simulated as follows: Task { Number of Computational Units: W Required Hardware: X Application: Y Time Units: Z } • Each task occupies W hardware instances of computational capability X for an application Y and for Z time units. • Required Hardware defines what type(s) of hardware is required and Y is the type of application. Elements of Simulation
- 17. • Similarly a coalition of capable hardware can be described by the following parameters: Coalition { Number of Computational Units: CU Compute Capability: CC Interconnection: I Storage Interconnection: SI Power Consumption: P Cost: CO Server Initialization: S } • Compute Capability is a dimensionless index computed with the procedure presented in the characterization of hardware. Power Consumption and Cost are dimensionless numbers measured with respect to a baseline. • Interconnection and Storage Interconnection is measured in (Gbps). • Server initialization is measured in (tu). Elements of Simulation
- 18. • The hardware is engaged for the number of time units prescribed by a task (Z). An amount of time (S) is required for initializing the hardware in case it was on a sleep state. Moreover, before the Task begins execution, initialization time to a functional state is required: transfer of software images, installation of appropriate libraries, mounting of storage, etc. Thus, the real time a Task requires is: • Time of Execution (tu) = S+Z+α+β • where α is the time required by the hardware to be functional and β the time required by the hardware to return to idle waiting for the next Task. • α mostly depends on the speed of the network as well as on the number of users (N) occupying the same storage server simultaneously. • α (tu) = (Size of the image (GB))/(SI(Gbps)*tu/(N*8*109)). • β is the time required to free the resource and return it to an idle state. • Finally for the network a linear model is considered: • delay=latency+size (GB)/ BW (GBps) Elements of Simulation
- 19. • Finally, a custom simulation framework will be used since CL is a unique Cloud Computing environment. • The presented simulation entities are enhanced in order to describe different types of deployment such as containers and bare metal images. • The simulator must be able to cope with static and dynamic coalition choices as well as update the list of static coalitions based on users’ choices. • Auto-scaling model should be introduced in the simulation for the three use cases. • This parallel hybrid DES-packet level simulation scheme is expected to describe adequately the CL system. Elements of Simulation and Future Work
- 20. THANK YOU Dr. Christos Papadopoulos-Filelis cpapad@ee.duth.gr