ECN-APJ
3 Argentium

Boot from SAN Implementation and Best Practices Guide

Boot from SAN Implementation and Best Practices Guide

Share: twitter.png

Please click here for all contents shared by us.

Introduction

Boot from SAN can simplify systems management. Boot from SAN capabilities provide redundant storage paths, deliver improved security through a centrally managed Fibre Channel array, minimize server maintenance and reduce backup time.


Detailed Information

What is Boot from SAN

Boot from SAN is a technique that allows servers to utilize an operating system (OS) image installed on external SAN-based storage to boot up, rather than booting off their own local internal disk or direct attached storage.

Boot from SAN Benefits

If you use boot from SAN, the benefits for your environment will include the following:

·         Cheaper servers. Servers can be more dense and run cooler without internal storage.

·         Easier server replacement. You can replace servers and have the new server point to the old boot location.

·         Less wasted space. Servers without local disks often take up less space.

·         Easier backup processes. You can backup the system boot images in the SAN as part of the overall SAN backup procedures. Also, you can use advanced array features such as snapshots on the boot image.

·         Improved management. Creating and managing the operating system image is easier and more efficient.

·         Better reliability. You can access the boot disk through multiple paths, which protects the disk from being a single point of failure.

Boot from SAN Implementation

Preparing host connectivity:

The following guidelines should be followed for host connectivity to SAN environments (take Linux for example):

·         Maintain the simplest connectivity configuration between host server and SAN environment before installing OS. The configuration can be altered after installation.

·         If multiple HBAs are attached to the host, make sure it is the HBA connected to the lowest-numbered PCI slot that is zoned to the array.

·         All arrays, except the array where the boot device resides, should be un-zoned from the host server. On the array where the boot device resides, there should only be the boot device that is attached to the host server.

·         EMC recommends that the boot LUN be assigned Host LUN ID 0. If the boot LUN has taken a Host ID other than 0, there is possibility for HBA BIOS installation failure, hence no visibility to the boot LUN.

·         Additional LUNs can be added after OS installation is completed.

·         When configuring a RHEL boot LUN under the Linux native DM-MPIO, it may require that either all paths to the boot device be available or only a single path be available during the installation. Refer to your Red Hat RHEL installation documentation for details of this type of installation.

·         When configuring a SLES boot LUN under the Linux native DM-MPIO, it expects only a single path to the boot device during installation with DM-MPIO. Refer to your SuSE SLES installation documentation for details of this type of installation.

·         When configuring a Linux boot LUN under EMC PowerPath control, the boot LUN may be configured using only a single path during the OS installation; however, you will want to add the additional paths for EMC PowerPath control. Refer to EMC PowerPath installation document for details of PowerPath installation.

Basic boot from SAN procedure:

Setting up and executing Boot from SAN requires performing certain steps on both the server and the storage sides of the SAN.

The basic steps for setting up the system to boot from SAN are as follows:

1. Establish the physical connectivity between the HBA, SAN switch, and storage subsystem.

2. Provision LUNs on the storage subsystem to accommodate host images. Create one LUN per OS boot image.

3. Select the proper HBA port (HBA WWPN) and LUN from which the host must launch its boot image.

4. Ensure that the appropriate LUN is mapped to the appropriate host server through storage partitioning. It is also required that no other host server can view this specific LUN.

5. Boot into the host server system.

6. Configure the HBAs on the hosts to point toward the external storage unit. The HBA BIOS will inform the host that its boot image is now located on the SAN.

7. Install OS onto the appropriate LUN.

Here we list the requirements and guidelines for SAN Boot:

·         SAN configuration, zoning of boot devices, and multipath configurations

·         Active path to boot LUN

·         Only one path to the boot LUN enabled, prior to installing and enabling a multipath driver

·         HBA BIOS selectable boot, or boot BIOS, must be enabled



Author: Cissy Zhang

Labels (1)
4 Replies
NitramSnave
1 Copper

Re: Boot from SAN Implementation and Best Practices Guide

Really helpful guide. Thanks

Mich6
2 Iron

Re: Boot from SAN Implementation and Best Practices Guide

May want to discuss the Page File in a Windows environment and the Best Practices for it.

Regards, Michel.

0 Kudos
Highlighted
miwoods1
1 Copper

Re: Boot from SAN Implementation and Best Practices Guide

So I'm doing a migration from a VNX to Unity. I have a physical linux server that have a boot from san LUN. What should be the process, so I can migrate the boot from san lun from vnx to unity and continue to function without negative impact?

0 Kudos
Jacktivated
1 Copper

Re: Boot from SAN Implementation and Best Practices Guide

Did you ever get an answer to this? Can you please tell me what you ended up doing?

I am also doing a migration from a VNX 5300 Block, with a Boot from SAN, to a Unity 300 Hybrid, and am looking for information on migrating the Boot From SAN LUNs to the Unity SAN.

 

Thanks.

0 Kudos