Chris Tyler - Fedora Linux

Table 6-4. Parity calculation for two drives

Notice that the total number of 1 bits in each row is an even number. You can determine the contents of any column based on the values in the other two columns ( A = B XOR C and B = A XOR C ); in this way, the RAID system can determine the content of any one failed drive. This approach will work with any number of drives.

Parity calculations are performed using the CPU's vector instructions (MMX/3DNow/SSE/AltiVec) whenever possible. Even an old 400 MHz Celeron processor can calculate RAID 5 parity at a rate in excess of 2 GB per second.

RAID 6 uses a similar but more advanced error-correcting code (ECC) that takes two bits of data for each row. This code permits recovery from the failure of any two drives, but the calculations run about one-third slower than the parity calculations. In a high-performance context, it may be better to use RAID 5 with a hot spare instead of RAID 6; the protection will be almost as good and the performance will be slightly higher.

During the early stages of the boot process, no RAID driver is available. However, in a RAID 1 (mirroring) array, each element contains a full and complete copy of the data in the array and can be used as though it were a simple volume. Therefore, only RAID 1 can be used for the /boot filesystem.

The GRUB boot record should be written to each drive that contains the /boot filesystem (see Lab 10.5, "Configuring the GRUB Bootloader")

RAID can combine drives of different types into an array. This can be very useful at times; for example, you can use a USB hard disk to replace a failed SATA drive in a pinch.

Daily disk or tape backups can be up to 24 hours out of date, which can hamper recovery when your main server is subject to a catastrophic disaster such as fire, circuit-frying power-supply-unit failure, or theft. Up-to-the-minute data backup for rapid disaster recovery requires the use of a remote storage mirror.

iSCSI ( SCSI over TCP/IP) is a storage area network technology that is an economical alternative to fiber channel and other traditional SAN technologies. Since it is based on TCP/IP, it is easy to route over long distances, making it ideal for remote mirroring.

Fedora Core includes an iSCSI initiator , the software necessary to remotely access a drive using the iSCSI protocol. The package name is iscsi-initiator-utils . Obviously, you'll need a remote iSCSI drive in order to do remote mirroring, and you'll need to know the portal IP address or hostname on the remote drive.

Create the file /etc/initiatorname.iscsi , containing one line:

InitiatorName=iqn. 2006-04.com.fedorabook:bluesky

This configures an iSCSI Qualified Name (IQN) that is globally unique. The IQN consists of the letters iqn , a period, the year and month in which your domain was registered ( 2006-04 ), a period, your domain name with the elements reversed, a colon, and a string that you make up (which must be unique within your domain).

Once the initiator name has been set up, start the iscsi server daemon:

# service iscsi start

You may see some error messages the first time you start the iscsi daemon; these can be safely ignored.

Next, use the iscsiadm command to discover the volumes (targets) available on the remote system:

# iscsiadm -m discovery -tst -p 172.16.97.2

[f68ace] 172.16.97.2:3260,1 iqn.2006-04.com.fedorabook:remote1-volume1

If the remote drive requires a user ID and password for connection, edit /etc/iscsid.conf .

The options indicate discovery mode, sendtargets ( st ) discovery type, and the portal address or hostname. The result that is printed shows the IQN of the remote target, including a node record ID at the start of the line ( f68ace ). The discovered target information is stored in a database for future reference, and the node record ID is the key to accessing this information.

To connect to the remote system, use iscsiadm to log in:

# iscsiadm -m node --record f68ace --login

The details of the connection are recorded in /var/log/messages :

Mar 30 22:05:18 blacktop kernel: scsi1 : iSCSI Initiator over TCP/IP, v.0.3

Mar 30 22:05:19 blacktop kernel: Vendor: IET Model: VIRTUAL-DISK Rev: 0

Mar 30 22:05:19 blacktop kernel: Type: Direct-Access ANSI SCSI revision: 04

Mar 30 22:05:19 blacktop kernel: SCSI device sda: 262144 512-byte hdwr sectors (134 MB)

Mar 30 22:05:19 blacktop kernel: sda: Write Protect is off

Mar 30 22:05:19 blacktop kernel: SCSI device sda: drive cache: write back

Mar 30 22:05:19 blacktop kernel: SCSI device sda: 262144 512-byte hdwr sectors (134 MB)

Mar 30 22:05:19 blacktop kernel: sda: Write Protect is off

Mar 30 22:05:19 blacktop kernel: SCSI device sda: drive cache: write back

Mar 30 22:05:19 blacktop kernel: sda: sda1

Mar 30 22:05:19 blacktop kernel: sd 14:0:0:0: Attached scsi disk sda

Mar 30 22:05:19 blacktop kernel: sd 14:0:0:0: Attached scsi generic sg0 type 0

Mar 30 22:05:19 blacktop iscsid: picking unique OUI for the same target node name iqn.2006-04.com.fedorabook:remote1-volume1

Mar 30 22:05:20 blacktop iscsid: connection1:0 is operational now

This shows that the new device is accessible as /dev/sda and has one partition ( /dev/sda1 ).

You can now create a local LV that is the same size as the remote drive:

# lvcreate main --name database --size 128M

Logical volume "database" created

And then you can make a RAID mirror incorporating the local LV and the remote drive:

# mdadm --create -l raid1 -n 2 /dev/md0 /dev/main/database /dev/sdi1

mdadm: array /dev/md0 started.

Next, you can create a filesystem on the RAID array and mount it:

# mkfs -t ext3 /dev/md0

mke2fs 1.38 (30-Jun-2005)

Filesystem label=

OS type: Linux

Block size=1024 (log=0)

Fragment size=1024 (log=0)

32768 inodes, 130944 blocks

6547 blocks (5.00%) reserved for the super user

First data block=1

Maximum filesystem blocks=67371008

16 block groups

8192 blocks per group, 8192 fragments per group

2048 inodes per group

Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729

Writing inode tables: done