Organizations that use multiple Intermapper servers can collect device statistics, interface statistics, and event log records into a central Intermapper Database server. Each Intermapper server at a remote site or region can be configured to connect to a central Intermapper Database server, rather use its own local server. This allows for trend analysis and reporting across all Intermapper servers, across the entire enterprise network. Intermapper Reports can then extract data from the central database, and create composite reports involving datasets collected from all Intermapper servers.
This design is resilient. If an Intermapper server at a remote site loses its connection to the central Intermapper Database server, it saves the data locally until the connection is re-established, at which point data collection resumes. No data is lost.
The volume of data transmitted from the Intermapper servers at the remote sites across the WAN to the central Intermapper Database server is proportional to the number of devices and interfaces for which data is being collected and server's polling rate. The data is compressed before it is sent. For most modern high-speed WAN networks the volume of data sent is low enough not to be an issue.
However, there are two scaling considerations to be aware of when using a central Intermapper Database server design.
Use Retention Policies to Limit Database Size
The first scaling consideration is that the performance of the Intermapper Reports engine is inversely proportional to the size of the database. To mitigate, when setting up a central Intermapper Database it is important to design retention policies that keep the database manageable in size. Retention policies take raw data points received from the Intermapper servers, average them over 5-minute, hourly, and daily time intervals, and store the averaged samples in the database to reduce the amount of data stored. A good rule of thumb is to keep the raw data points for just one or two days, 5-minute averaged samples for 1-3 months, hourly averaged samples for 6-12 months, and daily averaged samples forever.
If you want to look at historical charts of raw data points use the excellent Intermapper charts. Intermapper charts are designed to look at raw data points. Intermapper Reports is good for looking at averaged samples.
Use Retention Policies to Limit the Number of Datasets
The second scaling consideration is that there is a performance constraint in Intermapper Database that limits the number of datasets that can be processed per minute. To mitigate, it is important to apply retention policies wisely to interfaces. With Intermapper you can have per server, per map, and per device default retention policies. Use the Dataset View to view and apply retention policies to interfaces. When setting up a central Intermapper Database server for your organization, take the time to understand exactly how retention policies and datasets work, and to design appropriate retention policies with a mind to keeping the number of datasets that the Intermapper Database server has to process to a manageable number.
To summarize, yes, you can have centralized trend analysis and reporting if you have multiple Intermapper servers. This will work fine for many organizations without any scaling issues. If you have a very large network, then you need to be aware of the scaling considerations, and design and apply your retention policies accordingly. The best approach is to start with tight retention policies, monitor the performance of the server, and loosen up your retention polices over time.
Communication between the Intermapper servers at the remote sites and the central Intermapper Database server is protected using SSL encryption, and by default uses port 8183.
