SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 2 of 10

Transcription

1 Parallel and Distributed Simulation in the Cloud Richard M. Fujimoto 1, Asad Waqar Malik 2 and Alfred J. Park 3 1 School of Computational Science and Engineering, Georgia Institute of Technology, USA 2 National University of Science and Technology, Pakistan 3 IBM T.J. Watson Research Center, Yorktown Heights, USA Abstract Cloud computing offers the ability to transparently provide computing services remotely to users through the Internet, freeing them of the burdens associated with managing computing resources and facilities. It offers the potential to make parallel and distributed simulation capabilities much more widely accessible to users who are not experts in this technology and do not have ready access to high performance computing platforms. However, services hosted within the cloud can incur significant performance degradations. This article discusses the potential benefits and technical challenges that arise in utilizing cloud platforms for parallel and distributed simulations and a potential solution approach. 1. What is Cloud Computing? Cloud computing has been gaining much attention in recent years as a means of realizing a long sought-after vision where computing is provided to consumers as a utility, not unlike electricity, water, or natural gas. As such, it is revolutionizing portions of the IT industry conducive to this computational model. In contrast to the norm today where organizations potentially incur large capital expenditure (CapEx) costs to build and operate their own computing infrastructure and IT services to meet the computing needs of local users, cloud computing is a paradigm where computing services are implemented on servers that can be accessed by clients operating at remote locations throughout the Internet (Hewitt 2008). It is an approach where computing resources are provided as a service, e.g., Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). These services are inherently flexible and agile where users can choose the granularity of service and pay for only the computing resources they need. Commercial cloud computing services have gained some inroads and success utilizing this paradigm. Amazon Web Services Elastic Compute Cloud (EC2) offers compute cycles and storage charged on an hourly and monthly basis, respectively (Lizhe, Jie et al. 2008). EC2 provides virtualized hardware upon which users can build a wide variety of applications. Some higher level services, e.g., storage management services are also provided. Microsoft s Azure platform supports applications that are developed using.net libraries. Google AppEngine provides an environment for creating web service applications that operate on Google s infrastructure. While EC2 offers a lowlevel version of the cloud where users can build their own software stacks over virtualized hardware, Azure and AppEngine offer successively higher-level views and services, trading off flexibility with increased functionality and ease of use. Cloud computing outsources computing infrastructure services to the cloud provider, reducing or eliminating the need for organizations to offer extensive IT hardware and services. This may provide certain economic advantages to its users. First, the cloud provider may be able to provide computing infrastructure more affordably than a locally operated facility. This is because the cloud provider can take advantage of certain economies of scale to reduce its operating costs. In addition, the operator can place its facilities in locations that offer lower cost electricity, power, cooling, labor, property costs, and/or taxes. Electricity and cooling now represents a large fraction, e.g., a third, of the operating costs of a modern datacenter, while the cost of electricity in states such as California can be several times more than locations in Idaho or Washington SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 1 of 10

