Border Gateway Protocol: 

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This discusses networking considerations in Multitenant applications.    

This protocol can be configured on a Windows Server with Routing and Remote Access Service Gateway in multitenant mode. It gives the ability to manage the tenant’s vm networks and their remote sites. 

BGP is a dynamic routing protocol. It learns the route between sites that are connected using site-to-site VPN connections. It eliminates the need for manual route configuration on routers. When configured as a multi-tenant BGP router to exchange tenant and Cloud Service Provider subnet routes, the RAS gateway is deployed on a vm or a set of vms for high availability. The single tenant edge gateway deployment can be on a physical computer in a LAN deployment. 

The Powershell script to configure the multitenant mode looks like this: 

$foo_RoutingDomain = “FooTenant” 

$bar_RoutingDomain = “BarTenant” 

Install-RemoteAccess -MultiTenancy 

Enable-RemoteAccessRoutingDomain -Name $foo_RoutingDomain -Type All -PassThru 

Enable-RemoteAccessRoutingDomain -Name $bar_RoutingDomain -Type All -PassThru 

There can be several modes of deployment between Enterprise sites and a Cloud Service Provider Datacenter. This involves dynamic routing information exchange between an Enterprise and the multiple gateways of the CSP.  A few modes of deployments are enumerated below: 

RAS VPN site-to-site gateway with BGP at the Enterprise site edge. 

Third Party Gateway with BGP at the Enterprise site edge 

Multiple Enterprise sites with Third Party gateways 

Separation Termination points for BGP and VPN 

The last mode of deployment supports internal BGP (iBGP) and external BGP (eBGP) segregation. The iBGP is only used with the separation of termination points for BGP and VPN.  BGP is used for peering and maintains a separate routing table different from those for internal networks.  The route metrics are based on shortest AS paths rather than distance or cost between hops. Unlike OSPF or interior Gateway Protocol that provides fault tolerance or redundancy and direct connections to external Autonomous Systems, BGP handles multiple connections to an external Autonomous System while allowing the existing router to handle the additional demands. It is an admission control protocol based on path-vector routing.  

The way BGP works are that it establishes neighbor relationships called peers between routers called speakers. If the relationships are all within the same AS, it is called internal BGP. If it connects separate autonomous systems, it is called external BGP. Initially, peers share full routing tables. Afterward, they share only the updates.  

The features of the BGP Router using Windows Server include: 

Independent deployment of just the BGP routing role service and not the Remote Access Service which leads improved router performance. 

Collection of statistics using Message counters and Route Counters. The Get-BGPStatistics cmdlet provides this information. 

Equal Cost multipath routing support for redundant networks 

Hold Time Configuration- The BGP Router supports configuration of the Hold Timer Value according to the network requirements. 

Internal BGP and external BGP segregation – The local and remote BGP routers are distinct supporting iBGP and eBGP peering. The iBGP is only used with the fourth mode of deployment listed which is the separation of termination points for BGP and VPN. 

Latest RFC compliance – RFC-4271 aka BGP-4 protocol compliant implementation implies the product is interoperable with third party vendors. 

Ipv4 and ipv6 peering supported- this support comes from ipv4 and ipv6 peering while the BGP router is assigned an ipv4 address. 

Ipv4 and ipv6 advertisement capability or Multiprotocol Network layer Reachability Information NLRI is supported 

Mixed mode and passive mode peering is supported. The former refers to the BGP Router serving as both the initiator as well as the responder. The latter mode is just responsive so it helps with debugging and troubleshooting. 

Route attribute rewrite capability is provided.  The BGP routing policies Next-Hop, MED, Local-Pref and Community are supported. 

Route filtering – The BGP router supports filtering ingress or egress route advertisements.  

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the architectural approaches for IoT in multitenant solutions.     

IoT services like storage services are hetereogenous in their functionality. IoT systems vary in flavor and size. Not all IoT systems have the same certifications or capabilities. Multitenant solutions introduce sharing which brings a higher density of tenants to infrastructure and reduce the operational cost and management. Unlike compute or storage, isolation model can be as granular as the devices. Services that depend on the number of devices supported in a single instance include Azure IoT central, Azure IoT Hub Device Provisioning Service (DPS) and Azure IoT Hub. Different devices even in the same solution might have different throughput requirements. Throughput refers to the total bytes transferred in unit time and can be affected by both the number of messages as well as the size of messages. 

When these IoT resources are shared, isolation model, impact to scaling performance, state management and security of the IoT resources become complex. These key decisions for planning a multitenant IoT solution are discussed below.    

Scaling resources helps meet the changing demand from the growing number of tenants and the increase in the amount of traffic. We might need to increase the capacity of the resources to maintain an acceptable performance rate. For example, if a single IoT topic/queue is provisioned for all the tenants and the traffic exceeds the specific number of IoT operations per second, the Azure IoT will reject the application’s requests and all the tenants will be impacted. Scaling depends on Number of producers and consumers, Payload size, Partition count, Egress request rate and Usage of IoT Hubs Capture, Schema Registry, and other advanced features. When additional IoT is provisioned or rate limit is adjusted, the multitenant solution can perform retries to overcome the transient failures from requests. When the number of active users reduces or there is a decrease in the traffic, the IoT resources could be released to reduce costs. When the resources are dedicated to a tenant, they can be independently scaled to meet the tenants’ demands. This is the simplest solution, but it requires a minimum number of resources per tenant. A shared scaling of resources in the platform implies all the tenants will be affected. They will also suffer when the scale is insufficient to handle their overall load. If a single tenant uses a disproportionate amount of the resources available in the system, it leads to a well-known problem called the noisy neighbor antipattern. When the resource usage increases above the total capacity from the peak load of the tenants involved, failures occur which are not specific to a tenant and impact the performance of those tenants. The total capacity can also be exceeded when the individual usages are small, but the number of tenants increase dramatically. Performance problems often remain undetected until an application is under load.  A load testing preview can help analyze the behavior of the application under stress. Scaling horizontally or vertically helps correct the correlated application behavior.    

Data isolation depends on the scope of isolation. When the storage for IoT is SQL Server, then the IoT solution can make use of IoT Hub. If the storage is Azure Data Explorer, the IoT solution can benefit from IoT Central. Finally, IoT resources can be provisioned within a single subscription or separated into one per tenant.   

Varying levels and scope of sharing of IoT resources demands simplicity from the architecture of the multitenant application to store and access data with little expertise. A particular concern for multitenant solution is the level of customization to be supported.   

Patterns such as the use of the deployment stamp pattern, the IoT resource consolidation pattern and the dedicated IoT resources per tenant pattern help to optimize the operational cost and management with little or no impact to the usages.    

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN