History

Future Work

SORRY, RIGHT NOW THIS PAGE IS ONLY AVAILABLE IN SPANISH. WE HOPE TO HAVE A TRANSLATION ASAP

Lineas futuras de trabajo

Las lineas de trabajo futuras que se deben potenciar en ModularIT son las siguientes

Sistema de despliegue multiplataforma

Modelar el sistema de despliegue utilizando cobbler y puppet para que el despliegue sea completamente automatizado y funcione en cualquier plataforma (Hardware, Xen, KVM, VMWare, etc)

Con este esquema, cada servicio ModularIT debe estar modelada mediante un fichero de instalacion desatendida (kickstart en fedora/centos o preseed en debian/ubuntu) y con catalgos Puppet.

La instalacion inicial de la maquina se hara con el sistema de instalacion desatendida de la distro utilizada (automatizado con cobbler). En la instalacion desatendida se incluira Puppet y se crearan las configuraciones iniciales necesarias para que puppet continue con la configuracion sin intervencion (servidor puppet, nombre y tipo modularit, etc)

En el inicio de la maquina, una vez instalada, se ejecutara puppet que se encargara de terminar la configuracion del sistema en funcion de los parametros definidos en el servidor de configuracion

Una vez que puppet ha terminado la primera configuracion de todo, se ejecutara el script de inicializacion de ModularIT (necesario en algunos servicios). Esta tarea es muy critica y debemos asegurarnos que solo se ejecuta una vez y solo cuando puppet ha terminado la configuracion inicial. Una vez ejecutado el script de inicializacion debe borrarse, moverse o cambiarle los permisos para evitar la ejecucion accidental, ya que en algunos servicios este script inicializa los datos, borrando todos los anteriores.

Potenciar los principios fundamentales

  • Seguridad: Cada maquina de estar perfectamente modelada con su politica SELinux
  • Backups: Mejorar la definicion de backups para poder copiar unicamente los datos de usuario de cada servicio. De esta forma la recuperacion consitiria en un despliegue de VM de servicio y la recuperacion de los datos de usuario, con lo que se acelera la recuperacion
  • Aplicar los principios de doble contabilidad a todo: Este principio consiste en tratar de hacer comprobaciones dobles en todo. Por ejemplo, en las copias de seguridad cruzamos la informacion de los servidores de backup con la de las bases de virtualizacion para detectar maquinas de las que no se esta haciendo copias. Concretamente hay que aplicar doble contabilidad a:
    • Inventario de maquinas: Cotejar la informacion del inventario con la que recopilamos automaticamente para detectar inconsistencias. (Ver seccion de Inventario)
    • Monitorizacion: Cotejar la informacion de las maquinas que estamos monitorizando con la generada en el proceso de inventario, para detectar si tenemos maquinas que no se estan monitorizando (aunque las entradas de monitorizacion se generan dinamicamente)

Single Sign On

Actualmente ModularIT dispone de un servicio de centralizacion de usuarios de forma que para el acceso a todos los servicios ModularIT se utiliza el mismo usuario/clave. Pero este sistema no es un autentico sistema de autenticación única (Single Sign On) porque algunos servicios requieren que el usuario se auntentique en el momento de acceso al servicio.

Uno de los puntos que es necesario potenciar es el disponer de un autentico sistema de autenticación unico, de forma que los usuarios solo deben validarse una vez para el acceso a todos los servicios ModularIT.

Para implantar un servicio de este tipo probablemente adoptaremos soluciones basadas en LDAP/Kerberos como FreeIPA (www.freeipa.org) y se necesitara adaptar algunos de los servicios para soportar este sistema de autenticación

Descubrimiento de otras maquinas ModularIT instaladas

Para facilitar la implantación de politicas de doble contabilidad es necesario que las maquinas ModularIT instaladas en una misma infraestructura sean capaces de detectarse mutuamente para notificarlo al sistema de gestion y poder comprobar si las maquinas "que se ven" son las que deberian estar instaladas. Esto nos permitiria detectar maquinas que se han instalado pero no se han añadido al sistema de gestion centralizada.

Para implementar un servicio de este tipo, se pueden configurar anuncios de servicios especificos de ModularIT con avahi (www.avahi.org).

