close

Вход

Забыли?

вход по аккаунту

?

Appdirector Radware solution guide

код для вставкиСкачать
 North America Radware Inc. 575 Corporate Dr. Suite 205
Mahwah, NJ 07430 Tel 888 234 5763 International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8666 North America Radware Inc. 575 Corporate Dr. Suite 205
Mahwah, NJ 07430 Tel 888 234 5763 International Radware Ltd. 22 Raoul Wallenberg St. Tel Aviv 69710, Israel Tel 972 3 766 8666 Technical Solution Guide AppDirector 19 March 2007 Revision 1.03
Table of Contents Introduction
........................................................................................................................3
Step 1: Defining the Required Type of Solution
.................................................................4
Step 2: Before Installation
..................................................................................................6
Step 3: Pre-Installation Tasks
............................................................................................9
Step 4: Recommended Scenarios
....................................................................................22
Scenario 1: AppDirector as a Router in the Datacenter
................................................23
Scenario 2: AppDirector in One Leg Implementation (One Arm)
..................................30
Scenario 3: AppDirector in Local Triangulation Mode
..................................................37
Scenario 4: AppDirector with Local and Remote Servers
.............................................45
Scenario 5: AppDirector with AppXcel
..........................................................................53
Scenario 6: AppDirector with AppXcel – Backend SSL Enabled
..................................69
Scenario 7: Global Traffic Management with DNS/HTTP Redirection
..........................85
Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter
..........................................110
Step #5: Management Settings
......................................................................................118
Step #6: Configuring Redundancy in the AppDirector using VRRP
...............................120
Step #7: Advanced Content Switching – Layer 7
...........................................................129
Step #8: Client NAT Settings
.........................................................................................132
Introductio
n
Introduction This Technical Solution Guide summarizes the official recommended scenarios for installing the AppDirector in your network in order to help you select the best installation scenario for your application requirements. In this guide you will find the most commonly used AppDirector installation scenarios. According to your application type, you are directed towards the best scenario. The scenarios include: Detailed descriptions of the advantages and limitations Step-by-step procedures Reference network diagrams Performing an installation in keeping with the recommended installation scenarios presented in this guide will ensure a fast and smooth installation process and easier troubleshooting in the future. Note: Use of installation scenarios that are not covered in this guide can lead to unpredictable performance and functionality results. Applicable Product Versions This Technical Solution Guide is applicable for the following product versions: Product Hardware Platform Software Version AppDirector AD1000/256MB RAM
1.00.01 AppXcel AppXcel 4000 1.00.01 APSolute Insite 2.02.03 Document Conventions This guide uses the following documentation conventions: Command paths in the GUI are presented as: File > Save As. Screen displays may differ slightly from those included in this guide, depending on the system you use. For example, Microsoft Windows screens are different from X-Windows screens. The following icons are used throughout the document: Note: Important information that requires additional attention. To Statement: Detailed operating instructions that explain the step-by-step configuration process. 3 Step 1: Defining the Required Type of Solution Important Note: Select from the following list of applications the scenario that best fits your requirements. The scenarios are described in detail in Step 4: Recommended Scenarios, page 22. In case more than one scenario is recommended, the scenario with the rating in red stars ( ) should be used. AFE (Application Front End) Services for CRM Applications A CRM application in your network requires traffic priority. You cannot let other services on the same AppDirector (AD) consume unlimited bandwidth and slow the CRM communication. Another important requirement for CRM is session persistency for its long sessions. This cannot be achieved with regular L3 session tracking (the Client Table) as the source IP addresses of the clients might be NATed by your internal firewall. The recommended solutions for AFE services for CRM applications are provided in Scenario 1 and Scenario 2. AFE Services for Web Applications Web applications are application front-end services. Most of these services are exposed to Internet users and thus need to be highly secured. Different users might need to access different services according to their language, location and type of service. The recommended solutions for AFE services for Web applications are provided in Scenario 1 and Scenario 2. AFE Services for Database Applications Database servers are necessary for the application to be available. Without them the application can be available but data cannot be provided to the users or collected from them. Proper application health monitoring configuration allows the application to go down at the time the DB server is not in service. The recommended solutions for database servers are provided in Scenario 1 and Scenario 2. AFE Services for Streaming Applications Streaming applications require narrow bandwidth for the request but very wide bandwidth for the server's response (the streaming data). In order to gain more bandwidth capabilities the AppDirector can be installed in a way that the response will pass directly from the servers to the access router bypassing AppDirector. Theoretically there is no bandwidth limitation for this kind of setup. The recommended solution for AFE services for streaming applications is provided in Scenario 3. AFE Services for Global Sites Global sites have local resources and remote resources acting together as one. Clients who access the service need to receive the content from the best available site, which depends on proximity information as well as load sharing decisions made by the AppDirector. The recommended solution for AFE services for global sites is provided in Scenario 4. 4 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 1: Defini
n
g
the Req
u
ir
ed
T
y
pe of Sol
u
ti
on AFE Services with AppXcel AppXcel is Radware's application acceleration device. Combining AppXcel with AppDirector provide high availability and load sharing for the application servers together with the AppXcel's devices. Such a solution enables taking L7 decisions for HTTPS traffic as well. The recommended solutions for AFE services with AppXcel are provided in Scenario 5 and Scenario 6. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 5 Step 2: Before Installation Before installation, Radware recommends you take into consideration the following: 1. Physical Connectivity Concerns A Radware device acts as a switch. Crossed cables should be used between switches and straight cables should be used for connecting other network hosts. Make sure you use the right type of cable as stated. Some platforms support the Auto sensing feature (MDIX) and can operate with any type of cable, however this feature is disabled once you disable Auto negotiation. Only GBICs that have been tested and approved by Radware can be used. For an updated list, refer to: http://www.radware.com/content/support/faq/gigabitethernetandgibcsupport.
asp
. Auto negotiation is activated by default. In most cases, this is the preferred option. Verify that it is activated on the other side as well. Note: Disabling Auto negotiation disables the cable type Auto sensing feature (MDIX) as well (available on AS1v2, AS2, AS3 and AS4). Optical cables are not provided by Radware and need to be purchased separately. Some devices use SC connectivity as well as LC. Make sure you have the appropriate cable. The copper cables that Radware provides are intended for management only and should not be used for other types of traffic. CAT5 certified copper cables must be used. When connecting to network switches and working with Radware's proprietary redundancy protocol, make sure you disable Spanning Tree or at least enable Port Fast on the relevant ports (on the switch). It is also possible to set the Spanning Tree to operate in fast learning mode on the relevant ports. Radware Application Switches do not support the Spanning Tree protocol. 2. IP Allocation Concerns Make sure you have the IP addresses allocated and defined in your network for the AppDirector's interfaces, new servers, NAT IP addresses (if activated on the AppDirector), DNS IP addresses (if activated on the AppDirector) and for the redundant AppDirector as well. Pay particular attention to the Local Triangulation implementation and VLANs (explained in this document) where the IP addresses of the servers should be public routable IP addresses. 6 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 2: Before Installati
on 3. Management Concerns Install the Radware management software – APSolute Insite – on the management computer. There are two versions of this software. One is for the SQL database for use with Radware APSolute OS enhancement (and for DefensePro) and the other is for regular management purpose. The software can be downloaded from the Radware website: http://www.radware.com/content/support/software/config-
configinsite-matrix/default.asp
. Radware management uses SNMP communication running on UDP port 161. Make sure this communication port is not blocked by your firewall. Configuration upload/download action uses TFTP protocol. Ensure that TFTP is not blocked by your firewall and the management station is not NATed toward the Radware device. As TFTP traffic is initiated from the Radware device to the management station, a relevant firewall rule should be configured. UDP ports 162 and 69 are used for TFTP. Radware devices can also use HTTP, HTTPS, Telnet, and SSH for management. In case you choose to activate one of the above (see Step #5: Management Settings) verify that they are not blocked by your firewall. Traffic direction is from the management system to the Radware device. Radware devices have a console port for terminal communication, which uses an RS232 cable (provided by Radware). (See Scenario 3: AppDirector in Local Triangulation Mode.) 4. Latest Software Versions Radware classifies the software versions according to the following statuses: Status Description Shipping GA The default shipping version on new product orders. GA (General Availability) A general availability version that has completed full QA and beta processes and is considered a stable version. LA (Limited Availability)
A limited availability version that includes new features, has completed QA and beta processes, but currently has limited deployment in the field. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 7 The software is also classified according to the following types: Status Description MY (Maintenance Version) Radware is committed to providing 12 months notice before the end of maintenance for this software. FV (Features Version) Radware is committed to providing three months advanced notice before the end of maintenance for this software. Issues in this version may be fixed in a later feature version. CV (Customer Version) Specially developed software that has custom features or specific fixes for unique customer environments or applications. For ongoing maintenance, it is required to upgrade to the next version where the specific development is integrated. Note: It is recommended that you verify that the software version of the Radware device you are about to install is the GA (General Availability) or Shipping GA version. An updated list of software versions and their status can be found at: http://www.radware.com/content/support/software/statusmatrix/default.asp?_v=statu
smatrix
. 5. Technical Support
Radware offers its Certainty Support Program, a suite of technical support packages in various levels. You can view the complete set of programs at: . http://www.radware.com/content/support/default.asp
Once you purchased the relevant Certainty Support package you can either contact Radware via email (
support@radware.com
) or via the phone using our worldwide toll free numbers. An updated list is available at: http://www.radware.com/content/support/supportprogram/contact.asp
. Additional information about the Radware Certainty Support program is available at: http://www.radware.com/content/document.asp?_v=about&document=2774
8 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks Step 3: Pre-Installation Tasks This section describes the step-by-step configuration that it is common to the various scenarios. You can adjust it to meet your specific needs by using your own network's IP addresses. To configure the AppDirector: 1. Connect to the AppDirector using a serial cable. 2. In the COM3 Properties window, set your terminal emulation program parameters according to the explanations provided: Bits per second: 19200 Data bits: 8 Parity: None Stop bits: 1 Flow control: None 3. Power on the AppDirector. A start up configuration screen appears. 4. Fill in the requested information (IP, Subnet Mask, Physical interface, Default Gateway) and click Enter for the rest of the settings. Once you have provided the requested information, the device is rebooted. If the start up configuration screen does not appear, wait for the following prompt: AppDirector > AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 9 5. Log in with the default username (radware) and password (radware): AppDirector >login User: radware Password: ******* If you already set the IP, Subnet mask and Physical Interface in step 4, skip the next step. 6. Assign a management address to Interface #1: AppDirector# net ip-interface create 10.10.10.10 255.255.255.0 1 The result should be: Created successfully IP Address 10.10.10.10 If Number (-i ): 1 Network Mask (-m ): 255.255.255.0 Fwd Broadcast (-f ): enable Broadcast Addr (-ba ): ONE FILL VlanTag (-v ): 0 7. Make sure that the management computer is on the same network segment as the AppDirector. 8. On your desktop, open APSolute Insite by clicking the shortcut icon. The Login window appears. 9. In the Login window, type in the username and the password (default is: radware/radware) and click Ok. The main window appears. 10
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks 10. To connect to your AppDirector, in the main window, click Add > Add Radware Device > AppDirector. An AppDirector object appears in the main window. 11. To connect to the device, expand the icon view and double-click the AppDirector icon. The Connect to Device window appears. 12. In the Connect to Device window, type in the IP address (as configured in dialog wizard via the console) and the community. The default community of Radware products is public. 13. Click Ok and wait until you are connected to AppDirector. The AppDirector icon appears in the main window. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 11 14. Once the device is connected, adjust the device global settings for your network needs. Double-click the AppDirector icon. The Setup window appears. 15. In the Setup window, select Global > Client Table Settings. The default value for the Client Table is 65536 entries. 12
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks 16. To tune the Client Table, click Edit Settings. The Client Table Settings window appears. This table stores an entry for each active TCP session. You need to calculate the number of required entries. The recommended setting for up to 5,000 concurrent users is 50,000 entries; this is based on the fact that each entry generates five simultaneous TCP sessions that last two minutes each. Notes: Each change in the device's tuning table requires a system reboot, however the best way to know how many sessions you have for your application is to tune it for a higher value (200,000) and check how many entries AppDirector stores during peak time. Once you have this information, you can better tune the device for your numbers and reboot it later during the next available maintenance window. For a list of the tables that can be tuned and their maximum values, refer to the AppDirector Tuning Table
paper. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 13 17. In the Client Table Settings window, click Ok. 18. Then click Ok again to reboot the device. 19. After the device reboots, close all open windows and double-click the AppDirector icon. The Setup window appears. Note: If you are configuring the AD according to Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter, skip steps 20 – 27 and follow step 28. 20. In the Setup window, click Add. The Interface window appears. 21. In the Interface window, configure the physical interfaces as required. Each interface must have at least an IP address, a Subnet Mask, and a physical port number. Then click Ok to return to the Setup window. Repeat this step for other IP addresses that should be configured in this scenario or according to your network needs. 22. In the Setup window, click Networking. The Networking dropdown list appears. From the Networking dropdown list, select Routing Table. The Routing Table window appears. 14
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks 23. In the Routing Table window, click Add. The Edit Physical Route window appears. 24. In the Edit Physical Route window, type the routing configuration. For each entry, you should set at least the destination network, Network Mask, Net Hop (which should belong to one of the previously configured networks), and a physical port on the device where the traffic should be sent. Note: Routing can be configured only on interfaces that are active (i.e., a network cable is connected and the state is Up). 25. Click Ok to return to the Routing Table window. Repeat this action for each routing entry that you need to add. 26. In addition, a default Gateway must be configured and must point to the access router or the firewall as the next hop router. In the Edit Physical Route window for the gateway, set the following parameters according to the explanations provided: Destination IP Address 0.0.0.0 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 15 Subnet Mask 0.0.0.0 Next Hop The IP address of the access router or firewall IF Number The relevant IF number. 27. Click Ok twice to close the windows. Note: Follow steps 28-31 only if you are configuring the AD according to Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter. 28. In the Setup window, click Networking. The Networking dropdown list appears. From the Networking dropdown list, select VLAN. 16
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks The Virtual LAN window appears. 29. Highlight the row labeled 100001. This is a pre defined VLAN. Assign ports to this VLAN in the relevant section of this screen. The ports that should be assigned are the ports that should be member in this VLAN. 30. Click Update to confirm the changes and OK to close this window. 31. Repeat step 28-30 in case you need to configure more VLANs. If you wish to use other VLAN then the pre defined one click Add in the Virtual LAN window and create a new VLAN. 32. In the Setup window, click Add. The Interface window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 17 33. In the Interface window, configure the physical interfaces as requested. Each interface must have at least an IP address, a Subnet Mask, and a VLAN number as the 'If Num' (usually its 100001). Click Ok to return to the Set-Up window. 34. In the Setup window, click Networking. The Networking dropdown list appears. From the Networking dropdown list, select Routing Table. The Routing Table window appears. 18
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks 35. In the Routing Table window, click Add. The Edit Physical Route window appears. 36. In the Edit Physical Route window, type the routing configuration. For each entry, you should set at least the destination network, Network Mask, Net Hop (which should belong to one of the previously configured networks), and a VLAN port on the device where the traffic should be sent. Note: Routing can be configured only on interfaces that are active (a network cable is connected and the state is Up). 37. Click Ok to return to the Routing Table window. Repeat this action for each routing entry that you need to add. 38. In addition, a default Gateway must be configured and must point to the access router or the firewall as the next hop router. In the Edit Physical Route window for the gateway, set the following parameters according to the explanations provided: DESTINATION IP ADDRESS 0.0.0.0 SUBNET MASK 0.0.0.0 NEXT HOP THE IP ADDRESS OF THE ACCESS ROUTER OR FIREWALL. IF NUMBER THE RELEVANT VLAN NUMBER. 39. Click Ok twice to close the windows. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 19 Traffic Settings Pane - General Explanation The farm settings are configured in the Traffic Settings pane of the farm window. The key traffic parameters are described in Table 1. Table 1: Key Traffic Settings Parameter Description Dispatch Method The algorithm used to split traffic between servers, which can be cyclic, according to the amount of traffic or to the number of sessions. Other options include Hashing, the result of SNMP query to the servers (like CPU Usage), or the response time of the server to the AppDirector's health check traffic. Session Mode The way AppDirector adds entries to its Client Table. Regular: L3 load balancing (every source IP is written once and is attached to one server). Entry Per Session: L3 load balancing as in the Regular mode, but entries are written in the Client Table according to source IP address and source port (L4). This is recommended in case of servers that exist in more than one farm and to avoid system confusion. Server per Session: L4 load balancing where every session with a different source IP and source port is written into the Client Table and attached to a different server. This mode is used mainly for L7 content switching according to information from the application (cookies, URLs, and so on). Remove on Session End: Equivalent to Entry per Session but adds the option to remove the entries from the Client Table not only after the Client Aging Time has expired but also when the session ends (a FIN or RST packet that belongs to that session arrives from either the client or the server). For additional information on the Session mode, refer to the AppDirector User Guide
. Remove Entry in Select Server: Equivalent to Server per Session but adds the option to remove the entries from the Client Table not only after the Client Aging Time expired but also when the session ends (a FIN or RST packet that belongs to that session arrives from either the client or the server). For additional information on the Session mode, refer to the AppDirector User Guide
. 20
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 3: Pre-Installation T
a
sks Parameter Description Client Aging Time This is the period AppDirector keeps an entry of a session in the Client Table when there is no activity. AppDirector resets this timer each time there is TCP activity on the session. The default value is 60 seconds; however, Radware guidelines for the best tuning value are to determine your application timeout and add a minute to that value. This way persistency is maintained for your application's session. The value should be written in seconds, not minutes. Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on a global AppDirector, and so on. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 21 Step 4: Recommended Scenarios This section describes the most commonly used scenarios for installing the AppDirector in your network, including the step-by-step procedures for their implementation. The recommended scenarios include: Scenario 1: AppDirector as a Router in the Datacenter, page 23 Scenario 2: AppDirector in One Leg Implementation (One Arm), page 30 Scenario 3: AppDirector in Local Triangulation Mode, page 37 Scenario 4: AppDirector with Local and Remote Servers, page 45 Scenario 5: AppDirector with AppXcel, page 53 Scenario 6: AppDirector with AppXcel – Backend SSL Enabled, page 69 Scenario 7: Global Traffic Management with DNS/HTTP Redirection, page 85 Performing an installation in keeping with the recommended installation scenarios will ensure a fast and smooth installation process and easier troubleshooting in the future. Important Note: Refer to Step 1 for guidelines on selecting the scenario that best fits your requirements, according to your application type In cases where more than one scenario is recommended, the scenario rating accompanied by red stars ( ) should be used. 22
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Scenario 1: AppDirector as a Router in the Datacenter Scenario Description This is one of the most commonly used scenarios for installing AppDirector. All traffic to the servers and back passes through AppDirector, therefore traffic load balancing and high availability traffic shaping (QOS) and security policy enforcement (IPS) can be applied. In this scenario, the external interface of AppDirector has a public IP or one that is NATed by the Firewall/Router on top of it and the internal interface has an internal IP from the same segment as the servers’ segment. This way AppDirector acts as a router between the servers and the external segment. Traffic that is not destined to the AppDirector VIPs is routed towards its destination according to the Routing Table information. This scenario can be used for L3/L4 content switching as well as L7 content switching. This scenario should not be used for servers that work with loopback adapters that reply directly to the clients. Advantages The advantages of this scenario include the following: Simple IP management. Internal segment does not use public IPs. No need for coordination with the ISP, you can add as many servers as you want with no IP considerations. Security is enhanced as the servers are located in a different IP segment protected by the AppDirector. QOS is available for AppDirector based on application data (like HTTP cookies). Limitations The limitations of this scenario include the following: Changes in the physical network. Installing AppDirector in such a scenario requires cabling changes and routing changes. Direct access to the servers and from the servers is done via AppDirector. This should be included in the overall traffic calculations that AppDirector should process (for example, database synchronization, software auto updates, and so on). AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 23 Suggested Physical Implementation Figure 1 illustrates a suggested physical implementation of the AppDirector as a Router. A
P
S
o
l
u
t
e
A
p
p
l
i
c
a
t
i
o
n
D
e
l
i
v
e
r
y
A
p
p
D
i
r
e
c
t
o
r
G
1
G
2
G
3
G
4
G
5
F
9
F
1
0
F
1
1
F
1
2
F
1
F
2
F
3
F
4
F
1
3
F
1
4
F
1
5
F
1
6
F
5
F
6
F
7
F
8
A
P
S
o
l
u
t
e
A
p
p
l
i
c
a
t
i
o
n
D
e
l
i
v
e
r
y
A
p
p
D
i
r
e
c
t
o
r
G
1
G
2
G
3
G
4
G
5
F
9
F
1
0
F
1
1
F
1
2
F
1
F
2
F
3
F
4
F
1
3
F
1
4
F
1
5
F
1
6
F
5
F
6
F
7
F
8
Figure 1: AppDirector as a Router in the Datacenter Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks. After completing the pre-installation procedure, you are ready to configure the server farms. To configure the server farms: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. 24
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 2. In the Traffic Redirection window, select Farm > Add. The Farm window appears. 3. In the Farm window, type the farm name in the Farm Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 25 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 6. In the Server Address text box, type the server's IP address. Note: The servers should be located in the AppDirector's local segment. If not, you need to configure a relevant entry under the Routing Table. Other parameters should retain their default value. Click the Help button or refer to the AppDirector User Guide
for a detailed explanation about the use of these settings. 7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the additional servers as required. 26
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. 10. Click Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include; AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 27 Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point, the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms. 12. In the Traffic Redirection window, click L4 Policies. The L4 Policies pane appears. 13. In the L4 Policies pane, click Add. The L4 Policies window appears. 14. In the L4 Policies window, in the VIP Address text box, type the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set now. 15. Click Add to configure the policies. The Add L4 Policy window appears: 28
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios For this example (HTTP servers), the L4 Protocol should be TCP, the Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide
. 16. Click Ok to confirm and return to the L4 Policies window. 17. In case you have other farms and services, configure the VIPs and policies for them in this window as well. 18. Upon completion, click Ok twice to close the windows and return to the APSolute Insite main windows. 19. To configure the device management settings, refer to Step #5: Management Settings, page 119. 20. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. 21. To configure advanced Layer 7 parameters, refer to Step #7: Advanced Content Switching – Layer 7, page 129 22. To configure the NAT parameters, refer to Step #8: Client NAT Settings, page 132 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 29 Scenario 2: AppDirector in One Leg Implementation (One Arm) Scenario Description This scenario is recommended when minimum changes in the network are a mandatory condition. AppDirector is plugged into the backbone switch with one physical interface. The main changes are L3 routing changes that take place on the servers themselves. AppDirector, the servers and the gateway (Router/Firewall) can be located on the same L2 segment. In case this is not possible, AppDirector can have two IP addresses configured on the same physical interface: a router between the external network (the access router or the Firewall segment) and the internal network (the servers segment). In case the servers are located on another segment, their default gateway should be AppDirector so that the response traffic passes through AppDirector and is NATed to the VIP. In case the servers are on the same network segment as the access router or the Firewall and their default gateway cannot be changed, AppDirector should NAT the sessions going to the servers in order to force the response to pass via AppDirector and not be sent directly to the clients. This feature is known as Client NAT. Advantages The advantages of this scenario include: The changes in the network are minor. It is possible to perform fast fallback with no physical changes in the network. Management access to the servers is easy as they are directly accessible. The AppDirector is not required for this task. Limitations The limitations of this scenario include: Routing changes are required on the servers, however the default gateway is not the network's gateway but AppDirector. It is common to forget this fact when performing maintenance tasks on the servers. In case one segment is used (the same segment for the servers and the access router/Firewall), the servers are not hidden with an internal IP range behind the AppDirector as in the routing scenario. This might be considered a security threat. 30
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Suggested Physical Implementation Figure 2 illustrates a suggested physical implementation of the AppDirector in One Leg implementation in this scenario. APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
Figure 2: AppDirector in One Leg Implementation AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 31 Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks. After completing the pre-installation procedure, you are ready to configure the server farms. To configure the server farms: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, select Farms > Add. The Farm window appears. 32
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 3. In the Farm window, enter the farm name. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 6. In the Server Address text box, type the server's IP address. Note: The servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table. Other settings should not be changed. Click the Help button or refer to the AppDirector User
Guide
for a detailed explanation about these settings. 7. Click Ok to confirm a
nd return to the Traffic Redirection window. Repeat the above steps for the other servers you want to add. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 33 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. 10. In the Farm window, select Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include a 34
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point, the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms. 12. In the Traffic Redirection window, select L4 Policies. The L4 Policies pane appears. In the L4 Policies window, you need to set the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set. 13. Click Add to configure the policies. The Add L4 Policy window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 35 For this example (HTTP servers), the L4 Protocol should be TCP, the Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide
. 14. Click Ok to confirm and return to the L4 Policies window. 15. In case you have other farms and services, configure the VIPs and policies for them in the L4 Policies window 16. Upon completion, click Ok twice to close the windows and return to the APSolute Insite main window. 17. To configure the device management settings, refer to Step #5: Management Settings, page 119. 18. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. 19. To configure advanced Layer 7 parameters, refer to Step #7: Advanced Content Switching – Layer 7, page 129 20. To configure the NAT parameters, refer to Step #8: Client NAT Settings, page 132 36
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Scenario 3: AppDirector in Local Triangulation Mode Scenario Description This scenario is recommended for streaming applications and when minimum changes in the network are a mandatory condition. AppDirector will be connected via one physical interface to the backbone switch, and the main changes, which are L3 routing changes, will be implemented on the servers themselves. Traffic that reaches AppDirector's VIP is forwarded to the selected server where the only change in the packet is the destination MAC. The server responds directly to the client via the gateway without passing through AppDirector. The servers should have a loopback interface installed and be configured with AppDirector's VIP. Advantages The advantages of this scenario include the following: The changes in the network are minor. The effective throughput that can be gained by this architecture is higher than the first two scenarios. As the traffic from the servers to the clients (the server's response) is routed directly to the gateway, the throughput is the network's throughput. This is commonly used for streaming services where the client's request is small but the server's response is highly bandwidth consumption. Limitations The limitations of this scenario include the following: No L7 content switching is possible due to the fact that the servers’ response to the clients does not pass through the AppDirector. This prevents AppDirector terminating the TCP session between the client and the server that is required for the L7 inspection. No QOS or application security is possible for the outbound traffic due to the fact that the servers’ response to the clients does not pass through AppDirector. The servers must be configured on the same broadcast domain (L2 subnet) of AppDirector. Servers cannot be members of two farms at the same time. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 37 Suggested Physical Implementation Figure 3 illustrates a suggested physical implementation of the AppDirector in Local Triangulation mode. APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
Figure 3: AppDirector in Local Triangulation Mode 38
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks. After completing the pre-installation procedure, you are ready to configure the server farms. To configure the server farms: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, click Add. The Farm window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 39 3. In the Farm window, enter the farm name. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 6. In the Server Address text box, type the server's IP address. Notes: The servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table. Server type should be set to: "local Triangulation". Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide
for a detailed explanation of these settings. Each physical server should have a Loopback adaptor installed. For assistance with such an installation, refer to the AppDirector User Guide
. 7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the other servers you want to add. 40
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppDirector Global, and so on. Before enabling any of the advanced features, make certain they are applicable in such a Local Triangulation scenario. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 41 10. In the Farm window, select Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include; Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms. 42
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 12. In the Traffic Redirection window, click L4 Policies > Add. The L4 Policies window appears. In the L4 Policies window, you need to enter the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set. 13. In the L4 Policies window, click Add to configure the policies. The Add L4 Policy window appears. For this example (HTTP servers), the L4 Protocol should be TCP, the Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 43 role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide
. 14. Click Ok to confirm and to return to the L4 Policies window. In case you have other farms and services, configure the VIPs and policies for them in the L4 Policies window. When finished, click Ok twice to close the windows and return to APSolute Insite main window. 15. To configure the device management settings, refer to Step #5: Management Settings, page 119. 16. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. 44
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Scenario 4: AppDirector with Local and Remote Servers Scenario Description This scenario can be used when part of the application resources are located remotely at another data center where only L3 TCP connection is available (ISP Internet link or leased line for example). This kind of architecture allows you to better utilize local and remote resources while services to the users are provided transparently. Advantages The advantages of this scenario include the following: AppDirector can share the load among servers taking into consideration the traffic load on each site. AppDirector can utilize the local datacenter only and use the remote data enter only as a backup in case all local resources are unavailable. After initial redirection, the connection between clients and remote servers is established directly. AppDirector is not in between therefore the sessions are not subjected to multiple network hops. Limitations The limitations of this scenario include the following: Partial QoS or application security is possible due to the fact that sessions that are redirected to remote servers do not pass through AppDirector. As redirection is done via HTTP code (HTTP 302) or via DNS service, an application that does not use HTTP or DNS cannot be configured with global servers (unless you use the Global Triangulation architecture mentioned in the AppDirector User Gui
d
e
). Important Note: This scenario can be configured only when using the AppDirector Global operation license. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 45 Suggested Physical Implementation Figure 4 illustrates a suggested physical implementation of the AppDirector with local and remote servers. APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
Figure 4: AppDirector with Local and Remote Servers 46
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Step-by-Step Configuration Description Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9. To configure the server farms: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 47 2. In the Traffic Redirection window, click Farms > Add. The Farm window appears. 3. In the Farm window, enter the farm name. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. 48
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 6. In the Server Address text box, type the server's IP. Notes: In case this is the remote server, change the server Type to: "Remote Server". The local servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table. Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide
for a detailed explanation of these settings. 7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for any other servers you want to add. 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppDirector Global, and so on. Before enabling any of the advanced features, make certain they are applicable in such a Local Triangulation scenario. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 49 10. In the Farm window, select Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include; Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms. 12. Click L4 Policies > Add. The L4 Policies window appears. 50
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 13. In the L4 Policies window, in the VIP Address text box, type the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set. 14. Click Add to configure the policies. The Add L4 Policy window appears. For this example (HTTP servers), the L4 Protocol should be TCP, Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide
. 15. Click Ok to confirm and to return to the L4 Policies window. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 51 16. In the L4 Policies window, configure the VIPs and policies for any other farms and services as required. 17. When complete, click Ok twice to return to APSolute Insite main window. 18. To configure the device management settings, refer to Step #5: Management Settings, page 119. 19. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. 20. To configure the NAT parameters, refer to Step #8: Client NAT Settings, page 132 52
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Scenario 5: AppDirector with AppXcel Scenario Description SSL is a heavy task for the application servers. The amount of clients they can serve with SSL is much lower than the amount of clients they can serve without SSL. This scenario should be used when you plan to integrate Radware's AppXcel (AX) with AppDirector or into an existing AppDirector setup. AppXcel is an application acceleration device that enhances the performance of HTTP, HTTPS and other services that run over SSL. Using it as an integrated appliance in the AppDirector setup provides high availability and load sharing of AppXcel's resources. Using AppXcel for SSL Offloading Traffic that reaches the SSL VIP is not directed to the SSL server but is redirected to the AppXcel farm that contains AppXcel devices. An SSL session is established between the AppXcel and the client via AppDirector. SSL is decrypted by the AppXcel and a clear data session is established between the AppXcel and the application servers' farm through AppDirector. In this manner, the clients use SSL to communicate with the datacenter while, in order to enhance performance, the application servers use clear text and do not use SSL. Using AppXcel for HTTP Compression Traffic that reaches the servers VIP is not directed to the servers but instead, is redirected to the AppXcel farm. After establishing a TCP session between the client and the AppXcel, the AppXcel initiates a TCP session with the application server through AppDirector. The external session (Client <-> AX) uses content compression algorithms (like GZIP or Deflate) to make data transfer more efficient thus reducing the amount of data that needs to be transferred. Advantages The advantages of this scenario include the following: High availability is gained not only for the application servers but to the AppXcel devices as well. L7 content switching decisions can be made for HTTPS traffic after it is decrypted by the AppXcel. Application security policies can be enforced on the traffic that was encrypted by the AppXcel, so that SSL attacks can be detected. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 53 Suggested Physical Implementation Figure 5 illustrates a suggested physical implementation of the AppDirector with AppXcel. APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
PWR OK
SYS OK
SSL
RESET
ACT
OK
AppXcelAPSolute Application Delivery
SERIAL PORT
FE
LNK/ACT
LAN 2
BY PASS
BYPASS
FE
LNK/ACT
LAN 1
PWR OK
SYS OK
SSL
RESET
ACT
OK
AppXcelAPSolute Application Delivery
SERIAL PORT
FE
LNK/ACT
LAN 2
BY PASS
BYPASS
FE
LNK/ACT
LAN 1
Figure 5: AppDirector with AppXcel 54
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Step-by-Step Configuration Configuration according to this scenario entails configuration of both the AppDirector and AppXcel, as described in the following sections: Configuring AppDirector, below Configuring AppXcel, page 62 Configuring AppDirector Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9. To configure the server farms: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 55 2. In the Traffic Redirection window, click Add. The Farm window appears. 3. In the Farm window, enter the farm name in the Farm Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. 56
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 6. In the Server Address text box, type the server's IP address. Notes: The servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table. Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide
for a detailed explanation of these settings. 7. Click Ok and return to the Traffic Redirection window. Repeat the above steps for any other servers you want to add. 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 57 10. In the Farm window, click Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include a Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown menu. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to close the Farm window to return to the Traffic Redirection window. 12. Click Ok to confirm and return to the Traffic Redirection window. Repeat Steps 2-6 and set another farm for AppXcel devices. 58
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Note: If the application server farm is called "Application1", it is recommended to call this farm "Application1_SSL" for future troubleshooting. Both farms (HTTP and HTTPS) should be set for Entry per Session for the Session mode and have the Application Server Support set to Enable in the SSL Farm. The following window shows the "Application1_SSL" farm settings in the Farm window: 13. Click Ok to confirm and return to the Traffic Redirection window. The next step is to configure a L4 Policy to be used to intercept traffic coming to AppDirector's VIP and direct it to the right farm (either an HTTP or HTTPS farm). AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 59 14. In the Traffic Redirection window, click on L4 Policies. The L4 Policies pane appears. 15. Click Add. The L4 Policies window appears. 16. In the L4 Policies window, in the VIP address text box, type the Public IP address you want to assign to the L4 Policy. This IP address is the destination IP address of the traffic that reaches AppDirector and should be intercepted (the application's VIP address). 60
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 17. Click Add to create the interception policy. The Add L4 Policy window appears. 18. In the Add L4 Policy window, configure the traffic flow of each Layer 4 protocol. HTTP should be linked to the Application1 farm and HTTPS to the Application1_SSL farm. You need to enter the parameters twice (once each L4 protocol). 19. Click Ok to accept your preferences. The L4 Policies pane displays the complete policy content: 100.100.100.40 is the L4 Policy VIP, while the farms that can be selected according to the L4 protocol are the HTTP (Application1 for this example) and the HTTPS (Application1_SSL) farms: AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 61 20. To configure the device management settings, refer to Step #5: Management Settings, page 119 21. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. 22. To configure the NAT parameters, refer to Step #8: Client NAT Settings, page 132 Configuring AppXcel The process of setting up AppXcel to work according to this scenario is performed in several stages: Configuring AppXcel Networking, below Configuring the AppXcel Security Key and Certificate, page 64 Configuring the Tunnel, page 66 Backing Up the AppXcel Configuration, page 68 Configuring AppXcel Networking In order to use AppXcel in this scenario, you need to first configure its networking settings. To configure AppXcel: 1. Connect to AppXcel using a serial cable. 2. In the COM Properties window, set your terminal emulation program parameters according to the explanations provided: Bits per second: 19200 Data bits: 8 Parity: None Stop bits: 1 Flow control: None 62
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 3. Boot the AppXcel and wait for the login prompt: Radware AppXcel Version 1.00.01 AppXcel login: 4. Log in with the default username and password (radware/radware). 5. Assign a management address to LAN1: net management-ip create 10.10.11.20 255.255.255.0 -inf 1 6. Make certain the management computer is on the same network segment as the AppXcel. 7. Using APSolute Insite, add an AppXcel device (10.10.11.20). The default username and password are: radware/radware. The AppXcel appears in the main window. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 63 8. To configure the networking, double-click the AppXcel icon and select Routing Table. The Routing window appears. 9. In the Routing window, click Add and create the default gateway. (The default gateway should be AppXcel's interface on that network segment, in this example it is 10.10.11.10). The following example of the Edit Route window shows the correct parameter settings: 10. Click Ok to close the Edit Route window. 11. The click Ok to close the Routing Table window and the Setup window. Configuring the AppXcel Security Key and Certificate You now need to configure the Security Key and Certificate. The following options are available: 64
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Import a PKCS12 format package that contains both Key and Certificate. This is the file format that is generated when exporting the Key and Certificate from an IIS Server. Import each separately. This option is used when storing both on a backup media. You can Import using copy and paste or using a PEM/DER format. The key can be created on the AppXcel and a certificate request can be created on top of it. This request should be exported and sent to a Certificate Authority (CA) company. After signing it the certificate should be uploaded to the AppXcel. The following example describes the second option – importing the security key and certificate separately. Make sure you have the two files ready (key + certificate). For more on implementing the other options, refer to the AppXcel User Gui
d
e
. To import the security key and certificate: 1. Right-click the AppXcel icon and select Keys. The Keys window appears. 2. In the Keys window, click Import Key. The Import Key window appears. 3. In the Import Key window, configure the key parameters as follows: 4. In the New Key ID text box, type a key ID (1 for example). 5. In the Key Password text box, type the key password (to be used when exporting the key for backup purposes). Then type it again in the Verify Key Password text box for confirmation purposes. 6. Select the import method you want to use, File or Text. Then paste your key in the text box to replace the "Erase this line…" text or browse your disk to locate the key file. The string that should be pasted in this screen should begin with: " -----BEGIN RSA PRIVATE KEY-----………." and end with: "-----END RSA PRIVATE KEY-----". AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 65 7. Click Ok to close this window. The key you just imported is listed in the Keys window. 8. In the Keys window, select the key line and click Edit. 9. Click the Certificate button and select Import. Follow the procedure for importing a key. Enter the relevant parameters in the New Certificate window as shown below: 10. Click Ok repeatedly to close the windows. The Key and the Certificate are configured in your AppXcel. Configuring the Tunnel The next step is to configure the tunnel. A tunnel is the main application of the AppXcel and is represented by an IP address that should be accessible by the AppXcel. All traffic destined to the tunnel's IP address will get decryption services. It is possible to configure multiple tunnels in one AppXcel. 66
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios To configure the tunnel: 1. Double-click the AppXcel icon and click Add. The Edit Tunnel window appears. 2. In the Edit Tunnel window, set the following parameters according to the explanations provided: Tunnel Serial ID: 1 Interface: LAN 1 (The default value should be left). IP Address: The IP of the tunnel (should be the same IP configured in the AppXcel as the server IP in the "Application1_SSL" farm). Mask: The Subnet mask of the tunnel's network segment. Port: The application port of the traffic that should be handled by the tunnel. Normally, it should be 443 for SSL decryption. Server IP: The IP address of the L4 Policy in the AppDirector. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 67 Server Port: The application port of the backend servers' farm or L4 Policy that should receive the traffic. Normally port 80 is used. Attached Key ID: The key ID. Service Type: The type of application that is terminated. This is in order to provide special support for various applications such as HTTP (compression, caching, headers rewrite), FTP (FTPS support), or SMTP (SMTPS support). Other will not modify any of the application data content except terminating the SSL. 3. In the Edit Tunnel window, click Advanced to configure additional tunnel properties and select Tunnel Transparency. This forces AppXcel to establish a connection to the backend servers using the original clients' source IP address. 4. Click Ok to confirm your preferences and once again to close the main AppXcel window. Backing Up the AppXcel Configuration The final task is to back up the AppXcel's configuration file. To back up the configuration: 1. To save a copy of the configuration, select Device > Configuration File. The Download pane appears. 2. In the Download pane, select the AppXcel device, provide a path on your local hard disk to save the file, and type the configuration export password (default: radware). 3. Click Apply to start downloading and saving the configuration file. AppXcel is ready for operation. 68
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Scenario 6: AppDirector with AppXcel – Backend SSL Enabled Scenario Description This scenario should be used when you plan to integrate Radware's AppXcel (AX) with AppDirector or into an existing AppDirector setup. SSL is a heavy task for application servers. The number of clients they can serve with SSL is much lower than the number of clients they can serve without SSL. AppXcel is an application acceleration device that enhances the performance of HTTP, HTTPS and other services that run over SSL. Using it as an integrated appliance in the AppDirector setup enables high availability and load sharing of AppXcel's resources. Scenario 6 is different from Scenario 5, as in this case the servers are working in SSL mode and AppXcel encrypts the traffic sent. Scenario 6 is used mostly in banking environments where the laws forces traffic to be fully encrypted until it reaches the servers. This scenario also adds the capability to perform Layer 7 switching and maintain session persistency according to application data (Cookies, URLs, HTTP Headers, and so on.). Using AppXcel for SSL Offloading: Traffic that reaches the Application's VIP in AppDirector is not directed to the SSL servers, it redirected to the AppXcel farm. This farm contains AppXcel devices. An SSL session is established between AppXcel and the client via AppDirector. SSL is decrypted by AppXcel and a new SSL session - with lighter and less secure ciphers - is established between AppXcel and the backend servers via AppDirector. This way, the clients talk SSL with the data center, while, in order to enhance performance, the application servers use lighter ciphers. The traffic is encrypted while performance is boosted. Advantages The advantages of this scenario include the following: High availability is gained not only for the application servers but for AppXcel devices as well. L7 content switching decisions can be made for HTTPS traffic after it is decrypted by AppXcel. Application security policies can be enforced on the traffic that was encrypted by AppXcel, so that SSL attacks can be detected. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 69 Suggested Physical Implementation Figure 6 illustrates a suggested physical implementation of the AppDirector with AppXcel – with Backend SSL enabled. APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
PWR OK
SYS OK
SSL
RESET
ACT
OK
AppXcelAPSolute Application Delivery
SERIAL PORT
FE
LNK/ACT
LAN 2
BY PASS
BYPASS
FE
LNK/ACT
LAN 1
PWR OK
SYS OK
SSL
RESET
ACT
OK
AppXcelAPSolute Application Delivery
SERIAL PORT
FE
LNK/ACT
LAN 2
BY PASS
BYPASS
FE
LNK/ACT
LAN 1
Figure 6: AppDirector with AppXcel – with Backend SSL Enabled Step-by-Step Configuration This example demonstrates how SSL can be maintained all the way from client to server, while AppDirector can inspect the Layer 7 headers of the HTTP protocol. This is achieved through the AppXcel's ability to terminate the SSL, send the decrypted headers to AppDirector, and encrypt the traffic again with lower and more efficient ciphers. Configuration according to this scenario entails configuration of both the AppDirector and AppXcel, as described in the following sections: Configuring AppDirector Configuring AppXcel, page 78 70
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Configuring AppDirector Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9. To configure the server farms: 1. AppDirector is ready to configure the servers' farms. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, click Farms > Add. The Farm window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 71 3. In the Farm window, enter the farm name in the Farm Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 6. In the Server Address text box, type the server's IP address. Notes: The servers should be located in the AppDirector's local segment. If not, you will have to configure a relevant entry under the Routing Table. Other settings should not be changed. Click the Help button or refer to the AppDirector User Guide
for a detailed explanation of these settings. 7. In the Farm Servers window, click Ok to confirm and return to the Farm window. Repeat the above steps for any other servers you want to add. 72
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. 10. In the Farm window, click Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include a Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 73 Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to accept your preferences and return to the Traffic Redirection window. 12. Repeat Steps 2-7 and set the following farms: Japanese-Farm, SSL-Farm and add the relevant servers to those farms. After repeating these steps for each of the farms, you should have the following configured: i. English-Farm (English-1 server configured for this farm) ii. Japanese-Farm (Japanese-1 server configured for this farm) iii. SSL-Farm (AX-1 server configured for this farm) 13. Click Ok to confirm and return to the Traffic Redirection window. The next step is to configure the L7 parameters to let the AppXcel distinguish between English language users and Japanese language users. 14. In the Traffic Redirection window, click L4 Policies >L7 Policies. The L7 Policies window appears. 15. In the L7 Policies window, click L7 Method to configure a method for each language. 16. Click Add to create a method. The Edit Layer 7 Method window appears. 17. In the Edit Layer 7 Method window, set the following parameters for the first method (detecting English language users) according to the explanations provided: Method Name: English Method Type: Header Field Header Field: Accept-Language Token: en 18. Click Ok to accept your preferences and repeat the above step for Japanese language users. For Japanese, the value of Token should be 'ja'. 19. Click Ok to confirm the Japanese method and again in the Layer 7 Method window. The next step is to configure a Layer 7 policy. 20. In the Layer 7 Policies window, click Add Policy. 74
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 21. Type a name, an Index, and select English as the first method. 22. Click Add and repeat this step for another policy with the same name but with a different index number (English can be 1 and Japanese can be 2). The following is an example of such a window (for a policy that identifies English users): 23. Click Ok to accept your preferences and return to the Traffic Redirection window. The next step is to configure an L4 Policy to be used to intercept traffic coming to AppDirector's VIP and direct it to the right farm (either HTTP or HTTPS farm). Now you need to configure the policy for the SSL traffic from the clients and the interception policies for both HTTPS traffic from the users to the AppXcel and HTTPS traffic from the AppXcel to the backend servers. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 75 24. In the Traffic Redirection window, select L4 Policies. The L4 Policies pane appears. 25. In the L4 Policies pane, configure the traffic flow. HTTPS from clients should be linked to the SSL-Farm and HTTPS traffic from AppXcel should be inspected by L7 data and linked to the English-Farm or Japanese-Farm. 26. Click Add. The Add L4 Policy window appears. 27. In the Add L4 Policy window, create an L4 Entry (SSL Traffic should be linked to the SSL-Farm). 28. Click Ok to accept your preferences. The policy for the SSL traffic from the clients is ready. 76
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 29. Click Add again to create the L7 Policy to handle the traffic coming from AppXcel. The Add L4 Policy window appears. 30. Configure AppDirector to select a language farm according to the Users' language. In the Add L4 Policy window, in the Layer7 Related Parameters section, configure the following parameters according to the explanations provided: Backend Encryption Port: 443 Explicit Farm Name: None L7Persistent Switching Mode: First Bytes of Request to Read: 3504 PORT Classification Input: Header 31. Click Ok to save your preferences. 32. In the L4 Policies window, configure the interception policies for both HTTPS traffic from the users to the AppXcel and HTTPS traffic from the AppXcel to the backend servers. The special Layer 7 inspection is achieved using a Layer 7 type interception mechanism that listens on a predefined port for header information coming from the AppXcel, and makes routing decisions on SSL traffic that match those headers. This special protocol between AppXcel and AppDirector is a Radware proprietary protocol and cannot be used with any other vendor. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 77 The following example of the L4 Policies window shows the properly configured policies. 33. To configure the device management settings, refer to Step #5: Management Settings, page 119. 34. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. Configuring AppXcel The process of setting up AppXcel to work according to this scenario is performed in several stages: Configuring AppXcel Networking, 78 Configuring the AppXcel Security Key and Certificate, page 81 Configuring the Tunnel, page 82 Backing Up the AppXcel Configuration, page 84 Configuring AppXcel Networking In order to use AppXcel in this scenario, you need to first configure its networking settings. To configure AppXcel networking: 1. Connect to AppXcel using a serial cable. 2. In the COM Properties window, set your terminal emulation program parameters according to the explanations provided: Bits per second: 19200 Data bits: 8 Parity: None 78
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Stop bits: 1 Flow control: None 3. Boot AppXcel and wait for the login prompt: Radware AppXcel Version 1.00.01 AppXcel login: 4. Log in with the default username and password (radware/radware). 5. Assign a management address to LAN1: net management-ip create 10.10.11.20 255.255.255.0 -inf 1 6. Make sure the management computer is on the same network segment as the AppXcel. Using APSolute Insite, add an AppXcel device (10.10.11.20). The default username and password are: radware/radware. The AppXcel icon appears in the main window. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 79 The first step is to configure the networking. 7. Double-click the AppXcel icon. The Setup window appears. 8. In the Setup window, click Networking > Routing Table. The Routing Table window appears. 9. In the Routing Table window, click Add and create the default gateway. (The default gateway should be AppXcel's interface on that network segment, in this example it is 10.10.11.10). The following is an example configuration of the Edit Route settings: 10. Click Ok three times and return to the main window. 80
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Configuring the AppXcel Security Key and Certificate You now need to configure the Security Key and Certificate. The following options are available: Import a PKCS12 format package that contains both Key and Certificate. This is the file format that is generated when exporting the Key and Certificate from an IIS Server. Import each separately. This option is used when storing both on a backup media. You can Import using copy and paste or using a PEM/DER format. The key can be created on the AppXcel and a certificate request can be created on top of it. This request should be exported and sent to a Certificate Authority (CA) company. After signing it the certificate should be uploaded to the AppXcel. The following example describes the second option – importing the security key and certificate separately. Make sure you have the two files ready (key + certificate). For more on implementing the other options, refer to the AppXcel User Gui
d
e
. To import the security key and certificate: 1. Right-click the AppXcel icon and select Keys. The Keys window appears. 2. In the Keys window, click Import Key. The Import Key window appears. 3. In the Import Key window, configure the key parameters as follows: 4. In the New Key ID text box, type a key ID (1 for example). 5. In the Key Password text box, type the key password (to be used when exporting the key for backup purposes). Then type it again in the Verify Key Password text box for confirmation purposes. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 81 6. Select the import method you want to use, File or Text. Then paste your key in the text box to replace the "Erase this line…" text or browse your disk to locate the key file. The string that should be pasted in this screen should begin with: " -----BEGIN RSA PRIVATE KEY-----………." and end with: "-----END RSA PRIVATE KEY-----". 7. Click Ok to close this window. The key you just imported is listed in the Keys window. 8. In the Keys window, select the key line and click Edit. 9. Click the Certificate button and select Import. Follow the procedure for importing a key. Enter the relevant parameters in the New Certificate window as shown below: 10. Click Ok repeatedly to close the windows. The Key and the Certificate are configured in your AppXcel. Configuring the Tunnel The next step is to configure the tunnel. A tunnel is the main application of the AppXcel and is represented by an IP address that should be accessible by the AppXcel. All traffic destined to the tunnel's IP address will get decryption services. It is possible to configure multiple tunnels in one AppXcel. 82
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios To configure the tunnel: 1. Double-click the AppXcel icon and click Add. The Edit Tunnel window appears. 2. In the Edit Tunnel window, set the following parameters according to the explanations provided: Tunnel Serial ID: 1 Interface: LAN 1 (The default value should be left). IP Address: The IP of the tunnel (should be the same IP configured in the AppXcel as the server IP in the " SSL" farm). Mask: The Subnet mask of the tunnel's network segment. Port: The application port of the traffic that should be handled by the tunnel. Normally, it should be 443 for SSL decryption. Server IP: The IP address of the L4 Policy in the AppDirector. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 83 Server Port: The application port of the backend servers' farm or L4 Policy that should receive the traffic. When using backend SSL, port 443 is normally used. Attached Key ID: The key ID. Service Type: The type of application that is terminated. This is in order to provide special support for various applications such as HTTP (compression, caching, headers rewrite), FTP (FTPS support), or SMTP (SMTPS support). Other will not modify any of the application data content except terminating the SSL. 3. In the Edit Tunnel window, click Advanced. The Advanced pane appears. 4. In the Advanced pane, set the following parameters according to the explanations provided: Select the Tunnel Transparency checkbox. This forces AppXcel to establish a connection to the backend servers using the original clients' source IP. Select the Enable Backend SSL checkbox. This forces AppXcel to establish an SSL session instead of a regular clear text session with the backend server. In the Backend Layer 7 LB Port text box, type the application port that is to be used for AppXcel and AppDirector to communicate regarding the L7 information that needs to be exchanged. In this example, port 88 is used. The Backend Cipher Suite (which can be Low, Medium or High) is for the SSL session between the AppXcel and the Backend server. Radware recommends using 'Low' in order to boost performance. As the session is internal and should not leave the local datacenter, there is no need for it to be highly secured. 5. Click Ok to accept your preferences and close the main AppXcel window. Backing Up the AppXcel Configuration The final task is to back up the AppXcel's configuration file. To back up the configuration: 1. To save a copy of the configuration, select Device > Configuration File. The Download pane appears. 2. In the Download pane, select the AppXcel device, provide a path on your local hard disk to save the file, and type the configuration export password (default: radware). 3. Click Apply to start downloading and saving the configuration file. AppXcel is ready for operation. 84
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Scenario 7: Global Traffic Management with DNS/HTTP Redirection Scenario Description When using the global traffic management solution, several redirection methods are available to define how service requests are redirected to required destinations. When a client sends a new request for service, AppDirector selects the best available server for the task. If the required server is placed at the local site, AppDirector forwards the request for service to that server. If the required server is located at the remote site, AppDirector redirects the request for service using one of the following methods: DNS Redirection HTTP Redirection RSTP Redirection Triangulation Redirection An AppDirector that is included in a global traffic management solution continuously monitors the network and responds to permanent or transient performance conditions, directing customers to the best available site. The two main stages involved in this process are: making the management decision about the best site and redirecting the user to this site, if needed. Then, a server is selected within the local site. The selection of the best server farm is done according to the global IP traffic management decisions that are based on load balancing and/or proximity considerations: Load Balancing: To distribute the traffic load among physical sites, the load balancers in the network must continuously update each other with health and performance indices. The main load balancing site must know the condition of every other site in order to make the appropriate decisions based on the real-
time dynamic load. Proximity: Proximity considerations are based on network proximity. Network proximity indicates the network distance or time distance between the user and a data resource. For example, a user is geographically closer to the New York site than to the Chicago site, yet can access the Chicago site faster when the network path to the New York site is overloaded – in terms of network proximity, the user is closer to Chicago than to New York. On the basis of these load and/or network proximity considerations, AppDirector makes the load-balancing decision and determines to which site the request for service is redirected. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 85 AppDirector Global This scenario requires that both AppDirectors (Local and Remote) have a Global license. AppDirector Global performs local load balancing as well as distributed load balancing according to load considerations, but also directs clients to sites that are “closest” to that client according to the network proximity considerations. For more information about communication between Distributed Sites, refer to the AppDirector User Guide
, Chapter 7. Redirection Methods in this Scenario Once the best site for a particular task has been selected, the user is redirected to that site. In this scenario, AppDirector will use one of the following redirection methods to perform the redirection: DNS: DNS redirection uses the DNS mechanism. AppDirector has the ability to respond to DNS queries for the IP address of a specified host name that represents the service. When such a query is made, AppDirector responds with an IP address that provides the best service for the client. This IP address belongs to a local farm on AppDirector, to a remote farm on the distributed AppDirector, or to a remote standalone server. HTTP: For HTTP traffic, AppDirector uses the standard HTTP redirection mechanism (code 302/moved temporarily) to redirect the client to an alternate site. This alternate site can either be a standalone server or another AppDirector with its own virtual address. For further information about DNS and HTTP redirection methods, refer to the AppDirector User Guide
, Chapter 7. 86
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Suggested Physical Implementation Figure 7 illustrates a suggested physical implementation of the AppDirector in Global Traffic Management with DNS/HTTP Redirection. G2
G1
Web Server Director
F1 F2 F3 F4 F5 F6 F7 F82 4 6 8
1 3 5 7
PWR
RESET
SYS OK
MODE
G2
G1
Web Server Director
F1 F2 F3 F4 F5 F6 F7 F82 4 6 8
1 3 5 7
PWR
RESET
SYS OK
MODE
G2
G1
Web Server Director
F1 F2 F3 F4 F5 F6 F7 F82 4 6 8
1 3 5 7
PWR
RESET
SYS OK
MODE
G2
G1
Web Server Director
F1 F2 F3 F4 F5 F6 F7 F82 4 6 8
1 3 5 7
PWR
RESET
SYS OK
MODE
Figure 7: Using AppDirector with DNS/HTTP Redirection Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks, page 9. The configuration for this scenario is performed in the following stages: Configuring the Networking Settings and Connecting to the Main AppDirector, page 88. Configuring the Networking Settings and Connecting to the Remote AppDirector, page 91 Creating a VIP and Layer 4 Policy in the Main AppDirector, page 93. Configuring Redirection Parameters in the Main AppDirector, page 97 Creating a VIP and Layer 4 Policy in the Remote AppDirector, page 98 Configuring Redirection Parameters in the Remote AppDirector, page 101 Configuring the Reporting Intervals, page 102 Configuring Redirection, page 103 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 87 Configuring the Networking Settings and Connecting to the Main AppDirector You need to configure the network settings and connection to the main AppDirector. To configure networking and connect to the main AppDirector: 1. Connect the device and define interfaces 1, 4 and 16. Refer to Step 3 for a detailed explanation on how to set up the management interface. 2. Double-click the AppDirector icon. The Connect to Device window appears. 3. In the Connect to Device window, type in the device’s IP address (10.204.150.190) and click Ok. 4. Double-click the AppDirector icon again. The Setup window appears. 5. In the Setup window, click Add. The Interface window appears. 6. In the Interface window, set the following interfaces according to the explanations provided: IF Num: F-1 IP Address: 172.16.1.10 Network Mask: 255.255.255.0 88
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios IF Num: F-4 IP Address: 10.0.10.1 Network Mask: 255.255.255.0 IF Num: F-16 IP Address: 10.204.150.190 Network Mask: 255.255.255.0 The Routing Table will display the following settings: Destination IP Address: 0.0.0.0 Network Mask: 0.0.0.0 Next Hop: 172.16.1.1 IF Number: F-1 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 89 7. Add local servers. Note: In this example we use only one local server but you can add as many as required. From the main toolbar, click Add > Servers > Server. A Server icon appears in the main window. 8. Double-click the Server icon. The Server window appears. 90
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 9. In the Server window, set the following parameters according to the explanations provided: Server Name: Server 1 Admin Status: Selected IP Address: 10.0.10.10 Note: You have to type the IP Address in the IP address text box and click Add. 10. Click Apply and Ok. 11. Repeat the above steps to add as many local servers as needed to the map, including servers from both the local and remote site. 12. Click Ok to apply your settings. Configuring the Networking Settings and Connecting to the Remote AppDirector You need to configure the network settings and connection to the remote AppDirector. To configure networking and connect to the remote AppDirector: 1. Connect the device and define interfaces 1, 4 and 16. Refer to Step 3 for a detailed explanation on how to set up the management interface. 2. Double-click the AppDirector icon. The Connect to Device window appears. 3. In the Connect to Device window, enter the device’s IP address 10.204.150.191 and click Ok. 4. Double-click the AppDirector icon again. The Setup window appears. 5. In the Setup window, click Add. The Interface window appears. 6. In the Interface window, set the following interfaces according to the explanations provided: IF Num: F-1 IP Address: 172.16.2.10 Network Mask: 255.255.255.0 IF Num: F-4 IP Address: 10.0.20.1 Network Mask: 255.255.255.0 IF Num: F-16 IP Address: 10.204.150.191 Network Mask: 255.255.255.0 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 91 The Routing Table displays the following settings: Destination IP Address: 0.0.0.0 Network Mask: 0.0.0.0 Next Hop: 172.16.2.1 IF Number: F-1 7. Add local servers. Note: In this example we use only one local server but you can add as many as required. From the main toolbar, click Add > Servers > Server. A Server icon appears in the main window. 8. Double-click the Server icon and set the following parameters according to the explanations provided: Server Name: Server 2 Admin Status: Selected IP address: 10.0.20.10 Note: You have to type the IP Address in the IP address text box and click Add. 9. Click Apply and Ok. 10. Repeat the above steps to add as many local servers as needed to the map, including servers from both the local and remote site. 92
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 11. Click Ok to apply your settings. 12. To save the APSolute Insite map, in the main window, select File > Save Site or press <CTRL>+S on your keyboard. Assign a name to the site map and click Save. Creating a VIP and Layer 4 Policy in the Main AppDirector The next step is to create a VIP and Layer 4 policy in the main AppDirector. To create a VIP and a Layer 4 Policy: 1. Right-click the Main AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 93 2. In the Traffic Redirection window, select Farms and click Add. The Farm window appears. 3. In the Farm window, set the following parameters according to the explanations provided: Farm Name: AD1 Mode: Global 4. Click Apply > Add. The Farm Servers window appears. 5. In the Farm Servers window, select the server located on this site from the Server Name dropdown list and add a server description if required. 94
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 6. Click Ok. The Farm Servers window closes. 7. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 8. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. 9. In the Traffic Settings pane, set the traffic settings according to the explanations provided: Dispatch Method: The algorithm used to split traffic between servers, which can be cyclic, according to the amount of traffic or to the number of sessions. Other options include Hashing, the result of SNMP query to the servers (like CPU Usage), or the response time of the server to the AppDirector's health check traffic. For this scenario, we recommend that you select Cyclic. Session Mode: The way AppDirector adds entries to its Client Table. For this scenario, select ServerPerSession. Distribution Threshold: 5 Note: the default value of Distribution Threshold is 2500. This scenario is using the value 5 for demonstration purposes. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 95 Redirection Mode For this scenario, select HTTP as the Redirection mode. Note: If DNS is selected as the Redirection mode, you need to define a DNS Redirection Fallback. HTTP Redirection Mode: Select the required HTTP Redirection Mode. Note: When the HTTP Redirection Mode is set to Name Mode, in the Redirect To text box you need to type the name to which the request for service is redirected. If such a name is not specified the Server name is used. Client Aging Time: This is the period AppDirector keeps an entry of a session in the Client Table when there is no activity. AppDirector resets this timer each time there is TCP activity on the session. The default value is 60 seconds; however, Radware guidelines for the best tuning value are to determine your application timeout and add a minute to that value. This way persistency is maintained for your application's session. The value should be written in seconds, not minutes. Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppDirector Global, and so on. Before enabling any of those advanced features, make certain they are applicable for this scenario. 10. Click Ok to record your preferences and close the Farm window. 11. In the Traffic Redirection window, click L4Policies. The L4 Policies window appears. 12. In the L4 Policies window, click Add. 13. In the VIP Address text box, type the IP address of the VIP. For this scenario, type 172.16.1.2. 14. Click Add. The Add L4 Policy window appears. 15. In the Add L4 Policy window, set the following parameters according to the explanations provided: L4Protocol: TCP L4Port: 80 L4Policy name: any text string Farm name: AD1 16. Click Ok to close the Add L4 Policy window. 17. Click Ok to close the L4 Policies window. 96
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Configuring Redirection Parameters in the Main AppDirector The next task is to configure the redirection parameters in the main AppDirector. To configure redirection parameters: 1. Right-click the main AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, in the Farms pane, select the row for the AD1 farm and click Edit. The Farm window appears. 3. In the Farms window, click Add. The Farm Servers window appears. 4. In the Farm Servers window, set the following parameters according to the explanations provided: Server Name: Remote AD When you select the server from the dropdown list, The server address appears automatically. Type: Distributed AD Weight: The weight should be the sum of the total weight of all local servers on the other site. For example, if there are 3 servers on the remote site, each of them is configured with a weight of 1, the weight should be 3. Server Description: An optional text description. 5. Click Ok. The Farm Servers window closes. 6. Click Ok. The Farm window closes. 7. In the Traffic Redirection window, click Redirection. The Redirection pane appears. 8. In the Redirection pane, select your device and click Edit. The Traffic Redirection window for the selected device appears. 9. In the Traffic Redirection window, make sure that the Distributed Sites pane is selected. 10. In the Distributed Sites pane, from the Redirection Mode dropdown list, select Redirection. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 97 11. Click Add. The Edit Report Table window appears. 12. In the Edit Report Table window, set the following parameters according to the explanations provided: Distributed Farm: Type in the name of the remote Farm: AD2. Distributed Server: Type in the local VIP address: 172.16.1.2. L4 Policy Select the L4 Policy you configured (HTTP). Report Destination Address: Type in the IP address of the remote AD: 172.16.2.10. Redundant Remote Address If the main AppDirector device has a redundant device next to it, set its address here to ensure a smooth backup process. 13. Click Ok to close all opened windows. Creating a VIP and Layer 4 Policy in the Remote AppDirector The next step is to create a VIP and Layer 4 policy in the remote AppDirector. To create a VIP and a Layer 4 policy in the remote AppDirector: 1. Right-click the Remote AppDirector and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, select Farms >Add. The Farm window appears. 3. In the Farm window, set the following parameters according to the explanations provided: Farm Name: AD2 Mode: Global 98
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 4. Click Apply > Add. The Farm Servers window appears. 5. In the Farm Servers window, select the server located on this site from the Server Name dropdown list and add a server description if required. 6. Click Ok. The Farm Servers window closes. 7. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 8. In the Traffic Settings pane, set the traffic settings according to the explanations provided: Dispatch Method: The algorithm used to split traffic between servers, which can be cyclic, according to the amount of traffic or to the number of sessions. Other options include Hashing, the result of SNMP query to the servers (like CPU Usage), or the response time of the server to the AppDirector's health check traffic. For this scenario, we recommend that you select Cyclic. Session Mode: The way AppDirector adds entries to its Client Table. For this scenario, select ServerPerSession. Distribution Threshold: 5 Note: the default value of Distribution Threshold is 2500. This scenario is using the value 5 for demonstration purposes. Redirection Mode For this scenario, select HTTP as the Redirection mode. Note: If DNS is selected as the Redirection mode, you need to define a DNS Redirection Fallback. HTTP Redirection Mode: Select the required HTTP Redirection Mode. Note: When the HTTP Redirection Mode is set to Name Mode, in the Redirect To text box you need to type the name to which the request for service is redirected. If such a name is not specified the Server name is used. Client Aging Time: This is the period AppDirector keeps an entry of a session in the Client Table when there is no activity. AppDirector resets this timer each time there is TCP activity on the session. The default value is 60 seconds; however, Radware guidelines for the best tuning value are to determine your application timeout and add a minute to that value. This way persistency is maintained for your application's session. The value should be written in seconds, not minutes. Note: Additional settings can be tuned In the Traffic Settings pane. Nonetheless, it is recommended that you maintain the default settings unless otherwise required, for example, when enabling NAT, Installing a remote server on an AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 99 AppDirector Global, and so on. Before enabling any of those advanced features, make certain they are applicable in such a Local Triangulation scenario. 9. Click Ok record your preferences and close the Farm window. 10. In the Traffic Redirection window, click L4Policies. The L4 Policies window appears. 11. In the L4 Policies window, click Add. 12. In the VIP Address text box, type the IP address of the VIP. For this scenario, type 172.16.2.2. 13. Click Add. The Add L4 Policy window appears. 14. In the Add L4 Policy window, set the following parameters according to the explanations provided: L4Protocol: TCP L4Port: 80 L4Policy name: Any text string Farm name: AD2 15. Click Ok to close the Add L4 Policy window. 16. Click Ok to close the L4 Policies window. 100
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Configuring Redirection Parameters in the Remote AppDirector The next task is to configure the redirection parameters in the remote AppDirector. To configure redirection parameters: 1. Right-click the main AppDirector, select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, in the Farms pane, select the row for AD2 farm and click Edit. The Farm window appears. 3. In the Farm window, click Add. The Farm Servers window appears. 4. In the Farm Servers window, set the following parameters according to the explanations provided: Server Name: Remote AD When you select the server from the dropdown list, The server address appears automatically. Type: Distributed AD Weight: The weight should be the sum of the total weight of all local servers on the other site. For example, if there are 3 servers on the remote site, each of them is configured with a weight of 1, the weight should be 3. Server Description: An optional text description. 5. Click Ok. The Farm Servers window closes. 6. Click Ok. The Farm window closes. 7. In the Traffic Redirection window, click Redirection. The Redirection pane appears. 8. In the Redirection pane, select your device and click Edit. The Traffic Redirection window for the selected device appears. 9. In the Traffic Redirection window, make sure that the Distributed Sites pane is selected. 10. In the Distributed Sites pane, from the Redirection Mode dropdown list, select Redirection. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 101 11. Click Add. The Edit Report Table window appears. 12. In the Edit Report Table window, set the following parameters according to the explanations provided: Distributed Farm: Type in the name of the remote Farm: AD1. Distributed Server: Type in the local VIP address: 172.16.2.2. L4 Policy Select the L4 Policy you configured (HTTP). Report Destination Address: Type in the IP address of the remote AD: 172.16.1.10. Redundant Remote Address If the remote AppDirector device has a redundant device next to it, set its address here to ensure a smooth backup process. 13. Click Ok to close all opened windows. Configuring the Reporting Intervals The reporting settings should be configured for both the main device and the remote device. You need to perform the following procedure for each AppDirector. To configure the reporting intervals: 1. Double-click the AppDirector icon. The Setup window appears. 2. In the Setup window, click Global. The Global pane appears. 3. In the Global pane, select Advanced Settings and then click Edit Settings. The Advanced Settings window appears. 102
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 4. In the Advanced Settings window, set the following parameters according to the explanations provided: Load Report Interval: Set an interval number (in seconds) as required. Report Timeout: Set an interval number (in seconds) as required. 5. Click Ok to apply the setup and to close all opened windows. Configuring Redirection The process of configuring redirection is performed in several stages: Defining Redirection to HTTPS, page 104 Configuring DNS Redirection, page 105 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 103 Defining Redirection to HTTPS AppDirector can redirect HTTP traffic to HTTPS. Using HTTP Redirection, AppDirector can be configured to redirect clients to secure access to the site, using HTTPS. When the client accesses the farm, and AppDirector decides to redirect the client using HTTP Redirection, you can set AppDirector to indicate to the client that the site must be accessed using HTTPS rather than HTTP. To define redirection to HTTPS, you need to perform the following procedure for on both the main AppDirector and the remote AppDirector. To define redirection to HTTPS: 1. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, select Farm. The Farm pane appears. 3. In the Farm pane, double-click the selected farm or click Edit. The Farm window appears. 104
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 4. In the Farm window, select Traffic Settings. The Traffic Settings pane appears. 5. In the Traffic Settings pane, select the Redirect to HTTPS checkbox and click Ok. 6. Click Ok to close all opened windows. Configuring DNS Redirection AppDirector can redirect clients to other sites using the DNS mechanism. When using DNS Redirection, AppDirector becomes the authoritative DNS server for its farms. When a client sends a DNS request for a specific service, the AppDirector selects the local farm IP or a remote farm address for the answer. The configuration of DNS Redirection differs from the previous example only with regard to setting the Redirection Mode to DNS Redirection in the main AppDirector configuration. When using DNS Redirection for a farm, for example, www.radware.com, the authoritative DNS server for radware.com is configured with an NS (Name Server) record pointing to the AppDirector Virtual IP Interface (VIPI) Address, or to the AppDirector physical interface if no backup device is present. When a request for www.radware.com arrives at this DNS server, it sends the request to the main AppDirector, which then resolves it either to its own farm or to a remote server or a remote farm on a distributed AppDirector. The name of the farm on the AppDirector must match the required URL, for example, www.radware.com. To support site redundancy, a second NS record is configured, using the remote AppDirector Virtual IP Interface (VIPI) address. When the main AppDirector (or its backup device) is available, requests are received and are resolved by it. Otherwise, requests are sent to the remote AppDirector. This is part of the Internet DNS mechanism. The DNS server can be located anywhere. The following DNS settings should be applied to both the main and remote AppDirectors. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 105 To define DNS redirection: 1. Right-click the AppDirector icon and select APSolute OS > Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, click DNS. The DNS pane appears. 3. In the DNS pane, set the following DNS parameters: Select the Enable DNS checkbox. Select the Respond With Two A records checkbox. In the Host Name text box, enter the Host Name (domain for which DNS resolve is required). From the L4Policy Name dropdown list, select the relevant L4 policy. 4. In the DNS pane, click Add and select Farm. The Farm pane appears. 5. In the Farm pane, select the AD1 Farm and click Edit. The Farm window appears. 106
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 6. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 7. In the Traffic Settings pane, change the Redirection mode to DNS and set the DNS Redirection Fallback. 8. Click Ok to close the Edit Farm window. 9. In the Traffic Redirection window, click Redirection. The Redirection pane appears. 10. In the Redirection pane, select your device and click Edit. The Traffic Redirection window for the selected device appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 107 11. In the Traffic Redirection window, make sure that the Distributed Sites pane is selected. 12. In the Distributed Sites pane, set the following DNS parameters: From the DNS Redirection dropdown list, select the redirection mode (DNS, DNS + HTTP + Triangulation, and so on). From the DNS Redirection Fallback dropdown list, select the relevant fallback mode. In order to allow DNS servers to redirect traffic to the AppDirectors, you must create an L4 Policy with the VIP that is to be used as an NS record. 13. In the Traffic Redirection window, click L4Policies. The L4 Policies window appears. 14. In the L4 Policies window, click Add. 15. In the VIPAddress text box, for each site type in a different VIP address. 108
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 16. Click Add. The Add L4 Policy window appears. 17. In the Add L4 Policy window, for each site set the following parameters according to the explanations provided: L4Protocol: Any L4Port: Any L4Policy name: Any text string Application: Virtual Interface 18. Click Ok to close the Add L4 Policy window. 19. Click Ok to close the L4 Policies window. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 109 Scenario 8: AD as a L2 Bridge (VLAN) in the Datacenter Scenario Description This scenario is another way to install the AD. Radware recommends using it only if no other option (Scenario numbers 1, 2, 3) is suitable for your needs. It involves VLAN settings where more than one interface of the AD should be a member in the same L2 segment. The AD acts a bridge in terms of IP segments and does not perform L3 routing between the interfaces members in the VLAN. The term VLAN in Radware products means that the servers located under the AD and the FW / Router located on top of the AD are on the same L2 segment. Advantages The advantages of this scenario include the following: The default GW of the servers can be the AD but also the router/FW on top. This is an advantage as no routing changes are required in the servers. QOS is available by AD according to application data (like HTTP cookies). Limitations The limitations of this scenario include the following: Changes in the physical network. Installing AD in such a scenario requires changes in both cabling and routing. Direct access to and from the servers is done via AD. This should be included in the overall traffic calculations processed by AD (for example, database synchronization, software auto updates, and so on). Security is affected as the servers are located in the same IP segment of the AD and the router on top of it (most of the time these are public IPs). 110
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios Suggested Physical Implementation Figure 18 illustrates a suggested physical implementation of AD as a Bridge. APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
APSolute Application Delivery
AppDirector
G1
G2
G3
G4
G5
F9 F10 F11 F12F1 F2 F3 F4
F13 F14 F15 F16F5 F6 F7 F8
Figure 8: AD as a Bridge in the Datacenter AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 111 Step-by-Step Configuration Before you begin this configuration section, refer to Step 3: Pre-Installation Tasks. After completing the pre-installation procedure, you are ready to configure the server farms. To configure the server farms: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. 2. In the Traffic Redirection window, select Farm > Add. The Farm window appears. 112
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 3. In the Farm window, type the farm name in the Farm Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. 4. Next, configure your servers and associate them with the farm. In the Farm window, click Add. The Farm Servers window appears. 5. In the Farm Servers window, type the server name in the Server Name text box. Note: If the name contains more than one word, avoid spaces by adding a dash "-" between the words. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 113 6. In the Server Address text box, type the server's IP address. Note: The servers should be located in the AppDirector's local segment. If not, you need to configure a relevant entry under the Routing Table. Other parameters should retain their default value. Click the Help button or refer to the AppDirector User Guide
for a detailed explanation about the use of these settings. 7. Click Ok to confirm and return to the Traffic Redirection window. Repeat the above steps for the additional servers as required. 8. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 9. In the Traffic Settings pane, set the key traffic settings according to the explanations provided in Table 1, page 20. 114
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 10. Click Connectivity Check. The Connectivity Check pane appears. The Connectivity Check pane allows you to configure simple connectivity checks for the servers. The purpose of the connectivity checks is to let AppDirector know the state of the servers (active or down). Connectivity checks can include; Ping, TCP port (three-way handshake attempt), UDP port or HTTP page request. Note: It is possible to disable the checks. To disable the checks, in the Connectivity Check pane, select No Checks from the Connectivity Method dropdown list. Disabling the checks can be used in order to perform more complex and deep checks in the Health Monitoring module. 11. Click Ok to close the Farm window and return to the Traffic Redirection window. At this point, the farms, servers and their connectivity checks are configured. The next step is to configure the policies that need to intercept the traffic coming to AppDirector and redirect it to the relevant farms. 12. In the Traffic Redirection window, click L4 Policies. The L4 Policies pane appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 115 13. In the L4 Policies pane, click Add. The L4 Policies window appears. 14. In the L4 Policies window, in the VIP Address text box, type the VIP address that AppDirector will listen on. All traffic coming to this VIP will be classified according to the L4 Policy that you set now. 15. Click Add to configure the policies. The Add L4 Policy window appears: For this example (HTTP servers), the L4 Protocol should be TCP, the Layer 4 Port should be 80, and the Farm Name should indicate the farm that was configured earlier. The policy name is a free text field that describes the policy's role. Other settings should not be changed. For more information about the other settings, refer to the AppDirector User Guide
. 16. Click Ok to confirm and return to the L4 Policies window. 116
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step 4: Recom
m
end
ed Sce
n
a
r
ios 17. In case you have other farms and services, configure the VIPs and policies for them in this window as well. 18. Upon completion, click Ok twice to close the windows and return to the APSolute Insite main windows. 19. To configure the device management settings, refer to Step #5: Management Settings page 119. 20. To complete the configuration of this scenario, refer to Step #6: Configuring Redundancy in the AppDirector using VRRP, page 120. 21. To configure advanced Layer 7 parameters, refer to Step #7: Advanced Content Switching – Layer 7, page 119. 22. To configure the NAT parameters, refer to Step #8: Client NAT Settings, page 132 AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 117 Step #5: Management Settings The next step is to configure the AppDirector Management properties. These settings are relevant for all scenarios. To configure the management properties: 1. Double-click the AppDirector icon. The Setup window appears. 2. In the Setup window, click Access. The Access pane appears. 3. In the Access pane, select the Active checkbox for the desired management tool. You can enable Telnet, Web (HTTP or HTTPS) and SSH. For security reasons, Radware recommends using HTTPS (Secure Web) instead of HTTP and SSH instead of Telnet. Note: When Active is selected, the default username and password are radware. 4. Click Ok to close the Access pane. 118
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #5: Man
a
geme
n
t Setting
s 5. It is recommended to modify the default account. In the main window, select the AppDirector and select Device > Device Permissions. The Device Permissions window appears, with the User Table pane displayed by default. 6. In the User Table pane, click Add to create more accounts or double-click the radware account to modify its password. Click Apply. 7. To enable the physical ports, in the Device Permissions window, click Management Settings. The Management Settings pane appears. 8. In the Management Settings pane, enable the physical ports to be allowed for management for each management method (SNMP, Telnet, Web, SSH, SSL) and click Apply. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 119 Step #6: Configuring Redundancy in the AppDirector using VRRP This step covers the redundancy configuration. It guides you through the steps needed to configure redundancy on your pair of AppDirectors. Note: Redundancy should be set only when all configured interfaces are active (a network cable is connected and the state is 'up'). To configure redundancy using VRPP: 1. To connect to the backup AppDirector device, on the main toolbar, click Add > Add Radware Device > AppDirector. Another AppDirector object appears in the main window. 2. To connect to the device, expand the icon view and double-click the AppDirector icon. The Connect to Device window appears. 120
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #6: Co
nfi
guri
ng Re
du
nd
anc
y in
the A
p
pDirect
o
r usin
g
VRRP 3. Select both AppDirectors (holding down the <CTRL> button) and then click Link on the toolbar. The Multiple Device Links window appears. 4. In the Multiple Device Links window, select the appropriate option (in this example AppDirector_Active is "backed-up-by" AppDirector_Backup) and click Ok. The Redundancy window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 121 5. In the Redundancies window, from the Relation Type dropdown list, select VRRP. Note: Radware recommends using VRRP (Virtual Router Redundancy Protocol) as the redundancy method. However it is possible to use Radware's propriety ARP redundancy mechanism. For further information, refer to the AppDirector User Guide
. 6. In the Redundancies window, click Add VRID on the left side to create the VRRP settings for the first interface. The Edit VRRP Table window appears. 7. In the Edit VRRP Table window, set the following parameters according to the explanations provided: Note: If you configured any VLAN interface in the AD select the relevant VLAN name in the Interface field instead of the physical interface name. Follow this rule any time you are requested to select a physical interface. Interface: The interface name. VRID: The VRID number (Virtual Router Identification). Start from 1 or choose any value between 1 to 255. Change the priority to 255 (the highest possible to configure and a must in case of Active device). Primary IP: The IP address of the Active device. 122
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #6: Co
nfi
guri
ng Re
du
nd
anc
y in
the A
p
pDirect
o
r usin
g
VRRP 8. Click Ok to confirm the settings and return to the Redundancies window. The new entry appears in the Redundancies window, as shown in the example below. 9. In the Redundancies window, select the new entry on the left side and click the right arrow button to copy this entry to the backup device. The Copy Line from Master to Backup window appears. 10. In the Copy Line From Master to back up window, select the equivalent IP for the active's interface on the backup device (in this example 10.10.10.10 in the Active is equivalent to 10.10.10.11 on the Backup). AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 123 11. Repeat steps 5-10 for each additional interface on the AppDirector. After the redundancy configuration, assuming only one interface is configured in AppDirector, the Redundancies window appears as shown below. The next step is to add the associated IP addresses to each VRID. Associated IP addresses are the IP addresses that should be controlled by the VRRP mechanism and are taken over by the Backup device when the Active is not in service or down for maintenance. 124
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #6: Co
nfi
guri
ng Re
du
nd
anc
y in
the A
p
pDirect
o
r usin
g
VRRP 12. In the Redundancies window, click on the left Associated IP button. The Associated IP Address window appears. 13. In the Associated IP Address window, configure the IP address, the interface and the relevant VRID. The relevant VRID is the VRID that belongs to the network segment as the added IP address. 14. Click Add to confirm. Notes: All L4 Policies, NAT IPs, and DNS VIPs should be included in the associated IP table. Physical IP addresses should not be included in the Associated IP table. The AppDirector's Physical IP address is usually used as a default gateway for other network elements. If the backup device takes over, it must include this IP address as one of its own IP addresses (to enable other network elements to route their traffic via a live IP address). However, the active device cannot be accessed during the takeover period (that was caused due to maintenance tasks) because its IP address is taken over by the backup device. The solution is to use VIPs instead of physical IPs addresses. In order to do this, you must associate at least one VIP (like existing or new created L4 Policy) to each VRID (the VIP should match the VRID's network segment). As a result, the Active AppDirector will still be accessible during takeover as the backup will not take ownership of the active AppDirector's IP address. The configured VIPs are used as the network's default gateway in the same manner as the physical IP addresses were used until then. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 125 15. The last step is to activate these VRRP settings. Double-click the relevant interface entry. The Edit VRRP Table window appears. 16. In the Edit VRRP Table window, select the Enable Virtual Router checkbox. This must be repeated for each interface entry. The AppDirector redundant setup is ready. The next step is to synchronize the actual setup. 126
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #6: Co
nfi
guri
ng Re
du
nd
anc
y in
the A
p
pDirect
o
r usin
g
VRRP Synchronizing Configurations between Active and Backup Devices The Copy Configuration wizard converts the Active device's configuration into a Backup device's configuration format. You must run this wizard each time you change any of the AppDirector's settings in order to have an updated configuration on the Backup device. To synchronize configurations between active and backup devices: 1. In the AD Redundancies window, click Copy Configuration. The Copy Configuration window appears. 2. In the Copy Configuration window appears, click Apply to perform the actual convert and send action. Note: The copy action is performed using TFTP between the AppDirector and the APSolute Insite computer. As TFTP is sensitive to NAT over the network, make sure that the management computer is located on the same network as the AppDirector or is routed with no NAT in between. At this stage, the primary AppDirector is ready for operation. It is very important to back up the current configuration and store it in a safe location. It is also important to repeat the backup action periodically to ensure you always store an updated backup configuration file. 3. To back up the configuration file, in the main window, select the device and click Device> Configuration File. The Configuration File window appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 127 4. In the Configuration File window, click browse to locate and select a safe location to store the configuration file on your hard disk. The default location is the User Files directory in the APSolute Insite installation folder. 5. Once the download is complete, as indicated by the 100% progress bar, click Apply. 6. Click Ok to close the Configuration File window. 128
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #7: Adva
nced C
onte
n
t S
w
itc
h
i
ng – L
a
y
er 7 Step #7: Advanced Content Switching – Layer 7 Sometimes it is necessary to make load-balancing decisions according to information stored in the application Layer (L7), and not according to the source IP address or port. This may be relevant in the interest of persistency, for example, for a proxy server or a Firewall that performs NAT to the IP of the clients that need to have access to the servers' farm. For such purposes, you can configure Session ID Persistency in the AppDirector device. To configure Session ID persistency: 1. Right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. 2. Select the farm for which you want to enable L7 and click Session IDs. The Session IDs pane appears: Note: This example shows how to set “session_id” as the Session Identifier. According to the string that follows this identifier; AppDirector will maintain persistency. The Session ID can be found in the client's HTTP GET request or in the server's HTTP initial response. Radware recommends consulting your application expert as this field has no standards and can be implemented in a variety of ways. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 129 3. In the Session IDs pane, click Add. The Edit Session ID Persistency Table Text Match window appears. 4. In the Edit Session ID Persistency Table Text Match window, set the following parameter according to the explanation provided: Persistency Identifier: Type in the "session_id" ; the relevant identifier, according to your application. Notes: Additional settings in this window should not be changed unless your application has other HTTP headers that might have the same identifier inside or there are some other persistency needs that are not covered with this example. To better understand the role of these parameters, refer to the AppDirector User
Guide
for a detailed explanation. 5. Click Ok to confirm and close this window. 130
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #7: Adva
nced C
onte
n
t S
w
itc
h
i
ng – L
a
y
er 7 6. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 7. In the Traffic Settings pane, from the Sessions Mode dropdown list, select Server per Session to allow AppDirector to redirect TCP sessions from the same source IP (Proxy or Firewall) to different servers. 8. Click Ok and close the Farm window. AppDirector will search for the HTTP headers and will take the balancing/persistency decision according to this data. Note: Many other L7 decision taking and persistency are possible using AppDirector. For more information kindly refer to the AppDirector User Guide
. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 131 Step #8: Client NAT Settings Sometimes it is necessary to NAT sessions sent from the AppDirector to the application servers. If the application server's response sessions are routed directly to the Internet, they will be dropped by the destination host (because the source IP address belongs to the application server and not the AppDirector's VIP from the original client's session). For this reason, the application server needs to be forced to respond via the AppDirector, therefore the AppDirector changes the source IP address back to the original requested IP address. The solutions for this complexity can be either forcing the application server to be routed to the Internet via the AppDirector or to enable Client NAT on the AppDirector. To enable Client NAT: 1. In the AppDirector main window, right-click the AppDirector icon and select APSolute OS >Traffic Redirection. The Traffic Redirection window appears. 132
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #8: Cli
ent
NAT
Settings 2. In the Traffic Redirection window, select the NAT pane. The NAT pane appears. 3. In the NAT pane, click the NAT Settings button. The NAT Settings window appears. 4. In the NAT Settings window, select the Client NAT checkbox to enable the Client NAT capabilities. Click Ok to close the NAT Settings window. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 133 5. In the NAT pane, set the following parameters according to the explanations provided: Client NAT Addresses: Verify that this option is selected. From IP Address: Type the first IP address in the range of IP addresses to be used as the source IP address of the traffic sent to the application servers. To IP Address: Type the last IP address in the range of IP addresses to be used as the source IP address of the traffic sent to the application servers. 6. Click Add to save the range you entered. The following window shows the sample configuration. In this example, 10.10.10.50 was used as the NAT IP address. 7. In the NAT pane, set the following parameters according to the explanations provided: Client NAT Intercept Addresses: Verify that this option is selected. From IP Address: Type the first IP address in the range of IP addresses to be NATed when sent to the application servers. To IP Address: Type the last IP address in the range of IP addresses to be NATed when sent to the application servers. 8. Click Add to save the range you entered. 9. Click Farm. The Farms pane appears. 134
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide Step #8: Cli
ent
NAT
Settings 10. In the Farms pane, select the farm for which you want to configure Client NAT and click Edit. The Farm window appears. 11. In the Farm window, click Traffic Settings. The Traffic Settings pane appears. 12. In theTraffic Settings pane, set the NAT IP range you configured in the NAT Address Range text box. This IP range is used as the source IP address of traffic sent to the server in this farm. 13. Click Apply and then click Farm Servers. The Farm Servers pane appears. AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 135 14. In the Farm Servers pane, select the server and click Edit. The Farm Servers window appears. 15. Select the Client NAT checkbox to enable Client NAT for this specific server. It is also possible to use different NAT IP as set for the farm for traffic sent to this specific server. If this option is not configured, the farm's setting is used. Note: It is possible to configure Client NAT on selected farms only or on selected servers only. This is the reason you have to change settings globally, per farm and per server. 16. Click Ok to close the Farm Servers window. 17. Click Ok to close the Farm window. 18. Click Ok to close the Traffic Redirection window. Client NAT is now configured and from now on all users' traffic that is sent to the servers for which you defined Client NAT is NATed according to the settings. 136
AppD
irector T
e
chnic
a
l Sol
u
tio
n
Guide 
Автор
radware.mel
Документ
Категория
Без категории
Просмотров
16 984
Размер файла
3 515 Кб
Теги
solutions, guide, appdirector, radware
1/--страниц
Пожаловаться на содержимое документа