I'm deploying a global networking solution and using Terraform as my IaC solution. I have ExpressRoutes, VPN Gateways, Vnet-to-Vnet connections etc.
I've deployed a VPN Gateway in Azure North Central US and now when I come to deploy and IP address for it I can't. By default I use Zone-Redundant availability zones. Ie. Zone 1, 2 and 3. When I try to deploy an IP using Terraform, I can't use any of the available options - no zone string list, no single zone, not the No-Zone or None parameter. All I get is an error from the MS API saying the available zones for the region are ''. It's literally empty.
If I deploy it manually then get the IP properties of the address it shows the zones as an empty array. Are MS experiencing issues right now? I find it incomprehensible that the North Central US zone which is the regional pair of South Central US (which has 3 availability zones) has...no zones. I'm confused. Could someone share their experiences please, and advise whether this is a temporary issue. I scoured the internet and found nothing. I'm normally working in the European Azure regions so this is the first time I've used this particular one.
Currently, there are no availability zones present for North Central US in Azure but as per the document here, availability zones will be coming soon for North Central US. As of now, these are the Azure Regions with Availability zones.
Related
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.
I'm creating an application which uses an API that has black-listed countries. I'm currently developing this on an Azure VM. I'm in the UK and I'm allowed access to the API here, however my VM's IP shows up as being in the States which is disallowed. I believe a European IP would work.
Is there any way around this? My VM/Cloud Service location is West Europe. I've tried configuring a reserved public IP for West Europe also but this hasn't worked. I guess my understanding of what that actually does is flawed.
Thanks in advance.
Your understanding seems allright. Depending on the region you choose, your Cloud Service will be physically located in different Azure datacenters. For West Europe it would be Netherlands.
The thing that is flawed is IP Geolocation. These kind of services are based on databases that can be inaccurate. Microsoft for example can register some large IP address space as US, but they can assing some of these addresses to a datacenter in Netherlands - and there is no way for the Geolocation service to know about it.
For my services that are also in West Europe, some of them are reported be in US, some in NL - and different geolocation services gives different results.
Like the question says, I'm really having a problem where, although I've signed up for a Western Europe Windows Azure VM, whenever I access a site or service from this server I'm getting assigned a U.S IP Address.
This is really problematic because those services require my IP to be in Europe. Anyone else have this issue and know how I can change the IP somehow?
To add on to John's comment above, every Azure IP address is registered to Microsoft in the US. There is no option for support to provide you with a "European IP address" since such a thing doesn't exist in Azure. You should work with the other service provider to explore alternative options to requiring IP addresses registered to a European address since their strategy ultimately won't work as more services move to shared cloud infrastructures.
I want to add traffic manager to my azure virtual machine.I created total 4 virtual machine .2 in east us region and 2 in north Europe region.but when i want to add the both 2nd machine in the availability set respectively i didn't find the other machine which i want to add.
so help me to configure this
Availability Sets and Traffic Manager are not related subjects in Azure. When you create your two virtual machines in each Region make sure to add them to the same Cloud Service. This will enable load balancing and enforce availability set behaviour across the two VMs.
Repeat this in the second Region.
Then use Traffic Manager to route traffic using a Failover strategy (if appropriate) to the public interfaces of the Cloud Services.
While this is about using Web Roles you might find this blog series useful: http://blog.kloud.com.au/2014/11/03/deploy-an-ultra-high-availablity-mvc-web-app-on-microsoft-azure-part-1/
Availability sets are not the same as the traffic manager.
Availability sets are per region (that's why you only see 2 machines)
Add a traffic manager through the portal and select the VM's in both regions.
http://michaelwasham.com/windows-azure-powershell-reference-guide/understanding_configuring_availability_sets_powershell/
https://alexandrebrisebois.wordpress.com/2013/07/23/windows-azure-traffic-manager-high-performance-availability-resiliency/
I have a website hosted in Azure, which is globally load balanced across 3 different Azure data centres.
We can see from the following DNS check, that requests coming from the US, resolve to my West-US data centre. In and around Europe go to my European DC. South east asia goes to East Asia fine, but the entire of Australia gets routed to the US.
https://www.whatsmydns.net/#A/www.whatsonglobal.com
Being an Australian resident, and im sure for our Australian customers this isn't great. Especially since it's currently adding an extra 3 seconds of load time to the homepage.
How do I fix this without having to choose a different load balancer? I like the simplicity of the Azure traffic manager, but only if it's up to scratch.
Patrick, first off, the whatsmydns.net URL shows that the entire of Australia is not going to the US. 2 locations are going to Europe, and 1 location is going to US.
Azure constantly probes the LDNS servers around the world from all datacenters and regularly updates the performance tables in order to route users to the 'closest/fastest' datacenter. The fastest datacenter is usually based on the routing and peering relationships between ISPs, so it may not always be the geographically closest datacenter.
Most likely your users are getting faster performance from the website selected by the WATM endpoint than they would be from any other website, but you can validate this by trying to browse directly to the website URLs. If you find that WATM is not sending users to the fastest datacenter then you can open a support incident to have the Azure team investigate the routing and latency table.
Patrick - the behaviour is most likely due to there being no local footprint (yet) for Azure in Australia. There are CDN endpoints located in Australia and that's about it right now.
If you've got a site hosted in Azure then you'll be in Singapore, West US or any of the existing Regions anyway so the latency for users in Australia wouldn't be affected by hitting Traffic Manager in the US.