Deploying SAP NetWeaver Infrastructure with Foundry Networks ServerIron Deployment Guide

Transcription

1 Deplloyiing SAP NetWeaver Inffrastructure s wiith Foundry Networks ServerIron Deployment Guide July 2008 Copyright Foundry Networks Page 1

2 Table of Contents Executive Overview... 3 Deployment Architecture... 3 ServerIron Configuration... 5 Additional Design Considerations Foundry-SAP Solution... 8 Appendix A Running Configuration Appendix B Additional Information Copyright Foundry Networks Page 2

3 Executive Overview SAP is one of the leading providers of business software serving customers all over the world. These customers employ SAP technology to build comprehensive solutions for every aspect of business operations. Organizations of all sizes use SAP solutions to reduce cost, ease operations, manage business processes and improve performance. SAP NetWeaver technology offerings enable customers to execute a service oriented architecture (SOA) strategy and enjoy new levels of flexibility in the business process management. In the absence of a secure, high-performing, highly scaling and highly available network infrastructure, organizations will not be able to realize the full potential of SAP solutions. Foundry s intelligent application delivery switches can be configured to constantly monitor SAP application servers and optimally distribute traffic among them in order to achieve maximum application availability for business end-users. Integrating Foundry s ServerIron application delivery switches in front of SAP application servers enables organizations to maintain their competitive edge and remain on top of ever evolving business needs. Deployment Architecture SAP and Foundry designed a set of tests to illustrate how Foundry s ServerIron application switches accelerate delivery of SAP applications and secure SAP application servers. The test landscape incorporated many scenarios that customers typically use with their SAP SOA applications. All tests were performed with Foundry s ServerIron switches front ending the SAP NetWeaver application platform. These tests were conducted using the ServerIron GT-E with Integrated SSL (2BP) and ServerIron 4G-SSL hardware. The ServerIron software version used for this testing was TrafficWorks release 10.1 switch code. Figure 1: Integration Setup Foundry ServerIron 4G-SSL L2 Switch Wide Area Network L2 Switch Foundry ServerIron GT-E (Integrated SSL) L4 SLB SSL Acceleration Cookie Switching L7 SLB Custom Composite Application SAP Enterprise Portal NetWeaver BackEnd End-Users Server Composition Environment ECC Emulation Server Server Copyright Foundry Networks Page 3

4 Basic Terminologies Real server Real Servers are the Application Servers. They are either placed behind the application delivery switch via direct or indirect connection, or are connected to the core network infrastructure. In case of later, the application delivery switch such as ServerIron is connected to the core network via single upstream link and all traffic flows through this link. This design is also referred to as one-arm design. In a typical network, there would be one or more real servers running the same application instance to service clients/users. Application delivery switches allow administrators to add or remove real servers from the available pool without impacting service availability. Virtual server A Virtual server represents the logical instance of the application and resides on the application delivery switch. This virtual instance is mapped to a pool of backend real servers that provide application content. Clients connect to the virtual server and the application delivery switch load balances these requests among multiple real servers. Server Load Balancing (SLB) SLB offers numerous benefits such as ease of server farm administration, higher performance with efficient load distribution, better service availability & reliability with automatic failover and higher security. Application servers can be added or removed depending on traffic requirements without impacting service to existing end-users. Health Checks A health check is a mechanism through which application delivery switches poll backend real servers on a periodic basis for service availability. The ServerIron application delivery switches can use layer 3, layer 4, layer 7 and scripted health checks to verify availability of real servers and application instances on these real servers. If a real server or an application instance on a real server fails a health check, then the application switch takes that instance out of service rotation. Load Balancing Predictor The predictor algorithm determines how to balance client requests among multiple real servers. Some of the most popular predictor methods are: - Least Connections - Round Robin - Weighted - Dynamic Weighted Session Persistence If an application requires that end-user should connect to or persist to the same real server for subsequent requests then some form of connection or session persistence mechanism is employed. Session persistence can be based on fields such as client ip, http cookie, or http URL. Copyright Foundry Networks Page 4

