Estás leyendo:
Informática

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Lo leyeron y comentaron

Top Clicks

  • None

Flickr Photos







More Photos
%d bloggers like this: