Archive | iSCSI

QUADSTOR en Beta

Tags: , , , , ,

QUADSTOR en Beta

Posted on 10 octubre 2011 by Angel Ferrás Rodríguez

Se ha creado el proyecto QUADSTOR como solución  que proporciona almacenamiento virtualizado. Con base en FreeBSD, añade una interfaz gráfica  web para la administración sencilla de almacenamiento. Está basado en el proyecto IET portado por ellos mismos a FreeBSD, permite c

rear lunes (VDISKs) y ofrecerlas por fibra o iSCSI con características propias de almacenamiento enterprise actual: deduplicación, thin provisioning, soporte VAAI (vStorage APIs for Array Integration) para VSphere 5, además de proporcionar CIFS y NFS.

El proyecto se encuentra en la actualidad en fase beta y se puede usar en universidad y empresa libremente, pero … ni se puede distribuir, ni realizar ingeniería inversa previo a su consentimiento.

About Angel Ferrás Rodríguez

Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas. Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.

Comentarios desactivados

Errores en discos GPT en ESX / ESXi

Tags: , , ,

Errores en discos GPT en ESX / ESXi

Posted on 04 enero 2011 by Angel Ferrás Rodríguez

Hoy me encontré con el siguiente problema en un entorno VSphere 4.1: tenía una LUN iSCSI mapeada directamente a un huésped en una NAS OpenFiler  en modo "RAW Device Mapping" ( RDM ) . Después de eliminar este servidor con la intención de convertir esta lun en un datastore VMFS para los hosts ESX,  cuando intento mapearla a otro host virtual desde el wizard del cliente informa  que es imposible añadirlo como DataStore con el siguiente error:

Error: Call "HostDatastoreSystem.CreateVmfsDatastore"  for object; "datastoreSystem-143" on vCenter Server …… failed.

Haciendo googling   encuentro  la solución en el siguiente blog:

http://vcpgeeks.blogspot.com/2010/03/while-adding-lun-to-esx-error-unable.html

Siendo el causante el mapeo anterior como lun RDM que lo había creado una con tabla de particiones  gpt y no como msdos. Lo muestro en las salidas por consola siguientes:

[root@AGSS03 ~]# fdisk -l

Disk /dev/sdb: 73.4 GB, 73407868928 bytes
255 heads, 63 sectors/track, 8924 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         140     1124518+  83  Linux
/dev/sdb2             141         154      112455   fc  VMware VMKCORE
/dev/sdb3             155        8924    70445025    5  Extended
/dev/sdb5             155        8924    70444993+  fb  VMware VMFS

Disk /dev/sdc: 8392 MB, 8392802304 bytes
255 heads, 63 sectors/track, 1020 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         127     1020096   82  Linux swap / Solaris
/dev/sdc2             128         382     2048287+  83  Linux
/dev/sdc3             383        1020     5124735    5  Extended
/dev/sdc5             383        1020     5124703+  83  Linux

WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdd: 1800.3 GB, 1800324251648 bytes
255 heads, 63 sectors/track, 218876 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      218877  1758129151+  ee  EFI GPT

[root@AGSS03 ~]# parted /dev/sdd
GNU Parted 1.8.1
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print

Model: FSC FibreCAT_SX1 (scsi)
Disk /dev/sdd: 1800GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
1      17.4kB  1800GB  1800GB                     lvm

(parted)

 

Identificado el problema, la solución es  cambiar la tabla de partición de gpt a msdos. En ESX se puede realizar  desde la utilidad parted con el comando mklabel msdos:

[root@AGSS03 ~]# parted /dev/sdd
GNU Parted 1.8.1
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel msdos

Warning: The existing disk label on /dev/sdd will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
New disk label type?  [gpt]? msdos

(parted)

print

Model: FSC FibreCAT_SX1 (scsi)
Disk /dev/sdd: 1800GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End  Size  Type  File system  Flags

 

De esta forma ya es posible añadirlo como DataStore desde el wizard.

Éste procedimiento no servirá para ESXi ya que  no dispone de la utilidad parted. Hay un procedimiento descrito por VMware usando la utilidad dd al final del siguiente artículo:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008886

About Angel Ferrás Rodríguez

Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas. Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.

Comments (1)

SAN de bajo coste

