Deploy the SolarWinds Platform in a multi-tenant way
This topic applies to all SolarWinds Platform products.
You can deploy the SolarWinds Platform (SolarWinds Platform) as a single instance that runs on a server and serves multiple client organizations (clients). This type of deployment is designed to virtually partition the data and configuration, so that each client organization works with a customized virtual application instance.
Why go multi-tenant?
- One-platform serving multiple customers means cost savings
Easier release management - upgrade, database backups, or high availability need to be done only once.
Before you begin
- Configure what the user sees: You need to configure the SolarWinds Platform so that a customer can safely log in to the SolarWinds Platform Web Console and get a view limited to their IT resources, even though they are supported by a multi-tenant platform with other customers.
- Consider how you want to deploy the monitoring system - deploy it centrally and use additional polling engines for polling individual customers, or deploy an instance of the SolarWinds Platform to each customer and view all data in the Enterprise Operations Console?
Configure what users see
-
Set up account limitations: Specify nodes that a user will be able to see. You can use custom properties or patterns to define the group of nodes that should be visible for a specific user.
-
Set up view limitations: Configure views for specific user groups and limit the nodes that the views display.
What's the difference between view and account limitations?
Let's take a look at limitations using an example. Imagine you have two customers - US customer and EU customer.
View limitations
US Customer | EU Customer |
---|---|
You create US_user for the US customer. | You create EU_user for the EU customer. |
You create a US_view and assign it to the user. | You create a EU_view and assign it to the user. |
You limit US_view to Chicago_router and Austin_router. |
You limit EU_view to Frankfurt_router and London_router. |
In this case, if the US_user figures out the URL for the EU_View (for example because of logical naming conventions), then the user can also see information for Frankfurt_router and London_router. To prevent this, use account limitations.
Account limitations
US Customer | EU Customer |
---|---|
You create US_user for the US customer. | You create EU_user for the EU customer. |
You create a US_view and assign it to the user. | You create a EU_view and assign it to the user. |
You limit US_user to only access Chicago_router and Austin_router. |
You limit EU_user to only access Frankfurt_router and London_router. |
Using Account Limitations, the US_users will not see any nodes on the EU_view, even if they figured out the view URL.
Different SolarWinds Platform products may process the limitations in a different way. To learn more, see the Administrator Guide for your products.
Set up multi-tenant deployment
Consider the following options of dealing with duplicated IP addresses:
NAT-based deployment
Deploy a Network Address Translator (NAT) to translate customer domain addresses so that they are all unique from the SolarWinds Platform perspective.
This makes the identification of managed devices more complex because the translated IP’s don’t necessarily make sense in report readers. To address this, consider creating custom properties with IPs or node names and displaying these instead of the translated IPs. Custom properties are not affected by any translation.
EOC deployment
You can deploy a full instance of SolarWinds Platform products for each customer and get information about all of them consolidated in the Enterprise Operations Console.
EOC deployment using SolarWinds Observability Self-Hosted
You can deploy a full instance of SolarWinds Observability Self-Hosted for each customer and get information about all of them consolidated in Enterprise Operations Console.
EOC 2020.2.x and later can handle a mix of SolarWinds Observability Self-Hosted installations and module-based installations.
Using SolarWinds Observability Self-Hosted instead of modules has the added benefit of flexible licensing, which allows you to purchase a single license and activate a part of it on each SolarWinds Observability Self-Hosted server as needed, giving you great flexibility in your multi-tenant deployment. See Flexible licensing for SolarWinds Observability Self-Hosted.