Accessing the cluster running on Azure from on-site machines

All replies

• 

  

  0

  Sign in to vote

  Hi KWilliams1,

  Runing SOA workload (and Excel as well) on an Azure IaaS cluster from on premise clients is a well supported scenario since HPC Pack 2012 R2 Update 2 release. For details, please check this blog out, especially in Step 3. "Run a SOA workload from an on-premises client".

  Basically, it requires the head node share the same machine name and cloud service name and take the broker node role. The certificate generated should be imported on the client machine for HTTPS connection, and the Azure storage connection string should be set on the cluster if Azure storage queues/blobs are utilized to transfer the request/response messages.

  Then on the SOA client, use 'MyHeadNode.cloudapp.net' as the input string for SessionStartInfo, and remember to use default binding (basicHttpBinding) when creating the BrokerClient, e.g. using (BrokerClient<IService1> client = new BrokerClient<IService1>(session)).

  BR,

  Yutong Sun

  
  
  

  • Edited by Yutong SunMicrosoft employee Tuesday, December 1, 2015 2:30 AM
  • Marked as answer by KWilliams1 Wednesday, January 6, 2016 5:30 PM

  Tuesday, December 1, 2015 2:28 AM
• 

  

  0

  Sign in to vote

  Hi Yutong Sun,
  
  Thank you for your suggestions.
  
  We went through the procedure outlined below, which corresponds to one of those described in the blog article reference you provided.

  1. We first created a cluster on Azure using the HPC Pack IaaS Deployment script 4.5.0 ran from a PowerShell console. The configuration file and post-configuration script suggested in the article were used, the only difference being the number of compute nodes that was set to 2 in order to save time and resources.
     
     
  2. The cluster certificate was imported to the Certificates - CurrentUser\Trusted Root Certification Authorities store using the MMC.
     
     
  3. The HelloWorldR2 sample code was installed and modified according to sub-section Use Http binding with Azure storage queue in the article.
     
     
  4. When launching the HelloWorldR2 client project, we get the following error at line using (DurableSession session = DurableSession.CreateSession(info)):
     
     Message=Unknown error occurred: The remote server returned an error: (403) Forbidden..
     Source=Microsoft.Hpc.Scheduler.Session
     
     Note #1: When going to the head node through RDP and starting the HPC Cluster Manager, we can see that the job request has been received but could not be executed:
     Job Name: EchoService - WCF service
     State: Failed
     Error Message: Job failed to start on some nodes or some nodes became unreachable
     
     Note #2: When attempting to list all the cluster's jobs using job list /scheduler:https://headnodednsname.cloudapp.net /all in a Command prompt, as explained in Submit HPC jobs from an on-premises computer to an HPC Pack cluster in Azure, the command succeeds and lists all the failed EchoService jobs. As expected, removing the cluster certificate from the store causes the same command to fail with message The server certificate needs to either have a valid chain of trust or to be placed in the trusted root store.
     
     

  It therefore seems that we can reach the head node but no job can be successfully submitted to it.

  Any suggestions would be very much appreciated.

  Thank you.

  
  
  
  
  

  • Edited by Marc_Simard Saturday, December 19, 2015 10:32 PM

  Friday, December 18, 2015 11:28 PM
• 

  

  0

  Sign in to vote

  Hi Marc_Simard,

  The 403 Forbidden error when creating session from on-premise client to the IaaS cluster using Azure queue storage is probably caused by the access issue for the Azure storage e.g. incorrect access key for the Azure storage account. Could you please double check if the correct storage key and account are set via the following two ways:

  1. Using HPC Powershell Cmdlet: (this can be done in the post-configuration PostConfig.ps1)
  

  Set-HpcClusterProperty -AzureStorageConnectionString 'DefaultEndpointsProtocol=https;AccountName=<yourstorageaccountname>;AccountKey=<yourstorageaccountkey>'
  

  2. Open HPC Cluster Manager on the head node, click Configuration -> Deployment To-do List -> Set Windows Azure storage connection string, and input the correct storage key and account
  

  DefaultEndpointsProtocol=https;AccountName=<yourstorageaccountname>;AccountKey=<yourstorageaccountkey>

  Hope this helps.

  Merry Christmas and Happy New Year!

  
  

  BR,

  Yutong Sun
  

  
  

  
  

  Friday, December 25, 2015 2:46 PM
• 

  

  1

  Sign in to vote

  Hi Marc,
  
  According to the follow up investigations, we found that the issue was caused by using Username without Domain name when creating the SOA session. For the Azure HPC cluster, there happen to be a local administrator which was added before joining the domain. That's why creating the session succeeded with the Username, while coming request messages were denied by the broker afterward. It is always a good practice to use [Domain]\[Username] instead of only [Username] for SOA sessions on HPC Pack clusters.
  
  Also a side note, the credential for the SOA sessions are stored in the Windows Credential Vault (Control Panel\User Accounts\Credential Manager -> Windows Credentials) on the client machine once remembering the password is confirmed from the command line prompt. The credential can be removed from the vault, then the next time when creating a session without the info.Username and info.Password specified, the command line prompt would pop up again asking for the correct credential.

  Post it here for future reference.
  

  BR,
  Yutong Sun
  
  

  • Proposed as answer by MarcSim Wednesday, January 6, 2016 4:25 PM
  • Marked as answer by KWilliams1 Friday, June 10, 2016 4:46 PM

  Wednesday, January 6, 2016 4:35 AM