2 (Armbrust, Fox et al. 2009). The pay-as-yougo cost structure of cloud computing is attractive if the computational requirements of users vary greatly over time. Cloud computing allows the amount of computational power that is used, and the cost, to expand and shrink according to the user s needs. The alternative is to either overprovision the infrastructure within the users organization to meet the peak expected workload, leaving the facility underutilized during periods of less intense usage, or to create a lower cost facility that is unable to meet the demands offered at times of peak usage. Cloud computing represents a fusion of many related technologies and paradigms. It includes concepts associated with paradigms such as grid, utility and autonomous computing. Grid computing aggregates computational resources across different administrative domains so that they can act in concert to perform very large tasks. Grid computing is often heterogeneous and geographically detached (Aymerich, Fenu et al ). Applications of grid computing require a large number of processing cycles, access to large amounts of data, and can generate huge datasets. Autonomic computing (AC) is based on self-management, configuration, healing, and self-protection. An AC system uses a concept called closed control loops; without any external input it monitors and controls the system. It is a self adaptive system that dynamically changes its behavior in response to new situations and needs (Wang 2004). Utility computing is a provisioning model based on the idea of outsourcing and demand availability. Services and resources are provided to the end user and charged based on their usage (Haifeng, Galligan et al. 2005). Cloud computing includes elements of these associated approaches, and introduces new ways to interact with different services, as compared to traditional client/server architectures. While there has been much research in cloud computing and related technologies, comparatively little work have focused on their use in simulation, especially parallel and distributed simulation. There has been some work in federating distributed simulations utilizing the High Level Architecture (HLA) over grids (Cai, Turner et al. 2002; Xie, Teo et al. 2005; Chen, Turner et al. 2006; Pan, Turner et al. 2007). Other related work includes webbased simulation (Reichenthal 2002; Fitzgibbons, Fujimoto et al. 2004; Huang, Xiang et al. 2004), the Extensible Modeling and Simulation Framework (XMSF) for web services (Pullen, Brunton et al. 2005), object request broker (ORB) based frameworks (Cholkar and Koopman 1999; D Ambrogio and Gianni 2004). Execution of parallel and distributed simulations over clouds represents an interesting opportunity, but presents certain technical challenges, as will be discussed next. 2. Parallel Simulation in the Cloud Parallel discrete event simulation (PDES) refers to the execution of a discrete event simulation program across multiple processors. Typically this is done to scale simulations to larger configurations, to increase the detail and fidelity of the model, and/or to reduce execution time (Fujimoto 2000). As computational hardware becomes increasingly parallel (e.g., multi-core CPUs) with only modest clock speed improvements, simulation developers must turn to exploit parallelism as a means to address performance concerns. While cloud computing presents an intriguing means to offering traditional sequential simulation applications to users, its use for parallel and distributed simulations is perhaps more compelling. A significant impediment to the widespread exploitation of this technology has been the availability of suitable computing platforms. Cloud computing lowers the barrier to begin exploiting these technologies because it eliminates the need to purchase, and more importantly, operate and maintain high performance computing equipment at the local site. Further, by providing parallel and distributed simulation software as a service, cloud computing offers the ability to hide many of the complications of executing parallel and distributed simulation codes from the user, offering the potential to make exploitation of this technology much less risky than is the case today. SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 2 of 10

3 As such, cloud computing can help to address a long-standing problem faced by the parallel and distributed simulation community to simplify exploitation of the technology by domain scientists and engineers who are not experts in parallel computation or parallel simulation techniques. Currently, careful consideration of the hardware platform on which the simulation is to run must typically be performed to achieve good performance. Shielding the simulation modeler from the details of the underlying system details can accelerate the adoption and use of parallel and distributed simulation techniques. A cloud platform offers certain advantages from a simulation software vendor s perspective as well. Offering and maintaining this technology on a well-known, stable platform such as a virtual cluster in EC2 is a much less daunting undertaking compared to offering software that is sufficiently general that it can operate effectively on whatever platforms and configurations users happen to have in place at their local site. This reduces the costs associated with delivering parallel and distributed simulation products to end users, further enhancing its attractiveness. The appeal of cloud computing for high performance computing applications has not gone unnoticed by cloud computing vendors. For example, Amazon s EC2 supports the Message Passing Interface (MPI), the standard communications protocol used by messagebased parallel programs that run on clusters and supercomputers. This provides a direct path to making parallel and distributed simulations, at least those based on MPI, readily available to end users of the cloud. But this is not to say that parallel and distributed simulation in the cloud is a certainty, nor is it straightforward. Indeed, many key issues remain. Many of these concern cloud environments in general, and are not specific to parallel or distributed simulation. For example, users must be assured that proprietary and confidential data will be secure in a cloud environment before they will consider such a move. Services must be reliable, nearly always available, secure, and resistant to cyber attacks. Further, execution of parallel and distributed simulations in cloud environments introduces additional issues, as will be discussed next. Preliminary work in benchmarking parallel scientific programs in Amazon s EC2 provides some insight into the technical issues that will arise in executing parallel and distributed simulations in a cloud environment (Walker 2008; Ekanayake and Fox 2009). It has been observed that parallel scientific codes executed over EC2 ran significantly slower compared to execution on dedicated nodes of a cluster. Two issues are communications and interference. Data processing applications using paradigms such as MapReduce (Dean and Ghemawat 2008) have enjoyed much success in cloud environments, but do not require extensive communications among computing tasks that arise in parallel and distributed simulation codes. Cloud environments are often better at providing high bandwidth communications among applications than in providing low latency (Walker 2008). This is problematic for many simulation applications that are accustomed to sending many small messages requiring quick delivery rather than fewer large messages requiring high bandwidth alone. Cloud environments are shared among many users, and individual users are not guaranteed exclusive access to the processors assigned to that user s virtual cluster. In principle, gang scheduling techniques can be used to ensure an individual users is allocated a set of physical nodes at the same time instant, however, this property may not be guaranteed by the cloud provider. This can lead to difficulties for parallel simulation applications, especially those that utilize optimistic synchronization techniques. Interactive distributed simulations require that simulation computations be completed to meet hard or soft real time constraints. Response time guarantees would have to be provided by the cloud provider to fulfill this requirement. SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 3 of 10

