[openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able to ping loadbalancer ip
Michael Johnson
johnsomor at gmail.com
Fri Nov 11 01:12:39 UTC 2016
Hi Wanjing,
Yes, active/standby is available in Mitaka. You must enable it via
the octavia.conf file.
As for benchmarking, there has been some work done in this space (see
the octavia meeting logs last month), but it varies greatly depending
on how your cloud is configured and/or the hardware it is on.
Michael
On Thu, Nov 10, 2016 at 3:18 PM, Wanjing Xu (waxu) <waxu at cisco.com> wrote:
> Thanks, Michael. Now I have brought up this octavia. I have a question:
> Is HA supported on octavia, or is it yet to come? I am using
> stable/mitaka and I only see one amphorae vm launched per loadbalancer.
> And did anybody benchmark this octtavia against vender box?
>
> Regards!
>
> Wanjing
>
> On 11/7/16, 10:02 AM, "Michael Johnson" <johnsomor at gmail.com> wrote:
>
>>Hi Wanjing,
>>
>>You are not seeing the network interfaces for the VIP and member
>>networks because they are inside a network namespace for security
>>reasons. You can see these by issuing "sudo ip netns exec
>>amphora-haproxy ifconfig -a".
>>
>>I'm not sure what version of octavia and neutron you are using, but
>>the issue you noted about "dns_name" was fixed here:
>>https://review.openstack.org/#/c/337939/
>>
>>Michael
>>
>>
>>On Thu, Nov 3, 2016 at 11:29 AM, Wanjing Xu (waxu) <waxu at cisco.com> wrote:
>>> Going through the log , I saw the following error on o-hm
>>>
>>> 2016-11-03 03:31:06.441 19560 ERROR
>>> octavia.controller.worker.controller_worker request_ids=request_ids)
>>> 2016-11-03 03:31:06.441 19560 ERROR
>>> octavia.controller.worker.controller_worker BadRequest: Unrecognized
>>> attribute(s) 'dns_name'
>>> 2016-11-03 03:31:06.441 19560 ERROR
>>> octavia.controller.worker.controller_worker Neutron server returns
>>> request_ids: ['req-1daed46e-ce79-471c-a0af-6d86d191eeb2']
>>>
>>> And it seemed that I need to upgrade my neutron client. While I am
>>>planning
>>> to do it, could somebody please send me the document on how this vip is
>>> supposed to plug into the lbaas vm and what the failover is about ?
>>>
>>> Thanks!
>>> Wanjing
>>>
>>>
>>> From: Cisco Employee <waxu at cisco.com>
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org>
>>> Date: Wednesday, November 2, 2016 at 7:04 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org>
>>> Subject: [openstack-dev] [Neutron][neutron-lbaas][octavia] Not be able
>>>to
>>> ping loadbalancer ip
>>>
>>> So I bring up octavia using devstack (stable/mitaka). I created a
>>> loadbalander and a listener(not create member yet) and start to look at
>>>how
>>> things are connected to each other. I can ssh to amphora vm and I do
>>>see a
>>> haproxy is up with front end point to my listener. I tried to ping
>>>(from
>>> dhcp namespace) to the loadbalancer ip, and ping could not go through.
>>>I am
>>> wondering how packet is supposed to reach this amphora vm. I can see
>>>that
>>> the vm is launched on both network(lb_mgmt network and my vipnet), but I
>>> don¹t see any nic associated with my vipnet:
>>>
>>> ubuntu at amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699:~$ ifconfig -a
>>> eth0 Link encap:Ethernet HWaddr fa:16:3e:b4:b2:45
>>> inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0
>>> inet6 addr: fe80::f816:3eff:feb4:b245/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:2496 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:2626 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:307518 (307.5 KB) TX bytes:304447 (304.4 KB)
>>>
>>> lo Link encap:Local Loopback
>>> inet addr:127.0.0.1 Mask:255.0.0.0
>>> inet6 addr: ::1/128 Scope:Host
>>> UP LOOPBACK RUNNING MTU:65536 Metric:1
>>> RX packets:212 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:212 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:0
>>> RX bytes:18248 (18.2 KB) TX bytes:18248 (18.2 KB)
>>>
>>> localadmin at dmz-eth2-ucs1:~/devstack$ nova list
>>>
>>>+--------------------------------------+---------------------------------
>>>-------------+--------+------------+-------------+-----------------------
>>>------------------------+
>>> | ID | Name
>>> | Status | Task State | Power State | Networks
>>> |
>>>
>>>+--------------------------------------+---------------------------------
>>>-------------+--------+------------+-------------+-----------------------
>>>------------------------+
>>> | 557a3de3-a32e-419d-bdf5-41d92dd2333b |
>>> amphora-dad2f14e-76b4-4bd8-9051-b7a5627c6699 | ACTIVE | - |
>>>Running
>>> | lb-mgmt-net=192.168.0.4; vipnet=100.100.100.4 |
>>>
>>>+--------------------------------------+---------------------------------
>>>-------------+--------+------------+-------------+‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹
>>>+
>>>
>>> And it seemed that amphora created a port from the vipnet for its
>>>vrrp_ip,
>>> but now sure how it is used and how it is supposed to help packet to
>>>reach
>>> loadbalancer ip
>>>
>>> It will be great if somebody can help on this, especially on network
>>>side.
>>>
>>> Thanks
>>> Wanjing
>>>
>>>
>>>
>>>_________________________________________________________________________
>>>_
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list