Guidelines for Running HPC Applications on Azure Nodes
Updated: January 13, 2014
Applies To: Microsoft HPC Pack 2008 R2, Microsoft HPC Pack 2012, Microsoft HPC Pack 2012 R2, Windows HPC Server 2008 R2
This topic provides guidelines for running applications on Windows Azure nodes. This information applies to Windows Azure nodes that are added to an on-premises Windows HPC cluster (a Windows Azure “burst” scenario), or to nodes that are deployed as part of a Windows Azure service that uses the Windows Azure HPC Scheduler (Windows Azure only).
In this topic:
For additional considerations for MPI jobs, see Guidelines for Running MPI Applications in Azure.
For information about deploying applications to Azure Nodes, see Deploying Applications to Azure Nodes in a Windows HPC Cluster.
|Starting with Service Pack 3 of Microsoft® HPC Pack 2008 R2, you can run the hpcpack and hpcsync command utilities without using administrator credentials. These utilities help move files to and from Windows Azure HPC nodes and Windows Azure storage. You can run these as part of your job to stage data and save results, for example as Node Preparation and Node Release tasks.|
Windows Azure worker nodes cannot access on-premises nodes, shares, and license servers without additional setup (for example by using Windows Azure Virtual Network). You can work with your cluster administrator to package input data with your executable or separately and upload it to the Windows Azure nodes (for more information, see Deploying Applications to Azure Nodes in a Windows HPC Cluster). Alternatively, you can stage data to Windows Azure storage and use the hpcpack download command utility or the Windows Azure APIs to bring data to the nodes. You can also mount a VHD file as a drive directly from the Windows Azure storage account. For more information about moving input and output files in a Windows Azure node deployment including code samples and a sample file moving utility, see Windows HPC with Burst to Windows Azure: Application Models and Data Considerations.
Local storage on Windows Azure worker nodes is not persistent. When the nodes instances are stopped and then restarted on a different hardware node, the data stored in local storage does not follow the role instance. If your application writes results to disk, include a clean-up task to copy files to a persistent storage location, either on-premises (if enabled) or in the cloud (on Windows Azure storage). Starting with Service Pack 3 of HPC Pack 2008 R2, you can run the hpcpack upload command from your Windows Azure HPC nodes to save files to Windows Azure storage. For more information about moving input and output files in a Windows Azure Node deployment including code samples and a sample file moving utility, see Windows HPC with Burst to Windows Azure: Application Models and Data Considerations.
Applications that do not require licenses such as open-source or in-house applications can run on Windows Azure nodes with no additional configuration or considerations. However, many applications require software licenses, and depending on the licensing model, you might encounter the following issues:
Licenses are often managed by an on-premises license server, and enabling Windows Azure nodes to access on-premises resources requires additional configuration steps.
Starting with HPC Pack 2012, you can create a connection to an on-premises license server by using Windows Azure Virtual Network. For more information, see Understanding Azure Virtual Network for Azure Node Deployments with Microsoft HPC Pack.
Many licenses are issued based on a MAC address, but MAC addresses are not stable in Windows Azure. The MAC address for your Windows Azure nodes can change every time a node is reprovisioned.
Talk with your ISV about an alternative license model.