4 In the following, we describe an approach that utilizes the master/worker paradigm for executing parallel and distributed simulation codes. Developed for volunteer computing and desktop grid applications, this approach features properties such as bulk communication (rather than transmitting many small messages), automated support for fault tolerance and load balancing, and migrating computations to the data that are advantageous in the cloud. In a companion paper to appear later, we describe an optimistic synchronization protocol to address the interference problem. 3. Aurora Here, we adopt terminology used in parallel discrete event simulation (PDES). Specifically, a PDES program consists of a collection of logical processes (LPs) that communicate by exchanging time stamped messages. Here, we use the terms events and messages synonymously, unless stated otherwise. Each LP is a sequential discrete event simulation that operates by processing events in time stamp order to model the evolution of the system over time. The computation associated with each event involves modifying state variables to reflect changes in the system occurring at that instant in time, and (possibly) scheduling new events with timestamp in the simulated future. The master/worker paradigm is a mechanism for dividing up a potentially large computation into smaller portions of work that can be distributed to a pool of workers operating under the direction of a master controller. Although this concept has been well-studied in the general distributed computing literature, it has not been extensively explored for parallel discrete event simulation codes. The master/worker paradigm is well suited for cloud computing environments. Unlike traditional PDES codes that rely on frequent exchange of small messages among LPs, the master/worker approach features an automated bundling process that aggregates messages destined for different destinations and transmits them as one unit, achieving better utilization of the high bandwidth, relatively high latency interconnect in cloud environments. Further, by caching the state of LPs among the worker nodes, the execution mechanism has the effect of migrating computations to the data, a strategy that has proven to be successful in data intensive computing applications in environments based on the MapReduce paradigm frequently found in clouds. General distributed computing software does not have the same requirements as those of PDES programs and thus infrastructure must be specifically designed to support this simulation environment. Traditional master/worker systems lease work units to workers for execution. For example, SETI@Home (Anderson, Cobb et al. 2002) divides received radio telescope data into portions that workers can download for analysis. These work units are time-independent from other workers and require no communication between workers as they perform computations as leased by the master. These conditions simplify the runtime requirements of the underlying master/worker infrastructure and are inadequate to support PDES. In conventional PDES systems, a simulation consists of many logical processes that communicate by exchanging time-stamped messages as the simulation progresses. The first important difference in a master/worker PDES system is that the LP state must be tracked and stored. Some general distributed computing projects only require a simplifying result at the end of their computation, however, a PDES system must maintain the state of the LP that may be leased to a different worker at a later time. Furthermore, the PDES system must ensure that these time-stamped messages are delivered in the correct order to the proper destination LP to preserve the local causality constraint (LCC). Therefore, in addition to correctly ordering messages sent between LPs, these messages must be maintained for future delivery to any LP or collection of LPs that are leased as a work unit to an available worker. Moreover, work units must be properly constrained for execution as processing events and messages arbitrarily into the future may violate the LCC. Therefore conservative or optimistic time management schemes must be SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 4 of 10

