UNIT – V

Ready for the cloud

Syllabus :

Web application design, machine image design, privacy design, database

management: clustering or replication , primary key management, database
backups.

Web application design :

illustrates the generic application architecture that web applications share.

System State and Protecting Transactions :

⮚ The defining issue in moving to the cloud is how your application manages its
state. Let’s look at the problem of booking a room in a hotel.
⮚ The architecture from Figure 4-1 suggests that you have represented the room
and the hotel in a model. For the purposes of this discussion, it does not
matter whether you have a tight separation between model, view, and data, or
have mixed them to some degree.
⮚ The key point is that there is some representation of the hotel and room data
in your application space that mirrors their respective states in the database.
⮚ The process might look something like this basic sequence:
1. Lock the data associated with the room.

2. Check the room to see whether it is currently available.

3. If currently available, mark it as “booked” and thus no longer

available.
 4. Release the lock.

The problem with memory locks :

⮚ You can implement this logic in many different ways, not all of which will succeed in the
cloud. A common Java approach that works well in a single-server environment but fails in a
multiserver context might use the following code

⮚ Because the code uses the Java locking keyword synchronized, no other threads in the current
process can make changes to the room object.
⮚ If you are on a single server, this code will work under any load supported by the server.
Unfortunately, it will fail miserably in a multiserver context. The problem with this example
is the memory-based lock that the application grabs.
⮚ If you had two clients making two separate booking requests against the same server, Java
would allow only one of them to execute the synchronized block at a time. As a result, you
would not end up with a double booking.
⮚ On the other hand, if you had each customer making a request against different servers (or
even distinct processes on the same server), the synchronized blocks on each server could
execute concurrently.
⮚ As a result, the first customer to reach the room.book() call would lose his reservation
because it would be overwritten by the second.
The second client overwrites the first, causing a double-booking
Machine Image Design :
⮚ Two indirect benefits of the cloud are:
• It forces discipline in deployment planning
• It forces discipline in disaster recovery
⮚ Thanks to the way virtualized servers launch from machine images, your first step in
moving into any cloud infrastructure is to create a repeatable deployment process that
handles all the issues that could come up as the system starts up.
⮚ The machine image (in Amazon, the AMI) is a raw copy of your operating system and
core software for a particular environment on a specific platform. When you start a
virtual server, it copies its operating environment from the machine image and boots
up.
⮚ If your machineimage contains your installed application, deployment is nothing more
than the process of starting up a new virtual instance.
Amazon Machine Image Data Security
⮚ When you create an Amazon machine image, it is encrypted and stored in an Amazon
S3 bundle.
⮚ One of two keys can subsequently decrypt the AMI:
• Your Amazon key
• A key that Amazon holds
⮚ Only your user credentials have access to the AMI. Amazon needs the ability to
decrypt the AMI so it can actually boot an instance from the AMI.
What Belongs in a Machine Image?
⮚ A machine image should include all of the software necessary for the runtime
operation of a virtual instance based on that image and nothing more.
⮚ The starting point is obviously the operating system, but the choice of components is
absolutely critical. The full process of
⮚ establishing a machine image consists of the following steps:
1. Create a component model that identifies what components and versions are required to
run the service that the new machine image will support.
2. Separate out stateful data in the component model. You will need to keep it out of your
machine image.
3. Identify the operating system on which you will deploy.
4. Search for an existing, trusted baseline public machine image for that operating system.
5. Harden your system using a tool such as Bastille.
6. Install all of the components in your component model.
7. Verify the functioning of a virtual instance using the machine image.
8. Build and save the machine image.
 Software necessary to support a MySQL database server

Privacy Design

Privacy in the Cloud The key to privacy in the cloud—or any other environment—is the strict
separation of sensitive data from nonsensitive data followed by the encryption of sensitive
elements. The simplest example is storing credit cards. You may have a complex e-commerce
application storing many data relationships, but you need to separate out the credit card data from
the rest of it to start building a secure e-commerce infrastructure.
It’s a pretty simple design that is very hard to compromise as long as you take the following
precautions:

• The application server and credit card server sit in two different security zones with only web
services traffic from the application server being allowed into the credit card processor zone.

• Credit card numbers are encrypted using a customer-specific encryption key.

• The credit card processor has no access to the encryption key, except for a short period of time (in
memory) while it is processing a transaction on that card.

Database management :

● The problem of maintaining database consistency is not unique to the cloud. The cloud
simply brings a new challenge to an old problem of backing up your database, because your
database server in the cloud will be much less reliable than your database server in a
physical infrastructure.
● The virtual server running your database will fail completely and without warning. Count on
it.Whether physical or virtual, when a database server fails, there is the distinct possibility
that the files that comprise the database state will get corrupted.
● The likelihood of that disaster depends on which database engine you are using, but it can
happen with just about any engine out there.
● Absent of corruption issues, dealing with a database server in the cloud is very simple. In
fact, it is much easier to recover from the failure of a server in a virtualized environment
than in the physical world: simply launch a new instance from your database machine image,
mount the old block storage device, and you are up and running.
Clustering:

 The most effective mechanism for avoiding corruption is leveraging the capabilities of a
database engine that supports true clustering.
 In a clustered database environment, multiple database servers act together as a single
logical database server.
 The mechanics of this process vary from database engine to database engine, but the result
is that a transaction committed to the cluster will survive the failure of any one node and
maintain full data consistency.
 Unfortunately, database clustering is very complicated and generally quite expensive.
