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).
Related
I need to create a DINE policy, but it has to deploy different resources depending on the region.
For example:
If I am deploying in West Europe, I need to "DeployIfNotExist" a resource in West Europe.
If I am deploying in East US 2, I need to "DeployIfNotExist" a resource in East US 2.
Scenario:
I am adding to the diagnostic settings of Azure SQL, a link to EventHub (which is already existing in weu or eus2)
Is that possible todo?
** I know we can create two policies with the existing condition checking the region, but I am looking for a solution to do it in a single policy. **
I have a VM in Azure in location Central US . I have some restore points (fullbackups).
Can i restore the VM to a different resourcegroup in West US and reconnect to it with RDP ?
this is for disaster recovery if there is an issue with the Azure location or VM .
Also how can we guarantee that any location wont have issues ?
Interesting question.
You want to restore a VM hosted on the Central US to the West US.
Let's look into the Public Docs.
You could use the Cross Region (secondary region) restore to
restore Azure VMs in the secondary region, which is an Azure
paired region.
You can restore all the Azure VMs for the selected recovery point if
the backup is done in the secondary region.
During the backup, snapshots aren't replicated to the secondary
region. Only the data stored in the vault is replicated. So secondary
region restores are only vault tier restores. The restore time for the
secondary region will be almost the same as the vault tier restore
time for the primary region.
This feature is available for the options below:
Create a VM
Restore Disks
Unfortunately, I don't see the Central US region pairs with the West US region. So for your question if you can select your specific regional pair, answer is no.
Some Azure services rely upon regional pairs, such as Azure's
redundant storage. These services don't allow you to create new
regional pairings. Similarly, because Azure controls planned
maintenance and recovery prioritization for regional pairs, you can't
define your own regional pairs to take advantage of these services.
However, you can create your own disaster recovery solution by
building services in any number of regions and leveraging Azure
services to pair them.
I hope above helped to answer your questions.
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'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).
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.