Las maquinas verian los anuncios de las otras maquinas de la misma red local, y el "controlador" podria notificar a la infraestructura de gestion las maquinas que ve.

Ademas de los simples anuncios, las maquinas podrian hacerse consultas por Webservices para obtener el estado de los servicios y conocer si el servicio esta correctamente configurado. P.ej. podriamos detectar que hay un servidor de correo, pero que no esta correctamente configurado porque el dominio de correo no esta correctamente definido.

Sistema notificacion de eventos

Cada servicio ModularIT puede generar eventos que requieren notificacion a los usuarios, por ejemplo, una llamada entrante de un cliente, la recepcion de un Fax, un aviso de rotación de un disco de backup, etc. Actualmente la mayoria de estos eventos se notifican por correo electronico.

Para mejorar el nivel de integracion y la calidad de los servicios es fundamental contar con un sistema que nos permita unificar todas las notificaciones generadas por los servicios ModularIT dentro de la infraestuctura de un clientes, y permitir que los usuarios accedan a esta informacion mediante diferentes mecanismos, en funcion de las preferencias y situacion del usuario.

El sistema de notificacion de eventos de ModularIT debe contar con un componente cliente en cada maquina de servicio. Todos los eventos generados por el servicio, se le pasaran a este cliente, que enviara todos los eventos a la maquina "controladora". Esta "maquina controladora" almacenara todas las notificaciones de eventos recibidos, y los publicara en todos los servicios de notificacion registrados. De esta forma un usuario podra recibir la notificacion por email otro a traves de una notificacion Jabber y otro leerlo en un agregador RSS. De esta forma tambien se puede publicar las notificaciones en la intranet de ModularIT mediante un cliente RSS.

Los servicios de notificacion que se deben soportar son:

  • Syslog: Enviar el evento al syslog del equipo, tanto en el controlados como en el cliente
  • Jabber: Enviar las notificacionea a una sala de chat Jabber. De esta forma los usuarios se conectan a esa sala de chat y reciben las noitificaciones de eventos
  • Email: Enviar las notificaciones por email
  • RSS: Generar un feed RSS con las notificaciones. Los usuarios pueden consultarlas con cualquier cliente RSS y podemos publicarlas en la Intranet a traves de RSS
  • Alerta al entorno de monitorizacion: Generar una alerta al sistema de monitorizacion

Controladores de servicios

Para mejorar la integracion entre servicios y permitir la comunicacion entre maquinas de servicios ModularIT, cada maquina de servicio dispondra de un software de control que aceptara comandos REST o SOAP y cuya funcionalidad dependera del servicio en cuestion.

Este controlador debera soportar una seria de operaciones generales como:

  • Identificacion: Indicar el tipo de maquina (servicio) y la version
  • Configuracion: Volcado de las variables de configuracion ModularIT
  • Iniciar proceso configuracion: Forzar el inicio de la configuracion con Puppet
  • Operaciones especificas de cada servicio: Listar los comandos soportados por el controlador

Interfaz de gestion

Los servicios ModularIT estan basados en paquetes de software libre estandar y, por tanto, utilizan el interfaz propio de cada servicio. No obstante, para las opciones de configuracion y las operaciones mas basicas y habituales puede ser necesario desarrollar un interfaz de gestion sencillo que permita a los usuarios y prestadores de servicio realizar las operaciones de forma mas sencilla.

Este interfaz deberia enfocarse unicamente en las operaciones mas habituales y sobre todo en aquellas que se pueden realizar mediante llamadas a los webservices de los procesos controladores de servicio definidos en la seccion anterior.

Fomentar la figura del experto del servicio

La configuracion base de cada servicio ModularIT no pretende implementar todas las funcionalidades de cada servicio, ya que para eso ya esta el proyecto del sofware original utilizado en dicho servicio (Asterisk, Hylafax, Alfresco, etc)

La idea de ModularIT es identificar los servicios basicos de las empresas y que cada servicio ofrezca una configuracion base que cubra al maximo esas necesidades. Si un cliente concreto necesita funcionalidades que van mas alla de la configuracion basica, habria que adaptarle el servicio a sus necesidades.

