Una mínima arquitectura de sistemas para grupos apoyada en la virtualización de escritorios (y II)

Una mínima arquitectura…(Parte I)

El caso real es éste: un director de un grupo de trabajo solicita asesoramiento para la adquisición de un servidor de archivos con espacios de trabajo para el grupo y espacios privados o restringidos, ademas de la conexión con equipos de escritorio ya existentes -los existentes en el grupo-  y otros por adquirir. El uso no será intensivo, pero los sistemas operativos del grupo son esencialmente heterogéneos: desde la familia Windows a las variantes MAC OS. Los equipos trabajan dentro y fuera de la sede, en cuyo caso el acceso es obligatoriamente la VPN corporativa. En todos los casos los clientes poseen una asignación dinámica de la dirección de red. Por último, señalar que se dispone de una infraestructura de almacenamiento corporativa que puede ceder cierta cantidad de espacio altamente securizado (sistemas RAID de doble paridad).

Requisitos funcionales: (RF)

  • EL cliente necesita un servicio de almacenamiento de ficheros interoperable (Windows, Mac, …linux??) que permita a los miembros del equipo acceder a la documentación almacenada, así como poder guardar documentos de uso común o de interés general para el trabajo de equipo.
  • También solicita un terminal de usuario (o varios) capaz de poder acceder a esos recursos compartidos, y simultáneamente poder almacenar la documentación privada, de manera que sea posible la securización posterior mediante copia remota o algún mecanismo de salvaguarda equivalente.
  • La arquitectura deberá contemplar la posiblidad de salvaguarda y archivado de la documentación de los espacios de almacenamiento comunes y del espacio privado.

Requisitos no funcionales: (RNF)

  • La arquitectura propuesta debe ser plenamente accesible desde la red corporativa, pero con niveles de privacidad suficientes.
  • La arquitectura debe ser confiable, tanto en lo referente al hw como al sw de base (el MTBF -Medium Time Between Failures- debe tender al mínimo)
  • Es de desear que la latencia de puesta en marcha ante averías (MTTR -Medium Time To Repair) también sea mínima
  • La solución debe ser escalable
  • La arquitectura debe posibilitar un backup simple, al igual que el posterior proceso de archivado

Solución propuesta:

  • Adquisición de un servidor dual core -mínimo- con 4GB de memoria RAM y con implementación RAID (preferentemente RAID 5, asumible RAID 0 y posterior resinronizado y/o archivado) sobre el que se instalaría un Sistema operativo de servidor (Ubuntu server 64 + X) -el anfitrión o Host- y un sw de hipervisor (virtualización completa) que servirá de base para la gestión y monitorización de dos máquinas virtuales, una con Windows XP y otra con Ubuntu Desktop (Lucide Lynx) -los invitados o guests-.
  • Configuración de un segmento de red virtual que unira a host y guests con el resto de la red corporativa.
  • Los espacios de almacenamiento se proponen sobre el propio anfitrión: se creará un volumen común sobre el que se almacenará separadamente los archivos privados de las VMs guests, y los archivos de uso compartido entre éstos y el resto de host físicos de los miembros del equipo.
  • Los protocolos de acceso serán CIFS-SMB para los archivos del equipo de trabajo, y los accesos compartidos que Oracle VirtualBox -la solución de virtualización elegida- implementa entre el host y los diferentes guest -carpetas de uso compartido- para los archivos de uso privado.

Los servicios a implementar en el host:

  • Samba (sudo apt-get install samba samba-common smbclient system-config-samba winbind nautilus-share resolvconf)
  • Acceso por terminal remoto: VNC y RDP (Terminal server) (sudo apt-get install vncserver)
  • ssh
  • VirtualBox
  • Interfaces virtuales de red + bridge

La configuración del sistema de archivos: Un espacio compartido (/home/compartidos) sobre el que se crean dos subespacios, pub y private. Se habilita la compartición CIFS -rw- para pub y sólo para los miembros del grupo -vgrupo-, que deberán estar convenientemente registrados como usuarios en el smb.conf -comando smbpasswd -a-. Private debe ser de libre acceso para virtualbox. Destacar que el host SOLO se dedicará al soporte de la infraestructura de virtualización. COn esto se consigue una mayor limpieza en la arquitectura y se facilita la sencillez y comodidad en las tareas de respaldo. Existen por tanto 3 puntos de respaldo, o uno (o dos) sólo si se quiere -si los discos virtuales se crean físicamente dentro de /home/compartidos, lo que va en beneficio de la cohesión pero en detrimento de un respaldo sobre el sistema de almacenamento corporativo, que de momento no puede asumir el backup de los vdis-. Los tres puntos serían:

  • Punto de montaje del disco duro de la VM on Windows XP
  • Punto de montaje del disco duro de la VM con Ubuntu Desktop
  • /home/compartidos

