Enable Communication for Role Instances in Windows Azure
Updated: May 9, 2011
The role instances running in a hosted service in Windows Azure communicate through internal and external connections that vary depending on the type of communication that is needed. An external connection that is used to communicate with external clients is called an input endpoint, and an internal connection that is used to communicate with other role instances in the hosted service is called an internal endpoint. An input endpoint can connect by using a protocol of HTTP, HTTPS, or TCP. An internal endpoint can connect by using a protocol of HTTP or TCP. Endpoints are associated with IP addresses and ports, where the input endpoint is associated to a port that you define, and the internal endpoints are dynamically assigned ports by Windows Azure. You can statically assign the internal port to the same external port that is used by specifying the localPort attribute when defining the endpoints in the service definition.
A hosted service that is created in Windows Azure can be deployed into one of two different environments; a production environment and a staging environment. A service that is deployed in either of these environments has a DNS name and an IP address assigned to it. The DNS name that is associated with the production environment is assigned at runtime and is fixed for the lifetime of the service. The DNS name for the staging environment is dynamically generated each time a service is deployed. Each time that a service is deployed to one of these environments, the DNS name that is associated with it has an IP address assigned to it from a pool of available addresses. The IP address is kept until the service deployment is deleted. Upgrading your application, altering the configuration, or swapping the production and staging environments will not cause the IP address to change.
 Note |
|---|
| The range of IP addresses that are used by Windows Azure can change. If you are setting up firewall polices or other IP based security, you should not use IP based filtering. You should use other security mechanisms that do not depend on IP address ranges. |
All roles can have any type of input endpoints. Input endpoints are used to communicate with role instances from outside of Windows Azure. Each input endpoint defined for a role must listen on a unique port. The port that is defined for an input endpoint is used by the load balancer of Windows Azure to make your hosted service available on the Internet. A hosted service can have up to 25 input endpoints defined and can be distributed among the roles. For example, a hosted service could have one role defined and have all 25 input endpoints defined for that role, or the hosted service could have five roles defined have each role use five input endpoints.
All roles can have any type of internal endpoints. Internal endpoints are used for internal role communication, for example, role-to-role communication. A hosted service can have up to 25 internal endpoints defined and can be distributed among the roles. For example, a hosted service could have one role defined and have all 25 internal endpoints defined for that role, or the hosted service could have five roles defined have each role use five internal endpoints. The Windows Azure Fabric Controller assigns internal ports unless you use the localPort attribute in the service definition. When the Windows Azure Fabric Controller chooses the internal port number, you can discover it by using the following code example:
int port = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["EndPointName"].IPEndpoint.Port;
After you define internal endpoints, you can add network traffic rules based on the endpoints that you created to control how role instances can communicate with each other. The following diagram shows some common scenarios for controlling role communication:
-
Scenario 1 – Only allows network traffic from WebRole1 to WorkerRole1.
-
Scenario 2 – Only allows network traffic from WebRole1 to WorkerRole1 and WorkerRole2.
-
Scenario 3 – Only allows network traffic from WebRole1 to WorkerRole1, and WorkerRole1 to WorkerRole2.
-
Scenario 4 – Only allows network traffic from WebRole1 to WorkerRole1, WebRole1 to WorkerRole2, and WorkerRole1 to WorkerRole2.
The Windows Azure Managed Library provides methods for role instances to communicate at runtime. From code running within a role instance, you can retrieve information about the existence of other role instances and their endpoints, as well as information about the current role instance.
|
Note |
|---|
| You can only retrieve information about role instances that are running in your hosted service and that define at least one internal endpoint. You cannot obtain data about role instances running in a different service. |
You can use the Instances property to retrieve instances of a role. First use the CurrentRoleInstance to return a reference to the current role instance, and then use the Role property to return a reference to the role itself.
The Instances property returns a collection of RoleInstance objects. This collection always contains the current instance. If the role does not define an internal endpoint, the collection includes the current instance but no other instances. The number of role instances in the collection will always be 1 in the case where no internal endpoint is defined for the role. If the role defines an internal endpoint, its instances are discoverable at runtime, and the number of instances in the collection will correspond to the number of instances specified for the role in the service configuration file.
|
Note |
|---|
| The Windows Azure Managed Library does not provide a means of determining the health of other role instances, but you can implement such health assessments yourself if your service needs this functionality. You can use Windows Azure Diagnostics to obtain information about running role instances. For more information about collection diagnostic data, see Collect Logging Data by Using Windows Azure Diagnostics. |
See Also
