[OpenAFS] Re: High Available Transparent Shared-Disk
Jake Thebault-Spieker
summatusmentis@gmail.com
Mon, 11 Apr 2011 10:17:38 -0500
--bcaec51b1c17b8ca0b04a0a61455
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Apr 11, 2011 at 10:08 AM, Andrew Deason <adeason@sinenomine.net>wrote:
> On Sun, 10 Apr 2011 03:45:54 -0700 (PDT)
> a a <msmfree2@yahoo.com> wrote:
>
> > Hi All,
>
> Please don't multipost.
>
> > We are searching around a solution like a "high available transparent
> > file system" that makes the fault transparent to the application, so
> > in case of fault, redundant machine still can access the files even
> > the master machine is down (replica issue or such a thing).
> > It seems OpenASF doesn't have fail-over feature, am I right? My
> > question is that can OpenASF help us in our case?
>
> What is typically said is that, out of the box, OpenAFS has redundany
> for read-only data. What this means is that you can write data to one
> location (the "read-write volume"), and later on you decide when to
> distribute that data to multiple read-only sites ("releasing the
> volume"). After that, clients can read the data from the read-only
> sites, and will failover automatically if any of those sites fail.
>
> Releasing the volume data is normally done as an administrative action.
> It is automatable, and certainly some sites do automated releases a lot,
> but it's probably not useful to do it very frequently (e.g. every 5
> seconds). So OpenAFS doesn't really have a way to replicate data as it
> is written, right now. However, read-write replication is a known
> desired feature already, and some work has been done in that area, so it
> may exist in the future.
>
> However, it is still possible today to achieve some kind of read-write
> replication with OpenAFS volumes by just using some other kind of
> underlying storage. If you create your AFS volumes on a SAN, or
> DRBD-backed storage, you can achieve redundancy for read-write data if
> you bring up a fileserver on another machine when an outage occurs.
> Many sites have AFS data on a SAN that they can quickly serve from
> different fileservers, and I know of at least one site that has
> DRBD-backed fileservers that I believe have worked well.
>
>
> Also, since you seem to be asking this same question of several projects
> (the exact same question, in fact :), you may want to look at the Coda
> filesystem. Coda is very AFS-like, and offers built-in read-write
> replication. I believe it is not as mature/stable as OpenAFS, but you
> can judge for yourself if it fits your needs.
>
>
When I was at CMU this past summer, working with the people who develop
Coda, I would recommend against using it in production where you actually
care about your data. The professor who was developing (and still uses) Coda
still occassionally has data loss issues, and this has been some 10+ years
after they stopped developing Coda as a research project.
This professor has an employee that works on some Coda developement, but
does not support it (beyond when there is data loss within the research
group).
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--
Jacob Thebault-Spieker
Cell: (320) 288-6412
http://summatusmentis.com
--bcaec51b1c17b8ca0b04a0a61455
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 10:08 AM, Andrew=
Deason <span dir=3D"ltr"><<a href=3D"mailto:adeason@sinenomine.net">ade=
ason@sinenomine.net</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
On Sun, 10 Apr 2011 03:45:54 -0700 (PDT)<br>
a a <<a href=3D"mailto:msmfree2@yahoo.com">msmfree2@yahoo.com</a>> wr=
ote:<br>
<br>
> Hi All,<br>
<br>
Please don't multipost.<br>
<div class=3D"im"><br>
> We are searching around a solution like a "high available transpa=
rent<br>
> file system" that makes the fault transparent to the application,=
so<br>
> in case of fault, redundant machine still can access the files even<br=
>
> the master machine is down (replica issue or such a thing).<br>
> It seems OpenASF doesn't have fail-over feature, am I right? My<br=
>
> question is that can OpenASF help us in our case?<br>
<br>
</div>What is typically said is that, out of the box, OpenAFS has redundany=
<br>
for read-only data. What this means is that you can write data to one<br>
location (the "read-write volume"), and later on you decide when =
to<br>
distribute that data to multiple read-only sites ("releasing the<br>
volume"). After that, clients can read the data from the read-only<br>
sites, and will failover automatically if any of those sites fail.<br>
<br>
Releasing the volume data is normally done as an administrative action.<br>
It is automatable, and certainly some sites do automated releases a lot,<br=
>
but it's probably not useful to do it very frequently (e.g. every 5<br>
seconds). So OpenAFS doesn't really have a way to replicate data as it<=
br>
is written, right now. However, read-write replication is a known<br>
desired feature already, and some work has been done in that area, so it<br=
>
may exist in the future.<br>
<br>
However, it is still possible today to achieve some kind of read-write<br>
replication with OpenAFS volumes by just using some other kind of<br>
underlying storage. If you create your AFS volumes on a SAN, or<br>
DRBD-backed storage, you can achieve redundancy for read-write data if<br>
you bring up a fileserver on another machine when an outage occurs.<br>
Many sites have AFS data on a SAN that they can quickly serve from<br>
different fileservers, and I know of at least one site that has<br>
DRBD-backed fileservers that I believe have worked well.<br>
<br>
<br>
Also, since you seem to be asking this same question of several projects<br=
>
(the exact same question, in fact :), you may want to look at the Coda<br>
filesystem. Coda is very AFS-like, and offers built-in read-write<br>
replication. I believe it is not as mature/stable as OpenAFS, but you<br>
can judge for yourself if it fits your needs.<br>
<font color=3D"#888888"><br></font></blockquote><div><br>When I was at CMU =
this past summer, working with the people who develop Coda, I would recomme=
nd against using it in production where you actually care about your data. =
The professor who was developing (and still uses) Coda still occassionally =
has data loss issues, and this has been some 10+ years after they stopped d=
eveloping Coda as a research project. <br>
<br>This professor has an employee that works on some Coda developement, bu=
t does not support it (beyond when there is data loss within the research g=
roup). <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt=
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color=3D"#888888">
--<br>
Andrew Deason<br>
<a href=3D"mailto:adeason@sinenomine.net">adeason@sinenomine.net</a><br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
OpenAFS-info mailing list<br>
<a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.org</a><br=
>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Jacob Theba=
ult-Spieker<br>Cell: (320) 288-6412<br><a href=3D"http://summatusmentis.com=
">http://summatusmentis.com</a><br>
--bcaec51b1c17b8ca0b04a0a61455--