Re: Linux-cluster Digest, Vol 82, Issue 19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
Hello to all !
 
will you please guide me how can do a practice of clustrign as well as loadbalancer for testing enviorment can all of you please guide me what are the basic requirements
 
i have three centos machine apache,Mysql and postfix is runing on these machines
 
 
--
Regards..//
Anuj Singh Chauhan
(Voice): 09013203509




On Tue, Feb 15, 2011 at 10:30 PM, <linux-cluster-request@xxxxxxxxxx> wrote:
Send Linux-cluster mailing list submissions to
       linux-cluster@xxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
       https://www.redhat.com/mailman/listinfo/linux-cluster
or, via email, send a message with subject or body 'help' to
       linux-cluster-request@xxxxxxxxxx

You can reach the person managing the list at
       linux-cluster-owner@xxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linux-cluster digest..."


Today's Topics:

  1. Re: Cluster with shared storage on low budget (Gordan Bobic)
  2. Re: Cluster with shared storage on low budget (Jeff Sturm)
  3. Re: Cluster with shared storage on low budget (Gordan Bobic)
  4. Re: Cluster with shared storage on low budget (Bob Peterson)


----------------------------------------------------------------------

Message: 1
Date: Tue, 15 Feb 2011 13:31:42 +0000
From: Gordan Bobic <gordan@xxxxxxxxxx>
To: linux clustering <linux-cluster@xxxxxxxxxx>
Subject: Re: Cluster with shared storage on low budget
Message-ID: <4D5A803E.5090106@xxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Nikola Savic wrote:
> Gordan Bobic wrote:
>> Something else just occurs to me - you mentioned MySQL. You do realize
>> that the performance of it will be attrocious on a shared cluster file
>> system (ANY shared cluster file system), right? Unless you only intend
>> to run mysqld on a single node at a time (in which case there's no
>> point in putting it on a cluster file system).
>
>   MySQL Master and Slave(s) will run on single node. No two MySQL
> instances will run on same set of data. Shared storage for MySQL data
> should enable easier movement of MySQL instance between nodes. Eg. when
> MySQL master needs to be moved from one node to other, I assume it would
> be easier with DRBD, because I would "only" need to stop MySQL on one
> node and start it on other configured to use same set of data.

