HP Matrix Operating Environment Automated Storage Provisioning: "Static"SAN volume automation via multi-initiator NPIV

Insight Orchestration – Storage Automation via NPIV

2. HPIO examines the shared data disk that was allocated in the previous phase. The shared

data disk is capable of supporting up to three single-path servers (indicated above by the

server HBA WWNs: ‘wwnr4’, ‘wwnr5’, and ‘wwnr6’). Since the service only contains two

servers, HPIO selects the first two WWNs in the storage pool entry (i.e. ‘wwnr4’ and

‘wwnr5’).

3. The WWNs are added to their respective server HBA(s) as indicated above.

4. Each of the servers are powered up.

5. At this point, NPIV functionality is exercised. The servers indentify themselves to the SAN

using both of their WWNs (the green server with ‘wwnr1’ and ‘wwnr4’, the yellow server

with ‘wwnr2’ and ‘wwnr5’).

6. Based on this identity, each of the servers is granted access to their respective boot disks.

7. The servers boot from ‘Lun1’ and ‘Lun2’ respectively (via HBA firmware and the standard

System BIOS boot device selection process)

8. As the HBA driver is loaded by the OS, it examines the HBA NVRAM to determine if there

are any additional WWN identities stored. If there are, the HBA driver initiates the

additional NPIV login process (i.e. “FDISC”) and the OS “sees” the two targets that it is

allowed to see. In this example, the green server is able to access both ‘Lun1’ and ‘Lun4’.

The yellow server is able to access ‘Lun2’ as well as ‘Lun5’.

As the process completes, each of the LogicalServers have been fully provisioned. The OS has been

automatically deployed to the correct boot disk and the servers have full visibility to a common shared

data disk without any changes being made to the SAN.

As in the first use case above, the process has remained fully under the Server administrator’s control

while adhering to the storage pool boundaries established by the SAN administrator. The SAN

administrator has visibility using his own administrative tools to the activity generated by each of the

servers and the servers’ identity is fully auditable all the way back to the LogicalServer definition and

the storage pool assignments that have been made.

SAN Management Considerations and Recommendations

As should be evident from the use cases examined above, the ability to give a server multiple

identities within the SAN provides a “server provisioning experience” that is roughly analogous to

that of a virtual machine. The SAN administrator provides a well defined “sandbox” within which the

Server administrator may function with greater independence. The use of a SAN allows servers to be

flexibly attached to different storage resources over time. Furthermore, the presentation of the storage

resources may be sequenced in time, solving an important issue with OS deployment (i.e. describing

to the OS deployment technology that the disk should be used to receive the OS).

WWN Management

One issue is the swelling of the number of WWNs that are required to maintain a static SAN while

still offering flexibility in how a server is attached to its target storage. The WWN requirement can

be minimized by populating the storage pool with pool entries that will be commonly used within the

environment. To achieve the separation of boot disk visibility from data disk visibility, you must

specify at least two types of storage pool entries: one for boot and one for data (either private or

shared).

The greater the variability in the different LogicalServer storage definitions that will actually be

deployed, the greater the number of “class unique” storage pool entrie. The primary variables are:

1. Size of the disk