CLE202 Introduction to ServerIron ADX Application Switching and Load Balancing

Transcription

1 Introduction to ServerIron ADX Application Switching and Load Balancing Student Guide Revision <#>

2 : Introduction to ServerIron ADX Application Switching and Load Balancing Corporate Headquarters - San Jose, CA USA T: (408) info@brocade.com European Headquarters - Geneva, Switzerland T: emea-info@brocade.com Asia Pacific Headquarters - Singapore T: apac-info@brocade.com 2012 Brocade Communications Systems, Inc. All Rights Reserved. Brocade, the Brocade B-weave logo, Fabric OS, File Lifecycle Manager, MyView, Secure Fabric OS, SilkWorm, and StorageX are registered trademarks and the Brocade B-wing symbol and Tapestry are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. FICON is a registered trademark of IBM Corporation in the U.S. and other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services 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. Revision: December, 2012

3 For info about SSL look into the Appendix. It is also covered in the Advanced L4-7 class. There are no standards based documents that govern the operation of the Layer4-7 based products. It is therefore important to be careful when mixing layer4-7 products from multiple vendors. Revision

4 1. Application Switch Module (ASM): ASMs are blades that contain the Application Cores. Application cores are hardware components (FPGA) where much of the application acceleration is performed in hardware. The application cores are functionally equivalent to a Barrel Processor (BP) in the previous generation of the ServerIron products. The line cards are interchangeable between the 4000 and series. Like-size module can go into any appropriate slot. So if there are 4 ASM slots, the ASM card can go into any one of these slots. 2. Management Module (MM): This blade contains the main processor and also supports the SSL daughter cards when configured with SSL. 3. Switch Fabric Module (SFM): The SFM blade contains the Switch Fabric Module. This module is used by all the other blades to provide interconnection. 4. Line Card Slots: This card contains the Ethernet ports 5. Fan Tray: Contains redundant fans. The ADX is NEBS compliant so has the airflow from front to back, while the 1000 and 4000 series have the airflow from side to side. 6. Power Supplies: Contains fully redundant AC/DC power supply options. Hardware guide may be used for further details about the electrical characteristics and power regulation. Revision

5 This diagram shows additional SSL field upgradable daughter cards that can be added to the MM to enable the SSL functionality. The 1000 series is not field upgradable and will be shipped with the SSL daughter cards already populated. License will be needed to turn on SSL. The 4000 and the series are field upgradable to SSL. The MM has a 5 Gbps connection to the SFM and the SSL daughter cards have a total of 10 Gbps connection. If there are multiple MM blades in the ADX then only one will be active. If a high availability configuration is needed then two units (ADXs) will have to be used. Revision

6 ServerIron Concepts Brocade Application Switches Enable: On demand server farm and application scalability High availability applications with failure detection and automatic failover Load balancing for best service response time and application performance Robust server farm and application security from most attacks Server resource conservation by offloading connection management SSL acceleration to optimize secure Web transactions Maximized server utilization and better return on investment (ROI) Revision

7 ServerIron Concepts Server Load Balancing (SLB) SLB will distribute traffic to a server on a set balancing parameter. This will allow an even flow of traffic among servers resulting in a better response time for the client. A server can be removed from the balancing scheme for upgrade or repair and the ServerIron ADX will balance among the remaining servers. When the server is again up and running it will again be included in the balancing scheme. It is also easy to insert an additional server without disrupting service to the clients. Revision

8 ServerIron Concepts URL-Based Server Load Balancing URL switching is the ServerIron ADX s ability to direct HTTP requests to a server, or group of servers, using information in the text of a URL string. The ServerIron ADX examines the contents of a URL string and makes a decision about where to send the packet based on selection criteria in user-defined policies. If text in the URL string matches the selection criteria, the HTTP request is sent to a load-balanced server group specified in the policy. URL string is defined as the contents of the Request-URI part of the Request-Line in an HTTP request message. This information usually consists of the absolute pathname (directory and filename) of a resource. For example: /doc/serveriron ADX/1199/url_switching.html The URL string can also be the input to a process running on a remote server. For example: /quote.cgi?s=fdry&d=1d The network location of the resource is specified in the Host header field in an HTTP request message. For example: Host: The ServerIron ADX can examine both the URL string and Host header field when determining where to send the HTTP request. See RFC 1945 or RFC 2616 for more information on HTTP request messages. Revision

