Tenemos una aplicación que se ejecuta en algunos cuadros (más o menos 5 y crecerá). El hardware es idéntico en todas las máquinas, e idealmente el software también lo sería. Los he estado administrando a mano hasta ahora, y no quiero más (direcciones IP estáticas, deshabilitar todos los servicios necesarios, instalar paquetes necesarios ...). ¿Alguien puede equilibrar los pros y los contras de las siguientes opciones, o sugerir algo más inteligente?

1: instale centos individualmente en todas las cajas y administre las configuraciones con chef / cfengine / puppet. Esto sería bueno, ya que quería una excusa para aprender a usar una de las aplicaciones, pero no sé si esta es realmente la mejor solución.

2: Haga una caja perfecta e imagínela. Servir la imagen sobre PXE y cada vez que quiera hacer modificaciones, simplemente puedo reiniciar los cuadros desde una nueva imagen. ¿Cómo manejan normalmente los chicos del clúster cosas como tener direcciones MAC en los archivos / etc / sysconfig / network-scripts / ifcfg *? También utilizamos infiniband, y también se niega a comenzar si el hwaddr está mal. ¿Se pueden generar correctamente en el arranque?

Me estoy inclinando hacia la solución PXE, pero creo que el monitoreo con munin o nagios será un poco más complicado con esto. ¿Alguien tiene experiencia con este tipo de problema?

Todos los servidores tienen SSD y son rápidos y potentes.

Gracias Matt.

Su clúster suena más como un clúster HPC que como uno OLTP como el mío, pero creo que la configuración que estoy usando también funcionaría para usted. Lo llamo el "mpdehaan trifecta" porque ese es el problema del tipo que escribió o maneja las tres herramientas involucradas.

1.) Zapatero para el aprovisionamiento de construcción base. Cobbler es un proyecto que pretende ser la intersección de sus sistemas kickstart, pxe, yum-repo, dhcp, dns, etc. Es, con mucho, la forma más fácil de configurar y ejecutar una configuración kickstart, y puede desarrollar las otras funciones según sea necesario.

2.) Puppet para la gestión de la configuración. Idealmente, sus hosts construidos de zapatero son configuraciones muy básicas que saben lo suficiente como para llamar a su servidor de marionetas al inicio. Puppet aplicará sus ajustes de configuración y los mantendrá consistentes en todo su entorno a perpetuidad.

3.) Func para comandos ad-hoc para múltiples máquinas en paralelo. Por ejemplo, "despliegue una nueva comprobación de svn del código y reinicie apache". Es bastante fácil usar func para llamar al mismo comando bash en un grupo de servidores de forma muy similar a cluster-ssh. Si realmente desea entrar en él, puede escribir sus propios módulos para ello con un pitón realmente simple.

Las tres herramientas tienen buenos wiki y canales de IRC activos para obtener ayuda sobre freenode.

Visión general

De alguna manera, tienes dos preguntas aquí ...

• ¿Cómo construyo y mantengo servidores estándar?
• ¿Cómo mantengo la configuración estándar y hago cambios más tarde?

He dividido mi respuesta a continuación abordando esas dos cosas por separado, pero están muy relacionadas. Aquí estoy abordando las soluciones tecnológicas y no ninguna de las mejores prácticas relacionadas, como el control de cambios.

Si esto no cubre el alcance de su pregunta, por favor aclare y con gusto lo explicaré. Esta es una base necesaria, que es fundamental para una infraestructura tecnológica bien administrada.

Servidores de construcción

No me gustan las imágenes en el mundo UNIX; ese es más un enfoque de estilo Windows. Incluso algunas personas de Windows parecen estar volviendo a centrarse en los scripts para compilaciones estándar ahora.

Parece que el satélite se está volviendo algo popular en el mundo de RHEL. Spacewalk es la contraparte de código abierto. Definitivamente tienes que comprar el enfoque RHEL por completo para usar esto. Esto sirve tanto para la construcción del servidor como para la gestión de la configuración.

Idealmente, desearía establecer espejos y repositorios locales en un servidor de archivos para todo el software necesario.

Primero, aproveche su automatización de compilación de distribución, como Kickstart en RHEL / CentOS. El Kickstart sería una línea de base con variaciones, dependiendo de sus necesidades. Las compilaciones de Kickstart se pueden iniciar desde un servidor PXE.

Para la parte más avanzada de la compilación y cualquier cosa que no sea adecuada para un archivo Kickstart, puede escribir sus propios scripts personalizados. Sin embargo, es posible que Puppet o cfengine funcionen bien para usted en lugar de los scripts personalizados. He encontrado que los scripts personalizados son los más flexibles y no se limitan a ningún enfoque individual.

Si elige escribir sus propios scripts, le recomiendo un script central para la configuración universal. Esto sería configuración de seguridad, endurecimiento y cualquier cosa que se aplique a todas las compilaciones. Luego, un script final para finalizar la función del servidor. Por ejemplo, un servidor web o un servidor de base de datos.

Mantener estándares

Lo que usted describe también se encuentra en el mantenimiento de las configuraciones. Los estándares de compilación, las actualizaciones de software y otras cosas están relacionadas con las compilaciones, pero de muchas maneras están separadas.

Si elige confiar en los paquetes del sistema en lugar de crear sus propias compilaciones basadas en la fuente para sus roles de servidor más importantes, se puede mantener mucho de eso con las utilidades del sistema nativo. Esto puede ser tan simple como un script para ejecutar un forbucle contra su lista de servidores y ejecutar a yum -y update package.

Para la gestión de la configuración, aquí es donde entran en juego puppet, cfengine y otras utilidades de gestión de la configuración . Estas son utilidades muy útiles y proporcionan la base necesaria sin escribir sus propios scripts desde cero.

Cuando actualiza sus estándares de configuración para sus servidores, es importante rellenar esto en sus compilaciones de servidor estándar.

Recientemente terminé un gran proyecto para implementar un sistema centralizado de gestión de configuración / aprovisionamiento y configuración en $ WORK. Estamos ejecutando CentOS.

Mi diseño, que realmente me gusta, nos brinda un proceso de compilación de un solo clic (bueno, una página web GUI), utilizando algunos scripts PHP personalizados para unir todo a través de una interfaz de usuario web simple pero efectiva.

La teoría general es:

1. Realice todas las instalaciones desde un archivo KickStart único, unificado y minimalista (bueno, OK, uno para x86 y otro para x86-64, pero aún así, archivos prácticamente idénticos con una selección mínima de paquetes).
2. KickStat inicia el script de arranque de Puppet.
3. Puppet aplica todas las configuraciones específicas de nodo / host, instalación de paquetes, etc.

Estoy de acuerdo en que las imágenes no son una forma Unix de hacer las cosas ... son realmente más adecuadas para el mundo de Windows, donde la instalación y configuración con guiones / automatizadas no es tan simple.

Puede reemplazar Puppet con cualquier otro sistema de administración de configuración que se ajuste a la factura, pero resulta que me gusta la naturaleza declarativa de Puppet y su concepto de convergencia.

Este sistema produce una serie de beneficios:

• Puppet maneja todo más allá de una instalación base genérica, por lo que todos los paquetes y configuraciones requeridos están en un solo lugar.
• Los manifiestos de Puppet sirven como una fuente adicional de documentación de bajo nivel.
• Siempre y cuando se quede con Puppet (es decir, no realice cambios de configuración local, ni los fusione nuevamente en Puppet), es trivial construir un duplicado de una máquina.
• Dado que todos los hosts se crean a partir de una base común, puede preinstalar hardware o máquinas virtuales con el conjunto de paquetes base (KickStart) y luego convertirlos en nodos funcionales simplemente agregando clases según sea necesario.
• Puppet permite "etiquetar" hosts para producción o desarrollo, por lo que es increíblemente fácil construir una copia de desarrollo / prueba de un host, actualizar paquetes o realizar cambios de configuración según sea necesario, probar y luego volver a fusionarlo en producción.

Si sigue la ruta pxe, asegúrese de echar un vistazo a

http://etherboot.org/wiki/index.php

Gpxe te dará más flexibilidad con los objetivos de arranque. ¡¡¡Es bastante fácil arrancar un aoe blade y no hay nada como arrancar un kernel desde un servidor http remoto !!!!!!!!!! :-).

¿Qué tiempos de servidor necesita?

Es imposible crear una imagen perfecta, ya que siempre necesitará aplicar parches de seguridad y actualizaciones de software. Si se enfrentan a Internet, no puede ignorar los parches.

En el lado pxe, tiene algunas opciones, dependiendo de la E / S de archivo de su clúster. Puede iniciar un kernel y montar el disco de forma remota sobre aoe o iscsi.

También puede hacer algunas cosas muy inteligentes con copiar en escribir imágenes. Es ideal para actualizaciones y para revertir cualquier cambio que pueda ser problemático.

También he tenido éxito usando la raíz nfs, usando una solución nfs agrupada. Puede especificar diferentes archivos para servir dependiendo de las direcciones de sus clientes.

Nuevamente, debe verificar si a su aplicación le gusta ejecutar nfs. No es adecuado para todas las cargas de trabajo.

el servidor nfs agrupado puede contener 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

entonces, cada cliente hace referencia al mismo archivo, pero recibe el archivo relevante para el cliente. Es algo bastante impresionante, ¡pero no es simple!

Todo esto le dará tiempos de implementación más rápidos si centraliza el sistema de archivos en el almacenamiento de red. ¡La creación de imágenes de un sistema operativo a través de una red en un disco remoto lleva tiempo!

Si está utilizando alguna de estas soluciones, asegúrese de tener una capa de red bien diseñada y tolerante a fallas y que su servidor nfs / SAN esté bien diseñado y sea seguro.

Perder la conexión de su NFS / SAN sería malo para la salud del servidor. :-(

Es bastante fácil crear algunos scripts para tftp / pxe para controlar el proceso de arranque.

Si supiera más sobre lo que realmente está intentando agrupar, tal vez podría pensar en una solución que sea más adecuada para usted.