5 SSL Acceleration The Secure Sockets Layer (SSL) has become the most widely used protocol today for providing security and confidentiality for communications over the Internet. SSL provides a secure pipe and allows other protocols such as http to run inside it. Foundry ServerIron SSL acceleration offloads SSL handshake and encryption/decryption tasks from the real server. This saves processor cycles on the real servers and accelerates end-to-end application performance. ServerIron Configuration Configuration Steps 1) Enter the ServerIron configuration mode Connect to the ServerIron switch using console connection or telnet into the switch and issue following commands: SI> enable SI# config term SI(config)# All further configuration edits are executed from config mode. 2) Define the Real Servers Define real servers that are hosting Portal application and BackEnd application using following commands: (config)# server real <RsPortal1_name> <RsPortal1_IP> port <RsHTTPPort1> port <RsHTTPPort1> server-id <RsPortal1-id#> port <RsHTTPPort1> group-id <RsPortalGp-id#_start> <RsPortalGp-id#_end> (config)# server real <RsPortal2_name> <RsPortal2_IP> port <RsHTTPPort2> port <RsHTTPPort2> server-id <RsPortal2-id#> port <RsHTTPPort2> group-id <RsPortalGp-id#_start> <RsPortalGp-id#_end> For the integration setup in lab, the two Portal server instances were simulated on a single server and they were configured to listen on different ports, RsHTTPPort1 and RsHTTPPort2. (config)# server real <RsBE1_name> <RsBE1_IP> port <RsBEPort1> port <RsBESSLPort1> (config)# server real <RsBE2_name> <RsBE2_IP> port <RsBEPort2> port <RsBESSLPort2> For the integration setup in lab, the two BackEnd server instances were simulated on a single server and they were configured to listen on two ports, RsBEPort1 and RsBEPort2. Copyright Foundry Networks Page 5

6 3) Define the Virtual Servers Configure the virtual servers for Portal and BackEnd applications and associate (or bind) them to their respective real servers using the following commands: (config)# server virtual <VsPortal_name> <VsPortal_IP> port <VsHTTPSPort> bind <VsHTTPSPort> <RsPortal1_name> <RsHTTPPort1> <RsPortal2_name> <RsHTTPPort2> (config)# server virtual <VsBE_name> <VsBE_IP> port <VsBEPort> bind <VsBEPort> <RsBE1_name> <RsBEPort1> <RsBE2_name> <RsBEPort2> 4) Optionally, change the default load balancing predictor method The default predictor method is least connections i.e. by default, the ServerIron switch selects the real server that has least number of connections for handling subsequent client request. One can optionally employ different predictor method. (config)# server predictor round-robin 5) Configure the real server port characteristics Configure port profiles and define real server ports as TCP ports using the following commands: (config)# server port <RsHTTPPort1> (config)# server port <RsHTTPPort2> (config)# server port <RsBEPort1> (config)# server port <RsBEPort2> (config)# server port <RsBESSLPort1> (config)# server port <RsBESSLPort2> 6) Define SSL traffic profile and associate it with the virtual server Prior to defining SSL traffic profile, upload SSL certificate and key to ServerIron. The certificate may be self signed or obtained from a third party certificate authority. This certificate is presented to the clients when they connect to the virtual server IP through secure SSL channel. (config)# ssl profile <sslprofile_name> keypair-file <keyfile_name> certificate-file <certfile_name> cipher-suite <select_cipher-suites> (config)# virtual <VsPortal_name> <VsPortal_IP> port <VsHTTPSPort> ssl-terminate <sslprofile_name> 7) Configure client connection persistence using cookie insert and switching Configure ServerIron to do a search for a pre-defined cookie name inside each client request. If the cookie is present then extract cookie value and persist to real server that is identified using this cookie value. If the cookie is not present then insert cookie with name as ServerID and value as server-id of the real server that processed the request in the server response message going to the Copyright Foundry Networks Page 6

