Opciones para alta disponibilidad multisitio con Puppet

Mantengo dos centros de datos y, a medida que una mayor parte de nuestra infraestructura importante comienza a controlarse a través de Puppet, es importante que el Puppet Master trabaje en el segundo sitio en caso de que nuestro sitio primario falle.

Aún mejor sería tener una especie de configuración activa / activa para que los servidores en el segundo sitio no estén sondeando a través de la WAN.

¿Hay algún método estándar de alta disponibilidad de títeres de sitios múltiples?

Puppet en realidad se presta bastante bien a entornos multi-master, con advertencias. ¿El principal? A muchas partes de Puppet les gusta estar centralizadas. La autoridad de certificación, el inventario y los servicios de tablero / informe, el almacenamiento de archivos y las configuraciones almacenadas, todos ellos están en su mejor momento (o simplemente requieren) una configuración donde solo hay un lugar para que puedan hablar.

Sin embargo, es bastante factible hacer que muchas de esas piezas móviles funcionen en un entorno multimaestro, si está de acuerdo con la pérdida elegante de algunas de las funciones cuando ha perdido su sitio principal.

Comencemos con la funcionalidad base para obtener un nodo que informa a un maestro:

Módulos y Manifiestos

Esta parte es simple. La versión los controla. Si se trata de un sistema de control de versiones distribuido, simplemente centralice y sincronice, y modifique su flujo de inserción / extracción según sea necesario en el sitio de conmutación por error. Si se trata de Subversion, entonces probablemente querrá svnsyncel repositorio en su sitio de failover.

Autoridad certificada

Una opción aquí es simplemente sincronizar los archivos de autoridad de certificación entre los maestros, para que todos compartan el mismo certificado raíz y puedan firmar certificados. Esto siempre me ha parecido "hacerlo mal";

• ¿Debería un maestro realmente ver su propio certificado presentado en la autenticación del cliente para una conexión entrante de otro maestro como válida?
• ¿Funcionará de manera confiable para el servicio de inventario, el tablero, etc.?
• ¿Cómo agrega nombres alternativos de DNS válidos adicionales en el futuro?

Honestamente, no puedo decir que he hecho pruebas exhaustivas de esta opción, ya que parece horrible. Sin embargo, parece que Puppet Labs no está buscando alentar esta opción, según la nota aquí .

Entonces, lo que deja es tener un maestro de CA central. Todas las relaciones de confianza siguen funcionando cuando la CA está inactiva ya que todos los clientes y otros maestros almacenan en caché el certificado de la CA y la CRL (aunque no actualizan la CRL tan a menudo como deberían), pero no podrá firmar nuevos certificados hasta obtiene una copia de seguridad del sitio primario o restaura el maestro de CA a partir de copias de seguridad en el sitio de conmutación por error.

Escogerá un maestro para que actúe como CA y hará que todos los demás maestros lo deshabiliten:

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

Entonces, querrá que ese sistema central obtenga todo el tráfico relacionado con los certificados. Hay algunas opciones para esto;

1. Utilice el nuevo SRVsoporte de registros en 3.0 para apuntar todos los nodos de agente al lugar correcto para la CA:_x-puppet-ca._tcp.example.com
2. Configure la ca_serveropción de configuración en el puppet.confde todos los agentes

3. Proxy todo el tráfico para solicitudes relacionadas con CA de agentes en el maestro correcto. Por ejemplo, si está ejecutando todos sus maestros en Apache a través de Passenger, configúrelo en los no CA:

   SSLProxyEngine On
   # Proxy on to the CA.
   ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
   # Caveat: /certificate_revocation_list requires authentication by default,
   # which will be lost when proxying. You'll want to alter your CA's auth.conf
   # to allow those requests from any device; the CRL isn't sensitive.
   

Y eso debería hacerlo.

Antes de pasar a los servicios auxiliares, una nota al margen;

Nombres DNS para certificados maestros

Creo que esto es la razón más convincente para pasar a 3.0. Supongamos que desea apuntar un nodo a "cualquier antiguo maestro de trabajo".

Bajo 2.7, necesitaría un nombre DNS genérico como puppet.example.com, y todos los maestros lo necesitan en su certificado. Eso significa establecer dns_alt_namesen su configuración, volver a emitir el certificado que tenían antes de que se configuraran como maestro, volver a emitir el certificado nuevamente cuando necesite agregar un nuevo nombre DNS a la lista (como si quisiera tener varios nombres DNS para tienen agentes prefieren maestros en su sitio) .. feo.

Con 3.0, puede usar SRVregistros. Dale a todos tus clientes esto;

[main]
    use_srv_records = true
    srv_domain = example.com

Entonces, no se necesitan certificados especiales para los maestros: solo agregue un nuevo registro a su SRVRR en _x-puppet._tcp.example.comy listo, es un maestro en vivo en el grupo. Mejor aún, puede hacer que la lógica de selección maestra sea más sofisticada; "cualquier antiguo maestro que trabaje, pero prefiera el que está en su sitio" al configurar diferentes conjuntos de SRVregistros para diferentes sitios; no es dns_alt_namesnecesario

Informes / Panel de control

Este funciona mejor centralizado, pero si puedes vivir sin él cuando tu sitio principal está inactivo, entonces no hay problema. Simplemente configure todos sus maestros con el lugar correcto para colocar los informes.

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

..y ya está todo listo. No cargar un informe no es fatal para la ejecución de la configuración; simplemente se perderá si las tostadas del servidor del tablero de instrumentos.

Inventario de hechos

Otra cosa buena que hayas pegado en tu tablero es el servicio de inventario. Con el facts_terminusconjunto restsegún lo recomendado en la documentación, esto realmente interrumpirá las ejecuciones de configuración cuando el servicio de inventario central esté inactivo. El truco aquí es usar el inventory_servicetérmino en los maestros no centrales, lo que permite una falla graciosa.

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

Tenga su servidor de inventario central configurado para almacenar los datos de inventario a través de ActiveRecord o PuppetDB, y debe mantenerse actualizado siempre que el servicio esté disponible.

Entonces, si está de acuerdo con tener un entorno de administración de configuración bastante básico donde ni siquiera puede usar la CA para firmar un nuevo certificado de nodo hasta que se restaure, entonces esto puede funcionar bien, aunque sería realmente bueno si algunos de estos componentes fueran un poco más amigables para ser distribuidos .

El enfoque de "títere sin maestro" que describe Ladadadada es con el que estoy más familiarizado (es básicamente lo que hacemos con radmind en mi empresa). Creo que con mayor precisión es "Maestros múltiples sincronizados por un proceso externo", donde cualquier servidor podría (en teoría) servir a todo nuestro universo en una emergencia.

En nuestro caso, debido a la naturaleza de radmind, simplemente rsynclas transcripciones y los archivos de datos de un maestro aprobado al servidor radmind de cada sitio remoto, y los clientes extraen sus actualizaciones del servidor con un nombre de host corto radmind(a través de la magia de resolv.confesto se evalúa como radmind.[sitename].mycompany.comsiempre local). servidor radmind. Si el servidor local está caído, es bastante fácil anular y apuntar a cualquier otro servidor del sitio).

Este tipo de proceso rsync probablemente también funcionaría en su situación, pero probablemente sea subóptimo en comparación con una solución basada en control de versiones.

Para títeres o chefs, un sistema basado en el control de versiones tiene más sentido que el simple rsync por varias razones: la principal es que estás controlando las versiones de scripts de títeres (en lugar de imágenes completas del sistema operativo como lo harías con radmind).
Como beneficios adicionales de la administración basada en el control de versiones, puede hacer que varias personas trabajen en el repositorio a la vez (una gran victoria para el paralelismo), obtiene el historial de revisiones esencialmente de forma gratuita, y si alguien rompe el entorno de Puppet, tiene una reversión fácil (suponiendo que usted ' lo gitestás usando también tienes git blameque hace lo que dice en la lata).
La ramificación y fusión creativa incluso le permite manejar una importante actualización del sistema operativo u otra transición dentro del marco de control de versiones: una vez que lo haga correctamente, simplemente cambie a la nueva rama y (con suerte) el impulso de producción simplemente funcionará.

Si implementara esto aquí, probablemente aprovecharía los ganchos de pre-commit y post-commit en git para asegurar que las configuraciones de títeres que se están comprometiendo sean sanas (pre-lado del cliente) y las empuje al resto del universo si are (publicación del lado del servidor, posiblemente también desencadenando una actualización del entorno si sus políticas de implementación permiten tal comportamiento).

En términos de abrir nuevos servidores de puppetmaster en cada sitio, simplemente puede consultar el entorno de puppet para cada puppetmaster remoto y usar la piratería resolv.conf / hostname que describí anteriormente o cualquier IP de servicio de difusión redirigida a sistemas locales como sugirió Michuelnik ( este último es útil si desea una conmutación por error automática si el maestro de marionetas de un sitio explota) para asegurarse de que cada sitio vea al maestro de marionetas "correcto" y no obstruya sus enlaces WAN al intentar obtener actualizaciones.

La gente de Brain Tree Payments aparentemente ha combinado el control de versiones y las soluciones rsync junto con algunas tareas personalizadas de Capistrano: su solución parece estar a medias en el sentido de que todavía se basa en elementos de flujo de trabajo manual, pero podría adaptarse y automatizarse sin demasiado trabajo.
El probador compulsivo paranoico en mí tiene una afición por su nooppaso de verificación de cordura: el que odia los procesos manuales en mí desea un cierto nivel de automatización a su alrededor ...