jueves, 27 de agosto de 2009

Backup and Recovery (1era entrega)


Estimad@s,

En esta oportunidad vamos a estar conversando un poco sobre temas asociados a procesos de respaldo o backups, en este sentido existen muchas opciones en el mercado, sea software propietario como NetWorker de EMC, IBM Tivoli Storage Manager, NetBackup de Symantec, Backup Exec o, incluso software de fuente abierta para respaldar los datos, en muchas oportunidades vamos a enfrentar problemas para escoger la mejor opcion para proteger nuestros ambientes. Esta serie de posts tendran como objeto compartir algunas recomendaciones para seleccionar la mejor alternativa y brindar algunos tips que nos pueden ayudar con el tema del performance.

Y como mi compromiso con el tema del software libre no es en juego en este primer post de la serie empezaremos hablando del mundo Linux, espero que le saquen provecho.

Los productos de backup en Linux están añadiendo nuevas capacidades. Hoy la mayoría de los principales proveedores de software de gestión de almacenamiento, tales como Hewlett-Packard (HP) Co. y Symantec Corp. disponen de versiones para Linux de sus herramientas. En algunos software de copia de seguridad de datos de Linux, los fabricantes están ofreciendo la posibilidad de realizar backups a la nube (cloud backups), manejar sistemas virtualizados y deduplicar datos. Es evidente que hoy en dia hay más opciones y capacidades más sofisticadas para los usuarios que buscan una copia de seguridad de sus sistemas Linux.

Dado que realizar copias de seguridad tipo cloud backups son cada vez más populares, los vendedores de software para Linux, tales como Zmanda están agregando facilidades de cloud backups a sus repertorios. En el caso de Zmanda, su Zmanda Enterprise Backup permite realizar copias de seguridad a Amazon S3 (Simple Storage Service) un servicio de cloud backups para dispositivos Linux.

Del mismo modo, los productos de backup o respaldo para Linux ofrecen soporte para máquinas virtuales. Y es que aunque los sistemas virtualizados pueden respaldarse usando casi cualquier sistema de copia de seguridad (incluidos shell scripts), existen funciones especializadas de los sistemas virtualizados que responden mejor a software diseñado para la copia de seguridad virtualizadas.

Por ejemplo, Symantec Veritas NetBackup permite a los administradores tomar un snapshot de un único servidor físico y capturar a todos los servidores virtualizados ejecutandose en él, en lugar de tener que tomar snapshots individuales de cada uno de los servidores virtuales.

Normalmente los productos de copia de seguridad para ambientes virtualizados Linux pueden restaurar casi cualquier cosa, desde archivos individuales en una aplicación virtualizada a un bare-metal completo para restaurar un servidor Linux, físico o virtual. También es posible clonar una instancia existente de un servidor virtual para crear otro servidor virtual. Esto es útil para hacer una restauración rápida, especialmente en el caso de un fallo de hardware donde necesitamos obtener una instancia de servidor en funcionamiento rápidamente.

Soporte para Cluster también es cada vez más común en los productos de copia de seguridad de Linux, tales como NetVault: Backup de BakBone Software. Este incluye la capacidad para administrar clusters como una sola unidad en una sola pantalla en la consola para backups y gestión de almacenamiento. Este punto habia sido una limitante clasica en los productos de backups para Linux.

NetVault es ejemplo de otra tendencia en el software de backup de Linux. Ofrece protección continua de datos (CDP) a través de una característica llamada NetVault: Replicator que replica los cambios a nivel de bytes a través de una LAN o WAN.

Deduplicación de datos también ha llegado al mundo de los backups en Linux a través de empresas como de Data Domain que proporcionan deduplicación como parte de sus funcionalidades. Por supuesto, como cualquier otra característica de gestión de almacenamiento, los proveedores varían en la calidad del soporte para backups en Linux. En la elección de un producto de backup, es importante probar las soluciones para asegurarnos de que el candidato puede satisfacer nuestras necesidades y no sólo limitarnos a llenar con checkmarks una lista de características.

