Multitenant for 1000 ENVIRONMENTS

[luis braum garcia vargas]

Good morning, nice to greet you.
We have the following situation we are working on an offer in which the client expects the solution to provide the ability to configure at least 1,000 organizations or Multitenant groups. Understanding by multitenat the principle of software architecture in which a single instance of the application runs in the solution, but serving multiple clients or organizations independently, with its own authentication and profiles that prevent one organization from interacting with the others . An example of a multitenant grouping is the corporate clients of our client.

Taking into account the large size of this implementation, we want to know if there is any way to optimize this multi-tenant service without the need to put 1000 secondary UIM HUBS, since the documentation recommends a HUB for each client that we are going to manage that can be offered in this case to be used in UIM and Spectrum. Thank you

------------------------------
Senior Consultant
Esoft
Colombia
------------------------------

[Luc Christiaens]

Having a hub for each customer is the easiest way.
If you want to group multiple clients under 1 hub you have 2 possibilities:
-1- each client has it own servers => set origin at robot level and this works fine without any extra scripting
-2- some servers are running applications for multiple clients, and here start the problem
--------------------
With solution 2 you need to use origin_enrichment on alarm and qos level.
Alarm level is not a problem, this can easily be done via a pre-processing lua script
But qos origin_enrichment is done via enrichment.rb script for the qos_processor probe.  This works also fine after some trial and error
BUT: there is a problem in some Operator Console screens where a wrong sql query is used to display a device origin.
So it can happen that you look in Inventory and you see devices with 3,4,5 different origins
At the same time you can see a device appearing in different Groups due to this logic.
I have issues open for this (since more than 2 years) and still waiting..

[Garin Walsh]

A handful of comments:

For the most part, UIM monitoring components are installed on the server being monitored (some exceptions are the network aware probes like sql_response, net_connect, etc.) so the concern about having 1000 secondary hubs is not really applicable. If you are monitoring 1000 servers you are going to have 1000 UIM installations.

The "hub" is just an additional probe that runs on a UIM installation to provide a queueing mechanism and network connectivity. It's got a pretty small footprint. We run 2700 hubs in our customer base.

For the most part the install of UIM is what stamps the data and alerts with their identifier. When data goes through the hub probe, it gets stamped with the customer id that's configured for that hub. Robots (UIM installs that don't have a hub probe) have the availability to also stamp data going through them.

A single physical server can run an arbitrary number of instances of UIM. So if you have a case where you want to monitor sql server for a hundred customer specific servers, you could deploy the sql server probe to those 100 servers or you could have one server and install 100 copies of UIM on it (which would look like 100 different robots in UIM) and then put the 100 instances of the sql server probe on that one server. I do this for testing purposes frequently (much easier to have one physical server mimicking many for load testing purposes for instance)

There is no mechanism to physically separate data in UIM - all data is grouped by the probe it came from and all alarms go into the same table. You have to implement the separation logically - typically by using a value referred to as "origin" and then providing accounts that are configured to see those origins. Problem is that any logical separation of data relies on the developers writing the product to always understand and honor that methodology which is not the case 100% of the time. So if your data is protected (PHI for instance) then your have a significant risk to pay attention to.

Having many customers to keep separate relies on having a solid and predictable way of mechanically identifying the association between data and customer. For instance in our environment all robots include the customer name in them in a predictable location - we use a format of hostname.customername so that you can then operate on "*.customername" for instance. 

UIM was designed originally for an environment where IP address and hostname of a server were guaranteed to be unique. And where you had a significant difference in ratio between number of hubs and number of robots (one hub in a datacenter with all the monitored servers being robots - say 1:100 for instance). In a multi tenant environment, you are almost guaranteed that IPs will be duplicated (how many routers out there are going to have an ip of 192.168.0.1?) and hostnames are managed locally, not globally, so they'll also be duplicated (how many exchange servers get named "exchange" for instance?). And you are are going to have a significantly different ratio of hubs to robots - probably 1:10 or maybe even 1:1 for instance. Because UIM is going to default based on its assumptions you will have to implement processes to make sure that systems get identified appropriately to keep them unique.