Tags: , , , , , , , , , , , , , , , , , , , , ,

SAN de bajo coste

Posted on 28 julio 2010 by Angel Ferrás Rodríguez

En tiempos de crisis describimos los puntos clave para  diseñar una SAN de bajo coste.

  • iSCSI

iSCSI   es una alternativa a la clásica SAN de fibra óptica, siendo económica su implementación ya  que no requiere de una infraestructura y tecnología adiccional Hardware de costosas HBAs y Switches de Fibra. Con sólo un switch ethernet ( o dos que aporten redundancia de acceso) y  con un servidor con tarjetas Ethernet de Gigabit junto con unos discos ya tendrías una SAN. Los initiators y targets  iSCSI en muchos sistemas vienen con la distribución, al igual que las soluciones de multicamino (multipath).

Existen otras alternativas a iSCSI también basadas en Ethernet como AoE (ATA over Ethernet) que al eliminar una capa de encapsulación de frames (IP) da mayor rendimiento.

  • DISCOS

En la actualidad se diponen discos de buen precio y alta capacidad para una solución de bajo TIER. Un ejemplo podría ser 4 discos SATA de 3Gb/s ,  capacidad 2 TB,  64 MB de Caché y 7200 rpm  con un total aproximado de 500€. Proporcionando aproximadamente unos 6 TB en RAID software con MDADM (solución de servidores Linux de RAID software) , que nos da una media de 111 euros por Tera tolerante a fallo (RAID).

Preguntadle a vuestro proveedor de SAN cuanto saldría una amplación de los TB en fibra …   ;-)

Aunque no es comparable una cabina de discos en fibra en cuanto a rendimiento debido a sus fenomenales características Hardware (tarjetas de fibra operando en modo target y procesadores dedicados, memoria caché del frontend y backend de los discos, …). Además sus discos tienen un rendimiento mayor,  15.000 rpm frente a los 7200 rpm que tienen  los discos SATA, comparativamente  pueden  duplicar las I/Os y mejoras como gestión de colas o DIF T10. Según la necesidad de las aplicaciones del uso intensivo de disco podría ser adecuada una solución de bajo TIER.

  • RAID

La tecnología RAID Hardware dejó de ser hace años exclusiva de entornos enterprise y cualquier placa de PC lleva integrado una controladora de discos SATA con soporte de RAID 0,1,5.  Por otro lado los resultados del RAID por software (MDADM, ZFS, …) y los gestores de volúmenes (Logical Volumen Manager – LVM ,Solaris Volumen Manager – SVM ,Veritas Volume Manager – VxVM, ZFS, …) demuestran ser alternativa eficaz que  complementan de forma segura y hacen flexible cualquier cambio posterior en el almacenamiento.

  • MULTIPATH

Una solución SAN en iSCSI necesitaría de un switch ethernet para conectar los Initiator/s con los Target/s. Un diseño en SAN de fibra típico sería redundar HBAs y Switches de fibra proporcionando multicamino (multipah) al sistema eliminando puntos de fallo, se conseguiría de esta forma prevenir de cualquier fallo Hardware la continuidad de acceso a los discos. Esta tolerancia a fallos también es posible realizarse por analogía en iSCSI, redundando tarjetas  y switches ethernet, acompañado de un software multipath propio de la distribución o usando nativamente el multipath iSCSI.

  • SAN/NAS

Cualquier sistema UNIX/Linux dispone de soporte para protocolos fibra e iSCSI y combinar con  cualquier protocolo de compartición de ficheros como SMB o NFS. Ésto nos permitiría crear un servidor que centraliza el almacenamiento en el CPD redireccionándolo a ethernet sobre protocolos de bloques (iSCSI) o de ficheros (SMB,NFS).

También existen soluciones enterprise con esta funcionalidad  basadas en software abierto tales como NexentaStor,  OpenFiler o FreeNAS.

  • Sistemas de Ficheros con reservas

El acceso de diferentes servidores a los mismos volúmes (típico en clústeres) necesitan tener un control de acceso y reservas de forma que haya coherencia en las modificaciones en el sistema de ficheros. Ésto se puede conseguir eligiendo un sistema de ficheros de tipo disco compartido (Share Disk File System)   como GFS (REDHAT) o VMFS (VMWARE).

  • Controladoras Activo/Activo Activo/Pasivo

