Sonrian ... SNAPSHOT

… Uno de los factores determinantes dentro de una arquitectura de almacenamiento es poseer mecanismos de protección datos, y que la recuperación de estos sea los más rápido y consistentes posibles y sobre todo que estos mecanismos no supongan una degradación del rendimiento y permita a los administradores gestionar estas tareas de una manera fácil.  

En este artículo explicaremos el concepto de SNAPSHOT, concretamente desde el punto de vista de NetApp, pero es importante tomar en cuenta que es un concepto genérico, es decir, cada fabricante de acuerdo a su arquitectura define SNAPSHOT de una manera diferente.

En general se denomina SNAPSHOT, a una foto, instantánea o imagen de un sistema de ficheros en un momento dado, para diferentes propósitos, sin necesidad de afectar la disponibilidad de los datos e incluso el rendimiento, uno de los propósitos de generar un snapshot es para respaldo de los datos o para realizar clonados de sistemas de ficheros para proteger los datos ante cambios que se pueden producir en ellos.

Por ejemplo, el concepto de Snapshot en VMWARE es realizar una copia de una máquina virtual específica, en este sentido los administradores de VMWare realizan Snapshots cuando se quiere realizar algún cambio sobre alguna máquina virtual y en caso de producirse algún problema, restaurar la máquina virtual a partir del Snapshot que se generó y así volver al estado anterior de la máquina virtual.

Desde el punto de vista de NetApp , es una imagen en un momento determinado del sistema de ficheros, se realiza a nivel de volumen, por tanto, cuando se realiza un snapshot se realiza una copia de la tabla de inodes del volumen, cuando un fichero es modificado dentro del volumen, Data Ontap copia los bloques antes de modificarse al espacio reservado para snapshots, apuntando los punteros de snapshot a los bloques no modificados, mediante esta técnica se consigue una copia fiable del sistema sin la necesidad de tener que copiar todos los datos, solamente los que se modifican. Se pueden generar hasta 255 snapshots por volumen.

Cuando se crea un volumen se reserva un espacio para los snapshots, y se puede visualizar (es configurable) una vez montado el volumen, concretamente en el directorio . /Snapshot, en el ejemplo vemos un volumen montado en una máquina de Linux y se lista los snapshots generados.

root@maquetas> cd .snapshot/

root@maquetas> ls

 

hourly.0   hourly.1   hourly.2   hourly.3   hourly.4   snapshot1  snapshot2

root@maquetas> ls -la

drwxrwxrwx   9 root     root        4096 Jan 20 20:00 .

drwxr-xr-x   6 root     root        4096 Jan 20 19:30 ..

drwxr-xr-x   5 root     root        4096 Jan 20 19:30 hourly.0

drwxr-xr-x   4 root     root        4096 Nov 17 13:39 hourly.1

drwxr-xr-x   4 root     root        4096 Nov 17 13:39 hourly.2

drwxr-xr-x   4 root     root        4096 Nov 17 13:39 hourly.3

drwxr-xr-x   4 root     root        4096 Nov 17 13:39 hourly.4

drwxr-xr-x   4 root     root        4096 Nov 17 13:39 snapshot1

drwxr-xr-x   4 root     root        4096 Nov 17 13:39 snapshot2

 

La generación de los snapshots se pueden programar en las siguientes periodicidades.

§  Weekly: Se realizan todos los domingos a medianoche.

§  Nightly: Se realizan todos los días a medianoche.

§  Hourly: Se realizan a las horas programadas.

En el ejemplo mostramos una configuración de snapshots programados a través del comando “ snap sched “

Snap sched 1 2 6@8,12,16,20

Donde

1    Nº de snapshots “Weekly” que se guardan

2    Nº de snapshots “Nightly” que se guardan

6    Nº de snapshots “Hourly” que se guardan

8, 12, 16, 20 Horas a las que se realizan los snaps “Hourly”

Esta programación se puede realizar a través del Oncommand System Manager, que es la herramienta grafica de NetApp utilizada para administrar la cabina de NetApp.

