If you have multiple roles within your Windows Azure hosted service project, you may wish to segregate them or isolate them from each other. One reason for wishing to do so is to ensure that architectural boundaries are enforced. Windows Azure allows the granular control of network traffic exchange between internal endpoints amongst your role instances to achieve these ends.

The configuration of this control is done in the ServiceDefinition.csdef file and is quite intuitive.  In our scenario, we build three Roles, each of which hosts a TCP server and exposes it on an Internal Endpoint with a dynamic port. It is possible to also use static ports and any configuration of Endpoint type.

This capability has been around for some time, certainly is supported by SDK version 1.4 and beyond. I put together this post with SDK 1.5, and thus the title version marker ;-)

In our scenario, these three Roles will all attempt to communicate with each other, but will be restricted so that communication is only posssible thus:

  • Role A -> Role B
  • Role B -> Role C
  • All Roles -> Role A
Role Communication

Role Communication

This is achieved with the following node in <ServiceDefinition/>:

<NetworkTrafficRules>

<OnlyAllowTrafficTo>

<Destinations>

<RoleEndpoint endpointName=”InternalServerRoleA” roleName=”RoleA”/>

</Destinations>

<AllowAllTraffic/>

</OnlyAllowTrafficTo>

 

<OnlyAllowTrafficTo>

<Destinations>

<RoleEndpoint endpointName=”InternalServerRoleB” roleName=”RoleB”/>

</Destinations>

<WhenSource matches=”AnyRule”>

<FromRole roleName=”RoleA”/>

</WhenSource>

</OnlyAllowTrafficTo>

 

<OnlyAllowTrafficTo>

<Destinations>

<RoleEndpoint endpointName=”InternalServerRoleC” roleName=”RoleC”/>

</Destinations>

<WhenSource matches=”AnyRule”>

<FromRole roleName=”RoleB”/>

</WhenSource>

</OnlyAllowTrafficTo>

</NetworkTrafficRules>

As you can see, the definition of the rules is intuitive. There is also validation of these rule at compile time, so Visual Studio will warn you if you have anything wrong.

As usual, source code is provided: BareWeb.IntraRoleCommunications

You can find more information on other scenarios here: http://msdn.microsoft.com/en-us/library/windowsazure/gg433115.aspx

Happy clouding,

Andy

 

Note: if you receive the following warning, you must move your NetworkTrafficRules node to after the defintion of your Roles in ServiceDefinition.csdef – typcially the NetworkTrafficRules node should be the last thing in your csdef file before the closing NetworkTrafficRules tag.

Warning 7 The element ‘ServiceDefinition’ in namespace ‘http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition&#8217; has invalid child element ‘WorkerRole’ in namespace ‘http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition&#8217;.

About these ads