we are planning to use SignalR with Windows Azure Service Bus for a cloud application that requires live client updating (browsers). We might have about 200 clients connected to our solution. If we deploy our application over a 4 instances cloud service I know I should use the "GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString, 1);" option to connect them through the service bus.
My question is: Will it use service bus relays? or topics? as many as hubs on each instance? one relay per client (200 clients) connected using SignalR? I just want to know how much they will charge me to know if it is worth it. In fact the most important thing to know here is if SignalR uses Topics/subscriptions or relays?
Thanks a lot for your help,
The SignalR Azure Service Bus scaleout provider will only use one subscription per role instance. If you have 4 cloud service instances, you will actually want:
GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString, 4);
The second parameter is your instance count.
This will put all of your SignalR messages on one topic. If you want to distribute you messages between more topics, you can specify a topicCount as the third parameter to UseWindowsAzureServiceBus like so:
GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString,
instanceCount: 4,
topicCount: 2);
NOTE: The parameters above are only named for clarity.
Related
i want to develop a Game using Azure Cloud but i am not sure which ressources i could use for it. Folowing is my problem:
There is one publisher which is providing some messages. I need to find a way to add subscriber on demand. That means whenever i need more subscriber i need to add them without changing any settings on the portal.
All subscriber needs to get the published message at the same time.
Received message from the publisher needs to be deleted for all subscriber at the same time.
Is there a ressource or a way which fits theese needs?
Thanks.
Azure SignalR Service is WebSocket Gateway service that covers all your requirements.
While you could always host your own server, the service supports scaling out.
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 have implemented a Proof of Concept in Azure Service fabric that uses Azure Service Bus as a message queue. I'm using nServiceBus within the application to send and respond to messages which makes it very easy to change from one queuing technology to another.
I'd like to know if it's possible to use MSMQ instead of Service Bus in Azure Service Fabric as the nodes that are created are just windows 2016 servers and I'm not sure I need something like Service Bus. It's a question I want to answer with my POC.
Does anyone know whether MSMQ is included in an Azure Service Fabric node or how I could turn it on and if it's a viable solution?
Short answer - MSMQ is not suitable for Azure Service Fabric.
MSMQ is store and forward technology. It's using local file system to persist messages and then forward to another machine. When Service Fabric is going to move service from one node to another, it will not move the file system along. Meaning you'll lose messages.
I would recommend to stay with Azure Service Bus unless there's a good reason you're looking for an alternative.
I have a .NET web application that is deployed as a multi-instance Azure Web App. This web application makes use of SignalR to broadcast messages to connected clients. I'm scaling out using a Service Bus backplane, and this works great.
I also have a continuous WebJob that monitors a Service Bus queue, does some intensive processing, and as part of that processing needs to send out a broadcast message to SignalR clients.
It seems that there are two ways I can go with this:
Treat the WebJob as a SignalR client by connecting with my SignalR Hub running on the Web App using a HubConnection and an IHubProxy. This seems to work well, and is what I'm currently doing.
Somehow treat the WebJob as another Hub, and add it to the Service Bus backplane. I am not sure how I'd do this. I would then just broadcast messages using an IHubContext that I get from the SignalR.GlobalHost.ConnectionManager.
My questions are:
Is one way of doing this substantially better than another?
If option #2 is better, can someone post a link to how I'd go about doing this? It seems that most tutorials are in regards to a multi-instance scale-out using either SQL Server, Service Bus Topics, or Redis as the backplane.
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