This section covers the following topics:
- Distribution of Components
- Management Network
Distribution of Components
During the deployment of a DCMTI you must decide how to distribute the previously described components. Most often this becomes a discussion about control and ownership, which is beyond the scope of this document. However, there are three natural separation points.
Between the agents and the server. This separation point should be considered when there are few servers to be managed and the network between the management servers and the agents is robust and not very expensive. Most often this can be done in a campus environment with a high-speed backbone.
Between the management servers and the framework server. This approach is practical when certain expertise or management capability is only necessary at a local level.
Between the framework server and the process server. This approach is preferred when a high level of autonomy is required. This requirement typically happens when sites are geographically dispersed. An additional central framework server might be considered to create a world view of the IT environment.
Another way to redistribute the components in the DCMTI is by collapsing components. This can be done by combining more than one management server into one physical computer system or by including the process management tool in the framework server.
The main considerations in this case are performance and manageability. The latter becomes more critical as one computer becomes a lot more complex due to the need to combine two different servers that typically assume sole control over their resources. However, in smaller deployments the cost of hardware sometimes outweighs the challenges of complexity.
Building a separate management network (also referred to as an out-of-band network) to support the aforementioned management infrastructure is recommended highly. The following sections describe the main reasons for this recommendation.
Depending on the implementation, the management network traffic can be significant. Without a separate management network, all traffic from the management servers and clients, and from production activities compete for network bandwidth. This situation can create a problem. When there is a busy network connection, the management traffic cannot reach the management servers and alerts can not reach the process management server.
An extended version of the preceding scenario is that the network may fail, in which case there is no route to the management server and the failed network alert might not reach the management servers. Even when redundant networks are in place, you must still consider the possibility that a severe outage results in management information loss.
Although good progress has been made in Simple Network Management Protocol (SNMP) v2 and v3, SNMP v1 is inherently insecure. By having it share the same network as the production systems, these systems can be more vulnerable to security violations. You can achieve higher levels of security by separating the traffic.