Con esta idea, es necesario fomentar la figura de los expertos de servicios que son aquellos prestadores de servicio que son expertos en un servicio ModularIT determinado. La tarea de estos expertos es definir cual es la configuracion basica que se entregara en el servicio ModularIT y servir como personal de soporte para los posibles problemas que puedan surgir dentro del ciclo de desarrollo y mantenimiento del servicio.

Además, este planteamiento fomenta la cooperacion entre empresas y el modelo de negocio de colaboracion, ya que cuando un prestador de servicio que usa ModularIT se encuentra con un cliente que require una configuracion de servicio especifica no contemplada en la configuracion basica, puede apuyarse y derivar ese trabajo a alguno de los prestadores de servicio expertos en ese servicio concreto.

Inventario

Uno de los puntos fundamentales en los que se necesita trabajar es en el desarrollo de un sistema de inventario de maquinas, servicios y aplicaciones que cumpla con el enfoque de la doble contabilidad.

La doble contabilidad aplicada al inventario consiste en tener, por un lado, una relacion de todas las maquinas y servicios y, por otro lado, obtener de forma dinamica informacion de las maquinas instaladas y los dispositivos detectados, de forma que el sistema pueda cotejar la informacion y generar alertas en caso de detectar un inconsistencia: una maquina con menos memoria de la que deberia, una maquina detectada que no aparece en el inventario, etc.

Un sistema de inventario de estas caracteristicas deberia estar formado por los siguientes componentes.

Aplicacion de Inventario

Para la aplicacion de inventario podemos desarrollar una aplicacion especifica o utilizar alguno de los proyectos libres de inventario que ya existen, como el OCS Inventory (www.ocsinventory-ng.org)

La informacion contenida en el inventario es la que deberia utilizarse para alimentar el sistema de gestion (Puppet) y el de monitorizacion (Nagios, a traves de los recursos generados por Puppet)

Servicio de obtencion de datos de inventario

Cada maquina ModularIT se encargara de obtener sus datos inventariables y de enviarlos al sistema de inventario central.

Para esta tarea se puede utilizar el sistema Facter de Puppet para generar "facts" para cada recurso inventariable y realizar el envio de toda esta informacion a traves del sistema de informes de Puppet.

En el servidor Puppet sera necesario desarrollar un procesador de informes que extraiga toda esta informacion y la traslade a la aplicacion de inventario.

Dentro de la aplicacion de inventario necesitamos desarrollar un modulo que compare la informacion "oficial" con la que se ha obtendo de forma dinamica para generar avisos en caso de una inconsistencia. Si se detectan inconsistencias, el operador deberia tener la opcion de aceptar la informacion obtenida y pasarla al inventario.

Algunos de los datos a inventariar son:

  • Tipo y version de maquina ModularIT
  • Memoria RAM
  • Discos
  • Interfaces de Red
  • En maquinas fisicas:
    • Tipo de servidor
    • Informacion de hardware (Placas, etc)
      • lshw
      • IPMI si lo soporta
    • Service Tag (lshw)

Agente de detecccion de dispositivos

Al menos una de las maquinas de cada infraestructura de cliente deberia encargarse de obtener informacion y de tratar de detectar los otra maquinas y dispositivos de la red y enviarlo al sistema de inventario. De esta forma podriamos detectar maquinas ModularIT que no estan enviando correctamente su informacion de inventario, y dispositivos y maquinas no ModularIT

Para esta tarea, aparte de los anuncios de servicios ModularIT ya comentados, se pueden usar mecanismos activos de deteccion como escaneos de red con NMAP y mecanismos pasivos como la escucha de anuncios y de consultas ARO (arpwatch)

Agentes especificos

Para aumentar la informacion que podemos obtener de maquinas no ModularIT se pueden utilizar agentas adicionales opcionales. Para esta tarea se pueden utilizar los agentes de proyectos de inventario existentes como el OCS Inventory mencionado anteriormente.

Gestion y Monitorizacion distribuida

Actualmente la arquitectura ModularIT permite monitorizacion distribuida, es decir que se puede tener una consola de monitorizacion con los servicios de una intraestructura de cliente, y que este sistema reenvie la informacion al sistema de monitorizacion central.

