Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
iSCSI Software boot
1.2. Name of Document Author/Supplier:
Author: Sajid Zia
1.3 Date of This Document:
03 August, 2007
4. Technical Description
1. Background:
--------------
PSARC 2003/126 introduced the Solaris iSCSI Initiator to Solaris.
Solaris Initiator allows access to scsi storage using Sun's
TCP/IP stack through a general NIC. The initiator provided a
software only solution with no boot support. A traditional
boot requires firmware support on adapters which a general
NIC does not provide.
2. Problem Statement:
---------------------
Storage Area Networks (SANs) have been rapidly growing and
gaining popularity over the traditional client-server model due
to their ability to efficiently handle data. Typically, Storage
Area Networks require Fibre Channel, however, iSCSI for SANs,
which encapsulates standard SCSI over existing IP networks,
offers a lower cost alternative to expensive Fibre Channel.
Fibre Channel SANs support booting from an FC device over
a SAN thereby eliminating the need for a local hard disk on
a system. Boot is considered a basic OS functionality, and
currently no good iSCSI boot solution exists on the market
due to the fact that a general NIC does not provide any iSCSI
support in its BIOS.
3. Proposal:
------------
PSARC 2004/454 introduced the Solaris New Boot Architecture which
greatly simplified a boot process on x86 platforms. iSCSI boot
proposal leverages Solaris New Boot to offer a solution which
requires no dependency on iSCSI support in bios. This basic idea
here is to combine net and disk boot process. It uses pxegrub
to download boot archives from the install server in the early
stages of the boot and then loads iscsi initiator in client's
RAM to access the boot device using regular block disk IOs.
This proposal is offering a new iscsi boot functionality only,
and does not impact in any way the general solaris install/boot
process for non iscsi root devices.
4. Proposal Details:
--------------------
When a client system powers up or rebooted, these are the steps
which are followed for booting.
1. BIOS running on the machine makes a DHCP request.
2. DHCP server responds with boot server and boot file, i.e., pxegrub
3. BIOS downloads pxegrub using tftp
4. pxegrub displays the grub menu supplied by the boot server
5. pxegrub then gets the boot-archive (mini-kernel) from the boot server
and executes the mini kernel.
6. mini-kernel plumbs the network interface and enumerates the iSCSI
boot device.
7. root disk is seen through regular NIC port
8. rest of the OS image comes from the root disk using regular disk IOs
The steps 1-5 are exactly the same as followed by a normal Solaris
Installation process. The only difference is that the boot-archive in
step 5 comes from the root disk and not an Installation boot-archive
Installation
------------
The installation process changed a bit in the sense that we need to
provide iscsi boot target IP address and client's Initiator Node
Name during the installation to discover the boot device. This is
accomplished by using bootparams. The following name=val entry is
required in /etc/bootparams on the install server.
<Client's Name> iscsi-boot=Target_IP:Initiator_Node_Name
An example:
iscsi-1 iscsi-boot=192.29.74.155:iqn.1986-03.com.sun:01:iscsi-1
Once the installation is complete, the following extra steps an
administrator needs to do to prepare the client for booting:
1. newly created boot archives need to be copied to the Install
server for subsequent booting
2. menu list on the server need to reference the new boot archives
for booting.
The code changes for the project are mostly confined to iscsi
driver and require no interface/architectural changes. These are
some additional changes.
1. During the installation, an rc script is needed to discover and
enumerate the boot lun.
2. filelist.ramdisk file needs to be updated with iscsi persistent
database files which are needed to boot
3. SUNWsibi pkgmap needs to include iscsi database file entry.
4. A minor sockfs change is required, addressed by the CR 6422549
5. A minor update is needed in smf_include.sh script.
5. Limitations
--------------
This solution offers an innovative way of accomplishing iscsi boot
on a general NIC. The first phase of the project has few limitations
which will be addressed in subsequent phases.
1. It is supported only on x86/x64 platforms due to a dependency on
Solairs NewBoot
2. The customers will be encouraged to use the first phase of this
solution over physically secured networks. The next phase of the
project will add CHAP authentication.
3. Currently require targets to have TPGS disabled so that iqn based
names appear in the root device name. The next phase will add
multi-pathing support along with IPMP.
4. Only manual network installation is supported.
5. After the installation, the boot archives must be moved to the
installed server to be used for booting. This needs to be done
by the administrator.
6. Install server is required at the time of boot/reboots
7. The boot archives on the root disk and on the installed server
must be in sync. This needs to be ensured by the administrator.
8. dump/sync is only supported on a local partition due to a
networking bug 6205961, which will be addressed in the next
phase.
6. Benefits
-----------
Despite these limitations, this solution offers many benefits
which should outweigh the limitations for phase I release.
1. Offers an innovative solution to combine net/disk boot
2. No hardware dependencies
3. Works on any modern general NIC which has pxe support.
4. Superior to "diskless boot" which requires boot server to be
available all the time to service boot clients.
5. A generic Solaris iscsi boot solution will offer a huge
marketing advantage over our competitors. Currently there is
no good generic iSCSI boot solution available in the market.
8. References:
--------------
1. PSARC 2003/126 iSCSI Project
2. PSARC 2004/454 Solaris Boot Architecture
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
