- [Instructor] Let's consider how to make our network
more redundant in this video.
The big goal that a lot of network designers have
is called the five nines of availability.
That means that we are up 99.999% of the time.
And if you do the math that translates to only
about five minutes of downtime per year.
However, if we do want to achieve that level of redundancy,
we have to realize it's probably going to increase costs.
Because we're going to have redundant components,
we're going to have redundant power maybe with a UPS
maybe with a generator, we might have redundant routers
to give our end devices more than one gateway
that they could use to get out to the rest of the world.
Using a First Hop Redundancy Protocol
that we'll discuss in our next video.
But those are the types of things that we have to consider
if we want a redundant design,
and you need to decide is the increased cost justified
by an incremental improvement in uptime.
And if we do decide that we want to have
a fault tolerance in our design
which we're going to define as the ability of a device
to continue operation even if one of its components
were to fail.
If we decide that we want fault tolerance,
we need to realize that this might impact performance.
Instead of having two routers share the load,
we've got one router that's bearing the burden
that two routers used to have.
And it can increase complexity because of all of the
redundant connections that can make it
more difficult to troubleshoot.
As a super simple example,
consider a network where we've got
two connections going out to the internet.
Well this is good in that it can increase throughput,
we can send some traffic through one ISP
and some traffic through another ISP.
And it can also provide redundancy.
So if we did have a link that were to fail,
we could continue using the other link.
Even in the LAN portion of our network
we could add some redundant links.
Consider a server connecting into a switch,
some server support what's called NIC teaming,
where we have multiple network interface cards
connected into a switch.
That's going to give us more throughput and redundancy.
And remember your CCNA studies
where we talked about EtherChannel
or Port Aggregation?
Yeah, we could have Port Aggregation between our switches.
Again, it's going to increase throughput
because of load balancing,
but if one or two or even three of those links
we see on screen were to fail,
we are still going to fall back and use any remaining links.
Something else we could do to increase uptime,
is to have redundant servers.
We can have a cluster of servers each of which contained
the same information.
And that would let us maybe take one server out of service
and do some maintenance on that.
And by having multiple servers containing
the same information,
we could load balance across all those different servers.
We could have a load balancing appliance
that let us share the load.
And it's going to give us redundancy because
if one server were to fail,
then another server can take over.
So we're going to get load balancing,
and we're going to get redundancy,
we're going to get better maintenance windows
where we can take something out of servers.
And another big conversation surrounding redundant design
is what we do for disaster recovery.
First, here are a few different types of backups
that I would want you to know about.
First is a full backup.
This is where we're making a full backup,
as the name suggests of all the data on our server.
And whatever our backup media is,
whether it's some sort of external hard drive
or flash storage or even a tape,
we're going to be making a full backup of a server storage
every time we do a full backup.
And that could start to consume a lot of backup resources
and it could take more time.
So what we might want to do instead
is have a differential backup.
And I shouldn't say instead,
we can add on a differential backup to a full backup.
For example, let's say that we do a backup
on Monday night and it's a full backup.
Well on Tuesday night, some of the data has changed
during the day on Tuesday.
And we can do a differential backup
and that differential backup,
is just going to backup the data that has changed
since the previous full backup.
That way that backup is really quick,
and we're not going to consume as much backup media.
It's going to take a little bit longer to restore
because now we have to restore two backups.
We've got to restore the full backup
and then we have to overlay on top of that
the differential backup.
Yet another option is an incremental backup.
This is going to backup all changes since the last full backup,
or the last differential or the last incremental backup.
So for example,
if we had that full backup again on Monday night,
if we were just doing differential backups,
the Tuesday night backup would be changes
that had been made since the last full backup.
So Tuesday's changes basically.
But if we just stuck with a differential backup
and we took another backup on Wednesday night,
it would be everything since again the last full backup.
It will give us all the changes on Tuesday
and Wednesday in that backup.
It's different with an incremental backup
because it's only going to go back as far as
the last two full or differential or incremental backup.
So let's say that I took a full backup on Monday night,
I did a differential backup on Wednesday night,
and I did an incremental backup on Thursday night.
The Thursday night backup would only include changes made
since the Wednesday night differential backup.
The Wednesday night differential backup
that will contain all the changes made since
the last Monday night full backup.
An incremental backup can be performed faster
and take up even less storage than a differential backup.
The downside is when it comes time to restore.
Now we've got to restore a full backup
and potentially a differential backup
in addition to an incremental backup.
Another type of backup we might take
if we're using a virtual machine is called snapshot.
This is going to backup an entire server
including state information.
If you want to return your server to a specific state
with a specific set of files, a specific configuration,
you can take a snapshot inside
of your virtual machine's hypervisor.
One of the downsides to this though,
is we're not able to restore a single file from a snapshot,
while restoring the entire server.
Now, let's talk about disaster recovery options.
If we've got an enterprise data center,
and we had some sort of a natural disaster or maybe a fire,
something that actually destroyed the data center,
what options do we have for getting
things up and going again?
Well there are three main options.
One option is called a cold site.
At a cold site we have an offsite location,
something that's not been damaged by the fire hopefully,
or whatever other natural disaster may have occurred.
And in that cold site we've got floor space available,
we've got power, we've got an HVAC system,
but in addition to just the power
and the HVAC and the floor space,
we don't have any equipment.
So it's going to take quite some time to recover,
if we just have a cold site.
We're going to have to install servers there,
we're going to have to reinstall from backups.
It's going to take a while,
but it's less expensive to have just a cold site
because you're not buying redundant data center equipment.
To lessen the time,
it's going to require to recover
from a natural disaster like that,
we instead might have a warm site.
With a warm site, we still have an offsite location
that's been identified.
We have power, we have HVAC systems,
we have appropriate floor space,
but this time we've got the server hardware.
We don't have to install the server hardware
in this empty room like we would with a cold site.
So here the delay would be simply restoring
from the backups that we had taken.
But if downtime is going to really impact
our company's finances,
we might decide that it's justifiable to have a hot site.
This is what we had when I worked on at Disney World,
we had our main data center,
it was about 200 yards North of Fantasy land.
And we had a hot site in the tunnels underneath
the Magic Kingdom called the utilidors.
And there was a fiber optic connections and with a hot site,
not only do you have power in HVAC,
and you've got your floor space,
you also have a server hardware and synchronized data.
That means every time there is a change
to the main data center,
that change is immediately written to the hot site.
So now if the data center were to go offline,
you're still up and going you've got a hot site
with up to date data.
Now a few terms I want you to know
that surround our network redundancy,
one of them is an SLA a service level agreement.
This is what we tell our users that we're guaranteeing them
about how long a system is going to be down,
if a disaster were to occur.
Another metric that you want to know about,
is the recovery time objective or an RTO.
This can be part of your service level agreement,
and it's going to be the maximum amount of time
that we're going to be offline after a disaster.
And how much data we're going to lose?
That's going to be defined
by the recovery point objective or the RPO.
That's the maximum amount of data that we might lose
during a disaster because,
we haven't taken a backup in 12 hours.
Well, that might represent the maximum amount
of data that we're going to be losing.
And when you're buying equipment
to make your network more redundant,
you should consider the mean time between failures.
What is the average amount of time between failures
of a particular router or switch or UPS as an example?
And also consider how long does it take
to fix something if it goes down?
What is the mean time to repair?
Those are a few network redundancy considerations
to think about when you're doing your network design.
Again, you've got to weigh the cost of adding redundancy
against how valuable that extra little bit
of redundancy is going to be to your company.
You want to think about some of the drawbacks,
how we can maybe overburden a backup piece of gear,
how it's going to be more complex to troubleshoot.
You need to think about what kind of backups
you're going to be taking.
We talked about four different types of backups
in this video and also have a disaster recovery plan.
If there were a natural disaster at your main data center,
what would you do?
Do you have an offsite location identified?
And if so, is it an empty room?
Is it a room with servers in it?
Or is that a room with servers
that are actively synchronizing data
with your primary data center?
That's a look at some network design considerations
when it comes to redundancy.