OpenFiler – Instalacion y Configuracion Paso a Paso

Última actualización: 13 ENE 2014 04:10 hrs Colombia.

Este artículo tiene como objetivos:

• Implementar un servidor de almacenamiento en red tipo NAS usando la distribución Linux OpenFiler.
• Implementar un red de almacenamiento tipo SAN usando nuestra NAS OpenFiler como Storage y ISCSI como protocolo de comunicación entre hosts.

PAQUETES Y REPOSITORIOS

OpenFiler es una distribución Linux basada en rPath.

rPath se encuentra descontinuada desde el 2009 motivo por el cual existe un proyecto de migración de OpenFiler hacia una base CENTOS  la cual tiene una gran cantidad de repositorios y software disponible (como el magnífico Extra Packages for Enterprise Linux (EPEL)

Cuando dicha migración culmine podremos usar yum en vez de Conary, mientras eso sucede vamos a aprender a usar Conary en OpenFiler con los Repositorios de la distribución Foresight, la cual, junto con OpenFiler, son las únicas distribuciones que actualmente (ENE 2014) emplean Conary para gestionar sus paquetes de software.

Esta lectura será bastante comprensible para el lector con experiencia en la gestión de paquetes mediante aptitude, apt-get o yum.

Para el lector inexperto se recomienda leer el siguiente artículo antes de continuar: https://juliorestrepo.wordpress.com/2008/08/27/como-instalar-programas-en-gnu-linux/

# conary
Conary Software Configuration Management System

Common Commands (use «conary help» for the full list)

Information Display
config        Display the current configuration
help          Display help information
query/q       Query the local system database
rblist        List the rollbacks available in the rollback stack
repquery/rq   Query one or more Conary repositories
search        Search the system model for available packages
showcs/scs    Display information about a changeset file
verify        Verify filesystem matches conary database

System Modification
erase         Erase software from the system
install       Install software on the system
migrate       Migrate the system to a different group
rollback/rb   Roll back operations stored in the rollback stack
update        Update or install software on the system
updateall     Update all the software on the system

Para actualizar por completo nuestra distribución ejecutamos el siguiente comando:

# conary updateall

Por defecto, OpenFiler usa un repositorio sencillo de Foresight llamado CONTRIB

A continuación vamos a instalar el paquete hddtemp desde el repositorio CONTRIB para monitorear la temperatura de los discos duros de nuestro
OpenFiler (algo bastante importante si tenemos ya que el principal rol de OpenFiler es ser servidor de almacenamiento)

# conary update hddtemp=foresight.rpath.org@fl:1-contrib

El repositorio CONTRIB de Foresight es bastante reducido en comparación con el CONTRIB de otras distribuciones (como DEBIAN, por ejemplo).

Si usamos únicamente CONTRIB tendremos dificultades para encontrar e instalar otras aplicaciones (como mi adorado htop, por ejemplo)

Afortunadamente existe un repositorio de Desarrollo llamado DEVEL, el cual instalaremos en nuestro OPENFILER a continuación:

# conary update foresight-contexts=foresight.rpath.org@fl:2-devel

Ahora procederemos a instalar los paquetes htop y gdisk desde el repositorio DEVEL

# conary update htop=foresight.rpath.org@fl:2-devel
# conary update gdisk=foresight.rpath.org@fl:2-devel

Por último instalaremos el paquete iptraf, que nos servirá para monitorear el ancho de banda de nuestras tarjetas de red:

# conary update iptraf=contrib.rpath.org@rpl:devel/3.0.0-1-1

LA TEMPERATURA DE LOS DISCOS

Una vez instalado hddtemp, probaremos que funcione. En mi caso tengo instalados 2 tipos de disco: Un disco de 2700GB (Toshiba de 7200RPM) y un disco de 500GB (Corsair de Estado Solido)

# hddtemp /dev/sda
/dev/sdb: TOSHIBA DT01ACA300 : 43 C
# hddtemp /dev/sdb
/dev/sdc: Corsair Force GS : 29 C

Como puede observarse la diferencia de temperatura es impresionante. La razón es muy simple: El Toshiba tiene un motor girando a 7200 RPM y el Corsair NO.

SECTORES FÍSICOS y LÓGICOS

Para ubicar la información dentro de un disco duro, Wikipedia nos cuenta que «El primer sistema de direccionamiento que se usó fue el CHS (cilindro-cabeza-sector), ya que con estos tres valores se puede situar un dato cualquiera del disco. Más adelante se creó otro sistema más sencillo: LBA (direccionamiento lógico de bloques), que consiste en dividir el disco entero en sectores y asignar a cada uno un único número» http://es.wikipedia.org/wiki/Disco_duro y http://commons.wikimedia.org/wiki/File:Cilindro_Cabeza_Sector.svg

Tenemos sectores físicos (determinados por el Fabricante del disco) y sectores lógicos (determinados por la manera como particionemos lógicamente nuestro disco).

VERIFICAR EL TAMAÑO DE LOS SECTORES FÍSICOS DE NUESTRO DISCO

Para /dev/sda (mi disco de 3TB marca TOSHIBA) tenemos:

# lsblk -t /dev/sda
NAME   ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED
sda            0   4096      0    4096     512    1 cfq
`-sda1         0   4096      0    4096     512    1 cfq

Para /dev/sdb (mi disco de 500GB marca CORSAIR) tenemos:

# lsblk -t /dev/sdb
NAME   ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED
sdb            0    512      0     512     512    0 cfq
`-sdb1         0    512      0     512     512    0 cfq

Observamos 3 columnas:

• MIN-IO: Es el tamaño mínimo de Bytes, electrónicamente hablando (1 Byte = 8 bits), involucrado en 1 (una) operación de escritura o lectura (IO: Input Output) realizada por la aguja del disco (4096 Bytes para mi disco Toshiba y 512 Bytes para mi disco Corsair)
• PHY-SEC: Expresa en Bytes el tamaño del Sector Físico (4096 Bytes para mi disco Toshiba y 512 Bytes para mi disco Corsair)
• LOG-SEC: Expresa en Bytes el tamaño del Sector Lógico (512 Bytes en ambos discos)

Los valores expresados arriba también pueden verificarse con el comando hdparm (Hard Disk Parameters).

Para el Toshiba:

# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
Model Number:       TOSHIBA DT01ACA300
blablabla
blablabla
blablabla
blablabla
—
CHS current addressable sectors:   16514064
LBA    user addressable sectors:  268435455
LBA48  user addressable sectors: 5860533168
Logical  Sector size:                   512 bytes
Physical Sector size:                  4096 bytes
Logical Sector-0 offset:                  0 bytes
device size with M = 1024*1024:     2861588 MBytes
device size with M = 1000*1000:     3000592 MBytes (3000 GB)
cache/buffer size  = unknown
Form Factor: 3.5 inch
Nominal Media Rotation Rate: 7200

y para el Corsair:

# hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
Model Number:       Corsair Force GS
blablabla
blablabla
blablabla
blablabla
—
CHS current addressable sectors:   16514064
LBA    user addressable sectors:  268435455
LBA48  user addressable sectors:  937703088
Logical  Sector size:                   512 bytes
Physical Sector size:                   512 bytes
Logical Sector-0 offset:                  0 bytes
device size with M = 1024*1024:      457862 MBytes
device size with M = 1000*1000:      480103 MBytes (480 GB)
cache/buffer size  = unknown
Nominal Media Rotation Rate: Solid State Device

ALINEACION DE PARTICIONES (PARTITION ALIGNMENT)

Para obtener el máximo rendimiento en las operaciones de lectura y escritura de nuestros discos, los sectores físicos deberán estar alineados con los sectores lógicos.

Una alineación incorrecta de sectores puede significar, por ejemplo, que para leer 512 Bytes lógicos del disco sea necesario que la cabeza del disco lea físicamente 1024 Bytes (el doble).

Si tenemos un disco de 7200 RPM (como el caso de mi Toshiba) diseñado para realizar 100 IOPS (Operaciones de Entrada y Salida por Segundo, ver http://en.wikipedia.org/wiki/IOPS#Examples ) esto significaría que:

• Disco con Sectores Alineados: Necesitaríamos leer 1 sector físico por cada 512 Bytes útiles: 100 Operaciones de 512 Bytes útiles por sector = Leeríamos 51200 Bytes (aprox 51,2 MBytes) en un segundo.
• Disco con Sectores DESAlineados: Necesitaríamos leer 2 sectores por cada 512 Bytes útiles: Necesitaríamos el doble de Operaciones para leer los mismos 51200 Bytes (aprox 51,2 MBytes). = Leeríamos 51200 Bytes en 2 segundos, o sea SOLO 25600 Bytes (aprox 25,5 MBytes) en un segundo.

Desde otra perspectiva:

• Para leer 1GByte (1.024´000.000 Bytes) tardaríamos 20 segundos en un disco alineado y 40 segundos en un disco DESALINEADO.
• Para leer 100GBytes tardaríamos 2000 segundos (33 minutos) en un disco alineado y 4000 segundos (66 minutos) en un disco DESALINEADO.

GPT y MBR

La Globally Unique Identifiers Partition Table (GPT) es el reemplazo moderno de la antigua MBR (MS-DOS Master Boot Record). La MBR tuvo su origen en la década de 1980s con los computadores IBM, época en la cual la capacidad de los discos duros era de docenas de MegaBytes. ( http://www.linux.com/learn/tutorials/730440-using-the-new-guid-partition-table-in-linux-good-bye-ancient-mbr- ) GPT tiene una eficiencia del 96% en la utilización del espacio del disco mientras que la eficiencia de MBR es del 87% (11% inferior a GPT) ( https://wiki.archlinux.org/index.php/Advanced_Format#Introduction )

MBR limita a máximo 2 TeraBytes el tamaño de las particiones de disco. Esto significa que el disco Toshiba de 3TeraBytes que usamos en este artículo NO funcionará adecuadamente con MBR y debemos usar GPT.

El proceso de verificación de la alineación de las particiones es diferente para GPT y para MBR.

Para MBR (exclusivamente, no aplica para GPT):

Ejecutaremos el comando fdisk -lu en nuestro disco CORSAIR (cuya tabla de particiones es MBR)

# fdisk -lu /dev/sdb

Disk /dev/sdb: 480.1 GB, 480103981056 bytes
255 heads, 63 sectors/track, 58369 cylinders, total 937703088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000e2fbf

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   937701375   468849664   83  Linux

El valor Start = 2048 significa que nuestro disco está alineado correctamente. Cualquier otro valor divisible por 8 también es válido. ( https://wiki.archlinux.org/index.php/Advanced_Format#Check_your_partitions_alignment )

Para GPT (Recommended)

Por defecto, las particiones de un disco bajo GPT quedarán alineadas por defecto si son creadas con la aplicación gdisk

Recordemos:

Para instalar gdisk en OpenFiler, agregar el repositorio DEVEL de Foresight en OpenFiler mediante:

# conary update foresight-contexts=foresight.rpath.org@fl:2-devel

y luego instalar la aplicación gdisk desde el repositorio DEVEL mediante:

# conary update gdisk=foresight.rpath.org@fl:2-devel

Otra manera de verificar si nuestras particiones se encuentran alineadas es mediante el comando blockdev como se muestra a continuación, si el resultado es 0 (CERO) nuestra partición de encuentra alineada. ( https://wiki.archlinux.org/index.php/SSD#Partition_Alignment )

# blockdev –getalignoff /dev/<partition>
0

GDISK

Esta utilidad funciona de manera similar que la famosa fdisk, con la diferencia que el comando «o» en fdisk «create a new empty DOS partition table» mientras que en gdisk «create a new empty GUID partition table (GPT)» y que en las particiones que se crean en gdisk automáticamente quedarán alineados los sectores físicos con los lógicos (lo cual no necesariamente ocurre en fdisk).

A continuación realizaremos el procedimiento paso a paso para gestionar nuestras particiones con gdisk, tanto en nuestro disco Toshiba de 7200 RPM como en el Corsair de Estado Solido.

Opciones disponibles en la utilidad fdisk

# fdisk /dev/sdb

Command (m for help): m
Command action
a   toggle a bootable flag
b   edit bsd disklabel
c   toggle the dos compatibility flag
d   delete a partition
l   list known partition types
m   print this menu
n   add a new partition
o   create a new empty DOS partition table
p   print the partition table
q   quit without saving changes
s   create a new empty Sun disklabel
t   change a partition’s system id
u   change display/entry units
v   verify the partition table
w   write table to disk and exit
x   extra functionality (experts only)

Opciones disponibles en la utilidad gdisk

# gdisk /dev/sdb

Command (? for help): ?
b       back up GPT data to a file
c       change a partition’s name
d       delete a partition
i       show detailed information on a partition
l       list known partition types
n       add a new partition
o       create a new empty GUID partition table (GPT)
p       print the partition table
q       quit without saving changes
r       recovery and transformation options (experts only)
s       sort partitions
t       change a partition’s type code
v       verify disk
w       write table to disk and exit
x       extra functionality (experts only)
?       print this menu

Antes de comenzar vamos a visualizar qué discos tenemos conectados en nuestro OpenFiler mediante sfdisk

# sfdisk -l
Disk /dev/sda: 364801 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+ 267349- 267350- 2147483647+  ee  GPT
start: (c,h,s) expected (0,0,2) found (0,0,1)
/dev/sda2          0       –       0          0    0  Empty
/dev/sda3          0       –       0          0    0  Empty
/dev/sda4          0       –       0          0    0  Empty

Disk /dev/sdb: 58369 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+  58369-  58370- 468849664   83  Linux
/dev/sdb2          0       –       0          0    0  Empty
/dev/sdb3          0       –       0          0    0  Empty
/dev/sdb4          0       –       0          0    0  Empty

Pero ¿qué tenemos aquí?

Pues algo muy interesante. Son 2 discos: sda (nuestro Toshiba de 3TB) y sdb (nuestro Corsair de 500GB)

Respecto al disco sda podemos decir que ya está configurado con GPT y cuenta con una partición (la sda1) .

En sda se muestra el siguiente mensaje (al cual denominaremos «expected – found» )

start: (c,h,s) expected (0,0,2) found (0,0,1)

Siempre que veamos el mensaje expected – found en el comando sfdisk -l significa que nuestro disco está DESALINEADO.

Mi recomendación para alinearla es: Realiza un backup de toda la información del disco y procede a crear las particiones alineadas DESDE CERO antes de grabar información en el disco nuevamente. Más adelante como realizar la alineación de discos con el comando gdisk.

Sobre el disco sdb vemos que está configurado con MBR (si la salida no muestra explicitamente GPT, tal como se ve en el ejemplo con el disco sda, significa que estamos trabajando con MBR) y cuenta con una partición (la sdb1) que, como vimos anteriormente, está alineada, ya que no muestra el mensaje expected – found. Por lo que vimos GPT es tecnológicamente superior a MBR y nos interesa que el disco sdb use GPT en vez de MBR. Más adelante realizaremos esta conversión.

Comenzaremos configurando el disco Toshiba (sda) de la siguiente manera:

Ingresamos a gdisk:

# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Podemos observar que el sistema nos dice GPT: present , lo cual, como vimos, significa que el disco YA está configurado con GPT pero, como vimos el mensaje expected-found en la salida del comando sfdisk -l , el disco se encuentra desalineado. Estando 100% seguros que no tenemos información que perder en dicho disco, comenzaremos el proceso de alineación del disco creando una nueva tabla de particiones GPT (esto borrará toda la información del disco).

Command (? for help): o

This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): Y

Después de esto, la salida de la opción p se mostrará vacía (sin particiones)

Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3BE35A01-38DE-48C4-9624-F066A6639ABB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Procederemos a crear una nueva partición, que en nuestro caso abarcará la totalidad del disco, usando la opción n

Command (? for help): n
Partition number (1-128, default 1): presionamos enter para aceptar la opción por defecto.
First sector (34-5860533134, default = 2048) or {+-}size{KMGTP}: presionamos enter para aceptar la opción por defecto.
Last sector (2048-5860533134, default = 5860533134) or {+-}size{KMGTP}: presionamos enter para aceptar la opción por defecto.
Current type is ‘Linux filesystem’
Hex code or GUID (L to show codes, Enter = 8300): L
0700 Microsoft basic data  0c01 Microsoft reserved    2700 Windows RE
4200 Windows LDM data      4201 Windows LDM metadata  7501 IBM GPFS
7f00 ChromeOS kernel       7f01 ChromeOS root         7f02 ChromeOS reserved
8200 Linux swap            8300 Linux filesystem      8301 Linux reserved
8e00 Linux LVM             a500 FreeBSD disklabel     a501 FreeBSD boot
a502 FreeBSD swap          a503 FreeBSD UFS           a504 FreeBSD ZFS
a505 FreeBSD Vinum/RAID    a580 Midnight BSD data     a581 Midnight BSD boot
a582 Midnight BSD swap     a583 Midnight BSD UFS      a584 Midnight BSD ZFS
a585 Midnight BSD Vinum    a800 Apple UFS             a901 NetBSD swap
a902 NetBSD FFS            a903 NetBSD LFS            a904 NetBSD concatenated
a905 NetBSD encrypted      a906 NetBSD RAID           ab00 Apple boot
af00 Apple HFS/HFS+        af01 Apple RAID            af02 Apple RAID offline
af03 Apple label           af04 AppleTV recovery      af05 Apple Core Storage
be00 Solaris boot          bf00 Solaris root          bf01 Solaris /usr & Mac Z
bf02 Solaris swap          bf03 Solaris backup        bf04 Solaris /var
bf05 Solaris /home         bf06 Solaris alternate se  bf07 Solaris Reserved 1
bf08 Solaris Reserved 2    bf09 Solaris Reserved 3    bf0a Solaris Reserved 4
bf0b Solaris Reserved 5    c001 HP-UX data            c002 HP-UX service
ed00 Sony system partitio  ef00 EFI System            ef01 MBR partition scheme
ef02 BIOS boot partition   fb00 VMWare VMFS           fb01 VMWare reserved
fc00 VMWare kcore crash p  fd00 Linux RAID
Hex code or GUID (L to show codes, Enter = 8300): fd00
Changed type of partition to ‘Linux RAID’
Entering GPTPart::SetName(const UnicodeString…)

Al presionar L podemos visualizar los diferentes tipos de particiones seleccionables.

Para el propósito explicativo que tiene este artículo,  he seleccionado la opción fdoo correspondiente a Linux RAID ya que es pre-requisito para otros temas que abordaremos más adelante (el lector tendrá un criterio distinto, siempre de acuerdo a su necesidad). la opción por defecto es 8300 (Linux filesystem).

Ahora miraremos el listado de particiones con la opción p (print)

Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8437D185-3436-4B3F-AE60-93797A94CF2C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
1            2048      5860533134   2.7 TiB     FD00  Linux RAID

Ya tenemos nuestra partición. Procederemos a guardar los cambios con la opción w

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sda.
The operation has completed successfully.

Repetiremos este mismo proceso para el disco sdb (Nuestro Corsair de 500GB de Estado Solido) el cual, aunque vimos que se encuentra alineado, está usando una tabla de particiones MBR y nos interesa convertirlo a GPT (recordemos que GPT es 11% más eficiente que MBR).

Al finalizar nuestros cambios, el comando sfdisk -l deberá mostrar lo siguiente:

# sfdisk -l

WARNING: GPT (GUID Partition Table) detected on ‘/dev/sda’! The util sfdisk doesn’t support GPT. Use GNU Parted.

Disk /dev/sda: 364801 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/256/63 (instead of 364801/255/63).
For this listing I’ll assume that geometry.
Units = cylinders of 8257536 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+ 266305- 266306- 2147483647+  ee  GPT
/dev/sda2          0       –       0          0    0  Empty
/dev/sda3          0       –       0          0    0  Empty
/dev/sda4          0       –       0          0    0  Empty

WARNING: GPT (GUID Partition Table) detected on ‘/dev/sdb’! The util sfdisk doesn’t support GPT. Use GNU Parted.

Disk /dev/sdb: 364801 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/256/63 (instead of 364801/255/63).
For this listing I’ll assume that geometry.
Units = cylinders of 8257536 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+ 266305- 266306- 2147483647+  ee  GPT
/dev/sdb2          0       –       0          0    0  Empty
/dev/sdb3          0       –       0          0    0  Empty
/dev/sdb4          0       –       0          0    0  Empty

Qué maravilla! Nuestros 2 discos sda y sdb están perfectamente alineados, con GPT y sin mensajes expected-found.

Ahora podemos comenzar a trabajar con la espectacular gestión web de OpenFiler.

CONFIGURACIÓN DE ARREGLOS RAID EN OPENFILER

Si el lector aún no tiene conocimiento sobre arreglos RAID, puede documentarse visitando http://es.wikipedia.org/wiki/RAID

En nuestro OpenFiler vamos a configurar inicialmente 4 (cuatro) discos Corsair de 500 GB en un arreglo tipo RAID 1+0 (Mi favorito).

Tambien configuraremos 2 (dos) discos Toshiba de 3TB en un arreglo tipo RAID 1 (Espejo).

Recursos para realizar la implementación:

• Sistema Operativo OpenFiler que se encuentra instalado en una memoria Flash USB de 8GB en /dev/sda
• 2 discos Toshiba que se encuentran en /dev/sdb y /dev/sdc
• 4 discos Corsair que se encuentran en /dev/sdd , /dev/sde , /dev/sdf y /dev/sdg

CHUNK SIZE ¿CUAL ELEJIR? (1 – Lo que sucede en la PRÁCTICA)

Los arreglos RAID de OpenFiler se realizan POR SOFTWARE, no por Hardware.

Un RAID por Hardware siempre será más veloz en sus operaciones pero también más costoso ($$$) de implementar que un RAID por Software.

En la página http://louwrentius.com/linux-raid-level-and-chunk-size-the-benchmarks.html han realizado varios BENCKMARK bastante interesantes de arreglos RAID por Software en Linux.

De dicha página he extraido la siguiente imagen:

Según lo anterior, el chunk size más eficiente es 512KB. ¿Por qué? Yo supondría (no estoy seguro, ya que yo no realicé dicho benckmark) que esto sucede porque:

1. Los sectores físicos del disco duro usado en el benckmark tienen un tamaño de 512KB, y además
2. Los sectores lógicos de la partición del disco duro usado en el benckmark están correctamente alineados con los sectores físicos
3. Al elegir 512KB como el chunk size para el arreglo RAID 10 del Benchmark, estamos usando los mismos 512KB correspondientes al MIN-IO, PHY-SEC y LOG-SEC que obtuvimos en la sección VERIFICAR EL TAMAÑO DE LOS SECTORES FÍSICOS DE NUESTRO DISCO mediante los comandos » lsblk -t /dev/sda » y » hdparm -I /dev/sda «

Conclusión = Coincidimos en que tanto el MIN-IO del disco, como el PHY-SEC, el LOG-SEC y el Chunk Size elegido para el arreglo RAID corresponden al valor 512KB, en todos los casos. ¿No es esto un engranaje perfecto? El resultado, por lo que vemos en la imagen, es bastante bueno. No es raro que el comando mdadm –create (que veremos más adelante) asuma que 512KB es el tamaño por defecto para el chunk de un arreglo RAID cuando no se indica explicitamente un tamaño específico. ( The default when creating an array is 512KB. ver http://linux.die.net/man/8/mdadm )

Podemos usar el comando hdparm para verificar de manera sencilla la velocidad de lectura obtenida de un dispositivo de almacenamiento (un disco duro específico, una memoria Flash o nuestro arreglo RAID). Más adelante veremos como hacerlo.

CHUNK SIZE ¿CUAL ELEJIR? (2 – Lo que dice la TEORIA)

En el Chunk Size está el secreto del rendimiento de un arreglo RAID.

Debe elejirse a conciencia, dependiendo del uso que vaya a darse al RAID.

La regla general es:

• Muchas lecturas-escrituras: Chunks pequeños.
• Pocas lecturas-escrituras: Chunks grandes.
• Muchos usuarios concurrentes: Chunks pequeños.
• Pocos usuarios concurrentes: Chunks grandes.
• Para archivos grandes: usar chunks grandes.
• Para archivos pequeños: usar chunks pequeños.

Más concretamente:

Si vas a usar tu arreglo RAID para guardar archivos de varios GigaBytes, como imágenes ISO, archivos comprimidos de gran tamaño, videos, bases de datos SQL, archivos de disco de máquinas virtuales (como VDI, VMDK, RAW, etc) se recomienda usar tamaños de chunk superiores a 512 KB.

Si vas a usar tu arreglo RAID para guardar archivos de WORD, EXCEL, POWERPOINT, PDF, Imágenes y Fotografías de hasta 10MBytes (PNG, JPG, BMP), archivos de música de hasta 10 MBytes (MP3, WMA) se recomienda usar tamaños de chunk inferiores a 128 KB.

Uso híbrido (Archivos de todos los tipos y tamaños): Usa chunk de 256 KB.

Al respecto, véase:

http://www.zdnet.com/blog/storage/chunks-the-hidden-key-to-raid-performance/130
http://www.computerweekly.com/RAID-chunk-size-the-key-to-RAID-striping-performance

CREACION DE ARREGLOS RAID EN OPENFILER

Nuestros discos de Estado Solido marca Corsair son bastante veloces (lecturas y escrituras por el orden de 500MBytes/seg). Por este motivo, el primer arreglo RAID lo crearemos con estos discos. Mi predilección: RAID 10 (mirrored + striped). El RAID que más detesto: RAID 5 (por el bajo rendimiento generado al escribir la paridad y por el problema del Write Hole, vease http://sysnotas.blogspot.com/2013/01/los-arreglos-raid5-pueden-fallar.html )

OBSERVANDO A BAJO NIVEL LA SINCRONIZACIÓN DE NUESTRO RAID

La administración web de OpenFiler nos permite visualizar de manera sencilla los procesos de creación y sincronización de nuestros arreglos RAID. Sin embargo también es importante conocer cómo funcionan los arreglos RAID a bajo nivel usando la consola de Linux.

El archivo /proc/mdstat registra el estado de nuestro arreglo raid (bueno, defectuoso, sincronizando, etc)

A continuación vemos el proceso de sincronización de nuestro arreglo RAID 10 con 4 discos Corsair de 500GB… dice que demora 84 minutos.

# cat /proc/mdstat
Personalities : [raid10] [raid0]
md0 : active raid10 sdg1[3] sdf1[2] sde1[1] sdd1[0]
937698304 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
[>………………..]  resync =  0.2% (2033664/937698304) finish=84.3min speed=184878K/sec

La versión 2.99 de OpenFire, por algún motivo, impide crear arreglos del tipo RAID 1 [o sea el que pretendo crear con mis 2 discos Toshiba de 3TB (sdb y sdc) ]. Este dificultad está documentada en http://teratak-buluh.blogspot.com/2011/06/openfiler-299-attempted-to-create.html y en https://forums.openfiler.com/index.php?/topic/5405-openfiler-299-attempted-to-create-software-raid-1-array-failed/ y se soluciona reinstalando la utilidad mdadm desde el repositorio devel (ven ahora la importancia de conocer el funcionamiento de Conary?):

# conary update mdadm=openfiler.rpath.org@rpl:devel/2.6.4-0.2-1
Applying update job:
Update  mdadm(:runtime) (/openfileresa.rpath.org@esa:openfileresa-3.0/3.2.2-1-1 -> /conary.rpath.com@rpl:devel//openfiler.rpath.org@rpl:devel/2.6.4-0.2-1)
    Erase   mdadm:config=3.2.2-1-1
    Install mdadm:doc=2.6.4-0.2-1

Como puede observarse, hemos reemplazado la versión 3.2.2-1-1 existente por la anterior 2.6.4-0.2-1

Adicionalmente en http://www.everything-virtual.com/2011/04/openfiler-2-99-raid-creation-fix/ se sugiere ejecutar el siguiente comando para crear un acceso directo de la utilidad lvm en la carpeta /usr/sbin

# ln -s /sbin/lvm /usr/sbin/lvm

Luego de esto reiniciamos nuestra máquina y procedemos con la creación del arreglo RAID1 :

# reboot

A continuación vemos el proceso de sincronización de nuestro arreglo RAID 1 con 2 discos Toshiba de 3TB… dice que demora 300 minutos ( 5 horas !!! ) y también observamos que la creación de nuestro RAID 10 ha culminado.

# cat /proc/mdstat
Personalities : [raid10] [raid0] [raid1]
md1 : active raid1 sdc1[1] sdb1[0]
2930264383 blocks super 1.2 [2/2] [UU]
[>………………..]  resync =  0.2% (6134720/2930264383) finish=300.4min speed=162213K/sec

md0 : active raid10 sdg1[3] sdf1[2] sde1[1] sdd1[0]
937698304 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]

Una opción muy interesante es usar el comando watch y mirar en tiempo real las modificaciones de nuestro archivo mdstat

# watch -n 2 cat /proc/mdstat

VERIFICANDO LA VELOCIDAD DE LECTURA OBTENIDA DE NUESTRO ARREGLO RAID.

Mientras transcurren las 5 horas, aprenderemos a verificar de manera sencilla la velocidad de lectura de nuestro arreglo raid mediante el comando hdparm. Vamos a usar la opción –direct ( en algunas versiones debe escribirse –direct-io ) para efectuar las lecturas directamente desde la superficie del disco, sin pasar por la memoria caché que tienen los discos. (Nuestros discos Toshiba tienen, por ejemplo, 64KB de memoria caché).

Les mostraré los valores registrados por un disco Seagate de 400GB tipo PATA (Estandar anterior al Serial-ATA) y por un disco Samsung de 500GB tipo SATA II, ambos discos operan a 7200RPM.

# lshw -c disk

*-disk
description: ATA Disk
product: ST3400832A
vendor: Seagate
       logical name: /dev/sda
serial: 3NF154MX
size: 372GiB (400GB)

*-disk
description: ATA Disk
product: SAMSUNG HD501LJ
       logical name: /dev/sdb
serial: S0MUJ1EQ113403
size: 465GiB (500GB)

# hdparm -tT –direct /dev/sda

/dev/sda:
Timing O_DIRECT cached reads:   122 MB in  2.03 seconds =  60.04 MB/sec
Timing O_DIRECT disk reads: 206 MB in  3.01 seconds =  68.42 MB/sec

# hdparm -tT –direct /dev/sdb

/dev/sdb:
Timing O_DIRECT cached reads:  472 MB in  2.01 seconds = 235.21 MB/sec
Timing O_DIRECT disk reads: 150 MB in  3.02 seconds =  49.71 MB/sec

Ahora observemos la velocidad registrada por un (1) disco Corsair de Estado Solido:

# lshw -c disk

*-disk:1
description: ATA Disk
product: Corsair Force GS
logical name: /dev/sdg
size: 447GiB (480GB)

# hdparm -tT –direct /dev/sdg

/dev/sdg:
Timing O_DIRECT cached reads:   496 MB in  2.00 seconds = 247.72 MB/sec
Timing O_DIRECT disk reads: 752 MB in  3.00 seconds = 250.26 MB/sec

Miremos a continuación la velocidad registrada por /dev/md0 , correspondiente a nuestro arreglo RAID 10 con 4 discos Corsair de Estado Solido:

# hdparm -tT –direct /dev/md0

/dev/md0:
Timing O_DIRECT cached reads:  1060 MB in  2.00 seconds = 529.19 MB/sec
Timing O_DIRECT disk reads: 1578 MB in  3.00 seconds = 525.57 MB/sec

Las cifras son realmente espectaculares ¿no?

Pero el lector se preguntará:

Si son 4 discos ¿la velocidad de 4 discos no debería reportar ser 4 veces superior a la velocidad de 1 único disco?

Correcto! 4 discos son 4 veces más rápidos que 1 único disco, pero:

Al configurar un RAID 10 con 4 (cuatro) discos estamos usando 2 (dos) discos para balancear las transacciones de lectura y los otros 2 (dos) discos para balancear las transacciones de escritura.

Esta es la razón por la cual vemos que la velocidad de lectura SOLO se duplica, en vez de cuadruplicarse 🙂

¿Cuanta velocidad podremos obtener del arreglo RAID de nuestros 2 discos Toshiba de 3TB?

Las 5 horas de espera van en progreso.

En Cyberciti he encontrado un artículo sobre Cómo aumentar la velocidad de sincronización de un RAID por Software en Linux ( http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html ) sin embargo, debí leerlo antes de empezar a crear el RAID con los discos Toshiba. Queda como tarea para otra ocasión.

Mientras esperamos las 5 horas en cuestión también podemos verificar la temperatura de nuestros discos con el comando hddtemp.

Al comenzar este artículo, teniamos:

# hddtemp /dev/sda
/dev/sdb: TOSHIBA DT01ACA300 : 43 C

# hddtemp /dev/sdb
/dev/sdc: Corsair Force GS : 29 C

En este punto del artículo, nuestro servidor lleva 21 horas encendido y tenemos:

# hddtemp /dev/sdc
/dev/sdc: TOSHIBA DT01ACA300 : 47 C

# hddtemp /dev/sde
/dev/sde: Corsair Force GS : 37 C

Toshiba aumento 4 grados centigrados, mientras que Corsair aumento 8 grados.

Por fin… Acabo la sincronización del RAID 1 con los 2 discos Toshiba (sdb y sdc).

El resultado del hdparm para cada disco individual es el siguiente:

# hdparm -tT –direct /dev/sdb

/dev/sdb:
Timing O_DIRECT cached reads:   1034 MB in  2.00 seconds = 516.12 MB/sec
Timing O_DIRECT disk reads: 520 MB in  3.01 seconds = 172.91 MB/sec

# hdparm -tT –direct /dev/sdc

/dev/sdc:
Timing O_DIRECT cached reads:   1034 MB in  2.00 seconds = 517.01 MB/sec
Timing O_DIRECT disk reads: 558 MB in  3.01 seconds = 185.37 MB/sec

Ahora veamos el resultado del hdparm para el arreglo RAID 1 ( /dev/md1 ) conformado por ambos discos:

# hdparm -tT –direct /dev/md1

/dev/md1:
Timing O_DIRECT cached reads:   * in  * seconds = * MB/sec
Timing O_DIRECT disk reads: * in  * seconds = * MB/sec

http://www.bujarra.com/ProcedimientoOpenfiler.html

http://kb.open-e.com/How-can-I-connect-to-iSCSI-target-from-Linux-console_962.html

http://www.cyberciti.biz/faq/howto-setup-debian-ubuntu-linux-iscsi-initiator/

http://en.wikipedia.org/wiki/Advanced_Format

🙂