[openstack-dev] 答复: 答复: 答复: [Quantum] [LBaaS] Health Monitor Failure Detection
Leon Cui
lcui at vmware.com
Tue Nov 27 22:53:56 UTC 2012
I’m pretty sure that Haproxy doesn’t support multiple health_monitors
per pool. If the driver is Haproxy, we should validate this limitation.
It should be straightforward to map the Haproxy pool status to the very
single health_monitor associated with it.
Thanks
Leon
发件人: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
发送时间: 2012年11月27日 14:33
收件人: OpenStack Development Mailing List
主题: Re: [openstack-dev] 答复: 答复: [Quantum] [LBaaS] Health Monitor
Failure Detection
Hi Ilya,
1) It is not an option to use "GET /members/{member_id}" for retrieving
health status, since it needs to call the driver/device (and thus become
asynchronous). I vote for a separate method that retrieves health data,
actually it may be similar to "get_stats".
Health status is not the only “dynamic”/read-only attribute. The
“status” attribute of VIP, pool, etc. can change at any time, so does a
member’s health. It would complicate the API to separate calls for have
“static” attributes versus “dynamic” ones of an entity. So, either the
GET should be serviced by the driver like the other calls, or there needs
to be a way between the plugin and the driver to update these dynamic (or
operational) attributes of entities in the DB.
2) Not all load balancers able to map the health status back to health
monitor (HAProxy is an example). We may consider the following response:
{
"status": "FAIL",
"ext_code": "L4_CON",
"details": "Connection refused (tcp rst)",
"health_monitor_id": "f3eeab00-8367-4524-b662-55e64d4cacb5"
}
where attributes 'ext_code' and 'health_monitor_id' are optional.
Ilya, can you first confirm whether HA-Proxy can support several health
monitors per pool or not? If it can support only one, then the mapping is
obvious, no?
Youcef
From: Ilya Shakhat [mailto:ishakhat at mirantis.com]
Sent: Tuesday, November 27, 2012 10:35 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] 答复: 答复: [Quantum] [LBaaS] Health Monitor
Failure Detection
My 2 notes on the topic :)
1) It is not an option to use "GET /members/{member_id}" for retrieving
health status, since it needs to call the driver/device (and thus become
asynchronous). I vote for a separate method that retrieves health data,
actually it may be similar to "get_stats".
2) Not all load balancers able to map the health status back to health
monitor (HAProxy is an example). We may consider the following response:
{
"status": "FAIL",
"ext_code": "L4_CON",
"details": "Connection refused (tcp rst)",
"health_monitor_id": "f3eeab00-8367-4524-b662-55e64d4cacb5"
}
where attributes 'ext_code' and 'health_monitor_id' are optional.
Thanks,
Ilya
2012/11/27 Leon Cui <lcui at vmware.com>
Youcef/Peter,
Yes it sounds good to me.
Thanks
Leon
发件人: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
发送时间: 2012年11月26日 17:20
收件人: OpenStack Development Mailing List
主题: Re: [openstack-dev] 答复: [Quantum] [LBaaS] Health Monitor Failure
Detection
Hi Leon,
Yes, as Peter pointed out, user needs to know which health check has
failed. Whether we want this information to appear in the existing “GET
/members/{member_id}” or whether we want to have a new API for “GET
/members/{member_id}/details”, I’m fine with both. Currently however, we
do not have “/details” sub-resource for any other resource (it’s not a
pattern we are following in the API), so I see introducing it just for
this case may be an overkill.
Thanks
Youcef
From: Mellquist, Peter [mailto:peter.mellquist at hp.com]
Sent: Monday, November 26, 2012 2:58 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] 答复: [Quantum] [LBaaS] Health Monitor
Failure Detection
Hi Leon,
The admin / user needs to know the specific health monitor which has
failed so that they may take appropriate action to fix the member with the
failed health check. If we not provide this detail, then the root cause on
why the member has gone “inactive” will be unknown. Most JSON parsers
allow parsing fields of interest and ignoring others so it should not be
an issue for clients who are not interested in health monitors but … that
being said as we continue to work out important use cases, like this one,
we may find that a refactoring of the REST resources may be needed. I see
this as an iterative process.
Thanks,
Peter.
From: Leon Cui [mailto:lcui at vmware.com]
Sent: Thursday, November 22, 2012 4:49 PM
To: 'OpenStack Development Mailing List'
Subject: [openstack-dev] 答复: [Quantum] [LBaaS] Health Monitor Failure
Detection
Hi Peter and Youcef,
Showing the health monitor status details in member might be too much for
user. In most time, user (and Mgmt UI) might be only interested in the
overall pool/member status unless user wants to drill down to the details.
My concern is that we are adding more and more details in the top resource
GET API which add more payload and complex to parse. I’m wondering if we
can add a separate API GET /resource/<resource_id>/details which can
expose more detailed information for each resource.
Just my 2 cents.
Thanks
Leon
发件人: Mellquist, Peter [mailto:peter.mellquist at hp.com]
发送时间: 2012年11月22日 5:06
收件人: OpenStack Development Mailing List
主题: Re: [openstack-dev] [Quantum] [LBaaS] Health Monitor Failure
Detection
Hi Youcef,
This looks like it will work fine. I like this since it shows the state of
all the monitors for the member.
Peter.
From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
Sent: Wednesday, November 21, 2012 12:34 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum] [LBaaS] Health Monitor Failure
Detection
Hi Peter,
Yes you bring up a good point that we missed in the API. Usually in LB
products when user displays the member, then the monitors used to monitor
the member and their status are also displayed. We can adopt the same
approach as follows:
"member" : {
"id":"c57f581b-c834-408f-93fa-30543cf30618",
"tenant_id": "310df60f-2a10-4ee5-9554-98393092194c",
"pool_id": "cfc6589d-f949-4c66-99d2-c2da56ef3764",
"address": "192.168.224.31",
"port": 8080,
"weight" : 1,
"admin_state_up" : true,
"status" : "INACTIVE",
"health_monitors_status" : [
{
"health_monitor_id" :
"f3eeab00-8367-4524-b662-55e64d4cacb5",
"status" : "FAIL"
},
{
"health_monitor_id" :
"70995ff0-341a-11e2-81c1-0800200c9a66",
"status" : "SUCCESS"
}
]
}
Would this be acceptable?
Youcef
From: Mellquist, Peter [mailto:peter.mellquist at hp.com]
Sent: Wednesday, November 21, 2012 11:17 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Quantum LBaaS Health Monitor Failure Detection
Hi LBaaS’ers,
With the current capability to associate multiple health monitors with a
pool, it does not seem possible to see which specific health monitor has
detected an issue. For example, If I have a PING and HTTP monitor and the
HTTP monitor fails how can the user or admin have visibility into the
specific failure?
“When a pool has several monitors associated with it, each member of the
pool is monitored by all these monitors. If any monitor declares the
member as unhealthy, then the member status is changed to INACTIVE and the
member won't participate in its pool's load balancing. In other words, ALL
monitors must declare the member to be healthy for it to stay ACTIVE. “
Member status changing to INACTIVE does not describe the reason why.
Would it make sense to have a member status reason with the reference to
the health monitor id in this case? We could then see which health monitor
is failing and allow the user or admin to take appropriate action.
Peter.
"member" : {
"id":"c57f581b-c834-408f-93fa-30543cf30618",
"tenant_id": "310df60f-2a10-4ee5-9554-98393092194c",
"pool_id": "cfc6589d-f949-4c66-99d2-c2da56ef3764",
"address": "192.168.224.31",
"port": 8080,
"weight" : 1,
"admin_state_up" : true,
"status" : "INACTIVE",
"status_reason" : "f3eeab00-8367-4524-b662-55e64d4cacb5"
}
{
"health_monitor" :
{
"id" : "f3eeab00-8367-4524-b662-55e64d4cacb5",
"type" : "HTTP",
"delay" : 20,
"timeout": 10,
"max_retries": 3,
"http_method" : "GET",
"url_path" : "/",
"expected_codes" : "200,202",
"admin_state_up": true,
"status": "ACTIVE"
}
}
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/73f32c93/attachment-0001.html>
More information about the OpenStack-dev
mailing list