Mutable Services Technology for Building Resilient Network Infrastructures A joint project of...

NYU

Mutable Services

Technology for Building Resilient Network Infrastructures

A joint project of Arizona State University and New York University

Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 2Mutable Services (NYU and ASU) 2

Project Information

Part of Doug Maughan’s Fault Tolerant Networks program Some of our funding comes from Jay/OASIS

36-month contract started on June 14, 2001

PersonnelPI: Vijay Karamcheti (NYU)

Co-PIs: Partha Dasgupta (ASU), Zvi M. Kedem (NYU)

Rsrch. Scientists: Anatoly Akkerman, Eric Freudenthal

+

Several graduate students


Client 1

Client 2

X

Service reconstitution in the face of DDoS attacks

Project Goal

Mutable services are capable of dynamically relocating themselves when under attack, and selectively informing clients about new location

Y

Y’

Y’


Challenges and Solutions

Several issues How do we relocate services with low overhead? When/where do we move services to? How do we selectively inform only some clients about new location? What happens if one of these clients is responsible for the attack?

Leverage industry-standard component-based frameworks (J2EE, .NET) to (Re)deploy services

incrementally and at low cost Detect anomalous behaviors in

an application-specific fashion

Set up multiple access paths for different client-groups Selective publishing

Provide isolation among these paths by performing admission control at network edge

Our solution combines interior and boundary techniques


Frameworks such as Sun’s J2EE and Microsoft’s .NET have become the industry standard for constructing scalable network services Container environments offer common features

– Naming, communication, transaction support, …

“Best practices” guidelines

Example: A prototypical e-commerce app (Java Pet Store)

Component-Based Application Frameworks

Account

CartOrder

Catalog

Inventory

Session (Stateful)

Session (Stateless)

Entity

Account

Order

Inventory

Catalog

Shopping Cart

inventoryitem

productcategorylineitem

orderstatusorders

account

Web Tier EJB Tier Data Storage Tier


Client A

Y

Distributed Deployment of Component-Based Applications

Two advantages Frontier components isolate the application core from attacks Design patterns encourage state separation efficient replication

Y


PhysicalNetwork

Components

Overview of Approach (1): Service Distribution and Monitoring

Building on top of several Java-based open-source efforts JBoss, Jetty, Tyrex, Castor, …

OverlayNetwork

Extended J2EE container services

Dynamic decomposition Virtualization Access path based

resource allocation Naming, transactions Throttling

ControlNetwork

ControlControl components Monitor application

behavior Trigger exceptions for

deviation from expected behavior

Policy-based reconfiguration


Overview of Approach (2):Dynamic Reconfiguration Algorithms

Upon detecting that the application is unable to deliver desired performance Partition the client ID space Partition the application to create a new access path

– Relocate existing components, instantiate new ones

Partition resources among active paths

Partition A

FrontierComponents

Partition A2

Partition A1

FrontierComponents


Overview of Approach (3):Selective Publishing Infrastructure

Problem: How to inform a subset of clients about the new location of a service’s frontier component DNS-like approaches treat all requests uniformly

Solution: Need a name server that provides authenticated, differentiated responses Generalization of content-based routing

C

Name Server

0 1 2 3

range0: locrange2: loc

ID = { i } Ks-1

ID

1

3

2

Authentication at name server

C

Name Server

0 1 2 3

ID = k0, k1(), k2

()

1

2

3

k0

k10 k1

1

k211k2

10k201k2

00

{ loc } k200, k2

10

Encryption-based authentication


1

2

3

Boundary techniques Edge-based request admission control architecture

Ongoing: DNS-like server/resolver for differentiated response

Interior techniques Detailed case study of wide-area distribution of a component-

based application Analysis of application usage patterns

– Data mining formulation to detect access patterns in web logs

Ongoing: APIs, infrastructure for dynamic component deployment Development of test applications

Evaluation testbed Click-router based WAN emulator

Progress over the last year


(1) WAN Emulator: Testbed for Techniques

Real hosts, emulated link behaviors Use MIT’s Click modular router components to model network links

within a “router” node Components to regulate packet flow can be adapted to simulate bandwidth

restrictions, higher latencies, and packet lossage Sufficient to model inter-host traffic going through a WAN network

A

B

C

D

C-C

D-D

C-DAB-CD

C-C

D-D

C-D


Click-based WAN Emulator: Experience

Used to build a 42-node testbed (15+ subnets) Experiments reported later in

the talk refer to this testbed

High-fidelity emulation of latency and bandwidth properties

Emulator supports dynamic injection of fault behaviors Expressed as changes in link

