ADC. Application Deiivery Controller.

ADC

Application Deiivery Controller

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

Radware Product Overview Slide 3 Branch Office Customers Partner Data Center Application Servers Web & Portal

Servers ESB Message Queuing System Mainframe Database servers AppWall AppDirector AppXML Inflight

Application Delivery Controller Web Services and XML Gateway

Web Application Firewall HTTP Monitor

WAN Link Optimizer / Load Balancer

Router

Router

LinkProof

LinkProof DefensePro

On Demand Software Option Licenses

Slide 5

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

L o cal L o ad B al an ci n g Glo b al L o ad B alan cin g SSL Of fl o ad in g C ach in g C o mp ression A C L + SYN Pr o tecti o n Ser vi ce & DoS Pr o tecti o n B an d wi d th M an ag emen t Glo b al L o ad B alan cin g A C L + SYN Pr o tecti o n Ser vi ce & DoS Pr o tecti o n B an d wi d th M an ag emen t

IP Communication

• What is SLB / NAT

• Topologies

• Health monitoring

• L4/L7 farm traffic flow

• Session persistancy

• Acceleration

• Global SLB

• Management

• Hardware

Slide 7

Server Load Balancing

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

Source MAC Source MAC Destination MAC VIP MAC

Layer 3 Source IP Client IP Destination IP VIP Checksum B35C Layer 4 Source Port 2165 Destination Port 80 Checksum 037A Slide 10

The Life of an HTTP Request

Slide 11

IPDA 192.168.13.10: SYN ACK-ACK, TCP Port 80

Client

Client Site DNS Server

DNS Lookup for: www.appswitch.com

DNS response with: 192.168.13.10

Client

Web Server IPDA 192.168.13.10: TCP SYN, Dest TCP Port 80

IPDA (client) : TCP SYN-ACK

IPDA 192.168.13.10: HTTP GET (url), TCP Port 80

IPDA (client) : GET RESPONSE (data)

IPDA 192.168.13.10:TCP FIN, Dest TCP Port 80

Basic Frame Flow & Client and

Server Processing

Basic Frame Flow Process

Slide 13

DNS

www.appswitch.com ~ 192.168.13.10 Network Manager

(2) Switch selects best server based on policy.

(3) Response is sent to client via switch. VIP 192.168.13.10 Port 80 10.10.10.1 10.10.10.2 10.10.10.3 (1) DNS resolves incoming request to switch.

Routing Slide 14 10.10.10.1 10.20.30.2 10.10.10.3 Interface 10.10.10.254/24 Interface 192.100.13.1/28

Ensure proper routing

Client: 172.16.3.4:2000

VIP 192.168.13.10 Port 80

Route entry 10.20.30.2

Accessing the VIP Slide 15 DNS www.appswitch.com ~ 192.168.13.10 Network Manager 10.10.10.1 10.10.10.2 10.10.10.3

Access virtual-server IP-address/service

Client: 172.16.3.4:2000 DestIP: 192.168.13.10:80

VIP 192.168.13.10 Port 80

Detect Request

Slide 16

10.10.10.1

10.10.10.2

10.10.10.3

Detect request to virtual-server IP-address/service

Client: 172.16.3.4:2000 DestIP: 192.168.13.10:80 SrcIP : 172.16.3.4:2000 DestIP: 192.168.13.10:80 VIP 192.168.13.10 Port 80 client process

Is request already served?

Slide 17

10.10.10.1

10.10.10.2

10.10.10.3

Is current request already served?

Client: 172.16.3.4:2000 _{client process}

VIP 192.168.13.10 Port 80

SessionTable

Source client-IP:port Dest. VIP: service-port

Yes, Request Already Served

Slide 18

10.10.10.1

10.10.10.2

10.10.10.3

Is current request already served? Yes, send to servers.

Client: 172.16.3.4:2000

SessionTable

Source client-IP:port Dest. VIP: service-port LoadB. Rserver:listen-port

Protocol

client process

VIP 192.168.13.10 Port 80