5 employed alongside LP and work unit management in a master/worker PDES system. Proxy Message Message Message Work Unit Work Unit Work Unit Worker Figure 1. Overview of interaction between different back-end services and a worker during a typical simulation These key differences and requirements between general distributed computing programs and PDES in a master/worker paradigm is the impetus for the Aurora system. However, the need for highly scalable and high performance distributed simulations drive the architecture for the system, which is described next. The description of the Aurora architecture described next is based on that presented in (Fujimoto, Park et al. 2007). 3.1 Conceptual Overview The master/worker paradigm promotes a clear separation between the controller and workers that perform computation on the work unit passed to them by the master. The Aurora architecture divides the master infrastructure into three main back-end services as shown in Figure 1. These services include a proxy, one or multiple work unit state servers, and one or multiple work unit message state servers. The distributed nature of the back-end services helps to ensure scalability and robustness of the Aurora system. These back-end services communicate over TCP/IP sockets. The Aurora workers perform the actual simulation computation by contacting the proper back-end services to download simulation state and associated messages per work unit lease. Computation is done locally, independent of other workers. Once the computation completes, the final state and messages are uploaded to the work unit state and message state servers. This process repeats for a specified number of times or until the simulation reaches its end time. As shown in Figure 1, the worker only contacts back-end services pertinent to its own execution as directed by the proxy. Due to the addition of support for multiple concurrent simulations, Aurora uses the concept of simulation packages (SimPkg). A simulation package contains all the runtime parameters of the simulation such as the number of work units, a lookahead connectivity graph, simulation begin and end times, wallclock time deadlines per work unit lease, and possible initial states. These specifications are uploaded to the proxy service where necessary metadata and allocation of resources is done prior to starting the simulation and allowing workers to execute. 3.2 Aurora Proxy The Aurora Proxy service is the central core controller that oversees the simulation and the other two back-end components. Internal managers handle the other services. The work unit state and message state servers are controlled by independent managers within the proxy that keep track of metadata such as worker keys, server IP addresses, and simulation package to work unit storage allocation. The proxy contains three managers: state server manager, message state server manager, and a simulation package manager (see Figure 2). The work unit state server manager holds control information such as state server IP addresses and a list of work units of a simulation package the server is hosting. The message state server manager operates similarly to the state server, SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 5 of 10

6 except that it keeps track of message state servers instead of work unit state servers. Work Unit Proxy Work Unit State Connection State s TM Connection Message State Simulation Message Connection TSO Message Queues Worker Figure 2. Internal metadata and state management The baseline functionality for both the work unit state server and message state server are inherited from a common manager class, but is kept separate at the implementation level for caching mechanisms which will be distinct whether the server is supporting atomic work unit states or individual time stamped messages. The simulation manager stores the metadata of a simulation package and performs any work related to simulation packages and its associated work units. For example, when a simulation package is uploaded, the simulation manager finds space on available servers where work unit and future message state can be stored. Worker requests for work are passed to the simulation managers for leasing duties as well as to keep track of which work units have been leased or locked down to prevent further leasing. The simulation manager instantiates time managers as specified by the simulation package. Time managers hold information regarding leased work unit simulation times. These managers are responsible for computing safe processing bounds for any given work unit. Time managers may employ conservative or optimistic time management schemes or a possible combination of both. The implementation described here uses a centralized conservative time management mechanism. 3.3 Work Unit and Message State Services The other components of the Aurora back-end service are the work unit and message state servers. The work unit server contains the current values of state vectors for each work unit and the simulation time for which this state is valid. These work unit states are applicationdefined contiguous blocks of memory and are handled by pack and unpack procedures overwritten by the Aurora workers. The message state server is similar to the state server except that instead of storing the state of work units, future messages are stored in timestamp order according to their destination work unit. These services can be easily adapted for optimistic and caching routines by simply storing state and message state histories instead of discarding previous values upon state and message updates. Although distribution of the workload among the proxy, work unit state and message state servers has increased scalability and performance, much of the future performance potential of the Aurora system lies in exploiting optimistic execution and employing caching mechanisms. These services include the baseline architecture for these types of performance enhancements. 3.4 Workers and Work Unit Lifecycle The Aurora workers perform work as dictated by the master comprised of the proxy and associated state servers. The Aurora worker will SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 6 of 10

