Cisco UCS B-Servies : Boot Policy and Booting From SAN

[rumak18]

Hi folks,

sorry, but i just don't get it. How works the BOOT from SAN. I'm new to UCS. We have here 4 Hyper-V Servers and are configured with a Boot Policy for SAN booting with "vHBAs". Here i find the "Lun Name" in 4 entries (San primary-prim/sec and San secondary - prim/sec) but all have the same LUN Name "0". So ... all my 4 servers boot from the same image? I cannot believe it as there are four LUNs created on the storage deice itself called "hyper-v_lun1" , "hyper-v_lun2", "hyper-v_lun3" , ""hyper-v_lun4": So... how the hell do my hyper-v servers on the UCS boot from SAN? Where can i see my operating system? How can i find it? It's just so odd for me when coming from the VMWare world with "basic" rack servers.

[Niko Nikas]

Hello,

So lets start with why they all have the same LUN ID, "0".

When connecting to an end storage device, you need to be presented a LUN to use. This LUN will be masked (as multiple may be presented), and typically the boot LUN will be "0". However, you will only let one server have access to the boot LUN, so you can have multiple boot LUNs masked as "0", but each server will only see one.

*Note that the LUNs below are all different LUNs, just masked as 0*
[Server 1] ----> [LUN 0] *Allow server 1 access
[Server 2] ----> [LUN 0] *Allow server 2 access
[Server 3] ----> [LUN 0] *Allow server 3 access

So now that we have the masking (All LUN "0") piece sorted, why do they all have the same storage targets in the boot policy?

When booting from SAN, we are essentially saying look at these locations on this side of the fabric, and these locations on the other side of the fabric.

Primary [VHBA_A]
      Target 1 : Net_App_SC_1_1
      Target 2 : Net_App_SC_2_1

Secondary [VHBA_B]
      Target 1 : Net_App_SC_1_2
      Target 2 : Net_App_SC_2_2

The reason these are all the same, is because all the servers are trying to connect to the same end storage device (in this case lets say a NetApp array), but once they get there they are presented different LUNs via permissions set on the array (this would be done via initiator groups).

Let me know if I can clarify this any further for you.

--

Niko

[rumak18]

Hi Niko,

first of all. Thank you for our help. I appreciate it.

Unfortunately i still don't understand it fully.

This LUN will be masked (as multiple may be presented)

-> Who masks it?

When booting from SAN, we are essentially saying look at these locations on this side of the fabric, and these locations on the other side of the fabric.

-> What is "this side of the fabric" and what is "other side of the fabric"? In my opinion the boot deivce is on ONE site of the fabric -> Storage LUN.

(1)The reason these are all the same, is because all the servers are trying to connect to the same end storage device (in this case lets say a NetApp array), 
(2)but once they get there they are presented different LUNs via permissions set on the array (this would be done via initiator groups).

-> (1) checked

-> (2) "permissions set on the array" -> You mean storage own configuration" on the storage device?

[Niko Nikas · Accepted solution]

Hello,

Who masks it?

The masking will be done on the end storage device (so in our example the NetApp array).

Think of it like when you plug in a USB to your machine (add a new LUN), you give it an available ID like it will be the J: drive (or LUN 1, 2, 3, etc.).

What is 'this side of the fabric'?

Typically in an FC environment you have two completely separate fabrics to try and limit any failures to only part of your environment. That way if some issue does come up all of your devices don't experience a total outage, but may only lose half of their active paths. Typically it would be the A and B fabric, and they are usually on separate VSANs (if you are using Cisco gear).

Do you mean configuration on the storage device? (I think this is the last question.)

Yes, initiator groups are configured on the storage device, these essentially allow you to group a host (or set of hosts) together to make it easier to grant access to LUNs. For example, a UCS B-series server would typically have two WWPNs that it could use to log in to the NetApp array. So to make configuration easier on the array, we combine the two WWPNs into one initiator group.

--

Niko

[rumak18]

Hi Nico,

thank you for your help .Ineed it seems clearly now for me, especially beacause i tried some configuration in my environment.

Nethertheless i still got a question about BOOT FROM SAN that i would like to point out in this forum thread.

I still don't have an idea of how i can install a Windows Server OS on Cisco UCS-B Blade for example using BOOT FROM SAN. In physical environment i put the ISO/DVD (also virtually) and boot from it. But in UCS i even don't see the content of my LUN from which i boot and how the hell did the windows image we're using land there?   (-:

[Niko Nikas · Accepted solution]

Hello,

Glad to be able to help so far.

To clarify on this last piece, if everything from the SAN side is set up correctly, then to install Windows on your UCS blade, you will want to launch KVM for the blade and then select the 'Activate Virtual Media' button. After selecting this and accepting the pop-up, you should be able to select it again and then map a virtual 'CD/DVD' (your ISO). If you boot to this ISO, you should be able to load up Windows and install it to any disks (local or SAN) that the server can see (assuming drivers are correct).

One thing to note about Windows for installing to a SAN is that Windows does not like multiple paths presented (at least in older versions, that may have changed), so you may want to only present one path to the server for the initial install.

--

Niko

[rumak18]

All right...so in fact it's not different than in other manufacturers solutions. But does Windows Server support boot from SAN generally?

I still cannot fully image how my new windows installation will see the LUN I've defined for installation as there are several LUNs i give access to from this server , e.g.:

- One LUN for my Windows IMage

- Second, third and fourth for the Cluster Shared Storage

Perhaps i should consume some youtube videos....

[Niko Nikas · Accepted solution]

Hello,

Yes, Windows should support boot from SAN.

With regards to the LUNs, usually it's easier if there is only one presented for the initial install, but you should also be able to identify it by size if needed (usually your boot LUN will be significantly smaller than your data LUNs).

--

Niko