Cisco Cisco Email Security Appliance C170 Guia Do Utilizador

Página de 1224
 
39-25
Cisco AsyncOS 9.5 for Email User Guide
 
Chapter 39      Centralized Management Using Clusters
  Best Practices and Frequently Asked Questions
Good CM Design Practices
When you LIST your CM machines, you want to see something like this:
cluster = CompanyName
Group Main_Group:
Machine lab1.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Machine lab2.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Group Paris:
Machine lab3.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Machine lab4.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Group Rome:
Machine lab5.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Machine lab6.example.com (Serial #: XXXXXXXXXXXX-XXXXXXX)
Be careful not to lose track of the level at which you are making changes. For example, if you have 
changed the name of your Main_Group (using RENAMEGROUP) to London, it will look like this:
cluster = CompanyName
Group London:
Machine lab1.cable.nu (Serial #: 000F1FF7B3F0-CF2SX51)
...
However, this configuration tends to confuse many administrators, because they begin making changes 
to the London systems at the group level, and they stop using the Cluster level as the normal 
configuration level for basic settings.
Tip: it is not a good practice to have a group with the same name as the cluster, e.g. cluster London, 
group London.  If you are using site names for group names, it is not good practice to have a cluster name 
that refers to a location.
The correct method, as explained above, is to leave as many settings at the cluster level as possible. In 
most cases you should leave your primary site or main collection of machines in the Main_Group, and 
use groups for your additional sites. This is true even if you consider that both sites are “equal.”  
Remember, CM has no primary/secondary or master/slave servers — all clustered machines are peers.
Tip: if you will be using extra groups you can easily prepare the groups before those extra machines are 
joined to the cluster.
Best Practices for Accessing Spam Quarantines in Cluster Setup
Accessing spam quarantines of other appliances in a cluster from the logged-in appliance may cause 
excessive CPU usage on the logged-in appliance. To avoid this scenario, you can access the spam 
quarantines by logging into the respective appliances. 
Procedures: Configuring an Example Cluster
To configure this example cluster, log out of all GUIs on all machines before running 
clusterconfig
Run 
clusterconfig
 on any one of the primary site machines. You will then join to this cluster only the 
other local and remote machines that need the maximum possible shared settings (allowing for the