IBM DS3950: La nueva apuesta del gigante azul para el mercado “midrange”

Este nuevo sistema de almacenamiento, presentado hoy (a las 16:00 hora Española) a los partners de IBM, viene a mejorar la gama media de productos de almacenamiento del fabricante.

Durante la presentación, se comparó con las superventas DS47o00 así como con la reciente (y mas potente) DS5020.

La DS3950, estárá disponible en dos versiones (modelos 1814-94H y 1814-98H). Ambas  incorporan 4 interfaces de fibra a 8Gb/seg , si bien la 1894-98H además aporta 4 puertos Gigabit iSCSI.

La adición de estos puertos permite la creación de niveles de SAN, en función de necesidades de rendimiento, siendo imposible, eso si, servir una misma LUN a traves de ambos sistemas de forma simultánea.

Otra de las ventajas,  que esta gama de producto sigue aportando (como toda la familia DS), es la posibilidad de mezclar tecnologías de disco en las bandejas, de modo que permite la utilización de discos FC (146, 300 y 450 GB a 15.000 RPM/Seg) y SATA (750 GB y 1 TB).

Así mismo incluye capacidad para gestionar vía hardwareconjuntos RAID6 ( con la ventajosa variante P+Q, que permite que los grupos de este tipo tengan un rendimiento similar al de los RAID5 (además de RAID 0,1 y5). Según el fabricante, no habrá mas de un 2% de diferencia de rendimiento, con la seguridad añadida del RAID6).

Las bandejas de expansión  son similares a las utilizadas por la DS5020, si bien difieren entre otras cosas en que no permiten la utilización de discos FDE (con encriptación por hardware como en la 5020).

Con una respuesta, medida en IOPS, superior a la DS4700, (a mismo número de discos, por supuesto), y unas cifras que indican un 20% mas de IOPS  y  un 50% mas MB/Seg por watio consumido, con respecto a la DS4700.

El fabricante afirma que el sistema está construido para aportar una disponibilidad de 99,999 % (que no es cualquier dato).

Otras mejoras o cambios con respecto a la DS4700 son:

…………………………..DS4700                                    DS3950

Procesador………… Intel xScale 667                     Intel xScale 1,2 Ghz
Bus……………………. PCI-X  (1 GB/Seg)                 PCI-Express (2 GB/Seg)
Discos……………….. Hasta 112 FC/SATA            Hasta 112 FC/SATA

Cada bandeja puede alojar hasta 16 discos y los puertos FC son compatibles con velocidades FC de  2,4 y 8 (compatibilidad hacia atrás).

Su rendimiento con respecto a la DS4700, tambien puede determinarse en porcentajes como  un 25% mas IOPS en lectura de disco y un 60% mas MB/Seg en lectura de disco.

Por último indicar, que incluye las funcionalidades para realizar snapshots, clonado de volúmenes y remote mirroring, clásicos ya de esta familia.

Si quereis saber algo más de este sistema, hacedmelo saber.

Sobre el tamaño de las LUN & los Datastores en entornos VMware

Todo administrador de un entorno virtualizado (entendiendo que se entiende con ello, que dispone de almacenamiento consolidado), se plantea la disyuntiva del tamaño de las LUNs y el número de VMs que alojar en cada porción de disco.

Lo mas fácil es ir al extremo y definir una LUN “enorme”, de X terabytes en la que almacenaremos todas las máquinas virtuales.

Este sistema tiene una ventaja, y es que a menor cantidad de LUNs, menor cantidad de trabajo a gestionar tanto en cabina, como a nivel de masking, zoning y por último a nivel de Datastore* el administrador disminuye un área de gestión importante en todo centro de datos.

*Datastore:  De forma simplificada podemos decir que es la nomenclatura utulizada por VMware para designar a cada una de las LUNs visibles, si bien esto tiene ciertos matices que van más allá del objeto de este artículo).

Por contra, con este planteamiento, aparecen diversos problemas, unos menores, otros no tanto que se resuelven o minimizan con un tratamiento del almacenamiento diferente.

