...
Product Architecture
Opmantek's solution solutions are a 3-tier application applications comprised of a (shared) backend database, an application layer, and the presentation layer. While these can be decoupled and hosted on separate platforms, it is generally not necessary. In some rare situations, clients may benefit from hosting the Mongo DB on a separate server from the other applications.
...
- High lag times for remote locations
- Support for remote locations/offices or for customers (i.e. deployment for a Managed Service Provider)
- Desire to manage control of devices in a very granular way
- Provide a Client Portal (requires NMIS, opCharts, and opHA)
Document Architecture Decision
Now that you've selected your system architecture you should spend a moment to document your decision. You should include all relevant factors considered in making your decision, which subnets will be covered by each server, a generalized list of devices by manufacturer and model each server will handlemonitor, and any network or device configurations required (i.e. SNMP/WMI credentials, network security changes, etc).
Server Sizing
Server sizing is more of both an art than and a science. However, there is a good bit of math to throw in there when determining minimum storage requirements.
...
- Not recommended for mission-critical production deployments over 1.5K devices, or 15k interfaces elements per server.
- Minimum 8vCPU and 16GB-RAM
Storage Requirements
The biggest limiting factor in server performance is disk IO. The system must be able to have unrestricted read/write access to the storage medium. Opmantek highly recommends the use of local SSD storage over traditional hard drives.
NMIS
- The key issue in calculating the amount of storage required by NMIS is understanding how many, and what type, of elements are being collected, and how often (polling policy).
- An individual interface with default data retention might only consume 2.8MB for background information and 11.5MB for pkts_hc. However, adding BGP could add 5.8MB per peer, and CBQoS another 5.8MB PER CLASS.
- Here is a handy reference: Estimating NMIS Storage Requirements
Open-AudIT
- Even very large deployments of Open-AudIT require relatively little storage. 40GB is usually enough with default settings.
- However, if you are storing detailed change information across all tables this should be doubled.
opCharts, opReports, opEvents, opConfig, and opTrend
- Storage requirements cannot be estimated for these products, as usage dictates storage used.
- Storage for these products is managed by the Mongo DB, which applies a considerable amount of compression via the Wired Tiger storage engine.
- The best plan for moving forward is to allocate a minimum space, say 100GB, and then monitor the production of artifacts (dashboards, reports, stored configurations, etc) and adjust retention periods or increase storage as needed.
opHA
- Storage for opHA is relatively negligible and can be included under the estimation for NMIS.
opFlow/opFlowSP
- Storage for opFlow/opFlowSP can be capped to a maximum size; either a defined size or % of available space.
- This approach will affect the period of data being stored, as fixed storage space will truncate time as more flows are processed and stored.
- Under no circumstances should the opFlow/Sp database be left uncapped, as once the /data partition fills the mongod service will crash bringing down all Opmantek modules.
Opmantek Virtual Machine
- If you have deployed the Opmantek Virtual Machine (VM) you will notice separate partitions are used for the OS and applications, and application data (/data).
- This makes it incredibly easy to manage storage requirements, as you can simply adjust the size of the /data partition to increase storage as requirements change.
- Steps to resize the VM's /data partition can be found HERE: Resizing the Opmantek Virtual Machine (VM)
Polling Server vs Master Server
- Generally speaking, simply determine which applications are running on each server, then apply the estimates from above for each.
- The only caveat is with NMIS on a Master server, since NMIS is only processing and storing a relatively small amount of time-related performance data you do NOT need to apply the NMIS calculations. Simply allocate 40GB for NMIS and then add in storage for any other applications on the Master server.
Configuration
Common files and directory structures
NMIS
- /usr/local/nmis8/conf
- /usr/local/nmis8/Config.nmis
Open-AudIT, all OMK Modules
- /usr/local/omk/conf
- /usr/local/omk/opCommon.nmis
Thoughts
- Who will select the initial configurations for each product
- Who will manage/maintain product configurations
- How will product configurations be maintained across multiple servers
Next Up
Implement - Execute your plan, test, and validate the deployment.
...