We might want to regularly keep track of how important each server is
When cooling or power fails in a data center or university server room, knowing exactly which systems can be sacrificed and which must stay online becomes critical. Commenters contrast “pets vs. cattle” infrastructure philosophies, noting that even in modern, cloud-like or Kubernetes-based setups you still need clear asset inventories, dependency maps, and agreed criticality levels for services. Budget constraints, legacy hardware, and academic governance often prevent ideal redundancy, so organizations rely on documentation, tagging, and practiced load-shedding plans to reduce outage impact.
Redundant cooling and facility constraints
- Many argue for N+1 or multi-unit cooling (e.g., 4–5 smaller units) to avoid single points of failure; smaller standard units may be cheaper overall and easier to maintain.
- Others note universities often lack capital, physical space, and design influence, especially in old “historic” buildings, so redundancy and modernization are hard to fund despite long-term energy savings.
- Some compare redundancy to insurance: skipping it is an explicit risk decision whose true cost appears during outages.
“Pets vs cattle” and server importance
- Several commenters say the “cattle not pets” mantra doesn’t fit many environments: academia, HPC, telecom, and legacy-heavy enterprises still have unique, non-interchangeable systems.
- Even in “cattle” environments, you must prioritize which services stay up under constrained capacity; the metaphor can obscure real dependencies and fragile “hidden pets” (e.g., storage, DNS, SDN roots).
- Others defend the metaphor as a push toward standardization, automation, and fungible infrastructure, but acknowledge it can become a thought-limiting meme.
Asset, documentation, and dependency tracking
- Multiple comments stress having an asset inventory, tagging by application and criticality, and documenting server purpose and interdependencies.
- Some organizations refuse to operate machines not tied to a documented service; documentation quality improves after outages when owners feel the pain of being misclassified as “unimportant.”
- Tracking dependency graphs (and periodically testing by turning things off) is seen as crucial to avoid surprising transitive failures.
Prioritization, politics, and organizational realities
- Criticality rating schemes can be distorted by politics; if everything is “critical,” planning fails. Cost-sharing or operational obligations tied to high-criticality status can counter this.
- Academic and “feudal” organizational structures complicate centralized prioritization and platform approaches.
Virtualization, cloud, and Kubernetes
- Virtualization is widely praised for allowing VM migration, snapshotting, and concentrated shutdowns of less important hosts.
- Cloud is seen as excellent for multi-DC and geo-redundancy, though some argue it’s dramatically more expensive and many workloads remain unsuitable.
- Kubernetes is highlighted as helpful for shedding load at the pod/workload level and abstracting away which physical box runs what, but it still requires explicit prioritization and careful storage design.