The way we've managed
data has changed rapidly over the last few years,
and the way that we've deployed networks has
changed along with that. We used to have
server farms that would have individual computers
and individual servers inside of them. Let's say that we
had a server farm with over 100 individual servers
all working and connected together with the network. This enterprise
network is usually connecting all of
these devices using multiple VLANs,
redundant connections, and high-speed communication. But with virtual
servers, we've realized that we don't need 100
separate physical servers. Instead, we could create
100 virtual servers that may be located within
one single physical device. So this brings up the
question, that if we're collapsing all of
these servers into one single physical device,
what happens to our network? If we're replacing physical
servers with virtual servers, then we're taking all
of our physical network and we're replacing it
with a virtual network. This is called network function
virtualization, or NFV, where we'll take
all of our network devices and the entire
network infrastructure, and we'll move it directly
into the hypervisor. This means that all of our
switching, all of our routing, our VLANs, our firewalls, and
anything else on the network infrastructure are now contained
within this virtual system. This not only provides us
with the same functionality we had when we had physical
switches and physical routers, but in many cases, provides us
with additional capabilities. For example, when you need a
new switch or a new router, you don't have to go out,
purchase a new router, put it into a rack, power it
up and then physically connect those devices. Instead, you simply click
a few buttons inside of the hypervisor, and
you can drag and drop a brand new router
or a brand new switch into your network
infrastructure. This means that you could
have many different kinds of deployment options for
your virtual machines, your containers, you
can add fault tolerance and different monitoring
services, all from this network function virtualization. As with most virtual systems,
everything starts and ends with the hypervisor. This is our Virtual
Machine Manager, or VMM. This Virtual Machine Manager
is responsible for managing all of the operating systems,
all of the virtual systems, and all of our virtual
network connections that we're deploying
on this virtual system. The hypervisor is responsible
for managing access to the CPU, to memory, and to
the network for all of those virtual
systems, but it can all be managed from this one
Central Management Console. Sometimes you'll
hear this referred to as a single pane of glass,
because instead of visiting all of those individual
virtual systems, you simply go to one
management screen and you can control everything. Here's a better view
of this hypervisor. You can see this one hypervisor
has two different types of virtual regions. We also have different
virtual machines running in each of those regions. You can see that there are 24
processors inside of this one single physical device that's
managed by this hypervisor, with 47 gigahertz of cycles
available for the CPU, 90 gig of memory, and
you can see all of the virtual machines
that are managed by this single hypervisor. Now that we know where all
of our virtual machines are located, and the
device that is managing those virtual
machines, now we need to have a network that connects
all of those virtual machines together. We connect that through a
vSwitch, or a virtual switch. We're simply taking the physical
switch that we used to have, and we've moved it
into the virtual world. We can still do
all of the things that we used to do on
our physical switch. We know how to set all of
the forwarding options. We can configure
link aggregation between different virtual
switches and different servers. We can do port
mirroring and NetFlow to provide additional
management capabilities, even though this is contained
within a virtual environment. And deploying one of
these virtual switches from the hypervisor is simple. You simply drag and
drop, or click a button, and you can deploy one of
these virtual switches. This can also be automated
through the hypervisor's API so that this can be deployed
and removed automatically using orchestration. Here's a better view
of this virtual switch. There's the picture
of the virtual switch. It connects to eight
different networks and four different hosts. You can see all the
different ports-- 553 ports on this
virtual switch-- and all of the things
that is supported by this virtual switch. This supports NetFlow, it
supports Link Aggregation Control Protocol, or LACP,
for providing multiple links for load balancing. We also have port
mirroring, health, check and other features
available on the switch. Inside of your virtual machines
will be a virtual network interface card, or a vNIC. All of these virtual
servers need a vNIC so that they can
then communicate out to the rest of the network. This is usually also configured
through the hypervisor, and you can add additional
functionality or features depending on what you
need on that server. You may need multiple
network interface cards to provide load
balancing, or perhaps you want to add some type
of VLAN capabilities or additional monitoring. All of that can be done
through the hypervisor. Here's a graphical view of
these network connections in the hypervisor. On the right side is the
uplink to the physical network. We have to have some
way to take this data from the virtual world and get
it into our physical world, and these are the interfaces
that provide that. And then in these
different regions, in different virtual
machines, you can see individual
ports are configured. All of these individual
interfaces or vNICs are configured and connected
to the same central network. We can make some of
these networks private, we can associate them
with a different VLAN, and build out as complex
or detailed a network as we might need for
our applications.