RightScale User Conference NYC 2011 -
Joshua Solomin - Senior Product Marketing Manager, Zend Technologies
It's a common pain point among PHP developers: How do you achieve application-level elasticity while never losing a user session when you scale down servers? Now there's a push-button solution from Zend and RightScale that enables persistent sessions and allows you to readily triage problems with your business-critical PHP applications. This session will introduce you to an auto-scaling PaaS solution specifically designed to make it easier for you to deploy and manage cloud-based, highly available PHP server clusters.
Achieving Massive Scalability and High Availability for PHP Applications in the Cloud
1. PHP in the Cloud: Achieving True High Availability Joshua Solomin Senior Product Marketing Manager, Zend Technologies joshua.s@zend.com
2. Who is Zend? Leader in software and services for development, deployment and management of enterprise PHP applications RightScale Partner jointly producing the RightScaleZendDev & Test Pack (2010) and RightScaleZend Solution Pack (2011) Co-founders Andi Gutmans and Zeev Suraski created PHP3 PHP community leader & contributor through PHP advisory boards, core dev contributions, Zend Framework, SimpleCloud Zendsolutions are deployed at more than 40,000 organizations
3. Realizing IaaS scalability at the platform level We all love the cloud! Particularly for platforms… But IaaS doesn’t automatically handle application-level HA
4. What does high availability require? No single points of failure Multiple web servers Multiple load balancers Database replication Provided by the cloud, managed by RightScale Graceful failover when individual components DO fail But how does the PHP platform fail over – what about running applications?
5. A closer look at application user sessions HTTP is a stateless protocol – there is no “user session” The good news: this makes HTTP highly scalable and versatile The bad news: representing user state is left to the implementation A basic use case: identifying logged in users If I get two consecutive HTTP requests, how can I know that they are from the same user? How can I know if that user has logged in or not, before I authorize some actions? PHP sessions to the rescue!
7. But when a node fails, how do you prevent session loss?
8. Different Session Handling Mechanisms Default: stored in local files… but doesn’t easily scale >1 node A sticky load balancer can help, but has downsides NFS is a bad idea Can switch to other save handlers Database Memcached or …
9. Zend’s Session Clustering A PHP Session storage mechanism designed to be: Scalable Fault-tolerant Fast Cloud ready Sessions stored either in memory or on disk Daemons in a cluster talk to each other to share sessions Each session stored on two servers: master and backup
11. How does it work? New session created on the server that receives request (master) Master server picks a backup, and copies the session to it Session IDs identify the session’s master and backup servers If the request ends up at any non-master server, session is requested from the master
14. Scalability & Cloud Readiness Session Clustering provides a Graceful Shutdown mechanism At shut down, a node transfers all its sessions to a different server All cluster members notified to use the replacement server Rarely takes more than 30 seconds Graceful Shutdown allows spinning down machines without losing sessions Allows simple scaling down as well as scale up – ideal for the cloud!
15. Enterprise PHP in the Cloud: IaaS + PaaS New service co-developed by RightScale and Zend Instant provisioning of a pre-configured, multi-server PHP runtime environment in the cloud Portable across cloud providers – Amazon, Rackspace, Cloud.com Automated scaling at the server and PHP levels Management, monitoring and diagnostics Usage-based pricing
17. Application Monitoring Watches your application for: PHP Errors (including warnings, notices, uncaught exceptions...) Failing functions Failing DB queries Slow functions or DB queries Slow request executions High memory consumption When an issue is detected, an event is reported
18. Diagnostics: Code Tracing Reproducing problems is often difficult and time-consuming Zend Server captures the full execution flow in testing or production Allows the developer to “step back in time” and quickly determine root cause Integrated with Zend Studio
20. Next Steps Learn more about Zend Server: http://www.zend.com/server Learn more about the Rightscale-Zend solution: http://www.rightscale.com/products/plans-pricing/zend-solution-pack.php Watch the RightScale-Zendwebinar: http://www.rightscale.com/info_center/webinars/paas-in-a-box-zend.php
23. PHP sessions to the Rescue! PHP provides a built-in mechanism for handling user sessions A Session ID identifies a series requests as belonging to a specific user session The Session ID is sent by the browser to the server through a Cookie or a GET/POST parameter A Session Save Handler is used by PHP to store semi-persistent session data There are multiple Session Save Handlers out there, and switching between them usually requires no code changes
24. Sessions vs. Cookies HTTP Cookies can also be used to store user-specific semi-persistent data and through this represent state Unlike PHP Sessions, Cookies are stored on the client side Data stored in a cookie should not be trusted by the application Cookie data is sent back and forth between the browser and the server on each request Storing larger amounts of data in a cookie is impractical Cookies are a very good way to pass a session ID
25. How Zend’s Session Clustering Works Session Clustering is composed of two main parts: The Session Clustering Extension (mod_clustersave handler) The Session Clustering Daemon (“SCD”) Most of the work is done by the daemon The extension is mostly responsible for getting PHP to talk to the daemon Sessions are stored either in memory or on disk Daemons in a cluster talk to each other to share sessions Each session is stored on two servers: a master and a backup serve
26. High Availability If the Master Server goes down… The server receiving the request will get the session from the backup server instead The backup server will designate itself as the new master The backup server will pick a new backup server If the Backup Server goes down… The master server will pick a new backup server The user’s Session ID is changed to reflect these changes
Downsides of sticky LB: Performance and load distribution, according to many high-load users Redundancy (server goes down, sessions are lost) Ability to scale down (sessions are removed along with server)
Why “almost” any? Some apps hard-code the session storage mechanism, for whatever reason (for example Drupal, requires special plugins or code modifications to use other session save handlers) Some apps modify the session ID. This is usually a bad idea, with SC it will not work (we will later see why)
Demo: show how a Session Clustering Session ID looks like
May skip to the next slide and talk about this when showing the diagram
Can skip to next slide and talk about this slide without showing it