No, Do Load Balancing

Slide 19

Is current request already served? No, do load balancing

10.10.10.1

10.10.10.2

10.10.10.3 Client: 172.16.3.4:2000 _{client process}

VIP 192.168.13.10 Port 80

SessionTable

Source client-IP:port Dest. VIP: service-port

SessionTable

Source client-IP:port Dest. VIP: service-port LoadB. Rserver:listen-port Protocol

Send Request to Real Server

Slide 20

10.10.10.1

10.10.10.2

10.10.10.3

Send request to real-server

Client: 172.16.3.4:2000 SrcIP: 172.16.3.4:2000 DestIP: 10.10.10.3:80 client process VIP 192.168.13.10 Port 80

Real Server Responds Slide 21 10.10.10.1 10.10.10.2 10.10.10.3 Real-server responds server process Client: 172.16.3.4:2000 VIP 192.168.13.10 Port 80 SrcIP:10.10.10.3:80 DestIP: 172.16.3.4:2000

Service Map Table VIP - Real-server 1 …

VIP - Real-server x SessionTable

Source client-IP:port Dest. VIP: service-port LoadB. Rserver:listen-port Protocol

Client Processing Slide 22 TCP MAC Dst MAC Src MAC Src IP Address Dst IP Address Src Port Dst Port CIP VIP 2155 80 Client virt_mac router_mac CIP VIP 2155 80 Application Switch rip_mac CIP RIP 2155 80 rip_mac CIP RIP 2155 80 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

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.

Slide 23

Session table contain at minimum SrcIP, Sport, DestIP, Dport and protocol

Server Processing Slide 24 TCP MAC SrcMAC DestMAC Src IP Address Dst IP Address Src Port Dst Port VIP CIP 80 2155 Client vip_mac VIP CIP 80 2155 Application Switch rip_mac RIP CIP 80 2155 rip_mac RIP CIP 80 2155 Real Server

Server processing is enabled on a per-port basis under /cfg/slb/port #/server ena.

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.

Alteon SLB Terminology

Real Server – Actual server connecting to Real IP (RIP) – Real server IP Address

Group – Group of real servers for load balancing

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

Metrics – Used to select which real server in a group receives the client request

Weights – Bias load balancing to give the fastest real servers a larger share of connections Real Server Port (rport) – Defines the real server TCP or UDP port assigned to the service

Slide 26

Health Check – Only available server in a group receive the client requests

slide 28 VIPs and Farms

Farm-1 _Farm-2 Farm-3

VIP-A VIP-B VIP-C

AppDirector

slide 29 Dispatch Methods VIP Server 1 _{Server 2} AppDirector

Dispatch Methods:

• Cyclic

• Weighted Cyclic

• Fewest Users

• Least Traffic

• Fewest Users Local

• Least Traffic Local

• SNMP

• Hashing

Health Monitoring

Employees Customers Partners Data Center Database servers AppDirector Server 1 Server 2 Server n

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

Available server farm before HC:

{server 1, server 2, server3, …, server n}

Available server farm after HC:

{server 1, server 2, server3, …, server n}

New connections will be sent only to these servers! Check server health by simulating a user trying to

access an application on the server…

Radware ADC health monitoring methods include:

– HTTP, HTTPS, FTP - SAP

– DNS - Oracle

– Telnet, Ping - BEA

– SMTP, DHCP, SNMP, ICMP - MS Exchange – TCP/UDP port - SIP/UDP, SIP/TCP – RADIUS, LDAP, Diameter - More…

slide 32 Page and Content Checks

Server 1 _{Server 2} AppDirector

HTML Code

“Server Up”

HTML Code

“Server

Down”

slide 33 Checking Multiple Services

Server 1 _{Server 2}

AppDirector

FTP Login FTP Login

TCP 23 TCP 23

slide 34 Checking Backend Devices

Server 1 _{Server 2}

AppDirector

App 1 App 2

Database

1. Web Page Check

2. App Server Check

slide 35 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 37 Physical Topologies – Routing Mode

