15 votos

La gestión de una aplicación a través de múltiples servidores, o PXE vs cfEngine/Chef/la Marioneta

Tenemos una aplicación que se ejecuta en un par de (5 o así y seguirá creciendo) cajas. El hardware es idéntico en todas las máquinas, y lo ideal es que el software debería ser así. He sido la gestión de ellos con la mano hasta ahora, y no quiero más (direcciones ip estáticas, la desactivación de todos los servicios necesarios, la instalación de los paquetes necesarios...) . Puede alguien balance de los pros y los contras de las opciones siguientes, o sugerir algo más inteligente?

1: de forma Individual instalar centos en todas las cajas y administrar las configuraciones con el chef/cfengine/puppet. Esto sería bueno, como yo quería una excusa para aprender a utilizar una de las aplicaciones, pero no sé si esto es realmente la mejor solución.

2: Hacer un cuadro perfecto y la imagen. Servir la imagen a través de PXE y cada vez que quiero hacer modificaciones, solo puedo reiniciar las cajas de una nueva imagen. ¿Cómo clúster chicos suelen manejar las cosas como tener direcciones mac en el archivo /etc/sysconfig/network-scripts/ifcfg* los archivos? Utilizamos infiniband, y también se niega a iniciar si la hwaddr que está mal. Estos se generan correctamente en el arranque?

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

Todos los servidores cuentan con unidades Ssd en ellos y son rápidos y potentes.

Gracias, matt.

12voto

cagenut Puntos 3900

El clúster suena más como un clúster de HPC de un OLTP uno como el mío, pero creo que la configuración que estoy usando iba a funcionar para usted también. Yo lo llamo el "mpdehaan trifecta", porque ese es el ircnick de el hombre que escribió o gestiona los tres herramientas implicadas.

1.) Zapatero de la base construir el aprovisionamiento. Zapatero es un proyecto que pretende ser la intersección de su kickstart, pxe, yum-repo, dhcp, dns, etc sistemas. Su por lejos la forma más fácil para conseguir un arranque rápido de instalación y funcionamiento, y que puede crecer en el resto de las características como sea necesario.

2.) Puppet para la gestión de la configuración. Lo ideal sería que el zapatero construido los anfitriones son muy escueta configs que saber sólo lo suficiente para teléfono de la casa a su títere servidor de inicio. La marioneta se aplicarán los parámetros de configuración y los mantenga constante a través de su entorno en perpetuidad.

3.) Func para comandos ad-hoc para varias máquinas en paralelo. Por ejemplo, "implementación de un nuevo svn checkout del código y reiniciar apache". Su muy fácil de usar sólo func llamar el mismo comando de bash en un grupo de servidores tanto como clúster de ssh. Si usted realmente desea conseguir en ella puedes escribir tus propios módulos para con algunos realmente simple de python.

Todas las tres de estas herramientas tienen buena wiki y activa canales de irc para ayudar en freenode.

5voto

Warner Puntos 17528

Descripción

En algunas maneras, usted tiene dos preguntas aquí..

  • ¿Cómo puedo construir y mantener servidores estándar?
  • ¿Cómo puedo mantener la configuración estándar y realizar cambios más adelante?

He dividido mi respuesta por debajo de abordar esas dos cosas por separado, pero que están muy estrechamente relacionados. Me dirijo a las soluciones de tecnología de aquí y no de cualquiera de las mejores prácticas que están relacionados, tales como el control de cambios.

Si este no cubre el alcance de su pregunta, por favor aclarar y voy a ser feliz, a elaborar. Esto es necesario de la fundación, que es fundamental para una buena gestión de la infraestructura tecnológica.

La Construcción De Los Servidores

No me gustan las imágenes en el mundo UNIX; que es más de un estilo de Windows enfoque. Incluso algunas Ventanas de la gente parece ser un nuevo enfoque en secuencias de comandos estándar construye ahora.

Satélite parece conseguir algo popular en la RHEL mundo. Spacewalk es la Fuente Abierta de contraparte. Definitivamente, usted tiene que comprar en la RHEL enfoque totalmente el uso de este. Esto sirve tanto como servidor de la construcción y la gestión de la configuración.

Idealmente, usted quiere establecer local espejos y repositorios en un servidor de archivos para todo el software necesario.

En primer lugar, tomar ventaja de la generación de distribución de automatización, tales como Kickstart en RHEL/CentOS. El Kickstart sería una línea de base con variaciones, dependiendo de sus necesidades. El Kickstart construye puede ser iniciada desde un servidor PXE.

Para los más avanzados de la parte de la construcción y cualquier cosa que no era adecuado para un archivo Kickstart, usted puede escribir sus propios scripts personalizados. Sin embargo, usted puede encontrar títere o cfengine que funciona bien para usted en lugar de secuencias de comandos personalizadas. He encontrado secuencias de comandos personalizadas para ser más flexible y no se limitan a un solo enfoque.

Si usted decide escribir sus propios scripts, te recomiendo un core secuencia de comandos de configuración universal. Esta sería la configuración de seguridad, endurecimiento, y cualquier cosa que se aplica a todas las versiones. Al final una secuencia de comandos para finalizar la función de servidor. Por ejemplo, un servidor web o un servidor de base de datos.



El Mantenimiento De Los Estándares De

