We're running a multi-tenant website (multiple hosts, different configs for each host, but one application) where every customer on every request could get routed to client-specific data bases and solr instances. So, depending on which url is mapped to the application, different connection strings will be provided for each request. This works well for normal databases where IConnectionProvider would provide a different connection string on each request depending on the hostname. We're using SolrNet for our text indexing and will have multiple instances running for the different hosts. Presently the SolrNet facility for Castle Windsor gets registered once with a solrUrl at configuration time. We want to be able to resolve an instance of SolrNet on every request with a different solrUrl depending on the tenant/host configuration. Is this possible?
Use the multi-core / multi-instance support in the SolrNet Windsor facility, then use a IHandlerSelector to select the appropriate ISolrOperations<T> depending on tenant/host config.
Related
When there are several Apache Flink clusters running and the corresponding Web Frontend is opened in browser tabs, it would be great if these UIs can be distinguished in a visible way. Port number in the browser location bar might be useful.
In our use case, we switch among multiple clusters, connect to only one cluster at a time and use the same port for forwarding. In such case, there is no visible cue to identify the cluster the UI is displaying.
Does anyone know if there are ways to associate some tags that can be displayed in Apache Flink Web Frontend?
Trying to create a Mule project with support for multiple version endpoints. To begin with I have started with two API specification with same endpoints but with different version.
hello-world-v1.raml (version: 1, GET /hello)
hello-world-v2.raml (version: 2, GET /hello)
Then used these both RAML files to create Mule project. By default it created two Listeners on different port. But I want to start app in single server and port but go to flow based version of path e.g.
https://www.custom-greetings.com/api/v1/hello will server based on first RAML specification whereas
https://www.custom-greetings.com/api/v2/hello will server based on second RAML specification
The reason I want to have Mule project with both version is so that my client can use same domain instead of
https://www.custom-greetings-v1.com vs https://www.custom-greetings-v2.com
I am pretty sure there is efficient way to do this but not finding any related example or guidance.
Any help/pointer is appreciated.
Thanks.
If you are deploying to a standalone Mule server you can move the HTTP Listener configuration to a Mule Domain and share it with both applications. That way both listen to the same port but in different URI paths. This method can not be used in CloudHub nor Runtime Fabric deployments because they don't support domains.
Another alternative would be to combine manually both RAMLs into a single one and create a single application with a single HTTP Listener for both APIs. This alternative will be compatible with CloudHub and Runtime Fabric.
Yet another option would be to put a load balancer in front of both applications. For a standalone Mule installation you need to provide your own load balancer. CloudHub provides a feature called Dedicated Load Balancer to do this. Runtime Fabric uses Kubernetes ingress mechanism.
I'm trying to get a proof of concept going for a multi-tenancy containerized ASP.NET MVC application in Service Fabric. The idea is that each customer would get 1+ instances of the application spread across the cluster. One thing I'm having trouble getting mapped out is routing.
Each app would be partitioned similar to this SO answer. The plan so far is to have an external load balancer route each request to the SF Reverse Proxy service.
So for instance:
tenant1.myapp.com would get routed to the reverse proxy at <SF cluster node>:19081/myapp/tenant1 (19081 is the default port for SF Reverse Proxy), tenant2.myapp.com -> <SF Cluster Node>:19081/myapp/tenant2, etc and then the proxy would route it to the correct node:port where an instance of the application is listening.
Since each application has to be mapped to a different port, the plan is for SF to dynamically assign a port on creation of each app. This doesn't seem entirely scaleable since we could theoretically hit a port limit (~65k).
My questions then are, is this a valid/suggested approach? Are there better approaches? Are there things I'm missing/overlooking? I'm new to SF so any help/insight would be appreciated!
I don't think the Ephemeral Port Limit will be an issue for you, is likely that you will consume all server resources (CPU + Memory) even before you consume half of these ports.
To do what you need is possible, but it will require you to create a script or an application that will be responsible to create and manage configuration for the service instances deployed.
I would not use the built-in reverse proxy, it is very limited and for what you want will just add extra configuration with no benefit.
At moment I see traefik as the most suitable solution. Traefik enables you to route specific domains to specific services, and it is exactly what you want.
Because you will use multiple domains, it will require a dynamic configuration that is not provided out of the box, this is why I suggested you to create a separate application to deploy these instances. A very high level steps would be:
You define your service with the traefik default rules as shown here
From your application manager, you deploy a new named service of this service for the new tenant
After the instance is deployed you configure it to listen in a specific domain, setting the rule traefik.frontend.rule=Host:tenant1.myapp.com to the correct tenant name
You might have to add some extra configurations, but this will lead you to the right path.
Regarding the cluster architecture, you could do it in many ways, for starting, I would recommend you keep it simple, one FrontEnd node type containing the traefik services and another BackEnd node type for your services, from there you can decide how to plan the cluster properly, there is already many SO answers on how to define the cluster.
Please see more info on the following links:
https://blog.techfabric.io/using-traefik-reverse-proxy-for-securing-microservices-on-azure-service-fabric/
https://docs.traefik.io/configuration/backends/servicefabric/
Assuming you don't need an instance on every node, you can have up to (nodecount * 65K) services, which would make it scalable again.
Have a look at Azure API management and Traefik, which have some SF integration options. This works a lot nicer than the limited built-in reverse proxy. For example, they offer routing rules.
I am relatively new to this. So I am trying to understand the relationships among zookeeper, solrcloud, and http requests.
My understanding is:
Zookeeper (accessible through 2181) keeps config files for solrcloud.
and all http requests goes to solrcloud instance directly rather than going through zookeeper.
Therefore, zookeeper, in this particular case, is not used for its ability in routing (API) requests? I do not really think that should be the case. But based on the tutorials from solr official sites. It seems all the requests needs to go through solr's 8983 port.
Solr uses Zookeeper to keep its clusterstate (which servers has which cores / shards / parts of the complete collection) as well as configuration files and anything else that should be available all throughout the cluster.
The request itself is made to Solr, and Solr uses information from Zookeeper in the background to route the request internally to the correct location. A client can be Cloud Aware (such as SolrJ) and can query Zookeeper directly by itself and then contact the correct Solr server instantly, instead of having Solr route the request internally. In SolrJ, this is implemented as CloudSolrClient (or CloudSolrServer as it might be named in older versions of SolrJ) (and not the regular SolrServer, which would contact the Solr instance you're referencing and then route the request from there).
If you look at the documentation of CloudSolrClient, you can see that it takes the Zookeeper information as its argument, and not the Solr Server address. SolrJ makes a ZK request to Zookeeper, retrieves the clusterstate, then makes the HTTP request directly to the servers hosting the shard or collection.
I am making a search query on local Apache Solr Server by browser and see the results.
I want to make Same Query on the production server.
Since tomcat port is blocked on production, I cannot test the query results on the browser.
Is there any method to make query and see the results?
Solr is a java web application: if you can't access the port it's listening to, you can't access Solr itself. There's no other way to retrieve data from a remote location. Usually on production Solr is put behind an apache proxy, so that it protects the whole Solr and makes accessible only the needed contexts, in your case solr/select for example to make queries.