Skip to content

Latest commit

 

History

History
86 lines (63 loc) · 3.26 KB

mesos-a-platform-for-fine-grained-resource-sharing-in-the-data-center.md

File metadata and controls

86 lines (63 loc) · 3.26 KB

[2011 NSDI] Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center

One-line Summary

Mesos is a scheduler for sharing cluster resources between multiple services/applications. Using two-level scheduling (application-specific schedulers), its orchestration mechanism can provide scalable, decentralized scheduling.

Paper Structure Outline

Background & Motivation

  • Motivation: Share resources among multiple frameworks/services
  • Background: OS scheduling: time sharing
    • Mechanism: Pre-empt processes
    • Policy: Which process is chosen to run
  • Background: Cluster scheduling
    • Time sharing: Context switches are more expensive
    • Space sharing: Partition resources at the same time across jobs
    • Policies: Should be aware of locality
    • Scale
    • Fault tolerance
  • Background: Target environment
    • Multiple MapReduce versions
    • Mix of frameworks: MPI, Spark, MapReduce
    • Data sharing across frameworks
    • Avoid per-framework clusters (not good for resource utilization)

Design and Implementation

Architecture

Mesos architetcture

  • Centralized master (& its backups)
  • Agent on every machine
  • Two-level scheduling: Framework scheduler attached to Mesos
    • "Simplicity across frameworks"

Resource offers

Resource offers

  • Slave send heartbeats with information on available resources
  • Mesos master sends resource offers to frameworks -> Frameworks replies tasks & their granularity
  • Constraints
    • Example of constraints
      • Soft constraints: Prefer to run the task at a particular location (e.g. for data locality)
      • Hard constraints: Task needs GPUs
    • Constraints in Mesos
      • Applications can reject offers
      • Optimization: Filters (reduces the number of rejected offers)
  • Allocation
    • Assumption: Tasks are short -> allocate when they finish
    • Long tasks: Revocation beyond guaranteed allocation
      • E.g., MPI has guaranteed allocation of 8 machines; currently assigned 12 machines; can take away 4 machines
  • Isolation
    • Containers (Docker/Linux cgroups)

Fault tolerance

  • Node fails -> forward the failure to Hadoop, let them decide what to do
  • Master fails -> recover (soft) state by communicating with framework schedulers/workers
  • Also has a standby master
  • Framework scheduler fails -> Mesos doesn't handle that

Placement preferences

  • Problem: More frameworks have preferred nodes than available. Who gets the offers?
  • Lottery scheduling: Offers weighted by num allocations

Design choices & implications

  • Centralized vs. Distributed
    • Framework complexity: Every framework developer needs to implement a scheduler
    • Fragmentation, starvation: Especially if a job has large resource requirements. Partial workaround: min offer size
    • Inter-dependent framework: 2 frameworks cannot be colocated (e.g. due to security, privacy, ...)

Evaluations

Excerpted from Shivaram's CS 744 course notes

Links & References