Lustre discuss - Feb 2009 - Inquiry and advice requested on Lustre Implementation

Greetings-

  I am seeking out advice on CFS solutions. Currently we are running a
multi-node polyserve implementation over a SAN.

  I would consider going commodity for our next generation, with smaller and
numerous nodes. After looking into the Lustre documentation, I do see it as a
good test candidate. However, we would like to have our OSS''s and
OST''s on the same hardware. This being said, can someone pinpoint me to
a possibly high level diagram of how redundancy can be implemented across nodes,
if possible? Is it merely block level distribution without redundancy?

  It is entirely probable that I am misinterpreting the possibility here, please
let me know if this is the case.

Thanks-

Peter J. Milanese, Senior Systems Engineer
Information Technology Group
The New York Public Library
peterm-pr8sHEKKXcY@public.gmane.org - 212.621.0203


_______________________________________________
Lustre-discuss mailing list
Lustre-discuss-aLEFhgZF4x6X6Mz3xDxJMA@public.gmane.org
http://lists.lustre.org/mailman/listinfo/lustre-discuss

On Thu, 2009-02-12 at 11:15 -0500, PMilanese at nypl.org
wrote:
> Greetings-
Hi,
> I would consider going commodity for our next generation, with smaller
> and numerous nodes. After looking into the Lustre documentation, I do
> see it as a good test candidate. However, we would like to have our
> OSS''s and OST''s on the same hardware.
Just to make sure that nomenclature is not being confused, and OSS is a
computer.  and OST is a storage target (i.e. disk) the OST stores Lustre
objects (files and portions of files) on.

An OST can be an externally connected (logical) disk such as a DDN LUN
connected by fibre channel to the OSS.  An OST can also be connected
internally in the OSS such as a SATA, SCSI, (or heaven forbid) and IDE
disk.

Am I to understand you want the latter?  Do you already have this
hardware configuration and you just want to (re-)deploy it with Lustre?

The reason being, is that Lustre can only achieve it''s HA
deliver-ability goals when two OSSes (or MDSes) can see a common storage
target.  Doing this with internally connected disks is difficult and
usually requires a replication technology like DRBD to ensure that the
(i.e. network mirrored) disks are in sync.  This is a Sun-unsupported
configuration, but there have been reports of success on this list.
> This being said, can someone pinpoint me to a possibly high level
> diagram of how redundancy can be implemented across nodes, if
> possible?
I don''t know of any diagrams, but typically, you connect redundant
OSSes
to dual-ported disks so that either OSS can serve it''s data.  When one
dies, the other takes over.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090212/62a2c6ca/attachment.bin

>
>An OST can be an externally connected (logical) disk such as a DDN
>LUN
>connected by fibre channel to the OSS.  An OST can also be connected
>internally in the OSS such as a SATA, SCSI, (or heaven forbid) and
>IDE
>disk.
>
>Am I to understand you want the latter?  Do you already have this
>hardware configuration and you just want to (re-)deploy it with
>Lustre?
>

Indeed. We''d like to construct a mass capacity matrix, and are
currently weighing risk and recovery into the equation.

>The reason being, is that Lustre can only achieve it''s HA
>deliver-ability goals when two OSSes (or MDSes) can see a common
>storage
>target.  Doing this with internally connected disks is difficult and
>usually requires a replication technology like DRBD to ensure that
>the
>(i.e. network mirrored) disks are in sync.  This is a Sun-unsupported
>configuration, but there have been reports of success on this list.
>
>> This being said, can someone pinpoint me to a possibly high level
>> diagram of how redundancy can be implemented across nodes, if
>> possible?
>
>I don''t know of any diagrams, but typically, you connect redundant
>OSSes
>to dual-ported disks so that either OSS can serve it''s data.  When
>one
>dies, the other takes over.

I see. I was under the impression that mirroring was part of the Lustre package 
already. Am I correct to say that Lustre does handle the concatenation 
of OST volumes? 

Perhaps someone with DRBD experience can expand on that, as that would
be quite helpful. Is Lustre aware of DRBD? vice-versa?

Thanks for the Information Brian. It''s very helpful.

>
>b.


_______________________________________________
Lustre-discuss mailing list
Lustre-discuss-aLEFhgZF4x6X6Mz3xDxJMA@public.gmane.org
http://lists.lustre.org/mailman/listinfo/lustre-discuss

Please turn off the HTML formatting.  Plain text is sufficient for the
material this list covers.  Thanx.

On Thu, 2009-02-12 at 14:12 -0500, PMilanese at nypl.org wrote:
> 
> I see. I was under the impression that mirroring was part of the
> Lustre package 
> already.
No.  Not yet.  I don''t know when it will be.  It''s a fairly
distant
future feature.
> Am I correct to say that Lustre does handle the concatenation 
> of OST volumes? 
Well, yeah, I guess you could describe it that way.  Many OSTs can be
"pooled" into a filesystem and OSTs can be added and removed to/from a
filesystem at any time.

There is no actual "concatenation" going on,  Just lots of disks in a
single filesystem.
> Perhaps someone with DRBD experience can expand on that, as that would
> be quite helpful.
Lustre pools OSTs into a filesystem independent of DRBD.  They are
orthogonal to one-another.
> Is Lustre aware of DRBD? vice-versa?
No.  DBRD is just a networked block device.  Lustre uses block devices
(in whatever form they come) for OSTs.  It doesn''t really care what
technology (performance concerns aside) is underlying the block
device.
> 
> Thanks for the Information Brian. It''s very helpful.
You are welcome.

b.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090212/3e36636e/attachment.bin