微软SOA介绍

 

 

To initiate a session on the cluster, the client application calls the CreateSession method. When calling this method, the client application specifies the head node name and the service name. Optionally, the client application can specify information such as the job template to use, the priority level, the number of required resources, and the resource type (node, socket, or core). This information can be specified in the SessionStartInfo object. With this information, CreateSession submits a job to the head node that includes a Service task. The Service task includes a command to start the service host and load the specified service.

When the head node receives the SOA job from the client, the following interactions occur:

• The HPC Job Scheduler Service validates the job, applies default values for job properties as defined by the job template, and adds the job to the queue. cx
• When resources are available, the HPC Job Scheduler Service allocates resources to the job, and it runs an instance of the Service task on each allocated resource. This starts the service host and loads the service DLL on the allocated compute nodes, so the service is ready to accept requests.
• The HPC Session Service sends the client a list of available WCF broker nodes. The CreateSession method attempts to connect to a broker node on the list. A broker node accepts the connection from the client, and the HPC Broker Service creates a broker instance (also known as worker process) to manage the session.
• The client sends requests directly to the broker instance on the WCF broker node.
• The broker instance detects the allocated service hosts from the running service task and begins sending service requests.
• The broker instance passes requests and responses between the client and the service hosts.
• If the client created a durable session, the broker uses Message Queuing to store all messages. Responses that are stored by the broker can be retrieved by the client at any time, even after intentional or unintentional disconnect.

Note: The HPC Job Scheduler Service and the broker instance work together to adjust the number of allocated service hosts periodically based on resource availability and the number of outstanding requests. 

The following diagram illustrates this interaction.

 

 

Broker nodes and session behavior：

The WCF broker nodes manage sessions on the cluster. The HPC Broker Service runs on the WCF broker nodes and listens for requests from client applications. HPC Broker Service creates a broker instance for each session. The broker instance manages and monitors the session as follows:

• Creates an end point for the application traffic for that session.
• Finds out from HPC Session Service which service hosts are allocated to the job.
• Accepts requests from the client.
• Distributes requests across the allocated service hosts.
• Collects responses from the service hosts and sends them to the client.  
• Stores requests and responses using Message Queuing if the session is a durable session, so that work is not lost in case of interrupted connections with the client.
• Monitors the number of incoming requests and helps adjust resource allocation (grow/shrink) by setting and maintaining the Target Resource Count property for the job.
• Monitors service loading failures, and maintains the Excluded Nodes property for the job.
• Retries up to the specified number of times in the case of message failure.

The session handling behavior (such as timeouts and error handling) can be adjusted through the settings in the service configuration file. This means that the broker nodes can handle different services in different ways.

