I've been scouring the internet to try to find information on how Azure Storage and Azure Virtual Networks work together, is it possible to setup a Storage so that it can be accessed from another location?
For example I have a centralized authentication solution hosted on the US EAST center, but I have several identical region-local systems (one on EU NORTH, EU WEST, US EAST and US WEST) that need to be able to authenticate its users against the centralized authenticator located on the US EAST data-center.
Storage is not accessed via virtual networks. It's is accessed via its URI endpoint directly. You just access it from your app. If you cross region boundaries (e.g. running an app in one region, accessing storage in another region), you have to deal with latency, plus the cost of any outbound storage cost (for any data leaving the region).
Related
Background: I have application run by aks and azure SQL database on azure in central India. Now I have to expand it to outside India. Data from one region shouldn't travel outside the region.
Problem:
Now I have region 1 and 2 with aks & db on the respective regions. Now I need to have same url for both the regions but the traffic shouldn't be travelled to any other region. I tried with frontdoor based on latency but on edge cases the traffic is travelling outside the region. What azure services can help me in this scenario? Please suggest, thanks in advance.
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.
I have a cloud service and a storage account deployed using the classic resource manager in the East US region; there is also a classic backup vault in the West Europe region.
Due to high latency, I want to move all of these resources to the UK South region, which is the closest one to me and others using these services. I have created a new resource group in the UK South region, however, when I try to move my existing classic resources to the new resource group, it says:
Classic resources must be moved separately and aren't displayed below.
Reading the article it linked to, it says that to move classic resources when experiencing this limitation, I need to contact support to have this operation done manually.
I do not have a support plan and am hoping not to buy one for this single task. Is there any other way around this limitation?
I think that you can walk around it by:
1. Create a new blank cloud service in your new resource group in UK South region.
2. Modify the deployment process to deploy the code to the newly created cloud service.
I hope this helps.
As you mentioned that it is limited by Azure. The following is snippet from the official document.
When moving resources from one resource group to another resource group within the same subscription, the following restrictions apply:
Virtual networks (classic) cannot be moved.
Virtual machines (classic) must be moved with the cloud service.
Cloud service can only be moved when the move includes all its virtual machines.
Only one cloud service can be moved at a time.
Only one storage account (classic) can be moved at a time.
Storage account (classic) cannot be moved in the same operation with a virtual machine or a cloud service.
As Toan nguyen mentioned that we need to redeploy it if you don't want to call Azure Support.
I have a webservice which uploads data to blob store. I have 2 deployments of this webservice, on in south east asia and one in US. Each deployment has a different storage account associated with it(while creating a cloud service you can associate a storage account with it), say StorageSEA and StorageUS.
As of now, I read the storage account connection string from the config, which means that when I deploy to southeast asia I have to go and update the connection string to point to StorageSEA and change it to StorageUS when publishing to US. This doesn't seem like a approach I will be able to sustain in future, as I plan to go ahead with more deployments.
So I was wondering if there was a way to get the associated storage account instead of updating the config file for each deployment.
There are two solutions I could think of:
Use config transformation to create 2 separate deployment configuration files - one for South East Asia and other one for US. Each config file will have storage account for that data center.
Programmatically identify the deployment location - In this case, you would define both storage account connection string in your configuration file. When the role starts up, you would find the data center location of the cloud service and based on that you pick up one of the values. For this to work, you would need to implement Service Management API's Get Hosted Service Properties operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460806.aspx).
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.