Sin embargo, el sistema de distribucion de configuraciones es centralizado, lo que puede provocar mucha carga al servidor de configuraciones Puppet en instalaciones con muchos servidores.

Una de las lineas de trabajo que se desean seguir es adaptar el sistema de gestion de forma que tambien permita disponer de un servidor de configuraciones Puppet en cada infraestructura de cliente y que este obtenga la configuracion desde el servidor central.

Para conseguir este objetivo se puede utilizar un sistema de gestion de versiones distribuido como git para que los servidores Puppet subordinados se descargen el repositorio de objetos Puppet y las definiciones aplicables a su infraestructuras. Esta descarga de configuraciones deberia gestionarse internamente desde el propio puppet.

Utilidades de gestion de maquinas virtuales (vmtools)

Uno de los componentes de la arquitectura ModularIT que mas trabajo necesitan para completar la funcionalidad son las utilidades de gestion de maquinas virtuales vmtools.

Existen varios proyectos libres de herramientas de gestion de maquinas virtuales, pero al estar destinadas a una utilizacion "generica" de la virtualizacion la mayoria son demasiado complejas para las necesidades de ModularIT, en la que las funcionalidades de las maquinas virtuales estan perfectamente definidas.

Esto no quiere decir que en ModularIT pretendamos desarrollar un nuevo conjunto de herramientas independientes. La idea de vmtools es mas bien analizar que utilidades podemos reutilizar y hacer un wrapper que simplifique la utilizacion de estas herramientas, ocultando las opciones que no se utilizan en ModularIT.

Concretamente, y con la adopcion de KVM y abandono de Xen por parte de RedHat, la tendencia de ModularIT sera adoptar las utilidades de libvirt (virt-install, virt-image, etc) para la creacion/gestion de maquinas virtuales.

Servicios sin infraestructura propia

Una de las acciones que mas impacto inmediato pueden tener en el tejido empresarial canario en el que gran parte de las empresas son micro PyMEs sin la capacidad de implantar un sistema de servicios TIC con infraestructura propia, es la prestacion de estos servicios de forma remota.

En este sentido, en ModularIT pretendemos iniciar acciones en dos frentes.

Prestacion de servicios en remoto

Los servicios disponibles actualmente en ModularIT, concretamente los relativos a clientes ligeros, permiten con pequeñas modificaciones, la prestacion de servicios a clientes remotos a través de Internet.

Con este servicio las micro PyME que no deseen invertir en infraestructura propia podrian acceder a los servicios remotos ofrecidos por los prestadores de servicios que adopten ModularIT.

En este caso, los clientes pueden acceder a los servicios utilizando un terminal ligero de bajo coste, no es necesario disponer de un ordenador propio, lo que baja sensiblemente el coste de equipamiento, y sobre todo, los costes de mantenimiento, ya que estos terminales son menos sensibles a averias (no tienen partes moviles) y a problemas de software como errores de usuario y virus, ya que no utilizan un sistema propio, sino que todas las acciones se realizan en el servidor gestionado por ModularIT.

Puesto que tecnicamente esta opcion ya es posible con los servicios actuales, las tareas en este sentido estaran enfocadas en asegurar la privacidad y seguridad de los datos de los clientes, y de la adecuacion a los requisitos tecnicos impuestos por la LOPD.

Concretamente, las acciones a desarrollar son:

  • Añadir soporte NX al servidor de terminales
  • Añadir soporte de arranque de clientes ligeros en local (CompactFlash, Memoria USB o similar) con soporte de conexiones NX
  • Restriccion del escritorio remoto de los usuarios para garantizar la seguridad del sistema
  • Soporte de cifrado de datos de los usuario
  • Configuracion de seguridad que permita a los usuarios intrercambiar datos unicamente con otros usuarios del mismo cliente, pero los aisle del resto de los clientes.
  • Realizacion de los backups de cada usuario con diferentes claves de cifrado
  • Garantizar que los clientes solo pueden acceder a sus backups

Despliegue de servicios a plataformas de Cloud Computing

Uno de los conceptos que mas popular se esta haciendo ultimamente es el de "Cloud Computing" que consiste en ofrecer servicios de computación deslocalizados, es decir, se utilizan los servicios de computacion sin necesidad de conocer donde estan situados dichos servicios.

