I am a year old in using Azure resources.
I have an HTTP trigger function app and cosmos DB as a backend database. I am using a consumption plan for my function app, which I understand makes the system serverless. And by serverless, I understand I don't have to worry about the infrastructure.
So this serverless system is redundant within the region by default? or do I need to handle failover, by having an extra instance of the function app/cosmos DB in the same region which will serve as a backup instance?
Note - I'm talking about the same region failover, not multi-region redundancy.
Availability zone (AZ) support isn't currently available for function apps on Consumption plans.
In Consumption Plan, the functions apps SLA is 99.95% of the time.
It won't failover to a different geo region, no matter the hosting SKU. Use Traffic Manager to achieve that level of redundancy.
Needless to say, all resources your function depends on need to exist in the 2nd region as well (SQL instances, Redis, Event Hubs, ...). You are responsible for keeping state consistent across regions (think Azure SQL auto-failover groups).
One notable exception is Cosmos DB, which (if configured) can have automagically-managed replicas in multiple regions. Your function will always use the same connection string.
The best you can do (IMHO) is to define the data redundancy as Geo-zone-redundant storage and let Azure handle this for you.
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.
I am confused with azure SQL database backup plan (short term backup retention).
As far as i understood,
In DTU purchasing model, no extra charge for backup storage, you only pay for redundancy type (such as LRS,ZRS)
In vCore purchase model, you will have to pay for backup storage.
am i right ?
does that mean , i will not have any backups if do not subscribe to backup storage in vCore ?
further, in azure pricing calculator, in vCore, General purpose option, you have two redundancy drop down options (i am not talking about long term retention plan) , what is the difference between them ?
Thanks.
i will not have any backups if do not subscribe to backup storage in vCore ?
Yes, in vCore, if you do not allocate a storage account for backups, you will not be able to perform backup operations, either manually or automatically. If you believe you do not need backups, then you might be a fool ;), Azure will maintain access to your database according to the standard SLAs but the infrastructure will not provide a way for you to point-in-time restore the state of your database, only backups can adequately do that for you. But the storage costs are usually a very minimal component of your overall spend. Once the backup operation is complete you can download the backup for local storage and then clear the blob, making this aspect virtually cost free, but you will need a storage account to complete the backup process at all.
in azure pricing calculator, in vCore, General purpose option, you have two redundancy drop down options
Are you referring to the Computer Redundancy:
Zone redundancy for Azure SQL Database general purpose tier
The zone redundant configuration utilizes Azure Availability Zones to replicate databases across multiple physical locations within an Azure region. By selecting zone redundancy, you can make your serverless and provisioned general purpose single databases and elastic pools resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes of the application logic. This configuration offers 99.995% availability SLA and RPO=0. For more information see general purpose service tier zone redundant availability.
In the other tiers, these redundancy modes are referred to as LRS (Locally Redundant) and ZRS (Zone Redundant). Think of this your choice on what happens when your data centre is affected by some sort of geological or political event that means the server cluster, pod or whole data centre is offline.
Locally Redundant offers redundancy only from a geographically local (often the same physical site). In general this protects from local hardware failures but not usually against scenarios that take the whole data center off-line. This is the minimal level of redundancy that Azure requires for their hardware management and maintenance plans.
Zone Redundant offers redundancy across multiple geographically independent zones but still within the same Azure Region. Each Azure availability zone is an individual physical location with its own independent networking, power, and cooling. ZRS provides a minimum of 99.9999999999% durability for objects during a given year.
There is a third type of redundancy offered in higher tiers: Geo-Redundant Storage (GRS). This has the same Zone level redundancy but configures additional replicas in other Azure regions around the world.
In the case of Azure SQL DB, these terms for Compute (So the actual server and CPU) have almost identical implications as that of Storage Redundancy. So with regard to available options, the pricing calculator is pretty well documented for everything else, use the info tips for quick info and go to the reference pages for the extended information:
The specifics are listed here: Azure Storage redundancy but redundancy in Azure is achieved via replication. That means that an entire workable and usable version of your database is maintained so that in the event of failure, the replica takes the load.
A special feature of replication is that you can actively utilise the replicated instance for Read Only workloads, which gives us as developers and architects some interesting performance opportunities for moving complex reporting and analytic workloads out of the transactional data manipulations OOTB, traditionally this was a non-trivial configuration.
The RA prefix on redundancy options is an acronym for Read Access.
I have an Azure Function Premium plan for a C# function. I need this because my function needs to be deployed inside a VNET. Now I need to deploy another Python function. Can I reseuse my Premium plan? If I understand correctly it's a "server" which is running forever but which is only "used" when a function is triggered. Running two such a servers will be expensive and overkill for my functions.
Yes, you can run multiple Azure Function Apps in the same premium hosting plan, but the limitation is they should both run on same operating system either windows or Linux.
Running two such a servers will be expensive
Yes, it is expensive because of pre-warmed instances and always ready instances but predictable pricing.
The main 3 factors considered on Azure Functions are Application Insights, Network Traffic and Storage Account.
As per my experience,
Storage account is used by Azure functions for its internal state in which these costs are negligible.
When the functions are sending the traffic the outside world (Egress traffic), then the networking fees would occur which is usually low but may raise cost for high-volume data sending by the Azure Function.
Application Insights cost is the main factor we have to monitor and optimize. Refer to these few workarounds (Thread1 & Thread2) for optimizing cost in Azure Function - App Insights.
The Consumption Plan for Azure Functions is quite ideal, with its pleasant pricing and automatic scaling. However, I haven't found much information about High Availability with such a plan.
Let's consider a scenario. Imagine that, based on the load, there is currently one instance of the function app running. Then there is a problem in that data center. The consumption plan only scales out based on load. I can find no guarantees that a new instance will be added in this scenario, let alone that downtime will be prevented.
I'm aware that we could use Azure Front Door, with two separate function apps behind it. However, it appears that we must manage those function apps separately. That is a hassle. Swapping slots twice, remembering to change app settings in two places... That's no good.
What I'd like to achieve is something like Azure SQL in its Premium or Business-Critical tier, preferably with zone-redundant configuration. The diagram here shows how that works: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-high-availability#zone-redundant-configuration
In simple terms, there is a primary replica with automatic failover to a secondary replica in the same data center, and also automatic failover to secondary replicas in two different data centers within the availability zone.
Notice how there is no manual management of the secondary replicas, since they are simply replicated from the primary.
How much of this can we achieve with Azure Functions, and how?
According to MSDN, an azure service can conatins any number of worker roles. According to my knowledge a worker role can be recycled at any time by Windows Azure Fabric. If it is the true, then:
Worker role should be state less OR
Worker role should persist its state to Windows Azure storage services.
But i want to make a service which conatains client data and do not want to use Azure storage service. How I can accomplish this?
The velocity (whatever it is called) component of AppFabric is a distributed cache and can be used in these situations.
Azure's web and compute roles are stateless means all its local data is volatile and if you want to maintain the state you need to use some external resource to maintain that state and logic in your app to handle that. For simplicity you can use Azure drive but again internally its a blob storage.
You can write to local storage on the worker role by using the standard file IO APIs - but this will be erased upon instance shutdown.
You could also use SQL Azure, or post your data off to another storage service by HTTP (e.g. Amazon S3, or your own server).
However, this is likely to have performance implications. Depending on how much data you'll be storing, how frequently, and how big it is, you might be better off with Azure Storage!
Why don't you want to use Azure Storage?
If the data could be stored in Azure you have a good number of choices: Azure distributed cache, SQL Azure, blob, table, queue, or Azure Drive. It sounds like you need persistence, but can't use any of these Azure storage mechanisms. If data security is the problem, could you encrypt/hashing the data? Understanding why would be useful.
One alternative might be not persist at all, by chaining/nesting synchronous web service calls together, thus achieving reliable messaging.
Another might be to use Azure Connect to domain join Azure compute resource to your local data centre (if you have one), and use you on-premise storage.