Mostrando entradas con la etiqueta Almacenamiento. Mostrar todas las entradas
Mostrando entradas con la etiqueta Almacenamiento. Mostrar todas las entradas

viernes, 30 de marzo de 2012

Sub-LUN Tiering

Ahora si el mercado y tecnología de Storage se ha puesto interesante, el caso es que los desarrolladores de almacenamiento se estan poniendo las pilas y nos han sorprendido con una propuesta que promete bastante, se trata del tiering de almacenamiento, pero a nivel sub-lun.

Es decir, anteriormente moviamos toda una LUN de una capa a otra capa, sin embargo, estadisticamente la informacion no es requerida en la misma proporcion, dicho de otra forma, hay secciones de la informacion, por ejemplo indices, que son frecuentemente accedidos, mientras que hay otras partes de la informacion, como datos historicos que son poco o nada accedidos.

Tipicamente usamos el storage de alto rendimiento para bases de datos, y las bases de datos cuando menos tienen tablas, donde se guardan los datos; indices, que son apuntadores a los datos dentro de tablas; bases de datos temporales; archivos de registro log, etc.

El asunto de meter TODA la base de datos en disco premium, por ejemplo, estado sólido es costoso, asi que SUB-LUN tiering viene a hacer el trabajo por nosotros.

Primero hace un monitoreo, para saber cuales secciones de la informacion tienen mas acceso, una vez que hay estadisticas, mueve los datos con mas acceso a capas de disco superiores, por ejemplo a estado solido. De esta forma se incrementa dramaticamente el desempeño percibido de la base de datos, porque normalmente los indices, logs, tempDB son los datos que causan cuellos de botella en las transacciones.

Un sistema de Sub-LUN Tiering normalmente puede hacer el monitoreo de manera autonoma (no tan recomendable) o a solicitud del administrador, por ejemplo, imaginemos que en todo el mes la DB se comporta de una forma, pero al cierre del mes queremos acelerar el proceso. Monitoreando solo el proceso de cierre nos permite acelerarlo para el proximo mes, aunque la DB se comporte normalmente el resto del tiempo.

El movimiento de datos se lleva a cabo en pequeñas secciones, algunos como 3Par les llaman chunklets, la capacidad de estos bloques varia de fabricante a fabricante, pero se encuentran tamaños de 42MB para el HP P9500 y de 256MB para la familia 3Par. Se clasifican en Hot chunklet, warm chunklet y cold chunklet, dependiendo de la frecuencia de acceso y ello determina si es conveniente moverlos a una capa de mayor o menor rendimiento.

La tecnologia es llamada por nombre depende de cada quien pero EMC le llama FAST, HP-3Par le llama Adaptive Optimization en la familia 3Par y Smart Tiers en la familia P9000.

Sobre cual implementacion es mejor... aun no me atrevo a hacer pronostico, pero la de 3Par es muy interesante.

martes, 27 de marzo de 2012

Storage Tiering

OK, cada vez que se le pone mas inteligencia a los sistemas de computo es para facilitarnos la vida, claro, si sabemos como utilizar las nuevas mejoras, de otra forma sera un pesadilla.

Storage Tiering no es la excepción.

Empecemos por precisar a que nos referimos con "tiering".
En los dias antiguos nos bastaba con tener espacio de almacenamiento y lo mediamos por GB (o MB), esto debido a que el procesador era nuestra principal preocupación, cuando el procesador dejo de ser el problema nos enfocamos en los IOPS

Input Output Per Second (IOPS) es la unidad de medida para saber cuantas operaciones de lectura/escritura es capaz de realizar nuestro subsistema de almacenamiento. Sobra decir que entre mas IOPS mejor.
Ahora el tener mas IOPS siempre ha sido directamente proporcional al monto de la inversion, y sabemos que a mayor numero de discos en un arreglo, mayor rendimiento, suponiendo que los discos son iguales, pero y si son diferentes?

Existen discos de 5.4K, 7.2K 10K 15K etc. asi que la medida correcta es mas compleja, porque mientras los discos de 15K son mas rapidos, tambien son mas caros y por el mismo presupuesto podríamos adquirir mas discos de 10K y lograr en ciertos escenarios un mayor rendimiento que con discos de 15K. Aunque nuestro foco actual es el Tiering.

Tiering es la calificacion cualitativa de un subsistema de disco
por ejemplo, un Tier 1 se refiere a disco rapido, confiable apto para cargas de trabajo importantes que demandan tanto alto rendimiento como confiabilidad, tipicamente, bases de datos y sistemas centrales, aqui un ejemplo de las capas y su asociacion tipica con tecnologias de disco que los conorman:


  • Tier 0 - Estado Sólido
  • Tier 1 - Discos en arreglo SAN tipo SAS o FC de 15K
  • Tier 2 - Discos en arreglo SAN tipo SAS o FC de 10K
  • Tier 3 - Discos en arreglo SAN tipo SATA