Soluciones software tipo  IET en servidores linux  sobre las tarjetas ethernet del servidor  como Enterprise Target iSCSI proporcionará un comportamiento  análogo al  típico de  las controladoras de cabinas de discos  en fibra.

  • Soporte

El tema más delicado ya que el soporte SAN va en función de la interoperabilidad entre fabricantes destacando los elementos siguientes:

Sistema Operativo – Multipath – HBA-Drivers – Switch – Almacenamiento – Modos del multipath

Y debido a que el diseño de cada elemento en su totalidad  no se ajusta a los mismos estándares se necesita una certificación previa entre diferentes fabricantes.

Esta situación cambia bastante en un entorno iSCSI siendo un protocolo/estandar bien definido con una implementación precisa, que crea un marco de interoperatibidad mucho mayor.

Aún así, hablamos  de la infrestructura que contiene los datos de una empresa, y si algo en su CPD debe de tener soporte es este almacén de datos. Por lo que el final de este diseño propuesto puede variar bastante si no se quiere contratar soporte … incluyento por ejemplo  soluciones de backup, Alta disponibilidad (HA) con replicación síncrona entre dos cabinas de discos, … todo un tema a desarrollar y cuya implementación en producción es aconsejable que deba superar toda una fase de testeo intensivo  y planes robustos de contingencia.

Lo aconsejable es buscar soporte en alguna solución tipo Openfiler, siendo una de las soluciones más flexibles que cumple los puntos propuestod … aunque no olvidar que hay que mirar la interoperabilidad con lupa y como ejemplo  VMWARE no la certifica para sus servidores ESX.

Por otro lado si se elige una implementación  de un target iSCSI sobre un sistema operativo, ésta solución  no tiene porqué dejar de ser soportada por la distribución, ejemplo de ellos son: RHEL que incluye desde la versión 5.3 soporte para esta característica integrando SCSI Target Framework proyecto integrado en la linea principal de desarrollo del Kernel y mantenido por el creador de IET u OpenSolaris/Solaris Express 11 con el proyecto COMSTAR.

En Almacenamiento Abierto hemos diseñado cabinas de discos para entornos de producción con las siguientes características:

Ubuntu Server / SCST / LVM2 / MDADM (RAID 5) / HOT SPARE / ESX/ESXi 4/ MULTIPATH Nativo iSCSI/ SATA

Su aplicación para entornos de producción es un punto de interés fuerte por eso le hemos dedicado una serie de artículos sobre el proyecto SCST.

Si estás interesado en una implementación de targets SCST de bajo Tier certificado para VMWARE u otro entorno quizás te podamos ayudar, o si ya has implementado una o estás en en el proceso, nos gustaría conocer tu experiencia.

About Angel Ferrás Rodríguez

Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas. Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.

Comments (1)

Comprobación de VTL Open Source operando con Symantec Backup Exec

Tags: , , , , ,

Comprobación de VTL Open Source operando con Symantec Backup Exec

Posted on 24 mayo 2010 by Angel Ferrás Rodríguez

A continuación se muestra como la VTL Open Source sobre iSCSI creada en el capítulo anterior se integra en un software típico de administración de copias de seguridad en cintas como Symantec Backup Exec 12.5 para servidores Windows.

El entorno elegido ha sido un Windows Server 2008 SP1 de 32 bits. Se ha hecho un escaneo de la IP del servidor que contiene el proyecto mhvtl desde su iSCSI initiator y ha reconocido todos sus dispositivos:

Listado de dispositivos iSCSI w2k8

Desde la consola de Symantec Backup Exec 12.5 se observan igualmente las librerías y lectores de cintas:

Se hace una prueba sencilla: copia de respaldo de una carpeta del servidor y su restauración. Como se puede observar concluyen con éxito:

About Angel Ferrás Rodríguez

Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas. Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.

Comments (2)

VTL Open Source sobre iSCSI

Tags: , , , , ,

VTL Open Source sobre iSCSI

Posted on 23 mayo 2010 by Angel Ferrás Rodríguez

La instalación se hará en cuatro fases:

 

1.- Obtener las fuentes del núcleo de Linux

2.- Compilar un núcleo con el proyecto SCST

3.- Compilar proyecto mhvtl

