El término "tratar a sus servidores como ganado no como mascotas" ha proliferado en los últimos años, particularmente cuando se aplica a contenedores Docker y máquinas virtuales
¿Qué significa en realidad?
Respuestas:
Randy Bias narra la historia del término afirmando que probablemente se originó en 2011 o 2012 cuando Bill Baker usó la analogía al describir estrategias arquitectónicas de "ampliación" frente a "ampliación". Bias adoptó esto en sus presentaciones sobre patrones arquitectónicos en la nube:
En la vieja forma de hacer las cosas, tratamos a nuestros servidores como mascotas, por ejemplo, Bob, el servidor de correo. Si Bob cae, todo está en la cubierta. El CEO no puede recibir su correo electrónico y es el fin del mundo. En la nueva forma, los servidores están numerados, como el ganado en un rebaño. Por ejemplo, www001 a www100. Cuando un servidor se cae, se retira, se dispara y se reemplaza en la línea.
El sesgo continúa definiendo mascotas como
Servidores o pares de servidores que se tratan como sistemas indispensables o únicos que nunca pueden estar inactivos. Por lo general, se construyen, administran y "alimentan a mano" manualmente. Los ejemplos incluyen mainframes, servidores solitarios, balanceadores de carga / cortafuegos HA (activo / activo o activo / pasivo), sistemas de bases de datos diseñados como maestro / esclavo (activo / pasivo), etc.
y ganado como
Las matrices de más de dos servidores, que se crean utilizando herramientas automatizadas, y están diseñadas para fallar, donde ninguno, dos o incluso tres servidores son irremplazables. Por lo general, durante los eventos de falla no se requiere intervención humana ya que la matriz exhibe atributos de "enrutamiento alrededor de fallas" al reiniciar los servidores con fallas o replicar datos a través de estrategias como la replicación triple o la codificación de borrado. Los ejemplos incluyen matrices de servidores web, almacenes de datos de varios maestros, como los clústeres de Cassandra, múltiples bastidores de equipo juntos en clústeres y casi cualquier cosa que sea equilibrada en la carga y de varios maestros.
Básicamente, lo que Bias y Baker están tratando de transmitir es que tiene que haber una transición de cómo tratamos a los servidores de ser "Unique Snowflakes" con nombres y apegos emocionales, a un modelo por el cual si tenemos un problema con el servidor creamos un reemplazo y destruye el servidor problemático.
Finalmente, probablemente valga la pena mencionar que en entornos regulados, sacar un servidor por la parte posterior y dispararlo puede no ser óptimo. En estos casos, a menudo es ventajoso "congelar" el servidor, por ejemplo, usar docker pausepara congelar un contenedor. Esto se puede usar para realizar un análisis de causa raíz como parte del proceso de gestión de incidentes o problemas.
Para agregar a la respuesta de Richards, generalmente la analogía es útil en términos de considerar el impacto de la pérdida de un servidor.
Si siente algún tipo de angustia por la pérdida de una pieza individual de infraestructura, considérelo una mascota (lea antipatrón).
Si se sintiera bastante cómodo sabiendo que si alguna flota dejara de funcionar no habría un impacto real en las operaciones, entonces está hablando de ganado.
A menudo es tentador utilizar la analogía para clasificar simplemente sus servidores, es decir, "nuestros nodos de carga de trabajo son ganado pero nuestros equilibradores de carga son mascotas", pero caer en esa trampa es exactamente el problema. No hay lugar para mascotas en un entorno informático moderno (es decir, en la nube, en hardware básico, etc.). Si todos sus servidores se consideran ganado y son fácilmente reemplazables, puede comenzar a buscar cosas como el mono del caos para ayudar garantice que su infraestructura sea realmente resistente.