7 client. This cookie string and value are then used for persistence of a client connection to a given real server instance. (config)# csw-rule "<rule_name> header "cookie" pattern "ServerID=" (config)# csw-policy "<policy_name>" match "<rule_name>" persist offset 0 length <serverid_length> group-or-server-id default forward <RsPortalGp-id#> default rewrite insert-cookie ServerID (config)# server virtual <VsPortal_name> <VsPortal_IP> port VsHTTPSPort port VsHTTPSPort cookie-name "ServerID" port VsHTTPSPort csw-policy "<policy_name>" port VsHTTPSPort csw 8) Enable client side keepalives This allows ServerIron to handle multiple http transactions (http v1.1) over single client side connection while doing layer 7 switching. Enable client keepalive using the following command: (config)# server virtual <VsPortal_name> <VsPortal_IP> port VsHTTPSPort keep-alive 9) Optionally, enable source address NAT if required This step is optional. Source address NAT is required when the ServerIron switch is connected onearm to the network infrastructure. This is to ensure that the response traffic passes through the ServerIron switch. On the other hand, this step isn t required when real servers are placed inline with the ServerIron switch. (config)# server source-nat (config)# server source-ip <IP-address1> <subnet-mask> <default-gateway> (config)# server source-ip <IP-address2> <subnet-mask> <default-gateway> for-ssl Note: If High Availability (HA) is configured using two ServerIron switches then define source-natip addresses instead of source-ip addresses in this step. The definition of source-nat-ip address along with port-range keyword allows sharing of the same IP address between two peer units by dividing their allowable port ranges into two halves. 10) Configure L4 SLB for Composite Application Servers The Composite Application Servers may reside at remote branch office or available locally. For the integration lab, these servers were hosted at remote branch office using separate ServerIron unit. The configuration steps for this unit are very similar. Configure Composite real servers, Composite virtual servers, define port characteristics, and specify port bindings. Optionally, enable source address NAT if applicable and modify load balancing predictor method. (config)# server real <RsComp1_name> <RsComp1_IP> port <RsCompPort1> port <RsCompSSLPort1> (config)# server real <RsComp2_name> <RsComp2_IP> port <RsCompPort2> port <RsCompSSLPort2> (config)# server virtual <VsComp_name> <VsComp_IP> port <VsCompPort> bind <VsCompPort> <RsComp1_name> <RsCompPort1> <RsComp2_name> <RsCompPort2> Copyright Foundry Networks Page 7

8 (config)# server port <RsCompPort1> (config)# server port <RsCompPort2> (config)# server port <RsCompSSLPort1> (config)# server port <RsCompSSLPort2> Tcp (config)# server source-nat (config)# server source-ip <IP-address1> <subnet-mask> <default-gateway> (config)# server predictor round-robin Lab Configuration The following port numbers were used while configuring the ServerIron switch in the integration lab. Define additional ports if necessary. Port Value <RsHTTPPort1> <RsHTTPPort2> <VsHTTPSPort> 443 (SSL) <RsBEPort1> <RsBESSLPort1> <RsBEPort2> <RsBESSLPort2> <VsBEPort> 1080 <RsCompPort1> <RsCompSSLPort1> <RsCompPort2> <RsCompSSLPort2> <VsCompPort> 1080 Appendix A reflects the running configurations of the two ServerIron units in the integration lab. Additional Design Considerations Foundry-SAP Solution High Availability For building highly available SAP application delivery infrastructure, configure ServerIron application delivery switches in high availability (HA) mode. The two ServerIron switches that are enabled for high availability provide device level redundancy and quick recovery in the event of primary unit failure. Copyright Foundry Networks Page 8