A continuación explicaremos, para entender mejor el comportamiento de los snapshots la salida del comando “snap list” , esto nos ayudará a definir una buena configuración de snapshots.

Supongamos que al listar nuestros snapshots nos aparece la siguiente salida

 %/used             %/total            date                  name

     

31% (31%)    0% ( 0%)            Mar 08 00:00                     nightly.0

47% (29%)    0% ( 0%)            Mar 07 20:00                     hourly.0

57% (32%)    0% ( 0%)            Mar 07 16:00                     hourly.1

64% (29%)    0% ( 0%)            Mar 07 12:00                     hourly.2

69% (32%)    0% ( 0%)            Mar 07 08:00                     hourly.3

73% (29%)    0% ( 0%)            Mar 07 00:01                     nightly.1

76% (30%)    0% ( 0%)            Mar 06 20:00                     hourly.4

78% (31%)    0% ( 0%)            Mar 06 16:00                     hourly.5

La columna % used nos muestra el espacio consumido por los snapshots dividido por los bloques utilizados en el volumen, no toma en cuenta si ese espacio es utilizado por el filesystem o snapshots, el primer número es acumulativo para todos los snapshots de la lista, el segundo para el % usado por el snapshot específico.

La columna % total muestra el espacio consumido por los snapshots dividido por el espacio total de disco en el volumen, esto incluye el espacio de datos + espacio reservado para los snapshots incluye todo los bloques usados y libres, si el espacio total del volumen es 100 GB y el espacio consumido por snapshots son 60 MB el cálculo sería < 1% , por tanto nos mostraría 0% tal y como muestra la salida del ejemplo.

Por tanto, la variación de estos valores dependerá de los bloques nuevos, modificados y borrados, dicho esto, si la cantidad de datos varia entonces el % total seguirá siendo el mismo , pero el % used variará, si al contrario la tasa de cambio se mantiene constante, pero el volumen se aumenta o se reduce, entonces el % Total cambiará y el % used seguirá siendo el mismo.

Estos datos son útiles analizarlos, para concluir que cuando se tienen una gran cantidad de datos de snapshots y el espacio libre es alto, se debe de incrementar el % de reserva para snapshots y cuando el espacio libre es bajo, entonces se debe aumentar el tamaño del volumen, de la misma forma el valor del % total nos puede indicar si el porcentaje reservado para los snapshots es insuficiente, y si se ha desbordado el espacio de los datos en el volumen, si se tiene un periodo de retención grande estos datos determinarán hasta cuanto se debe aumentar de tamaño el volumen.

Por último, si se decide eliminar snapshots, ejecutar antes los siguientes comando “snap delta” y snap “reclaimable” para tener una idea que snapshots eliminar.

En conclusión, es importante definir una buena política de retención y reserva de los snapshots tomando en cuenta la variación de los datos almacenados en el volumen, en la práctica, muchas veces nos encontramos sin espacio en el volumen debido a una mala definición de la configuración de los snapshots.

Bueno amigos, espero que este articulo les haya sido de utilidad.

Hasta pronto

TICjob.es

Les dejo un Portal para encontrar empleo en Tecnología de la Información

Factores de fiabilidad de los Discos

....  Una de las cuestiones más recurrentes en todo sistema de almacenamiento es como sabemos la fiabilidad de nuestro hardware, ya que como todo en la vida las cosas se degradan por su uso y los discos no son la excepción, por lo general en cuanto a unidades de discos el tiempo de vida es de 5 años, algunos fabricantes incluso toman como referencia este dato para establecer sus coberturas de garantía.

En este artículo veremos  los factores y como miden por lo general esa fiabilidad los fabricantes de almacenamiento.

Estos factores se aplican para unidades de discos pero también son útiles para cualquier elemento de hardware.

MEAN TIME BETWEEN FAILURES (MTBF)

