Ubuntu: upgrades interrumpidos y recuperación ante desastres

Si algo sabemos a estas alturas es que la interrupción de un proceso de upgrade (cambio de versión del sistema operativo sustituyendo la existente por otra más reciente) es una fatalidad y de las chungas.

Cuando acontece tamaño desastre hay que pensar sólo en una cosa: calma…mucha calma ante todo. Y es que todo puede tener solución, al menos una de compromiso que nos asegure lo más importante: la recuperación de nuestros datos.

Un live CD de cualquier distro de Linux os puede permitir acceder al Filesystem de vuestro disco petado.  A unas malas, montar el disco como slave en otra máquina es una alternativa a contemplar si tenéis el recurso disponible. Un disco externo o el disco maestro de la otra máquina pueden ser el destino de la salvaguarda.

Como leeréis a continuación, el escenario es sobre una máquina activa. La elección de un /home y una máquina funcionando no es incongruente: bien puede ser sobre la que habéis montado el disco como esclavo, o mejor, este planteamiento de inicio os sirve para prevenir o para adelantar trabajo, y además de esta manera controláis dónde y cómo se almacenan. Si no lo veis claro, sustituid /home por la ruta de backup que hayáis decidido.

Como ya sabéis, los sistemas Linux proporcionan un punto único de acceso a la información almacenada en el sistema desde los directorios personales que cuelgan de /home, Otra cosa son los datos almacenados:

las bases de datos mysql se alojan en /var/lib/mysql, los ficheros de configuración implicados son /etc/mysql/my.cnf y /etc/apparmor.d/usr.sbin.mysqld. La idea es ubicarlas dentro de /home y para ello hay que:

  1. Parar el daemon mysqld:
    sudo /etc/init.d/mysql stop
  2. Mover el contenido de /var/lib/mysql a /home/mysql (no estará de más hacer una copia de seguridad):
    sudo cp -rpf /var/lib/mysql /home
     sudo mv /var/lib/mysql /var/lib/mysql.bak
  3. Crear un enlace suave llamado mysql en /var/lib apuntando al nuevo directorio:
    sudo ln -s /home/mysql  /var/lib/mysql 
  4. Cambiar el propietario de /home/mysql con caracter recursivo:
    sudo chown -R mysql:mysql /home/mysql
  5. Editar my.cnf y cambiar el valor de datadir:
    datadir  = /home/mysql
  6. Editar /etc/apparmor.d/usr.sbin.mysqld y añadir  los pertinentes permisos para la nueva ruta:
    /home/mysql/ r,
     /home/mysql/** rwk,
  7. Restablecer apparmor:
    sudo /etc/init.d/apparmor restart
  8. Restablecer el servicio mysql:
    sudo /etc/init.d/mysql start

Ahora tenemos todos los datos colgando de un directorio que controlamos: puede ser nuestro directorio personal o si nos movemos en entornos corporativos, unidades de red NAS o cualquier tipo de sistema de archivos remoto con el que podamos comunicar a nuestro servidor. El procedimiento sería el mismo.

Ahora tenéis casi todo lo que importa dentro de una ruta que controláis y que podéis copiar para luego sustituir una vez machacado el viejo filesystem por la nueva re-instalación, en caso de que la cosa no tenga remedio.  Si tenéis webservers sobre apache con instalación estándar,  hablamos otro día de cómo proceder 😉

Poco más. Espero que podáis utilizarlo con éxito en caso de desastre. Saludos calamares

Advertisements

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

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)