AppDirector

Router 4.3.2.1 192.168.1.1 192.168.1.10 192.168.1.11 192.168.1.12 192.168.1.13

Slide 38

Next-Hop-Router per VIP

Switch Switch Backup AppDirector Active AppDirector Router 4.3.2.254 4.3.2.2 4.3.2.1 192.168.1.1 192.168.1.10 192.168.1.11 192.168.1.12 192.168.1.13 192.168.1.2 Router 4.3.2.253 VIP 1 VIP 2

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

Supported Topologies Slide 40 S1 S2 S3 S4 Service VIP Client IPv6 IPv4

IPv6 Clients

IPv4, IPv6 or mixed Servers

slide 42

AppDirector – Basics of Traffic Flow

• In most circumstances, the AD requires that traffic flow

bi-directionally 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 43 Flow Options

There are 4 different possible flow configurations on the

AppDirector:

• Normal

• Local Triangulation

• Client NAT

slide 44 Overview

Normal Flow:

– Client connects to a Layer-4 policy (VIP).

– AppDirector makes a forwarding decision.

– Client is sent to a selected Server.

slide 45 Overview – Normal Flow

VIP (6.6.6.100) Client – 4.3.2.1 Server 1 192.168.1.10 Server 2 192.168.1.11 _192.168.1.12 Server 3 Client’s Request Source IP = 4.3.2.1 Destination IP = VIP – 6.6.6.100 Load Balancing Decision 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 AppDirector to Client Source IP = VIP – 6.6.6.100 Destination IP = 4.3.2.1 VIP

slide 46 Overview – Client NAT

VIP (6.6.6.100) Client – 4.3.2.1 Server 1 192.168.1.10 Server 2 192.168.1.11 Server 3 _192.168.1.12 Client’s Request Source IP = 4.3.2.1 Destination = VIP – 6.6.6.100 Load Balancing Decision AppDirector to Server Source IP = 6.6.6.50 Destination = 192.168.1.10 Server to Client Source IP = 192.168.1.10 Destination = 6.6.6.50 AppDirector to Client Source IP = VIP – 6.6.6.100 Destination = 4.3.2.1 VIP Client NAT 6.6.6.50

slide 47 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 48 Local Functionality

AppDirector

Farm 1 _{Farm 2 Farm 3}

512 Layer4

Policies VIP 1 VIP 2 VIP 3 50.000 logical _Servers

slide 50 Layer 4 Policies

Farm – a group of servers that provide a service

Layer 7 Policies – farm selection

based on application level

parameters

Virtual IP address

Layer 4 Policies – farm selection based on network

slide 51 Layer 4 Policies FTP WWW DNS VIP Destination IP = VIP Destination port = 53

Destination IP = Selected server Destination port = 53

Destination IP = VIP Destination port = 21

Destination IP = Selected server Destination port = 21

slide 52

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)

slide 54 Layer 7 Policies - Example

Green.com Black.com _Blue.com

VIP

Destination IP = VIP Destination URL = www.blue.com

Destination IP = Selected server Destination IP = VIP

Destination URL = www.green.com

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 HTTP Request Header

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 Identifies

URL Hostname and/or path in Host header or in URL for proxy request

File Type File type in URL Header Field Any Header Field

Cookie Cookie header in request message Regular Expression String anywhere in the message Text String anywhere in the message RADIUS Attribute Specified RADIUS attribute value

slide 56

slide 57 Layer 7 Policies

www.red.com (English)

VIP

www.red.com (Spanish) www.blue.com (English) www.blue.com (Spanish) URL – www.red.com

Accept- Language: es*

URL – www.blue.com Accept- Language: es*

URL – www.red.com Accept- Language: en*

URL – www.blue.com Accept- Language: en*

Persistency Server Load

Balancing Bindings

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

Immediate Bindings

Slide 60

Client Load Balancer

Real Server

“Best Available Server” selection TCP SYN request

TCP SYN request

Three-way handshake completion

1

2

3

Client to Alteon

Delayed Bindings