Vista de vCenter en el apartado de gestión de Datastores

Según algunos whitepapers de VMware, lo recomendable en general son LUNs de no más de 500 GB, si bien este dato dicho en frío tiene mucho de discutible.

Cuando VMware crea un sistema de archivos sobre cierta LUN, pasamos a denominar a esta como “Datastore” y es a partir de dicho momento en el que podemos hacer uso de la misma.

El sistema de archivos creado se denomina VMFS, y es un tipo de filesystem con capacidad de clustering, acceso múltiple y  concurrente por varias máquinas. Esto permite que en un solo datastore, residan, lean y escriban en un mismo momento varias máquinas virtuales y por tanto convivan de forma “pacífica”.

Lo que hay detrás, es que como consecuencia,  el sistema de archivos tiene que disponer de un sistema de bloqueos muy desarrollado adapado a dicho tipo de acceso y preparado para  un conjunto de máquinas con una fuerte carga de transacciones de disco que incluso puede poner en serios apuros al sistema de disco.

Es por ello que un solo datastore , con un gran número de máquinas virtuales conlleva un mayor número de bloqueos y operaciones concurrentes y por tanto en ciertos “micro-momentos” habrá VMs, a la espera de su tiempo de atención de disco y/o desbloqueo de cierta área del mismo.

Como consecuencia, el rendimiento del sistema de disco con las máquinas virtuales que corren sobre él, se ve decrementado y alguien empieza a pensar que la red SAN no es tan “galáctica” como aquel comercial se empeñaba en aseverar antes de su adquisición.

Otros pensarán que todo es culpa de la capa de virtualización y el modelo tradicional de “una máquina por servidor físico” es totalmente irremplazable.

Es por ello que también hay quien apunta una regla, de forma general, que dicta que en un datastore no se deben acumular más de 10 VMs (y con ello limitar hasta cierto punto el número de colisiones de disco por  área de almacenamiento).

¿Es entonces el tamaño del datastore o el número de VMs, lo que limita el rendimiento del sistema?, como el lector podrá suponer, ni todo es blanco…

Una mezcla de ambos componentes es lo que determina un correcto acceso a disco (prescindiendo en este pequeño examen, el tipo de almacenamiento, rendimientos, tipos de RAID y tecnología de disco, canal de acceso, caches de controladoras, y muchas otras variables a considerar en un proyecto real).

Podría pensarse que si utilizamos LUNs de menos de 500 GB y menos de 10 VMs por LUN, nos acercamos a un modelo simple de acción, pero creo que estamos de acuerdo si preciso que no aporta la misma carga, el servidor Oracle del ERP corporativo que un servidor de impresión, y por tanto será preciso medir las necesidades de acceso a disco de cada servidor y/o aplicación en cada caso para decidir el número de LUNS, las VMs que pueden ser vecinas de piso o aquellas que deben ser realojadas en lugares diferentes y mas “exclusivos” de nuestra red de almacenamiento.

Digamos que la norma a seguir pasa por no rebasar, siempre que sea factible, un 80% del rendimiento del sistema de disco por LUN, y asociar en cada una un conjunto de VMs que en su acceso total medio  no sobrepase un el límite de operaciones por segundo o requerimientos de MB/Seg por encima de la regla de negocio definida.

La contrapartida es cierta y es en la que estás pensando: Hay que crear, administrar y gestionar mas LUNs en el sistema, pero todo sea porque la aplicación de gestión de incidencias no aumente su carga con las  de tipo “esto me va lento…”

¿Que porcentaje a reservar para instantáneas en cabina?, ¿disminución de rendimiento asociada a asignación ligera de disco por VM? y ¿como repercute todo lo anterior en el sistema de backup?

Será obejeto de otro artículo , porque este acaba de terminar…;-)

Thin o Thick storage…fuera del storage?

Thin provisioning en vSphere4, funcionalidades tradicionales de almacenamiento, aportadas por la capa de aplicación.