9 Security The Denial of Service (DoS) attack prevention feature when enabled provides attack protection against multi-million TCP SYN attacks per second. ServerIron offers this protection at a very high rate because the feature is implemented using hardware assistance. Global Server Load Balancing (GSLB) As reliance on IP and Web applications for business processes increases, many organizations need to deliver business services from multiple locations for faster delivery, redundancy and scalability. GSLB uses a DNS-based approach to distribute client traffic to multiple locations and offers automatic failover between sites for disaster recovery and multi-site scalability. GSLB is transparent to SAP application implementation and deployment. It can be added as an additional solution to offer redundancy across sites. Copyright Foundry Networks Page 9

10 Appendix A Running Configuration SerevreIron GT-E with Integrated SSL (2BP) ~ As seen on extreme right in Figure 1 above ~ Functions SSL Acceleration, Cookie Insert/Switching for session persistence & load balancing SLB-ServerIronGT E-2#sh runn Building configuration... Current configuration : 2125 bytes ver TD2 module 1 bi-0-port-wsm6-ssl-management-module module 2 bi-jc-16-port-gig-copper-module ssl profile sap keypair-file sap-key certificate-file sap-cert cipher-suite all-cipher-suites server predictor round-robin server port server port server port server port server port server source-nat server source-ip server source-ip for-ssl csw-rule "r1" header "Cookie" pattern "Serverid=" csw-policy "p1" match "r1" persist offset 0 length 4 group-or-server-id default forward 2 default rewrite insert-cookie "Serverid" server real portal port port server-id 1024 port group-id 2 2 port port server-id 1025 Copyright Foundry Networks Page 10

11 port group-id 2 2 server real BE port port port port server virtual portal-vip port ssl port ssl ssl-terminate sap port ssl cookie-name "Serverid" port ssl csw-policy "p1" port ssl csw port ssl keep-alive bind ssl portal portal server virtual BE-vip port 1080 bind 1080 BE BE vlan 1 name DEFAULT-VLAN by port no spanning-tree vlan 2 by port untagged ethe 2/9 to 2/16 no spanning-tree no enable aaa console ip address ip default-gateway telnet server snmp-server web-management interface ethernet 2/1 interface ethernet 2/9 end ServerIron 4G-SSL ~ As seen on extreme left of Figure 1 above ~ Functions L4 load balancing LB-ServerIron 4G#sh runn Building configuration... Current configuration : 1089 bytes ver TI2 Copyright Foundry Networks Page 11

12 no global-stp server predictor round-robin server port server port server port server port server source-nat server source-ip server real composite port port port port server virtual composite-vip port 1080 port ssl sticky bind 1080 composite composite bind ssl composite composite vlan 1 name DEFAULT-VLAN by port no spanning-tree no enable aaa console ip address ip default-gateway telnet server snmp-server web-management interface ethernet 1 end Copyright Foundry Networks Page 12

13 Appendix B Additional Information SAP NetWeaver Foundry ServerIron Application Switches Copyright Foundry Networks Page 13

14 Deploying SAP NetWeaver Infrastructure with Foundry Networks ServerIron July, 2008 Author: Deepak I. Kothari, Product Marketing Manager, L4-7 Products Group, Foundry Networks, Inc. Foundry Networks, Inc. World Headquarters 4980 Great America Parkway, Santa Clara, CA U.S.A. Worldwide Inquiries: Phone: Fax: info@foundrynet.com Web: Foundry Networks, BigIron, EdgeIron, FastIron, IronPoint, IronView IronWare, JetCore, NetIron, ServerIron, SecureIron, Terathon, TurboIron, and the Iron family of marks are trademarks or registered trademarks of Foundry Networks, Inc. in United States and other countries. All other trademarks used in this document are the properties of their respective owners. Although Foundry has attempted to provide accurate information in these materials, Foundry assumes no legal responsibility for the accuracy or completeness of the information. More specific information is available on request from Foundry. Please note that Foundry's product information does not constitute or contain any guarantee, warranty or legally binding representation, unless expressly identified as such in a duly signed writing. Copyright 2008 Foundry Networks, Inc. All rights reserved. Copyright Foundry Networks Page 14