I am looking at the diagram at Service Bus For Windows Server : Supported Topologies
My question is, in 2 tier deployment, can i install Service Bus Gateway on Machine1, Service Bus Broker on Machine2 and Windows Fabric on Machine3 or that diagram means i install all these 3 components on same machine and have 3 machines like that and create a farm?
Also i am little confused as what do they mean by "Service Bus Host"? Does it mean a system that has Service Bus Gateway, Service Bus Broker and Windows Fabric (all 3 components) installed on it or just Service Bus Broker?
You must install all 3 components together on one node. You can decide to put the databases on another server but the services get installed together.
Therefore the term service host probably would mean all three.
Related
I have a on-premise service bus installed i want to browse and test in service bus explorer . How can i know the endpoint of my service bus installed locally and details step by step procedure to test on service bus explorer. Like shared secret key all the attribute values in endpoint
The connection string looks something like this
Endpoint=sb://<hostname>/ServiceBusDefaultNamespace;StsEndpoint=https://<hostname>:9355/ServiceBusDefaultNamespace;RuntimePort=5671;ManagementPort=9355;TransportType=Amqp
The ports are the default when configuring and should be changed accordingly if required.
One thing to note is that the newer releases of Service Bus Explorer do not support Service Bus for Windows Server (which itself is out of mainstream support) and you would need to use v2.1 which last supports it.
Since there seems to be no releases available, you will have to fetch and run the code directly.
Currently we have 2 load balanced web servers. We are just starting to expose some functionality over NSB. If I create two "app" servers would I create a cluster between all 4 servers? Or should I create 2 clusters?
i.e.
Cluster1: Web Server A, App Server A
Cluster2: Web Server B, App Server B
Seems like if it is one cluster, how do I keep a published message from being handled by the same logical subscriber more than once if that subscriber is deployed to both app server A and B?
Is the only reason I would put RabbitMQ on the web servers for message durability (assuming I didn't have any of the app services running on the web server as well)? In that case my assumption is that I am then using the cluster mirroring to get the message to the app server. Is this correct?
Endpoints vs Servers
NServiceBus uses the concept of endpoints. An endpoint is related to a queue on which it receives messages. If this endpoint is scaled out for either high availability or performance then you still have one queue (with RabbitMQ). So if you would have an instance running on server A and B they both (with RabbitMQ) get their messages from the same queue.
I wouldn't think in app servers but think in endpoints and their non functional requirements in regards to deployment, availability and performance.
Availability vs Performance vs Deployment
It is not required to host all endpoints on server A and B. You can also run service X and Y on server A and services U and V on server B. You then scale out for performance but not for availability but availability is already less of an issue because of the async nature of messaging. This can make deployment easier.
Pubsub vs Request Response
If the same logical endpoint has multiple instances deployed then it should not matter which instance processes an event. If it is then it probably isn't pub sub but async request / response. This is handled by NServiceBus by creating a queue for each instance (with RabbitMQ) on where the response can be received if that response requires affinity to requesting instance.
Topology
You have:
Load balanced web farm cluster
Load balanced RabbitMQ cluster
NServiceBus Endpoints
High available multiple instances on different machines
Spreading endpoints on various machines ( could even be a machine per endpoint)
A combination of both
Infrastructure
You could choose to run the RabbitMQ cluster on the same infrastructure as your web farm or do it separate. It depends on your requirements and available resources. If the web farm and rabbit cluster are separate then you can more easily scale out independently.
I have been going through the NServiceBus samples, one point which is not clear to me is the cardinality of NserviceBus Host to Endpoint. Is the relationship 1 NServiceBusHost to 1 Endpoint? What does this look like in production? 1 Windows Service per 1 Endpoint?
Thanks In Advance
We have 3 main actors the NServiceBus.Host that is the physical host that allows an Endpoint, more to come, to be hosted as a Windows Service on a Windows machine. So there is a 1:1 relation between a NServiceBus.Host and a Windows Service.
One host can, starting with V5, host multiple endpoints instances (we can have more than one bus per service listening to different Qs) where an endpoint instance is the physical deployment of an endpoint that is a logical definition that owns a set of message types.
So in production we can 1 service, that monitors 1 queue that hosts 1 endpoint. But you can also have multiple endpoints in the same service even if by default the on-premises NSB.host does not support that out-of-the-box. On the other hand we support it out-of-the-box on Azure where we have a dynamic host that allows more than 1 instance per host while keeping the instances isolated in different processes.
cross answered: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/particularsoftware/7zOHHOOqDi4/I4p2TbvFGc0J
My management is evaluating non-Azure Microsoft Windows Service Bus (Azure is out of consideration for security reasons). It will be used to setup topic/subscription model with a number of WCF services with netMessagingBinding that we building, so I just have a few basic questions about that.
Are there any specific hardware requirements like dedicated server, dedicated database etc. for WSB to run in production environment?
It's easy to configure WCF service to listen on a specific topic subscription. Is there any way for WCF service to listen to multiple subscriptions?
Appreciate the answers.
You can install the service components and the databases all on one server (that is the default). However, for a number of reasons, we installed the services on a dedicated app server and then created the Service bus databases on an existing database server. The install package allows you to specify a different db server. Check this article for the minimum server requirements
Yes you can get one WCF service to listen to multiple subscriptions. You would need to create two (or more) System.ServiceModel.ServiceHost instances and then run them inside one process. For example we had one windows service running two ServiceHost's. Each host listened at a different queue and therefore implemented a different contract. This meant where queues were logically grouped we didn't need a new windows service per queue. You could do the same with subscriptions.
For question one, you will have to go through the exercise of hardware sizing. the good news is that WCF services can scale vertically, so you can add up servers if there were issues in handling client load.
To do hardware sizing you will have to make an estimate the expected load and then do performance/scalablity testing to figure the load bearing capacity of your serviceBus/services .
you could find a lot of resources for load testing like this one http://seroter.wordpress.com/2011/10/27/testing-out-the-new-appfabric-service-bus-relay-load-balancing/
once you do load testing and come up with the numbers, you can then do sizing using references like this one http://msdn.microsoft.com/en-us/library/bb310550.aspx
We are implementing a service/message-bus feature in our SignalR application and have been looking at Redis, with automatic fail-over using Redis Sentiel. We would like to maintain our own servers and have read SignalR powered by Service Bus. Since this is a Winddows Azure implementation, how can I accomplish this in our internal network with VM's with automatic fail-over similar to the Redis solution discussed above?
You may want to look at Service Bus for Windows Server:
http://msdn.microsoft.com/en-us/library/windowsazure/jj193022(v=azure.10).aspx
It has API symmetry between Azure Service Bus and the Windows Server API (particularly for messaging: queues and topics/similar to SignalR). It doesn't include the caching and ACS services. However, if you want the Azure Service Bus - Caching...you can get that in:
AppFabric for Windows Server
http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx