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