Lo que usted describe también cae bajo el mantenimiento de configuraciones. Los estándares de construcción, actualizaciones de software, y otras cosas que están relacionadas con la construye, pero en un montón de maneras separadas.

Si usted elige confiar en el sistema de paquetes en lugar de crear su propia fuente basado construye para sus más importantes funciones de servidor, muchos de los que se pueden mantener de forma nativa con las utilidades del sistema. Esto puede ser tan simple como una secuencia de comandos para ejecutar un for de bucle en contra de su lista de servidor y ejecutar un yum -y update package.

Para la gestión de la configuración, esto es, donde la marioneta, cfengine, y otros de gestión de la configuración de las utilidades que entran en juego. Estos son muy útiles servicios públicos y proporcionar la base necesaria sin necesidad de escribir sus propios scripts desde cero.

Cuando la actualización de sus normas de configuración de los servidores, es importante para la reposición de este en su servidor estándar se basa.

0voto

Kirill Osenkov Puntos 3902

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

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

Gpxe le dará más flexibilidad con arranque de los objetivos . Es muy fácil de arranque de un área de efecto de la cuchilla y no hay nada como arrancar un kernel fuera de un servidor http remoto!!!!!!!!!! :-).

¿Qué servidor veces se necesita?

Es imposible crear una imagen perfecta, como tu siempre vas a necesitar para aplicar los parches de seguridad y actualizaciones de software. Si tienen conexión a internet, usted no puede pasar por alto la aplicación de parches.

En el pxe lado, tienes un par de opciones, dependiendo de su e/S de archivos de clúster. Ya sea acaba de arrancar un kernel y montar el disco de forma remota a través de aoe o iscsi.

También puede hacer algunas cosas muy inteligente con copia de escritura de imágenes. Es ideal para las actualizaciones y revertir los cambios que podría ser problemático.

También he tenido éxito en el uso de la root de nfs , el uso de un clúster de nfs solución. Puede especificar archivos diferentes para ser servido, dependiendo de sus direcciones de cliente.

De nuevo, usted debe comprobar si la aplicación de la(s) le gusta correr fuera de nfs. No es adecuado para cada carga de trabajo.

agrupado nfs sever puede contener 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

por lo tanto, cada cliente hace referencia al mismo archivo, pero te sirve el archivo que es relevante para el cliente. Es bastante impresionante cosas, sin embargo no es sencillo!

Todo esto te dará más rápido despliegue veces si centralizar el sistema de archivos de almacenamiento en red. Imagen de un sistema operativo a través de una red a un disco remoto, toma tiempo!!!!

Si su uso de cualquiera de estas soluciones, asegúrese de que tiene un bien diseñado y culpa tolerante a la capa de red y de que el nfs/SAN server está bien diseñada + seguro!!

Pérdida de la conexión NFS/SAN, sería malo para la salud del servidor. :-(

Es muy fácil de artesanía algunos scripts para que el servidor tftp/pxe para controlar el proceso de arranque.

Si supiera más de lo que tu en realidad tratando de clúster podría tal vez pensar en una solución que era más adecuado para usted.

0voto

Jason Antman Puntos 1378

Recientemente he terminado un gran proyecto para el despliegue de un sistema centralizado de construcción, el aprovisionamiento y la gestión de la configuración del sistema en $TRABAJO. Estamos corriendo CentOS.

Mi diseño, lo que ocurre que me gusta mucho, nos da un prácticamente un solo clic (bueno, una interfaz gráfica de usuario web page) proceso de construcción, el uso personalizado de los scripts PHP para unir todo a través de un sencillo pero eficaz interfaz de usuario web.

La teoría general es:

  1. Hacer todas las instalaciones de un único, unificado, minimalista archivo KickStart (bueno, OK, uno para las arquitecturas x86 y x86-64, pero aún así, prácticamente idénticos a los archivos con un mínimo de selección de paquetes).
  2. KickStat secuencia de comandos postinstall se levanta de la Marioneta.
  3. La marioneta se aplica a todos los nodos/host específico de la configuración, la instalación de paquetes, etc.

Estoy de acuerdo en que las imágenes no son Unix y manera de hacer las cosas... son realmente más adecuado para el mundo de Windows donde scripts/automatizado de instalación y configuración no es tan simple.

Puede reemplazar Puppet con cualquier otro sistema de administración de configuración que se ajusta a la ley, pero a mí me gusta del Puppet declarativa de la naturaleza y su concepto de convergencia.

Este sistema produce una serie de beneficios:

  • La marioneta se encarga de todo, más allá de un genérico a base de instalar, por lo que todos los paquetes necesarios y la configuración en un solo lugar.
  • El Puppet se manifiesta servir como una fuente adicional de bajo nivel de documentación.
  • Mientras usted se pega con Puppet (es decir, no hacer la configuración local de cambios, o combinación de ellos de nuevo en Marioneta) es trivial para construir un duplicado de una máquina.
  • Desde todos los hosts están construidos a partir de una base común, usted puede pre-instalación de hardware o de máquinas virtuales con la base (KickStart) paquete y, a continuación, convertirlos en funcional nodos simplemente por la adición de clases como sea necesario.
  • Puppet permite "etiquetar" los ejércitos de la producción o de desarrollo, por lo que es muy fácil construir un desarrollo/pruebas copia de un host, los paquetes de actualización o hacer cambios de configuración según sea necesario, de prueba, y luego se funden de nuevo en la producción.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: