Tag Archive | "SAN"

SAN Low Cost – Backblaze

Tags: , , ,

SAN Low Cost – Backblaze

Posted on 11 agosto 2010 by Angel Ferrás Rodríguez

Siguiendo con el artículo anterior que describía tecnologías para la implementación de un SAN de bajo coste, añado una interesante reseña sobre la solución de backups Backblaze. Esta empresa, formada por reputados empresarios, han hecho una propuesta de almacenamiento barato inusual, basado en un diseño del chassis de un servidor para rack de 4U con capacidad de albergar 45 discos SATA, conteniendo en total 67 teras  con un coste de 7,867$, saliendo el precio del tera a 117$.

Una comparativa del ahorro que supone esta solución:

Basada 100% en software libre:

Usada con éxito en entornos de producción, aunque tiene sus detractores que se basan en la no implementación de la especificación DIF T10 (de protocolo SCSI) o la falta de redundancia eléctrica (PSU), … hay un hilo interesante en GOOGLE GROUPS  sobre ello.

También encontré  inspiradoras modificaciones como ZFS o Alta disponibilidad.

Añado una entrada del Blog de StorageMojo que nos explica el porqué la diferencia de coste entre las soluciones SAN de los proveedores típicos de almacenamiento y la propuesta por BackBlaze, sin desperdicio …

Y por último animar a un  nuevo grupo  llamado OpenStoragePod que basados en ésta solución, investigan sobre diferentes alternativas hardware y software y cuya misión es:

to challenge the server tax” on enterprise storage solutions

Comments (3)

Una SAN para tiempos de crisis

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

Una SAN para tiempos de crisis

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

En tiempos de crisis proponemos “cocinar” una SAN a bajo precio con los siguientes ingredientes:

iSCSI

iSCSI   es una alternativa a la clásica SAN de fibra óptica, es 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 operativos para servidores actuales es gratuito y ya vienen con la distribución, al igual que las soluciones de multicamino (multipath).

DISCOS

En la actualidad se diponen discos de buen precio y alta capacidad para una solución de rango medio (midrange). Un ejemplo podría ser 4 discos SATA de 3Gb/s ,  capacidad 2 TB,  64 MB de Caché y 7200 rpm  podrían salir a unos 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 el TB en fibra …   ;-)

Haciendo justicia no es comparable una cabina de discos en fibra en cuanto a rendimiento debido a sus fenomenales características Hardware. 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 . En un entorno de alta capacidad frente a rendimiento, sería adecuado nuestra propuesta con discos SATA, en caso contario, incluir discos SAS  con una controladora  será una alternativa  más adecuada.

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, 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.

PROXY SAN/NAS

Cualquier sistema UNIX/Linux dispone de soporte para fibra e iSCSI, con una correcta configuración se podría realizar un redirección de los volúmnes (lunes) en fibra a traves de iSCSI sobre ethernet 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.

FS 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 productos y marcas.

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 … 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 con el proyecto COMSTAR.

Comments (1)

VTL 4 – Creando una VTL Open Source para FC

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

VTL 4 – Creando una VTL Open Source para FC

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

Ya disponemos en nuestro AA Labs de una VTL Open Source sobre FCP. Su implementación está basada en los trabajos previos sobre mhVTL y SCST.  Siguiendo con la configuración SAN del post anterior, hemos conseguido emular una librería modelo Storagetek SL700 y un drive SDL600 de Quantum:

Partiendo del escenario descrito en los post  SCST 2 y SCST 3, donde se compiló un kernel vanilla y se le añadió el proyecto SCST junto con los drivers de QLogic en modo target, configurado para que ofreciera a la SAN un disco virtual (VDISK). Se añade al servidor el proyecto mhVTL emulando una librería de cintas modelo Sun Storagetek SL700 con un drive SDLT600 de QUANTUM, encargándose el módulo SCST de ofrecerlas a través de la HBA QLogic QLA2340 en modo target.

El procedimiento de su implementación es el siguiente:

1.- Crear entorno previo SCST descrito en el  post SCST 2.

2.- Instalar proyecto mhVTL

3.- Configurar mhVTL

4.- Configurar SCST para dar visibilidad a los elementos de mhVTL por fibra.

2.- Instalar proyecto mhVTL

Si se ha realizado  la VTL Open Source sobre iSCSI, ya sabrás como instalarlo. Descarga de las fuentes mhvtl en formato tar.gz desde la web del proyecto. A continuación el procedimiento de instalación sería:

# useradd vtl
# passwd vtl
# mkdir /opt/mhvtl
# chown -Rf vtl:vtl /opt/mhvtl
# mkdir /etc/mhvtl
# chown -Rf vtl:vtl /etc/mhvtl
# cd /root/mhvtl-0.18-4
# make distclean
# cd kernel
# make
# make install
# cd ../
# make
# make install

3.- Configurar mhVTL

Edición del fichero /etc/mhvtl/device.conf  para definir en el proyecto mhVTL la librería y el drive:

# cat /etc/mhvtl/device.conf
VERSION: 4

# VPD page format:
# <page #> <Length> <x> <x+1>… <x+n>

# NOTE: The order of records is IMPORTANT…
# The 'Unit serial number:' should be last (except for VPD data)
# i.e.
# Order is : Vendor ID, Product ID, Product Rev and serial number finally
# Zero, one or more VPD entries.
#
# Each 'record' is sperated by one (or more) blank lines.
# Each 'record' starts at column 1

Library: 2 CHANNEL: 0 TARGET: 0 LUN: 0
Vendor identification: STK
Product identification: L700
Product revision level: 5500
Unit serial number: XYZZY

Drive: 1 CHANNEL: 0 TARGET: 1 LUN: 0
Library ID: 2 Slot: 1
Vendor identification: QUANTUM
Product identification: SDLT600
Product revision level: 5500
Unit serial number: ZF7584364
Max density: 0×46
VPD: b0 04 00 02 01 00

Definir el contenido de la librería en el fichero /etc/mhvtl/library_contents:

# cat /etc/mhvtl/library_contents
# Define how many tape drives you want in the vtl..
# The 'XYZZY_...' is the serial number assigned to
# this tape device.

Drive 1: ZF7584364

# Place holder for the robotic arm. Not really used.
Picker 1:

# Media Access Port
# (mailslots, Cartridge Access Port, <insert your favourate name here>)
# Again, define how many MAPs this vtl will contain.
MAP 1:
MAP 2:
MAP 3:
MAP 4:

# And the 'big' on, define your media and in which slot contains media.
# When the rc script is started, all media listed here will be created
# using the default media capacity.
Slot 1:    800843S3
Slot 2: 800844S3
Slot 3: 800845S3
Slot 4: 800846S3
Slot 5: 800847S3
Slot 6: 800848S3
Slot 7: 800849S3
Slot 8: 800850S3
Slot 9: 800851S3
Slot 10: 800852S3
Slot 11: 800853S3
Slot 12: 800854S3
Slot 13: 800855S3
Slot 14: 800856S3
Slot 15: 800857S3
Slot 16: 800858S3
Slot 17: 800859S3
Slot 18: 800860S3
Slot 19: 800861S3
Slot 20: 800862S3
Slot 21:
Slot 22:
Slot 23:
Slot 24:
Slot 25:
Slot 26:
Slot 27:
Slot 28:
Slot 29:
Slot 30:
Slot 31: CLN001L1
Slot 32: CLN002L1

4.- Configurar SCST para dar visibilidad a los elementos de mhVTL por fibra.

Levantar  servicio mhVTL:

/etc/init.d/mhvtl start

Comprobación:

# lsscsi
[2:0:0:0]    disk    ATA      WDC WD7500AACS-0 01.0  /dev/sda
[8:0:0:0]    mediumx STK      L700             5500  -
[8:0:1:0]    tape    QUANTUM  SDLT600          5500  -

Se observan el VDISK (procedente de prueba anterior) y la librería STK L700 junto con el drive QUANTUM SDLT600 creados por mhVTL.

Se configura para que los dispositivos sean visibles por la HBA:

# echo "add 8:0:1:0 1" > /proc/scsi_tgt/groups/Default/devices

# echo "add 8:0:0:0 2" > /proc/scsi_tgt/groups/Default/devices

