Needs suggestion for redundant Storage

Michael Schuh michael.schuh at gmail.com
Wed Apr 12 11:24:13 UTC 2006


> CARP can let you failover an IP address and ggated provides remote
> access to a physical disk device but the combination will not give you
> a fault tolerant server.  One major problem is that you will lose the
> content of the cache when a system fails - this amounts to roughly the
> last 30 seconds of data written (though the write-through behaviour of
> NFS may mitigate this).  Other potential problems are:  Loss of
> connection state - NFS is stateless but lockd and mountd retain client
> state information so you will lose any client locks and the server may
> object to being presented with filehandles that were issued by a
> different host.  Handling the failure of the inactive host - you will
> need to identify the behaviour when the remote part of your mirror
> becomes inaccessible.

Yes, i agree, that was the reason why i would use ggated whit carp and
geom mirror, but the problem was the mount of the shared filesystem....

carp..if the machine or the netif goes to hell
ggated to mirror the shared disks over the network with gmirror
if one disk fails gmirror noticed that and let me show them....

>
> And none of the above protects against filesystem corruption.  Cheap
> hardware presumably means that you won't be using ECC RAM and there
> will me minimal (if any) protection against data corruption on the
> various busses.  The odd bit-flip will be virtually undetectable
> until someone notices that their data is corrupt.
i agree also with them....but i can not have all the things
another solution to prevent that was an cluster-tool that mirrors
files not filesystems over the net....
may be i should make a try or think over another solution...

> Without backups, you can't recover from any problems - user errors or
> system errors.  I'm certain the lack of backups _will_ become the
> focus as soon as something valuable is lost.  And given the sort of
> dodgy setup you want to construct, that may not take long.
>
yes i know, and i be not there friend, backup is my friend by any problem with
the boxes....but this comes later if the money is there :-) or the
management will spend the money....

> >> Read the mailing lists - they are full of problems with them.  If
> >> you value your data you will not use Sil controller.
> >>
> >yes, this do i also know, but if i have a lot of them, and 2 falls out,
> >so what happens if i had another box with my data?
>
> The data is just as likely to be garbled on the remote system as well.
> I don't think people are saying that the Sil controllers stop working,
> they just don't work reliably so you can't rely on any data that has
> been handled by a Sil controller.
>
> >Oh that was fist not my idea, the management has questioned these features,
> >in have said "OMG you aore not serious", but  is it...... :-((
> >so that is better for me and my job to make what management wishes,
> >later i can say.....i have you warned......
>
> You need to write a memo to your management that clearly points out the
> risks.  Keep a notarised copy for yourself and make sure yout CV is up
> to date.  You can rest assured that you will be the scaegoat when it
> all goes wrong.

*grin*  that was also an good idea, the first disagreement i have made
past days...the next follows if the etat-management begins.....

i would sort the costs for possibiliy disaster recovery in relativiness of
costs of data-corruption (in the cas all data goes to hell)....
i think then comes the right thinking back.....
i think the best question for that to the management was:
"what if the data goes to /dev/null by any failure fo the Hardware,
and keep in mind, we do not have any backup."


regars

michael


More information about the freebsd-stable mailing list