October 02, 2012
At ISC Cloud 2012, talking points for the Birds of a Feather sessions were hand-picked by the participants. While the importance of security was a key theme throughout the two-day event, several other salient topics emerged during the voting process. The finalized BoF roster included "Applications and software in the cloud," "HPC Cloud Reference Architectures" and "Data Transfer in/out of Clouds" to be held in parallel. Each group had about 10-15 participants discussing the challenges and implications of their chosen topic. After the conference, the panel moderators each submitted their notes on their findings.
BOF 1: Applications/Software in the Cloud
Moderator: David Wallom, Oxford eResearch Centre
The discussion was started with the consideration of how cloud computing could change the supply of application software with the possibility of ISV partnering with cloud providers to change the delivery model. This would allow application flexibility, but it was pointed out that there is an inherent unpredictability of a pay-as-you-go (PAYG) model. It may be an issue for those groups that have been previously subjected to a fairly stable cost model, though in many other areas PAYG is becoming more normal. A problem is that in current IaaS cloud models, costing is not simple and there may be resistance to the introduction of new business models from long-term users.
It was pointed out that it isn't just the end-user applications but also all other components. An illustration of PAYG for areas other than end-user applications, which clearly shows one of the problems with other models is where LSF is an annual license, even though it may only be required a few times (less than 10).
With this change of model, how do we support the legacy application? This will depend on the type: Community applications that are open source will have to rely on their community and commercial applications will require their users to 'gang up' as it were. However, there are problems with a SaaS delivery mechanism since there could be resultant legacy version support required as many commercial customers want longevity. Over the longer term, cloud migration means users will have to be more used to version migration, and if so, application providers will have to make sure version migration is easier.
The level of cloud utilization will depend on the different application communities and different maturities of software. The possibility of flexibility is strongest where software is newest, i.e., application users do not favor one model over another. It is unlikely that cloud will affect the application design model to change MPI, and thus OpenMP will still need to be supported. On a longer term, the different types of interconnection software (MPI/OpenMP) won't matter as the hardware will catch up with newer ideas.
We mustn't forget that software isn't just the application but also the networks that exist around it: Community-as-a-Service and Support-as-a-Service.
Of course, less data means that it is easier to move to the cloud, but if you can do more operations on your data in the cloud then this becomes less important, for example, only downloading the important result although this may require workflow in the cloud.
With the emergence of standard APIs for different components, the time is right for application designers to accept these changes in models by moving to the most advantageous cloud provider. We must ensure that application designers learn lessons from the previous instances where public cloud providers changed their models and made previous design decisions irrelevant or less than optimal.
It is a whole ecosystem. Remember that:
The user decides on the software that best solves their problem. End users don't care, and they just want solutions.
Hardware licensing versus software licensing costs can be decisive.
Optimization for many different types of use cases can lead to different types of hardware solutions.
Cloud provider chooses hardware, software, interconnects, .i.e., the most efficient solution.
Community clouds targeted to different communities are not inevitable but likely as different ISV and communities get together to best optimize their requirements and solutions together.
Whatever use of cloud or otherwise we decide on has to fit with other parts of the business model/activity.
Cloud providers have the opportunities to get away from unnecessary user complications and also support their users with new models. There are good opportunities for long term relationships between ISV and cloud providers.
Finally the difference between the cloud and Application Service Provider (which we have had for around ten years) was discussed. It was brought to light that the quality/ubiquity of the network resources and the sheer number of resource types have changed.
BOF 2: Reference Architecture
Moderator: Josh Simons, VMware
Two basic models for moving HPC workloads into a cloud environment:
1. Virtual clusters formed by creating a persistent set of virtual machines on demand. Each virtual machine runs the same software stack (OS, libraries, batch scheduler, etc.) as was used in a bare-metal environment. This is desirable because from an end-user/scientist perspective, the interface to the compute interface remains the same: they use the same batch scheduler interfaces. The use of virtual machines is transparent to the end-user.
2. Virtual machines are created on demand to run each job and they persist only for the lifetime of the job. This allows each job to run with its own custom software stack, for individual jobs to be migrated dynamically across the virtual infrastructure for load-balancing, resiliency, or power management. This is not an evolutionary model in that the end-user would need to interact with either a new software layer that understands how to launch VMs rather than scheduling onto existing cluster nodes. This could be an entirely new layer or an augmented version of existing job schedulers.
It was noted that hybrids of the above two approaches could be used as well.
The following components were identified as being critical pieces of reference architecture for HPC in the cloud. (Not an exhaustive list.)
Self-service capabilities to enable end-users to create clusters on the fly.
A catalogue of virtual machines and software stacks that can be used to create these virtual clusters.
A provisioning engine to instantiate these virtual machines (it was noted that Open Stack work on "placement groups" is relevant).
An ability to elastically flex compute resources up and down as needs change.
A monitoring component to watch the health and performance of the infrastructure.
Billing and chargeback.
Data staging components – to move data in and out of the cloud.
Policy-based resource control mechanisms to mediate access to hardware resources between multiple cloud tenants.
Security – data security and protection and secure isolation of workloads in a multi-tenant environment.
It was noted that a "cloud" might not be virtualized, though virtualization was seen to make a number of the above functions easier to deliver.
It was posited that once HPC moves into the cloud, there will be a need to support complex applications that require cross-cloud workflows, similar to some of the meta-computing concepts developed within the grid computing realm. It was noted that if "cloud" is the follow-on to grid computing, then it would be useful to examine grid architectures closely, to determine which features should be brought forward into mainstream cloud architectures.
There are problems still to be solved if HPC is to move into the cloud. Some are technical – end-to-end automation of the use of HPC in the cloud. Others are business related: licensing, politics, and budgetary. The budgetary issue is particularly interesting: In the face of "unlimited" compute resources, how does an organization control access to limit its budgetary spend? This is particularly important for HPC workloads, which as we know can consume all available resources at a site. What happens when such users get access to unlimited resources in the cloud? Answering these questions will likely uncover additional required components for an HPC cloud reference architecture.
BOF 3: Data Transport
Moderator: Rolf Sperber, Alcatel-Lucent
There has to be a differentiation concerning the size of datasets to be transported in and out of the cloud. The target is optimized access – it can be achieved for small amount of data if there is a predictable way of accessing required data or moving data in or out of the cloud. For large datasets to be transported, the quality of service will have to be guaranteed for longer periods of time.
To have instant access to data in a cloud, current metadata will not be sufficient. A software that has knowledge of the network infrastructure and defines a virtual network on demand is required. Multiple carrier and in consequence multiple vendor environments will have to be taken into account.
This is about huge datasets to be transported over long distances. Final target is to have predictable transfer times for multiple datasets to be transported to a single location.
Federation of folders into a single folder with a metadata server to keep track of size, locality, etc.
Optimize transport by means of adequate transfer software. Here we are talking about software products (most of them commercial) that help solve the TCP problem
Optimize access by proactive distribution if possible. Here settled paradigms of work will have to be overcome.
Optimize transport requirements with respect to site of computation.
Provide network control to enable clients to define an appropriate virtual network.
Multiple carriers with heterogeneous environments to be taken into account.
Charging models to be implemented.
Third iteration or Target
Further optimize applications to minimize transport requirements.
Integrate network control into applications.
Software defined networking taking care of both dedicated instance of time when transfer starts and duration of transfer in relation to size.
SDN calculating both routes and time of reservation.
SDN calculating total duration.
Jun 17, 2013 |
With that in mind, Datapipe hopes to establish themselves as a green-savvy HPC cloud provider with their recently announced Stratosphere platform. Datapipe markets Stratosphere as a green HPC cloud service and in doing so partnering with Verne Global and their Icelandic datacenter, which is known for its propensity in green computing.
Jun 12, 2013 |
Cloud computing is gaining ground in utilization by mid-sized institutions who are looking to expand their experimental high performance computing resources. As such, IBM released what they call Redbooks, in part to assist institutions’ movement of high performance computing applications to the cloud.
Jun 06, 2013 |
The San Diego Supercomputer Center launched a public cloud system for universities in the area designed specifically to run on commodity hardware with high performance solid-state drives. The center, which currently holds 5.5 PB of raw storage, is open to educational and research users in the University of California.
05/10/2013 | Cleversafe, Cray, DDN, NetApp, & Panasas | From Wall Street to Hollywood, drug discovery to homeland security, companies and organizations of all sizes and stripes are coming face to face with the challenges – and opportunities – afforded by Big Data. Before anyone can utilize these extraordinary data repositories, however, they must first harness and manage their data stores, and do so utilizing technologies that underscore affordability, security, and scalability.
04/02/2012 | AMD | Developers today are just beginning to explore the potential of heterogeneous computing, but the potential for this new paradigm is huge. This brief article reviews how the technology might impact a range of application development areas, including client experiences and cloud-based data management. As platforms like OpenCL continue to evolve, the benefits of heterogeneous computing will become even more accessible. Use this quick article to jump-start your own thinking on heterogeneous computing.