In this lesson,
we start designing redundant networks.
First, you need to ask yourself,
are you going to use redundancy in the network,
and if so, where and how?
So are you going to do it from a module or a parts perspective?
For instance, are you going to have multiple power supplies,
multiple network interface devices, multiple hard drives,
or are you going to look at more from a chassis redundancy
and have two sets of routers or two sets of switches?
These are things you have to think about.
Which one of these are you going to use,
because each one is going to affect the cost of your network
based on the decisions you make.
You have to be able to make a good business case
for which one you're going to use and why.
For instance, if you could just have a second network
interface card or a second power supply,
that's going to be a lot cheaper than having to have
an entire switch or an entire extra router there.
Now, each of those switches and routers,
some of these can cost 3 or 4 or $5,000,
and so it might be a lot cheaper
to have a redundant power supply, right?
And so these are the things you have to think about
and weigh as you're building your networks.
Another thing you have to think about is software redundancy
and which features of those are going to be appropriate?
Sometimes you can solve a lot of these redundancy problems
by using software as opposed to hardware.
For example, if you have a virtual network setup,
you could just put in a virtual switch
or a virtual router in there,
and that way you don't have to bring another
real router or real switch in.
That can save you a lot of money.
There's also a lot of other software solutions out there,
like a software RAID, that will give you
additional redundancy for your storage devices
as opposed to putting in an extra hard drive chassis
or another RAID array or storage area network.
Also, these are the types of things
you have to be thinking about
as you're building out your network, right?
When you think about your protocols,
what protocol characteristics are going to affect
your design requirements?
This is really important if you're designing things
and you're using something like
TCP versus UDP in your designs,
because TCP has that additional redundancy
by resending packets where UDP doesn't.
This is something you have to consider as well.
As you design all these different things,
all these different factors are going to work together
just like gears.
Each one turns another, each one is going to feed another one,
and the more reliability and availability
you get in your networks
by adding all these components together.
In addition to all this,
there are other design considerations
that we have to think about as well.
Like what redundancy features should we use
in terms of powering the infrastructure devices?
Are we going to have internal power supplies
and have two of those and have them redundant?
Or, are we going to have battery backups or UPSes?
Are we going to have generators?
All of these things are things you have to think about.
And I don't have necessarily the right answers for you,
because it all comes down to a case-by-case basis.
Every network is going to be different
and everyone has its own needs
and its own business case associated with it.
The network that I had at former employers
were serving hundreds of thousands of clients,
and those are vastly different
than the ones that are servicing
my training company right now
with just a handful of employees.
Because when you're dealing with your network design
and your redundancies,
you have to think about the business case first.
Each one is going to be different
based on your needs and your considerations.
What redundancy features should be used
to maintain the environmental conditions of your space?
If you have good power and space and cooling,
you need to make sure that you're thinking about
air conditioning and do you have one unit or two?
Do you have generators on site?
Do you have additional thermal heating or thermal cooling?
All of these things are things you have to think about.
What do you do when power goes down?
What are some of those things
that you're going to have to deal with
if you're running a server farm
that has to have units running all the time,
because it can't afford to go down
because it's going to affect thousands and thousands of people
instead of just your one office with 20 people?
All of these are things you have to consider
as you think about it.
In my office, we made the decision
that one air conditioning unit was enough,
because if it goes down, we might just not work today
and we'll come to work tomorrow.
We can get over that.
But in a server farm,
we need to make sure we have multiple air conditioners,
because if that goes down,
it can actually burn up all the components, right?
So we have to have additional power and space and cooling
that are fully redundant
because of that server infrastructure
that we're supporting there.
These are the things you have to balance in your practices.
And so when you start looking at the best practices,
I want you to examine your technical goals
and your operational goals.
Now, what I mean by that is
what is the function of this network?
What are you actually trying to accomplish?
Are you trying to get to 90% uptime?
Or 95% or 99%?
Or are you going for that gold standard
of five nines of availability?
Every company has a different technical goal,
and that technical goal is going to determine
the design of your network.
And you need to identify that
inside of your budgeting as well,
because funding these high availability-features
is really expensive.
As I said, if I want to put a second router in there,
that might cost me another 3,000 or $5,000.
In my own personal network, we have a file server,
and it's a small NAS device.
We're not comfortable just having all of those
on our devices there.
So we decided we weren't comfortable
having all of our file storage on a single hard drive,
and we built this NAS array instead.
So if one of those drives goes out,
we have three others that are carrying the load.
This is the idea here.
Now, eventually we decided we didn't need that NAS anymore,
and so we replaced that NAS enclosure with a full RAID 5.
Later on, we took that full RAID 5
and we switched it over to a cloud server
that has redundant backups
in two different cloud environments.
And so all of these things work together
based on our decisions.
But as we moved up that scale
and got more and more redundancy,
we have more and more cost associated.
It was a lot cheaper just to have
an eight terabyte hard drive with all of our files on it.
Then we went to a NAS array,
and that cost two or three times that money.
Then we went to a full RAID 5,
and that cost a couple more times than that.
Then we went to a cloud and we have to pay more for that.
Remember, all your decisions here
are going to cost you more money,
but if it's worth it to you, that would be important, right?
And so these are the things you have to balance
as you're designing these fully redundant networks
based on those technical goals.
You also need to categorize
all of your business applications into profiles
to help with this redundancy mission
that you're trying to go and accomplish here.
This will really help you
as you start going into the quality of service as well.
Now, if I said, for instance,
that web is considered category one, email is category two,
and streaming video is going to be category three,
then we can apply profiles
and give certain levels of service
to each of those categories.
Now we'll talk specifically of how that works
when we talk about quality of service in a future lesson.
Another thing we want to do
is establish performance standards
for our high-availability networks.
What are the standards that we're going to have to have?
These standards are going to drive
how success is measured for us.
And in the case of my file server for instance,
we measure success as it being up and available
when my video editors need access it
and that they don't lose data,
because if we lost all our files,
that would be bad for us, right?
Those are two metrics that we have,
and we have numbers associated with each of those things.
In other organizations, we measure it
based on the uptime of the entire end-to-end service.
So if a client can't get out to the internet for an ISP,
that would be a bad thing.
That's one of their measurements.
Now the other one might be what is their uptime?
All these performance standards are developed
through metrics and key performance indicators.
If you're using something like ITIL
as your IT service management standards,
this is what you're going to be doing
as you're trying to run those
inside your organization as well.
Finally, here we want to define how we manage and measure
the high-availability solutions for ourselves.
Metrics are going to be really useful to quantify success
if you develop those metrics correctly.
Decision makers and leaders love seeing metrics.
They love seeing charts and seeing the performance
and how it's going up over time,
and how our availability is going up,
and how our costs are going down.
Those are all good things.
But if you don't know what you're measuring
or why you're measuring it,
it really goes back to your performance standards.
Then, these are the kind of things
that are wasting your time with metrics.
A lot of people measure a lot of things
and they don't really tell you
if you're getting the outcome you're wanting.
I want to make sure that you think about
how you decide on what metrics you're going to use.
Now, we've covered a lot of different design criteria
in this lesson, but the real big takeaway here
that I want you to think about is this.
If you have an existing network,
you can add availability to it
and you can add redundancy to it.
You can retrofit stuff in,
but it's going to cost you a lot more time
and a lot more money.
It is much, much cheaper
to design this stuff early in the process
when you start building a network from scratch.
So, if you're designing a network
and you're asked early on what kind of things you need,
I want you to think about all these things
a redundancy in your initial design.
Adding them in early is going to save you a lot of money.
Every project has three main factors,
time, cost, and quality.
And usually one of these things
is going to suffer at the expense of the other two.
For example, if I asked you to build me a network
and I want it to be fully redundant
and available by tomorrow, could you do it?
Well, maybe, but it's probably going to cost me a lot of money,
and because I give you very little time,
it's going to cost me even more,
or your quality is going to suffer.
So you could do it good, you could do it quick,
or you could do it cheap, but you can't do all three.
It's always going to be a trade off between these three things,
and I want you to remember as you're out there
and you're designing networks,
you need to make sure you're thinking about your redundancy
and your availability and your reliability,
because often that quality is going to suffer
in favor of getting things out quicker
or getting things out cheaper.