Export (0) Print
Expand All

Overview of the Windows Azure HPC Scheduler

Updated: April 17, 2013

This topic provides an overview of the sample Windows Azure service that includes the Windows Azure HPC Scheduler and of the features that are included in the Windows Azure HPC Scheduler SDK that enable this type of deployment. You can also watch a video that introduces the code sample; see Windows Azure HPC Scheduler Code Sample: Overview.

In this topic:

For steps to build and publish the sample service, see the Getting Started with Application Deployment with the Windows Azure HPC Scheduler.

Overview of the sample Windows Azure service

The sample Windows Azure service is intended to help you explore how to package your applications within a Windows Azure HPC Scheduler deployment. When you build and run the sample in Visual Studio (specifically, when you run the AppConfigure project), you can provide your Windows Azure subscription ID and other administrative information such as what you want to call your cloud service, storage account, and scheduler deployment. When you click Publish (in the UI for AppConfigure), the sample application will create a deployment in Windows Azure. The topology that this service deploys into Windows Azure includes a SQL Azure database to store state information about the job queue and resource configuration, a head node to schedule jobs and support SOA workloads, a web-front end node to provide a web-based job submission portal (the Windows Azure HPC Scheduler Portal), and one or more compute nodes to run jobs. The sample service deploys a SOA service and client to the head node and an MPI application to the compute nodes.

The following diagram illustrates the sample deployment:

Sample deployment with Windows Azure Scheduler

You can monitor the progress of the deployment in the Windows Azure Management Portal. After the deployment is up and running, you can submit some sample jobs using the Windows Azure HPC Scheduler Portal, or by initiating a remote desktop connection to the head node and using the HPC Job Manager.

The following diagram illustrates some ways that you can interact with the sample deployment:

Interact with sample Windows Azure Scheduler app

The Windows Azure HPC Scheduler tools

To set up a hosted service in Windows Azure, you create a service model which defines the role types and service topology. The service model consists of a ServiceDefinition.csdef file and a ServiceConfiguration.cscfg file. ServiceDefinition.csdef specifies the settings that are used by Windows Azure to configure a cloud service (such as the type of role that you want to deploy). ServiceConfiguration.cscfg specifies configuration values for your roles (such as how many instances of each you want to deploy).

The Windows Azure HPC Scheduler SDK includes plug-ins that you can import through the ServiceDefinition.csdef file. These plug-ins import functionality such as scheduling and runtime support for parallel workloads. Each HPC Scheduler plug-in has corresponding elements that must be specified in the ServiceConfiguration.cscfg file. The Windows Azure HPC Scheduler SDK includes the ClusterConfig class that helps you define values for the scheduler settings and operate on the ServiceConfiguration.cscfg file. The plug-ins and the ClusterConfig class are described in the following two sections.

Adding the plug-ins for the Windows Azure HPC Scheduler to the .csdef file

The Windows Azure HPC Scheduler SDK provides plug-ins that you can import through the ServiceDefinition.csdef file. These plug-ins let you add functionality and runtime support to your Windows Azure roles. In the sample application, we define three types of roles as described in the following list:

  • Head node: This is a Windows Azure worker role with the HpcHeadNode plug-in added. The HpcHeadNode plug-in provides job scheduling and resource management functionality.

  • Compute node: This is a Windows Azure worker role with the HpcComputeNode plug-in added. The HpcComputeNode plug-in provides runtime support for MPI and SOA. This plug-in also includes built-in management features that allow the workload to be managed by an instance that is running the HpcHeadNode module.

  • Front end: This is a Windows Azure web role with the HpcWebFrontEnd plug-in added. The HpcWebFrontEnd plug-in provides a built-in web portal an HTTP web service (based on the REST model) to provide job submission interfaces to the Windows Azure HPC Scheduler.

The following example shows how these roles are defined in the ServiceDefinition.csdef for the sample application.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="AzureSampleService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-05.1.7">
  <WebRole name="FrontEnd" vmsize="Small">
      <Site name="Web">
        <VirtualApplication name="Portal" physicalDirectory="C:\Program Files\Windows Azure HPC Scheduler SDK\v1.7\hpcportal" />
          <Binding name="HPCWebServiceHttps" endpointName="Microsoft.Hpc.Azure.Endpoint.HPCWebServiceHttps" />
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
      <Import moduleName="Diagnostics" />
      <Import moduleName="HpcWebFrontEnd" />
      <Import moduleName="RemoteAccess" />
  <WorkerRole name="HeadNode" vmsize="Small">
      <Import moduleName="Diagnostics" />
      <Import moduleName="HpcHeadNode" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
  <WorkerRole name="ComputeNode" vmsize="Small">
      <Import moduleName="Diagnostics" />
      <Import moduleName="HpcComputeNode" />
      <Import moduleName="RemoteAccess" />

For a list of the plug-ins that are available in the Windows Azure HPC Scheduler SDK, see Things to Know About the Windows Azure HPC Scheduler. You can use these plug-ins to help create a deployment topology that is suited to your application.

Support for the HpVmNode plug-in in the Windows Azure HPC Scheduler is deprecated. The VM Role feature (beta) of Windows Azure is being retired on May 15, 2013.

Configuring the roles in the .cscfg file