7 perform iterations of a work unit lifecycle as specified at run time. This lifecycle is comprised of four major steps: (1) initialization, (2) work unit setup, (3) application-defined execution, and (4) work unit finalization. The initialization step is typically done only one time when the worker starts up. This step includes thread initialization, signal handler setup, and command-line parsing. After this step completes, the work unit begins the setup and download phase to populate the worker with the proper state variables and messages to process for the leased simulation execution time. The steps for the work unit setup are performed in the following order: 1. Worker key request 2. Request work unit and metadata 3. Populate internal metadata structures and create a work unit manager if necessary 4. Contact state server and download state 5. Contact message state server and download messages 6. Unpack work unit state 7. Unpack work unit messages and populate the incoming message queue in time-stamp order A worker key is a unique identifier issued to the worker upon first contact by the proxy. The worker uses its key to identify itself in future communications. Once a unique worker key is issued, the worker performs a work unit request where the proxy may or may not lease a work unit to the requesting worker. If a work unit is available to be leased, associated metadata about the work unit is downloaded from the proxy service. Internally, the worker will then set up supporting data structures for the impending work unit. Once this step has completed, the worker will then contact the proper work unit state and message state servers and download the packed information. The work unit state is then processed by the application-defined unpack method to load current state variables. The message states are automatically unpacked by the Aurora worker into a time-stamp ordered priority queue for processing by the worker during the simulation execution. After the work unit setup has completed, the application-defined simulation execution method is invoked and the simulation runs until the end time as specified during the work unit metadata download (step 2 of the work unit setup). During the simulation execution, if the work unit detects a message that is destined for another work unit, it will perform a destination message server lookup. This is performed in a separate thread from the main execution loop and the result is cached for future use. When the simulation reaches the end time as specified by the proxy, work unit finalization begins which is the final step in the work unit lifecycle. This process is comprised of seven steps: 1. Pack final state 2. Pack future messages destined for itself 3. Contact proxy to begin consistency convergence 4. Collate and pack future messages destined for other work units by message state server keys; deliver collated messages to the proper message state servers 5. Upload work unit state to state server 6. Upload messages packed in step 2 to message state servers 7. Receive consistency convergence verification from proxy The first step calls an application-defined method for packing the final state into a contiguous area of memory for upload to the state server. Next, the worker packages any remaining unprocessed messages on the timestamp ordered message queue which may have been created by sending messages during simulation execution by the work unit to itself. The worker then initiates a consistency convergence to the proxy. A consistency convergence locks down the work unit so it may not be leased again or updated in multiple lease scenarios. This allows atomic commits and prevents inconsistent updates of updated work unit and message states. The worker then begins a message collation process where future messages destined for work units that reside on the same physical message state server are packed together. This reduces the frequency of smaller message updates and allows the workers to update groups of messages at one time. After SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 7 of 10

