Welcome back to BSphere 8 in the real world. Now we'll discuss connecting to storage.
So, in order to connect to storage, you're going to need a storage adapter.
If you're trying to connect to local storage, you'll have a storage controller, you know,
in that server that connects you to those disks and that's how you're connecting to your storage.
If you're using a SAN, you're going to have an HBA.
You might have an iSCSI HBA. You might have a fiber channel HBA.
You might have a software, what's called a software initiator or a software, you know, basically HBA.
So, you can have a software iSCSI initiator or you can have a software fiber channel over Ethernet initiator.
So, a SCSI adapter would just be an adapter in the system in your server that, you know,
cables connecting to drives and using SCSI commands from this card over those cables to those drives that are in that server.
iSCSI is sending SCSI commands, again, to drives, but now we're encapsulating those SCSI commands in IP
and then we're sending them over a network.
Now, if we have an HBA, what that means is we have a card that is, you know, an intelligent card, a smart card,
that has a chip on it that knows how to speak iSCSI.
So, the iSCSI host can take that workload, offload it to the HBA, and let the HBA manage all the IP stuff,
all the, you know, all the checks on the disk and, you know, putting the encapsulation on there
and sending it out over the network.
And then when it comes back in, again, the card can check the packets, make sure that they're valid, you know,
remove all the IP and just send the operating system SCSI instead of having to always have to do all that IP work as well.
iSCSI HBAs are not really as common as you might think.
A lot of times if you're doing iSCSI, it's because you're trying to do less expensive than fiber channel.
And a lot of times if you're doing iSCSI are using what's called a software initiator,
which means they have like a 10-gig NIC in their system, but it's just a regular NIC.
It's not an HBA.
It's not a smart card necessarily.
And the kernel is doing a lot of that work.
Back when processors were slower, you could see a huge improvement by having iSCSI HBA,
like maybe like 30 or so percent improvement in performance and a huge reduction in CPU utilization.
With CPUs being so much faster than they used to be, and, you know, networks are still very fast.
They're only getting faster.
You're seeing more and more people being willing to take a smaller performance hit and save the money from the HBA.
But there are also more and more people who are starting to buy these smart adapters,
and the smart adapters can handle things on the card kind of in a flexible way.
You can say I want this card to be an iSCSI initiator and offload the work to there or a function over Ethernet initiator.
Or what you can do is say this card's got four ports.
I want two of them to be regular IP ports and two of them to be iSCSI HBA ports and, you know, things like that.
So there's a lot of different things happening, and which is going to be the trend in the future, who knows.
For a while it was starting to go more and more just regular software initiator,
but now you're starting to see these specialty cards becoming more popular.
They get more functionality and become less expensive too.
So RAID, there are RAID controllers.
So a SCSI adapter just shows each disk to the operating system.
If there are seven disks attached to a SCSI controller, the operating system sees seven disks.
A RAID controller has the ability to take those seven disks, and you can log into the card,
and you can say I want to create a RAID 0 or a RAID 1 or a RAID 6 or whatever it is you want to configure with these seven disks,
and then they present to the operating system those seven disks as one disk.
On your ESXi host, if you're not using vSAN, then it's fine to configure RAID on them.
Local disks aren't used a lot either way.
If you're not using vSANs on your host, maybe you're just using it for storing ISOs or something like that on them maybe.
If you're using vSAN, then you don't want any RAID configured on those disks.
You want each disk presented to the ESXi host as the disk they actually are.
So, a lot of RAID controllers now have the ability to be a RAID controller,
or you can flip them and say just be a basically a SCSI adapter and show every disk on this controller to the operating system,
and that is primarily there for the benefit of ESXi and vSAN.
So, fiber. Fiber means you are using glass instead of copper for your cabling.
There's fiber channel. Fiber channel is a network protocol where obviously we're expecting to see fiber glass,
and we have fiber channel HBAs, and you have to have a fiber channel HBA to use fiber channel.
And we're sending the SCSI packets encapsulated in fiber channel out over my network,
either from the storage array or the ESXi host to the storage array of the ESXi host,
meaning that the cable goes straight from the SAN to the host.
There's nothing in between, and they're so directly attached.
Or it could also go to a fiber channel switch.
So, in that situation, we might have a switch with, you know, 48 ports.
We have a stack of 48-port fiber channel switches, and the SANs,
and maybe multiple SANs are connected to that switch, and my host,
and maybe I've got a lot of hosts are connected to those switches,
and I can do what's called zoning on the switches and say these particular hosts are able to see these SANs.
Or I can even say as far down as these LUNs on these SANs through my zoning.
All right?
So, if I have a lot of hosts, more than I could plug into a storage array,
and maybe have multiple storage arrays, and so, again, you know, more than one host could connect to,
I'll create a fiber – or use a fiber channel switch.
Now, fiber channel over Ethernet means I'm using an Ethernet switch.
So, I'm encapsulating my iSCSI traffic in fiber channel in Ethernet and sending it over the network.
And it's just a regular Ethernet network.
It could still be glass.
It doesn't have to be copper.
A lot of people associate Ethernet with copper.
But you can also send Ethernet packets over fiber optic cables.
So, maybe I have fiber cables connecting my hosts directly into my storage array,
and I'm just using fiber channel over Ethernet between them.
Because I'm using Ethernet cards that are just Ethernet cards with fiber, you know, SFP ports on them.
And then Ethernet is just an encapsulation protocol, right?
Just a way – it's a protocol that works at Layer 2 to get, you know, packets onto the wire.
This is how the wire, you know, the Layer 2 part of the network is going to be working.
Above that is, you know, things like IT for addressing and routing.
Layer 2 Ethernet also has MAC addresses for addressing.
But it's a hardware address.
Above that, IP.
That's where you start, you know, like operating system and operating system addresses and stuff like that.
So, SAM implementations.
There's fiber channel SAMs.
There's fiber channel over Ethernet SAMs.
And there's iSCSI SAMs, right?
So, you will need to set up those SAMs.
And each type of SAM will be set up differently.
Every vendor with a different type of SAM will be set up differently.
So, you may have a fiber channel SAM from one vendor and you set it up a little differently than you might a fiber channel SAM from a different vendor.
Same thing with iSCSI.
There are certain things that will be the same, though, across all of them, for example, if it's fiber channels.
So, for example, fiber channels devices all have unique worldwide names.
So, there's going to be the worldwide name for the initiator on the host.
And there's going to be a worldwide name for the SAM.
And each storage controller on the SAM is going to have a unique worldwide name.
All right?
So, you know, things like that are going to be the same across all fiber channel vendors.
So, there might be uniquenesses within how you configure the disk and the LUNs and all that kind of stuff,
but certain things are always going to be the same, like, for example, using worldwide names for fiber channel.
Okay?
The SAM admin can't access the OS of the VMs.
So, you know, the VMs themselves are not accessible from the SAM.
What's on those disks may be.
Right?
That kind of depends on how you are implementing it.
If you're implementing on your ESXi host and your vSphere environments encryption, then it's encrypted on there, too.
So, it's not going to be accessible.
All right?
But it can monitor what's happening.
Okay?
It doesn't see the data that's going on.
It can't see what's going on with the VMs themselves.
But it can monitor the storage.
It can see things like latency.
It can see things like if there's errors in the packets coming in and things like that.
Okay?
The HBA is visible to the SAM as being part of the ESXi system.
The HBA is not visible to the SAM to show them the VM.
Okay?
The SAM doesn't see the VM.
It sees the ESXi host.
The ESXi host is writing that data.
The only time that might be different is if you had a physical mode raw device map.
Okay?
ESXi performs the multipathing.
So, ESXi will decide how packets get from it and, you know, if it's going to do round-robin
or what's going to happen there to the SAM.
The SAM doesn't decide that.
The ESXi host decides what kind of multipathing scheme they're going to use.
So, to do a SAM setup, generally, there's a few things you're going to need to do.
So, on the ESXi host, you're going to need to make sure that it has – is available
to see the SAM.
So, you're going to need to make sure that on the ESXi host, you have the HBA.
You have the HBA configured correctly.
It knows the address that's on the – you know, for the zoning or whatever you're going
to be doing.
For the SAM, it is ISCSI.
It needs to know the IP address of the SAM that you're connecting to.
Then you're going to provide the host with a worldwide name.
This is for Fiber Channel, right, of the port you want to connect to.
Record the worldwide names for the storage processors, which are going to be the storage
controllers on the SAM itself.
Then you're going to create LUNs, and you're going to assign what hosts are allowed to
connect to those LUNs.
On the storage device side, you're going to say what you can and cannot connect to.
All right?
So, templates are pre-Version 8.
So, SAMs support one VMF volume per LUN.
Now, you can do more.
It's not recommended to do more, but, you know, people are going to sometimes do what
they can do because they can.
But you should create, you know, one VMF volume per LUN.
Avoid diagnostic partitions on the SAM unless it's needed for, you know, the SAM vendor
or something like that.
So, you can create little partitions on LUNs that the SAM uses for diagnostic stuff.
Try to avoid those on LUNs that are presented to your ISCSI hosts, right?
Raw device maps to access raw disks.
LUN ID must be consistent when presented to the ISCSI host.
What they're saying is you don't want the ISCSI host to see different LUN IDs for different
hosts.
You want to make sure that LUN 0, LUN 1, LUN 2 are always the same on each host.
LUN 2 on one host is LUN 2 on all the hosts in a cluster because you don't want the different
hosts to think there is a different LUN and that VM that's running on it is a different
VM.
You want to be able to find the VM when it goes to look for it in case it needs to start
it up or something like that, right?
Ensure appropriate queues on the physical HBA.
So, HBA queues are kind of an interesting thing.
By default, the default HBA queue size is going to be 32.
And if you don't have anything else running, nothing else has changed, it's just going
to be 32.
And when that queue starts to get full, then what happens is the host has to tell the SAM
to back off.
It has to slow down what it's sending and tell the SAM to slow down what it's sending
to it, what it's receiving.
And that can hinder performance.
What can happen, though, is we do have something called Storage I.O.
Control.
And Storage I.O.
Control is a way for the GIGSXI host to give certain VMs on a datastore more or less access
to the datastore compared to other VMs on that same datastore.
It can't make the throughput more, but it can basically control how much access to a
datastore a certain VM gets compared to another one.
So if one VM is really noisy, you can give one of the ones that are getting choked out
some access.
You can also, just based on priority, this one's just more important, so I want to give
it more access.
And the way the GIGSXI host does that is it actually changes that queue size.
It's called queue depth.
It changes the queue depth dynamically when there's contention, when there's a slowdown
performance and you set that, like how many milliseconds we're going to allow for this
latency.
When you start to see latencies creeping up, then it will start changing the queue depth
to make sure that certain VMs that need more performance get that performance.
So the HPA queue is a pretty interesting thing.
Windows VMs require increased SCSI timeout value to 60.
So on the Windows VM itself, you're going to go in there and edit at the registry and
change that timeout value to 60.
And that's important because if a path were to fail and the host is trying to fail over
to another path, it might take longer than the Windows operating system is used to waiting.
And so it'll all of a sudden think that disk is down and start reporting the disk is down
and, you know, things like that.
So you want to increase that value so that way the Windows VM will be a little bit more
patient in case of a path failover.
All right?
So with LUNs, GIGSXI hosts are compatible with LUNs.
Of course, it can use LUNs on the storage array.
All LUNs need the appropriate HPA before the connection.
So you just need to have your HPAs configured.
You need the HPAs on the host.
You can't configure a host to use a data store, a LUN to configure a data store, until all
the HPAs are configured and things like that.
It's like saying you can't connect to a disk until you've installed the SCSI adapter, of course, right?
LUNs can be shared between hosts.
That's one thing that's really interesting is that I can have a LUN.
I format it with VMFS.
And in a Windows environment, typically, only one server is using that at a time, right?
There are these multi-active and things like that, but it gets a little bit unstable and
stuff like that.
Not all people usually want to use that.
But in a vSphere environment, I can have seven or eight hosts connected to one data store,
right, or one LUN using different VMs on there.
And they're reading and writing from that one file system all at the same time.
Multiple hosts are reading and writing from that file system all at the same time.
It's pretty fascinating how well VMware's done that.
And they've done it really well for, like, a couple of decades.
It's pretty impressive.
So, vMotion or DRS.
So, vMotion is a way where I can have a VM running on one host and then move it live
without bringing the VM down to another host.
And I can do that because the VM lives on a LUN on a SAN that both hosts can see, right?
If that VM isn't on a data store that both hosts can see at the same time, then I can't
do that vMotion.
I can do a storage vMotion and a vMotion at the same time, which is I change the storage
and the compute at the same time, but that's a different conversation.
DRS is the same thing.
So, basically, DRS is just automated vMotions.
It's where the system looks at all the hosts and says, this host here is getting really,
really busy.
Its CPU is going at, like, 90%.
And this host over here is only going at 20%.
This one's only going at 30%.
Let's move some of the VMs from this host to these other two and even that CPU utilization
out.
And I'm using CPU as an example, right?
So, vMotion is around.
Again, in order to do that, in order to have things like vMotion so DRS can work, we need
to have that shared storage, okay?
And in order to have that all happen and all work, the data storage needs to look the same
to all those hosts.
So, meaning it needs to have the same LUN ID and the same worldwide names and things
like that.
Implementing a Fibre Channel SAM.
So, in order to do Fibre Channel, you have to have an HPA.
With iSCSI, you don't, because with iSCSI, you can use a software initiator with Fibre
Channel over Ethernet.
I don't, but I can use a Fibre Channel over Ethernet software initiator as well.
But to do a true Fibre Channel SAM, you need to have an HPA.
You want the HPAs.
It's best if all the HPAs are in a cluster, are from the same vendor and the same firmware
and they're all patched the same.
You don't want a mixture of HPA vendors.
You don't want a mixture of firmware versions because that can make the performance seem
inconsistent to you.
So, Secure Boot.
What is Secure Boot?
Basically, Secure Boot is a way where we can specify that we want the image that we're
booting from to be provided by a trusted vendor, right?
So, the operating system that I'm booting up will have basically an encrypted file that
shows that it's a trusted source, right?
We don't want to make sure that you've got changed and all of a sudden now there's a
hacker's changed part of my kernel and I've got a root kit, right, and something weird
has happened to my network.
It'll be encrypted and the certificate that I'm using to boot from will be able to decrypt
that and I'll be able to say, oh, yeah, that is what I'm looking for.
My hash will come out correctly, basically.
All right.
So, it's basically saying that all the software that I'm using to boot my operating system
is signed by a trusted certificate for this, right?
What do you need for Secure Boot?
You need an EFI firmware in your motherboard, virtual hardware version 13 or later if you're
doing Secure Boot with the virtual machines and the OS that supports Secure Boot, which
Linux systems do, Windows systems do, pretty much all modern operating systems we'll be
using do.
And then we have Fiber Channel SAN.
This is kind of walking through a process we kind of already talked about.
So, it's going to be – configuring the SAN itself is going to be specific to the vendor,
right?
You're going to connect the host to the SAN.
How are we connecting the host to the SAN?
Either through some kind of a switch, Fiber Channel switch, or Ethernet switch, or we
can connect directly from the host into a Fiber Channel SAN.
I've actually seen iSCSI implementations done that way, too.
I don't recommend that for iSCSI, but you can do it.
I've seen it done quite a few times.
Configure the HBA on the connected host.
So, when you're talking about configuring the HBA, if it's a software initiator, we're
going to associate a VM kernel port with it.
If it's a physical HBA, we might need to do some configuration on the HBA itself to point
it towards the SAN for, like, booting and things like that if we're doing a LUN boot.
Ensure the hosts have iSCSI installed, obviously, right?
Spin up the VMs with the guest OS if we're going to be doing any kind of VMs running
at a certain time.
And the VM has access to the SAN.
The VM itself doesn't really have access to the SAN.
It has access to its virtual disks that live on the SAN.
So, booting from a Fiber Channel SAN.
We're actually able to boot our ESXi host, which I kind of alluded to, from a LUN on a SAN,
for example, a Fiber Channel SAN.
In order to do that, you have to have an HBA.
So, that's why most often it would be Fiber Channel.
If you have an iSCSI HBA, they can do this also.
If you're using a software initiator, you can't do a boot from LUN.
So, boot from LUN, we're going to configure, obviously, on the SAN.
We're going to configure the SAN with a LUN.
The LUN is going to be allowed access from an HBA.
And normally, you're going to want to only allow access from a specific single HBA because it's for one host.
Then we're going to go to the HBA, and we're going to point the HBA,
we're going to log into it and tell it that we're going to use it as a boot device,
and this is the LUN.
This is the SAN.
This is the LUN we're going to boot from.
Then we need to go into our BIOS and tell our BIOS that our boot device is going to be our Fiber Channel HBA,
and then it will show the LUN that we're going to be booting from on there.
Then you can go in and you can boot up, and when you go to install your operating system,
your HBA will be an adapter that you can use, and the LUN will be a disk that you can use.
When you go to install eSXI, if you have an HBA in there running and you've already presented storage to it,
it's going to show you all the different LUNs that are on there.
Even if they're not configured as boot devices, it will show you all the LUNs it can see,
because those are disks that the installer can see.
And if that LUN happens to be running production virtual machines, it can format it and wipe them out.
So usually if you're not doing a boot from LUN, you want to not plug in your HBA cables during that installation process
or be really, really careful.
Make sure you're choosing a local disk and you're booting to the right local disk.
Make sure you're choosing the correct LUN.
And usually it's going to be a really small LUN compared to the ones that you have VM drain on.
So if you see a LUN that's like 8 terabytes and you see a LUN that's a couple hundred gigs or something,
it's probably that small LUN, right?
So make sure you're choosing the right one because you don't want to wipe out all the VMs on the LUN
just trying to install your operating system if you chose the wrong one.
So choose the right one, install your operating system.
Configuring HBA to boot.
So if you have an Emulex HBA, you can configure that to do a boot from SAN.
That run.lputil, that is a Linux utility.
And because ESXi is based on Linux and it has a bash shell,
you should be able to run this utility from your ESXi host to allow you to configure the firmware on your Emulex HBA
to do its boot from SAN, right?
You can update the BIOS on there and do your boots from SAN on there.
Then you need to go to the host and you need to configure the host to boot, like I mentioned before,
from that HBA and from that LUN.
You'll need to enable all that in the BIOS after you've configured the HBA itself.
So once you've done that, you've already gone into the BIOS you chose to boot from that particular device.
You can say what LUN you're going to start from, all that kind of stuff.
The worldwide name of the boot device you're going to be using.
Reboot.
And you can go in there and you can install your OS.
So Fiber Channel over Ethernet.
Basically, there's Fiber Channel frames that are encapsulated in Ethernet frames, right?
So they're going to be encapsulated to get over your Ethernet network.
It requires a Fiber Channel over Ethernet adapter.
It can be a hardware adapter.
It can be a software adapter.
A maximum of four ports per host for Fiber Channel over Ethernet.
Now, if you're using NICs, you can do ones that support FCOE offloading or you can do ones that have no FCOE offloading,
which means there's regular Ethernet NICs, which means you're using your ISCSI software initiator.
Okay, you're going to configure a VM kernel port to work with your software initiator.
And then in vSphere, you're going to go into your storage tab and you're going to add the software adapter.
You're going to configure the kernel port and all that kind of stuff there.
And then you need to choose a VM NIC, which means you're going to be choosing basically a VM kernel that you configured to work with that adapter.
So an ISCSI SAN works a lot like a Fiber Channel over Ethernet software adapter.
So if you're using ISCSI software adapter, it works kind of the same way.
If you have a hardware ISCSI HBA, then it works like a Fiber Channel HBA, very similar.
Not everyone can connect directly to a SAN.
So advantages of a SAN over the Internet, meaning over an IP, right, not actually the capital I Internet,
basically is that it's a cheaper way of connecting to a SAN, whereas Fiber Channel traditionally requires expensive HBAs
and it requires expensive Fiber Channel switching.
Fiber itself can be more expensive, things like that.
The SANs are oftentimes a little more expensive.
This allows you to connect using regular Ethernet adapters, which are less expensive.
You probably want to get some higher-end adapters still, but they'll be less expensive than a Fiber Channel HBA.
And you can use the copper you already have.
Hopefully it's at least 10-gig copper.
And your Ethernet switches, which hopefully, again, are at least 10-gig at the very least.
Nowadays, 25-gig is really, really common.
And it allows you to use that initiator and a VM kernel port to connect to your storage.
So to configure ISCSI, again, for the storage array itself, it's going to be specific to the vendor, how you set it all up.
But there are certain things that are going to be the same for everybody, right?
You're going to configure your storage targets, right?
You're going to go in there and you can configure, you know, again, you're going to pull your disk.
You're going to create a LUN, and then you're going to create your storage targets.
And a lot of times, you can create a group, right?
They call it a host group.
So the host is going to be which machine they allow to connect to it.
It can either be an IP address or it can be this unique worldwide name or actually the UUID ISCSI that you're going to get, right?
And you can get this from the host, and then you can put it into your storage array and say that anything from this host is allowed to connect to.
And you can say what LUNs.
You can say to everything or to this LUN and this LUN or whatever you want to do, right?
You might configure a diagnostics partition.
You know, you can use local storage on the host for this or the storage array for that.
Set a large enough queue for the ISCSI controller driver.
So, again, this queue depth thing is something that default normally is just 32, but you can go in there and you can adjust it.
By lowering it down, you can sort of make it so that the VMs get kind of more fair access.
The problem with that, though, could also be that you could start choking the VMs because the queue could fill up too fast by making them a smaller number.
A way around that is to enable storage IO control, if you have that with your license,
because that will dynamically change that queue depth to up to its max by default most of the time until there's contention.
Then you can start changing that queue depth as needed, all right?
No support for ISCSI tape drives.
Multipathing the IO load balancing on a single – to a single physical LUN, right?
So, IO load balancing would go to multiple LUNs because it's IP-based, right?
It's not like Fibre Channel.
It's a little bit different because it's IP-based.
Multipathing with third-party hardware adapters and with the software or dependent hardware.
Usually, the multipathing, the third-party multipathing is from the storage array vendor, not from the adapter vendor.
And you want to make sure that whatever multipathing you're using is supported by ESXi.
So, you want something that's, like, certified by VMware to work with ESXi, not some unsigned adapter.
And eight, you'd have to go in through a bunch of hoops to even be able to install an unsigned, you know, VIV or driver onto a host.
So, that should be not much of a problem anymore.
Configure the ISCSI adapters and create your ISCSI storage.
So, we'll show you how to go in there and create data stores on ISCSI storage.
Once you've set up your ISCSI storage, you're going to configure your ISCSI adapter.
You can use either a hardware adapter, which does not require a dedicated VM kernel port, or the software,
which does require a dedicated VMware kernel port, and I'll show you that.
You're going to create the kernel adapter.
That's what you have to do before you assign it to the software initiator, obviously.
You can create the ISCSI adapter, which just simply means you're going to install it.
You're going to go in there and select software adapters and choose ISCSI software adapter and install it in there.
And then you're going to attach the VM kernel port to the software adapter.
Then, once you've done that, you'll run a scan, and the scan should show you what devices, which means what LUNs, it's discovered.
And then, from there, you can choose to format them to create a VMFS data store.
So, this is a storage with a hardware HBA.
Again, you don't need a dedicated VM kernel port for that.
It's software-dependent hardware, VMware ISCSI adapters.
So, what they're talking about, basically, is you want to make sure you get devices when you're using these hardware adapters.
They're supported by VMware, but you're not going to have to dedicate a VM kernel port to them, right?
But you will need – obviously, you'd have IP installed, which is installed by default.
No problem there.
VM kernel adapter, create ISCSI adapter, and then bind the SCSI adapters, okay?
So, then you're going to create your data store.
When we get into the lab, I'll walk you through how to actually find your software ISCSI adapter, how to get your kernel adapter to it, how to do a scan, how to find your data store.
We'll walk through all that.
So, booting from an ISCSI SAN, it's the same thing, basically, as for a fiber channel.
You need an HBA, right?
You're going to get your HBA.
You're going to configure the HBA menu, and you're going to configure it to be a boot device.
You're going to save what port on the HBA you want to use for your booting.
You're going to set an IP address.
Now, normally, you're going to set the IP address for your ISCSI in ESXi, but because we want to boot, it needs to have an address it can use to boot up.
So, you're going to go ahead and give it an IP address, set a gateway.
Hopefully, you're not going through a router.
Hopefully, a gateway is not really required because you're not going through a router for this.
But you can set the IP address, NAS gateway, normal IP properties.
Set the ISCSI name because you're going to want to give that name to the storage array so you can say that this unique name is allowed to connect to this LUN because that's what you're going to be booting from.
So, all that needs to be done on the initiator in advance in order to boot up and connect and find the LUN over the network, okay?
And if you're going to use CHAP for, you know, any kind of security, then you can configure CHAP.
CHAP is so old and insecure, it's kind of up to you if you want to enable it or not.
So, then you're going to the ISCSI boot parameters.
So, basically, what that means is you're going to go into the BIOS.
You're going to choose the adapter.
You're going to set the IP target and what you want to boot to, right?
Set the LUN and the ISCSI name.
Set it as the primary boot device in BIOS.
And then set what LUN is going to be the target for this boot.
VMS data store per LUN, obviously, you only want one VMS data store per LUN.
You don't want multiple data stores on a single LUN, especially if you're trying to boot from it because if you're trying to boot from it, it has to be one because then it wouldn't know what data store.
Because all it sees is the LUN.
You don't give the partition ID, it won't know what it's trying to boot from.
There's multiple on there.
You might try to boot from the wrong one.
Someday, your SAN and your ISCSI deployment is going to fail.
It's an absolute guaranteed.
They always do.
And not just ISCSI.
You know, Fiber Channel fails, too.
HBAs fail.
Switches fail.
Storage controllers fail.
Storage controllers, especially from your more high-end, reputable storage vendors, are kind of bulletproof.
I mean, they last forever, but there's failures sometimes, too, right, especially on the older ones as they age.
So, have a plan.
What's going to happen?
So, one of the common things is like, okay, so here's the nice thing about doing a boot from LUN.
I have this server.
Maybe it's a blade, right?
Maybe it's a rack-mount server.
And the server fails.
The CPU on the server fails.
The adapter on the server fails.
Whatever it is.
But I have another blade that's like my hot spare.
I can go in to this other server, whether it be a blade or rack-mount, and I can do all that same configuration I did before, going into the HBA, giving it the IP address, giving it the same name.
I can, you know, point it to the storage array.
I can point it to that LUN, go into BIOS, point it to the adapter, point it to the LUN, get it all set up.
And then when I boot it up, it's going to go to that same LUN that the old one was pointing to, and that host is back.
That exact same host with that same operating system is back on that server.
So, it does make recovering from a failure easy if the failure is not on the SAM side, if it's on the server side, because I can easily just point another server to it and get it back.
So, if you do have hot spares laying around, which on some big enterprise environments, that's more common, that makes it really super easy to recover from.
So, things are going to fail, know they're going to fail, plan for them to fail, and what are you going to do when they fail?
And it makes it easy because you can have a plan that says, here's all the settings for each of the hosts.
If this one fails, just load it on that one over there, and you can bring it right back up again.
Okay?
So, some ISCSI best practices.
How are you monitoring your SAM?
So, monitor the traffic where it's headed.
So, two things.
One, you want to monitor your IP traffic in general and make sure that it's going to the host you want it to go to, right?
You don't want some rogue system on there trying to, you know, get into your network.
If your security is set up correctly, if your configurations are set up securely and correctly on your SAM, there shouldn't be rogue hosts being able to see anything anyway.
But just to make sure, you also want to monitor that traffic.
You also want to monitor the health of the SAM itself.
You want to monitor for things like, you know, storage controller errors.
You know, if something's getting too hot, you know, alarms or heat and things like that, you want to, you know, monitor all that kind of stuff.
Changing a LUN ID that's attached to the VMFS datastore, things are going to fail.
Things are going to go down.
VMs are going to fail.
If you have, you know, those LUNs attached to some kind of RAID group on something, that RAID group is going to fail.
If you change a LUN ID, if for some reason you have to change a LUN ID on a system that's working, you need to turn everything off that's on it, make that change,
and then reconfigure the host that points that datastore again, and then start up the VMs again.
All right?
You basically don't want to change LUN IDs, okay?
iSCSI adapter names need to have a unique worldwide name, okay?
It needs to be unique worldwide.
That's why I call it a unique worldwide name.
Basically, that's just saying, yeah.
So if you really want to come to the big deal is if you're using a software initiator because you can name it whatever you want.
And so make sure what you're naming it is going to be really, truly unique in your environment and for anything it might ever, ever see.
NFS datastore.
So NFS is great.
It wasn't always supported at all.
And then when it was supported, it wasn't supported for production.
It was really only for, like, templates and ISOs and things like that.
But over the years, it got better and better.
And the support for it, VMware support for it got better.
And NFS itself got faster and faster and more reliable.
NetApp had a lot to do with that, but not only NetApp.
And so now NFS is supported for running production workloads on there.
And even Microsoft supports running production workloads on, you know, ESXi on NFS storage.
So if you are using it, you need to have your TCPIP stack, you know, correctly set up.
You want secured somehow.
You know, choose what security mechanisms you want to use for authenticating against that.
You don't want to authenticate normally as root.
You want another account set up.
But you can also, if you are using root, there's going to be an option on the NFS device.
It's called NoRootSquash.
You want to make sure you have NoRootSquash configured on there.
What can you store?
VMs, ISOs, templates, pretty much everything.
You know, production running live VMs.
Supported features, DRS, HA, vMotion, everything is supported on NFS now with ESXi.
And it works really well.
It works really well.
So this pretty much concludes attaching the network storage.
Let's go ahead and go to our demo environment, and I'll show you how to configure an iSCSI software adapter.
So here we are back in our vSphere environment.
So I'm going to go ahead and choose my host.
And I'm going to go to Configure.
And Storage Adapters is the very top one.
And you can see right here I have an iSCSI software adapter.
So I can select my software adapter.
And here are some of the basic properties that are in here that are already configured.
One thing that you'll want to do that you'll need to do, you know, kind of first if you want to use this,
is you would have to configure.
I'm going to jump over here to my VM kernel adapters real quick.
And I have configured a VM kernel interface just for my iSCSI traffic.
And as a best practice, what you normally will want to do is you might want to have a separate virtual switch configured.
With adapters, usually you'll have more than one in a production environment,
but you'll have adapters dedicated just to your iSCSI storage.
And they'll create a VM kernel port that is configured to use those adapters, all right?
So you might have on here some 25-gig adapters that are connected to your storage network that are going to connect to your iSCSI SAN.
So then back under Storage Adapters here, you can go to Network Bindings, and you'll have your iSCSI adapter selected here.
Now, because of this virtual environment, I actually have a virtual SAN,
and so I actually need to use my management network to connect to that.
But in a production environment, you actually would have your VM kernel adapter connected to that
and your VM kernel adapter connected to, again, like your 25-gig NICs that are dedicated just to storage.
If you need to add, you can go to Add, and you can choose the adapter that you need that to connect to,
and just say OK, and then it would show up over here.
So really, configuring the software adapter is pretty simple, right?
The big thing is, again, configuring the virtual switch, attaching the correct adapters to it,
creating that VM kernel port that has an IP address that's on your iSCSI network, right,
then assigning that storage adapter a VM kernel port.
Then once you've done that, you can go in and you can tell it if you want to rescan your storage,
looking for new storage devices.
Well, actually, I did skip a step.
Before you did that, you probably are going to want to go in and set up the discovery.
You're going to need to go in here and tell it the name or the IP address of your storage array, right?
So here, you can see what services you have enabled on there, what settings you have set up on there.
If you want to add a new adapter, you just simply go in, give it the IP address of the storage array,
and you can tell it what port number.
3260 is kind of the default for iSCSI, but you can go in there and set a port number,
but you need to do something different.
So then once you've added the iSCSI server, right, you've added a VM kernel port,
you set up the server to be, you know, accessible.
You know what server you want to connect to.
On the storage array side, we've already told it the information about the host connecting to it, right,
and presented a lens to it.
So we're going to, you know, set the discovery to the VM kernel port.
Then we're going to say we want to rescan our storage.
That's running.
It's going to complete pretty quick.
While it's running, I can actually go ahead and, because it's already done this before,
I then go to devices, and this is the storage device that I configured on my storage array to be presented to my VM kernel,
right, to my software SCSI initiator.
So from here, I could go in and I can use this to create a new data store,
we will actually go in and we'll create a data store, create a couple different data stores.