none
Internal IP Address of Role Load Balancer

    Question

  • I have successfully added a worker role to a virtual network by adding the following into the service config:

    <NetworkConfiguration>
        <VirtualNetworkSite name="VirtualNetwork" />
        <AddressAssignments>
          <InstanceAddress roleName="RoleName">
            <Subnets>
              <Subnet name="Front" />
            </Subnets>
          </InstanceAddress>
        </AddressAssignments>
      </NetworkConfiguration>

    The dashboard for the role shows a single public address and IP, which would be the address of the NLB, but not the internal IP (the address on the virtual network). The 'resources' section of the virtual network shows the IP addresses of the two instances of the role that are running, not the load balancer. Using one or other IP address works well across the VPN gateway that has been set up (which is cool!).

    So, in this scenario:

    1. Is there an internal IP (virtual network IP) of the existing load balancer? Do I need to add extra configuration to the above to enable it?

    2. Assuming that there is an internal IP for the NLB, how can I set the lease of the NLB to be infinite? As you can with VMs, so that I can add a VPN DNS entry.

    Without a private IP on the load balancer, worker roles on Virtual Networks are unusable. Apart from having an IP address per instance, it will change every time the role is recycled (including role upgrades).

    Finally, it seems that the support of roles in Virtual Networking is not well supported or documented. What are the plans for this support come GA of virtual networking?

    Simon

    Tuesday, November 27, 2012 6:23 PM

Answers

  • Simon,

    As a network engineer, I'm not sure what you mean by "VPN equivalent" but it sounds like you're asking for the internal IP that maps to that public IP. The assumption I'm hearing is that the load balancer is a device with 2 sides: a public facing side and private facing side. The reality is that it is not a device at all but rather a software implementation (SLB or Software Load Balancer). It cannot be addressed directly. All it does is change the destination IP of incoming traffic to match that of a VM. When the VM responds, all it does is change the source address back from whatever is assigned to the VM back to the Public facing IP. This hides the internal addresses from external hosts which simultaneously allows multiple internal hosts to respond to requests hitting a single external IP.

    The short answer is that the internal equivalent of the public IP is the IP assigned to your VM. If you have multiple VMs in the Cloud Service, then the load balancer simply rotates the IPs in round-robin fashion.

    The Cloud Service does not have an accessible internal IP.

    Stated another way, the Load Balancer only forwards incoming traffic so even if it had an accessible internal IP it would not be useful to you. This is done partly for performance reasons so that we need only process incoming traffic.

    It sounds like you want to load balance internal traffic. This is not a feature of Azure.

    You are correct that you would have to provide your own internal load balancing since the SLB (Software Load Balancer) only balances traffic that hits the public Virtual IP (VIP).

    What I would suggest to you is to host your own internal DNS. Then have each of your roles register a service name mapped to its internal IP with the DNS server. Whenever a role needs to contact that service name, DNS will deliver the collection of IPs in round-robin fashion so that you will get a kind of load balancing that scales.

    Simon, if this still doesn't answer your question (entirely possible since there are some assumptions in my response), would you be willing to contact me by email to we can work directly on this? If you prefer to continue here on the forum, that is fine too.

    Regards,

    -Steve

    Tuesday, December 04, 2012 10:16 PM