9 ServerIron Concepts Health Check There are two series of health checks. The startup health checks and the on-going health checks. The start-up health checks are accomplished only at binding and not on an on-going basis. The ServerIron ADX can determine the health of the real servers without having to implement on-going health checks. Health checks are done by default when the server and its application are first started. When a real server is configured on the ServerIron ADX, the ServerIron ADX sends an ARP request for the real server and then sends an IP ping to the server to verify that the ServerIron ADX can reach the server through the network. Later, when the bind is used to bind the real server to a virtual server (VIP), the ServerIron ADX sends a Layer 4 or Layer 7 health check to bring up the port used for the binding. For example, if bind is used to bind a real server to a virtual server using port HTTP, the ServerIron ADX sends an HTTP Layer 7 health check to bring up the HTTP port on the real server. Revision

10 ServerIron Concepts SYN-Defense The SYN-defense feature allows the ServerIron to complete the TCP three-way handshake on behalf of a connecting client. When a connecting client sends a TCP SYN to a server, the ServerIron forwards the SYN to the real server, then forwards the SYN ACK from the server to the client. Next, the ServerIron sends an ACK to the real server, completing the three-way handshake on behalf of the connecting client. This action allows the real server to move the connection from its pending connection queue to its established (and much larger) connection queue. Use the server syn-def-dont-send-ack command to prevent the ServerIron from sending the ACK to the real server to complete the three-way handshake. Configuration: ServerIron ADX(config)#server syn-def-dont-send-ack SYN Attacks do not complete the 3-way handshake Hackers can overwhelm servers by sending continuous SYN requests - a type of Distributed Denial of Service (DDOS) attack. The ServerIron ADX will clear the pending connection from the real server/firewall after no response The ServerIron ADX clears its own connection table Revision

11 ServerIron Concepts IP TCP SYN-Proxy: SYN-Proxy shields the server completely from any TCP connection requests until the connection is successfully completed with the three-way handshake. The ServerIron ADX forwards the connection context to the server after the connection is fully established. Partially established connections are never seen by the servers and are timed-out by the ServerIron ADX. To configure the IP TCP Syn-Proxy, use the following commands: Configure syn-proxy in the global mode. ServerIron(config)# ip tcp syn-proxy Enable syn-proxy on each interface handling inbound SYN requests. ServerIron(config)#interface e 3/1 ServerIron(config-if-3/1)# ip tcp syn-proxy in Note that the default value for a valid ACK time is 32 seconds and is not user configurable. If you enter a value, it is ignored. The command remains in the config file the way you enter it, in case you need to downgrade to the previous release. Revision

12 ServerIron Concepts Transaction Rate Limiting (TRL) TRL provides a way to monitor and limit traffic from any one IP address. When this feature is enabled, the ServerIron ADX counts the number of bytes received from any one IP address over a specified interval. During this interval, if the number of bytes received from an individual IP address exceeds a specified threshold value, traffic from that IP address is held down and not processed for a specified number of minutes. TRL can be used to ensure that traffic from a single IP address does not monopolize resources on the ServerIron ADX. Transaction Rate Limiting can be applied to individual interfaces on the ServerIron ADX; only traffic on the specified interfaces is monitored. Transaction Rate Limiting can be applied to TCP, UDP, and ICMP traffic. For TCP and UDP traffic, you can apply Transaction Rate Limiting to up to four destination ports. TRL counts the number of transactions received from any one IP address. If the transaction count exceeds a specified threshold value, traffic from that IP address is held and not processed for a specified number of minutes. Transaction rate limit provides the flexibility to specify different configurations for different clients, based on the client IP address/prefix. Revision

