[pgpool-general: 7820] Re: Virtual IP not reachable after if_up_cmd setup
Nirav Bhatt
niravbhatt.cpp at gmail.com
Sat Oct 23 23:15:38 JST 2021
Thanks!
I just sent my patch to pgpool-hackers at pgpool.net
Check it and see if there are any issues.
-Nirav Bhatt
On Tue, Oct 19, 2021 at 5:53 AM Bo Peng <pengbo at sraoss.co.jp> wrote:
> Hello,
>
> Sorry for late response.
>
> > Hello,
> >
> > I tried and I found the solution. I am able to ping the server2 with
> > virtual IP from server1 and server3.
>
> Great!
>
> > In addition to your route table suggestion, following 2 things must be
> done:
> >
> > 1-ip addr add command is must.
> > So far I was thinking AWS and ip command are mutually exclusive, but no,
> > it's not.
> > I am still unaware if arp is needed or not for pgpool to function? I am
> > able to use virtual IP to ping the instances without running arp.
>
> I think you don't need to setup arp on AWS.
>
> > 2-This is specific to AWS: The source-destination check for the active
> > network interface must be disabled.
> >
> > This is the SrcDestCheck attribute of the network interface.
> > When true, this allows traffic only destined to the main IP address of
> the
> > interface, and not anything else.
> > Network address translation is simply impossible when this ON.
> > So this must be turned off for the instance which is about to own the
> > virtual IP to become the primary.
> >
> > (I do not see any harm is keeping it OFF forever for all participating
> > nodes, though I would like to know if you disagree)
> >
> > The source where I got this SrcDestCheck idea is here:
> > http://www.scalingbits.com/book/export/html/618
> >
> > The AWS documentation for this is here:
> >
> https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck
> >
> > If needed, I can volunteer to update your tutorial / docs with this tiny
> > finding of mine (I couldn't find docs contribution guidelines so far).
>
> It would be greatly appreciated.
> You can send the patch to pgpool-general at pgpool.net or
> pgpool-hackers at pgpool.net.
> Thank you.
>
> > If you would rather do it yourself when you get a chance, that will be
> > fine, too.
> >
> > Thank you so much for being with me all along, yours is truly a great
> open
> > source endeavor!
> > It takes grit and dedication to come up with such an ambitious open
> source
> > project and supporting it.
> >
> > -Nirav
> >
> > On Wed, Oct 13, 2021 at 7:50 PM Nirav Bhatt <niravbhatt.cpp at gmail.com>
> > wrote:
> >
> > > Thanks again.
> > >
> > > I tried the routing approach described today with various values, but
> no
> > > luck yet.
> > >
> > > aws ec2 create-route --route-table-id rtb-xxxxxx
> --destination-cidr-block
> > > 192.168.50.50/32 --instance-id <i-xxxxxxx> --region us-east-2
> > >
> > > The route table used is attached with all 3 subnets where 3
> > > pgpool+postgres servers lie.
> > >
> > > The AWS create-route and replace-route is successful always, but I
> still
> > > can't ping my instance (server1 which is on i-xxxxxxx above) from
> server2
> > > and server3 with:
> > >
> > > ping 192.168.50.50
> > >
> > > I also opened my security group for all 3 servers to allow all traffic
> > > from 192.168.50.50/32. But no luck.
> > > Where am I mistaken?
> > >
> > > On Wed, Oct 13, 2021 at 10:19 AM Bo Peng <pengbo at sraoss.co.jp> wrote:
> > >
> > >> Hello,
> > >>
> > >> > Yes I saw Elastic example already.
> > >> > But I don’t want to use it for cost and privacy reasons.
> > >> >
> > >> > All my servers are in separate subnets but same region.
> > >> >
> > >> > Any example script of the 3rd option of using routes with private
> > >> Virtual
> > >> > IP?
> > >>
> > >> Currently we don't have a documetaion of the 3rd option.
> > >> We may add more docs or blogs about setting VIP on AWS in the future.
> > >>
> > >> Below is a slide in Japanese.
> > >> You can find the setting of route tables in P.44-46.
> > >> I hope it could be helpful.
> > >>
> > >>
> > >>
> https://www.sraoss.co.jp/wp-content/uploads/files/event_seminar/material/2017/jpug_20171103_pgpool_aws.pdf
> > >>
> > >>
> > >> > Thanks so much for the support...
> > >> >
> > >> > On Wed, 13 Oct 2021 at 5.39, Bo Peng <pengbo at sraoss.co.jp> wrote:
> > >> >
> > >> > > Hello,
> > >> > >
> > >> > > The settings of delegate_IP, if_up_cmd,if_down_cmd and arping_cmd
> are
> > >> used
> > >> > > for on-premises.
> > >> > > If you are running your cluster on AWS, you need to configure
> > >> > > wd_escalation_command and wd_de_escalation_command.
> > >> > >
> > >> > > There are several ways to setup virtual IP on AWS.
> > >> > >
> > >> > > For example:
> > >> > > - use an elastic ip
> > >> > > – configure Route53
> > >> > > – create route tabale for a private VIP
> > >> > >
> > >> > > The following documetation is using an "elastic ip".
> > >> > >
> > >> > > https://www.pgpool.net/docs/latest/en/html/example-aws.html
> > >> > >
> > >> > > On Tue, 12 Oct 2021 20:26:04 +0300
> > >> > > Nirav Bhatt <niravbhatt.cpp at gmail.com> wrote:
> > >> > >
> > >> > > > Hello,
> > >> > > >
> > >> > > > Inside my AWS cloud, I have following 3 servers
> > >> > > >
> > >> > > > (all 3 can reach each other very fine using ping server1, ping
> > >> server2,
> > >> > > > ping server3 as well as IP address.):
> > >> > > >
> > >> > > > 10.192.10.10 server1
> > >> > > > 10.192.11.20 server2
> > >> > > > 10.192.12.30 server3
> > >> > > >
> > >> > > > 10.192.10.40 Virtual IP (I want this to be private, not elastic
> > >> which is
> > >> > > > public)
> > >> > > >
> > >> > > > I was testing the following if_up_cmd command on server1:
> > >> > > >
> > >> > > > /usr/bin/sudo /sbin/ip addr add 10.192.10.40/32 dev ens5 label
> > >> ens5:0
> > >> > > >
> > >> > > > I could see new IP in the ifconfig result:
> > >> > > >
> > >> > > > ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
> > >> > > > inet 10.192.10.10 netmask 255.255.255.0 broadcast
> > >> 10.192.10.255
> > >> > > > inet6 fe80::4b0:29ff:fe38:3399 prefixlen 64 scopeid
> > >> 0x20<link>
> > >> > > > ether 06:b0:29:38:33:99 txqueuelen 1000 (Ethernet)
> > >> > > > RX packets 67233 bytes 67464992 (67.4 MB)
> > >> > > > RX errors 0 dropped 0 overruns 0 frame 0
> > >> > > > TX packets 22922 bytes 5116469 (5.1 MB)
> > >> > > > TX errors 0 dropped 0 overruns 0 carrier 0
> collisions 0
> > >> > > >
> > >> > > > ens5:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001
> > >> > > > inet 10.192.10.40 netmask 255.255.255.255 broadcast
> > >> > > 10.192.10.255
> > >> > > > ether 06:b0:29:38:33:99 txqueuelen 1000 (Ethernet)
> > >> > > >
> > >> > > > lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
> > >> > > > inet 127.0.0.1 netmask 255.0.0.0
> > >> > > > inet6 ::1 prefixlen 128 scopeid 0x10<host>
> > >> > > > loop txqueuelen 1000 (Local Loopback)
> > >> > > > RX packets 39948 bytes 13976834 (13.9 MB)
> > >> > > > RX errors 0 dropped 0 overruns 0 frame 0
> > >> > > > TX packets 39948 bytes 13976834 (13.9 MB)
> > >> > > > TX errors 0 dropped 0 overruns 0 carrier 0
> collisions 0
> > >> > > >
> > >> > > > However, after running the ip addr add, I can not ping the new
> > >> elastic IP
> > >> > > > 10.192.10.40 from other servers. Only server1 has successful
> ping.
> > >> > > >
> > >> > > > I tried running arping past the above, but that is also failing.
> > >> > > >
> > >> > > > arping -U 10.192.10.40 -w 1 -I ens5:1
> > >> > > >
> > >> > > > I tried adding and deleting several times, with different IP
> > >> combinations
> > >> > > > also to suit different AWS subnets, but no result. Server2 and
> > >> server3
> > >> > > > can't simply reach it.
> > >> > > >
> > >> > > > My system is Ubuntu, the AMI is following, in case it helps:
> > >> > > > ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20211001
> > >> > > >
> > >> > > > Thanks for the support!
> > >> > > > -Nirav
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Bo Peng <pengbo at sraoss.co.jp>
> > >> > > SRA OSS, Inc. Japan
> > >> > > http://www.sraoss.co.jp/
> > >> > >
> > >>
> > >>
> > >> --
> > >> Bo Peng <pengbo at sraoss.co.jp>
> > >> SRA OSS, Inc. Japan
> > >> http://www.sraoss.co.jp/
> > >>
> > >
>
>
> --
> Bo Peng <pengbo at sraoss.co.jp>
> SRA OSS, Inc. Japan
> http://www.sraoss.co.jp/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20211023/85936dca/attachment-0001.htm>
More information about the pgpool-general
mailing list