All replies

  • Hello Simon,

    Thank you for posting your question here.

    There is no need for additional IP configuration on your worker role. The internal routing happens automatically.

    Load balancing works the same way for Cloud Services regardless of whether they are in a Virtual Network. The public IP is mapped to the Cloud Service. Each of the roles in the same Cloud Service share that public virtual IP (VIP). Create a Load Balanced Endpoint to distribute the traffic across the roles in the Cloud Service.

    Best regards,

    -Steve

    Wednesday, November 28, 2012 1:14 AM
  • I do have an endpoint defined as follows:

     <InputEndpoint name="UDP10111" protocol="udp" port="10111" localPort="*" />

    The endpoint works fine with the public VIP. The problem is that I cannot see what the private IP of this endpoint is. It is not visible on the cloud service dashboard, nor is it visible as a resource for the Virtual Network.

    The clients, that connect across the VPN, cannot connect to the public VIP - so I have to have a private IP. The second part of the problem is the lease of this private IP.

    Wednesday, November 28, 2012 9:02 AM
  • Hi Simon,

    Can you please confirm that you don't see the internal IP of your role in the Dashboard for the virtual Network? I just deployed both Web and Worker roles to my Virtual Network and their IPs did show up under the "Resources" section of the Dashboard.

    As a workaround, would it work for you to RDP (Remote Desktop) to the role using the Public Endpoint? That way you could get the IP from the role directly.

    And what about programmatically using RoleInstance.InstanceEndpoints Property?

    Let me know whether one of these works for you. If not, please let me know why so I can better understand your question.

    Regards,

    -Steve


    Monday, December 03, 2012 6:14 PM
  • My question is, what is the private VIP of the cloud service itself, not the individual role instances?

    I can confirm that I see the internal IPs of the roles, but not of the cloud service (i.e. load balancer).

    As an example, I created a standard empty MVC project and deployed it into a cloud service with the network configuration as described above.

    On the resources page I get the following...

    That means that a separate virtual/private IP address has been assigned for each instance. Cool, and expected.

    However, on the cloud service dashboard I get this...

    ..which is a public IP address for the service. (which is the NLB for the deployed web role instances)

    So the question is, what is the VPN equivalent of the above IP address? I should have a single IP address on the service, regardless of how many instances are deployed. The clients on the VPN cannot route to the public IP address, only to those on the VPN. So I should have a 172.27.2.? address for the service.

    This is important because:

    1. I want to make use of the load balancing properties of the cloud service (as I am used to with public addresses).

    2. I want to be able to scale up and down.

    3. I need to make a single entry in the VPN DNS server for the cloud service.

    The requirement therefore, from virtual networking and roles, is to have a private IP address of the cloud service (NLB) and to be able to set it with an infinite lease (as per VMs). Without the service/nlb being on the VPN, Azure roles cannot be practically used with virtual networking.

    (The only work around that I can see is to run a load balancer myself on a VM within the virtual network, assign it an infinite lease, and get it to load balance between the role instances. This doesn't work very well as, apart from the admin effort, a self configured NLB won't know when roles are stopping and spinning up.)

    Thanks for your help.

    Simon

    Tuesday, December 04, 2012 12:19 PM
  • Simon,

    As a network engineer, I'm not sure what you mean by "VPN equivalent" but it sounds like you're asking for the internal IP that maps to that public IP. The assumption I'm hearing is that the load balancer is a device with 2 sides: a public facing side and private facing side. The reality is that it is not a device at all but rather a software implementation (SLB or Software Load Balancer). It cannot be addressed directly. All it does is change the destination IP of incoming traffic to match that of a VM. When the VM responds, all it does is change the source address back from whatever is assigned to the VM back to the Public facing IP. This hides the internal addresses from external hosts which simultaneously allows multiple internal hosts to respond to requests hitting a single external IP.

    The short answer is that the internal equivalent of the public IP is the IP assigned to your VM. If you have multiple VMs in the Cloud Service, then the load balancer simply rotates the IPs in round-robin fashion.

    The Cloud Service does not have an accessible internal IP.

    Stated another way, the Load Balancer only forwards incoming traffic so even if it had an accessible internal IP it would not be useful to you. This is done partly for performance reasons so that we need only process incoming traffic.

    It sounds like you want to load balance internal traffic. This is not a feature of Azure.

    You are correct that you would have to provide your own internal load balancing since the SLB (Software Load Balancer) only balances traffic that hits the public Virtual IP (VIP).

    What I would suggest to you is to host your own internal DNS. Then have each of your roles register a service name mapped to its internal IP with the DNS server. Whenever a role needs to contact that service name, DNS will deliver the collection of IPs in round-robin fashion so that you will get a kind of load balancing that scales.

    Simon, if this still doesn't answer your question (entirely possible since there are some assumptions in my response), would you be willing to contact me by email to we can work directly on this? If you prefer to continue here on the forum, that is fine too.

    Regards,

    -Steve

    Tuesday, December 04, 2012 10:16 PM
  • Thanks, that does answer the question. For purposes of retaining the argument in the thread for future use and feedback to the product team, below is some clarification on the problem and why Azure should provide the feature.

    I get that the SLB is on a sophisticated service that is difficult to add virtual networking features to. However, the addition of the VPN gateway functionality requires that Azure offers a virtual network-based load balancer. Without such functionality, using Windows Azure roles across a VPN are useless. What you refer to as 'internal' traffic originates externally when a VPN gateway is used. So no, I am not trying to load balance internal traffic - the VPN gateway is internal, but the traffic originates on the customer network.

    Consider the following diagram that illustrates my current project.

    The customer network has up to 100,00 devices that have no public Internet access (in this case they are embedded mobile devices), only access to the VPN. The VPN gateway in Azure works well but, as you have answered, the cloud service is inaccessible. The Azure SLB does do round-robin load balancing, but does a lot more — it is integrated with the fabric controller. When you scale the cloud service, or roles are recycled, the fabric controller lets the SLB know — and that is a critical feature. Implementing such functionality on a hand-configured IaaS-based NLB is really hard (and a maintenance issue) because you will have to do more than implement a simple probe, but have to interrogate the role instances to find out how many are running and where they are. You lose so much of the PaaS benefits (scaling) that it may be better to implement the 'roles' as plain IaaS (web) servers and use Chef to handle their startup and plugging in to the LNB — at least there is more predictable control (and chef recipes).

    This is probably why there is little official documentation on virtual networking with roles because, although it sort-of works, its not workable. The bottom line, you cannot use Windows Azure roles when integrating with a customer network via a VPN. The ability to access the cloud service SLB on a private IP, across the VPN, is critical to enabling the functionality.





    • Edited by Simon Munro Wednesday, December 05, 2012 7:47 PM
    Wednesday, December 05, 2012 7:41 PM
  • Hi Simon,

    I am faced with exactly the same issue, have you found a solution yet?

    Regards,

    Douw


    DGL

    Thursday, February 27, 2014 11:24 PM
  • Steve, is this still the situation?  I am faced with exactly this issue and I do not see an easy workaround.
    Thursday, April 10, 2014 7:44 PM
  • Hello all,

    Good news, internal load balancing is now publicly available.

    http://msdn.microsoft.com/library/dn690121.aspx

    Regards,

    Douw


    DGL


    • Edited by BETER Wednesday, May 14, 2014 2:51 AM
    • Proposed as answer by BETER Wednesday, May 14, 2014 2:52 AM
    Thursday, April 10, 2014 10:52 PM