Do Logic Apps have some sort of built in geo-replication like the Azure Scheduler or Key Vaults? I can't seem to find any information about it.
I have seen some implementations using API management but that is for Logic App that use HTTP triggers, in my case I'm using Service Bus triggers.
If there is no geo-replication how would a disaster recovery implementation look like for my scenario?
I think you are asking three questions - How do I get a geo-redundant Logic Apps deployment and How do I get a geo-redundant Service Bus Messaging deployment and how do I use them in combination.
I would start with the Service Bus Messaging side as it is the foundation for the LA process. In order to have a geo-redundant Service Bus Messaging queue you have to use the Premium SKU and this article goes into detail on how it works: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-geo-dr
For the Logic Apps side you would setup an LA in each region (primary and secondary) and point the Logic Apps to the alias for Service Bus Queue. You would then disable the Logic App in the secondary region and only enable it when the primary region's Logic App was not operational. This would have to be done with some endpoint monitoring scripting and then switch over to the secondary and disable the primary.
Like you said, there are other more automated options (Traffic Manager) when Logic Apps is being triggered by HTTP traffic but since you are reading queues the recovery is more complex.
Related
I have a local machine that reads RabbitMQ queue messages.
I wish to move it to cloud. Which Azure service can be used in this case?
I went through event hubs, but I am not sure, if it would read messages from rabbitMQ continuously.
Any suggestions for the service that should be put to use.
You should take a look at Azure Service Bus. It has got FIFO queues as well as publish/subscribe capabilities. However if using Azure managed service is not a strict requirement you can use RabbitMQ on a VM (or a cluster for high availability) as well.
UPDATE: Your response means you want a managed service. There are 2 options - if you want to go with RabbitMQ but do not want to manage the infrastructure you can go for 3rd party service provider like CloudAMQP who will manage it on your behalf. The other option is to go for Cloud native messaging - meaning if you are on Azure you change your messaging service to Azure Service Bus. This would mean changing you code as well.
I'm developing a basic Azure IoT Remote Monitoring solution with the Azure Solution Accelerator "Remote Monitoring". When I start to actually pay for services and stop using a free account, very soon the cash starts to pile up and there seem to be very many resources created behind the scenes. I'm wondering which resources I really need and which one I could throw away to save money. These are the resources that I have:
App Service plan
App Service
Network interface
Network security group
Public IP address
Virtual network
Storage account
Azure Cosmos DB account
Device Provisioning Service
Event Hubs Namespace
App Service
App Service plan
IoT Hub
Key vault
Logic app
Azure Maps Account
API Connection
Disk
Storage account (2)
Stream Analytics job
Time Series Insights environment
Time Series Insights event source
Virtual machine
CosmosDB is probably one of the more expensive resources in your list so if you can find a way to swap some other datastore for it you can save some money.
Take a look at Remote Monitoring architectural choices. The Azure IoT Remote Monitoring solution accelerator is an open-source, MIT licensed, solution accelerator. To help you speed up your IoT development process, it shows common IoT scenarios such as:
Device connectivity
Device management
Stream processing
The Remote Monitoring solution follows the recommended Azure IoT reference architecture.
This article describes the key architectural and technical choices made in each of the Remote Monitoring subsystems. However, the technical choices Microsoft made in the Remote Monitoring solution aren't the only way to implement a remote monitoring IoT solution. You should regard the technical implementation as a baseline for building a successful application and you should modify it to:
Fit the available skills and experience in your organization.
Meet your vertical application needs.
We have an application built of multiple Logic Apps. We will use Azure API Management to consolidate all those endpoints into a single endpoint.
We need this application to be highly available, so we want to deploy it to 2 regions (eg West Europe and North Europe).
As of Nov 2018, the only API Management plan that supports multi-region is the Premium plan that costs 18x the Basic plan. The Premium plan is way out of our budget.
We had the idea to setup two Basic API Management units, one for each region, having both configurations synchronized, and placing a Traffic Manager in front of both.
Assuming that we will only use the gateway functionality of API Management (not developer/publisher portal, authentication etc), what will we be missing with our "Poor Man's Multi Region" solution instead of going with the "native" multi-region of the Premium plan?
Whatever you will have to build will be missing (as you pointed out):
Configuration synchronization - you will have to make sure that configuration is synchronized between multiple services.
Traffic Manager - you will have to have TM or something else on top of services to reroute traffic in case of DR.
Scale and everything else from this list: https://azure.microsoft.com/en-us/pricing/details/api-management/
It is possible to create multi region DR of Azure API Management in Developer/ Basic/ Standard tier.
High level steps -
Create two API Management in Standard mode. One in primary region and other in secondary region.
Configure APIs and related backend in API Management primary. As you API Management standard is not part of VNET, the backend APIs will require public IP to get imported in API Management.
Create Azure AD Application to have necessary permission to make changes in API Management instances in cross region.
Allow rights on resource groups of both API Management in two regions.
Create two logic apps. One to create backup of primary API Management. Second will be used to restore the same backup in secondary region API Management.
Create traffic manager and add API Management IP address/ domains names as endpoint profiles. Configure Traffic manager in Failover/ Priority mode.
Configure status page of API Management in Traffic manager to know health status of API Management for traffic manager so that it can switch to secondary region in case of DR situation.
I'm struggling at understanding if and what needs to be done to provide for high availability of two different types of Azure resources:
Azure Service Bus
Function Apps
Service Bus guarantee at least 99.9% of the time for most of the service (includes Relay, Queues and Topics, Notification Hubs). Besides, replication and partitioning messaging entities (Each partitioned queue or topic consists of multiple fragments. Each fragment is stored in a different messaging store. If the corresponding messaging store is unavailable, Service Bus writes the message to a different fragment, if possible.) could be used as common solution for high availability.
The following article would be helpful, please read it.
High Availability and Disaster Recovery for Azure Service
Bus
For Function Apps running on App Service Plans Microsoft guarantee that the associated Functions compute will be available 99.95% of the time. So if possible, you could run your Function App on an App Service Plan and enable the Always On setting.
I'm currently building a hybrid-cloud solution that needs to write messages to a queue for later processing. It is absolutely imperative that the queue is highly available (99.999+% uptime).
My options are to read/write messages to a local ZeroMQ high availability pair, or an Azure Service Bus. I would prefer to go the Azure Service Bus route, but can't find any documentation regarding high availability configuration for Azure Service Bus.
Has anyone had success setting up Azure Service Bus for high availability? I understand that the SLA for a single instance of any Azure service cannot be changed. I'm thinking more along the lines of the failover capabilities of Azure Web Apps.
The main thing you can do for consuming a service at a higher than SLA value is to ensure you are handling retry logic. The key here will be the temporal nature of any outage, and tuning a retry backoff to handle edge cases. Some use linear or exponential backoffs to wait even longer for the service to come back up.
Also, you can have more than one service bus in a different region for georedundancy, and either load balancing messages across the two or use one as a hot backup. This can get you around any regional outages and keep your service up when one data center is not meeting its local SLA.
You can find the for SLA for Azure Service Bus here: legal/sla/service-bus/v1_0/
For Service Bus Relays, we guarantee that at least 99.9% of the time,
properly configured applications will be able to establish a
connection to a deployed Relay. For Service Bus Queues and Topics, we
guarantee that at least 99.9% of the time, properly configured
applications will be able to send or receive messages or perform other
operations on a deployed Queue or Topic. For Service Bus Basic and
Standard Notification Hub tiers, we guarantee that at least 99.9% of
the time, properly configured applications will be able to send
notifications or perform registration management operations with
respect to a Notification Hub. For Event Hubs Basic and Standard
tiers, we guarantee that at least 99.9% of the time, properly
configured applications will be able to send or receive messages or
perform other operations on the Event Hub.
We've had Service Bus Relay up and running for 5+ years and have had one outage. It was an outage at the specific data center the relay was provisioned in and touched many services. After that we implemented redundancy by implementing a secondary Service Bus Relay namespace in a different data center location. The reconfigured code was set to check the connectivity on every connection and switch the primary and secondary connections. We treated them as equals so once we "failed over" that namespace would become primary.
Service Bus now supports Geo-disaster recovery and Geo-replication at the namespace level.
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-geo-dr