1 / 21

Cloud Based Analytics for Cloud Based Applications

Cloud Based Analytics for Cloud Based Applications. András Pataricza 1 , Imre Kocsis 1 , Zsolt Kocsis 2 et al. 1 Dept. of Meas. and Information Systems, BME, Hungary 2 IBM CAS Budapest, Hungary {pataric,ikocsis}@mit.bme.hu ICA CON 2012, April 20, 2012. Cloud s for demanding applications ?.

fifield
Télécharger la présentation

Cloud Based Analytics for Cloud Based Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cloud Based Analytics forCloud Based Applications András Pataricza1, Imre Kocsis1, Zsolt Kocsis2 et al. 1Dept. of Meas. and Information Systems, BME, Hungary 2IBM CAS Budapest, Hungary {pataric,ikocsis}@mit.bme.hu ICA CON 2012, April 20, 2012

  2. Clouds for demanding applications? Standard infrastructure vs demanding application?

  3. Clouds for demanding applications? Extra-functional reqs: throughput, timeliness, availability „Small problems” have high impact (soft real time) Virtual Desktop Infrastructure Telecommunications

  4. Experimental setup N.B.: VMware R&D published similar (March 2012)

  5. IT EDA is Big Data! Which determine the QoS? Hypervizor (host + VMs), OS, application, ...

  6. IT EDA is Big Data! High availabilty, rare faults Rare events: granularity AND long horizon Searching for outliers

  7. Rare events: lot of sand, a few pellets Typically sand: gold mining ≠ data mining

  8. Visual analytics = causal insight Computing power use = CPU use × CPU clock rate (const.) Should be pure proportional Correlation coefficient: 0.99998477434137 Well-visible, but numerically suppressed Origin???

  9. Visual analytics Noisy… High frequency components dominate But they correlate (93%!) YOU DON’T SEE IT

  10. Dangers in a standard cloud for demanding apps?

  11. Impacts of resource sharing? Self-induced Parasitic influence

  12. Short transient faults – long recovery As if you unplug your desktop for a second... 30 sec service outage 120 sec SLA violation 8 sec platform overload

  13. Deterministic (?!) run-time in the public cloud... Performance outage intolerable by overcapacity Variance tolerable by overcapacity

  14. The noisy neighbour problem Logic „fence” Tenant Neighbor Hypervisor

  15. Tenant-side measurability and observability Tenant Neighbor Hypervisor

  16. Let’s try it at user level

  17. Monitoring, prediction and reaction Michael: Now we can hurry Michael:Don’t worry, we have spare resources Fast detection, Spare resources Fast reaction (actual) Mystery shopper:There is an obstacle across the road

  18. The mistery shopper concept • Basic logic as with benchmarks, but... • Metric req: • same interference-sensitivities as the service • same resource-sensitivities as the service • representative for types of services • Runtime req: • Non-intrusiveness (instead of saturation) • Long running (rare events) • (Low specific impact on service) Not trivially feasible... but everything else impossible Example: short computation bursts sampling available CPU for longer computation

  19. Indirect platform & QoS observability 1. Connect 3. Infer (qualitatively) Works without the application! 2. Observe The „classic” approach: deploy, run/test, observe, analyze The „classic” approach: deploy, run/test, observe, analyze The „classic” approach: deploy, run/test, observe, analyze Observability problems (if present) bypassed

  20. Mystery shopper & service QoS Application failure Main application Fast detection Reaction time window Reaction time window VM internal fault Noisy neighbour fault Mystery shopper

  21. Summary • Technical • SLA coverage needed for all aspects • Missing guarantees can be (somewhat) compensated • Cheap computing power -> redundancy • „Double” autonomic computing • Cloud level – provider • Application level – user • Methodology • Visual exploratory data for insight • Algorithmic analysis for proofs and evaluation • Fault-tolerance design patterns revisited • Cheap redundancy in the cloud

More Related