Se mide el tiempo de vida de un dispositivo de hardware, es la forma menos precisa para medir este factor, ya que por lo general los fabricantes no esperan toda la vida del dispositivo para realizar esta medición, por tanto el dato se obtiene de la tasa de fallo durante el tiempo de vida esperado por el dispositivo.

La formula sería la siguiente

MTBF = test duration * # of drives tested / # of drives that failed during testing

Los valores de MTBF más comunes de los dispositivos de discos de tipo SSD , SATA, SAS y FC son

Discos SSD                   2.0 millones de horas

Discos SAS y FC          1.6 millones de horas

Discos SATA                1,2 millones de horas.

Como hemos mencionado la garantía de los discos normalmente es de 5 años (43,800 horas), como ven, hay una notable diferencia con los valores descritos, por tanto el valor de horas por año sería 43,800 / 5 como resultado tenemos 8,760

Tomando estos valores  podemos obtener por cada tipo de disco el porcentaje de fallos por año.

Discos SATA

1200,000 horas MTBF / 8,760 horas por año = 136,9863

1 fallo / 136.9863 = 0,00730 * 100 = 0,73 % fallos por año

Discos FC – SAS

1600,000 horas MTBF / 8,760 horas por año = 182,6484

1 fallo / 182.6484 = 0,00547 * 100 = 0,55 % fallos por año

Discos SSD ( Estado sólido )

2000,000 horas MTBF / 8,760 horas por año = 228.3105

1 failure / 228.3105  = 0,00438 * 100 = 0,44 % fallos por año

Por tanto podemos calcular 40 drives SAS

40 SAS Drives * 0,55 % = 0,22 fallos /años * 5 años = 1,1 fallos en 5 años

AVERAGE RETURN RATE (ARR)

Se basa en la tasa de rendimiento real que ofrece un dispositivo que está en uso, el problema es que no distingue que los dispositivos hayan sido retornados debido a falsos positivos, o razones que no tienen que ver con algún error.

AVERAGE FAILURE RATE (AFR)

Es la medida más precisa de fiabilidad debido a que se basa en la devolución y en su verificación del fallo del dispositivo, pero se calcula en el tiempo con lo cual resulta difícil su medición por los fabricantes.

En resumen, estos valores son teóricos y por tanto llevados a la realidad no son exactos, ya que la degradación de los dispositivos está supeditada a muchos factores dentro de una arquitectura de almacenamiento, pero podemos concluir que dependiendo la tecnología de los discos unos son más fiables que otros, factor importante que influye en el coste de los mismos.

Espero que este artículo les haya sido de utilidad.

Hasta pronto….

VMware on NetApp Overview (video)

STORAGECONSEJOS . Documentación necesaria

..... Esta sección la he llamado “storageconsejos”  en ella iré exponiendo  algunos consejos que por mi experiencia me han servido para implementar cualquier solución que integra diferentes tecnologías, no es necesario aplicarlos para alcanzar el éxito en cualquier proyecto pero si considero que su aplicación nos ahorraría muchos dolores de cabeza al momento de su implementación.

Revisar estos tres documentos fundamentales para empezar una correcta implementación “Release Notes” , la “ Comptability Matrix” y “Best Practices”, la información descrita en estos documentos nos ayudará a determinar si tendremos algún problema al momento de integrar las soluciones de los fabricantes que intervendrán en nuestro diseño.

A continuación describiremos que información podemos encontrarnos en estos documentos.

Release Notes .  Es un documento donde se explica que nuevas funcionalidades o características vamos a encontrar en la versión que vamos a instalar, un dato importante que nos podemos encontrar en este documento son las limitaciones de funcionamiento que tiene la versión así como también que  errores o problemas soluciona con respecto a las versiones anteriores.

Comptability Matrix.- Esta información es de vital importancia al momento de realizar el diseño y la implementación de un proyecto, la no verificación de la compatibilidad del software o hardware utilizado nos puede llevar a tener problemas e incidencias de difícil solución y lo que es peor que el fabricante no “soporte” esta implementación al no cumplirse la compatibilidad de sus productos que se integran en cualquier diseño.

