<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 March 2017 at 22:12, Gordon Sim <span dir="ltr"><<a href="mailto:gsim@redhat.com" target="_blank">gsim@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23/03/17 13:34, Ulf Lilleengen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Resending this as 3 of us were not subscribed to the list.<br>
<br>
After our discussion yesterday, I've tried to collect my thoughts on<br>
multitenancy. In our past discussions there have been sort of 2 views on<br>
multitenancy: one where multitenancy is handled within the dispatch<br>
router, and one with multiple isolated router networks. As Rob mentioned<br>
(and I agree) we should think of supporting both.<br>
<br>
I don't think took into account supporting isolated and non-isolated<br>
tenants when we discussed this earlier. And I'm not sure if we should<br>
think of it as just 1 role or 2 roles externally:<br>
<br>
* Client - connects to the messaging endpoint<br>
* Tenant - Manages one address space<br>
(* Instance - Have 1 or more tenants)<br>
* Messaging operator - Manages EnMasse instances and tenants<br>
* OpenShift operator - Manages OpenShift<br>
<br>
Instances are isolated into separate OpenShift namespaces, while a<br>
tenant may share the same instance (routers and possibly brokers) with<br>
other tenants.<br>
<br>
Does it make sense to think of it this way? With this definition we have<br>
support for multiple instances today, but not multiple tenants within<br>
the same instance.<br>
</blockquote>
<br></blockquote><div><br></div><div>I'm fine with the above terms, though I'd prefer to find an alternative name for "Tenant"... The Tenant "role" in your definition is, I think, the Address Space Manager.  I'm not sure what role would be specifically tied to an instance - that seems to be covered by the Messaging Operator... I guess one question is who (Address Space Manager or Messaging Operator) has the ability to scale-up/scale-down aspects of the service.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have also been trying to collect my thoughts, specifically on the motivation for density and how best to address it. (The following is a bit of a ramble)<br>
<br>
The desire for greater density is a desire for more efficient utilisation of resources: cpu, memory, file handles and disk space.<br>
<br>
My assumption is that virtualisation provides efficient *cpu* utilisation without requiring shared processes.<br>
<br>
The way the broker journal works, I doubt there is any gain in the efficient use of *disk space* from sharing a broker between tenants as opposed to having each tenant use their own broker.<br>
<br>
I'm also assuming the bulk of the file handles used will be from by the applications own connections into the messaging service, so there would be no significant gain in efficiency in file handle utilisation from sharing infrastructure between tenants either.<br>
<br>
So I think the issue of density boils down to memory use.<br>
<br>
The argument for sharing a broker (or router) between tenants being that there is some minimum memory overhead for a broker (or router) process, independent of how much work it is actually doing, and that this overhead is significant.<br>
<br>
Clearly there *is* some overhead, but perhaps then it would be worth experimenting a little to see if we can determine what it is, whether it can be reduced or tuned down in any way, and how it compares to the amount of memory consumed by different workloads.<br>
<br>
Focusing just on the core messaging components to begin with, the minimal install of the current architecture would be a single router and single broker (since a broker can now host multiple queues).<br>
<br>
For a single broker, the router only adds any value if the application(s) require the direct semantics that it offers and is only needed if those semantics are required over a connection that also accesses brokered addresses.<br>
<br></blockquote><div><br></div><div>For consistency / simplicity of deployment we might also want also want to have the router consistently provide the interface to authentication/authorisation services... however I would hope that the router would be "lightweight" with regards to memory (and cpu and disk) compared to a broker.  Personally if we want to try to reduce the footprint of each address I would look at whether we can decompose the "broker" part in such a way as if all we need is a "queue" then a queue is all that is being provided.  Of course whether Java is the best platform to provide memory efficient services is an entirely different question :-).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If an application/tenant needs more than a single broker/router, it would seem to me that there would be little benefit from trying to share with other tenants.<br>
<br></blockquote><div><br></div><div>Overall the above is very similar to my current thinking.  Where a shared router infrastructure might provide more value (and this is just some very hazy thinking on my part) is potentially things like cross cluster/datacenter links - pure infrastructure which is not specific to a given "application".  The only other "plus" for shared router infrastructure is potentially some sort of reduction on the number of entities that need to be "managed"/"monitored"... however I think tying a router to a particular application rather than having all routers shared across many applications is actually probably easier from a management perspective.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the most compelling use case for shared infrastructure is where there are a lot of very small applications that could share a broker. Perhaps this use case would be better catered for by Rob (Godfrey)'s 'virtual broker' concept? I.e. maybe we have quite different underlying infrastructure for different service+plan combinations?<br>
<br></blockquote><div><br></div><div>Agreed - as I was saying last week, I think we need to go through each of the axes of scaling we want to cater for and define how we are going to achieve that.  The pattern for very dense, low usage queues is very different from a massively distributed high throughput queue.</div><div> </div><div>-- Rob</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
______________________________<wbr>_________________<br>
enmasse mailing list<br>
<a href="mailto:enmasse@redhat.com" target="_blank">enmasse@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/enmasse" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/enmasse</a><br>
</blockquote></div><br></div></div>