Distributed Deployment For optimal performance of GMS, it is recommended to use distributed deployment of GMS in production environment. The specifics of the distributed deployment architecture typically depend on the following: • The amount of syslogs entering the GMS system. • The types of Scheduled Reports (Daily vs. Weekly/Monthly). In the GMS architecture, reports are created by querying in real-time the reporting databases that run on each Agent managing the appliances. Creating reports for longer time-periods (such as Monthly) requires that higher RAM and disk space be available to the reporting databases. With less RAM and disk space, monthly reports can be created, but the report generation takes longer periods. If RAM and disk-space cannot be increased on an Agent, reducing the amount of syslogs coming into that Agent helps improve report generation performance. This is achieved either by disabling some syslogs from being sent by appliances, or by adding more Agents to distribute the load further. Another way to increase the RAM available for reporting database is by having dedicated Agents for managing appliances, and not having Console or AIOP role systems to manage any appliance. Virtual Appliances and UMAs run 32-bit operating systems, which limits the amount of RAM that reporting databases have access to in these environments. These platforms are perfect for handing 15 to 20 million syslogs per day, and for daily reports. For deployments where Weekly or Monthly reports are required, 64-bit operating systems (Windows), with a minimum of 8GB RAM (preferably 16GB RAM) are needed for faster performance of scheduled reports delivery. A key factor affecting reporting performance is the disk I/O characteristics. The Syslog collection, uploading syslogs to the reporting database, and querying of the reporting database for creating reports, are very disk intensive. Continued disk I/O bottlenecks impact reporting performance. In Windows, “perfmon” can be used to monitor your disk I/O, specifically the counters “% Disk Time” and “Current Disk Queue Length.” The average value of the counter “% Disk Time” should be as low as possible (but not zero). An average value of 90 percent or more indicates that the hard disk cannot keep up with the demand. This could be because of a hard disk that is too slow, or it could be caused by excessive paging (that might require you to increase RAM). The “Current Disk Queue Length” counter tells you how many I/O operations are waiting for the hard disk to become available. Again, this number should be as low as possible. There are differing opinions of what is an acceptable value, but in general the average disk queue length should be very low, such as three or less. The default installation of GMS installs all modules on a single drive. Separating out hard-disks for different operations further improves performance. This separation can be done in the following two areas: • Syslog Collection: By default, syslogs are collected in the “<GMSVP>\syslogs” folder. The Syslog Collector service writes the syslogs in real time in this folder. The faster the disk, the better the performance of writing syslogs to this folder. These syslogs are then read by the Summarizer service to be parsed, enhanced, and then uploaded to the reporting database. To change the syslogs collection folder, change the following sgmsConfig.xml entry:<Parameter name="syslogFilePath" value="C:\GMSVP\syslogs"/> • Reporting Database Cache: On Windows this database cache resides in the “<GMSVP>\Infobright\cache” folder. This is a temp working folder used by the reporting database to build the query data. Because the reporting database is installed by default in the same drive as GMS is installed, it is recommended to use a different hard disk for the cache folder. This can be achieved by creating a folder such as “G:\cache” and using that folder path in the file “<GMSVP>\infobright\data\brighthouse.ini” as follows:CacheFolder=G:\cache It is recommended that this drive has at least 20GB space available. Finally, consider including only a subset of report types for Monthly Scheduled reports. For instance, under “Data Usage” the sub-report “Details” is a consolidation of all other sub-reports (Timeline, Initiators, Responders and Services). So, in your monthly reports, either add the “Details” report, or the Timeline, Initiators, Responders, and Services, but do not add both. For most GMS deployments the previously mentioned fine-tuning is not necessary. However, for deployments that see suboptimal performance of monthly reports, the previous fine-tuning steps are important. The bullets below are a recap of the fine-tuning options detailed in this section: • Check disk I/O performance and consider using a high speed HDD. • Check RAM requirements, monitor its paging and consider adding RAM. • Consider separating out drives where syslogs are stored and reporting database cache resides. • Consider distributing the deployment further by adding more agents. • Consider setting up only agents for managing units and not using consoles or AIOP system managed units at all. • Consider filtering out syslogs at the source (Firewalls) by disabling syslogs not needed, or filtering syslogs at the GMS by adding syslog filters (that allow you to collect the syslogs on the file system for auditing, but do not get uploaded to the reporting database). • Consider not adding duplicate reports to the monthly reports.