Monat: August 2019

Harnessing the power of the Location of Things with Azure Maps

The Internet of Things (IoT) is the beginning of accessing planetary-scale insights. With the mass adoption of IoT and the very near future explosion of sensors, connectivity, and computing, humanity is on the cusp of a fully connected, intelligent world. We will be part of the generation that realizes the data-rich, algorithmically deterministic lifestyle the world has never seen. The inherent value of this interconnectedness lies within the constructs of human nature to thrive. Bringing all of this information together with spatial intelligence has been challenging to say the least. Until today.

Today, we’re unveiling a cross-Azure IoT collaboration simplifying the use of location and spatial intelligence used in conjunction with IoT messaging. The result is the means for customers to use Azure IoT services to stay better informed about their “things” in terms of space. Azure IoT customers can now implement IoT spatial analytics using Azure Maps. Providing spatial intelligence to IoT devices means greater insights into not just what’s happening, but where it’s happening.

Azure Maps provides geographic context for information and, as it pertains to IoT, thus geographic insights based on IoT information. Customers are using Azure Maps and Azure IoT for monitoring movement of assets and cross reference the “things” with their location. For example, assume a truck is delivering refrigerated goods from New York City to Washington DC. A route is calculated to determine the path and duration the truck should take to deliver the goods. From the route, a geofence can be created and stored in Azure Maps. The black box on the truck tracking the vehicle would provide Azure IoT Hub to determine if the truck ever leaves the predetermined path. If it does, this could signal that something is wrong—a detour could be disastrous for refrigerated goods. Notifications of detours could be setup and communicated through Azure Event Grid and sent over email, text, or a myriad of other communication mediums.

When we talk about Azure IoT, we often talk about data (from sensors) which leads to insights (when computed) which leads to actions (a result of insights). With The Location of Things, we’re now talking about data from sensors which leads to insights which leads to actions and where they are needed. Knowing where to take actions has massive implications in terms of cost efficacy and time management. When you know where you have issues or opportunities, you can then make informed decisions of where to deploy resources, where to deploy inventory, or where to withdraw them. Run this over time and with enough data and you have artificial intelligence you could deploy at the edge to help with real-time decision making. Have enough data coming in fast enough and you’d be making decisions fast enough to predict future opportunities and issues—and where to deploy resources before you need them.

Location is a powerful component of providing insights. If you have a means of providing location via your IoT messages you can start doing so immediately. If you don’t have location natively, you’d be surprised at how you can get location associated with your sensors and device location. RevIP, Wi-Fi, and cell tower triangulation all provide a means of getting location into your IoT messages. Get that location data into the cloud and start gaining spatial insights today.
Quelle: Azure

Azure Load Balancer becomes more efficient

Azure introduced an advanced, more efficient Load Balancer platform in late 2017. This platform adds a whole new set of abilities for customer workloads using the new Standard Load Balancer. One of the key additions the new Load Balancer platform brings, is a simplified, more predictable and efficient outbound connectivity management.

While already integrated with Standard Load Balancer, we are now bringing this advantage to the rest of Azure deployments. In this blog, we will explain what it is and how it makes life better for all our consumers. An important change that we want to focus on is the outbound connectivity behavior pre and post platform integration as this is a very important design point for our customers.

Load Balancer and Source NAT

Azure deployments use one or more of three scenarios for outbound connectivity, depending on the customer’s deployment model and the resources utilized and configured. Azure uses Source Network Address Translation (SNAT) to enable these scenarios. When multiple private IP addresses or roles share the same public IP (public IP address assign to Load Balancer, used for outbound rules or automatically assigned public IP address for standalone virtual mahines), Azure uses port masquerading SNAT (PAT) to translate private IP addresses to public IP addresses using the ephemeral ports of the public IP address. PAT does not apply when Instance Level Public IP addresses (ILPIP) are assigned.

