So starting off,
I'd like to make sure that you and I
are on the same sheet of music
regarding the basic infrastructure
for the software-defined data center,
or SDDC for short from VMware.
And one of the core components
of that infrastructure is the hypervisor called ESXi.
So ESXi runs on top of hardware,
usually, it's a pretty hefty server
that has lots of CPU, and memory,
and network access through network interface cards.
These days, a lot of those network interface cards
are 10 gigs each. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are 10 gigs each.
And that ESXi host also has some storage,
and that storage could be local
or the ESXi host may have access
to network-based storage as well.
So the hypervisor,
think of it like an operating system
that's running on top of the hardware,
in the case of ESXi,
it's a specialized, dedicated operating system
for host hardware,
that could then provide a home for one or more VMs.
And also with the right licensing,
some containers as well.
So the hypervisor's responsible for doling out
and providing the resources
regarding CPU, and memory,
and network access, and storage, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and network access, and storage,
for each of the VMs or containers
that are running on that hypervisor.
So an individual virtual machine
believes it has access to storage,
and RAM, and CPU, and everything else,
but behind the scenes,
it's all being provided logically
via the hypervisor.
And most environments that are running ESXi
are gonna have more than just one ESXi host.
So here's an example of three ESXi hosts,
each of them with network access,
and with CPU, and RAM,
and either storage or network-attached storage,
and each of them supporting several VMs
that are running on those respective ESXi hosts. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that are running on those respective ESXi hosts.
And to manage multiple ESXi hosts,
we're often gonna use a vCenter server,
which is implemented as a virtual machine.
And then vCenter is interacting with
and managing all the ESXi hosts,
then you and I,
we interact with vCenter to get information
regarding what's going on,
so this is us right here at our management PC.
So we interact with vCenter
and vCenter interacts with each of the ESXi hosts.
And when working with multiple ESXi hosts,
generally, we'll put two or more into a cluster,
and then leverage some really cool features WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then leverage some really cool features
that we can get from that cluster of ESXi hosts,
that are being managed by vCenter,
including cool things like DRS,
distributed resource scheduler,
or being able to move a virtual machine
from this ESXi host to another one,
whether it's powered on or off.
And when implementing the switching
on these ESXi hosts,
it's often a pain to go into each one,
and configure a virtual switch here,
another one here, another one here,
and then if we wanna do vMotion,
or migrate VMs back and forth,
we need to make sure we have the same port groups
on each of the switches,
so oftentimes, we'll use a virtual distributed switch, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so oftentimes, we'll use a virtual distributed switch,
and that way, we can have
a configuration for a virtual switch
be replicated across multiple hosts.
So that way if we want a port group
called port group 10,
and we want it on all three switches,
we create a virtual distributed switch,
we create a distributed port group called, "PG-10."
And then, poof!
Once these three hosts
are all part of that distributed switch,
they will all have that port group.
And then behind the scenes,
that port group will lead
to one or more of the physical NICs,
which are called VMNICs
for access out to the physical world.
So that's all well and good,
However, I would like to point out a few challenges WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, I would like to point out a few challenges
that we are going to fix and address with NSX.
Let me label some VMs,
I'm gonna go ahead and let's name them VM A here,
and then VM B right here,
and VM C.
So VM A is being hosted on ESXi-one,
and ESXi-two is hosting VM B and VM C.
Let's also imagine that each of those VMs
are connected logically to a port group,
and I'll go ahead and put that port group
in the same color here,
that's part of a distributed switch.
And let's imagine each of those port groups WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's imagine each of those port groups
are associated with VLAN 10.
And let's also imagine that this VMNIC right here
with the green cable,
is associated with this switch,
and that this port group is using that uplink.
So this represents VLAN 10.
Now under the covers,
all of this connectivity right here
is gonna be provided by our physical network.
So we may have some top-of-rack switches
and we have VLAN 10 that's accessible
by both ESXi-one and ESXi-two.
And if that's the case, no problem.
So as far as the IP addresses,
VM A could be 10.10.0.11, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
VM A could be 10.10.0.11,
and VM B could be 10.10.0.12,
and VM C could be 10.10.0.13.
And they could all communicate with each other
because they're on the same port group,
And that port group is associated with VLAN 10,
and VLAN 10 is accessible on the physical network
between ESXi-one and ESXi-two.
So with that in mind,
let me ask a couple of questions
and these are gonna lead to a couple problems as well.
And one of those is security.
How do we implement controls
between what can be done between VM A,
for example, and VM B?
Back and forth between each other, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Back and forth between each other,
or VM A to VM C?
Now all three of those VMs are in the same VLAN,
so in the physical world,
we could perhaps do some layer two security
if we knew what the MAC addresses were,
and so forth.
And also if we had the expertise
and time to do that in the physical world.
However, it's a hassle,
because we're bringing up and down
various VMs all the time,
and if we want security involved,
it'd be a pain to have to go
to the physical environment
and identify what the MAC addresses are,
and then try to implement some layer two security
for traffic going back and forth
to control what's allowed. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to control what's allowed.
And it even gets worse
if we wanna start controlling
what services are allowed.
For example, if we wanna allow SSH
between VM A and VM B,
and HTTPS between VM A and VM C,
and maybe ICMP between VM B and VM C,
once again, this can be very tough
to implement it here at the physical network
to control the traffic between those VMs.
So I'll leave a question mark there,
saying there should be a better way
of implementing security between our VMs
in the infrastructure.
Another challenge could be this,
let's imagine that ESXi-one and ESXi-two, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's imagine that ESXi-one and ESXi-two,
behind the scenes on the physical network,
do not have connectivity to that same VLAN 10.
So let's imagine down here,
instead of just having trunking with layer two,
we have a router.
And if that's the case,
ESXi-one and ESXi-two
no longer have access to that same
layer two broadcast domain.
So even though the clients
are using the 10.10.0 address space,
assuming a 24-bit mask up here,
if we don't have a contiguous VLAN
between ESXi-one and two,
VM A cannot be on the same broadcast domain here
as VM B and VM C. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as VM B and VM C.
So over here, if we have a VLAN 10,
and maybe over here, it's VLAN 20,
or even if the numbers are the same on both sides,
VLAN 10 over here,
and VLAN 10 over here on another switch,
because we have a logical layer three router
in the middle of that,
we're gonna have two different broadcast domains,
and as a result,
we cannot have VM A
on the same layer two broadcast domain
with a traditional distributed switch
as VM B and VM C.
And that's because the infrastructure
behind the scenes has a router
between ESXi-one and ESXi-two.
So our next challenge WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So our next challenge
is an extended layer two broadcast domain
when we have a router between the two ESXi hosts.
Because if this is our topology
of the physical world
of the router between ESXi-one and ESXi-two,
we are not going to have an extended
layer two broadcast domain
across these two ESXi hosts.
Another challenge that comes up is routing.
So for example, let's take VM B and VM C,
and let's put VM B in the 20 subnet,
10.20.0, dot, let's use 20,
and let's put VM C in the 30 subnet,
10.30, with a host address of 30 also. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
10.30, with a host address of 30 also.
And so if these devices are in different subnets,
how can we route between them?
So one way of doing that,
we could go ahead and put VM A on one port group,
and put VM B on a different port group here,
and VM C on yet a different port group.
Maybe this is VLAN 40,
and VLAN 50, and VLAN 60.
And let me remove my router down here.
So if these three VMs
are now on three different port groups,
and effectively on three different VLANs,
in the physical world,
we could set up our routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we could set up our routing
between the subnets
10.10.0, 10.20.0, and 10.30.0,
but once again, that is gonna require us
to do that in the physical environment
with logical layer three interfaces
on whatever gear we're using,
from Cisco, or HP,
or Juniper, et cetera.
And although that can be done
in the physical environment,
it'd be much more convenient
if we could set up that routing logically
inside of the virtualized environment.
And while we're talking about
traditional network services,
let's also put a question mark
regarding how do we implement features
like network address translation, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like network address translation,
and DHCP services, and VPNs,
and load balancing, and the list goes on.
And once again, the answer to that
in the physical environment
would be to use the tools that we have.
Either from Cisco,
or Juniper, or HP, et cetera,
and we'd set up those features.
However, it would be a lot more convenient
if we could set up those features
virtually inside of our vSphere environment.
And now is time for the great news.
All these features,
which, with traditional vSphere might be a problem,
can now be solved and done with software WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can now be solved and done with software
once we implement NSX,
and add that to our vSphere environment.