I see that azure Microsoft-hosted build agents are allocated in the same geography as the Azure DevOps organization. However, is there anyway to request for Microsoft hosted build agents to be allocated in a different region?
Our issue is, that our Azure DevOps organization is in region eastus2, where offices are in US, EU and AU. For test setups we get resources from azure on the go. ex. rabbitmq containers. Different offices maintain their own subscriptions and maintain different resource groups in the same regions closer to their offices.
Given that, we observe if a one in AU setup a pipeline to use a rabbitmq container it is allocated in the same region as the resource group, where Microsoft hosted agents in US, tests timeout.
But if we change the resource group to EU/US or the resource to EU/US, tests do not timeout. Given, each office prefers to have their resources in the same region as the office, is there any suggestion to overcome the issue?
As it is written here
Your hosted agents run in the same Azure geography as your organization. Each geography contains one or more regions. While your agent may run in the same region as your organization, it is not guaranteed to do so. To obtain the complete list of possible IP ranges for your agent, you must use the IP ranges from all of the regions that are contained in your geography. For example, if your organization is located in the United States geography, you must use the IP ranges for all of the regions in that geography.
This is not necessarily true that your organization is in the same region as your agents. They are in the same geography.
But answering you question this is not possible to request for agent for another region. So if you need that you need to consider self hosted agents on your won infrastracture. You can create several agent pools and handle them to support your need.
Related
I've got a pipeline that builds web artefacts and attempts to copy them to my Azure Storage using the Azure File Copy task provided in the Azure Pipelines. I've been trying for the last 2 days to fix this 403 response, stating there is a permissions error.
I have a service connection for this pipeline.
The service connection application registration has user_impersonation for Azure Storage in API Permissions
The service connection application registration has 'Storage Blob Data Contributor' & 'Storage Blob Data Owner' for the target Storage Account, the Resource Group and the Subscription.
Since the storage account uses a Firewall and has IP range whitelisting enabled according to your comment, you should add the agent's IP address to the whitelist.
If you're running your own build agent, it's pretty straightforward.
If you use Microsoft-hosted agent to run your jobs and you need the information about what IP addresses are used, see Microsoft-hosted agents Agent IP ranges.
In some setups, you may need to know the range of IP addresses where agents are deployed. For instance, if you need to grant the hosted agents access through a firewall, you may wish to restrict that access by IP address. Because Azure DevOps uses the Azure global network, IP ranges vary over time. We publish a weekly JSON file listing IP ranges for Azure datacenters, broken out by region. This file is published every Wednesday with new planned IP ranges. The new IP ranges become effective the following Monday. We recommend that you check back frequently to ensure you keep an up-to-date list.
Since there is no API in the Azure Management Libraries for .NET to list the regions for a geography, you must list them manually.
EDIT:
There's a closed (! - but still active) GitHub issue here: AzureDevops don't considerate as 'Microsoft Services'
EDIT 2:
Your hosted agents run in the same Azure geography as your organization. Each geography contains one or more regions. While your agent may run in the same region as your organization, it is not guaranteed to do so. To obtain the complete list of possible IP ranges for your agent, you must use the IP ranges from all of the regions that are contained in your geography. For example, if your organization is located in the United States geography, you must use the IP ranges for all of the regions in that geography.
To determine your geography, navigate to https://dev.azure.com/<your_organization>/_settings/organizationOverview, get your region, and find the associated geography from the Azure geography table. Once you have identified your geography, use the IP ranges from the weekly file for all regions in that geography.
Since yesterday, I'm trying to create new VM and I'm not able because the majority of the sizes are not available for my region, West Europe. Using Azure Portal I get all D series greyed:
I tried Azure Reservations with same result:
I suppose there are issues in this and another regions.
But then I tried to get availability using CLI tool az, following this reference. The, executing referenced command I get this list of available sizes:
It seems contradictory information, because I see some D series VM.
May it be that they are available in general, not taking into account current occupation?
Is there any az command to get actual available sizes in my region?
Da/Das series VMs use AMD CPU. However, based on my test, they are not available in location West Europe.
The normal D series VM should be available in West Europe. There are several reasons which may prevent you from choosing it:
You have reached your CPU resource limitation in that region. To solve this, you may request an increase in CPU quota limits per Azure VM series
Some Azure subscriptions (trial, MSDN developer, student trial and so on) can only create limited resources in limited locations. To solve this, you may update your subscription to a pay-as-you-go one.
Other reasons. You may directly contact the Azure Support team by submitting a support request on the Azure portal.
I have been tasked with building a PoC in Azure to "simulate" a future global deployment where data transfer time is important factor. The actual deployment will be using fully on-prem resources. So, as odd as it sounds, I am looking for the worse performance possible between the two options.
Architecture A (single tenant):
Create a single Azure tenant in the US region
Create a Resource Group with a US-based location
Create another Resource Group with an EU-based location
Architecture B (dual tenant):
Create an Azure tenant in the US region with a US-based RG
Create an entirely separate Azure tenant in an EU region with a EU-based RG
Would the dual-tenant structure above make any measurable difference one way or the other from the single-tenant (assuming all vNetwork, VMs, etc are identical)? I am thinking the single-tenant setup would be faster since (presumably) the traffic never leaves the Azure Service Fabric. But that's just speculation.
Here is what I got back from a colleague. She is (obviously) far more versed in Azure IaaS than I am. Answer #3 below indicates that the closest analog to the client MPLS connection is via VPN/ER. Not really worth the cost but still good to know.
Can a single subscription be used to provision US and European region located resources? Yes
Can resources in US and European located regions be managed from a US based portal? Yes
When allowing resources in US and European located regions communicate with one another what are our options? A couple primary ways...
Intra-regional (tenant to tenant:region to region)
Communications can be provisioned to travel across the Microsoft Azure
backbone. It never hits the open Internet.
VPN or Express Route:
Travels either the open internet or a private in TLS like route from
one region to another. However express route, the mpls like option,
does require advanced routing (BGP) and dedicated circuits at I other
point from different connectivity providers. Also, expensive.
Can we use same subscription in different Azure region. I want to create different Virtual Networks in different region and design protocol to communicate these regions.
Regards
Abdul
Yes, you can easily use the same subscription to spin up resources in other regions in Azure.
What regions you can use depends on your subscription type though. If you use any of the Azure credit offers you will find that certain offers has limits on the regions they can activate resources in.
I would recommend that you simply test by making a resource group in Azure in the region you want to test with, then create a new Azure Virtual Network in that resource group (which will per default have the same region).
This shows you the regions available to you. Repeat for each region you want a network in.
If you wish to connect the Azure Virtual Networks in different regions with each other you can setup Azure Virtual Network Peering
A little side note.
Not all types of resources are available in all regions. I would recommend checking what regions are available in the Azure Region Map, then check the Offers by Region page to see if the product you want to use is available in your chosen region.
I've created a Hosted Service that talks to a Storage Account in Azure. Both have their regions set to Anywhere US but looking at the bills for the last couple of months I've found that I'm being charged for communication between the two as one is in North-Central US and the other South-Central US.
Am I correct in thinking there would be no charge if they were both hosted in the same sub-region?
If so, is it possible to move one of them and how do I go about doing it? I can't see anywhere in the Management Portal that allows me to do this.
Thanks in advance.
Adding to what astaykov said: My advice is to always select a specific region, even if you don't use affinity groups. You'll now be assured that your storage and services are in the same data center and you won't incur outbound bandwidth charges.
There isn't a way to move a storage account; you'll need to either transfer your data (and incur bandwidth costs), or re-deploy your hosted service to the region currently hosting your data (no bandwidth costs). To minimize downtime if your site is live, you can push your new hosted service up (to a new .cloudapp.net name), then change your DNS information to point to the new hosted service.
EDIT 5/23/2012 - If you re-visit the portal and create a new storage account or hosted service, you'll notice that the Anywhere options are no longer available. This doesn't impact existing accounts (although they'll now be shown at their current subregion).
In order to avoid such charges the best guideline is to use Affinity Groups. You define affinity group once, and then choose it when creating new storage account or hosted service. You can still have the Affinity Group in "Anywhere US", but as long as both the storage account and the hosted service are in the same affinity group, they will be placed in one DataCenter.
As for moving account from one region to another - I don't think it is possible. You might have to create a new account and migrate the data if required. You can use some 3rd party tool as Cerebrata's Cloud Storage Studio to first export your data and then import it into the new account.
Don't forget - use affinity groups! This is the way to make 100% sure there will no be traffic charges between Compute, Storage, SQL Azure.