I have 2 instances of azure worker role project publish in azure cloud.
Currently i am publishing both instances to west Europe as I declared in my cloud service.
Is it possible to set one instance to west Europe and the other one to USA in one cloud service, or do I need to declare 2 cloud service - one for each region ?
Scaling a Azure Cloud Service is available only within the region or datacenter. You will need to deploy an instance in each region.
Please check Scaling Azure cloud services geographically across multiple data centers.
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.
As per my knowledge, Azure VM allows user to do in-place scaling up and down with Reserved Instance (RI) offer (1/2/3 yrs).
If I have an App Service with Premium plan, and Azure Advisor service gives me recommendation to use RI, how do I use the reserved instance offer for 1/2/3 years? Can I just scale down App Service plan to availa the new pricing from App service left navigation panel and just select the new plan or same plan with RI offer? Because I am unable to do this in-place scaling down to use RI for my existing App Service plan in my Dev/Test or Prod environments.
Or do I have to recreate my App Service plan infrastructure from scratch again to use RI offer of Premium or Isolated plan?
The important thing to know about Reserved Instances in Azure is that
The reserved instance pricing applies to the applicable instances in
your subscription, up to the number of instances that you reserve. The
reserved instances are a billing matter and are not tied to specific
compute instances
App Service RI
So if you reserve 2 instances, then each billing period will have the cost of up to 2 instances deducted. If you are running 3 matching instances, the cost for 2 will be deducted. If you are running 1 matching instance, the cost for 1 will be deducted.
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 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).