Hi
I have redundant haproxy servers on my environment. We use corosync and
pacemaker that manages the HA and then have HAproxy run on the HA domain
controller.
On 21/08/2015 15:51, Jeff Palmer wrote:
I've done exactly this. Amazon AWS has a DNS service called route53.
Route53 has built in "health checks"
What I did was setup the 2 haproxy nodes as A records, with a
healthcheck and a TTL of 30 seconds.
If one of the haproxy nodes failed the health check twice, route53
would remove it from the RR record set.
While not a *perfect* solution, 60 seconds of an unresponsive haproxy
node was better for my use-case, than say.. monitoring it, and
manually updating DNS, or moving IP's to new nodes, or whatever else.
maybe that would suffice for you as well?
If you already have a DNS provider you like, you could do like I did,
and delegate a subdomain to route53.
In my case, I had "example.com" that used another DNS provider. I
delegated "lb.example.com" to amazons route53. my haproxy nodes were
then:
fe1.lb.example.com
fe2.lb.example.com
fe3.lb.example.com
records that needed haproxy on front of them, just became cnames to
"lb.example.com"
Hope that makes sense!
On Fri, Aug 21, 2015 at 10:04 AM, Nikolaos Milas <nmi...@noa.gr> wrote:
Hello,
We are setting up a proxy, a haproxy server on CentOS 7, to our mail
services (webmail, smtp, pop3, imap, simple and with STARTTLS, or SSL/TLS as
appropriate). The load of the services is considered low. All clients will
be accessing the above services through the new proxy.
Current goal: To provide redundancy (fail-over) of the haproxy server.
I have read: http://www.serverphorums.com/read.php?10,255589 which provides
valuable information, but I would like your opinions, due to the limitations
we face (see below).
All our VPS servers are provided free of charge (we are a non-profit
scientific research foundation) by our ISP, but there are limitations:
- All our servers (DNS, Mail, Web, etc.) are hosted on VPSs (i.e.
they are VMs) on two different data centers (on our ISP's cloud),
i.e. we don't have any local physical servers available
- Each VPS server must have a single (exactly one) distinct
permanent IP Address and a single network interface
- We don't control how each VM is connected to the Internet
- We don't have any SLAs for network or VPS availability
On the good side, the uptime is very high; we rarely face downtime, yet, we
need redundancy for the rare occasions when a VM will not be available due
to hardware or network issues.
It would be enough for us to be able to use two VMs (each running haproxy
with identical configuration), one on each of the two data centers, as an
active/passive pair.
However, under the above circumstances, I find it difficult to use the
usually suggested solutions of keepalived, heartbeat, pacemaker (and any
similar software which causes IP Address changes). A common DNS name with
two A records is not a reliable solution.
So, could you please provide some opinions/advice on how to move on with our
available resources?
Thanks in advance,
Nick
--
Kobus Bensch Trustpay Global LTD email signature Kobus Bensch
Senior Systems Administrator
Address: 22 & 24 | Frederick Sanger Road | Guildford | Surrey | GU2 7YD
DDI: 0207 871 3958
Tel: 0207 871 3890
Email: kobus.ben...@trustpayglobal.com
<mailto:kobus.ben...@trustpayglobal.com>
--
Trustpay Global Limited is an authorised Electronic Money Institution
regulated by the Financial Conduct Authority registration number 900043.
Company No 07427913 Registered in England and Wales with registered address
130 Wood Street, London, EC2V 6DL, United Kingdom.
For further details please visit our website at www.trustpayglobal.com.
The information in this email and any attachments are confidential and
remain the property of Trustpay Global Ltd unless agreed by contract. It is
intended solely for the person to whom or the entity to which it is
addressed. If you are not the intended recipient you may not use, disclose,
copy, distribute, print or rely on the content of this email or its
attachments. If this email has been received by you in error please advise
the sender and delete the email from your system. Trustpay Global Ltd does
not accept any liability for any personal view expressed in this message.
