Running with Multiple Servers
Overview
To provide a level of redundancy, PSM supports the use of multiple servers to manage a network.
In a multi-server configuration, each server receives traps from, and reports on, the network elements that it has discovered. The set of discovered network elements can be the same or can be different from server to server, depending purely on how you choose to divide your network for management. The servers can be geographically distinct for better disaster recovery or be part of a geographically-based management scheme.
Some BTI Series network elements have limits on the number of PSM servers that can be used to manage them. See PSM Server Requirements for details.
Since the servers operate directly on configuration data stored on the network elements themselves, each server has the latest view, and is able to detect and recover from conflicts (in the unlikely event that two or more servers are changing the same set of attributes on the same network element).
While the PSM server does not store network element configuration data, it does store configuration data associated with the PSM server itself. This PSM configuration data relates to user interface interactions and the presentation of information, and includes the following:
users for the server
the list of network elements to discover and domain/group membership, which relate to what network elements to manage and how they are organized
alarm assignment/acknowledgment and maintenance modes, which relate to management actions that a user can take
customer details and association, which can be optionally defined and associated with services
profiles, which are network-wide to provide consistency across network elements
various options related to the display of data, the locations of tools, and other attributes specific to the server
The PSM server stores this set of information in the local MySQL database, which is set up and initialized during the PSM server installation process, and which persists through PSM server software upgrades.
How this data behaves when you run with multiple servers depends on whether you choose to run these servers independently (without server replication), or loosely coupled (with server replication).
Running Multiple Servers Without Server Replication
When you run multiple servers without server replication, each server is unaware of the other servers, and each has its own set of PSM configuration data.
The PSM configuration data that resides on the PSM server is not replicated nor synchronized with the PSM configuration data on the other servers.
For example, network element groups created on one server are not visible to the other servers, alarm assignment on one server is not visible to the other servers, and so forth.
With this approach, while you still achieve redundancy, you might have to recreate and/or reconcile your PSM configuration data when a server goes down.
Running Multiple Servers with Server Replication
When you run multiple servers with server replication, some of the PSM configuration data is synchronized among all servers within the same server replication cluster. This data subset is called the replicated data.
Updates to the replicated data on one server are automatically conveyed to all other servers in the same cluster. For example, a network element group created on one server automatically appears on the other servers, an alarm assignment on one server automatically appears on the other servers, and so forth. In this way, when a server goes down, you can simply log in to another server and continue working.
When enabling server replication on a server, you must explicitly specify the list of servers that belong to the same server replication cluster. A server replication cluster is a group of servers whose replicated data is synchronized among all its members. Not all servers in the network need to belong to the same server replication cluster. You can have more than one server replication cluster in the network.
When a server configured for server replication comes up, it seeks out other members in the cluster and retrieves their replicated data. The server then overwrites its own replicated data with the retrieved replicated data. In other words, the first server that comes up is assumed to possess the correct replicated data. Servers that come up subsequently acquire and adopt this replicated data, which ultimately comes from the first server. Once all servers are up, the relationship between servers is peer-to-peer. Changes made on one server are automatically multicasted to the other servers. Each server will always have the up-to-date view.
Table 1 presents a high level view of what PSM configuration data is replicated and what is not replicated. Items not in this list are also not replicated. More details on this replicated data are provided in the respective sections of this guide.
Table 1: Replicated Data
PSM configuration data | Replicated |
|---|---|
NEs to discover | No To support geographically-based management schemes, NE discovery is not replicated. |
NE maintenance mode | Yes |
NE group membership and group attributes | Yes |
Ethernet domain membership | Yes |
Acknowledged and/or assigned alarms | Yes |
Customer information and customer-to-service mapping | Yes |
Profile templates | Yes |
Users | Yes In order for user replication to work correctly, all servers in a cluster must use the same RADIUS server for authentication. |
Various PSM user preferences and options that relate to the display and presentation of information | No |
For information on how to configure server replication, see Configuring Server Replication.