SQL Sentry Multi-Tenant Configuration - Setting the Stage

owenmurf over 2 years ago 3 minute read time

In my previous life, while working as a sales engineer for the Orion^® Platform, I constantly referenced a blog post written many years ago about how multi-tenant deployments would work. Having the ability to set up your monitoring tool to enable polling for multiple clients is essential for managed service providers (MSPs). So, let’s look at how SolarWinds^® SQL Sentry^® can be deployed in a multi-tenant way. Here we’ll be using multiple monitoring services and sites to achieve this.

SQL Sentry provides best-in-class tools for monitoring the Microsoft data platform. Additionally, SQL Sentry offers multiple features designed to be configured to provide the required segregation between customers while enabling per-tenant customization without increasing the complexity of the monitoring environment. This blog post is part one of a two-part series.

The SQL Sentry monitoring tool installs the following components:

SQL Sentry monitoring service. SQL Sentry provides agentless monitoring of SQL Server instances, using one or more SQL Sentry monitoring services. These monitoring services are Windows services responsible for collecting event and performance data and sending notifications for target SQL Server instances. Additionally, a monitoring service collects SQL Server and Windows performance data (Windows Management Instrumentation—WMI).
SQL Sentry repository database. The monitoring service writes the collected information to the SQL Sentry repository, a database hosted on a SQL Server instance.
SQL Sentry client. The SQL Sentry client connects to the SQL Sentry repository database allowing users to view real-time and historical information about the monitored targets and instances.

What Are Sites?

Sites are a logical grouping of targets (a single server containing one or more monitored instances), database instances, SMTP servers, and monitoring services within your SQL Sentry environment. Each SQL Sentry environment has at least one site configured by default; you can see it represented within the navigator pane as the default site. Computers and connections you add to your environment to monitor automatically become part of this default site. Customer-specific monitoring and alerting can be defined at the site level as well. To configure SQL Sentry for multi-tenancy, we will be setting up multiple sites. In the diagram below, we see how SQL Sentry is configured for single-site architecture.

Should I Configure Multiple Sites Within My Environment?

While not every SQL Sentry environment will need multiple sites, they offer several advantages when your organization manages geographically sparse assets or assets in multiple domains. Sites allow you to monitor these assets when no trust exists between domains.

Multi-Site Configuration

The best approach for monitoring multiple customers in SQL Sentry is configuring each customer in their own site. Each customer is represented by one site and has one or more monitoring services in each location. All customer monitoring services write to a single SQL Sentry repository database. Each monitoring service will allow you to monitor between 40-100 targets.

This configuration provides the required separation between customers and enables custom monitoring and alerting policies for each customer (overriding or running in tandem with globally defined policies). By installing monitoring services on tenants’ local networks, the MSP eliminates the security issues raised by trying to monitor SQL Server and WMI across authentication domains.

In the following diagram, the SQL Sentry database is installed in a central location and will be used by each tenant site. For more information on installing SQL Sentry see the installation guide. It’s recommended you create a public DNS A Record for this server for ease of configuration in client sites.

In part two of this blog post, we’ll dive into sample configurations of SQL Sentry to configure it for managed service providers (MSPs)—think SMTP config, alerting options, tenant security, etc.