[CentOS] iSCSI disk preperation

Mon Feb 7 20:19:11 UTC 2011
Ross Walker <rswwalker at gmail.com>

On Mon, Feb 7, 2011 at 2:36 PM, Dr. Ed Morbius <dredmorbius at gmail.com> wrote:
> on 13:56 Mon 07 Feb, Jason Brown (jason.brown at millbrookprinting.com) wrote:
>> I am currently going through the process of installing/configuring an
>> iSCSI target and cannot find a good write up on how to prepare the disks
>> on the server.  I would like to mirror the two disks and present them to
>> the client.  Mirroring isn't the question, its how I go about it is the
>> problem.  When I partitioned the two drives and mirrored them together,
>> then presented them to the client, it showed to the client as a disk out
>> no partion on it.  Should I partition the drive again and then lay the
>> file system down on top of that?  Or should I delete the partitions on
>> the target server and just have sda and sdb mirrored, then when the
>> client attaches the disk, then partion it (/dev/sdc1) and write the file
>> system.
> What are you using for your iSCSI target (storage array)?
> Generally, RAID management of the storage is managed on the target side.
> You'd use the target's native abilities to create/manage RAID arrays to
> configure one or more physical disks as desired.  If you're using a
> dedicated vendor product, it should offer these capabilities through
> some interface or another.
> Presentation of the iSCSI device is as a block storage device to the
> initiator (host mounting the array).  That's going to be an
> unpartitioned device.  You can either further partition this device or
> use it as raw storage.  If you're partitioning it, and using multipath,
> you'll have to muck with kpartx to make multipath aware of the
> partitions.
> We've elected to skip this locally and create a filesystem on the iSCSI
> device directly.
> Creating and mounting filesystems are both generally managed on the
> initiator.
> Truth is, there's a lot of flexibility with iSCSI, but not a lot of
> guidance as to best practices that I could find.  Vendor docs have
> tended to be very poor.  Above is my recommendation, and should
> generally work.  Alternate configurations are almost certainly possible,
> and may be preferable.

If a best practices doc could be handed to you right now, what would
you like it to contain?

I would suspect that it would be different whether your setting up an
initiator or a target, so maybe start by splitting it into two

I would be happy to draft something up and put it on a wiki somewhere,
but I would need a list of talking points to start with.