GMS

Best Practices for GMS Operations

Best Practices for GMS Operations

This document contains information about how to maximize GMS performance, ensure orderly upgrades, maintain up-todate backups, and provide optimal use of the network, CPU, and hard disk resources of the GMS deployment.

Database Best Practices

The following practices can help you maintain a reliable database with optimal performance: Recovery model: By default, GMS creates the SGMSDB database with a Simple Recovery model. SonicWALL highly recommends this model for GMS deployments. A Full Recovery model imposes additional maintenance requirements on the database administrator. Backups: You should back up the SGMSDB GMS database on a regular basis. If a Full Recovery model is in use, the database administrator must take frequent backups of the database and transaction logs to avoid filling up the database disk space and impairing GMS functionality. The larger the GMS deployment (in terms of reporting data), the more frequently the backups must be done. SonicWALL recommends the Simple Recovery model because it imposes fewer maintenance requirements on the administrator, and needs less disk space. In a Simple Recovery model database, the SGMSDB database should still be backed up on a regular basis. In the event of a database crash, the most recent database snapshot is used to bring the GMS system up and running. Index maintenance: The performance of GMS greatly depends on the quality of the indexes for the GMS tables. The quality of a GMS table index deteriorates over time as new data is inserted into the table and old data is deleted. The larger the database, the more frequently you should perform index maintenance. SonicWALL recommends a daily index maintenance job. You should schedule the index maintenance job to run after scheduled data purging, such as nightly deletion of old report data. This is specified in the bottom section of the Console>Reports>Summarizer screen. Dedicated database server: For optimal performance, and for minimal interference from other applications, you should install the SGMSDB database on a dedicated database server. This server should have fast connectivity to the GMS servers. The access uptime between GMS servers and the database server should be very high. To minimize access issues due to network outages, the database server should be on the same subnet as the GMS servers.

Configuration Changes
Before making global or group level configuration changes and firmware upgrades, a GMS administrator should apply the change at a unit level, and then test it with a group node that has two to three firewalls. If both tests lead to expected results without causing any side effects or bringing down management access to the remotely managed units, the GMS administrator can push the changes to a larger group or global level node in GMS.

Backup Schedule
To minimize the disruption from hardware or operating system crashes during GMS operation, you should back up your GMS servers and database on a regular basis. SonicWALL recommends a weekly full backup and a daily incremental backup. You can enable the GMS AddUnit.xml & Pref File backup feature to automatically save the AddUnit.xml file and Prefs files during scheduled backups. Configure GMS to preserve the last 10 copies of the Prefs files for the appliances.

Debug Level
Normally, you should run the GMS system in debug level zero. You can configure this in the Console>Diagnostics>Debug Log Settings screen. When Support requests that you provide debug logs, you can change the debug level to a higher number, but be sure to reset it back to zero as soon as you are done collecting the debug data.

Distributed Servers
For best use of resources and to help minimize database bottlenecks, SonicWALL recommends Gen-2 (Distributed) mode for Summarizer. When several Agents are managing multiple appliances, you should distribute the appliances so that CPU, network, and hard disk resources are equitably shared for current management and reporting needs, as well as for future expansion. You can use the Capacity Planning screen to determine if your GMS deployment is evenly distributed. For example, in a deployment with three Agents, if one of the Agents is getting 90% of the syslog packets, you should determine the reason for the imbalance and consider changing the appliance distribution. You can also use the Capacity Planning screen to determine which Agent should manage a new appliance that you are adding to the deployment. You should take monthly snapshots of the Capacity Planning screen to see how your GMS deployment and remotely managed networks are evolving over time and to identify any spikes in various data that is captured in this screen.

Standby Servers
To minimize downtime to GMS operations, you should have cold standby servers ready to replace GMS servers in case of hardware or operating system failures.

Firewall Data Volume Best Practices

The following practices will help ensure optimal use of the network, CPU, and hard disk resources of the GMS deployment for mission critical business needs: Turn off unneeded syslogs at the source: If you do not need reporting or forensics on an appliance, you can turn off syslogs at the source to help conserve bandwidth, CPU, and hard disk usage. You can select the checkbox for Send Heartbeat Status Messages Only in the Policies>System>Management screen. Granular syslog control: When reporting on appliances running SonicOS Enhanced, you can turn off syslog categories that you do not need. Use syslog throttling: To minimize the possibility that a syslog storm will disrupt your networks, you can use the syslog throttling feature on all your appliances. Syslog storms can occur when a malicious application is running on a remote network. Granular summarization control: You can turn on summarization for only those appliances for which you need reporting. You can also perform selective reporting on those appliances. For example, if you do not need VPN Reports for an appliance, then you can use the Reports>Configuration>Summarizer Settings screen to turn them off. Scheduled reports: You can create scheduled email reports for a specific set of reports and appliances. Consider using password protected zipped attachments to minimize email payloads and to improve security. Fine tune raw and summarized data archiving: You can use the minimum number of days for storage of raw syslog data as well as summarized data. The minimum number of days required is specific to the business needs of your GMS deployment. Use filter options: When using scheduled reports for email or archiving, use the minimum number of Top Sites, Top Users, etc, that is acceptable for your business needs. SonicWALL recommends full reports on a weekly basis, and incremental reports daily.

SonicWALL November, 2006