Respaldo (y archivado): Se deja en el aire, con 2 propuestas: Rsync + archivado externo si el espacio se dimensiona por encima de los 25GB. Si no, cabe la posibilidad de almacenamiento sobre RAID-dp creando un export NFS en nuestra cabina de almacenamiento NetApp y montándolo en el anfitrión como /home/compartidos Ventajas e inconvenientes: Ventajas:

  • TCO (Coste Total de la propiedad) muy bajo: un sólo equipo físico proveera los servicios de un servidor de archivos y dos equipos de escritorio.
  • Portabilidad asegurada: las máquinas virtuales no necesitan un sistema operativo en concreto ya que se instalan sobre el hipervisor, que puede correr tanto en Linux como en Windows y Mac (MAC OS 10.4 mínimo).
  • Simplificación de los puntos de respaldo: 3 o sólo 1, con la seguridad de abarcar todo el ámbito de la salvaguarda de los datos.
  • MTBF -Medium Time Between Failures- y MTTR -Medium Time To Repair- que tienden a reducirse: el primero al elegir un sw de base Linux, que minimiza la entrada de malware así como es mucho más inmune al mismo, orientado a sistemas Windows, mucho más comunes. La reanudación de los servicios asociados a las máquinas virtuales tras un deterioro grave de los mismos se reduciría a restaurar un archivo -el disco duro de la máquina virtual-; si lo que ocurre es el deterioro del propio anfitrión, se puede reanudar sobre otro hipervisor instalado sobre cualquer otra máquina física -o virtual-
  • Escalabilidad: ante nuevas necesidades, tales como el acceso de nuevos usuarios o la creación de nuevas máquinas virtuales, la arquitectura es perfectamente escalable, si bien el límite de VMs simultáneas viene dado por el nº de núcleos del procesador (2).

Inconvenientes:

  • Mayor complejidad de la arquitectura: asumible por el Servicio de Informática
  • Mayor complejidad en la configuración del servidor: asumible por el Servicio de Informática
Advertisements

Una mínima arquitectura de sistemas para grupos apoyada en la virtualización de escritorios (I)

Fuente: smallbizlink.monster.comExisten organizaciones en las que una infraestructura básica corporativa de servicios TIC debe dar soporte a pequeños grupos cuyas necesidades no siempre coinciden y que tienden a una autonomía casi plena, requiriendo de la organización los servicios básicos de red, impresión, backup y archivado.

Los dolores de cabeza para elpersonal TIC son evidentes: falta de homogeneidad en el software de base, tanto a nivel de sistemas operativos como en la selección de los gestores de bases de datos, miriadas de puntos de respaldo, incremento de las situaciones de pérdida de información, aumento de las incidencias de seguridad… realmente una situación compleja.

Sin subir al nivel de programas de aplicación, donde la autonomía provoca la selección – sin criterios técnicos solventes, sino más bien por la utilización del martillo de oro o alguna que otra razón aún más espuria-, la realidad de la infraestructura se aleja de la solución sencilla, en la que el Servicio de informática propone y controla una infraestructura común en la organización.

Es obvio que la organización en grupos con infraestructura autónoma lleva implícita un elevado nivel de conocimientos por parte de los usuarios; o eso o el servicio TIC corporativo se vería obligado a asumir una gran cantidad de tarea e incorporar recursos humanos por encima de lo razonable.

El catálogo de servicios corporativo básico debería asumir de cualquier manera tanto las tareas de mantenimiento, monitorización y respaldo de los servicios de red corporativos -voz y datos-, así como los servicios de backup y respaldo sin olvidar claro está los servicios de atención a usuarios. Otros como la coordinación técnica de proyectos, el descubrimiento tecnológico y la consultoría infomática se sobreentienden aunque, como la gestión de incidencias, queda fuera del objetivo de este post.

El objetivo apunta a una arquitectura de sistemas de reducidas dimensiones, cuyo objetivo debe ser la optimización de los recursos hardware, de la disponibilidad y la reducción de los puntos de respaldo con el fin de clarificar y simplificarlo. Robustez, reducción de vulnerabilidades y ahorro económico son elementos de valor añadido que aderezan las necesidades principales.