For the cases where multiple instances share a public IP address, each instance behind an Azure Load Balancer VIP is pre-allocated a fixed number of ephemeral ports used for PAT (SNAT ports), needed for masquerading outbound flows. The number of pre-allocated ports per instance is determined by the size of backend pool, see the SNAT algorithm section for details.

Differences between legacy and new SNAT algorithms

The platform improvements also involved improvements in the way the SNAT algorithm works in Azure. The table below does a side-by-side comparison of these allocation modes and their properties

 
Legacy SNAT Port Allocation
(Legacy Basic SKU Deployments)
New SNAT Port Allocation
(Recent Basic SKU deployments and Standard SKU deployments)

Applicability
Services deployed before September 2017 use this allocation mode
Services deployed after September 2017 use this allocation mode.

Pre-allocation
160
(smaller number for tenants larger than 300 instances)

For SNAT port allocation according to the back-end pool size and the pool boundaries, visit SNAT port pre-allocation.

In case outbound rules are used, the pre-allocation will be equal to the ports defined in the outbound rules. If the ports are exhausted on a subset of instances they will not be allocated any SNAT ports.

Max ports
No ceiling;
Dynamic, on-demand allocation of a small number of ports until all are exhausted.
No throttling of requests.
All available SNAT ports are allocated dynamically on-demand.
Some throttling of requests is applied (per instance per sec.)

Scale up

Port re-allocation is done.

Existing connections might drop on re-allocation.

Static SNAT ports are always allocated to the new instance.

If backend pool boundary is changed, or ports are exhausted, port reallocation is done.

Existing connections might drop on re-allocation.

Scale Down
Port re-allocation is done.
If backend pool boundary is changed, port reallocation is done to allocate additional ports to all.

Use Cases

Noisy neighbors could consume all ports and starve remaining instances/tenants.
Management of Port allocation is nearly impossible without any throttling.

Much better customization & control over the SNAT port allocation.
Higher pre-allocation to cover the majority of customer scenarios.
highly predictable port allocation and application behavior.

Platform Integration & impact on SNAT port allocation

We’re working on the integration of the two platforms to extend reliability and efficiency and enable capabilities like telemetry and SKU upgrade for the customers. As a result of this integration, all the users across Azure will be moved to the new SNAT port allocation algorithm. This integration exercise is in progress and expected to finish before Spring 2020.

What type of SNAT allocation do I get after platform integration?

Let’s categorize these into different scenarios:

Legacy SNAT port allocation is the older mode of SNAT port allocation and is being used by deployments made before September 2017. This mode allocates a small number of SNAT ports (160) statically to instances behind a Load Balancer and relies on SNAT failures and dynamic on-demand allocations afterwards.

After platform integration, these deployments will be moved to the new SNAT allocation in the new platform as described in section A above. However, we’ll ensure a port allocation equal to a maximum of <Static port allocation, Dynamic port allocation in older platform> in the new platform after migration.

New SNAT port allocation mode in the older platform was introduces in early 2018. This mode is same as the new SNAT port allocation Mode described above.

After platform integration, these deployments will remain unchanged, ensuring the preservation of SNAT port allocation from the older platform.

How does it impact my services or my existing outbound flows?

In majority of the cases, where the instances are consuming less than the default pre-allocated SNAT ports, there will be no impact to the existing flows.
In a small number of the customer deployments, which are using a significantly higher number of SNAT ports (received via Dynamic allocation), there might be a temporary drop of a portion of flows, which depend on additional dynamic port allocation. This should auto-correct within a few seconds.

What should I do right now?

Review and familiarize yourself with the scenarios and patterns described in Managing SNAT port exhaustion for guidance on how to design for reliable and scalable scenarios.

How do I ensure no disruption for upcoming critical period?

The platform integration & resulting port allocation algorithm is an Azure platform level change. However, we do understand that you are running critical production workloads in Azure and want to ensure this level of service logic changes are not implemented during critical periods and avoiding any service disruption. In such scenarios, please create a Load Balancer support case from the portal with your deployment information, and we’ll work with you to ensure no disruption to your services.
Quelle: Azure