Sin embargo, si estamos buscando opciones para un backup basico, hay un montón de productos Linux disponibles. Algunos de ellos son simples shell scripts que se basan en las utilidades de Linux tales como tar para manejar los backups. Otros son más sofisticados como Bacula, que ofrecen características adicionales. Por ejemplo, Bacula que es una solucion open source, ahora ofrece virtual backups y emulación de cintas, en su versión 3.0.

Este post esta basado en un articulo de Rick Cook y ha sido mal llevado al castellano por este servidor. En las proximas entregas estaremos conversando un poco sobre
NetWorker, TSM y Netbackup, soluciones de backup que dominan el mercado.

Sobre el autor: Rick Cook se especializa en escribir sobre temas relacionados con almacenamiento y la gestión de almacenamiento.


Mis respetos,
White Shark

jueves, 20 de agosto de 2009

Disaster Recovery para Virtual Machines (2da parte)


Estimad@s,

En esta segunda entrega de los posts dedicados al tema de DR para virtual machines estaremos conversando de mecanismos alternos a la automatizacion a traves de VMware SRM para automatizar el failover de nuestras VMs.

Geoclustering para Disaster Recovery

Existen productos disponibles para hacer geoclustering que proporcionan una sofisticado esquema de DR cross-site. De hecho, geoclustering soporta failover y failback en forma automatica de múltiples sitios y datos en modo raw-device, y no exige un Virtual Center activo.

Symantec Veritas
Cluster Services (VCS) permite failover en esquemas servidor físico a VM, VM a servidor físico, y VM a VM.

Por ejemplo, VCS podria hacer failover de un servidor físico en el site protegido a una máquina virtual en el site remoto, o vice-versa. Estas capacidades van mucho más allá de lo VMware SRM soporta pero en función de las necesidades del centro de datos, puede ser digno de consideración.

Otra opcion disponible es Windows HPC Server 2008, pero sólo soporta esquemas de failover de servidor fisico a servidor fisico o de máquina virtual a máquina virtual. Una limitante importante es que HPC Server debe estar ejecutandose en el servidor de Windows, tanto en el site local como en el site remoto, y sólo soporta failover de Windows a Windows.

SAN o array replication para VM Disaster Recovery

La mayoria de los esquemas automatizados de DR dependen fuertemente de la replicacion de datos a nivel de la SAN o el arreglo de discos. Con esto en mente, un failover automatizado puede ser implementado desde distintos enfoques fundamentados en la tecnologia disponible a nivel de la SAN o el storage.

Una vez que la replicacion del datastore es realizada, los administradores pueden construir sus propios sets de scripts empleando VMware nativo o cualquir otro software para automatizar el failover de la maquina virtual. Sin embargo estas rutinas deben contemplar todo el trabajo de reconfiguracion de los servers ESX para correr las VMs, reasignar las direcciones IP de las VMs y promover las copias de los datastores replicados.

Data protection software para VM Disaster Recovery

Software de Data protection tales como EMC NetWorker, CommVault Galaxy, IBM Tivoli Storage Manager (TSM) and Symantec BackupExec and NetBackup soportan DR a varios niveles. Dicho soporte puede consistir de simples opciones de restauraciones tipo bare-metal y/o sofisticados esquemas independientes de replicacion de la data respaldada.

Tivoli Storage Manager soporta un administrador de DR que puede ser empleado para replicar de manera automatica la data respaldada a un site remoto. Una vez que la data es recuperada en el site remoto esta puede restaurada y las VMs pueden ser reconfiguradas en forma manual o a traves de scripting.

De manera alternativa, otros software de Data Protection soportan una opcion de restauracion tipo bare-metal. Esta funcionalidad puede proveer una version restaurable de toda la data requerida por un servidor fisico o una VM en un solo paso. Cuando la data ha sido restaurada, el administrador necesita reconfigurar la VM para ejecutarse en el site remoto y realizar la reasignacion de IPs requerida. Posteriormente, la VM puede ser levantada y recuperada desde su backup.

Ademas, cualquier software de backup puede ser usado para recuperar una VM en un site remoto. Sin una opcion de bare-metal, puede tomar mas pasos recuperar toda la data de la VM pero una vez que esto es realizado, el resto del proceso de DR es similar. En conclusion un esquema de DR para VMware puede ser implementado de muchas maneras. Cualquier esquema de failover automatico dependera en gran medida del esquema de replicacion y el software seleccionado.

