> >
> > I can't see a way around some significant downtime even with that, and
> > there is no way they will give me the option to be down from a planned
> > perspective.
>
> So, out of nowhere straight into production, without performance user
> acceptance testing period? And they won't allow
Hopefully the following provide some relieves ...
1. Enable lock trimming tunable. It is particularly relevant if NFS-GFS
is used by development type of workloads (editing, compiling, build,
etc) and/or after filesystem backup. Unlike fast statfs, this tunable is
per-node base (you don't need
Doug Tucker wrote:
I don't mean to teach you to suck eggs, so please don't take this as
patronizing, 'cause that's not my intention in any way shape or form,
but since 1TB SATA disks go for around $160, could you not just plug a
couple of those in as scratch space for the migration?
>
I can't
--- On Mon, 10/6/08, Doug Tucker <[EMAIL PROTECTED]> wrote:
> From: Doug Tucker <[EMAIL PROTECTED]>
> Subject: Re: [Linux-cluster] rhcs + gfs performance issues
> To: "linux clustering"
> Received: Monday, October 6, 2008, 4:05 PM
> >
> > A
>
> I don't mean to teach you to suck eggs, so please don't take this as
> patronizing, 'cause that's not my intention in any way shape or form,
> but since 1TB SATA disks go for around $160, could you not just plug a
> couple of those in as scratch space for the migration?
I can't see a way a
Doug Tucker wrote:
And reverting back to the Tru64/Alpha system is?
Nope, completely out of drive space on that one. I'm basically stuck
where I'm at with it underperforming.
I don't mean to teach you to suck eggs, so please don't take this as
patronizing, 'cause that's not my intention in
>
> And reverting back to the Tru64/Alpha system is?
Nope, completely out of drive space on that one. I'm basically stuck
where I'm at with it underperforming.
> Gordan
>
> --
> Linux-cluster mailing list
> Linux-cluster@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
--
L
Doug Tucker wrote:
O
Worse, you may need to change the GFS file system options for the new
version, so you may end up having to backup/restore the data. I don't
think you can avoid cluster downtime for the upgrade.
Then upgrading is not an option.
And reverting back to the Tru64/Alpha syste
O
> Worse, you may need to change the GFS file system options for the new
> version, so you may end up having to backup/restore the data. I don't
> think you can avoid cluster downtime for the upgrade.
Then upgrading is not an option.
>
> Gordan
>
> --
> Linux-cluster mailing list
> Linux-clu
Doug Tucker wrote:
1) Tru64 and TruCluster with Advfs from 7 years ago is simply that much
more robust and mature than RHES4 and CS/GFS and therefore tremendously
outperforms it...or
RHEL4 is quite old. It's been a while since I used it for clustering.
RHEL5 has yielded considerably better perf
> 2) do you know if RHEL5 will participate in a RHEL4 cluster?
Not with incompatible lock modules (DLM vs. GULM). Sorry. I don't
beleve there's a way to upgrade while the cluster is online.
--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www.redhat.com/mailman/listinfo/linux-cl
> > 1) Tru64 and TruCluster with Advfs from 7 years ago is simply that much
> > more robust and mature than RHES4 and CS/GFS and therefore tremendously
> > outperforms it...or
>
> RHEL4 is quite old. It's been a while since I used it for clustering.
> RHEL5 has yielded considerably better perfo
Doug Tucker wrote:
In your cluster.conf, make sure in the
section is pointing at a private crossover IP of the node. Say you have
2nd dedicated Gb interface for the clustering, assign it address, say
10.0.0.1, and in the hosts file, have something like
10.0.0.1 node1c
10.0.0.2 node2c
That w
--- On Fri, 10/3/08, Doug Tucker <[EMAIL PROTECTED]> wrote:
> From: Doug Tucker <[EMAIL PROTECTED]>
> Subject: Re: [Linux-cluster] rhcs + gfs performance issues
> To: "linux clustering"
> Received: Friday, October 3, 2008, 3:47 PM
> Let me say first, I ap
Let me say first, I appreciate your help tremendously. Let me answer
some questions, and then I need to go do some homework you have
suggested.
> In your cluster.conf, make sure in the
>
>
> section is pointing at a private crossover IP of the node. Say you have
> 2nd dedicated Gb interface
Doug Tucker wrote:
Do you have a separate gigabit interface/vlan just for cluster
>> communication? RHCS doesn't use a lot of sustained bandwidth but
>> performance is sensitive to latencies for DLM comms. If you only have
>> 2 nodes, a direct crossover connection would be ideal.
Not sure how
Thanks so much for the reply, hopefully this will lead to something.
On Fri, 2008-10-03 at 17:25 +0100, Gordan Bobic wrote:
> It sounds like you have a SAN (fibre attached storage) that you are trying to
> turn into a NAS. That's justifiable if you have multiple mirrored SANs, but
> makes a mock
ike.
Gordan
-Original Message-
From: "Doug Tucker" <[EMAIL PROTECTED]>
To: linux-cluster@redhat.com
Sent: 03/10/08 16:54
Subject: [Linux-cluster] rhcs + gfs performance issues
We recently migrated from a 7 year old file server running on a single
proc dec alpha running Tr
We recently migrated from a 7 year old file server running on a single
proc dec alpha running Tru64 and utilizing Truclustering for HA, to a
Redhat cluster suite and gfs for HA on a dual duo core dell 2950 with
32gb ram, and have been having major performance issues. Both have
fiber attached stora
19 matches
Mail list logo
