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";<aji.zq...@gmail.com>;
????????: 2015??4??29??(??????) ????12:23
??????: "OpenStack Development Mailing
List"<openstack-dev@lists.openstack.org>;
????: [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