8 this process completes, the final state and future messages destined for the work unit are uploaded to the appropriate servers. The final step is a verification of consistency convergence from the proxy that the process was completed successfully without errors on the back-end. During steps 4-6, the Aurora state and message state servers send messages to the proxy indicating updates to their respective states. The proxy acknowledges these messages and tracks the consistency convergence process. The final result of the update is returned to the worker. 3.5 Performance For a performance evaluation of the Aurora system, a torus queuing network was used to compare the impact of work unit granularity and the amount of work per work unit lease on overall system throughput. In this simulation, servers can be aggregated into subnets that can then be mapped to single work units. In this study, the coarse-grained queuing network was configured as a 250,000 server 500x500 closed torus network with 625 partitions of 25x25 torus subnets. The fine-grained queueing network was configured as a 22,500 server 150x150 closed torus network partition into x10 torus subnets that can be leased as work units. The coarse-grained simulation had internal links within each work unit with a delay of 10 microseconds and external work unit-to-work unit delays of 1 millisecond. The fine-grained simulation had the external delay set at 0.1 milliseconds while the internal delay remained unchanged. Both simulation scenarios generated 10,000 jobs destined for internal servers and 10,000 jobs destined for servers external to the work unit. Additionally, both scenarios had job service times exponentially distributed with a mean of 5 microseconds. The differences in simulation parameters ensured significant differences of work in each work unit lease. A total of 42 processors consisting of heterogeneous architectures were used in this performance evaluation. 16 processors in two compute nodes were comprised of 8-way 550MHz Pentium III machines with 4 GB of memory per node and the remaining 26 processors were Pentium Xeon 3.06GHz SMT enabled processors across 13 nodes with 1 GB of memory per node. The Aurora back-end was run on three Pentium Xeon 2.8GHz machines with 4 GB of memory each. All machines were running RedHat Linux and had Fast Ethernet among each set of similar processors, but on disparate LANs between machine types. The back-end setup for the Coarse and Fine scenario contained 1 work unit state server and 1 message state server whereas the Fine (2) scenario used 1 work unit server and 2 message state servers. For the figures below, deferred refers to the amount of wallclock time (seconds) a worker spends waiting for a valid work unit lease from the back-end. Import indicates to the amount of time the worker downloads work unit metadata, work unit state vectors, messages and the associated time spent in the applicationdependent deserialization routine. Finalize is the time to perform the logical inverse of import where the work unit state and messages are serialized and consistency convergence is achieved on the back-end services for the returning work unit. Application is the time spent executing application simulation code. The overheads for the coarse and fine-grained simulations are detailed in Figure 3. As expected, the coarse-grained simulation incurred much less overhead than the fine-grained simulations. For the fine-grained simulations, the majority of the time spent is in the work unit overheads, most notably the work unit finalization and import. With an additional message state server available, we can observe a reduction in overhead time in the Fine (2) scenario. Figure 4 details the global event throughput for each of the scenarios. Although the coarse-grained simulation was expected to have higher event throughput than the finegrained simulations due to less overhead, the Fine (2) scenario showed gains through the addition of only one more message state server resulting in a 53% increase in event throughput. 4. Concluding Remarks Cloud computing offers the promise of outsourcing the task of providing and managing execution platform to users while hiding many of the complicated details of PDES execution. SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 8 of 10

9 As such, it offers the possibility of making parallel and distributed simulation technology much more readily accessible to the simulation community. As cloud computing environments become more common, their use for parallel and distributed simulations become more attractive. Figure 3. Processor time breakdown In this article, we attempted to highlight some of the benefits and important challenges associated with executing parallel and distributed simulation in cloud environments, and suggested some possible solutions that have been implemented and observed. This work only represents an initial step in executing parallel and distributed codes in cloud computing environments. There are many avenues for future research. As noted earlier, use of the cloud for interactive parallel and distributed simulations is an open area of study. Experience with simulation application codes in cloud environments is limited, and development frameworks and tools are needed. Security and reliability issues merit greater attention. A mechanism for auto tuning parallel and distributed codes to improve the convenience for users is an area that will require further study. The interaction of fault tolerance mechanisms with the parallel and distributed simulation execution requires further study. Acknowledgement This research was funded in part by NSF Grant ATM Figure 4. Event throughput References Anderson, D. P., J. Cobb, et al. (2002). "SETI@home: an experiment in public-resource computing." Communications of the ACM 45: Armbrust, M., A. Fox, et al. (2009). Above the Clouds: A Berkeley View of Cloud Computing. Berkeley, CA, Electrical Engineering and Computer Sciences, University of California at Berkeley. Aymerich, F. M., G. Fenu, et al. (2008 ). An Approach to a Cloud Computing Network. First International Conference on the Applications of Digital Information and Web Technologies, ICADIWT Cai, W., S. J. Turner, et al. (2002). A load management system for running HLA-based distributed simulations over the grid. Proceedings of the Sixth IEEE International Workshop on Distributed Simulation and Real-Time Applications, Fort Worth, TX. Chen, D., S. J. Turner, et al. (2006). A Framework for Robust HLA-based Distributed Simulations. International Workshop on Principles of Advanced and Distributed Simulation, Singapore. Cholkar, A. and P. Koopman (1999). A widely deployable Web-based network simulation framework using CORBA IDL-based APIs. Proceedings of the 31st conference on Winter simulation: Simulation---a bridge to the future - Volume 2. Phoenix, Arizona, United States, ACM Press. SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 9 of 10

