Re: "Virtual" RAID1

[tlaronde%polynum.com@localhost]

Hello,

On Sat, Jun 22, 2019 at 04:36:05PM +0100, U'll Be King Of The Stars wrote:
> I have been designing a system that does something a lot like this, to function as a multimedia asset management system.
> 
> I would love to compare notes with you if you like.
> 
> Do you want this to work on the block level? It sounds like you do.
> 

Yes and no... The question of the filesystem on the disks is open.

I'd like to work at the block level if the filesystem was like one found
on Plan9, that is a WORM with deduplication of blocks and, as a bonus,
history---versioning-- of files. This is something I have found to be of
great use for a lot of small businesses working on files (typically CAD,
land survey, GIS...).

But at the beginning whether there is some network file system protocol
involved on the client or on the server is not a problem.

> Things like this do exist, but you have to be very specific about what you are trying to get out of it?  From your description it sounds like you simply want to do replication between two nodes.  But then I thought about it more and realized that, in this case, you could simply set your file service as "active" and the remote one as "redundant".
> 
> Or are you trying to implement a cache for your working files that are a subset of the complete file service that has too much data to store locally?
> 

This would be mainly for files that need to be saved (not intermediary
versions of files but landmark versions).

For the different statuses of the data, I manipulate, so to speak, the
namespace:

	1) There is data that is what is currently being created/modified.
	I call this the "minute". It is in memory as far as the user is
	concerned. When it is worth it, it is "committed" (save on disk)
	(since I'm developping a GIS system, hence the tools, I have the 
	hand on that);

	2) There are directories that the user knows are not backup-ed. He
	can not expect any guarantee on these. These directories have space
	allocated and there is recyclement : when they are approaching
	fullness, the oldest entries are removed;

	3) There are directories that are backup-ed but not all files are
	backup-ed. "Algebraic" approach: are only long-term backup-ed the
	files needed as source that are enough to reconstruct all the data
	(once more because in my case I'm the one who provides the program
	to construct and create the data from the sources).

> I am trying to minimize noise in the local sub-NAS of the complete file server.  The sub-NAS will have SSD's and the remote upstream NAS will have many arrays of high-capacity spinning HDD's.

I'm partly concerned by the same aspects plus that whatever space one
gives users, they fill it. So the amount to handle is a PITA.

The problem is to try to minimize to the
minimum for safety what is back-up on spinning, "cheap", HDD (thus I
want to have the minimum stress on them since there are "cheap")
vs expensive HDD that are able to support reliably the reading/writing
for what is used at the moment (I do not use SSD for the moment;
when files are small, the speed is not crucial and even "normal" disks
are not stressed; and when files are huge, the prices are 
prohibitive...).

> 
> In your case there are companies that, I think, do what you need, such as Dell/EMC.  But they are expensive and proprietary.

This is the problem: there is a gap. One finds "cheap" solutions but
that are absolutely unreliable (I have found them to be indeed costly
precisely because you pay small amounts but have nothing except problems
in return). But then, the "next" proposals are simply prohibitive
for small businesses.

If one wants (as I do), fast immediate serving, secondary fallback for
not disrupting the day work and long term back-up plus versioning, this
is simply not affordable. But the pieces, for the most part, are there
scattered all around.

> 
> Can you please specify in detail what you want to do?  I would like to see if there is any common overlap.  If you like, we could share our findings.

For the moment I'm exploring and trying to do the best with what I have.

For the moment the findings are these:

1) Even with small businesses, I mean a ten of nodes, one needs to
invest in good HDD, very good HDD, for serving immediate data if the
files are huge;

2) Trying to split say pair of disks with one half of the disk serving
data1, the other half used for fallback of data2, and the reverse on the
second disk, is an error: if the two disks serve data, they need to be
high end one. It is better to have one high end disk for serving,
one less high end one for fallback;

3) Since security is not one  action but a string of several measures so
that absolute disaster may only happen if several independent steps fail
at the very same time (combination of probilities), supplementary
to first back-up, I tried to put a back-up that could be used
immediately by a Windows node that could serve the data during the
time the server could be brought up. I tried NTFS (because of Windows)
on USB mass media storage (writing with ntfs-3g on a NetBSD server). The
performances are abysmal. The USB storage are low end 2.5" HDD that
fail (if it is not the USB connectic).

A better solution is to use the UDF filesystem (there is good support on
NetBSD thanks to Reinoud Zandijk) that is supported too by Windows.

And since NetBSD runs on a large variety of hardware, I'm now trying to
build "mini" servers with ARM that could be plugged in the network for
backup and that could simply switch to serve the data the main server
gone down.

I don't think there is a lot of new in what is put above. But the thing
that a majority of people don't realize is that there is a fixed cost
for these serving/fallback/backup solution and that, at the moment, the
commercial proposals are out of reach of a huge amount of structures
while I do think there is the possibility to offer something that
doesn't cost 10k euros per year, even if it does offer "five nines"
(advertised) reliability.

Best,

T.Laronde

> 
> Andrew
> 
> On 22 June 2019 14:13:21 BST, tlaronde%polynum.com@localhost wrote:
> >Hello,
> >
> >I don't know if the idea is stupid, but I wonder if there is a way
> >to combine existing programs in order to associate in a RAID1 a local
> >disk and a "remote" disk, i.e. a way to give the RAID1 software a
> >pseudo-device as the secondary disk, write data being sent also to this
> >remote disk while read data being only done via the network if the
> >local disk fails to answer after some laps of time (in order not to 
> >crowd the network with the redundant reads, if a "shared" network
> >pipe is the mean of the remote link, or simply to not waste energy).
> >
> >This would allow both remote backup and fallback.
> >
> >Is there something like that existing? the idea being to combine
> >as much as possible existing facilities and just to insert a simple
> >client/server encapsulating "disk" data at the right place (the 
> >pseudo-device) to make it work.
> >
> >Hoping this does not sound totally weird,
> >-- 
> >        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
> >                     http://www.kergis.com/
> >                       http://www.sbfa.fr/
> >Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C