Need some pointers on how one could achieve "true" multi region setup for AADDS.
As per Microsoft's documentation, AADDS is "designed" to be "single regioned". Although it provides some (arguably) redundancy by spinning up essentially 2 managed domain controllers, it does not take into account performance.
Microsoft recommends (and there isn't really any other way to do this) setting up VPN's or VNET peering in order to access your AADDS from other regions, but this has huge impact over performance, and also over actual redundancy (HA designs should be multi region imo, and AADDS should be HA).
We're deploying Windows VM's in (at the time of writing this question) 10 regions, with AADDS in West Europe. We're seeing huge penalties for our apps that require/rely on LDAP ( >10s in some regions) for even the most basic LDAP queries with quite the small return payload.
Was hoping someone figured out a way to mirror/cache AADDS in a new region, like maybe adding a new worker DC or some black magic, so that VMs and services would connect more locally?
Cheers!
Azure AADDS Multi-Region Support is already a requested feature and is under works currently. However, there is no ETA to share at the moment. You can follow What's new in Azure Active Directory? for updates.
The only option to achieve Geo-redundancy is by deploying ADDS across multiple regions via IaaS VMs, Vnet pairing, and VPN gateways.
Also, for high availability, each Azure AD Domain Services managed domain includes two domain controllers. You don't manage or connect to these domain controllers, they're part of the managed service. If you deploy Azure AD Domain Services into a region that supports Availability Zones, the domain controllers are distributed across zones. In regions that don't support Availability Zones, the domain controllers are distributed across Availability Sets. You have no configuration options or management control over this distribution.
According to Azure AADDS FAQ documentation, they do support a fail-over to another geo location.
You can follow this tutorial page in order to create a replica set for your AADDS deployment.
Related
I was told recently that the Hub VNET is only used in case there is on-premise networking to/from considerations.
I am quite surprised as were many, at the table.
I was under the impression if I have, say, a AZURE Cloud only env. that I could still have a Hub Spoke approach. Or is this not so? What would be the preferred non-Hub Spoke approach if there is peering or inter-VNET access required?
I am aware of VNET Peering and other methods to access resources in other VNETs, API's and Private Link.
The hub-spoke approach works great in some scenarios in cloud-only environments - although in most of docs or architectural patterns Microsoft shows it together with on-prem connectivity.
I used it frequently when we shared some resources like ACR, Log Analytics or simply to host a jump host (with Bastion) to access resources in other networks.
One of the most common scenarios is also the Azure Monitor Private Link Scope, where the hub-spoke topology is recommended:
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-design#hub-and-spoke-networks
In an Azure Cloud only environment, you can still have a Hub-Spoke approach and this is the recommended one.
While you can cross-peer different spokes to form a Mesh for spokes to exchange data (in a non-Hub scenario), this will become complicated as the number of spokes increases. You will have to configure 1:n Peering in every VNet.
With Hub-Spoke model, you have to route spoke-spoke traffic via Hub Vnet, but the advantage here is that the Hub Vnet becomes the single point entry for the environment and you can deploy resources here that would be shared and used by all other VNets (such as custom DNS server, Firewall)
We have a standard 3 tier web application that need to be migrated into cloud (more of VM based lift and shift instead of cloud native at this point).
Wondering which factors should I consider to make a decision if Azure Scale Set or Azure Availability Set should be used for Web and Application tiers.
Probably answer to questions like:
Can availability set autoscale like Scale set?
Any overhead of using either option for a simple web application?
Will both need load balancer in front of them ?
Might help to take a decision.
Any suggestions please?
You can refer to the N-tier architecture on virtual machines. Each of tier consists of two or more VMs, placed in an availability set or VM scale set. The load balancer is used to distribute requests across the VMs in a tier. Each tier is also placed inside its own subnet, and add NSG rules to restrict access to each tier and route tables to individual tiers.
For your questions:
No, The main difference is that a Scale Set have Identical VMs which makes it easy to add or remove VMs from the set whereas an Availability Set does not require them to be identical. An availability set is spread across fault domains that shared a set of hardware components, which means when you have more than one VM in different fault domains in a set it reduces the chances of losing all your VMs in event of a hardware failure in the host or rack. A regional (non-zonal) scale set uses placement groups, which act as an implicit availability set with five fault domains and five update domains. Refer to this question.
It's recommended to use VM Scale Sets for autoscaling. VMSS can automatically create and integrate with the Azure load balancer or Application Gateway.
Yes, both need Azure LB in front of them.
Generally speaking, both scenarios do not offer any way to magically make this happen, so you are kinda forced to use webapps if you want minimum overhead.
yes it can, but you need to prestage vms
yeah, you need to configure vms and for vmss you need automation so that scaling can happen automatically
yes, both will need a load balancer (web apps - not).
But your app might not work with webapps, so you are kinda forced to use vms or vmsses
I am starting to read documentation on Azure Networking and every single example evrywhere gives an example of 2 Virutal Machines and then explains be it subnet, Traffic Manager, Load Balancer etc
Maybe its a dumb question But Can I do Load Balancing for Azure App Services, Azure DB, Storage Account etc without Virtual Machines ?
For PaaS services you cannot use load balancing for the most part, because it makes no sense. you would need to replicate data on your own. if you are to load balance between PaaS services. besides thats the idea behind PaaS, you dont have to care about PaaS. it just works.
But for webapps (and it makes sense) you can use load balancers\application gateway\traffic manager to balance load.
You need to understand network design and build a theory behind it.
Now, load balancing is required for HA and redundancy in a network, beyond which you extract the capability of the load balancer based on your requirements/Application.
So, PaaS services are not managed by completely by the user. You are paying a premium for using them and they will come with a built-in redundancy which you should opt for during deployment.
Load Balancing on Azure is Primarily "configurable" for IaaS only.
If two logic apps are there in two different regions and I want to do load balancing between these two how to do this.
Through some source, I got to know that it is possible through API management but they have not mentioned how to do this.
So, how to do load balancing between two logic apps?
Well...why do you want to do this? "Load Balancing" especially with LogicApps is fundamentally different on Azure than on-premise or self hosted. It's not wrong, just different ;)
What they were probably referring to was Azure Load Balancer which appears as a Networking Service, not APIM.
This, you can use to distribute requests as you would with traditional load balancers.
Since you want to load balance across regions I would look into Azure Traffic Manager. Traffic Manager is a DNS load balancer that sits outside/above Azure regions and allows you to have traffic balanced based on various performance profiles (i.e. Weighted, Performance, etc.)
High Level / General steps are:
Setup Logic Apps in 2 Regions
Create and register public dns domain for the logic apps - apps.foo.com (done outside Azure typically)
Point your DNS record for apps.foo.com to Azure Traffic Manager
Add endpoints to Azure Traffic Manager for Logic App in Region 1 and Logic App in Region 2 and setup your traffic manager profile
Calls to the Logic App start with the custom DNS domain get routed to ATM which then distributes to the regions based on your configured profile.
I know that with the Premium tier, I could have up to 50 instances to put my web app on in Azure. If I needed to go beyond this, like 75 instances, what would be the most appropriate way to do this?
Maybe two different app service plans, different web app endpoints load balanced by Traffic Manager?
Thanks!
A Hosting Plan is simply a geographical collection of web servers. With in that hosting plan you can have 'x' number of servers (depending on the SKU)
The machines in a Hosting Plan will be split across fault and update domains. So that a server rack dying, or an upgrade rollout won't take out all of the servers in the hosting plan.
However what this doesn't protect you against is geographically scaled issues. If you have a hosting plan in West Europe and the West Europe region suffers an outage. At that point you could lose your entire deployment.
This is where them being a geographical collection of servers becomes an important characteristic. If you create a number of hosting plans in a number of regions, not only will you have local redundancy against fault and update outages but you will also gain redundancy against geographical outages.
Obviously if you need 500 servers, there is nothing stopping you creating 10 premium SKU hosting plans and deploying them all to the West Europe region and creating some sort of round robin DNS load balancing solution.
But the better solution is to share them across regions. Creating a hierarchy of traffic manager profiles to share the load amongst them. With the right automation you can have some regions coming on and off line as your load increases / decreases.
Personally, unless I have specifically required premium features (Biztalk etc) my preference has always been to simply deploy more service plans. It is far more cost effective.