Por ejemplo, VMware Site Recovery Manager puede automatizar la mayoria de los esquemas de failover de VMs, pero tiene algunas limitaciones ya comentadas en el post previo; software de Geo-clustering provee failover automatico, pero con la excepcion de VCS, esta limitado a un unico sistema operativo; SAN o array replication puede ser empleada sin embargo requiere de un fuerte componente de scripting para automatizar completamente el failover; la mayoria de los software de data protection soportan DR, pero de igual manera requieren scripting para automatizar el failover.

Debido a los costos asociados a la replicacion un esquema de failover automatizado puede estar acotado a unas pocas virtual machines criticas con el resto del universo de VMs relegadas a esquemas menos sofisticados y por que no? Un esquema de DR multi-tier facilmente podria estar conformado por combinaciones de las tecnologias expuestas apuntando a una mayor automatizacion para las virtual machines de mayor criticidad.

Con este post cerramos el tema esperando que les sirva de orientacion a la hora de definir esquemas de DR en entornos de virtualizacion.

Mis respetos,
White Shark

martes, 18 de agosto de 2009

Disaster Recovery para Virtual Machines


Disaster Recovery es un mecanismo para hacer failover de un site primario a una locacion remota y proseguir con la operacion en el site secundario. Existen algunas opciones para facilitar la recuperacion en caso de desastres en un entorno de virtualizacion. VMware introdujo su software Site Recovery Manager que automatiza este failover de maquinas virtuales.

Alternativamente, existen opciones como la agrupación geográfica (geoclustering). También hay paquetes estándar de protección de datos disponibles que apoyan diversos niveles de DR para maquinas virtuales. Si bien estos paquetes son menos automatizados que Site Recovery Manager o geoclustering, tambien es cierto que cuestan mucho menos.

Algunos de los enfoques disponibles en la actualidad son:
  • VMware Site Recovery Manager
  • Geoclustering para maquina virtuales
  • SAN o replicación basada en arreglos de discos
  • Software de Data Protection para maquinas virtuales
En esta primera entrega asociada a los mecanismos para realizar DR de maquinas virtuales estaremos tratando Site Recovery Manager como una primera opcion, en proximas entregas estudiaremos enfoques alternativos.

Site Recovery Manager

Disaster Recovery a traves de SRM depende en gran medida del arreglo de discos o la red de de almacenamiento (SAN) para la replicación de los DataStore entre sitios. El software SRM se ejecuta en un servidor SRM o una máquina virtual en ambos sites, pero también requiere de Virtual Center corriendo en el sitio remoto.

Una vez que SRM se ejecuta, un administrador debe:
  1. Establecer la replicación de DataStores
  2. Identificar los DataStores replicados
  3. Seleccionar las máquinas virtuales protegidas
  4. Remapear el hardware de las maquinas virtuales
  5. Crear un plan de recuperación de datos
Un factor muy importante a tomar en cuenta es la reasignacion de direcciones IP. Las direcciones IP en el site remoto no puede ser las mismas que en el site principal. Algunas están relacionados con la aplicación y el sistema operativo ejecutandose en la máquina virtual, y otras están asociados con las interfaces del Hypervisor de VMware como el servidor que ejecuta vCenter Server, Site Recovery Manager, etc. Dado que las maquinas virtuales son traidas al site secundario las direcciones IP deben ser cambiadas para poder levantar la operacion.

Varios planes de recuperación pueden ser definidos y los administradores pueden seleccionar alguno para un determinado failover. Alternativamente pueden coexistir planes de recuperación que proporcionan diferentes capacidades de tolerancia a fallos y opciones de recuperación parcial, por ejemplo, la falla de un solo DataStore o un host ESX en el site protegido.

Como tal, SRM requiere al menos un manual de procedimiento. Adicionalmente SRM tambien soporta pruebas de DR en el site local y un administrador puede modificar un plan ya existente con el objeto de apoyar estas pruebas.

Uno de los aspectos positivos de Site Recovery Manager es que puedes tener tantos o tan pocos planes de recuperación como necesitas. Es totalmente factible tener un plan de recuperación para una falla total del site y uno o mas para fallas de infraestructura aisladas.

Una duda frecuente es la relacion entre VMware HA y VMware SRM. VMware alta disponibilidad (HA) para ESX ofrece tolerancia a fallos, pero sólo en el site local. SRM interviene cuando se requiere failover a un sitio remoto. No todas las fallas de infraestrutura requieren que un plan de Disster Recovery sea utilizado y es aqui cuando VMware HA hace sentido.

VMware SRM tambien tiene algunas limitaciones, entre ellas podemos identificar:
  • Soporte a data en modo raw-device
  • Soporte a datastores multi LUN
  • Soporte a automatizacion de DR multi-site
  • Automatizados de apoyo y recuperación
VMware puede acceder almacenamiento de canal de fibra en al menos dos formas. La primera forma es a través de un acceso a datos SCSI del hipervisor, estos datos son virtualizados a un sistema de archivos tipo cluster, conocido como VMFS DataStore. La segunda es a través de dispositivos en raw-device, mediante el cual la máquina virtual toma control del puerto del hardware Fibre Channel y controla ese link asi como el almacenamiento adjunto en el otro extremo del enlace.

El no soporte de SRM a dispositivos en modo raw-device se debe a que estos datos son más complejos y menos automatizados. SRM no monitorea la replicacion de estos datos y no los promueve activamente para su accesibilidad desde la maquina virtual del site secundario. Todos estos pasos tienen que ser realizados por los administradores en forma manual o a traves de scripts.

El modo raw-device es normalmente utilizado en máquinas virtuales que requieren rendimiento intensivo. Estas son típicamente aplicaciones de alto perfil, pero precisamente estas son las menos susceptibles a ser virtualizados alojandose generalmente en hosts dedicados. A medida que los centros de datos requieran ser movidos a un esquema 100% virtualizado esto se convertirá en un motivo de preocupación.

About the author: Ray Lucchesi is president of Silverton Consulting, a storage, strategy and systems consulting services company, based in the USA offering products and services to the data storage community.

Este articulo ha sido mal llevado al castellano por mi persona, en las proximas entregas le estaremos dando continuidad a este tema.

Me despido atento a cualquier comentario.

Mis respetos,
White Shark

sábado, 15 de agosto de 2009

OpenSolaris vs Linux (o la respuesta de Jonathan a Linus)


Estimados,