• Unless you have a skilled DBA on hand, you should not even consider undertaking
the deployment of a clustered database environment.
• A clustered database vendor often requires you to pay for the most expensive
licenses to use the clustering capabilities in the database management system
(DBMS). Even if you are using MySQL clustering, you will have to pay for five
machine instances to effectively run that cluster.
• Clustering comes with significant performance problems. If you are trying to cluster
across distinct physical infrastructures—in other words, across availability zones—
you will pay a hefty network latency penalty.
 The alternative to clustering is replication. A replication-based database infrastructure
generally has a main server, referred to as the database master. Client applications execute
write transactions against the database master. Successful transactions are then replicated
to database slaves.

Replication:

Replication has two key advantages over clustering:

 It is generally much simpler to implement.
 It does not require an excessive number of servers or expensive licenses.

A simple replication (arrows show dependency)

By separating read operations to execute against slaves, your applications can scale without clustering
  Another reason to leverage replication is performance.
 Without segmenting your data, most database engines allow you to write against only the
master, but you can read from the master or any of the slaves.
 An application heavy on read operations can therefore see significant performance benefits
from spreading reads across slaves.

Primary Key Management:

 With a web application operating behind a load balancer in which individual nodes within
the web application do not share state information with each other, the problem of cross
database primary key generation becomes a challenge.
 The database engine’s auto-increment functionality is specific to the database you are using
and not very flexible; it often is guaranteed to be unique only for a single server.

How to generate globally unique primary keys

First, you could use standard UUIDs to serve as your primary key mechanism. They have the
benefit of an almost non-existent chance of generating conflicts, and most programming
languages have built-in functions for generating them. I don’t use them, however, for three
reasons:
• They are 128-bit values and thus take more space and have longer lookup times than the
64-bit primary keys I prefer.
• Cleanly representing a 128-bit value in Java and some other programming languages is
painful. In fact, the best way to represent such a value is through two separate values
representing the 64 high bits and the 64 low bits, respectively.
• The possibility of collisions, although not realistic, does exist.

In order to generate identifiers at the application server level that are guaranteed to be unique
in the target database, traditionally I rely on the database to manage key generation. I
accomplish this through the creation of a sequencer table that hands out a key with a safe key space.

The sequencer table looks like this:

CREATE TABLE sequencer (
name VARCHAR(20) NOT NULL,
next_key BIGINT UNSIGNED NOT NULL,
last_update BIGINT UNSIGNED NOT NULL,
spacing INT UNSIGNED NOT NULL;
PRIMARY KEY ( name, last_update ),
UNIQUE INDEX ( name )
);

The following Python example illustrates how to generate a pseudorandom unique person ID:

import thread
import random
nextKey = −1;
spacing = 100;
lock = thread.allocate_lock();
def next():
try:
lock.acquire(); # make sure only one thread at a time can access
if nextKey == −1 or nextKey > spacing:
loadKey();
nextId = (nextKey * 100000);
nextKey = nextKey + 1;
finally:
lock.release();
rnd = random.randint(0,99999);
nextId = nextId + rnd;
return nextId;

You can minimize the wasting of key space by tracking the allocation of random numbers and
incrementing the nextKey value only after the random space has been sufficiently exhausted.
The further down that road you go, however, the more likely you are to encounter the
following challenges:
• The generation of unique keys will take longer.
• Your application will take up more memory.
• The randomness of your ID generation is reduced.

Database Backups

Good database backup strategy is hard, regardless of whether or not you are in the cloud. In
the cloud, however, it is even more important to have a working database backup strategy.

Types of database backups:

Most database engines provide multiple mechanisms for executing database backups. The
rationale behind having different backup strategies is to provide a trade-off between the impact
that executing a backup has on the production environment and the integrity of the data in
the backup. Typically, your database engine will offer at least these backup options (in order
of reliability):
• Database export/dump backup
• File system backup
• Transaction log backup

To execute a database export on SQL Server, for example, use the following command:
BACKUP DATABASE website to disk = 'D:\db\website.dump'
The result is an export file you can move from one SQL Server environment to another SQL
Server environment.

Most databases provide the option to export parts of the database individually. For example,
you could dump just your access_log table every night. In MySQL:
$ mysqldump website access_log > /backups/db/website.dump

The following SQL will freeze MySQL and allow you to snapshot the filesystem on which the
database is stored:
FLUSH TABLES WITH READ LOCK

Applying a backup strategy for the cloud

The best backup strategy for the cloud is a file-based backup solution. You lock the database
against writes, take a snapshot, and unlock it. It is elegant, quick, and reliable. The key cloud
feature that makes this approach possible is the cloud’s ability to take snapshots of your block
storage volumes.
 Execute regular full database exports against a replication slave

For the purposes of a backup, it does not matter if your database slave is a little bit behind the
master. What matters is that the slave represents the consistent state of the entire database at
a relatively reasonable point in time.

Once the backup is complete, you should move it over to S3 and regularly copy those backups
out of S3 to another cloud provider or your own internal file server.
Your application architecture should now be well structured to operate not only in the Amazon
cloud, but in other clouds as well.

Assignment Cum Tutorial Questions

1)Explain the web application design with a neat diagram.
2)Write a MySQL Procedure for stored Processes of Transactions for event “Booking a Room
in hotel”
3)Explain Machine image design
4)Explain Privacy Design
5)Explain how clustering or replication is used by the cloud in database management
6)Explain the primary key management
7)Explain how database backups are performed
8)Explain how machine image belongs in a machine image design