4.- Configurar dispositivos para mhvtl



El escenario:

Se ha elegido la instalación sobre un Sistema Operativo Centos versión 5.4 de 64 bits. En nuestro AA Labs hemos elegido una máquina virtual  hospedada en un VMWARE Server sobre OpenSuse 11.2.

1.- Obtener las fuentes del núcleo de Linux

Documentación:

Wiki CentOS: http://wiki.centos.org/HowTos/I_need_the_Kernel_Source

Foros de nimsa

Procedimiento:

Instalar entorno de compilación y todos los paquetes necesitados para las cuatro fases junto con todas sus dependencias:

# yum install make gcc hmaccalc openssl openssl-devel zlib-devel lsscsi mt-st mtx rpm-build redhat-rpm-config unifdef kernel-headers subversion

Crear usuario vtl y asignar contraseña:

# useradd vtl
# passwd vtl

 

Crear directorios /opt/mhvtl y /etc/mhvtl y se hace propietario a nuevo usuario:

# mkdir /opt/mhvtl
# chown -Rf vtl:vtl /opt/mhvtl

# mkdir /etc/mhvtl
# chown -Rf vtl:vtl /etc/mhvtl

Loguearse como usuario vtl:

#su – vtl

Conocer la versión del núcleo Linux que corre en tu sistema:

$ uname -a

Linux centos.ferras.local 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:08:30 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

Desempaquetar y preparar los archivos Fuentes:

[vtl@centos ~]$ cd

[vtl@centos ~]$ mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

[vtl@centos ~]$ echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmmacros

Descargar el paquete de Fuentes que corresponde a la versión de Kernel de tu CentOS/RHEL desde aquí e instalarlo:

$ rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-194.3.1.el5.src.rpm

$ cd ~/rpmbuild/SPECS

$ rpmbuild -bp --target=`uname -m` kernel-2.6.spec

 

Comprobar que el árbol de fuentes del kernel esté en /home/vtl/rpmbuild/BUILD/:

 

$ ls ~/rpmbuild/BUILD/

kernel-2.6.18[vtl@centos SPECS]$ cp -Rf /home/vtl/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.x86_64 /usr/src/kernels/

Copiarlos como root a /usr/src/kernels:

 

#cp -Rf /home/vtl/rpmbuild/BUILD/kernel-2.6.18/linux-2.6.18.x86_64 /usr/src/kernels/

2.- Compilar un núcleo con el proyecto SCST

Documentación:

Howto ISCSI-SCST: http://iscsi-scst.sourceforge.net/iscsi-scst-howto.txt

Foros de nimsa

Procedimiento:

Como usuario root descargar proyecto scst con subversion y añadir los parches indicados:

# cd /root

# svn co https://scst.svn.sourceforge.net/svnroot/scst/trunk scst

# cd /usr/src/kernels/linux-2.6.18.x86_64

# patch -p1 < /root/scst/iscsi-scst/kernel/patches/put_page_callback-2.6.18.1.patch

# patch -p1 < /root/scst/scst/kernel/scst_exec_req_fifo-2.6.18.patch

Compilar la imagen del kernel:

# make clean
# make && make modules
# make modules_install && make install

Comprobar que ha creado entrada el el grub de nuevo kernel vmlinuz-2.6.18-prep:

# cat /boot/grub/menu.lst

(…)

title CentOS (2.6.18-prep)

root (hd0,0)

kernel /vmlinuz-2.6.18-prep ro root=/dev/VolGroup00/LogVol00

initrd /initrd-2.6.18-prep.img

Reiniciar sistema con nuevo kernel y comprobarlo:

# uname -a

Linux centos.ferras.local 2.6.18-prep #1 SMP Thu May 20 21:13:48 CEST 2010 x86_64 x86_64 x86_64 GNU/Linux

Crear e instalar módulo scst:

#cd /root/scst
#make scst scst_install iscsi iscsi_install scstadm scstadm_install

3.- Compilar proyecto mhvtl

Documentación:

Proyecto Linux Virtual Tape Library

Foros de nimsa

Procedimiento:

Descargar proyecto mhvl en formato tgz desde aquí, se ha elegido la versión de desarrollo mhvtl-2010-05-08 (0.18-7):