13 ServerIron Concepts Connection Rate Control (CRC) CRC specifies the maximum number of new TCP, UDP, or individual port connections per second allowed on the real server. It enables you to limit the connection rate to a real server for the following: All TCP traffic All UDP traffic Individual TCP or UDP ports The ServerIron ADX increments the connection counter for real server connections only after the ServerIron ADX selects a server for the connection. If the ServerIron ADX cannot serve a client request because a real server, cache, or firewall already has the maximum number of connections for the current second for the requested port, the ServerIron ADX tries another server. If there are no servers available, the ServerIron ADX sends a TCP RST to the client. If you configure a limit for TCP or UDP and also for an individual application port, the ServerIron ADX uses the lower limit. For example, if you limit new TCP connections to a real server to 1000 per second and also limit new HTTP connections to 600 per second, the ServerIron ADX limits connections to TCP port HTTP to 600 per second. Revision

14 ServerIron Concepts Server Load Balancing 2 of 2 A ServerIron ADX establishes a virtual server that acts as a front-end to physical servers, distributing user service requests among active real servers. SLB packet processing is based on the Network Address Translation (NAT) method. Packets received by the virtual server IP address are translated into the real physical IP address based on the configured distribution metric and sent to a real server. Packets returned by the real server for the end user are translated by SLB so that the source address is that of the virtual server instead of the real server. NAT translation is performed for both directions of the traffic flow. Converting virtual services to real services requires IP and TCP checksum modifications. Revision

15 ServerIron Concepts Configure Real Servers You can add a description to a real server, virtual server, firewall, or cache. The description appears in the output of show commands and in the running-config and startup-config files. For example, to add the description Real Server # 20 to a real server: ServerIron ADX (config)# server real RS ServerIron ADX (config-rs-rs20)# description Real Server # 20 Syntax: description < text > On the ServerIron ADX 400/800, the real server s IP address can be changed, even when the real server is active. This feature is useful when you want to perform some maintenance on the real server (either the server itself or the server s configuration on the ServerIron ADX ) or when the network topology has changed. By default, when you change a server s IP address, the ServerIron ADX performs the change gracefully, as follows: Existing connections are allowed to continue on the old IP address until they terminate normally. New client requests are sent to the new IP address. Revision

16 Server Load Balancing The Solution: ServerIron ADX in a Multinetted Network With Source-NAT 1. Since the packets from the real servers are returning through the ServerIron ADX, the real servers do not need to be configured with a gateway. 2. ServerIron ADX receives the request from the client and replaces the destination address with the real server s address and the source address with the server source-ip that is on the same subnet as the real server s IP address. 3. The real server reverses the source and destination IP, since the destination IP is on the same subnet as the real server s IP, there is no need to ARP for the gateway. 4. The ServerIron ADX receives the packet from the real server and replaces the destination with the client s IP address and replaces the source with the IP address of the vip. Revision

17 Server Load Balancing Direct Server Return (DSR) Overview Direct Server Return configures the ServerIron ADX to instruct real servers to send client responses directly to the clients instead of sending the responses back through the ServerIron ADX. As a result, the clients receive faster response time and the ServerIron ADX is free to support even more sessions to serve more clients (a connection is two sessions, one in each direction). You configure DSR on an individual TCP/UDP port basis on the ServerIron ADX by entering or selecting the DSR parameter when you configure your virtual servers. In addition, the feature requires that you configure a loopback interface on each real server and give the loopback interface the IP address of the VIP. The ServerIron ADX sends the client traffic to the real server without translating the destination address from the VIP into the real server s IP address. Thus, the real server receives the client traffic addressed to its loopback address and responds directly to the client. The DSR feature applies to individual TCP/UDP ports. To configure the SI for DSR, you enable the feature for individual TCP/UDP ports when configuring the virtual server. For example, when you enable TCP port 80 (HTTP) on a virtual server, you can add the dsr parameter to enable DSR for that port. Traffic for other ports still returns through the SI. The SI does not translate the destination IP address in client requests for the port with DSR enabled. However, the SI does still translate the destination IP address in the client s request to the real server s IP address for other ports. This feature was formerly known as SwitchBack. Revision