A subset of the broker monitoring settings can also be defined by using the SessionStartInfo.BrokerSettingsInfo class when the client application creates a session. Values provided in the SessionStartInfo.BrokerSettingsInfo class override the values that are specified in the service configuration file. For more information, see SessionStartInfo.BrokerSettingsInfo (http://msdn.microsoft.com/en-us/library/microsoft.hpc.scheduler.session.sessionstartinfo.brokersettingsinfo(VS.85).aspx).

 

The HPC Job Scheduler Service and SOA sessions：

The HPC Job Scheduler Service runs on the head node. This service maintains the job queue, allocates cluster resources to jobs, and starts tasks on the head node.  The HPC Job Scheduler Service can run in one of two modes: Queued or Balanced. Queued mode is optimized for MPI and batch jobs, Balanced mode is optimized for interactive workloads. For more information, see the 错误!未找到引用源。section in this document.

The cluster administrator can define job templates to control the allowable job properties for job types or user sets.  Job properties include priority level and requested resources. When you are creating a client application, it is a good practice to check with the cluster administrator regarding specific job templates that should be used to start a session on the cluster, or provide a way that the end-user can specify an appropriate job template.  For more information, see the 错误!未找到引用源。 section later in this document.

When an SOA client application calls the CreateSession method, a job that includes a Service task is submitted to the head node. The Service task runs a command or service on all resources that are allocated to the job. New instances of the command start when new resources are added to the job or if a previously running instance exits and the resource is still allocated to the job. A service task can create up to 1,000,000 subtasks (instances). Service tasks continue to start instances until the job is canceled or stopped, the maximum run time expires, or the maximum number of instances is reached.

The broker instance detects the allocated service hosts from the running service task and begins sending service requests. The broker instance manages the session, and sets and maintains the following job properties:

• Target Resource Count – For SOA jobs, this property acts as a dynamic maximum resource count, so the HPC Job Scheduler Service does not allocate more service hosts than can be used by the job. The broker node sets and maintains the Target Resource Count job property based on the number of outstanding messages for the session.

Excluded Nodes List – This job property lists nodes that should not be used to run a particular job, for example, if the tasks in a job keep failing on a particular node. For SOA jobs, the broker instance sets and maintains the list of excluded nodes for a session. The broker instance adds a node to this list if the service cannot load on that node. The EndPointNotFoundRetryPeriod setting (in the service configuration file) specifies how long the service host should retry loading the service and how long the broker should wait for a connection. If this time elapses, the broker adds the node (service host) to the Excluded Nodes list.

 

Broker node failover

The servers in a failover clusters work together, so if one server in the cluster fails, another server in that cluster automatically begins providing service (in a process known as failover).  To increase SOA runtime reliability, you can configure the head node in a failover cluster and then configure WCF broker nodes in separate failover clusters.

The following diagram shows a head node configured in a failover cluster that contains two nodes, plus a set of WCF broker nodes configured in a failover cluster that contains four nodes, three active and one passive (a passive node is inactive but ready to provide service if needed).

 

For a failover cluster that supports the head node, the storage server contains the job scheduler and management databases. The HPC Job Scheduler Service can fail over to another server if a problem occurs. For the WCF broker nodes, the storage disk contains Message Queuing queues for durable sessions.

A cluster can also include WCF broker nodes that are not configured for failover. If the cluster has failover broker nodes and non-failover broker nodes, the broker nodes that are not configured for failover are only used to host non-durable sessions, and they are not connected to Message Queuing disks.

One instance of Message Queuing runs on each active WCF broker node, and each instance requires its own disk in storage. Optimally, each Message Queuing instance has access to two disks: one for Message Queuing data file and one for Message Queuing transaction file. You can store the data and transaction files on a single disk, but that can affect performance. The Message Queuing instance can use a virtual hard disk (VHD) as its shared disk, so you can further consolidate by storing multiple VHDs on a single shared disk. The broker node can access shared disks through SCSI, iSCSI or FibreChannel networks.

How to develop?

To implement a cluster-SOA solution, developers create a service DLL, a service configuration file, and a client application. Then administrators copy the service DLLs to compute nodes on the cluster and register the service by placing the service configuration file on the head node. Administrators or end-users can then install the client application on end-user’s computers.

The client application provides an interface for the end-users. When end-users run the client application on their computers, it submits a service job to the cluster, initiates a session with the broker node, sends service requests, and receives responses.

The following diagram provides an overview of the process for implementing a cluster-SOA solution.

 

 

 

程序开发人员使用visual studio的wcf项目开发的服务端和客户端应用。服务端管理员通过复制服务和注册服务两个步骤将计算服务部署到集群。管理员安装客户端应用到用户的工作站。在投入生产后，用户运行客户端应用，应用就会调用集群上的计算服务并取得结果。

开发服务端：

1. 开发服务端

服务端一般是用来开发函数的。

1. 部署服务端

三种策略：本地部署，中央部署和混合部署

 

 

1. 注册服务：

主要是一个xml的注册文件，它定义了service.dll的地址

 

 

开发客户端：

你首先要先生成WCF client

DurableSession Class:

The DurableSession class supports reliable computations. When a durable session is created, the HPC Broker Service persists request and response messages, so if the client or network fails, the requests and responses are not lost. Client applications use the session ID to reattach to a session and retrieve responses.

Note: For durable sessions, the message size limit is 4 MB because of Message Queuing.

The DurableSession class provides the following method to retrieve responses:

AttachSession method:  Provides a non-blocking call that retrieves responses, but it does not cause the broker node to release the responses (so they can be retrieved again in the case of failure). This allows the client to attach to a failed session to retrieve responses or to restart a file and recollect session to retrieve responses.

Note: You can configure high-availability WCF broker nodes to ensure resilience if the WCF broker node fails.

 

BrokerClient Class:

In a standard WCF client, a single call sends and receives responses. With the BrokerClient class, sending and receiving are separate calls. The BrokerClient constructor wraps the WCF client to override standard call behavior and create a message-based proxy.

The BrokerClient class provides the following methods for sending and receiving messages:

• SendRequests method: Sends a batch of requests to the WCF broker node. In non-durable sessions, requests start processing when they are received. In durable sessions, the WCF broker node does not start processing requests until EndRequests is called. The client application can break a large batch of requests into separate BrokerClient instances, so all the requests do not have to be sent before the processing begins.
• EndRequests method: Confirms that all messages have been sent and ends the enumerator for the responses. In durable sessions, this call signals that the WCF broker node should start processing requests. If this call fails during a durable session, the client application must resend the batch of requests.
• GetResponses method: Returns a response enumerator so the client application can loop through to get the responses.

You can create multiple BrokerClient instances in one session. You can use each BrokerClient instance to send a batch of requests and receive the corresponding responses. When you create multiple instances of a BrokerClient object, you must give each instance a unique ID to identify the responses. You can create multiple BrokerClient instances to perform the following tasks:

• Send a batch of requests with one parameter set, change the parameter set, and then send a new set of requests in a different BrokerClient instance within the same session.
• Run multiple models at the same time with different parameters by using different BrokerClient instances.
• Break large batches of requests into separate BrokerClient instances in durable sessions. This means that the WCF broker node can start processing requests before the entire batch is sent.
• Share one session with multiple client applications by creating BrokerClient instances with unique identifiers. Each batch of computations is tagged with the BrokerClient ID to identify requests and retrieve results.

Notes   The BrokerClient class is not thread safe, so the client should not call SendRequests or GetResponses in multiple threads.

Only one user at a time can call GetResponses with a particular client ID. If a second user tries to get responses for the same client ID at the same time, the first user will get an error message and the second user will gain control of the client.

 

客户端编程模型的中心概念是会话（session），它是应用和服务之间的句柄。HPC SOA架构的应用步骤如下。

1. 创建会话，得到一个服务端点索引。（endpoint reference）
2. 根据端点索引创建服务代理。HPC server 2008 R2支持两种不同的代理，WCF代理和HPC服务代理。WCF代理由svcutil或visual studio wcf工具产生。HPC服务代理是由HPC pack软件开发工具包提供
3. 使用代理发送计算请求并接收结果。

 

会话有四种可选设置：

Durable, Non-Durable, Shared, Non-Shared

 

服务端实例：（代码略）

Wcf代理的方法是通过异步调用发送计算请求并通过回调函数接收处理结果：（代码略）。

HPC服务代理的方法是调用SendRequest（）发送请求并通过GetResponse（）接收结果（代码略）。

 

客户端实例：（代码略）

 

总得来说，hpc面向服务的模式是将计算密集的代码从应用中分割开来成为服务并在集群上运行。

 

 

 

要得到计算时间的话，在endrequests后比较合适。Createsession只是创建了会话，还没有计算，sendrequests并不是真正的发送请求，只有调用client.flush()或者是client.endrequests()才会发送请求。在client.getresponses()后停止计时，就可以得到计算时间了。

 

Soa模型已经把复杂的并行封装起来了，只要以合理的方式分成若干个request，服务器端会根据可用的资源并行处理各个request。比如发给你1024个request，系统给你64个核，理想情况下每个核为你算16个request。

 

开发人员完成soa服务代码后需要两步来部署到一个服务到HPC系统：

1. 把该服务的配置文件（servicename.config）放在环境变量%CCP_SERVICEREGISTRATION_PATH%所指的目录（默认为\\你的头节点名字\\hpcserviceregistration是共享目录），这样hpc就知道有这样一个服务可以使用。
2. 把soa服务的dll文件放到某个hpc节点访问的到的路径，比如共享文件夹或者每个节点都由的绝对路径，然后在该服务的配置文件里service assembly部分指向该路径，这样就告诉hpc系统从哪里加载该服务代码。