| Keith via plug on 21 Jul 2020 09:10:16 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] RAID-1 mdadm vs. Mobo H/W = moot |
I was thinking of DRBD on the same machine as an asynchronous RAID between a fast NVMe drive and a slow HDD. If you mirror them, you lose the performance of the NVMe. But if you use DRBD to mirror them, if you lose the NVMe, just rebooting would boot off the HDD and fsck (or in the case of xfs, just mounting the filesystem) would get you back to a running system.
Regards– Bhaskar
Yea, I'm with you on the thinking since that is how I use DRBD but the issue is while /etc/drbd.conf would be the same on the primary and secondary, the daemon that runs will only let you define the resource as primary ***or*** secondary.
I suppose one possibility would be to containerize (nspawn)
another system on a different IP to just handle your DRBD
secondary. Still feels like overkill but that would be less work
than doing a single server LizardFS system for mirroring. It
would be an interesting use case.
As long as DRBD shows your secondary "UpToDate" its is a
mountable and usable filesystem when it becomes primary (or if you
physically move it to replace a primary). The issue with async
replication for DRBD (mode A) is that when it is flagged
"Inconsistent" it is not usable. I've tried and all I run is XFS-
it didn't work. I don't remember the details of the failure but
this is the nerve racking part. For this, it would make more
sense to run mode B (memory synchronous <-- this should be
stupidly fast on the same system) or mode C (synchronous <--
should be as good as LVM / mdadm). See
https://www.linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-replication-protocols
I should also point out that for DRBD being up to date means a viable secondary. It actually does not mean all the data is sync'd yet in the case of mode A. In an orderly manner you can disconnect the secondary and it will be mountable even as the primary continues to run. If you do that though, when you reconnect it will be marked inconsistent until is catches up. For what you are talking about being inconsistent is going to be pretty short lived but it is a point that is worthy of being harped on. Asynchonous DRBD would also be very similar to using degraded RAID-1 so if this did work, I could see it be used with an external drive you sync regularly but then keep offline.
Finally... I'm running DRBD 8.x. I ended getting heavily into LizardFS before the release of DRBD 9 which has a dual primary mode, n-way redundancy (2 < n <= 16) and some other improvements. I'm leaning very much in the direction of Lizard FS for the future of my data protection solutions but at some point I'm going to give DRBD 9 a hard look. There is a lot to like about it and I may continue to use DRBD 8 or 9 in combination with LizardFS.
On Mon, Jul 20, 2020 at 11:56 AM Keith via plug <plug@lists.phillylinux.org> wrote:
___________________________________________________________________________
On 7/20/20 9:24 AM, K.S. Bhaskar via plug wrote:
On Mon, Jul 20, 2020 at 2:47 AM JP Vossen via plug <plug@lists.phillylinux.org> wrote:
On 7/16/20 9:21 PM, JP Vossen wrote:
> I'm building 2 new PCs and I am wondering about RAID-1. I've been using
> mdadm RAID-1 for at least a decade with excellent results. But I
> haven't had to deal with (U)EFI up to now, and that's a mess, along with
> the fact that the Linux Mint/Ubuntu `Ubiquity` installer doesn't do
> RAID. :-(
>
> I only care about RAID-1 (mirror) and Linux. I would not even consider
> Mobo RAID anymore more complicated than a mirror, but since a mirror is
> *so* simple...
<snip>
The short version is, the Asus ROG STRIX B450-F GAMING ATX AM4
motherboard [0] is *not* capable of using both M2 slots if you are
*also* using the Radeon Vega Graphics processor [1]! :-(
So we fell back to plan-b which is to install some old HDD drives I had
laying around and I'll get around to writing some kind of `rsync` script
(after I take a look at Brent's code).
Thanks for the thoughts, I was reasonably certain about not doing the
hardware RAID, and that was certainly confirmed!
[KSB] <…snip…>
Bhaskar, I recall you've talked about your /spare/ process before. I
think perhaps some of my concerns with mobo H/W RAID came from similar
discussions with you and/or wider PLUG. Plan B is going to be similar,
but actually a bit simpler.
nvme0n1p2 is the main storage. sda1 *will be* a periodic `rsync` clone
of nvme0n1p2, with some hack I haven't figured out yet for the
`/data/etc/fstab`. It will also house Mint's "TimeShift" (think Mac
Time Machine). So if nvme0n1p2 unexpectedly dies [2], I can just boot
from sda and keep going, possibly with having to do a bit of a restore
from either TimeShift or my other backups.
[KSB] I confess that I don't know as much about DRBD as I could or should, but I wonder if it might be possible to use it to replicate from the NVMe storage to the old HDD. This would also avoid the need to hack on /etc/fstab or /boot/grub/grub.cfg – since the HDD partition would not need to be mounted, it can have the same UUID as the NVMe partition. Before doing something “risky” shut down the DRBD replication, and start it up again once the upgrade or whatever completes successfully.DRBD is basically network RAID-1 so you wouldn't use it to mirror drives on the same system. You **could** use it to replicate a system mirror set from server A to server B but personally, I don't think its worth it. My current data protection solutions use DRBD and as much as I love it, when a full resync gets triggered having to scrub through and get the secondary up to date is nerve racking because you can't use the secondary until DRBD thinks its stable. That's not as big a deal with you're on a LAN but actual RAID-1 will always let you mount the other mirror even if its out of date.
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Keith C. Perry, MS E.E. Managing Member, DAO Technologies LLC (O) +1.215.525.4165 x2033 (M) +1.215.432.5167 www.daotechnologies.com
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Keith C. Perry, MS E.E. Managing Member, DAO Technologies LLC (O) +1.215.525.4165 x2033 (M) +1.215.432.5167 www.daotechnologies.com
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug