Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 Provides reference architecture and procedures for deploying the Brocade ServerIron ADX Series switches with Microsoft Exchange Server 2010.
CONTENTS Introduction... 3 Microsoft Enterprise Engineering Center... 3 About the Testing... 3 For More Information... 3 Overview... 4 Microsoft Exchange Server 2010... 4 Brocade ServerIron ADX... 4 Solution Architecture... 5 Application and Application Networking Architecture... 6 Brocade ServerIron ADX Networking Architecture... 7 Server Architecture... 7 Implementing and Configuring the Brocade ServerIron ADX... 7 Affinity... 8 Brocade ServerIron ADX Configuration... 9 Configuration Prerequisites... 9 Managing the Brocade ServerIron ADX via the CLI... 9 Managing the Brocade ServerIron ADX via the GUI... 10 Configuring Layer 2 Active/Hot Standby Redundancy... 11 Configuring the Server Farm (Real Servers) Using the CLI... 12 Configuring the Server Farm (Real Servers) Using the GUI... 13 Configuring the VIP with Port Persistence and Binding Real Servers to the VIP Using the CLI... 14 Configuring the VIP and Binding the Real Servers to the VIP Using the GUI... 15 Configuring Round Robin Load Balancing... 16 Configuring SSL Profiles and Proxy Using the CLI... 16 Configuring SSL Profiles and Proxy Using the GUI... 17 Defining SSL Accelerated Service... 19 Persistence: Configuring CSW Rules and Policy... 20 Conclusion... 24 Appendix: Running Configurations... 25 Basic Configuration with L2 Active/Hot Standby SSL Proxy and Round Robin Predictor... 25 Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 2 of 27
INTRODUCTION To address challenges associated with today s mission-critical enterprise application deployments, Brocade, and Microsoft have validated the solution documented in this guide. The guide provides a reference architecture and instructions for the implementation of the Brocade ServerIron ADX Series switches with Microsoft Exchange Server 2010. This solution optimizes application availability, performance, and security and decreases application Total Cost of Ownership (TCO). In order to use this guide, you should: Perform all of the configuration procedures on the Brocade ServerIron ADX. Be familiar with both Brocade ServerIron ADX and Microsoft Exchange Server 2010. Refer to the product documentation for both products. Have the Brocade ServerIron ADX installed in your network. Have a general understanding of how the Brocade ServerIron ADX functions. Microsoft Enterprise Engineering Center Brocade and Microsoft cooperated in all phases of the solution development, including lab setup at the Microsoft Enterprise Engineering Center (EEC), located at the Microsoft corporate campus in Redmond, solution functionality, and performance testing. Brocade and Microsoft jointly validated that the lab setup and solution testing represents best efforts in creating a realistic customer deployment environment and accurate documentation of the deployment. The EEC is a state-of-the-art proving ground for the world s most complex computing environments. With over $75 million invested in hardware and networking equipment from the industry s top manufacturers, the EEC can replicate virtually any production environment. Many of Microsoft s most important customers come to the EEC to get a clear view of how pre-release Microsoft products will perform in their own environments prior to actually deploying the solution. In addition, customers can influence the quality of the final release by reporting issues to Microsoft, which reduces uncertainty and can lower their deployment costs. The EEC can tackle the most complex re-creations of real-world enterprise production environments. About the Testing A number of tests were performed at the Microsoft EEC to validate the solution described in this guide. Affinity was tested using the LB-generated cookies and Source IP port persistence for all the Exchange Server 2010 protocols (OWA, ECP, MAPI/RPC, EAS, OAB, EWS, and Autodiscover). CAS servers were used to validate that the traffic was sent to the correct CAS server. Note that the Exchange Server 2010 load tester ran 6,000 simulated users against the Brocade ServerIron ADX, which placed load of approximately 8% on the Brocade ServerIron ADX. For More Information For more information on the Brocade ServerIron ADX, visit: www.brocade.com For information about Brocade offerings supporting Microsoft Exchange, visit: http://www.brocade.com/exchange For information on Brocade Education offerings, visit: http://www.brocade.com/education For more information on Microsoft Exchange Server 2010, visit: http://www.microsoft.com/exchange For more information on the Microsoft EEC, visit: http://www.microsoft.com/eec Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 3 of 27
OVERVIEW The joint solution offers optimized Exchange Server 2010 application availability, performance, security, and costs by providing application optimization services from the Brocade ServerIron ADX. Microsoft Exchange Server 2010 Microsoft Exchange Server 2010 is the server side of a client server, collaborative application product developed by Microsoft as part of the Microsoft Server product for Microsoft infrastructure solutions. Exchange Server 2010 includes e-mail, calendar, contacts and tasks, support for mobile and Web-based access to information, and support for data storage. Exchange Server 2010 provides users with the flexibility to tailor deployment to their unique needs and a simplified way to help keep e-mail continuously available. This flexibility and simplified availability comes from innovations to the core Exchange Server 2010 platform and delivers advances in performance, scalability, and reliability, while lowering the TCO. Microsoft Exchange Server 2010 deployments can leverage Brocade ServerIron ADX Series load balancing technologies for performance, affinity, scalability, high availability, and security. Without hardware load balancing, as organizations scale, a single server running Exchange Server 2010 may hit the upper limits of its processing capacity. Use of a Brocade ServerIron ADX Series switch optimizes traffic distribution to all available servers to ensure that switches consider server availability, load, response time, and other userconfigured performance metrics when selecting a server for incoming client connections. Communications is such a key enabler of business that any downtime for applications can adversely impact revenue and productivity. Microsoft Exchange Server 2010 comprises the following server roles in a three-tier architecture: Clients Client Access Server (CAS) servers Mailbox (MBX) database servers Additional server roles include: Unified Messaging Server, which connects a Private Branch exchange (PBX) system to Exchange 2010 Hub Transport Server, the mail routing server that routes mail within the Exchange organization Edge Transport Server, the mail routing server that typically sits at the perimeter of the topology and routes mail in to and out of the Exchange organization Brocade ServerIron ADX The Brocade ServerIron ADX, a Layer 4 7 application delivery switch, provides application availability, performance, security, and affinity capabilities for application infrastructure such as Exchange 2010, as described in the following sections. Application Availability Server and application health checks. Continuously monitors the health of the application availability. Server load balancing. Efficiently routes the end user and Web services request to the best available server dependent on the load balancing scheme being utilized. Network platform health monitoring. Ensures continuity of business operations through mirroring end user transactions across a redundant Brocade ServerIron ADX network. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 4 of 27
Application Performance Server load balancing. The Brocade ServerIron ADX balances the traffic load between the real servers based on a predictor used for optimal resource utilization, maximum throughput, and minimum response time. Server health monitoring. The Brocade ServerIron ADX performs health checks on the real servers to ensure that traffic is not forwarded to a real server that has failed or is not responsive. Application Security SSL Proxy. Secure Socket Layer (SSL) Proxy is the most secure configuration option available, allowing for end-to-end SSL encryption. It is also more complex as it requires keys and certificates on the Brocade ServerIron ADX, as well as on each real server.ssl Proxy allows the Brocade ServerIron ADX to decrypt HTTPS traffic, run complex HTTP Content Switching Rules (CSW rules), re-encrypt the traffic, and forward it to the appropriate server. The CSW feature makes sure that existing user sessions are forwarded to the same server to which the session was initially connected. End user access control. Provides Access Control Lists (ACLs) to protect the client-to-server traffic from worms and intruders, which attack vulnerable open server ports not being used by the application. SYN attack protection. Provides protection to back-end servers from SYN attacks. SYN attacks can exhaust back-end server resources by opening a vast number of partial TCP connections. Application Affinity Options CWS Rules. Affinity is handled by the CSW rules, which look at the cookie and determine whether it is a new cookie from a new session or an existing cookie generated by the Brocade ServerIron ADX. The new cookie is stripped from the packet and replaced with a load balancer cookie that has a server ID (server-id) attached to it. The server ID ensures that all traffic from that session is now forwarded to the same server. Source IP Port Persistence. Source IP Port Persistence provides a persistent hashing mechanism for virtual server ports, which evenly distributes hash assignments and enables a client to always be redirected to the same real server. Source IP Port Persistence, which functions at Layer 4, can be applied to non-http traffic for which cookies are not part of the protocol specification and other HTTP traffic as long as no other persistence mechanism is applied on the same port. SOLUTION ARCHITECTURE The solution architecture used for the Brocade ServerIron ADX with Microsoft Exchange Server 2010 is shown in Figure 1. The ports used by Exchange services are: HTTP (Port 80) and HTTPS (Port 443) HTTP and HTTPS are used for several Microsoft Exchange Servers: Outlook Web Access (OWA) Outlook Anywhere (OA) (MAPI tunneled over HTTPS) Exchange ActiveSync for mobile devices (EAS) Exchange Control Panel (ECP) Exchange Web Services (EWS) Autodiscover (AUDI) Offline address book distribution Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 5 of 27
NOTE: Microsoft recommends using HTTPS. RPC/MAPI (Port 135) Microsoft Remote Procedure Call (RPC) defines a powerful technology for creating distributed client/server programs. The RPC run-time stubs and libraries manage most of the processes relating to network protocols and communication. TCP Ports 60000 and 60001 As with Remote Procedure Call (RPC) applications, the end-point TCP port numbers for these services are allocated by the RPC end-point mapper when the services are started. This means that a large range of destination ports may need to be configured for load balancing without the ability to specifically target traffic for these services based on port number. It is possible to statically map these services to specific port numbers in order to simplify load balancing. If the ports for these services are statically mapped, then the traffic for these services will be restricted to port 135 (used by the RPC port mapper) and the two specific ports that have been selected for these services. In this configuration TCP ports 60000 and 60001 were statically mapped. Note that these values can be changed manually. Refer to the Microsoft Knowledge Base for details on mapping the static ports (http://technet.microsoft.com/en-us/library/ff625248.aspx ). L2 switch Outlook clients Brocade ServerIron ADX L2 switch Active Directory CAS 1 MBX 1 SQL Server database cluster CAS 2 MBX 2 CAS 3 MBX 3 MBX4 Figure 1. Brocade ServerIron ADX load balancer with the Exchange Server 2010 Application and Application Networking Architecture In this solution, the Brocade ServerIron ADX ensures affinity and load balances traffic going to the server farm. The Brocade ServerIron ADX use SSL proxy to decrypt incoming traffic, apply CSW rules, and reencrypt traffic back to the server farm. Note that Microsoft recommends the use of HTTPS for user traffic. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 6 of 27
Brocade ServerIron ADX Networking Architecture The Brocade ServerIron ADX provides the following features: Session persistence. Session persistence is the ability to forward client requests to the same server for the duration of a session. Content Switching Rules (CSW). Layer 7 switching allows the Brocade ServerIron ADX to make forwarding decisions about HTTP traffic using information in a URL, cookie, or SSL session ID. SSLProxy. In full SSL proxy mode, the ServerIron ADX maintains encrypted data channels with the client and the server. This mode provides additional security without incurring SSL hardware acceleration cost on the server. SSL proxy provides visibility to application traffic for Layer 7 processing and security. Health monitoring. Health monitoring is used to track the state of the server and determine its ability to process connections in the server farm. Brocade ServerIron ADX provides load balancing of the traffic to the server farm using Round Robin, Least Local Connections, Dynamic Weighted Predictor, and so on (for more about these methods, see the Brocade ServerIron ADX product documentation). Since the solution uses source IP port persistence on the Virtual IP (VIP), the Round Robin predictor for VIP is automatically enabled and used to evenly distribute hash assignments. After you enter the port <port> persist-hash command, the predictor round-robin command automatically appears under the virtual server entry in the configuration file. Active/Hot Standby redundancy uses a dedicated link between the Brocade ServerIron ADX switches, which transmits flow-state information, configuration synchronization information, and the redundancy heartbeat. Server Architecture The server architecture consists of three CAS servers, four MBX servers, two Outlook clients, and one Hyper- V server: The three CAS servers are load balanced by the Brocade ServerIron ADX and each has the hardware and software configuration shown in the table below. Server Name Software Speed Sockets Core Memory CAS (Client Access Server) Windows Server 2008 R2 Enterprise 2.66 Ghz 2 2 16 GB MBX (Mailbox Server) Windows Server 2008 R2 Enterprise 3.00 Ghz 4 3 32 Gb Outlook Clients Windows Server 2008 R2 Enterprise 2.66 Ghz 2 2 16 GB NOTE: The MBX database and Active Directory server are not load balanced. IMPLEMENTING AND CONFIGURING THE BROCADE SERVERIRON ADX The Brocade ServerIron ADX used in this solution is deployed in an Active/Hot standby mode and is connected to two Layer 2 switches. Key features implemented on the Brocade ServerIron ADX to support this deployment are: Layer 4 load balancing Layer 7 load balancing Source IP port persistence SSL Proxy Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 7 of 27
Server health monitoring Connection replication for stateful (or state-aware) failover Affinity Affinity is the ability to associate a client to a specific Client Access Server (CAS) to ensure that all requests sent from that client go to the same CAS. The following load balancing methods support affinity on the Brocade ServerIron ADX: Load Balancer (LB)-created cookie SSL session ID Source IP NOTE: LB-created cookie (since the incoming traffic is SSL, an SSL proxy must be used) can be used with source IP, and SSL session ID can also be used with source IP (SSL), but all three cannot be used together. One of these methods must be used since Exchange recommends using HTTPS instead of HTTP. Brocade recommends using LB- created cookie and source IP port persistence. SSL session ID affinity is not recommended, as some browsers renegotiate new SSL session IDs every few minutes thus breaking the affinity. LB-Created Cookie This method is very reliable for tying a client session to a Client Access Server. The load balancer inserts a cookie into the client-server protocol that is associated with a CAS server. The session continues to forward traffic to the same CAS server until the session is over. The LB-created cookie method is supported for OWA and ECP protocols that run on top of HTTP in Microsoft Exchange 2010, but has these limitations: Not supported for RPC, Exchange Address Book Service, POP, and IMAP The load balancer needs to have the ability to read and interpret the HTTP stream. When using SSL, the load balancer must decrypt the traffic to examine content. To use this method, the client must support receiving arbitrary cookies from the server and then including them in all future requests to the server. Note that this capability is unsupported in: Exchange ActiveSync clients, Outlook Anywhere (OA) (not supported in any version of Outlook up to and including Outlook 2010), and some Exchange Web Services clients. However, Outlook Web Access (OWA), Exchange Control Panel (ECP), and remote PowerShell Exchange 2010 protocols are supported. Source IP Port Persistence In this method, the LB looks at a client IP address and sends all traffic from a certain source/client IP to a given CAS. Cookie persistence is recommended for workloads where it is supported; but if source IP persistence is necessary for those workloads, it can still be used. However, the source IP method has two limitations: Whenever the IP address of the client changes, the affinity is lost. However, the user impact is acceptable as long as this occurs infrequently. Having a large number of clients from the same IP address leads to uneven distribution. Distribution of traffic among the CAS machines then depends on how many clients are arriving from a given IP address. Two things that can cause a lot of clients to arrive from the same IP address are: Network Address Translators (NATs) or outgoing proxy servers (for example, Microsoft Forefront Threat Management Gateway, or TMG). In this case the original client IP addresses are masked by the NAT or outgoing proxy server IP addresses. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 8 of 27
CAS-to-CAS proxy traffic. One CAS machine can proxy traffic to another CAS machine, typically between Active Directory (AD) sites, as most Exchange 2010 traffic needs to be handled by either a CAS in the same AD site as the mailbox being accessed or a CAS with the same major version as the mailbox being accessed. BROCADE SERVERIRON ADX CONFIGURATION The following are the high-level steps required to deploy the Brocade ServerIron ADX with Exchange Server 2010: Configure Layer 2 Active/Hot standby redundancy Configure SSL profiles Configure CSW rules Configure CSW policy Configure the server farm (real servers) Configure the VIP and bind the real servers to the VIP Configure load balancing: Round Robin Configure SSL Configuration Prerequisites The following prerequisites are required to deploy the solution: Working knowledge of installing and deploying the Exchange Server 2010 Experience with basic networking and troubleshooting Experience installing and deploying the Brocade ServerIron ADX Working knowledge of the Brocade ServerIron ADX Command-Line Interface (CLI) Brocade ServerIron ADX running software version 12.1 or later Brocade ServerIron ADX TrafficWorks Graphic User Interface (GUI, supported in the Brocade ServerIron ADX version 12.1 or later) NOTE: Not all steps can be completed using the GUI. Managing the Brocade ServerIron ADX via the CLI 1. At the opening CLI prompt, enter: ServerIron> enable 2. Access the configuration level of the CLI, enter: ServerIron# configure terminal ServerIron (config)# 3. To assign an IP address to the ServerIron, enter: ServerIron (config)# ip add 192.168.1.253 255.255.255.0 4. To assign a default gateway, enter: ServerIron (config)# ip default-gateway 192.168.1.1 Additional commands: ServerIron (config)# hostname SP1 ServerIron (config)# enable super-user-password foundry Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 9 of 27
ServerIron (config)# no enable aaa console ServerIron (config)# telnet server ServerIron (config)# username SP1 nopassword NOTE: It is recommended that a semi-secure password be used. 5. To exit from the configuration level of the CLI, enter: SP1 (config)# end To save the configuration to NVRAM, enter: SP1# write memory Managing the Brocade ServerIron ADX via the GUI To access the Brocade ServerIron ADX using the GUI, perform the steps listed above and complete the following procedure. Connecting the Brocade ServerIron ADX to the Network 1. Connect the ServerIron to your network infrastructure. 2. Check to see if ping access to the ServerIron IP address is working. 3. Open a browser (MS Internet Explorer or FireFox) window. 4. Type the ServerIron IP address into the browser window and press Enter. The Login window is displayed. 5. Click the HTTP button to display the user name and password dialog box. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 10 of 27
NOTE: The default user name and password are admin and brocade respectively. For greater security, you should change the password. 6. Enter the user name and password and click OK. The home page for the ServerIron Web interface is displayed. Configuring Layer 2 Active/Hot Standby Redundancy In this deployment with the Microsoft Exchange Server 2010, the Brocade ServerIron ADX was configured as active/hot standby, in which both ServerIron ADX switches share the same VIP and configuration (with the exception of the management IP address). In a typical hot standby configuration, one ServerIron ADX is the active device and performs all the Layer 2 switching and Layer 4 Server Load Balancing (SLB) switching, while the other ServerIron ADX monitors switching activities and remains in a hot standby role. If the active ServerIron ADX becomes unavailable, the standby ServerIron ADX immediately assumes the unavailable ServerIron ADX s responsibilities. The failover from the unavailable ServerIron ADX to the standby device is transparent to users. In addition to the same Virtual IP address, both ServerIron ADX switches share a common MAC address known to the clients. Therefore, if a failover occurs, the clients still know the ServerIron ADX by the same MAC address. The active sessions running on clients continue and clients and routers do not need to re-arp (Address Resolution Protocol) for the ServerIron ADX MAC address. The configuration used for the ServerIron ADX in this deployment with the Microsoft Exchange Server ADX was active/hot standby, in which both ServerIron switches share the same VIP address and configuration (with the exception of the management IP address) but one ServerIron ADX is active and the other is in hot standby mode. NOTE: These tasks must be performed using the CLI. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 11 of 27
At the configuration prompt: 1. Configure the active ServerIron and hot standby (backup) ServerIron VLAN: vlan 999 by port > Creates the backup VLAN untagged ethe 3 > Associates the VLAN to Ethernet port 3 no spanning-tree 2. Ensure that VLAN 1 has the spanning tree disabled: vlan 1 name DEFAULT-VLAN by port no spanning-tree 3. Configure the redundant link: server backup ethe 3 0012.f27c.8540 vlan-id 999 > Sets the active server server backup-preference 5 > Determines the switch back time (configure only on backup) Where 0012.f27c.8540 is the active ServerIron system MAC address 4. Add the interface to monitor for redundancy: server router-ports ethernet 4 Configuring the Server Farm (Real Servers) Using the CLI NOTE: When configuring the real server, include the following command lines in conjunction with the CSW rules: Server-ID: the numerical value to identify each individual server that will be used in the CSW rules to determine which server to persist on. Group-ID : A real server group can contain one or more real servers. If there is more than one real server in a server group, requests are load balanced across all the servers in the group. server real casa1 10.100.0.2 port ssl port ssl server-id 1201 port ssl group-id 1 1 port 135 port 60000 port 60001 port http port http url "HEAD /" port http server-id 1201 port http group-id 1 1 server real casa2 10.100.0.22 port ssl port ssl server-id 1202 port ssl group-id 1 1 port 135 port 60000 port 60001 port http port http url "HEAD /" port http server-id 1202 port http group-id 1 1 Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 12 of 27
server real casa3 10.100.0.23 port ssl port ssl server-id 1203 port ssl group-id 1 1 port 135 port 60000 port 60001 port http port http url "HEAD /" port http server-id 1203 port http group-id 1 1 Configuring the Server Farm (Real Servers) Using the GUI 1. In the Traffic Management section on the left, click Real Server and click the Basic tab. Enter the names of the real servers. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 13 of 27
2. Click the Port tab to display the port configuration screen, and enter the port type, server-id and health check information for every real server. Configuring the VIP with Port Persistence and Binding Real Servers to the VIP Using the CLI server virtual caslb1 10.100.0.20 predictor round-robin no port ssl sticky port ssl port 60000 port 60000 persist-hash port 60001 port 60001 persist-hash port 135 port 135 persist-hash port http bind ssl casa1 ssl casa2 ssl casa3 ssl bind 60000 casa1 60000 casa2 60000 casa3 60000 bind 60001 casa1 60001 casa2 60001 casa3 60001 bind 135 casa1 135 casa2 135 casa3 135 Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 14 of 27
Configuring the VIP and Binding the Real Servers to the VIP Using the GUI 1. In the Traffic Management section, click Virtual Server and click the Basic tab. Create the VIP interface. 2. In this screen also, from the Predictor drop-down menu, choose Round Robin and click Apply. 3. Click the Port tab to apply the port type used for this VIP interface. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 15 of 27
4. To bind the VIP to the real servers, click the Bind tab and bind the associated real servers to their VIP. Configuring Round Robin Load Balancing Since the solution uses Source IP port persistence on the VIP(s) for which you re going to perform port persistence, the Round Robin predictor for VIP is automatically enabled. This default is used to evenly distribute hash assignments. After you enter the port <port> persist-hash command, the predictor roundrobin command automatically appears under the virtual server in the configuration file. Configuring SSL Profiles and Proxy Using the CLI In the full SSL proxy mode, the ServerIron ADX maintains encrypted data channels with the client and the server. This mode provides additional security with no SSL hardware acceleration cost to the server. SSL proxy provides visibility to application traffic for Layer 7 processing and security. Configuration of SSL proxy requires the network administrator for the ServerIron ADX to upload the CAS certificate that was issued from the Certificate Authority (CA) server and the CA server certificate. See the Brocade ServerIron ADX product documentation for instructions using the CLI. 1. Configure the SSL profiles for SSL proxy: ssl profile serverside ca-cert-file cert2 session-cache off ssl profile clientside keypair-file cas-export certificate-file cas-export cipher-suite all session-cache off 2. Configure the VIP to perform SSL proxy: server virtual caslb1 10.100.0.20 port ssl ssl-proxy clientside serverside Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 16 of 27
Configuring SSL Profiles and Proxy Using the GUI Uploading the SSL Certificate Once you receive an SSL certificate from the CA, upload it to the ServerIron ADX: 1. Click the SSL Switching link on the Security button. 2. Click the Certificates tab 3. Click the Certificate Upload to ServerIron down arrow. 4. Enter the following information: Certificate Format: Select PEM (the default) or PKCS12. Certificate File Name (Optional): Specify a name for the certificate if you wish to upload the certificate on the ServerIron ADX with a different name. If you leave this field blank, the certificate is uploaded with the same name. Chain CA Certificate: Click the check box if you want to chain (append) the certificate you are uploading to an existing certificate on the ServerIron ADX. Note that the "Select Server Certificate" title of the next field changes to "Select CA Certificate" when you click the check box. Select Server Certificate on ServerIron: Select the existing certificate on the ServerIron to which you want to chain this selected CA certificate. Select Server Certificate or Select CA Certificate: Select the server certificate or CA certificate from your local directory. 5. Click Upload. If the procedure is successful, the message "The operation was successful" appears at the top of the page and the certificate is listed in the Summary table. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 17 of 27
Creating an SSL Profile To create an SSL profile, first make sure that an SSL key and SSL certificate have been created or uploaded to the ServerIron ADX. Then follow the steps below to define an SSL profile. 1. Click the SSL Switching link on the Security button.2, and click the SSL Profiles tab. 2. Select New from the drop-down list and provide the following information: SSL Profile Name: For example: ssl-profile-1 SSL Certificate: Select from the drop-down list. Certificate Chaining: Click Enable if the certificate in use is a chained certificate. 3. Click Apply to accept and create the SSL profile. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 18 of 27
4. Additional options under the SSL profile must be applied, click the Advanced Options down arrow to display these options. Select CA Certificates: This selection is applicable if the ServerIron is configured in SSL proxy mode, in which it acts as an SSL client to a server-side SSL certificate 5. Click Update. Defining SSL Accelerated Service Before enabling SSL acceleration, make sure that the following have been created: Virtual Server Virtual Server Port SSL (TCP) Profile Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 19 of 27
1. Click the SSL Switching link on the Security button. 2. Click the SSL Services tab. 3. Provide the following information: Virtual Server: Select from the drop-down list. Virtual Server Port: Select from the drop-down list. SSL Mode: Select Proxy. Server Profile: Select the profile from the drop-down list. Client Profile: Since SSL proxy mode is used, select the profile from the drop-down list. 4. Click Apply to enable SSL acceleration for a service (VIP). Persistence: Configuring CSW Rules and Policy The Exchange Server 2010 traffic is forwarded by the client via SSL. SSL proxy must be used to convert the SSL traffic to HTTP. The CSW rules are then applied to the HTTP traffic, which is re-encrypted and forwarded to the CAS server. CSW Rule Behavior for LB-Inserted Cookie LB generates a cookie when a specific rule is matched. The cookie insertion is typically configured together with cookie switching. The ServerIron ADX performs cookie switching based on the cookie value of "ServerID" or as defined in the rules. Note that when the client is sending MAPI/RPC traffic toward the server, port 135 and a dynamic application port (here 60000-60001) are used. In this case the traffic is forwarded based on the form of hashing used. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 20 of 27
Figure 2 describes the workflow for inserting cookies. Figure 2. CSW rules for inserting cookies The following cases map to the flowchart in Figure 2. Case#1: Server ID exists If no rule is encountered, the ServerIron ADX takes the default action. It forwards the request to server group 1 and inserts a cookie with the name "ServerID," which expires in 60 minutes. If a server ID exists, extract the ID and check if a server with same ID is up. If the server than forward the packet request to the server. If the server is down than select a server based on layer 4 server load balancing, insert a cookie server ID in the response and forward it to the selected server. Configure CSW rules as follows: csw-rule "cookie1" header "cookie" pattern "SERVERID=" case-insensitive HTTP Header rule name: Header Pattern: Matches if the specified pattern exists anywhere within the specified HTTP header field Syntax: [no] csw-rule <rule-name> header <header-name> pattern <value> Configure CSW policy as follows: csw-policy "ex2010a" case-insensitive match "cookie1" persist offset 0 length 4 group-or-server-id default forward 1 default rewrite insert-cookie "ServerID" Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 21 of 27
Syntax: default rewrite insert-cookie [<cookie-name> [<domain> [<path> [<age>]]]] The <cookie-name> variable specifies the name of the cookie to be inserted. The <path> variable specifies the attribute path for the cookie to be inserted. If the <path> variable is not configured or it is configured to be "*", "/" is defined for the cookie path. The <domain> variable specifies the attribute domain for the cookie to be inserted. If the <domain> variable is not configured or it is configured to be "*", the default domain for the cookie inserted in the HTTP response will be the same as the one in the previous request. The <age> variable specifies how many minutes the browser takes to expire the cookie to be inserted. If the <age> variable is not configured, the cookie will be expired once the browser is closed. If the <age> variable is configured to be 0, the browser will age out the cookie immediately. NOTE: <cookie-name> is required; while <path>, <domain>, and <age> are optional. Case#2: Server ID doesn t exist When a new session is created, there is no server ID. When a server ID doesn t exist, inspect the packet for URL prefix OWA and ECP. Scenario 1: OWA and ECP URLs exist If these URL prefixes exist, then forward the packet to a server selected based on Layer 4 server load balancing (insert a cookie server ID in the response before forwarding to the selected server). Configure CSW rules as follows: csw-rule "ecp" url prefix "/ECP" case-insensitive csw-rule "owa" url prefix "/OWA" case-insensitive URL rule name: URL prefix: Matches if the URL string begins with the specified prefix. Syntax: [no] csw-rule <rule-name> url prefix <value> Configure CSW policy as follows: csw-policy "ex2010a" case-insensitive match "owa" forward 1 match "owa" rewrite insert-cookie "ServerID" match "ecp" forward 1 match "ecp" rewrite insert-cookie "ServerID" You can configure the ServerIron ADX to insert a cookie into an HTTP response when a specified rule is matched. When the rule is matched, a cookie is inserted in the response when any of the following occur: No cookie header is found in the HTTP request, or a cookie header exists but it does not contain the cookie specified by the port http server-id command. The specified cookie name is found in the HTTP request, but the cookie value is out of the range used for cookie switching. The cookie value must be between 1 and 2047. The specified cookie name is found in the HTTP request, but the real server or server group indicated by the cookie value is not available. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 22 of 27
For example, the following command causes the ServerIron ADX to insert the cookie indicated by the port http Server-id command into the HTTP response when rule ecp is matched: ServerIronADX(config-csw-policy1)# match ecp rewrite insert-cookie Syntax: [no] match <rule-name> rewrite insert-cookie Scenario 2: OWA and ECP URLs don t exist If the URL OWA and ECP don t exist, then inspect the packet for the prefixes AUDI, EWS, OAB. If these URLs exist, forward the packet to a server selected based on URL hash mechanism used. (Remember that there are only two protocols that support cookie persistence: OWA and ECP.) For a given rule, you can configure a primary persist action and a secondary persist action. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron ADX uses the secondary persist action to direct packets to a server. For EWS, the following commands configure a rule and policy that use the persist action: Configure CSW rules as follows: csw-rule "audi" url prefix "/AUTODISCOVER" case-insensitive csw-rule "ews" url prefix "/EWS" case-insensitive csw-rule "oab" url prefix "/OAB" case-insensitive Configure CSW policy as follows: csw-policy "ex2010a" case-insensitive match "audi" persist offset 0 length 0 match "ews" persist offset 0 length 0 match "oab" persist offset 0 length 0 Syntax: [no] match <rule-name> persist offset <offset> length <length> [[<persistmethod>] [secondary]] For example, the csw-rule command creates a rule that matches if an incoming packet contains EWS in the URL field. The csw-policy command creates a policy called ex2010a. The match ews persist command associates the rule with the persist action. As a result, if an incoming packet has EWS in the URL field, it is used as the persist string. The ServerIron ADX uses the persist string along with the default hashing-bucket persist method to calculate the real server to which to send the packet. The <offset> variable specifies the offset in bytes from the beginning of the content matched by the <rule-name> to be used as the persist string. If you specify 0 as the <offset>, the persist string begins at the start of the matched content. The <length> variable specifies the length in bytes of the persist string. If you specify 0 as the <length>, the persist string ends at the end of the matched content. If these URLs don t exist, a server is selected based on the predictor used (in this case Round Robin) and the packet is forwarded to it: server virtual caslb1 10.100.0.20 predictor round-robin Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 23 of 27
The CLI configuration for the CSW rules should look like this: csw-rule "audi" url prefix "/AUTODISCOVER" case-insensitive csw-rule "catchall" url exists csw-rule "cookie1" header "cookie" pattern "SERVERID=" case-insensitive csw-rule "ecp" url prefix "/ECP" case-insensitive csw-rule "ews" url prefix "/EWS" case-insensitive csw-rule "oab" url prefix "/OAB" case-insensitive csw-rule "owa" url prefix "/OWA" case-insensitive The CLI configuration for the CSW policy should look like this: csw-policy "ex2010a" case-insensitive match "cookie1" persist offset 0 length 4 group-or-server-id match "owa" forward 1 match "owa" rewrite insert-cookie "ServerID" match "ecp" forward 1 match "ecp" rewrite insert-cookie "ServerID" match "audi" persist offset 0 length 0 match "ews" persist offset 0 length 0 match "oab" persist offset 0 length 0 match "catchall" forward 1 default forward 1 default rewrite insert-cookie "ServerID" Once created, CSW Rules and Policy must be enabled on the VIP to become active as follows: server virtual caslb1 10.70.4.100 port ssl csw-policy "ex2010a" port ssl csw port http port http csw-policy "ex2010a" port http csw CONCLUSION Microsoft Exchange Server 2010 can be effectively deployed behind a Brocade ServerIron ADX load balancer using LB-generated cookies and Source IP port persistence to ensure affinity. Since Microsoft recommends using HTTPS, the Brocade ServerIron ADX uses SSL Proxy to allow the use of HTTP CSW rules. For more information about implementing load balancing with Microsoft Exchange 2010, visit: http://technet.microsoft.com/en-us/library/ff625247.aspx Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 24 of 27
APPENDIX: RUNNING CONFIGURATIONS Basic Configuration with L2 Active/Hot Standby SSL Proxy and Round Robin Predictor ADX1#sh run Building configuration... Current configuration : 5480 bytes ver 12.1.00cT401 global-protocol-vlan ssl profile clientside keypair-file exported-p12.p12 certificate-file exported-p12.p12 cipher-suite all-cipher-suites session-cache off ssl profile serverside cipher-suite all-cipher-suites ca-cert-file certificate.pem session-cache off server backup ethe 16 001b.edc2.a050 vlan-id 999 server port 135 tcp server port 60000 tcp server port 60001 tcp server router-ports ethernet 1 server router-ports ethernet 2 context default csw-rule "audi" url prefix "/AUTODISCOVER" case-insensitive csw-rule "catchall" url exists csw-rule "cookie1" header "cookie" pattern "SERVERID=" case-insensitive csw-rule "ecp" url prefix "/ECP" case-insensitive csw-rule "ews" url prefix "/EWS" case-insensitive csw-rule "oab" url prefix "/OAB" case-insensitive csw-rule "owa" url prefix "/OWA" case-insensitive csw-policy "ex2010a" case-insensitive match "cookie1" persist offset 0 length 4 group-or-server-id match "owa" forward 1 match "owa" rewrite insert-cookie "ServerID" match "ecp" forward 1 match "ecp" rewrite insert-cookie "ServerID" Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 25 of 27
match "audi" persist offset 0 length 0 match "ews" persist offset 0 length 0 match "oab" persist offset 0 length 0 match "catchall" forward 1 default forward 1 default rewrite insert-cookie "ServerID" server real casa1 10.100.0.21 port ssl port ssl server-id 1201 port ssl group-id 1 1 port 135 port 60000 port 60001 port http port http url "HEAD /" port http server-id 1201 port http group-id 1 1 server real casa2 10.100.0.22 port ssl port ssl server-id 1202 port ssl group-id 1 1 port 135 port 60000 port 60001 port http port http url "HEAD /" port http server-id 1202 port http group-id 1 1 server real casa3 10.100.0.23 port ssl port ssl server-id 1203 port ssl group-id 1 1 port 135 port 60000 port 60001 port http port http url "HEAD /" port http server-id 1203 port http group-id 1 1 server virtual caslb1 10.100.0.20 predictor round-robin port ssl no port ssl sticky port ssl ssl-proxy clientside serverside port ssl csw-policy "ex2010a" port ssl csw port 60000 port 60000 persist-hash Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 26 of 27
port 60001 port 60001 persist-hash port 135 port 135 persist-hash port http port http csw-policy "ex2010a" port http csw bind ssl casa1 ssl casa2 ssl casa3 ssl casa4 ssl bind 60000 casa1 60000 casa2 60000 casa3 60000 casa4 60000 bind 60001 casa1 60001 casa2 60001 casa3 60001 casa4 60001 bind 135 casa1 135 casa2 135 casa3 135 casa4 135 vlan 1 name DEFAULT-VLAN by port vlan 1818 by port untagged ethe 1 to 4 vlan 999 by port untagged ethe 16 no spanning-tree aaa authentication web-server default local chassis name ADX1 enable telnet authentication no enable aaa console hostname ADX1 ip address 10.100.0.101 255.255.255.0 ip dns domain-name www.cas.brocade.com ip default-gateway 10.100.0.1 logging console telnet server username admin password... username administrator nopassword web-management enable ethe 1 to 2 no-asm-block-till-bootup 2010 Brocade Communications Systems, Inc. All Rights Reserved. 06/10 GA-DG-303-00 Brocade, the B-wing symbol, BigIron, DCFM, DCX, Fabric OS, FastIron, IronView, NetIron, SAN Health, ServerIron, TurboIron, and Wingspan are registered trademarks, and Brocade Assurance, Brocade NET Health, Brocade One, Extraordinary Networks, MyBrocade, and VCS are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned are or may be trademarks or service marks of their respective owners. Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in this document may require an export license from the United States government. Deploying the Brocade ServerIron ADX with Microsoft Exchange Server 2010 27 of 27