Use Linux as a SAN Provider

At one-tenth the cost of the typical commercial appliance, Linux can deliver storage with speed and redundancy. Make the move toward a full-featured iSCSI SAN solution with what you already have in your server room.

Setting Up the Initiator and Target

In preparation for setting up the target, you need to provide it with a
disk. This can be a physical disk or you can create a disk image. In
order to set up a disk image, run the dd command:

dd if=/dev/zero of=/srv/iscsi.image.0 bs=1 seek=10M count=1

This command creates a file about 10MB called /srv/iscsi.image.0
filled with zeros. This is going to represent the first iscsi disk.
To create another, do this:

dd if=/dev/zero of=/srv/iscsi.image.1 bs=1 seek=10M count=1

Configuration for the IET software is located in /etc/ietd.conf.
Though a lot of tweaks are available in the file, the important
lines really are just the target name and LUN. For each target,
exported disks must have a unique LUN. Target names are formatted
specially. The official term for this name is the iSCSI Qualified
Name (IQN).

The format is:

iqn.yyyy-mm.(reversed domain name):label

where iqn is required, yyyy signifies a four-digit year, followed by mm
(a two-digit month) and a reversed domain name, such as org.michaelnugent.
The label is a user-defined string in order to better identify the
target.

Here is an example ietd.conf file using the images created above and a
physical disk, sdd:

The IncomingUser is used during discovery to authenticate iSCSI
initiators. If it is not specified, any initiator will be allowed to
connect to open a session. The OutgoingUser is used during discovery
to authenticate the target to the initiator. For simplicity, I made
them the same in this example, but they don't need to be. Note that
both of these are required by the RFC to be 12 characters long. The
Microsoft initiator enforces this strictly, though the Linux one does
not.

Start the server using /etc/init.d/iscsitarget start (this may change
depending on your distribution). Running ps ax | grep
ietd will
show you that the server is running.

Now you can move on to setting up the initiator to receive data from
the target. To set up an initiator, place its name (in IQN format)
in the /etc/iscsi/initiatorname.iscsi file
(or possibly /etc/initiatorname.iscsi).
An example of a well-formatted file would be the following:

InitiatorName=iqn.2009-05.org.michaelnugent:iscsi-01

In addition, you also need to modify the /etc/iscsi/iscsid.conf file to match the
user names and passwords set in the ietd.conf file above:

Now, run /etc/init.d/iscsi restart. Doing so will connect to the new
block devices. Run dmesg and fdisk
-l to view them. Because these are
raw block devices, they look like physical disks to Linux. They'll
show up as the next SCSI device, such as /dev/sdb. They still need to
be partitioned and formatted to be usable. After this is done, mount
them normally and they'll be ready to use.

This sets up the average iSCSI volume. Often though, you may want machines to run
entirely diskless. For that, you need to run root on iSCSI as well.
This is a bit more involved. The easiest, but more expensive way is
to employ a network card with iSCSI built in. That allows the card
to mount the volume and present it without having to do any additional
work. On the downside, these cards are significantly more expensive
than the average network card.

To create a diskless system without an iSCSI-capable network card,
you need to employ PXE boot. This requires that a DHCP server be available in
order for the initiator to receive an address. That DHCP server will
have to refer to a TFTP server in order for the machine to download
its kernel and initial ramdisk. That kernel and ramdisk will have
iSCSI and discovery information in it. This enables the average
PXE-enabled card to act as a more expensive iSCSI-enabled network card.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.