[Gluster-users] GlusterFS as underlying Replicated Disk for App Server

[Dan Hawker]

> What sort of read/write patterns are these global transaction logs?

Generally, not too bad. The files are relatively small and are used by the
WLS Transaction recovery process to ascertain how far along a particular
global transaction set it has gotten, to allow it to ensure it can
rollback/commit everything correctly across many transactions (each
transaction could be a local resource, remote DB or remote
service/composite, so it's an ACID process to ensure data integrity across
the resources WLS accesses).

We'll end up having a few clusters and hence differing performance
requirements depending upon their use, but from our existing DEV/TEST setup
and previous experience with this stuff, it's nothing too extreme. Each
transaction log is usually a few MB in size. It grows fairly linearly and
most of the time, most are over and done with in a short time. Long running
processes or those that have a human task (manager authoriser button in a
web app for instance), could be hanging around for a significant time.

IOPS wise again, we'll have to test properly, but again from experience and
what we've seen so far, nothing difficult. It doesn't touch the sides of
our existing NAS head.

Only one process (as in a single WLS instance == a single JVM == single
process in Linux), will access each log at a time, so performance issues
due to locking shouldn't be a real issue. The problem comes when disaster
strikes and we need to recover any in-flight transactions. Another WLS
instance can recover these, but they need access to the transaction logs,
hence the usual use of NFS.



> I've found GlusterFS excels at use cases were you need to read or
> write entire files at a time, and in great volume from many sources.
> We use it as storage for our production users who read and write a lot
> of large media files (mostly from our render farm, which can push a
> lot of data around very quickly), and it works brilliantly.
>
> However, we did attempt to run applications off it (as we were running
> applications off an NFS share previously), and host our Linux user
> home drives from it, and both of these cases didn't quite work out for
> us.  GlusterFS appears to not like reading portions of a file at a
> time (say, when you load a binary or library, and Linux only requires
> a small part of that file read).  We ended up going back to NFS for
> home and apps, but keeping GlusterFS where it excelled - for large
> volume file writes and reads of entire files.
>
>
Hmm, nice to know. We won't be running any apps directly off of it per-se,
just keeping some artefacts such as these logs there. However, am pretty
sure WLS appends to the file as it goes until it hits a particular (user
definable) size, and then creates another one, so the use-case doesn't
quite fit the 'write an entire file at a time' scenario.

Some serious testing is required :)

Thanks for your thoughts

Dan



> -Dan
>
>
> On 8 October 2013 00:27, Dan Hawker <danhawker at googlemail.com> wrote:
> >
> > Hi All,
> >
> > We have a requirement for a common replicated filesystem between our two
> > datacentres, mostly for DR and patching purposes when running Weblogic
> > clusters.
> >
> > For those that are not acquainted, Weblogic has a persistent store that
> it
> > uses for global transaction logs amongst other things. This store can be
> > hosted on shared disk (usually NFS), or in recent versions within an
> Oracle
> > DB. Unfortunately, some of the products that we use, have to use the disk
> > option.
> >
> > Ordinarily I'd just follow Oracle's guidelines and use an Enterprise NAS
> > head and NFS, however the NAS head we have at my present role, has rather
> > lacklustre replication granularity (every 5mins), which just won't cut
> it,
> > so we're looking at alternatives, including throwing more cash at the
> > storage vendor.
> >
> > The Linux team here use GlusterFS to host and replicate their Puppet
> > infrastructure between the datacentres. They like and understand it, and
> say
> > it's got good performance, so we were wondering if we could also leverage
> > Gluster for the persistent data stores that can't be DB hosted.
> >
> > Wondered if anyone has tried this kind of thing with Weblogic or any
> other
> > JEE app server before, and if it is feasible. We'll obviously test this
> > extensively, but before we do spend time and resource, we're just after
> some
> > degree of confidence that it may work at all.
> >
> > Thanks
> >
> > Dan
> >
> > --
> > Dan Hawker
> > --
> >
> > _______________________________________________
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
>
>
> --
> Dan Mons
> R&D SysAdmin
> Cutting Edge
> http://cuttingedge.com.au
>



-- 
--
Dan Hawker
danhawker at googlemail.com
07773 348975
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131008/539ca2a3/attachment.html>