Suppose I have several role instances and one instance writes to Azure Storage (blob, tables or queue - whatever). How fast will other instances be able to see and read those changes?
There is no propagation of data from Azure Storage to Role Instances. When you request or persist data from storage you're making an OData request over the network in the background to the Azure Storage services.
Because the data is stored in a central location there is only one authority for the information. The instant that authority is updated, clients will immediately receive the updated data when it is requested.
Related
We have below flow on-prem to reload master data in cache of API servers. API servers are spring boot applications.
User uploads master data via excel files using admin UI.
These files is placed on NAS storage. After this, admin app calls REST endpoints on multiple API servers to reload this master data into API server memory cache.
We have plans to move this set up to azure cloud whereby API servers would be deployed on VM scale sets with auto scaling enabled.
Given that number of VMs, their IPs would vary, how can we support this master data reload in azure environment? One option I can think of -
Admin app reads the master data file and pushes it to a queue (either azure queue storage or active MQ)
API servers either have listeners or schedulers to get message from queue and reload master data.
Is this the best approach? But with queuing solutions, once message is read off queue by one API server, it will not be available for the other instances right?
Could anyone please advise on alternatives to support this master data reload in azure environment with minimal changes to current application?
Regards
Jacob
I have blob storage and app service in our Azure account.
I was uploaded by app service 200GB from my local PC to blob storage.
Data has been charged (14 EUR) as DATA TRANSFER OUT - Zone 1. I don't understand why it happened.
I previously thought that this type of data transfer is IN TO Zone 1 and is free (no charged).
I thought that all uploads to storage is free and all downloads from storage are charged.
Is it correct pricing ?
In case you use some kind of replicated storage as described here the outgoing replication traffic which flows across regions will be charged to you (described here at the bottom).
What is Geo-Replication Data Transfer Charge? When you write data into
GRS accounts, that data will be replicated to another Azure region.
The Geo-Replication Data Transfer charge is the bandwidth cost of
replicating that data to another Azure region.
Our plan is to migrate Azure Web Roles to Azure Web Sites. So far the Azure Web Roles were using Azure Caching that was shared across instances.
Our first thought was to switch to Redis Cache. But after a few other discussions we started discussing using just Http Runtime Cache as our data isn't big (we do not store any images or big data). It's all strings and numbers.
If go for Http Runtime Cache (using it on five instances of one Azure Web Site).
Could following scenario happen?:
Request comes to first instance that serves a content of freshly cached data.
User click's on an item but the request goes to second instance that has older cache at that moment that does not contain the item.
Would this result in an error? Is this a very possible situation? Can we be sure that the request will always go to that one instance?
By default Azure Websites implements sticky sessions, meaning that when a user makes a request and it gets routed to instance A, all future requests will also go to instance A for as long as instance A stays up
while developing Azure application I got famous error "Cache referred to does not exist", and after a while I found this solution: datacacheexception Cache referred to does not exist (for short: dont point multiple cache clusters to one storage account by ConfigStoreConnectionString)
Well, I have 3 roles using co-located cache, and testing+production environment. So I would have to create 6 "dummy" storage accounts just for cache configuration. This doesnt seems very nice to me.
So the question is - is there any way to point multiple cache clusters to one storage account? for example, specify different containers for them (they create one named "cacheclusterconfigs" by default) or so?
Thanks!
Given your setup, i would point each cloud service at its own storage account. So this gives two per environment (one for each cloud service). Now there are other alternatives, you could set up Server AppFabric cache in an IaaS VM and expose that to both of your cloud services by placing them all within a single Azure Virtual Network. However, this will introduce latency to the connections as well as increase costs (from running the virtual network).
You can also put the storage account for cache as the same one used by diagnostics or the data storage for your cloud services, just be aware of any scalability limits as the cache will generate some traffic (mainly from the addition of new items to the cache).
But unfortunately, to my knowledge there's no option currently to allow for two caches to share the same storage account.
I am hosting an on-premises website which I want to migrate to Windows Azure Virtual machine.I will be using multiple instances of Azure VMs. Currently I am using IN-Proc session management technique. Do I really need to change this session mode to migrate the website to cloud. Why??
If you want to have more than 1 Web Role Instance (for load balancing/scalability/redundancy purposes) then Yes you do need to change it. Just a reminder, but you need a minimum of 2 roles in order to be eligible for the 99.9% SLA.
InProc means that the session information is stored in that web roles process. a second web role instance, has no knowledge of that data contained in process in the first web role.
So if your first web request goes to WEBROLE_1 it has your session information.
If your second request goes to WEBROLE_2, it won't know that you already have some session data stored in the other role.
There are a number of other options for storing your session info including using TableStorage, SQL Azure or App Fabric Cache.