Guidelines for Running HPC Applications on Azure Nodes
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).
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.
Tip
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.
Providing input data
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.
Persisting your output data
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.
Application license 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:
| Issue | Workaround |
|---|---|
| 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. |
See Also
Burst to Azure Worker Instances with Microsoft HPC Pack
Deploying Applications to Azure Nodes in a Windows HPC Cluster