Upload
jessica-martin
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 3Mutable Services (NYU and ASU) 3
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’
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 4Mutable Services (NYU and ASU) 4
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 5Mutable Services (NYU and ASU) 5
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 6Mutable Services (NYU and ASU) 6
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 7Mutable Services (NYU and ASU) 7
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 8Mutable Services (NYU and ASU) 8
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 9Mutable Services (NYU and ASU) 9
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 10Mutable Services (NYU and ASU) 10
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 11Mutable Services (NYU and ASU) 11
(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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 12Mutable Services (NYU and ASU) 12
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 13Mutable Services (NYU and ASU) 13
(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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 14Mutable Services (NYU and ASU) 14
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 15Mutable Services (NYU and ASU) 15
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 16Mutable Services (NYU and ASU) 16
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)
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 17Mutable Services (NYU and ASU) 17
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 18Mutable Services (NYU and ASU) 18
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 19Mutable Services (NYU and ASU) 19
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 20Mutable Services (NYU and ASU) 20
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 21Mutable Services (NYU and ASU) 21
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
Mutable Services (NYU and ASU) OASIS PI Meeting – August 20, 2002 22Mutable Services (NYU and ASU) 22
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