El mantenimiento de un sistema informático es un asunto que siempre ha traído de cabeza a los servicios de informática. El conjugar las necesidades de los usuarios finales que requieren software actualizado y cambiante con las posibilidades del personal dedicado al mantenimiento, es una tarea compleja. Si a esto unimos la variabilidad de los equipos, la dispersión de estos, la ausencia de horas previstas para el mantenimiento, la obsolescencia de los equipos, las actualizaciones de software y la necesidad de resolver los problemas de funcionamiento de una forma ágil y centralizada, la verdad es que el “puzle” se complica enormemente. Afortunadamente existen varias alternativas para diseñar un sistema que elimine algunos de los inconvenientes anteriores. Si bien ninguna alternativa es perfecta, algunas son mejores que otras y sus ventajas superan ampliamente a sus inconvenientes.
Cuando se realiza un estudio de diseño para la implantación del sistema, las alternativas son tantas como empresas existen. No hay nada que pueda ser considerado estándar y es común que los técnicos usen las herramientas más adecuadas de unas y otras posibilidades adaptándolas a su entorno y necesidades. Unas veces se usan herramientas propietarias y otras de Software libre. Aún así existen unas directrices básicas que se repiten de forma más o menos universal.
El diseño más sencillo de concebir y más cercano al usuario sería un equipo autónomo con sistema operativo local. Este no varía demasiado del que el usuario puede tener en su casa y la forma de trabajo con el equipo recién instalado puede parecerle amigable. Lamentablemente esta alternativa es la que más problemas aglutina desde el punto de vista de su gestión y mantenimiento. Los problemas son:
- Requiere un trabajo enorme para cada equipo en su instalación. Necesita unos recursos humanos desorbitados.
- No permite la actualización de los equipos de una forma rápida ni centralizada.
- No permite casi ningún control sobre el uso de los equipos.
- Los equipos están expuestos al uso malintencionado o inconsciente de los usuarios lo cual puede hacer que dejen de ser operativos.
- A la larga este sistema consigue que los equipos más nuevos tengan una configuración y los mas antiguos otra, confundiendo al usuario y al propio personal de informática.
Existe la posibilidad de mejorar el diseño anterior añadiendo los equipos autónomos con replicación de discos. La instalación no se produce manualmente sino mediante herramientas de replicación de discos como Ghost, Imagedrive, System Imager, etc. Eliminada la necesidad de que el personal de informática introduzca uno tras otro decenas de Cd para instalar software, aparecen de nuevo multitud de problemas:
- La replicación es un proceso largo que consume mucho ancho de banda de la red y que normalmente no puede realizarse en horario laboral al coincidir este con el horario de uso del equipo.
- Los equipos siguen estando expuestos al mal uso por parte de los usuarios. Si el mal uso desencadena en que el equipo no funcione bien, la única solución es volver a replicarlo completo, normalmente esto es más rápido que intentar averiguar el problema.
- Las actualizaciones de software implican una nueva replicación.
Mejoraríamos el diseño si permitimos equipos autónomos con software a través de la red. En este modelo los equipos ejecutan uno o varios sistemas operativos localmente. El sistema operativo está también instalado localmente pero las aplicaciones se encuentran en unidades de red. Es habitual que los sistemas operativos locales se repliquen como en el caso anterior. Los problemas que aparecen son:
- No todas las aplicaciones permiten su ejecución desde unidades de red.
- Seguimos teniendo el mismo problema de replicación de equipos y mal uso. En este caso el problema se limita a lo instalado localmente. Por tanto hemos evitado el problema cuantitativa pero no cualitativamente.
Si los equipos no ejecutasen las aplicaciones localmente, tan solo ejecutasen un cliente de conexión a un servidor de aplicaciones (terminal de aplicaciones) sería la panacea del administrador del sistema. Los servidores suelen estar bien protegidos contra usos malintencionados y bajo la exclusiva supervisión del personal de sistemas. Existe un control absoluto sobre lo que pasa en cada uno de los equipos ya que realmente en ellos no pasa nada, todo pasa en los servidores que estos usan. A este tipo de terminales evolucionados de los primeros terminales “tontos” se les denomina clientes ligeros o THINCLIENTS. Pese a ello, seguimos manteniendo algunos problemas:
- Algunas aplicaciones no son adecuadas para su uso en un entorno de terminal. Las aplicaciones multimedia o las que “devoran” recursos de los servidores son de este tipo.
- Las tendencias de programación actuales no facilitan el trabajo en estos entornos. Los fabricantes de software desarrollan aplicaciones que sacrifican la agilidad por la vistosidad. Tecnologías como java, flash, etc. son auténticas devoradoras de recursos para al fin y al cabo hacer lo mismo que se podía haber hecho con otras herramientas de una forma mucho más óptima.
- Los entornos de terminal son muy dependientes de la infraestructura informática. Si la red no funciona o si los servidores no son adecuados, el sistema se viene abajo.
A la vista de todo lo anterior, resulta evidente que el menos malo de los sistemas será el que incorpore lo mejor de cada uno de ellos, un sistema mixto. Las claves para el diseño son las siguientes:
- Si mantener uno o varios sistemas operativos en los discos es un problema, no lo hagamos. Es más, incluso quitemos el disco.
- Si el mantenimiento de aplicaciones en unidades de red es posible y sencillo, hagámoslo para todas las que lo permitan.
- Si la replicación de imágenes de disco para que el equipo arranque no es posible dentro del horario del personal, hagamos una imagen lo suficientemente pequeña para que se pueda cargar con cada arranque del equipo de forma rápida.
- Si determinadas aplicaciones colapsan los servidores de aplicaciones, ejecutemos estas localmente en los equipos.
- Si necesitamos mantener una estructura homogénea donde todos los equipos de todas las oficinas funcionan del mismo modo, usemos un sistema centralizado de configuración de los equipos.
- Si nuestros equipos tienen recursos locales que podemos aprovechar, hagámoslo. Esto es, usemos el disco si lo tienen para labores que agilicen el trabajo sin introducir dependencias del mismo (si se tiene disco se usa, si no se tiene no, si el disco falla el equipo debe seguir funcionando). Lo mismo pasa con la CPU y la memoria del equipo, aprovechémosla pero no hagamos que nuestro sistema dependa de su “calidad” en exceso.
Si aplicamos las premisas anteriores pasaríamos de tener un cliente ligero (THINCLIENT) a un cliente “inteligente” (THINKCLIENT). El problema que surge es si esto existe o bien tenemos que crearlo nosotros mismos. La respuesta a lo anterior es “casi”. Existen thinclients que aparte de incluir clientes de conexión a servidores de aplicaciones, permiten la ejecución local de ciertas aplicaciones, normalmente navegadores web. Estos equipos están basados en un firmware local y suelen ser caros. Existen otros sistemas basados en equipos normales de consumo que los convierten en thinclients cambiando el firmware por una imagen de arranque que se descarga de la red. Evidentemente son mucho más baratos. Pero si no nos queremos conformar con la ejecución de unas pocas aplicaciones locales, no nos queda más remedio que fabricarnos nuestro propio sistema. Esto es lo que hemos realizado en SANCTI PETRI SYSTEM. Usamos un sistema de software libre, el cual hemos ampliado para dotarle de más funcionalidades locales.
SANCTI PETRI SYSTEM
Una de las virtudes de SPS es que es ligero. Inicialmente esto viene motivado por la necesidad de ocupar poco espacio en la imagen de arranque, usar poca memoria y ejecutarse en cpus que ya estén casi obsoletas. Pero cuando se usa SPS en equipos modernos todo esto se traduce en un efecto secundario: su extrema rapidez. SPS es rápido porque prescinde de multitud de servicios y componente innecesarios.
Los componentes básicos de SPS son los siguientes:
- Servidor de arranque: Normalmente un servidor DHCP y TFTP que puede ser tanto Linux como Windows. Se permite arrancar también de instalaciones locales en el disco duro, Live CDs, Pen drives o cualquier otro disco de estado sólido.
- Imagen de arranque: Contiene un kernel de Linux y una imagen initrd empaquetadas en un paquete NBI para su arranque por etherboot o separadas para su arranque por PXE. Existen formas de usar la imagen empaquetada con PXE usando un pequeño cargador previo. El tamaño de la imagen es la clave de sancti petri system. Su tamaño oscila de 8Mb a 16Mb.
- Paquetes: SPS tiene un diseño modular. Quitando el kernel, el resto de la imagen initrd es un puzle compuesto por muchas piezas llamadas paquetes. Existe por ejemplo un paquete para cada adaptador de red, otro para cada adaptador gráfico, otro para cada cliente de conexión, etc. Existen varias categorías:
- Clientes de conexión: Citrix ICA, MS Windows terminal services (RDP), Tarantella, X,telnet, tn5250, VMS term, SSH, NX, etc.
- Clientes de red: Cliente smb, cliente nfs.
- Clientes locales: Firefox, Sylpheed, Dillo, E3, Mplayer, Blackbox, X3PDF, etc. Son los que aportan la inteligencia a nuestro equipo, permitiéndonos que aparte de establecer conexiones de terminal con nuestros servidores, ejecutemos localmente clientes “pesados” en el propio terminal.
- Ficheros de configuración: Almacenan variables con las que se toman todas las decisiones sobre cómo arrancan los terminales, como se configuran, que sesiones presentan, etc Son muchos los ficheros de configuración que SPS permite tener, desde ficheros especiíficos para cada equipo o ficheros generales para todos los equipos (MLD.GLOBAL); pero realmente son tres los fundamentales:
- MLD.PERFIL: Este fichero alberga la definición de todos los terminales de nuestra red con información sobre su nombre, dirección MAC y grupos a los que pertenece.
- MLD-XXX: Donde XXX es el nombre de cada grupo. Son los ficheros de configuración que cada equipo usa en función del grupo o grupos a los que pertenece. Dentro de ellos definimos todas las opciones de configuración de los terminales de dicho grupo.
- MLD-YYY: Donde YYY es el nombre de cada equipo. Son los ficheros de configuración exclusivo de cada equipo.
FUENTE: Servicios informáticos de la universidad de Córdoba. (Juan Antonio Marín Beltrán y Luis Meléndez Aganzo)