1 / 10

Challenges of Self-Managing Systems: a System Administrator’s Perspective

Challenges of Self-Managing Systems: a System Administrator’s Perspective. Dr. Alva L. Couch, Associate Professor of Computer Science, Tufts University, Medford, MA USA couch@cs.tufts.edu. Sysadmins and self-managing systems. Self-managing systems: built from bottom up, system-centric

erelah
Download Presentation

Challenges of Self-Managing Systems: a System Administrator’s Perspective

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. Challenges of Self-Managing Systems: a System Administrator’s Perspective Dr. Alva L. Couch, Associate Professor of Computer Science, Tufts University, Medford, MA USA couch@cs.tufts.edu

  2. Sysadmins and self-managing systems • Self-managing systems: built from bottom up, system-centric • How to make systems more robust • System administration: built from the top down, administrator (people) centric • How to empower people to do their jobs

  3. Sysadmin Challenges for Self-managing Systems • Personal liability: it is not the self-healing system that can lose its job • Semantic distance and the problem of common referents: system administrators do not understand what self-healing systems do • Expense of policy changes: small changes can incur large (political) costs • Interference with auditing: can’t both “fix it” and “analyze it”

  4. Desirable Forms of Self-Management • Strong closures: “keep the box closed!” • “Half-open” is worse than “open” • We don’t want to debug “your” code (or “tweak your knobs”!) • Guarantees: “what can we expect?” • SLA for administrators • Controls concentrate on SLA parameters: optimization/intrusiveness tradeoffs

  5. “Like Hardware” • No need to build system • Automatic baselining and upgrades • Directly modify only configuration • Configuration concentrates on SLA • Replacement if fails • Remote diagnosis

  6. Low-Hanging Fruit • Closed, optimized network services • File sharing • Web services • Don’t forget management aids • Distributed • backup and recovery • email and spam control • firewalling and virus control • Tiered (local/remote) filesystems • User authentication and authorization

  7. The Near Future • Commoditization of services: file service becomes like routing; a reliable closed box. Already almost true. • Gradual commoditization of higher-level “policy-free” services, e.g., user privilege management. • System administrator’s job becomes component engineering.

  8. What Won’t Happen • Peer-peer adoption without strong convergence and fault-tolerance guarantees (peer-peer is a “problem”, not a “solution”) • Commoditization of administrator interface and business policies: “variant taxonomies of policy”

  9. Standards • Existing standards • Will aid developers; should not concern administrators • About how a tool should interact, not about how an administrator should interact • Standards that have helped sysadmins: • pop, imap, smtp, … • Sysadmin controls service; user controls choice of client/GUI • Some potentially helpful standards • Semantics of SLA parameters for component solutions • Base (“policy-free?”) semantics for user bindings including authentication and authorization.

  10. Conclusions • Build self-managing components. • Provide an interface with strong semantics. • Let sysadmins do the rest: • User interface • Translation from business policy to system policy.

More Related