Hola, soy Elver Sena Sosa. Now we are
talking about networking architecture, or
network architecture for vSAN.
If you have ever talked to a network engineer, or better yet, if you're a vSphere
administrator or storage administrator, and you talk to a network engineer,  you know
by now that they are the people that are
the most intelligent. Or at least that's
what they think. No offense to my peer
network engineers. The question is
how do we structure this, or how can you talk to them so that they can provide the
networking services that you require to
have a functioning vSAN environment? So,
this is the recommendation that I have
come up with that can help you ask a few
questions to the network engineer, so
they know what to provide without you
telling them what to do. Because god
knows that the biggest sin you can do
to a network engineer is to tell them
what to do.
You never do that, that's bad! So this is what you should do. First, let me
explain what you will need and then
we'll go with the question. One thing that you
will need, and being a vSphere
administrator you should know that you
need a management vmkernal port.
That's, you need that right? You need to
connect to the host and that's gonna go
to a port group so when I say port group
think VLAN. vMotion, you want your vMotion right? And you don't connect that
to the same port group as the management vmkernal port. You could, but don't do
it, right? So that's a different port
group, right? VLAN again if you're doing
NSX, right? You're gonna have your VXLAN be
in kernal ports. Again, port group right?
And you might have a full tolerance and
so forth, but because those i want to
keep a simple and you're going to add
the next one which is the vSAN
vmkernel port, again another port group
right? And that's the stuff for the host
and now you're gonna have one or more, if you
have NSX you have a bunch of port groups, but that they won't be excellent. But,
you're gonna have more groups, port groups, one or more that are for your production
stuff, right? The be VM traffic where you connect your VNICs for the most part and
those port groups are going to connect, I
strongly suggest you put that in a
distributed switch. The vsphere of the distributed switch has to weigh more
than the networking features of the standard vSwitch. The standard vSwitch would work,
but you're gonna be missing some
stuff like network I/O and so forth. So,
you do that. We haven't connected
this to anything yet just the
configuration, and this is what you do
next and and I know it's challenging
sometimes to come up with these numbers, but you need to that kind of guesstimate a lot
of this. How much traffic, how
much traffic, how much traffic, how much
traffic, how much traffic? Add all of that traffic up.
Then you take a single vmknics, a
physical interface on that house, and fit
all that traffic into that single
interface. That's how you do it.
If this is a hundred MB then this is
one gig. If this is three gig then this
is 10 gig. If this is 15 gig then this is 25
gigs, right? You could do 40, but yes stay
away from 40, not good. Or not that
recommended. So, you do that put a lot of
stuff in there. Now one caveat, if this is
a 100 MG you could put it on one gig
but if this is the all-flash vSAN
solution this has to be 10 gig, no options.
You have to go take it, because otherwise VMware does not support it. So
you put one interface, period. Then you
connect that to a single physical switch,
right? Which we like to call the top of the rack. Now as you can see we have single
point of failures, and that's where the
second link comes in to a different top
of rack switch. Either one is a single point of failure. So what you have with this
design is that in case of a link failure
you do not have degraded
performance when traffic fails over to
the other link. You don't have that. If
your business is struggling, has a budget
constraint, and you cannot do this then
you might pay all the things. But then
you have to document the fact that they
might have degraded performance in case of a link failure. So there you have it,
kind of what the design looks like, but
by itself it is not sufficient. So what you
want to do next is that you want to do
this, LACP. But, that presents a potential
problem because you have two switches
and LACP doesn't work across two
switches, unless you lie to LACP and you
create a multi-chassis link aggregation
an MLAG. Now you can do LACP. So this is what the design should look like, or what I
recommend that it looks like. So how
do I turn all of this into questions that I
can ask the network team so they can
provide the services that I need without
us telling the network team what to do? So first question you ask for, this
isn't like a question this is more like my requirement,
I need VLANS, right? 1, 2, 3.. you count
how many VLANS you need. When you ask
for VLANs they're gonna come back and
ask you about default gateways and
subnets, right? Now you can't come up with the subnets, they do. They own the IP address
in space. So you ask that question. Second question you say, second thing, I need 2X
vmnic. Is that 10 gig or 25 gigs? You say that you need two with hardware redundancy, and two top of racks.
You tell them that and they will know what to do. So you say I need two
vmnic going to different switches,
that's it and they have to be ten gigs.
Then you ask this, I need link
aggregation, LACP. The moment you tell
them this they know they had to provide
you this, and there you have it. Also when
you tell them this, they know that all these VLANS have to
be reachable through the LACP so they
can trunk the VLANS there. Finally,
well not finally, but in addition. I'm sure
there's something in the back of my head that is not
coming out right now. There is always a
question about MTU. I want to put a note
here that's number 5, QoS, and I'll come
back to that in a
second. There is a question about MTU.
Should I keep it at 1500 default or
should I make it a jumbo frame? Jumbo
frames are anything bigger than 1500. So it
turns out that for vSAN, vSAN doesn't care. It works more or less the same.
Whether you're doing 1500 or 9000, which is the most that the vDS can do. So you don't care
for vSAN purposes. However, there might
be virtual machines that care.  VMotion
can perform better, right, because it
would perform faster. VXLANS
requires, for NSX,  requires 1550 jumbo frame but you go with 1600 anyway
just in case. That's VMware's recommendation. So what you do is, see it doesn't
matter for vSAN. Just request 9000 jumbo frame, it doesn't hurt anything and you
just have it. It really doesn't hurt
anything.
So, oops sorry wrong window. That was meant to be right here. Although that can be configured
there. Now for the QoS. Oh oh oh, something else for LACP. I'm gonna put it
here since I kind of made a mess right
here. For the LACP, there is something
called the hashing algorithm. Basically
how egress traffic is going to go out
because vSAN is gonna have vmkernal port talking to a lot. The best
way to use the LACP is to do a hash of
an IP hash. The network team if they ask
you, you say "Hey, IP hash works." They
probably work anyway. Whatever has to
happen in the ingress doesn't affect what
you have to configure on the egress. So IP hash
for LACP. Finally, for QoS for the most
part you won't need QoS unless this link
right here, or both of them, are heavily
utilized which is causing buffering
problems over here on the physical
switches. That's where QoS will come in,
when too much stuff is coming in and
something has to wait. If you require QoS
you need to talk to the network team to
ask them what class of service, that's
layer two, do I need to use for management, vMotion, VXLAN, and so forth.
Actually for VXLAN that will be
inherited from whatever the VM is
sending. For vSAN, because it's a
storage traffic, chances are pretty good
that they're going to give you a CoS of
3. That's usually reserved for storage
traffic drive like our channel wide iSCSI,
right? Especially if they are doing datacenter vision there. For the layer three, which is a
DSCP. For that one they will give you a
number that, they might not need to give
you the numbers, sorry, because usually the DSCP marking happens here. For the most
part that's kind of it for the network
design. If you go with something like
this you are extremely likely guaranteed
that you will have a performing network that
will meet the requirements for vSAN. One more thing before I close out
the video, the up links here if this is a
vSAN hybrid, oh I'm sorry all-flash
If this is 10 gig, these up links
have to be 10 gig or higher. Hopefully it
will be 100 gig if available, but 40 will do.
Anything that is higher, you want it to go
up, because vSAN requires a 10 gig
for the all-flash from end-to-end and
that has to do with something called
port to port latency, right? The speed has
to be quick.And this is kind of a very
high level network architecture for vSAN.
I want to thank you all for watching.
I am Elver Sena Sosa, have a lovely day!
 
