Now, one of the challenges with the NSX application platform in deploying it is
that there's
so many components involved in getting it up and working.
And that's the benefit of using the automation feature to implement the NSX
application platform,
including the Kubernetes cluster that it's going to be using for its
functionality.
So to really appreciate this automation component, let's take a look at what
the automation brings
to the table.
And to assist with that, let's bring out the documentation for the application
platform
automation guide, which is what we want to focus on right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
automation guide, which is what we want to focus on right here.
So in the big picture, the automation regarding the implementation of the NSX
application platform
is going to be performed by coordination between the NSX manager and a special
VM that's used
to automate the process of deploying the NSX application platform.
And that's what this VMware NSX application platform automation guide is all
about.
So if we scroll down a little bit, unless you're in the outline that section
six is
all about troubleshooting in the event, something doesn't go well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
all about troubleshooting in the event, something doesn't go well.
Now I also want to tell you from experience that what cannot go well would be
the underlying
infrastructure, including if DNS isn't working or internet connectivity isn't
working or
reachability between our subnets that are being used by the Kubernetes and as a
result,
the NSX application platform.
I've also experienced the situation where if you're implementing the NSX
application platform
on top of an NSX implemented network that also often causes problems as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on top of an NSX implemented network that also often causes problems as well.
And that's why in the previous skill, we took a look at how to implement on
real VLANs
and real switches and real routers, the infrastructure in a conjunction between
our hardware platforms
and vSphere as the network infrastructure that we were using for the NSX
application platform.
So if you have not yet seen that previous set of videos and that previous skill
on preparing
the network, I would strongly encourage you to take a look at that first.
Because most of the issues and problems are going to come up right here are
going to be
tied to an infrastructure that's not correctly set up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tied to an infrastructure that's not correctly set up.
So as we continue to scroll down, let's take a big picture look at what the NSX
automation
is going to do for us.
And in another shell here, the two stages that the automation is going to bring
to the
table for us and getting the NSX application platform up and running.
And again, behind the scenes, we're going to be using this NSX automation
appliance,
a little VM to do most of that heavy lifting for us.
So in the big picture, the automation appliance working in conjunction with the
NSX manager
and our existing vSphere environment is going to do two big stages. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and our existing vSphere environment is going to do two big stages.
And they are major.
The first one here is going to do Pre-JEX.
It's going to be a content library that's needed for the images as part of the
Kubernetes.
It'll deploy a load balancer that's being used as part of the Kubernetes
cluster.
It'll manage the certificates working in conjunction with vCenter.
It'll enable TKGs on the vSphere cluster.
So TKGs is the Tanzu Kubernetes grid.
Think of that like VMware's method of implementing a Kubernetes cluster.
It's going to create the VMs and storage classes associated with that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to create the VMs and storage classes associated with that.
And it'll do some of the prep work in preparation for the NSX application
appliance.
And it'll also do some other prep work in preparation for the NSX application
platform.
So this first part here, this first phase is all about getting the Kubernetes
side set
up and ready.
So after stage one is done, stage two, along with some additional prep work
here, the bottom
line is going to go ahead and deploy the NSX application platform on top of
that Kubernetes
infrastructure.
And as I mentioned earlier, there's a lot that can go wrong. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as I mentioned earlier, there's a lot that can go wrong.
But if you have the network infrastructure in place first, including DNS
resolution,
time synchronization, routing between all the subnets, and also having a really
good
plan about what IP dressing scheme you're going to use.
Having that correct infrastructure is going to prevent most of the common
problems that
stop people cold when they're trying to use the automation component in
deploying NAP.
So as we scroll down through this document, let's go ahead and take a look at a
diagram.
And I love how it says general requirements because all the nitty gritty WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I love how it says general requirements because all the nitty gritty
details are
actually in the documentation for NAP itself.
And this document is specifically aimed at assisting individuals who want to
use the automation
and getting the NAP deployed, including the Kubernetes cluster setup.
So here are some of the critical components.
You'll notice here that this represents a router.
And in the previous set of videos, we set up our infrastructure.
And I have this as my top of rack switch, which is a multi layer switch
providing the
routing between these three networks.
So this network right here in green and the text here is really small. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this network right here in green and the text here is really small.
I'm going to tell you what these are.
This is our management network.
So we have our ESXI host connected here.
We have our NSX manager connected here.
We have our vCenter connected here.
And this diagram, they have some fault tolerance with more than just one NSX
manager as part
of an NSX cluster.
So in our topology, this is VLAN 11 that we set up in the previous set of
videos.
And the addressing space here is 10.11.11 with a slash 24.
And then my top of rack switch has the IP address of dot one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then my top of rack switch has the IP address of dot one.
And we tested that connectivity in our previous sets of videos.
So we have that VLAN already in place, ready to go.
The next network is showing here is the workload network.
So in our topology, that is VLAN 13.
Using the IP address space there on VLAN 13 of 10 dot 13 dot 13 with a 24 bit
mask and
the default gateway is once again, my top of rack switch here at dot one.
And then this network right here is the front end network, which in our top
ology is VLAN
12, which is using the IP addressing space of 10 dot 12 dot 12 dot zero with a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
12, which is using the IP addressing space of 10 dot 12 dot 12 dot zero with a
24 bit
mask.
And once again, my top of rack switch is at dot one.
And as part of the automation, it's going to deploy for us a little HA proxy
that's going
to be used as part of our Kubernetes environment.
And so one of the core components in making sure everything is going to work is
having
a really good plan regarding what IP addresses we're going to use and where and
that way,
if we're building on top of a already functioning network that we built in the
previous set
of videos, and then we have a good plan for IP addressing and then we implement WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of videos, and then we have a good plan for IP addressing and then we implement
that plan
as part of the automation, that's going to go a long way in avoiding most of
the problems
people are going to have when they implement nap using the automation tool,
again, having
the correct networks in place that are proven functional and then having a good
plan for
implementing all the rest.
So having said that, let's take this idea here.
We are in the network topology, including what we already did in the previous
set of
videos.
And let's lay out a plan.
So here is our existing topology, which we verified in the previous skill.
And this is also the topology we're now going to be using for the actual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is also the topology we're now going to be using for the actual
deployment of the
NSX application platform using the automation appliance to do it.
So let's confirm a few of our components.
I've got DNS up here at 10 dot 10 dot 10 dot 100 and that's going to be
important because
we are going to need to add a couple specific fully qualified domain names that
can be resolved
by our Kubernetes and NSX environment.
So the fact that we already verified that we're using this DNS server and that
's functional,
that's really important.
Now a few other devices that we want to make sure we know what their IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now a few other devices that we want to make sure we know what their IP
addresses are,
as well as their DNS names would be the vCenter.
So I've got the vCenter sitting here on this network segment, the VLAN 11
network, which
is our management network in its IP address is dot 111 and is DNS resolvable
name is
V C S a dash VLAN dash 11 dot O G I T dot lab.
And what I would recommend is that as you're planning out and implementing the
NSX application
platform using the automation VM, I would make sure that each of the components WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
platform using the automation VM, I would make sure that each of the components
we're
using, including vCenter and the NSX manager, etc, are all correctly resolvable
by our DNS
server.
And again, they're going to save you time and troubleshooting later in the
event some
of these names are not resolvable.
So right now as we're documenting these elements, let me go ahead and also do a
quick test just
to verify that other devices on these network segments can do the resolution of
this name
to this IP address using our DNS server.
And because we already have a little VM that we tested earlier in our previous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because we already have a little VM that we tested earlier in our previous
video right
here, let's go to that VM right now and just verify that we can do name
resolution for this
name to that IP address for our vCenter.
So let me bring a little VM.
So this VM represents this computer sitting on VLAN 12 right here.
Let's confirm its IP address.
So what the command line will do an IP address, we could also use IF config
that would also
work.
The IP address is 10 dot 12 dot 12 dot three, and if you do a route dash and it
'll confirm WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
'll confirm
that it's default gateway is 10 dot 12 dot 12 dot one.
And let's also verify we can ping our DNS server up here at 10 dot 10 dot 10
dot 100.
So we'll do a ping to 10 dot 10 dot 10 dot 100.
And that looks good.
So we'll go ahead and stop that.
And let's try name resolution.
And let's do an NS look up.
And there's a couple options here we could use an us look up or another tool
that's doing
DNS resolution for us.
And I also created when I set up all these a records, I also set up reverse
lookup records
as well.
And that's really convenient for verifying names and IP addresses. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's really convenient for verifying names and IP addresses.
So if we did an NS look up for 10 dot 11 dot 11 dot and we're looking for a 111
1 and press
enter.
Here's coming back to the name for that which is VCS a dash VLAN dash 11 dot O
GIT dot lab,
which is absolutely correct.
So one of the benefits of having reverse lookups enabled and reverse look up
records is that
we can actually verify names by plugging in the IP address with an NS look up
instead
of having to type out the full name.
So as far as the name resolution for this network infrastructure for VCS a dash WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as far as the name resolution for this network infrastructure for VCS a dash
VLAN
dash 11 dot O GIT dot lab, that looks great.
So I move that out of the way.
And another VM I have up here is the actual NSX manager.
And that is at dot 121.
And the DNS record I created for it.
In fact, let me go ahead and clean this up just a little bit.
So everything in this lab environment is in the DNS domain O GIT dot lab.
So this NSX manager right here, his name is NSX manager NSX dash MGR to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this NSX manager right here, his name is NSX manager NSX dash MGR to be
specific dash
VLAN dash 11.
And before we get too far along, let's go ahead and verify that in DNS as well.
So we'll bring back our client and let's set the up arrow key and do a reverse
look up
for 10 dot 11 dot 11 dot one two one and press enter and just confirm that name
as well.
NSX dash manager dash VLAN dash 11 dot O GIT dot lab.
Perfect.
So one of the benefits of actually doing this from a VM inside of this
infrastructure is
just to verify in real terms that when other clients try to do DNS to this DNS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just to verify in real terms that when other clients try to do DNS to this DNS
server from
these networks, it's going to have the same results who are verifying step by
step as
we go through that name resolution is working in a Zimplace.
So let me minimize that.
So now that we've verified the IP addresses and the DNS names associated with
our vCenter
and also with our NSX manager, let's continue taking a look at the automation
guide for the
NSX application platform.
So as we continue to scroll down, here we have some of the requirements
regarding connectivity.
So from the front end network going to our Kubernetes, we need to make sure we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from the front end network going to our Kubernetes, we need to make sure we
're allowing
these protocols and ports and then from the management network over to the DNS
server
that we're allowing these ports, which is simply DNS here.
And here showing us in section three dot two is the protocols and ports needed
between source
and destination.
So between the automation appliance and the front end network, we need to make
sure we're
allowing TCP on these two ports and between the automation appliance and the
management
network we need to allow these ports.
This basically just DNS.
Now in my topology, I also have DNS on a network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now in my topology, I also have DNS on a network.
So I want to make sure that I have access to DNS wherever it is from the nap
automation
appliance.
We also should a game plan together regarding what IP address we want to use
for that automation
appliance.
So what I propose we do for the actual automation VM itself that's going to
orchestrate a lot
of this work for us is let's go ahead and put that at dot six on the management
network
of 10 dot 11 dot 11.
So that'll be the automation appliance address once we deploy that VM on our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that'll be the automation appliance address once we deploy that VM on our
network.
In addition, we want to make sure that between this automation appliance and v
Center that
we're allowing TCP port 443 now because we're going to be deploying the
automation appliance
on the same exact management network and we're not setting up any distributed
firewall rules.
Most of these should not be a problem as long as we have reachability from a
routing perspective.
And then between the NSX automation appliance and the NSX managers, we also
need to allow
TCP port 443 as well as TCP port 22 because what's going to happen is this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
TCP port 443 as well as TCP port 22 because what's going to happen is this
appliance that's
going to be doing the automation for us, we can integrate that when we deploy
it with the
NSX manager.
And so to do that is going to be using TCP port 22 to do that.
And that's referred to as the NSX UI plugin registration.
So we can think of it like this little VM once we deploy it being able to
integrate with
and communicate with the NSX manager via a little plugin that it can deploy.
And when we deploy this automation VM, when we tell it, we want to integrate
with the
plugin for the NSX manager will actually see the interface on the NSX manager WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
plugin for the NSX manager will actually see the interface on the NSX manager
change reflecting
the fact that this little automation VM has been added.
As we scroll down, one of the requirements is a basic license for Tanzu, which
by default
is going to give you a short eval period.
Or if you have VMUG advantage, which is $200 US a year, they also give you one
year evaluation
licenses that you can use.
And not just for Tanzu, but also for other things like vCenter and ESXI host
and other
products as well.
And then as we continue to scroll down, it talks about the actual installation WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then as we continue to scroll down, it talks about the actual installation
of the
automation VM.
Now before we actually deploy the automation VM and tell it to start its work,
we also
need to do a little bit of additional planning regarding IP addressing.
So let's take a moment with our existing topology here and consider some of the
requirements
that's going to need for IP addressing and make a plan for what we want to use.
So in the automation guide, I'm looking through it.
I don't see a nice list of exactly the IP addresses that it would like us to
plan for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
plan for.
So let me go ahead and go to an additional resource that's available on the
internet.
And here is a great blog article that's going to help us a lot in setting up
our IP addressing.
And it's called getting started with NSX application platform.
And this is dated November 4th, 2022, which is a while ago, but the information
is still
valid.
So if we scroll down, it's talking about the two ways of installing the NSX
application
platform manually or doing the automated install using the automation appliance
, which is
what we're going to do. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what we're going to do.
And if we scroll down, this is reinforcing the concepts of the networks
involved.
So we already know we have that infrastructure in place.
And here is the nap, I pan planner that I wanted to show you.
So on our management network, in our case, our management network is VLAN 11
with the
address base of 10.11.11 with a 24 bit mask.
We need to plan for an IP address that's going to be used for the HA proxy on
that network.
So in our network, let's use .5 for the HA proxy everywhere, because the HA
proxy is going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
proxy is going
to be up here on the workload network.
So in our case, our workload network is VLAN 13 with the address base of 10.13.
13.
So for the HA proxy VM that is going to deploy, let's use on that network, the
10 13 13 network
with a six dot five for that HA proxy there as well.
And then in our topology for the front end network, we are using VLAN 12, which
is using
the IP addressing space of 10 12 12 with a 24 bit mask.
So on that network, the front end network for HA proxy, let's go ahead and use
.5 as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
.5 as well.
So just as a reminder for the automation VM itself, we're going to put that one
on the
management network and it'll be at .6.
And then for the HA proxy VM, which is going to be deployed as part of the
automation, we're
going to use .5 for each of its interfaces, the HA proxy's interfaces on each
of the networks.
And as part of using the auto VM to deploy nap, anytime it asks us about a
range of addresses,
let's start with .41 on the respective subnet.
And then based on how many IP addresses that it needs, it'll go ahead and use WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then based on how many IP addresses that it needs, it'll go ahead and use
for example,
five or 16 IP addresses starting off with one we specify.
So for our game plan, we'll just specify that we want to use .41 as a starting
IP address
for any ranges that are needed as part of the deployment of nap.
And on the back end, the Cooper Netties cluster that's being used to support
nap.
Then also here on the front end network, this 10 12 12 network, it's also going
to be asking
us about two DNS entries.
And so when we get to that point in the wizard, we'll make sure that we have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so when we get to that point in the wizard, we'll make sure that we have
the DNS entries
mapped to the specific addresses it wants.
So those entries, those DNS entries that we need to create will be two entries
on the
10 12 12 network.
It's very likely you can ask us about a resolvable name that goes to .19 and
also .20.
But again, that could vary based on the IP addresses that we're using and the
ranges we've
selected.
And it comes to that point where it's asking us about the FQDNs, the fully
qualified domain
names that map to specific IP addresses, we'll head over to our DNS server and
make sure
those exist. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
those exist.
And also as part of that, we'd also want to make sure that not only do these
entries
exist, but we'd want to test them from VMs on those respective networks, just
to make
sure that DNS is correctly resolving the name to the respective IP addresses.
So let's update our topology with this information.
So for the HA proxy, this is going to be deployed on each of the networks, the
management front
end and workload, we're going to be using .5 for the actual automation VM that
we're
going to deploy to help orchestrate all of this for that automation VM. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to deploy to help orchestrate all of this for that automation VM.
Let's place it on the management network up here at 10.11.11.
And let's use six for that IP address for the automation via.
So with the HA proxy, that's going to be on the management network, I'll color
code that
in green.
So I'll scoot me on the front end network.
I'll color code that in pink.
And it's also going to be on the workload network.
And I'll color code that with this orange color here.
And then whenever it's asking us about who is your DNS server will point to 10,
10, 10,
100.
Whenever it asks us about NTP services for time synchronization, we'll also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Whenever it asks us about NTP services for time synchronization, we'll also
point to 10.10.10.100.
When the wizard is asking us about the vCenter server, we'll point to this v
Center here at
.111 or use its name.
And I would recommend as you go through using the names as you go through.
And that way when it does pre checks, it can help validate that the DNS is
working correctly.
And whenever it asks us about where your NSX manager is, we'll go ahead and
point it
to this device at 121 once again using the DNS name for that.
And also for ranges of addresses, whenever it asks for those, let's go ahead WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And also for ranges of addresses, whenever it asks for those, let's go ahead
and we'll
start at .41 for IP address ranges that it can use as part of the deployment.
All right.
So with that game plan in mind using the existing network infrastructure from
our previous sets
of videos, our next logical step is to go ahead and deploy the actual
automation VM
which can be used to help orchestrate all of this work.
And that's exactly what you and I get to do in the next video.
So I'll see you there in just a moment.