Slide 61

Client _{Load Balancer}

Real Server

“Best Available Server” selection TCP 3-way handshake

LB records sequence # Client sends 1st _GET

TCP 3-way handshake LB records sequence # Forwards the client’s GET

Sequence # adjustment and connection splicing

1

2

3

4

Server Binding Mechanisms

Slide 62

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

Hash Metric Operation

Hash(20.6.7.8) = 3 R3

Slide 63 R1 1 R2 2 R3 3 R1 4 R2 5 R3 6 R1 7 R2 8 Rx 1023 Hash Table

Hash(47.1.2.3) =

7

R1

R2 R1 R3 20.6.7.8 47.1.2.3

Command line configuration: /cfg/slb/group x/metric hash

Why Source IP Persistence Mode

Does Not Work

• 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 Client #1 Client #2 Proxy Firewall RIP_1 RIP_3 RIP_2

Same Proxy IP address for all clients

All connections from clients behind the proxy firewall are redirected to RIP_1.

slide 65

Dynamic Session ID Example - Cookie

Session-ID-Identifier

Dynamic Session ID Example

– URL-Parameter

Page 66

Session-ID-Identifier

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 69

Slide 70

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

Demo Conclusions

slide 73 Redundancy – Interface Grouping

The Problem . . .

Active AD Backup AD

Server Farm VRRP Advertisements

Radware Global Solution Flow

•

Best Site Selection

– Site Load – Network Proximity

•

DNS Redirection

•

Application Redirection – _{Session persistency} Slide 75

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

Site Selection

Radware patented Global solution utilizes both

Site Selection – cont.

AppDirector Web-GW1 Web-GW2 AppDirector Calculate site load Calculate site load Calculate network proximity Calculate network proximity Calculate network proximity Calculate network proximity Slide 77

DNS Redirection WEB1 AppDirector 1 WEB2 AppDirector 2 DNS www.site.com? www.site.com=AD2 Ask DNS NP2 www.site.com? Best site selection Best site selection Slide 78

Application-level redirection methods:

•

HTTP redirection

•

Global Triangulation Redirection

•

RTSP redirection

•

HTTPS redirection

•

SIP redirection

•

Proxy redirection Application Redirection

Unique to Radware

With competitive solutions - 5% of HTTP

transactions are lost

•

Case examples:

– Customers using applications which do NOT use DNS

– User session already open to another site

• How?

– Wide range of Application Redirection methods

HTTP redirection

Client

New York Site

London Site

Slide 80

London Site _{New York Site}

Global Triangulation Redirection

New York Site

London Site

Slide 81

London Site _{New York Site}

RTSP redirection WSD NP AppDirector AppDirector New York RTSP RTSP RTSP London RTSP HTTP Hong Kong HTTP HTTP HTTP HTTP Redirect RTSP NY RTSP RTSP Slide 82 AppDirector

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)

Alteon Platform Portfolio

Throughput (Gbps) P o rt De n sity , P ro ce ss in g P o w e r 1G 2G 4G 8G 20G 40G Alteon 4408 on ODS VL Slide 85 Alteon 4416 on ODS 2

Alteon 5412 on ODS 3 _{Alteon 10000 on ODS 4}

80G

Alteon VA

Alteon 5224 on ODS LS

Soft ADC, running on general-purpose servers On demand scalable 0-4 Gbps On demand scalable 0-4 Gbps and 1-24 vADCs On demand scalable 8-20 Gbps and 1-28 vADCs On demand scalable 20-80 Gbps and 1-256 vADCs

Understanding VADI Computing Resources vADC Slide 86

Computing Resources

• Dedicated ADC

• ADC-VX

• Alteon VA

vADC provides all ADC capabilities

• Advanced application services • Full L4-7

• Routing and networking • Resources

• OS

A vADC can represent an application or device

vADCs are centrally managed and

Radware vADCs and ADC-VXTM On Demand Services Infrastructure Layer 4-7 Services Network Global SLB SharePoint 1Gbps IP Domain 1 Customer Managed Global SLB, Security, ITM

