Рисунок 3. Политика перехода отключения при сбое

Политика возвращения ресурса аналогична политике выхода из строя. Но здесь вы можете запретить Failback. Это необходимо в тех ситуациях, когда смена владельца ресурса может привести к сбоям приложений кластера. В случае, если вы хотите разрешить возвращение ресурса, то вы можете разрешить делать это немедленно (Immeditely) или же в определенный интервал времени, например, в нерабочие часы, когда нагрузка на кластер минимальная (см. рис. 4).

Рисунок 4. Политика возвращения ресурса

Как правило, вместе с почтовым сервером в крупных сетях используется также различное дополнительное программное обеспечение, например, антивирус, антиспам, система шифрования и т. д. Что касается средств защиты от нежелательных почтовых сообщений (антиспама), то мое мнение, что данная служба должна располагаться на почтовом шлюзе (relay) и не должна расходовать ресурсы нашего кластера.

Что же касается таких средств, как почтовый антивирус, то перед развертыванием кластера необходимо узнать, поддерживает ли ваш антивирус кластеризацию. Как правило, все современные антивирусные системы для почтовых серверов позволяют осуществлять установку на кластерные системы. При этом антивирус после установки превращается в ресурс кластера, и вы можете управлять им так же, как и прочими ресурсами. В следующем примере используется Trend Micro ScanMail for Exchange в качестве антивирусной системы для почтового сервера (см. рис. 5).

Рисунок 5. Ресурсы кластера

Основным инструментом управления почтовым кластером является консоль Cluster Administration. Работа с почтовым кластером имеет свои особенности, в частности, нужно быть очень осторожным при работе с ресурсами, остановка основных, таких как System Attendant, приведет к остановке всех зависимых ресурсов.

К тому же не стоит забывать о тех вопросах, которые освещались в параграфе «Когда кластер не поможет…».