Re: [openstack-dev] [ceilometer] time based auto scaling
Hi, I like the base idea to trigger scaling based on other information than what we have from the current Ceilometer alarms. Although I think this functionality should live somewhere else than under the responsibility of Ceilometer. This type of scaling is usually based on trend analysis and other application specific data, which is out of the scope for Ceilometer, even if it has the capability of triggering Heat. Best Regards, Ildiko Feladó: Julien Danjou [jul...@danjou.info] Küldve: 2015. április 29. 9:29 Címzett: ZhiQiang Fan Másolatot kap: OpenStack Development Mailing List Tárgy: Re: [openstack-dev] [ceilometer] time based auto scaling On Wed, Apr 29 2015, ZhiQiang Fan wrote: > However, current ceilometer only provide time constraint alarm, which will > only evaluate but not guarantee it will be triggered. And heat cannot > provide something like timer, but just can wait for the signal. > > So I propose to add a new type of alarm, which will definitely send a > signal to action when it is evaluated (with or without repeat, it will work > well with time constraint) > > Any suggestion? I've proposed exactly that around 18-24 years go I think during a summit, and nobody was really interested back then and was worried to have yet another cron system – though OpenStack didn't have one. I still think it's a good idea and it will be a nice addition to the alarming system, so if you want to write a spec for that I'll be all yours. :) -- Julien Danjou # Free Software hacker # http://julien.danjou.info __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] time based auto scaling
On Wed, Apr 29 2015, ZhiQiang Fan wrote: > However, current ceilometer only provide time constraint alarm, which will > only evaluate but not guarantee it will be triggered. And heat cannot > provide something like timer, but just can wait for the signal. > > So I propose to add a new type of alarm, which will definitely send a > signal to action when it is evaluated (with or without repeat, it will work > well with time constraint) > > Any suggestion? I've proposed exactly that around 18-24 years go I think during a summit, and nobody was really interested back then and was worried to have yet another cron system – though OpenStack didn't have one. I still think it's a good idea and it will be a nice addition to the alarming system, so if you want to write a spec for that I'll be all yours. :) -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] ?????? [ceilometer] time based auto scaling
Agree with ZhiQiang. Maybe we could achieve this by heat itself or other project like Mistral, but it seems more natural to achieve this through ceilometer alarm system. -- Luo gangyiluogan...@chinamobile.com -- -- ??: "ZhiQiang Fan";; : 2015??4??29??(??) 12:23 ??: "OpenStack Development Mailing List"; ????: [openstack-dev] [ceilometer] time based auto scaling Hi devs, I'm thinking to add new type of alarm for time based auto scaling, but not sure if there is a better way to achieve it outside ceilometer scope Currently we can auto scaling based on vm load, but it will take several minutes to do it. For the worst case, when the vm load is heavy, ceilometer needs 10 minutes (by default) to collect the performance data, and alarm need 1 minutes to evaluate it, maybe there is evaluation_periods which set to higher that 1 to avoid performance peak. So even though we can collect data by 1 minutes, but evaluation periods may be set to 3, so the worst case is after vm load perfomance in high level for 4 minutes, then the alarm is triggered, then heat will expand vm count, nova will take dozens seconds or more to create, finally the service on the in the heat server group will performance bad or unavailable for several minutes, which is not acceptable for some critical applications. But if we can know some high load which related with time, for example, 08:00am will be a peak, and after 22:00pm will definitely drop to idel level, then heat can increase some vms at 07:30am, then decrease some vms at 22:00 (or decrease by load as normal routine) However, current ceilometer only provide time constraint alarm, which will only evaluate but not guarantee it will be triggered. And heat cannot provide something like timer, but just can wait for the signal. So I propose to add a new type of alarm, which will definitely send a signal to action when it is evaluated (with or without repeat, it will work well with time constraint) Any suggestion?__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] time based auto scaling
+1, if you really care about time range, Mistral can meet your requirements. Besides, maybe not directly related, as for autoscaling, I always believe there should be a message queue service(like Zaqar) between the (web) application and the worker, a task request will be posted to the queue as a message, worker will pick the message from the queue to handle. And then we can trigger the autoscaling based on the workload of queue instead of the hardware usage. Just drop my 2 cents. On 29/04/15 16:39, Fox, Kevin M wrote: > what about Mistral? > > https://wiki.openstack.org/wiki/Mistral > > Thanks, > Kevin * > > * > > *From:* ZhiQiang Fan > *Sent:* Tuesday, April 28, 2015 9:23:20 PM > *To:* OpenStack Development Mailing List > *Subject:* [openstack-dev] [ceilometer] time based auto scaling > > Hi devs, > > I'm thinking to add new type of alarm for time based auto scaling, but > not sure if there is a better way to achieve it outside ceilometer scope > > Currently we can auto scaling based on vm load, but it will take > several minutes to do it. For the worst case, when the vm load is > heavy, ceilometer needs 10 minutes (by default) to collect the > performance data, and alarm need 1 minutes to evaluate it, maybe there > is evaluation_periods which set to higher that 1 to avoid performance > peak. > > So even though we can collect data by 1 minutes, but evaluation > periods may be set to 3, so the worst case is after vm load perfomance > in high level for 4 minutes, then the alarm is triggered, then heat > will expand vm count, nova will take dozens seconds or more to create, > finally the service on the in the heat server group will performance > bad or unavailable for several minutes, which is not acceptable for > some critical applications. > > But if we can know some high load which related with time, for > example, 08:00am will be a peak, and after 22:00pm will definitely > drop to idel level, then heat can increase some vms at 07:30am, then > decrease some vms at 22:00 (or decrease by load as normal routine) > > However, current ceilometer only provide time constraint alarm, which > will only evaluate but not guarantee it will be triggered. And heat > cannot provide something like timer, but just can wait for the signal. > > So I propose to add a new type of alarm, which will definitely send a > signal to action when it is evaluated (with or without repeat, it will > work well with time constraint) > > Any suggestion? > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers & Best regards, Fei Long Wang (王飞龙) -- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] time based auto scaling
what about Mistral? https://wiki.openstack.org/wiki/Mistral Thanks, Kevin From: ZhiQiang Fan Sent: Tuesday, April 28, 2015 9:23:20 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [ceilometer] time based auto scaling Hi devs, I'm thinking to add new type of alarm for time based auto scaling, but not sure if there is a better way to achieve it outside ceilometer scope Currently we can auto scaling based on vm load, but it will take several minutes to do it. For the worst case, when the vm load is heavy, ceilometer needs 10 minutes (by default) to collect the performance data, and alarm need 1 minutes to evaluate it, maybe there is evaluation_periods which set to higher that 1 to avoid performance peak. So even though we can collect data by 1 minutes, but evaluation periods may be set to 3, so the worst case is after vm load perfomance in high level for 4 minutes, then the alarm is triggered, then heat will expand vm count, nova will take dozens seconds or more to create, finally the service on the in the heat server group will performance bad or unavailable for several minutes, which is not acceptable for some critical applications. But if we can know some high load which related with time, for example, 08:00am will be a peak, and after 22:00pm will definitely drop to idel level, then heat can increase some vms at 07:30am, then decrease some vms at 22:00 (or decrease by load as normal routine) However, current ceilometer only provide time constraint alarm, which will only evaluate but not guarantee it will be triggered. And heat cannot provide something like timer, but just can wait for the signal. So I propose to add a new type of alarm, which will definitely send a signal to action when it is evaluated (with or without repeat, it will work well with time constraint) Any suggestion? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ceilometer] time based auto scaling
Hi devs, I'm thinking to add new type of alarm for time based auto scaling, but not sure if there is a better way to achieve it outside ceilometer scope Currently we can auto scaling based on vm load, but it will take several minutes to do it. For the worst case, when the vm load is heavy, ceilometer needs 10 minutes (by default) to collect the performance data, and alarm need 1 minutes to evaluate it, maybe there is evaluation_periods which set to higher that 1 to avoid performance peak. So even though we can collect data by 1 minutes, but evaluation periods may be set to 3, so the worst case is after vm load perfomance in high level for 4 minutes, then the alarm is triggered, then heat will expand vm count, nova will take dozens seconds or more to create, finally the service on the in the heat server group will performance bad or unavailable for several minutes, which is not acceptable for some critical applications. But if we can know some high load which related with time, for example, 08:00am will be a peak, and after 22:00pm will definitely drop to idel level, then heat can increase some vms at 07:30am, then decrease some vms at 22:00 (or decrease by load as normal routine) However, current ceilometer only provide time constraint alarm, which will only evaluate but not guarantee it will be triggered. And heat cannot provide something like timer, but just can wait for the signal. So I propose to add a new type of alarm, which will definitely send a signal to action when it is evaluated (with or without repeat, it will work well with time constraint) Any suggestion? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev