Cisco Cisco Email Security Appliance C160 用户指南
35-25
Cisco AsyncOS 8.0.1 for Email User Guide
Chapter 35 Centralized Management Using Clusters
Best Practices and Frequently Asked Questions
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:
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.
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.
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.
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.
joined to the cluster.
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
machine only-settings like IP address). The
machine only-settings like IP address). The
clusterconfig
command cannot be used to join a remote
machine to the cluster — you must use the CLI on the remote machine and run
clusterconfig
(“join an
existing cluster”).
In our example above we log in to lab1, run
clusterconfig
and create a cluster called CompanyName.
We have only one machine with identical requirements, so we log in to lab2, and
saveconfig
the existing
configuration (it will be drastically altered when it inherits most of lab1 settings.) On lab2 we can then
use
use
clusterconfig
to join an existing cluster. Repeat if you have additional machines at this site needing
similar policies and settings.
Run CONNSTATUS to confirm that DNS resolves correctly. As machines are joined to the cluster, the
new machines inherit almost all of their settings from lab1 and their older settings are lost. If they are
production machines you will need to anticipate if mail will still be processed using the new
configuration instead of their previous configuration. If you remove them from the cluster, they will not
revert to their old, private configs.
new machines inherit almost all of their settings from lab1 and their older settings are lost. If they are
production machines you will need to anticipate if mail will still be processed using the new
configuration instead of their previous configuration. If you remove them from the cluster, they will not
revert to their old, private configs.
Next, we count the number of exceptional machines. If there is only one, it should receive a few extra
machine level settings and you will not need to create an extra group for it. Join it to the cluster and begin
copying settings down to the machine level. If this machine is an existing production machine you must
back up the configuration and consider the changes to mail processing as above.
machine level settings and you will not need to create an extra group for it. Join it to the cluster and begin
copying settings down to the machine level. If this machine is an existing production machine you must
back up the configuration and consider the changes to mail processing as above.