Best Practices .- La revisión de las mejores prácticas recomendadas por el fabricante nos ayudará a realizar un diseño más óptimo de nuestra arquitectura, estas consideraciones recomendadas por los fabricantes es de suponer que han sido debidamente testeadas o aplicadas, no obstante hay que señalar que estas recomendaciones en algunos casos no se aplican porque también depende de los requerimientos de la solución a implementar.

Bueno amigos, espero que este consejo les haya sido de utilidad.

Hasta pronto….

VCENTER Físico o Virtual.

…. Cuando estamos en las tareas previas para empezar a diseñar una infraestructura virtual basado en VSphere VMWARE una duda que siempre nos asalta es si instalamos el VCenter en una máquina física o en una Virtual, tomando en cuenta lo importante que este elemento supone, la respuesta no queda del todo respondida debido a que en parte depende de cada entorno y de los puntos de fallo que podamos encontrar en hacerlo de una manera u otra, por tanto aquí describimos unos TIPS a tomar en cuenta que pueden ayudarnos en esta decisión.

La primer pregunta que nos debemos de hacer es ¿Qué pasa si nuestro VCENTER falla?

·        La alta disponibilidad HA sigue funcionando ya que solamente se requiere el VCenter para configurar esta funcionalidad

·        VMware VMotio n y Storage VMotion requieren del VCENTER sin embargo si antes se ha ejecutado una tarea de estas funcionalidades no se verá afectada.

·        DRS y DPM solamente funcionan con el VCenter activo , debido a que son necesarios  los datos que están en la base de datos de VCenter .

·        Los templates también son manejados por el VCenter

·        El acceso a los históricos, estadísticas de los ESX´s de la plataforma no se podrán consultar sin el VCenter activo

·        Una de las características que gestiona el VCenter son los switches distribuidos aunque una parte de la configuración de los mismo se guarda en cada uno de los Hosts , las funcionalidad de los switches distribuidos dejaran de operar, por eso es probable que si nuestro VCenter tiene la red en un switch distribuido no tengamos acceso al VCenter, para entornos grandes que se disponen de NICs suficientes se configura la parte de red del VCENTER en switches Standard con lo cual se tendría una configuración híbrida.

Uno de los puntos importantes en nuestro diseño es por tanto determinar como protegemos nuestros VCenter, es aquí donde toma vital importancia el tema de virtualizarlo, ya que gozaríamos de todos los mecanismos de alta disponibilidad y recuperación de toda la plataforma de virtualización al ser una máquina más dentro del entorno, otra alternativa es almacenar la base de datos del VCenter en por ejemplo nuestro entorno de base de datos de producción sea SQL u ORACLE, por otroa lado también VMWare nos ofrece el producto VMWare Heartbeat, o también considerar activar el FT (fault Tolerance) en la máquina de VCenter sin embargo habría que considerar pro y contras de activar la funcionalidad de Fault Tolerance.

Ventajas y desventajas de VCenter Fisico

·        El VCEnter al estar fuera de la infraestructura virtual no tendría que competir con los recursos de las otras máquinas que se encuentran en el entorno, generalmente se reserva a través de los Resource Pools valores determinados para garantizar la alta disponibilidad.

·        Si falla un Host (ESX) tendremos acceso inmediato al VCenter sin necesidad de esperar a que el HA del entorno de virtualización actúe.

·        Se necesita de un servidor físico para instalar el VCenter

·        Los métodos de backup son más complejos tanto del Sistema Operativo de la máquina como de la base de datos de VCenter

·        Un Servidor físico está más expuesto a fallos de hardware .

·        Las tareas de mantenimiento y actualizaciones son más costosas y en caso de fallo los procedimientos de recuperación son más costosos .

Ventajas y desventajas de VCenter Virtual

·        No requerimos de un servidor físico para instalar el VCenter

·        Al fallar el ESX donde este el VCenter a través de HA tendríamos la recuperación de la máquina rápidamente.

·        Se aprovechan los mecanismos y procedimientos de BAckup de toda la infraestructura virtual para respaldar el VCenter.

·        Si tenemos VMotion, podemos mover en “caliente” nuestro VCenter  a otro servidor en caso de que necesite más recursos de hardware.

·        El VCenter estaría compitiendo con las otras máquinas virtuales por los recursos del Host (ESX) o Cluster.

En conclusión si tenemos todos las funcionalidades a nivel de alta disponibilidad, balanceo y mecanismos de respaldo y recuperación además de un almacenamiento remoto lo más recomendable es hacerlo virtual, si no tenemos estas funcionalidades y disponemos del hardware necesario y de un hardware limitado a nivel de recursos en los ESX´s lo mejor es instalarlo en una máquina física.

Espero que este artículo les haya sido de utilidad.

Hasta Pronto……

NETAPP Innovación Tecnológica de Almacenamiento

NETAPP ( Netwok Appliance ) es uno de los fabricantes lideres en almacenamiento, creado hace 20 años ofrece una amplia gama de cabinas de almacenamiento que denomina FAS (Fabric Attached Storage) combinando arquitecturas  de tipo NAS y SAN en una sola cabina a través de los diferentes protocolos de acceso a los datos.

El equipamiento de NetApp ejecuta el Sistema Operativo Data Ontap desarrollado para optimizar funcionalidades de almacenamiento a bajo y alto nivel, este sistema operativo se encuentra instalado en cada una de las controladoras que conforman la arquitectura y es propietario de NetApp.

El Data Ontap gestiona las diferentes bandejas de discos de tecnologías SATA, SAS, FC, SSD,  etc , ofreciendo dos niveles de raid denominados RAID4 y RAIDDP que ofrecen una alta disponibilidad de los datos y a su vez optimiza operaciones tanto de lectura como escritura a nivel de IOPs a través de la NVRAM que permite un rápido acceso a los datos si necesidad de esperar la escritura en disco de las diferentes aplicaciones.

Los FAS de NetApp  están diseñados para trabajar en modo Cluster Activo / Activo, por tanto, ofrece una alta disponibilidad en caso de cualquier fallo de las controladoras que conforman la arquitectura de almacenamiento a través de mecanismo de failover (takeover – Giveback), ofreciendo niveles de tolerancia a fallos y  facilidad para realizar tareas de mantenimiento  sin necesidad de detener los servicios.

A través de sus diferentes productos NetApp provee almacenamiento a otras tecnologías como son base de datos, Virtualización, correo y mensajería y servicios de ficheros de las organizaciones a través de mecanismos  que permiten tener  acceso rápido, eficiente y sobretodo protegido a los datos dentro de una empresa.

Cada vez más la tendencia de NetApp es integrar sus productos y soluciones a los principales fabricantes de otras tecnologías como son CISCO , VMWARE, SYMANTEC, CITRIX, MICROSOFT y así ofrecer mayores funcionalidades para el aprovisionamiento de almacenamiento a todas las aplicaciones y servicios de cualquier organización.

En futuros artículos mostraremos en detalle la arquitectura de NetApp y las funcionalidades y productos que ofrece actualmente.

Almacenamiento y Virtualización van de la mano

… Actualmente en el sector de TI , la tendencia cada vez más es la de Virtualizar los diferentes entornos y aplicaciones de una organización, esto permite a los departamentos de TIC optimizar tareas de administración, centralizar cada vez más los elementos de su centro de datos y lo más importante, ahorrar espacio y tiempo de mantenimiento de sus servidores.

Pues bien, toda arquitectura de virtualización necesita un almacenamiento remoto o local, por tanto es indispensable tener un repositorio o “datastore” para almacenar la configuración de las máquinas virtuales, que al fin y al cabo son ficheros que emulan dispositivos de una máquina física. Es por eso que cada vez más los fabricantes de Hypervisores (VMWARE, CITRIX, HYPER-V, ORACLE), desarrollan herramientas y funcionalidades capaces de integrar cada vez más su software a su almacenamiento, y a su vez los fabricantes de sistemas de almacenamiento también desarrollan aplicaciones con la finalidad de facilitar la administración y gestión de toda su infraestructura, así pues, podemos ver alianzas entre fabricantes como NETAPP (Storage) que ha desarrollado herramientas para integrarse con  VMWARE (Virtual Storage Console) o con CITRIX (Citrix Storage Link), que permiten desde una única consola de administración gestionar el almacenamiento para poder realizar tareas de aprovisionamiento, dimensionamiento, backup y recuperación de datos de una manera más optima y sobretodo rápida.

Por tanto, los fabricantes de almacenamiento invierten mucho en ofrecer a sus clientes mecanismos que sean cada vez más óptimos y sobretodo que garantice una disponibilidad total de los datos y en caso de pérdida de estos una recuperación casi inmediata porque en TI la falta de disponibilidad de las aplicaciones se refleja después en dinero.

A continuación les detallo los puntos a tener en cuenta respecto a almacenamiento en una infraestructura virtual.

1.- Determinar el hypervisor a utilizar (Vmware, Xen Citrix, Oracle , Hyper V, Red Hat , etc ) , si hablamos meramente de aspectos técnicos (no costes), es necesario evaluar la integración de estos fabricantes de virtualización con los de almacenamiento (NetApp, EMC, HP, etc).

2.- Métodos de acceso al almacenamiento, es decir, utilizar NAS o SAN, o ambos, en este punto es importante saber si nuestro almacenamiento soporta ambos métodos de acceso.

3.- Tener un sistema de backup que permita respaldar y restaurar lo más rápida y eficiente posible, aunque los fabricantes de almacenamiento proveen mecanismos de backup, por ejemplo NetApp a nivel de los Snapshots es importante tener un sistema de backup que nos permite guardar los datos en cinta o disco independientemente de los métodos de recuperación de la cabina de almacenamiento.

4.- Tener una herramienta de gestión que permita al administrador realizar tareas de administración y mantenimiento de toda la infraestructura virtual lo más óptima posible, si la parte de virtualización y almacenamiento se integran en una sola consola mejor.

5.- Tener una herramienta de monitorización y de alarmas, como por ejemplo NAGIOS,  que nos permita saber en todo momento como se encuentra nuestro almacenamiento en términos de espacio y de rendimiento esto nos evitará tener que lamentarnos después si toda nuestra infraestructura deja de dar servicio por el simple hecho de no tener espacio suficiente para almacenar y ejecutar las aplicaciones.

6.- El almacenamiento nos debe de ofrecer niveles de RAID (Redundant Array of Independent Disk) que nos permita tener mecanismos de alta disponibilidad de los datos , así como también de tolerancia a fallos.

7.- Por último y no menos importante es la seguridad y disponibilidad de nuestros datos, al evaluar cualquier sistema de almacenamiento éste nos debe de proveer mecanismos de seguridad de los datos que se almacenan en él.

En resumen, si usted está pensando en virtualizar su centro de datos no olvide que un elemento crítico en todo su diseño es sin duda el almacenamiento y sobretodo como acceder a él, en el artículo tecnologías de almacenamiento de este blog, podemos ver las diferentes formas de acceder a los datos, sin embargo, cada aplicación de acuerdo a sus requerimientos determina la tecnología de acceso a implementar.

En posteriores artículos explicaremos las diferentes formas de provisionar almacenamiento a nuestra infraestructura de virtualización.

Hasta Pronto.

Tecnologías de Almacenamiento

…. Ya estamos aquí nuevamente, en este artículo describiremos algunos conceptos y términos básicos de las tecnologías utilizadas en toda arquitectura de almacenamiento, es importante entender estos conceptos ya que los emplearemos a medida que entremos en más detalle explicando las diferentes tecnologías.

Explicaremos las tres principales tecnologías de almacenamiento DAS  (Direct Attached Storage), NAS (Network Attached Storage) y SAN (Storage Area Network).
Son tecnologías que a través de sus diferentes protocolos, métodos accesos y hardware nos permiten acceder a los datos de cualquier dispositivo o cabina de almacenamiento.

Conociendo al Disco Duro

… Como dice la canción “ …  El siempre creyó que un disco duro era un disco de metálica …. “. Bromas aparte, en todo almacenamiento lo más importante es el o los discos donde irá almacenada la información independientemente del tipo, uso y como se acceda a él, es importante conocer las principales características de los discos duros, eso nos llevará a poder elegir qué tipo de información guardamos en los discos tomando en cuenta las aplicaciones que utilizarán este almacenamiento.

En este artículo veremos que no solamente es importante cuanta capacidad tenga el disco duro sino que es necesario conocer otras características para poder elegir el mejor sistema de almacenamiento.

Tamaño o Capacidad

Es la cantidad de información que se puede guardar en un disco duro, la unidad de medida es el Byte y actualmente ya hemos llegado al orden de los teras.

Velocidad de Rotación (RPM)

Se refiere a la velocidad con la que gira el o los platos del disco duro, donde se almacenan magnéticamente los datos, por tanto a mayor velocidad de rotación, mayor cantidad de transferencia de datos, pero también aumentará el ruido, es la característica que indica si un disco es rápido o lento.

Tiempo de acceso

Característica medida en milisegundos , indica el  tiempo promedio que tarda la cabeza del disco en acceder a los datos que estamos consultando, es el conjunto de las siguientes velocidades, como son el tiempo que tarda un disco buscar sectores en donde se encuentra nuestra información.
Frame Buffer (Cache)

La poseen todos los discos, es la memoria en donde se guardan los últimos sectores leídos, hoy en día llega hasta los 16 MB, y influye directamente al rendimiento, lo más optimo es tener un “cache” amplio en el disco.

Tasa de Transferencia (Transfer Rate)

Se refiere a la cantidad de datos que un disco puede leer y escribir en el plato de un disco se mide en Mbits/seg .

Tipo de Interfaz (IDE – SCSI – SATA I /II – SAS - FC ).

Por Tipo de Interfaz no referimos a la forma como se conecta el dispositivo, los más comunes son los IDE que llega al 133MB/s, tenernos también las SCSI , pasando también por SATA y SATA II que alcanza una velocidad de transferencia de 300 MB/s, entre las más costosas están las de tipo SAS y las de tipo FC.

 En resumen,  en el eterno problema del rendimiento de las aplicaciones influyen muchos elementos uno de ellos es sobre que tipo de disco está “corriendo”, en articulo posteriores explicaremos herramientas que nos permitan medir estos valores de una forma más exacta.

Hasta la próxima ……

Implementación de RAID - DP en NetApp

....

NetApp por defecto utiliza un nivel de raid denominado RAID-DP para garantizar la protección de datos y tolerancia de fallos, a continuación explicaremos como trabaja este nivel de RAID propietario de NetApp ,también hemos de comentar que además de RAID-DP NetApp ofrece un segundo nivel de RAID como es RAID4, en este artículo también haremos mención a este nivel de RAID.

RAID-DP, como se ha mencionado, es propietario de NetApp, se implementó a partir de la versión de  6.5 de DataOntap , este nivel de RAID aumenta la tolerancia de fallos permitiendo el fallo de dos unidades de discos dentro de un raidgroup, explicaremos en detalle cómo trabaja RAID DP, el método de recuperación ante fallo de discos.

¿Por qué implementar RAID DP?, la respuesta radica en el hecho de mejorar la tolerancia a fallos, debido también al creciente aumento de capacidad que han venido experimentando las unidades de discos, el aumento de errores en discos grandes, y por supuesto mejorar la fiabilidad.