Como parte de la serie de entregas dedicadas al tema OpenSolaris vs Linux me voy a permitir hacerme eco de la respuesta de Jonathan (el CEO de Sun) a Linus Torvalds, el creador de Linux ante un comunicado un tanto incisivo (http://lkml.org/lkml/2007/6/12/232) que este ultimo hiciera algun tiempo atras.

(extraido del blog oficial de Jonathan, mal llevado al castellano por este servidor)

Linus,

En primer lugar, estoy contento con el crédito a Sun por las contribuciones que hemos realizado en el mundo del código abierto y Linux en concreto - el compromiso lo tomamos seriamente. Es la razón por la que se liberó OpenOffice, Gnome, Mozilla, Java, y una larga lista de otras contribuciones que aparecen en casi todas las distribuciones linux. Los individuos siempre definen las comunidades, pero Sun ha hecho su parte para hacer crecer el mercado - tanto para los demás como para nosotros mismos.

Pero no estoy de acuerdo con algunos de sus puntos. ¿La comunidad Linux a herido a Sun? No, ni siquiera un poco. Son las empresas que se apalancan en su trabajo. Quisiera hacer una muy clara distinción - incluso si nuestra competencia es convenientemente temeraria. A ellos les gusta pintar la batalla como Sun versus la comunidad, y no lo es. Las empresas compiten, las comunidades simplemente se decantan por una opcion.

OpenSolaris ha recorrido un largo camino desde la última vez que usted lo miro. Y su comunidad está creciendo, como resultado más alla de ZFS (aunque parece que estamos generando un gran interés aqui, esto no es completamente intencional) - OpenSolaris escala en cualquier hardware, posee virtualización embebida, una gran infraestructura de servicios web, gestión de fallos , diagnosticabilidad, y mucho más. Siéntase libre para probarlo por sí mismo.

...
aqui se desarrolla una amplia argumentacion sobre GPL2 y GPL3
...

(mi parte favorita)

Pero sobre todo, desde mi perspectiva, hay que bajar las espadas - no eres el enemigo para nosotros, no somos el enemigo para usted. La mayor parte del mundo no tiene acceso a Internet - eso es el enemigo a vencer, la brecha que nos separa. Al unirse nuestras comunidades, podemos llevar la transparencia y oportunidad a todo el planeta. Estamos tras sus drivers? No más de lo que ustedes buscan es ZFS o DTrace o Crossbow - no es predación, es prudencia.

Quiero que escuche esto de mí directamente. Queremos trabajar juntos, queremos unir las manos y las comunidades - no tenemos ninguna intención de detener el avance del open source, o pujar por patentes absurdas. Y para demostrar la sinceridad de la oferta, le invito a cenar a mi casa. Voy a cocinar, usted traiga el vino. Un
mashup en el sentido más verdadero.

Asi finaliza esta elegante respuesta ante el incisivo ataque de Linus Torvalds a OpenSolaris. Juzguen uds mismos las posiciones expuestas.


Mis respetos,
White Shark

viernes, 14 de agosto de 2009

Que es OpenSolaris?


Ante las interrogantes de muchos allegados he decidido dedicar unas lineas a aclarar que es OpenSolaris. A continuacion una breve pero concreta definicion extraida de Wikipedia, la enciclopedia libre.

OpenSolaris es un sistema operativo de codigo abierto basado en Solaris, el sistema operativo insignia de Sun Microsystems. Tambien es el nombre del proyecto iniciado por Sun para construir una comunidad de usuarios y desarrolladores en torno a el.

OpenSolaris es derivado del codigo base de Unix System V Release 4, con modificaciones sustanciales realizadas por Sun desde que adquirio los derechos de ese codigo en 1994. Este sistema operativo es el unico derivado de Unix System V basado en codigo abierto disponible en la actualidad. Componentes de codigo abierto son snapshots o imagenes de la ultima version de Solaris bajo desarrollo. Sun ha anunciado que las futuras versiones de Solaris estaran basadas en tecnologias provenientes del proyecto OpenSolaris.

Y ya que entramos en el tema de OpenSolaris, en las proximas entregas estaremos conversando un poco de las ventajas de este sobre otros sistemas operativos de codigo abierto disponibles (entiendase Linux).

Mis respetos,
White Shark

Microsoft y Nokia van contra BlackBerry


El gigante del software introducirá su Office en teléfonos inteligentes de la finlandesa con el fin de atacar el sector de negocios mediante aplicaciones y herramientas para empresarios...

Yo solo me pregunto, donde estaba StarOffice/OpenOffice mientras finlandeses y el pequeno Gates negociaban?

Creo que algo ocupados.

Saludos,
White Shark

Si Bolivar se hubiese ido ...


Hoy, mientras argumentaba con mi padre sobre la imposibilidad de inclusion en el proyecto revolucionario de gente con ideas distintas al proceso me comento lo siguiente:

"Si Bolivar se hubiese ido porque no compartia el proyecto de los espanoles hoy seriamos una colonia"

Y mi padre es de esos revolucionarios que sin haberse beneficiado con un centavo de las mieles del poder sigue pensando en que es un proyecto valido.

Y saben que? tiene razon, seriamos una colonia, la diferencia entre Bolivar y la gente que como yo tiene una vision distinta del proyecto de pais que queremos es que no tenemos ni las armas, ni la motivacion para lanzar una nueva campana admirable. Algunos pensamos en nuestras familias, otros en el sacrificio que hay que hacer; mientras la revolucion habla de batalla de ideas, los heridos y lesionados en cada evento caen de este lado. Algunos prefieren irse, toda opcion es valida mientras sepas asumir las consecuencias. La lucha es desigual, ellos tienen el poder, las armas y el dinero. Que quieres tu? Quieres buscar otros horizontes? buscalos, Quieres pelear? pelea. Lo unico verdaderamente estupido que puedes hacer es dejar tu destino en las manos de alguien mas.

Que has hecho hoy por tu pais?, Que has hecho hoy por tu destino?

Nuevamente la tecnologia y los bytes han quedado de lado.

Mis respetos,
White Shark