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, <[email protected]> wrote: > Send Linux-cluster mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: linux clustering <[email protected]> > Subject: Re: [Linux-cluster] Cluster with shared storage on low budget > Message-ID: <[email protected]> > 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 <[email protected]> > To: linux clustering <[email protected]> > Subject: Re: [Linux-cluster] Cluster with shared storage on low budget > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > -----Original Message----- > > From: [email protected] > [mailto:[email protected]] > > 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 <[email protected]> > To: linux clustering <[email protected]> > Subject: Re: [Linux-cluster] Cluster with shared storage on low budget > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Jeff Sturm wrote: > >> -----Original Message----- > >> From: [email protected] > > [mailto:[email protected]] > >> 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 <[email protected]> > To: linux clustering <[email protected]> > Subject: Re: [Linux-cluster] Cluster with shared storage on low budget > Message-ID: > < > 263367529.33108.1297787066881.javamail.r...@zmail06.collab.prod.int.phx2.redhat.com > > > > 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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-cluster > > End of Linux-cluster Digest, Vol 82, Issue 19 > ********************************************* >
-- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