18 Server Load Balancing Primary and Backup Servers When you use remote servers in a remote sub-net, you must enable Source-NAT to force traffic to return to the ServerIron ADX that performed the original destination NAT. The source IP addresses used for Source-NAT must be in the original ServerIron ADX s broadcast domain. The remote real server replies are addressed to the original ServerIron ADX, not to the client s address. The original ServerIron ADX can then properly reverse the destination NAT. NAT When sending client request to remote real server: Destination NAT Translate virtual IP address known by client into real server address. Source-NAT Translate client IP address into source IP address defined on the ServerIron ADX. This ensures that server response comes back to ServerIron ADX instead of directly to client. When receiving response from remote server: Source-NAT Translate real server address into virtual IP address known by client. Destination NAT Translate ServerIron ADX source IP address into client IP address. Revision

19 Global Server Load Balancing (BSLB) Global Server Load Balancing (GSLB) Brocade Global Server Load Balancer is the missing piece that allows for robust health checking for round-robin (RR) DNSs. The GSLB can be set up to be transparent or non-transparent. In transparent mode, the GSLB does not take over the IP address of the auth-dns server. In fact, there is no VIP at all. The ServerIron is simply placed directly in front of the DNS(s) and transparently (L2) passes DNS requests through to the server. The response is still intercepted and the health metrics are still applied to the responses. What you lose here is the ability to SLB the DNSs. No predictors are applied and the first release will loose the resiliency piece in that if one DNS goes becomes disabled we will not load the data to another server (future release will enable the resiliency piece). Non-transparent mode means that we do take over the IP address of the auth-dnss [one or more]. With this load balancing of DNSs can take place. For those DNSs that are geographically separated, the GSLB can still make queries to those servers using the Source-NAT option. This allows auth-dnss to be located anywhere. Revision

20 Global Server Load Balancing (BSLB) ServerIron ADX GSLB Direction to Functional Site ServerIron ADX-A is configured as a DNS proxy for the DNS that is authoritative for the domain brocade.com. Let s see how this works: The client enters and a request is made to his local DNS for a lookup. If an entry is not found, the clients local DNS sends a recursive query to the authoritative DNS for brocade.com. The GSLB ServerIron ADX, as proxy for the authoritative DNS, forwards the lookup request from the client s local DNS to the authoritative DNS Other DNSs know the authoritative DNS by the VIP configured on the GSLB ServerIron ADX, instead of its real IP address. The authoritative DNS for brocade.com answers the client s query (forwarded by the GSLB ServerIron ADX) by sending a list of IP addresses for the sites the correspond to the requested host. The GSLB ServerIron ADX assesses each IP address in the DNS reply to determine the optimal site for the client, and moves the address for that site to the top of the list The client receives a reordered list of IP addresses. The client uses the best address. Revision

21 Transparent Cache Switching (TCS) Benefits of TCS (Transparent Cache Switching) TCS allows a ServerIron ADX to detect and switch web traffic to a local cache server within the network. A single ServerIron ADX (or hot standby pair) can provide transparent cache switching for up to 1024 web cache servers. Cache servers process web queries faster and more efficiently by temporarily storing details about repetitive web queries locally, reducing the number of external inquiries required to process a web query. By limiting the number of queries sent to remote web servers, the overall WAN access capacity required is lessened as is the overall operating cost for WAN access. Brocade switches increase the reliability of transparent caching within a network by supporting redundant web cache server configurations known as web cache server groups, as well as supporting redundant paths to those server groups with the server backup option. Revision 1212 D 3

22 Transparent Cache Switching (TCS) Web Cache Capacity Scalability To scale, simply add additional web cache servers. The traffic can be directed to different caches depending on source or destination address for optimal caching hits. Revision 1212 D 9