Viability of nginx instead of hardware load balancer?
david at icewatermedia.com
Wed Sep 16 18:03:58 MSD 2009
DSL was only an example of one distro ( good for testing to prove a
Also for no SPF, you would do the same thing I suggested with VM but with
physical 1U boxes, were your network could provide the fail over, and you
would simply have 2 very cheap nginx based load balancer so quick fail
over if one node had an issue.
The question was on viability not on application, which is why I was
outlining the difference methodologies to accomplish this.
Regard cost, that all depend on your setup. You could have multiple
failing over hardware nodes that on boot pull a config from a repo
somewhere. And Have an internal system to reconfigure the conf and commit
it to the repo with changes ( If using SVN you could then have a post-commit
hook to tell nginx to get the new file the reload)
So you could actually keep you Admin time very low, as low if not lower
than learning and administrating a purchased hardware system.
It the age old plan for growth, and you can feed an army, fail to plan and
starve the army.
From: owner-nginx at sysoev.ru [mailto:owner-nginx at sysoev.ru] On Behalf Of Gena
Sent: Wednesday, September 16, 2009 3:07 AM
To: David Murphy
Subject: Re: Viability of nginx instead of hardware load balancer?
On Wednesday, September 16, 2009 at 0:09:50, David Murphy wrote:
DM> Regarding ESX you are completely wrong, as I mentioned each VM
DM> would be on their own HOST which means a the entire cluster would
DM> have to fail to cause the LB to not switch over.
yes, this is my mistake, sorry.
DM> Also DSL has been ported to 2.6 also.
DM> To be 100% accurate DSL = 2.4 while DSL-N = 2.6
you are joking ?
or you seriously think what "DSL-N version 0.1 RC3"
now ready for production use as load balancer base OS?
DM> I was mentioning the cost difference in regards to building your own
DM> hardware based solution using a nginx setup as your LB versus
DM> paying for hardware. To show how he could use nginx in an appliance
DM> manner. This would yield a better ROI and allow for more fail over.
such production of hardware based solution and continuous support can be "a
lot cheaper" only if your time and work cost nothing.
also, what about requested "no single point of failure" in this case?
More information about the nginx