Differences between Azure Resource Manager and Azure Service Manager - Developer's Perspective, Part Two, About Networking

    Our gratitude to the preparation of the article to Mikhail Tryakhov ( @PerseptronYar ) from Akvelon (Yaroslavl) for help in writing this article. Michael works on the Microsoft Azure CLI (Command Line Interface) development team, specializing in Networking Services.

    Greetings, dear readers!


    Let's continue with a description of Microsoft Azure core development tools, which began a month ago in an article on the first steps in Azure Resource Manager (ARM). We managed to talk about the main differences between the classic (Azure Service Management) approach and the new ARM mode. We examined the ways of working with JSON-templates (templates), allowing more simple way to deploy and modify the architecture. At the first opportunity, we demonstrated how to configure security policy using an example of a three-tier application.
    I really thank for the feedback that was received, albeit in a modest amount, but in a constructive manner. Your questions have prompted me to describe the process of creating hybrid solutions - and already in this article we will touch on some cases of this subject area. Let me remind you, we considered an example of architecture, schematically depicted below.



    To begin with, I would like to continue working with Networking services in ARM. So, let's look at the interaction between the internal layers of the application.



    Let me remind you that we have already set up a security policy through Network Security Groups, banning, in particular, access to database services (backend) directly from the Internet.


    {
       "name": "Block_Internet",
       "properties": {
          "description": "Block Internet",
          "protocol": "*",
          "sourcePortRange": "*",
          "destinationPortRange": "*",
          "sourceAddressPrefix": "*",
          "destinationAddressPrefix": "Internet",
          "access": "Deny",
          "priority": 200,
          "direction": "Outbound"
       }
    }

    In addition, the subject area may require us and other feats of arms. In order to ensure the correct interaction between the levels of our application, we need to configure routing. Most of the required cases are beautifully covered by the default System Routes. This allows you not to worry about setting up connections between virtual machines within the virtual network, regardless of the subnets (subnets) to which they relate. System routes, in addition, provide data exchange outside the established network (to the Internet, to other networks via VPN). Relationships with the route table are automatically created. In order to reduce the size of our template, I propose to make this task a little simplified.



    But we are not here to spend a lot of time on default data services. Consider less trivial cases when we can’t get by with basic system routing. For such purposes User Defined Routing (UDR) can be used. With it, we can create user-defined routes and implement a more complex custom scenario. For example, UDR will help you use virtual devices in the Azure architecture, provide access to the Internet through your local network.



    The implementation of such a task can be solved precisely due to User Defined Routes. Other cases where the need for UDR is obvious is to configure Firewall, building a deeper analysis of the data transmitted over the network. A similar way to build routing can also help in more useful customization of the logging system.

    So, let's look at an example of building a UDR. We modify the default case with System Routes and add a third virtual machine through which we will run our traffic to complete the tasks.



    I propose to redeploy the infrastructure using the JSON template, which we decided to consider the most obvious. We will work with him in one of the already familiar editors. First of all, we will naturally launch Visual Studio, but for our example, such a powerful IDE is a rather "difficult" solution. As an alternative, you can use any editor that supports working with JSON. One of the relatively new ways out of the situation of potential syntax errors in JSON is VS Code, available, for example, in the beta version of the marketplace .

    Its code is available atthis link . I believe that if you look into it, its volume will give an understanding of why I cowardly brought this task out of the initial three-level scheme. As before, we are not afraid and continue. In the template, we create a virtual network and three subnets: frontend, backend and the Virtual Appliance (subnet3) intermediate between them. Frontend subnet (subnet1) we, in addition to NSG, correlate with the route table (route table), which will direct outgoing traffic. I note that User Defined Routes are suitable for configuring only outgoing traffic, moreover, routing should occur outside the same subnet.

    In each subnet, we deploy virtual machines and assign Public IP addresses to them, configure network security groups, add ours to the default rules, and allow access via RDP. Well, for dessert - add the route table mentioned above, in which we prescribe a rule that reflects the destination of our route (destination route).


    {
      "type": "Microsoft.Network/routeTables",
      "name": "[variables('routeTableName')]",
      "apiVersion": "2015-05-01-preview",
      "location": "[parameters('location')]",
      "properties": {
        "routes": [
          {
            "name": "VirtualApplianceRouteToSubnet3",
            "properties": {
              "addressPrefix": "[parameters('subnet3Prefix')]",
              "nextHopType": "VirtualAppliance",
              "nextHopIpAddress": "[variables('NvmPrivateIPAddress')]"
            }
          }
        ]
      }
    }


    I ask you to pay attention to an important point - we indicate the type and address of the next recipient of our traffic. In our case, we indicate that if traffic came to Subnet 3 (Virtual Appliance), then we redirect it to the next (private) IP address.
    An additional step that is required is to establish the necessary connection between the final Backend subnet, its private IP address and our route table. To do this, we create Network Interfaces (NIC) for each subnet. If everything is idle and uninteresting for the Frontend subnet, then in the Backend configuration it is not so simple. In it, we indicate the connection of public and private IP addresses, and also allow forwarding of IP. Got the coveted router.


    "properties": {
      "ipConfigurations": [
        {
          "name": "ipconfig1",
          "properties": {
            "privateIPAllocationMethod": "Static",
            "privateIPAddress": "[variables('NvmPrivateIPAddress')]",
            "publicIPAddress": {
              "id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('PublicIPNameForVM2'))]"
            },
            "subnet": {
              "id": "[variables('subnet2Ref')]"
            }
          }
        }
      ],
      "enableIPForwarding": true
    }


    Other configuration features (Network interfaces, etc.), again, I urge you to track in an accessible template . There we make all the necessary parameters for creating virtual machines, indicating their Network Interfaces. We also see the obvious in the context of the above settings of virtual machines on Windows.

    So, having deployed the desired infrastructure, we can test what happened in the end. For example, we can track that the Virtual Appliance (VM3) has free access to the Backend level (VM2). Turning to the first virtuaki (Frontend Layer, VM1), we can track how the expected redirect occurs.



    I hope this not so simple case has added you some understanding about the methods of creating User Defined Routing solutions. And even if this article does not prompt you to immediate experiments, it will certainly be bookmarked for the near future.

    One can not help but say a few words about using Express Routes, the basic case for the use of which is the need to connect your network services to Azure and other Microsoft cloud services (Office 365, CRM Online). Existing infrastructure can be located in your data center (on-premises), or located in different places. What is important - the established connection is isolated from the general Internet connection, and will be made via a dedicated channel (Express route circuit). The connection is excluded not only with other Internet resources, but even with Microsoft Azure services (Storage, SQL database). Dynamic routing will take place over standard protocols (BGP). There are several ways to establish a LAN connection to Microsoft cloud services.



    In the case of Cloud Exchange co-location, the connection is made through the Ethernet Exchange co-location provider. This method of establishing a connection will allow, for example, to provide a virtual cross-connection with Azure.

    A point-to-point connection provides an Ethernet network between your company's local data center and Azure. Access is still provided through dedicated channels and access through the public Internet is excluded.

    Any-to-any networks allow integration with the Azure cloud of the global WAN (for example, the campus of a large university, an office practicing remote work). This is done using a MPLS-based VPN. In the context of Azure, this is called IPVPN, which allows the WAN to perceive Azure as another campus or remote office.

    The number of concrete cases is truly large, and I considered it excessive to bring it here. I will only refer to a very useful document that describes in detail the significant part of cases that can be solved using Express routes.

    In the end, I want to say a few words about how the above methods of making connections interact with each other. When we do not explicitly specify a route table for a subnet, System Routes are used by default. If the table is indicated and the connection is established, routing is done by coincidence of the longest prefix (LPM) among UDR and System Routes. If there are several routes with matching LPM values, the route is selected by source in the following order:


    • UDR
    • BGP route (if using ExpressRoute);
    • System Routes

      Hopefully this article has added insight into routing issues with Microsoft Azure in the new Azure Resource Manager. Ahead - load balancing and hybrid solutions ARM, ASM, on-premises. As before, I really look forward to your questions and suggestions. Thanks for attention!

    Also popular now: