Technical Field Enablement. Symantec Messaging Gateway 10.0 HIGH AVAILABILITY WHITEPAPER. George Maculley. Date published: 5 May 2013

Transcription

1 Symantec Messaging Gateway 10.0 HIGH AVAILABILITY WHITEPAPER George Maculley Date published: 5 May 2013 Document Version: 1.0 Technical Field Enablement

2 Contents Introduction... 3 Scope... 3 Symantec Messaging Gateway architecture... 3 Design Considerations... 3 High Availability Architecture... 4 Software Configuration... 5 Step Step Step Step Step Step Step Step Deploying Symantec Messaging Gateway in an HA environment Appendix A VMware HA Checklist Appendix B Symantec Messaging Gateway appliance specifications management Symantec reserves the right to make changes without prior notice Page 2 05 May 2013

3 INTRODUCTION Symantec Messaging Gateway (SMG) is a secure gateway solution. In addition to providing antispam, malware protection, and content filtering features, SMG provides an interface for handling quarantine and data loss prevention (DLP) incidents. Due to the sensitive and mission critical nature of service, it is important to include this service in any disaster recovery planning. Taking this a step further, companies may want to implement a high availability solution to ensure that they are always able to access their electronic message data. This document proposes a solution for implementing a high availability (HA) architecture for the Symantec Messaging Gateway product. SCOPE This paper will address the necessary components and configurations for implementing SMG in a high availability environment. Implementing SMG in a high availability environment will enable an almost seamless recovery due to an unplanned hardware failure, and will enable the migration of services from one physical device to another for planned downtime. For an unplanned outage, in process transactions will be lost. However, due to the resilient nature of SMTP, no data will be lost, and failed message transfers will be re-initiated automatically. High availability is not the same as fault tolerance (FT). Fault tolerance would allow for a seamless recovery from a hardware failure, with no loss of data or in process transactions. Although FT is achievable for SMG, it is outside of the scope of this document. SYMANTEC MESSAGING GATEWAY ARCHITECTURE The Symantec Messaging Gateway solution consists of two server roles: Scanner and Control Center. The Control Center is the central management, configuration, message quarantine, and reporting interface for all Scanners. The Scanner is the mail processing engine and SMTP relay. In the current software version, once a Scanner is configured to accept connections from a Control Center, the only outbound communication from the Scanner to the Control Center is an upload of statistical data. The Control Center initiates connections to the Scanners to push configuration data, and to query the Scanners when reports are run. In the event that a Scanner is unable to communicate with a Control Center, it will continue to operate normally. By default, each Scanner will keep a record of its statistical data for 1 week, or up to 50MB of storage space. If a Control Center is unavailable for longer than the lesser of these conditions, then statistical data will be lost. In small deployments, it is possible to host both the Control Center and the Scanner role on a single appliance. To simplify the diagrams in this document, the diagrams will show both roles on a single server. However, the same considerations and instructions can be used in split deployments, including having many separate Scanners. Because the SMG Scanners are SMTP relays, it is necessary to include HA capability for both the Scanner and Control Center roles, or else messages in transit on the Scanners may be lost. DESIGN CONSIDERATIONS Page 3 05 May 2013

4 Symantec Messaging Gateway does not have any features to implement clustering or high availability. Therefore, it is necessary to implement SMG in the virtual appliance form factor, and to take advantage of the HA capabilities provided by VMware in order design an HA solution for SMG. When implementing SMG on VMware hosts, it is important to utilize prudent capacity planning for the physical servers on which the software will reside. Insufficient computing, network, or storage resources can reduce the effectiveness and reliability of any HA solution. The performance of any virtual appliance is typically 20% less than the performance of a physical appliance with the same CPU and RAM specifications. The High Availability feature of VMware requires several hardware and software components to implement, as well as specific environmental configurations. A list of the requirements can be found in Appendix A. HIGH AVAILABILITY ARCHITECTURE To create a VMware cluster, a minimum of two ESXi hosts and shared storage (via SAN) between the two hosts are required. It is highly recommended to have redundant network connections between all hosts in the cluster, in addition to having a separate network connection for production network traffic. VMware technology enables administrators to abstract computing resources to a great degree. However, individual virtual machines are still limited to the physical characteristics of the host on which they execute. It is recommended to use server class hardware with specifications which meet or exceed that of the SMG physical appliance hardware. The hardware specifications for the SMG physical appliances are detailed in Appendix B. The diagram below shows a simple VMware cluster configuration. It is recommended, to have more than two ESXi hosts assigned to the cluster. Page 4 05 May 2013

5 For environments that include multiple Scanners, it is recommended that the Scanner images be load balanced across all available ESXi cluster hosts, in order to limit the impact of a single ESXi host failure. SOFTWARE CONFIGURATION The configuration of a VMware cluster consists of nine steps. For each step, the administrator will have to decide which features to enable and in some cases, what settings to use. This guide will give some guidance for each step, but other choices are also valid, and should be made based on the administrator s familiarity and comfort with VMware. Page 5 05 May 2013

6 STEP 1 Give the cluster a name, and determine whether to enable vsphere HA and/or vsphere DRS. This example shows that both features are enabled. Page 6 05 May 2013

