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

Size Matters

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.

Small Data

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.

Big Data

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.

First Iteration

• 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

  • Tixel

  • Aspera

• Optimize access by proactive distribution if possible. Here settled paradigms of work will have to be overcome.

Second Iteration

• 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.

  • Federation

  • 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.