How do I use Central Management?

Central Management makes it possible to share configuration data across multiple iPrism units, making it easier to administer them.  

Note: The Enterprise Reporting Server (ERS) for iPrism does not support Central Management.

Acquiring multiple iPrisms is typically done for the following reasons:

• Load Balancing  (click for network diagram)

  

• Redundancy  (click for network diagram)

  

• Multiple Internet Connections  (click for network diagram)

  

Central Management Overview

Chapter 9 of the iPrism Administration Guide contains detailed information on how to use iPrisms in a central management configuration.

• Central Management supports all h-Series and M-Series appliances, as long as they are running the same software version. All iPrisms, regardless of model, must have the same OS version.

• Central Management supports appliances with varying installed HotFixes, in order to provide flexibility.

• You can designate a single master system and one or more slave systems. Any configuration changes made to the master system will be automatically copied by the slaves.

• There should be only one master system designated at any given time.

• Other systems need to be set as slaves if they want to participate in the configuration sharing. If you do not want them to participate in the shared arrangement, you must designate them as standalone systems (refer to Chapter 9 of the iPrism Administration Guide for instructions on how to do this).

• • Master configuration settings that are shared:

Profiles
Networks to Filter
Filter Exceptions
Custom Filters
Triggers/email alerts
Reports Settings
LDAP Authentication configuration settings
Overrides
Profile Mapping

• • Master configuration settings that are not shared:

Network configuration settings such as interfaces, routing information, hostname, DNS server(s), and syslog server are NOT shared, as they are unique to each iPrism. Sharing could cause conflicts or network problems; e.g., sharing the same iPrism IP address would cause network conflicts.

Certain dynamic activities that cannot be shared; for more information, see iPrism Activities that are not shared.

• All communications are implemented over the HTTP protocol. This means that master and slave iPrisms should be able to contact themselves with HTTP in both directions. This may be done using direct connections or an HTTP proxy.
  Note: This may impact your IP filtering configuration if you have a firewall between the master and the slave systems.

• All communications are encrypted so as not to expose your configuration to network sniffing.

• The master iPrism will never try to modify the networking configuration of a slave (IP addresses and mask, routes, interface settings) because these are unique and/or system-dependent.

See Also:

How do I Check, Change or Add iPrism Port Assignments?

Setting up and Using Central Management

Please refer to Chapter 9 of the iPrism Administration Guide for detailed information on how to use iPrisms in a central management configuration, including the following topics:

• Initial Central Management Configuration

• Adding or Removing a Slave

• Designation a new Master

iPrism Activities that are not Shared

• Report data: Individual iPrism units report only on their own filtering activity, and do not share this data directly with other iPrism units. However, if you have multiple iPrism units, reporting data can be aggregated for high-performance reporting with the Enterprise Reporting Server (ERS) for iPrism. Reporting data may also be aggregated by using Syslog from Master & Slaves to a centralized SysLog server. See:

ERS Overview

How do I configure a Syslog Host for HTTP/IM/P2P Events?

• Authentication: If a user authenticates through the master iPrism, the user authentication session is not shared with the slave iPrism for the same reason as in Access Requests above.

Note: Triggers based on groups of users or IP ranges will not work reliably. Each iPrism sees only the traffic sent to it. When traffic from a related group of client systems spans multiple iPrisms (as in the case of load balancing), the iPrisms don't accumulate this information correctly, each seeing only its share of the traffic.