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