There is a better way to do that. Run DRBD in active-passive mode, and
grab the fail-over scripts from heartbeat. Then set up a dependency in
cluster.conf that will handle a combined service of DRBD disk (handling
active/passive switch), file system (mounting the fs once the DRBD
becomes active locally, and mysql. You define them as dependant on each
other in cluster.conf by suitable nesting.

> Additionally, floating IP address assigned to MySQL master would need to
> be re-assigned to new node.

You can make that IP a part of the dependency stack mentioned above.

> Slaves would also need to be restarted to
> connect to new master. Even without floating IP used only my MySQL
> Master, slaves and web application can easily be reconfigured to use new
> IP. Do you see problem in this kind of setup?

If the IP fails over and the FS is consistent you don't need to change
any configs - MySQL slaves will re-try connecting until they succeed.
Just make sure your bin-logs are on the same mount as the rest of MySQL,
since they have to fail over with the rest of the DB.

Gordan



------------------------------

Message: 2
Date: Tue, 15 Feb 2011 10:55:43 -0500
From: Jeff Sturm <jeff.sturm@xxxxxxxxxx>
To: linux clustering <linux-cluster@xxxxxxxxxx>
Subject: Re: [Linux-cluster] Cluster with shared storage on low budget
Message-ID:
       <64D0546C5EBBD147B75DE133D798665F0855C0F4@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

> -----Original Message-----
> From: linux-cluster-bounces@xxxxxxxxxx
[mailto:linux-cluster-bounces@xxxxxxxxxx]
> On Behalf Of Gordan Bobic
> Sent: Tuesday, February 15, 2011 7:05 AM
>
> Volume resizing is, IMO, over-rated and unnecessary in most cases,
except where data
> growth is quite mind-boggling (in which case you won't be using MySQL
anyway).

We actually resize volumes often.  Some of our storage volumes have 30
LUNs or more.  We have so many because we've virtualized most of our
infrastructure, and some of the hosts are single-purpose hosts.

We don't want to allocate too more storage in advance, simply because
it's easier to grow than to shrink.  Stop the host, grow the volume,
e2fsck/resize2fs, start up and go.  Much nicer than increasing disk
capacity on physical hosts.

CLVM works well for this, but that's about all it's good for IMHO.  I
prefer to use the SAN's native volume management over CLVM when
available.

Haven't tried DRBD yet but I'm really tempted... it sounds like it has
come a long way since its modest beginnings.

-Jeff





------------------------------

Message: 3
Date: Tue, 15 Feb 2011 16:17:03 +0000
From: Gordan Bobic <gordan@xxxxxxxxxx>
To: linux clustering <linux-cluster@xxxxxxxxxx>
Subject: Re: Cluster with shared storage on low budget
Message-ID: <4D5AA6FF.8080608@xxxxxxxxxx>
Content-Type: text/plain; charset=windows-1252; format=flowed

Jeff Sturm wrote:
>> -----Original Message-----
>> From: linux-cluster-bounces@xxxxxxxxxx
> [mailto:linux-cluster-bounces@xxxxxxxxxx]
>> On Behalf Of Gordan Bobic
>> Sent: Tuesday, February 15, 2011 7:05 AM
>>
>> Volume resizing is, IMO, over-rated and unnecessary in most cases,
> except where data
>> growth is quite mind-boggling (in which case you won't be using MySQL
> anyway).
>
> We actually resize volumes often.  Some of our storage volumes have 30
> LUNs or more.  We have so many because we've virtualized most of our
> infrastructure, and some of the hosts are single-purpose hosts.
>
> We don't want to allocate too more storage in advance, simply because
> it's easier to grow than to shrink.  Stop the host, grow the volume,
> e2fsck/resize2fs, start up and go.  Much nicer than increasing disk
> capacity on physical hosts.

Seems labour and downtime intensive to me. Maybe I'm just used to
environments where that is an unacceptable tradeoff vs. ?40/TB for storage.

Not to mention that it makes you totally reliant on SAN level
redundancy, which I also generally deem unacceptable except on very high
end SANs that have mirroring features.

Additionally, considering you can self-build a multi-TB iSCSI SAN for a
few hundred ?/$/? which will have volume growing ability (use sparse
files for iSCSI volumes and write a byte to a greater offset), I cannot
really see any justification whatsoever for using LVM with SAN based
storage.

> Haven't tried DRBD yet but I'm really tempted... it sounds like it has
> come a long way since its modest beginnings.

Not sure how far back you are talking about but I have been using it in
production in both active-active and active-passive configurations since
at least 2007 with no problems. From the usage point of view, the
changes have been negligible.

Gordan



------------------------------

Message: 4
Date: Tue, 15 Feb 2011 11:24:26 -0500 (EST)
From: Bob Peterson <rpeterso@xxxxxxxxxx>
To: linux clustering <linux-cluster@xxxxxxxxxx>
Subject: Re: Cluster with shared storage on low budget
Message-ID:
       <263367529.33108.1297787066881.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset=utf-8

----- Original Message -----
| We don't want to allocate too more storage in advance, simply because
| it's easier to grow than to shrink. Stop the host, grow the volume,
| e2fsck/resize2fs, start up and go. Much nicer than increasing disk
| capacity on physical hosts.

These might be good for ext3/4, but with gfs and gfs2 you can lvresize
and gfs2_grow while the lv is mounted.  In fact, we expect it.
Just make sure the vg has the clustered bit set (vgchange -cy) first.

Regards,

Bob Peterson
Red Hat File Systems



------------------------------

--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

End of Linux-cluster Digest, Vol 82, Issue 19
*********************************************



--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux