From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6D3271381F3 for ; Thu, 29 Aug 2013 14:11:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C2C1BE0E22; Thu, 29 Aug 2013 14:11:07 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B76F0E0CE5 for ; Thu, 29 Aug 2013 14:11:06 +0000 (UTC) Received: from mail-ve0-f173.google.com ([209.85.128.173]:52996) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VF2wG-003kTY-4t for gentoo-user@lists.gentoo.org; Thu, 29 Aug 2013 21:11:08 +0700 Received: by mail-ve0-f173.google.com with SMTP id cy12so348757veb.4 for ; Thu, 29 Aug 2013 07:11:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QCwBKkqsne6WZRIL2gO3N4lDhv3y24wvvWD0FF5JzTg=; b=boydCP5xRnca5SqB6LCt5w9dCxcFSjQetss08mDs1tn8d5S0hDcsL2N99Gx9lBOC32 Yp93+KI0asN3KISAeA0Ls02gK8xviU2fyqyhaIF6GpZMa5ejF/CMrC71OYOLc1moGtrX C92Jbr2c7K28rE6qE1sDzY3r3eRa3E5eXRpsCgqI2gvuhfgWxcd8owGmL6h98V+53wPD jGoVQDaQHgiTzOdns+MIv+1Kq5914Oon/pJwHcJe2osEWQGRAu/MDX2pbOJs7GHUuQ4B gQSeHDZFmccWDEHmAtGafEtH71/WggTVfu16XSiUHBxRrqOsVwiB1GuzMsqtYh8Y4vCQ 7J2A== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.23.113 with SMTP id l17mr2213273vdf.23.1377785465002; Thu, 29 Aug 2013 07:11:05 -0700 (PDT) Received: by 10.220.163.69 with HTTP; Thu, 29 Aug 2013 07:11:04 -0700 (PDT) Received: by 10.220.163.69 with HTTP; Thu, 29 Aug 2013 07:11:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 21:11:04 +0700 Message-ID: Subject: Re: [gentoo-user] HA-Proxy or iptables? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf307812b637e68c04e516add8 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: c24c3520-d2fa-4b95-9fbf-5b9497313355 X-Archives-Hash: 07e250ed97662e3fda98123c22bef3e2 --20cf307812b637e68c04e516add8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Aug 29, 2013 7:13 PM, "Randy Barlow" wrote= : > > Honestly, I think the best solution is to switch the company to using domain names to access these resources. This makes it much easier to silently introduce things like load balancers later on if you ever need to scale. It's also much easier to communicate to new users how to find this resource. Once you migrate to IPv6 it becomes a very long address to tell people as well. > I agree, but considering that the split is Really Urgent=E2=84=A2, I'll jus= t have to make do with redirection for the time being. > To answer your specific question, I would just do it with iptables if you must continue accessing it by IP address. I will point out that the service on the new IP address now has doubled its chances of going out of service, because it depends on both machines running, even though the first has nothing to do with it. Also, doing this with firewall rules isn't very nice from a systems management perspective for the future, as it's not very obvious what's going on with some server rewriting packets for another one. If someone sees that in two years, are they going to know what to do? What if they want to take server 1 down, and forget that it also disrupts 2? Using DNS is much cleaner for these reasons. Again , I agree 100%. Fortunately, nobody is allowed to bring down a server without my team's blessing, so if they ever need to bring the server down, we will force them to arrange a schedule with the other team. Rgds, -- --20cf307812b637e68c04e516add8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 29, 2013 7:13 PM, "Randy Barlow" <randy@electronsweatshop.com> wrote:
>
> Honestly, I think the best solution is to switch the company to using = domain names to access these resources. This makes it much easier to silent= ly introduce things like load balancers later on if you ever need to scale.= It's also much easier to communicate to new users how to find this res= ource. Once you migrate to IPv6 it becomes a very long address to tell peop= le as well.
>

I agree, but considering that the split is Really Urgent=E2= =84=A2, I'll just have to make do with redirection for the time being.<= br>

> To answer your specific question, I would just do it wi= th iptables if you must continue accessing it by IP address. I will point o= ut that the service on the new IP address now has doubled its chances of go= ing out of service, because it depends on both machines running, even thoug= h the first has nothing to do with it. Also, doing this with firewall rules= isn't very nice from a systems management perspective for the future, = as it's not very obvious what's going on with some server rewriting= packets for another one. If someone sees that in two years, are they going= to know what to do? What if they want to take server 1 down, and forget th= at it also disrupts 2? Using DNS is much cleaner for these reasons.

Again , I agree 100%.

Fortunately, nobody is allowed to bring down a server withou= t my team's blessing, so if they ever need to bring the server down, we= will force them to arrange a schedule with the other team.

Rgds,
--

--20cf307812b637e68c04e516add8--