Como es facil notar, conforme nos acercamos al Tier 0 el precio que hay que pagar se incrementa, por eso hay que cuidar de poner los datos adecuados y no consumir espacio sin motivo.

Los arreglos actuales (al menos los mas inteligentes) proveen un metodo de movimiento de los datos en una LUN entre los distintos Tiers del arreglo, por ejemplo, un HP EVA es capaz de mover una LUN de disco SATA a disco SAS de 15K sin que el servidor host se vea afectado mas que por el desempeño incrementado que le da esta nueva configuracion, a esta capacidad de movimiento de los datos le llamamos "Storage Tiering".
La capacidad de mover los datos de discos lentos a rapidos o viceversa tiene varios beneficios, pero el principal es el de poder probar donde obtenemos el rendimientos que necesitamos al menor precio, naturalmente siempre querremos el maximo rendimiento, pero entonces debemos estar dispuestos a desembolsar el maximo de dinero,

Con las unidades de estado solido obtenemos un rendimiento fabuloso, pero hay que utilizarlo cuidadosamente, para esto nos ayuda storage tiering, para poder colocar datos y moverlos hasta obtener el rendimiento adecuado, tipicamente pondriamos en unidades de estado sólido los datos con mayor tasa de utilizacion, en Tier 1 y 2 los datos frecuentes y el Tier 3 los historicos o poco accedidos.

martes, 6 de marzo de 2012

Thin or not to Thin (1.1)

Aparentemente mis amigos de Blogger han sufrido problemas tecnicos y la entrada anterior llamada "Thin or not to thin" se ha perdido, no pretendo reescribirla tal cual pero hare mi mejor esfuerzo, ya que no contaba con un respaldo (lo sé, es una vergüenza).

Pero el asunto es el de Thin Provisioning (ThP); podriamos definirlo con el siguiente enunciado: El administrador de Servidores es engañado por el administrador de almacenamiento, pero y si son la misma persona?

Normalmente cuando tenemos un almacenamiento en SAN, compartimos el almacenamiento total disponible entre los servidores (hosts) que necesitan el espacio util, como ejemplo, si tenemos un arreglo en SAN con una capacidad util de 10TB y tenemos 10 servidores a los cuales les queremos dar un total de 1TB a cada uno, entonces tendremos que al final de la asignacion el espacio libre en el almacenamiento es de cero.
Esta situacion nos impide darle espacio adicional a cualquier servidor nuevo o existente, sin embargo, los servidores a los cuales les hemos asignado el espacio no necesariamente estan ocupando el 100%, es mas, no es recomendable que lo hagan. Para salvar esta situacion nuestro$ amigos proveedores de soluciones de almacenamiento han desarrollado una solucion llamada Thin Provisioning.

ThP se trata de asignar un espacio del arreglo a un servidor y NO RESERVAR esa capacidad, de tal forma que mientras el servidor cree tener un espacio dedicado, por ejemplo 1TB, el arreglo solo utiliza lo que el servidor le ha mandado a escribir, de esta forma el arreglo puede disponer del espacio no utilizado para entregarselo a otros servidores o bien funciones propias de arreglo, como Snapshots y Clones.

Como ejemplo ilustremoslo de esta manera, supongamos que tenemos 10 servidores que requieren 1TB cada uno, una vez asignado el espacio los servidores lo consumen, supongamos que cada servidor consume 100GB, tendremos que cada server tiene 900GB libres que nadie mas puede utilizar. ThP reconoce esta situacion y permite que los 9TB libres (10 x 900GB) puedan ser ocupados por otros servidores, veamoslo en una imagen:




Como veremos es evidente el ahorro en espacio en disco y de esta forma se reduce la probabilidad de comprar disco cada que se requiere alojar espacio para un nuevo servidor, sin embargo hay que tener precauciones a fin de no cometer pecados mortales que causen una tragedia, entre ellos:


  • Penalizacion de rendimiento
    • Cada volumen con ThP causa utilizacion de los CPUs del arreglo, por lo que puede bajar su rendimiento, en el caso de arreglos con ThP por hardware como 3Par esta penalizacion es menor, se puede mitigar con planeacion y dimensionamiento adecuado.
  • Sobre-suscripcion
    • ThP nos permite asinar mas espacio del que realmente tenemos en el arreglo, por lo que hay que tener cuidado y monitoreado como se va consumiendo el disco, ya que si llegamos al 100% de utilizacion, las aplicaciones dejaran de funcionar y en el peor de los casos el arreglo dejara de funcionar, la forma de mitigar este riesgo es monitorear frecuentemente el porcentaje de utilizacion del espacio fisico.

Aunque los riesgos asociados a ThP existen, pueden ser facilmente mitigados y a cambio ThP nos ofrece l posibilidad de utilizar mejor el espacio adquirido y esto nos permite alojar mas servidores, realizar pruebas y respaldos etc. con lo que se justifica plenamente la inversion en licenciamiento o la inversion en un arreglo con estas capacidades.

Adicionalmente el ThP realizado por el arreglo disminuye el impacto en performance en aplicaciones como VMWare VSphere.