Elegir entre nombres de host significativos y sin sentido [cerrado]

Asuma un entorno con un clúster gestionado por títeres de diferentes servidores: hardware, software, sistemas operativos, virtuales / dedicados, etc.

¿Elegiría nombres de host significativos (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, etc.) o preferiría nombres de host sin sentido, como los personajes de un libro o una película?

El problema que veo con nombres de host significativos es que los nombres generalmente representan un solo servicio y si un servidor tiene más de un propósito, se vuelve realmente desordenado (especialmente si los roles del servidor cambian con frecuencia).

¿No está asignando un nombre de servicio a una dirección IP y manteniendo esa asignación lo que se supone que debe hacer DNS?

¿Cuáles son las ventajas y los inconvenientes de ambos enfoques y qué problemas reales ha tenido que abordar con el enfoque que eligió?

Érase una vez tuve la oportunidad de decidir sobre un esquema de nombres. Así que di vueltas y pregunté a mis desarrolladores, quienes, después de todo, eran las personas que tenían que trabajar con estos nombres en el día a día, si preferían los nombres funcionales (es decir, nombres que representan, de alguna forma codificada, el propósito de la máquina) o nombres mnemotécnicos (es decir, nombres extraídos de algún esquema de nombres humanos preexistente, que no contenía contenido implícito sobre el propósito de la máquina).

De 38 desarrolladores, 37 nombres mnemónicos preferidos; solo uno prefiere los nombres funcionales. Así que los nombré a todos después de los ríos (hay una gran cantidad de nombres posibles, y muchos de ellos son cortos, fáciles de recordar y rápidos de escribir).

El cerebro humano está bastante bien diseñado para atribuir significado a los nombres. Si proporciona nombres memorables, las personas recordarán rápidamente para qué se usan esos nombres y los usarán. Si utiliza nombres extraídos de un trasfondo común (por ejemplo, ríos, elementos, estrellas, condados, bebidas, se le ocurre la idea), ayuda a las personas a reconocer de inmediato el nombre de host de una empresa cuando lo encuentran; de lo contrario, declaraciones como "todo el correo electrónico terminó betelgeuse" pueden ser un poco confusas).

Por el contrario, mis desarrolladores sintieron que habían tenido trabajos previos realmente difíciles de recordar exactamente lo que pr1ms001era.

Pero debo agregar que utilizamos CNAME en el DNS interno para proporcionar un nombre funcional a la asignación de nombres mnemotécnicos, por lo que si realmente le resultó más fácil recordar que el servidor de correo principal en el primer clúster en el sitio de relaciones públicas era pr1ms001, entonces el DNS lo haría hacerle saber que eso era actualmente orwell. Además, eso nos permite tener muchos nombres funcionales por máquina, por lo que siempre que use el nombre funcional relevante para la función en la que estaba trabajando, podría estar seguro de que pr1imap001siempre apuntaría al servidor IMAP, incluso si moviéramos esa funcionalidad de orwella rhine. Y cuando hudsonmurió, podríamos cambiar el nombre del reemplazo sin afectar las funciones operativas, de modo que nunca tuviéramos el "¿quieres decir nuevo hudsono viejo hudson?" Confusión.

Esto se reduce en gran medida a si sus servidores son petso livestock.

Las mascotas obtienen nombres individuales. Son distintos entre sí, y nos preocupamos por esas diferencias. Cuando uno se enferma, generalmente tratamos de curarlo para que recupere la salud. Tradicionalmente, los servidores han sido mascotas.

El ganado obtiene números. En su mayoría son idénticos, y qué diferencias hay, no nos importan y generalmente tratamos de minimizar. Cuando uno se enferma, lo dejamos y obtenemos otro. Los servidores totalmente virtualizados, especialmente los servidores IaaS como AWS, son ganado.

En los entornos más complejos, tienes una mezcla. Sus backends web, por ejemplo, son casi seguramente ganado. Si necesita más, puede girar un poco más con la configuración estándar; Si no necesita tantos, apague algunos. Sus servidores de bases de datos, en algunas configuraciones, son mascotas. Puede haber mucha configuración especial en cada uno; incluso puede ejecutarlos en metal desnudo en lugar de virtualización.

