Configuration Management Tools (for network people)

Transcript

1. Configuration Management Tools (for network people) Joshua Hoblitt National Optical Astronomy Observatory TPLW perfSONAR Club 2014-01-27
2. What is “Configuration Management”? • Very well defined meaning in the context of “Systems Engineering” – Effectively tracking and organizing requirements, documents and drawings • The meaning is “a bit fuzzier” when used in an IT context – Could mean either recording what was done (auditing) or defining the ideal state (enforcement) • Fundamental a business process more than a procedure dictated by any given tool(s)
3. C.M. is not a new concept • Historic / non-C.M. dedicated examples: – CiscoWorks (now Prime) – RANCID – Ghost – OpenView / Unicenter – CFEngine • Consider: – Tftp distribution of configs? – Account information in a radius server? – Nagios configs?
4. C.M. Space is changing rapidly • New network management tools emerging – Tail-f NCS – Netconf – Walled gardens breaking down (vendor specific tools) • Popularity of “host” C.M. tools is being driven by necessity – Lots of new projects; many unsolved problems • Starting to see overlap / convergence between “network” and “host” tools – The lines are blurring between traditional IT silos – Eg, vSwitches, openflow, etc.
5. Common Problems with manual configuration • Primates are error prone – Often “things” are not setup the way you think they are • Configuration verification is labor intensive – Most installation tools/scripts are brain dead • “Business logic” is often redeveloped over and over again – I know I configured X just last year... • Configuration data ends up being: – ephemeral – unversioned – unreproducible
6. Common Problems with manual configuration (cont.) • New software deployment across many systems ends up costing ~O(N) in labor • Software updates can be even more labor intensive than an initial deployment • Disaster recovery time == help! • By hand configuration scales at best linearly – FTEs = ~servers / admin_efficiency • Automated configuration has the potential to scale based on configuration complexity instead of the number of nodes – FTEs = (resources * resource_complexity) / admin_efficiency
7. Selecting C.M. tool(s) • Basic case of selecting the right tool for the job – Prior familiarity, Community considerations, etc. • Equipment provider / software may come with modules for a specific tool – Eg, JUNOS bundling a puppet agent • Tools can overlap even on the same host – Example: • Ops managing the core OS with Chef • Dev uses Ansible for app deployment • Space is in considerable flux – May look considerably different 5-10 years from now
8. Learning Curve • The hard part is understanding the application – Software often [usually] has properties that are “automation resistant” – Dependencies often poorly captured – In theory, translating app management between tools much easier than discovering how to initially manage it • Value is in automation logic; not the code • Testing remains difficult – Big improvements in this area recently due to virtualization (eg, vagrant)
9. Value of C.M. for perfSONAR deployment • Policy consistency • Appliance bootable ROM model is great – But is problematic for remote sites • Reducing effort required for deployment – May allow many more deployments without organization • Ease upgrading – Including pre-production testing in an virtualized env • Possibility of automated “grid” assembly
10. Summary • C.M. is better thought of as a process rather than a specific set of tools • All C.M. tools have an inherent learning curve – Require investment before pay off • Can enable management of more resources without additional effort • Possible major value for “business continuity” in post-apocalyptic scenarios • Predict increasing overlap/merging of “host” and “network” centric tools