7 STEP 2 Determine the level of automation the cluster software will implement with regards to which ESXi hosts specific virtual machines will run on. The example shows an automation level of Manual. This is chosen so that the administrator can make an educated choice based on knowledge of the environment. For environments with multiple Scanner appliances and more than two cluster hosts, this will enable the administrator to ensure that the Scanners will be load balanced across available cluster hosts. Page 7 05 May 2013

8 STEP 3 Set the power management rules for the cluster. The example shows that this feature is disabled, but can safely be enabled in advanced VMware environments. Page 8 05 May 2013

9 STEP 4 Enable host monitoring, and disable admission control. Advanced admission control policies are outside of the scope of this paper. Page 9 05 May 2013

10 STEP 5 Set restart options for virtual machines in the cluster. It is important to set the Host Isolation Response parameter to Power Off, otherwise for the case of a management network failure, it would be possible that the VMware HA software may try to run the SMG appliance on two hosts at the same time. Since the image is only located on the SAN, there could be a catastrophic failure or corruption if the SMG VM is failed over to another machine while the original machine is still accessing the disk. Page May 2013

11 STEP 6 This example shows VM Monitoring disabled. The administrator can enable this at their discretion. Although SMG does have VMware tool support, there is a chance that enabling this feature could cause unnecessary failovers in the event that an ESX server is overwhelmed. Page May 2013

12 STEP 7 Determine whether to enable Enhanced vmotion Capability (EVC). This is an advanced settings, and should be set to Disabled unless the administrator is certain of the physical host environment. Page May 2013

13 STEP 8 Determine where to store the swapfile. It is recommended to store the swapfile with the virtual machine. Page May 2013

14 STEP 9 Review settings and finalize configuration. DEPLOYING SYMANTEC MESSAGING GATEWAY IN AN HA ENVIRONMENT Once the VMware cluster is created and physical ESXi hosts are added to the cluster, Symantec Messaging Gateway can be deployed into the cluster by deploying the SMG Virtual Appliance OVF into the cluster, just as one would do for a single ESXi host. When deploying the OVF template, it is necessary to choose a path to the SAN device as the datastore in order for HA failover to work. No further action is required in order for SMG to be protected by the cluster. Page May 2013

15 APPENDIX A VMWARE HA CHECKLIST The following list is provided as a quick reference. Full details should be obtained from VMware. All ESXi hosts in the cluster must be licensed for VMware HA. There must be at least 2 hosts in the cluster. All hosts need a unique host name. All hosts need to be configured with static IP addresses. All hosts must have access to the same management networks. There must be at least one management network in common among all hosts and best practice is to have at least 2. To ensure that any virtual machine can be run on any host in the cluster, all hosts should have access to the same virtual machine networks and datastores. Similarly, virtual machines must be located on shared, not local, storage. All hosts in the VMware HA cluster must have DNS configured so that the short host name of any host in the cluster can be resolved to the appropriate IP address from any other host in the cluster. Source: Page May 2013

16 APPENDIX B SYMANTEC MESSAGING GATEWAY APPLIANCE SPECIFICATIONS Symantec Model CPU Memory SMG 8340 v SMG 8360 v SMG 8380 v x Intel G GHz, 3M Cache, Dual Core/2T 4GB 1333MHz Single Ranked UDIMM (4x1GB) (2) x Intel Xeon E5-2620, 2.00GHz, 15MCache 32GB 1333Mhz Single Ranked DIMM (8x4GB) (2) x Intel Xeon E5-2620, 2.00GHz, 15MCache 32GB 1333Mhz Single Ranked DIMM (8x4GB) NIC Dual On-Board Broadcom 5720 QP 1Gb Network Broadcom 5720 QP 1Gb Network Daughter Card Daughter Card Minimum requirements for deploying SMG in a virtual machine can be found at: Page May 2013

17 Any technical information that is made available by Symantec Corporation is the copyrighted work of Symantec Corporation and is owned by Symantec Corporation. NO WARRANTY. The technical information is being delivered to you as is and Symantec Corporation makes no warranty as to its accuracy or use. Any use of the technical documentation or the information contained herein is at the risk of the user. Documentation may include technical or other inaccuracies or typographical This document may include information about pre-release software. Any unreleased update to the product or other planned modification is subject to ongoing evaluation by Symantec and therefore subject to change. This information is provided without warranty of any kind, express or implied. Customers who purchase Symantec products should make their purchase decision based upon features that are currently available. SYMANTEC MANAGEMENT RESERVES THE RIGHT TO MAKE CHANGES WITHOUT PRIOR NOTICE. About Symantec Symantec is a global leader in providing security; storage and systems solutions to help businesses and consumers secure and manage their information. Headquartered in Mountain View, Calif., Symantec has operations in more than 40 countries. More information is available at For product information in the U.S. call tollfree 1 (800) For specific country offices and contact numbers, please visit our Web site. Symantec Corporation World Headquarters 350 Ellis Street Mountain View, CA USA +1 (650) Copyright 2013 Symantec Corporation. All rights reserved. Symantec and the Symantec logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.