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 – How to make systems more robust • System administration: built from the top down, administrator (people) centric – How to empower people to do their jobs
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”
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
“Like Hardware” • No need to build system • Automatic baselining and upgrades • Directly modify only configuration • Configuration concentrates on SLA • Replacement if fails • Remote diagnosis
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
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.
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”
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.
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.
Recommend
More recommend
