<div>Hi,</div> <div>Hello to all !</div> <div> </div> <div>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 </div> <div> </div> <div>i have three centos machine apache,Mysql and postfix is runing on these machines</div> <div> </div> <div> </div> <div>-- Regards..// Anuj Singh Chauhan (Voice): 09013203509 </div> <div class="gmail_quote">On Tue, Feb 15, 2011 at 10:30 PM, <<a href="mailto:linux-cluster-request@redhat.com">linux-cluster-request@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Send Linux-cluster mailing list submissions to <a href="mailto:linux-cluster@redhat.com">linux-cluster@redhat.com</a> To subscribe or unsubscribe via the World Wide Web, visit <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> or, via email, send a message with subject or body 'help' to <a href="mailto:linux-cluster-request@redhat.com">linux-cluster-request@redhat.com</a> You can reach the person managing the list at <a href="mailto:linux-cluster-owner@redhat.com">linux-cluster-owner@redhat.com</a> 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 <<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>> To: linux clustering <<a href="mailto:linux-cluster@redhat.com">linux-cluster@redhat.com</a>> Subject: Re: [Linux-cluster] Cluster with shared storage on low budget Message-ID: <<a href="mailto:4D5A803E.5090106@bobich.net">4D5A803E.5090106@bobich.net</a>> 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 <<a href="mailto:jeff.sturm@eprize.com">jeff.sturm@eprize.com</a>> To: linux clustering <<a href="mailto:linux-cluster@redhat.com">linux-cluster@redhat.com</a>> Subject: Re: [Linux-cluster] Cluster with shared storage on low budget Message-ID: <64D0546C5EBBD147B75DE133D798665F0855C0F4@hugo.eprize.local> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: <a href="mailto:linux-cluster-bounces@redhat.com">linux-cluster-bounces@redhat.com</a> [mailto:<a href="mailto:linux-cluster-bounces@redhat.com">linux-cluster-bounces@redhat.com</a>] > 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 <<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>> To: linux clustering <<a href="mailto:linux-cluster@redhat.com">linux-cluster@redhat.com</a>> Subject: Re: [Linux-cluster] Cluster with shared storage on low budget Message-ID: <<a href="mailto:4D5AA6FF.8080608@bobich.net">4D5AA6FF.8080608@bobich.net</a>> Content-Type: text/plain; charset=windows-1252; format=flowed Jeff Sturm wrote: >> -----Original Message----- >> From: <a href="mailto:linux-cluster-bounces@redhat.com">linux-cluster-bounces@redhat.com</a> > [mailto:<a href="mailto:linux-cluster-bounces@redhat.com">linux-cluster-bounces@redhat.com</a>] >> 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 <<a href="mailto:rpeterso@redhat.com">rpeterso@redhat.com</a>> To: linux clustering <<a href="mailto:linux-cluster@redhat.com">linux-cluster@redhat.com</a>> Subject: Re: [Linux-cluster] Cluster with shared storage on low budget Message-ID: <<a href="mailto:263367529.33108.1297787066881.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com">263367529.33108.1297787066881.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com</a>> 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 <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> End of Linux-cluster Digest, Vol 82, Issue 19 ********************************************* </blockquote></div>