la reducción del tiempo de recuperación ante desastres pasa en la actualidad por la utilización de tecnologías de virtualización de equipos: una granja de servidores virtuales respaldados convenientemente permiten un restablecimiento del estado anterior al desastre en tiempos muy por debajo de ls soluciones estándar de respaldo de servidores físicos, y su motivo es obvio -porque se respaldan datos, configuración y estado simultáneamente-. Por tanto, la misma idea es aplicable si se virtualizan los entornos de trabajo de los usuarios.

Una infraestructura Desktop virtualization accesible y asequible es el objetivo final que los Servicios TIC pueden y deben promover como estrategia a medio y largo plazo. Por el camino, podemos comenzar a ofrecerle al usuario soluciones – y he aquí cuando la heterogeneidad se transforma en ventaja- que involucren a los sistemas virtualizados en un entorno cercano, accesible y comprensible cuyo objetivo es el habituarlos a las tecnologías y a los accesos a sus nuevos entornos de trabajo de una manera menos traumática.

¿Qué soluciones? Pues sin el ánimo de reinventar nada,  aquellas que provean al usuario de la funcionalidad que demanda y que simultáneamente  consigan los objetivos no funcionales de la disminución del tiempo de recuperación ante desastres y el aumento de la disponibilidad…sin olvidar la escalabilidad de la solución, por supuesto.

El caso real es éste: un director de un grupo de trabajo solicita asesoramiento para la adquisición de un servidor de archivos con espacios de trabajo para el grupo y espacios privados o restringidos, ademas de la conexión con equipos de escritorio ya existentes -los existentes en el grupo-  y otros por adquirir.

El uso no será intensivo, pero los sistemas operativos del grupo son esencialmente heterogéneos: desde la familia Windows a las variantes MAC OS.

Los equipos trabajan dentro y fuera de la sede, en cuyo caso el acceso es obligatoriamente la VPN corporativa. En todos los casos los clientes poseen una asignación dinámica de la dirección de red.

Por último, señalar que se dispone de una infraestructura de almacenamiento corporativa que puede ceder cierta cantidad de espacio altamente securizado (sistemas RAID de doble paridad).

La solución seleccionada…en el próximo post. Prometo hacerlo en unos días.

Saludos calamares.

Ir a la segunda parte: una mínima arquitectura…(parte II)

¿Se almacena la información independientemente del sistema?



Hola calamares.

Mis amigos-con la web 2.0 podría haber hecho un multienlace a todos ellos…- saben que desde hace tiempo me ronda por la cabeza esta idea. Y es que observo la evolución de los paradigmas de desarrollo del software y la hallo en extremo similar a la evolución del almacenamiento de información en los sistemas vivos -algo que conozco con el criterio de autoridad que me da mi título, pero que en realidad no es tanto como debiera-, o sea, la evolución del material genético en la filogenia.

Y es sorprendente hasta qué punto son parecidos: si asociamos los conceptos de programa/aplicación a los ácidos nucléicos (doble hélice de ADN o ARN), el progreso es paralelo: el cromosoma único bacteriano y la programación estructurada, el núcleo eucariota y la programación modular, o más el paradigma orientado a objetos con el encapsulamiento y el polimorfismo implementado con la presencia de la membrana celular y la funcionalidad alélica.

la evolución hacia la programación orientada a objetos es aún más patente al subir un nivel de funcionalidad -subimos una capa de abstracción en la máquina– y observamos la organización histológica -clases de células- y orgánicas -ensamblados o paquetes-…sin palabras.

En sí, una célula es análoga un objeto de la POO -instancia de una clase genérica o especie– cuya característica primordial es la de mantener un grado de autonomía funcional lo suficientemente importante como para poder ser reutilizado en una estructura dinámica de nivel superior u organismo -aplicación modular donde las haya…-. Almacena información encapsulada -o doblemente encapsulada si es una célula eucariota o nucleada-

Pues bien, barrunto que tamaña semejanza no puede ser fruto de la casualidad. ¿Y si la información, cuando crece, tiende a almacenarse en estructuras similares (homólogas dirían los biólogos, polimórficas los informáticos)? ¿Y si ES NECESARIO que la información se fragmente a partir de una cantidad crítica para poder asegurar la disponibilidad? ¿Y si para asegurar esa disponibilidad se hace imprescindible que esos fragmentos de almacenamiento se rodeen de estructuras y adquieran una funcionalidad mínima? ¿Y si, por último, fuese imprescindible para poder separar la funcionalidad “interna” de la que verdaderamente ofrece, el que se aislen del entorno, se encapsulen?

Contadme vuestras impresiones, que éste es un tema que verdaderamente me apasiona.