• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Management on Cloud 2011
 

Management on Cloud 2011

on

  • 478 views

 

Statistics

Views

Total Views
478
Views on SlideShare
478
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Management on Cloud 2011 Management on Cloud 2011 Presentation Transcript

    • Sticky Session Support in Auto Scaling IaaS Systems Michele Stecca , Luca Bazzucco, and Massimo Maresca Follow me on Twitter: @steccami E-mail: m.stecca@cipi.unige.it Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) Washington D.C., July 9 th 2011
    • Agenda
      • Introduction
      • Web Apps’ Session Management
        • Session Stickiness
        • Session Stickiness in Elastic Architectures
      • Architectural Solutions for Session mgmt
      • Session Management in the Eucalyptus IaaS system
      • Conclusions
    • 1. Introduction
      • Design Issues
      • How can we manage HTTP Sessions?
        • Session Replication?
      • Where are Session data stored?
        • DB vs. in-memory?
      • How many servers do we need?
        • Under- vs. Over- provisioning problems
      • What if we migrate such an architecture in elastic systems like IaaS?
        • Session Management? Load Balancer support?
      The deployment schema of a scalable system supporting the execution of Web Applications
    • 2. Web Apps’ Session Management (1/4)
      • Session Stickiness: general aspects
      • Sticky Sessions
        • The Load Balancer can be configured to redirect the HTTP requests related to the same Session to the same back-end node
        • Back-end nodes are independent and don’t need to share Sessions’ data
        • Sessions data are usually stored in-memory
      • Non Sticky Sessions
        • The Load Balancer can dispatch the HTTP requests regardless the specific Session they belong to
        • Back-end nodes need to share the Sessions’ data
        • Session data can be stored in-memory (a Session replication mechanism is needed) or in a common Database
    • 2. Web Apps’ Session Management (2/4)
      • Session Stickiness: comparison
      • Sticky Sessions
        • The Load Balancer is supposed to keep track the ongoing Sessions to dispatch HTTP requests correctly
        • Back-end nodes are independent and doesn’t need to share Sessions’ data (no synchronization overheads are added)
        • In case of a node failure all the Sessions running on that node are lost
      • Non Sticky Sessions
        • A “dumb” Load Balancer is allowed
        • Back-end nodes need to share the Sessions’ data (e.g., by means of specific protocols like JGroup)
        • Robust solution from a Fault Tolerance point-of-view (Sessions’ data are shared among back-end nodes)
    • 2. Web Apps’ Session Management (3/4)
      • Session Stickiness in elastic architectures (1/2)
      • Elastic means that the number of back-end servers may change according to different metrics (e.g., the number of incoming requests, the response time of the servers, etc.)
        • Number of Servers can increase ( scale-up operation)
        • Number of Servers can decrease ( scale-down operation)
      • We focus on migration of Sticky Session-based systems to elastic architectures because Sticky Sessions:
        • Don’t need to share a consistent state (e.g., through the JGroup protocol)
        • Provide better performance
        • Often fulfill also the Fault Tolerance requirements (i.e., for non-mission-critical applications like e-commerce)
    • 2. Web Apps’ Session Management (4/4)
      • Session Stickiness in elastic* architectures (2/2)
      • The scale-up operation is safe by construction (we are adding resources)
      • The scale-down operation is
        • Safe in the Non Sticky case (Session Data are replicated)
        • Not safe in the Sticky case (by removing a back-end server we are also removing all the Sessions running on it)
        • OUR AIM IS SUPPORTING SCALING DOWN OPERATIONS IN THE STICKY CASE WITHOUT LOSING ONGOING SESSIONS
      • *In this paper “elastic architecture” = “IaaS system”
    • 3. Architectural Solutions for Session mgmt (1/5)
      • Session Monitoring (1/2)
      • Definition: a back-end server is in “zombie-mode” when it can process ongoing sessions while it cannot process new sessions
      • The Scaling down operation is performed as follows:
        • Choose one of the active back-end servers to be turned off and call it Terminating Server – TS
        • Put TS in zombie-mode
        • Start monitoring the number of active sessions in TS (the Load Balancer stores this information)
        • When the number of active sessions in TS = 0, issue a “turn off” command for TS in the IaaS system
    • 3. Architectural Solutions for Session mgmt (2/5)
      • Session Monitoring (2/2)
      • Advantages
        • It is easy to implement
        • The Load Balancer is supposed to provide only one “additional” functionality (i.e., retrieveActiveSessionsForBackEndServer)
        • It can be applied to all available Web Servers because they don’t need to be changed
      • Disadvantages
        • It doesn’t minimize the expenditures because TS isn’t turned off immediately
        • The mechanism is vulnerable to attacks consisting of keeping sessions alive for long time
    • 3. Architectural Solutions for Session mgmt (3/5)
      • The Scaling down operation is done as follows:
        • Choose one of the active back-end servers to be turned off and call it Terminating Server – TS
        • The Load Balancer invokes the migrateSessions service in TS(1 in Fig.)
        • Migration of TS’ sessions to another Web Server called NewServer through the acceptSessions service (2 in Fig.)
        • While the migration is in progress the Load Balancer buffers all the requests directed to TS. Turn off TS as soon as the Migration phase is ended
        • From now on the Load Balancer redirects all the requests originally directed to TS to NewServer
      • Session Migration (1/2)
    • 3. Architectural Solutions for Session mgmt (4/5)
      • Session Migration (2/2)
      • Advantages
        • It leads to money savings because TS is immediately turned off
        • It doesn’t suffer attacks consisting of keeping sessions alive for long time
      • Disadvantages
        • It is more complicated to implement
        • The Load Balancer must support more complex functionalities like “buffering”
        • Web Servers must provide the migrateSessions and acceptSessions APIs
        • In order to create a “generic” autoscaling system, Web Servers should provide standardized APIs
    • 3. Architectural Solutions for Session mgmt (5/5)
      • Session Monitoring vs. Session Migration
      • Session Migration allows money savings because TS is immediately turned off but…
      Web Servers don’t provide standardized APIs thus… We chose the Session Monitoring approach for secure scale-down operations in Sticky Session elastic systems. We added such a feature to the Eucalyptus Open Source IaaS system.
    • 4. Session mgmt in the Eucalyptus IaaS system (1/4)
      • Overview of the Eucalyptus system
      • It is an Open Source IaaS system compliant with Amazon EC2 interfaces
    • 4. Session mgmt in the Eucalyptus IaaS system (2/4)
      • Components added to the Eucalyptus system
      • The Load Balancer, the Monitor, and the Control Daemon
    • 4. Session mgmt in the Eucalyptus IaaS system (3/4)
      • The Monitor is in charge of monitoring the actual resource usage of each running instance in the back-end
        • Implemented in Java
      • The Load Balancer supports the “zombie-mode” as well as provides the number of active sessions for each server
        • We extended the HaProxy Open Source Load Balancer which supports hot-reconfiguration
      • The Control Daemon interacts with other Eucalyptus components to start/stop virtualized servers on the basis of performance indicators
        • Implemented in Java
    • 4. Session mgmt in the Eucalyptus IaaS system (4/4)
      • Scaling-down operation implementation
      • The Control Daemon detects the need to perform a Scaling-down operation;
      • The Control Daemon sets the Terminating Server in zombie-mode. From now on all new sessions will be forwarded to other servers;
      • The Control Daemon periodically polls the Load Balancer until all the sessions associated to the terminating node have expired;
      • When all the sessions associated to the terminating node have expired, the Control Daemon turns off the TS VM and it updates the Load Balancer configuration by removing the entry related to the terminated virtual machine.
    • 5. Conclusions
      • We described the issues related to Web Apps’ Session mgmt in scalable architectures
      • We identified and compared two possible solutions for safe scaling down operations in Sticky systems (Session Migration vs. Session Monitoring)
      • We described in details both the solutions
      • We implemented the Session Monitoring approach in the Eucalyptus IaaS system supporting a safe Scaling-down operation
      • In the future we plan to perform evaluation tests on the prototype.
    • Thank you for your attention! Follow me on Twitter: @steccami Email: m.stecca@cipi.unige.it Michele Stecca