ADC Application Deiivery Controller petrl@radware.com
Introducing Radware Application Delivery Solution Radware Application Delivery solution is a comprehensive, cost-effective solution ensuring: Full availability Maximum performance Complete security of your mission-critical applications, while enabling greater cost reduction and higher ROI Slide 2
Radware Product Overview HTTP Monitor Web Services and XML Gateway Partner Inflight AppXML Message Queuing System Router Intrusion Prevention Mainframe Customers LinkProof DefensePro AppDirector ESB Router Application Delivery Controller LinkProof WAN Link Optimizer / Load Balancer AppWall Web & Portal Servers Database servers Web Application Firewall Branch Office Application Servers Data Center Slide 3
Features
On Demand Software Option Licenses With the on demand scalability, using a simple license upgrade one can: Increase application acceleration scalability SSL offloading Compression Add new application-aware services Global server load balancing Bandwidth Management Service and DoS protection Service & DoS Protection ACL + SYN Protection Bandwidth Management Caching Compression SSL Offloading Global Load Balancing Local Load Balancing Slide 5
Features
IP Communication What is SLB / NAT Topologies Health monitoring L4/L7 farm traffic flow Session persistancy Acceleration Global SLB Management Hardware Slide 7
Technical Overview
Server Load Balancing Slide 9
IP Communication L2 Header MAC Source Address MAC Destination Address Checksum IP Header IP Source Address IP Destination Address Checksum TCP Header Source Port Destination Port Checksum Session ID IP Source Address Source Port Layer 2 Layer 3 Layer 4 Source MAC Source MAC Destination MAC VIP MAC Source IP Client IP Destination IP VIP Checksum B35C Source Port 2165 Destination Port 80 Checksum 037A Slide 10
The Life of an HTTP Request DNS Lookup for: www.appswitch.com Client DNS response with: 192.168.13.10 Client Site DNS Server IPDA 192.168.13.10: TCP SYN, Dest TCP Port 80 Client IPDA 192.168.13.10: SYN ACK-ACK, TCP Port 80 IPDA (client) : TCP SYN-ACK Web Server IPDA 192.168.13.10: HTTP GET (url), TCP Port 80 IPDA 192.168.13.10:TCP FIN, Dest TCP Port 80 IPDA (client) : GET RESPONSE (data) IPDA (client) : TCP FIN-ACK Slide 11
Basic Frame Flow & Client and Server Processing Slide 12
Basic Frame Flow Process (1) DNS resolves incoming request to switch. Network Manager DNS www.appswitch.com ~ 192.168.13.10 VIP 192.168.13.10 Port 80 10.10.10.1 10.10.10.2 (2) Switch selects best server based on policy. (3) Response is sent to client via switch. 10.10.10.3 Slide 13
Routing VIP 192.168.13.10 Port 80 Interface 192.100.13.1/28 Interface 10.10.10.254/24 Route entry 10.20.30.2 10.10.10.1 Client: 172.16.3.4:2000 10.20.30.2 Ensure proper routing 10.10.10.3 Slide 14
Accessing the VIP Network Manager DNS www.appswitch.com ~ 192.168.13.10 VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 DestIP: 192.168.13.10:80 10.10.10.2 Access virtual-server IP-address/service 10.10.10.3 Slide 15
Detect Request SrcIP : 172.16.3.4:2000 DestIP: 192.168.13.10:80 VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 DestIP: 192.168.13.10:80 client process 10.10.10.2 Detect request to virtual-server IP-address/service 10.10.10.3 Slide 16
Is request already served? SessionTable Source client-ip:port Dest. VIP: service-port VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 client process 10.10.10.2 Is current request already served? 10.10.10.3 Slide 17
Yes, Request Already Served client process SessionTable Source client-ip:port Dest. VIP: service-port LoadB. Rserver:listen-port Protocol VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 10.10.10.2 Is current request already served? Yes, send to servers. 10.10.10.3 Slide 18
No, Do Load Balancing SessionTable Source client-ip:port Dest. VIP: service-port VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 client process 10.10.10.2 Is current request already served? No, do load balancing 10.10.10.3 Slide 19
Send Request to Real Server client process SessionTable Source client-ip:port Dest. VIP: service-port LoadB. Rserver:listen-port Protocol VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 10.10.10.2 Send request to real-server SrcIP: 172.16.3.4:2000 DestIP: 10.10.10.3:80 10.10.10.3 Slide 20
Real Server Responds SessionTable Source client-ip:port Dest. VIP: service-port LoadB. Rserver:listen-port Protocol Service Map Table VIP - Real-server 1 VIP - Real-server x VIP 192.168.13.10 Port 80 10.10.10.1 Client: 172.16.3.4:2000 server process 10.10.10.2 Real-server responds SrcIP:10.10.10.3:80 DestIP: 172.16.3.4:2000 10.10.10.3 Slide 21
Client Processing MAC Dst MAC Src MAC virt_mac router_mac rip_mac router_mac rip_mac router_mac Src IP Address Dst IP Address CIP VIP CIP VIP CIP RIP CIP RIP TCP Src Port Dst Port 2155 80 2155 80 2155 80 2155 80 Client Application Switch Real Server Client processing is enabled on a per-port basis under /cfg/slb/port #/client ena. For SLB traffic, switch uses a different mac address: aa:bb:cc:dd:ee:fe Slide 22
Client-to-Server Traffic Recognize received SYN packet addressed to a VIP (TCP connection request). Is session table entry present? If no entry, do slb. Bind session and create session ID entry. IP address substitution based on Session ID Recognize successive packets associated with the same session and send to the same real server. Unbind upon reception of a FIN packet or time-out. Packets not addressed to a VIP are switched at L2. Session table contain at minimum SrcIP, Sport, DestIP, Dport and protocol Display content: /info/slb/sess/dump other filter options help Slide 23
Server Processing MAC SrcMAC DestMAC vip_mac rip_mac rip_mac router_mac router_mac router_mac Src IP Address Dst IP Address VIP CIP VIP CIP RIP CIP RIP CIP TCP Src Port Dst Port 80 2155 80 2155 80 2155 80 2155 Client Application Switch Real Server Server processing is enabled on a per-port basis under /cfg/slb/port #/server ena. Slide 24
Server-to-Client Traffic All packets must be watched. Determine whether arriving packets are associated with virtual services or native communications. Implement Source IP/s-port substitution if the packet is associated with a virtual service. Use service map table Static table Associates VIP to RealServer Forward using L2 switching if the packet is not associated with a virtual service. Slide 25
Alteon SLB Terminology Real Server Actual server connecting to Real IP (RIP) Real server IP Address Real Server Port (rport) Defines the real server TCP or UDP port assigned to the service Weights Bias load balancing to give the fastest real servers a larger share of connections Group Group of real servers for load balancing Metrics Used to select which real server in a group receives the client request Health Check Only available server in a group receive the client requests Virtual Server All client requests are forwarded to the virtual server defined on the Alteon Virtual IP (VIP) IP address of the virtual server on the Alteon Service This TCP or UDP service port select a group of real server Slide 26
LB algorithms
VIPs and Farms AppDirector VIP-A VIP-B VIP-C Farm-1 Farm-2 Farm-3 Farm-3 slide 28
Dispatch Methods AppDirector VIP Dispatch Methods: Cyclic Weighted Cyclic Fewest Users Least Traffic Fewest Users Local Least Traffic Local SNMP Hashing Response Time Server 1 Server 2 slide 29
Health Monitoring
Health Monitoring Health Monitoring is the process of checking the health of servers to determine the status of a server, place the server in or out of service and perform load-balancing decisions Partners Available server farm before HC: {server 1, server 2, server3,, server n} Radware ADC health monitoring methods include: HTTP, HTTPS, FTP - SAP DNS - Oracle Telnet, Ping - BEA SMTP, DHCP, SNMP, ICMP - MS Exchange Server 1 TCP/UDP port - SIP/UDP, SIP/TCP RADIUS, LDAP, Diameter - More Customers Check server health by simulating a user trying to access an application on the server AppDirector Server 2 Database servers Employees Available server farm after HC: {server 1, server 2, server3,, server n} New connections will be sent only to these servers! Server n Data Center slide 31
Page and Content Checks HTML Code Server Up AppDirector HTML Code Server Down Server 1 Server 2 slide 32
Checking Multiple Services AppDirector FTP Login FTP Login TCP 23 TCP 23 Server 1 Server 2 slide 33
Checking Backend Devices AppDirector 1. Web Page Check 2. App Server Check 3. Database Check Server 1 Server 2 App 1 App 2 Database slide 34
Sample List Of Pre-Defined Checks ARP Citrix ICA Citrix Application Browsing DHCP Diameter DNS FIX FTP HTTP IMAP4 LDAP LDAPS NNTP Physical Port Ping POP3 Radius Accounting Radius Authentication RTSP SIP TCP SIP UDP SMTP SNMP SSL Hello HTTPS TCP Port UDP Port TFTP TCP User Defined UDP User Defined. slide 35
Topologies
Physical Topologies Routing Mode 192.168.1.13 192.168.1.12 AppDirector Router 192.168.1.11 192.168.1.1 4.3.2.1 192.168.1.10 Default Gateway - AppDirector slide 37
Next-Hop-Router per VIP 192.168.1.13 Active AppDirector Router 192.168.1.1 4.3.2.1 192.168.1.12 Switch VIP 1 VIP 2 Switch 4.3.2.253 192.168.1.11 192.168.1.2 4.3.2.2 Router 192.168.1.10 Backup AppDirector 4.3.2.254 Slide 38
Full IPv4/6 Gateway Availability of IPv6 support in AppDirector 2.20 enabled us to be the only ADC vendor receiving IPv6 Ready Logo The IPv6 Logo indicates that the product includes IPv6 mandatory core protocols and can interoperate with other IPv6 equipment Slide 39
Supported Topologies IPv6 Clients IPv4, IPv6 or mixed Servers Client IPv6 Service VIP IPv4 IPv6 S1 S2 S3 S4 Slide 40
Traffic Flow
AppDirector Basics of Traffic Flow In most circumstances, the AD requires that traffic flow bidirectionally through the device-- clients send a request to a Layer-4 policy and the AD forwards the request to a server: the server responds back through the AD. The AD will only load balance traffic that is destined to a matching Layer-4 policy The AD will not intercept other traffic flowing through the device. It will only route it. slide 42
Flow Options There are 4 different possible flow configurations on the AppDirector: Normal Local Triangulation Client NAT Global slide 43
Overview Normal Flow: Client connects to a Layer-4 policy (VIP). AppDirector makes a forwarding decision. Client is sent to a selected Server. Server responds back to Client through AppDirector. slide 44
Overview Normal Flow Client s Request Source IP = 4.3.2.1 Destination IP = VIP 6.6.6.100 Load Balancing Decision Client 4.3.2.1 AppDirector to Client Source IP = VIP 6.6.6.100 Destination IP = 4.3.2.1 VIP VIP (6.6.6.100) AppDirector to Server Source IP = 4.3.2.1 Destination IP = 192.168.1.10 Server to Client Source IP= 192.168.1.10 Destination IP = 4.3.2.1 Server 1 192.168.1.10 Server 2 192.168.1.11 Server 3 192.168.1.12 slide 45
Overview Client NAT Client s Request Source IP = 4.3.2.1 Destination = VIP 6.6.6.100 Client NAT 6.6.6.50 Load Balancing Decision AppDirector to Server Source IP = 6.6.6.50 Destination = 192.168.1.10 VIP Client 4.3.2.1 AppDirector to Client Source IP = VIP 6.6.6.100 Destination = 4.3.2.1 VIP (6.6.6.100) Server to Client Source IP = 192.168.1.10 Destination = 6.6.6.50 Server 1 192.168.1.10 Server 2 192.168.1.11 Server 3 192.168.1.12 slide 46
Overview Global: HTTP and DNS: Client is redirected based on HTTP or DNS and then traffic is the same as a local traffic flow. Triangulation: Client connects to AD A is forwarded to AD B and receives responses from AD B. slide 47
Local Functionality 512 Layer4 Policies AppDirector VIP 1 VIP 2 VIP 3 50.000 logical Servers Farm 1 Farm 2 Farm 3 Note: You can tune the device to support up to 6000 Layer4 policies slide 48
Layer 4 Policies
Layer 4 Policies Virtual IP address Layer 4 Policies farm selection based on network level parameters Layer 7 Policies farm selection based on application level parameters Farm a group of servers that provide a service slide 50
Layer 4 Policies Destination IP = VIP Destination port = 21 Destination IP = VIP Destination port = 53 VIP Destination IP = Selected server Destination port = 21 Destination IP = Selected server Destination port = 53 FTP WWW DNS slide 51
Application - Components of the Layer 4 Policy The Application parameter allows using custom TCP or UDP ports for applications that require special handling, such as HTTP, HTTPS, FTP, SIP, etc. For example, use port 2100 for FTP Control Channel. For well-known protocols, such as 80 for HTTP, there is no need to specify the application. For Virtual IP Interface configuration, the Application parameter must be set to Virtual IP Interface and L4 Port and Protocol to Any. Applications supported include: Any(Default) FTP Control HTTP HTTPS PING REXEC RSH SCTP SIP RTSP TS COOKIE RADIUS TCP TFTP UDP Virtual IP Interface MH-SCTP (MultiHoming SCTP) Generic-SSL (with Layer 4 Port defined) slide 52
Layer 7 Policies
Layer 7 Policies - Example Destination IP = VIP Destination URL = www.green.com Destination IP = VIP Destination URL = www.blue.com VIP Destination IP = Selected server Destination IP = Selected server Green.com Black.com Blue.com slide 54
HTTP Request Header GET / HTTP/1.1 Host: www.radware.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.2). Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: de-de Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive slide 55
Layer 7 Methods A Layer 7 Method defines a specific criteria (namely the existence or non existence of certain specific content within the message), evaluated on a specific part of each handled message. Layer 7 Methods are used in load balancing and modification decisions. A condition will evaluate to TRUE only if all values specified in the method match values appearing in the specified part of the message. Method Type URL File Type Header Field Cookie Regular Expression Text RADIUS Attribute Identifies Hostname and/or path in Host header or in URL for proxy request File type in URL Any Header Field Cookie header in request message String anywhere in the message String anywhere in the message Specified RADIUS attribute value Note: List shows only the methods used in Layer7 policies! slide 56
Layer 7 Policies URL www.red.com Accept- Language: es* URL www.red.com Accept- Language: en* URL www.blue.com Accept- Language: es* VIP URL www.blue.com Accept- Language: en* www.red.com (English) www.red.com (Spanish) www.blue.com (English) www.blue.com (Spanish) slide 57
Persistency Server Load Balancing Bindings Slide 58
Persistency Requirements Successive connections must go to the same server. Data associated with a user Caches requests Firewalls Secured HTTP connections via SSL Persistent load balancing is never even distribution Slide 59
Immediate Bindings Client Load Balancer 1 TCP SYN request 2 Best Available Server selection Real Server 3 TCP SYN request 4 Three-way handshake completion Slide 60
Delayed Bindings Client Load Balancer 1 Client to Alteon TCP 3-way handshake LB records sequence # Client sends 1 st GET 2 Best Available Server selection Real Server 3 Alteon to Server TCP 3-way handshake LB records sequence # Forwards the client s GET 4 Sequence # adjustment and connection splicing Slide 61
Server Binding Mechanisms Two types of binding mechanisms for ADCs Immediate binding Decision about which real server to send the request to is made upon arrival of the TCP SYN packet. Delayed binding Decision about which real server to send the request to is made after the TCP 3-way handshake is completed by the switch. Allows a load balancer to look inside the client s request packet for specifics and bind to the appropriate server Enables advanced load balancing options Layer7 Server Load Balancing Layer7 Redirection Filter SSL Session ID-based Binding for session persistence Cookies-based Binding for session persistence Slide 62
Hash Metric Operation 20.6.7.8 47.1.2.3 Hash Table R1 1 R2 2 R3 3 Hash(20.6.7.8) = 3 R3 R1 4 R2 5 VIP Hash(47.1.2.3) = 7 R1 R3 6 R1 7 R2 8 Command line configuration: /cfg/slb/group x/metric hash Rx 1023 R1 R2 R3 Slide 63
Why Source IP Persistence Mode Does Not Work RIP_1 All connections from clients behind the proxy firewall are redirected to RIP_1. Client #1 RIP_2 Proxy Firewall RIP_3 Same Proxy IP address for all clients Client #2 Many individual users coming from a proxy firewall are directed to a single server. Traffic is concentrated on a single server instead of being load balanced. Slide 64
Dynamic Session ID Example - Cookie Session-ID-Value Session-ID-Identifier slide 65
Dynamic Session ID Example URL-Parameter Session-ID-Value Session-ID-Identifier Page 66
XML Tag based Persistency Allows to preserve persistency according to the value or attributes of a certain XML tag within the XML/SOAP messages body. Case sensitive. Must specify the XML tag and the path (partial or absolute) to the XML tag by which persistency should be maintained. For XML tag attribute add @<attribute_name> at the end of the XML path. Slide 67
Transaction Acceleration
Server Offloading & Application Acceleration Slide 69
Server Offloading & Application Acceleration Enhanced Application Acceleration functions Server offloading: SSL acceleration Client Authentication Caching Content Delivery Acceleration: HTTP Compression Caching TCP optimization Central Certificate repository Improved ADC manageability Slide 70
Demo Conclusions Slide 71
Redundancy
Redundancy Interface Grouping The Problem... Active AD Backup AD VRRP Advertisements Server Farm slide 73
Global SLB
Radware Global Solution Flow Best Site Selection Site Load Network Proximity DNS Redirection Application Redirection Session persistency Slide 75
Site Selection Global Server Load Balancing is based on: Site Load - direct clients to the most available site, according to the site which is the least loaded and has the most operational servers Cyclic Least amount of users Least amount of traffic Windows NT agent SNMP customized Response time Server weights Network Proximity direct clients to the closest site, in terms of: Router hops Latency Radware patented Global solution utilizes both Slide 76
Site Selection cont. AppDirector Calculate network proximity Web-GW1 Calculate site load Calculate network proximity Calculate site load Calculate network proximity Calculate network proximity AppDirector Web-GW2 Slide 77
DNS Redirection Best site selection www.site.com? AppDirector 1 WEB1 www.site.com? DNS Ask DNS NP2 AppDirector 2 WEB2 Best site selection www.site.com=ad2 Slide 78
Application Redirection Application-level redirection methods: HTTP redirection Unique to Radware Global Triangulation Redirection With competitive solutions - 5% of HTTP RTSP redirection transactions are lost HTTPS redirection Case examples: SIP redirection Customers using applications which do NOT use DNS User session already open to another site Proxy redirection How? Wide range of Application Redirection methods Slide 79
HTTP redirection London Site London Site New York Site New York Site Client Client Slide 80
Global Triangulation Redirection London Site London Site New York Site New York Site Client Slide 81
RTSP redirection Redirect RTSP NY HTTP HTTP RTSP London AppDirector RTSP HTTP AppDirector WSD NP Hong Kong HTTP HTTP RTSP RTSP RTSP RTSP AppDirector New York Slide 82
RTSP redirection: Business Benefits Global redirection of RTSP requests Economizes customer s network Audio/video streaming content is kept in fewer locations, no need to replicate Significantly reduces the number of RTSP servers and IT overhead Competitive service through faster response time End users are directed to the best site, based on load and proximity (in environments where RTSP servers are located in more than one site) Slide 83
OnDemand Switch Hardware
Port Density, Processing Power Alteon Platform Portfolio On demand scalable 0-4 Gbps and 1-24 vadcs Alteon 5412 on ODS 3 Alteon 10000 on ODS 4 Alteon 5224 on ODS LS On demand scalable 20-80 Gbps and 1-256 vadcs Alteon VA Alteon 4416 on ODS 2 Alteon 4408 on ODS VL On demand scalable 8-20 Gbps and 1-28 vadcs 1G 2G 4G 8G 20G 40G On demand scalable Soft ADC, running on 0-4 Throughput Gbps (Gbps) general-purpose servers 80G Slide 85
Understanding VADI vadcs are centrally managed and provisioned using AppShape technology vadc provides all ADC capabilities Advanced application services Full L4-7 Routing and networking Resources vadc OS A vadc can represent an application or device Computing Resources Computing Dedicated Resources ADC ADC-VX Alteon VA Slide 86
Radware vadcs and ADC-VX TM Customer Managed Customer Monitor Only Provider Managed Global SLB, Security, ITM On Demand Global SLB Services On Demand ITM Services On Demand Security Services Fully featured ADC Health Checks, Layer 7 Configurations, etc. Layer SharePoint 4-7 Services Layer Oracle 4-7 Services Marketing Layer 4-7 Services Applications Vlans, ARP Tables, Virtual Routing and Forwarding Tables IP Network Domain 1 IP Network Domain 2 IP Network Domain 3 Physical Resources (CPU, Memory, SSL) Private: config file Infrastructure 1Gbps logging statistics Private: config file Infrastructure 2Gbps logging statistics Private: config file Infrastructure 2Gbps logging statistics Slide 87
Radware ADC-VX Solution ADC-VX is the industry s first ADC hypervisor that runs multiple virtual ADC instances Each vadc is private and isolated 30x higher consolidation ratio than the competition! Each vadc performance is reserved, predictable and guaranteed vadcs Highest are instantly vadc density provisioned in the market on demand Best Lowest solution cost for per ADC vadc virtualization and consolidation vadc throughput range 10Mbps to 20Gbps Fit any size and type of customer Has been deployed in more than 100 projects and consolidated more than 1000 ADC devices! Alteon 5224 1-16 Gbps 1-24 vadcs Alteon 5412 8-20 Gbps 1-28 vadcs Alteon 10000 20-80 Gbps 1-256 vadcs Slide 88
Radware Alteon VA Solution Alteon VA is a vadc running on industry-leading hypervisors VMware ESX / ESXi KVM Open XEN Hyper-V Each Alteon VA is a VM in the Virtualization Infrastructure Provides identical functionality to physical ADC Alteon VA throughput options range from 10Mbps up to 1Gbps Slide 89
Alteon 10,000 Platform o o o o Performance o o o o High-end 80G ADC platform Up to 4 processing blades of 20Gbps each Switch blade for internal communication External ports:15 x 10G, 8 x 1G 80 Gbps throughput 1.4M L4 CPS 700K L7 CPS 56M concurrent connections Slide 90
Alteon 10,000 Fully standard ATCA system o ATCA standard adopted by carriers and large enterprises o Designed for low power consumption to reduce OPEX and greener IT o Up to 3 power supply units o Hot swappable blades o Shelf Manager provides chassis monitoring and control o NEBS level 3 compliance Slide 91
Alteon 10,000 and VADI Alteon 10,000 joins Radware s VADI solutions: Running ADC-VX Hypervisor Single vadc on a dedicated chassis with a throughput of 80Gbps ADC-VX on Alteon 10,000 supports up to 80 vadcs Alteon 10,000 fully benefits from all VADI services and can be managed by the Orchestration systems Slide 92
Integration into the Ecosystem First-to-market ADC management SDK & plug-in Provides all management building blocks, workflows and interfaces Fully integrates Radware s vadc to workflow automation Full application delivery resource elasticity Eliminates manual vadc configuration updates Supported orchestration and management systems VMware vcenter Orchestrator VMware vcloud Director Red Hat Enterprise Virtualization (RHEV) Slide 93
Radware ADC Fabric TM Data Center Migrate a vadc from Management & physical Migrate across ADC the Orchestration Cross form factor System virtualized ADC Scale Fabric to meet ADC when redundancy capacity business is needs maxed out A Provision vadc with AppShape technology from catalogue B Radware Application Delivery Fabric Higher resiliency, unlimited scalability, maximum ADC agility, faster application rollout, lower costs Virtualized Application Delivery Infrastructure Applications Network & Storage Virtualized Data Center Slide 94
Radware ADC Provides the Best of Both Models Benefit Legacy Shared ADC Legacy Multiple ADCs Next-Gen Radware ADC Resiliency SLA Agility Operations Scalability Cost Fault isolation between applications Private & guaranteed resources per application Fast & simple application rollout Configuration, troubleshooting, software upgrades Application centric visibility Cost-effectively add new applications & capacity Reduced number of ADC appliances Reduced rack space, power, cooling & service costs Slide 95
Radware ADC Provides the Best of Both Models Benefit Legacy Shared ADC Legacy Multiple ADCs Next-Gen Radware ADC Resiliency Fault isolation between applications SLA Agility Operations Scalability Cost Private & guaranteed resources per application Fast & simple application rollout Configuration, troubleshooting, software upgrades Application centric visibility Cost-effectively add new applications & capacity Reduced number of ADC appliances Complicated Not Resilient Not Predictable Expensive Not Scalable Not Agile vadc per App & AppShape Reduced rack space, power, cooling & service costs Slide 96
Radware vadc per App with AppShape Technology Changes the ADC Paradigm Only Radware ADC! SLA Guarantee Agile Scalable Cost Effective Application centric Slide 97
Management Options
Management Methods Command Line Interface Serial Telnet SSH Web Based Management HTTP HTTPS APSolute API SOAP/XML SNMP (APSolute Vision) V1, V2, and V3 slide 99
Management Dashboard Slide 100
Fast Rollout Using vadc and AppShape Slide 101
Thank You www.radware.com 102