El concepto de RAID que utilizan paridad a pesar de todos los niveles existentes y  de diferentes fabricantes es el mismo, es decir, un raid te permite que ante el fallo de una unidad de disco simplemente se recrean los datos de paridad y los discos restantes en la matriz o volumen de un disco de repuesto “spare”.

RAID-DP es una evolución de RAID4 que almacena los datos en filas horizontales, calculando la paridad para los datos de la fila, una vez calculada almacena esta paridad en un disco llamado de paridad dentro de un raidgroup, por tanto a nivel de Raid group RAID-DP añade un segundo disco de paridad , con lo cual, mientras un disco de paridad de un volumen con RAID4 almacena los datos de los discos en fila RAID-DP además de los discos en fila almacena en su otro disco de paridad los datos de los discos en diagonal, con lo cual combina la protección horizontal tradicional (RAID4) y la protección diagonal lo que permite tener tolerancia de fallos de hasta dos discos, esto indica que RAID4 se incluye dentro del funcionamiento de RAID DP.

Para entender mejor estos conceptos les detallo un ejemplo.

En el diagrama se observa un RAID4 tradicional que utiliza la paridad de fila con 4 discos de datos, las filas representan los bloques estándar de 4 KB que emplea RAID4, en este ejemplo la paridad se calcula sumando los valores de cada uno de los bloques horizontales obteniendo el valor de paridad (3 + 1 + 2 + 3 = 9 ).  Por tanto, si fallase un disco, el proceso que se utiliza simplemente se invierte , por ejemplo si el primer disco fallase RAID4 tiene que recrear el valor de datos en ese caso 3 , el cálculo sería (9 - 3 - 2 – 1 = 3), se recrearía a partir de un disco de “spare”.

Ahora bien en el caso de RAID-DP como se ha mencionado añadimos un disco para DP (Doble paridad) tal y como indica la figura.

En el caso de RAID-DP la suma diagonal se almacena en el segundo disco de paridad (1 + 2 + 2 + 7 = 12). Debemos tomar en cuenta que el cálculo de la paridad diagonal incluye un elemento de la paridad de fila como parte de la suma de paridad diagonal.

En la figura se puede ver mejor este concepto.

Ahora explicaremos el proceso de reconstrucción en RAID DP, así pues simulamos el fallo de dos discos

Cuando se activa la reconstrucción del disco en primer lugar RAID-DP busca la cadena en el que se inicia

la reconstrucción . En este caso la primera franja de paridad diagonal es la diagonal azul, con 4 cuatro de los

Cinco elementos disponibles RAID-DP es capaz de realizar la reconstrucción. Los datos han sido recreados utilizando

El siguiente cálculo (12 - 7 - 2 – 2 = 1).

Continuando con la reconstrucción RAID-DP (paridad de fila) en la misma cadena para determinar otras reconstrucciones, ya que ha

reconstruido el primer elemento del segundo disco.

Veamos por tanto las siguientes reconstrucción de la misma manera que la primera .

Quedando finalmente la reconstrucción y recuperación total del raidgroup

Con este ejemplo hemos intentado explicar el funcionamiento de RAID-DP cuando se produce el fallo de dos discos dentro del raidgroup, cabe indicar que la rapidez de la reconstrucción dependerá de la cantidad de discos que forman el raidgroup y también del tamaño y tecnología de los discos.

En cuanto a rendimiento de RAID-DP éste puede ser 2% o 3% solamente más lento que RAID4 este aumento se produce porque necesita escribir en un disco adicional que es el segundo de paridad, en cuanto a CPU no hay ninguna diferencia de rendimiento.

Por último, comentar que para hacer un RAID-DP se necesitan por lo menos 3 discos ( 1 de Datos y 2 de paridad) , y que es posible de una manera sencilla sin disrupción de servicio pasar de RAID4 a RAID-DP más no es posible el proceso contrario.

Espero que este artículo haya sido de utilidad sobre todo para entender cómo trabaja RAID-DP dentro de la arquitectura de NetApp.

Hasta pronto