Quizá queramos llevar un seguimiento regular de lo importante que es cada servidor
Cuando falla el enfriamiento o la energía en un centro de datos o una sala de servidores universitaria, saber exactamente qué sistemas se pueden sacrificar y cuáles deben seguir en línea se vuelve crítico. Los comentaristas contraponen las filosofías de infraestructura de “mascotas vs. ganado”, y señalan que incluso en configuraciones modernas, basadas en cloud o Kubernetes, todavía se necesitan inventarios claros de activos, mapas de dependencias y niveles de criticidad acordados para los servicios. Las limitaciones presupuestarias, el hardware heredado y la gobernanza académica a menudo impiden una redundancia ideal, así que las organizaciones confían en la documentación, el etiquetado y planes practicados de reducción de carga para disminuir el impacto de las caídas.
Enfriamiento redundante y limitaciones de la infraestructura
- Muchos defienden el enfriamiento N+1 o de varias unidades (por ejemplo, 4–5 unidades más pequeñas) para evitar puntos únicos de fallo; las unidades estándar más pequeñas pueden ser más baratas en conjunto y más fáciles de mantener.
- Otros señalan que las universidades a menudo carecen de capital, espacio físico e influencia en el diseño, especialmente en edificios antiguos “históricos”, así que la redundancia y la modernización son difíciles de financiar pese al ahorro energético a largo plazo.
- Algunos comparan la redundancia con un seguro: prescindir de ella es una decisión explícita de asumir riesgos cuyo coste real aparece durante las caídas.
“Mascotas vs. ganado” e importancia del servidor
- Varios comentaristas dicen que el mantra de “cattle not pets” no encaja en muchos entornos: la academia, el HPC, las telecomunicaciones y las empresas muy cargadas de sistemas heredados siguen teniendo sistemas únicos, no intercambiables.
- Incluso en entornos de “ganado”, hay que priorizar qué servicios deben seguir activos con capacidad limitada; la metáfora puede ocultar dependencias reales y frágiles “mascotas ocultas” (por ejemplo, almacenamiento, DNS, raíces de SDN).
- Otros defienden la metáfora como un empujón hacia la estandarización, la automatización y una infraestructura fungible, pero reconocen que puede convertirse en un meme que limita el pensamiento.
Seguimiento de activos, documentación y dependencias
- Varios comentarios insisten en tener un inventario de activos, etiquetar por aplicación y criticidad, y documentar el propósito del servidor y sus interdependencias.
- Algunas organizaciones se niegan a operar máquinas que no estén vinculadas a un servicio documentado; la calidad de la documentación mejora después de las caídas, cuando los responsables sienten el dolor de ser clasificados como “no importantes”.
- Llevar un seguimiento de los grafos de dependencias (y probar periódicamente apagando cosas) se considera crucial para evitar fallos transitivos sorprendentes.
Priorización, política y realidades organizativas
- Los esquemas de clasificación por criticidad pueden deformarse por la política; si todo es “crítico”, la planificación falla. Repartir costes o imponer obligaciones operativas ligadas al estatus de alta criticidad puede contrarrestarlo.
- Las estructuras organizativas académicas y “feudales” complican la priorización centralizada y los enfoques de plataforma.
Virtualización, cloud y Kubernetes
- La virtualización recibe muchos elogios por permitir migración de VMs, instantáneas y apagados concentrados de los hosts menos importantes.
- Se considera que la nube es excelente para la redundancia entre varios centros de datos y geográfica, aunque algunos sostienen que es drásticamente más cara y que muchas cargas de trabajo siguen sin ser adecuadas.
- Kubernetes se destaca por ayudar a reducir carga a nivel de pod/carga de trabajo y abstraer qué máquina física ejecuta qué, pero aun así requiere priorización explícita y un diseño cuidadoso del almacenamiento.