Re: Software Raid 5

I don't know if DRBD was a way to simplify the task or if there are
other reasons it was chosen.  I didn't make the choice to use DRBD so I
can't answer as to why it makes any more sense than any other mechanism.
AOE stands for ATA over Ethernet.  There is a kernel driver that sets up
a drive as /dev/etherd/eX.Y where X is a shelf the actual drive is
designated to be on and Y is the drive within that shelf you are
addressing.  The communication for reads/writes is done over Ethernet
and so you can have raid over the network where two drives are on
different racks / power supplies etc.

I'm assuming that if you can have root failover with directly connected,
shared, drives that the AOE method should work as well, but was hoping
someone would have experience with this.

I just don't grasp how the cluster handles the loss of the system that
made the initial mount when it goes away.  For instance, if there was a
complete array stored in an initrd and that initrd was booted and 3
primary units joined the array, could you pivot root over to a software
raid consisting of 3 drives one on each box.  Then if it is possible,
could you then turn off the system from which the cluster was booted and
the cluster continue to run?


Larry Brown

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
David Bo Jensen
Sent: Monday, June 19, 2006 2:45 PM
To: [email protected]
Subject: Re: [SSI-users] Software Raid 5

What is AOE devices?
If  Raid 5 is possible as you describe it, then DRBD will not make much
sense, would it?


----- Original Message ----- 
From: "Brown, Larry" <[email protected]>
To: "Ed King" <[email protected]>
Cc: <[email protected]>
Sent: Monday, June 19, 2006 7:40 PM
Subject: [Norton AntiSpam] Re: [SSI-users] Software Raid 5


> My apologies, I should have been more specific.  I have also come
across
> a number of posts touching on software raid.  I was referring to
> inter-node software raid IE:
>
> md0
> /dev/1/hda2
> /dev/2/hda2
> /dev/3/hda2
> /dev/4/hda2
>
> Where loss of node 1 would not constitute loss of the cluster.  If
this
> is not possible with the md code that is in the kernel due to the
> underlying architectural changes, is it possible to do this with AOE
> devices?
>
>
> Larry Brown
>
> -----Original Message-----
> From: Ed King [mailto:[email protected]]
> Sent: Monday, June 19, 2006 1:27 PM
> To: Brown, Larry
> Cc: [email protected]
> Subject: Re: [SSI-users] Software Raid 5
>
> If you want the root to be fault tolerant, a standard debian
> installation allows this (Sarge 3.1).
>
> We partition each drive with a small boot partition (~50MB) , some
swap
> space (1GB) and the rest being allocated for RAID.
>
> The installer is told that the first drive, first partition is mounted
> as boot, the other primary partitions on the other drives are not
> designated to be mounted (the debian installer can't have more than
one
> drive mounted to the boot point).
>
> The installer allows the creation of the raid, and we flag that as
> mounting as the root filesystem -- it gives us a very large software
> raid, and on the faster processors can actually give better
performance
> than hardware raids.  The boot partition never changes (unless we
> upgrade the kernel) and is small enough so we use dd to copy it over
to
> the other unused partitions so all the drives are now bootable.
>
> Brown, Larry wrote:
>> OK, I'm going to ask a stupid question.  I'm sure I must have run
>> across this in the past but can't find any mention of it now...
>>
>> Is it possible to allow a small group of nodes to boot to an init
node
>
>> where the init node is still running off initrd, mount their disks
>> with software raid, and pivot root over to them allowing the root
>> filesystem to be fault tolerant with software raid 5?
>>
>> Larry Brown
>>
>>
>>
>>
>> _______________________________________________
>> Ssic-linux-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/ssic-linux-users
>>
>>
>
>
>
>
> _______________________________________________
> Ssic-linux-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ssic-linux-users
>
> 




_______________________________________________
Ssic-linux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ssic-linux-users