Cloud Computing Computer Science Innovations, LLC

Unix Communicate between machines. Unencrypted.... ftp, telnet, rsh Only have encrypted No telnet but ssh, no ftp but scp and no rsh Command is rsync RSA became popular, we wanted private key access to servers.

Unix Communicate between machines. Unencrypted.... ftp, telnet, rsh Only have encrypted No telnet but ssh, no ftp but scp and no rsh Command is rsync RSA became popular, we wanted private key access to servers.

Unix Communicate between machines. Unencrypted.... ftp, telnet, rsh Only have encrypted No telnet but ssh, no ftp but scp and no rsh Command is rsync RSA became popular, we wanted private key access to servers.

Security Assert and Identity. Identity asserters. Initially username and passwords Problem username and password on unencrypted lines. All access to a server must be encrypted. Identity asserters are pluggable. Once you assert an identity, you gather roles.

Best Practices No username password Turn off passwords in /etc/ssh/sshd_config Passwords …. no You only use your private key to get in. To copy we use In the same way as ssh we use scp

Goals Understand Load Balancing. Apply Load Balancing. Understand the Use Case for Load Balancing. Great science is simple.

What is a Session? 1.HTML was designed as a specification on how to represent documents. 2.It was not designed to be a communication protocol across the Internet. 3. It was designed to represent things like word documents. 4. So there are no concepts of Semantics (meaning) and no concept of state. 5. Initially, web pages had no state, so what did we do?

What is State? 1.Finite State Autometa. Alan Turing, Turing Machine? 2. State persists and conditions change. But a web page had no state, so you had to transfer the state from page to page. 3. forward to e, etc, etc. 4. Your whole state would be get parameters on the URL. This was SLOW.

Cookies to the Rescue 1.The server keeps a state for every session. Every user has one to many sessions, typically So every request has the request and the request adds to it a session id, or cookie. Now we get sessions. 3. So the session is a memory resident model of user data.

Serializeable 1. If you wish to transfer data from machine to machine, it must be Serializeable. This is the opposite of Transient. 2. For example, if a war file (web application archive) is accessing a database locally, it has a Database Connection. Does it make sense to transfer that Connection to a machine in China and access the database? transient Connection myConnection; Class created implements Serializeable.

Marker Design Pattern 1. Calling it Serialzeable, marks the class. 2. Calling it Transient, marks the class. 3.Both imply something happens, but you really do not have to concern yourself with how, or even what. Just mark things transient as such. 1.This is how we replicated sessions. It only replicates Serializeable data.

Serializeable 1. Class, a class has a method, the method may be public, private, or package-friendly. 2. Convention. 3. Not security. If a class is serializeable the JVM calls a private method(s) readObject and writeObject. 1.This is how we replicated sessions. It only replicates Serializeable data.

Load Balancing 1.Load balancing is used to divvy up between two or more servers the amount of work usually done by one. 2.Load balancing can be implemented with hardware, software, or a combination of both.

Fault Tolerance Over the Web 1. More than one copy of the Session. 2. How can I do this? 3. Send all messages to multiple servers and have warm stand-bys. 4.NO.. The correct way is to propagate state changes.

Fault Tolerance 1.Systems fault to another and the only lost is a session. 2.Load balancing occurs on a session by session basis. 3. In essence only a shopping cart is lost.

Need for a Solution 1.A traditional standalone (non-clustered) server does not provide any failover or load balancing capabilities. 2.When the server goes down, the entire web site is unavailable until the server is brought back up. 3.Any sessions that were stored in the server's memory are lost and the users have to log in again and enter all of the data lost due to the server crash.

There are two kinds of sessions handled by a server cluster: sticky sessions and replicated sessions. Session Replication

A sticky session specifies that once a session is created by a given server, subsequent requests from the user will continue to be routed to that same server in order to preserve session information. Sticky Session

1.The Service provider uses cookies to relay session information, the load balancer needs to redirect to the server that created the session. 2.Without sticky sessions, all servers would have to be trusted and performance might be impaired. Sticky Session

1.On the other hand, a server that's part of a cluster provides both scalability and failover capabilities. 2.A cluster is a group of multiple server instances running simultaneously and working together to provide high availability, reliability, and scalability. 3.The server cluster appears to clients as a single server instance. Server Clusters

One To Many - Multicast 1.IP multicast is the broadcast technology that enables multiple servers to "subscribe" to a given IP address and port number and listen for messages. (Multicast IP addresses range from to ). 2.Each server instance in the cluster uses multicast to broadcast regular heartbeat messages

1.IP sockets also provide the mechanism for sending messages and data among the servers in a cluster. The server instances use IP sockets for replicating HTTP session state among the cluster nodes. 2.Socket reader threads are always "busy" polling sockets, even if the sockets have no data to read. This unnecessary overhead can reduce performance. Server Communication - IP Sockets

1.Sticky sessions are those sessions that stay on the single server that received the web request. 2.The other cluster members don't have any knowledge of the session state in the first server. 3.If the server that has the session goes down, the user has to again log in to the web site and re- enter any data stored in the session. Sticky Session Solution

In the second session type, the session state in one server is copied to all of the other servers in the cluster. The session data is copied whenever the session is modified. Replicated Session

1.Sticky sessions are simple and easy to handle, since we don't need to replicate any session data to other servers. This results in less overhead and better performance. But if the server goes down, so does all of the session data stored in its memory. 2.Since the session data is not copied to other servers, the session is completely lost – even in transaction. 3.Replication is high overhead and complex. Comparison

Stateless: A stateless object doesn't maintain any state in memory between invocations, since the client and server don't need to store any information about each other. Conversational: A conversational object is dedicated to a particular client for the duration of a session. During the session, it serves all requests from that client, and only requests from that client. State Management of Objects

Cached: A cached object maintains state in memory and uses it to process requests from multiple clients. Implementations of cached services vary in the extent to which they keep the copies of cached data consistent with each other and with associated data in the back-end store Singleton: A singleton is active on exactly one server in the cluster at a time and processes requests from multiple clients. State Management of Objects – Concluded

1.Session data must be serializeable 2.Design the application to be idempotent 3.Store state on the business tier 4.Serialization overhead Programming Considerations