plainblack.com
Username Password
search
Bookmark and Share

    

clustering

User arjan
Date 5/28/2009 1:46 pm
Views 1557
Rating 0    Rate [
|
]
Previous · Next
User Message
arjan
Since the word clustering is used more often, a question. Since some
time I'm thinking about a WebGUI setup with no single point of failure.
The main problem here is the storage. I've experimented with network
attached storage (coraid) but that's nothing I would use in a production
environment.
Does anybody have a suggestion as to how to setup an environment where
multiple modperl instances could read and write to the same disk, but a
disk that's served by multiple machines? Preferably without a script
that checks the connection and changes the configuration on failure.

Kind regards,
Arjan.


Back to Top
Rate [
|
]
 
 
JT
> Does anybody have a suggestion as to how to setup an environment where
> multiple modperl instances could read and write to the same disk,  
> but a
> disk that's served by multiple machines? Preferably without a script
> that checks the connection and changes the configuration on failure.


The best way to do it is a storage area network. However, that's  
pretty pricey, but it's the only good way to do it as far as I'm  
concerned. Everything else has lots of limitations and gotchas.


Back to Top
Rate [
|
]
 
 
Mike_S
We use a 14-disk fibre channel NetApp filehead and mount via NFS.  As
JT said, everything has limitations and gotchas.




On Thu, May 28, 2009 at 1:40 PM,   wrote:
> JT wrote:
>
>> Does anybody have a suggestion as to how to setup an environment where
>> multiple modperl instances could read and write to the same disk,
>> but a
>> disk that's served by multiple machines? Preferably without a script
>> that checks the connection and changes the configuration on failure.
>
>
> The best way to do it is a storage area network. However, that's
> pretty pricey, but it's the only good way to do it as far as I'm
> concerned. Everything else has lots of limitations and gotchas.
>
>
> http://www.plainblack.com/webgui/dev/discuss/clustering/1
>
>
> --
>
> Plain Black, makers of WebGUI
> http://plainblack.com
>
>


Back to Top
Rate [
|
]
 
 
patspam
We're using NFS too, although on a much smaller scale. But we've been talking about tackling it from a different angle, that is, extending WebGUI to distribute files across the cluster.

Patrick

On Fri, May 29, 2009 at 6:00 AM, <mike@donor.com> wrote:
Mike_S wrote:

We use a 14-disk fibre channel NetApp filehead and mount via NFS.  As
JT said, everything has limitations and gotchas.




On Thu, May 28, 2009 at 1:40 PM,   wrote:
> JT wrote:
>
>> Does anybody have a suggestion as to how to setup an environment where
>> multiple modperl instances could read and write to the same disk,
>> but a
>> disk that's served by multiple machines? Preferably without a script
>> that checks the connection and changes the configuration on failure.
>
>
> The best way to do it is a storage area network. However, that's
> pretty pricey, but it's the only good way to do it as far as I'm
> concerned. Everything else has lots of limitations and gotchas.
>
>
> http://www.plainblack.com/webgui/dev/discuss/clustering/1
>
>
> --
>
> Plain Black&#44; makers of WebGUI
> http://plainblack.com
>
>


http://www.plainblack.com/webgui/dev/discuss/clustering/2


--

Plain Black&#44; makers of WebGUI
http://plainblack.com




Back to Top
Rate [
|
]
 
 
Mike_S
On Thu, May 28, 2009 at 6:00 PM,   wrote:
> patspam wrote:
>
> We're using NFS too, although on a much smaller scale. But we've been
> talking about tackling it from a different angle, that is, extending WebGUI
> to distribute files across the cluster.

You may want to take a look at the CDN feature recently added.  Since
the act of syncing is not S3 specific, you can script it to do
anything.  So you could have a script that calls rsync to replicate
the content to the local drives of each node in your cluster.  I
suspect with a little effort, the same script could be smart enough to
run on all servers, and rsync to all servers other than itself (eg A
-> B&C, B -> A&C, C -> A&B).  That way you would get full redundancy,
the capacity of the cluster, and the performance of local disk on each
machine.  Just an idea that would require minimal coding.


Back to Top
Rate [
|
]
 
 
patspam
Hey Mike,

Yeah that's the sort of thing we're excited about! I'll check out that script for sure. Love the S3 direction you guys took in the last release.

We were thinking more down the lines of having storage events trigger asynchronous per-file syncing across the cluster, but that would obviously take more work to implement. Maybe something to discuss at the WUC hackathon..

Patrick

On Fri, May 29, 2009 at 11:50 AM, <mike@donor.com> wrote:
Mike_S wrote:

On Thu, May 28, 2009 at 6:00 PM,   wrote:
> patspam wrote:
>
> We're using NFS too, although on a much smaller scale. But we've been
> talking about tackling it from a different angle, that is, extending WebGUI
> to distribute files across the cluster.

You may want to take a look at the CDN feature recently added.  Since
the act of syncing is not S3 specific, you can script it to do
anything.  So you could have a script that calls rsync to replicate
the content to the local drives of each node in your cluster.  I
suspect with a little effort, the same script could be smart enough to
run on all servers, and rsync to all servers other than itself (eg A
-> B&C, B -> A&C, C -> A&B).  That way you would get full redundancy,
the capacity of the cluster, and the performance of local disk on each
machine.  Just an idea that would require minimal coding.


http://www.plainblack.com/webgui/dev/discuss/clustering/4


--

Plain Black&#44; makers of WebGUI
http://plainblack.com




Back to Top
Rate [
|
]
 
 
JT
Patspam, what are you mounting via NFS? Is it a net appliance, another  
server, something else?

When we set up inexpensive clusters where we don't have the benefit of  
a SAN, then we set up one web node as the primary server and mount  
that server from the other web nodes. Then we set up an rsync mirror  
so that the files from the primary server are mirrored over to an  
alternate location on at least one other node. That way we can make  
that other node the primary should it become necessary. In that case  
it's not an automatic failover, which is what Arjan was looking for.



Back to Top
Rate [
|
]
 
 
    



© 2010 Plain Black Corporation | All Rights Reserved