# wget http://sites.google.com/site/linuxvtl2/mhvtl-2010-05-08.tgz?attredirects=0

Descomprimir y compilar:

# tar xzvf mhvtl-2010-05-08.tgz

# cd mhvtl-0.18/

# make distclean

# cd kernel

# make

# make install

# cd ..

#make

# make install

4.- Configurar dispositivos para mhvtl

 

Documentación:

Foros de nimsa

Procedimiento:

En el foro de nimsa se ha publicado un script para la creación automática de los ficheros de configuración iscsi-scstd.conf y scst.conf. De esta forma crea una configuración particular de librerías y drives emulados por iSCSI:

[root@centos ~]# cat make_scst_config.sh

#!/bin/ksh

# Customize your own

IQN=iqn.2010-05.es.ferras

# Build /etc/iscsi-scstd.conf

lsscsi -g | grep -e tape -e mediumx| awk '{print $1}'| cut -d "[" -f2| cut -d "]" -f1| while read each; do

echo "Target $IQN:$each" >>/tmp/iscsi-scstd.tmp

done

if [ -f /etc/iscsi-scstd.conf ]; then

cp -f /etc/iscsi-scstd.conf /etc/iscsi-scstd.conf_`date +%m%d%y%H%M%S`

echo Created backup of existing /etc/iscsi-scstd.conf as /etc/iscsi-scstd.conf_`date +%m%d%y%H%M%S`

fi

cat /tmp/iscsi-scstd.tmp >/etc/iscsi-scstd.conf

echo Created new /etc/iscsi-scstd.conf

rm -f /tmp/iscsi-scstd.tmp

echo ——-

# Build /etc/scst.conf

echo "[HANDLER changer]" >/tmp/scst.tmp

lsscsi -g| grep mediumx | awk '{print $1}'| cut -d "[" -f2| cut -d "]" -f1| while read each1; do

echo DEVICE $each1 >>/tmp/scst.tmp

done

echo "[HANDLER tape]" >>/tmp/scst.tmp

lsscsi -g| grep tape | awk '{print $1}'| cut -d "[" -f2| cut -d "]" -f1 | while read each2; do

echo DEVICE $each2 >>/tmp/scst.tmp

done

lsscsi -g | grep -e tape -e mediumx|awk '{print $1}'| cut -d "[" -f2| cut -d "]" -f1| while read each3; do

echo "[GROUP Default_$IQN:$each3]" >>/tmp/scst.tmp

done

lsscsi -g | grep -e tape -e mediumx| awk '{print $1}'| cut -d "[" -f2| cut -d "]" -f1| while read each4; do

echo "[ASSIGNMENT Default_$IQN:$each4]" >>/tmp/scst.tmp

echo "DEVICE $each4,0" >>/tmp/scst.tmp

done

if [ -f /etc/scst.conf ]; then

cp -f /etc/scst.conf /etc/scst.conf_`date +%m%d%y%H%M%S`

echo Created backup of  existing /etc/scst.conf as /etc/scst.conf_`date +%m%d%y%H%M%S`

fi

cat /tmp/scst.tmp >/etc/scst.conf

echo Created new /etc/scst.conf

rm -f /tmp/scst.tmp

echo — Done —

Ejecutarlo:

# sh make_scst_config.sh

Arrancar mhvtl:

/etc/init.d/mhvtl start

Cargar los módulos scst:

modprobe scst
modprobe scst_tape
modprobe scst_changer

Si hemos llegado hasta aquí sin errores deberíamos ver los nuevos dispositivos SCSI del sistema:

# lsscsi

[0:0:0:0]    disk    VMware,  VMware Virtual S 1.0   /dev/sda

[1:0:0:0]    mediumx SPECTRA  PYTHON           550V  -

[1:0:1:0]    tape    IBM      ULT3580-TD4      550V  /dev/st0

[1:0:2:0]    tape    IBM      ULT3580-TD4      550V  /dev/st1

[1:0:3:0]    tape    IBM      ULT3580-TD4      550V  /dev/st2

[1:0:4:0]    tape    IBM      ULT3580-TD4      550V  /dev/st3

[1:1:0:0]    mediumx SPECTRA  PYTHON           550V  -

[1:1:1:0]    tape    IBM      ULT3580-TD4      550V  /dev/st4