Algunas de las plataformas que ofrecen servicios de Cloud Computing, como el EC2 de Amazon, se estan haciendo muy populares debido a su robistez, facilidad de uso y bajo coste.

Teniendo en cuenta esta tendencia, otra opcion para las empresas que no puedan o no quieran invertir en una infraestructura propia, consiste en la implantacion de los servicios necesarios en una de estas plataformas de cloud computing y pagar por los recursos utilizados.

En este sentido, uno de los principales objetivos de ModularIT a medio plazo es adaptar la arquitectura de forma que nos permita instalar las maquinas virtuales de servicio directamente a estas plataformas de Cloud Computing, principalmente la EC2 de Amazon, y su alternativa libre Eucalyptus (http://eucalyptus.cs.ucsb.edu) de UC Santa Barbara.

Componentes del proyecto

  • Base de virtualizacion
    • CentOS
    • Xen/KVM
    • CD de instalacion desatendida
  • Repositorio RPM
    • Lista de repos YUM "oficiales" que usa ModularIT
    • Repo adicional solo para paquetes que no esten en ningun repo de los que usamos
      • Solo como ultimo recurso, la primera opcion sera siempre enviar estos paquetes a repos oficiales como EPEL, CentOS extras, etc
      • Solo mantendremos paquetes que no acepten en estos repos o que esten en proceso y necesitemos ya
  • vmtools
    • Herramientas de gestion simplificada de maquinas virtuales
    • Desarrollarlas como paquete RPM y/o gema ruby
    • Hay que adaptarlas para imagenes de discos (KVM)
    • Utilidades que deberiamos desarrollar
      • vmcreate: Crear una VM
        • Añadir opciones para varios volumenes LVM
        • Soporte de config de red debian
      • vmclean/vmpack: Limpia la imagen de datos privados y la empaqueta para distribuir en ModularIT
      • vmrename: Renombrar una VM?
      • vmbootstrap: Generar una imagen de maquina basica a partir del mecanismo original de instalacion (centos=yum, debian=debootstrap). Esta imagen base es la que se asumira como origen en el resto de maquinas de servicio
      • vmmigrate: Migrar una VM a otro hierro
        • En caliente: Si disponemos de almacenamiento compartido hacer el migrate de Xen/KVM
        • En "frio":
          • Copiamos el fichero de config si no existe en el destino. Si ya existe lo dejamos como esta porque puede interesar conservar el nombre de los volumenes y/o la MAC
          • Vemos que volumenes usa la maquina en el fichero de config y hacemos snapshot y rsync al destino de cada uno de ellos
          • Hacemos un "save" de la maquina y copiamos el fichero generado al destino. A partir de este momento la maquina esta parada, no hay servicio
          • Hacemos un ultimo rsync de los volumenes
          • Arrancamos la VM en destino. El tiempo de parada sera el que se tarde en copiar el fichero del save y el ultimo rsync de los volumenes.
      • vmlist/vmget: Listar las VM y versiones disponibles en el repo y descargar el servicio/version indicado
      • vmupdate: Actualizar una maquina virtual determinada a la ultima version de la imagen. Basicamente debera descargarla, desempaquetar, copiar los datos de la VM de produccion, parar la de produccion y arrancar la nueva
      • vmkernelupgrade: Actualizar el kernel en una VM. Basicamente es cambiar el kernel en el fichero de config y copiar el /lib/modules/(uname -r) a la imagen de la VM
  • Repo de maquinas virtuales
    • Definir los requisitos basicos de las maquinas
  • Repo GIT de objetos de gestion Puppet
    • Definiciones Puppet
      • Las definiciones deberian ser capaces de generar una maquina de servicio completa a partir de la base generada por vmbootstrap, con lo que seria equivalenye instalar la base y ejecutar puppet para LDAP que instalar directamente la imagen de la VM ldap, aunque mas lento. De esta forma se facilita enormemente el desarrollo de VM de servicio
  • Alertas PIFIA: Migrar a Ruby, usar algo integrado con Puppet o god
  • Redmine: Herramienta de comunidad para coordinar y documentar el desarollo