[
https://issues.apache.org/jira/browse/SLIDER-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556966#comment-14556966
]
Gour Saha commented on SLIDER-868:
----------------------------------
[[email protected]], [~jbnote] these are very good points. I will be working
on a formal proposal on this soon. So please keep ideas flowing.
{quote}
we have daily, weekly and yearly duty cycles for infrastructure usage, so a
time-based schedule would need to be either very complex or adjusted very
frequently. This is not even accounting for organic growth which would make
adjustments necessary every week
{quote}
[~jbnote] It should be possible to make modifications to the skyline after its
initial submission and it should take effect (fairly) immediately. This should
cater to the organic growth. With additional support for skyline versions, it
can also be possible to provide a skyline override (for a certain time window),
after the expiry of which the original cruise control skyline will take effect.
This is like, say speed up a little when your car is on cruise control and then
when you let go the gas pedal, it will go back to its original cruise speed.
{quote}
Indeed what would really be awesome is to have load monitoring, a simple load
extrapolation engine (linear would probably be sufficient) for resource
pre-allocation, and high/low load resource usage threshold to trigger actual
resource allocation / deallocation.
{quote}
I might have got this all wrong, so correct me if I did. This is more of the
reactive management that I am referring to. Such an engine can be built (or
existing ones used) outside the scope of Slider. Based on the report of these
tools, it should be fairly straight forward to make REST calls to Slider
(almost everything in Slider will have REST support soon) and modify the
skyline. There are several system info/tools already existing, say something as
simple as the SAR report of a host. I don't think Slider is the right home for
such tools/logic. Also, it will be practically impossible for Slider to support
all the types of resource monitoring, that all the business applications would
need (look at SLIDER-875).
{quote}
Maybe the CPU load / memory usage can simply be monitored by the agent through
cgroups
{quote}
YARN provides this information and we should rely on it. This and metrics
dumped by Slider to ATS (SLIDER-120) will be used to generate alerts
(SLIDER-701). These and multitude of other application/system health reports
can be used to write simple/complex logic to determine business application
usage needs. Once that is determined, REST calls can be made to Slider to
modify the skyline.
> Ability to put a Slider application on cruise control
> -----------------------------------------------------
>
> Key: SLIDER-868
> URL: https://issues.apache.org/jira/browse/SLIDER-868
> Project: Slider
> Issue Type: New Feature
> Components: agent, app-package, appmaster
> Affects Versions: Slider 0.70
> Reporter: Gour Saha
>
> You create a Slider application package, deploy it to a YARN cluster and
> manage it. From the management perspective it is primarily flexing. Based on
> needs (and the architecture of the application) you grow or shrink specific
> components of your long running application from time to time. Of course you
> can set some constraints like affinity, anti-affinity, and strict placement
> (for data locality or other reasons). Some of these are handled very well by
> Slider, others are best efforts.
> However long running applications have an inherent need to be auto (or even
> self) managed. This can be achieved by a custom management tool, interacting
> with Slider client based on constant feedback on the health of the
> application (metrics, alerts, etc.). This is primarily reactive management.
> There is also proactive management, where the application owner is aware of
> the usage pattern of the application over time. For example, a financial
> application usage peaks between 8am to 4pm Mon to Sat (local time), and slows
> down at other times. A tax application usage peaks for a few months prior to
> April 15 and then slows down for several months. Certain healthcare
> applications peak during flu season. You get the point!
> It should be possible to declaratively define such an application usage
> skyline, which can be fed to Slider and put an application on cruise control.
> The specification can be modified dynamically and Slider should honor the
> modified version for (reasonably acceptable) future state of the application.
> This kind of feature would need support from YARN. There should be a way for
> Slider to provide details to YARN for guaranteed future capacity planning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