10 D Ambrogio, A. and D. Gianni (2004). Using CORBA to Enhance HLA Interoperability in Distributed and Web-Based Simulation. Computer and Information Sciences: Dean, J. and S. Ghemawat (2008). "MapReduce: simplified data processing on large clusters." Communications of the ACM 51(1). Ekanayake, J. and G. Fox (2009). High Performance Parallel Computing with Clouds and Cloud Technologies. Bloomington, IN, Department of Computer Science, Indiana University. Fitzgibbons, J. B., R. M. Fujimoto, et al. (2004). IDSim: an extensible framework for Interoperable Distributed Simulation. Proceedings of the IEEE International Conference on Web Services, San Diego, CA. Fujimoto, R. (2000). Parallel and Distributed Simulation Systems, Wiley Interscience. Fujimoto, R. M. (1990). "Parallel discrete event simulation." Communications of the ACM archive 33(10): Fujimoto, R. M., A. Park, et al. (2007). Towards Flexible, Reliable, High Throughput Parallel Discrete Event Simulations. Cooperative Research in Science and Technology (COST) Symposium on Modeling and Simulation in Telecommunications. Haifeng, G., P. Galligan, et al. (2005). The Application of Utility Computing and Web- Services to Inventory Optimisation. Proceedings of the 2005 IEEE International Conference Services Computing (SCC 05). 2: Hewitt, C. (2008). "ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing." Internet Computing, IEEE 12(5): Huang, Y., X. Xiang, et al. (2004). A Self Manageable Infrastructure for Supporting Webbased Simulations. Proceedings of the 37th annual symposium on Simulation. Arlington, VA, IEEE Computer Society. Lizhe, W., T. Jie, et al. (2008). Scientific Cloud Computing: Early Definition and Experience. 10th IEEE International Conference on High Performance Computing and Communications, HPCC. Pan, K., S. J. Turner, et al. (2007). A Service Oriented HLA RTI on the Grid. Web Services, ICWS IEEE International Conference on. Pullen, J. M., R. Brunton, et al. (2005). "Using Web services to integrate heterogeneous simulations in a grid environment." Future Gener. Comput. Syst. 21(1): Reichenthal, S. W. (2002). Re-introducing web-based simulation. Proceedings of the 34th conference on Winter simulation: exploring new frontiers. San Diego, California, Winter Simulation Conference. Walker, E. (2008). "Benchmarking Amazon EC2 for High Performance Scientific Computing." from Wang, Y. (2004). On autonomous computing and cognitive processes. Third IEEE International Conference on Cognitive Informatics, IEEE. Xie, Y., Y. M. Teo, et al. (2005). Servicing Provisioning for HLA-Based Distributed Simulation on the Grid. Proceedings of the 19th Workshop on Principles of Advanced and Distributed Simulation. Monterey, CA, IEEE Computer Society. Richard Fujimoto is a Regents Professor and Chair of the School of Computational Science and Engineering at the Georgia Institute of Technology. He received his M.S. and Ph.D. degrees from the University of California (Berkeley) in 1980 and 1983 respectively. He has published over 200 articles on parallel and distributed simulation. Among his past activities he led the definition of the time management services for the DoD High Level Architecture (HLA). Asad Waqar Malik is a PhD candidate at National University of Science and Technology (NUST), Pakistan. He received his MS in Software Engineering and Bachelor of Computer Science degrees from NUST and Hamdard University respectively. He has been working in the distributed simulation field since He also worked as an international scholar at Georgia Institute of Technology. He has five international conference publications. His research interest includes real time decision support system, distributed simulation, and C4I systems. Alfred Park is a postdoctoral research scientist at IBM T.J. Watson Research Center at Yorktown Heights, New York. He received his BS, MS and PhD in Computer Science from the Georgia Institute of Technology in 2002, 2004 and 2009 respectively. His interests are in large scale stream processing systems, high performance computing, metacomputing, and parallel and distributed simulation. SCS M&S Magazine 2010 / n3 (July) Fujimoto et al - Page 10 of 10