Convenciones de nomenclatura de servidores funcionales

Question

He visto "The Coolest Server Names" y he visto otro smaller-ish question relacionado con el mío, que desafortunadamente se cerró.

Es una pregunta seria, ya que estoy en un equipo de desarrollo de aplicaciones internas que administra las aplicaciones en un par de docenas de servidores. A la gente de la red generalmente no le importa lo que llamamos los servidores, siempre y cuando conozcan sobre ellos, para que podamos llegar a cualquier convención.

Las aplicaciones que manejan los servidores pueden ser aplicaciones personalizadas de fabricación propia o pueden ser de mayor tamaño como SharePoint. Pueden ser:

• En distintos entornos de red que no pueden hablar el uno al otro (con cortafuegos pensar servidores externos-off frente a servidores de intranet-esque)
• En diferentes lugares físicos (la oficina de California frente a Nueva York, etc. .)
• En múltiples niveles de despliegue (producción, montaje, pruebas, dev)
• tener una o varias funciones (servidor web, servidor de base de datos, servidor de correo, servidor de aplicaciones)
• carga equilibrada o no
• Colocarse (para fines de recuperación de desastres) o primario

¡Whew! ¿Crees que incluso es posible llegar a una convención que pueda abordar todos estos aspectos, o los más importantes? Sería bueno escuchar el nombre de un servidor (o una entrada de DNS) y ser capaz de saber de inmediato lo que hace, y también sirve para que los chicos nuevos entren en velocidad. "sharepoint-IPC-1 está inactivo" podría ser analizado en "el servidor web de producción interno de SharePoint en el centro de datos de California que es el primer nodo en el balanceo de carga está inactivo" ... pero eso parece demasiado complicado a primera vista.

Otra cosa en mi mente es que un antiguo servidor de retransmisión de correo se está desmantelando, lo que significa que tenemos que revisar muchas aplicaciones antiguas para volver a establecer los valores del servidor codificado (lo sé ... :).

Answer 1

Aquí hay algunas pautas generales que trato de cumplir, basadas en errores que he cometido en el pasado.

Nunca base sus nombres de la máquina de ...

• hardware Máquinas swapeada fuera todo el tiempo, y usted no quiere tener que hacer demasiado trabajo si cambia de un IBM servidor, a un servidor Sun, a un servidor Dell.

• Ubicación El equipo e incluso las salas de servidores se pueden mover en función de los requisitos comerciales o los problemas técnicos.

• Uso previsto A medida que su producto evoluciona, también lo hará el uso previsto de cada servidor. Tener una máquina llamada "dbsrv" pero eventualmente actúa como un servidor de archivos también es confuso.

• Propietario La persona que "posee" el equipo (un empleado) puede cambiar, debido a despidos, despidos y movimientos dentro de la empresa.

• Subred Como dije antes, los laboratorios pueden moverse, y también lo pueden hacer las subredes. Uno de los objetivos principales del DNS es liberarte de estar vinculado a una dirección IP específica, entonces, ¿por qué atarte innecesariamente?

Ahora, algunas sugerencias para la situación que describes ...

• máquinas distribuidas en una región Esto es lo que los subdominios están en el DNS. Podría tener "west.company.com" y "east.company.com".

• Tiene una o más funciones No las nombre de acuerdo con el uso previsto. Si los nombra basándolos en una gran colección de nombres, dioses griegos, por ejemplo, con el tiempo sabrá intuitivamente que zeus.east significa su servidor principal de base de datos y apollo.west es su servidor de base de datos de respaldo. En el peor de los casos, búscalo en una hoja de cálculo.

• Carga equilibrada o no Puede tomar dos enfoques. Podría tener un nombre único por nodo detrás del equilibrador de carga, o podría hacer algo como athena-1.east, athena-2.east, etc. De cualquier manera, un equilibrador de carga (con suerte) le liberará de preocuparse demasiado por lo que cada nodo recibe su nombre

• En espera o no Esto no suena como un criterio que debería tener un impacto en el nombre de la máquina.

Lo que estoy diciendo es esencialmente:

1. independiente de su equipo en diferentes subdominios regionales
2. Elija un esquema de nombres con un montón de nombres de dioses griegos (en este ejemplo)
3. Don No basar los nombres en ninguno de los criterios que mencioné anteriormente (uso previsto, ubicación, etc.)

Intentando hacer cualquier cosa más que eso será más problemas de lo que vale la pena.

Answer 2

Sé que es tentador asignar nombres a los servidores que describen sus funciones y otros atributos similares y en un mundo perfecto que funcionará, pero en la práctica he descubierto que después de un tiempo estas cosas se descomponen como funciones y otros parámetros de los servidores cambian (a medida que cambian los requisitos del negocio) por lo que los nombres ya no reflejan la realidad.

Creo que debería asignar nombres únicos a los servidores que no dicen nada sobre la función u otros parámetros y tener algún tipo de lista (actualizada) detallando esas cosas para que su gente pueda buscarla. Eso es lo que hacemos aquí.

El otro extremo es usar direcciones IP solamente o tener nombres basados ​​en direcciones IP que también pueden llevar a un desastre si alguna vez tiene que cambiar sus direcciones IP.