Fully featured ADC Health Checks, Layer 7

Configurations, etc. Vlans, ARP Tables, Virtual Routing and Forwarding Tables Physical Resources (CPU, Memory, SSL) Private: config file logging statistics On Demand Services Infrastructure Layer 4-7 Services Network ITM Oracle 2Gbps IP Domain 2 On Demand Services Infrastructure Layer 4-7 Services Network Security Marketing Applications 2Gbps IP Domain 3 Customer “Monitor Only” Provider Managed

Private: config file logging statistics Private: config file logging statistics Slide 87

ADC-VX

is the industry’s first ADC hypervisor that runs multiple virtual

ADC instances

• Each vADC is private and isolated

• Each vADC performance is reserved, predictable and guaranteed

• vADCs are instantly provisioned on demand

• Best solution for ADC virtualization and consolidation

Has been deployed in more than 100 projects and consolidated more

than 1000 ADC devices!

Radware ADC-VX Solution

Alteon 5412 8 - 20 Gbps 1 - 28 vADCs Alteon 5224 1 - 16 Gbps 1 - 24 vADCs Alteon 10000 20 - 80 Gbps 1 - 256 vADCs Slide 88

30x higher consolidation ratio than the competition!

• Highest vADC density in the market

• Lowest cost per vADC

• vADC throughput range – 10Mbps to 20Gbps

• Fit any size and type of customer

• 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

Radware Alteon VA Solution

Alteon 10,000

Slide 90

• Platform

o High-end 80G ADC platform

o Up to 4 processing blades of 20Gbps each

o Switch blade for internal communication

o External ports:15 x 10G, 8 x 1G • Performance o 80 Gbps throughput o 1.4M L4 CPS o 700K L7 CPS o 56M concurrent connections

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

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

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)

Virtualized Application Delivery Infrastructure

Radware ADC FabricTM

Virtualized Data Center Network & Storage

Applications Data Center

Management &

Orchestration System

Migrate a vADC from physical ADC to

virtualized ADC Provision vADC with

AppShape technology from catalogue

Scale to meet business needs

Slide 94

Migrate across the ADC Fabric when capacity is maxed out

A B

Cross form factor redundancy

Radware Application Delivery Fabric

–

Higher resiliency, unlimited scalability, maximum ADC agility,

faster application rollout, lower costs

SLA Private & guaranteed resources per application

Benefit

Legacy Shared ADC Legacy Multiple ADCs Next-Gen Radware ADC

Operations Configuration, troubleshooting,

software upgrades

Application centric visibility

Radware ADC Provides the Best of Both Models

Slide 95

Cost Reduced number of ADC appliances Reduced rack space, power, cooling & service costs

Scalability Cost-effectively add new

applications & capacity

Resiliency Fault isolation between applications

SLA Private & guaranteed resources per application

Benefit

Legacy Shared ADC Legacy Multiple ADCs Next-Gen Radware ADC

Operations Configuration, troubleshooting,

software upgrades

Application centric visibility

Radware ADC Provides the Best of Both Models

Slide 96

Cost Reduced number of ADC appliances Reduced rack space, power, cooling & service costs

Scalability Cost-effectively add new

applications & capacity

Resiliency Fault isolation between applications

Agility Fast & simple application rollout Complicated

Not Resilient Not Predictable Expensive Not Scalable Not Agile vADC per App & AppShape

Radware vADC per App with AppShape

Technology Changes the ADC Paradigm

Only Radware ADC!

✔

_{SLA Guarantee}

✔

_Agile

✔

_Scalable

✔

_{Cost Effective}

✔

_{Application centric}

Slide 97

slide 99

Management Methods

• Command Line Interface

• Serial • Telnet • SSH

• Web Based Management

• HTTP • HTTPS

• APSolute API

• SOAP/XML

• SNMP (APSolute Vision)

• V1, V2, and V3

Management Dashboard

Fast Rollout Using vADC and AppShape

Thank You

www.radware.com