16. Intro: Fault tolerance - multi-tier architecture

 

 

 

 

 

 

 

Welcome to module 3, in this module we want to look at fault tolerance

But for a multi-tier stack.

Right.

So in the previous module we looked at a single instance stack.

Right.

And this was a Essentially the PHP application with the mysql database in the same server.

Right.

And here we saw that although we have some options for recovering from different kinds of failures in

in many of these options we had data loss.

Right.

And we also had downtime in all the three scenarios we had downtime.

And so.

So these are the limitations of the single instance architecture.

Right.

And in this module we want to solve these problems.

So let's see how to how to do that.

And we'll have to create a multi-tier stack so let us also understand why we have to create a multi tier stack

now.

Ok, so first of all downtime, how do we solve that

The way we can solve that is first having multiple instances we have two instances let us say one

and two all right.

And also we should have two zones say A and B.

Right.

And what this means is if an instance fails let's say this instance fails.

So then we have the other one right.

So our application is still up.

Right so we have no down time.

And if the zone fails this one fails then we have the other one.

So again even if there's a failure we have the zone and the other instance in that zone and an application

will be up.

OK.

So this is how we can we can solve this particular problem.

However when we do that we create some other problem which we have to solve as well.

So for instance the mysql database that we had on this.

So right now that we have two servers should we be having do mysql instances.

Right.

And the answer is no you can't you can't have that because some users will write into this

mysql server let's say and some other user who is using the other server will not have access.

They will not have access will not be able to see that data that the first user has created.

And if you have two mysql servers like this on two instances it's very hard to keep them in sync.

OK so so what you have to do is you have to move this database into its own tier we have to move

it into its own tier.

So what we have to do is we have to create an RDS relational database.

Service an RDS instance and our database will reside in this instance and our PHP application in

running in these EC2 instances will communicate with the mysql server in the RDS instance

so we will have both.

Servers we will two servers, we will have both of them talking to the same RDS instance.

And this way our users all our users no matter what server they are using using will have the same view of the data.

Okay so.

So essentially we have to move the database out into its own tier.

We have a similar problem with images.

So remember we have images in our application right.

And the same the same thing happens with images.

Let's say there's one user who creates a new image in this server but there could be another user using

the other server.

And that user will not have access to that image.

Right but not to not see the same image.

So in the same way.

Right.

We have to move images out.

We have a centralize images in a different service and S3 is a great place for images.

So S3 is very good for images videos those kinds of things.

And we will keep our images in S3 OK and the user will then access images from S3 rather than from the EBS

volumes attached to the servers.

OK.

Also remember there's another problem with using multiple instances and that is the user the

user has no way of knowing which server to go to.

All right.

So the user has to be pointed to the load balancer.

So we need a load balancer.

And the user will simply go to the load balancer and the load balancer will then distribute the requests the

user requests to the servers that are running behind it.

Right so something like this and load balancer uses algorithms such as Round Robin

and other algorithms as well.

And distributes the user requests to the multiple instances running behind it.

So just because we want to use multiple instances we end up having to solve many other problems

and the solution is to centralize things images into S3 database into its own tier.

And then we have a way to distribute requests to those servers as well.

So now you can see we have we have taken care of downtime.

Right.

And by the way note that the load balancer is fault tolerant and highly available on its own.

We don't have to do anything.

And so is S3 S3 is also fault tolerant and highly available.

OK.

All right what about data loss.

So we've addressed the downtime issue.

But what about data loss.

So the way we do that is we can use an option with RDS called multi AZ deployment and here.

What happens is so this is multi AZ.

Right.

And what happens here is that our RDS will create a primary server a primary instance and a secondary

instance and these will always be in two different AZs.

So this way if the zone fails or the primary instance or zone fails RDS will fail over to the secondary

instance in the secondary zone.

OK so this gives us fault tolerance in the database

in the data tier as well.

And also the multi AZ option turns on on replication.

Right so this is a replication of data on an ongoing basis and it is also synchronous replication

which means data is saved in both places at the same time both servers have the exact copy of the

data.

Right.

And using this feature what happens is if there's a failure let's say the instance fails.

Right.

Or the storage volume of this instance fails.

Right.

Or the zone fails in all these cases RDS will fail over to the secondary server in the other

Zone.

Right.

And because we have synchronous replication there's no data loss.

And our servers will start talking right.

So our servers will fail over to the other instance.

And they will start talking to the secondary server right they will start talking to the secondary server.

So let's this way we have both fault tolerance.

in terms of downtime we avoid downtime.

And by using RDS's multi AZ we also avoid data loss.

Right.

And remember S3 is highly durable.

So there's no chance of data loss with S3 S3 is highly durable.

Right.

And data will never be lost in S3 mainly because S3 has many copies of the same

data S3 is highly durable.

So for data loss we have two solutions actually one is RDS multi AZ and the other is S3.

It's highly durable on its own.

Okay.

Right.

This is what we are doing in this module essentially we are solving the problems from the previous module.

And in this architecture right.

We have no data loss and we have no downtime.

So this is much better.

Great.

So the rest of the videos in this module and the other instructional material.

Let's see how to implement.

Let's see how to implement this architecture for our stack.

So see you soon.

All right so there is one more thing to be taken care of.

We have covered data loss and downtime.

There's one more thing which we have to address and that is sessions sessions.

So the problem that happens when you use multiple instances behind a load balancer balancer is that the user

right let's say the user is sent to this particular server and the user creates a session on this.

So

right.

the load balancer will send the user to the other server sometimes.

So.

So if it's a round robin the second request that the user makes will we be will be to this particular

server where there is no session there is no session on the server.

So the user will have to log in once again which is not not a great solution.

Right so so.

So this for this problem fortunately load balancer has a solution right and that is call sticky sessions.

Right.

So we have to enable and configure sticky sessions and after we do that what will happen is that user

once she creates a session on the server will be sent to the same server.

So the user will be sent on the same server and not to the other.

So the user will not be sent to the other server only to the same server on which

the session was created.

This solves our sessions problem and will see this aspect of the load balancer as well in this module.

Okay.

So so this is what we want to do.

And in the other videos under this module and also the other instructional material right lets see how

to how to implement this fault tolerant multi-tier multi-tier architecture for our application.