UCS Storage Provisioning

The purpose of this document is to provide guidance on the provisioning to the UCS
from the storage platforms utilized in Xerox NA. It is assumed that the reader has
the basic concepts of SAN zoning and has familiarity with the Xerox NA
infrastructure. It will be helpful to understand NPIV in a SAN environment, allowing
multiple host virtual WWPNs to use the same physical port on the SAN.
The HCL Architect & Engineering team have adopted a Boot from SAN approach
for the Xerox midrange UCS environment. There a several OS platforms being
utilized and each will differ on how it is being provisioned when booting from SAN.
The Boot from SAN has been tested on the ESX and Linux platforms with
adjustments made to insure success. A caveat when booting from SAN is that
zoning\registration should be considered a two-phased approach, only one initiator
will login to allow a zone\registration, masking to the boot device. On the second
boot to the host, you will find the remaining initiator logins, allowing the completion
of normal masking. The procedures below will define the provisioning for each of
these tested platform, deviations from this procedure can result in failure as well as
unapproved\ununiformed configuration in the environment.
Process steps:
Phase one:
1. UCS Opens ticket for storage team requesting boot luns for host OS platform
2. Storage team verifies all pertinent documentation is attached to ticket (PAP,
Storage template).
3. Storage team provides Storage Initiators (SIs) for boot lun visibility.
a. Options:
i. Creates aliases and zones on SAN based on information provided
ii. Create boot device *
iii. Masking (optional) on Clariion unable to do this until registration
is completed
4. UCS admin builds host profile with SIs for boot lun visibility and boots host for
first FLOGI.
5. Storage team verifies host initiator login and completes the
registration\masking of boot device to the host to this one host initiator (HI).
Phase two:
1. UCS admin boots host and confirms initial lun visibility.
2. Storage team verifies remaining (HIs) are logging in to SAN and completes all
remaining zoning\registration, masking work.
3. Remaining storage allocations can be completed

*Boot devices should be a fully pre-allocated device

All service request for boot luns should have an approved PAP and an
attached UCS Boot LUN SAN Request Template
It is preferred that UCS blade are powered on and connected to SAN before
zoning is completed, *yet not necessary.

ESX Hosts
The ESX host environment will be deployed on the DMX or VMAX Storage platform,
this will allow a boot lun 0 allocation on an active\active storage backend to multiple
host within a cluster, not so much a limitation on the active\passive Clariion storage
arrays but an ease of management choice.
The UCS admin will open a ticket for the storage team requesting boot luns for a
particular platform. The ticket will have UCS Boot LUN SAN Request Template
attached and generally would have pertinent information regarding the host and the
WWPN. The storage team will provide the WWN of the storage initiators that is
planned for zoning.
VMAX5935:

FA_WWNS

Clariion initiators can be found on the Brocade switches

This will allow the UCS admin to build a service profile and associate to the target
host. Ideally the zoning should be completed at the host first login to the switch,
however because we are booting from SAN it is not always necessary, zoning can
be completed ahead of time with the know information provided on the template. *It
is very important to understand that all ESX boot luns will be 6GB in size and
masked as LUN ID 0. The internal LUN ID is irrelevant to the host or boot process. It
is the UCS admins responsibility to divvy UCS host across the fabric interconnects
for the UCS chassis, insuring host i/o load balancing.
Linux & Unix Hosts
The Linux and Unix host are considered a standalone host and can be deployed on
both the DMX\VMAX and the Clariion Storage platform. The choice of storage
platform will be at the discretion of the approving architect based on host
application i\o and host demands, this should be found documented on the
approved PAP.
The Linux host will be provisioned a boot lun 0 of 121GB in size. This document will
be updated when we have boot device requirements for Unix Hosts. All DMX\VMAX
allocations will be of the same practice of that of the ESX, however when
provisioning the boot lun\storage from the Clariion there are some differences, this

because of the Clariion storage active\passive nature. The storage admin will need
to provide the following information on the storage template for the UCS admin:
1) HLU
2) SP owning LUN 0
3) Initiator to SP owning LUN 0
Ex. Snapshot of Template:

Host lx470 has been targeted to have a boot lun owned by SPA, therefore on vHBA0
which will be the host primary boot vHBA. Host lx471 has been targeted to have a
boot lun owned by SPB with vhBA1 being the host primary boot vHBA.

*It is possible to complete all zoning with the information provided beforehand on
the storage template provided the information is accurate; however inaccuracies on
the provided information will delay the turnover.
Notes\Learnings:
1. Zoning issues
UCS admin provided the wrong WWPN (vHBA0\vHBA1)
UCS admin reversed the VHBAs
2. Verify port logins at the UCS assigned SAN ports
Run a nodefind <wwn> on the switch to confirm host login on the
switch.
3. Host unable to see boot lun
Verify storage initiator used on service profile
Verify zoning, masking
4. When creating lun it should a fully pre-allocated device.

Reading Material and References:

\\usa0300cifs001\HCL_Storage\Unified Cisco System
http://www.cisco.com/en/US/docs/unified_computing/ucs/ts/guide/TS_SANBootAndCo
nnect.html#wp1067117