The failover problem I saw was this:
I have 3-4 different farms configured and after a rough period of 24hr the
primary would failover to the secondary(for no apparent reason) but not all the
farms would fail over as when I logged into the secondary I had some farms down
along with their interfaces down. Which makes no sense because if it fails over
all the interfaces and farms should come up??
I thought the error may be caused because some are virtual interfaces and
others are vlan interfaces but from your comment this shouldn't matter ... only
the physical ip tied to the eth adaptor / web gui should not failover which if
I'm correct means that all my virtual / vlan interfaces and associated farms
should failover together?
Steven Lepage
Network Administrator
SkyTrac Systems LTD
200-170 Rutland Road North
Kelowna, BC V1X 3B2
(001) (250) 765-2393 (Office)
From: laura Garcia [mailto:[email protected]]
Sent: Tuesday, December 06, 2011 4:01 PM
To: [email protected]
Subject: Re: [Zenloadbalancer-support] Server farm stops on its own..
Hi Steve,
I write over your mail.
On Tue, Dec 6, 2011 at 10:54 PM, Steve LePage
<[email protected]<mailto:[email protected]>> wrote:
I think I may have found my cluster issue in regards to the failover not
working correctly. The throughput issue seems fine now with the additions and
running on a single LB for the last week and a half has proven that the system
works correctly.
This is a very weird behaviour, cause the cluster is an independent service of
farm services. What was exactly your problem with the failover?
What I noticed today is that some of my farms virtual adaptors got created as
vlan adaptors (eth#.# instead of eth#:#) and if / when the cluster failed over
not all ip's failed over and I believe this may be the reason?
The only ones interfaces that must not failover are the ip physical cluster
nodes and the management ip (web gui ip).
There is no need for these adaptors to be vlan they would be fine set as
virtual, I was wondering the best method to change them to virtual with the
least downtime possible as this is on a live system.
I'm assuming that it's probably rename the if_eth#.#_conf files to
if_eth#:#_conf and edit the file so the definition in the file uses : not . and
restart the zendloadbalancer service?
No, it isn't enough to change the config files. As you've vlan interfaces, I
think could be created virtual ips online with the same ip configuration and
then delete the vlan interface. The farm doesn't need to be restarted as it's
bind to the same ip and port, at least in my lab works well without restarting.
Regards,
Laura.
From: Steve LePage [mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, November 18, 2011 1:03 PM
To:
[email protected]<mailto:[email protected]>
Subject: Re: [Zenloadbalancer-support] Server farm stops on its own..
Perfect I'll try that and let you know how it works out..
From: laura Garcia [mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, November 18, 2011 12:40 PM
To:
[email protected]<mailto:[email protected]>
Subject: Re: [Zenloadbalancer-support] Server farm stops on its own..
Hi Steve,
We've wrote a TIP in our facebook page to increase the throughput of ZenLB,
try this:
root ~# echo 100000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
root ~# echo 5 > /proc/sys/net/ipv4/tcp_fin_timeout
Regards,
Laura.
On Fri, Nov 18, 2011 at 8:13 PM, Steve LePage
<[email protected]<mailto:[email protected]>> wrote:
We have the current release setup in a 2 machine cluster that runs an http /
https farms. We have setup our own farmguardian script and have had the farm
running for a long time with no problems in the test environment. We recently
went live and have noticed that the https farm averages around 500 Connections
which is fine and working however every once and a while the https farm just
stops on its own without warning and we have to restart it. This has just
started happening since we started to load it up. I have set the https farm to
a max connection limit of 30000 so this 500 connections shouldn't be causing
the issue however the farm is dying for no reason and it's becoming
concerning.. Any Ideas?
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
