Semester7

Notes of courses done/attended in semester 7 in college

what to monitor?
- SLOs jo sign-in kie honge
- some parameters change with time, those I will have to monitor

stats mil gaye, but ek set of stats se I cannot predict everything
so window ke across nikal
and then avg vagairah karle
i.e. profiling of resource utilizn karle
3 back-box profiles per vm
- cpu utilizn
  - over a period of time
- n/w b/w utilizn
  - over a period of time
- swap rate(page fault rate)
for grey-box, 4 profiles
- memory utilizn
- service time
- req drop rate
- incoming req rate
done over sliding window
similarly physical machine ki bhi profiling bhi kar sakta
Each profile contains a distribution and a time series
histogram = utilizn profile
- how many times a utilizn is occuring

time series profile = wrt time, predict what could be next resource usage value
list all reported observations in Window
used to detect hotspots by spotting increasing utilizn trends
given a time series, a hotspot is flagged only if
- most recent k out of n values exceed threshold
- and next predicted value also exceeds threshold

Interpreting these 2 graphs?
estimating peak cpu and n/w b/w needs
- vm may g et higher share of resources than guaranteed allocn
- if distribution profile is a tail, it tells peak demand
- tail ka end denote, ki tab tak resources the allocated
  - if all vms are not using their full resources, peak referes to actual peak need
  - if all vm are using their allocated share, scheduler will allocate only that it guaranteed
    - so peak will not represent actual needs
    - prob with black-box monitoring
    - so peak+data is added
SLOs = appln level metrics nahi dekhe hamne black box me
estimating peak memory needs
- xen allows fixed amount of physical memory to be assigned to each vm
  - it is hard upper bound that cannot be exceeded regardless of memory demand and usage
- vmware me, variable, that cna be adjusted, sabkoi utna min de de, and if some1 needs more, de de free pool me se

move load from most overloaded servers to least overloaded
determining which VMs to migrate?
find volume of each vm, then volume to size ratio
- size = kitna data transfer karna
we want less size, high volume, so pick greatest value
i.e. order by this ratio, and pick highest one to migrate

volume to size ratio dekh le
but what if a gp of vms ek saath cluster bana ke kaam karre the? commmunication cost badh jayega, so that also take into account
affinity based
- communicn costs among VMs
- memory sharing b/w VMs
  - gan scheduling