[1:1:2:0]    tape    IBM      ULT3580-TD4      550V  /dev/st5

[1:1:3:0]    tape    IBM      ULT3580-TD4      550V  /dev/st6

[1:1:4:0]    tape    IBM      ULT3580-TD4      550V  /dev/st7

# cat /proc/scsi_tgt/scsi_tgt

Device (host:ch:id:lun or name)                             Device handler

0:0:0:0                                                     dev_disk

1:0:1:0                                                     dev_tape

1:0:2:0                                                     dev_tape

1:0:3:0                                                     dev_tape

1:0:4:0                                                     dev_tape

1:1:1:0                                                     dev_tape

1:1:2:0                                                     dev_tape

1:1:3:0                                                     dev_tape

1:1:4:0                                                     dev_tape

1:0:0:0                                                     dev_changer

1:1:0:0                                                     dev_changer

Una comprobación de que los targets iSCSI están correctamente levantados puede ser la siguiente: Desde un Windows XP con el initiator iSCSI instalado se hace un scan a la IP del servidor mhvtl. Se deberán detectar todos los dispositivos iSCSI:

initiator xp

Y desde el  Administrador de dispositivos:

El el siguiente capítulo vamos a poner a prueba la mhvtl creada desde un software de backup, Symantec Backup Exec.

About Angel Ferrás Rodríguez

Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas. Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.

Comments (4)

Virtualización de Librerías de Cintas

Tags: , ,

Virtualización de Librerías de Cintas

Posted on 21 mayo 2010 by Angel Ferrás Rodríguez

Desde la bajada  del precio de los discos, las soluciones de copias de seguridad y recuperación de desastres en los Centros de Datos estan cambiado. La forma tradicional para mantener copias de los datos de nuestros Data Centers ha sido durante décadas sobre cintas magnéticas. Los discos, en la actualidad por precio,  mejoras en consumo eléctrico, rendimiento y aumento descomunal de su capacidad, auguran la muerte del soporte magnético que tantas décadas han puesto nuestros datos a buen recaudo. Paralelamente durante estos años se ha desarrollado  un software que garantiza la eficacia y el éxito de las copias, automatizando dichas tareas de forma desanvmwaretendida. La calidad del software de gestión automática de backup y recuperación de desastres se ha convertido en un amortiguador de migración de soportes. Con la reciente aparición de soluciones tipo VDR/SRM en los entornos virtualizados de VMWARE nos podemos hacer una idea del futuro próximo de las fórmulas de backup y contingencia que encontraremos. En la actualidad los grandes proveedores  de almacenamiento nos proponen un modelo híbrido que incluyen una de las soluciones software de administración automática de copias de seguridad tales como Netbackup, Legato o TSM pero sustituyendo las clásicas librería de cintas por homólogos virtulizados  llamados VTL (Virtual Tape Library), que a su vez pueden convivir con las clásicas proporcionando mejoras sustanciales en las ventanas de copias. Estas librerías de cintas virtuales son servidores que disponen de targets de fibra óptica, iscsi (o cualquier protocolo de almacenamiento ej. SAS) emulando a nivel software librerías y lectores de cintas estándares y dialogan como tales con los administradores software de copias de seguridad, con la diferencia que la información es guardada en discos. De esta forma se consigue desde la administración de los sistemas de copias de seguridad tradicional que la migración de soporte, magnético a disco, no cambie, disfrutando de las virtudes de este software clásico de administración junto con otras de las excelencias que tiene esta migración, el incremento de velocidafalconstored de la copia y restauración. Éste modelo híbrido en una solución ideal, implementándose desde hace tiempo con éxito en muchos centros de datos, ejemplo de ello son las VTLs de FalconStore . Desde Almacenamiento Abierto, vamos a dedicar una sección a estos entornos virtualizados, aprendiendo como implementar una solución Open Source e integración con un software clásico de backup.

About Angel Ferrás Rodríguez

Ingeniero Superior en Electrónica que trabaja en la actualidad como Analista de Sistemas. Se especializa en Sistemas SAN, Almacenamiento y Backup en base a su experiencia en los sistemas informáticos de grandes cuentas. Escribe en la actualidad en web especializada de almacenamiento sobre soluciones de código abierto.

Comments (2)