Each Windows Azure HPC Scheduler plug-in that you add to the ServiceDefinition.csdef file has corresponding elements in the ServiceConfiguration.cscfg file. These elements are added automatically when you import a scheduler plug-in into a service role (if you are using Visual Studio). You can view these in Visual Studio by looking at the ServiceConfiguration.cscfg file for the Windows Azure service.

For example, the following screen shot illustrates some of these configuration elements. Notice the settings that are added from the Microsoft.Hpc.Azure namespace.

Windows Azure HPC Scheduler elements in cscfg file

These elements in the ServiceConfiguration.cscfg file define settings for the role. For example, all nodes in the deployment need the configuration file to specify values such as the name of the hosted service, the administrator account, the data connection string, and which role is hosting the scheduler. Additionally, each scheduler plug-in has some required modules and some optional modules that are enabled in the ServiceConfiguration.cscfg file. For example, the head node must have the scheduler and node modules enabled, and can optionally have the session and broker modules enabled to support SOA workloads.

The Windows Azure HPC Scheduler SDK includes the ClusterConfig class that helps you define values for the scheduler settings and operate on the ServiceConfiguration.cscfg file. This class automatically enables the required modules for each plug-in, and provides methods that you can call to enable additional modules. For example, to enable the correct modules to support SOA workloads, you can call the EnableSOA method.

You can also use ClusterConfig to insert user account information into the appropriate places in the ServiceConfiguration.cscfg file. Rather than inserting the values manually in multiple places in the XML, you can set these values as properties of the ClusterConfig class. For example:


After specifying the required values and calling any optional methods, you can then call the Generate method. This method takes your original ServiceConfiguration.cscfg file as input, and then generates a new .cscfg file that includes all the scheduler values. The output file also preserves any values that you specified for other plug-ins and other customer settings.

The basic steps for using ClusterConfig are as follows:

  1. Create an instance of the ClusterConfig class

  2. Specify the ServiceDefinition.csdef file for your service

  3. Set user account information

  4. Optionally, enable the SOA module

  5. Generate the ServiceConfiguration.cscfg file

The following example illustrates the basics of how to use ClusterConfig.

In the AzureSampleService, the configuration file is generated by CreateCscfgFile (in the AppConfigure project). That example is more complex than the following code example because it includes error handling, and it also takes the values for the account information from a file named appConfigure.exe.config. appConfigure.exe.config is used to store the input values that you provide in the sample user interface (this file is created in the AzureSampleService\AppConfigure\bin\Debug folder).

            ClusterConfig config = new ClusterConfig();



            // Fill in the Windows Azure account information.
            config.SubScriptionId = new Guid("{<mySubscriptionID>}");
            config.ServiceName = "myHostedService";
            config.SetStorage("myStorageAccount", "<myPrimaryAcessKey>");

            // Fill in the SQL Azure account information.
            config.DBServer = "myAzureServerName";
            config.DBUser = "Admin";
            config.DBPassword = "!!123abc";
            config.DBName = "myDBName";

            // Fill in the certificate thumbprints.
            X509Certificate2 cert = CertificateHelper.LoadCert(@"myCert.pfx", "!!123abc");
            config.AddCertificate("Microsoft.Hpc.Azure.Certificate.SSLCert", cert);
            config.AddCertificate("Microsoft.Hpc.Azure.Certificate.PasswordEncryptionCert", cert);

            // Override some preconfigured settings.
            config.ClusterName = "myCluster";

            // Set up the built-in cluster admininstrator account.
            config.ClusterAdmin = "Admin";
            config.ClusterAdminEncryptedPassword = CertificateHelper.EncryptWithCertificate("!!123abc", cert);

            // Write the configuration to a file.
            // If the file already exists, merge the HPC settings with the settings in the 
            // file. Set the 2nd parameter to false if you want the program to check whether 
            // all of the settings are set, in which case the Generate method throws an 
            // exception if any setting is not set.
            config.Generate("input.cscfg", "output.cscfg");

Including the application binaries in the deployment

When you define your Windows Azure deployment, you can specify which roles should include your application binaries. For example, the sample service deploys a SOA service and client to the head node and an MPI application to the compute nodes.

Each of the defined roles in the sample has a project file within the Visual Studio solution. To include your application binaries on a role, the application binaries need to be built to the bin folder for that role. For example, the following screenshot illustrates the contents of the ComputeNode\Bin\Debug folder after building the sample solution. The folder includes the files for a sample MPI application (Bakery).

Application files built to the ComputeNode project

There are different methods for including your binaries in the bin folder for a role, and the sample service demonstrates two methods: redirecting the output directory for your application project, and adding your application as a reference in one or more role projects.

In the sample service, the MPI application (Bakery) only needs to be deployed to the compute node instances. In this case, we configured the output directory of the Bakery project to build the binaries to the compute node folder, as illustrated in the following screenshot.

Set build dir to add binaries to computeNode role

Alternatively, you can add a reference to your application in the references section of one or more role projects. In the sample service, the SOA client and service (SOAHelloWorldAzure and SOAHelloWorldAzureClient) are included as references in the HeadNode project. The following screenshot illustrates that the SOA client and service are included in the references for the HeadNode project (in the Solution Explorer pane in Visual Studio).

Add app reference in Visual Studio to role project

See Also

© 2014 Microsoft