Y se pone en modo target el host asociado como interfaz en sysfs:

# echo “1″ >/sys/class/scsi_host/host7/target_mode_enabled

Comprobación:

# cat /sys/class/scsi_host/host7/active_mode

Target

# cat /proc/scsi_tgt/scsi_tgt
Device (host:ch:id:lun or name)                             Device handler
2:0:0:0                                                     dev_disk
vm_disk                                                     vdisk_fileio
8:0:1:0                                                     dev_tape
8:0:0:0                                                     dev_changer

Desde el Host con W2k8 que opera en modo initiator se observan desde el administrador de dispositivos de la siguiente forma:

Se ha instalado la Utilidad OneCommand manager de Emulex con propósito de diagnóstico, la librería y el drive emulados se observan de la siguiente forma:

Para comprobar la conectividad del host con la VTL por fibra  se han usado las utilidades mtx en su versión para Windows:

Estado de la librería:

c:\mtx>mtx.exe -f 3:0:0:2 status
Storage Changer 3:0:0:2:1 Drives, 36 Slots ( 4 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = 800843S3

Storage Element 1:Empty
Storage Element 2:Full :VolumeTag=800844S3
Storage Element 3:Full :VolumeTag=800845S3
Storage Element 4:Full :VolumeTag=800846S3
Storage Element 5:Full :VolumeTag=800847S3
Storage Element 6:Full :VolumeTag=800848S3
Storage Element 7:Full :VolumeTag=800849S3
Storage Element 8:Full :VolumeTag=800850S3
Storage Element 9:Full :VolumeTag=800851S3
Storage Element 10:Full :VolumeTag=800852S3
Storage Element 11:Full :VolumeTag=800853S3
Storage Element 12:Full :VolumeTag=800854S3
Storage Element 13:Full :VolumeTag=800855S3
Storage Element 14:Full :VolumeTag=800856S3
Storage Element 15:Full :VolumeTag=800857S3
Storage Element 16:Full :VolumeTag=800858S3
Storage Element 17:Full :VolumeTag=800859S3
Storage Element 18:Full :VolumeTag=800860S3
Storage Element 19:Full :VolumeTag=800861S3
Storage Element 20:Full :VolumeTag=800862S3
Storage Element 21:Empty
Storage Element 22:Empty
Storage Element 23:Empty
Storage Element 24:Empty
Storage Element 25:Empty
Storage Element 26:Empty
Storage Element 27:Empty
Storage Element 28:Empty
Storage Element 29:Empty
Storage Element 30:Empty
Storage Element 31:Full :VolumeTag=CLN001L1
Storage Element 32:Full :VolumeTag=CLN002L1
Storage Element 33 IMPORT/EXPORT:Empty
Storage Element 34 IMPORT/EXPORT:Empty
Storage Element 35 IMPORT/EXPORT:Empty
Storage Element 36 IMPORT/EXPORT:Empty

Información de la librería:

c:\mtx>tapeinfo.exe -f 3:0:0:2
Product Type: Medium Changer
Vendor ID: 'STK     '
Product ID: 'L700            '
Revision: '5500'
Attached Changer API: No
SerialNumber: 'XYZZY     '
Ready: yes

Información del drive:

c:\mtx>tapeinfo.exe -f Tape0
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'SDLT600         '
Revision: '5500'
Attached Changer API: No
SerialNumber: 'ZF7584364 '
MinBlock: 4
MaxBlock: 1048576
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0×49
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0×10
DeCompType: 0×10
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 499
Partition 0 Size in Kbytes: 500
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

Carga de cinta de Slot 1 a drive 0:

c:\mtx>mtx.exe -f 3:0:0:2 load 1 0
Loading media from Storage Element 1 into drive 0…done

Descarga de drive 0 a slot 1:

c:\mtx>mtx.exe -f 3:0:0:2 unload 1 0
Unloading drive 0 into Storage Element 1…done

Como se puede observar la librería virtual opera correctamente a las peticiones descritas a través de fibra. Queda para un próximo post estudiar el comportamiento de la librería administrada por un software típico de backup.

Fuentes:

Proyecto mhvtl

Proyecto SCST

Foros de nimsa

Blog nsrd.info

Comentarios desactivados