Patch Manager Architecture – Deploying Application & Management Role Servers
This is part two of a two part article discussing scenarios for implementing additional Patch Manager servers. In part one of this article I described some of the common scenarios for using additional Patch Manager Automation Role servers that may be beneficial to your environment. In this part I will discuss scenarios for using additional Application Role and Management Role servers.
Again, I would like to emphasize the fact that because Patch Manager is licensed by the number of managed nodes in your organization, there are no additional Patch Manager licensing costs associated with implementing additional Patch Manager servers.
As previously discussed, the Application Role is the component of Patch Manager that interfaces with the console user. The Management Role is the component of Patch Manager that stores inventory data and oversees the delegation of task execution events to the Automation Role servers. . A Management Role server hosts a Management Group, which is defined by one or more of one of the following: a workgroup, an Active Directory domain, a WSUS server.
Why implement additional Application Role servers?
Implementing additional Application Role servers is done to provide redundancy or additional load capacity for console connections, or to create isolated sandboxes in which a console user manages an environment. An Application Role server has its own credentials, user profiles, and security roles.
Why implement additional Management Role servers?
Implementing additional Management Role servers is done to physically segregate the Patch Manager data into multiple data stores. Multiple data stores might be appropriate where segments of an organization have data sensitivity or confidentiality concerns about their managed systems, or where reporting is typically done at a more granular level, perhaps by department or site.
Scenario 1: Using an Application Role server to manage console connections
A scenario where multiple application servers would be appropriate is when managing a large number of Patch Manager console users, or where high-availability requirements exist. In a High Availability (HA) scenario, there would be three Application Role servers implemented:
- The primary server (PAS) is not used for console connections, but only as a control system for the Patch Manager environment. It should be backed up regularly.
- At least two Secondary Application Role servers (SAS) would be implemented. These servers primarily handle console connections and task management. Consoles can be split across the servers for rudimentary load balancing and individual console users would connect to the alternate server if their home server was offline, or the servers can be designated as an active/standby pair, and the consoles would only connect to the standby server if the active server is offline and immediate access is required.
This HA scenario can scale to as many Application Role servers as are required. Theoretically, each console user could have their own dedicated Application Role server installed on their personal systems.
Scenario 2: Using a Management Role server to segregate patch and asset data
One use for an additional Management Role server is to physically segregate the patch data collected from the WSUS server from the asset inventory data collected from the Managed Computer Inventory (WMI) task. This might be done for performance reasons, providing better report generation from smaller databases, or because an organization has a large dataset and does not want to invest in a licensed instance of SQL Server.
For some environments, the 10GB database size limitation of SQL Server 2008 R2 Express Edition may not be sufficient for both WSUS (patch) data and WMI (inventory) data. The primary Patch Manager server can be used to hold the data for the WSUS inventory, and a second Management Role server can be configured with a management group just for managing domain and asset inventory data collected via WMI. This implementation would look something like this:
Because the data is physically segregated, this significantly reduces the size of the database that must be accessed for generating reports. Patch management reports come from the database server containing patch data, and asset management reports come from the database server containing asset inventory data. The smaller datasets will result in faster rendering of reports.
Finally, security controls can also be applied in this scenario, so users who should only have access to patch data, can be physically and logically isolated from the asset inventory data, or vice versa, and users who need access to both can still have full access.
Scenario 3: Using an Application and Management Role server in a testing lab
One scenario in which an additional Application and Management Role server might be implemented is for an installation of Patch Manager in a testing lab. Many organizations test patches before deployment in a lab setting. Configuring an additional Patch Manager server in the lab allows that environment to be completely isolated from the production environment.
In this particular lab scenario, we are able to implement a second Management Role server, as our lab environment operates in a subdomain of the primary domain. We will define a separate Management Group for this subdomain and the WSUS server in our lab, so that we can physically isolate any inventory data we might choose to collect, as well as manage all task execution completely within the lab environment.
This scenario might also apply to a special business unit that has confidentiality considerations, or even to a perimeter network (DMZ), where communication into the primary network is not possible and all management resources must also be on the DMZ.
Deploying additional Application Role servers or Management Role servers can provide enhancements to your Patch Manager infrastructure in the areas of redundancy, load-balancing, data distribution, and improved report performance.
For more information about Patch Manager Automation Role servers, and advanced deployment scenarios, please see the Patch Manager Deployment Guide. For general product information, please visit the Patch Manager page on the SolarWinds website.