We have one webapp running on Azure, which pushes data to Azure Redis, then we have an on-prem component which reads that data from Azure redis and processes that.
Recently due to Azure region failure that Azure Redis went down. Web app and my on-prem component was not able to contact Azure redis.
How can I make sure zero down time for my web app to access Azure redis ?
Redis-GeoRelication doesn't solves my problem as it is unideirectional, and Manual failover. Also my web app and on-prem component need to know both redis endpoint, and contact accrondignly. which is not seemless.
Azure redis doesn't support cluster having shards in multiple region.
So my requirement is, Web-app and on-prem component both need to contain one cache/database endpoint ( without having any knowledge about the replication of the cache/database). if primary cache/db fails then, that endpoint should automatically goes to replicated cache or DB.
As per Documentation from Azure, it doesn't seem Azure Redis is correct fit for this requirment, is there any other Azure component which fits this requiremnet.
Had a look to Azure sql with failover group. As per documentation, "you can configure a grace period that controls the time between the detection of the outage and the failover itself. It is possible that traffic manager initiates the endpoint failover before the failover group triggers the failover of the database. In that case the web application cannot immediately reconnect to the database. But the reconnections will automatically succeed as soon as the database failover completes." . We can set that grace period to 1 hour (minimum) .
So it means with Azure sql also. In case of failure of one db server, my web application will not be able to write to db for atleast 1 hour, Is my understanding correct ?
Azure SQL and Azure Cosmos DB both support single endpoint and HA across regions, you might want to look into those.
Those are not caches, but they do allow for a single endpoint and failover
Related
I have two subscription in an azure account
After I only changed sql database from subscription A to subscription B,
The website slowed down.
Now sql database is in subscription A.
And cloud service is in subscription B.
Could this be related?
Now SQL database is in subscription A, and cloud service is in subscription B.
Could this be related?
The short answer: no.
The slightly longer answer: there might be multiple factors that impact the performance between the Cloud Service and the database. You could think of location, network, hardware, SKU/tier and so on. The subscription the database is in should not be one of them.
As long as all other properties of the database and the server it runs on are the same as they were previously, there should be little to no difference in the performance of the connection between the two.
Azure continuously monitors the latency (speed) of core areas of its network using internal monitoring tools as well as measurements collected by ThousandEyes, a third-party synthetic monitoring service.
and
Monthly latency numbers across Azure regions do not change regularly.
Also, this might be an interesting read: Microsoft global network.
Let's say that I have an azure sql (paas) that has in front of it a scale set of VM's, each VM containing a website hosted in IIS. In front of the scaleset i have a traffic manager for website updates purpose only ( whenever i need an update, i create a second scaleset with VM's having the latest version and after the second scaleset deploy, i change the traffic manager to route traffic to the newly created scaleset). The website is 100% stateless. The problem raises for me just after i create the second scaleset: how would i run rollout scripts on sql azure db without disturbing clients that consume the old website version?
I am thinking of using mirroring or sort of for the db to replicate transactions on a second azure db, while running on it in the same time rollout scripts. I just have then to cut traffic from the live scaleset and wait for sessions to drain and then switch to the new scaleset. is this a good aproach? I see that i lose the "always on" capability that i really need. I really don' t know the best practice, a book or a link would be highly apreciated.
In short, i would like to remain as "highly available as possible" even for planned application updates. How can I reach this?
Try or consider having 1 more SQL Azure database. Your traffic manager could indicate also which of the 2 SQL Azure database is the active. Deploy changes to the passive database, then update the traffic manager database to make the passive database the new active database.
We are looking to host our Azure web application at 2-3 locations globally to reduce load latency and for BCP if an application server fails (we will use Traffic Manager to direct traffic)
We will be co-locating the Azure SQL DB databases along with the web app. We want to get the databases synced near real-time. The data volumes will be under 1 GB on any given day. There will be no on-premise database. Here intent is not to have a master slave but more active-active databases
Given Azure Data Sync is now in GA,
a) What kind of delay in sync should I plan for (I can tolerate a few seconds of latency)
b) Will there be any performance issues in both the DB's during these periods of sync. How do conflicts get resolved- latest timestamp?
c) Can I use out of-the-box azure portal functionality- or will I need additional tools
Minimum sync frequency is 5 minutes.
Check this out https://learn.microsoft.com/en-us/azure/sql-database/sql-database-sync-data
I have one Microsoft Azure subscription with one cloud service and one sql azure instance. Now I want create another cloud service with a different subscription (using a different microsoft account). With this second cloud service, can I use the same sql azure instance of the first subscription? (I need to share data between the two cloud service)
Or there may be performance issues?
Thanks in advance
Yes. Azure SQL DB instance can be accessed from different subscription as long as you have the connection string, username and password to the Azure SQL instance. As long as both the services are from the same region, there is no performance issue.
Yes, sure. From user perspective SQL Azure is mostly an ordinary SQL Server which you can access from anywhere in the world (given that the firewall rules allow that access) - from Azure services, from VMs in some other services hosted elsewhere, from your desktop, from servers in your company server room.
Network latency might kick in. Also more clients to the same instance mean more load. Also there's a limit on number of concurrent connections. Other than that - no problems.
You need to make sure are a member in each Azure instance to be able to use the others SQL DB
I recently got a trial version of Windows Azure and wanted to know if there is any way I can deploy an application using Cassandra.
I can't speak specifically to Cassandra working or not in Azure unfortuantly. That's likely a question for that product's development team.
But the challenge you'll face with this, mySQL, or any other role hosted database is persistence. Azure Roles are in and of themselves not persistent so whatever back end store Cassandra is using would need to be placed onto soemthing like an Azure Drive (which is persisted to Azure Blob Storage). However, this would limit the scalability of the solution.
Basically, you run Cassandra as a worker role in Azure. Then, you can mount an Azure drive when a worker starts up and unmount when it shuts down.
This provides some insight re: how to use Cassandra on Azure: http://things.smarx.com/#Run Cassandra
Some help w/ Azure drives: http://azurescope.cloudapp.net/CodeSamples/cs/792ce345-256b-4230-a62f-903f79c63a67/
This should not limit your scalability at all. Just spin up another Cassandra instance whenever processing throughput or contiguous storage become an issue.
You might want to check out AppHarbor. AppHarbor is a .Net PaaS built on top of Amazon. It gives users the portability and infrastructure of Amazon and they provide a number of the rich services that Azure offers such as background tasks & load balancing plus some that it doesn't like 3rd party add-ons, dead-simple deployment and more. They already have add-ons for CouchDB, MongoDB and Redis if Cassandra got high enough on the requested features I'm sure they could set it up.