Por supuesto, en cualquier entorno, puede nombrar SERVICIOS y abordarlos directamente. Esta es una mejor práctica en cualquier caso; sus desarrolladores no deberían necesitar saber o importar cuál es el nombre de host real de un servicio. El nombre de host debe ser un detalle puramente operativo. Piense, entonces, en codificar información que sea útil para su personal de operaciones en los nombres de host; por ejemplo, a menudo es útil denotar en qué centro de datos se encuentra un servidor.

Esto ha sido cubierto aquí antes ...

Mi recomendación es una combinación de nombres funcionales y nombres mnemotécnicos ...

Si está escribiendo una solicitud y necesita una dirección ccts-logserver1, use ese nombre en todas partes, pero conviértalo en un CNAME o un alias. El verdadero nombre de host puede ser lo que quieras: una fruta o verdura, la mitología griega o el personaje de Seinfeld ... pero te da cierta flexibilidad cuando necesitas asociar nombres funcionales reales, pero conserva algo que la gente pueda recordar.

Piense en el ejemplo donde mango, el servidor de base de datos falla ... pero se reemplaza con otra cosa, digamos peach. Quizás los procesos y aplicaciones existentes necesitan ver cmt-prod-db1. Puede intercambiar los sistemas, construirlos sin conflictos de nombres y mantener felices a las aplicaciones (y desarrolladores).

Donde trabajo gestionamos múltiples sitios, múltiples compañías, en múltiples ciudades. Para nosotros, los nombres mnemotécnicos no pueden funcionar. En su lugar, usamos un formulario abreviado que describe nuestros servidores. Esto funciona bien en nuestro caso, ya que tenemos algunos clientes que pueden tener varias oficinas en diferentes dominios (o una sola oficina en múltiples dominios, o varias oficinas en el mismo dominio, ¡o todo lo anterior!)

Para nosotros, la información contiene Compañía / Dominio, ciudad, función, número. Entonces, para un controlador de dominio para una compañía, digamos Cypress en Chicago sería:

CYPRCHDOM001 (Nos referiríamos a esto como DOM principal de Cypress en la conversación)

CYPRCHSQL001 sería su servidor SQL, CYPRCHMGM001 sería su administración (es decir, antivirus, copias de seguridad, etc.), y CYPRCHAPP001 sería un servidor de aplicaciones mixtas. Fácil de recordar, fácil de clasificar, fácil de enseñar.

El único requisito para los nombres de host es que deben ser únicos en la red.

El significado no solo tiene que ver con la función de los servidores. La ubicación puede ser muy útil si tiene que lidiar con dispositivos físicos. Saber si un dispositivo es virtual o físico también puede ser útil. Ser capaz de distinguir la diferencia entre un dispositivo de red, un servidor Linux o un cuadro de Windows puede ser muy útil cuando se trata de averiguar qué herramienta usar para iniciar sesión.

La forma en que lo manejamos es tratar de poner esta información en el nombre del dispositivo de la siguiente manera:

L o T - Live o Test P o V - Físico o virtual S o N - Servidor o Red (no tenemos ningún servidor Linux) un número secuencial para garantizar la unicidad Un código de país ISO 3166-1 de tres letras que indica dónde está el dispositivo se encuentra.

Luego usamos CNAMES en DNS para asignar varios nombres de servicios al nombre de host.

Tengo sentimientos encontrados sobre esto. Sin duda, ahorra tiempo al tener que buscar dónde se encuentra un determinado dispositivo. Por otro lado, es mucho más difícil recordar lo que hace un servidor dado cuando se le presenta su nombre de host, en comparación con nuestro sistema anterior que usaba piedras preciosas. Las piedras preciosas no implicaban ningún significado en absoluto, pero eran fáciles de recordar porque cada persona podía crear sus propias conexiones.

Supongo que el único consejo sería establecer un esquema ya que la mayor confusión surgió cuando hicimos la transición de un sistema a otro.