properties

0.01

0.1

1

10

100

1000

0.125 0.5 2 8 32 128Requested latency (ms)

La

ten

cy (

ms)

Expected

Measured (No background traffic)

Measured (Background traffic of 1 MB/s)

1

10

100

1000

10000

8 32 128 512 2048 8192

Requested BW (Kbps)

Ba

nd

wid

th (

Kb

ps)

Expected

Measured UDP Bandwidth

Measured TCP Bandwidth


(2) Admission Control at the Network Edge

Challenges Distributed requests, distributed server components Coping with server and redirector failure Scaling server capacity to presented load (to meet SLAs)

– Trigger interior reconfiguration

Service

GoldSilver

BestEffort

Redirector


Architecture for Request Admission Control

Architecture enforces rate guarantees at steady state E.g., up to 1500 gold requests will be satisfied every time period

Each redirector maintains implicit queues per service level Every time window, decides fraction to forward to each server

– Linear programming formulation

Based only on aggregate information about traffic characteristics

QiRi

S1

Sk

Sm

Fik

Dik

Aggregate values of

Ri, Qi, Fik, and Dik

Redirectors Servers


Prototype of Admission Control Architecture

Network-layer implementation Service identified by IP, port combination

DuplicateSyn detection

NAT port-allocation table

Linux Virtual Server

IP packet filtering and rewriting,TCP connection management

Spreadreliable group communication,

group membership, node failure

lpsolve

linear programsolver

Scheduler

every time window:Ÿ setup and solve LPŸ configure queue parametersŸ expand/shrink server capacity

Dynamiccombining

tree

Serverheartbeats

User-level

Kernel

ControlMessages

requests

responses

Node Coordination Packet Redirection


100 Gold requests200 Gold requests300 Gold requests400 Gold requests100 Gold requests

0

50

100

150

200

250

300

350

400

450

500

1 61 121 181 241 301 361 421 481 541 601 661

Time (in seconds)

#re

qu

est

s /

seco

nd

Gold (highest priority)

Silver

Bronze

Service Differentiation Architecture: Enforcement of Guarantees

5 redirectors, 5 web servers (capacity = 100 requests/second)


Our project aims to dynamically distribute component-based applications across a wide area

However, such applications are currently deployed statically and usually in a centralized server setting

Two questions Can such applications be incrementally deployed?

Need to deal with several issues, e.g., cross-container JNDI refs

How does distribution affect performance?

(3) Deployment of Component-Based Applications on Wide-Area Networks


Dynamic Deployment Architecture

Application Deployment Manager

1

2

3

RegisteringAgent

A

1 Register application2 Parse/store descriptors

3 Return component graph

4

5

Deployer

4 Request scenario

5 Determine deploymentrequirements

6

A’ A’’ A’’’

6 Customize/pushdescriptors

Y

7

7 Pull components,instantiate

JBossDeployer(internal)

JBoss Containers


Case study: Deployment of an industry-standard e-commerce application on the following network

Measured per-click response times for key usage patterns Browsers: Main – (Category – Product – Item)+ Buyers: Main – Signin – (ShoppingCart)+ – Checkout – PlaceOrder –

Commit – Signout 80% browsers and 20% buyers

Application source modifications to improve performance Restricted attention to reusable design patterns

Performance Impact of Distribution

100 ms

Local clientsRemote clients


Case Study: Performance

91 94

489

541

5774 75

172

0

100

200

300

400

500

600

Local Browser Local Buyer Remote Browser Remote Buyer

Re

spo

nse

Tim

e (

ms)

Base

Remote façade

Stateful component caching

Query caching

Asynchronous updates


A Closer Look at Two Design Patterns:Façade and Component Caching

Local clientsRemote clients

productJSP

catalog

Base

productJSP

catalog

catalogfaçade

itemEJB

itemRO

updater

remotecatalog façade

catalogfaçade

Façade

itemRO

updater

ComponentCaching


Status and Plans

Boundary techniques Early version of the admission

control architecture is available for experimentation

Plans: Remove dependence on Linux

Virtual Server Locality-aware distribution of

requests DNS-like nameserver for

differentiated response

TestbedPlans Incorporation of network attack

and fault models Scalability enhancements

Interior techniques JBoss-based dynamic

deployment infrastructure for J2EE components is available

Plans Extension of the infrastructure

to EJB 2.0 specification Inference of application usage

patterns and anomaly detection

Mutable Services Technology for Building Resilient Network Infrastructures A joint project of...

Documents

Transcript of Mutable Services Technology for Building Resilient Network Infrastructures A joint project of...